diff --git a/pages/_meta.json b/pages/_meta.json index 7eed4e65a..e33c96e0d 100644 --- a/pages/_meta.json +++ b/pages/_meta.json @@ -107,5 +107,19 @@ "connect": { "title": "Connect", "display": "children" + }, + + "+++ Superchain": { + "title": "", + "type": "separator" + }, + "--- Superchain": { + "title": "Superchain", + "type": "separator" + }, + + "superchain": { + "title": "Superchain", + "display": "children" } } diff --git a/pages/builders/app-developers/tools.mdx b/pages/builders/app-developers/tools.mdx index 7aeb81f23..66fbf97f4 100644 --- a/pages/builders/app-developers/tools.mdx +++ b/pages/builders/app-developers/tools.mdx @@ -13,5 +13,5 @@ This section provides information on open-source code repositories for OP Stack - + diff --git a/pages/builders/app-developers/tools/supersim.mdx b/pages/builders/app-developers/tools/supersim.mdx deleted file mode 100644 index 57a0d8e40..000000000 --- a/pages/builders/app-developers/tools/supersim.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Supersim -lang: en-US -description: >- - Learn about supersim in the Optimism ecosystem. This guide provides detailed - information and resources about supersim. ---- - -import Supersim from '@/pages/stack/interop/supersim.mdx' - - diff --git a/pages/builders/tools/_meta.json b/pages/builders/tools/_meta.json index 440d418b9..cfa402509 100644 --- a/pages/builders/tools/_meta.json +++ b/pages/builders/tools/_meta.json @@ -3,6 +3,6 @@ "connect": "Connecting", "build": "Building", "monitor": "Monitoring", - "op-tools": "OP tools", + "op-tools": "Metal L2 Tools", "fee-calculator": "Fee calculator" } diff --git a/pages/builders/tools/connect/rpc-providers.mdx b/pages/builders/tools/connect/rpc-providers.mdx index 92f4ad280..0c91ffd36 100644 --- a/pages/builders/tools/connect/rpc-providers.mdx +++ b/pages/builders/tools/connect/rpc-providers.mdx @@ -33,7 +33,7 @@ This reference guide lists RPC and node providers to help you connect to a Metal For early-stage startups, dRPC and Optimism Collective provide Metal L2 nodes from 3 geo clusters without method restrictions and are totally free! For commercial nodes, dRPC uses a pay-as-you-go model without hidden fees and rate limits. Feel free to try fast and reliable nodes. -### Supported Networks +Supported Networks Metal L2 Mainnet, Metal L2 TestNet (Metal L2 Sepolia) diff --git a/pages/builders/tools/op-tools.mdx b/pages/builders/tools/op-tools.mdx index 4335cef41..f5276a454 100644 --- a/pages/builders/tools/op-tools.mdx +++ b/pages/builders/tools/op-tools.mdx @@ -1,15 +1,15 @@ --- -title: Op Tools +title: Metal L2 Tools lang: en-US description: >- - Learn about op tools in the Optimism ecosystem. This guide provides detailed - information and resources about op tools. + Learn about Metal L2 tools. This guide provides detailed + information and resources about Metal L2 tools. --- import { Card, Cards } from 'nextra/components' -# Op Tools +# Metal L2 Tools -This section provides information on . +This section provides information on Metal L2 tools. diff --git a/pages/builders/tools/op-tools/_meta.json b/pages/builders/tools/op-tools/_meta.json index 4886952ac..cf663f520 100644 --- a/pages/builders/tools/op-tools/_meta.json +++ b/pages/builders/tools/op-tools/_meta.json @@ -1,34 +1,28 @@ { "block-explorer": { - "title": "OP Mainnet explorer", - "href": "https://optimistic.etherscan.io/", + "title": "Metal L2 Mainnet Explorer", + "href": "https://explorer.metall2.com/", "newWindow": true }, - "bridge": { - "title": "Superchain bridges", - "href": "https://app.optimism.io/bridge", + "metall2bridge": { + "title": "Metal L2 Bridge", + "href": "https://bridge.metall2.com/", "newWindow": true }, - "sdk": { - "title": "Optimism SDK", - "href": "https://sdk.optimism.io/", + "bridge": { + "title": "Superchain Bridges", + "href": "https://app.optimism.io/bridge", "newWindow": true }, "faucet": { - "title": "Superchain faucet", + "title": "Superchain Faucet", "type": "page", - "href": "https://console.optimism.io/faucet?utm_source=docs", + "href": "https://console.optimism.io/faucet", "newWindow": true }, "console": { - "title": "Superchain dev console", - "href": "https://console.optimism.io/?utm_source=docs", - "newWindow": true - }, - "gas": { - "title": "Gas tracker", - "type": "page", - "href": "https://optimistic.grafana.net/public-dashboards/c84a5a9924fe4e14b270a42a8651ceb8?orgId=1&refresh=5m", + "title": "Superchain Dev Console", + "href": "https://console.optimism.io/", "newWindow": true } } diff --git a/pages/chain/getting-started.mdx b/pages/chain/getting-started.mdx index 15a6455ad..08a0ae68e 100644 --- a/pages/chain/getting-started.mdx +++ b/pages/chain/getting-started.mdx @@ -11,7 +11,7 @@ import { Steps } from 'nextra/components' This guide explains the basics of Metal L2 development. Metal L2 is [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), meaning we run a slightly modified version of the same `geth` you run on mainnet. Therefore, the differences between Metal L2 development and Ethereum development are minor. -But a few differences [do exist](/stack/differences). +But a few differences [do exist](../stack/differences). ## Metal L2 and Metal L2 Testnet Endpoint URLs diff --git a/pages/connect/contribute.mdx b/pages/connect/contribute.mdx index a7cf78027..2edce77b5 100644 --- a/pages/connect/contribute.mdx +++ b/pages/connect/contribute.mdx @@ -1,6 +1,6 @@ --- title: Contribute -description: Documentation covering Docs Contribute, Stack Contribute, Style Guide in the Contribute section of the OP Stack ecosystem. +description: Documentation covering Docs Contribute, Stack Contribute, Style Guide in the Contribute section. lang: en-US --- @@ -8,10 +8,10 @@ import { Card, Cards } from 'nextra/components' # Contribute -Documentation covering Docs Contribute, Stack Contribute, Style Guide in the Contribute section of the OP Stack ecosystem. +Documentation covering Docs Contribute, Stack Contribute, Style Guide in the Contribute section. - + - + diff --git a/pages/connect/contribute/docs-contribute.mdx b/pages/connect/contribute/docs-contribute.mdx index 283178544..0faf51680 100644 --- a/pages/connect/contribute/docs-contribute.mdx +++ b/pages/connect/contribute/docs-contribute.mdx @@ -35,7 +35,7 @@ Metal L2 Docs(docs.metall2.com) is a fork of the Optimism docs, an open-source p Review the [style guide](style-guide) and follow the PR process outlined in the [contributor guidelines](https://github.com/MetalPay/metal-l2-docs/blob/main/CONTRIBUTING.md) to get started. * [Submit a bug report](https://immunefi.com/bounty/optimism/): create a report to help us improve our products and developer tooling. For more information, please read our [Security Policy](/chain/security/security-policy). -## How to work on docs.metall2.com +## How to work on Metal L2 Docs Whether you're adding to the site, creating content, or working on open issues, you'll need a [GitHub](https://github.com) account. All updates are made via the GitHub PR process. This means you create a local copy of the website, make your changes and request to merge your changes. diff --git a/pages/connect/contribute/stack-contribute.mdx b/pages/connect/contribute/stack-contribute.mdx index a1693b258..6792e54b7 100644 --- a/pages/connect/contribute/stack-contribute.mdx +++ b/pages/connect/contribute/stack-contribute.mdx @@ -39,7 +39,7 @@ The OP Stack needs YOU (yes you!) to help review the codebase for bugs and vulne ## Docs Contributions -Want a new tutorial? See something that could be a little clearer? Check out the [Metal L2 DocsContribution page](docs-contribute) for more information on how to help. No contribution is too small! +Want a new tutorial? See something that could be a little clearer? Check out the [Metal L2 Docs Contribution page](docs-contribute) for more information on how to help. No contribution is too small! ## Community Contributions diff --git a/pages/connect/contribute/style-guide.mdx b/pages/connect/contribute/style-guide.mdx index 7bf604387..06f1c0e67 100644 --- a/pages/connect/contribute/style-guide.mdx +++ b/pages/connect/contribute/style-guide.mdx @@ -8,7 +8,7 @@ import { Callout } from 'nextra/components' # Docs style guide -This Style Guide aims to assist Metal L2 contributors in writing technical content with a consistent voice, tone, and style. See the [glossary](/connect/resources/glossary) for an alphabetical listing of commonly used words, terms, and concepts used throughout the technical docs and across the OP Collective. +This Style Guide aims to assist contributors in writing technical content with a consistent voice, tone, and style. See the [glossary](/connect/resources/glossary) for an alphabetical listing of commonly used words, terms, and concepts used throughout the technical docs and across the OP Collective. * For docs-related questions or comments, create an issue in the [docs repo](https://github.com/ethereum-optimism/docs/issues). @@ -26,7 +26,7 @@ This Style Guide aims to assist Metal L2 contributors in writing technical conte ### Folder structure -The folder structure for the [docs.metall2.com](https://github.com/ethereum-optimism/docs) repository is organized into several high-level categories under the main `pages` folder such as `builders`, `chain`, `connect`, and `stack`. +The folder structure for the [docs](https://github.com/MetalPay/metal-l2-docs) repository is organized into several high-level categories under the main `pages` folder such as `builders`, `chain`, `connect`, and `stack`. The left sidebar (side navigation) is managed in the `_meta.json` file, which should be edited only for adding or deleting pages. Frequent edits may lead to merge conflicts due to ongoing content updates. Accept changes from others when committing a PR. @@ -81,7 +81,7 @@ See below for when to use title or sentence case. * Use sentence case for body content and short phrases, even when the content is a link. Sentence case means you only capitalize the first letter of the sentence.
- **Example:** If you're trying to figure out how to do something specific as a node operator, you might search our collection of [tutorials](/builders/node-operators/rollup-node) or [suggest a new one](https://github.com/ethereum-optimism/docs/issues). + **Example:** If you're trying to figure out how to do something specific as a node operator, you might search our collection of [tutorials](/builders/node-operators/rollup-node) or [suggest a new one](https://github.com/MetalPay/metal-l2-docs/issues). * Use lowercase in code snippets by default, unless the code block uses capitalization (e.g., for the name of a function or variable) and you are referring to the function or variable elsewhere within the technical documentation.
**Examples**: Run `git add` or Import `useState` @@ -323,7 +323,7 @@ Content types help manage technical content by defining the purpose and common s | Guides | Explain what things are and how they work | [Standard Bridge Guide](/builders/app-developers/bridging/standard-bridge) | | Quick Start Guides | Briefly explain how to "minimally" get started with a product, often in 30 minutes or less | [Superchain App Quick Start](/builders/app-developers/quick-start) | | Tutorials | Provide task-oriented guidance with step-by-step "learn by doing" instructions | [Bridging ERC-20 tokens with viem](/builders/app-developers/tutorials/cross-dom-bridge-erc20) | -| FAQs | Address frequently asked questions | [FAQ: OP Mainnet Security Model](/chain/security/faq) | +| FAQs | Address frequently asked questions | [FAQ: Security Model](/chain/security/faq) | | Troubleshooting | List common troubleshooting scenarios and solutions | [Troubleshooting: Run a Node](/builders/node-operators/management/troubleshooting) | | Reference | Provide deep, theoretical knowledge of the internal workings of a system, such as API endpoints and specifications | [Node and RPC Providers](/builders/tools/connect/rpc-providers) | diff --git a/pages/connect/resources.mdx b/pages/connect/resources.mdx index a4ae2c526..8f2e27ed0 100644 --- a/pages/connect/resources.mdx +++ b/pages/connect/resources.mdx @@ -1,6 +1,6 @@ --- title: Resources -description: Documentation covering Glossary in the Resources section of the OP Stack ecosystem. +description: Documentation covering Glossary in the Resources section of the Metal L2 docs. lang: en-US --- @@ -8,7 +8,7 @@ import { Card, Cards } from 'nextra/components' # Resources -Documentation covering Glossary in the Resources section of the OP Stack ecosystem. +Documentation covering Glossary in the Resources section of the Metal L2 docs. diff --git a/pages/connect/resources/_meta.json b/pages/connect/resources/_meta.json index 97804169a..77c3512d5 100644 --- a/pages/connect/resources/_meta.json +++ b/pages/connect/resources/_meta.json @@ -1,6 +1,6 @@ { "changelog": { - "title": "Changelog", + "title": "Optimism Node Changelog", "href": "https://github.com/ethereum-optimism/optimism/releases", "newWindow": true }, diff --git a/pages/connect/resources/glossary.mdx b/pages/connect/resources/glossary.mdx index 53b845871..9a862d09c 100644 --- a/pages/connect/resources/glossary.mdx +++ b/pages/connect/resources/glossary.mdx @@ -8,12 +8,12 @@ import { Callout } from 'nextra/components' # Glossary -The glossary provides definitions of important terminology used throughout the Developer Documentation. To make revisions to this page, please [submit an issue](https://github.com/ethereum-optimism/docs/issues/new?assignees=\&labels=glossary%2Cdocumentation%2Ccommunity-request\&projects=\&template=suggest_glossary_term.yaml\&title=%5BGLOSSARY%5D+Add+PR+title). +The glossary provides definitions of important terminology used throughout the Developer Documentation. ## Table of contents * [General Terms](#general-terms) -* [OP Profile & Identity](#op-profile--identity) +* [Profile & Identity](#op-profile--identity) * [OP Stack & OP Superchain](#op-stack--op-superchain) * [Protocol](#protocol) @@ -58,7 +58,7 @@ at the request of the L1 consensus layer. On L2, the executed blocks are freshly #### MTL Token -A governance token, referred to as "MTL." Content should not discuss the token price or speculate on the price. +A governance token, referred to as "MTL". Content should not discuss the token price or speculate on the price. #### Layer 1 (L1) @@ -134,7 +134,7 @@ behavior. A rollup node running in validator mode is sometimes called *a replica \[[return to top](#table-of-contents)] -## OP profile & identity +## Profile & identity #### Attestations diff --git a/pages/stack/_meta.json b/pages/stack/_meta.json index fb6fe060f..001008bb4 100644 --- a/pages/stack/_meta.json +++ b/pages/stack/_meta.json @@ -9,13 +9,5 @@ "fault-proofs": "Fault proofs", "transactions": "Transactions", "features": "Features", - "security": "Security", - "--- EXPERIMENTAL": { - "title": "EXPERIMENTAL", - "type": "separator" - }, - "opcm": "OP Contracts Manager", - "interop": "Interoperability", - "beta-features": "Beta features", - "research": "Research" + "security": "Security" } diff --git a/pages/stack/beta-features.mdx b/pages/stack/beta-features.mdx deleted file mode 100644 index 8ac25ed02..000000000 --- a/pages/stack/beta-features.mdx +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: Beta Features -description: Learn how beta features in the OP Stack work, their benefits, and how to provide feedback. -lang: en-US ---- - -import { Callout } from 'nextra/components' -import { Card, Cards } from 'nextra/components' - - - Note: All features listed here are currently in beta and under active - development. Expect changes in functionality, design, and performance as we - gather feedback and make improvements. - - -# Beta Features - -Welcome to the beta features overview. This section contains a list of the latest in-development features currently in the beta stage. Beta features are available for early access and feedback gathering, helping to refine and optimize these tools before a full release. - -These features may undergo changes based on user feedback and ongoing improvements. The functionality and design may evolve. Explore the sections below for more information on individual beta features and participation in shaping their final release. - -## What are beta features? - -Beta features are early-stage functionalities available for testing and feedback. Access to beta features provides opportunities to try new tools and provide valuable input that directly influences their final versions. - -## Benefits of using beta features - -* **Early access**: Be among the first to use the latest innovations. -* **Influence Development**: Your feedback plays a critical role in helping us refine and optimize these features. -* **Enhanced Product Understanding**: Working with beta features can provide insights into the future direction of our product and how it will evolve. - -## Key Considerations - -When using beta features, please keep the following in mind: - -* **Functionality May Vary**: Since these features are still under development, there may be occasional bugs or performance issues. -* **Limited Support**: Support for beta features may be limited, and these features are not recommended for critical production environments. -* **Continuous Updates**: Beta features will be updated frequently based on user feedback, which means they may undergo significant changes during the testing phase. - -## How to provide feedback - -Feedback from beta users helps improve and refine these features. Here's how to contribute: - -1. **Document Your Experience**: Take note of any issues, suggestions, or enhancements you'd like to see. -2. **Report Through Official Channels**: Submit feedback and bug report through the optimism [monorepo](https://github.com/ethereum-optimism/optimism/issues). -3. **Participate in Surveys**: Occasionally, we'll send surveys to beta users. Participating in these helps us prioritize improvements. - -## Available beta features - -Explore our current beta features below. Each feature includes links to detailed documentation for setup, usage, and feedback guidelines. - - - } /> - -{' '} - -} -/> - - diff --git a/pages/stack/beta-features/_meta.json b/pages/stack/beta-features/_meta.json deleted file mode 100644 index 68d1975ec..000000000 --- a/pages/stack/beta-features/_meta.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "custom-gas-token": "Custom gas token", - "alt-da-mode": "Alt-DA Mode" -} diff --git a/pages/stack/beta-features/alt-da-mode.mdx b/pages/stack/beta-features/alt-da-mode.mdx deleted file mode 100644 index 446afe4d8..000000000 --- a/pages/stack/beta-features/alt-da-mode.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: Alt-DA Mode explainer -lang: en-US -description: Learn the basic process, benefits, and considerations for running an Alt-DA mode chain. ---- - -import { Callout } from 'nextra/components' - -import { AltCallout } from '@/components/WipCallout' - - - -# Alt-DA Mode Explainer - -Alt-DA Mode enables seamless integration of various Data Availability (DA) Layers, regardless of their commitment type, into the OP Stack. This allows any chain operator to launch an OP Stack chain using their favorite DA Layer for sustainably low costs. - -## Sustainably low costs - -In order to function securely, OP Stack chains need to ensure that L2 transaction data is available to all node operators. EIP-4844 has massively reduced Ethereum L1 data costs for OP Stack rollups, but blobspace is on the path to congestion, which will lead to higher blob fees and increased chain operator costs. -Over the past few years, alternative DA Layers have been built as an alternative place for L2s to post L2 data that is cheap, with more throughput, but remains stable and minimizes security and decentralization tradeoffs. - -## How it works - -Alt-DA Mode introduces a standard interface for reading and writing data to Alt-DA Layers and allows any DA Layer team to build and maintain their own [DA Server](https://specs.optimism.io/experimental/alt-da.html#da-server) to enable the OP Stack to communicate with their DA Layer. The DA Server handles any of the custom DA Layer logic, such as key management, interfacing with a DA Layer node, etc. - -This abstraction ensures that new features and improvements to Alt-DA Mode will come to all chains using Alt-DA Mode, regardless of the DA Layer they choose to use. -Although the Data Availability Challenge (DA Challenge) will be disabled at launch, this integration provides a solution compatible with upcoming OP Stack features. - -## Future improvements - -Just like with the Rollup configuration of the OP Stack, core contributors are continuously improving the decentralization, security, and cost-effectiveness of Alt-DA Mode. Some of the future features that core contributors are looking to build are: - -* Integration with Fault Proofs -* Plasma Data Availability Challenges support for more DA Layers (currently only supports DA Layers with a `keccak256` commitment type) -* DA Bridge integrations (like Celestia Blobstream and Eigen DA Cert Verification) -* Increasing the amount of data that can be committed to in a single commitment (potentially with merklization) - -## Tradeoffs of Alt-DA Mode - -Alt-DA Mode will always have more trust assumptions than simply posting data to L1 Ethereum. In its current initial iteration, Alt-DA Mode with generic commitments fully trusts the chain operator to make data available by both posting all data to the DA Layer and posting corresponding commitments to L1 Ethereum. If a chain operator posts incorrect commitments or does not post data to the DA Layer, it will not be accessible by node operators. The future improvements mentioned above are intended to address this trust assumption. After DA Bridges are integrated, then as long as the DA Layer and its DA Bridge are decentralized and functioning as intended, then once data is posted to the DA Layer, the L1 commitments would be bridged without relying on a single trusted party. It is important to remember that, even after integrating the DA Bridges and Fault Proofs, there will still be an added trust assumption that the DA Layer and DA Bridge are secure and functioning as intended. - -## Next steps - -* Ready to get started? Read our guide on how to [deploy your Alt-DA Mode chain](/builders/chain-operators/features/alt-da-mode). -* For more info about how Alt-DA Mode works under the hood, [check out the specs](https://specs.optimism.io/experimental/alt-da.html). - -## FAQs - -### Can I deploy a chain using Ethereum L1 DA and later switch to Alt-DA? - -While it is a future goal to spec out a migration path from Ethereum L1 DA to Alt-DA Mode, the migration path has not been scoped out yet. - -### Can I deploy a chain using Alt-DA and then later switch to Ethereum L1 DA? - -Same as above, it is a future goal to spec out this migration path, but the migration path has not been scoped out yet. - -### Can I switch between Alt-DA layers when using Alt-DA Mode? - -This is technically possible today. A chain operator can start posting data to two DA Layers simultaneously during a transition period and coordinates their node operators to switch the DA Server they operate during that time. -If assistance is needed here, please reach out [via Github](https://github.com/ethereum-optimism/developers/discussions) diff --git a/pages/stack/beta-features/custom-gas-token.mdx b/pages/stack/beta-features/custom-gas-token.mdx deleted file mode 100644 index 9065976c7..000000000 --- a/pages/stack/beta-features/custom-gas-token.mdx +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: Custom Gas token explainer -lang: en-US -description: Learn the basic process, benefits, and considerations for running a custom gas token chain. ---- - -import { Callout } from 'nextra/components' -import { CGTCallout } from '@/components/WipCallout' - - - -# Custom gas token explainer - -The Custom Gas Token configuration lets OP Stack chain operators deploy their chain allowing a specific ERC-20 token to be deposited in as the native token to pay for gas fees. Chain operators can now customize their gas token to: - -* provide utility for their project's token -* make it easier to subsidize gas costs for their users directly via their token treasury -* facilitate in-game economies, allowing players to pay for gas with their in-game currency -* build alignment with the community of any token. - -## Native gas tokens - -By default, L2 OP Stack chains allow users to deposit ETH from L1 into the L2 chain as native L2 token that can then be used to pay for gas fees. -Chain operators wanted to configure the stack to use a custom token to pay for gas, other than ETH. - -With custom gas tokens, chain operators can now set an L1 ERC-20 token address at the time of deploying the contracts of their L2 chain. -When deposited, this L1 ERC-20 token will become the native gas token on the L2 and can be used to pay for gas fees. - - - **Caveats chain operators should be aware of:** - - * You cannot switch from your custom gas token to another token after the chain is launched. - * Existing chains cannot switch to use a custom gas token. A custom token must be configured at the time of chain deployment. - * You will need to manually modify your fee configuration values to properly charge fees for users. - * Understand the [constraints required for your chain to be able to join the Superchain](#considerations) when setting the custom gas token for your chain. - - -## How it works - -This is the general flow of how custom gas tokens work on the OP Stack: - -* On deployment of an L2 chain, set the address of an L1 token to be used as the gas token. -* When depositing the custom gas token to L2, it mints the native L2 token. -* Withdrawing the native L2 token results in the unlocking of the custom token on L1. -* The native L2 token is used by default to pay for gas fees. - -## Benefits - -Chain operators get the following benefits by using custom gas tokens: - -* can use an L1 ERC-20 token as the custom gas token for L2 OP Stack chain deployment -* can use an ERC-20 token on an existing L2 OP Stack chain as as the custom gas token for an L3 OP Stack chain deployment -* can use custom gas tokens with other configurations of the OP Stack, including Plasma Mode. - -## Considerations - -The custom token being used must adhere to the following constraints to be able to join the Superchain: - -* must be a valid ERC-20 token -* the number of decimals on the token MUST be exactly 18 -* the name of the token MUST be less than or equal to 32 bytes -* symbol MUST be less than or equal to 32 bytes. -* must not be yield-bearing -* cannot be rebasing or have a transfer fee -* must be transferrable only via a call to the token address itself -* must only be able to set allowance via a call to the token address itself -* must not have a callback on transfer, and more generally a user must not be able to make a transfer to themselves revert -* a user must not be able to make a transfer have unexpected side effects - - - -## Next steps - -* Ready to get started? Read our guide on how to [deploy your custom gas token chain](/builders/chain-operators/features/custom-gas-token). -* For more info about how the custom gas token feature works under the hood, [check out the specs](https://specs.optimism.io/experimental/custom-gas-token.html). - -## FAQs - -### What is the Wrapped (ERC-20) Gas Token? - -* The `WETH` predeploy at `0x4200000000000000000000000000000000000006` represents the wrapped custom gas token. If you wish to transact with your native gas token as an ERC-20, you can `deposit` and `withdraw` from this contract to wrap and unwrap your token. -* What this means is the asset at the `WETH` predeploy is not `ether` but instead is the wrapped version of your custom gas token. Its an ERC20 token, the `name()` will be `"Wrapped ..."` (whatever the name of your token is). - -### How do I charge fees as the chain operator? - -The initial release of custom gas token does not have special logic for taking into account the exchange rate between the custom gas token and ether. Currently, the protocol charges fees for users with scalars on the L1 blob fee and L1 base fee in ETH. Chain operator will be taking user fees in the custom gas token and spending in ether. - -For the initial release of custom gas token, the chain operator will need to manage this either out of band or by manually tuning the fee scalar values to capture the exchange rate between ETH and the custom gas token to ensure profitability. A future release may include [L1 Fee Abstraction](https://github.com/ethereum-optimism/specs/issues/73) where the L1 fee is calculated in a smart contract instead of native code. This would enable an on chain oracle to take into account the exchange rate of the custom gas token. - -### Can I migrate my chain into being custom gas token? - -If you are already live using `ether` to pay for gas, you cannot become a custom gas token chain. This would likely require a risky, high lift state migration that we would not recommend. - -### Do node operators need to do anything? - -There are no core changes to `op-geth` or `op-node` so the infrastructure that node operators run is exactly the same as any other OP Stack based chain. The differences are encapsulated in the smart contracts, so only the L1 contract deployments and L2 genesis generation need to be done in a particular way. diff --git a/pages/stack/interop.mdx b/pages/stack/interop.mdx deleted file mode 100644 index c601fdb88..000000000 --- a/pages/stack/interop.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Interop -description: Documentation covering Cross Chain Message, Explainer, Message Passing, Op Supervisor, Superchain Erc20, Superchain Weth, Supersim, Transfer Superchainerc20 in the Interop section of the OP Stack ecosystem. -lang: en-US ---- - -import { Card, Cards } from 'nextra/components' - -# Interop - -Documentation covering Cross Chain Message, Explainer, Message Passing, Op Supervisor, Superchain Erc20, Superchain Weth, Supersim, Transfer Superchainerc20 in the Interop section of the OP Stack ecosystem. - - - - - - - - - - - - - - - - - - - diff --git a/pages/stack/interop/_meta.json b/pages/stack/interop/_meta.json deleted file mode 100644 index 469dc5cda..000000000 --- a/pages/stack/interop/_meta.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "explainer": "Interop explainer", - "architecture": "Architecture", - "devnet": "Interop devnet", - "supersim": "Supersim Multichain Development Environment", - "cross-chain-message": "Anatomy of cross-chain message", - "message-passing": "Interop message passing", - "op-supervisor": "OP Supervisor", - "assets": "Assets" -} \ No newline at end of file diff --git a/pages/stack/interop/architecture.mdx b/pages/stack/interop/architecture.mdx deleted file mode 100644 index c068cdf61..000000000 --- a/pages/stack/interop/architecture.mdx +++ /dev/null @@ -1,144 +0,0 @@ ---- -title: Interoperability architecture -lang: en-US -description: How it works. ---- - -import { Callout } from 'nextra/components' -import Image from 'next/image' - -import { InteropCallout } from '@/components/WipCallout' - - - -# Interoperability architecture - -An OP Stack node consists of two pieces of software: a consensus client (e.g. op-node) and an execution client, which is responsible for processing user transactions and constructing blocks. Interoperability among OP Stack chains is enabled via a new service called -[*OP Supervisor*](/stack/interop/op-supervisor). Every node operator is expected to run this service in addition to the [rollup node](/builders/node-operators/architecture#rollup-node) and [execution client](/builders/node-operators/architecture#execution-client). - -```mermaid - -graph LR - - classDef chain fill:#FFE - classDef transparent fill:none, stroke:none - - subgraph chain1[OP Stack chain #1] - node1[OP Node] - super1[OP-Supervisor] - geth1[Execution Engine] - node1<-->super1<-->geth1<-->node1 - end - subgraph X[ ] - chain2[OP Stack chain #2] - chain3[OP Stack chain #3] - l1node[L1 Consensus Layer] - end - - chain2-->|log events|super1 - chain3-->|log events|super1 - l1node-->|block status|super1 - - class chain1,chain2,chain3 chain - class X transparent -``` - -OP-Supervisor holds a database of all the log events of all the chains in the interoperability cluster. -Every event can potentially initiate a cross domain message, and it is the job of OP-Supervisor to validate that the log event really happened on the source chain. -Additionally, OP-Supervisor reads information from L1's consensus layer to determine the transaction safety of L2 blocks. - -## How messages get from one chain to the other - -To understand *why* we need this additional service, it is useful to know how interop messages get from one blockchain to another. - -```mermaid - -sequenceDiagram - participant app as Application - participant src as Source Chain - box rgba(0,0,0,0.1) Destination Chain - participant dst-sup as OP-Supervisor - participant dst-geth as Execution Engine - end - app->>src: Transaction - src->>dst-sup: Log Event - note over src,dst-sup: Log Event = Initializing Message - app->>dst-geth: Transaction - dst-geth->>dst-geth: Call to CrossL2Inbox to execute or verify a message. - dst-geth->>dst-sup: Did you receive this initiating message? - dst-sup->>dst-geth: Yes - note left of dst-geth: Call is successful - dst-geth->>dst-geth: CrossL2Inbox emits ExecutingMessage. - note over dst-geth: Executing Message -``` - -Cross domain messages require two transactions. -The first transaction creates an *initiating message* on the source chain. -The second transaction creates an *executing message* on the destination chain. -This executing message could result in a contract function being executed on the destination chain. - -The initiating message is simply a log event. -Any log event on any chain that inteoperates with the destination can initiate a cross domain message. - -The transaction that receives the message on the destination chain calls a contract called [`CrossL2Inbox`](https://specs.optimism.io/interop/predeploys.html#crossl2inbox). -This call can be at the top level, directly from the externally owned account, or come through a smart contract. -The call to `CrossL2Inbox`, also known as the *executing message*, needs to [identify the initiating message uniquely](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol#L35-L42), using the chain ID of the source chain, the block number, and the index of the log event within that block, as well as a few other fields as a sanity check. - -`CrossL2Inbox` can either [validate the message exists](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol#L171-L185), or [call a contract if the message exists](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol#L171-L185). - -[For more information, see the cross-chain messages anatomy page](./cross-chain-message). - -## Safety levels - -```mermaid - -flowchart LR - classDef finalized fill:#CCC - classDef safe fill:#8F8 - classDef unsafe fill:#F89 - subgraph I[Blocks with Initiating Messages] - style I fill:none - subgraph A[Chain A] - A0[Block n] - A1[Block n+100] - A2[Block n+105] - class A0 finalized - class A1 safe - class A2 unsafe - end - subgraph B[Chain B] - B0[Block m] - B1[Block m+3] - class B0,B1 safe - end - end - subgraph C[Chain C] - C0[Block with executing messages] - class C0 unsafe - end - A0 --> C0 - A1 --> C0 - A2 --> C0 - B0 --> C0 - B1 --> C0 -``` - -Interop expands the scope of trust for unsafe blocks, blocks that are shared through [the gossip protocol](/builders/chain-operators/architecture#sequencer). -To trust that an unsafe block is valid and is going to become safe and then finalized, you need to trust not only the sequencer that produces it, but also all the other sequencers that produce other blocks that are still unsafe, but that include initiating messages that are executed in that block. - -However, this is only for *unsafe* blocks, and only if the sequencer allows messages from unsafe blocks to be processed. -A block is only considered promotable to *safe*, and therefore ready to be written to L1, when all the blocks on which it depends are safe. - -For example, in the image below, most blocks are safe. -Block `n` in chain `A` is even finalized, and immune from reorgs. -However, block `n+105` in chain `A` is unsafe, it (or a block on which it depends) is not written to L1. -Because the new block depends upon it, it is also unsafe. - -## Next steps - -* Want to learn more? - Read our guide on the anatomy of a [cross-chain message](./cross-chain-message) or check out this - [interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). -* Ready to get started? Use [Supersim](./supersim), a local dev environment that simulates interop for testing applications against a local version of the Superchain. -* For more info about how OP Stack interoperability works under the hood, - [check out the specs](https://specs.optimism.io/interop/overview.html). diff --git a/pages/stack/interop/assets.mdx b/pages/stack/interop/assets.mdx deleted file mode 100644 index 4d287b5f9..000000000 --- a/pages/stack/interop/assets.mdx +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Assets -description: Documentation covering Cross Chain Message, Explainer, Message Passing, Op Supervisor, Superchain Erc20, Superchain Weth, Supersim, Transfer Superchainerc20 in the Interop section of the OP Stack ecosystem. -lang: en-US ---- - -import { Card, Cards } from 'nextra/components' - -# Interop - -Documentation covering SuperchainERC20, Superchain WETH, Supersim, and how to transfer a SuperchainERC20. - - - - - - - - - - - - diff --git a/pages/stack/interop/assets/_meta.json b/pages/stack/interop/assets/_meta.json deleted file mode 100644 index 1db8c901e..000000000 --- a/pages/stack/interop/assets/_meta.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "superchain-erc20": "SuperchainERC20", - "transfer-superchainERC20": "How to transfer a SuperchainERC20", - "deploy-superchain-erc20": "Deploy assets using SuperchainERC20", - "superchainerc20-best-practices": "SuperchainERC20 best practices", - "superchain-weth": "SuperchainWETH (Interoperable ETH)" -} \ No newline at end of file diff --git a/pages/stack/interop/assets/deploy-superchain-erc20.mdx b/pages/stack/interop/assets/deploy-superchain-erc20.mdx deleted file mode 100644 index 1da6522b5..000000000 --- a/pages/stack/interop/assets/deploy-superchain-erc20.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Deploy assets using SuperchainERC20 -lang: en-US -description: Learn about the basic details of deploying assets on SuperchainERC20 ---- - -import { Callout } from 'nextra/components' -import { Steps } from 'nextra/components' - -# Issuing new assets with SuperchainERC20 - - - Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. - - -This guide explains how to issue new assets with the `SuperchainERC20` and bridge them effectively using the `SuperchainERC20Bridge`. If you want more information about the `SuperchainERC20 standard`, see our [`SuperchainERC20` standard explainer](/stack/interop/assets/superchain-erc20) - -Note that bridging assets through the Superchain using `SuperchainERC20` never affects the total supply of your asset. The supply remains fixed, and bridging only changes the chain on which your asset is located. This keeps the token's total amount the same across all networks, ensuring its value stays stable during the move and that the `SuperchainERC20` retains a unified, global supply count. - -## Steps to issue and bridge assets - - - ### Deploy the `SuperchainERC20` Token Contract - - To ensure fungibility across chains, the SuperchainERC20 assets need to have the same contract address on all chains. Achieving this requires deterministic deployment methods, such as: - - * `Create2Deployer`: A smart contract that enables deploying contracts with predictable addresses. - * `OptimismSuperchainERC20Factory`: A factory contract designed for L1-native tokens to ensure uniform deployments across chains. - - There are [many ways to do this](https://github.com/Arachnid/deterministic-deployment-proxy), but [here's an example smart contract to start](https://github.com/ethereum-optimism/superchainerc20-starter/blob/main/packages/contracts/src/L2NativeSuperchainERC20.sol). For an in-depth guide on how to deploy a `SuperchainERC20` use the [SuperchainERC20 Starter Kit](https://console.optimism.io/build). - - By deploying assets at identical addresses across multiple chains, we abstract away the complexity of cross-chain validation. - - ### Implement the IERC7802 interface - - Implementations of `SuperchainERC20` will be required to implement the [IERC7802](https://specs.optimism.io/interop/token-bridging.html#ierc7802) interface, that includes two external functions and two events. - - The interface defines two functions for bridging: - - * `sendERC20`: Initializes a cross-chain transfer of a `SuperchainERC20` by burning the tokens locally and sending a message to the `SuperchainERC20Bridge` on the target chain using the `L2toL2CrossDomainMessenger`. This ensures that asset supply remains constant, as sending an asset moves it from one chain to another without creating additional supply. - * `relayERC20`: Processes incoming messages from the L2toL2CrossDomainMessenger and mints the corresponding amount of the SuperchainERC20. - - [Here's an example implementation of the `SuperchainERC20Bridge`](https://specs.optimism.io/interop/token-bridging.html#implementation) - - -## Next steps -* Use the [SuperchainERC20 Starter Kit](https://console.optimism.io/build) to deploy your token across the Superchain -* Explore the [SuperchainERC20 specifications](https://specs.optimism.io/interop/token-bridging.html) for in-depth implementation details. -* Review the [Superchain Interop Explainer](../explainer) for answers to common questions about interoperability. diff --git a/pages/stack/interop/assets/superchain-erc20.mdx b/pages/stack/interop/assets/superchain-erc20.mdx deleted file mode 100644 index 7d5077e45..000000000 --- a/pages/stack/interop/assets/superchain-erc20.mdx +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: SuperchainERC20 -lang: en-US -description: Learn about the basic details of the SuperchainERC20 implementation. ---- - -import { Callout } from 'nextra/components' - -# SuperchainERC20 - - - Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. - - -`SuperchainERC20` is an implementation of [ERC-7802](https://ethereum-magicians.org/t/erc-7802-crosschain-token-interface/21508) designed to enable asset interoperability in the Superchain. -Asset interoperability allows for tokens to securely move across chains without asset wrapping or liquidity pools for maximal capital efficiency, thus unifying liquidity and simplifying the user experience. - -Additional features: - -* **Simplified deployments**: 0-infrastructure cost to make your token cross-chain. Provides a consistent, unified implementation for tokens across all Superchain-compatible networks and a common cross-chain interface for the EVM ecosystem at large. -* **Permissionless propagation**: Easily clone an existing token contract to a new OP Stack chain using `create2` without requiring the original owner, which enables movement of assets to the new chain once Interop goes live. Importantly, permissionless propagation retains the integrity of the original owner on the contract and preserves security but proliferates the contract's availability to new chains. -* **Common standard**: Implements ERC-7802, a unified interface that can be used across all of Ethereum to enable cross-chain mint/burn functionality. - -## How it works - -`SuperchainERC20` facilitates secure token transfers between chains in the Superchain networks via native burning and minting. - -* **Token Burning**: Initiating message where token is **burned** on the source chain. A user initiates a transfer of token from one blockchain to another and specifies the recipient wallet address on the destination chain. A specified amount of token is burned on the source chain. -* **Token Minting**: Executing message where token is **minted** on the destination chain. The specified amount of token is minted on the destination chain directly to the recipient wallet address. - -An important thing to note is using `crosschainBurn` and `crosschainMint` on the `SuperchainERC20` to move your asset across the Superchain only affects which chain your asset is located on and does not change the overall supply of the token. This keeps the token's total amount the same across all networks, ensuring its value stays stable during the move and that the `SuperchainERC20` retains a unified, global supply count. - -```mermaid -sequenceDiagram - box rgba(255, 4, 32, 0.1) ChainA - participant User-chainA - participant SuperchainERC20-chainA - participant SuperchainERC20Bridge-chainA - end - box rgba(248, 61, 213, 0.1) ChainB - participant SuperchainERC20Bridge-chainB - participant SuperchainERC20-chainB - participant User-chainB - end - - - User-chainA->>SuperchainERC20-chainA: Initiate token transfer - SuperchainERC20-chainA->>SuperchainERC20Bridge-chainA: Bridge to chainB - SuperchainERC20Bridge-chainA->>SuperchainERC20-chainA: Burn tokens - SuperchainERC20Bridge-chainA-->>SuperchainERC20Bridge-chainA: Emit cross-chain event - SuperchainERC20Bridge-chainB-->>SuperchainERC20Bridge-chainB: Validates message - SuperchainERC20Bridge-chainB-->>SuperchainERC20-chainB: Mint tokens - SuperchainERC20-chainB->>User-chainB: User receives tokens -``` - -This diagram illustrates the process where tokens are burned on the source chain and minted on the destination chain, enabling seamless cross-chain transfers without the need for asset wrapping or liquidity pools. - -## Major components - -* **Token Contract**: implements `SuperchainERC20` with bridging functionality. -* **Factory Predeploy**: uses a `create2`-based factory for deploying `SuperchainERC20` tokens consistently across chains. -* **Bridging Functions**: using methods like `sendERC20` and `relayERC20` for cross-chain transfers. - -## Comparison to other token implementations - -`SuperchainERC20` differs from other token implementations in its focus and implementation: - -* `SuperchainERC20` implements ERC-7802, which provides a minimal crosschain mint/burn interface designed to be a common pattern for the EVM ecosystem. -* `SuperchainERC20` shares trust assumptions across all chains in the Superchain, such that custom assumptions around security and latency are not required to account for when executing transfers. - - - Projects moving from other token implementations may need to adapt to the `SuperchainERC20` specification. - - -## Implementation details - -Application developers must do two things to make their tokens `SuperchainERC20` compatible. Doing this setup now ensures that tokens can benefit from Interop once the Interop upgrade happens. - -1. Permission only `SuperchainERC20Bridge` to call `crosschainMint` and `crosschainBurn`. -2. Deployment at same address on every chain in the Superchain using `create2` function. - -For now, application developers should view `SuperchainERC20`as ERC20 tokens with additional built-in functions that allow cross-chain asset movement that will be enabled once Interop goes live. - -For step-by-step information on implementing SuperchainERC20, see [Deploy assets using SuperchainERC20](/stack/interop/assets/deploy-superchain-erc20) - - - To enable asset interoperability, `SuperchainERC20` must give access to the address where the future `SuperchainERC20Bridge` will live. - - -## Next steps - -* Explore the [SuperchainERC20 specifications](https://specs.optimism.io/interop/token-bridging.html) for in-depth implementation details. -* Check out the [Superchain ERC20 starter kit](https://github.com/ethereum-optimism/superchainerc20-starter) to get started with implementation. -* Watch the [Superchain interop design video walkthrough](https://www.youtube.com/watch?v=FKc5RgjtGes) for a visual explanation of the concepts. -* Review the [Superchain Interop Explainer](../explainer) for answers to common questions about interoperability. diff --git a/pages/stack/interop/assets/superchain-weth.mdx b/pages/stack/interop/assets/superchain-weth.mdx deleted file mode 100644 index bef20fc98..000000000 --- a/pages/stack/interop/assets/superchain-weth.mdx +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: SuperchainWETH (Interoperable ETH) -lang: en-US -description: Learn basic details about SuperchainWETH or Interoperable ETH. ---- - -import { Callout } from 'nextra/components' - -# SuperchainWETH (Interoperable ETH) - - - Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. - - -Superchain WETH or Interoperable ETH is a specialized version of the standard WETH (Wrapped Ether) contract designed to enable seamless movement of ETH across the Superchain. It addresses the liquidity constraints and usability issues that arise when transferring ETH between different chains. - -## Features and benefits - -* Enables seamless ETH transfers across different chains in the Superchain -* Maintains fungibility of ETH across the Superchain -* Provides liquidity for cross-chain transactions -* Improves user experience by abstracting complex bridging processes - - - The `SuperchainTokenBridge` can only rebalance assets across chains. It cannot mint or increase/decrease the total circulating supply. - - -## How it works - -Currently, L2-to-L2 ETH transfers between two interoperable chains require four separate transactions: - -1. Wrap `ETH` to `SuperchainWETH`. -2. Call `SuperchainTokenBridge#SendERC20` to burn `SuperchainWETH` on source chain and relay a message to the destination chain that mints `SuperchainWETH` to the recipient (`crosschainBurn` is used). -3. Execute the message on the destination chain, triggering `SuperchainTokenBridge#RelayERC20` to mint `SuperchainWETH` to the recipient (`crosschainMint` is used). If the destination is a non-custom gas token chain, ETH is sourced from the `ETHLiquidity` contract. -4. Unwrap the received `SuperchainWETH` to `ETH`. - - -Abstraction is a possible future consideration to reduce this process to two transactions, which can be followed in the [design docs](https://github.com/ethereum-optimism/design-docs/pull/146/files). - - -```mermaid -sequenceDiagram - participant User - participant Source Chain - participant Cross-Chain Messenger - participant Destination Chain - - User->>Source Chain: 1. Wrap ETH to SuperchainWETH - Source Chain->>Cross-Chain Messenger: 2. Burn SuperchainWETH and relay message - Cross-Chain Messenger->>Destination Chain: 3. Mint SuperchainWETH to recipient - User->>Destination Chain: 4. Unwrap SuperchainWETH to ETH -``` -_Figure 1: Superchain WETH transfer process between two interoperable L2 chains._ - - - `crosschainBurn` and `crosschainMint`can only be called by the `SuperchainTokenBridge`. - - -## Major components - -### `SuperchainWETH` contract - -This contract implements the core functionality for wrapping, unwrapping, and cross-chain transfer of ETH. It integrates with the `SuperchainTokenBridge` for interoperable actions. - -* Contract address: `0x4200000000000000000000000000000000000024` - -### `ETHLiquidity` contract - -A predeploy contract with a large pool of ETH that provides liquidity for cross-chain transfers. It allows "burning" and "minting" of ETH for cross-chain transfers. ETH is associated with bridge ETH from the L1 lockbox, making ETH available to interop chains through a shared lockbox rather than fragmented amongst the existing portal contracts. - -* Contract address: `0x4200000000000000000000000000000000000025` - -### `L2ToL2CrossDomainMessenger` contract - -This predeploy contract facilitates general message passing between different chains in the Superchain. It also securely transfers ERC20 tokens between L2 chains. - -* Contract address: `0x4200000000000000000000000000000000000023` - - - `SuperchainWETH` implements strict access controls to ensure security (e.g., only `SuperchainWETH` can call `ETHLiquidity` functions). - - -## Next steps - -* Explore the [`SuperchainWETH`](https://specs.optimism.io/interop/superchain-weth.html) specs for in-depth implementation details. -* Review the [Superchain Interop Explainer](../explainer) for answers to common questions about interoperability. diff --git a/pages/stack/interop/assets/superchainerc20-best-practices.mdx b/pages/stack/interop/assets/superchainerc20-best-practices.mdx deleted file mode 100644 index d1127a305..000000000 --- a/pages/stack/interop/assets/superchainerc20-best-practices.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Best practices for managing SuperchainERC20 tokens -lang: en-US -description: Essential best practices for deploying and managing SuperchainERC20 assets across Superchain networks. ---- - -# Best practices for managing SuperchainERC20 tokens - -The following best practices are essential for deploying and managing `SuperchainERC20` assets across the Superchain. These guidelines help ensure optimal cross-chain functionality. - -Note that the total supply of your tokens never fluctuates across the Superchain. Cross-chain burning and minting only affects the location of a token across the Superchain. - -## Consistent addresses across chains - -Use predefined addresses: Assign and verify the same address for each `SuperchainERC20` instance on every chain. Predefined addresses reduce deployment conflicts and ensure tokens are accurately recognized across chains. Otherwise, the SuperchainERC20Bridge would need a way to verify if the tokens they mint on destination correspond to the tokens that were burned on source. - -Consider using `Create2Deployer` or one of our [predeploys](https://specs.optimism.io/interop/predeploys.html) to ensure this. - -## Testing before mainnet deployment - -Test with production-like conditions: Deploy to staging environments that simulate mainnet conditions, especially for functions like `crosschainBurn` and `crosschainMint`. Test under realistic transaction loads to validate performance. - -We recommend using [Supersim](https://supersim.pages.dev/introduction) as an easy way to simulate the Superchain and test your SuperchainERC20 deployment. - -Test edge cases such as maximum balance transfers and interchain latency to ensure asset reliability across different scenarios. - -## Next steps - -* Explore the [SuperchainERC20 specifications](https://specs.optimism.io/interop/token-bridging.html) for in-depth implementation details. -* Watch the [Superchain interop design video walkthrough](https://www.youtube.com/watch?v=FKc5RgjtGes) for a visual explanation of the concepts. -* Review the [Superchain Interop Explainer](../explainer) for answers to common questions about interoperability. diff --git a/pages/stack/interop/assets/transfer-superchainERC20.mdx b/pages/stack/interop/assets/transfer-superchainERC20.mdx deleted file mode 100644 index 9a17dcacd..000000000 --- a/pages/stack/interop/assets/transfer-superchainERC20.mdx +++ /dev/null @@ -1,117 +0,0 @@ ---- -title: How to transfer a SuperchainERC20 -lang: en-US -description: Learn how to transfer a SuperchainERC20 between chains using L2ToL2CrossDomainMessenger. ---- - -import { Callout, Steps } from 'nextra/components' - -# How to transfer a SuperchainERC20 - - - Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. - - -This guide provides an overview of transferring `SuperchainERC20` tokens between chains. - -## Overview - -Transferring SuperchainERC20 tokens between chains involves two main phases: - -1. **Source Chain Operations** - * Mint tokens if needed - * Initiate the transfer using the bridge -2. **Destination Chain Operations** - * Relay the transfer message - * Verify the transfer completion - - - Always verify your addresses and amounts before sending transactions. Cross-chain transfers cannot be reversed. - - -## How it works - -This diagram illustrates the process of a SuperchainERC20 token transfer between chains. -Through the `L2ToL2CrossDomainMessenger` contract, tokens are burned on the source chain and a transfer message is emitted. -This message must then be relayed to the destination chain, where an equivalent amount of tokens will be minted to the specified recipient address - ensuring secure cross-chain transfers while maintaining the total token supply across all chains. - -```mermaid -sequenceDiagram - actor User - participant SourceChain - participant Bridge as L2ToL2CrossDomainMessenger - participant DestChain - - Note over User,DestChain: Step 1: Prepare Tokens - User->>SourceChain: Check token balance - alt - User->>SourceChain: Mint or acquire tokens - end - - Note over User,DestChain: Step 2: Initiate Transfer - User->>SourceChain: Approve bridge contract - User->>Bridge: Call sendERC20 - Bridge->>SourceChain: Burn tokens - Bridge-->>Bridge: Emit transfer message - - Note over User,DestChain: Step 3: Complete Transfer - User->>Bridge: Get message details - User->>Bridge: Relay message on destination - Bridge->>DestChain: Mint tokens to recipient - - Note over User,DestChain: Step 4: Verify - User->>DestChain: Check token balance -``` - - - ### Step 1: Prepare your tokens - - Ensure you have tokens on the source chain using one of these methods: - - * Use existing tokens you already own - * Mint new tokens using the [SuperchainERC20](https://github.com/ethereum-optimism/supersim/blob/main/contracts/src/L2NativeSuperchainERC20.sol) contract if you have minting permissions - * Acquire tokens through a supported exchange or transfer - - ### Step 2: Initiate the transfer - - To start the transfer: - - 1. Choose the destination chain where you want to receive the tokens - 2. Specify the recipient address and the amount to transfer - 3. Call the bridge contract, which will: - * Lock or burn your tokens on the source chain - * Emit a message that will be used to mint tokens on the destination chain - - ### Step 3: Complete the transfer - - To finalize the transfer on the destination chain: - - 1. Get the message details from the source chain event - 2. Use the `L2ToL2CrossDomainMessenger` contract to relay the message - 3. The message relay will trigger the minting of tokens on the destination chain - - - The transfer isn't complete until the message is successfully relayed on the destination chain. See the [technical reference guide](https://supersim.pages.dev/guides/interop/cast) for specific relay instructions. - - - ### Step 4: Verify completion - - After relaying the message: - - 1. Check your token balance on the destination chain - 2. Confirm the transferred amount matches what you sent - 3. The tokens should now be available for use on the destination chain - - -For detailed technical instructions including contract addresses, specific commands, and message relaying details, refer to our [technical reference guide](https://supersim.pages.dev/guides/interop/cast). - -## Alternative methods - -You can also use: - -* [viem bindings/actions](https://supersim.pages.dev/guides/interop/viem) for TypeScript integration - -## Next steps - -* Read the [Superchain Interop Explainer](/stack/interop/explainer#faqs) or check out this [Superchain interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes) -* Use [Supersim](../../interop/supersim), a local dev environment that simulates Superchain interop for testing applications against a local version of the Superchain diff --git a/pages/stack/interop/cross-chain-message.mdx b/pages/stack/interop/cross-chain-message.mdx deleted file mode 100644 index 9353d563d..000000000 --- a/pages/stack/interop/cross-chain-message.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Anatomy of a cross-chain message -lang: en-US -description: Learn how cross-chain messaging works with OP Stack interoperability. ---- - -import { Callout } from 'nextra/components' -import Image from 'next/image' - -# Anatomy of a cross-chain message - -A cross-chain message refers to any communication sent using Superchain interop. This includes messages sent between different chains within an interop cluster, as well as messages sent on a single chain for interoperable. This functionality enables asset transfers that utilize the [SuperchainERC20](assets/superchain-erc20) token standard. - -## How it works - -To send a cross-chain message on the Superchain using [Superchain interoperability](explainer), these two aspects must be in place: - -1. Each interoperable chain runs a verifying node for each chain in the interoperable set. -2. Each cross-chain message has an **initiating transaction** on the source chain and a **finalizing transaction** on the destination chain. - * **First/initiating transaction:** is submitted to the source chain and emits an event that can be consumed on a destination chain. - * **Second/finalizing transaction:** is submitted to a destination chain, where the block builder should only include it if certain that the first transaction was included in the source chain. The block builder can use OP-Supervisor to determine the integrity of the initiating message. Anyone can submit the second transaction. - - There is no strict requirement that the executing message is ever submitted. See the specs for details on tracing the [executing message event](https://specs.optimism.io/interop/predeploys.html#executingmessage-event). - - -
- -Anatomy of Cross-Chain Message with Interop - -In the example above, `Ox123` sends 1 OP from OP Mainnet to Base, but this applies to any asset using the SuperchainERC20 token standard. - -## Next steps - -* More questions? Check out the FAQ section in the [Superchain Interop Explainer](explainer#faqs) or check out this [Superchain interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). -* Ready to get started? Use [Supersim](supersim), a local dev environment that simulates Superchain interop for testing applications against a local version of the Superchain. -* For more info about how Superchain interoperability works under the hood, [check out the specs](https://specs.optimism.io/interop/overview.html). diff --git a/pages/stack/interop/devnet.mdx b/pages/stack/interop/devnet.mdx deleted file mode 100644 index 3edbca365..000000000 --- a/pages/stack/interop/devnet.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: Interop devnet -lang: en-US -description: Details on the public interoperability devnets. ---- - -import { Callout, Tabs, Steps } from 'nextra/components' - -# Interop devnet - - - Interop devnet is currently in active development and may experience periods of instability, including potential outages, as the networks is regularly updated and improved. Developers should expect some level of unreliability when interacting with the devnet. The devnet is intended for testing and development purposes only, and should not be relied upon for mission-critical applications. - - -The Interop devnet is a temporary public network of two OP Stack Sepolia instances that supports SuperERC20 tokens, native cross-chain messaging, and cross-chain ETH transfers. As we iterate on Superchain interop, these networks will be deprecated once the next devnets are released. - -NOTE: The current Interop devnet has been deprecated. This page will be updated once the next Interop devnet is live. - -## Interop devnet 0 - -| Parameter | Value | -| --------------------------- | ----- | -| Network Name | `TBA` | -| Chain ID | `TBA` | -| Currency Symbol1 | ETH | -| Explorer | 'TBA' | -| Public RPC URL | 'TBA' | -| Sequencer URL | 'TBA' | -| OptimismPortal2 | `TBD` | - -## Interop devnet 1 - -| Parameter | Value | -| --------------------------- | ----- | -| Network Name | `TBA` | -| Chain ID | `TBA` | -| Currency Symbol1 | ETH | -| Explorer | 'TBA' | -| Public RPC URL | 'TBA' | -| Sequencer URL | 'TBA' | -| OptimismPortal2 | `TBD` | - -1. The "currency symbol" is required by some wallets like MetaMask. -2. The `OptimismPortal` is a low-level contract responsible for passing messages between L1 and L2. Messages sent directly to the `OptimismPortal` have no form of replayability. You can send ether directly to the portal to receive it to the sender address on the L2. - -## Sending ETH to the interop devnets - - - ### Get Sepolia ETH - - You can utilize the [Superchain Faucet](https://console.optimism.io/faucet) to get ether on Sepolia. - - ### Send the Sepolia ETH to the devnet - - You can send ether directly to the `OptimismPortal` address and it will go to the same sender address on the devnet. - - ### Wait for bridging to complete - - It'll take approximately 2 minutes for the bridging process to complete and the ether to appear in your wallet. - - -## Next steps - -* Want to start with local development? Use [Supersim](/stack/interop/supersim), a local dev environment that simulates interop for testing applications against a local version of the Superchain. -* Read about [interop message passing](/stack/interop/cross-chain-message) to see how you can implement it yourself on this devnet. diff --git a/pages/stack/interop/explainer.mdx b/pages/stack/interop/explainer.mdx deleted file mode 100644 index e54633110..000000000 --- a/pages/stack/interop/explainer.mdx +++ /dev/null @@ -1,132 +0,0 @@ ---- -title: Interoperability explainer -lang: en-US -description: Learn the basics of interoperability on the OP Stack. ---- - -import { Callout } from 'nextra/components' -import Image from 'next/image' - -import { InteropCallout } from '@/components/WipCallout' - - - -# Interoperability explainer - -The Oracle problem states that a blockchain can only be certain about information generated by that chain. But what about information that happens outside that blockchain, how do you verify what happens somewhere else? - -Interoperability is the ability for a blockchain to securely read the state of another blockchain. -Native OP Stack interoperability provides the ability to read messages and transfer assets across chains in the Superchain (without having to go through L1) via low-latency, secure message passing. This results in the following benefits: -* 1-block latency asset movement that is both maximally capital efficient and non-fragmenting -* improved user experience for developers on the Superchain -* secure transfer of ETH and ERC-20s across L2s -* horizontally scalable applications - -In a practical sense, this allows users to securely and easily move ETH and tokens from one OP Stack chain to another by leveraging OP governed blockspace security. -## Secure message passing -Superchain interop includes both the protocol layer message passing and the Superchain ERC20 token specification. - -* **Message passing protocol:** the initial + finalizing/executing [message](cross-chain-message) that fire events to be consumed by the chains in the [dependency set](https://specs.optimism.io/interop/dependency-set.html) -* **SuperchainERC20 token specification**: the [SuperchainERC20](assets/superchain-erc20) turns message passing into asset transfer between chains in the interop set. Learn more about how the SuperchainERC20 token standard enables asset interoperability in the Superchain [here](/stack/interop/assets/superchain-erc20) - -This means ETH and ERC-20s can seamlessly and securely move across L2s, and intent-based protocols (i.e., bridges) can build better experiences on top of the message passing protocol. - -## Low latency -Interoperability allows for horizontally scalable blockchains, a key feature of the Superchain. With Superchain interop, latency can be 1-block (~2 seconds) by optimistically accepting cross-chain messages. - -## Interop clusters -The interop protocol works via a dependency set which is configured on a per-chain basis. The dependency set defines the set of chains that a chain will accept incoming messages from. - -This gives the OP Stack an unopinionated and flexible foundation, so chain operators can choose which chains their chains depend on, and it is not a requirement that chains are in each other's dependency set. - -## Superchain interop cluster -The Superchain builds on top of the interop protocol and implements a single mesh network with complete dependencies. In this model, each blockchain in the Superchain interop cluster would have direct connections to every other blockchain, creating a fully connected mesh network. Compared to a hub and spoke model, this provides the highest level of interoperability, as any blockchain can transact directly with any other. - -Each blockchain in the Superchain interop cluster shares the same security model to mitigate the weakest-link scenario. As outlined in the [Standard Rollup Charter](https://gov.optimism.io/t/season-6-standard-rollup-charter-ratification/8135#p-36758-governing-policies-11), these chains share the same L1 `ProxyAdmin` Owner. Any changes to the Superchain interop cluster must follow the standard Protocol Upgrade vote procedure—the established governance process for Superchain modifications. - - -## New predeploys - -The following predeploys have been added to enable interoperability. Predeployed smart contracts exist at predetermined addresses in the genesis state. They are similar to precompiles but instead run directly in the EVM instead of running native code outside the EVM. - -### CrossL2Inbox - -The `CrossL2Inbox` is the system predeploy for cross chain messaging. Anyone can trigger the execution or validation of cross chain messages, on behalf of any user. - -* **Address:** `0x4200000000000000000000000000000000000022` -* **Specs:** [CrossL2Inbox](https://specs.optimism.io/interop/predeploys.html#crossl2inbox) - -### L2ToL2CrossDomainMessenger - -The `L2ToL2CrossDomainMessenger` is a higher level abstraction on top of the `CrossL2Inbox` that provides general message passing, utilized for secure transfers ERC20 tokens between L2 chains. Messages sent through the `L2ToL2CrossDomainMessenger` on the source chain receive both replay protection and domain binding, ie the executing transaction can only be valid on a single chain. - -* **Address:** `0x4200000000000000000000000000000000000023` -* **Specs:** [L2ToL2CrossDomainMessenger](https://specs.optimism.io/interop/predeploys.html#l2tol2crossdomainmessenger) - -### OptimismSuperchainERC20Factory - -The `OptimismSuperchainERC20Factory` creates ERC20 contracts that implement the SuperchainERC20 standard, grants mint-burn rights to the `L2StandardBridge` (`OptimismSuperchainERC20`), and includes a remoteToken variable. These ERC20s are called `OptimismSuperchainERC20` and can be converted back and forth with `OptimismMintableERC20` tokens. The goal of the `OptimismSuperchainERC20` is to extend functionalities of the `OptimismMintableERC20` so that they are interop compatible. - -* **Address:** `0x4200000000000000000000000000000000000026` -* **Specs:** [OptimismSuperchainERC20Factory](https://specs.optimism.io/interop/predeploys.html#optimismsuperchainerc20factory) - - -### BeaconContract - -The `BeaconContract` predeploy gets called by the `OptimismSuperchainERC20` BeaconProxies deployed by the SuperchainERC20Factory. The Beacon Contract implements the interface defined in [EIP-1967](https://eips.ethereum.org/EIPS/eip-1967). - -* **Address:** `0x4200000000000000000000000000000000000027` -* **Specs:** [BeaconContract](https://specs.optimism.io/interop/predeploys.html#beaconcontract) - -### SuperchainERC20Bridge - -The `SuperchainERC20Bridge` is an abstraction on top of the `L2toL2CrossDomainMessenger` that facilitates token bridging using interop. It has mint and burn rights over `SuperchainERC20` tokens, as described in the [token bridging spec](https://specs.optimism.io/interop/token-bridging.html). - -* **Address:** `0x4200000000000000000000000000000000000028` -* **Specs:** [SuperchainERC20Bridge](https://specs.optimism.io/interop/predeploys.html#superchainerc20bridge) -## Considerations -Chain operators will need to run additional infrastructure to be part of the interoperable set. -* The Superchain-backend service, [`op-supervisor`](op-supervisor), will be a requirement for running an OP Stack chain that has interop enabled. -`op-supervisor` is responsible for validating all cross-chain messages and will need to have an RPC configured for each chain in the dependency set. -* In the future, to reduce infrastructure costs, `op-supervisor` will rely on the P2P network and cryptographic schemes for validating cross-chain messages. - - -For additional considerations, join the [Interop discussion](https://github.com/ethereum-optimism/specs/discussions/128) in our specs repo. - - -## Next steps -* Want to learn more? Read our guide on the anatomy of a [cross-chain message](cross-chain-message) or check out this [interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). -* Ready to get started? Use [Supersim](supersim), a local dev environment that simulates interop for testing applications against a local version of the Superchain. -* For more info about how OP Stack interoperability works under the hood, [check out the specs](https://specs.optimism.io/interop/overview.html). - -## FAQs - -### What is the latency/security tradeoff? -If a sequencer does not want to trust another sequencer at all, they can choose to only accept executing messages where the initiating message has been finalized with L1 levels of security. This demonstrates the difference in latency vs speed. The L2 data must be submitted to L1 and then the L1 block containing the transaction with the L2 data must be finalized. It takes about 15 minutes for an L1 block to finalize, and higher throughput OP Stack chains like Base and OP Mainnet submit a batch about every 5 minutes. This means that it could take about 20 minutes for an L2 transaction to be considered final and be able to be trustlessly consumed by another chain. At lower latencies, the sequencer accepting the executing message takes on some amount of equivocation risk. It could be possible to build a bonding system to add economic security to prevent equivocation, but that is not in the scope of the first release. - -See this [dune dashboard](https://dune.com/oplabspbc/op-stack-chains-l1-activity#submission-frequency) to see how often OP Stack chains submit batches. - -
- -Safe and Unsafe Security Diagram - -### What is stopping a sequencer from censoring a cross-chain message? -There is nothing stopping a sequencer from censoring a transaction when it is sent directly to the sequencer. This does not mean the network has no censorship resistance, users can always send a deposit transaction for censorship resistance as strong as L1 guarantees. The tradeoff here is the latency, instead of being confirmed in ~2 seconds, the transaction can be confirmed at the rate of L1 block production. It may be possible to adopt something like [EIP-7547](https://eips.ethereum.org/EIPS/eip-7547) in the future to enable low latency censorship resistance. - -### What is the weakest link scenario? -Without shared security, there is a risk that interacting chains could enter a conflicting state due to cross-chain interactions. If a weaker chain in the network is attacked or experiences a reorganization, it could change its state independently. This would leave the entire interop cluster in an inconsistent state, as the security of interactions across chains is only as strong as the weakest chain. - -### Are callback style transactions possible? -If two blocks are being built at the same time with shared knowledge of their contents, it is possible to build blocks where a transaction calls to another chain, does compute and then a transaction calls back with the results. This requires no protocol level changes, it just requires more sophisticated block builder infrastructure. - -### What is stopping a shared sequencer from including just the executing message and not the initiating message? -The protocol enforces the fact that all executing messages are valid. It does this by reorganizing out executing messages that have invalid initiating messages. Running software that does not enforce this would be non-standard behavior and would leave yourself at risk of accepting an invalid executing message and therefore running on a forked chain. - -### What is the trust/verification model? Do sequencers that opt into this interop system have to trust each other fully? -Sequencers only have to trust each other, if they are accepting executing messages where the initiating message is unsafe. This is because the sequencer's ability to equivocate on unsafe data, i.e., batch submit something different from what they gossip over the p2p network. Once data is submitted to L1, it is considered final relative to the L2 and therefore there is no longer an equivocation risk. - -### Is interop different between chains with non-fungible blockspace? -Chains that have non-fungible blockspace are chains that have different features - it could be that they use Plasma for data availability, a custom gas paying token or have a large execution gas limit. As long as the chain can be fault proven, it can work with Superchain interoperability. At the application layer, it is important for chains to have legibility into the type of chain that the message originated from. This ensures that applications do not accept messages from chains they consider not secure enough. See this [discussion](https://github.com/ethereum-optimism/specs/issues/121) for additional thoughts. - -When it comes to chains that have different gas limits that are interoperable, it creates a set of transactions that can execute on one chain but not the other. This happens when the transaction consumes more than the gas limit of the smaller chain but less than of the bigger chain. At 2024 usages levels, these sorts of transactions are very rare. In the future, it may be the case that these transactions become more common, it will be up to the chain operators to ensure quality of service for their users. - diff --git a/pages/stack/interop/message-passing.mdx b/pages/stack/interop/message-passing.mdx deleted file mode 100644 index b12542fcd..000000000 --- a/pages/stack/interop/message-passing.mdx +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: Interop message passing overview -lang: en-US -description: Learn about cross-chain message passing in the Superchain. ---- - -import { Callout, Steps } from 'nextra/components' - -# Interop message passing overview - - - Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. - - -This guide provides an overview of cross-chain message passing in the Superchain. - -## Overview - -The Superchain uses a pull-based event system for cross-chain communication. Messages are sent through the `L2ToL2CrossDomainMessenger` contract, which provides a secure and standardized way to pass information between chains. - -## How it works - -The following diagram illustrates how messages flow between chains through the `L2ToL2CrossDomainMessenger` contract, which acts as a bridge for cross-chain communication. When a contract on the source chain initiates a message, it's processed through several stages before reaching its destination, ensuring secure and reliable message delivery. - -```mermaid -sequenceDiagram - participant Source as Source Chain - participant Messenger as L2ToL2CrossDomainMessenger - participant Dest as Destination Chain - - Note over Source,Dest: Message Creation - Source->>Messenger: Emit message event - Note over Source,Dest: Message Serialization - Messenger-->>Messenger: Convert to standard format - Note over Source,Dest: Identifier Creation - Messenger-->>Messenger: Generate unique ID - Note over Source,Dest: Message Execution - Messenger->>Dest: Process message -``` - -Cross-chain messaging involves four main phases: - -1. **Message Creation**: The source chain contract emits an event containing the message data and destination information. This event serves as the initiating message that will be relayed across chains. - -2. **Message Serialization**: The messenger contract converts the event data into a standardized format that can be consistently processed across different chains in the Superchain. - -3. **Identifier Creation**: A unique identifier is generated for the message, containing information about its `origin`, `timestamp`, and other `metadata`. This identifier helps track and verify the message. - -4. **Message Execution**: The destination chain receives and processes the message, executing any associated actions or state changes specified in the original message. - -For detailed implementation steps and code examples, see our [message passing implementation guide](https://supersim.pages.dev/guides/interop/viem). - -## Common Use Cases - -* Simple messages between identical contracts -* Complex multi-contract interactions -* Cross-chain state synchronization -* Token transfers and bridging - -For a practical example, see our [cross-chain ping pong tutorial](https://supersim.pages.dev/guides/interop/cross-chain-contract-calls-pingpong). - -## Next steps - -* Read about the [anatomy of a cross-chain message](/stack/interop/cross-chain-message) -* Try [Supersim](supersim) for testing cross-chain messages locally -* Learn about [manually relaying messages](https://supersim.pages.dev/guides/interop/cast) diff --git a/pages/stack/interop/op-supervisor.mdx b/pages/stack/interop/op-supervisor.mdx deleted file mode 100644 index 7afafb83b..000000000 --- a/pages/stack/interop/op-supervisor.mdx +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: OP Supervisor -lang: en-US -description: Learn the basics of OP Supervisor. ---- - -import { Callout, Tabs, Steps } from 'nextra/components' - -# OP Supervisor - - - Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. - - -OP Supervisor is a service that verifies cross-chain messages and manages interoperability between chains in the OP Stack. It serves as a hub where each `op-node` can index the data needed for cross-chain verification. Chain operators and teams running full nodes like RPC providers are expected to run this service. -Some features and benefits include: - -* Enables secure cross-chain message passing on the Superchain -* Provides a unified point for managing interoperability data -* Supports multiple networks simultaneously -* Offers potential for public endpoints to aid in node synchronization - -## How cross-chain message verification works - -OP Supervisor verifies messages between different chains in the OP Stack, reducing the risk of invalid or malicious cross-chain interactions.⁠ It centralizes the verification process, which reduces the complexity of operating individual nodes⁠.⁠ - -* `op-geth`: queries `op-supervisor` during block-building to verify if a message is sufficiently safe to include. This process involves checking each executing message and potentially undoing transactions if conflicts or unknown states are encountered. -* `op-node`: queries cross-chain safety information and coordinates safety updates between OP stack nodes and `op-supervisor`. It uses the API provided by `op-supervisor` to perform actions like: - * Updating and retrieving various safety levels - * Checking and returning the `cross-unsafe` head for a given chain - * Attempting to promote a block to `cross-safe` status - * Attempting to finalize an L2 block based on L1 finality - -## Log data indexing and management - -OP Supervisor acts as a hub for indexing data that every `op-node` needs to cross-verify with other chains, centralizing the process of managing interoperability data. Maintains the integrity of cross-chain interactions by tracking safety changes⁠ across the Superchain, ensuring consistent application of invalid dependency resolutions. ⁠ - -`op-supervisor` indexes two types of cross-chain dependencies: - -* Interop messages (events): `op-supervisor` maintains an events-index per L2 chain, which determines message-dependencies to check if blocks are safe -* L1 DA (data availability): `op-supervisor` tracks the L1 DA for L2 blocks and maintains a DA safety-index per L2 chain, which helps determine how to rewind L2 chains to resolve invalid dependencies - -## API for cross-chain safety - -OP Supervisor provides an interface for `op-node` to query cross-chain safety information and coordinate safety updates between OP stack nodes and `op-supervisor⁠⁠`. OP-Supervisor uses a global read API to determine **message safety** and **block safety,** utilizing both the events index and the safety index (See op-supervisor's [log data indexing](#log-data-indexing-and-management)). The API is designed to handle potential L1 reorgs that can affect the validity of cross-chain messages⁠. - -Key API methods include: - -| Method | Description | -| ----------------------------------------- | ------------------------------------------------------------------------------------- | -| `UnsafeView` and `SafeView` | Returns the Local and Cross heads for their respective levels | -| `DerivedFrom` | OP Nodes use to check the L1 source of the Supervisor (needed for Safe Head tracking) | -| `UpdateLocalSafe` and `UpdateLocalUnsafe` | Tells the Supervisor when the Node's heads change | -| `Finalized` | Returns the Finalized Head | -| `UpdateFinalizedL1` | Signals to the Supervisor new finality signals | -| `CheckMessage` | Checks logs in the DB directly in tests | - -For a full listing of API names, see the [`op-supervisor` client](https://github.com/ethereum-optimism/optimism/blob/develop/op-service/sources/supervisor_client.go). - -## RPC access to all chains - -OP Supervisor requires RPC access to all chains in the dependency set. This allows `op-supervisor` to verify cross-chain messages and sync data across multiple networks simultaneously, such as OP Mainnet and Base nodes using the same instance. - -Benefits: - -* Scalability: As the number of chains in the Superchain grows, `op-supervisor` can handle the increasing complexity of cross-chain interactions. -* Improved reliability: It enables a more redundant setup, which is good for stability in the growing ecosystem. - -## Next steps - -* Want to learn more? Read our guide on the anatomy of a [cross-chain message](/stack/interop/cross-chain-message) or check out this [interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). -* For more info about how OP Stack interoperability works under the hood, [check out the specs](https://specs.optimism.io/interop/overview.html). diff --git a/pages/stack/interop/supersim.mdx b/pages/stack/interop/supersim.mdx deleted file mode 100644 index 674485a66..000000000 --- a/pages/stack/interop/supersim.mdx +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: Supersim multichain development environment -lang: en-US -description: Learn how to use the Supersim local dev environment tool designed to simulate the Optimism Superchain. ---- - -import { Callout } from 'nextra/components' - -# Supersim multichain development environment - - - Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. - - -[Supersim](https://github.com/ethereum-optimism/Supersim) is a local development environment tool designed to simulate the Optimism Superchain for developers building multi-chain applications. It provides a simplified way to test and develop applications that interact with multiple chains within the Superchain ecosystem. - -## Supersim workflow - -```mermaid -graph LR - A[Write Smart Contracts] --> B[Deploy on Supersim] - B --> C[Test Cross-Chain Interactions] - C --> D[Debug and Refine] - D --> B - C --> E[Ready for Production] -``` - -This diagram illustrates the typical workflow for developers using Supersim, from writing smart contracts to testing and refining cross-chain interactions. - -## Features and benefits - -* Simulates multiple OP Stack chains locally (e.g., chain 901, 902) -* Supports testing of cross-chain messaging and interactions -* Includes pre-deployed interoperability contracts -* Offers a CLI interface for starting and managing Supersim instances -* Provides local JSON-RPC endpoints for each simulated chain -* Allows for custom configuration of chain parameters -* Facilitates testing of Superchain-specific features like SuperchainERC20 tokens -* Easy to use with common Ethereum development tools -* Supports chain forking - -## Supersim CLI interaction - -```mermaid -graph TD - A[Developer] --> B[Supersim CLI] - B --> C[Chain 901] - B --> D[Chain 902] - B --> E[...] - C --> F[JSON-RPC Endpoint] - D --> G[JSON-RPC Endpoint] - E --> H[JSON-RPC Endpoint] -``` - -This diagram illustrates how developers interact with Supersim through the CLI, which simulates OP Stack specific features (specifically interop) on locally run chains, each with its own JSON-RPC endpoint and pre-deployed interoperability contracts. - -## Next steps - -* Check out the dedicated [Supersim docs](https://Supersim.pages.dev/) for tutorials and specific use cases. -* Questions about Interop? Check out the FAQ section in the [Superchain Interop Explainer](/stack/interop/explainer#faqs) or check out this [Superchain interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). -* For more info about how Superchain interoperability works under the hood, [check out the specs](https://specs.optimism.io/interop/overview.html). diff --git a/pages/stack/opcm.mdx b/pages/stack/opcm.mdx deleted file mode 100644 index aa4bac0c5..000000000 --- a/pages/stack/opcm.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: OP Contracts Manager -lang: en-US -tags: ["opcm","eng-security"] -description: Learn how OP Contracts Manager deploys of the OP Stack with one transaction. ---- - -import { Callout, Tabs, Steps } from 'nextra/components' - -# OP Contracts Manager - -The OP Contracts Manager is a contract that deploys the L1 contracts for an OP Stack chain in a single transaction. It provides a minimal set of user-configurable parameters to ensure that the resulting chain meets the standard configuration requirements. - -The version deployed is always a governance-approved contract release. The set of governance approved contract releases can be found on the Optimism Monorepo releases page, and is the set of releases named `op-contracts/vX.Y.Z`. It deploys the [Fault Proof System](/stack/fault-proofs/explainer), using the [PermissionedDisputeGame](/stack/smart-contracts#permissioneddisputegame). - -* Ethereum address: [0x18cec91779995ad14c880e4095456b9147160790](https://etherscan.io/address/0x18cec91779995ad14c880e4095456b9147160790) -* Sepolia address: [0xf564eea7960ea244bfebcbbb17858748606147bf](https://sepolia.etherscan.io/address/0xf564eea7960ea244bfebcbbb17858748606147bf) - -## Purpose - -OPCM simplifies the L1 contract deployments for new OP Stack chains. It addresses three aspects of deploying the OP Stack's L1 contracts: - -1. **Deploy Superchain Contracts.** Superchain contracts are shared between many OP chains, so this occurs only occasionally in production. -2. **Deploy Shared Implementation Contracts.** This occurs once per contracts release in production. -3. **Deploy OP Chain Contracts.** This occurs for every OP chain deployment in production. - -In a future iteration, it also is meant to handle upgrading the smart contracts. - -## Learn more - -* Checkout the [OPCM specs](https://specs.optimism.io/experimental/op-contracts-manager.html) -* Checkout the [OPCM design document](https://github.com/ethereum-optimism/design-docs/blob/main/protocol/op-contracts-manager-arch.md) diff --git a/pages/stack/research.mdx b/pages/stack/research.mdx deleted file mode 100644 index 1a485ee0f..000000000 --- a/pages/stack/research.mdx +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Research -description: Documentation covering Block Time Research in the Research section of the OP Stack ecosystem. -lang: en-US ---- - -import { Card, Cards } from 'nextra/components' - -# Research - -Documentation covering Block Time Research in the Research section of the OP Stack ecosystem. - - - - diff --git a/pages/stack/research/_meta.json b/pages/stack/research/_meta.json deleted file mode 100644 index 470d7e645..000000000 --- a/pages/stack/research/_meta.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "block-time-research": "Block time research" -} - \ No newline at end of file diff --git a/pages/stack/research/block-time-research.mdx b/pages/stack/research/block-time-research.mdx deleted file mode 100644 index ca8678765..000000000 --- a/pages/stack/research/block-time-research.mdx +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: Block time research -lang: en-US -tags: ["op-geth", "op-reth", "eng-platforms"] -description: Sunnyside Labs' (formerly Test in Prod) and OP Labs 1 second block time research. ---- - -# Block time research - -Sunnyside Labs (formerly Test in Prod) and OP Labs have researched whether we can drop OP Chains' block time to one second. - -To validate if dropping the block time is safe, we should check if nodes can build a block under a second when the block spends maximum gas in the production environment–i.e., block building time should take less than one second when the block spends maximum gas. We benchmarked the block-building time of every block at Base and grouped the data in various gas ranges using multiple clients–op-geth & op-reth. - -## Method and raw data - -This [GitHub repository](https://github.com/testinprod-io/block-building-stats/tree/main) contains the test methods, data sets, client versions, and raw data. - -The following benchmarks are available in this [notebook](https://github.com/testinprod-io/block-building-stats/blob/main/stats.ipynb). - -## Benchmarks - -| ![Figure 1: op-geth / archive node / block 5492540 \~ 9816497.](/img/op-stack/protocol/block-time-research-figure-1.png) | -| :----------------------------------------------------------------------------------------------------------------------: | -| **Figure 1**: op-geth / archive node / block 5492540 \~ 9816497 | - -| ![Figure 2: op-geth / full node / block 5492540 \~ 9816497.](/img/op-stack/protocol/block-time-research-figure-2.png) | -| :-------------------------------------------------------------------------------------------------------------------: | -| **Figure 2**: op-geth / full node / block 5492540 \~ 9816497 | - -Figures 1 and 2 show the Base nodes' block-building time distribution with op-geth archive node & full node from block 5492540 to 9816497. We can see that the average block building time takes 0.58 and 0.36 seconds each for blocks that spent 25M \~ 30M gas, which is less than one second. - -| ![Figure 3: op-reth / archive node / block 5492540 \~ 9816497.](/img/op-stack/protocol/block-time-research-figure-3.png) | -| :----------------------------------------------------------------------------------------------------------------------: | -| **Figure 3**: op-reth / archive node / block 5492540 \~ 9816497 | - -Figure 3 shows the Base nodes' block-building time distribution using the op-reth archive node from block 5492540 to 9816497. Compared to op-geth's archive node, we can see that op-reth shows a better performance in all ranges. - -| ![Figure 4: op-geth / archive node / block 13686867 \~ 15074141.](/img/op-stack/protocol/block-time-research-figure-4.png) | -| :------------------------------------------------------------------------------------------------------------------------: | -| **Figure 4:** op-geth / archive node / block 13686867 \~ 15074141 | - -| ![Figure 5: op-geth / full node / block 14567037 \~ 15074141.](/img/op-stack/protocol/block-time-research-figure-5.png) | -| :---------------------------------------------------------------------------------------------------------------------: | -| **Figure 5:** op-geth / full node / block 14567037 \~ 15074141 | - -Throughout the research, we found that the node meaningfully takes longer to build a block as the chain stores more states and transactions to access more historical data. Therefore, we benchmarked the latest blocks in Figures 4 and 5. On average, both the full node and archive node could build a congested block on time. It is worth noting that the average block-building time of high gas spending range is similar to the older blocks, but the average block-building time is higher on the newer blocks. - -| ![Figure 6: op-geth / archive node / block 13686867 \~ 15074141 / histogram of 25m\~30m gas range.](/img/op-stack/protocol/block-time-research-figure-6.png) | -| :----------------------------------------------------------------------------------------------------------------------------------------------------------: | -| **Figure 6**: op-geth / archive node / block 13686867 \~ 15074141 / histogram of 25m\~30m gas range | - -If we zoom in on the 25m\~30m gas range of the archive node, the average could be potentially concerning–0.51 sec. It is worth noting that we can see the average is diverged from p50 (0.4 sec) because of outliers in the histogram (Figure 6), and p50 is a more important metric than the average for the block progression (Sequencer) because of its asynchronous nature. - -When the sequencer seals the block after the block time, it stops to include the transactions and yields the current processing transactions to the next block. Therefore, the sequencer can include most transactions that took less than one second in the block on time and include outliers in the next block. Therefore, we can expect the system to be able to build blocks in one second in most cases, even in the highest gas range (25m\~30m gas). - -As a result, we can learn that nodes can build the latest blocks of Base Mainnet with the highest level of production loads in one second with an [i3en.3xlarge instance](https://aws.amazon.com/ec2/instance-types/i3en/) (or similar specs). - -## Expected impacts - -### Verifier - -* Sync from genesis: If OP Chains' block time drops to one second, verifiers may need longer to sync the chain from the genesis with L1 derivation. However, we expect it won't be a notable issue for verifiers as OP Stack supports the [engine sync](/builders/node-operators/management/snap-sync). -* Following the tip: The research suggests that verifiers are less likely to have a problem following the tip because nodes could build a block under one second at the highest gas range, especially since most verifiers are full nodes. - -### Sequencer - -* Block progression: As the previous paragraph mentioned, the data suggests we don't expect problems on a shorter block time. - -## Limitation - -The data suggests we don't expect a problem dropping the block time to one second for now, as the average block building time of the latest blocks takes 0.19 seconds for the Base Mainnet. One concerning point: the benchmark shows that it takes longer to build a block as the chain progresses. When the chain stores more states over time and usage surges to a peak like 2017 Ethereum, we might need performance patches then. - -However, it is also worth noting that the research assumes that the Base Mainnet handles 2x of their current traffic–dropping the block time to half but still spending gas as current (when it runs two seconds of block time). Plus, the Base Mainnet's average block gas spending is 10M. To make all blocks reach the highest gas level that this research focuses on (25M), it's another 2.5x. - -Therefore, this research assumes the chain processes approximately 5x traffic compared to the current Base Mainnet (2x in block time \* 2.5x in gas spending). - -## Reference - -Base's prior research for raising gas limit: [replayor](https://github.com/danyalprout/replayor) diff --git a/pages/stack/security.mdx b/pages/stack/security.mdx index fbf62b199..1786d634a 100644 --- a/pages/stack/security.mdx +++ b/pages/stack/security.mdx @@ -14,4 +14,7 @@ Documentation covering Faq, Pause in the Security section of the OP Stack ecosys + + + diff --git a/pages/stack/security/_meta.json b/pages/stack/security/_meta.json index d84287eaa..bb7965882 100644 --- a/pages/stack/security/_meta.json +++ b/pages/stack/security/_meta.json @@ -1,4 +1,5 @@ { "faq": "Security FAQs", - "pause": "Pause and unpause the Bridge" + "pause": "Pause and unpause the Bridge", + "audits-report": "Audit reports" } \ No newline at end of file diff --git a/pages/stack/security/audits-report.mdx b/pages/stack/security/audits-report.mdx new file mode 100644 index 000000000..05e07ec2b --- /dev/null +++ b/pages/stack/security/audits-report.mdx @@ -0,0 +1,39 @@ +--- +title: Audit reports +lang: en-US +description: A comprehensive list of security reviews for the OP Stack, including links to detailed audit reports and descriptions of their scope. +--- + +import Link from "next/link" + +# Audit reports + +Security is a top priority for the OP Stack. Below, you'll find a comprehensive list of past audits conducted on various components of the OP Stack ecosystem. Each report includes the scope, focus, and a link to the full audit documentation. These reviews ensure that the system is secure and reliable for all users. + +## Summary + +The following table summarizes all security audits conducted to date: + +| Audit Date | Reviewer | Focus and Scope | View report | +| ---------- | -------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 2020-10 | Trail of Bits | Rollup | view | +| 2020-11 | Dapphub | ECDSA Wallet | view | +| 2021-03 | OpenZeppelin | OVM and Rollup | view | +| 2021-03 | ConsenSys Diligence | Safety Checker | view | +| 2022-05 | Zeppelin | Bedrock Contracts | view | +| 2022-05 | Trail of Bits | OpNode | view | +| 2022-08 | Sigma Prime | Bedrock GoLang | view | +| 2022-09 | Zeppelin | Bedrock and Periphery Contracts | view | +| 2022-10 | Spearbit | Drippie: `Drippie.sol` | view | +| 2022-11 | Trail of Bits | Invariant Testing: `OptimismPortal.sol` | view | +| 2022-12 | Runtime Verification | Deposit Transaction: `OptimismPortal.sol` | view | +| 2023-01 | Trail of Bits | Bedrock Updates: `SystemConfig.sol` | view | +| 2023-01 | Sherlock | Bedrock: All contracts in `packages/contracts-bedrock/src` | [view](https://github.com/sherlock-audit/2023-01-optimism) | +| 2023-03 | Sherlock | Bedrock Fixes: All contracts in `packages/contracts-bedrock/src` | [view](https://github.com/sherlock-audit/2023-03-optimism) | +| 2023-12 | Trust | Superchain Config Upgrade: Various contracts | view | +| 2024-02 | Runtime Verification | Pausability | [view](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/test/kontrol/README.md) | +| 2024-02 | Cantina | MCP L1: Various contracts | view | +| 2024-03 | Sherlock | Fault Proofs | [view](https://github.com/sherlock-audit/2024-02-optimism-2024) | +| 2024-08 | Cantina | Fault proof MIPS: `MIPS.sol` | view | +| 2024-08 | Spearbit | Fault proof no-MIPS: Dispute contracts | view | +| 2024-10 | 3Doc Security | Fault proof MIPS: `MIPS.sol` | view | diff --git a/pages/superchain/superchain-registry.mdx b/pages/superchain/superchain-registry.mdx index 28c5ca30d..4b763dd4b 100644 --- a/pages/superchain/superchain-registry.mdx +++ b/pages/superchain/superchain-registry.mdx @@ -25,3 +25,7 @@ You can find more details in the [Standard Rollup Charter documentation](/superc We **strongly** recommend using the [op-deployer](/builders/chain-operators/tools/op-deployer) to deploy L1 contracts and generate the L2 genesis file that meet the configuration requirements outlined in the [Standard Rollup Charter](/superchain/blockspace-charter). + +## Joining the Registry + +All Superchain Ecosystem members are welcome to join the Superchain Registry, regardless of whether they adhere to the standard rollup charter or not. To join the Registry, [follow the steps in this guide](https://github.com/ethereum-optimism/superchain-registry/blob/main/docs/ops.md#adding-a-chain) to submit a pull request and join the Superchain Ecosystem. This guide will help you set up your chain, create your environment, and run all the validation checks needed to ensure your chain is ready to join the Registry. diff --git a/public/audit-reports/2020_10-Rollup-TrailOfBits.pdf b/public/audit-reports/2020_10-Rollup-TrailOfBits.pdf new file mode 100644 index 000000000..3bca4cfac Binary files /dev/null and b/public/audit-reports/2020_10-Rollup-TrailOfBits.pdf differ diff --git a/public/audit-reports/2020_11-Dapphub-ECDSA_Wallet.pdf b/public/audit-reports/2020_11-Dapphub-ECDSA_Wallet.pdf new file mode 100644 index 000000000..4d82bd147 Binary files /dev/null and b/public/audit-reports/2020_11-Dapphub-ECDSA_Wallet.pdf differ diff --git a/public/audit-reports/2021_03-OVM_and_Rollup-OpenZeppelin.pdf b/public/audit-reports/2021_03-OVM_and_Rollup-OpenZeppelin.pdf new file mode 100644 index 000000000..15990a172 Binary files /dev/null and b/public/audit-reports/2021_03-OVM_and_Rollup-OpenZeppelin.pdf differ diff --git a/public/audit-reports/2021_03-SafetyChecker-ConsenSysDiligence.pdf b/public/audit-reports/2021_03-SafetyChecker-ConsenSysDiligence.pdf new file mode 100644 index 000000000..50aa580f5 Binary files /dev/null and b/public/audit-reports/2021_03-SafetyChecker-ConsenSysDiligence.pdf differ diff --git a/public/audit-reports/2022_05-Bedrock_Contracts-Zeppelin.pdf b/public/audit-reports/2022_05-Bedrock_Contracts-Zeppelin.pdf new file mode 100644 index 000000000..188188746 Binary files /dev/null and b/public/audit-reports/2022_05-Bedrock_Contracts-Zeppelin.pdf differ diff --git a/public/audit-reports/2022_05-OpNode-TrailOfBits.pdf b/public/audit-reports/2022_05-OpNode-TrailOfBits.pdf new file mode 100644 index 000000000..ad424d08f Binary files /dev/null and b/public/audit-reports/2022_05-OpNode-TrailOfBits.pdf differ diff --git a/public/audit-reports/2022_08-Bedrock_GoLang-SigmaPrime.pdf b/public/audit-reports/2022_08-Bedrock_GoLang-SigmaPrime.pdf new file mode 100644 index 000000000..2076693d1 Binary files /dev/null and b/public/audit-reports/2022_08-Bedrock_GoLang-SigmaPrime.pdf differ diff --git a/public/audit-reports/2022_09-Bedrock_and_Periphery-Zeppelin.pdf b/public/audit-reports/2022_09-Bedrock_and_Periphery-Zeppelin.pdf new file mode 100644 index 000000000..39425807b Binary files /dev/null and b/public/audit-reports/2022_09-Bedrock_and_Periphery-Zeppelin.pdf differ diff --git a/public/audit-reports/2022_10-Drippie-Spearbit.pdf b/public/audit-reports/2022_10-Drippie-Spearbit.pdf new file mode 100644 index 000000000..e6c3a5c49 Binary files /dev/null and b/public/audit-reports/2022_10-Drippie-Spearbit.pdf differ diff --git a/public/audit-reports/2022_11-Invariant_Testing-TrailOfBits.pdf b/public/audit-reports/2022_11-Invariant_Testing-TrailOfBits.pdf new file mode 100644 index 000000000..e99d3d418 Binary files /dev/null and b/public/audit-reports/2022_11-Invariant_Testing-TrailOfBits.pdf differ diff --git a/public/audit-reports/2022_12-DepositTransaction-RuntimeVerification.pdf b/public/audit-reports/2022_12-DepositTransaction-RuntimeVerification.pdf new file mode 100644 index 000000000..36d31dfb7 Binary files /dev/null and b/public/audit-reports/2022_12-DepositTransaction-RuntimeVerification.pdf differ diff --git a/public/audit-reports/2023_01-Bedrock_Updates-TrailOfBits.pdf b/public/audit-reports/2023_01-Bedrock_Updates-TrailOfBits.pdf new file mode 100644 index 000000000..7ab5e3755 Binary files /dev/null and b/public/audit-reports/2023_01-Bedrock_Updates-TrailOfBits.pdf differ diff --git a/public/audit-reports/2023_12_SuperchainConfigUpgrade_Trust.pdf b/public/audit-reports/2023_12_SuperchainConfigUpgrade_Trust.pdf new file mode 100644 index 000000000..b03c44916 Binary files /dev/null and b/public/audit-reports/2023_12_SuperchainConfigUpgrade_Trust.pdf differ diff --git a/public/audit-reports/2024_02-MCP_L1-Cantina.pdf b/public/audit-reports/2024_02-MCP_L1-Cantina.pdf new file mode 100644 index 000000000..69f4891dd Binary files /dev/null and b/public/audit-reports/2024_02-MCP_L1-Cantina.pdf differ diff --git a/public/audit-reports/2024_05-FaultProofs-Sherlock.pdf b/public/audit-reports/2024_05-FaultProofs-Sherlock.pdf new file mode 100644 index 000000000..ba6da27b4 Binary files /dev/null and b/public/audit-reports/2024_05-FaultProofs-Sherlock.pdf differ diff --git a/public/audit-reports/2024_05_SafeLivenessExtensions-Cantina.pdf b/public/audit-reports/2024_05_SafeLivenessExtensions-Cantina.pdf new file mode 100644 index 000000000..c1135ee4d Binary files /dev/null and b/public/audit-reports/2024_05_SafeLivenessExtensions-Cantina.pdf differ diff --git a/public/audit-reports/2024_08_Fault-Proofs-MIPS_Cantina.pdf b/public/audit-reports/2024_08_Fault-Proofs-MIPS_Cantina.pdf new file mode 100644 index 000000000..2a6017130 Binary files /dev/null and b/public/audit-reports/2024_08_Fault-Proofs-MIPS_Cantina.pdf differ diff --git a/public/audit-reports/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf b/public/audit-reports/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf new file mode 100644 index 000000000..d9adce78d Binary files /dev/null and b/public/audit-reports/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf differ diff --git a/words.txt b/words.txt index ff12b8378..45939b2cc 100644 --- a/words.txt +++ b/words.txt @@ -7,7 +7,6 @@ ADDIU ADDU airgap Allnodes -Allocs allocs ANDI Apeworx @@ -15,7 +14,6 @@ authrpc Badgeholder's Badgeholders badgeholders -basefee BGEZ BGTZ Biconomy @@ -24,7 +22,6 @@ birthdate BLEZ BLOBPOOL blobpool -blobspace blockhash blocklists BLOCKLOGS @@ -34,7 +31,6 @@ blockprofilerate Blockscout Blockspace blockspace -blocktime BLOOMFILTER bloomfilter BLTZ @@ -44,43 +40,35 @@ Bootnodes bootnodes bottlenecked Brotli -brotli Callouts callouts -Celestia -Celestia's chainlist chaosnet Chugsplash Clabby codebases collateralized -compr COMPUTEPENDINGBLOCK computependingblock confs +Consen corsdomain counterfactually Crosschain -crosschain -daserver +Dapphub DATACAP datacap DATADIR datadir Devnet devnet -devnets devx -direnv DISABLETXPOOLGOSSIP disabletxpoolgossip Discv discv DIVU -dripcheck Drippie -Eigen ENABLEDEPRECATEDPERSONAL enabledeprecatedpersonal enginekind @@ -93,15 +81,12 @@ ETHSTATS ethstats EVMTIMEOUT evmtimeout -executability -exfiltrate EXITWHENSYNCED exitwhensynced EXTRADATA extradata Farcaster farcaster -Faultproof FDLIMIT fdlimit featureset @@ -127,21 +112,18 @@ hardfork hardforks HEALTHCHECK healthcheck -healthchecks HISTORICALRPC historicalrpc HISTORICALRPCTIMEOUT historicalrpctimeout HOLESKY +Holesky holesky -IERC IGNOREPRICE ignoreprice implicity INFLUXDBV influxdbv -inteoperates -interchain IPCDISABLE ipcdisable ipcfile @@ -154,7 +136,6 @@ journalremotes JSPATH jspath jwtsecret -Keccak leveldb lightkdf logfile @@ -182,16 +163,13 @@ MINSUGGESTEDPRIORITYFEE minsuggestedpriorityfee Mintable MIPSEVM -Monitorism Mordor -mountpoint MOVN MOVZ MTHI MTLO MULT multiaddr -multichain multiclient multisigs MULTU @@ -223,10 +201,9 @@ nosyncserve Numba Offchain offchain -OPCM -opcm oplabs opnode's +Pausability pausable pcscdpath Peerstore @@ -243,22 +220,15 @@ pprof Precommitments precommitments preconfigured -Predeploy predeploy Predeployed predeployed Predeploys predeploys Preimage -preimage PREIMAGES preimages -preinstall -Preinstalls -preinstalls -Prestate prestate -prestates PRICEBUMP pricebump PRICELIMIT @@ -267,14 +237,11 @@ productionize productionized Protip Proxied -Proxyd -proxyd pseudorandomly Quicknode quicknode quickstarts RANDAO -rebalance Regenesis regenesis REJOURNAL @@ -282,22 +249,17 @@ rejournal REMOTEDB remotedb replayability -replayor REQUIREDBLOCKS requiredblocks -rollouts Rollups rollups Routescan rpckind RPCPREFIX rpcprefix -rpcs RPGF Rpgf rpgf -Runbooks -runbooks RWAs safedb Schnorr @@ -318,28 +280,21 @@ Spearbit SRAV SRLV stablecoins -statefulset subcomponents subgame subheaders SUBU -Sunnyside SUPERCHAIN Superchain superchain Superchain's -Superchainerc -superchainerc Superchains Superscan -Supersim -supersim SYNCMODE syncmode SYNCTARGET synctarget syscalls -therealbytes thirdweb threadcreate tility @@ -347,12 +302,10 @@ timeseries trustlessly trustrpc txfeecap -txmgr txns TXPOOL txpool txproxy -txproxyd uncountered undercollateralize Unprotect @@ -370,7 +323,6 @@ vmdebug VMODULE vmodule Warpcast -xlarge XORI xtensibility ZKPs