-
Notifications
You must be signed in to change notification settings - Fork 11.3k
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
[consensus handler] reorder txns by gas price #12266
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@@ -465,6 +466,10 @@ pub struct ProtocolConfig { | |||
/// 3f+1 must vote), while 0bps would indicate that 2f+1 is sufficient. | |||
buffer_stake_for_protocol_upgrade_bps: Option<u64>, | |||
|
|||
/// What version of reordering algorithm we are using for user transactions included in a Narwhal | |||
/// commit in consensus handler. | |||
consensus_user_transaction_reordering_version: Option<u64>, |
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.
I thought this is similar to gas model in the sense that we will probably iterate a few times so I added it as a version number instead of feature flag.
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.
we could still use a feature flag, but make it an enum instead of a bool - i think that will help readability, since the enum variants can be descriptive.
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.
Good idea.
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.
PR looks good. Is there a discussion thread on ordering transactions by gas price?
@@ -357,6 +370,22 @@ impl<T: ParentSync + Send + Sync> ExecutionState for ConsensusHandler<T> { | |||
} | |||
} | |||
|
|||
fn reorder_by_gas_price(sequenced_transactions: &mut [VerifiedSequencedConsensusTransaction]) { |
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.
optional: maybe just order_by_gas_price
?
.protocol_config() | ||
.consensus_user_transaction_reordering_version_as_option() | ||
{ | ||
reorder_by_gas_price(&mut sequenced_transactions[1..]); |
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: Can we add a monitored_scope here?
@@ -465,6 +466,10 @@ pub struct ProtocolConfig { | |||
/// 3f+1 must vote), while 0bps would indicate that 2f+1 is sufficient. | |||
buffer_stake_for_protocol_upgrade_bps: Option<u64>, | |||
|
|||
/// What version of reordering algorithm we are using for user transactions included in a Narwhal | |||
/// commit in consensus handler. | |||
consensus_user_transaction_reordering_version: Option<u64>, |
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.
we could still use a feature flag, but make it an enum instead of a bool - i think that will help readability, since the enum variants can be descriptive.
tracking_id: _, | ||
kind: ConsensusTransactionKind::UserTransaction(cert), | ||
}) => cert.gas_price(), | ||
// Non-user transactions are considered to have gas price of zero and are put to the end. |
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.
i believe this sorts ConsensusCommitPrologue txns to the end, which is definitely not what we want.
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.
On line 306, where this function is called, we are sorting only the second transactions onwards so the first txn in the vector which is consensus commit prologue txn should not be affected.
ConsensusTransactionOrdering::ByGasPrice | ||
) { | ||
let _scope = monitored_scope("HandleConsensusOutput::order_by_gas_price"); | ||
order_by_gas_price(&mut sequenced_transactions); |
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.
What is the typical and max size of sequenced_transactions?
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.
The size of sequenced_transactions
is the number of Sui transactions in a Narwhal commit + 1 (prologue). In 100 node deployments, Narwhal commits happen every 1~2s. Actual size of sequenced_transactions
is correlated with TPS. The size limit is much larger based on Narwhal limits.
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.
If we are concerned about added latency due to this additional step, I can run an experiment in private testnet with high TPS and observe what the monitored scope metrics show us.
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.
I don't think we're going to have any problems caused by sorting - consensus handler is dominated by db reads and writes. Anything that is purely in memory like this should not cause problems
b9a0201
to
39c5526
Compare
d408bb6
to
aaee5b9
Compare
## Description This PR adds a step in consensus handler to reorder transactions in a Narwhal commit by their gas prices. Right now the reordering is purely based on gas price, which will be later changed to be based on object hotness, etc, as well. ## Test Plan Added a test. --- If your changes are not user-facing and not a breaking change, you can skip the following section. Otherwise, please indicate what changed, and then add to the Release Notes section as highlighted during the release process. ### Type of Change (Check all that apply) - [ ] protocol change - [x] user-visible impact - [ ] breaking change for a client SDKs - [ ] breaking change for FNs (FN binary must upgrade) - [x] breaking change for validators or node operators (must upgrade binaries) - [ ] breaking change for on-chain data layout - [ ] necessitate either a data wipe or data migration ### Release notes Previously transactions in a Narwhal commit were ordered as the sub-dag is flattened in a depth-first traversal. Now we have added a round of ordering that orders the user transactions in the same commit by gas price, where a transaction with higher gas price will be added for execution in the transaction manager first.
Description
This PR adds a step in consensus handler to reorder transactions in a Narwhal commit by their gas prices. Right now the reordering is purely based on gas price, which will be later changed to be based on object hotness, etc, as well.
Test Plan
Added a test.
If your changes are not user-facing and not a breaking change, you can skip the following section. Otherwise, please indicate what changed, and then add to the Release Notes section as highlighted during the release process.
Type of Change (Check all that apply)
Release notes
Previously transactions in a Narwhal commit were ordered as the sub-dag is flattened in a depth-first traversal. Now we have added a round of ordering that orders the user transactions in the same commit by gas price, where a transaction with higher gas price will be added for execution in the transaction manager first.