Asterisc support guide #1189
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,76 @@ | ||||||
| --- | ||||||
| title: Asterisc | ||||||
| lang: en-US | ||||||
| description: Learn about Asterisc | ||||||
| --- | ||||||
|
|
||||||
| # Asterisc | ||||||
|
|
||||||
| [Asterisc](https://github.com/protolambda/asterisc/tree/master) is an alternative fault-proof VM for the OP Stack, crafted to validate RISC-V program execution via an interactive fraud-proof mechanism. Asterisc bridges simplicity and functionality, delivering a minimalist yet powerful solution for optimistic rollup fraud-proofing. Leveraging the RISC-V architecture, it offers: | ||||||
|
|
||||||
| * Support for 64-bit operations | ||||||
| * Concurrent yet deterministic threading | ||||||
| * Compatibility with RISC-V's expanding ecosystem | ||||||
|
There was a problem hiding this comment. I think I would remove these bullet points. It is 64-bit and that might be worth mentioning (it's good because it provides more memory for the fault proof program) but we don't support multithreading, and compatibility to run anything other than Kona is explicitly not a goal. (Just as Cannon doesn't try to be able to run any MIPS code, it's built to only support op-program). |
||||||
|
|
||||||
| Read more about fault-proofs in our [Fault-proof explainer](/stack/fault-proofs/explainer) | ||||||
|
|
||||||
| ## How it works | ||||||
|
|
||||||
| Asterisc enables parties to reach consensus on shared execution trace states. In cases of dispute, it identifies the diverging execution step. Commitments are generated for memory, registers, CSR, and VM states across the execution trace, with disputed steps emulated within the EVM to resolve inconsistencies. | ||||||
|
There was a problem hiding this comment. Similar to a comment above, it's not Asterisc alone that "enables parties to reach consensus on shared execution trace states". It's the fault proof program (Kona in this case) running in a fault proof VM (Asterisc in this case) that does this. |
||||||
|
|
||||||
| Ready to dive in? Keep reading or head over to the [Asterisc repo](https://github.com/protolambda/asterisc/tree/master). | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
|
|
||||||
| ## Getting started | ||||||
|
|
||||||
| 1. Read through the [additional repo docs](https://github.com/protolambda/asterisc/tree/master/docs). | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
| 2. Use Foundry to compile the associated smart contracts. | ||||||
| 3. Compile test binaries using the [`Makefile`](https://github.com/protolambda/asterisc/blob/master/tests/go-tests/Makefile). | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
| 4. Execute `rvgo` tests to validate both on-chain and off-chain operations through RISC-V unit tests. | ||||||
|
|
||||||
| ## Key components | ||||||
|
|
||||||
| * **`rvgo`:** A Go-based RISC-V emulator with two operational modes: | ||||||
| * **`Fast Mode`:** Executes one instruction per step on the VM state. | ||||||
| * **`Slow Mode`:** Emulates one instruction per step using a VM state oracle. | ||||||
| * **`rvsol`:** A Solidity/Yul implementation of the slow-mode step for EVM compatibility. | ||||||
|
|
||||||
| ### Yul in Solidity | ||||||
|
|
||||||
| Yul is chosen for its simplicity and precision, offering direct mirroring with Go code while retaining critical features like underflow/overflow behavior and untyped operations. | ||||||
|
|
||||||
| [See the repo](https://github.com/protolambda/asterisc/blob/master/README.md#why-use-yul-in-solidity) for a deeper dive on Yul and fast/slow modes. | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
|
|
||||||
| ## Supported RISC-V subsets | ||||||
|
|
||||||
| Here's a few key subsets. For the complete list, see the [repo](https://github.com/protolambda/asterisc?tab=readme-ov-file#risc-v-subset-support). | ||||||
|
|
||||||
| * `RV32I`: Base 32-bit instruction set | ||||||
| * `RV64I`: 64-bit instruction set | ||||||
| * `RV32M` and `RV64M`: Multiplication | ||||||
| * `RV32A` and `RV64A`: Atomics | ||||||
| * Compact instructions for Rust: Work in progress | ||||||
|
|
||||||
| Unsupported operations are implemented as no-ops, ensuring compatibility with the Go runtime. | ||||||
|
|
||||||
| ## FAQ | ||||||
|
|
||||||
| The following section highlights specific advantages that Asterisc provides over other fault-proof systems. | ||||||
|
|
||||||
| ### Benefits over Cannon | ||||||
|
|
||||||
| [Cannon](https://github.com/ethereum-optimism/cannon/), originally developed by [`geohot`](https://github.com/geohot/) and now maintained by Optimism, offers similar functionality but has key differences: | ||||||
|
|
||||||
| * Cannon operates on a 32-bit MIPS architecture, whereas Asterisc uses RISC-V. | ||||||
| * Asterisc supports 64-bit operations and deterministic threading, making it more future-ready. | ||||||
|
|
||||||
| ### Benefits over Cartesi | ||||||
|
|
||||||
| [Cartesi](https://github.com/cartesi/) provides RISC-V fraud-proofing for a full machine, including numerous additional features. However, this added complexity can introduce risks. Asterisc focuses on simplicity by running single-process executions with minimal system calls. | ||||||
|
|
||||||
| ### Benefits over WebAssembly | ||||||
|
|
||||||
| Arbitrum's WebAssembly-based fraud-proofing leverages a business-source license and transformation to WAVM, limiting its general usability. In contrast, Asterisc is open-source under the MIT license, offering broader applicability. | ||||||
|
|
||||||
| ## Contributing | ||||||
|
|
||||||
| Asterisc is designed to run Go programs for fraud-proofing optimistic rollups. Contributions that align with its goals of simplicity, minimalism, and compatibility are highly encouraged. | ||||||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might make sense for both Cannon and Asterisc to have "FPVM" in the title (or neither of them), since they're both fault proof VMs and basically alternative implementations of the same thing. Symmetry in the title would also emphasize the equivalence.