Im working on an user interface for hyperledger fabric with bevel operator. In fabric's default implementation, the CA creates a key for signing transactions for each user. I wanted to remove this process by allowing the user to sign the transaction with his own private key. I discovered that you can separate the submit transaction process by create the transaction first, but i dont know how to submit it after it is signed. What can i do to implement this?

I tried submitting it after it was signed, but it returned errors due to it not being signed with the wallet key

Im working on an user interface for hyperledger fabric with bevel operator. In fabric's default implementation, the CA creates a key for signing transactions for each user. I wanted to remove this process by allowing the user to sign the transaction with his own private key. I discovered that you can separate the submit transaction process by create the transaction first, but i dont know how to submit it after it is signed. What can i do to implement this?

I tried submitting it after it was signed, but it returned errors due to it not being signed with the wallet key

• blockchain
• hyperledger-fabric
• hyperledger
• pki
• hyperledger-fabric-ca

1 Answer 1

Using the fine-grained transaction flow in the Fabric Gateway client API, you can explicitly sign each message in the flow before it is sent: proposal, transaction and commit. The approach for doing this where your application is operating as an intermediary to allow remote clients to interact with the Fabric network is documented as Off-line signing. See the API documentation (Go, Node, Java) for a more detailed description and some example code snippets.

In summary, the client needs to provide your intermediary application with their public credentials: X.509 certificate and the Member Services Provider ID to which they are associated. You use these to create a Gateway instance. To perform off-line signing:

1. A Contract obtained from the Gateway is used to create a transaction Proposal.

2. You get the digest from the Proposal (Go, Node, Java) and return this to the client for them to create a signature over the Proposal content.

3. The client returns the signature to you, and you use the Gateway to create a new signed Proposal (Go, Node, Java) from the signature and the serialized bytes of the original (unsigned) Proposal.

The signed Proposal can then be sent for endorsement. You follow the same steps to sign the resulting Transaction and Commit objects as the flow progresses.

By default, digests are a SHA256 hash of the message content. If your signing implementation requires a different hash algorithm or the entire message bytes, you can set an appropriate hash algorithm or specify the NONE (or no-op) hash algorithm when creating the Gateway instance.