Description
Feature Request
Summary
Celestia is introducing high throughput and low latency gossiping protocols that rely on the validators being able to commit to offchain messages using their consensus keys and existing KMS. However, the current key management systems only support signing predefined consensus messages via the privval.Message
interface. To address this limitation, this proposal extends that interface to allow signing arbitrary message hashes in a backwards compatible way.
It’s worth noting that signing hashes of offchain messages doesn’t require the typical “watermark” double signing protection.
Details
More specifically, Celestia is adding two protocols that would make use of this feature. The first is what we’re calling the Full Mesh Overlay (FMO), in which all validators directly connect to each other alongside their normal connections to consensus nodes. The second is what we’re referring to as Vacuum!, in which validators are committing to blobs that they have before they are included in a block.
Proposal
Include the following types in the privval.Message
interface:
message SignP2PMessageRequest {
bytes hash = 1;
string chain_id = 2;
string unique_id = 3;
}
message SignedP2PMessageResponse {
bytes signature = 1;
RemoteSignerError error = 2;
}
So the Message
interface will become:
message Message {
oneof sum {
PubKeyRequest pub_key_request = 1;
PubKeyResponse pub_key_response = 2;
SignVoteRequest sign_vote_request = 3;
SignedVoteResponse signed_vote_response = 4;
SignProposalRequest sign_proposal_request = 5;
SignedProposalResponse signed_proposal_response = 6;
PingRequest ping_request = 7;
PingResponse ping_response = 8;
// new types:
SignP2PMessageRequest sign_p2p_message_request = 9;
SignedP2PMessageResponse signed_p2p_message_response = 10;
}
}
Pros
- Native support for signing arbitrary offchain messages.
- Lay the groundwork for other consumers of the CometBFT and Malachite stacks to implement modern low latency high throughput gossiping mechanisms.
- Backwards compatible.
Security risks
Double-signing protection isn’t necessary for signing p2p messages in almost all cases. To simplify the implementation for the many kms we’re suggesting to explicitly not add it.