diff --git a/abci/README.md b/abci/README.md new file mode 100644 index 00000000..ea035d6e --- /dev/null +++ b/abci/README.md @@ -0,0 +1,222 @@ +# Block SDK Proposal Construction & Verification + +## Overview + +This readme describes how the Block SDK constructs and verifies proposals. To get a high level overview of the Block SDK, please see the [Block SDK Overview](../README.md). + +The Block SDK is a set of Cosmos SDK and ABCI++ primitives that allow chains to fully customize blocks for specific use cases. It turns your chain's blocks into a **`highway`** consisting of individual **`lanes`** with their own special functionality. The mempool is no longer a single black box, but rather a set of lanes that can be customized to fit your application's needs. Each lane is meant to deal with specific a set of transactions, and can be configured to fit your application's needs. + +Proposal construction / verification is done via the `PrepareProposal` and `ProcessProposal` handlers defined in [`abci.go`](./abci.go), respectively. Each block proposal built by the Block SDK enforces that a block is comprised of contiguous sections of transactions that belong to a single lane. + +For example, if your application has 3 lanes, `A`, `B`, and `C`, and the order of lanes is `A -> B -> C`, then the proposal will be built as follows: + +```golang +blockProposal := { + Tx1, (Lane A) + Tx2, (Lane A) + Tx3, (Lane A) + Tx4, (Lane B) + Tx5, (Lane B) + Tx6, (Lane B) + Tx7, (Lane C) + Tx8, (Lane C) + Tx9, (Lane C) +} +``` + +## Proposal Construction + +The `PrepareProposal` handler is called by the ABCI++ application when a new block is requested by the network for the given proposer. At runtime, the `PrepareProposal` handler will do the following: + +1. Determine the order of lanes it wants to construct the proposal from. If the application is configured to utilize the Block SDK module, it will fetch the governance configured order of lanes and use that. Otherwise, it will use the order defined in your [`app.go`](../tests/app/app.go) file (see our test app as an example). +2. After determining the order, it will chain together all of the lane's `PrepareLane` methods into a single `PrepareProposal` method. +3. Each lane will select transactions from its mempool, verify them according to its own rules, and return a list of valid transactions to add and a list of transactions to remove i.e. see [`PrepareLane`](../block/base/abci.go). +4. The transactions will only be added to the current proposal being built _iff_ the transactions are under the block gas and size limit for that lane. If the transactions are over the limit, they will NOT be added to the proposal and the next lane will be called. +5. A final proposal is returned with all of the valid transactions from each lane. + +If any of the lanes fail during `PrepareLane`, the next lane will be called and the proposal will be built from the remaining lanes. This is a fail-safe mechanism to ensure that the proposal is always built, even if one of the lanes fails to prepare. Additionally, state is mutated _iff_ the lane is successful in preparing its portion of the proposal. + +To customize how much block-space a given lane consumes, you have to configure the `MaxBlockSpace` variable in your lane configuration object (`LaneConfig`). Please visit [`lanes.go`](../tests/app/lanes.go) for an example. This variable is a map of lane name to the maximum block space that lane can consume. Note that if the Block SDK module is utilized, the `MaxBlockSpace` variable will be overwritten by the governance configured value. + +### Proposal Construction Example + +> Let's say your application has 3 lanes, `A`, `B`, and `C`, and the order of lanes is `A -> B -> C`. +> +> * Lane `A` has a `MaxBlockSpace` of 1000 bytes and 500 gas limit. +> * Lane `B` has a `MaxBlockSpace` of 2000 bytes and 1000 gas limit. +> * Lane `C` has a `MaxBlockSpace` of 3000 bytes and 1500 gas limit. + +Lane `A` currently contains 4 transactions: + +* Tx1: 100 bytes, 100 gas +* Tx2: 800 bytes, 300 gas +* Tx3: 200 bytes, 100 gas +* Tx4: 100 bytes, 100 gas + +Lane `B` currently contains 4 transactions: + +* Tx5: 1000 bytes, 500 gas +* Tx6: 1200 bytes, 600 gas +* Tx7: 1500 bytes, 300 gas +* Tx8: 1000 bytes, 400 gas + +Lane `C` currently contains 4 transactions: + +* Tx9: 1000 bytes, 500 gas +* Tx10: 1200 bytes, 600 gas +* Tx11: 1500 bytes, 300 gas +* Tx12: 100 bytes, 400 gas + +Assuming all transactions are valid according to their respective lanes, the proposal will be built as follows (this is pseudo-code): + +```golang +// Somewhere in abci.go a new proposal is created: +blockProposal := proposals.NewProposal(...) +... +// First lane to be called is lane A, this will return the following transactions to add after PrepareLane is called: +partialProposalFromLaneA := { + Tx1, // 100 bytes, 100 gas + Tx2, // 800 bytes, 300 gas + Tx3, // 200 bytes, 100 gas +} +... +// First Lane A will update the proposal. +if err := blockProposal.Update(partialProposalFromLaneA); err != nil { + return err +} +... +// Next, lane B will be called with the following transactions to add after PrepareLane is called: +// +// Note: Here, Tx6 is excluded because it and Tx5's gas would exceed the lane gas limit. Tx7 is similarly excluded because it and Tx5's size would exceed the lane block size limit. Note that Tx5 will always be included first because it is ordered first and it is valid given the lane's constraints. +partialProposalFromLaneB := { + Tx5, // 1000 bytes, 500 gas + Tx8, // 1000 bytes, 400 gas +} +... +// Next, lane B will update the proposal. +if err := blockProposal.Update(partialProposalFromLaneB); err != nil { + return err +} +... +// Finally, lane C will be called with the following transactions to add after PrepareLane is called: +partialProposalFromLaneC := { + Tx9, // 1000 bytes, 500 gas + Tx10, // 1200 bytes, 600 gas + Tx12, // 100 bytes, 400 gas +} +... +// Finally, lane C will update the proposal. +if err := blockProposal.Update(partialProposalFromLaneC); err != nil { + return err +} +... +// The final proposal will be: +blockProposal := { + Tx1, // 100 bytes, 100 gas + Tx2, // 800 bytes, 300 gas + Tx3, // 200 bytes, 100 gas + Tx5, // 1000 bytes, 500 gas + Tx8, // 1000 bytes, 400 gas + Tx9, // 1000 bytes, 500 gas + Tx10, // 1200 bytes, 600 gas + Tx12, // 100 bytes, 400 gas +} +``` + +If any transactions are invalid, they will not be included in the lane's partial proposal. + +## Proposal Verification + +The `ProcessProposal` handler is called by the ABCI++ application when a new block has been proposed by the proposer and needs to be verified by the network. At runtime, the `ProcessProposal` handler will do the following: + +1. Determine the order of lanes it wants to verify the proposal with. If the application is configured to utilize the Block SDK module, it will fetch the governance configured order of lanes and use that. Otherwise, it will use the order defined in your [`app.go`](../tests/app/app.go) file (see our test app as an example). +2. After determining the order, it will chain together all of the lane's `ProcessLane` methods into a single `ProcessProposal` method. +3. Given that the proposal contains contiguous sections of transactions from a given lane, each lane will verify the transactions that belong to it and return the remaining transactions to verify for the next lane - see [`ProcessLane`](../block/base/abci.go). +4. After determining and verifiying the transactions that belong to it, the lane will attempt to update the current proposal - so as to replicate the exact same steps done in `PrepareProposal`. If the lane is unable to update the proposal, it will return an error and the proposal will be rejected. +5. Once all lanes have been called and no transactions are left to verify, the proposal outputted by `ProcessProposal` should be the same as the proposal outputted by `PrepareProposal`! + +If any of the lanes fail during `ProcessLane`, the entire proposal is rejected. There ensures that there is always parity between the proposal built and the proposal verified. + +### Proposal Verification Example + +Following the example above, let's say we recieve the same proposal from the network: + +```golang +blockProposal := { + Tx1, // 100 bytes, 100 gas + Tx2, // 800 bytes, 300 gas + Tx3, // 200 bytes, 100 gas + Tx5, // 1000 bytes, 500 gas + Tx8, // 1000 bytes, 400 gas + Tx9, // 1000 bytes, 500 gas + Tx10, // 1200 bytes, 600 gas + Tx12, // 100 bytes, 400 gas +} +``` + +The proposal will be verified as follows (this is pseudo-code): + +```golang +// Somewhere in abci.go a new proposal is created: +blockProposal := proposals.NewProposal(...) +... +// First lane to be called is lane A, this will return the following transactions that it verified and the remaining transactions to verify after calling ProcessLane: +verifiedTransactionsFromLaneA, remainingTransactions := { + Tx1, // 100 bytes, 100 gas + Tx2, // 800 bytes, 300 gas + Tx3, // 200 bytes, 100 gas +}, { + Tx5, // 1000 bytes, 500 gas + Tx8, // 1000 bytes, 400 gas + Tx9, // 1000 bytes, 500 gas + Tx10, // 1200 bytes, 600 gas + Tx12, // 100 bytes, 400 gas +} +... +// First Lane A will update the proposal. +if err := blockProposal.Update(verifiedTransactionsFromLaneA); err != nil { + return err +} +... +// Next, lane B will be called with the following transactions to verify and the remaining transactions to verify after calling ProcessLane: +verifiedTransactionsFromLaneB, remainingTransactions := { + Tx5, // 1000 bytes, 500 gas + Tx8, // 1000 bytes, 400 gas +}, { + Tx9, // 1000 bytes, 500 gas + Tx10, // 1200 bytes, 600 gas + Tx12, // 100 bytes, 400 gas +} +... +// Next, lane B will update the proposal. +if err := blockProposal.Update(verifiedTransactionsFromLaneB); err != nil { + return err +} +... +// Finally, lane C will be called with the following transactions to verify and the remaining transactions to verify after calling ProcessLane: +verifiedTransactionsFromLaneC, remainingTransactions := { + Tx9, // 1000 bytes, 500 gas + Tx10, // 1200 bytes, 600 gas + Tx12, // 100 bytes, 400 gas +}, {} +... +// Finally, lane C will update the proposal. +if err := blockProposal.Update(verifiedTransactionsFromLaneC); err != nil { + return err +} +... +// The final proposal will be: +blockProposal := { + Tx1, // 100 bytes, 100 gas + Tx2, // 800 bytes, 300 gas + Tx3, // 200 bytes, 100 gas + Tx5, // 1000 bytes, 500 gas + Tx8, // 1000 bytes, 400 gas + Tx9, // 1000 bytes, 500 gas + Tx10, // 1200 bytes, 600 gas + Tx12, // 100 bytes, 400 gas +} +``` + +As we can see, in the process of verifying a proposal, the proposal is updated to reflect the exact same steps done in `PrepareProposal`. + diff --git a/adapters/signer_extraction_adapter/README.md b/adapters/signer_extraction_adapter/README.md new file mode 100644 index 00000000..7affb848 --- /dev/null +++ b/adapters/signer_extraction_adapter/README.md @@ -0,0 +1,31 @@ +# Signer Extraction Adapter (SEA) + +## Overview + +The Signer Extraction Adapter is utilized to retrieve the signature information of a given transaction. This is purposefully built to allow application developers to retrieve signer information in the case where the default Cosmos SDK signature information is not applicable. + +## Utilization within the Block SDK + +Each lane can configure it's own Signer Extraction Adapter (SEA). However, for almost all cases each lane will have the same SEA. The SEA is utilized to retrieve the address of the signer and nonce of the transaction. It's utilized by each lane's mempool to retrieve signer information as transactions are being inserted and for logging purposes as a proposal is being created / verified. + +## Configuration + +To extend and implement a new SEA, the following interface must be implemented: + +```go +// Adapter is an interface used to determine how the signers of a transaction should be extracted +// from the transaction. +type Adapter interface { + GetSigners(sdk.Tx) ([]SignerData, error) +} +``` + +The `GetSigners` method is responsible for extracting the signer information from the transaction. The `SignerData` struct is defined as follows: + +```go +type SignerData struct { + Signer sdk.AccAddress + Sequence uint64 +} +``` + diff --git a/adapters/signer_extraction_adapter/signer_extraction_adapter.go b/adapters/signer_extraction_adapter/signer_extraction_adapter.go index 98ae04f9..c7f0d6da 100644 --- a/adapters/signer_extraction_adapter/signer_extraction_adapter.go +++ b/adapters/signer_extraction_adapter/signer_extraction_adapter.go @@ -25,7 +25,7 @@ func (s SignerData) String() string { return fmt.Sprintf("SignerData{Signer: %s, Sequence: %d}", s.Signer, s.Sequence) } -// SignerExtractionAdapter is an interface used to determine how the signers of a transaction should be extracted +// Adapter is an interface used to determine how the signers of a transaction should be extracted // from the transaction. type Adapter interface { GetSigners(sdk.Tx) ([]SignerData, error) diff --git a/block/README.md b/block/README.md new file mode 100644 index 00000000..f3715f9b --- /dev/null +++ b/block/README.md @@ -0,0 +1,103 @@ +# Block SDK Mempool & Lanes + +## Overview + +> This document describes how the Block SDK mempool and lanes operate at a high level. To learn more about how to construct lanes, please visit the [build my own lane readme](../lanes/build-your-own/README.md) and/or the [base lane documentation](./base/README.md). To read about how proposals are construct, visit the [abci readme](../abci/README.md). + +Mempools are traditionally used to temporarily store transactions before they are added to a block. The Block SDK mempool is no different. However, instead of treating each transaction the same, the Block SDK allows for developers to create `Lanes` that permit transactions to be ordered differently based on the properties of the transaction itself. + +What was once a single monolithic data structure, is now a collection of sub-mempools that can be configured to order transactions in a way that makes sense for the application. + +## Lanes + +Lanes are utilized to allow developers to create custom transaction order, validation, and execution logic. Each lane is responsible for maintaining its own mempool - ordering transactions as it desires only for the transactions it wants to accept. For example, a lane may only accept transactions that are staking related, such as the free lane. The free lane may then order the transactions based on the user's on-chain stake. + +When proposals are constructed, the transactions from a given lane are selected based on highest to lowest priority, validated according to the lane's verfication logic, and included in the proposal. + +Each lane must implement the `Lane` interface, although it is highly recommended that developers extend the [base lane](./base/README.md) to create new lanes. + +```go +// LaneMempool defines the interface a lane's mempool should implement. The basic API +// is the same as the sdk.Mempool, but it also includes a Compare function that is used +// to determine the relative priority of two transactions belonging in the same lane. +type LaneMempool interface { + sdkmempool.Mempool + + // Compare determines the relative priority of two transactions belonging in the same lane. Compare + // will return -1 if this transaction has a lower priority than the other transaction, 0 if they have + // the same priority, and 1 if this transaction has a higher priority than the other transaction. + Compare(ctx sdk.Context, this, other sdk.Tx) (int, error) + + // Contains returns true if the transaction is contained in the mempool. + Contains(tx sdk.Tx) bool + + // Priority returns the priority of a transaction that belongs to this lane. + Priority(ctx sdk.Context, tx sdk.Tx) any +} + +// Lane defines an interface used for matching transactions to lanes, storing transactions, +// and constructing partial blocks. +type Lane interface { + LaneMempool + + // PrepareLane builds a portion of the block. It inputs the current context, proposal, and a + // function to call the next lane in the chain. This handler should update the context as needed + // and add transactions to the proposal. Note, the lane should only add transactions up to the + // max block space for the lane. + PrepareLane( + ctx sdk.Context, + proposal proposals.Proposal, + next PrepareLanesHandler, + ) (proposals.Proposal, error) + + // ProcessLane verifies this lane's portion of a proposed block. It inputs the current context, + // proposal, transactions that belong to this lane, and a function to call the next lane in the + // chain. This handler should update the context as needed and add transactions to the proposal. + // The entire process lane chain should end up constructing the same proposal as the prepare lane + // chain. + ProcessLane( + ctx sdk.Context, + proposal proposals.Proposal, + txs []sdk.Tx, + next ProcessLanesHandler, + ) (proposals.Proposal, error) + + // GetMaxBlockSpace returns the max block space for the lane as a relative percentage. + GetMaxBlockSpace() math.LegacyDec + + // SetMaxBlockSpace sets the max block space for the lane as a relative percentage. + SetMaxBlockSpace(math.LegacyDec) + + // Name returns the name of the lane. + Name() string + + // SetAnteHandler sets the lane's antehandler. + SetAnteHandler(antehander sdk.AnteHandler) + + // Match determines if a transaction belongs to this lane. + Match(ctx sdk.Context, tx sdk.Tx) bool + + // GetTxInfo returns various information about the transaction that + // belongs to the lane including its priority, signer's, sequence number, + // size and more. + GetTxInfo(ctx sdk.Context, tx sdk.Tx) (utils.TxWithInfo, error) +} +``` + +## Lane Priorities + +Each lane has a priority that is used to determine the order in which lanes are processed. The higher the priority, the earlier the lane is processed. For example, if we have three lanes - MEV, free, and default - proposals will be constructed in the following order: + +1. MEV +2. Free +3. Default + +Proposals will then be verified in the same order. Please see the [readme above](../abci/README.md) for more information on how proposals are constructed using lanes. + +The ordering of lane's priorities is determined based on the order passed into the constructor of the Block SDK mempool i.e. `LanedMempool`. + +## Block SDK mempool + +The `LanedMempool` is a wrapper on top of the collection of lanes. It is solely responsible for adding transactions to the appropriate lanes. Transactions are always inserted / removed to the first lane that accepts / matches the transactions. **Transactions should only match to one lane.**. **In the case where a transaction can match to multiple lanes, the transaction will be inserted into the lane that has the highest priority.** + +To read more about the underlying implementation of the Block SDK mempool, please see the implementation [here](./mempool.go). diff --git a/block/base/README.md b/block/base/README.md new file mode 100644 index 00000000..9dd2a4d9 --- /dev/null +++ b/block/base/README.md @@ -0,0 +1,145 @@ +# Base Lane + +## Overview + +> The base lane is purposefully built to be a simple lane that can be extended (inherited) by other lanes. It provides the basic functionality that is required by all lanes with the option to override any of the methods. + +The base lane implements the lane interface and provides a few critical methods that allow application developers to create a lane that has custom transaction ordering and execution logic. The most important things you need to know in order to build a custom lane are: + +* `MatchHandler`: This method is responsible for determining if a given transaction should be accepted by the lane. +* `PrepareLaneHandler`: This method is responsible for reaping transactions from the mempool, validating them, re-ordering (if necessary), and returning them to be included in a block proposal. +* `ProcessLaneHandler`: This method is responsible verifying the matched transactions that were included in a block proposal. +* `LaneMempool`: This allows developers to have the freedom to implement their own mempools with custom transaction ordering logic. +* `LaneConfig`: This allows developers to customize how the lane behaves in terms of max block space, max transaction count, and more. + +## MatchHandler + +MatchHandler is utilized to determine if a transaction should be included in the lane. This function can be a stateless or stateful check on the transaction. The function signature is as follows: + +```go +MatchHandler func(ctx sdk.Context, tx sdk.Tx) bool +``` + +To create a custom lane with a custom `MatchHandler`, you must implement this function and pass it into the constructor for the base lane. For example, the [free lane](../../lanes/free/lane.go) inherits all the base lane functionality but overrides the `MatchHandler` to only accept staking related transactions. + +```go +// DefaultMatchHandler returns the default match handler for the free lane. The +// default implementation matches transactions that are staking related. In particular, +// any transaction that is a MsgDelegate, MsgBeginRedelegate, or MsgCancelUnbondingDelegation. +func DefaultMatchHandler() base.MatchHandler { + return func(ctx sdk.Context, tx sdk.Tx) bool { + for _, msg := range tx.GetMsgs() { + switch msg.(type) { + case *types.MsgDelegate: + return true + case *types.MsgBeginRedelegate: + return true + case *types.MsgCancelUnbondingDelegation: + return true + } + } + + return false + } +} +``` + +The default `MatchHandler` is implemented in the [base lane](./handlers.go) and matches all transactions. + +## PrepareLaneHandler + +The `PrepareLaneHandler` is responsible for reaping transactions from the mempool, validating them, re-ordering (if necessary), and returning them to be included in a block proposal. If any of the transactions were invalid, it should return them alongside the transactions it wants to include in the proposal. The invalid transactions will subsequently be removed from the lane's mempool. The function signature is as follows: + +```go +PrepareLaneHandler func( + ctx sdk.Context, + proposal proposals.Proposal, + limit proposals.LaneLimits, +) (txsToInclude []sdk.Tx, txsToRemove []sdk.Tx, err error) +``` + +To create a custom lane with a custom `PrepareLaneHandler`, you must implement this function and set it on the lane after it has been created. Please visit the [MEV lane's](../../lanes/mev/abci.go) `PrepareLaneHandler` for an example of how to implement this function. + +The default `PrepareLaneHandler` is implemented in the [base lane](./handlers.go). It reaps transactions from the mempool, validates them, ensures that the lane's block space limit is not exceeded, and returns the transactions to be included in the block and the ones that need to be removed. + +## ProcessLaneHandler + +The `ProcessLaneHandler` is responsible for verifying the transactions that belong to a given lane that were included in a block proposal and returning those that did not to the next lane. The function signature is as follows: + +```go +ProcessLaneHandler func(ctx sdk.Context, partialProposal []sdk.Tx) ( + txsFromLane []sdk.Tx, + remainingTxs []sdk.Tx, + err error, +) +``` + +Note that block proposals built using the Block SDK contain contiguous sections of transactions in the block that belong to a given lane, to read more about how proposals are constructed relative to other lanes, please visit the [abci section](../../abci/README.md). As such, a given lane will recieve some transactions in (partialProposal) that belong to it and some that do not. The transactions that belong to it must be contiguous from the start, and the transactions that do not belong to it must be contiguous from the end. The lane must return the transactions that belong to it and the transactions that do not belong to it. The transactions that do not belong to it will be passed to the next lane in the proposal. The default `ProcessLaneHandler` is implemented in the [base lane](./handlers.go). It verifies the transactions that belong to the lane and returns them alongside the transactions that do not belong to the lane. + +Please visit the [MEV lane's](../../lanes/mev/abci.go) `ProcessLaneHandler` for an example of how to implement a custom handler. + +## LaneMempool + +The lane mempool is the data structure that is responsible for storing transactions that belong to a given lane, before they are included in a block proposal. The lane mempool input's a `TxPriority` object that allows developers to customize how they want to order transactions within their mempool. Additionally, it also accepts a signer extrator adapter that allows for custom signature schemes to be used (although the default covers Cosmos SDK transactions). To read more about the signer extractor adapter, please visit the [signer extractor section](../../adapters/signer_extraction_adapter/README.md). + +### TxPriority + +The `TxPriority` object is responsible for ordering transactions within the mempool. The definition of the `TxPriority` object is as follows: + +```go +// TxPriority defines a type that is used to retrieve and compare transaction +// priorities. Priorities must be comparable. +TxPriority[C comparable] struct { + // GetTxPriority returns the priority of the transaction. A priority must be + // comparable via Compare. + GetTxPriority func(ctx context.Context, tx sdk.Tx) C + + // CompareTxPriority compares two transaction priorities. The result should be + // 0 if a == b, -1 if a < b, and +1 if a > b. + Compare func(a, b C) int + + // MinValue defines the minimum priority value, e.g. MinInt64. This value is + // used when instantiating a new iterator and comparing weights. + MinValue C +} +``` + +The default implementation can be found in the [base lane](./mempool.go). It orders transactions by their gas price in descending order. The `TxPriority` object is passed into the lane mempool constructor. Please visit the [MEV lane's](../../lanes/mev/mempool.go) `TxPriority` for an example of how to implement a custom `TxPriority`. + +## LaneConfig + +The lane config is the object that is responsible for configuring the lane. It allows developers to customize how the lane behaves in terms of max block space, max transaction count, and more. The definition of the `LaneConfig` object is as follows: + +```go +// LaneConfig defines the basic configurations needed for a lane. +type LaneConfig struct { + Logger log.Logger + TxEncoder sdk.TxEncoder + TxDecoder sdk.TxDecoder + AnteHandler sdk.AnteHandler + + // SignerExtractor defines the interface used for extracting the expected signers of a transaction + // from the transaction. + SignerExtractor signer_extraction.Adapter + + // MaxBlockSpace defines the relative percentage of block space that can be + // used by this lane. NOTE: If this is set to zero, then there is no limit + // on the number of transactions that can be included in the block for this + // lane (up to maxTxBytes as provided by the request). This is useful for the default lane. + MaxBlockSpace math.LegacyDec + + // MaxTxs sets the maximum number of transactions allowed in the mempool with + // the semantics: + // - if MaxTx == 0, there is no cap on the number of transactions in the mempool + // - if MaxTx > 0, the mempool will cap the number of transactions it stores, + // and will prioritize transactions by their priority and sender-nonce + // (sequence number) when evicting transactions. + // - if MaxTx < 0, `Insert` is a no-op. + MaxTxs int +} +``` + +Each lane must define its own custom `LaneConfig` in order to be properly instantiated. Please visit [`app.go`](../../tests/app/app.go) for an example of how to implement a custom `LaneConfig`. + + + diff --git a/block/proposals/README.md b/block/proposals/README.md new file mode 100644 index 00000000..33962677 --- /dev/null +++ b/block/proposals/README.md @@ -0,0 +1,21 @@ +# Proposals + +## Overview + +> The proposal type - `proposals.Proposal` - is utilized to represent a block proposal. It contains information about the total gas utilization, block size, number of transactions, raw transactions, and much more. It is recommended that you read the [proposal construction and verification](../../abci/README.md) section before continuing. + +## Proposal + +After a given lane executes its `PrepareLaneHandler` or `ProcessLaneHandler`, it will return a set of transactions that need to be added to the current proposal that is being constructed. To update the proposal, `Update` is called with the lane that needs to add transactions to the proposal as well as the transactions that need to be added. + +Proposals are updated _iff_: + +1. The total gas utilization of the partial proposal (i.e. the transactions it wants to add) are under the limits allocated for the lane and are less than the maximum gas utilization of the proposal. +2. The total size in bytes of the partial proposal is under the limits allocated for the lane and is less than the maximum size of the proposal. +3. The transactions have not already been added to the proposal. +4. The lane has not already attempted to add transactions to the proposal. + +If any of these conditions fail, the proposal will not be updated and the transactions will not be added to the proposal. The lane will be marked as having attempted to add transactions to the proposal. + +The proposal is responsible for determining the `LaneLimits` for a given lane. The `LaneLimits` are the maximum gas utilization and size in bytes that a given lane can utilize in a block proposal. This is a function of the max gas utilization and size defined by the application, the current gas utilization and size of the proposal, and the `MaxBlockSpace` allocated to the lane as defined by its `LaneConfig`. To read more about how `LaneConfigs` are defined, please visit the [lane config section](../base/README.md#laneconfig) or see an example implementation in [`app.go`](../../tests/app/app.go). +