Proposal: support application-level transaction signing
hrharder opened this issue · comments
Overview
An (informal) proposal to support signing of arbitrary — or customizable — messages in addition to Tendermint votes and proposals, such as application-level transactions from Tendermint ABCI apps, such as Cosmos or Kosu.
Motivation
We recently added remote signing support to our ABCI application, however, we will be unable to use such a configuration in production settings due the lack of available remote signers that support application-level transaction signing.
Of course this is no ones fault but our own for designing such an application, so I don't mean for this issue to imply such a feature is necessarily desirable in tmkms.
Our application logic requires validators to submit attestation transactions signed with their validating key pair, which is currently trivial when validators use FilePV and store they keys locally, but becomes impossible with a remote signer and the current tmkms implementation.
I expect supporting transaction signing within tmkms would ultimately mean supporting the signing of arbitrary data (to some degree), which may not be desirable. In such a case, additional configuration could be provided to restrict signing to certain message types, however I'm not familiar enough with the current implementation details to know if this is reasonable or possible (eg. via protobuf or similar).
Zaki says that @althea-net has a rust transaction signer which may be helpful, but I'm not sure where.
Note
Me and my team would love to assist with an implementation, but unfortunately none of us know rust.
We would be willing and able (and excited to) contribute to any specification, or implement any necessary updates in relevant Go packages (such as tendermint/privval).
@hrharder what's the domain separation story around what you want to sign with the validator key? So long as messages are sufficiently domain separated, I think this is fine to support
@tarcieri I'll try to answer your question, but I may be misunderstanding, so please clarify if the below doesn't answer.
Our ABCI application implements a simple one-way "peg-zone" (as described here) between an Ethereum contract system that supports management logic for the Tendermint-based network.
In order to make such a scheme possible, active validators must sign application-level attestation messages over state changes to the contract system (via Ethereum event logs). This is implemented as a subprocess (we call the Witness) that runs "outside" the core ABCI state machine logic and maintains an Ethereum JSONRPC connection, and solely functions to submit signed attestations transactions to a validators mempool when relevant state changes occur. Happy to go into more details about this, but I don't think it is relevant.
So yes –– the messages should be sufficiently domain separated, if I am correctly interpreting that to mean a sufficient separation between application logic, and lower-level Tendermint consensus messages. Let me know if this is not what you mean.
When I say "domain separation", I mean specifically that you are using a single signing key for two applications: as the validator consensus key, and your application-level consensus messages.
Domain separation ensures that an application-level signer can't forge consensus messages.
Gotcha – so do I take that to mean it would generally be ill-advised to do what we are doing? Using the same key for application-level and consensus messages?
The logic there was to ensure accountability of validators in submitting the application-level messages, and to easily verify the recovered signatures of the attestation messages against the active TM validator set.
I have a hard time visualizing a way in which a byzantine validator even in such a construct would be able to forge consensus messages, at least in a way they couldn't already do by messing with the internals of Tendermint, but I don't doubt I'm missing something.
We'll be posting a design for this issue soon. We'd like to support these kinds of use cases and will be exploring various options which prevent the KMS from acting like an unvalidated signing oracle but can support application-specific logic.
I've opened an issue with a more concrete design in #386. Let me know if that would meet your needs for this particular proposal.