9 docs tagged with "learn"

Assets exist on the base layer, which is where they have actual meaning and value. As with any execution layer solution, a Cartesi dApp that wants to manipulate assets (e.g. to allow players to bet on a game, so that the winner receives the loser's assets) needs a secure way of "teleporting" the assets from the base layer to the execution layer, and then a way to "teleport" them back to the base layer.

This guide is designed to highlight the key distinctions between v0.8 and v0.9, offering assistance to those transitioning an existing application or individuals already acquainted with v0.8 who require a concise overview.

Borrowing from familiar mainstream terminology, from a developer’s point of view a Cartesi dApp is developed by implementing two main components: a front-end and a back-end.

Now that we have described the architecture of a Cartesi dApp and how the front-end and back-end communicate with the Cartesi Rollups framework, let’s step back a bit to discuss how a dApp can be implemented in practice.

As explained in the previous section, the Cartesi Rollups framework achieves scalability by moving the bulk of the computation outside the blockchain, using the ledger as a data source but not as an execution environment. As such, the solution contains both on-chain (L1) and off-chain (L2) components.

In a Cartesi dApp, the front-end and back-end parts of the application communicate with each other through the Rollups framework via a set of HTTP APIs.

The combination of an Optimistic Rollups framework and the Cartesi Machine Emulator enables the development of smart contracts and dApps using any package or library that is available for Linux. This allows developers to break free from the scalability limitations of the Ethereum Virtual Machine (EVM), and brings the rise of a new blockchain era to handle real-life and complex use cases.

In Cartesi Rollups, the outputs include:

In Cartesi Rollups, there are two kinds of requests that can be made to the dApp: