Get desktop application:
View/edit binary Protocol Buffers messages
Used in: , , , , , , , ,
Used in: , , , , , , , , , , , , ,
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.
Used in:
Used in:
Compressed in base64 representation.
Used in: ,
Used in:
advertise what queries a peer can reply to (it can always query others for whatever it wants)
Used in:
The content of the capability.
Used in: ,
duplicate of GetContractRange. Can introduce a 'type' instead. result is (Classes+, PatriciaRangeProof)*
may not appear if Fin is sent to end the whole response
may not appear if Fin is sent to end the whole response
may not appear if Fin is sent to end the whole response
Used in:
Responses are sent ordered by the order given in the request.
Fin is sent after the peer sent all the data or when it encountered a block that it doesn't have its classes.
Used in:
Used in:
Contains all transaction types that can be in a new block: - User transactions (same types as MempoolTransaction: Declare, DeployAccount, Invoke) - L1Handler transactions (messages from L1, not propagated via mempool)
Used in:
Used in:
Present only if the nonce was updated
Present only if the contract was deployed or replaced in this block.
stream of leaves in the contracts tree
Used in:
request a range from the contract state tree that matches the given root (block) starts at 'start' and ends no more than 'end'. the result is (ContractRange+, PatriciaRangeProof)*
volition
how many ContractRange items to send before sending a proof
may not appear if Fin is sent to end the whole response
may not appear if Fin is sent to end the whole response
may not appear if Fin is sent to end the whole response
leafs of the contract state tree
Used in:
the key
patricia
Used in:
result is (ContractStorageRange+, PatriciaRangeProof)*
volition
may not appear if Fin is sent to end the whole response
optimized for flat storage, not through a trie (not sharing key prefixes)
Used in: ,
Used in: ,
Used in: ,
Used in:
Present only if the class is Cairo1
see https://external.integration.starknet.io/feeder_gateway/get_transaction?transactionHash=0x29fd7881f14380842414cdfdd8d6c0b1f2174f8916edcfeb1ede1eb26ac3ef0
Used in: , ,
Used in:
Used in:
Used in:
Responses are sent ordered by the order given in the request.
Fin is sent after the peer sent all the data or when it encountered a block that it doesn't have its events.
Used in: , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
mark the end of a stream of messages
Used in: , , , , , , , ,
(message has no fields)
A hash value representable as a Felt252
Used in: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
A 256 bit hash value (like Keccak256)
Used in:
Required to be 32 bytes long
Used in:
see https://external.integration.starknet.io/feeder_gateway/get_transaction?transactionHash=0x41906f1c314cca5f43170ea75d3b1904196a10101190d2b12a41cc61cfd17c An invoke V3 transaction without client-side proof (only contains proof_facts).
Used in: ,
An invoke V3 transaction with client-side proof. Used in consensus and mempool contexts where proof is included.
Used in: ,
Used in: , , , ,
to allow interleaving from several nodes
Used in:
Used in: ,
Used in: ,
L2 gas info for the block (next price and gas used).
Used in:
Doesn't contain L1Handler, as those don't need to be propagated and can be downloaded from L1.
Used in:
Used in:
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)
send when joining and periodically (period TBD)
Used in:
when a node joins it can ask peers for the nodes they know
this can be used to request for peer information when only its id is known. The number of ids is limited (TBD) we might know only of an id when getting a message through a relayer from a new peer.
a selection of random nodes the peer knows. Limited (TBD exact number).
Used in:
needed to know the height, so as to how many nodes to expect in a proof.
and also when receiving all leaves, how many to expect
Used in:
Used in:
Used in:
as bits of left/right
non leaf nodes required to build the trie given the range (leaves)
Used in: ,
Used in:
one of the accepted block hashes in the underlying layer (ethereum in starknet).
accepted is currently the current last or one before it.
a salt such that keccak(salt||blockHash||id) is below posDifficulty
Used in:
Used in:
Identifies a Starknet block based on the content streamed in the proposal.
Number of executed transactions in the proposal.
Optional payload carried in ProposalFin: commitment parts and L2 gas.
Used in:
Used in:
Network format: 1. First message is ProposalInit (init, includes all block metadata) 2. transactions is sent repeatedly (for non-empty blocks) 3. Last message is ProposalFin
Used in:
Used in: , , , ,
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in: , ,
This can be None only in transactions that don't support l2 gas. Starting from 0.14.0, MempoolTransaction and ConsensusTransaction shouldn't have None here.
Used in:
Used in:
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
Used in:
Responses are sent ordered by the order given in the request.
All of the messages related to a block need to be sent before a message from the next block is sent.
Multiple contract diffs for the same contract may appear continuously if the diff is too large or if it's more convenient.
Fin is sent after the peer sent all the data or when it encountered a block that it doesn't have its state diff.
A position in some contract's state tree is identified by the state tree's root and the key in it
Used in:
Used in:
A capability for one of the following protocols: 1. /starknet/headers/ 2. /starknet/state_diffs/ 3. /starknet/classes/ 4. /starknet/transactions/ 5. /starknet/events/ The capability defines which blocks does the node store
Used in:
(message has no fields)
Keep data for the top n blocks of the chain for the given protocol.
Used in:
Used in:
(message has no fields)
Keep all data from a hardcoded block for the given protocol.
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
see https://external.integration.starknet.io/feeder_gateway/get_transaction?transactionHash=0x41d1f5206ef58a443e7d3d1ca073171ec25fa75313394318fc83a074a6631c3
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
TBD: can support a flag to return tx hashes only, good for standalone mempool to remove them, or any node that keeps track of transaction streaming in the consensus.
Responses are sent ordered by the order given in the request. The order inside each block is according to the execution order.
Fin is sent after the peer sent all the data or when it encountered a block that it doesn't have its transactions.
Used in: , ,
Used in: , , ,
We use a type field to distinguish between prevotes and precommits instead of different messages, to make sure the data, and therefore the signatures, are unambiguous between Prevote and Precommit.
This is optional since a vote can be NIL.
Used in: