Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: Cosmos transaction signing support #386
Presently Tendermint KMS only supports signing consensus proposals/votes. That said, the prerequisites are all in place, both in the
This proposal is to add first class support to sign transactions in the format used by the Cosmos SDK. Though this project is "Tendermint KMS" and intended to be agnostic to specific Tendermint applications, the Cosmos SDK's transaction format seems widely adopted among Tendermint applications, enough to warrant this support. (In the future there are various ways this support could be generalized to signing other transaction/object types, using e.g. WASM, but that sort of approach is considered out-of-scope for this particular proposal)
Our initial use case at iqlusion is signing transactions for a Terra exchange rate oracle. The KMS-side goal of this proposal is to avoid making the KMS-side functionality hardcoded to this particular application, but rather to place a set of constraints (provided via
There are several ways such a feature could be implemented. The proposal below is one, with debatable details, which presently targets doing things as similarly to the existing Tendermint consensus signing as possible:
Here's a brief rationale and some alternatives to consider for each of these options:
About your open question wrt Ledger devices..
Extending the rust driver to support both Tendermint and Cosmos apps, should be fairly easy.
The only change the app needs is to have a menu option so users can enable/disable "sign without confirmation". BUT, I am not sure Ledger will accept this feature unless it is released with a big warning.
I would prefer to limit by protocol which tx types can be signed without confirmation. That way the check can be done inside the secure element and not in the KMS software layer.
(Maybe not the place for this suggestion, and definitely too early. LMK I will remove it)
Reading in #361 that proposal would give the ability to sign messages: please structure this so that (down the line) messages can be stored in IPFS (for larger files, such as PDFs) or similar file storage protocol. A digital notary is a real world business use case with large demand. The current landscape for PAdES-Long Term Validation PDF signature/certification is an oligopoly maintained by Adobe and a few trusted partners (AATL), with complex implementation, exorbitant costs, and outdated technology.
PS: I would be interested in using a PDF digital notary for my other (non blockchain related) company.
@gaia to the extent this can be used as a digital notary service, I think the main idea here would be notarizing things as Cosmos transactions, which are validated and stored by a Tendermint application which understands the Cosmos SDK transaction format.
Anything more general than that, beyond generalizing something which could be used to produce Cosmos SDK-compatible transactions, I'd suggest discussing on #361 instead.