btc commiter state and proof

[any0Ne1010]

1. Work Flow

1.1 Batch & Proof

flowchart TD
    A[proof tx] --> B[check permission]
    B --> |no permission| C[return error]
    B --> |has permission| D[execute tx verification]
    D --> |fail| C
    D --> |success| E[save tx to db] 
    E --> F[emit event]

1.2 Listen for events

flowchart TD
    A[event] --> B[parse event]
    B --> C[structure proposal tx]

1.3 Submit proposal

flowchart TD
    A[proposal tx] --> B[check permssion]
    B --> |fail| C[return error]
    B --> |success| D[proposal already exists]
    D --> |yes| E[add vote]
    D --> |no| F[create vote]
    F --> E 
    E --> G[check if the vote exceeds the majority?]
    G --> |yes| H[calculate client address to submit to BTC ]
    H -->  I[set vote status to success]
    G --> |no|J[end]
    I --> J

1.4 Check proposal status

flowchart TD
    A[check proposal status] --> |success| B[parse the winning address of the poll]
    B --> C[is the address equal to myself?]
    C --> |yes| D[structure proof and sign]
    C --> |no| G[end]
    A --> |voting| G

1.5 Submit proof

flowchart TD
    A[proof and signature] --> |submit to BTC| B[end]

[any0Ne1010]

2. Need clear details
   • How to determine which Client's turn to submit proof to BTC?
   • How does BTC verify the Client's permissions?
   • Whether Aggregator may do evil and whether its permissions need to be verified.

[any0Ne1010]

• "How to determine which Client's turn to submit proof to BTC?" A simple algorithm: tx_id % total_clients_amount. But it has a problem: If the client is downtime after the proposal is successful, how to solve it?

[any0Ne1010]

• "Whether Aggregator may do evil and whether its permissions need to be verified" I think we just check the permission when the aggregator submits the proof.

[any0Ne1010]

• "How does BTC verify the Client's permissions?" I think it can't. So we also need to add the client's signature when submitting the proof to btc.

[any0Ne1010]

3. Interface and Data Structure

3.1 Interface 3.1.1 Tx RPC

// Msg defines the Msg service.
service Msg {
  // BatchProof defines a method for a committer to commit a batch proof.
  rpc BatchProof(MsgBatchProofTx) returns (MsgBatchProofTxResponse) {
    option (google.api.http) = {
      post: "/committer/batch_proof"
      body: "*"
    };
  }

  // TapRoot defines a method for a committer to commit a taproot.
  rpc TapRoot(MsgTapRootTx) returns (MsgTapRootTxResponse) {
    option (google.api.http) = {
      post: "/committer/taproot"
      body: "*"
    };
  }

  // TimeoutProposal defines a method for a committer to timeout a proposal.
  rpc TimeoutProposal(MsgTimeoutProposalTx) returns (MsgTimeoutProposalTxResponse) {
    option (google.api.http) = {
      post: "/committer/timeout_proposal"
      body: "*"
    };
  }
}

3.1.2 Query RPC

// Query defines the gRPC querier service.
service Query {
  // Params queries the parameters of the module.
  rpc Params(QueryParamsRequest) returns (QueryParamsResponse) {
    option (google.api.http).get = "/evmos/ethermint/committer/params";
  }

  // LastProposalId queries the last proposal ID of the module.
  rpc LastProposalId(QueryLastProposalIdRequest) returns (QueryLastProposalIdResponse) {
    option (google.api.http).get = "/evmos/ethermint/committer/last_proposal_id";
  }

  // Proposal queries a proposal by its ID.
  rpc Proposal(QueryProposalRequest) returns (QueryProposalResponse) {
    option (google.api.http).get = "/evmos/ethermint/committer/proposals/{proposal_id}";
  }
}

3.2 Data Structure 3.2.1 Tx Msg

MsgBatchProofTx

message MsgBatchProofTx {
  option (gogoproto.goproto_getters) = false;

  uint64 id = 1;

  string from = 2;

  string proof_hash = 3;

  string state_root_hash = 4;

  uint64 start_index = 5;

  uint64 end_index = 6;
}

message MsgBatchProofTxResponse {
  option (gogoproto.goproto_getters) = false;

  uint64 id = 1;
}

MsgTapRootTx

message MsgTapRootTx {
  option (gogoproto.goproto_getters) = false;

  uint64 id = 1;

  string from = 2;

  string bitcoin_tx_hash = 3;
}

message MsgTapRootTxResponse {
  option (gogoproto.goproto_getters) = false;

  uint64 id = 1;
}

MsgTimeoutProposalTx

message MsgTimeoutProposalTx {
  option (gogoproto.goproto_getters) = false;

  uint64 id = 1;

  string from = 2;
}

message MsgTimeoutProposalTxResponse {
  option (gogoproto.goproto_getters) = false;

  uint64 id = 1;
}

3.2.2 Query Request

QueryLastProposalIdRequest

message QueryLastProposalIdRequest {}

message QueryLastProposalIdResponse {
  uint64 last_proposal_id = 1;

  uint64 end_index = 2;
}

QueryProposalRequest

message QueryProposalRequest {
  uint64 proposal_id = 1;
}

message QueryProposalResponse {
  Proposal proposal = 1;
}

3.2.3 State

Proposal

message Proposal {
  uint64 id = 1;
  string proposer = 2;
  string proof_hash = 3;
  string state_root_hash = 4;
  uint64 start_index = 5;
  uint64 end_index = 6;
  uint64 block_hight = 7;
  repeated string voted_list_phase_commit = 8;
  repeated string voted_list_phase_timeout = 9;
  uint64 status = 10;
  string bitcoin_tx_hash = 11;
  string winner = 12;
}

[zhouop0]

I suppose the transaction including procedure 1.3 should include ‘finalbatchNum‘. It is used to find which proof and stateRoot should be submitted to BTC network.

During phase 1.3, Why should client addresses be submitted to the BTC network？ Whether the client address should be submitted to the B2Node？

[any0Ne1010]

"During phase 1.3, Why should client addresses be submitted to the BTC network？ Whether the client address should be submitted to the B2Node？"

@zhouop0 The client's address does not need to be submitted to BTC. Its address only needs to be recorded in B2Node, which means that we have selected the address of the client to submit the proof to BTC. Finally, the selected client submits the proof to BTC and attaches its signature.

[any0Ne1010]

• "How to determine which Client's turn to submit proof to BTC?" A simple algorithm: tx_id % total_clients_amount. But it has a problem: If the client is downtime after the proposal is successful, how to solve it?

Maybe we should add more one proposal to solve it.

If the selected client submits the proof to BTC in time, the hash of its transaction result is submitted to B2Node in the form of a proposal. Other clients monitor the event, verify the transaction, and vote if the transaction is OK. If the selected node does not submit the proof to BTC in time, other clients will trigger the timeout operation, and then submit the timeout transaction to the node, and a new client will be elected after the vote is passed.

1.3 Submit proposal

flowchart TD
    A[proposal tx] --> B[check permssion]
    B --> |fail| C[return error]
    B --> |success| D[proposal already exists]
    D --> |yes| E[add vote]
    D --> |no| F[create vote]
    F --> E 
    E --> G[check if the vote exceeds the majority?]
    G --> |yes| H[calculate client address to submit to BTC ]
    H -->  I[set vote status to pending_status]
    G --> |no|J[end]
    I --> J

[BananaLF]

2. Need clear details

• How to determine which Client's turn to submit proof to BTC?
• How does BTC verify the Client's permissions?
• Whether Aggregator may do evil and whether its permissions need to be verified.

How verify proof which was submited into btc?

[Stonepapa]

BananaLF

After submitting proof to Bitcoin, the committer client will subscribe the Bitcoin state and submit a result proposal to B2 Nodes. Others committer clients will vote for the result proposal by checking Bitcoin state.

The above mechanisam will make sure that the rollup proof will be recoreded on Bitcoin.

[BananaLF]

BananaLF

After submitting proof to Bitcoin, the committer client will subscribe the Bitcoin state and submit a result proposal to B2 Nodes. Others committer clients will vote for the result proposal by checking Bitcoin state.

The above mechanisam will make sure that the rollup proof will be recoreded on Bitcoin.

Thank you for reply. But the mechanisam of verifing proof use fraud proof like BitVM maybe much better.