Contradicting TX IDs (common.Envelope and protoblocktx.Tx)

[liran-funaro]

The committer receives two kinds of TX IDs:

• common.Envelope
• protoblocktx.Tx

They may be contradicting.

[liran-funaro]

Suggested API changes

Global API (protoblocktx)

Remove id from protoblocktx.Tx

message Tx {
    repeated TxNamespace namespaces = 1; // Namespaces associated with the transaction.
    repeated bytes signatures = 2; // signature per namespace.
}

Coordinator

Add tx_ids field to protocoordinatorservice.Block

message Block {
    uint64 number = 1;                  // The block number.
    repeated protoblocktx.Tx txs = 2;   // List of transactions within the block.
    repeated string tx_ids = 3;         // Transaction IDs within the block generated by the orderer.
    repeated uint32 txs_num = 4;        // Transaction number within the block generated by the orderer.
    repeated TxStatusInfo rejected = 5; // Rejected transactions.
}

Verifier

The verifier doesn't need the TX ID and the coordinator doesn't use the TX ID in the response. Thus, it can be removed from the response. This makes the verifier response identical to protoblocktx.StatusWithHeight. Thus, the verifier can return protoblocktx.StatusWithHeight instead of its own protosigverifierservice.Response.

message StatusWithHeight {
    Status code = 1;
    uint64 block_number = 2;
    uint32 tx_number = 3;
}

VC

The VC service doesn't require any changes as protovcservice.Transaction already includes a separate TX ID field.

message Transaction {
  string ID = 1;
  repeated protoblocktx.TxNamespace namespaces = 2;
  optional InvalidTxStatus prelim_invalid_tx_status = 3;
  uint64 block_number = 4;
  uint32 tx_num = 5;
}

[cendhu]

The proposed structure is fine, but it is important that the endorsement signature also covers the txID. In Fabric, the endorsers' sign the proposal hash (which includes the txID), binding the endorsement to a specific transaction. This is a security measure that ensures an endorsement can only be used once. As long as we enforce the inclusion of the txID during both signature generation and verification, we can proceed with using the simplified transaction message.

[liran-funaro]

Solved by #110