You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: cartesi-rollups_versioned_docs/version-1.5/development/asset-handling.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -53,7 +53,7 @@ The dApp’s off-chain layer often requires knowledge of its address to facilita
53
53
By calling [`relayDAppAddress()`](../rollups-apis/json-rpc/relays/relays.md), function of the `DAppAddressRelay` contract, it adds the dApp’s address as a new input for the Cartesi dApp to process. Next, the off-chain machine uses this address to generate a voucher for execution at the [`executeVoucher()`](../rollups-apis/json-rpc/application.md/#executevoucher) function of the `CartesiDApp` contract.
54
54
55
55
:::note epoch length
56
-
By default, Cartesi nodes close one epoch every 7200 blocks. You can [manually set the epoch length](./cli-commands.md/#run) to facilitate quicker asset-handling methods.
56
+
By default, Cartesi nodes close one epoch every 7200 blocks. You can [manually set the epoch length](/get-started/cli-commands/#run) to facilitate quicker asset-handling methods.
57
57
:::
58
58
59
59
Here are the function signatures used by vouchers to withdraw the different types of assets:
**NOTE::** For python developers, add the below snippet to `line 26` of your Dockerfile. It should come immediately after the line `COPY ./requirements.txt .`.
160
-
161
-
This command would help install essential compilers to help compile some dependencies we'll be using.
159
+
:::caution Note for Python Developers
160
+
Add the below snippet to `line 26` of your Dockerfile. It should come immediately after the line `COPY ./requirements.txt .`
161
+
This command would install essential meta-packages to help compile some dependencies we'll be using.
162
+
:::
162
163
163
164
```Dockerfile
164
165
# Install build dependencies for compiling native extensions
By default, Cartesi nodes close one epoch every 7200 blocks. You can [manually set the epoch length](./cli-commands.md/#run) to facilitate quicker asset-handling methods.
146
+
By default, Cartesi nodes close one epoch every 7200 blocks. You can manually set the epoch length to facilitate quicker asset-handling methods.
147
147
:::
148
148
149
149
Here are the function signatures used by vouchers to withdraw the different types of assets:
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).
5
-
:::
3
+
## What is a bond mechanism?
6
4
5
+
A bond mechanism in the fraud-proof system is an economic security system that requires any participant to post a collateral when submitting a claim in the dispute-resolution process.
6
+
7
+
The goal is to introduce a modest economic cost to submitting claims, thereby mitigating the impact of Sybil attacks. Bonds provide a means to reimburse dispute-related expenses, ensuring that honest participants are not financially penalized for engaging in validation.
8
+
9
+
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.
10
+
11
+
## Why do we need bonds? A Case without Bonds
12
+
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.
13
+
14
+
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.
15
+
16
+
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.
17
+
18
+
## Implementation in PRT v2
19
+
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.
20
+
21
+
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.
22
+
23
+
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.
24
+
25
+
When joining a tournament, participants must send the bond value in Ether. The contract enforces this requirement and reverts with an `InsufficientBond` error if the payment is insufficient.
26
+
27
+
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.
28
+
29
+
The submitter of the winning commitment receives any remaining bonds after tournament completion, recovering their costs plus rewards from eliminated participants.
30
+
31
+
However, in practice, issuing refunds introduces an additional challenge. During dispute actions such as bisections and steps, multiple honest validators may attempt the same operation simultaneously. Only the first transaction succeeds, while any following ones revert, creating a race condition that leads to unnecessary gas losses and complicates proper refunds.
32
+
33
+
To address this, PRT can leverage 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.
34
+
35
+
This approach preserves the goal of making honest validation effectively costless, even when many validators attempt the same operation.
Copy file name to clipboardExpand all lines: fraud-proofs/honeypot/introduction.md
-4Lines changed: 0 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,5 @@
1
1
# Introduction
2
2
3
-
:::caution
4
-
Honeypot app is being updated. We recently found a bug in the application that has led to a fail-stop state. This means the current deployment is permanently frozen, and the bounty funds within it are no longer recoverable. Get in touch with us on [Discord](https://discord.gg/cWGbyFkQ2W) for more details.
5
-
:::
6
-
7
3
This section focuses on the Cartesi application - the Honeypot - its introduction, application logic and how it demonstrates the PRT fraud-proof system's capabilities in a real-world scenario.
Copy file name to clipboardExpand all lines: fraud-proofs/references/daveconsensus.md
+73-35Lines changed: 73 additions & 35 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,6 +3,17 @@
3
3
## DaveConsensus Contract
4
4
---
5
5
6
+
DaveConsensus (also referred to as PRT-Rollups Consensus) is the consensus contract for applications that use Dave-style tournaments (such as PRT) for verification.
7
+
This contract is responsible for validating a single application, whose inputs must originate from a pre-configured InputBox contract.
8
+
9
+
DaveConsensus manages epochs, which are defined as half-open block-number intervals of the form [a, b).
10
+
Epochs are numbered sequentially starting from 0.
11
+
12
+
Off-chain nodes can track progress by subscribing to the _EpochSealed_ event. This event indicates which epochs have been sealed, which ones are fully settled, and which epoch is currently open for challenges.
13
+
Anyone may settle an epoch by calling _settle()_, and an epoch’s eligibility for settlement can be checked via _canSettle()_. Learn more about epochs [here](../../../fraud-proofs/fraud-proof-basics/epochs).
14
+
15
+
This contract links input ingestion, epoch progression, and Dave tournament-based verification under a single consensus interface.
16
+
6
17
### `canSettle()`
7
18
8
19
```solidity
@@ -15,25 +26,25 @@ Check if the current epoch can be settled by querying the tournament's arbitrati
15
26
16
27
| Name | Type | Description |
17
28
|------|------|-------------|
18
-
|`isFinished`|`bool`| Whether tournament is finished |
19
-
|`epochNumber`|`uint256`| Current epoch number |
20
-
|`winnerCommitment`|`Tree.Node`| Winner's commitment from tournament |
29
+
|`isFinished`|`bool`| Whether the current sealed epoch tournament has finished |
30
+
|`epochNumber`|`uint256`| Current sealed epoch number |
31
+
|`winnerCommitment`|`Tree.Node`| Winner's commitment in case the tournament has finished|
21
32
22
33
### `settle()`
23
34
24
35
```solidity
25
36
function settle(uint256 epochNumber, bytes32 outputsMerkleRoot, bytes32[] calldata proof) external
26
37
```
27
38
28
-
Settle an epoch using tournament results and create a new tournament for the next epoch.
39
+
Settle the current sealed epoch. On success, it emits an [`EpochSealed`](#epochsealed) event.
29
40
30
41
**Parameters:**
31
42
32
43
| Name | Type | Description |
33
44
|------|------|-------------|
34
-
|`epochNumber`|`uint256`| The epoch number to settle|
35
-
|`outputsMerkleRoot`|`bytes32`|Root hash of the outputs Merkle tree|
36
-
|`proof`|`bytes32[]`| Merkle proof array for validation|
45
+
|`epochNumber`|`uint256`| The current sealed epoch number (used to avoid race conditions)|
46
+
|`outputsMerkleRoot`|`bytes32`|The post-epoch outputs Merkle root (used to validate outputs)|
47
+
|`proof`|`bytes32[]`|The bottom-up Merkle proof of the outputs Merkle root in the final machine state|
37
48
38
49
### `getCurrentSealedEpoch()`
39
50
@@ -50,7 +61,7 @@ Get information about the current sealed epoch including bounds and tournament.
50
61
|`epochNumber`|`uint256`| Current epoch number |
51
62
|`inputIndexLowerBound`|`uint256`| Lower bound of input indices (inclusive) |
52
63
|`inputIndexUpperBound`|`uint256`| Upper bound of input indices (exclusive) |
0 commit comments