Asterisc support guide #1189
Asterisc support guide #1189
Conversation
✅ Deploy Preview for docs-optimism ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
📝 Walkthrough📝 WalkthroughWalkthroughThe pull request introduces documentation for Asterisc, a new fault-proof virtual machine (VM) for the OP Stack. Two primary changes are made:
The documentation explains Asterisc's approach to validating RISC-V program execution through an interactive fraud-proof mechanism, detailing its support for 64-bit operations, deterministic threading, and compatibility with the RISC-V ecosystem. The changes aim to provide developers and users with detailed information about Asterisc's technical capabilities, implementation details, and its role in the broader context of fault-proof technologies. Sequence Diagram(s)sequenceDiagram
participant User
participant Asterisc VM
participant RISC-V Program
participant Dispute Resolution
User->>Asterisc VM: Execute RISC-V Program
Asterisc VM->>RISC-V Program: Run Program
RISC-V Program-->>Asterisc VM: Generate State Commitments
alt Execution Dispute
Dispute Resolution->>Asterisc VM: Challenge Execution
Asterisc VM->>Dispute Resolution: Provide Detailed Execution Trace
Dispute Resolution->>Dispute Resolution: Validate Diverging Steps
end
Dispute Resolution-->>User: Resolve Dispute
Possibly related issues
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (7)
pages/stack/fault-proofs/asterisc.mdx (7)
1-5: Enhance the description to be more informativeConsider expanding the description to better reflect the content and purpose, for example: "Learn about Asterisc, a fault-proof virtual machine for validating RISC-V program execution in the OP Stack"
🧰 Tools
🪛 GitHub Check: lint
[warning] 1-1:
Missing newline character at end of file
8-8: Improve sentence variety in the introductionConsider rewording to avoid repetitive sentence beginnings. For example:
-Asterisc bridges simplicity and functionality, delivering a minimalist yet powerful solution for optimistic rollup fraud-proofing. +This fault-proof VM bridges simplicity and functionality, delivering a minimalist yet powerful solution for optimistic rollup fraud-proofing.🧰 Tools
🪛 LanguageTool
[style] ~8-~8: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...a an interactive fraud-proof mechanism. Asterisc bridges simplicity and functionality, d...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
10-12: Standardize list formattingUpdate the list formatting to follow the style guide:
-- Support for 64-bit operations -- Concurrent yet deterministic threading -- Compatibility with RISC-V's expanding ecosystem +* Support for 64-bit operations +* Concurrent yet deterministic threading +* Compatibility with RISC-V's expanding ecosystem🧰 Tools
🪛 GitHub Check: lint
[warning] 10-10:
Marker style should be*
[warning] 10-10:
Incorrect list-item indent: add 2 spaces
[warning] 11-11:
Marker style should be*
[warning] 11-11:
Incorrect list-item indent: add 2 spaces
[warning] 12-12:
Marker style should be*
[warning] 12-12:
Blocked character found: (’) at index 25
[warning] 12-12:
Incorrect list-item indent: add 2 spaces
24-27: Adjust list indentationUpdate the ordered list indentation to follow the style guide:
-1. Read through the [additional repo docs](https://github.com/protolambda/asterisc/tree/master/docs). -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). -4. Execute `rvgo` tests to validate both on-chain and off-chain operations through RISC-V unit tests. +1. Read through the [additional repo docs](https://github.com/protolambda/asterisc/tree/master/docs). +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). +4. Execute `rvgo` tests to validate both on-chain and off-chain operations through RISC-V unit tests.🧰 Tools
🪛 GitHub Check: lint
[warning] 24-24:
Incorrect list-item indent: add 1 space
[warning] 25-25:
Incorrect list-item indent: add 1 space
44-44: Fix grammatical errorChange "Here's a few key subsets" to "Here are a few key subsets" to maintain proper subject-verb agreement.
69-69: Remove redundant hyphenChange "WebAssembly-based" to "WebAssembly based" as per style guidelines.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~69-~69: The hyphen in WebAssembly-based is redundant.
Context: ...# Benefits over WebAssembly Arbitrum’s WebAssembly-based fraud-proofing leverages a business-sou...(ADVERB_LY_HYPHEN_FIX)
71-73: Add newline at end of fileAdd a newline character at the end of the file to comply with standard text file formatting.
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. +
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
pages/stack/fault-proofs/_meta.json(1 hunks)pages/stack/fault-proofs/asterisc.mdx(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- pages/stack/fault-proofs/_meta.json
🧰 Additional context used
📓 Path-based instructions (1)
pages/stack/fault-proofs/asterisc.mdx (1)
Pattern **/*.mdx: "ALWAYS review Markdown content THOROUGHLY with the following criteria:
- Use proper nouns in place of personal pronouns like 'We' and 'Our' to maintain consistency in communal documentation.
- Avoid gender-specific language and use the imperative form.
- Monitor capitalization for emphasis. Avoid using all caps, italics, or bold for emphasis.
- Ensure proper nouns are capitalized in sentences.
- Apply the Oxford comma.
- Use proper title case for buttons, tab names, page names, and links. Sentence case should be used for body content and short phrases, even in links.
- Use correct spelling and grammar at all times (IMPORTANT).
- For H1, H2, and H3 headers:
- Use sentence case, capitalizing only the first word.
- Preserve the capitalization of proper nouns, technical terms, and acronyms as defined in the 'nouns.txt' file located in the root directory of the project.
- Do not automatically lowercase words that appear in the 'nouns.txt' file, regardless of their position in the header.
- Flag any headers that seem to inconsistently apply these rules for manual review.
- When reviewing capitalization, always refer to the 'nouns.txt' file for the correct capitalization of proper nouns and technical terms specific to the project.
"
🪛 LanguageTool
pages/stack/fault-proofs/asterisc.mdx
[style] ~8-~8: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...a an interactive fraud-proof mechanism. Asterisc bridges simplicity and functionality, d...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[uncategorized] ~31-~31: Loose punctuation mark.
Context: ...it tests. ## Key components - rvgo: A Go-based RISC-V emulator with two o...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~33-~33: Loose punctuation mark.
Context: ... step on the VM state. - Slow Mode: Emulates one instruction per step usi...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~34-~34: Loose punctuation mark.
Context: ...tep using a VM state oracle. - rvsol: A Solidity/Yul implementation of the ...
(UNLIKELY_OPENING_PUNCTUATION)
[grammar] ~43-~43: Consider using the plural verb form for the plural noun “subsets”.
Context: ...ow modes. ## Supported RISC-V subsets Here's a few key subsets. For the complete lis...
(THERE_IS_A_LOT_OF)
[uncategorized] ~45-~45: Loose punctuation mark.
Context: ...v-file#risc-v-subset-support). - RV32I: Base 32-bit instruction set - RV64I: ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~69-~69: The hyphen in WebAssembly-based is redundant.
Context: ...# Benefits over WebAssembly Arbitrum’s WebAssembly-based fraud-proofing leverages a business-sou...
(ADVERB_LY_HYPHEN_FIX)
🪛 GitHub Check: lint
pages/stack/fault-proofs/asterisc.mdx
[warning] 1-1:
Missing newline character at end of file
[warning] 10-10:
Marker style should be *
[warning] 10-10:
Incorrect list-item indent: add 2 spaces
[warning] 11-11:
Marker style should be *
[warning] 11-11:
Incorrect list-item indent: add 2 spaces
[warning] 12-12:
Marker style should be *
[warning] 12-12:
Blocked character found: (’) at index 25
[warning] 12-12:
Incorrect list-item indent: add 2 spaces
[warning] 24-24:
Incorrect list-item indent: add 1 space
[warning] 25-25:
Incorrect list-item indent: add 1 space
🔇 Additional comments (2)
pages/stack/fault-proofs/asterisc.mdx (2)
16-20: LGTM!
The section effectively explains Asterisc's consensus mechanism and dispute resolution process.
29-41: LGTM!
The section effectively describes the key components and their operational modes, with a clear explanation of the Yul implementation choice.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~31-~31: Loose punctuation mark.
Context: ...it tests. ## Key components - rvgo: A Go-based RISC-V emulator with two o...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~33-~33: Loose punctuation mark.
Context: ... step on the VM state. - Slow Mode: Emulates one instruction per step usi...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~34-~34: Loose punctuation mark.
Context: ...tep using a VM state oracle. - rvsol: A Solidity/Yul implementation of the ...
(UNLIKELY_OPENING_PUNCTUATION)
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (8)
pages/stack/fault-proofs/asterisc.mdx (8)
1-5: Enhance the description to be more specificConsider expanding the description to better reflect the document's content, such as:
"Learn about Asterisc, a fault-proof VM for validating RISC-V program execution in the OP Stack"
9-9: Improve sentence variety in the introductionConsider rewording to avoid repetitive sentence beginnings:
-Asterisc bridges simplicity and functionality, delivering a minimalist yet powerful solution for optimistic rollup fraud-proofing. +This fault-proof VM bridges simplicity and functionality, delivering a minimalist yet powerful solution for optimistic rollup fraud-proofing.🧰 Tools
🪛 LanguageTool
[style] ~9-~9: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...a an interactive fraud-proof mechanism. Asterisc bridges simplicity and functionality, d...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
19-19: Break down the technical explanation for clarityConsider restructuring the explanation into bullet points:
-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. +Asterisc enables parties to reach consensus on shared execution trace states through: + +* Identification of diverging execution steps in disputes +* Generation of commitments for: + - Memory states + - Register states + - CSR states + - VM states +* EVM emulation of disputed steps for resolution
25-28: Add context to setup stepsConsider adding brief explanations for each step:
-2. Use Foundry to compile the associated smart contracts. -3. Compile test binaries using the `Makefile`. -4. Execute `rvgo` tests to validate both on-chain and off-chain operations through RISC-V unit tests. +2. Use Foundry to compile the associated smart contracts (required for on-chain verification). +3. Compile test binaries using the `Makefile` in the `tests/go-tests` directory. +4. Execute `rvgo` tests to validate both on-chain and off-chain operations through RISC-V unit tests. These tests ensure correct VM behavior.
39-39: Expand on Yul's technical benefitsConsider adding specific technical advantages:
-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. +Yul is chosen for its simplicity and precision, offering: +* Direct one-to-one mapping with Go code +* Precise control over arithmetic operations +* Built-in overflow and underflow protection +* Low-level optimization capabilities +* Simplified debugging through untyped operations
45-45: Fix grammatical error in introduction-Here's a few key subsets. +Here are a few key subsets.
72-72: Fix hyphenation in WebAssembly reference-Arbitrum's WebAssembly-based fraud-proofing leverages a business-source license +Arbitrum's WebAssembly fraud-proofing leverages a business-source license🧰 Tools
🪛 LanguageTool
[uncategorized] ~72-~72: The hyphen in WebAssembly-based is redundant.
Context: ...# Benefits over WebAssembly Arbitrum's WebAssembly-based fraud-proofing leverages a business-sou...(ADVERB_LY_HYPHEN_FIX)
76-76: Expand contribution guidelinesConsider adding specific areas where contributions would be valuable, such as:
- Documentation improvements
- Test case additions
- Performance optimizations
- Bug fixes
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
pages/stack/fault-proofs/asterisc.mdx(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
pages/stack/fault-proofs/asterisc.mdx (1)
Pattern **/*.mdx: "ALWAYS review Markdown content THOROUGHLY with the following criteria:
- Use proper nouns in place of personal pronouns like 'We' and 'Our' to maintain consistency in communal documentation.
- Avoid gender-specific language and use the imperative form.
- Monitor capitalization for emphasis. Avoid using all caps, italics, or bold for emphasis.
- Ensure proper nouns are capitalized in sentences.
- Apply the Oxford comma.
- Use proper title case for buttons, tab names, page names, and links. Sentence case should be used for body content and short phrases, even in links.
- Use correct spelling and grammar at all times (IMPORTANT).
- For H1, H2, and H3 headers:
- Use sentence case, capitalizing only the first word.
- Preserve the capitalization of proper nouns, technical terms, and acronyms as defined in the 'nouns.txt' file located in the root directory of the project.
- Do not automatically lowercase words that appear in the 'nouns.txt' file, regardless of their position in the header.
- Flag any headers that seem to inconsistently apply these rules for manual review.
- When reviewing capitalization, always refer to the 'nouns.txt' file for the correct capitalization of proper nouns and technical terms specific to the project.
"
🪛 LanguageTool
pages/stack/fault-proofs/asterisc.mdx
[style] ~9-~9: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...a an interactive fraud-proof mechanism. Asterisc bridges simplicity and functionality, d...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[uncategorized] ~32-~32: Loose punctuation mark.
Context: ... tests. ## Key components * rvgo: A Go-based RISC-V emulator with two o...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~34-~34: Loose punctuation mark.
Context: ...p on the VM state. * Slow Mode: Emulates one instruction per step usi...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~35-~35: Loose punctuation mark.
Context: ...p using a VM state oracle. * rvsol: A Solidity/Yul implementation of the ...
(UNLIKELY_OPENING_PUNCTUATION)
[grammar] ~44-~44: Consider using the plural verb form for the plural noun “subsets”.
Context: ...ow modes. ## Supported RISC-V subsets Here's a few key subsets. For the complete lis...
(THERE_IS_A_LOT_OF)
[uncategorized] ~47-~47: Loose punctuation mark.
Context: ...ile#risc-v-subset-support). * RV32I: Base 32-bit instruction set * RV64I...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~72-~72: The hyphen in WebAssembly-based is redundant.
Context: ...# Benefits over WebAssembly Arbitrum's WebAssembly-based fraud-proofing leverages a business-sou...
(ADVERB_LY_HYPHEN_FIX)
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
pages/stack/fault-proofs.mdx (1)
Line range hint
9-26: Maintain consistent title case in cardsSome cards use inconsistent capitalization. Based on the provided words.txt and documentation guidelines:
Apply these changes for consistency:
- <Card title="Fault proof VM - Cannon" href="/stack/fault-proofs/cannon" /> + <Card title="Fault Proof VM - Cannon" href="/stack/fault-proofs/cannon" /> - <Card title="OP-Challenger explainer" href="/stack/fault-proofs/challenger" /> + <Card title="OP-Challenger Explainer" href="/stack/fault-proofs/challenger" /> - <Card title="Fault proofs explainer" href="/stack/fault-proofs/explainer" /> + <Card title="Fault Proofs Explainer" href="/stack/fault-proofs/explainer" /> - <Card title="FP System components" href="/stack/fault-proofs/fp-components" /> + <Card title="FP System Components" href="/stack/fault-proofs/fp-components" /> - <Card title="Fault proofs Mainnet security" href="/stack/fault-proofs/fp-security" /> + <Card title="Fault Proofs Mainnet Security" href="/stack/fault-proofs/fp-security" /> - <Card title="Fault proof VM - MIPS.sol" href="/stack/fault-proofs/mips" /> + <Card title="Fault Proof VM - MIPS.sol" href="/stack/fault-proofs/mips" />
🧹 Nitpick comments (1)
pages/stack/fault-proofs.mdx (1)
Line range hint
1-7: Simplify the description metadataThe description redundantly lists all components. Consider revising to a more concise format:
- description: Documentation covering Cannon, Challenger, Explainer, Fp Components, Fp Security, Mips in the Fault Proofs section of the OP Stack ecosystem. + description: Documentation covering fault proof components in the OP Stack ecosystem.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
pages/stack/fault-proofs.mdx(1 hunks)words.txt(3 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
pages/stack/fault-proofs.mdx (1)
Pattern **/*.mdx: "ALWAYS review Markdown content THOROUGHLY with the following criteria:
- Use proper nouns in place of personal pronouns like 'We' and 'Our' to maintain consistency in communal documentation.
- Avoid gender-specific language and use the imperative form.
- Monitor capitalization for emphasis. Avoid using all caps, italics, or bold for emphasis.
- Ensure proper nouns are capitalized in sentences.
- Apply the Oxford comma.
- Use proper title case for buttons, tab names, page names, and links. Sentence case should be used for body content and short phrases, even in links.
- Use correct spelling and grammar at all times (IMPORTANT).
- For H1, H2, and H3 headers:
- Use sentence case, capitalizing only the first word.
- Preserve the capitalization of proper nouns, technical terms, and acronyms as defined in the 'nouns.txt' file located in the root directory of the project.
- Do not automatically lowercase words that appear in the 'nouns.txt' file, regardless of their position in the header.
- Flag any headers that seem to inconsistently apply these rules for manual review.
- When reviewing capitalization, always refer to the 'nouns.txt' file for the correct capitalization of proper nouns and technical terms specific to the project.
"
🔇 Additional comments (1)
words.txt (1)
15-16: LGTM! New terms follow the established pattern
The additions of "Asterisc", "asterisc", "Cartesi", and "WAVM" maintain consistency with the existing dictionary structure and support the documentation updates.
Also applies to: 53-53, 399-399
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
pages/stack/fault-proofs/asterisc.mdx (2)
7-15: Use sentence case for section headersAccording to the coding guidelines for .mdx files, H1 headers should use sentence case. Additionally, avoid using italics for emphasis in the bullet points.
Apply these changes:
-# Asterisc +# Introduction to Asterisc -* Support for 64-bit operations -* Concurrent yet deterministic threading -* Compatibility with RISC-V's expanding ecosystem +- Support for 64-bit operations +- Concurrent yet deterministic threading +- Compatibility with RISC-V's expanding ecosystem🧰 Tools
🪛 LanguageTool
[style] ~9-~9: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...a an interactive fraud-proof mechanism. Asterisc delivers a minimalist yet powerful solu...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
66-73: Improve comparison section clarityThe comparison with WebAssembly needs refinement to maintain neutrality and focus on technical differences rather than licensing.
Consider restructuring as:
-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. +Asterisc differs from Arbitrum's WebAssembly-based fraud-proofing in several ways: +- Uses RISC-V instead of WebAssembly/WAVM transformation +- Provides direct execution without intermediate transformations +- Available under the MIT license🧰 Tools
🪛 LanguageTool
[uncategorized] ~72-~72: The hyphen in WebAssembly-based is redundant.
Context: ...# Benefits over WebAssembly Arbitrum's WebAssembly-based fraud-proofing leverages a business-sou...(ADVERB_LY_HYPHEN_FIX)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
pages/builders/chain-operators/tutorials/create-l2-rollup.mdx(1 hunks)pages/builders/node-operators/tutorials.mdx(1 hunks)pages/stack/fault-proofs/asterisc.mdx(1 hunks)words.txt(3 hunks)
✅ Files skipped from review due to trivial changes (1)
- pages/builders/node-operators/tutorials.mdx
🧰 Additional context used
📓 Path-based instructions (2)
pages/builders/chain-operators/tutorials/create-l2-rollup.mdx (1)
Pattern **/*.mdx: "ALWAYS review Markdown content THOROUGHLY with the following criteria:
- Use proper nouns in place of personal pronouns like 'We' and 'Our' to maintain consistency in communal documentation.
- Avoid gender-specific language and use the imperative form.
- Monitor capitalization for emphasis. Avoid using all caps, italics, or bold for emphasis.
- Ensure proper nouns are capitalized in sentences.
- Apply the Oxford comma.
- Use proper title case for buttons, tab names, page names, and links. Sentence case should be used for body content and short phrases, even in links.
- Use correct spelling and grammar at all times (IMPORTANT).
- For H1, H2, and H3 headers:
- Use sentence case, capitalizing only the first word.
- Preserve the capitalization of proper nouns, technical terms, and acronyms as defined in the 'nouns.txt' file located in the root directory of the project.
- Do not automatically lowercase words that appear in the 'nouns.txt' file, regardless of their position in the header.
- Flag any headers that seem to inconsistently apply these rules for manual review.
- When reviewing capitalization, always refer to the 'nouns.txt' file for the correct capitalization of proper nouns and technical terms specific to the project.
"
pages/stack/fault-proofs/asterisc.mdx (1)
Pattern **/*.mdx: "ALWAYS review Markdown content THOROUGHLY with the following criteria:
- Use proper nouns in place of personal pronouns like 'We' and 'Our' to maintain consistency in communal documentation.
- Avoid gender-specific language and use the imperative form.
- Monitor capitalization for emphasis. Avoid using all caps, italics, or bold for emphasis.
- Ensure proper nouns are capitalized in sentences.
- Apply the Oxford comma.
- Use proper title case for buttons, tab names, page names, and links. Sentence case should be used for body content and short phrases, even in links.
- Use correct spelling and grammar at all times (IMPORTANT).
- For H1, H2, and H3 headers:
- Use sentence case, capitalizing only the first word.
- Preserve the capitalization of proper nouns, technical terms, and acronyms as defined in the 'nouns.txt' file located in the root directory of the project.
- Do not automatically lowercase words that appear in the 'nouns.txt' file, regardless of their position in the header.
- Flag any headers that seem to inconsistently apply these rules for manual review.
- When reviewing capitalization, always refer to the 'nouns.txt' file for the correct capitalization of proper nouns and technical terms specific to the project.
"
🪛 LanguageTool
words.txt
[duplication] ~404-~404: Möglicher Tippfehler: ein Wort wird wiederholt
Context: ...WAVM xlarge XORI xtensibility ZKPs ZKVM Zora zora Sepolia voxel sepolia SEPOLIA Pyth Pyth...
(GERMAN_WORD_REPEAT_RULE)
[duplication] ~408-~408: Möglicher Tippfehler: ein Wort wird wiederholt
Context: ...ility ZKPs ZKVM Zora zora Sepolia voxel sepolia SEPOLIA Pyth Pyth's Ankr Mitigations Immunefi A...
(GERMAN_WORD_REPEAT_RULE)
[duplication] ~410-~410: Möglicher Tippfehler: ein Wort wird wiederholt
Context: ...Zora zora Sepolia voxel sepolia SEPOLIA Pyth Pyth's Ankr Mitigations Immunefi Arbitrum's
(GERMAN_WORD_REPEAT_RULE)
pages/stack/fault-proofs/asterisc.mdx
[style] ~9-~9: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...a an interactive fraud-proof mechanism. Asterisc delivers a minimalist yet powerful solu...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[uncategorized] ~32-~32: Loose punctuation mark.
Context: ... tests. ## Key components * rvgo: A Go-based RISC-V emulator with two o...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~34-~34: Loose punctuation mark.
Context: ...p on the VM state. * Slow Mode: Emulates one instruction per step usi...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~35-~35: Loose punctuation mark.
Context: ...p using a VM state oracle. * rvsol: A Solidity/Yul implementation of the ...
(UNLIKELY_OPENING_PUNCTUATION)
[grammar] ~44-~44: Consider using the plural verb form for the plural noun “subsets”.
Context: ...ow modes. ## Supported RISC-V subsets Here's a few key subsets. For the complete lis...
(THERE_IS_A_LOT_OF)
[uncategorized] ~47-~47: Loose punctuation mark.
Context: ...ile#risc-v-subset-support). * RV32I: Base 32-bit instruction set * RV64I...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~72-~72: The hyphen in WebAssembly-based is redundant.
Context: ...# Benefits over WebAssembly Arbitrum's WebAssembly-based fraud-proofing leverages a business-sou...
(ADVERB_LY_HYPHEN_FIX)
🔇 Additional comments (5)
words.txt (3)
15-16: LGTM: Asterisc term addition
The addition of "Asterisc" and its lowercase variant is consistent with the documentation needs, as it's a new fault-proof VM being introduced.
53-53: LGTM: Cartesi term addition
The addition of "Cartesi" is appropriate as it's referenced in comparisons with Asterisc in the documentation.
407-416: Verify the removal of terms
The removal of terms like "Ankr", "Immunefi", and "Mitigations" should be verified to ensure they're no longer referenced in the documentation.
✅ Verification successful
Terms have been safely removed
The verification process confirms that the removed terms "Ankr", "Immunefi", "Mitigations", and "Pyth" are no longer present in any of the documentation files across the repository. The comprehensive search through all markdown files (.md, .mdx, .markdown) showed no occurrences of these terms.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if removed terms are still referenced in documentation
# Test: Search for removed terms in .mdx files
echo "Checking for removed terms in documentation..."
rg -i "ankr|immunefi|mitigations|pyth" '**/*.mdx'
Length of output: 203
Script:
#!/bin/bash
# Let's check for documentation files with different extensions and locations
echo "Finding documentation files..."
fd -e md -e mdx -e markdown
echo -e "\nChecking for removed terms in all documentation files..."
rg -i "ankr|immunefi|mitigations|pyth" -t md -t markdown
Length of output: 9271
🧰 Tools
🪛 LanguageTool
[duplication] ~408-~408: Möglicher Tippfehler: ein Wort wird wiederholt
Context: ...ility ZKPs ZKVM Zora zora Sepolia voxel sepolia SEPOLIA Pyth Pyth's Ankr Mitigations Immunefi A...
(GERMAN_WORD_REPEAT_RULE)
[duplication] ~410-~410: Möglicher Tippfehler: ein Wort wird wiederholt
Context: ...Zora zora Sepolia voxel sepolia SEPOLIA Pyth Pyth's Ankr Mitigations Immunefi Arbitrum's
(GERMAN_WORD_REPEAT_RULE)
pages/stack/fault-proofs/asterisc.mdx (1)
1-5: LGTM: Frontmatter structure
The frontmatter follows the standard format with title, language, and description fields.
pages/builders/chain-operators/tutorials/create-l2-rollup.mdx (1)
74-74: LGTM: Proper noun capitalization
The capitalization of "Sepolia" has been corrected according to the coding guidelines for proper nouns in documentation.
There was a problem hiding this comment.
There are some specific comments within, but as a more high-level comment I'd suggest some changes:
- A lot of this just mirrors what's in the Asterisc README, which I think is unnecessary.
We should have only one source of the same content. If it belongs here then it should move, but we shouldn't have both. Also, the things in the README like how to compile and run tests are probably not what the audience of the OP docs are looking for, I think the repo README is more appropriate for those anyway.
- It could be more minimal by explicitly referencing the Cannon docs, and saying explicitly that it's equivalent, it's an alternative implementation of a fault proof VM, and also that Kona is a alternative implementation of a fault-proof program.
So explicitly saying that Asterisc + Kona is equivalent to Cannon + op-program.
Then we could just mention the differences (that Asterisc is RISC-V instead of MIPS, and that Kona is written in Rust, where as op-program is written in Go). We could provide more detail on additional differences if you want.
-
Just as the Cannon page talks about op-program (since they're two parts of the same system), I think the Asterisc page should mention Kona.
-
I think it should be inside "experimental".
| @@ -2,6 +2,7 @@ | |||
| "explainer": "Fault proofs explainer", | |||
| "fp-components": "FP system components", | |||
| "cannon": "FPVM: Cannon", | |||
| "asterisc": "Asterisc", | |||
There was a problem hiding this comment.
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.
|
|
||
| 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. | ||
|
|
||
| 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.
| Ready to dive in? Keep reading or head over to the [Asterisc repo](https://github.com/protolambda/asterisc/tree/master). | |
| Ready to dive in? Keep reading or head over to the [Asterisc repo](https://github.com/ethereum-optimism/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 delivers a minimalist yet powerful solution for optimistic rollup fraud-proofing through Go. Leveraging the RISC-V architecture, it offers: |
There was a problem hiding this comment.
I think I would explicitly mention that it's equivalent to Cannon, but an alternative implementation based on the RISC-V instead of MIPS architecture, and that it's designed to run Kona instead of op-program. (Kona is an alternative implementation of op-program, and Asterisc is an alternative implementation of Cannon).
There was a problem hiding this comment.
to validate RISC-V program execution via an interactive fraud-proof mechanism
To be clear, the interactive fraud-proof mechanism is a combination of the "fault proof program" (Kona or op-program) running in a fault proof VM (Asterisc or Cannon).
|
|
||
| * 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).
|
|
||
| ## Getting started | ||
|
|
||
| 1. Read through the [additional repo docs](https://github.com/protolambda/asterisc/tree/master/docs). |
There was a problem hiding this comment.
| 1. Read through the [additional repo docs](https://github.com/protolambda/asterisc/tree/master/docs). | |
| 1. Read through the [additional repo docs](https://github.com/ethereum-optimism/asterisc/tree/master/docs). |
|
|
||
| 1. Read through the [additional repo docs](https://github.com/protolambda/asterisc/tree/master/docs). | ||
| 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.
| 3. Compile test binaries using the [`Makefile`](https://github.com/protolambda/asterisc/blob/master/tests/go-tests/Makefile). | |
| 3. Compile test binaries using the [`Makefile`](https://github.com/ethereum-optimism/asterisc/blob/master/tests/go-tests/Makefile). |
|
|
||
| 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.
| [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. | |
| [See the repo](https://github.com/ethereum-optimism/asterisc/blob/master/README.md#why-use-yul-in-solidity) for a deeper dive on Yul and fast/slow modes. |
|
|
||
| ## 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.
No description provided.