-
Notifications
You must be signed in to change notification settings - Fork 48
Updates: Fraud Proof System Docs #300
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
Merged
Merged
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,36 @@ | ||
| # Bonds | ||
|
|
||
| :::warning Work in progress | ||
| Bonds mechanism is not yet implemented in the Cartesi's fraud proof system. To get the latest updates, get in touch with the core contributors on Cartesi [Discord](https://discord.gg/cartesi). | ||
| ::: | ||
| ## What is a bond mechanism? | ||
|
|
||
| A bond mechanism in the fraud-proof system is an economic security system that requires participants to post collateral when posting claims in the dispute resolution process. | ||
|
|
||
| The goal is to introduce a modest economic cost to submitting claims, thereby mitigating the impact of Sybil attacks. Bonds provide a means to finance and subsequently reimburse dispute-related expenses, ensuring that honest participants are not financially penalized for engaging in validation. | ||
riseandshaheen marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| The mechanism is not intended to create participation incentives, rather, its design objective is to keep honest, altruistic validation as close to costless as possible, irrespective of the number or behavior of Sybil identities. | ||
|
|
||
| ## Why do we need bonds? A Case without Bonds | ||
| In a dispute process, each transaction made on Ethereum would incur gas costs for the proposer and the challenger. This cost does not include the bond amount. In this setup, a malicious proposer who can spend a relatively large amount of gas fees has an advantage to repeatedly post claims until the honest challenger exhausts their funds or computational resources. | ||
|
|
||
| This is infamously known as the resource exhaustion attack or [proof-of-whale attack](https://ethresear.ch/t/fraud-proofs-are-broken/19234). It is a type of Sybil attack. To deter such an attack, we introduce a bond system in the fraud-proof system. | ||
riseandshaheen marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| Naively introducing a high bond amount will impact decentralisation. Liveness and security may depend on preventing the adversary from creating too many Sybils. Increasing bonds in such a scenario harms decentralization by restricting the number of players that can afford to participate. | ||
|
|
||
| ## Implementation in PRT v2 | ||
| Cartesi’s _Permissionless Refereed Tournament (PRT) v2_ features a bond system. Each tournament level requires a bond to be posted in order for a commitment to be submitted. | ||
|
|
||
| A defender gets the gas fees as a refund with an optional incentive to be an active defender of the system. In a single dispute process(a tournament system), the fraud-proof design asks participants to stake a bond at each level of the game. | ||
riseandshaheen marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| In the worst-case scenario, an honest validator will have one bond for each tournament level. Currently, PRT v2 features three levels: top, middle, and bottom, which correspond to three bonds. Bond values differ at each level. | ||
|
|
||
riseandshaheen marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| When joining a tournament, participants must send the bond value in Wei. The contract enforces this requirement and reverts with an InsufficientBond error if the payment is insufficient. | ||
riseandshaheen marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| The **refund calculation** is capped by three values: the contract balance, a weighted fraction of the bond value, and the actual gas used plus a profit margin. The profit margin incentivizes honest participants to perform necessary operations. | ||
|
|
||
| The winning commitment's submitter receives all bonds after tournament completion, recovering their costs plus rewards from eliminated participants. | ||
riseandshaheen marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| However, in practice, issuing refunds introduces an additional challenge. During dispute actions such as bisect and step, multiple honest validators may attempt the same operation simultaneously. Only the first transaction succeeds, while the rest revert, creating a race condition that leads to unnecessary gas losses and complicates proper refunds. | ||
riseandshaheen marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| To address this, PRT uses a targeted technique based on **MEV-Share’s** `mev_sendBundle` RPC. Although MEV-Share is a general MEV redistribution protocol, we rely on it only for its ability to relay transactions predictably through searcher relays. By submitting dispute actions via `mev_sendBundle`, validators avoid public mempool races and ensure that the intended action is included without incurring failed-transaction costs. | ||
riseandshaheen marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| This approach preserves the goal of making honest validation effectively costless, even when many validators attempt the same operation. | ||
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
Oops, something went wrong.
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.
Uh oh!
There was an error while loading. Please reload this page.