docs: add a section about Censorship Timeout #1945
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Converting this to |
GreatSoshiant
approved these changes
Dec 30, 2024
| @@ -259,3 +260,28 @@ Developers and users should consider the appropriate level of finality based on | |||
| ### Decentralized Fair Sequencing | |||
|
|
|||
| Arbitrum’s long-term vision includes transitioning from a centralized Sequencer to a decentralized, fair sequencing model. In this framework, a committee of servers (or validators) collectively determines transaction ordering, ensuring fairness, reducing the influence of any single party, and making it more resistant to manipulation. By requiring a supermajority consensus, this approach distributes sequencing power among multiple honest participants, mitigates the risks of front-running or censorship, and aligns with the broader blockchain principles of enhanced security, transparency, and decentralization. | |||
|
|
|||
| ## Censorship Timeout | |||
There was a problem hiding this comment.
I think it makes sense to move this section on top of ### Decentralized Fair Sequencing section.
anegg0
reviewed
Dec 31, 2024
|
|
||
| ### How the Censorship Timeout feature works | ||
|
|
||
| To explain how this feature improves the security of chains settling to Arbitrum One and Arbitrum Nova, consider the scenario where an L3’s parent chain sequencer (the L2 sequencer) is censoring or offline. In such a case, every assertion and/or sub-challenge move would need to wait 24 hours before they could bypass the L2 sequencer (using the SequencerInbox’s forceInclusion method described here). In this scenario, challenge resolution would be delayed by a time `t` where `t = (24 hours) * number of moves for a challenge`. To illustrate with sample numbers, if a challenge takes 50 sequential moves to resolve, then the delay would be 50 days. |
There was a problem hiding this comment.
Suggested change
| To explain how this feature improves the security of chains settling to Arbitrum One and Arbitrum Nova, consider the scenario where an L3’s parent chain sequencer (the L2 sequencer) is censoring or offline. In such a case, every assertion and/or sub-challenge move would need to wait 24 hours before they could bypass the L2 sequencer (using the SequencerInbox’s forceInclusion method described here). In this scenario, challenge resolution would be delayed by a time `t` where `t = (24 hours) * number of moves for a challenge`. To illustrate with sample numbers, if a challenge takes 50 sequential moves to resolve, then the delay would be 50 days. | |
| To explain how this feature improves the security of chains settling to Arbitrum One and Arbitrum Nova, consider the scenario where an L3’s parent chain sequencer (the L2 sequencer) is censoring or offline. In such a case, every assertion and/or sub-challenge move would need to wait 24 hours before bypassing the L2 sequencer (using the SequencerInbox’s forceInclusion method described here). In this scenario, challenge resolution would be delayed by a time `t` where `t = (24 hours) * number of moves for a challenge`. To illustrate with sample numbers, if a challenge takes 50 sequential moves to resolve, then the delay would be 50 days. |
anegg0
reviewed
Dec 31, 2024
|
|
||
| To explain how this feature improves the security of chains settling to Arbitrum One and Arbitrum Nova, consider the scenario where an L3’s parent chain sequencer (the L2 sequencer) is censoring or offline. In such a case, every assertion and/or sub-challenge move would need to wait 24 hours before they could bypass the L2 sequencer (using the SequencerInbox’s forceInclusion method described here). In this scenario, challenge resolution would be delayed by a time `t` where `t = (24 hours) * number of moves for a challenge`. To illustrate with sample numbers, if a challenge takes 50 sequential moves to resolve, then the delay would be 50 days. | ||
|
|
||
| The Censorship Timeout feature mitigates this by implementing a time threshold that is decremented when unexpected delays in assertion posting occur due to one (or all) of the above mentioned cases of censorship or sequencer outage. Once that time threshold is met, the force inclusion window is lowered - effectively enabling entities to make moves without the 24 hour delay-per-move. |
There was a problem hiding this comment.
Suggested change
| The Censorship Timeout feature mitigates this by implementing a time threshold that is decremented when unexpected delays in assertion posting occur due to one (or all) of the above mentioned cases of censorship or sequencer outage. Once that time threshold is met, the force inclusion window is lowered - effectively enabling entities to make moves without the 24 hour delay-per-move. | |
| The Censorship Timeout feature mitigates this by implementing a time threshold that is decremented when unexpected delays in assertion posting occur due to one (or all) of the above-mentioned cases of censorship or sequencer outage. Once that time threshold is met, the force inclusion window is lowered, enabling entities to make moves without the 24-hour delay-per-move. |
anegg0
reviewed
Dec 31, 2024
Comment on lines
+283
to
+287
| - `delay buffer` = 14400 L1 Ethereum blocks (2 days) | ||
| - `threshold` = 150 L1 Ethereum blocks (30 minutes) for Arbitrum One and 300 L1 Ethereum blocks (1 hour) for Arbitrum Nova | ||
| - `replenish rate` = 5% (meaning 1 day is replenished every 20 days, or roughly a 95% uptime) | ||
|
|
||
| We believe that the Censorship Timeout feature provides stronger guarantees of censorship resistance for Arbitrum chains - especially those that settle to Arbitrum One or Arbitrum Nova. As always, chain owners can decide whether to utilize this feature for their chain and can also change the default parameters as they see fit for their use case. |
There was a problem hiding this comment.
Suggested change
| - `delay buffer` = 14400 L1 Ethereum blocks (2 days) | |
| - `threshold` = 150 L1 Ethereum blocks (30 minutes) for Arbitrum One and 300 L1 Ethereum blocks (1 hour) for Arbitrum Nova | |
| - `replenish rate` = 5% (meaning 1 day is replenished every 20 days, or roughly a 95% uptime) | |
| We believe that the Censorship Timeout feature provides stronger guarantees of censorship resistance for Arbitrum chains - especially those that settle to Arbitrum One or Arbitrum Nova. As always, chain owners can decide whether to utilize this feature for their chain and can also change the default parameters as they see fit for their use case. | |
| - `delay buffer` = 14400 L1 Ethereum blocks (2 days) | |
| - `threshold` = 150 L1 Ethereum blocks (30 minutes) for Arbitrum One and 300 L1 Ethereum blocks (1 hour) for Arbitrum Nova | |
| - `replenish rate` = 5% (meaning 1 day is replenished every 20 days or roughly a 95% uptime) | |
| We believe that the Censorship Timeout feature provides stronger guarantees of censorship resistance for Arbitrum chains - especially those that settle to Arbitrum One or Arbitrum Nova. As always, chain owners can decide whether to utilize this feature for their chain and can also change the default parameters as they see fit for their use case. |
anegg0
approved these changes
Dec 31, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this pull request adds a short explanation about censorship timeout into section about how the arbitrum sequencer works