diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/exception.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/exception.md index 654fb4e8f..1d0435870 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/exception.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/exception.md @@ -3,6 +3,8 @@ id: exception title: Exception --- + + The `/exception` endpoint is used to register an exception when the dApp cannot proceed with request processing. This should be the last method called by the dApp backend while processing a request. When an exception occurs during request processing, the dApp backend should: diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/finish.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/finish.md index 9480501e3..04338dd63 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/finish.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/finish.md @@ -3,6 +3,8 @@ id: finish title: Finish --- + + The `/finish` endpoint is used to indicate that any previous processing has been completed and the backend is ready to handle the next request. The subsequent request is returned as the call's response. The dApp backend should call the `/finish` endpoint to start processing rollup requests. The Rollup HTTP Server returns the next rollup request in the response body. diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/introduction.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/introduction.md index 6aae203b8..ed80346b2 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/introduction.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/introduction.md @@ -3,6 +3,8 @@ id: introduction title: Introduction --- + + The backend of a Cartesi dApp processes requests in the following manner: - **Finish** — Called via [`/finish`](./finish.md), indicates that any previous processing has been completed and the backend is ready to handle the next request. The subsequent request is returned as the call's response and can be of the following types: diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/notices.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/notices.md index 7a90900f2..27953794c 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/notices.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/notices.md @@ -3,6 +3,8 @@ id: notices title: Notices --- + + A notice is a verifiable data declaration that attests to off-chain events or conditions and is accompanied by proof. Notices provide a mechanism to communicate essential off-chain events from the execution layer to the base layer in a verifiable manner. diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/reports.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/reports.md index 34faa1ad4..3a712ead2 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/reports.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/reports.md @@ -3,6 +3,8 @@ id: reports title: Reports --- + + Reports are stateless logs, offering a means to record read-only information without changing the state. Primarily used for logging and diagnostic purposes, reports provide valuable insights into the operation and performance of a dApp. Unlike notices, reports lack any association with proof and are therefore unsuitable for facilitating trustless interactions, such as on-chain processing or convincing independent third parties of dApp outcomes. diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/vouchers.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/vouchers.md index 51409abfa..b273900a9 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/vouchers.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/vouchers.md @@ -6,6 +6,8 @@ resources: title: DELEGATECALL Opcode --- + + Vouchers serve as a mechanism for facilitating on-chain actions initiated in the execution layer. Imagine vouchers as digital authorization tickets that grant dApps the authority to execute specific actions directly on the base layer. These vouchers encapsulate the details of the desired on-chain action, such as a token swap request or asset transfer. diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/application-factory.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/application-factory.md index 164950726..785de1272 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/application-factory.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/application-factory.md @@ -6,6 +6,8 @@ resources: title: Application Factory contract --- + + The **ApplicationFactory** contract is a tool for reliably deploying new instances of the [`Application`](../contracts/application.md) contract with or without a specified salt value for address derivation. Additionally, it provides a function to calculate the address of a potential new `CartesiDApp` contract based on input parameters. diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/application.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/application.md index 385821a0e..6049486ce 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/application.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/application.md @@ -8,6 +8,8 @@ resources: title: OpenZeppelin Contracts --- + + The **Application** contract serves as the base layer representation of the application running on the execution layer. The application can interact with other smart contracts through the execution and validation of outputs. These outputs, generated by the application backend on the execution layer, can be proven in the base layer through claims submitted by a consensus contract. Every Application is subscribed to a consensus contract and governed by a single address (owner). The consensus has the authority to submit claims, which are then used to validate outputs. The owner has complete control over the Application and can replace the consensus at any time. Consequently, users of an Application must trust both the consensus and the application owner. Depending on centralization or ownership concerns, the ownership model can be modified. This process is managed by the consensus contract. For more information about different ownership and consensus models, refer to the [consensus contracts](./consensus/overview.md). diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/abstract-consensus.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/abstract-consensus.md index 7b586a402..23c31eb08 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/abstract-consensus.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/abstract-consensus.md @@ -6,6 +6,8 @@ resources: title: AbstractConsensus Contract --- + + The **AbstractConsensus** contract provides an abstract implementation of `IConsensus` with common consensus functionality. ## Functions diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/authority-factory.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/authority-factory.md index 48ec68eee..3e3eeb9d0 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/authority-factory.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/authority-factory.md @@ -6,6 +6,8 @@ resources: title: AuthorityFactory Contract --- + + The **AuthorityFactory** contract allows anyone to reliably deploy new `IAuthority` contracts. ## Functions diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/authority.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/authority.md index 48c604567..a29a840c8 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/authority.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/authority.md @@ -6,6 +6,8 @@ resources: title: Authority Contract --- + + The **Authority** contract implements a single-owner consensus mechanism where only the contract owner can submit and accept claims. ## Functions diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/iauthority-factory.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/iauthority-factory.md index c9c91f50d..00e4757da 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/iauthority-factory.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/iauthority-factory.md @@ -6,6 +6,8 @@ resources: title: IAuthorityFactory Interface --- + + The **IAuthorityFactory** interface defines the contract for deploying new `IAuthority` contracts. ## Events diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/iauthority.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/iauthority.md index 3e04fd366..bf0e47406 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/iauthority.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/authority/iauthority.md @@ -6,6 +6,8 @@ resources: title: IAuthority Interface --- + + The `IAuthority` interface defines a consensus contract controlled by a single address, the owner. ## Description diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/iconsensus.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/iconsensus.md index 660022646..539aba313 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/iconsensus.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/iconsensus.md @@ -6,6 +6,8 @@ resources: title: IConsensus Interface --- + + The `IConsensus` interface defines the main consensus contract behavior for validating and accepting claims submitted by validators. ## Description diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/ioutputs-merkle-root-validator.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/ioutputs-merkle-root-validator.md index 50381952d..a0b941c4a 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/ioutputs-merkle-root-validator.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/ioutputs-merkle-root-validator.md @@ -6,6 +6,8 @@ resources: title: IOutputsMerkleRootValidator Interface --- + + The `IOutputsMerkleRootValidator` interface provides valid outputs Merkle roots for validation. ## Description diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/overview.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/overview.md index dff5dd066..4f445ca03 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/overview.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/overview.md @@ -6,6 +6,8 @@ resources: title: Consensus Smart Contracts --- + + The consensus mechanism in Cartesi Rollups is responsible for validating and accepting claims submitted by validators. These contracts ensure the integrity of the rollup by validating outputs Merkle roots. ## Consensus Contracts diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/iquorum-factory.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/iquorum-factory.md index 1cf78eb89..e91cc0bc8 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/iquorum-factory.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/iquorum-factory.md @@ -6,6 +6,8 @@ resources: title: IQuorumFactory Interface --- + + The **IQuorumFactory** interface defines the contract for deploying new `IQuorum` contracts. ## Events diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/iquorum.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/iquorum.md index a179662a0..c033a9485 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/iquorum.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/iquorum.md @@ -6,6 +6,8 @@ resources: title: IQuorum Interface --- + + The `IQuorum` interface defines a consensus model controlled by a small, immutable set of validators. ## Description diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/quorum-factory.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/quorum-factory.md index 176f177b1..6d80d5270 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/quorum-factory.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/quorum-factory.md @@ -6,6 +6,8 @@ resources: title: QuorumFactory Contract --- + + The **QuorumFactory** contract allows anyone to reliably deploy new `IQuorum` contracts. ## Functions diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/quorum.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/quorum.md index 629339719..82099cc62 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/quorum.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/consensus/quorum/quorum.md @@ -6,6 +6,8 @@ resources: title: Quorum Contract --- + + The **Quorum** contract implements a multi-validator consensus mechanism where claims are accepted when a majority of validators vote in favor. ## Functions diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/input-box.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/input-box.md index 2bffa0cb4..7fae34b8d 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/input-box.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/input-box.md @@ -6,6 +6,8 @@ resources: title: InputBox contract --- + + The **InputBox** is a trustless and permissionless contract that receives arbitrary data blobs (called "inputs") from any sender and adds a compound hash to an append-only list (the "input box"). The hash stored on-chain comprises the hash of the input blob, block number, timestamp, input sender address, and input index. diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/overview.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/overview.md index 27f21b165..4435641b7 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/overview.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/overview.md @@ -6,6 +6,8 @@ resources: title: Smart Contracts for Cartesi Rollups --- + + The Cartesi Rollups framework consists of components on two layers: the base layer (the foundational blockchain where an application contract is deployed, such as Ethereum) and the execution layer (the Cartesi off-chain layer where the application runs its backend logic). The frontend interacts with base layer smart contracts to send inputs to the backend, deposit assets, and process outputs. diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC1155BatchPortal.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC1155BatchPortal.md index b9445c683..916f2213b 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC1155BatchPortal.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC1155BatchPortal.md @@ -4,6 +4,8 @@ resources: title: ERC1155BatchPortal contract --- + + The **ERC1155BatchPortal** allows anyone to perform batch transfers of ERC-1155 tokens to a dApp while informing the off-chain machine. diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC1155SinglePortal.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC1155SinglePortal.md index a85c7ee7b..ef5c47e5f 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC1155SinglePortal.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC1155SinglePortal.md @@ -4,6 +4,8 @@ resources: title: ERC1155SinglePortal contract --- + + The **ERC1155SinglePortal** allows anyone to perform single transfers of ERC-1155 tokens to a dApp while informing the off-chain machine. ### `depositSingleERC1155Token()` diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC20Portal.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC20Portal.md index 08261f225..5bc492c2b 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC20Portal.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC20Portal.md @@ -4,6 +4,8 @@ resources: title: ERC20Portal contract --- + + The **ERC20Portal** allows anyone to perform transfers of ERC-20 tokens to a dApp while informing the off-chain machine. diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC721Portal.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC721Portal.md index 7719e399f..2c688250a 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC721Portal.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/ERC721Portal.md @@ -4,6 +4,8 @@ resources: title: ERC721Portal contract --- + + The **ERC721Portal** allows anyone to perform transfers of ERC-721 tokens to a dApp while informing the off-chain machine. diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/EtherPortal.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/EtherPortal.md index edf46329e..aca3f188a 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/EtherPortal.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/contracts/portals/EtherPortal.md @@ -4,6 +4,8 @@ resources: title: EtherPortal contract --- + + The **EtherPortal** allows anyone to perform transfers of Ether to a dApp while informing the off-chain machine. diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/index.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/index.md index 6c06cf7c0..c41d72c45 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/index.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/index.md @@ -10,6 +10,8 @@ resources: title: Smart Contracts for Cartesi Rollups --- + + In a Cartesi dApp, the frontend and backend components communicate through the Rollups framework using HTTP and JSON-RPC APIs. When designing the APIs for this communication framework, we aimed to ensure that developers could create their applications without excessive concern about the low-level components of Cartesi Rollups. diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/inspect/inspect-state-http-api-for-cartesi-rollups.info.mdx b/cartesi-rollups_versioned_docs/version-2.0/api-reference/inspect/inspect-state-http-api-for-cartesi-rollups.info.mdx index f8b374352..5a0c07185 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/inspect/inspect-state-http-api-for-cartesi-rollups.info.mdx +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/inspect/inspect-state-http-api-for-cartesi-rollups.info.mdx @@ -8,6 +8,8 @@ hide_title: true custom_edit_url: null --- + + import ApiLogo from "@theme/ApiLogo"; import Heading from "@theme/Heading"; import SchemaTabs from "@theme/SchemaTabs"; diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/inspect/inspect.api.mdx b/cartesi-rollups_versioned_docs/version-2.0/api-reference/inspect/inspect.api.mdx index 2782999c4..e66bb8a22 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/inspect/inspect.api.mdx +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/inspect/inspect.api.mdx @@ -11,6 +11,8 @@ info_path: cartesi-rollups/_versioned_docs/version-2.0/rollups-apis/inspect/insp custom_edit_url: null --- + + import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods.md index a8e64b6e1..4c8a41b67 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods.md @@ -3,6 +3,8 @@ id: methods title: Methods --- + + # JSON-RPC API Methods This page provides a quick reference to all available JSON-RPC methods in the Cartesi Rollups Node API. For each method, you will find: diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/applications/get.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/applications/get.md index daff9086f..2e3e7ec03 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/applications/get.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/applications/get.md @@ -3,6 +3,8 @@ id: applications-get title: Get Application --- + + # Get Application ## Example Request diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/applications/list.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/applications/list.md index 55abab6ee..f7028d8b1 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/applications/list.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/applications/list.md @@ -3,6 +3,8 @@ id: applications-list title: List Applications --- + + # List Applications ## Example Request diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/epochs/get.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/epochs/get.md index 9fe4d1322..0a216f1a0 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/epochs/get.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/epochs/get.md @@ -3,6 +3,8 @@ id: epochs-get title: Get Epoch --- + + # Get Epoch ## Example Request diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/epochs/last-accepted.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/epochs/last-accepted.md index 1b56d9e03..4b15922ae 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/epochs/last-accepted.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/epochs/last-accepted.md @@ -3,6 +3,8 @@ id: jsonrpc-epochs-last-accepted title: Get Last Accepted Epoch Index --- + + # Get Last Accepted Epoch Index ## Example Request diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/epochs/list.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/epochs/list.md index 1808db3c6..a589d0d9d 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/epochs/list.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/epochs/list.md @@ -3,6 +3,8 @@ id: epochs-list title: List Epochs --- + + # List Epochs ## Example Request diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/inputs/get.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/inputs/get.md index abfd335cd..a25170ec8 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/inputs/get.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/inputs/get.md @@ -3,6 +3,8 @@ id: inputs-get title: Get Input --- + + # Get Input ## Example Request diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/inputs/list.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/inputs/list.md index b19f93d1c..3afdd921b 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/inputs/list.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/inputs/list.md @@ -3,6 +3,8 @@ id: inputs-list title: List Inputs --- + + # List Inputs ## Example Request diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/inputs/processed-count.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/inputs/processed-count.md index 22cc6d0c8..57ad1ffe2 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/inputs/processed-count.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/inputs/processed-count.md @@ -3,6 +3,8 @@ id: jsonrpc-inputs-processed-count title: Get Processed Input Count --- + + # Get Processed Input Count ## Example Request diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/node/chain-id.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/node/chain-id.md index 86db0d2e8..79166d723 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/node/chain-id.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/node/chain-id.md @@ -3,6 +3,8 @@ id: node-chain-id title: Get Chain ID --- + + # Get Chain ID ## Example Request diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/node/version.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/node/version.md index 26dc7b0f6..f44840a0f 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/node/version.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/node/version.md @@ -3,6 +3,8 @@ id: node-version title: Get Node Version --- + + # Get Node Version ## Example Request diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/outputs/get.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/outputs/get.md index 6440d64f9..416904fe9 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/outputs/get.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/outputs/get.md @@ -3,6 +3,8 @@ id: outputs-get title: Get Output --- + + # Get Output ## Example Request diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/outputs/list.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/outputs/list.md index e791300aa..44d0dec19 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/outputs/list.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/outputs/list.md @@ -3,6 +3,8 @@ id: outputs-list title: List Outputs --- + + # List Outputs ## Example Request diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/reports/get.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/reports/get.md index 427790c23..744edd48f 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/reports/get.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/reports/get.md @@ -3,6 +3,8 @@ id: reports-get title: Get Report --- + + # Get Report ## Example Request diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/reports/list.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/reports/list.md index 2f76c7c79..90218c3a7 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/reports/list.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/methods/reports/list.md @@ -3,6 +3,8 @@ id: reports-list title: List Reports --- + + # List Reports ## Example Request diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/overview.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/overview.md index a26d904fd..4812a6498 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/overview.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/overview.md @@ -3,6 +3,8 @@ id: overview title: Overview --- + + # JSON-RPC API Overview The Cartesi Rollups Node API provides a JSON-RPC interface for interacting with Cartesi Rollups applications. This API allows you to: diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/types.md b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/types.md index 83e13ed96..02f3d0bc7 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/types.md +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/jsonrpc/types.md @@ -3,6 +3,8 @@ id: types title: Types --- + + # JSON-RPC API Types This page documents the data types used in the Cartesi Rollups Node API. These types are used in both request parameters and response data. diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/add-notice.api.mdx b/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/add-notice.api.mdx index f9b08d8a2..085b93b6f 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/add-notice.api.mdx +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/add-notice.api.mdx @@ -11,6 +11,8 @@ info_path: cartesi-rollups/_versioned_docs/version-2.0/api-reference/rollup/cart custom_edit_url: null --- + + import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/add-report.api.mdx b/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/add-report.api.mdx index c26919d19..161e94240 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/add-report.api.mdx +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/add-report.api.mdx @@ -11,6 +11,8 @@ info_path: cartesi-rollups/_versioned_docs/version-2.0/api-reference/rollup/cart custom_edit_url: null --- + + import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/add-voucher.api.mdx b/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/add-voucher.api.mdx index 30ee98781..d50786ce0 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/add-voucher.api.mdx +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/add-voucher.api.mdx @@ -11,6 +11,8 @@ info_path: cartesi-rollups/_versioned_docs/version-2.0/api-reference/rollup/cart custom_edit_url: null --- + + import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/cartesi-rollup-http-api.info.mdx b/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/cartesi-rollup-http-api.info.mdx index 977acdbb0..1de6b7f2f 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/cartesi-rollup-http-api.info.mdx +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/cartesi-rollup-http-api.info.mdx @@ -8,6 +8,8 @@ hide_title: true custom_edit_url: null --- + + import ApiLogo from "@theme/ApiLogo"; import Heading from "@theme/Heading"; import SchemaTabs from "@theme/SchemaTabs"; diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/finish.api.mdx b/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/finish.api.mdx index 008eaf191..3216409aa 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/finish.api.mdx +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/finish.api.mdx @@ -11,6 +11,8 @@ info_path: cartesi-rollups/_versioned_docs/version-2.0/api-reference/rollup/cart custom_edit_url: null --- + + import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; diff --git a/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/register-exception.api.mdx b/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/register-exception.api.mdx index 088e24374..b92a1dc12 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/register-exception.api.mdx +++ b/cartesi-rollups_versioned_docs/version-2.0/api-reference/rollup/register-exception.api.mdx @@ -11,6 +11,8 @@ info_path: cartesi-rollups/_versioned_docs/version-2.0/api-reference/rollup/cart custom_edit_url: null --- + + import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; diff --git a/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/mcp-server.mdx b/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/mcp-server.mdx index 661b7dc8e..e603eb645 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/mcp-server.mdx +++ b/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/mcp-server.mdx @@ -5,6 +5,8 @@ resources: title: MCP Server Standard --- + + import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; diff --git a/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/overview.md b/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/overview.md index 947d31a9c..a7ed28020 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/overview.md +++ b/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/overview.md @@ -2,6 +2,8 @@ title: Overview --- + + import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; diff --git a/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/prompting.md b/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/prompting.md index 6818bda2a..0bc717b5d 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/prompting.md +++ b/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/prompting.md @@ -2,6 +2,8 @@ title: Prompting --- + + Effective prompting helps your AI assistant use Cartesi docs, skills, and the MCP server reliably. Clear prompts tell the assistant what to generate and which skill or doc source to follow. ## Anatomy of a strong prompt diff --git a/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/skills.md b/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/skills.md index a4a13c2f7..a0a8371e8 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/skills.md +++ b/cartesi-rollups_versioned_docs/version-2.0/build-with-ai/skills.md @@ -9,6 +9,8 @@ resources: title: Cartesi skills setup walkthrough --- + + **Cartesi Skills** are lightweight, specialized instructions for AI agents. Each skill covers a focused task: scaffolding a new app, building backend logic, wiring a frontend, interacting with L1 contracts, or deploying to a self-hosted node. Cartesi Skills follow the open [Agent Skills](https://agentskills.io/home) format. For a similar pattern in the broader Ethereum ecosystem, see [eth-skills](https://www.ethskills.com/). diff --git a/cartesi-rollups_versioned_docs/version-2.0/core-concepts/cartesi-machine.md b/cartesi-rollups_versioned_docs/version-2.0/core-concepts/cartesi-machine.md index 72140ca2d..7ec8c59b2 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/core-concepts/cartesi-machine.md +++ b/cartesi-rollups_versioned_docs/version-2.0/core-concepts/cartesi-machine.md @@ -3,6 +3,8 @@ id: cartesi-machine title: Cartesi Machine --- + + The [Cartesi Machine](/cartesi-machine) is a virtual machine that runs an entire Linux OS, in which a dApp's backend is executed. The Cartesi Machine is based on the [RISC-V ISA](https://riscv.org/), a set of instructions for processors. It runs in isolation, meaning it operates independently and is reproducible. Central to Cartesi Rollups is the Cartesi Machine, a virtual machine designed to perform off-chain computations for blockchain applications. When examined from a high level of abstraction, the Cartesi Machine can be compared to an AWS Lambda function, with similarities that encompass: diff --git a/cartesi-rollups_versioned_docs/version-2.0/deployment/introduction.md b/cartesi-rollups_versioned_docs/version-2.0/deployment/introduction.md index 4460f0066..27a7039cc 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/deployment/introduction.md +++ b/cartesi-rollups_versioned_docs/version-2.0/deployment/introduction.md @@ -7,6 +7,8 @@ resources: --- + + Applications built on Cartesi Rollups are intended to be deployed to public blockchains so users can access them. This can be done by taking advantage of a cloud-based infrastructure. Deploying a Cartesi dApp involves two steps: deploying a smart contract that defines your dApp on-chain and then instantiating a node that runs the application's intended backend logic. diff --git a/cartesi-rollups_versioned_docs/version-2.0/deployment/self-hosted/standard.md b/cartesi-rollups_versioned_docs/version-2.0/deployment/self-hosted/standard.md index e1ebc58f8..e43d24974 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/deployment/self-hosted/standard.md +++ b/cartesi-rollups_versioned_docs/version-2.0/deployment/self-hosted/standard.md @@ -3,21 +3,41 @@ id: standard title: Self-hosted deployment (standard) --- -This guide explains how to run a Cartesi Rollups node locally on your machine for development and testing purposes on **testnet**. + + +This guide explains how to run a Cartesi Rollups node on your machine for **testnet** development and testing. :::warning Production Warning -**This self-hosted approach should NOT be used in _production_.** +**Do not use this compose file as a production deployment.** + +It is a testnet-oriented starting point. It does not include public snapshot verification, production-grade secrets, high availability, or hardened Postgres. +::: + +## Node topology + +The [Mugen-Builders compose file](https://github.com/Mugen-Builders/deployment-setup-v2.0) already runs **one process per container**, not a single combined node: + +| Service | Role | +| :-- | :-- | +| `database` | Postgres | +| `evm-reader` | Reads L1 inputs and related events | +| `advancer` | Runs the Cartesi Machine; serves inspect | +| `validator` | Computes epoch claims and proofs | +| `claimer` | Submits claims on-chain | +| `jsonrpc-api` | JSON-RPC query API | + +Keep that split. Do not collapse reader, advancer, validator, claimer, and JSON-RPC into one process except for short local experiments. -While this setup works with testnet environments, it's designed exclusively for development purposes. It lacks critical production requirements such as: +The sample compose shares one Postgres role (`postgres`) and one database (`rollupsdb`). That is acceptable only for this testnet compose. For any longer-lived deployment, create a **dedicated database user per service**, grant only the tables that service needs, and do not use the superuser in application containers. -- Public snapshot verification -- Proper security hardening -- Production-grade infrastructure. - ::: +The EVM reader **polls HTTP**. `BLOCKCHAIN_HTTP_ENDPOINT` is required. A WebSocket endpoint is optional and is not required for reading blocks. + +Pin runtime and database image tags to the rollups-node release you intend to run. The compose file on GitHub may lag a newer node alpha. ## Prerequisites -Before starting, ensure you have the following installed: +- Cartesi CLI 2.0 (currently alpha) +- Docker Desktop 4.x (Compose and Buildx) - Cartesi CLI: An easy-to-use tool for developing and deploying your dApps. @@ -27,57 +47,49 @@ For more details about the installation process for each of these tools, please ## Configuration -Before running the node, you need to configure your `.env` file with the following environment variables: +Create a `.env` file in the project root: ```shell BLOCKCHAIN_ID= AUTH_KIND="private_key" CARTESI_AUTH_PRIVATE_KEY="" -BLOCKCHAIN_WS_ENDPOINT="" BLOCKCHAIN_HTTP_ENDPOINT="" CARTESI_BLOCKCHAIN_DEFAULT_BLOCK="" ``` -**Important notes:** - | Variable | Description | | ---------------------------------- | -------------------------------------------------------------------- | -| `BLOCKCHAIN_ID` | Replace `` with your blockchain network ID | -| `BLOCKCHAIN_WS_ENDPOINT` | Replace `` with your WebSocket endpoint | -| `BLOCKCHAIN_HTTP_ENDPOINT` | Replace `` with your HTTP endpoint | -| `AUTH_KIND` | Set to `private_key` for local development | -| `CARTESI_AUTH_PRIVATE_KEY` | Replace `` with a private key for selected chain | -| `CARTESI_BLOCKCHAIN_DEFAULT_BLOCK` | Set to either `latest` or `finalized` | +| `BLOCKCHAIN_ID` | Chain ID of the target network | +| `BLOCKCHAIN_HTTP_ENDPOINT` | HTTP JSON-RPC endpoint for the base layer | +| `AUTH_KIND` | `private_key` for local and testnet experiments | +| `CARTESI_AUTH_PRIVATE_KEY` | Funded private key for the selected chain | +| `CARTESI_BLOCKCHAIN_DEFAULT_BLOCK` | `latest` or `finalized` | :::danger Security -Ensure to follow best practices when handling private keys during local development and deployment to production. +Do not commit private keys. Use Docker secrets or a file-backed key in any environment that is not a throwaway testnet. ::: ## Setting up the local node -1. **Download the Cartesi Rollups Node docker compose file in your project root:** +1. **Download the compose file into the project root** (alongside `.cartesi/`): ```shell curl -L https://raw.githubusercontent.com/Mugen-Builders/deployment-setup-v2.0/main/compose.local.yaml -o compose.local.yaml ``` -2. **Build the application with the Cartesi CLI:** +2. **Build the application snapshot:** ```shell cartesi build ``` - This command compiles your application into RISC-V architecture and creates a Cartesi machine snapshot locally. - -3. **Run the Cartesi Rollups Node with the application's initial snapshot attached:** +3. **Start the stack:** ```shell docker compose -f compose.local.yaml --env-file .env up -d ``` - This starts the local node using the configuration from your `.env` file. - -4. **Deploy and register the application to the node:** +4. **Deploy and register the application:** ```shell docker compose --project-name cartesi-rollups-node \ @@ -87,19 +99,17 @@ Ensure to follow best practices when handling private keys during local developm --register ``` - Replace `` with your application name and `` with a unique identifier. The salt must be unique for each deployment and cannot be repeated. You can generate a unique salt using: + Replace `` with the application name. The salt must be unique. Generate one with: ```shell cast keccak256 "your-unique-string" ``` - After this process, you'll have your application deployed and registered to the node. - - If deployment fails during the automated process, fall back to manually deploying the authority and application contracts. + If deployment fails, fall back to deploying authority and application contracts separately. ### Manual deployment fallback - 1. Deploy an authority contract with `cast`. Replace each placeholder with the expected value, and grab the returned address from the command output (the final `sed` call normalizes the address). + 1. Deploy an authority with `cast`. Capture the returned address (the `sed` call normalizes it): ```shell cast send "newAuthority(address,uint256)" \ @@ -107,9 +117,9 @@ Ensure to follow best practices when handling private keys during local developm --json | jq -r '.logs[-1].data' | sed 's/^0x000000000000000000000000/0x/' ``` - You can find the AuthorityFactory, portals and inputbox addresses for your target chain in the **Deployed Contracts** section below; Replace `` with the appropriate address. + Factory, portal, and InputBox addresses for the target chain are listed under **Deployed contracts** below. - 2. Use the address you got above as the `` in the deploy command below. This command re-runs the snapshot registration using the specified authority and epoch values. + 2. Register the snapshot against that authority: ```shell docker compose --project-name cartesi-rollups-node \ @@ -119,11 +129,11 @@ Ensure to follow best practices when handling private keys during local developm --json ``` - On success this command deploys, registers and returns the address of the deployed application contract, this should be notted for further interaction with your applciation. + On success the command returns the application contract address. -## Deployed Contracts: +## Deployed contracts -Depending on your intended deployment chain, you can find the list of required contracts like the Inputbox, Portals, Authority Factory etc, below: +Rollups contract addresses for supported networks: - [Cannon Devnet](https://usecannon.com/packages/cartesi-rollups/2.2.0/13370-main/deployment/contracts) - [Ethereum Sepolia](https://usecannon.com/packages/cartesi-rollups/2.2.0/11155111-main/deployment/contracts) @@ -131,9 +141,9 @@ Depending on your intended deployment chain, you can find the list of required c - [OP Sepolia](https://usecannon.com/packages/cartesi-rollups/2.2.0/11155420-main/deployment/contracts) - [Base Sepolia](https://usecannon.com/packages/cartesi-rollups/2.2.0/84532-main/deployment/contracts) -## Accessing the node +Use the Cannon package version that matches the contract suite your node was built against. -Once running, your local Cartesi Rollups Node will be accessible through the standard APIs: +## Accessing the node -- Inspect endpoint: `http://localhost:10012/inspect/` -- JSON-RPC endpoint: `http://localhost:10011/rpc` +- Inspect: `http://localhost:10012/inspect/` +- JSON-RPC: `http://localhost:10011/rpc` diff --git a/cartesi-rollups_versioned_docs/version-2.0/deployment/snapshot.md b/cartesi-rollups_versioned_docs/version-2.0/deployment/snapshot.md index 2b79b0c08..237a7a40a 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/deployment/snapshot.md +++ b/cartesi-rollups_versioned_docs/version-2.0/deployment/snapshot.md @@ -3,6 +3,8 @@ id: snapshot title: Public snapshot --- + + A Cartesi snapshot is a compressed representation of your application's machine state that can be deployed to rollups nodes. This process involves: 1. Building your application with the Cartesi CLI diff --git a/cartesi-rollups_versioned_docs/version-2.0/development/advanced-configuration.md b/cartesi-rollups_versioned_docs/version-2.0/development/advanced-configuration.md index 47d208292..e8268c4f0 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/development/advanced-configuration.md +++ b/cartesi-rollups_versioned_docs/version-2.0/development/advanced-configuration.md @@ -4,6 +4,8 @@ title: Advanced configuration resources: --- + + When you build an application with the Cartesi CLI, the CLI needs to know how to set up your Cartesi Machine. Things like how much memory to allocate, what code to run, and what data to include. All of these choices live in a single file at the root of your project called `cartesi.toml`. If you have worked with configuration files like `docker-compose.yml` or `Cargo.toml`, the idea is the same. You describe what you want, and the CLI takes care of the rest. diff --git a/cartesi-rollups_versioned_docs/version-2.0/development/asset-handling.md b/cartesi-rollups_versioned_docs/version-2.0/development/asset-handling.md index 4bbf9ff24..f8c222c86 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/development/asset-handling.md +++ b/cartesi-rollups_versioned_docs/version-2.0/development/asset-handling.md @@ -6,6 +6,8 @@ resources: title: The Cartesi dApp Developer Free Course --- + + Assets exist on the base layer, where they have actual meaning and value. As with any execution layer solution, a Cartesi Application that wants to manipulate assets needs a secure way of "teleporting" the assets from the base layer to the execution layer and when necessary, back to the base layer. diff --git a/cartesi-rollups_versioned_docs/version-2.0/development/building-an-application.md b/cartesi-rollups_versioned_docs/version-2.0/development/building-an-application.md index 6f04bf241..37a9671f3 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/development/building-an-application.md +++ b/cartesi-rollups_versioned_docs/version-2.0/development/building-an-application.md @@ -3,6 +3,8 @@ id: building-an-application title: Building an application --- + + “Building” in this context compiles your application into RISC-V architecture and consequently builds a Cartesi machine containing your application. This architecture enables computation done by your application to be reproducible and verifiable. Ensure you have Docker engine running, then navigate the directory to your application and build by running: diff --git a/cartesi-rollups_versioned_docs/version-2.0/development/creating-an-application.md b/cartesi-rollups_versioned_docs/version-2.0/development/creating-an-application.md index 7322c317b..d287e2f43 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/development/creating-an-application.md +++ b/cartesi-rollups_versioned_docs/version-2.0/development/creating-an-application.md @@ -6,6 +6,8 @@ resources: title: CartesiScan --- + + Cartesi CLI simplifies creating applications on Cartesi. To create a new application, run: @@ -33,9 +35,8 @@ This command creates a `new-app` directory with essential files for your applica Cartesi CLI has templates for the following languages – `cpp`, `cpp-low-level`, `go`, `java`, `javascript`, `lua`, `python`, `ruby`, `rust`, and `typescript`. :::note Libraries for simplifying development -We have high-level framework and alternative templates that simplify development and enhances input management, providing a smoother and more efficient experience. -For Go use Rollmelette, for Rust use Crabrolls, for Python use python-Cartesi and for Typescript/Javascrips use Deroll. -Visit this [page](../resources/community-tools.md) to learn more about these and other available tools. +High-level frameworks can simplify routing, inputs, and testing. For TypeScript use Deroll; for Python use python-Cartesi or Cartesapp. +See [Community tools](../resources/community-tools.md). ::: ## Implementing your application Logic diff --git a/cartesi-rollups_versioned_docs/version-2.0/development/installation.md b/cartesi-rollups_versioned_docs/version-2.0/development/installation.md index 3749d327b..e70fd7b23 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/development/installation.md +++ b/cartesi-rollups_versioned_docs/version-2.0/development/installation.md @@ -12,6 +12,8 @@ resources: title: Install Ubuntu LTS --- + + The primary requirements for building on Cartesi are: - Cartesi CLI: An easy-to-use tool for developing and deploying your dApps. diff --git a/cartesi-rollups_versioned_docs/version-2.0/development/query-outputs.md b/cartesi-rollups_versioned_docs/version-2.0/development/query-outputs.md index df8db12b8..5e96b6663 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/development/query-outputs.md +++ b/cartesi-rollups_versioned_docs/version-2.0/development/query-outputs.md @@ -6,6 +6,8 @@ resources: title: The Cartesi dApp Developer Free Course --- + + In Cartesi Rollups, outputs are essential in interacting with the blockchain. The direct output types are notices, reports and vouchers. The JSON-RPC server unifies Notice and Vouchers into a single query, therefore a single request returns all Notices and Vouchers generated by the application. diff --git a/cartesi-rollups_versioned_docs/version-2.0/development/running-an-application.md b/cartesi-rollups_versioned_docs/version-2.0/development/running-an-application.md index d77a09085..7770ff6f8 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/development/running-an-application.md +++ b/cartesi-rollups_versioned_docs/version-2.0/development/running-an-application.md @@ -6,6 +6,8 @@ resources: title: CartesiScan --- + + Running your application creates a docker container containing all required services, and exposes your application node on port `6751`, then an anvil network specific to your application on port `6751/anvil`. The node also logs all outputs received by your backend. Here are the prerequisites to run the node: @@ -83,7 +85,3 @@ Each of these services runs independently and can be activated or deactivated at - **Paymaster**: An account abstraction implementation that works hand in hand with the bundler to sponsor gas fees for transactions handled by the bundler, available at `http://localhost:6751/paymaster`. - **Passkey**: Runs a local passkey server, that enables account generation and interaction with application without a traditional wallet, available at `http://localhost:6751/passkey` - -:::note Testing tools -[NoNodo](https://github.com/Calindra/nonodo) is a Cartesi Rollups testing tool that works with host machine applications, eliminating the need for Docker or RISC-V compilation. -::: diff --git a/cartesi-rollups_versioned_docs/version-2.0/development/send-inputs-and-assets.md b/cartesi-rollups_versioned_docs/version-2.0/development/send-inputs-and-assets.md index 5581ec822..6f8a6bb2d 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/development/send-inputs-and-assets.md +++ b/cartesi-rollups_versioned_docs/version-2.0/development/send-inputs-and-assets.md @@ -8,6 +8,8 @@ resources: title: Angular template --- + + You can send two requests to an application depending on whether you want to change or read the state. - **Advance**: In this request, any input data changes the state of the application. diff --git a/cartesi-rollups_versioned_docs/version-2.0/getting-started/architecture.md b/cartesi-rollups_versioned_docs/version-2.0/getting-started/architecture.md index deb74432f..a3d80ce66 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/getting-started/architecture.md +++ b/cartesi-rollups_versioned_docs/version-2.0/getting-started/architecture.md @@ -14,6 +14,8 @@ resources: title: Dave --- + + The Cartesi Rollups framework is designed to enable complex computations off-chain while maintaining the security guarantees of blockchain technology. It consists of two primary components: **the on-chain base layer** (such as Ethereum), where the dApp contract is deployed, and **the off-chain execution layer**, where the dApp's backend logic operates. A decentralized application (dApp) built on Cartesi incorporates several key elements: diff --git a/cartesi-rollups_versioned_docs/version-2.0/getting-started/concepts.md b/cartesi-rollups_versioned_docs/version-2.0/getting-started/concepts.md index cefcf22fc..34cf9e877 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/getting-started/concepts.md +++ b/cartesi-rollups_versioned_docs/version-2.0/getting-started/concepts.md @@ -8,6 +8,8 @@ resources: title: Dave --- + + Before diving deep into the architecture and mechanisms of rollups, it's important to understand the fundamental concepts behind these scalability solutions. Rollups play a crucial role in enhancing blockchain performance by moving computation off-chain while ensuring security through on-chain verification. This section covers the core principles of rollups, the different approaches to validating state updates, and how dispute resolution mechanisms function. These foundational ideas will help you better grasp the architecture and innovations introduced by Cartesi's rollup solutions, including the **Dave** fraud-proof system. ## What is a Blockchain Rollup? diff --git a/cartesi-rollups_versioned_docs/version-2.0/getting-started/installation.md b/cartesi-rollups_versioned_docs/version-2.0/getting-started/installation.md index eed732d03..4fed879e5 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/getting-started/installation.md +++ b/cartesi-rollups_versioned_docs/version-2.0/getting-started/installation.md @@ -3,4 +3,6 @@ id: Installation title: Installation --- + + TODO: This is blank diff --git a/cartesi-rollups_versioned_docs/version-2.0/index.md b/cartesi-rollups_versioned_docs/version-2.0/index.md index f3bd14c7e..768e0da8b 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/index.md +++ b/cartesi-rollups_versioned_docs/version-2.0/index.md @@ -8,6 +8,8 @@ resources: title: Application-Specific Rollups --- + + Welcome to Cartesi Rollups, where decentralized application development meets unprecedented flexibility. With a foundation built on the Linux operating system, Cartesi Rollups offers modular stacks that allow developers to tailor consensus, data availability, and settlement layers according to their project requirements. Utilizing the Cartesi Machine for transaction processing, developers can effortlessly implement sophisticated logic using their preferred programming language or tool. Explore the possibilities and streamline your decentralized application development journey with Cartesi Rollups. diff --git a/cartesi-rollups_versioned_docs/version-2.0/resources/community-tools.md b/cartesi-rollups_versioned_docs/version-2.0/resources/community-tools.md index c403a64ce..003671e61 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/resources/community-tools.md +++ b/cartesi-rollups_versioned_docs/version-2.0/resources/community-tools.md @@ -3,180 +3,58 @@ id: community-tools title: Community tools --- -Several tools created and maintained by the community streamline the dApp creation process on Cartesi Rollups. + -## Deroll - -Introducing Deroll, a powerful TypeScript framework designed to simplify the development of dApps on Cartesi. - -- **Features**: - - Simplifies dApp development with intuitive methods. - - Handles advance and inspect requests easily. - - Comprehensive wallet functionality for ERC20, ERC721 and ERC-1155 token standards. - - Integrated router for complex routing logic. - -- **Getting Started**: - - Create a new Deroll project by running: - ```bash - npm init @deroll/app - ``` - -- **Resources**: - - [Deroll Documentation](https://deroll.dev) - - [Deroll GitHub Repository](https://github.com/tuler/deroll) - ---- - -## NoNodo - -NoNodo is a cutting-edge development tool for Cartesi Rollups that allows applications to run directly on the host machine, bypassing Docker or RISC-V compilation. - -- **Features**: - - Run applications directly on the host machine for faster performance. - - No Docker or RISC-V Required. - -- **Getting Started**: - - Install NoNodo by running: - ```bash - npm install -g @nonodo/cli - ``` -- **Resources**: - - [NoNodo GitHub Repository](https://github.com/Calindra/nonodo) - ---- - -## Cartesify - -Cartesify is a robust Web3 client designed for seamless interaction with the Cartesi Machine. - -- **Features**: - - Send transactions to the Cartesi Machine. - - Query data efficiently. - - Engage with backend systems using a REST-like interface. - -- **Resources**: - - [Cartesify GitHub Repository](https://github.com/Calindra/cartesify) - ---- - -## Tikua +Community projects that help build Cartesi Rollups applications. These are maintained outside the core Cartesi repositories. Confirm compatibility with Rollups v2 (JSON-RPC node API, unified outputs) before adopting them. -Tikua is a versatile JS Cartesi package designed for seamless integration with any visual library, whether in browser or terminal environments. - -- **Features**: - - Integrates smoothly with any visual library on both Browser and Terminal. - - Supports any provider or network with extensive configurability. - - Handles multi-chain applications. - - Provides warnings for unsupported provider chains. - - Retrieve machine results. - -- **Resources**: - - - [Tikua GitHub Repository](https://github.com/doiim/tikua) - - ---- - -## Rollmelette - -Rollmelette is a high-level framework that simplifies building Cartesi applications using the Go programming language. - -- **Features**: - - Simplifies the development of Cartesi applications. - - Provides a high-level API for interacting with the Cartesi Machine. - - Simplifies sending inputs, retrieving outputs and asset handling - - Supports the Go programming language. - -- **Resources**: - - [Rollmelette GitHub Repository](https://github.com/rollmelette/rollmelette) - ---- - -## Crabrolls +## Deroll -Introducing Crabroll, a powerful Rust framework designed to simplify the development of rust applications on Cartesi. +TypeScript framework for Cartesi dApps. -- **Features**: - - Simplifies dApp development with intuitive methods. - - Handles advance and inspect requests easily. - - Comprehensive wallet functionality for ERC20, ERC721 and ERC-1155 token standards. +- Advance and inspect handlers +- Wallet helpers for ERC-20, ERC-721, and ERC-1155 +- Router for application methods -- **Getting Started**: - - Create a new crabrolls project by running: - ```bash - git clone git@github.com:crabrolls-cartesi/template.git - ``` +```bash +npm init @deroll/app +``` -- **Resources**: - - [Crabrolls Documentation](https://crabrolls-cartesi.github.io/crabrolls/) - - [Crabrolls GitHub Repository](https://github.com/crabrolls-cartesi/crabrolls) +- [Documentation](https://deroll.dev) +- [GitHub](https://github.com/tuler/deroll) --- -## Python-Cartesi +## libcma (Cartesi Machine Assets) -Python-Cartesi is a high-level framework that simplifies the development of Cartesi applications using Python. +C++ library for parsing portal deposits and managing an in-machine asset ledger (Ether, ERC-20, ERC-721, ERC-1155). It is the basis for proveable balances and contracts v3 emergency withdrawal. -- **Features**: - - Simplifies the development of Cartesi applications. - - Prioritizes testing, equipping developers with tools to write tests for DApps within a local Python environment. - - Allows full control over inputs and outputs for scenarios where high-level tools may be insufficient - - Supports the Python programming language. +- Core: [Mugen-Builders/machine-asset-tools](https://github.com/Mugen-Builders/machine-asset-tools) +- Rust bindings: [Mugen-Builders/cma-rust-parser](https://github.com/Mugen-Builders/cma-rust-parser) +- Node.js / TypeScript bindings: [riseandshaheen/libcma-binding-node](https://github.com/riseandshaheen/libcma-binding-node) -- **Getting Started**: - - Install Python-Cartesi by running: - ```bash - pip install python-cartesi - ``` -- **Resources**: - - [Python-Cartesi GitHub Repository](https://github.com/prototyp3-dev/python-cartesi) +Related: [libcmt bindings](https://github.com/Mugen-Builders/libcmt-bindings) expose the guest `libcmt` C API (rollup I/O, ABI, Merkle) without the HTTP rollup server. --- -## TypeScript-SQLite template - -A backend application built with TypeScript and SQLite, designed to complement a corresponding frontend project. - -- **Features**: - - TypeScript and SQLite for backend development. - - Integration with React for the frontend. - - Ethers.js for seamless blockchain interaction. - - Template designed for easy project initiation. - -- **Resources**: - - [TypeScript-SQLite GitHub Repository](https://github.com/doiim/cartesi-ts-sqlite) - - [Pre-deployed demo available on the Sepolia Network](https://doiim.github.io/cartesi-ts-react-sqlite/). - ---- +## Python-Cartesi -## Python-Wallet +Python framework with local testing helpers and control over inputs and outputs. -A Python-based wallet implementation for Cartesi dApps designed to handle various types of assets. +```bash +pip install python-cartesi +``` -- **Features**: - - Simplifies asset handling for Cartesi dApps. - - Deposit assets into the dApp. - - Transfer assets within the dApp. - - Withdraw assets from the dApp. +- [GitHub](https://github.com/prototyp3-dev/python-cartesi) -- **Resources**: - - [Python-Wallet GitHub Repository](https://github.com/jplgarcia/python-wallet/tree/main) - - [Full example](https://github.com/jplgarcia/python-wallet/blob/main/dapp.py) --- -## CartDevKit -CartDevKit is an all-in-one package for building on Cartesi. +## Cartesapp -- **Features**: - - CLI tool for easy project setup. - - Templates for backend, frontend and Cartesify. +Opinionated Python library and CLI for Cartesi Rollups apps: routed endpoints, host and machine tests, build/run/deploy, and auto-generated frontend libraries. -- **Getting Started**: - - Create a new project: - ```bash - npx cartdevkit@latest create mydapp - ``` +```bash +pip3 install cartesapp[dev]@git+https://github.com/prototyp3-dev/cartesapp@main +cartesapp create NAME +``` -- **Resources**: - - [CartDevKit GitHub Repository](https://github.com/gconnect/cartdev-kit) - - [CartDevKit Documentation](https://africlab.gitbook.io/cartdevkit) \ No newline at end of file +- [GitHub](https://github.com/prototyp3-dev/cartesapp) diff --git a/cartesi-rollups_versioned_docs/version-2.0/resources/integration-guides.md b/cartesi-rollups_versioned_docs/version-2.0/resources/integration-guides.md index 0229081b0..f70ab5915 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/resources/integration-guides.md +++ b/cartesi-rollups_versioned_docs/version-2.0/resources/integration-guides.md @@ -3,6 +3,8 @@ id: integration-guides title: Integrations guide --- + + Guides for integrating external protocols into your Cartesi application. Each integration offers a unique functionality to your application. ## Avail Integration diff --git a/cartesi-rollups_versioned_docs/version-2.0/resources/mainnet.md b/cartesi-rollups_versioned_docs/version-2.0/resources/mainnet.md index 2a5801d96..a7c8220b6 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/resources/mainnet.md +++ b/cartesi-rollups_versioned_docs/version-2.0/resources/mainnet.md @@ -6,6 +6,8 @@ resources: title: Honeypot dApp --- + + Cartesi Rollups are app-specific execution environments that can be deployed as L2, L3, or sovereign rollups. It's not your typical L1 blockchain, so the idea of a "Mainnet launch" is slightly different. What goes to mainnet are the dApps built using Cartesi! And with the launch of the Honeypot dApp, Cartesi Rollups is officially ready for mainnet! ## About Mainnet diff --git a/cartesi-rollups_versioned_docs/version-2.0/resources/migration-guide.md b/cartesi-rollups_versioned_docs/version-2.0/resources/migration-guide.md index fdb3ee4a6..c42c06d1b 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/resources/migration-guide.md +++ b/cartesi-rollups_versioned_docs/version-2.0/resources/migration-guide.md @@ -3,94 +3,432 @@ id: migration-guide title: Migration Guide --- + + ## Migrating from Cartesi Rollups v1.5.x to v2.0 -Rollups node v2.0 introduces some major changes in how the node works internally and how the application code interacts with it. Not all the breaking changes affect all applications. To identify which changes might affect your application, check if any of the following cases apply: +Rollups node v2.0 changes how the node works internally and how application code interacts with it. Not every breaking change affects every application. Use the checklist below, then follow the matching sections. -### My back-end... -- handles ERC-20 token deposit inputs. See the [ERC-20 token deposit inputs](#erc-20-token-deposit-inputs) section. -- handles application address relay inputs. See the Application address section. -- generates Ether withdrawal vouchers. See the Ether withdrawal vouchers section. +### If the application backend -### My front-end... -- validates notices. See the Outputs section. -- executes vouchers. See the Outputs section. -- listens to voucher execution events. See the Outputs section. -- checks if a voucher was executed. See the Outputs section. -- uses inspect calls. See the Inspect calls section. -- uses JSON-RPC queries. See the JSON queries section. +- Decodes ERC-20 deposit inputs. See [ERC-20 token deposit inputs](#erc-20-token-deposit-inputs). +- Handles `DAppAddressRelay` inputs. See [Application address](#application-address). +- Generates Ether withdrawal vouchers. See [Ether withdrawal vouchers](#ether-withdrawal-vouchers). +- Builds a Cartesi Machine image with `machine-emulator-tools`. See [Cartesi Machine image](#cartesi-machine-image). -:::note -If your application uses a high-level framework(ex. Deroll, Rollmelette etc.) for either backend or frontend, check if the framework has already implemented the changes described in this guide. +### If the application frontend + +- Queries the node GraphQL API. See [JSON-RPC queries](#json-rpc-queries). +- Validates notices. See [Outputs](#outputs). +- Executes vouchers. See [Outputs](#outputs). +- Listens to voucher execution events. See [Outputs](#execution-event). +- Checks if a voucher was executed. See [Outputs](#execution-check). +- Uses inspect `GET /inspect/`. See [Inspect calls](#inspect-calls). +- Uses `@cartesi/wagmi`, `@cartesi/viem`, or another TypeScript client. See [TypeScript applications](#typescript-applications). + +:::note High-level frameworks +If you use Deroll, python-cartesi, Cartesapp, or a similar framework, check whether it already implements these changes before rewriting backend or frontend code by hand. ::: -### ERC-20 token deposit inputs +--- + +## ERC-20 token deposit inputs In SDK v1, ERC-20 token deposit inputs start with a 1-byte Boolean field which indicates whether the transfer was successful or not: -#### 1. Define the environment variables +| Field | Type | Size | Description | +| :-------- | :-------- | :------- | :--------------------------------------- | +| `success` | `bool` | 1 byte | Whether the ERC-20 transfer succeeded | +| `token` | `address` | 20 bytes | Address of the ERC-20 token contract | +| `sender` | `address` | 20 bytes | Address of the depositor | +| `amount` | `uint256` | 32 bytes | Amount of tokens deposited | +| `data` | `bytes` | variable | Extra data passed by the depositor | + +In SDK v2, the ERC-20 portal only accepts successful transfers. Because `success` would always be `true`, it was removed. The deposit payload is: + +| Field | Type | Size | Description | +| :------- | :-------- | :------- | :----------------------------------- | +| `token` | `address` | 20 bytes | Address of the ERC-20 token contract | +| `sender` | `address` | 20 bytes | Address of the depositor | +| `amount` | `uint256` | 32 bytes | Amount of tokens deposited | +| `data` | `bytes` | variable | Extra data passed by the depositor | + +Update the back-end to stop reading or checking the leading `success` byte. See [asset handling](../development/asset-handling.md#abi-encoding-for-deposits). + +Sources: [rollups-contracts `InputEncoding`](https://github.com/cartesi/rollups-contracts/blob/main/contracts/common/InputEncoding.sol); [contracts.md](https://github.com/cartesi/rollups-contracts/blob/v2.0.1/docs/contracts.md). + +--- + +## Application address + +In SDK v1, the back-end had no direct way to know its own on-chain address. `DAppAddressRelay` relayed it as an input. The back-end detected inputs from that contract and stored the payload. That address was required to build Ether or ERC-721 withdrawal vouchers. + +```python +# v1 — detect and store the relayed application address +if msg_sender.lower() == dapp_relay_address.lower(): + rollup_address = payload +``` + +In SDK v2, `DAppAddressRelay` is removed. Every advance-state input includes the application address in metadata as `app_contract`: + +```javascript +// v2 — read the application address from input metadata +const dAppAddress = data["metadata"]["app_contract"]; +``` + +Remove any handling of `DAppAddressRelay` inputs. Use `data.metadata.app_contract` whenever a voucher needs the application contract address. + +--- + +## Ether withdrawal vouchers + +In SDK v1, withdrawing Ether was a two-step process: -- `SALT`: A random 32-byte value for the deterministic deployment functions. -- `RPC_URL`: The RPC endpoint to be used. -- `MNEMONIC`: The mnemonic phrase for the Authority owner's wallet (other wallet options may be used). -- `HISTORY_FACTORY_ADDRESS`: The address of a valid HistoryFactory instance. -- `AUTHORITY_ADDRESS`: The address of the Authority instance used by the application. +1. Relay the application address using `DAppAddressRelay`. +2. Emit a voucher that called `withdrawEther(address,uint256)` on the `CartesiDApp` contract, with destination set to the application itself. - :::note environment variables - A `HistoryFactory` is deployed at `0x1f158b5320BBf677FdA89F9a438df99BbE560A26` for all supported networks, including Ethereum, Optimism, Arbitrum, Base, and their respective Sepolia-based testnets. - ::: +```javascript +// v1 — Ether withdrawal voucher +const call = encodeFunctionData({ + abi: CartesiDAppAbi, + functionName: "withdrawEther", + args: [receiver, amount], +}); -#### 2. Instantiate a New _History_ +const voucher = { + destination: applicationAddress, + payload: call, +}; +``` + +In SDK v2, `withdrawEther` is gone. Ether withdrawal vouchers send wei directly: the application contract `safeCall`s `destination` with `value`. -This is a two-step process. First calculate the address of the new History. After that, the new instance of History may be created. +- Set `destination` to the recipient. +- Set `payload` to empty (`zeroHash` / `0x`). +- Set `value` to the Wei amount as a 32-byte big-endian hex string **without** the `0x` prefix. -- To calculate the address of a new _History_ contract call the `calculateHistoryAddress(address,bytes32)(address)` function with the help of Foundry's Cast: +```javascript +// v2 — Ether withdrawal voucher +import { numberToHex, parseEther, zeroHash } from "viem"; - ```shell - cast call \ - --trace --verbose \ - $HISTORY_FACTORY_ADDRESS \ - "calculateHistoryAddress(address,bytes32)(address)" \ - $AUTHORITY_ADDRESS \ - $SALT \ - --rpc-url "$RPC_URL" - ``` +const voucher = { + destination: receiver, + payload: zeroHash, + value: numberToHex(BigInt(parseEther("1"))).slice(2), +}; +``` - If the command executes successfully, it will display the address of the new History contract. Store this address in the environment variable `NEW_HISTORY_ADDRESS` for later use. +See [asset handling](../development/asset-handling.md#withdrawing-tokens) and the [ether wallet tutorial](../tutorials/ether-wallet.md). -- Create a new instance of _History_ may be created by calling function `newHistory(address,bytes32)`: +--- - ```shell - cast send \ - --json \ - --mnemonic "$MNEMONIC" \ - $HISTORY_FACTORY_ADDRESS \ - "newHistory(address,bytes32)(History)" \ - $AUTHORITY_ADDRESS \ - $SALT \ - --rpc-url "$RPC_URL" - ``` +## Cartesi Machine image - The `cast send` command will fail if Cast does not recognize the _History_ type during execution. In such cases, replace _History_ with `address` as the return type for `newHistory()` and execute the command again. +The application still runs inside a Cartesi Machine. The guest-tools package that provides the rollup HTTP loop was renamed and versioned independently of the node. -The `cast send` command may also fail due to gas estimation issues. To circumvent this, provide gas constraints with the `--gas-limit` parameter (e.g., `--gas-limit 7000000`). +| | v1.5 | v2.0-alpha | +| :-- | :-- | :-- | +| Guest tools | `machine-emulator-tools` (typically `0.14.1`) | `machine-guest-tools` (typically `0.17.2` with node `alpha.12`) | +| Typical base | Ubuntu Jammy RISC-V images | Ubuntu Noble RISC-V images | +| Node emulator (released) | Emulator SDK 0.17.x | Emulator `v0.20.0` ([rollups-node#720](https://github.com/cartesi/rollups-node/pull/720)) | -#### 3. Replace the _History_ +The machine snapshot (template hash) must match the hash registered with the application contract and the node. Rebuilding against a different emulator or guest-tools version produces a different hash. -Ensure the environment variables from the previous step are set, including `NEW_HISTORY_ADDRESS`, which should have the address of the new History. +### Building for SDK 2.0 -To replace the _History_ used by the _Authority_, run this command: +Do not retrofit a v1.5 Dockerfile. Start the application from scratch with **Cartesi CLI 2.0** (currently alpha) and the **prerelease application templates**. Those templates are the source of truth for the v2 image layout. ```shell -cast send \ - --json \ - --mnemonic "$MNEMONIC" \ - "$AUTHORITY_ADDRESS" \ - "setHistory(address)" \ - "$NEW_HISTORY_ADDRESS" \ - --rpc-url "$RPC_URL" +cartesi create my-dapp --template javascript --branch prerelease/sdk-12 +``` + +`--branch` selects a branch of [cartesi/application-templates](https://github.com/cartesi/application-templates/tree/prerelease/sdk-12). `prerelease/sdk-12` is the CLI 2.0 default. Then port application logic into the new project and run `cartesi build`. + +:::caution Next emulator line +[`rollups-node#791`](https://github.com/cartesi/rollups-node/pull/791) (merged, **not in a node release yet**) bumps the node to machine-emulator `v0.21.0` and machine-guest-tools `v0.18.0`. After that ships, rebuild the image with matching guest tools before registering it. +::: + +--- + +## Outputs + +In SDK v1, the only verifiable outputs were notices and vouchers. Each type lived in a separate buffer inside the machine and in a separate Merkle tree in the proof. Adding or changing output types cascaded through the whole SDK. + +In SDK v2, notices and vouchers share one buffer and one proof tree (**output unification**). An output is an arbitrary byte array encoded as a Solidity function call, so the type is the function selector. Any output can be validated, not only notices. A new executable type, the **DELEGATECALL voucher**, was added. + +The `Application` contract API changed accordingly. The following subsections match the [rollups-contracts v1→v2 wiki](https://github.com/cartesi/rollups-contracts/wiki/Migration-Guide-(v1%E2%86%92v2)#outputs). + +| Action | v1 | v2 | +| :----- | :-- | :-- | +| Validate | `validateNotice(bytes notice, Proof proof)` | `validateOutput(bytes output, OutputValidityProof proof)` | +| Execute | `executeVoucher(address destination, bytes payload, Proof proof)` | `executeOutput(bytes output, OutputValidityProof proof)` | +| Execution check | `wasVoucherExecuted(uint256 inputIndex, uint256 outputIndex)` | `wasOutputExecuted(uint256 outputIndex)` | +| Execution event | `VoucherExecuted(uint256 voucherId)` | `OutputExecuted(uint64 outputIndex, bytes output)` | + +On contracts v3, do not treat a voucher as executable until the epoch status is `CLAIM_ACCEPTED`. `CLAIM_SUBMITTED` and `CLAIM_STAGED` are not enough. See [`rollups-contracts#514`](https://github.com/cartesi/rollups-contracts/pull/514) and [`rollups-node#779`](https://github.com/cartesi/rollups-node/pull/779). + +### Encoding + +Outputs are ABI-encoded Solidity function calls. Supported signatures are on the [`Outputs` interface](https://github.com/cartesi/rollups-contracts/blob/v2.0.1/src/common/Outputs.sol). Decode them with any Ethereum ABI library (for example viem). Selectors: + +| Selector | Kind | Encoded as | +| :------------ | :---------- | :-- | +| `0xc258d6e5` | Notice | `Notice(bytes payload)` | +| `0x237a816f` | Voucher (`CALL`) | `Voucher(address destination, uint256 value, bytes payload)` | +| `0x10321e8b` | DelegateCall voucher | `DelegateCallVoucher(address destination, bytes payload)` | + +The JSON-RPC `raw_data` field is this encoded blob. Pass it as `output` to `validateOutput` and `executeOutput`. `decoded_data.type` on the node is the same selector. + +The `value` field on a `CALL` voucher is the Wei forwarded with the call. It is also how Ether withdrawals work, and it can fund payable functions. + +### Proofs + +The proof type changed. Application code should use the proof the node returns with the output, not construct one. + +SDK v1 used a nested `Proof` / `OutputValidityProof` with per-type epoch roots, input index within the epoch, and two sibling arrays: + +```solidity +struct Proof { + OutputValidityProof validity; + bytes context; +} + +struct OutputValidityProof { + uint64 inputIndexWithinEpoch; + uint64 outputIndexWithinInput; + bytes32 outputHashesRootHash; + bytes32 vouchersEpochRootHash; + bytes32 noticesEpochRootHash; + bytes32 machineStateHash; + bytes32[] outputHashInOutputHashesSiblings; + bytes32[] outputHashesInEpochSiblings; +} +``` + +SDK v2 uses a single, simpler structure. Outputs are identified by a global, ever-increasing `outputIndex` (they are not keyed by input index): + +```solidity +struct OutputValidityProof { + uint64 outputIndex; + bytes32[] outputHashesSiblings; +} +``` + +### Validation + +SDK v1 could validate only notices, and `validateNotice` returned `bool`: + +```solidity +function validateNotice( + bytes calldata notice, + Proof calldata proof +) external view returns (bool success); +``` + +SDK v2 validates any output. `output` is the Solidity-encoded function call. There is no Boolean return: the call succeeds or it reverts. + +```solidity +function validateOutput( + bytes calldata output, + OutputValidityProof calldata proof +) external view; +``` + +### Execution + +SDK v1 executed only `CALL` vouchers and returned `bool`: + +```solidity +function executeVoucher( + address destination, + bytes calldata payload, + Proof calldata proof +) external returns (bool success); ``` -In SDK v2, we modified the ERC-20 portal to only accept successful transactions. With this change, the success field would always be true, so it has been removed: +SDK v2 executes `CALL` and `DELEGATECALL` vouchers through one function. Again, `output` is the encoded function call, and the call reverts on failure instead of returning `false`. + +```solidity +function executeOutput( + bytes calldata output, + OutputValidityProof calldata proof +) external; +``` + +### Execution event + +SDK v1 emitted `VoucherExecuted` with an opaque `voucherId` (input index packed with output index within that input): + +```solidity +event VoucherExecuted(uint256 voucherId); +``` + +SDK v2 emits `OutputExecuted` with the global output index and the encoded output bytes: + +```solidity +event OutputExecuted(uint64 outputIndex, bytes output); +``` + +Update event listeners from `VoucherExecuted` to `OutputExecuted`. Index by `outputIndex`, not by `(inputIndex, outputIndexWithinInput)`. + +### Execution check + +SDK v1 required both the input index and the output index within that input: + +```solidity +function wasVoucherExecuted( + uint256 inputIndex, + uint256 outputIndexWithinInput +) external view returns (bool executed); +``` + +SDK v2 only needs the output index: + +```solidity +function wasOutputExecuted( + uint256 outputIndex +) external view returns (bool executed); +``` + +--- + +## JSON-RPC queries + +In SDK v1, notices, vouchers, and reports were queried through GraphQL at `/graphql`. + +```javascript +// v1 — query notices via GraphQL +const response = await fetch("http://localhost:8080/graphql", { + method: "POST", + headers: { "Content-Type": "application/json" }, + body: JSON.stringify({ + query: `{ notices { edges { node { index input { index } payload } } } }`, + }), +}); +``` + +In SDK v2, GraphQL is removed. POST JSON-RPC 2.0 to the node's **`/rpc`** path (not the node root). The host and port depend on how the node is exposed. + +```javascript +// v2 — list outputs (notices + vouchers) via JSON-RPC +const response = await fetch("http://localhost:10011/rpc", { + method: "POST", + headers: { "Content-Type": "application/json" }, + body: JSON.stringify({ + jsonrpc: "2.0", + method: "cartesi_listOutputs", + params: { application: "0xYourAppAddress", limit: 50, offset: 0 }, + id: 1, + }), +}); +const { result } = await response.json(); +``` + +```javascript +// v2 — get a specific output by index +await fetch("http://localhost:10011/rpc", { + method: "POST", + headers: { "Content-Type": "application/json" }, + body: JSON.stringify({ + jsonrpc: "2.0", + method: "cartesi_getOutput", + params: { application: "0xYourAppAddress", output_index: "0x0" }, + id: 1, + }), +}); +``` + +Each output has a `decoded_data.type` selector: + +| Type selector | Output kind | +| :------------ | :---------- | +| `0xc258d6e5` | Notice | +| `0x237a816f` | Voucher | +| `0x10321e8b` | DelegateCall Voucher | + +`raw_data` is the ABI-encoded bytes for `executeOutput()` / `validateOutput()`. + +Reports **are** on JSON-RPC (`cartesi_listReports`, `cartesi_getReport`). They are also returned inline on inspect responses. + +GraphQL → JSON-RPC map: + +| v1 GraphQL | v2 JSON-RPC | +| :-- | :-- | +| `notices` / `vouchers` | `cartesi_listOutputs` / `cartesi_getOutput` | +| `reports` | `cartesi_listReports` / `cartesi_getReport` | +| `inputs` | `cartesi_listInputs` / `cartesi_getInput` | +| — | `cartesi_listApplications` / `cartesi_getApplication` | +| — | `cartesi_listEpochs` / `cartesi_getEpoch` / `cartesi_getLastAcceptedEpochIndex` | +| — | `cartesi_getChainId` / `cartesi_getNodeVersion` | + +On node `v2.0.0-alpha.12` (contracts v3), also: + +| Method | Use | +| :-- | :-- | +| `cartesi_listWithdrawals` / `cartesi_getWithdrawal` | Emergency L1 withdrawals after foreclosure — **not** voucher withdrawals | +| `cartesi_listTournaments`, `cartesi_getTournament`, `cartesi_listMatches`, … | PRT / Dave data | + +`cartesi_getApplication` on contracts v3 returns `enabled` plus `status` (`OK`, `FAILED`, `INOPERABLE` / `DIVERGED` / `CORRUPTED`, `FORECLOSED`). Do not read a single `state: ENABLED` field from older examples. + +From [`rollups-node#789`](https://github.com/cartesi/rollups-node/pull/789) (merged after `alpha.12`): inputs are identified by `transaction_hash` + `log_index` (multiple `InputAdded` logs in one L1 transaction are distinct). `cartesi_listInputs` accepts `transaction_hash`. There is no `transaction_reference`. + +Unknown application errors use a dedicated JSON-RPC code ([`rollups-node#783`](https://github.com/cartesi/rollups-node/pull/783)). + +The node's EVM reader now **polls HTTP** for new blocks ([`rollups-node#781`](https://github.com/cartesi/rollups-node/pull/781)). A WebSocket blockchain endpoint is no longer required for the reader. + +:::caution Open JSON-RPC work +[`rollups-node#793`](https://github.com/cartesi/rollups-node/pull/793) (open) adds batch requests, index ranges, multi-status epoch filters, executed/pending output counts, `cartesi_getNodeInfo`, and renames `cartesi_getMatchAdvanced` → `cartesi_getMatchAdvance`. Do not treat those methods as released until that PR merges and a node alpha ships. +::: + +Full method list: [JSON-RPC methods](../api-reference/jsonrpc/methods.md). Spec source: [`internal/jsonrpc/jsonrpc-discover.json` on `next/2.0`](https://github.com/cartesi/rollups-node/blob/next/2.0/internal/jsonrpc/jsonrpc-discover.json). + +--- + +## Inspect calls + +In SDK v1, inspect was an HTTP GET with the payload in the URL path: + +```javascript +// v1 — inspect via GET +const response = await fetch( + `http://localhost:8080/inspect/${encodeURIComponent(payload)}` +); +``` + +In SDK v2, inspect is HTTP POST to `/inspect/` with the payload in the body. The application must be in the path because one node can host several apps. + +```javascript +// v2 — inspect via POST +const response = await fetch(`http://localhost:10012/inspect/0xYourAppAddress`, { + method: "POST", + headers: { "Content-Type": "application/json" }, + body: JSON.stringify(payload), +}); +const result = await response.json(); +``` + +The OpenAPI spec also accepts `application/octet-stream` for a binary body ([`api/openapi/inspect.yaml` on `next/2.0`](https://github.com/cartesi/rollups-node/blob/next/2.0/api/openapi/inspect.yaml)). + +The response is still a list of reports with hex payloads, plus `status`, `exception_payload`, and `processed_input_count`. + +Inspect is served from a temporary machine fork and is synchronous. It returns **503** when the machine is not ready, inspect capacity is exhausted, or the application was **foreclosed** (`Application was foreclosed; machine unavailable`). Body size is limited ([`rollups-node#761`](https://github.com/cartesi/rollups-node/pull/761)). + +--- + +## TypeScript applications + +v1.5 frontends typically called GraphQL directly. v2 TypeScript clients should use the packages in [cartesi/rollups-ts](https://github.com/cartesi/rollups-ts/tree/prerelease/v2-alpha) (`prerelease/v2-alpha`). They wrap the JSON-RPC node API, InputBox, and output execution. + +| Role | Earlier v2-alpha name | Current package | +| :-- | :-- | :-- | +| JSON-RPC typed client | `@cartesi/rpc` | [`@cartesi/rpc`](https://github.com/cartesi/rollups-ts/tree/prerelease/v2-alpha/packages/rpc) | +| viem L1 / node helpers | `@cartesi/viem` | [`@cartesi/client`](https://github.com/cartesi/rollups-ts/tree/prerelease/v2-alpha/packages/client) | +| React / wagmi hooks | `@cartesi/wagmi` | [`@cartesi/react`](https://github.com/cartesi/rollups-ts/tree/prerelease/v2-alpha/packages/react) | +| Input/output codec | — | [`@cartesi/codec`](https://github.com/cartesi/rollups-ts/tree/prerelease/v2-alpha/packages/codec) | + +Replace `@cartesi/viem` imports with `@cartesi/client` and `@cartesi/wagmi` with `@cartesi/react`. Pin explicit alpha versions; the `@alpha` npm tag can resolve to an older prerelease. + +:::note +See [rollups-ts#123](https://github.com/cartesi/rollups-ts/pull/123) and [#124](https://github.com/cartesi/rollups-ts/pull/124) for RPC type updates against the node API. Component layout for a React app is in the [React frontend tutorial](../tutorials/react-frontend-application.md); that page may still show the earlier package names. +::: -When the Cartesi Rollups Node restarts, it processes all existing inputs, recalculates the epochs, and sends the claims to the new _History_ based on the updated configuration. diff --git a/cartesi-rollups_versioned_docs/version-2.0/tutorials/calculator.md b/cartesi-rollups_versioned_docs/version-2.0/tutorials/calculator.md index 6927dac7d..412987ab0 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/tutorials/calculator.md +++ b/cartesi-rollups_versioned_docs/version-2.0/tutorials/calculator.md @@ -6,6 +6,8 @@ resources: title: Source code for the Calculator App --- + + In this tutorial, we will build a simple Calculator application to illustrate how requests are sent and processed within Cartesi Rollups Infrastructure. We provide JavaScript, Python, Rust, Go, and C++ implementations so you can use your preferred backend language. diff --git a/cartesi-rollups_versioned_docs/version-2.0/tutorials/counter.md b/cartesi-rollups_versioned_docs/version-2.0/tutorials/counter.md index 1d7327e4b..b03386393 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/tutorials/counter.md +++ b/cartesi-rollups_versioned_docs/version-2.0/tutorials/counter.md @@ -6,6 +6,8 @@ resources: title: Source code for the Counter Application --- + + This tutorial aims to guide you through creating and interacting with a basic Cartesi application, it'll take you through setting up your dev environment, creating a project then finally running and interacting with your application locally. We provide Rust, JavaScript, Python, Go, and C++ implementations of the application, so you can choose whichever language you're more comfortable with. diff --git a/cartesi-rollups_versioned_docs/version-2.0/tutorials/erc-1155-token-wallet.md b/cartesi-rollups_versioned_docs/version-2.0/tutorials/erc-1155-token-wallet.md index db012be56..faf72a2ca 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/tutorials/erc-1155-token-wallet.md +++ b/cartesi-rollups_versioned_docs/version-2.0/tutorials/erc-1155-token-wallet.md @@ -3,6 +3,8 @@ id: erc-1155-token-wallet title: Integrating ERC1155 token wallet functionality --- + + This tutorial guides you through building an ERC-1155 token wallet for a Cartesi backend application using TypeScript. It covers **single** and **batch** deposits from the base layer, internal balance tracking, transfers, and withdrawals for both modes. ## Setting up the project diff --git a/cartesi-rollups_versioned_docs/version-2.0/tutorials/erc-20-token-wallet.md b/cartesi-rollups_versioned_docs/version-2.0/tutorials/erc-20-token-wallet.md index 7d6c1c84f..b21f4e91d 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/tutorials/erc-20-token-wallet.md +++ b/cartesi-rollups_versioned_docs/version-2.0/tutorials/erc-20-token-wallet.md @@ -3,6 +3,8 @@ id: erc-20-token-wallet title: Integrating ERC20 token wallet functionality --- + + This tutorial will guide you through creating a basic ERC20 token wallet for a Cartesi backend application using TypeScript. ## Setting up the project diff --git a/cartesi-rollups_versioned_docs/version-2.0/tutorials/erc-721-token-wallet.md b/cartesi-rollups_versioned_docs/version-2.0/tutorials/erc-721-token-wallet.md index 0c0c85308..0267195ba 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/tutorials/erc-721-token-wallet.md +++ b/cartesi-rollups_versioned_docs/version-2.0/tutorials/erc-721-token-wallet.md @@ -3,6 +3,8 @@ id: erc-721-token-wallet title: Integrating ERC721 token wallet functionality --- + + This tutorial will guide you through creating a basic ERC721(NFT) token wallet using TypeScript for a Cartesi backend application. ## Setting up the project diff --git a/cartesi-rollups_versioned_docs/version-2.0/tutorials/ether-wallet.md b/cartesi-rollups_versioned_docs/version-2.0/tutorials/ether-wallet.md index 6df01a44f..19bf0dff6 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/tutorials/ether-wallet.md +++ b/cartesi-rollups_versioned_docs/version-2.0/tutorials/ether-wallet.md @@ -3,6 +3,8 @@ id: ether-wallet title: Integrating Ether wallet functionality --- + + This tutorial will build a basic Ether wallet inside a Cartesi backend application using TypeScript. The goal is to have a backend application to track balances and receive, transfer, and withdraw Ether. diff --git a/cartesi-rollups_versioned_docs/version-2.0/tutorials/marketplace.md b/cartesi-rollups_versioned_docs/version-2.0/tutorials/marketplace.md index 7b08cfc9d..1e8e39ccd 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/tutorials/marketplace.md +++ b/cartesi-rollups_versioned_docs/version-2.0/tutorials/marketplace.md @@ -6,6 +6,8 @@ resources: title: Source code for the Marketplace Application --- + + In this tutorial we'll be building a simple NFT Marketplace application, where users are able to deposit a unique token to be sold at a fixed price, then other users are able to purchase and withdraw these purchased tokens to their wallet. This Tutorial is built using an Object oriented approach and aims to cover, application creation, Notice, Voucher and Report generation, we'll also be decoding and consuming the payload passed alongside advance and inspect requests. diff --git a/cartesi-rollups_versioned_docs/version-2.0/tutorials/react-frontend-application.md b/cartesi-rollups_versioned_docs/version-2.0/tutorials/react-frontend-application.md index 4d59c61e5..b1c978d79 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/tutorials/react-frontend-application.md +++ b/cartesi-rollups_versioned_docs/version-2.0/tutorials/react-frontend-application.md @@ -6,6 +6,8 @@ resources: title: Source code for the frontend application --- + + # Building a React Frontend for Cartesi Apps This is a comprehensive guide for building a React frontend that interacts with the deployed Cartesi applications using Cartesi TypeScript packages, wagmi hooks and viem library. diff --git a/cartesi-rollups_versioned_docs/version-2.0/tutorials/running-applications-on-a-forked-network.md b/cartesi-rollups_versioned_docs/version-2.0/tutorials/running-applications-on-a-forked-network.md index c942c6b74..0b5dc8b83 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/tutorials/running-applications-on-a-forked-network.md +++ b/cartesi-rollups_versioned_docs/version-2.0/tutorials/running-applications-on-a-forked-network.md @@ -4,6 +4,8 @@ title: Running applications on a forked network resources: --- + + ## Introduction When building Cartesi applications, it is often necessary to interact with contracts and services that are already deployed on a live blockchain network. While a local clean chain is useful during early development, it does not always reflect real world conditions. diff --git a/cartesi-rollups_versioned_docs/version-2.0/tutorials/utilizing-the-cli-AA-feature.md b/cartesi-rollups_versioned_docs/version-2.0/tutorials/utilizing-the-cli-AA-feature.md index 90add2236..7fb2e91ab 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/tutorials/utilizing-the-cli-AA-feature.md +++ b/cartesi-rollups_versioned_docs/version-2.0/tutorials/utilizing-the-cli-AA-feature.md @@ -9,6 +9,8 @@ resources: title: Account Abstraction Script demo --- + + This tutorial will guide you through utilizing the account abstraction (AA) feature of the CLI to interact with your application while testing locally. ## Introduction diff --git a/cartesi-rollups_versioned_docs/version-2.0/tutorials/utilizing-the-cli-test-tokens.md b/cartesi-rollups_versioned_docs/version-2.0/tutorials/utilizing-the-cli-test-tokens.md index a4be57d09..b360c8347 100644 --- a/cartesi-rollups_versioned_docs/version-2.0/tutorials/utilizing-the-cli-test-tokens.md +++ b/cartesi-rollups_versioned_docs/version-2.0/tutorials/utilizing-the-cli-test-tokens.md @@ -4,6 +4,8 @@ title: Utilizing test tokens in dev environment resources: --- + + ## Introduction The **Cartesi CLI** is one of the most important tools for developing applications with Cartesi. It provides a wide range of functionalities that simplify and automate the process of setting up, deploying, and interacting with your applications. diff --git a/cartesi-rollups_versioned_sidebars/version-2.0-sidebars.json b/cartesi-rollups_versioned_sidebars/version-2.0-sidebars.json index 6d50904f8..a70320c08 100644 --- a/cartesi-rollups_versioned_sidebars/version-2.0-sidebars.json +++ b/cartesi-rollups_versioned_sidebars/version-2.0-sidebars.json @@ -248,8 +248,7 @@ "items": [ "resources/community-tools", "resources/mainnet-considerations", - "resources/migration-guide", - "resources/integration-guides" + "resources/migration-guide" ] }, {