ethereum-optimism · krofax · Jan 6, 2025 · Jan 6, 2025 · Jan 6, 2025 · Jan 6, 2025
@@ -25,6 +25,6 @@ When you make attestations about individuals:
 *   Leave the recipient address blank
 *   Enter the users id into the attestation metadata
 
-### Further reading
+### Next steps
 
 For more details on individual identity in the Optimism Collective, refer to **[the governance docs](https://community.optimism.io/docs/identity/project-and-individual-identity-in-the-collective/#building-a-digital-identity)** on building a digital identity.
@@ -20,6 +20,6 @@ All other project metadata is stored or referenced in the [Project Metadata Atte
 *   The Project Metadata Attestation is re-issued whenever there's a change in metadata.
 *   Apps displaying project metadata should refer to the most recent attestation for up-to-date information.
 
-## Further reading
+## Next steps
 
 For more information about identity in the Optimism Collective, see the [Identity Overview](/chain/identity/overview.mdx).
@@ -8,11 +8,13 @@ import { Card, Cards } from 'nextra/components'
 
 # Fault Proofs
 
-Documentation covering Cannon, Challenger, Explainer, Fp Components, Fp Security, Mips in the Fault Proofs section of the OP Stack ecosystem.
+Documentation covering Cannon, Kano Challenger, Explainer, Fp Components, Fp Security, Mips in the Fault Proofs section of the OP Stack ecosystem.
 
 <Cards>
   <Card title="Fault proof VM - Cannon" href="/stack/fault-proofs/cannon" />
 
+  <Card title="Fault proof VM - Kano" href="/stack/fault-proofs/kona" />
+
   <Card title="OP-Challenger explainer" href="/stack/fault-proofs/challenger" />
 
   <Card title="Fault proofs explainer" href="/stack/fault-proofs/explainer" />

@@ -2,6 +2,7 @@
     "explainer": "Fault proofs explainer",
     "fp-components": "FP system components",
     "cannon": "FPVM: Cannon",
+    "kona": "FPVM: Kona",
     "challenger": "OP-Challenger",
     "mips": "MIPS.sol",
     "fp-security": "FP Mainnet security"

@@ -203,7 +203,7 @@ As mentioned previously, Cannon is responsible for setting up all state that may
 Cannon is also responsible for interacting with the PreimageOracle Server, and directing OP-Challenger to provide Pre-images to
 the onchain `PreimageOracle.sol` if necessary for the instruction that will be run in `MIPS.sol`.
 
-The PreimageOracle Server connection is instantiated in `run.go`, where the server itself is run locally with its own local Key-Value store.
+The `PreimageOracle` Server connection is instantiated in `run.go`, where the server itself is run locally with its own local Key-Value store.
 `mips.go` communicates with the PreimageOracle Server when reading and writing Pre-images as part of MIPS syscall instructions,
 as well as hinting to the PreimageOracle Server.
 
@@ -215,7 +215,7 @@ This ABI is implemented by the VM by intercepting the `read`/`write` syscalls to
 Note that although the oracle provides up to 32 bytes of the pre-image,
 Cannon only supports reading at most 4 bytes at a time, to unify the memory operations with 32-bit load/stores.
 
-## Further Reading
+## Next steps
 
 *   [Cannon FPVM Specification](https://specs.optimism.io/experimental/fault-proof/cannon-fault-proof-vm.html)
 *   [Merkle Proofs Specification](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md)

@@ -76,7 +76,6 @@ As a result, the trust assumption is reduced to requiring only that the Guardian
 
 It's not expected that normal users run `op-proposer` to regularly propose output roots.
 Users would generally just propose a single output root if they need to withdraw and the chain operator isn't proposing outputs for them via direct calls to the `DisputeGameFactory` via Etherscan or using the [`create-game`](https://github.com/ethereum-optimism/optimism/tree/develop/op-challenger#create-game) subcommand of `op-challenger`.
-Documentation for `op-challenger` is forthcoming.
 
 ### How much ETH should a chain operator put aside to operate the Fault Proof System?
 
@@ -100,4 +99,10 @@ The list-claims subcommand of op-challenger can also provide a good view of the
 ./op-challenger/bin/op-challenger list-claims --l1-eth-rpc <SEPOLIA_L1> --game-address 0xcf8f181497DAD07277781517A76cb131C54A1BEE
 ```
 
-See the [specs](https://specs.optimism.io/experimental/fault-proof/stage-one/bond-incentives.html) for more details.
+## Next steps
+
+*   For more info about how fault proofs works under the hood,
-*   For more info about how fault proofs works under the hood,
+*   For more info about how fault proofs work under the hood,
-*   For more info about how fault proofs works under the hood,
+*   For more info about how fault proofs work under the hood,
+    [check out the specs](https://specs.optimism.io/fault-proof/index.html).
+*   Learn how to use [op-challenger](/stack/fault-proofs/challenger) to participate in the dispute process.
+*   Explore the [cannon](/stack/fault-proofs/cannon) fault proof system implementation.
+*   Understand the [components of the fault proof](/stack/fault-proofs/fp-components) system and their role in enhancing decentralization.
@@ -0,0 +1,106 @@
+---
+title: "Fault proof VM - Kona"
+lang: en-US
+sidebar_label: "FPVM: Kona"
+description: "Learn about Kona and its default operation as part of Optimism's Fault Proof Virtual Machine."
+---
+
+# FPVM: Kona
+
+Kona is an alternative fault-proof program for the OP Stack, providing a Rust-based implementation to complement the Asterisc fault-proof VM. Together, they form an equivalent system to Cannon and op-program but with distinct architectural and implementation differences.
+
+
+## Overview
+
+Kona works as the fault-proof program within the Asterisc fault-proof system. It operates by executing program logic step-by-step and generating commitments for every state transition. These commitments allow disputing parties to identify and resolve divergences in execution traces through interactive fraud proofs.
+
+Key features of Kona include:
+
+*   **Written in Rust:** High performance and memory safety.
+*   **Optimized for Asterisc:** Specifically tailored to work with the Asterisc RISC-V-based fault-proof VM.
+*   **Deterministic Execution:** Ensures consistency in state transitions during disputes.
+
+Kona + Asterisc is analogous to Cannon + op-program, providing an alternative pathway to secure optimistic rollups.
+
+## Relationship to Asterisc
+
+Kona is designed to:
+
+*   Complement Asterisc, which serves as the RISC-V fault-proof VM.
+*   Validate execution traces using the interactive fraud-proof mechanism.
+*   Offer an alternative to the Cannon + op-program system, leveraging Rust and RISC-V for distinct performance characteristics.
+
+For more on Asterisc, see the [Asterisc documentation](./asterisc.mdx).
+
+
+
+## Key differences
+
+### Architecture
+
+| System              | Fault-Proof VM | Fault-Proof Program | Language | Architecture |
+| ------------------- | -------------- | ------------------- | -------- | ------------ |
+| Asterisc + Kona     | Asterisc       | Kona                | Rust     | RISC-V       |
+| Cannon + op-program | Cannon         | op-program          | Go       | MIPS         |
+
+### Performance
+
+*   Kona benefits from Rust's memory safety and performance optimizations.
+*   Asterisc uses RISC-V, offering a simpler and more adaptable instruction set.
+
+## Getting started
+
+To set up and use Kona, follow these steps:
+
+1.  **Clone the repository:**
+    ```bash
+    git clone https://github.com/anton-rs/kona.git
+    cd kona
+    ```
+
+2.  **Install Dependencies:**
+    Ensure you have the Rust toolchain installed. Use `rustup` to set up Rust:
+    ```bash
+    curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
+    rustup install stable
+    ```
+
+3.  **Compile the program:**
+    Build the Kona fault-proof program:
+    ```bash
+    cargo build --release
+    ```
+
+4.  **Run Tests:**
+    Execute the test suite to verify your setup:
+    ```bash
+    cargo test
+    ```
+
+5.  **Explore further documentation:**
+    Check the [Kona repo docs](https://github.com/anton-rs/kona) for advanced usage and implementation details.
+
+## Benefits of Kona
+
+1.  **Rust-Based Implementation:**
+    *   Provides performance advantages and memory safety.
+
+2.  **Integration with Asterisc:**
+    *   Designed to fully utilize the RISC-V-based VM's capabilities.
+
+3.  **Focused Functionality:**
+    *   Tailored for the OP Stack's fault-proofing needs without additional complexity.
+
+## Limitations
+
+Kona is not a general-purpose program and is specifically designed for use within the Optimism fault-proofing stack. It does not support arbitrary RISC-V programs, focusing solely on its role as the fault-proof program for Asterisc.
+
+Kona is currently in the experimental stage. While it provides a functional alternative, it may lack the maturity and stability of Cannon + op-program. Users are encouraged to contribute to its development and provide feedback.
+
+## Next steps
+
+*   [Kona Repository](https://github.com/anton-rs/kona)
+*   [Kona Book](https://anton-rs.github.io/kona/)
+*   [Optimism Fault-Proofs Explainer](./explainer)
+*   [Cannon Documentation](./cannon)
+{/* *   [Asterisc Documentation](./asterisc) */}
@@ -253,7 +253,7 @@ The internal pure [`execute`](https://github.com/ethereum-optimism/optimism/blob
 | SC (Store Conditional Word)                    | 0x38        | -          | -          |
 | SYNC (Synchronize Shared Memory)               | 0x00        | 0x0F       | -          |
 
-## Further reading
+## Next steps
 
 *   [Cannon Overview](https://github.com/ethereum-optimism/optimism/blob/546fb2c7a5796b7fe50b0b7edc7666d3bd281d6f/cannon/docs/README.md)
 *   [Cannon FPVM Specification](https://specs.optimism.io/experimental/fault-proof/cannon-fault-proof-vm.html)

@@ -10,8 +10,10 @@ Allnodes
 Allocs
 allocs
 ANDI
+Ankr
 Apeworx
 Arweave
+Asterisc
 authrpc
 Badgeholder's
 Badgeholders
@@ -150,6 +152,7 @@ holesky
 IERC
 IGNOREPRICE
 ignoreprice
+Immunefi
 implicity
 Inator
 inator
@@ -171,6 +174,8 @@ JSPATH
 jspath
 jwtsecret
 Keccak
+Kona
+kona
 leveldb
 lightkdf
 logfile
@@ -199,6 +204,7 @@ minsuggestedpriorityfee
 Mintable
 Mintplex
 MIPSEVM
+Mitigations
 Monitorism
 Moralis
 Mordor
@@ -296,6 +302,8 @@ Proxied
 Proxyd
 proxyd
 pseudorandomly
+Pyth
+Pyth's
 QRNG
 Quicknode
 quicknode
@@ -330,6 +338,9 @@ runbooks
 RWAs
 safedb
 Schnorr
+SEPOLIA
+Sepolia
+sepolia
 seqnr
 SEQUENCERHTTP
 sequencerhttp
@@ -403,6 +414,7 @@ VMDEBUG
 vmdebug
 VMODULE
 vmodule
+voxel
 Warpcast
 xlarge
 XORI