A deep dive into Honeypot, an optimistic rollup application.

Tech/Oct 4, 2023/FELIPE ARGENTO

Welcome to Honeypot, a challenge that encapsulates the concept of an optimistic, application-specific rollup.

In technical terms, this means that Honeypot runs on a dedicated rollup infrastructure designed for a single decentralized application. It doesn’t compete for blockspace with other dApps, and it has the freedom for full customization. Honeypot is important because it heralds the mainnet readiness of Cartesi Rollups, indicating that the entire infrastructure is geared up to support the creation of more application-specific rollups. More than a hacking challenge, it’s an event that paves the way for a new era of specialized blockchain applications. Beyond its playful facade, Honeypot fulfills critical roles:

It serves as a thrilling arena for hackers and developers to flex their skills and attempt to break the system.
It provides a financial benchmark for gauging the safe limit of assets that can be stored under this new infrastructure.
It functions as an open-source bug-hunting campaign, inviting the wider Cartesi project community to test, scrutinize, and refine the underlying code.

In this article, we will dive deeper into the nuts and bolts supporting this innovative application, examine the code that makes it tick, and unpack the trust assumptions involved in its infrastructure. So, buckle up for an exciting journey into this pot of honey!

Data availability, state root commitments and assets

When it comes to comfortably interacting with a rollup, it's essential to grasp the finer details, including data availability, state root commitments, and the location and control of assets. To clarify, let's address these questions:

How is data stored, and how can its availability be assured when it's most needed?
Where are the assets located, and who has the ability to control them?
Where and when are state root commitments posted, and what state are they referring to?

Remember, when discussing application-specific rollups, applications using the same rollup infrastructure might have different answers to these questions. For instance, Cartesi-based applications might store their data on Ethereum but post their state root commitments on Optimism, or they might ensure data availability on Syscoin while keeping their assets on Ethereum.

But let's focus on the Honeypot dApp, bearing in mind that these configurations are decisions made by the developers of that specific application. The Honeypot dApp is a bona fide Ethereum Layer 2 application. The creators opted to use Ethereum as the solution for all the above concerns. So, to answer the questions above:

All data interacting with the Honeypot dApp originates from standard Ethereum transactions, sent to a contract that we'll delve into in the "Infrastructure / SDK code" section. While inputs arrive as call data, they are actually stored as hashes in the blockchain, thereby allowing for potential disputes in the future.
All assets under Honeypot's control arrive and remain on Ethereum, facilitated through the use of Portals, which we will also explain in the following section.
As for the state root commitments? You guessed it - they're posted on Ethereum too. The validator chosen during the Honeypot's deployment is tasked with doing this periodically. These commitments, or claims, are composed of three elements:

The full state of the dApp machine after all inputs to be taken into account have been processed.
A set of vouchers which permits executing a call on the underlying blockchain (in this case, Ethereum). Example of a voucher: adding liquidity to a Uniswap pool
A set of notices, which are statements that the Honeypot dApp has made and can be proven on-chain. Example of a notice: a summary of all the dApp's financial positions after its last allocation.

In the context of the Honeypot dApp, successful hacking means either deceiving the dApp into creating a voucher that enables asset theft or executing a voucher that the dApp didn't create. We will discuss vouchers, state commitments, and other relevant topics in more depth in the upcoming sections.

Validation, Upgradeability and Dispute Resolution

Understanding the intricacies of validation is also a crucial aspect of engaging with a rollup. One can consider application chains (appchains) as effective means of maximizing the potency of a 1-of-N trust assumption. Essentially, this trust assumption denotes the reliance on at least one honest validator (potentially the user themself) to ensure the correct execution of a dApp, enabled by the dispute resolution protocol.

Cartesi Compute, previously referred to as Descartes operates a functioning two-party arbitration system. A recent academic paper published by members of the research unit, elaborates on the concept of converting this arbitration system into a permissionless (nxn) setup, resistant to delay attacks. Harnessing this innovation to craft a working dispute resolution mechanism, as opposed to tailoring the Compute system to function within rollups, is an open problem that is being tackled by different ecosystem contributors.

Now, considering the Honeypot application, the launch has been initiated under an Authority Validator regime, prior to the establishment of the dispute resolution mechanism. In this setup, a single address maintains the exclusive authority to determine truth. Though anyone can operate the Honeypot dApp and check the validator's honesty, there is no established method yet to combat potential misconduct except for expressing dissent. Therefore, participating in the game, as it stands now, necessitates placing trust in the authority to follow protocol and operate with integrity.

When it comes to upgradeability, this aspect is less problematic for application-specific rollups compared to shared EVM rollups. The Cartesi Rollups Software Development Kit (SDK) allows applications to select who possesses upgrade rights (which could even be the application itself). In the case of Honeypot, the developers chose a non-upgradeable approach, ensuring that the deployed version remains immutable.

Infrastructure / SDK code

Delving into the specifics of creating an application-specific rollup might initially seem like a daunting task, considering the perceived need to code everything from scratch for each launch. However, as we've hinted at throughout this article, that's precisely the challenge that Cartesi Rollups SDK mitigates.

Building an application-specific rollup using Cartesi involves two types of code: general, reusable, and shared code; and application-specific code. This effective balance allows developers to reap the benefits of shared functionality while customizing aspects unique to their application.

In this section, we'll strive to outline the critical components and reference the code addressing topics we've discussed earlier. Although it's not feasible to cover everything in detail here, a wealth of information is available in the comprehensive documentation and README files for those interested in delving deeper.

The shared infrastructure comprises three primary components that interact with one another: onchain code, the Cartesi node, and the Cartesi machine. Each plays a crucial role in the functioning and efficiency of the rollup application. As we explore further, we'll shed light on how these components work together to facilitate the seamless operation of the Honeypot dApp.

Onchain:

The onchain code serves as a crucial intermediary between off-chain components, such as the node and Cartesi machine, and other smart contracts or externally owned accounts. This component is designed in a modular format, each with clear responsibilities and well-defined interfaces. For a comprehensive understanding, we encourage you to explore the README and the smart contracts in this repository here.

For Data Availability: the Input Box Contract

Central to data availability is the Input Box contract. This module is entrusted with receiving user inputs intending to interact with dApps. For each dApp, the module maintains an append-only list of hashes derived from the input and associated metadata, like the sender's input and the block timestamp. All the data needed to reconstruct a hash is perpetually available on-chain, ensuring that users can sync the off-chain machine with the latest input without reliance on data providers. This module is completely permissionless, leaving the off-chain machine to determine the input's validity. For further details, consider exploring the code for the Input Box on GitHub or on Sepolia Etherscan.

For State Root Commitments: Consensus Interface and Authority Contract

The Consensus interface and the Authority contract are necessary to understand State Root commitments. This module's primary role is to provide valid claims to dApps after achieving consensus. The module's interface is intentionally generic to cater to various consensus models. The manner in which claims are encoded and stored is abstracted entirely by the interface, while the History contract is responsible for the implementation. Currently, Cartesi only implements a consensus type called Authority, which is owned by a single address wielding complete power over the consensus. It is the simplest possible implementation and as such it is of course very limited in its features.. The code is available on the repository or verified on the Sepolia testnet.

Output Validation and Cartesi dApp

The Output Validation library and the Cartesi dApp code itself are critical to understanding the consequences of commitment. Finding a bug here might open a path to stealing the honey.

Vouchers play a significant role, permitting dApps in the execution layer to interact with contracts in the base layer via message calls. Each voucher consists of a destination address and a payload. A voucher can only be executed once the dApp's consensus submits a claim containing it. They can be executed in any order, and although the DApp contract is indifferent to the voucher's content being executed, it enforces sanity checks before allowing its execution.

Asset Management: The Portals

When it comes to asset management, one should examine Portals. As the name suggests, Portals facilitate the secure teleportation of assets from the base layer to the execution layer. The assets pass through the portal for verification but are actually stored in the dApp contract. The dApp developer is at liberty to utilize this information as they see fit, potentially creating a wallet for each user in the execution layer where assets can be managed at significantly lower cost through inputs understood by the application-specific logic.

Honeypot Deployment Information

The code to consult when deploying the honeypot application, choosing the validator address, and defining if it is upgradeable or not, is the Cartesi dApp factory. You can find the details here.

You can access all of the code in the GitHub repository, and for verified contracts on Etherscan, you may refer to the deployment files:

Cartesi Node:

Navigating the world of application-specific rollups necessitates a bridge between the distinct environments of smart contracts and the computational framework of Cartesi Machines. This bridge comes in the form of a middleware that deftly handles the flow of information between these environments. This middleware is tasked with consuming data from smart contracts, relaying it to the machine for processing, and finally, broadcasting the results back onto the blockchain.

Think of the middleware as an interpreter in a conversation between two parties speaking different languages. It translates the output of one side into a format that the other can understand and vice versa. This middleware, coupled with the Cartesi Machine, forms the basis of what we refer to as the Cartesi Node.

Whether you're interested in the state of rollups or you're actively engaged in the landscape, the Cartesi Node plays an indispensable role akin to that of Geth within the Ethereum ecosystem. It embodies a blend of execution and data retrieval functions. The Cartesi Node advances the off-chain machine's state and makes the resulting state publicly available. It consumes information from the blockchain and enforces state updates, maintaining the on-chain state updates' integrity. Using the always insightful Patrick McCorry's terminology, the Cartesi Node plays the executor role.

In essence, whether you're a user simply tracking the state of rollups or a validator ensuring the veracity of state updates, the Cartesi Node serves as your comprehensive window into the world of application-specific rollups. It takes care of complex interactions, enabling you to concentrate on your specific interests or responsibilities.

Checkout the code:

https://github.com/cartesi/rollups/tree/v0.9.0/offchain

Cartesi Machine:

Unarguably, the Cartesi Machine holds a pivotal position within the Cartesi ecosystem, offering an innovative solution for verifiable computation. This technology paves the way for dApps to scale in a way akin to mainstream applications, and augments the capabilities of dApp developers.

Key attributes of the Cartesi Machine include self-containment, reproducibility, and transparency. They operate in isolation, free from external influences; any computation performed on a Cartesi Machine will yield identical results, regardless of who performs it; moreover, they expose their full state for external scrutiny.

Modern software development typically involves merging a variety of pre-existing software components. These components, developed and vetted over several decades by a global community, use established toolchains and rely on a host of services offered by modern operating systems.

However, smart contracts are often developed using specialized toolchains and operate directly atop custom virtual machines without an underlying operating system. This setup deprives developers of familiar and effective tools, severely curtails their expressive power, and therefore drastically impedes productivity.

This is where Cartesi Machines, built on the time-tested RISC-V platform, stand out. The RISC-V platform enjoys the support of a robust community of developers, who have fostered an expansive software infrastructure, including ports of the Linux Operating System and the GNU toolchain.

By shifting key parts of dApp logic to run inside Cartesi Machines and atop the Linux Operating System, developers can bypass the constraints and peculiarities of specific blockchains as well as avoid unnecessary details of the Cartesi Machine architecture. They regain access to the familiar tools essential for their craft.

In essence, Cartesi's ambition is to empower dApp developers to unleash their creativity without hindrance and to significantly increase their productivity. This is the essence of the Cartesi Machine. And this is where the Honeypot dApp runs.

Checkout the code:

https://github.com/cartesi/machine-emulator

Application-specific code

Admittedly, the previous section was very long and in-depth. But guess what? This section is going to be short and sweet. Why? Because we've already done the heavy lifting in the previous sections.

Honeypot's behavior is all neatly packed into a single C++ file, right here: honeypot.cpp. If you want to understand better how the framework works, see our documentation here.

If you're thinking, "Hold on a sec, that's a lot of code for a simple honeypot!" - you're not wrong. But let me drop some perspective. This is the first-of-its-kind application cooking up on the Cartesi Infrastructure! The current length of the honeypot code is because we're at the early stage of the development cycle. Once we've got things like a C++ wallet library that sweeps away portal interactions and voucher withdrawals, future honeypot codes will be just a few quick lines.

For more detailed insights into the honeypot application, including its functionalities and deployment procedures, I highly recommend taking a look at the repository's comprehensive README. Not only does it describe the inner workings of the dApp, it also offers a step-by-step guide on how to launch your own honeypot:

https://github.com/cartesi/honeypot

So there you have it! With Cartesi, the daunting part is already done, freeing you up to focus on your unique code.

How to contribute and stay in the loop

At Cartesi we believe in the power of collective minds, in transparency and in lively discussions. And that's exactly what you'll find in our Discord Channel - a diverse mix of contributors brainstorming, troubleshooting, and shaping the future of Cartesi. Our communication, development and research are all done publicly there. Plus, we've got folks eager to answer your questions and delve into debates about every piece of the architecture discussed in this article.

So, feel like jumping into engaging conversations, sharing your thoughts, or maybe even asking that question that's been on your mind? Come on over! Join the Cartesi Discord Channel. And if you haven’t yet, take a shot at Honeypot!