With the Block SDK, blocks are broken up into smaller partial blocks called
lanehas its own custom block building logic and stores distinct types of transactions.
- Each lane can only consume a portion of the block as defined on the
lane's configuration (
- When a block proposal is requested, a block will fill with transactions from each
lane, iteratively, in the order in which the
lanesare defined in the application.
- When a block proposal is processed, each
lanewill verify its portion of the block, iteratively, in the order in which the
lanesare defined in the application.
- Transactions in blocks MUST respect the ordering of lanes.
🔁 Background: Transaction Lifecycle
Knowledge of the general transaction lifecycle is important to understand how
- A transaction begins when it is signed and broadcasted to a node on a chain.
- It will be then be verified by the application on the node.
- If it is valid, it will be inserted into the node's
mempool, which is a storage area for transactions before inclusion in a block.
- If the node happens to be a
validator, and is proposing a block, the application will call
PrepareProposalto create a new block proposal.
- The proposer will look at what transactions they have in their mempool, iteratively select transactions until the block is full, and share the proposal with other validators.
- When a different validator receives a proposal, the validator will verify its contents via
ProcessProposalbefore signing it.
- If the proposal is valid, the validator will sign the proposal and broadcast their vote to the network.
- If the block is invalid, the validator will reject the proposal.
- Once a proposal is accepted by the network, it is committed as a block and the transactions that were included are removed from every validator's mempool.
🛣️ Lane Lifecycle
Lanes introduce new steps in the transaction lifecycle outlined above.
LanedMempool is composed of several distinct
lanes that store their own transactions. The
LanedMempool will insert the transaction into all
lanes that accept it
- After the base application accepts a transaction, the transaction will be checked to see if it can go into any
lanes, as defined by the lane's
Lane's can be configured to only accept transactions that match a certain criteria. For example, a
lanecould be configured to only accept transactions that are staking related (such as a free-transaction lane).
- When a new block is proposed, the
PrepareProposalHandlerof the application will iteratively call
lane(in the order in which they are defined in the application). The
PrepareLanemethod is similar to
lanewill trigger the lane to reap transactions from its mempool and add them to the proposal (if they respect the verification rules of the
- When proposals are verified in
ProcessProposalby other validators, the
lanein the same order as they were called in the
- Each subsequent call to
ProcessLanewill filter out transactions that belong to previous lanes. A given lane's ProcessLane will only verify transactions that belong to that lane.
Let's say we have a
LanedMempool composed of two lanes:
LaneA is defined first in the
LaneB is defined second.
LaneA contains transactions Tx1 and Tx2 and
LaneB contains transactions
Tx3 and Tx4.
When a new block needs to be proposed, the
PrepareProposalHandler will call
LaneA first and
PrepareLane is called on
LaneA will reap transactions from its mempool and add them to the proposal. The same applies for
LaneA reaps transactions Tx1 and Tx2 and
LaneB reaps transactions Tx3 and Tx4. This gives us a proposal composed of the following:
ProcessProposalHandler is called, it will call
LaneA with the proposal composed of Tx1, Tx2, Tx3, and Tx4.
LaneA will then verify Tx1 and Tx2 and return the remaining transactions - Tx3 and Tx4. The
ProcessProposalHandler will then call
LaneB with the remaining transactions - Tx3 and Tx4.
LaneB will then verify Tx3 and Tx4 and return no remaining transactions.