8000 Proposal: Extend the `privval.Message` interface to support signing arbitrary hashes · Issue #5126 · cometbft/cometbft · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
Proposal: Extend the privval.Message interface to support signing arbitrary hashes #5126
Open
@rach-id

Description

@rach-id

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestneeds-triageThis issue/PR has not yet been triaged by the team.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0