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:
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!
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:
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:
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.
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.
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.
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.
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.
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.
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.
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.
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:
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:
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:
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:
So there you have it! With Cartesi, the daunting part is already done, freeing you up to focus on your unique code.
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!
Join our newsletter to stay up to date on features and releases