/events/blocks allows the caller to query a sequence of BlockEvents indicating which blocks were added and removed from storage to reach the current state. Following BlockEvents allows lightweight clients to update their state without needing to implement their own syncing logic (like finding the common parent in a reorg). /events/blocks is considered an “indexer” endpoint and Rosetta implementations are not required to complete it to adhere to the Rosetta spec. However, any Rosetta “indexer” MUST support this endpoint.
EventsBlocksRequest is utilized to fetch a sequence of BlockEvents indicating which blocks were added and removed from storage to reach the current state.
The network_identifier specifies which network a particular object is associated with.
offset is the offset into the event stream to sync events from. If this field is not populated, we return the limit events backwards from tip. If this is set to 0, we start from the beginning.
x >= 05
limit is the maximum number of events to fetch in one call. The implementation may return <= limit events.
x >= 05
Expected response to a valid request
EventsBlocksResponse contains an ordered collection of BlockEvents and the max retrievable sequence.
max_sequence is the maximum available sequence number to fetch.
x >= 05
events is an array of BlockEvents indicating the order to add and remove blocks to maintain a canonical view of blockchain state. Lightweight clients can use this event stream to update state without implementing their own block syncing logic.
BlockEvent represents the addition or removal of a BlockIdentifier from storage. Streaming BlockEvents allows lightweight clients to update their own state without needing to implement their own syncing logic.