Get desktop application:
View/edit binary Protocol Buffers messages
Responses are sent ordered by the order given in the request.
Used in:
Fin is sent after the peer sent all the data or when it encountered a block that it doesn't have its header.
sent to all peers (except the ones this was received from, if any). for a fraction of peers, also send the GetBlockHeaders response (as if they asked for it for this block)
Note: commitments may change to be for the previous blocks like comet/tendermint hash of block header sent to L1
Used in:
For the structure of the block hash, see https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/header/#block_hash
This can be deduced from context. We can consider removing this field.
Encoded in Unix time.
Patricia root of contract and class patricia tries. Each of those tries are of height 251. Same as in L1. Later more trees will be included
The state diff commitment returned by the Starknet Feeder Gateway
For more info, see https://community.starknet.io/t/introducing-p2p-authentication-and-mismatch-resolution-in-v0-12-2/97993 The leaves contain a hash of the transaction hash and transaction signature.
By order of execution. TBD: required? the client can execute (powerful machine) and match state diff
By order of issuance. TBD: in receipts?
By order of issuance. This is a patricia root. No need for length because it's the same length as transactions.
Starknet version
for now, we assume a small consensus, so this fits in 1M. Else, these will be repeated and extracted from this message.
can be more explicit here about the signature structure as this is not part of account abstraction