-
Notifications
You must be signed in to change notification settings - Fork 629
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(congestion): reject new transactions on RPC level #11419
Changes from all commits
d1ea36f
f161e54
6891891
5b25b6c
f1b492d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -643,9 +643,25 @@ impl RuntimeAdapter for NightshadeRuntime { | |
verify_signature: bool, | ||
epoch_id: &EpochId, | ||
current_protocol_version: ProtocolVersion, | ||
receiver_congestion_info: Option<ExtendedCongestionInfo>, | ||
) -> Result<Option<InvalidTxError>, Error> { | ||
let runtime_config = self.runtime_config_store.get_config(current_protocol_version); | ||
|
||
if let Some(congestion_info) = receiver_congestion_info { | ||
let congestion_control = CongestionControl::new( | ||
runtime_config.congestion_control_config, | ||
congestion_info.congestion_info, | ||
congestion_info.missed_chunks_count, | ||
); | ||
if !congestion_control.shard_accepts_transactions() { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You may consider making that more flexible by making the threshold a configurable value rather than using the runtime parameter of 0.25. The drawback is that those would need to be kept somewhat in sync. I also dislike that some rpc node may artificially lower it in order to get their users priority but this is something they can do anyway. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good point. We can consider adding the flexibility. But just to be clear, there should not much to be gained by setting a higher threshold. Unless the congestion level lowers between now and when the chunk producer considers it, it will be rejected and dropped anyway. Most of the time, the RPC will just end up waiting for a timeout before it inevitably fails, annoying the user and wasting resources on the RPC in the process. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For some users the UX doesn't matter as much as just maximizing the chances of getting their transaction in. For those it may be useful. It may also be useful for us if we discover that we did the math wrong and need to change it quickly :) |
||
let receiver_shard = | ||
self.account_id_to_shard_uid(transaction.transaction.receiver_id(), epoch_id)?; | ||
return Ok(Some(InvalidTxError::ShardCongested { | ||
shard_id: receiver_shard.shard_id, | ||
})); | ||
} | ||
} | ||
|
||
if let Some(state_root) = state_root { | ||
let shard_uid = | ||
self.account_id_to_shard_uid(transaction.transaction.signer_id(), epoch_id)?; | ||
|
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.
How about the congestion info of the sender? If the sender is congested their tx limit will be lowered and some transactions may also be rejected because of that.
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 reject them. We just lower the gas limit. When we reach the gas limit, we keep following transactions in the pool rather than rejecting (dropping) them. Eventually, new transactions are dropped but that's because the pool is full, not due to something we added in nep-539.
We could still try to be smart about it, like reject something on the RPC if we think the pool is filling up with transactions all using the same sender shard. But it seems a bit tricky to get the heuristics right. If we are too aggressive, we risk frustrating users by rejecting their transactions for no good reason. Not to mention that "rogue RPCs" could abuse the system by filling the transaction pool beyond what our RPCs do, which would starve the honest RPCs completely under congestion.
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.
Sounds good, we can observe what happens in the wild and make adjustments if we find it necessary.