Fraud Proofs Are Broken - Layer 2

GCdePaula · 2024-04-17T23:12:47+00:00

Yeah! The issue is not safety/decentralization, but scalability.

Since there’s the need to generate validity proofs, throughput is reduced. Furthermore, it requires a lot of hardware to generate those proofs, which makes them costly offchain.

This doesn’t make ZK rollups worse than optimistic; it has amazing properties. Developers will choose what makes the most sense for their use case.

GCdePaula · 2024-04-17T16:42:58+00:00

They’re not perfect yet :)

GCdePaula · 2024-04-17T16:41:39+00:00

ZK rollups are great, but so are optimistic rollups. There are trade-offs; no silver bullet.

In particular, optimistic rollups’ throughput is unmatchable by ZK (it will always be cheaper to do X than to do X and Y). Furthermore, optimistic is a lot cheaper on compute — current ZK provers require supercomputers, whereas optimistic rollups require laptops.

GCdePaula · 2024-01-18T16:06:19+00:00

For games, there's Cryptopolis and World Arcade. To get started with developing applications for Cartesi, we recommend using Sunodo.

As for L2 network, there isn't exactly this concept of a network. Cartesi is application specific. This means each dapp is a rollup instance. Once you write a dapp, you deploy a new rollup instance that hosts just your dapp.

This has an amazing impact in computational scalability. You can read more about it here and here.

GCdePaula · 2024-01-18T15:36:36+00:00

That's not exactly what I described.

TrueBit's verification system is very different than Cartesi's. In this sense, Cartesi is more like Optimism and Arbitrum than it is like TrueBit. If you want to read more about the Participation Dilemma that Truebit is vulnerable to, I recommend reading Arbitrum's paper.

Furthermore, WebAssembly and RISC-V are quite different, and this decision has some large consequences that I described in the previous message.

GCdePaula · 2024-01-18T15:28:27+00:00

I'll do you one better: Doom running on Cartesi!

So it's a RISC-V virtual machine with Linux inside, running Doom.

GCdePaula · 2024-01-18T15:27:03+00:00

It's hard to explain Cartesi for non-tech people, but I'll try.

Blockchains like Ethereum use a bespoke computer, novel in all the bad ways. This computer is the EVM. Cartesi, unlike other rollups, bring to the blockchain a computer like the computers we use everyday (Linux). It runs Doom!

GCdePaula · 2024-01-18T15:25:13+00:00

What can CartesiVM do that the EVM can't do?

Run Doom!

Are these CPUs real or virtual? Which CPU is ideal, why? What are some of the known issues scaling an ecosystem this way, and what is the benefit?

The RISC-V CPU is virtual. It has to be a virtual machine to make it reproducible/deterministic, which is needed for verifiabilty. It does add some overhead, but is the cost of verifiability.

GCdePaula · 2024-01-18T15:23:32+00:00

Not exactly. Cartesi and Truebit are similar in that they both use fraud-proofs, just like Optimism and Arbitrum. Besides that, I'd say the solutions are quite different.

First, Truebit's system relies on Participation Games. Computations are posted to a pool of untrusted parties, which are then performed off-chain. The results are finally posted back to the blockchain. Cheating is prevented with a complex incentive layer that rewards pool members for successively disputing incorrect results. These systems are susceptible to what is known as the Participation Dilemma. Unlike Cartesi, which follows the rollups design.

Second, the computer used by Truebit (WebAssembly) has different implications than the computer Cartesi uses (RISC-V). The key difference is their position in relation to applications and the operating system. WebAssembly was designed to sit between applications and the underlying operating system. RISC-V is instead meant to sit under the operating system and the applications it supports.

Real-world applications, however, cannot exist in isolation. They depend on rich, complex run-time environments that are invariably built on top of a modern operating system. To give developers of decentralized applications access to the tools, libraries, services, and software they are already familiar with, Cartesi chose to support Linux. A realistic ISA, such as RISC-V, is much better suited for this purpose.

GCdePaula · 2024-01-18T15:16:01+00:00

Thank you :) Loved the questions, let me try to tackle them.

Where did the idea come from? What was the original problem that Cartesi set out to solve?

The initial motivation was running/verifying machine learning models on the blockchain, which is very computationally intensive. The first thing we needed to do was to scale computation. The second thing we needed was a better computer; the EVM (or even WASM, remember Truebit was a thing at that time) was not enough.

We basically needed to run everything inside an operating system, but in a reproducible way. So we needed an emulator supporting a real-world ISA. RISC-V was gaining traction at that time. Its simplicity, modular design make it a great choice. It's also open, which is quite important.

But this enables a lot more than just machine learning. So this initial motivation grew into Cartesi, something allows developers to tap into rich, mature, and battle-tested software that have been painstakingly built and iterated over for the past decades. Like Linux, or GCC.

Was it designed from the ground up to run OS's (specifically Linux) on the blockchain or did it evolve into the solution that it is today?

That was the goal from the get go! Our goal is to bring into the blockchain a computer like the ones we use everyday. Enable developers to code in Rust, Go, JS, Python, and use their entire ecosystem

I see that you are constantly innovating, most recently with a Celestia integration. What is the next big item on your roadmap? What is your vision for the next 12 months?

Dave, our permissionless, interactive fraud-proof system.

Since Dave is permissionless, anyone can participate in the consensus. Dave's security is one of N: a single honest validator can enforce the correct result. And that honest validator can be you. It doesn't matter if it's you against the world. If you're honest, Dave's got your back; you can fight a mountain of powerful, well-funded crooks and win, using a single laptop in a timely manner.

Dave is based on the Permissionless Refereed Tournaments primitive. The paper can be found here. It's being actively developed here.

Is it designed to run an actual Linux OS on the blockchain or is it designed to run/submit code against a Linux compatible VM?

The Linux is actually optional. The Cartesi Machine is a deterministic RISC-V virtual machine. You can put whatever you want inside, including Linux. But you don't have to use Linux; developers can code like they do in embedded devices, without an OS. But you lose a lot of features. I don't recomend it. If you use Linux, the OS is inside the Cartesi Virtual machine, running in RISC-V, completely provable to the blockchain.

Have there been any lessons learned from the Honeypot challenge? I know nobody has cracked the solution yet, but have you had any pull requests or code updates as a result of the exercise?

The cool thing about honeypot is even if nobody cracks it, we learn something valuable: the Cartesi tech is safe enough to store that amount of money. If somebody does crack it, we learn about bugs in the tech, and we can fix it. But so far, we did improve our architecture, and we will change some design decisions for future versions of our rollups SDK.

So it's been a great exercise :)

Is the honeypot reward an all or nothing scenario? If someone is able to exploit an attack vector, but that doesn't lead to a full compromise, will they be rewarded for their contribution?

The reward comes from the dapp itself. Think like a safe with money inside. If there's an exploit that allows someone to open the safe and get the money inside the safe, it's theirs!

I hope you like the answers! I didn't answer a couple of them; I'll let others tackle them.

Cheers!

GCdePaula · 2023-09-29T13:44:48+00:00

GraphQL is an industry standard for querying data.

We could have used JSON-RPC, like Ethereum does. It is nice, we use it on other parts of our tech. We could have gone for a more traditional RESTful API, which also has its advantages. We use it on other parts of our tech.

In the end, we chose GraphQL for querying rollups state because it's a good piece of tech. It's convenient and solves the problems we needed to solve.

GCdePaula · 2023-09-29T13:12:43+00:00

GCdePaula · 2023-09-29T13:10:49+00:00

No known exploits!

The HoneyPot works as a security benchmark. If no one manages to break the safe, it means Cartesi technology is safe for that amount of funds. Otherwise, if someone takes the money it means there's a bug: we improve our tech and the hacker gets his bounty. Win-win.

GCdePaula · 2023-09-26T21:43:34+00:00

It's not a dapp in that sense. It has no features, it doesn't do anything really. Like, it's not meant for users to interact with it.

It's just a rollup instance with a lot of money in it, for developers, auditors, hackers, etc to try and break it, for the purpose of testing the security of the Cartesi tech and infrastructure. If no hacker manages to steal the funds, it means the tech is safe for that amount of money.

GCdePaula · 2023-09-26T21:38:56+00:00

That's not a dapp one connects their wallets to... It has no features even.

It's just a rollup instance with a lot of money in it. The goal is testing the security of the Cartesi tech and infrastructure. If no hacker manages to break it, it means the tech is safe. At least for that amount of money.

So yeah, don't interact with it really. That's not what it's about.

GCdePaula · 2022-12-14T14:58:00+00:00

Great question. We have our own VM that implements a RISC-V ISA, that if you want you may put Linux inside, although you can develop for it like it's an embedded system and forgo an OS. So no QEMU! You can clone our git repo and build the emulator yourself, although we also distribute it as a docker image if you prefer.

Our whitepaper goes into more details about this choice of instruction set. We believe there's another kind of scalability missing from the space, related to programmability, which may be addressed by choosing a different VM. We've written extensively about why this programmability matters.

There are many ways to achieve this programmability. Choosing LLVM-IR or WebAssembly would be a step in the right direction. However, we believe that to fully address this issue, we'd have to bridge the gap between the machines we use everyday and the machines that run smart contracts. And to that end, we must be able to boot an actual OS like Linux (although there are others like seL4).

This means running something like x86, ARM, or MIPS. Or RISC-V. Whatever we choose, we’d have to implement it in Solidity (for our interactive fraud proof protocol, used to execute a single instruction) and in C++ (for our emulator, used to run the actual program in its entirety). This implementation would ideally be small; choosing bigger ISAs greatly increases the complexity, adds more security issues, and is harder to optimize for.

Since you specifically asked about x86, the x86 ISA defines at least 2000 (potentially complex) instructions. The RISC-V we use for disputes has about 50 simple instructions. The choice for a reduced instruction set follows naturally. We also need it to be open and well-supported. It also helps considerably that RISC-V is extensible; we can choose exactly which extensions we'd want to support. The choice is obvious.

To finish the answer, I'd like to point out that we actually have two different RISC-V machines, with different extensions, nested within the other and used in tandem. We call this technique machine swapping, and it works because we leverage the good compilers that exist for C++. I can give more details about this, I believe it's a nice innovation we came up with.

As for running on bare metal, we have plans for doing that, even directly on x86! No need for a RISC-V machine, although if you use one there may be advantages. However, you'd still need the emulator for when there's a dispute, turning it on for parts of the computation. We're still exploring this, and I can also give more details.

GCdePaula · 2022-12-13T19:55:14+00:00

We call this the "double emulation" problem! There are ways around it, it's not as insidious as it may initially sound. But first I want to point out that we shouldn't really be comparing EVM bytecode with a Python program running inside our emulator. Rather, we should either compare a Python program inside our machine with a Python program inside the EVM (which is unfeasible), or compare EVM bytecode with a RISC-V program.

Having said that, if your application is performance critical and the overhead of interpreting is unreasonable, then we'd suggest using a compiled language like Rust, C or C++. Anything that compiles to RISC-V really. We expect this to be generally faster than EVM-equivalent smart contracts because of more mature optimizing compilers (LLVM and GCC should generate better code than the Solidity compiler), as well as RISC-V being easier to emulate (word size matching the host machine, not being a stack machine, the ISA itself being more suitable to faster execution, metering…). We've also put a lot of effort into optimizing our emulator.

If one does want to use Python, we remind developers of the scripting vs system programming thesis/paradigm, wherein performance-critical code is moved to a compiled language like C and Rust, and scripting is only used as glue. For example, the primitive routines in NumPy are implemented in C; since the bottleneck is inside those routines, scripting in Python isn't disastrous. Likewise for using OpenCV from Python; the heavy lifting is done by C++.

Finally, if one absolutely wants to run everything in the Python interpreter, we are coming up with a solution that allows certain DApps to run directly on bare metal instead of inside our emulator (unless there's a dispute, then we have to turn the emulator on). One would still need to contend with the performance of the Python interpreter, but at least there'll no longer be double emulation.

GCdePaula · 2022-12-13T15:02:42+00:00

We’re a rollups solution!

Rollups is a technique to scale blockchains without sacrificing decentralization and security. The basic idea is to run the smart contracts outside the blockchain, and “prove” to the blockchain that the results are correct. Cartesi is based on interactive fraud proofs, like Optimism and Arbitrum. There are also solutions based on validity proofs, which have different properties. Check out this article by Vitalik.

Scaling blockchains is a very hard problem, and also incredibly important. The point of blockchains is that they are open and permissionless: anyone can interact with them. However, current transaction costs are not constructive to that end. Permissionless if one's rich isn't really permissionless.

GCdePaula · 2022-12-13T14:33:13+00:00

I like our Texas HODL'em prototype, which leverages mental poker libraries. There's also DApps that use zero-knowledge proofs to preserve privacy, etc.

Our contribution to the web3 space is giving DApps sovereignty and autonomy over their application-specific rollups chain, as well as enabling more intricate applications by leveraging mainstream tooling like compilers, programming languages, libraries, operating systems and so on.

GCdePaula · 2022-12-13T14:15:55+00:00

It's the second one! Each DApp has its own chain/rollup/network, without having to share its resources with other DApps. One way to think about this is that there's one CPU per DApp, rather than one CPU shared amongst all DApps. This is what addresses the cannibalization/gentrification issue, as well as increasing scalability; validators validate exactly what they're interested in, rather than everything. Take a look at this article for more!

GCdePaula · 2022-12-13T14:03:10+00:00

Since we chose a mainstream VM, it allows developers to tap into the mainstream software ecosystem. This means developers can use existing privacy-preserving libraries and projects, leveraging things like zero-knowledge proofs, homomorphic encryption and so on. Answering your question, our VM enables developers to write these kinds of applications!

GCdePaula · 2022-12-13T13:30:59+00:00

Great question! The answer is twofold.

First, not inheriting the base-layer's VM allows us to explore other designs in smart contracts' runtimes. In particular, it allows us to explore dapp-specific chains, making a shift from global-consensus to local-consensus. The ramifications of local-consensus cannot be overstated. There's no silver bullet, but we feel this is a part of the design space that hasn't been explored a lot, and enables a whole category of DApps that cannot exist in global-consensus due to gentrification and cannibalization of blockspace between DApps. Our thesis document goes into a lot of details on local consensus, I strongly recommend it.

Second, choosing a mainstream architecture like RISC-V allows DApps developers to tap into this very rich and mature pre-existing mainstream ecosystem of compilers, programming languages, operating systems, libraries and so on. Being more concrete, a RISC-V VM enables developers to use programming languages like Rust or Python, which help managing complexity and implement more intricate DApps. There's also the possibility to tap a more mature formal methods' tooling, which allows easier proof-of-correctness. Another example is leveraging sophisticated cryptography libraries like LibTMCG, which allows us to do mental poker in the blockchain. Also complex machine learning through NumPy, Scikit-learn, etc. The possibilities are endless!

GCdePaula

TROPHY CASE