Staging batch 6

cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/vouchers.md

@@ -184,7 +184,7 @@ def emit_safe_erc20_transfer(token, to, amount):
     encoded_params = encode(["address", "address", "uint256"], [to_checksum_address(token), to_checksum_address(to), amount])
     payload = "0x" + (selector + encoded_params).hex()
     voucher = {
-        "destination": "0xfafafafafafafafafafafafafafafafafafafafa",  # endereço do contrato
+        "destination": "0xfafafafafafafafafafafafafafafafafafafafa",  # address of the contract containing the logic
         "payload": payload,
     }
     response = requests.post(rollup_server + "/delegate-call-voucher", json=voucher)
@@ -233,7 +233,7 @@ func emitSafeERC20Transfer(token, to common.Address, amount *big.Int) error {
 	}
 
 	voucher := map[string]interface{}{
-		"destination": "0xfafafafafafafafafafafafafafafafafafafafa",
+		"destination": "0xfafafafafafafafafafafafafafafafafafafafa", // address of the contract containing the logic
 		"payload":     common.Bytes2Hex(payload),
 	}
 

cartesi-rollups_versions.json

@@ -1,5 +1,4 @@
 [
-  "2.0",
   "1.5",
   "1.3",
   "1.0",

docs/compute.md

@@ -26,7 +26,7 @@ title: Cartesi Compute
 - [General requirements](./tutorials/requirements.md)
 - [Cartesi Compute SDK Environment](./tutorials/compute-env.md)
 
-### Hello World dApp
+### Hello World dApp 
 
 - [Creating basic dApp](./tutorials/helloworld/create-project.md)
 - [Hello World machine](./tutorials/helloworld/cartesi-machine.md)

docusaurus.config.js

@@ -185,7 +185,7 @@ const config = {
           },
           {
             label: "Rollups",
-            to: "/cartesi-rollups/2.0",
+            to: "/cartesi-rollups/1.5",
             activeBaseRegex: "^/cartesi-rollups",
             position: "left",
           },
@@ -348,7 +348,7 @@ const config = {
         // docRootComponent: "@theme/DocPage",
         docItemComponent: "@theme/ApiItem",
         includeCurrentVersion: false,
-        lastVersion: "2.0",
+        lastVersion: "1.5",
         admonitions: {
           keywords: [
             "note",
@@ -361,9 +361,9 @@ const config = {
           ],
         },
         versions: {
-          "2.0": {
-            label: "2.0",
-            path: "2.0",
+          "1.5": {
+            label: "1.5",
+            path: "1.5",
           },
         },
         showLastUpdateTime: true,
@@ -375,7 +375,7 @@ const config = {
         redirects: [
           {
             from: '/cartesi-rollups',      // the old/base route
-            to:   '/cartesi-rollups/2.0/', // the new route to redirect to
+            to:   '/cartesi-rollups/1.5/', // the new route to redirect to
           },
         ],
       },

fraud-proofs/prt/prt-introduction.md

@@ -5,20 +5,20 @@ The Permissionless Refereed Tournament (PRT) is the foundational algorithm of Ca
 In this section, we’ll look into the traditional fraud-proof models and how PRT overcomes the struggle of sybil attacks with its design elements. 
 
 ## Background: Traditional Fraud Proof Systems
-Traditional fraud-proof protocols are based on the work of [Canetti et. al](https://www.sciencedirect.com/science/article/pii/S0890540113000217?via%3Dihub). Consider the simplest setup with two players. The basic mechanism involves players agreeing on an initial state and state-transition function (STF), then running computations locally to submit final state claims to the blockchain. 
+The concept of fraud-proofs used in traditional optimistic rollups is based on the work of [Canetti et. al](https://www.sciencedirect.com/science/article/pii/S0890540113000217?via%3Dihub). Consider the simplest setup with two players. The basic mechanism involves players agreeing on an initial state and state-transition function (STF), then running computations locally to submit final state claims to the blockchain. 
 
 If both players submit the same claim, the system accepts it. If they disagree, a verification game begins. The game proceeds in two phases. First, a bisection phase runs as a binary search over the computation, narrowing down where the players first diverge. Once the divergent step is found, the blockchain itself applies the STF once in a one-step execution, and the dishonest party is eliminated.
 
 This two-player model is simple and robust. However, when extended naively to many players, it reveals a fundamental weakness.
 
-#### Fragility Under Sybils
+#### Limitations Under Sybils
 In the traditional model, each claim is tied to an individual player, and players cannot pool defences even if they agree. Every player must defend their claim personally, and their signatures are bound into the protocol. This allows for Sybil attacks: an adversary can spawn many identities, post the honest claim, and then deliberately lose verification games, causing the honest claim to be eliminated.
 
-In short, the approach does not reveal lies, it only reveals liars as called out in the EthResearch post [here](https://ethresear.ch/t/fraud-proofs-are-broken/19234). This fragility makes the approach unsuitable for permissionless environments, where Sybils are inevitable. Early fraud proof systems, such as those used in Cartesi and Arbitrum, would suffer indefinite settlement delays, since resolution time grows linearly with the number of Sybils.
+In short, its outcome reflects player elimination rather than the validation of the computational truth as called out in the EthResearch post [here](https://ethresear.ch/t/fraud-proofs-are-broken/19234). This fragility makes the approach unsuitable for permissionless environments, where Sybils are inevitable. Early fraud proof systems, such as those used in Cartesi and Arbitrum, would suffer indefinite settlement delays, since resolution time grows linearly with the number of Sybils.
 
-## Introducing PRT algorithm
-Permissionless Refereed Tournaments (PRT), developed by Cartesi, address this fragility by rethinking the nature of claims. Instead of committing only to the final state, PRT introduces **computation hashes** (explained in the _Fundamental Concepts_ section), which are stronger commitments to the entire path of the computation.
-A computation hash is built as a Merkle tree, where each leaf represents the state at every transition. In this way, a claim encodes not just an endpoint, but the full history of the computation. To defend a claim during a bisection, a player must provide a Merkle proof showing that an intermediate state is consistent with the computation hash. This eliminates the possibility of an adversary deliberately misplaying an honest claim, since the Merkle proofs themselves guarantee correctness.
+## Introducing PRT Algorithm
+Permissionless Refereed Tournaments (PRT), developed by Cartesi, address this fragility by rethinking the nature of claims. Instead of committing only to the final state, PRT introduces _computation hashes_ (explained in the [Fundamental Concepts](../../../fraud-proofs/fraud-proof-basics/state-transition-function#computation-hash) section), which are stronger commitments to the entire path of the computation.
+A **computation hash** is built as a Merkle tree, where each leaf represents the state at every transition. In this way, a claim encodes not just an endpoint, but the full history of the computation. To defend a claim during a bisection, a player must provide a Merkle proof showing that an intermediate state is consistent with the computation hash. This eliminates the possibility of an adversary deliberately misplaying an honest claim, since the Merkle proofs themselves guarantee correctness.
 
 With computation hashes, the protocol shifts from _revealing liars to revealing lies_. This shift has profound consequences. Players who agree on the same computation hash no longer need to defend claims in isolation. They can be grouped together and collaborate without requiring trust, forming what the literature calls the “hero” side of the dispute.
 

get-started/index.mdx

@@ -20,7 +20,7 @@ import DocCard from '@theme/DocCard';
     <DocCard item={{
       type: "link",
       label: "Cartesi Rollups",
-      href: "/cartesi-rollups/2.0/",
+      href: "/cartesi-rollups/1.5/",
       description: "Deploy scalable Appchains as L2/L3"
     }} />
   </div>
@@ -38,9 +38,9 @@ import DocCard from '@theme/DocCard';
   <div className="col col--6 p-2">
     <DocCard item={{
       type: "link",
-      label: "Dave",
-      href: "/get-started/fraud-proofs",
-      description: "Permissionless Fraud Proof system"
+      label: "Fraud Proof System",
+      href: "/fraud-proofs",
+      description: "Dispute resolution with PRT algorithm"
     }} />
   </div>
 

get-started/quickstart.md

@@ -40,13 +40,13 @@ If you use Windows, you must have [WSL2 installed and configured](https://learn.
 To create the backend application from scratch, run:
 
 ```bash
-cartesi rollups create <dapp-name> --template <language>
+cartesi create <dapp-name> --template <language>
 ```
 
 This creates a new directory with template code in the language you specify.
 
 ```bash
-$ cartesi rollups create js-dapp --template javascript
+$ cartesi create js-dapp --template javascript
 ✔ Application created at /js-dapp
 ```
 
@@ -69,18 +69,9 @@ The `cartesi build` command builds a Cartesi machine and compiles your applicati
 To run the environment, you can use the following command:
 
 ```bash
-cartesi rollups start
+cartesi run
 ```
-This will spin up docker containers for the Cartesi Rollups environment including Rollups Node and the Anvil devnet.
-
-## Deploy the application
-
-Deploying your application in this context means to register your application on the Cartesi Rollups environment.
-
-```shell
-cartesi rollups deploy
-```
-An address will be assigned to your application along with a corresponding Consensus Contract.
+This will run your backend with the docker containers for the Cartesi Rollups environment including Rollups validator node and the Anvil devnet.
 
 ## Send inputs to the application
 
@@ -128,13 +119,13 @@ You can obtain the relevant addresses by running `cartesi address-book`.
 
 You can create a custom frontend that interacts with your application.
 
-Follow [the React.js tutorial to build a frontend for your application](/cartesi-rollups/2.0/tutorials/react-frontend-application/).
+Follow [the React.js tutorial to build a frontend for your application](/cartesi-rollups/1.5/tutorials/react-frontend-application/).
 
 ## Deploy the application
 
 There are two methods to deploy an application:
 
-1. [Self-hosted deployment](/cartesi-rollups/2.0/deployment/self-hosted/): Deploy the application node using your infrastructure.
+1. [Self-hosted deployment](/cartesi-rollups/1.5/deployment/self-hosted/): Deploy the application node using your infrastructure.
 
 2. Third-party service provider: Outsource running the application node to a service provider.