-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(ABCI): New Proposal Struct with Associated Metadata #126
Conversation
block/proposals/update.go
Outdated
return fmt.Errorf("err retriveing transaction info: %s", err) | ||
} | ||
|
||
// Invarient check: Ensure that the transaction is not already in the proposal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Invariant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shii, i cant spell
block/proposals/update.go
Outdated
for index, tx := range partialProposal { | ||
txInfo, err := utils.GetTxInfo(p.TxEncoder, tx) | ||
if err != nil { | ||
return fmt.Errorf("err retriveing transaction info: %s", err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
retrieve
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ong i cant spell
block/proposals/update.go
Outdated
} | ||
|
||
// Invarient check: Ensure we have not already prepared a partial proposal for this lane. | ||
if _, ok := p.Info.TxsByLane[lane]; ok { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: would make this check the first check (avoids redundant work)
block/proposals/update.go
Outdated
// the lane. | ||
// 5. The lane must not have already prepared a partial proposal. | ||
// 6. The transaction must not already be in the proposal. | ||
func (p *Proposal) UpdateProposal(lane string, partialProposal []sdk.Tx, limit LaneLimits) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would the caller pass in their LaneLimits? Why wouldn't the proposal j get them here from the lane-string? I.e if the purpose of this abstraction is to have devs only aware of adding txs to proposals, does it not make more sense to j hide the notion of a LaneLimit
entirely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea i agree, will update
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
* new proto types for proposal info * new proposal type * nits * lane input * lint * feat(ABCI): Deprecating `CheckOrderHandler` with new Proposal MetaData (#127) * refactor without checkorder * nits * more nits * lint * nits * feat(ABCI): Updating MEV lane to have no `CheckOrder` handler + testing (#128) * updating mev lane * nits * preventing adding multiple bid txs in prepare * update (cherry picked from commit b9d6761) # Conflicts: # abci/abci.go # abci/abci_test.go # block/base/handlers.go # block/base/types.go # block/proposals.go # block/utils/utils_test.go # lanes/mev/abci.go # tests/app/ante.go # tests/app/app.go # tests/integration/block_sdk_suite.go
* new proto types for proposal info * new proposal type * nits * lane input * lint * feat(ABCI): Deprecating `CheckOrderHandler` with new Proposal MetaData (#127) * refactor without checkorder * nits * more nits * lint * nits * feat(ABCI): Updating MEV lane to have no `CheckOrder` handler + testing (#128) * updating mev lane * nits * preventing adding multiple bid txs in prepare * update (cherry picked from commit b9d6761)
* new proto types for proposal info * new proposal type * nits * lane input * lint * feat(ABCI): Deprecating `CheckOrderHandler` with new Proposal MetaData (#127) * refactor without checkorder * nits * more nits * lint * nits * feat(ABCI): Updating MEV lane to have no `CheckOrder` handler + testing (#128) * updating mev lane * nits * preventing adding multiple bid txs in prepare * update (cherry picked from commit b9d6761) Co-authored-by: David Terpay <[email protected]>
…) (#132) * feat(ABCI): New Proposal Struct with Associated Metadata (#126) * new proto types for proposal info * new proposal type * nits * lane input * lint * feat(ABCI): Deprecating `CheckOrderHandler` with new Proposal MetaData (#127) * refactor without checkorder * nits * more nits * lint * nits * feat(ABCI): Updating MEV lane to have no `CheckOrder` handler + testing (#128) * updating mev lane * nits * preventing adding multiple bid txs in prepare * update (cherry picked from commit b9d6761) # Conflicts: # abci/abci.go # abci/abci_test.go # block/base/handlers.go # block/base/types.go # block/proposals.go # block/utils/utils_test.go # lanes/mev/abci.go # tests/app/ante.go # tests/app/app.go # tests/integration/block_sdk_suite.go * fix * nit * docs nit * height nit --------- Co-authored-by: David Terpay <[email protected]> Co-authored-by: David Terpay <[email protected]>
Overview
This PR creates a new proposal type that replace the current proposal building object. The premise here is the following:
By attaching metadata to the proposal about how many transactions were included by each lane, we can deprecate the
CheckOrderHandler
and solely have a singleProcessLane
handler. Given a constructed proposal with meta data attached to it - lane x has 1 txs, lane y has 2 txs, etc. - we no longer have to do any introspection into what transactions belong to what lane. Definitively, we can take the proposal and break it up into its corresponding partial proposals - the proposals each lane built - and have stronger guarantees about the properties of the proposed block.Additionally, this will both decrease the complexity of the code base and will allow us to subsequently do more nuanced things when building/verifying proposals. For example, this can include