diff --git a/components/WipCallout.tsx b/components/WipCallout.tsx index c64f397cb..72dd73d5c 100644 --- a/components/WipCallout.tsx +++ b/components/WipCallout.tsx @@ -73,17 +73,21 @@ export function InfoCallout({ context }: Props): ReactElement { ); } -export function AltCallout({ context }: Props): ReactElement { +interface BetaCalloutProps extends Props { + featureName: string; +} + +function BetaCallout({ context, featureName }: BetaCalloutProps): ReactElement { return (
-
+
{context ? ( context ) : ( -
- The Alt-DA Mode feature is currently in Beta within +
+ The {featureName} feature is currently in Beta within the MIT-licensed OP Stack. Beta features are built and reviewed by - the Optimism Collective’s core contributors, and provide developers + the Optimism Collective's core contributors, and provide developers with early access to highly requested configurations. These features may experience stability issues, and we encourage feedback from our early users. @@ -93,3 +97,11 @@ export function AltCallout({ context }: Props): ReactElement {
); } + +export function AltCallout(props: Props): ReactElement { + return ; +} + +export function CGTCallout(props: Props): ReactElement { + return ; +} \ No newline at end of file diff --git a/pages/builders/app-developers/bridging/basics.mdx b/pages/builders/app-developers/bridging/basics.mdx index 5b8edaba1..0af641177 100644 --- a/pages/builders/app-developers/bridging/basics.mdx +++ b/pages/builders/app-developers/bridging/basics.mdx @@ -1,29 +1,29 @@ --- -title: Bridging Basics +title: Bridging basics lang: en-US description: Learn about the fundamentals of sending data and tokens between Ethereum and OP Mainnet. --- -# Bridging Basics +# Bridging basics OP Mainnet is a "Layer 2" system and is fundamentally connected to Ethereum. However, OP Mainnet is also a distinct blockchain with its own blocks and transactions. App developers commonly need to move data and tokens between OP Mainnet and Ethereum. This process of moving data and tokens between the two networks is called "bridging". -## Sending Tokens +## Sending tokens One of the most common use cases for bridging is the need to send ETH or ERC-20 tokens between OP Mainnet and Ethereum. OP Mainnet has a system called the [Standard Bridge](./standard-bridge) that makes it easy to move tokens in both directions. If you mostly need to bridge tokens, make sure to check out the [Standard Bridge](./standard-bridge) guide. -## Sending Data +## Sending data Under the hood, the Standard Bridge is just an application that uses the OP Mainnet [message passing system to send arbitrary data between Ethereum and OP Mainnet](./messaging). Applications can use this system to have a contract on Ethereum interact with a contract on OP Mainnet, and vice versa. All of this is easily accessible with a simple, clean API. -## Next Steps +## Next steps Ready to start bridging? Check out these tutorials to get up to speed fast. diff --git a/pages/builders/app-developers/bridging/custom-bridge.mdx b/pages/builders/app-developers/bridging/custom-bridge.mdx index 23ea17319..e0e60e2c4 100644 --- a/pages/builders/app-developers/bridging/custom-bridge.mdx +++ b/pages/builders/app-developers/bridging/custom-bridge.mdx @@ -1,12 +1,12 @@ --- -title: Custom Bridges +title: Custom bridges lang: en-US description: Important considerations when building custom bridges for OP Mainnet. --- import { Callout } from 'nextra/components' -# Custom Bridges +# Custom bridges Custom token bridges are any bridges other than the [Standard Bridge](./standard-bridge). You may find yourself in a position where you need to build a custom token bridge because the Standard Bridge doesn't completely support your use case. @@ -35,7 +35,7 @@ The [Superchain Token List](/chain/tokenlist) exists to help users and developer Once you've built and tested your custom bridge, make sure to register any tokens meant to flow through this bridge by [making a pull request against the Superchain Token List repository](https://github.com/ethereum-optimism/ethereum-optimism.github.io#adding-a-token-to-the-list). You **must** deploy your bridge to OP Sepolia before it can be added to the Superchain Token List. -## Next Steps +## Next steps You can explore several examples of custom bridges for OP Mainnet: diff --git a/pages/builders/app-developers/bridging/messaging.mdx b/pages/builders/app-developers/bridging/messaging.mdx index 0d8cd9e6a..c52e6642f 100644 --- a/pages/builders/app-developers/bridging/messaging.mdx +++ b/pages/builders/app-developers/bridging/messaging.mdx @@ -1,12 +1,12 @@ --- -title: Sending Data Between L1 and L2 +title: Sending data between L1 and L2 lang: en-US description: Learn how bridging works between L1 and L2, how to use it, and what to watch out for. --- import { Callout } from 'nextra/components' -# Sending Data Between L1 and L2 +# Sending data between L1 and L2 Smart contracts on L1 (Ethereum) can interact with smart contracts on L2 (OP Mainnet) through a process called "bridging". This page explains how bridging works, how to use it, and what to watch out for. @@ -16,7 +16,7 @@ This page explains how bridging works, how to use it, and what to watch out for. For a step-by-step tutorial on how to send data between L1 and L2, check out the [Solidity tutorial](/builders/app-developers/tutorials/cross-dom-solidity). -## Understanding Contract Calls +## Understanding contract calls It can be easier to understand bridging if you first have a basic understanding of how contracts on EVM-based blockchains like OP Mainnet and Ethereum communicate within the *same* network. The interface for sending messages *between* Ethereum and OP Mainnet is designed to mimic the standard contract communication interface as much as possible. @@ -57,7 +57,7 @@ Here you're using the [low-level "call" function](https://docs.soliditylang.org/ Although these two code snippets look a bit different, they're doing the exact same thing. Because of limitations of Solidity, **the OP Stack's bridging interface is designed to look like the second code snippet**. -## Basics of Communication Between Layers +## Basics of communication between layers At a high level, the process for sending data between L1 and L2 is pretty similar to the process for sending data between two contracts on Ethereum (with a few caveats). Communication between L1 and L2 is made possible by a pair of special smart contracts called the "messenger" contracts. @@ -121,17 +121,17 @@ contract MyContract { You can find the addresses of the `L1CrossDomainMessenger` and the `L2CrossDomainMessenger` contracts on OP Mainnet and OP Sepolia on the [Contract Addresses](/chain/addresses) page. -## Communication Speed +## Communication speed Unlike calls between contracts on the same blockchain, calls between Ethereum and OP Mainnet are *not* instantaneous. The speed of a cross-chain transaction depends on the direction in which the transaction is sent. -### For L1 to L2 Transactions +### For L1 to L2 transactions Transactions sent from L1 to L2 take **approximately 1-3 minutes** to get from Ethereum to OP Mainnet, or from Sepolia to OP Sepolia. This is because the Sequencer waits for a certain number of L1 blocks to be created before including L1 to L2 transactions to avoid potentially annoying [reorgs](https://www.alchemy.com/overviews/what-is-a-reorg). -### For L2 to L1 Transactions +### For L2 to L1 transactions Transactions sent from L2 to L1 take **approximately 7 days** to get from OP Mainnet to Ethereum, or from OP Sepolia to Sepolia. This is because the bridge contract on L1 must wait for the L2 state to be *proven* to the L1 chain before it can relay the message. @@ -177,9 +177,9 @@ modifier onlyOwner() { } ``` -## Fees For Sending Data Between L1 and L2 +## Fees for sending data between L1 and L2 -### For L1 to L2 Transactions +### For L1 to L2 transactions The majority of the cost of an L1 to L2 transaction comes from the smart contract execution on L1. When sending an L1 to L2 transaction, you send to the [`L1CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/L1CrossDomainMessenger.sol) contract, which then sends a call to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol) contract. @@ -195,7 +195,7 @@ The amount of L1 gas charged increases when more people are sending L1 to L2 tra You should always add a buffer of at least 20% to the gas limit for your L1 to L2 transaction to avoid running out of gas. -### For L2 to L1 Transactions +### For L2 to L1 transactions Each message from L2 to L1 requires three transactions: @@ -211,11 +211,11 @@ Each message from L2 to L1 requires three transactions: The total cost of an L2 to L1 transaction is therefore the combined cost of the L2 initialization transaction and the two L1 transactions. The L1 proof and finalization transactions are typically significantly more expensive than the L2 initialization transaction. -## Understanding the Challenge Period +## Understanding the challenge period One of the most important things to understand about L1 ⇔ L2 interaction is that **mainnet messages sent from Layer 2 to Layer 1 cannot be relayed for at least 7 days**. This means that any messages you send from Layer 2 will only be received on Layer 1 after this one week period has elapsed. -We call this period of time the "challenge period" because it is the time during which a transaction can be challenged with a [fault proof](/stack/protocol/rollup/overview#fault-proofs). +We call this period of time the "challenge period" because it is the time during which a transaction can be challenged with a [fault proof](/stack/rollup/overview#fault-proofs). Optimistic Rollups are "optimistic" because they're based around the idea of publishing the *result* of a transaction to Ethereum without actually executing the transaction on Ethereum. In the "optimistic" case, this transaction result is correct and one can completely avoid the need to perform complicated (and expensive) logic on Ethereum. diff --git a/pages/builders/app-developers/bridging/standard-bridge.mdx b/pages/builders/app-developers/bridging/standard-bridge.mdx index da23a5059..2d137d6ad 100644 --- a/pages/builders/app-developers/bridging/standard-bridge.mdx +++ b/pages/builders/app-developers/bridging/standard-bridge.mdx @@ -36,7 +36,7 @@ The Standard Bridge is composed of two contracts, the [`L1StandardBridge`](https These two contracts interact with one another via the `CrossDomainMessenger` system for sending messages between Ethereum and OP Mainnet. You can read more about the `CrossDomainMessenger` in the guide on [Sending Data Between L1 and L2](./messaging). -### Bridged Tokens +### Bridged tokens The Standard Bridge utilizes bridged representations of tokens that are native to another blockchain. Before a token native to one chain can be bridged to the other chain, a bridged representation of that token must be created on the receiving side. @@ -50,7 +50,7 @@ A native token may have more than one bridged representation at the same time. Users must always specify which bridged token they wish to use when using the bridge. Different bridged representations of the same native token are considered entirely independent tokens. -### Bridging Native Tokens +### Bridging native tokens The Standard Bridge uses a "lock-and-mint" mechanism to convert native tokens into their bridged representations. This means that **native tokens are locked** into the Standard Bridge on one side, after which **bridged tokens are minted** on the other side. @@ -129,7 +129,7 @@ The process for bridging a native token involves a few steps. This process is identical in both the Ethereum to OP Mainnet and OP Mainnet to Ethereum directions. -### Bridging Non-Native Tokens +### Bridging non-native tokens The Standard Bridge uses a "burn-and-unlock" mechanism to convert bridged representations of tokens back into their native tokens. This means that **bridged tokens are burned** on the Standard Bridge on one side, after which **native tokens are unlocked** on the other side. @@ -237,7 +237,7 @@ The address of this entry is the address of the bridged representation of the to -## Special Considerations +## Special considerations ### USDC diff --git a/pages/builders/app-developers/contracts/_meta.json b/pages/builders/app-developers/contracts/_meta.json index f8ed2c3be..50aa18684 100644 --- a/pages/builders/app-developers/contracts/_meta.json +++ b/pages/builders/app-developers/contracts/_meta.json @@ -1,5 +1,6 @@ { "compatibility": "Solidity Compatibility", "system-contracts": "System Contracts", - "optimization": "Cost Optimization" + "optimization": "Cost Optimization", + "superchain-erc20": "SuperchainERC20 Token Standard" } diff --git a/pages/builders/app-developers/contracts/compatibility.mdx b/pages/builders/app-developers/contracts/compatibility.mdx index ed9cc7d7b..7133db286 100644 --- a/pages/builders/app-developers/contracts/compatibility.mdx +++ b/pages/builders/app-developers/contracts/compatibility.mdx @@ -1,21 +1,21 @@ --- -title: Solidity Compatibility +title: Solidity compatibility lang: en-US description: Learn about the differences between OP Mainnet and Ethereum when building Solidity contracts. --- -# Solidity Compatibility +# Solidity compatibility OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), which means OP Mainnet looks exactly like Ethereum in every way possible. Almost all Ethereum tooling works out of the box on OP Mainnet, including the [Solidity](https://soliditylang.org/) smart contract language. However, there are a few minor differences between OP Mainnet and Ethereum that you should be aware of when building Solidity contracts. -## EVM/Opcode Differences +## EVM/Opcode differences Most smart contracts will work on OP Mainnet without any changes. Check out the [Differences Between Ethereum and OP Mainnet](/chain/differences#opcodes) page for a detailed list of the few differences you should know about. -## Gas Differences +## Gas differences OP Mainnet uses the same gas costs as Ethereum. However, OP Mainnet also charges an [L1 Data Fee](/stack/transactions/fees#l1-data-fee) for the cost of publishing an L2 transaction to L1. diff --git a/pages/builders/app-developers/contracts/optimization.mdx b/pages/builders/app-developers/contracts/optimization.mdx index 7d599718c..d792cf4b1 100644 --- a/pages/builders/app-developers/contracts/optimization.mdx +++ b/pages/builders/app-developers/contracts/optimization.mdx @@ -1,12 +1,12 @@ --- -title: Contract Optimization on OP Mainnet +title: Contract optimization on OP Mainnet lang: en-US description: Learn how to optimize contracts for OP Mainnet and what to look out for when you do so. --- import { Callout } from 'nextra/components' -# Contract Optimization on OP Mainnet +# Contract optimization on OP Mainnet OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), which means OP Mainnet looks exactly like Ethereum in every way possible. One large and mostly unavoidable discrepancy between OP Mainnet and Ethereum is a slight [difference in transaction fee models](/stack/transactions/fees). @@ -36,12 +36,12 @@ This is the basic premise that makes OP Mainnet contract optimization slightly d ## Considerations -### Additional Complexity +### Additional complexity Contract optimizations can create additional complexity, which can in turn create additional risk. Developers should always consider whether this added complexity is worth the reduction in cost. -### Changing Economics +### Changing economics Various potential upgrades to OP Mainnet may also make optimizations to the L1 Data Fee less relevant. For instance, [EIP-4844](https://www.eip4844.com/), if adopted, should significantly reduce the cost of publishing data to Ethereum and would therefore also decrease the L1 Data Fee. @@ -57,7 +57,7 @@ If you expect your contracts to be used mostly in the short term or you have the ## Techniques -### Calldata Compression +### Calldata compression Compressing user data on the client side and decompressing it on the contract side can be an effective way to decrease costs on OP Mainnet. This technique decreases the amount of data provided by the user in exchange for a significant increase in onchain computation. @@ -66,7 +66,7 @@ Although several libraries exist to perform this calldata compression, none of t As a result, links to these libraries have been explicitly omitted here to avoid encouraging developers from using potentially buggy software. Most of these libraries can be found with a quick search online but, as always, be careful with code you find on the internet. -### Custom Encoding +### Custom encoding The [Solidity ABI encoding scheme](https://docs.soliditylang.org/en/v0.8.23/abi-spec.html#argument-encoding) is not particularly data efficient. Contracts can often reduce the amount of calldata provided by defining a custom argument encoding protocol. diff --git a/pages/builders/app-developers/contracts/superchain-erc20.mdx b/pages/builders/app-developers/contracts/superchain-erc20.mdx new file mode 100644 index 000000000..dfaf8f84e --- /dev/null +++ b/pages/builders/app-developers/contracts/superchain-erc20.mdx @@ -0,0 +1,6 @@ +--- +--- + +import SuperchainERC20 from '@/pages/stack/interop/superchain-erc20.mdx' + + diff --git a/pages/builders/app-developers/contracts/system-contracts.mdx b/pages/builders/app-developers/contracts/system-contracts.mdx index 2e01eebe1..4178a81a4 100644 --- a/pages/builders/app-developers/contracts/system-contracts.mdx +++ b/pages/builders/app-developers/contracts/system-contracts.mdx @@ -1,12 +1,12 @@ --- -title: Using OP Mainnet System Contracts +title: Using OP Mainnet system contracts lang: en-US description: Learn how to work with OP Mainnet contracts directly from other contracts and how to work with contracts from the client side. --- import { Steps } from 'nextra/components' -# Using OP Mainnet System Contracts +# Using OP Mainnet system contracts System contracts on Ethereum (L1) and OP Mainnet (L2) are an important part of the OP Mainnet ecosystem. You may want to interact with these system contracts for any number of reasons, including: @@ -18,7 +18,7 @@ You may want to interact with these system contracts for any number of reasons, In this tutorial, you'll learn how to work with OP Mainnet contracts directly from other contracts and how to work with them from the client side. -## Before You Begin +## Before you begin You'll need to find the address of the particular contract that you want to interact with before you can actually interact with it. @@ -26,7 +26,7 @@ You'll need to find the address of the particular contract that you want to inte * Find the addresses for all networks on the [Contract Addresses](/chain/addresses) page. * Use the JSON file including contract addresses for all Superchain networks in the [Superchain Registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/addresses/addresses.json). -## Using System Contracts in Solidity +## Using system contracts in Solidity All you need to interact with the OP Mainnet system contracts from another contract is an address and an interface. You can follow [the instructions above](#finding-contract-addresses) to find the address of the contract you want to interact with. @@ -42,7 +42,7 @@ Install the package as follows: npm install @eth-optimism/contracts-bedrock ``` -### Importing Contracts +### Importing contracts Simply import the desired contract or interface from the `@eth-optimism/contracts-bedrock` package: @@ -57,14 +57,14 @@ For example, if you wanted to import the [`L1CrossDomainMessenger`](https://gith import { L1CrossDomainMessenger } from "@eth-optimism/contracts/L1/messaging/L1CrossDomainMessenger.sol"; ``` -### Getting L2 Contract Addresses +### Getting L2 contract addresses System contracts on L2 are "pre-deployed" to special addresses that are the same on most OP Stack chains. You can find these addresses on the [Contract Addresses](/chain/addresses) page. These addresses are also provided as constants in the [`Predeploys`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/libraries/Predeploys.sol) contract for use in Solidity. -## Using System Contracts in JavaScript +## Using system contracts in JavaScript You can also interact with the OP Mainnet system contracts from the client side. @@ -77,7 +77,7 @@ Install the package as follows: npm install @eth-optimism/contracts-ts ``` -### Getting Contract Artifacts and Interfaces +### Getting contract artifacts and interfaces You can use the `@eth-optimism/contracts-ts` package to easily access the address or ABI of any OP Mainnet contract. @@ -90,9 +90,9 @@ import { } from '@eth-optimism/contracts-ts' // Note that the address is keyed by chain ID! -console.log(l2OutputOracleAddresses[10], abi) +console.log(l2OutputOracleAddresses[10], l2OutputOracleProxyABI) ``` -### Interacting with the Contract +### Interacting with the contract You can then feed this address and ABI into your favorite web3 library to interact with the contract. `@eth-optimism/contracts-ts` also exports [React hooks](https://wagmi.sh/cli/api/plugins/react) and [wagmi actions](https://wagmi.sh/react/api/actions) for interacting with OP Mainnet contracts. diff --git a/pages/builders/app-developers/overview.mdx b/pages/builders/app-developers/overview.mdx index cf5222e13..8b6a9e1d3 100644 --- a/pages/builders/app-developers/overview.mdx +++ b/pages/builders/app-developers/overview.mdx @@ -1,17 +1,17 @@ --- -title: App Developer Overview +title: App developer overview lang: en-US description: Learn about deploying contracts, cross-chain messaging, and tutorials to help you build applications on OP Mainnet. --- import { Cards, Card } from 'nextra/components' -# App Developer Overview +# App developer overview If you're a developer looking to build on OP Mainnet, you've come to the right place. In this area of the Optimism Docs you'll find everything you need to know about building OP Mainnet applications. -## Getting Started +## Getting started If you're brand new to OP Mainnet, try starting with the guide on [deploying a basic contract](/chain/getting-started). It'll get you familiar with the basic steps required to get a contract deployed to the network. @@ -28,7 +28,7 @@ You might also want to check out the [testing on OP Networks guide](/chain/testi } /> -## Bridging and Messaging +## Bridging and messaging Looking to build an application that sends ETH, tokens, or data between OP Mainnet and Ethereum? You'll find some useful guides and tutorials in this area of the docs. @@ -65,7 +65,7 @@ They'll help you get a head start when building your first Optimistic project. You can also [suggest a new tutorial](https://github.com/ethereum-optimism/docs/issues/new?assignees=\&labels=tutorial%2Cdocumentation%2Ccommunity-request\&projects=\&template=suggest_tutorial.yaml\&title=%5BTUTORIAL%5D+Add+PR+title) if you have something specific in mind. We'd love to grow this list! -## Next Steps +## Next steps If you still can't find the content you're looking for, there's a few options to get extra help. diff --git a/pages/builders/app-developers/quick-start.mdx b/pages/builders/app-developers/quick-start.mdx index 34482b0c1..98cc91da0 100644 --- a/pages/builders/app-developers/quick-start.mdx +++ b/pages/builders/app-developers/quick-start.mdx @@ -1,5 +1,5 @@ --- -title: Superchain App Quick Start +title: Superchain app quick start lang: en-US description: Learn how to quickly build and deploy an app to any OP Chain using Scaffold-OP. --- @@ -8,7 +8,7 @@ import { Callout, Steps } from 'nextra/components' import Image from 'next/image' import { Tabs } from 'nextra/components' -# Superchain App Quick Start +# Superchain App quick start This quick start walks you through an easy three-step process to deploy an app to any OP Chain – in under 15 minutes. This quick start uses [`Scaffold-OP`](https://github.com/ethereum-optimism/scaffold-op) to build the Superchain App, covers the setup process, and links to more detailed guides, so you can dive a bit deeper when needed. @@ -29,7 +29,7 @@ You can request testnet ETH from the Superchain Faucet in one of two ways: **con You can also try using [other available OP Sepolia faucets](/builders/tools/build/faucets). -## Step 2: Build a Basic App with Scaffold-OP +## Step 2: Build a basic app with Scaffold-OP Scaffold-OP is a fork of [`scaffold-ETH2`](https://docs.scaffoldeth.io/) with minimal differences: additional app examples, native support for Superchain testnets, and more low-level instructions. Scaffold-OP is an open-source toolkit for building decentralized applications on the Ethereum blockchain and is designed to make it easier for developers to create and deploy smart contracts and @@ -104,7 +104,7 @@ Before you begin, you need to install the following tools: * Edit your deployment scripts in `packages/hardhat/deploy` -## Step 3: Deploy Contracts to Superchain Testnets +## Step 3: Deploy contracts to Superchain Testnets You will follow the steps below to deploy contracts to a remote testnet (e.g., Optimism Sepolia). Please ensure you have enough Sepolia ETH on all these Superchains before deploying (See [Step 1 above](#step-1-get-testnet-eth-from-superchain-faucet)). @@ -159,7 +159,7 @@ Please ensure you have enough Sepolia ETH on all these Superchains before deploy Congratulations! You now have an OP Mainnet app ready for development, which can also be deployed to more OP Chains! 🎉 -## Next Steps +## Next steps * Share feedback about this quick start or `scaffold-op` in the [developer forum](https://github.com/ethereum-optimism/developers/discussions/262). * You can also [add Foundry to Scaffold-OP](https://github.com/ethereum-optimism/scaffold-op?tab=readme-ov-file#adding-foundry) for more robust and faster testing. diff --git a/pages/builders/app-developers/tools/_meta.json b/pages/builders/app-developers/tools/_meta.json index 9f3f9aa63..6eabf1a34 100644 --- a/pages/builders/app-developers/tools/_meta.json +++ b/pages/builders/app-developers/tools/_meta.json @@ -1,5 +1,6 @@ { "ecosystem-overview": "Open Source Code Repo", + "supersim": "Supersim Multichain Development Environment", "console": { "title": "Superchain Dev Console", "href": "https://console.optimism.io/?utm_source=docs", diff --git a/pages/builders/app-developers/tools/ecosystem-overview.mdx b/pages/builders/app-developers/tools/ecosystem-overview.mdx index 10fe3a21b..e6f08ef4c 100644 --- a/pages/builders/app-developers/tools/ecosystem-overview.mdx +++ b/pages/builders/app-developers/tools/ecosystem-overview.mdx @@ -1,17 +1,17 @@ --- -title: Open Source Code Repo +title: Open source code repo lang: en-US description: Learn about an ecosystem of libraries and utilities tailored to help you deploy applications on the OP Stack. --- import { Cards, Card } from 'nextra/components' -# Open Source Code Repo for OP Stack Builders +# Open source code repo for OP Stack builders The [ecosystem repository](https://github.com/ethereum-optimism/ecosystem) is a comprehensive resource of libraries, utilities, and forkable code examples specifically tailored for builders deploying applications on the OP stack. The ecosystem repository was developed to help ease and expedite the development process for all builders working on the OP stack, helping them deliver value to the community without the necessity of mastering every detail of how the protocol itself operates. -## Getting Started +## Getting started Our initial launch includes an example [bridge application](https://github.com/ethereum-optimism/ecosystem/tree/main/apps/bridge-app) that demonstrates how to bridge ETH and any ERC20 tokens listed in the [Superchain Token List](/chain/tokenlist). This application serves as a reference for anyone looking to build their own bridge, offering a clearer understanding of how to interact with the protocol on both the L1 and L2 sides. diff --git a/pages/builders/app-developers/tools/supersim.mdx b/pages/builders/app-developers/tools/supersim.mdx new file mode 100644 index 000000000..dc60c54ac --- /dev/null +++ b/pages/builders/app-developers/tools/supersim.mdx @@ -0,0 +1,6 @@ +--- +--- + +import Supersim from '@/pages/stack/interop/supersim.mdx' + + diff --git a/pages/builders/app-developers/transactions/estimates.mdx b/pages/builders/app-developers/transactions/estimates.mdx index 732de864c..8fb70e326 100644 --- a/pages/builders/app-developers/transactions/estimates.mdx +++ b/pages/builders/app-developers/transactions/estimates.mdx @@ -1,12 +1,12 @@ --- -title: Estimating Transaction Fees on OP Mainnet +title: Estimating transaction fees on OP Mainnet lang: en-US description: Learn how to properly estimate the total cost of a transaction on OP Mainnet. --- import { Callout, Steps } from 'nextra/components' -# Estimating Transaction Fees on OP Mainnet +# Estimating transaction fees on OP Mainnet Check out the guide on understanding [Transaction Fees on OP Mainnet](./fees) for an in-depth explanation of how OP Mainnet transaction fees work. @@ -16,7 +16,7 @@ It's important to properly estimate the cost of a transaction on OP Mainnet befo Here you'll learn how to estimate both of the components that make up the total cost of an OP Mainnet transaction, the [execution gas fee](./fees#execution-gas-fee) and the [L1 data fee](./fees#l1-data-fee). Make sure to read the guide on [Transaction Fees on OP Mainnet](./fees) for a detailed look at how these fees work under the hood. -## Execution Gas Fee +## Execution gas fee Estimating the execution gas fee on OP Mainnet is just like estimating the execution gas fee on Ethereum. @@ -47,7 +47,7 @@ Make sure to check out the guide on [Setting Transaction Gas Parameters on OP Ma -## L1 Data Fee +## L1 data fee The Viem library provides a convenient method for estimating the L1 data fee for a transaction. @@ -97,7 +97,7 @@ Selecting the right tool for your use case will depend on your specific needs. * [Viem](https://viem.sh/op-stack#getting-started-with-op-stack) provides first-class support for OP Stack chains, including OP Mainnet. You can use Viem to estimate gas costs and send cross-chain transactions (like transactions through the Standard Bridge system). It's strongly recommended to use Viem if you are able to do so as it will provide the best native support at the moment. -### Future Proofing +### Future proofing The L1 Data Fee formula is subject to change in the future, especially as the data availability landscape evolves. As a result, it's important to future proof your transaction fee estimation code to ensure that it will continue to function properly as the L1 Data Fee formula changes. diff --git a/pages/builders/app-developers/transactions/parameters.mdx b/pages/builders/app-developers/transactions/parameters.mdx index e5e18aa3e..22e450911 100644 --- a/pages/builders/app-developers/transactions/parameters.mdx +++ b/pages/builders/app-developers/transactions/parameters.mdx @@ -1,12 +1,12 @@ --- -title: Setting Transaction Gas Parameters on OP Mainnet +title: Setting transaction gas parameters on OP Mainnet lang: en-US description: Learn how to set gas parameters for transactions on OP Mainnet. --- import { Callout, Steps } from 'nextra/components' -# Setting Transaction Gas Parameters on OP Mainnet +# Setting transaction gas parameters on OP Mainnet OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) which means that it is as compatible with Ethereum as possible, down to the client software used to run OP Mainnet nodes. Like Ethereum, OP Mainnet has an EIP-1559 style fee mechanism that dynamically adjusts a [base fee](https://ethereum.org/en/developers/docs/gas/#base-fee) that acts as the minimum fee that a transaction must pay to be included in a block. @@ -15,7 +15,7 @@ OP Mainnet also allows transactions to pay a [priority fee](https://ethereum.org Setting the base fee and the priority fee appropriately is important to ensure that your transactions are included in a timely manner. This guide will walk you through some best practices for determining the base fee and priority fee for your transactions. -## Selecting the Base Fee +## Selecting the base fee The base fee is the minimum fee that a transaction must pay to be included in a block. Transactions that specify a maximum fee per gas that is less than the current base fee cannot be included in the blockchain. @@ -53,7 +53,7 @@ If you are less sensitive to the base fee, you may wish to simply use a large mu -## Selecting the Priority Fee +## Selecting the priority fee The priority fee is an optional tip that can be paid to the Sequencer to incentivize them to include your transaction more quickly. The priority fee is paid in addition to the base fee. diff --git a/pages/builders/app-developers/transactions/statuses.mdx b/pages/builders/app-developers/transactions/statuses.mdx index 0427ab651..ed635a400 100644 --- a/pages/builders/app-developers/transactions/statuses.mdx +++ b/pages/builders/app-developers/transactions/statuses.mdx @@ -1,10 +1,10 @@ --- -title: Transaction Statuses on OP Mainnet +title: Transaction statuses on OP Mainnet lang: en-US description: Learn about the statuses transactions can have on OP Mainnet. --- -# Transaction Statuses on OP Mainnet +# Transaction statuses on OP Mainnet Transactions on OP Mainnet can have a number of different statuses depending on where a transaction is in the process of being included in the blockchain. Understanding these statuses can help you troubleshoot issues, build safer applications, and display more accurate information to your users. @@ -19,7 +19,7 @@ At this point the transaction is not part of the blockchain and there is no guar The list of all pending transactions can be retrieved by calling the standard JSON-RPC method [`eth_getBlockByNumber`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbynumber) with the parameter `pending` as the block number. -## Sequencer Confirmed / Unsafe +## Sequencer confirmed or unsafe **Typically within 2-4 seconds** @@ -30,7 +30,7 @@ Applications should make sure to consider this possibility when displaying infor The latest "sequencer confirmed" block can be retrieved by calling the standard JSON-RPC method [`eth_getBlockByNumber`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbynumber) with the parameter `safe` as the block number and comparing this to the result returned for the `latest` block. If the `safe` block is behind the `latest` block, then the earliest "sequencer confirmed" block is the `safe` block plus one. -## Published to Ethereum / Safe +## Published to Ethereum or safe **Typically within 5-10 minutes, up to 12 hours** diff --git a/pages/builders/app-developers/transactions/troubleshooting.mdx b/pages/builders/app-developers/transactions/troubleshooting.mdx index fdf67ab8b..2953b8479 100644 --- a/pages/builders/app-developers/transactions/troubleshooting.mdx +++ b/pages/builders/app-developers/transactions/troubleshooting.mdx @@ -1,12 +1,12 @@ --- -title: Troubleshooting Transactions +title: Troubleshooting transactions lang: en-US description: Learn how to troubleshoot common problems with transactions. --- -# Troubleshooting Transactions +# Troubleshooting transactions -## Transactions Stuck in the Transaction Pool +## Transactions stuck in the transaction pool OP Chain uses EIP-1559, but with different parameters than L1 Ethereum. As a result, while the base fee on L1 can grow by up to 12.5% in a twelve second period (in the case of a single 30M gas block), the L2 base fee can grow by up to 77% (in the case of six 30M gas blocks). diff --git a/pages/builders/app-developers/tutorials/cross-dom-bridge-erc20.mdx b/pages/builders/app-developers/tutorials/cross-dom-bridge-erc20.mdx index bbddc794d..c2de64336 100644 --- a/pages/builders/app-developers/tutorials/cross-dom-bridge-erc20.mdx +++ b/pages/builders/app-developers/tutorials/cross-dom-bridge-erc20.mdx @@ -9,7 +9,7 @@ import { WipCallout } from '@/components/WipCallout' -# Bridging ERC-20 Tokens to OP Mainnet With the Optimism SDK +# Bridging ERC-20 tokens to OP Mainnet with the Optimism SDK @@ -27,7 +27,7 @@ Make sure to check out the [Standard Bridge guide](/builders/app-developers/brid because they can cause bridge accounting errors. -## Supported Networks +## Supported networks The Optimism SDK supports any of the [Superchain networks](/chain/networks). [Some Superchain networks](https://sdk.optimism.io/enums/l2chainid) are already included in the SDK by default. @@ -38,7 +38,7 @@ If you want to use a network that isn't included by default, you can simply [ins * [node](https://nodejs.org/en/) * [pnpm](https://pnpm.io/installation) -## Create a Demo Project +## Create a demo project You're going to use the Optimism SDK for this tutorial. Since the Optimism SDK is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. @@ -89,7 +89,7 @@ You will need to get some ETH on both of these testnets. Sepolia. -## Add a Private Key to Your Environment +## Add a private key to your environment You need a private key to sign transactions. Set your private key as an environment variable with the `export` command. @@ -110,7 +110,7 @@ node This will bring up a Node REPL prompt that allows you to run javascript code. -## Import Dependencies +## Import dependencies You need to import some dependencies into your Node REPL session. @@ -126,7 +126,7 @@ You need to import some dependencies into your Node REPL session. ``` -## Set Session Variables +## Set session variables You'll need a few variables throughout this tutorial. Let's set those up now. @@ -159,7 +159,7 @@ Let's set those up now. -## Get L1 Tokens +## Get L1 tokens You're going to need some tokens on L1 that you can bridge to L2. The L1 testing token located at [`0x5589BB8228C07c4e15558875fAf2B859f678d129`](https://sepolia.etherscan.io/address/0x5589BB8228C07c4e15558875fAf2B859f678d129) has a `faucet` function that makes it easy to get tokens. @@ -186,7 +186,7 @@ The L1 testing token located at [`0x5589BB8228C07c4e15558875fAf2B859f678d129`](h ``` -## Deposit Tokens +## Deposit tokens Now that you have some tokens on L1, you can deposit those tokens into the `L1StandardBridge` contract. You'll then receive the same number of tokens on L2 in return. @@ -259,7 +259,7 @@ You'll then receive the same number of tokens on L2 in return. ``` -## Withdraw Tokens +## Withdraw tokens You just bridged some tokens from L1 to L2. Nice! @@ -336,7 +336,7 @@ Now you're going to repeat the process in reverse to bridge some tokens from L2 ``` -## Next Steps +## Next steps Congrats! You've just deposited and withdrawn tokens using the Optimism SDK. diff --git a/pages/builders/app-developers/tutorials/cross-dom-bridge-eth.mdx b/pages/builders/app-developers/tutorials/cross-dom-bridge-eth.mdx index 5c7d442c8..0c5e5b141 100644 --- a/pages/builders/app-developers/tutorials/cross-dom-bridge-eth.mdx +++ b/pages/builders/app-developers/tutorials/cross-dom-bridge-eth.mdx @@ -9,9 +9,7 @@ import { WipCallout } from '@/components/WipCallout' -# Bridging ETH to OP Mainnet With the Optimism SDK - - +# Bridging ETH to OP Mainnet with the Optimism SDK This tutorial explains how you can use the [Optimism SDK](https://sdk.optimism.io) to bridge ETH from L1 (Ethereum or Sepolia) to L2 (OP Mainnet or OP Sepolia). The Optimism SDK is an easy way to add bridging functionality to your JavaScript-based application. @@ -20,7 +18,7 @@ It also provides some safety rails to prevent common mistakes that could cause E Behind the scenes, the Optimism SDK uses the [Standard Bridge](/builders/app-developers/bridging/standard-bridge) contracts to transfer ETH and ERC-20 tokens. Make sure to check out the [Standard Bridge guide](/builders/app-developers/bridging/standard-bridge) if you want to learn more about how the bridge works under the hood. -## Supported Networks +## Supported networks The Optimism SDK supports any of the [Superchain networks](/chain/networks). [Some Superchain networks](https://sdk.optimism.io/enums/l2chainid) are already included in the SDK by default. @@ -31,7 +29,7 @@ If you want to use a network that isn't included by default you can simply [inst * [node](https://nodejs.org/en/) * [pnpm](https://pnpm.io/installation) -## Create a Demo Project +## Create a demo project You're going to use the Optimism SDK for this tutorial. Since the Optimism SDK is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. @@ -78,7 +76,7 @@ You will need to get some ETH on Sepolia to follow along. You can use [this faucet](https://sepoliafaucet.com) to get ETH on Sepolia. -## Add a Private Key to Your Environment +## Add a private key to your environment You need a private key in order to sign transactions. Set your private key as an environment variable with the `export` command. @@ -99,7 +97,7 @@ node This will bring up a Node REPL prompt that allows you to run javascript code. -## Import Dependencies +## Import dependencies You need to import some dependencies into your Node REPL session. @@ -117,7 +115,7 @@ You need to import some dependencies into your Node REPL session. -## Set Session Variables +## Set session variables You'll need a few variables throughout this tutorial. Let's set those up now. @@ -279,7 +277,7 @@ You should now have more ETH on L1. -## Next Steps +## Next steps Congrats! You've just deposited and withdrawn ETH using the Optimism SDK. diff --git a/pages/builders/app-developers/tutorials/cross-dom-solidity.mdx b/pages/builders/app-developers/tutorials/cross-dom-solidity.mdx index b846658c1..5c28e1178 100644 --- a/pages/builders/app-developers/tutorials/cross-dom-solidity.mdx +++ b/pages/builders/app-developers/tutorials/cross-dom-solidity.mdx @@ -1,5 +1,5 @@ --- -title: Communicating Between OP Mainnet and Ethereum in Solidity +title: Communicating between OP Mainnet and Ethereum in Solidity lang: en-US description: Learn how to write Solidity contracts on OP Mainnet and Ethereum that can talk to each other. --- @@ -8,9 +8,7 @@ import { Steps, Callout, Tabs } from 'nextra/components' import { WipCallout } from '@/components/WipCallout' -# Communicating Between OP Mainnet and Ethereum in Solidity - - +# Communicating between OP Mainnet and Ethereum in Solidity This tutorial explains how to write Solidity contracts on OP Mainnet and Ethereum that can talk to each other. Here you'll use a contract on OP Mainnet that can set a "greeting" variable on a contract on Ethereum, and vice-versa. @@ -25,7 +23,7 @@ Just looking to bridge tokens between OP Mainnet and Ethereum? Check out the tutorial on [Bridging ERC-20 Tokens to OP Mainnet With the Optimism SDK](./cross-dom-bridge-erc20). -## Message Passing Basics +## Message passing basics OP Mainnet uses a smart contract called the `CrossDomainMessenger` to pass messages between OP Mainnet and Ethereum. Both chains have a version of this contract (the `L1CrossDomainMessenger` and the `L2CrossDomainMessenger`). @@ -48,7 +46,7 @@ You can use [this faucet](https://sepoliafaucet.com/) to get ETH on Sepolia. You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on OP Sepolia. -## Review the Contracts +## Review the contracts You're about to use two contracts that have already been deployed to Sepolia and OP Sepolia, the `Greeter` contracts. You can review the source code for the L1 `Greeter` contract [here on Etherscan](https://sepolia.etherscan.io/address/0x31A6Dd971306bb72f2ffF771bF30b1B98dB8B2c5#code). You can review the source code for the L2 `Greeter` contract [here on Etherscan](https://sepolia-optimism.etherscan.io/address/0x5DE8a2957eddb140567fF90ba5d57bc9769f3055#code). @@ -57,7 +55,7 @@ Both contracts have exactly the same source code. Feel free to review the source code for these two contracts now if you'd like. This tutorial will explain how these contracts work in detail later on in the [How It Works](#how-it-works) section below. -## Interact With the L1 Greeter +## Interact with the L1 Greeter You're first going to use the L1 `Greeter` contract to set the greeting on the L2 `Greeter` contract. You'll send a transaction directly to the L1 `Greeter` contract which will ask the `L1CrossDomainMessenger` to send a message to the L2 `Greeter` contract. @@ -102,7 +100,7 @@ L2 transactions triggered on L1 are typically processed within one minute but ca -## Interact With the L2 Greeter +## Interact with the L2 Greeter Now you're going to use the L2 `Greeter` contract to set the greeting on the L1 `Greeter` contract. You'll send a transaction directly to the L2 `Greeter` contract which will ask the `L2CrossDomainMessenger` to send a message to the L1 `Greeter` contract. @@ -279,14 +277,14 @@ You should see the message you sent from L2. -## How It Works +## How it works Congratulations! You've successfully sent a message from L1 to L2 and from L2 to L1. This section will explain how the `Greeter` contracts work so you can follow the same pattern to deploy your own contracts. Luckily, both `Greeter` contracts are exactly the same so it's easy to see how everything comes together. -### The Messenger Variable +### The Messenger variable The `Greeter` contract has a `MESSENGER` variable that keeps track of the `CrossDomainMessenger` contract on the current chain. Check out the [Contract Addresses page](/chain/addresses) to see the addresses of the `CrossDomainMessenger` contracts on whichever network you'll be using. @@ -294,7 +292,7 @@ Check out the [Contract Addresses page](/chain/addresses) to see the addresses o ```solidity file=/public/tutorials/cross-dom-solidity.sol#L14 hash=ce8be857d4b4e1992cd3c16b8f2864b9 ``` -### The Other Greeter Variable +### The other Greeter variable The `Greeter` contract also has an `OTHER_GREETER` variable that keeps track of the `Greeter` contract on the other chain. On L1, this variable is set to the address of the L2 `Greeter` contract, and vice-versa. @@ -302,7 +300,7 @@ On L1, this variable is set to the address of the L2 `Greeter` contract, and vic ```solidity file=/public/tutorials/cross-dom-solidity.sol#L15 hash=eedd8c3050a83e56f37f367c6faa6f5d ``` -### The Greetings Mapping +### The Greetings mapping The `Greeter` contract keeps track of the different greetings that users have sent inside a `greetings` mapping. By using a mapping, this contract can keep track of greetings from different users at the same time. @@ -317,7 +315,7 @@ The `Greeter` has a simple constructor that sets the `MESSENGER` and `OTHER_GREE ```solidity file=/public/tutorials/cross-dom-solidity.sol#L18-L24 hash=718f3dc498975548eec30da99e47adf2 ``` -### The Send Greeting Function +### The sendGreeting function The `sendGreeting` function is the most important function in the `Greeter` contract. This is what you called earlier to send messages in both directions. @@ -330,7 +328,7 @@ The final parameter is the gas limit that gets used when the message is relayed ```solidity file=/public/tutorials/cross-dom-solidity.sol#L26-L38 hash=3104a6775fe3a505cf2f84b71b078aee ``` -### The Set Greeting Function +### The setGreeting function The `setMessage` function is the function that actually sets the greeting. This function is called by the `CrossDomainMessenger` contract on the other chain. diff --git a/pages/builders/app-developers/tutorials/first-contract.mdx b/pages/builders/app-developers/tutorials/first-contract.mdx index 52bd22337..03acec0c1 100644 --- a/pages/builders/app-developers/tutorials/first-contract.mdx +++ b/pages/builders/app-developers/tutorials/first-contract.mdx @@ -1,12 +1,12 @@ --- -title: Deploying Your First Contract on OP Mainnet +title: Deploying your first contract on OP Mainnet lang: en-US description: Learn how to write and deploy your first contract on OP Mainnet using the MetaMask browser extension. --- import { Callout, Steps } from 'nextra/components' -# Deploying Your First Contract on OP Mainnet +# Deploying your first contract on OP Mainnet **This tutorial is meant for developers who are new to OP Mainnet and Solidity.** @@ -20,7 +20,7 @@ This tutorial walks you through the process of deploying your first smart contra * Firefox or any Chromium-based browser (Chrome, Brave, Edge, etc.) -## Wallet Setup +## Wallet setup You'll need access to an [Ethereum wallet](https://ethereum.org/en/wallets/) if you want to deploy a smart contract. This tutorial uses [MetaMask](https://metamask.io), a popular browser extension wallet, just to get you started. @@ -163,13 +163,13 @@ Having issues with the Optimism Superchain Faucet? You can try using [other available OP Sepolia faucets](/builders/tools/build/faucets) instead. -## Check Your Wallet Balance +## Check your wallet balance After you get some ETH on OP Sepolia, you can check your wallet balance in MetaMask. Make sure that your balance has updated before continuing. If you don't see any ETH in your wallet, double check that your MetaMask is connected to the OP Sepolia network. -## Write Your First Contract +## Write your first contract The most popular smart contract development language today is [Solidity](https://docs.soliditylang.org/en/latest/). In this tutorial, you'll be using a browser-based integrated development environment (IDE) called [Remix](https://remix.ethereum.org/). @@ -222,7 +222,7 @@ You shouldn't see any compilation errors for this contract. -## Deploy Your Contract +## Deploy your contract Now that you've written your first contract, you can deploy it to OP Sepolia. Deploying contracts with Remix is pretty straightforward. @@ -268,7 +268,7 @@ Remix will automatically detect when your transaction has confirmed and will sho -## Interact With Your Contract +## Interact with your contract Now that you've deployed your contract, you can interact with it. Remix makes it easy to interact with your contract by providing a built-in user interface. @@ -307,12 +307,12 @@ Congrats, you've successfully deployed and interacted with your first smart cont -## How Your Contract Works +## How your contract works Now that you've deployed your contract, you might be wondering how it works. Let's take a closer look at the code you wrote. -### License Identifier +### License identifier The first line of most Solidity files is the license identifier. This line is used to specify the license under which the code is released. @@ -321,7 +321,7 @@ In this case, the code written is released under the [MIT license](https://opens ```solidity file=/public/tutorials/first-contract.sol#L1 hash=8384d75c38c570f3edb87cf9f64f2ec2 ``` -### Pragma Directive +### Pragma directive The next line is a [pragma directive](https://docs.soliditylang.org/en/latest/layout-of-source-files.html#pragma). This line tells the Solidity compiler which version of the Solidity language to use. @@ -330,7 +330,7 @@ In this case, the code is written for Solidity version 0.8.0 or higher. ```solidity file=/public/tutorials/first-contract.sol#L2 hash=70ebe002bc5488bb81baa0504de273c1 ``` -### Contract Definition +### Contract definition The next line defines a contract called `MyFirstContract`. A contract is a collection of code and data that is stored at a specific address on the blockchain. @@ -340,7 +340,7 @@ The contract definition is followed by a pair of curly braces that contain the c ```solidity file=/public/tutorials/first-contract.sol#L4 hash=8f3ace25e5f9ea06d8cb388eb3ab1775 ``` -### Message Variable +### Message variable The first thing you'll notice inside the contract definition is a variable called `message`. This variable is declared as a `string`, which is a Solidity type that represents a string of characters. @@ -349,7 +349,7 @@ The `public` keyword means that this variable can be read from outside the contr ```solidity file=/public/tutorials/first-contract.sol#L5 hash=42a1bdfe81e5b3bba6b99d3255ef4f2b ``` -### Message Update Function +### Message update function The next thing you'll notice is a function called `setMessage`. This function takes a single argument called `_message` of type `string`. @@ -359,7 +359,7 @@ Since this function doesn't have any access control, anyone can update the `mess ```solidity file=/public/tutorials/first-contract.sol#L7-L9 hash=b7e5531c48425b183e794f9f251c5540 ``` -## Next Steps +## Next steps To learn more about Solidity, check out the [Solidity documentation](https://docs.soliditylang.org/en/latest/) for more information about the language itself. If you learn best by reading source code, check out [this annotated code for an ERC-20 token contract](https://ethereum.org/en/developers/tutorials/erc20-annotated-code/). diff --git a/pages/builders/app-developers/tutorials/sdk-estimate-costs.mdx b/pages/builders/app-developers/tutorials/sdk-estimate-costs.mdx index 677890ed1..8b47d81c4 100644 --- a/pages/builders/app-developers/tutorials/sdk-estimate-costs.mdx +++ b/pages/builders/app-developers/tutorials/sdk-estimate-costs.mdx @@ -1,14 +1,14 @@ --- -title: Estimating Transaction Costs on OP Stack +title: Estimating transaction costs on OP Stack lang: en-US -description: Learn how to use Viem to estimate the cost of a transaction on OP Mainnet. +description: Learn how to use viem to estimate the cost of a transaction on OP Stack. --- import { Callout, Steps, Tabs } from 'nextra/components' -# Estimating Transaction Costs on OP Stack +# Estimating transaction costs on OP Stack -In this tutorial, you'll learn how to use [Viem](https://viem.sh/op-stack/) to estimate the cost of a transaction on OP Mainnet. +In this tutorial, you'll learn how to use [viem](https://viem.sh/op-stack/) to estimate the cost of a transaction on OP Mainnet. You'll learn how to estimate the [execution gas fee](/builders/app-developers/transactions/fees#execution-gas-fee) and the [L1 data fee](/builders/app-developers/transactions/fees#l1-data-fee) independently. You'll also learn how to estimate the total cost of the transaction all at once. @@ -16,7 +16,7 @@ You'll also learn how to estimate the total cost of the transaction all at once. Check out the full explainer on [OP Stack transaction fees](/builders/app-developers/transactions/fees) for more information on how OP Mainnet charges fees under the hood. -## Supported Networks +## Supported networks Viem supports any of the [Superchain networks](/chain/networks). The OP Stack networks are included in Viem by default. @@ -27,26 +27,26 @@ If you want to use a network that isn't included by default, you can add it to V * [node](https://nodejs.org/en/) * [pnpm](https://pnpm.io/installation) -## Create a Demo Project +## Create a demo project You're going to use Viem for this tutorial. Since Viem is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. - {

Make a Project Folder

} + {

Make a project folder

} ```bash mkdir op-est-cost-tutorial cd op-est-cost-tutorial ``` - {

Initialize the Project

} + {

Initialize the project

} ```bash pnpm init ``` - {

Install Viem

} + {

Install viem

} ```bash pnpm add viem @@ -73,10 +73,10 @@ This tutorial explains how estimate transaction costs on OP Sepolia. You will need to get some ETH on OP Sepolia in order to run the code in this tutorial. - You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on OP Sepolia. + You can use the [Superchain faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on OP Sepolia. -## Add a Private Key to Your Environment +## Add a private key to your environment You need a private key in order to sign transactions. Set your private key as an environment variable with the `export` command. @@ -97,14 +97,14 @@ node This will bring up a Node REPL prompt that allows you to run JavaScript code. -## Set Session Variables +## Set session variables You'll need a few variables throughout this tutorial. Let's set those up now. -{

Import Viem and other necessary modules

} +{

Import viem and other necessary modules

} ```js file=/public/tutorials/sdk-estimate-costs.js#L3-L6 hash=32ecaac58846bfe7e785e2cc35562120 ``` @@ -125,7 +125,7 @@ Let's set those up now. ``` -## Estimate Transaction Costs +## Estimate transaction costs You're now going to use the Viem to estimate the cost of a transaction on OP Mainnet. Here you'll estimate the cost of a simple transaction that sends a small amount of ETH from your address to the address `0x1000000000000000000000000000000000000000`. @@ -191,7 +191,7 @@ Here you'll estimate the cost of a simple transaction that sends a small amount Estimates will never be entirely accurate due to network conditions and gas price fluctuations, but they should be close to the actual costs. -## Next Steps +## Next steps * Always estimate before sending: Estimating costs before sending a transaction helps prevent unexpected fees and failed transactions. * Account for gas price volatility: Gas prices can change rapidly. Consider adding a buffer to your estimates or implementing a gas price oracle for more accurate pricing. diff --git a/pages/builders/app-developers/tutorials/sdk-trace-txns.mdx b/pages/builders/app-developers/tutorials/sdk-trace-txns.mdx index 3a70bacec..637d7cb6a 100644 --- a/pages/builders/app-developers/tutorials/sdk-trace-txns.mdx +++ b/pages/builders/app-developers/tutorials/sdk-trace-txns.mdx @@ -1,5 +1,5 @@ --- -title: Tracing Deposits and Withdrawals +title: Tracing deposits and withdrawals lang: en-US description: Learn how to use the Optimism SDK to trace deposits and withdrawals between L1 and L2. --- @@ -8,9 +8,7 @@ import { Callout, Steps } from 'nextra/components' import { WipCallout } from '@/components/WipCallout' -# Tracing Deposits and Withdrawals - - +# Tracing deposits and withdrawals In this tutorial, you'll learn how to use the [Optimism SDK](https://sdk.optimism.io) to trace a [Standard Bridge](../bridging/standard-bridge) deposit or withdrawal between L1 and L2. You'll specifically learn how to determine the status of a deposit or withdrawal and how to retrieve the transaction receipt for the executed transaction on L1 (for withdrawals) or L2 (for deposits). @@ -25,7 +23,7 @@ You can also check out the tutorial on [Viewing Deposits and Withdrawals by Addr * [node](https://nodejs.org/en/) * [pnpm](https://pnpm.io/installation) -## Create a Demo Project +## Create a demo project You're going to use the Optimism SDK for this tutorial. Since the Optimism SDK is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. @@ -60,7 +58,7 @@ pnpm add ethers@^5 -## Add RPC URLs to Your Environment +## Add RPC URLs to your environment You'll be using the `getMessageReceipt` function from the Optimism SDK during this tutorial. This function use event queries to retrieve the receipt for a deposit or withdrawal. @@ -88,7 +86,7 @@ node This will bring up a Node REPL prompt that allows you to run javascript code. -## Import Dependencies +## Import dependencies You need to import some dependencies into your Node REPL session. @@ -106,7 +104,7 @@ You need to import some dependencies into your Node REPL session. -## Set Session Variables +## Set session variables You'll need a few variables throughout this tutorial. Let's set those up now. @@ -152,7 +150,7 @@ Create an instance of the `CrossChainMessenger` class: ```js file=/public/tutorials/sdk-trace-txns.js#L20-L25 hash=158c6888c82bdc2f07c37c3edb3a9a6a ``` -## Trace a Deposit +## Trace a deposit You can use the `CrossChainMessenger` instance to trace a deposit. @@ -191,7 +189,7 @@ Once you have the transaction receipt, you can directly query for the actual L2 -## Trace a Withdrawal +## Trace a withdrawal You can also use the `CrossChainMessenger` instance to trace a withdrawal. diff --git a/pages/builders/app-developers/tutorials/sdk-view-txns.mdx b/pages/builders/app-developers/tutorials/sdk-view-txns.mdx index 7287680de..d93b63610 100644 --- a/pages/builders/app-developers/tutorials/sdk-view-txns.mdx +++ b/pages/builders/app-developers/tutorials/sdk-view-txns.mdx @@ -1,5 +1,5 @@ --- -title: Viewing Deposits and Withdrawals by Address +title: Viewing deposits and withdrawals by address lang: en-US description: Learn how to use the Optimism SDK to view all deposits and withdrawals triggered by a given address. --- @@ -8,9 +8,7 @@ import { Callout, Steps } from 'nextra/components' import { WipCallout } from '@/components/WipCallout' -# Viewing Deposits and Withdrawals by Address - - +# Viewing deposits and withdrawals by address In this tutorial, you'll learn how to use the [Optimism SDK](https://sdk.optimism.io) to view all of the [Standard Bridge](../bridging/standard-bridge) deposits and withdrawals triggered by a given address. @@ -23,7 +21,7 @@ Check out the tutorial on [Bridging ERC-20 Tokens With the Optimism SDK](./cross * [node](https://nodejs.org/en/) * [pnpm](https://pnpm.io/installation) -## Create a Demo Project +## Create a demo project You're going to use the Optimism SDK for this tutorial. Since the Optimism SDK is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. @@ -57,7 +55,7 @@ pnpm add ethers@^5 -## Add RPC URLs to Your Environment +## Add RPC URLs to your environment You'll be using the `getDepositsByAddress` and `getWithdrawalsByAddress` functions from the Optimism SDK during this tutorial. These functions use event queries to retrieve the deposits and withdrawals made by a given address. @@ -85,7 +83,7 @@ node This will bring up a Node REPL prompt that allows you to run javascript code. -## Import Dependencies +## Import dependencies You need to import some dependencies into your Node REPL session. @@ -103,7 +101,7 @@ You need to import some dependencies into your Node REPL session. -## Set Session Variables +## Set session variables You'll need a few variables throughout this tutorial. Let's set those up now. @@ -139,7 +137,7 @@ Create an instance of the `CrossChainMessenger` class: ```js file=/public/tutorials/sdk-view-txns.js#L19-L24 hash=158c6888c82bdc2f07c37c3edb3a9a6a ``` -## Query for Deposits +## Query for deposits You'll first query for all of the deposits made by the target address. The `CrossChainMessenger` has a convenient function called `getDepositsByAddress` that makes this easy. @@ -158,7 +156,7 @@ The `CrossChainMessenger` has a convenient function called `getDepositsByAddress -## Query for Withdrawals +## Query for withdrawals You'll next query for all of the withdrawals made by the target address. The `CrossChainMessenger` has a convenient function called `getWithdrawalsByAddress` that makes this easy. diff --git a/pages/builders/app-developers/tutorials/send-tx-from-eth.mdx b/pages/builders/app-developers/tutorials/send-tx-from-eth.mdx index d7a53efe3..5b95054cf 100644 --- a/pages/builders/app-developers/tutorials/send-tx-from-eth.mdx +++ b/pages/builders/app-developers/tutorials/send-tx-from-eth.mdx @@ -1,5 +1,5 @@ --- -title: Triggering OP Mainnet Transactions from Ethereum +title: Triggering OP Mainnet transactions from Ethereum lang: en-US description: Learn how to force transaction inclusion without the OP Mainnet Sequencer. --- @@ -8,9 +8,7 @@ import { Callout, Steps } from 'nextra/components' import { WipCallout } from '@/components/WipCallout' -# Triggering OP Mainnet Transactions from Ethereum - - +# Triggering OP Mainnet transactions from Ethereum OP Mainnet currently uses a single-Sequencer block production model. This means that there is only one Sequencer active on the network at any given time. @@ -28,7 +26,7 @@ You'll use the OP Sepolia testnet, but the same logic will apply to OP Mainnet. * [node](https://nodejs.org/en/) * [pnpm](https://pnpm.io/installation) -## Create a Demo Project +## Create a demo project You're going to use the `@eth-optimism/contracts-ts` package for this tutorial. Since the `@eth-optimism/contracts-ts` package is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. @@ -83,7 +81,7 @@ You can use [this faucet](https://sepoliafaucet.com) to get ETH on Sepolia. You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on OP Sepolia. -## Add a Private Key to Your Environment +## Add a private key to your environment You need a private key in order to sign transactions. Set your private key as an environment variable with the `export` command. @@ -104,7 +102,7 @@ node This will bring up a Node REPL prompt that allows you to run javascript code. -## Import Dependencies +## Import dependencies You need to import some dependencies into your Node REPL session. @@ -127,7 +125,7 @@ You need to import some dependencies into your Node REPL session. -## Set Session Variables +## Set session variables You'll need a few variables throughout this tutorial. Let's set those up now. @@ -146,7 +144,7 @@ Let's set those up now. -## Check Your Initial Balance +## Check your initial balance You'll be sending a small amount of ETH as part of this tutorial. Quickly check your balance on OP Sepolia so that you know how much you had at the start of the tutorial. @@ -154,7 +152,7 @@ Quickly check your balance on OP Sepolia so that you know how much you had at th ```js file=/public/tutorials/send-tx-from-eth.js#L15-L16 hash=062c80bbd70e12144fe45532611a1846 ``` -## Trigger the Transaction +## Trigger the transaction Now you'll use the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/L1/OptimismPortal.sol) contract to trigger a transaction on OP Sepolia by sending a transaction on Sepolia. @@ -200,7 +198,7 @@ Here you'll determine the hash of the L2 transaction using the `@eth-optimism/co -## Check Your Updated Balance +## Check your updated balance You should have a little less ETH on OP Sepolia now. Check your balance to confirm. @@ -213,7 +211,7 @@ Make sure that the difference is equal to the amount you were expecting to send. ```js file=/public/tutorials/send-tx-from-eth.js#L57-L58 hash=e44227b3ca6f46e6a16a10689b11ad39 ``` -## Next Steps +## Next steps You've successfully triggered a transaction on OP Sepolia by sending a transaction on Sepolia. Although this tutorial demonstrated the simple example of sending a basic ETH transfer from your L2 address via the OptimismPortal contract, you can use this same technique to trigger any transaction you want. diff --git a/pages/builders/app-developers/tutorials/standard-bridge-custom-token.mdx b/pages/builders/app-developers/tutorials/standard-bridge-custom-token.mdx index d6e2a5dbd..71eb9a639 100644 --- a/pages/builders/app-developers/tutorials/standard-bridge-custom-token.mdx +++ b/pages/builders/app-developers/tutorials/standard-bridge-custom-token.mdx @@ -1,5 +1,5 @@ --- -title: Bridging Your Custom ERC-20 Token Using the Standard Bridge +title: Bridging your custom ERC-20 token using the Standard Bridge lang: en-US description: Learn how to bridge your custom ERC-20 token using the standard bridge. --- @@ -8,9 +8,7 @@ import { Callout, Steps } from 'nextra/components' import { WipCallout } from '@/components/WipCallout' -# Bridging Your Custom ERC-20 Token Using the Standard Bridge - - +# Bridging your custom ERC-20 token using the Standard Bridge In this tutorial you'll learn how to bridge a custom ERC-20 token from Ethereum to an OP Stack chain using the Standard Bridge system. This tutorial is meant for developers who already have an existing ERC-20 token on Ethereum and want to create a bridged representation of that token on OP Mainnet. @@ -45,19 +43,19 @@ You can use [this faucet](https://sepoliafaucet.com/) to get ETH on Sepolia. You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on OP Sepolia. -## Add OP Sepolia to Your Wallet +## Add OP Sepolia to your wallet This tutorial uses [Remix](https://remix.ethereum.org) to deploy contracts. You will need to add the OP Sepolia network to your wallet in order to follow this tutorial. You can use [this website](https://chainid.link?network=op-sepolia) to connect your wallet to OP Sepolia. -## Get an L1 ERC-20 Token Address +## Get an L1 ERC-20 token address You will need an L1 ERC-20 token for this tutorial. If you already have an L1 ERC-20 token deployed on Sepolia, you can skip this step. Otherwise, you can use the testing token located at [`0x5589BB8228C07c4e15558875fAf2B859f678d129`](https://sepolia.etherscan.io/address/0x5589BB8228C07c4e15558875fAf2B859f678d129) that includes a `faucet()` function that can be used to mint tokens. -## Create an L2 ERC-20 Token +## Create an L2 ERC-20 token Once you have an L1 ERC-20 token, you can create a corresponding L2 ERC-20 token on OP Sepolia. This tutorial will use [Remix](https://remix.ethereum.org) so you can easily deploy a token without a framework like [Hardhat](https://hardhat.org) or [Foundry](https://getfoundry.sh). @@ -113,7 +111,7 @@ _SYMBOL: "MCL2T" -## Bridge Some Tokens +## Bridge some tokens Now that you have an L2 ERC-20 token, you can bridge some tokens from L1 to L2. Check out the tutorial on [Bridging ERC-20 tokens with the Optimism SDK](./cross-dom-bridge-erc20) to learn how to bridge your L1 ERC-20 to L2s using the Optimism SDK. diff --git a/pages/builders/app-developers/tutorials/standard-bridge-standard-token.mdx b/pages/builders/app-developers/tutorials/standard-bridge-standard-token.mdx index 57c589f68..6046bd1f7 100644 --- a/pages/builders/app-developers/tutorials/standard-bridge-standard-token.mdx +++ b/pages/builders/app-developers/tutorials/standard-bridge-standard-token.mdx @@ -1,5 +1,5 @@ --- -title: Bridging Your Standard ERC-20 Token Using the Standard Bridge +title: Bridging your standard ERC-20 token using the Standard Bridge lang: en-US description: Learn how to bridge your standard ERC-20 token using the standard bridge. --- @@ -10,12 +10,10 @@ import { WipCallout } from '@/components/WipCallout' # Bridging Your Standard ERC-20 Token Using the Standard Bridge - - In this tutorial you'll learn how to bridge a standard ERC-20 token from Ethereum to an OP Stack chain using the Standard Bridge system. This tutorial is meant for developers who already have an existing ERC-20 token on Ethereum and want to create a bridged representation of that token on layer 2. -This tutorial explains how to use the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/186e46a47647a51a658e699e9ff047d39444c2de/packages/contracts-bedrock/contracts/universal/OptimismMintableERC20Factory.sol) to deploy a standardized ERC-20 token on layer 2. +This tutorial explains how to use the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/universal/OptimismMintableERC20Factory.sol) to deploy a standardized ERC-20 token on layer 2. Tokens created by this factory contract are compatible with the Standard Bridge system and include basic logic for deposits, transfers, and withdrawals. If you want to include specialized logic within your L2 token, see the tutorial on [Bridging Your Custom ERC-20 Token Using the Standard Bridge](./standard-bridge-custom-token) instead. @@ -28,7 +26,7 @@ The Standard Bridge **does not** support [**fee on transfer tokens**](https://gi The Standard Bridge system requires that L2 representations of L1 tokens implement the [`IOptimismMintableERC20`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/universal/IOptimismMintableERC20.sol) interface. This interface is a superset of the standard ERC-20 interface and includes functions that allow the bridge to properly verify deposits/withdrawals and mint/burn tokens as needed. Your L2 token contract must implement this interface in order to be bridged using the Standard Bridge system. -This tutorial will show you how to use the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/186e46a47647a51a658e699e9ff047d39444c2de/packages/contracts-bedrock/contracts/universal/OptimismMintableERC20Factory.sol) to create a basic standardized ERC-20 token on layer 2. +This tutorial will show you how to use the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/universal/OptimismMintableERC20Factory.sol) to create a basic standardized ERC-20 token on layer 2. ## Dependencies @@ -44,7 +42,7 @@ You can use [this faucet](https://sepoliafaucet.com) to get ETH on Sepolia. You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on OP Sepolia. -## Get an L1 ERC-20 Token Address +## Get an L1 ERC-20 token address You will need an L1 ERC-20 token for this tutorial. If you already have an L1 ERC-20 token deployed on Sepolia, you can skip this step. @@ -52,7 +50,7 @@ Otherwise, you can use the testing token located at [`0x5589BB8228C07c4e15558875 ## Create an L2 ERC-20 Token -Once you have an L1 ERC-20 token, you can use the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/186e46a47647a51a658e699e9ff047d39444c2de/packages/contracts-bedrock/contracts/universal/OptimismMintableERC20Factory.sol) to create a corresponding L2 ERC-20 token on OP Sepolia. +Once you have an L1 ERC-20 token, you can use the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/universal/OptimismMintableERC20Factory.sol) to create a corresponding L2 ERC-20 token on OP Sepolia. All tokens created by the factory implement the `IOptimismMintableERC20` interface and are compatible with the Standard Bridge system. @@ -85,7 +83,7 @@ Set your L1 ERC-20 token address as an environment variable with the `export` co {

Deploy your L2 ERC-20 token

} -You can now deploy our L2 ERC-20 token using the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/186e46a47647a51a658e699e9ff047d39444c2de/packages/contracts-bedrock/contracts/universal/OptimismMintableERC20Factory.sol). +You can now deploy our L2 ERC-20 token using the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/universal/OptimismMintableERC20Factory.sol). Use the `cast` command to trigger the deployment function on the factory contract. This example command creates a token with the name "My Standard Demo Token" and the symbol "L2TKN". The resulting L2 ERC-20 token address is printed to the console. @@ -95,7 +93,7 @@ The resulting L2 ERC-20 token address is printed to the console. -## Bridge Some Tokens +## Bridge some tokens Now that you have an L2 ERC-20 token, you can bridge some tokens from L1 to L2. Check out the tutorial on [Bridging ERC-20 tokens with the Optimism SDK](./cross-dom-bridge-erc20) to learn how to bridge your L1 ERC-20 to L2s using the Optimism SDK. diff --git a/pages/builders/cex-wallet-developers/cex-support.mdx b/pages/builders/cex-wallet-developers/cex-support.mdx index 044c5118e..b9bf2473c 100644 --- a/pages/builders/cex-wallet-developers/cex-support.mdx +++ b/pages/builders/cex-wallet-developers/cex-support.mdx @@ -1,12 +1,12 @@ --- -title: Supporting OP Mainnet in Your Exchange +title: Supporting OP Mainnet in your exchange lang: en-US description: Learn how to support OP Mainnet in your exchange. --- import { Callout } from 'nextra/components' -# Supporting OP Mainnet in Your Exchange +# Supporting OP Mainnet in your exchange Check out this guide to get an overview of everything you need to know to properly support OP Mainnet within your exchange. @@ -17,23 +17,23 @@ You can use your favorite Ethereum libraries and tools to work with OP Mainnet. Head over to the [Networks and RPC Endpoints](/chain/networks) page for network connection details and check out the [RPC Providers](/builders/tools/connect/rpc-providers) page for an updated list of RPC providers that support OP Mainnet. If you need to run your own OP Mainnet node, head over to the [Node Operator](/builders/node-operators/rollup-node) guide. -## Native Gas Token (ETH) +## Native gas token (ETH) OP Mainnet uses ETH as its native gas token. Transactions are paid for in ETH and account balances are denominated in ETH. -## Transaction Fees +## Transaction fees OP Mainnet charges the standard gas fee for transactions, but also charges an additional L1 data fee for the cost of publishing transaction data to Ethereum. Check out the [Transaction Fees](/stack/transactions/fees) page for more information about how transaction fees work on OP Mainnet. -## Smart Contracts +## Smart contracts Smart contracts on OP Mainnet function the same way they do on Ethereum. This includes ERC-20 token contracts. You can use your existing logic for managing withdrawals and deposits of ERC-20 tokens. -## Token Addresses +## Token addresses The ERC-20 contract address for a token on OP Mainnet may differ from the address for the same token on Ethereum. Make sure to reference the [Bridged Token Addresses](/chain/tokenlist) to confirm that you are using the correct token addresses in your application. @@ -44,7 +44,7 @@ You may need to transfer ETH or ERC-20 tokens between OP Mainnet and Ethereum. For instance, you may need to use this functionality to balance the supply of ETH on OP Mainnet and Ethereum depending on the demand for withdrawals and deposits on the two networks. Refer to the [Basics of Bridging](/builders/app-developers/bridging/basics) and the [Standard Bridge](/builders/app-developers/bridging/standard-bridge) guides for more information about how to bridge ETH and ERC-20 tokens between OP Mainnet and Ethereum. -## Transaction Statuses +## Transaction statuses OP Mainnet transactions have a number of different statuses during the transaction lifecycle. Refer to the [Transaction Statuses](/builders/app-developers/transactions/statuses) page for more information about the different transaction statuses and how to handle them in your application. @@ -55,7 +55,7 @@ For instance, you may only want to credit a deposit if the transaction is finali Make sure to understand the various transaction statuses to avoid security issues in your application. -## Audits and Security Reviews +## Audits and security reviews The OP Stack codebase upon which OP Mainnet is built has undergone a number of security reviews. Visit [GitHub](https://github.com/ethereum-optimism/optimism/tree/develop/docs/security-reviews) for a full list of the most recent reports. diff --git a/pages/builders/cex-wallet-developers/wallet-support.mdx b/pages/builders/cex-wallet-developers/wallet-support.mdx index 31c085699..ff0341390 100644 --- a/pages/builders/cex-wallet-developers/wallet-support.mdx +++ b/pages/builders/cex-wallet-developers/wallet-support.mdx @@ -1,12 +1,12 @@ --- -title: Supporting OP Mainnet in Your Wallet +title: Supporting OP Mainnet in your wallet lang: en-US description: Learn how to support OP Mainnet in your wallet. --- import { Callout } from 'nextra/components' -# Supporting OP Mainnet in Your Wallet +# Supporting OP Mainnet in your wallet Check out this guide to get an overview of everything you need to know to properly support OP Mainnet within your wallet. @@ -17,12 +17,12 @@ You can use your favorite Ethereum libraries and tools to work with OP Mainnet. Head over to the [Networks and RPC Endpoints](/chain/networks) page for network connection details and check out the [RPC Providers](/builders/tools/connect/rpc-providers) page for an updated list of RPC providers that support OP Mainnet. If you need to run your own OP Mainnet node, head over to the [Node Operator](/builders/node-operators/rollup-node) guide. -## Native Gas Token (ETH) +## Native gas token (ETH) OP Mainnet uses ETH as its native gas token. Transactions are paid for in ETH and account balances are denominated in ETH. -## Transaction Fees +## Transaction fees OP Mainnet charges the standard gas fee for transactions, but also charges an additional L1 data fee for the cost of publishing transaction data to Ethereum. Check out the [Transaction Fees](/stack/transactions/fees) page for more information about how transaction fees work on OP Mainnet. @@ -32,12 +32,12 @@ Transactions on OP Mainnet must pay for an additional "L1 data fee" that often h Make sure that your wallet is configured to display this fee to your users so that they are aware of the total cost of their transaction. -## Smart Contracts +## Smart contracts Smart contracts on OP Mainnet function the same way they do on Ethereum. You can use your favorite Ethereum libraries and tools to interact with smart contracts on OP Mainnet. -## Token Addresses +## Token addresses The ERC-20 contract address for a token on OP Mainnet may differ from the address for the same token on Ethereum. Addresses for many common tokens will differ between OP Mainnet and Ethereum. @@ -49,7 +49,7 @@ You may need to transfer ETH or ERC-20 tokens between OP Mainnet and Ethereum. This is a useful feature for users who want to move tokens between the two networks. Refer to the [Basics of Bridging](/builders/app-developers/bridging/basics) and the [Standard Bridge](/builders/app-developers/bridging/standard-bridge) guides for more information about how to bridge ETH and ERC-20 tokens between OP Mainnet and Ethereum. -## Transaction Statuses +## Transaction statuses OP Mainnet transactions have a number of different statuses during the transaction lifecycle. The status of a transaction can be useful for users. diff --git a/pages/builders/chain-operators/architecture.mdx b/pages/builders/chain-operators/architecture.mdx index a719bc439..81464816c 100644 --- a/pages/builders/chain-operators/architecture.mdx +++ b/pages/builders/chain-operators/architecture.mdx @@ -1,5 +1,5 @@ --- -title: Chain Architecture +title: Chain architecture lang: en-US description: Learn about the OP chain architecture. --- @@ -8,7 +8,7 @@ import Image from 'next/image' import { Callout } from 'nextra/components' import {OpProposerDescriptionShort} from '@/content/index.js' -# Chain Architecture +# Chain architecture This page contains information about the components of the rollup protocol and how they work together to build the layer 2 blockchain from the Chain Operator's @@ -18,7 +18,7 @@ clients. The OP Stack also has some privileged roles that produce L2 blocks. If you want a more detailed view of the OP Stack protocol, check out the [OP Stack section](/stack/getting-started) of our documentation. -## Permissioned Components +## Permissioned components These clients and services work together to enable the block production on the L2 network. Sequencer nodes (`op-geth` + `op-node`) gather proposed transactions from users. @@ -49,7 +49,7 @@ amount of data required to reproduce L2 blocks. -## Ingress Traffic +## Ingress traffic It is important to setup a robust chain architecture to handle large volumes of RPC requests from your users. The Sequencer node has the important job of working with @@ -96,7 +96,7 @@ replicas can help horizontally scale RPC requests. Replica Node Diagram -## Next Steps +## Next steps * Find out how you can support [snap sync](/builders/chain-operators/management/snap-sync) on your chain. diff --git a/pages/builders/chain-operators/configuration/batcher.mdx b/pages/builders/chain-operators/configuration/batcher.mdx index ac07942aa..334a2cbef 100644 --- a/pages/builders/chain-operators/configuration/batcher.mdx +++ b/pages/builders/chain-operators/configuration/batcher.mdx @@ -1,18 +1,18 @@ --- -title: Batcher Configuration +title: Batcher configuration lang: en-US description: Learn the OP Stack batcher configurations. --- import { Callout, Tabs } from 'nextra/components' -# Batcher Configuration +# Batcher configuration This page lists all configuration options for the op-batcher. The op-batcher posts L2 sequencer data to the L1, to make it available for verifiers. The following options are from the `--help` in [v1.7.6](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.6). -## Global Options +## Global options ### active-sequencer-check-duration @@ -262,24 +262,24 @@ default value is `10`. `OP_BATCHER_NUM_CONFIRMATIONS=10` -### plasma.da-server +### altda.da-server HTTP address of a DA Server. - `--plasma.da-server=` - `--plasma.da-server=` + `--altda.da-server=` + `--altda.da-server=` `OP_BATCHER_PLASMA_DA_SERVER=` -### plasma.da-service +### altda.da-service Use DA service type where commitments are generated by plasma server. The default value is `false`. - `--plasma.da-service=` - `--plasma.da-service=false` + `--altda.da-service=` + `--altda.da-service=false` `OP_BATCHER_PLASMA_DA_SERVICE=false` @@ -633,7 +633,7 @@ Print the version. The default value is false. ## Recommendations -### Set Your `OP_BATCHER_MAX_CHANNEL_DURATION` +### Set your `OP_BATCHER_MAX_CHANNEL_DURATION` The default value inside `op-batcher`, if not specified, is still `0`, which means channel duration tracking is disabled. @@ -652,7 +652,7 @@ To minimize costs, we recommend setting your `OP_BATCHER_MAX_CHANNEL_DURATION` * Thus a larger gap between posting batches can result in significant delays in the operation of certain types of high-security applications. -### Configure Your Batcher to Use Multiple Blobs +### Configure your batcher to use multiple blobs The `op-batcher` has the capabilities to send multiple blobs per single blob transaction. This is accomplished by the use of multi-frame channels, see the [specs](https://specs.optimism.io/protocol/derivation.html#frame-format) for more technical details on channels and frames. diff --git a/pages/builders/chain-operators/configuration/overview.mdx b/pages/builders/chain-operators/configuration/overview.mdx index 8a5c74f08..ecf678b17 100644 --- a/pages/builders/chain-operators/configuration/overview.mdx +++ b/pages/builders/chain-operators/configuration/overview.mdx @@ -6,7 +6,7 @@ description: Learn the how to configure an OP Stack chain. import { Callout, Steps } from 'nextra/components' -# Chain Operator Configurations +# Chain operator configurations OP Stack chains can be configured for the Chain Operator's needs. Each component of the stack has its own considerations. See the following for diff --git a/pages/builders/chain-operators/configuration/proposer.mdx b/pages/builders/chain-operators/configuration/proposer.mdx index da7b24846..4702f208c 100644 --- a/pages/builders/chain-operators/configuration/proposer.mdx +++ b/pages/builders/chain-operators/configuration/proposer.mdx @@ -6,13 +6,13 @@ description: Learn the OP Stack proposer configurations. import { Tabs } from 'nextra/components' -# Proposer Configuration +# Proposer configuration This page list all configuration options for op-proposer. The op-proposer posts the output roots to the L1, to make it available for verifiers. The following options are from the `--help` in [v1.7.6](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.6). -## Global Options +## Global options ### active-sequencer-check-duration diff --git a/pages/builders/chain-operators/configuration/rollup.mdx b/pages/builders/chain-operators/configuration/rollup.mdx index 6dd615624..323b0f858 100644 --- a/pages/builders/chain-operators/configuration/rollup.mdx +++ b/pages/builders/chain-operators/configuration/rollup.mdx @@ -1,12 +1,12 @@ --- -title: Rollup Deployment Configuration +title: Rollup deployment configuration lang: en-US description: Learn about the OP Stack rollup deployment configurations. --- import { Callout } from 'nextra/components' -# Rollup Deployment Configuration +# Rollup deployment configuration New OP Stack blockchains are currently configured with a deployment configuration JSON file inside that is passed into the smart contract @@ -29,12 +29,12 @@ This document highlights the deployment configurations and their values. and the actual requirements in the [OP Stack Configurability Specification](https://specs.optimism.io/protocol/configurability.html). -## Deployment Configuration Values +## Deployment configuration values These values are provided to the deployment configuration JSON file when deploying the L1 contracts. -### Offset Values +### Offset values These offset values determine when network upgrades (hardforks) activate on your blockchain. @@ -168,7 +168,7 @@ makes predeployed contracts easily upgradeable. *** -### Proxy Addresses +### Proxy addresses #### l1StandardBridgeProxy @@ -179,7 +179,7 @@ and is used as part of building the L2 genesis state. * **Default value:** None * **Recommended value:** * **Notes:** Must not be `address(0)` -* **Standard Config Requirement:** Implementation contract must the most +* **Standard Config Requirement:** Implementation contract must be the most up-to-date, governance-approved version of the OP Stack codebase, and, if the chain has been upgraded in the past, that the previous versions were a standard release of the codebase. @@ -196,7 +196,7 @@ genesis state. * **Default value:** None * **Recommended value:** * **Notes:** Must not be `address(0)` -* **Standard Config Requirement:** Implementation contract must the most +* **Standard Config Requirement:** Implementation contract must be the most up-to-date, governance-approved version of the OP Stack codebase, and, if the chain has been upgraded in the past, that the previous versions were a standard release of the codebase. @@ -212,7 +212,7 @@ used as part of building the L2 genesis state. * **Default value:** None * **Recommended value:** * **Notes:** Must not be `address(0)` -* **Standard Config Requirement:** Implementation contract must the most +* **Standard Config Requirement:** Implementation contract must be the most up-to-date, governance-approved version of the OP Stack codebase, and, if the chain has been upgraded in the past, that the previous versions were a standard release of the codebase. @@ -228,7 +228,7 @@ used as part of the derivation pipeline. * **Default value:** None * **Recommended value:** * **Notes:** Must not be `address(0)` -* **Standard Config Requirement:** Implementation contract must the most +* **Standard Config Requirement:** Implementation contract must be the most up-to-date, governance-approved version of the OP Stack codebase, and, if the chain has been upgraded in the past, that the previous versions were a standard release of the codebase. @@ -244,7 +244,7 @@ is used as part of the derivation pipeline. * **Default value:** None * **Recommended value:** * **Notes:** Must not be `address(0)` -* **Standard Config Requirement:** Implementation contract must the most +* **Standard Config Requirement:** Implementation contract must be the most up-to-date, governance-approved version of the OP Stack codebase, and, if the chain has been upgraded in the past, that the previous versions were a standard release of the codebase. @@ -263,9 +263,7 @@ Number of seconds between each L2 block. Must be \< = L1 block time (12 on mainn * **Default value:** None * **Recommended value:** * **Notes:** Must not be `0`. Must be less than the L1 blocktime and a whole number. -* **Standard Config Requirement:** 2 seconds. High security and - interoperability compatibility requirement, until de-risked/solved at app - layer. +* **Standard Config Requirement:** 1 or 2 seconds *** @@ -542,7 +540,7 @@ scalar used for fee calculations. *** -### Proposal Fields +### Proposal fields These fields apply to output root proposals. The l2OutputOracleSubmissionInterval is configurable, see the section below for @@ -572,7 +570,7 @@ addition of permissionless proposals. * **Type:** Number * **Default value:** None * **Recommended value:** -* **Notes:** his MUST be the timestamp corresponding to the block defined by +* **Notes:** this MUST be the timestamp corresponding to the block defined by the l1StartingBlockTag. * **Standard Config Requirement:** @@ -686,7 +684,7 @@ SequencerFeeVaultWithdrawalNetwork value. *** -### Minimum Fee Withdrawal Amounts +### Minimum fee withdrawal amounts Withdrawals to L1 are expensive and the minimum fee is to prevent overhead costs of continuous tiny withdrawals. If the withdrawal execution costs more @@ -733,7 +731,7 @@ amount for the SequencerFeeVault. *** -### Withdrawal Network +### Withdrawal network *** @@ -779,7 +777,7 @@ L1 and a value of 1 will withdraw ETH to the recipient address on L2. *** -### Fault Proofs +### Fault proofs *** @@ -973,7 +971,7 @@ instead of the older output oracle mechanism. 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. Learn more [here](/stack/protocol/features/custom-gas-token). +to pay for gas fees. Learn more [here](/stack/beta-features/custom-gas-token). *** @@ -1005,7 +1003,7 @@ gas on L2. 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. Lean more [here](/stack/protocol/features/alt-da-mode). +for sustainably low costs. Learn more [here](/stack/beta-features/alt-da-mode). *** diff --git a/pages/builders/chain-operators/deploy/genesis.mdx b/pages/builders/chain-operators/deploy/genesis.mdx index a6bf9aa69..7004e07d8 100644 --- a/pages/builders/chain-operators/deploy/genesis.mdx +++ b/pages/builders/chain-operators/deploy/genesis.mdx @@ -1,19 +1,24 @@ --- -title: OP Stack Genesis Creation +title: OP Stack genesis creation lang: en-US description: Learn how to create a genesis file for the OP Stack. --- import { Callout } from 'nextra/components' -# OP Stack Genesis Creation +# OP Stack genesis creation + + +This page is out of date and shows the legacy method for genesis file creation. +For the latest recommended method, use [op-deployer](/builders/chain-operators/tools/op-deployer). + The following guide shows you how to generate the L2 genesis file `genesis.json`. This is a JSON file that represents the L2 genesis. You will provide this file to the execution client (op-geth) to initialize your network. There is also the rollup configuration file, `rollup.json`, which will be provided to the consensus client (op-node). -## Solidity Script +## Solidity script At the time of this writing, the preferred method for genesis generation is to use the foundry script located in the monorepo to generate an "L2 state dump" and then pass this into the op-node genesis subcommand. @@ -79,10 +84,10 @@ go run cmd/main.go genesis l2 \ --l2-allocs= \ --outfile.l2= \ --outfile.rollup= \ - --l1-rpc=> + --l1-rpc=> ``` -## Next Steps +## Next steps * Learn how to [initialize](/builders/node-operators/configuration/base-config#initialization-via-genesis-file) `op-geth` with your `genesis.json` file. diff --git a/pages/builders/chain-operators/deploy/overview.mdx b/pages/builders/chain-operators/deploy/overview.mdx index d6ce3695d..1d3617644 100644 --- a/pages/builders/chain-operators/deploy/overview.mdx +++ b/pages/builders/chain-operators/deploy/overview.mdx @@ -1,12 +1,12 @@ --- -title: OP Stack Deployment Overview +title: OP Stack deployment overview lang: en-US description: Learn about the different components of deploying the OP Stack. --- import { Callout } from 'nextra/components' -# OP Stack Deployment Overview +# OP Stack deployment overview When deploying an OP Stack chain, you'll be setting up four different components. It's useful to understand what each of these components does before @@ -14,7 +14,7 @@ you start deploying your chain. The OP Stack can be deployed as a L3, which includes additional considerations. The following information assumes you're deploying a L2 Rollup on Ethereum. -## Smart Contracts +## Smart contracts The OP Stack uses a set of smart contracts on the L1 blockchain to manage aspects of the Rollup. Each OP Stack chain has its own set of L1 smart @@ -27,14 +27,14 @@ contracts that are deployed when the chain is created. changes. Read more about the details on our [Smart Contract Release Section](/stack/smart-contracts#official-releases). -## Sequencer Node +## Sequencer node OP Stack chains use a Sequencer node to gather proposed transactions from users and publish them to the L1 blockchain. OP Stack chains rely on at least one of these Sequencer nodes. You can also run additional replica (non-Sequencer) nodes. -### Consensus Client +### Consensus client OP Stack Rollup nodes, like Ethereum nodes, have a consensus client. The consensus client is responsible for determining the list and ordering of blocks @@ -43,7 +43,7 @@ the OP Stack consensus client exist, including `op-node` (maintained by the Optimism Foundation), [`magi`](https://github.com/a16z/magi) (maintained by a16z) and [`hildr`](https://github.com/optimism-java/hildr) (maintained by OptimismJ). -### Execution Client +### Execution client OP Stack nodes, like Ethereum nodes, also have an execution client. The execution client is responsible for executing transactions and maintaining the @@ -65,7 +65,7 @@ the form of L2 state roots) to the L1 blockchain. This allows smart contracts on L1 to read the state of the L2, which is necessary for cross-chain communication and reconciliation between state changes. -## Software Dependencies +## Software dependencies | Dependency | Version | Version Check Command | | ------------------------------------------------------------- | -------- | --------------------- | @@ -78,7 +78,7 @@ communication and reconciliation between state changes. | [jq](https://github.com/jqlang/jq) | `^1.6` | `jq --version` | | [direnv](https://direnv.net) | `^2` | `direnv --version` | -### Notes on Specific Dependencies +### Notes on specific dependencies #### `node` @@ -114,7 +114,7 @@ then **close your terminal and reopen it** so that the changes take effect (or (and things might not work later). -## Next Steps +## Next steps * Discover how to [deploy the smart contracts](/builders/chain-operators/deploy/smart-contracts). * Find out how to create your [genesis file](/builders/chain-operators/deploy/genesis). diff --git a/pages/builders/chain-operators/deploy/smart-contracts.mdx b/pages/builders/chain-operators/deploy/smart-contracts.mdx index 63a3512f1..2a26e2f10 100644 --- a/pages/builders/chain-operators/deploy/smart-contracts.mdx +++ b/pages/builders/chain-operators/deploy/smart-contracts.mdx @@ -6,7 +6,12 @@ description: Learn how to deploy the OP Stack L1 smart contracts. import { Callout } from 'nextra/components' -# OP Stack Smart Contract Deployment +# OP Stack smart contract deployment + + +This page is out of date and shows the legacy method for smart contract deployment. +For the latest recommended method, use [op-deployer](/builders/chain-operators/tools/op-deployer). + The following guide shows you how to deploy the OP Stack L1 smart contracts. The primary development branch is `develop`, however **you should only deploy @@ -18,7 +23,7 @@ generally not considered backwards compatible. Standard OP Stack chains should use the latest governance approved and audited versions of the smart contract code. -## Deployment Configuration +## Deployment configuration Deploying your OP Stack contracts requires creating a deployment configuration JSON file. You will create a new deployment configuration file in the following @@ -26,20 +31,20 @@ monorepo subdirectory: [packages/contracts-bedrock/deploy-config](https://github For the full set of deployment configuration options and their meanings, you can see the [rollup deployment configuration page](/builders/chain-operators/configuration/rollup). -## Deployment Script +## Deployment script The smart contracts are deployed using [foundry](https://github.com/foundry-rs) and you can find the script's source code in the monorepo at [packages/contracts-bedrock/scripts/deploy/Deploy.s.sol](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/scripts/deploy/Deploy.s.sol). -### State Diff +### State diff Before deploying the contracts, you can verify the state diff by using the `runWithStateDiff()` function signature in the deployment script, which produces the outputs inside [`snapshots/state-diff/`](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock/snapshots/state-diff). Run the deployment with state diffs by executing: ```bash -forge script -vvv scripts/Deploy.s.sol:Deploy --sig 'runWithStateDiff()' --rpc-url $ETH_RPC_URL --broadcast --private-key $PRIVATE_KEY +forge script -vvv scripts/deploy/Deploy.s.sol:Deploy --sig 'runWithStateDiff()' --rpc-url $ETH_RPC_URL --broadcast --private-key $PRIVATE_KEY ``` ### Execution @@ -66,7 +71,7 @@ shared SuperchainConfig contract. ``` DEPLOYMENT_OUTFILE=deployments/artifact.json \ DEPLOY_CONFIG_PATH= \ - forge script scripts/Deploy.s.sol:Deploy \ + forge script scripts/deploy/Deploy.s.sol:Deploy \ --broadcast --private-key $PRIVATE_KEY \ --rpc-url $ETH_RPC_URL ``` @@ -77,7 +82,7 @@ All functions for deploying a single contract are public, meaning that the `--sig` argument to forge script can be used to target the deployment of a single contract. -## Best Practices +## Best practices Production users should deploy their L1 contracts from a contracts release. All contracts releases are on git tags with the following format: @@ -90,7 +95,7 @@ running the additional infrastructure requirements: [op-challenger](https://gith additional changes to the economics of operating a permissionless fault proof that chain operators should have a firm understanding of. -## Next Steps +## Next steps * Learn how to [create your genesis file](/builders/chain-operators/deploy/genesis) * See all [configuration options](/builders/chain-operators/configuration/rollup) and example configurations diff --git a/pages/builders/chain-operators/features/alt-da-mode.mdx b/pages/builders/chain-operators/features/alt-da-mode.mdx index e6f6397c7..409190053 100644 --- a/pages/builders/chain-operators/features/alt-da-mode.mdx +++ b/pages/builders/chain-operators/features/alt-da-mode.mdx @@ -1,19 +1,19 @@ --- -title: How to Run an Alt-DA Mode Chain +title: How to run an Alt-DA mode chain lang: en-US description: Learn how to configure and run an Alt-DA mode chain within the OP Stack. --- import { Callout, Steps } from 'nextra/components' -# How to Run an Alt-DA Mode Chain +# How to run an Alt-DA mode chain The Alt-DA Mode feature is currently in Beta within the MIT-licensed OP Stack. Beta features are built and reviewed by Optimism Collective core contributors, and provide developers with early access to highly requested configurations. These features may experience stability issues, and we encourage feedback from our early users. -This guide provides a walkthrough for chain operators who want to run an Alt-DA Mode chain. See the [Alt-DA Mode Explainer](/stack/protocol/features/alt-da-mode) for a general overview of this OP Stack configuration. +This guide provides a walkthrough for chain operators who want to run an Alt-DA Mode chain. See the [Alt-DA Mode Explainer](/stack/beta-features/alt-da-mode) for a general overview of this OP Stack configuration. An Alt-DA Mode OP Stack chain enables a chain operator to post and read data to any alternative data availability layer that has built a functioning OP Stack DA Server. @@ -35,7 +35,7 @@ You should use at least the following compatible op\* versions when running your - ### Setup Your DA Server + ### Setup your DA server DA Servers are not built or maintained by Optimism Collective Core Contributors. DA servers are maintained by third parties and run at your own risk. Please reach out to the team who built the DA Server you are trying to run with any questions or issues. @@ -44,10 +44,10 @@ You should use at least the following compatible op\* versions when running your * Celestia's docs on how to run the [Celestia DA server](https://github.com/celestiaorg/op-plasma-celestia/blob/main/README.md) * EigenDA's docs on how to run the [EigenDA DA server](https://github.com/Layr-Labs/op-plasma-eigenda/blob/main/README.md) * Avail's docs on how to run the [AvailDA DA Server](https://docs.availproject.org/docs/build-with-avail/Optimium/op-stack/op-stack#setup-avail-da-server) - * 0gDA's docs on how to run the [0gDA DA Server](https://github.com/0glabs/0g-da-op-plasma/blob/op0g/README.md) + * 0gDA's docs on how to run the [0gDA DA Server](https://github.com/0glabs/0g-da-op-plasma) * Near DA's docs on how to run the [Near DA Server](https://github.com/Nuffle-Labs/data-availability/blob/84b484de98f58a91bf12c8abe8df27f5e753f63a/docs/OP-Alt-DA.md) - ### Configure Your `op-node` + ### Configure your `op-node` * Spin up your OP chain as usual but set `--altda.enabled=true` and point both `op-batcher` and `op-node` to the DA server. * No configuration changes are required for `op-geth` or `op-proposer`. @@ -67,7 +67,7 @@ You should use at least the following compatible op\* versions when running your ``` - ### Configure Your Batcher + ### Configure your batcher * Set `--altda.enabled=true` and `--altda.da-service=true`. * Provide the URL for `--atlda.da-server=$DA_SERVER_HTTP_URL`. @@ -88,7 +88,7 @@ You should use at least the following compatible op\* versions when running your After completing steps 1-3 above, you will have an Alt-DA mode chain up and running. - ### Set Your Fee Configuration + ### Set your fee configuration * Chain operators are not posting everything to Ethereum, just commitments, so chain operators will need to determine fee scalars values to charge users. The fee scalar values are network throughput dependent, so values will need to be adjusted by chain operators as needed. * Cost structure for Alt-DA Mode: The transaction data is split up into 128kb chunks and then submitted to your DA Layer. Then, 32 byte commitments are submitted (goes to batch inbox address) to L1 for each 128kb chunk. Then, figure out how much that costs relative to the amount of transactions your chain is putting through. @@ -105,12 +105,12 @@ You should use at least the following compatible op\* versions when running your -## For Node Operators (Full and Archive Nodes) +## For node operators (full and archive nodes) * Run a DA server as laid out in [Step 1](#setup-your-da-server) * Provide the same `--altda.enabled=true, --altda.da-server...` on `op-node` as listed in [Step 2](#configure-your-op-node) -## Inclusion Criteria +## Inclusion criteria Alt DA teams who want to be featured on this page must meet the following criteria: @@ -118,17 +118,17 @@ Alt DA teams who want to be featured on this page must meet the following criter * Supporting detailed documentation, to be referenced [here](#setup-your-da-server) * Functioning OP Stack devnet using your DA server with linked configuration, contract addresses, and RPC address -## Breaking Changes: Renaming Plasma Mode to Alt-DA Mode +## Breaking changes: renaming Plasma Mode to Alt-DA Mode This feature has been renamed from Plasma Mode to Alt-DA Mode in the monorepo at: [0bb2ff5](https://github.com/ethereum-optimism/optimism/commit/0bb2ff57c8133f1e3983820c0bf238001eca119b). There are several breaking changes you should be aware of. These include changes to configuration file parameters, environment variables, and CLI commands. Before proceeding with the migration, ensure you are using [OP Stack v1.9.1](https://github.com/ethereum-optimism/optimism/releases/tag/v1.9.1) or later. -### Modify `rollup.json` Config: +### Modify `rollup.json` config: Update your `rollup.json` configuration file by replacing the old Plasma config with the new Alt-DA config. There are two possible formats for the old Plasma config: -### Legacy Plasma Config +### Legacy plasma config If your config looks like this: @@ -140,7 +140,7 @@ If your config looks like this: "da_resolve_window": 2000, ``` -### Recent Plasma Config +### Recent plasma config Or if it looks like this: @@ -153,7 +153,7 @@ Or if it looks like this: } ``` -### New Alt-DA Config +### New Alt-DA config Replace either of the above configurations with: @@ -170,9 +170,9 @@ Replace either of the above configurations with: Only include fields in the new config that were present in your old config. -## Updating OP Stack Runtime Config Parameters +## Updating OP Stack runtime config parameters -### CLI Parameters +### CLI parameters Update the following CLI parameters for both `op-node` and `op-batcher`: @@ -183,7 +183,7 @@ Update the following CLI parameters for both `op-node` and `op-batcher`: | `--plasma.verify-on-read` | `--altda.verify-on-read` | | `--plasma.da-service` | `--altda.da-service` | -### Environment Variables +### Environment variables #### op-node @@ -222,8 +222,8 @@ After making these changes, your system should be properly configured to use the Remember to thoroughly test your configuration in testnet before going mainnet. -## Next Steps +## Next steps -* Additional questions? See the FAQ section in the [Alt-DA Mode Explainer](/stack/protocol/features/alt-da-mode#faqs). +* Additional questions? See the FAQ section in the [Alt-DA Mode Explainer](/stack/beta-features/alt-da-mode#faqs). * For more detailed info on Alt-DA Mode, see the [specs](https://specs.optimism.io/experimental/alt-da.html). * If you experience any problems, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/features/bridged-usdc-standard.mdx b/pages/builders/chain-operators/features/bridged-usdc-standard.mdx index f352c5e12..9158881b2 100644 --- a/pages/builders/chain-operators/features/bridged-usdc-standard.mdx +++ b/pages/builders/chain-operators/features/bridged-usdc-standard.mdx @@ -12,7 +12,7 @@ This explainer provides a high-level overview of the Bridged USDC Standard and h ## Bridged USDC Standard -USDC is one of the most bridged assets across the crypto ecosystem, and USDC is often bridged to new chains prior to any action from Circle. This can create a challenge when bridged USDC achieves substantial marketshare, but native USDC (issued by Circle) is preferred by the ecosystem, leading to fragmentation between multiple versions of USDC. Circle introduced the [Bridged USDC Standard](https://www.circle.com/en/bridged-usdc) to ensure that chain operators can easily deploy a form of bridged USDC that is capable of being upgraded in-place by Circle to native USDC, if and when appropriate, and prevent the fragmentation problem. +USDC is one of the most bridged assets across the crypto ecosystem, and USDC is often bridged to new chains prior to any action from Circle. This can create a challenge when bridged USDC achieves substantial market share, but native USDC (issued by Circle) is preferred by the ecosystem, leading to fragmentation between multiple versions of USDC. Circle introduced the [Bridged USDC Standard](https://www.circle.com/en/bridged-usdc) to ensure that chain operators can easily deploy a form of bridged USDC that is capable of being upgraded in-place by Circle to native USDC, if and when appropriate, and prevent the fragmentation problem. Bridged USDC Standard for the OP Stack allows for an efficient and modular solution for expanding the Bridged USDC Standard across the Superchain ecosystem. @@ -28,7 +28,7 @@ Chain operators can use the Bridged USDC Standard for the OP Stack to get bridge The referenced implementation for the OP Stack has undergone [audits from Spearbit](https://github.com/defi-wonderland/opUSDC/blob/main/audits/spearbit.pdf) and is recommended for production use. -## Next Steps +## Next steps * Ready to get started? Read the setup guide for the [Bridged USDC Standard for the OP Stack](https://github.com/defi-wonderland/opUSDC#setup). * If you experience any problems, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/features/custom-gas-token.mdx b/pages/builders/chain-operators/features/custom-gas-token.mdx index f2a42c986..599e43a6b 100644 --- a/pages/builders/chain-operators/features/custom-gas-token.mdx +++ b/pages/builders/chain-operators/features/custom-gas-token.mdx @@ -1,22 +1,22 @@ --- -title: How to Run a Custom Gas Token Chain +title: How to run a custom gas token chain lang: en-US description: Learn how to run a custom gas token chain. --- import { Callout, Steps } from 'nextra/components' -# How to Run a Custom Gas Token Chain +# How torRun a custom gas token chain The Custom Gas Token feature is a Beta feature of the MIT licensed OP Stack. While it has received initial review from core contributors, it is still undergoing testing, and may have bugs or other issues. -This guide provides a walkthrough for chain operators who want to run a custom gas token chain. See the [Custom Gas Token Explainer](/stack/protocol/features/custom-gas-token) for a general overview of this OP Stack feature. +This guide provides a walkthrough for chain operators who want to run a custom gas token chain. See the [Custom Gas Token Explainer](/stack/beta-features/custom-gas-token) for a general overview of this OP Stack feature. An OP Stack chain that uses the custom gas token feature enables an end user to deposit an L1 native ERC20 token into L2 where that asset is minted as the native L2 asset and can be used to pay for gas on L2. - ### Deploying Your Contracts + ### Deploying your contracts * Checkout the [`v2.0.0-beta.3` of the contracts](https://github.com/ethereum-optimism/optimism/tree/op-contracts/v2.0.0-beta.3) and use the commit to deploy. @@ -56,7 +56,7 @@ section of the docs. ```bash DEPLOYMENT_OUTFILE=deployments/artifact.json \ DEPLOY_CONFIG_PATH= \ - forge script scripts/Deploy.s.sol:Deploy \ + forge script scripts/deploy/Deploy.s.sol:Deploy \ --broadcast --private-key $PRIVATE_KEY \ --rpc-url $ETH_RPC_URL ``` @@ -87,7 +87,7 @@ section of the docs. * `DEPLOY_CONFIG_PATH` is the path to the file for the deploy config used to deploy * `STATE_DUMP_PATH` is a path to the generated L2 allocs file, this is the genesis state and is required for the next step. - ### Generating L2 Genesis + ### Generating L2 genesis The `op-node` is used to generate the final L2 genesis file. It takes the allocs created by the forge script as input for the `--l2-allocs` flag. @@ -101,7 +101,7 @@ section of the docs. --outfile.rollup ``` - ### Spinning Up Your Infrastructure + ### Spinning up your infrastructure Ensure that the end to end system is running. @@ -125,7 +125,7 @@ section of the docs. cast call --rpc-url $L1_ETH_RPC_URL 'isCustomGasToken()(bool)' ``` - ### Depositing Custom Gas Token into the Chain + ### Depositing custom gas token into the chain * To deposit the custom gas token into the chain, users must use the **`OptimismPortalProxy.depositERC20Transaction`** method * Users MUST first `approve()` the `OptimismPortal` before they can deposit tokens using `depositERC20Transaction`. @@ -141,7 +141,7 @@ section of the docs. ) public; ``` - ### Withdrawing Custom Gas Tokens out of the Chain + ### Withdrawing custom gas tokens out of the chain * To withdraw your native custom gas token from the chain, users must use the **`L2ToL1MessagePasser.initiateWithdrawal`** method. Proving and finalizing withdrawals is identical to the process on chains that use ETH as the native gas token. @@ -154,8 +154,8 @@ section of the docs. ``` -## Next Steps +## Next steps -* Additional questions? See the FAQ section in the [Custom Gas Token Explainer](/stack/protocol/features/custom-gas-token#faqs). +* Additional questions? See the FAQ section in the [Custom Gas Token Explainer](/stack/beta-features/custom-gas-token#faqs). * For more detailed info on custom gas tokens, see the [specs](https://specs.optimism.io/experimental/custom-gas-token.html). * If you experience any problems, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/features/preinstalls.mdx b/pages/builders/chain-operators/features/preinstalls.mdx index 1b571d9aa..7c21d6596 100644 --- a/pages/builders/chain-operators/features/preinstalls.mdx +++ b/pages/builders/chain-operators/features/preinstalls.mdx @@ -6,7 +6,7 @@ description: Learn how to use preinstalls on your chain. import { Callout, Steps } from 'nextra/components' -# OP Stack Preinstalls +# OP Stack preinstalls This guide explains OP Stack preinstalls and what it brings to developers. To go to production on a new chain, developers need their core contracts: Gnosis Safes, the 4337 entrypoint, create2deployer, etc. On a blank EVM, these contracts can take weeks to be deployed. Now, core contracts come *preinstalled* on the OP Stack -- no third party deployment necessary. @@ -19,7 +19,7 @@ With these contracts preinstalled at set addresses, developers can also expect a Preinstalls are automatically enabled for all new OP chains after Ecotone. -## Contracts and Deployed Addresses +## Contracts and deployed addresses This table lists the specific contracts to be pre/deployed for new OP Chains. @@ -36,6 +36,6 @@ This table lists the specific contracts to be pre/deployed for new OP Chains. | [`permit2`](https://github.com/Uniswap/permit2) | `0x000000000022D473030F116dDEE9F6B43aC78BA3` | | [ERC-4337 Entrypoint `v0.6.0`](https://github.com/eth-infinitism/account-abstraction/tree/v0.6.0) | `0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789`
`SenderCreator` dependency @ `0x7fc98430eaedbb6070b35b39d798725049088348` on ETH mainnet | -## Resources and Next Steps +## Resources and next steps * Still Have Questions? You can reach us in our [developer support forum](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/features/span-batches.mdx b/pages/builders/chain-operators/features/span-batches.mdx index ccddabd3c..250257df5 100644 --- a/pages/builders/chain-operators/features/span-batches.mdx +++ b/pages/builders/chain-operators/features/span-batches.mdx @@ -6,7 +6,7 @@ description: Learn how to use and enable span batches on your chain. import { Callout, Steps } from 'nextra/components' -# Span Batches +# Span batches Span batches are an important feature that optimizes batch processing within the chain. This section provides an overview of span batches, instructions on how to enable them, and links to detailed design documents. @@ -14,7 +14,7 @@ Span batches are an important feature that optimizes batch processing within the Span batches allow for efficient processing of multiple batches in a single operation, reducing overhead and improving performance. By grouping transactions together, span batches can help optimize the throughput of the network. -## Enabling Span Batches +## Enabling span batches To enable span batches, follow these steps: @@ -41,7 +41,7 @@ To enable span batches, follow these steps: * You should see log entries indicating that batches are being processed according to the configured settings. -## Links to Related Pages +## Links to related pages For more detailed information on the design and implementation of span batches, refer to the following resources: diff --git a/pages/builders/chain-operators/hacks/data-availability.mdx b/pages/builders/chain-operators/hacks/data-availability.mdx index 4f33176a5..32218c494 100644 --- a/pages/builders/chain-operators/hacks/data-availability.mdx +++ b/pages/builders/chain-operators/hacks/data-availability.mdx @@ -1,12 +1,12 @@ --- -title: Data Availability Hacks +title: Data availability hacks lang: en-US description: Learn how to modify the default Data Availability Layer module for an OP Stack chain. --- import { Callout } from 'nextra/components' -# Data Availability Hacks +# Data availability hacks OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. diff --git a/pages/builders/chain-operators/hacks/derivation.mdx b/pages/builders/chain-operators/hacks/derivation.mdx index d8ab14d4c..47651c308 100644 --- a/pages/builders/chain-operators/hacks/derivation.mdx +++ b/pages/builders/chain-operators/hacks/derivation.mdx @@ -1,12 +1,12 @@ --- -title: Derivation Hacks +title: Derivation hacks lang: en-US description: Learn how to modify the default Derivation layer module for an OP Stack chain. --- import { Callout } from 'nextra/components' -# Derivation Hacks +# Derivation hacks OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. @@ -28,11 +28,11 @@ Modifying the Derivation layer can have unintended consequences. For example, re ## Modding -### EVM Event-Triggered Transactions +### EVM event-triggered transactions -The default Rollup configuration of the OP Stack includes "deposited"transactions that are triggered whenever a specific event is emitted by the `OptimismPortal` contract on L1. Using the same principle, an OP Stack chain can derive transactions from events emitted by *any* contract on an EVM-based DA. Refer to [attributes.go](https://github.com/ethereum-optimism/optimism/blob/e468b66efedc5f47f4e04dc1acc803d4db2ce383/op-node/rollup/derive/attributes.go#L70) to understand how deposited transactions are derived and how custom transactions can be created. +The default Rollup configuration of the OP Stack includes "deposited" transactions that are triggered whenever a specific event is emitted by the `OptimismPortal` contract on L1. Using the same principle, an OP Stack chain can derive transactions from events emitted by *any* contract on an EVM-based DA. Refer to [attributes.go](https://github.com/ethereum-optimism/optimism/blob/e468b66efedc5f47f4e04dc1acc803d4db2ce383/op-node/rollup/derive/attributes.go#L70) to understand how deposited transactions are derived and how custom transactions can be created. -### EVM Block-Triggered Transactions +### EVM block-triggered transactions Like with events, transactions on an OP Stack chain can be triggered whenever a new block is published on an EVM-based DA. The default Rollup configuration of the OP Stack already includes a block-triggered transaction in the form of [the "L1 info"transaction](https://github.com/ethereum-optimism/optimism/blob/e468b66efedc5f47f4e04dc1acc803d4db2ce383/op-node/rollup/derive/attributes.go#L103) that relays information like the latest block hash, timestamp, and base fee into L2. The Getting Started guide demonstrates the addition of a new block-triggered transaction in the form of a new transaction that reports the amount of gas burned via the base fee on L1. diff --git a/pages/builders/chain-operators/hacks/execution.mdx b/pages/builders/chain-operators/hacks/execution.mdx index 1a8f9c338..495ceb8a1 100644 --- a/pages/builders/chain-operators/hacks/execution.mdx +++ b/pages/builders/chain-operators/hacks/execution.mdx @@ -1,12 +1,12 @@ --- -title: Execution Hacks +title: Execution hacks lang: en-US description: Learn how to modify the default Execution Layer module for an OP Stack chain. --- import { Callout } from 'nextra/components' -# Execution Hacks +# Execution hacks OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. @@ -28,7 +28,7 @@ As with modifications to the Derivation Layer, modifications to the Execution La ## Modding -### EVM Tweaks +### EVM tweaks The default Execution Layer module is the EVM. It's possible to modify the EVM in many different ways like adding new precompiles or inserting predeployed smart contracts into the genesis state. Precompiles can help make common smart contract operations cheaper and can therefore further reduce the cost of execution for your specific use-case. These modifications should be made directly to [the execution client](https://github.com/ethereum-optimism/op-geth). diff --git a/pages/builders/chain-operators/hacks/featured-hacks.mdx b/pages/builders/chain-operators/hacks/featured-hacks.mdx index 81e4e0645..f844e08eb 100644 --- a/pages/builders/chain-operators/hacks/featured-hacks.mdx +++ b/pages/builders/chain-operators/hacks/featured-hacks.mdx @@ -1,12 +1,12 @@ --- -title: Featured Hacks +title: Featured hacks lang: en-US description: Learn about some of the customizations stack developers have made for an OP Stack chain. --- import { Callout } from 'nextra/components' -# Featured Hacks +# Featured hacks OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. @@ -28,7 +28,7 @@ Featured Hacks is a compilation of some of the cool stuff people are building on OPCraft was an OP Stack chain that ran a modified EVM as the backend for a fully onchain 3D voxel game built with [MUD](https://mud.dev/). -### OP Stack Configuration +### OP Stack configuration * Data Availability: Ethereum DA (Goerli) * Sequencer: Single Sequencer @@ -52,7 +52,7 @@ OPCraft was an OP Stack chain that ran a modified EVM as the backend for a fully Ticking Optimism is a proof-of-concept implementation of an OP Stack chain that calls a `tick` function every block. By using the OP Stack, Ticking Optimism avoids the need for off-chain infrastructure to execute a function on a regular basis. Ticking Conway is a system that uses Ticking Optimism to build [Conway's Game of Life](https://conwaylife.com/) onchain. -### OP Stack Configuration +### OP Stack configuration * Data Availability: Ethereum DA (any) * Sequencer: Single Sequencer diff --git a/pages/builders/chain-operators/hacks/overview.mdx b/pages/builders/chain-operators/hacks/overview.mdx index 8a8221f8c..cf7a56dd6 100644 --- a/pages/builders/chain-operators/hacks/overview.mdx +++ b/pages/builders/chain-operators/hacks/overview.mdx @@ -1,12 +1,12 @@ --- -title: Introduction to OP Stack Hacks +title: Introduction to OP Stack hacks lang: en-US description: Learn general information on how to experiment and customize an OP Stack chain. --- import { Callout } from 'nextra/components' -# Introduction to OP Stack Hacks +# Introduction to OP Stack hacks Welcome to OP Stack Hacks, the **highly experimental** region of the OP Stack docs. OP Stack Hacks are an unofficial guide for messing around with the OP Stack. Here you'll find information about ways that the OP Stack can be modified in interesting ways. @@ -18,7 +18,7 @@ OP Stack Hacks create blockchains that aren't exactly OP Stack, and may be insec OP Stack Hacks are not for the faint of heart. You will not be able to receive significant developer support for OP Stack Hacks — be prepared to get your hands dirty and to work without support. -## OP Stack Hack Guides +## OP Stack hack guides We have curated a list of guides to walk you through different OP stack modules that you can customize as a developer. @@ -28,7 +28,7 @@ We have curated a list of guides to walk you through different OP stack modules * [Settlement Hacks](settlement) * [Featured Hacks](featured-hacks) -## OP Stack Hack Tutorials +## OP Stack hack tutorials We also have a handful of tutorials offering step-by-step instructions on how to make customizations to an OP Stack chain. **As a reminder, you will not be able to receive significant developer support for OP Stack Hacks — be prepared to get your hands dirty and to work without support.** diff --git a/pages/builders/chain-operators/hacks/settlement.mdx b/pages/builders/chain-operators/hacks/settlement.mdx index 87baf9d44..f86fe1d06 100644 --- a/pages/builders/chain-operators/hacks/settlement.mdx +++ b/pages/builders/chain-operators/hacks/settlement.mdx @@ -1,12 +1,12 @@ --- -title: Settlement Hacks +title: Settlement hacks lang: en-US description: Learn how to modify the default Settlement Layer module for an OP Stack chain. --- import { Callout } from 'nextra/components' -# Settlement Hacks +# Settlement hacks OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. diff --git a/pages/builders/chain-operators/management/best-practices.mdx b/pages/builders/chain-operators/management/best-practices.mdx index 33184b384..9f268e0ad 100644 --- a/pages/builders/chain-operators/management/best-practices.mdx +++ b/pages/builders/chain-operators/management/best-practices.mdx @@ -1,19 +1,19 @@ --- -title: Chain Operator Best Practices +title: Chain operator best practices lang: en-US description: Learn some best practices for managing the OP Stack's off-chain components. --- import { Callout } from 'nextra/components' -# Chain Operator Best Practices +# Chain operator best practices The following information has some best practices around running the OP Stack's off-chain components. -## Best Practices +## Best practices -### Correct Release Versions +### Correct release versions Chain and node operators should always run the latest production releases of the OP Stack's off chain components. Our latest releases, notes, and changelogs @@ -35,7 +35,7 @@ and `op-geth` releases can be found [here](https://github.com/ethereum-optimism/ version. Since we cannot left-pad with zeroes, the geth major version is not padded. -### Keep Deployment Artifacts +### Keep deployment artifacts After deploying your contracts on Ethereum, you should keep a record of all the deployment artifacts: @@ -49,20 +49,20 @@ created in [packages/contracts-bedrock/deployments](https://github.com/ethereum- deployment * The genesis file that you generated after the contract deployment -### Incremental Upgrade Rollouts +### Incremental upgrade rollouts When upgrading your nodes, take a staggered approach. This means deploying the upgrade gradually across your infrastructure and ensuring things work as expected before making changes to every node. -### Isolate Your Sequencer +### Isolate your sequencer You can isolate your sequencer node, by not connecting it directly to the internet. Instead, you could handle your ingress traffic behind a proxy. Have the proxy forward traffic to replicas and have them gossip the transactions internally. -### Improve Reliability of Peer-to-Peer transactions +### Improve reliability of peer-to-peer transactions These flags can improve the reliability of peer-to-peer transactions from internal replica nodes and the sequencer node. diff --git a/pages/builders/chain-operators/management/blobs.mdx b/pages/builders/chain-operators/management/blobs.mdx index 398d7c08d..605e1b296 100644 --- a/pages/builders/chain-operators/management/blobs.mdx +++ b/pages/builders/chain-operators/management/blobs.mdx @@ -1,5 +1,5 @@ --- -title: Using Blobs +title: Using blobs lang: en-US description: Learn how to switch to using blobs for your chain. --- @@ -15,10 +15,10 @@ This guide walks you through how to switch to using blobs for your chain after E This guide is intended for chains already upgraded to Ecotone. -## Switch to Using Blobs +## Switch to using blobs - ### Determine Scalar Values for Using Blobs + ### Determine scalar values for using blobs The first step to switching to submit data with Blobs is to calculate the scalar values you wish to set for the formula to charge users fees. @@ -27,7 +27,7 @@ This guide walks you through how to switch to using blobs for your chain after E information is tuned to a network like OP Mainnet. For more details on fee scalar, see [Transaction Fees, Ecotone section](/stack/transactions/fees#ecotone). - #### Adjust Fees to Change Margins + #### Adjust fees to change margins As a chain operator, you may want to scale your scalar values up or down either because the throughput of your chain has changed and you are either filling significantly more or less of blobs, or because you wish to simply increase your margin to cover operational expenses. So, to increase or decrease your margin on L1 data costs, you would simply scale both the `l1baseFeeScalar` and the `l1blobBaseFeeScalar` by the same multiple. @@ -39,7 +39,7 @@ This guide walks you through how to switch to using blobs for your chain after E newBlobBaseFeeScalar = prevBlobBaseFeeScalar * 1.1 ``` - ### Update Your Scalar Values for Blobs + ### Update your scalar values for blobs Once you have determined your ideal `BaseFeeScalar` and `BlobBaseFeeScalar`, you will need to apply those values for your chain. The first step is to encode both values into a single value to be set in your L1 Config: @@ -74,7 +74,7 @@ This guide walks you through how to switch to using blobs for your chain after E - ### Update Your Batcher to Post Blobs + ### Update your batcher to post blobs Now that the fee config has been updated, you should immediately configure your batcher! @@ -89,7 +89,7 @@ This guide walks you through how to switch to using blobs for your chain after E * Optionally, you can configure your batcher to support multi-blobs. See [Multi-Blob Batcher Configuration](/builders/chain-operators/configuration/batcher#configure-your-multi-blob-batcher) for more details. -## Switch Back to Using Calldata +## Switch back to using calldata As a chain operator, if the `blobBaseFee` is expensive enough and your chain is not processing enough transactions to meaningfully fill blobs within your @@ -98,7 +98,7 @@ back to posting data to calldata. Utilize the [fee parameter calculator](https:/ blobs back to using calldata. - ### Determine Your Scalar Values for Using Calldata + ### Determine your scalar values for using calldata If you are using calldata, then you can set your `BaseFeeScalar` similarly to how you would have set "scalar" prior to Ecotone, though with a 5-10% bump to @@ -115,11 +115,11 @@ blobs back to using calldata. BlobBaseFeeScalar = 0 ``` - ### Update Your Scalar Values for Using Calldata + ### Update your scalar values for using calldata To set your scalar values, follow the same process as laid out in [Update your Scalar values for Blobs](#update-your-scalar-values-for-blobs). - ### Update Your Batcher to Post Calldata + ### Update your batcher to post calldata Now that the fee config has been updated, you will want to immediately configure your batcher. @@ -131,7 +131,7 @@ blobs back to using calldata. * Ensure your `OP_BATCHER_MAX_CHANNEL_DURATION` is properly set to maximize savings. **NOTE:** While setting a high value here will lower costs, it will be less meaningful than for low throughput chains using blobs. See [OP Batcher Max Channel Configuration](/builders/chain-operators/configuration/batcher#set-your--op_batcher_max_channel_duration) for more details. -## Other Considerations +## Other considerations * For information on L1 Data Fee changes related to the Ecotone upgrade, visit the [Transaction Fees page](/stack/transactions/fees#ecotone). * If you want to enable archive nodes, you will need to access a blob archiver service. You can use [Optimism's](/builders/node-operators/management/snapshots#op-mainnet-archive-node) or [run your own](/builders/chain-operators/tools/explorer#create-an-archive-node). diff --git a/pages/builders/chain-operators/management/key-management.mdx b/pages/builders/chain-operators/management/key-management.mdx index 3fc1d38e8..be6592825 100644 --- a/pages/builders/chain-operators/management/key-management.mdx +++ b/pages/builders/chain-operators/management/key-management.mdx @@ -1,19 +1,19 @@ --- -title: Key Management +title: Key management lang: en-US description: A guide for chain operators on managing private keys on their chain, covering hot and cold wallets, and the use of a HSM. --- import { Callout } from 'nextra/components' -# Managing Your Keys +# Managing your keys This guide informs chain operators on important key management considerations. There are certain [privileged roles](/chain/security/privileged-roles) that need careful consideration. The privileged roles are categorized as hot wallets or cold wallets. -## Hot Wallets +## Hot wallets The addresses for the `Batcher` and the `Proposer` need to have their private keys online somewhere for a component of the system to work. If these addresses @@ -31,7 +31,7 @@ RPC method. if you're interested in whats happening under the hood. -## Cold Wallets +## Cold wallets The addresses for the cold wallets cannot be used without human intervention. These can be set up as multisig contracts, so they can be controlled by groups diff --git a/pages/builders/chain-operators/management/operations.mdx b/pages/builders/chain-operators/management/operations.mdx index 0cbc68941..b85102f96 100644 --- a/pages/builders/chain-operators/management/operations.mdx +++ b/pages/builders/chain-operators/management/operations.mdx @@ -1,15 +1,15 @@ --- -title: Rollup Operations +title: Rollup operations lang: en-US description: Learn basics of rollup operations, such as how to start and stop your rollup, get your rollup config, and how to add nodes. --- import { Callout, Steps } from 'nextra/components' -# Rollup Operations +# Rollup operations This guide reviews the basics of rollup operations, such as how to start your rollup, stop your rollup, get your rollup config, and add nodes. -## Stopping Your Rollup +## Stopping your rollup An orderly shutdown is done in the reverse order to the order in which components were started: @@ -30,7 +30,7 @@ An orderly shutdown is done in the reverse order to the order in which component Make sure you use **CTRL-C** to avoid database corruption. If Geth stops unexpectedly the database can be corrupted. This is known as an "[unclean shutdown](https://geth.ethereum.org/docs/fundamentals/databases#unclean-shutdowns)" and it can lead to a variety of problems for the node when it is restarted. -## Starting Your Rollup +## Starting your rollup To restart the blockchain, use the same order of components you did when you initialized it. @@ -60,7 +60,7 @@ Just wait until it is. -## Getting Your Rollup Config +## Getting your rollup config Use this tool to get your rollup config from `op-node`. This will only work if your chain is **already** in the [superchain-registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json) and `op-node` has been updated to pull those changes in from the registry. @@ -113,13 +113,13 @@ You'll need to run this tool: "use_plasma": false } ``` -### Check the Flags +### Check the flags Ensure that you are using the appropriate flag. The `--network=sepolia` flag allows the tool to pick up the appropriate data from the registry, and uses the OPChains mapping under the hood. -## Adding Nodes +## Adding nodes To add nodes to the rollup, you need to initialize `op-node` and `op-geth`, similar to what you did for the first node. You should *not* add an `op-batcher` because there should be only one. @@ -162,7 +162,7 @@ If you do it this way, you won't have to wait until the transactions are written ### Start `op-node` (using the same command line you used on the initial node) -## Next Steps +## Next steps * See the [Node Configuration](/builders/node-operators/configuration/base-config) guide for additional explanation or customization. * If you experience difficulty at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/management/snap-sync.mdx b/pages/builders/chain-operators/management/snap-sync.mdx index 07baefa52..97e372754 100644 --- a/pages/builders/chain-operators/management/snap-sync.mdx +++ b/pages/builders/chain-operators/management/snap-sync.mdx @@ -1,23 +1,23 @@ --- -title: Using Snap Sync for Chain Operators +title: Using snap sync for chain operators lang: en-US description: Learn how to use and enable snap sync on your OP chain. --- import { Callout, Steps } from 'nextra/components' -# Using Snap Sync for Chain Operators +# Using snap sync for chain operators -This guide reviews the optional feature of Snap Sync for OP chains, including benefits and how to enable the feature. +This guide reviews the optional feature of snap sync for OP chains, including benefits and how to enable the feature. -Snap Sync significantly improves the experience of syncing an OP Stack node. Snap Sync is a native feature of go-ethereum that is now optionally enabled on `op-node` & `op-geth`. -Snap Sync works by downloading a snapshot of the state from other nodes on the network and is then able to start executing blocks from the completed state rather than having to re-execute every single block. -This means that performing a Snap Sync is significantly faster than performing a full sync. +Snap sync significantly improves the experience of syncing an OP Stack node. Snap sync is a native feature of go-ethereum that is now optionally enabled on `op-node` & `op-geth`. +Snap sync works by downloading a snapshot of the state from other nodes on the network and is then able to start executing blocks from the completed state rather than having to re-execute every single block. +This means that performing a snap sync is significantly faster than performing a full sync. * Snap sync enables node operators on your network to sync faster. * Snap sync removes the need for nodes on your post Ecotone network to run a [blob archiver](/builders/node-operators/management/blobs). -## Enable Snap Sync for Chains +## Enable snap sync for chains To enable snap sync, chain operators need to spin up a node which is exposed to the network and has transaction gossip disabled. @@ -29,17 +29,17 @@ For snap sync, all `op-geth` nodes should expose port `30303` TCP and `30303` UD - ### Setup a Snap Sync Node + ### Setup a snap sync node * Expose port `30303` (`op-geth`'s default discovery port) to the internet on TCP and UDP. * Disable transaction gossip with the [`--rollup.disabletxpoolgossip`](/builders/node-operators/configuration/execution-config#rollupdisabletxpoolgossip) flag - ### Enable Snap Sync on Your Network + ### Enable snap sync on your network - * Follow the [Node Operator Snap Sync Guide](/builders/node-operators/management/snap-sync#enable-snap-sync-for-your-node) to enable snap sync for your chain network. + * Follow the [Node operator snap sync guide](/builders/node-operators/management/snap-sync#enable-snap-sync-for-your-node) to enable snap sync for your chain network. ## Next Steps -* See the [Node Configuration](/builders/node-operators/configuration/base-config#configuration) guide for additional explanation or customization. +* See the [Node configuration](/builders/node-operators/configuration/base-config#configuration) guide for additional explanation or customization. * If you experience difficulty at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/management/troubleshooting.mdx b/pages/builders/chain-operators/management/troubleshooting.mdx index f24f8561d..e8a00a10d 100644 --- a/pages/builders/chain-operators/management/troubleshooting.mdx +++ b/pages/builders/chain-operators/management/troubleshooting.mdx @@ -1,14 +1,14 @@ --- -title: Troubleshooting Chain Operations +title: Troubleshooting chain operations lang: en-US description: Learn solutions to common problems when troubleshooting chain operations. --- -# Troubleshooting: Chain Operations +# Troubleshooting: chain operations This page lists common troubleshooting scenarios and solutions for chain operators. -## EvmError in Contract Deployment +## EvmError in contract deployment L1 smart contract deployment fails with the following error: @@ -31,7 +31,7 @@ You can generate a random salt value using the following command: export IMPL_SALT=$(openssl rand -hex 32) ``` -## Failed to Find the L2 Heads to Start From +## Failed to find the L2 Heads to start from `op-node` fails to execute the derviation process with the following error: @@ -54,7 +54,7 @@ If you are not following the tutorial, make sure to take the following steps: 4. Reinitialize `op-geth` with the `genesis.json` file. 5. Restart `op-geth` and `op-node`. -## Batcher Unable to Publish Transaction +## Batcher unable to publish transaction `op-batcher` fails to publish transactions with the following error: diff --git a/pages/builders/chain-operators/self-hosted.mdx b/pages/builders/chain-operators/self-hosted.mdx index 200eb7f4b..a94ee4080 100644 --- a/pages/builders/chain-operators/self-hosted.mdx +++ b/pages/builders/chain-operators/self-hosted.mdx @@ -1,16 +1,16 @@ --- -title: How to Start a Self-Hosted Chain +title: How to start a self-hosted chain lang: en-US description: Learn how to start a self-hosted OP Chain with standard configuration. --- import { Callout, Steps } from 'nextra/components' -# How to Start a Self-Hosted Chain +# How to start a self-hosted chain This guide provides an overview of how to start a self-hosted OP Chain with standard configuration. It walks you through how to build, configure, test, and launch your OP Chain. To skip ahead to custom features or settings, you can explore the [chain operator tutorials](#chain-operator-tutorials). -## Build Your Chain +## Build your chain There are two main steps to get started building your own self-hosted OP Chain: learn fundamental components of OP chains and spin up an OP Stack testnet chain. @@ -38,7 +38,7 @@ There are two main steps to get started building your own self-hosted OP Chain: * Just follow the [Creating Your Own L2 Rollup Testnet](/builders/chain-operators/tutorials/create-l2-rollup) tutorial to get started. -## Configure Your Chain +## Configure your chain OP Chains can be configured for throughput, cost, and other decentralization tradeoffs. The following steps are intended for standard configuration of OP Chains. @@ -63,7 +63,7 @@ OP Chains can be configured for throughput, cost, and other decentralization tra * Enable [analytics tracking for your OP Chain](/builders/node-operators/management/metrics), to immediately generate onchain metrics after mainnet launch. -## Test Your Chain +## Test your chain Before launching on Mainnet, thoroughly test and debug OP Chain contracts, features, and security. Here are your options. @@ -84,11 +84,11 @@ Before launching on Mainnet, thoroughly test and debug OP Chain contracts, featu * Run [basic transaction tests](https://metamask.io/) using Metamask. -## Launch Your Chain on Mainnet +## Launch your chain on Mainnet After testing is complete, you are ready to launch your OP Chain on Mainnet. Optionally, you can also request [launch support](https://share.hsforms.com/1yENj8CV9TzGYBASD0JC8_gqoshb) and subscribe to [receive chain upgrade notifications](https://github.com/ethereum-optimism/developers/discussions/categories/announcements). -## Chain Operator Tutorials +## Chain operator tutorials Here's a curated collection of chain operator tutorials put together by the Optimism community. They'll help you get a head start deploying your first OP Stack chain. @@ -105,7 +105,7 @@ They'll help you get a head start deploying your first OP Stack chain. You can also [suggest a new tutorial](https://github.com/ethereum-optimism/docs/issues/new?assignees=\&labels=tutorial%2Cdocumentation%2Ccommunity-request\&projects=\&template=suggest_tutorial.yaml\&title=%5BTUTORIAL%5D+Add+PR+title) if you have something specific in mind. We'd love to grow this list! -## Next Steps +## Next steps * After deploying your chain, check the [Rollup Operations](./management/operations) guide for common operations you'll need to run with your rollup. * If you run into any problems, please visit the [Chain Troubleshooting Guide](./management/troubleshooting) for help. diff --git a/pages/builders/chain-operators/tools/_meta.json b/pages/builders/chain-operators/tools/_meta.json index 4c5077834..0779e410c 100644 --- a/pages/builders/chain-operators/tools/_meta.json +++ b/pages/builders/chain-operators/tools/_meta.json @@ -1,7 +1,9 @@ { "chain-monitoring": "Chain Monitoring", - "op-challenger": "Configure Challenger For Your Chain", - "op-conductor": "Conductor", - "op-deployer": "Deployer", - "explorer": "Block Explorer" + "explorer": "Block Explorer", + "op-challenger": "op-challenger", + "op-conductor": "op-conductor", + "op-deployer": "op-deployer", + "op-txproxy": "op-txproxy", + "proxyd": "proxyd" } diff --git a/pages/builders/chain-operators/tools/chain-monitoring.mdx b/pages/builders/chain-operators/tools/chain-monitoring.mdx index c97183443..54a225a75 100644 --- a/pages/builders/chain-operators/tools/chain-monitoring.mdx +++ b/pages/builders/chain-operators/tools/chain-monitoring.mdx @@ -1,17 +1,17 @@ --- -title: Chain Monitoring Options +title: Chain monitoring options lang: en-US description: Learn about onchain and offchain monitoring options for your OP Stack chain. --- import { Callout } from 'nextra/components' -# Chain Monitoring Options +# Chain monitoring options This explainer covers the basics of onchain and offchain monitoring options for your OP Stack chain. Onchain monitoring services allow chain operators to monitor the overall system and onchain events. Offchain monitoring lets chain operators to monitor the operation and behavior of nodes and other offchain components. -## Onchain Monitoring Services +## Onchain monitoring services Onchain monitoring services provide insights into the overall system, helping chain operators track and monitor on-chain events. Some examples of onchain monitoring services include `monitorism` and `dispute-mon`. @@ -71,9 +71,9 @@ Additional flags: You can find more info on `op-dispute-mon` on [the repo](https://github.com/ethereum-optimism/optimism/tree/develop/op-dispute-mon). -Chain operators can easily create their grafana dashboard for Dispute Monitor using the following json file: [Download the Dispute Monitor JSON](/grafana/dispute-monitor-1718214549035.json). +Chain operators can easily create their grafana dashboard for Dispute Monitor using the following json file: [Download the Dispute Monitor JSON](/resources/grafana/dispute-monitor-1718214549035.json). -## Offchain Component Monitoring +## Offchain component monitoring Offchain monitoring allows chain operators to monitor the operation and behavior of nodes and other offchain components. Some of the more common components that you'll likely want to monitor include `op-node`, `op-geth`, `op-proposer`, `op-batcher`, and `op-challenger`. The general steps for enabling offchain monitoring is pretty consistent for all the OP components: @@ -108,7 +108,7 @@ You can find more information about these flags in our [Batcher configuration do ### `op-challenger` The `op-challenger` operates as the *honest actor* in the fault dispute system and defends the chain by securing the `OptimismPortal` and ensuring the game always resolves to the correct state of the chain. -For verifying the legitimacy of claims, `op-challenger` relies on a synced, trusted rollup node as well as a trace provider (e.g., [Cannon](/stack/protocol/fault-proofs/cannon)). See the [OP-Challenger Explainer](/stack/protocol/fault-proofs/challenger) for more information on this service. +For verifying the legitimacy of claims, `op-challenger` relies on a synced, trusted rollup node as well as a trace provider (e.g., [Cannon](/stack/fault-proofs/cannon)). See the [OP-Challenger Explainer](/stack/fault-proofs/challenger) for more information on this service. To enable metrics, pass the `--metrics.enabled` flag to `op-challenger` and follow the steps above for customization options. @@ -123,6 +123,6 @@ To enable metrics, pass the `--metrics.enabled` flag to `op-challenger` and foll Metrics listening port ``` -## Next Steps +## Next steps * If you encounter difficulties at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/tools/explorer.mdx b/pages/builders/chain-operators/tools/explorer.mdx index fe42693ac..3046fe498 100644 --- a/pages/builders/chain-operators/tools/explorer.mdx +++ b/pages/builders/chain-operators/tools/explorer.mdx @@ -1,12 +1,12 @@ --- -title: Block Explorer +title: Block explorer lang: en-US description: Learn how to deploy a Blockscout block explorer for your OP Stack chain. --- import { Callout } from 'nextra/components' -# Deploying a Block Explorer +# Deploying a block explorer [Blockscout](https://www.blockscout.com/) is an open source block explorer that supports OP Stack chains. Keep reading for a quick overview on how to deploy Blockscout for your OP Stack chain. @@ -19,7 +19,7 @@ Keep reading for a quick overview on how to deploy Blockscout for your OP Stack * [Docker](https://docs.docker.com/get-docker/) -## Create an Archive Node +## Create an archive node Blockscout needs access to an [archive node](https://www.alchemy.com/overviews/archive-nodes#archive-nodes) for your OP Stack chain to properly index transactions, blocks, and internal interactions. If using `op-geth`, you can run a node in archive mode with the `--gcmode=archive` flag. diff --git a/pages/builders/chain-operators/tools/op-challenger.mdx b/pages/builders/chain-operators/tools/op-challenger.mdx index 760af2647..1fc8b90d9 100644 --- a/pages/builders/chain-operators/tools/op-challenger.mdx +++ b/pages/builders/chain-operators/tools/op-challenger.mdx @@ -1,17 +1,17 @@ --- -title: How to Configure Challenger For Your Chain +title: How to configure challenger for your chain lang: en-US description: Learn how to configure challenger for your OP Stack chain. --- import { Callout, Steps } from 'nextra/components' -# How to Configure Challenger For Your Chain +# How to configure challenger for your chain -This guide provides a walkthrough of setting up the configuration and monitoring options for `op-challenger`. See the [OP-Challenger Explainer](/stack/protocol/fault-proofs/challenger) for a general overview of this fault proofs feature. +This guide provides a walkthrough of setting up the configuration and monitoring options for `op-challenger`. See the [OP-Challenger Explainer](/stack/fault-proofs/challenger) for a general overview of this fault proofs feature. - ### Build the Executable + ### Build the executable * Clone the monorepo @@ -38,7 +38,7 @@ This guide provides a walkthrough of setting up the configuration and monitoring make op-challenger ``` - ### Configure Challenger + ### Configure challenger * Configure challenger with the required flags. Tip: Use the `op-challenger --help` to view all subcommands, command line, and environment variable options. * The example config file below shows the flags to configure in this step: @@ -172,7 +172,7 @@ This guide provides a walkthrough of setting up the configuration and monitoring Challenger will refuse to interact with any games if it doesn't have the matching prestate. - ### Execute Challenger + ### Execute challenger The final step is to execute challenger with the required flags. It will look something like this (but with required flags added): @@ -193,7 +193,7 @@ This guide provides a walkthrough of setting up the configuration and monitoring --hd-path "m/44'/60'/0'/0/8" \ ``` - ### Test and Debug Challenger (Optional) + ### Test and debug challenger (optional) This is an optional step to use `op-challenger` subcommands, which allow chain operators to interact with the fault proof system onchain for testing and debugging purposes. For example, it is possible to test and explore the system in the following ways: @@ -216,8 +216,8 @@ This guide provides a walkthrough of setting up the configuration and monitoring Chain operators can easily create their grafana dashboard for Dispute Monitor using the following json file: [Download the Dispute Monitor JSON](/resources/grafana/dispute-monitor-1718214549035.json). -## Next Steps +## Next steps -* Additional questions? See the FAQ section in the [OP Challenger Explainer](/stack/protocol/fault-proofs/challenger). +* Additional questions? See the FAQ section in the [OP Challenger Explainer](/stack/fault-proofs/challenger). * For more detailed info on `op-challenger`, see the [specs](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html). * If you experience any problems, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/tools/op-conductor.mdx b/pages/builders/chain-operators/tools/op-conductor.mdx index 6d4d6cff0..43dfaf4f1 100644 --- a/pages/builders/chain-operators/tools/op-conductor.mdx +++ b/pages/builders/chain-operators/tools/op-conductor.mdx @@ -12,7 +12,7 @@ This page will teach you what the `op-conductor` service is and how it works on a high level. It will also get you started on setting it up in your own environment. -## Enhancing Sequencer Reliability and Availability +## Enhancing sequencer reliability and availability The [op-conductor](https://github.com/ethereum-optimism/optimism/tree/develop/op-conductor) is an auxiliary service designed to enhance the reliability and availability of @@ -26,7 +26,7 @@ It is important to note that the `op-conductor` does not incorporate Byzantine fault tolerance (BFT). This means the system operates under the assumption that all participating nodes are honest and act correctly. -### Summary of Guarantees +### Summary of guarantees The design of the `op-conductor` provides the following guarantees: @@ -40,14 +40,14 @@ The design of the `op-conductor` provides the following guarantees: **On a high level, `op-conductor` serves the following functions:** -### Raft Consensus Layer Participation +### Raft consensus layer participation -* **Leader Determination:** Participates in the Raft consensus algorithm to +* **Leader determination:** Participates in the Raft consensus algorithm to determine the leader among sequencers. -* **State Management:** Stores the latest unsafe block ensuring consistency +* **State management:** Stores the latest unsafe block ensuring consistency across the system. -### RPC Request Handling +### RPC request handling * **Admin RPC:** Provides administrative RPCs for manual recovery scenarios, including, but not limited to: stopping the leadership vote and removing itself @@ -55,18 +55,18 @@ The design of the `op-conductor` provides the following guarantees: * **Health RPC:** Offers health RPCs for the `op-node` to determine whether it should allow the publishing of transactions and unsafe blocks. -### Sequencer Health Monitoring +### Sequencer health monitoring * Continuously monitors the health of the sequencer (op-node) to ensure optimal performance and reliability. -### Control Loop Management +### Control loop management * Implements a control loop to manage the status of the sequencer (op-node), including starting and stopping operations based on different scenarios and health checks. -## Conductor State Transition +## Conductor state transition The following is a state machine diagram of how the op-conductor manages the sequencers Raft consensus. @@ -84,6 +84,8 @@ At OP Labs, op-conductor is deployed as a kubernetes statefulset because it requires a persistent volume to store the raft log. This guide describes setting up conductor on an existing network without incurring downtime. +You can utilize the [op-conductor-ops](https://github.com/ethereum-optimism/infra/tree/main/op-conductor-ops) tool to confirm the conductor status between the steps. + ### Assumptions This setup guide has the following assumptions: @@ -138,7 +140,7 @@ This setup guide has the following assumptions: {

Pause two conductors

} - Pause `sequencer-0` &` sequencer-1` conductors with [conductor\_pause](#conductor_pause) + Pause `sequencer-0` &` sequencer-2` conductors with [conductor_pause](#conductor_pause) RPC request. {

Update op-node configuration and switch the active sequencer

} @@ -150,7 +152,7 @@ This setup guide has the following assumptions: * all sequencer op-node configs: ```yaml - OP_NODE_CONDUCTOR_ENABLED: "true" + OP_NODE_CONDUCTOR_ENABLED: "true" # this is what commits unsafe blocks to the raft logs OP_NODE_RPC_ADMIN_STATE: "" # this flag cant be used with conductor ``` @@ -162,7 +164,7 @@ This setup guide has the following assumptions: {

Add voting nodes

} - Add voting nodes to cluster using [conductor\_AddServerAsVoter](#conductor_addServerAsVoter) + Add voting nodes to cluster using [conductor_AddServerAsVoter](#conductor_addserverasvoter) RPC request to the leader conductor (`sequencer-1`) {

Confirm state

} @@ -188,11 +190,11 @@ This setup guide has the following assumptions: {

Confirm state

} - Confirm all conductors successfully resumed with [conductor\_paused](#conductor_paused) + Confirm all conductors successfully resumed with [conductor_paused](#conductor_paused) {

Tranfer leadership

} - Trigger leadership transfer to `sequencer-0` using [conductor\_transferLeaderToServer](#conductor_transferLeaderToServer) + Trigger leadership transfer to `sequencer-0` using [conductor_transferLeaderToServer](#conductor_transferleadertoserver) {

Confirm state

} @@ -214,7 +216,7 @@ This setup guide has the following assumptions: `OP_CONDUCTOR_PAUSED: true` flag and `OP_CONDUCTOR_RAFT_BOOTSTRAP` flag. -#### Blue/Green Deployment +#### Blue/green deployment In order to ensure there is no downtime when setting up conductor, you need to have a deployment script that can update sequencers without network downtime. @@ -238,7 +240,7 @@ An example of this workflow might look like: 5. Deploy the change to the original sequencer, wait for it to sync to the chain head. Execute health checks. -#### Post-Conductor Launch Deployments +#### Post-conductor launch deployments After conductor is live, a similar canary style workflow is used to ensure minimal downtime in case there is an issue with deployment: @@ -252,7 +254,7 @@ minimal downtime in case there is an issue with deployment: 1. If not, then there is likely an issue with the deployment. Roll back. 5. Upgrade the remaining sequencers, run healthchecks. -### Configuration Options +### Configuration options It is configured via its [flags / environment variables](https://github.com/ethereum-optimism/optimism/blob/develop/op-conductor/flags/flags.go) @@ -357,7 +359,7 @@ It is configured via its [flags / environment variables](https://github.com/ethe Conductor exposes [admin RPCs](https://github.com/ethereum-optimism/optimism/blob/develop/op-conductor/rpc/api.go#L17) on the `conductor` namespace. -#### conductor\_overrideLeader +#### conductor_overrideLeader `OverrideLeader` is used to override the leader status, this is only used to return true for `Leader()` & `LeaderWithID()` calls. It does not impact the @@ -382,7 +384,7 @@ manually started sequencer. -#### conductor\_pause +#### conductor_pause `Pause` pauses op-conductor. @@ -402,7 +404,7 @@ manually started sequencer. -#### conductor\_resume +#### conductor_resume `Resume` resumes op-conductor. @@ -422,7 +424,7 @@ manually started sequencer. -#### conductor\_paused +#### conductor_paused Paused returns true if the op-conductor is paused. @@ -442,7 +444,7 @@ Paused returns true if the op-conductor is paused. -#### conductor\_stopped +#### conductor_stopped Stopped returns true if the op-conductor is stopped. @@ -482,7 +484,7 @@ SequencerHealthy returns true if the sequencer is healthy. -#### conductor\_leader +#### conductor_leader API related to consensus. @@ -506,7 +508,7 @@ Leader returns true if the server is the leader. -#### conductor\_leaderWithID +#### conductor_leaderWithID API related to consensus. @@ -530,13 +532,13 @@ LeaderWithID returns the current leader's server info. -#### conductor\_addServerAsVoter +#### conductor_addServerAsVoter - API related to consensus. + API related to consensus. The address parameter is the raft consensus address, not the RPC address. -AddServerAsVoter adds a server as a voter to the cluster. +AddServerAsVoter adds a server as a voter to the cluster. @@ -549,12 +551,12 @@ AddServerAsVoter adds a server as a voter to the cluster. ```sh - cast rpc conductor_addServerAsVoter --rpc-url http://127.0.0.1:50050 + cast rpc conductor_addServerAsVoter --rpc-url http://127.0.0.1:50050 ``` -#### conductor\_addServerAsNonvoter +#### conductor_addServerAsNonvoter API related to consensus. @@ -579,7 +581,7 @@ The non-voter will not participate in the leader election. -#### conductor\_removeServer +#### conductor_removeServer API related to consensus. @@ -603,7 +605,7 @@ RemoveServer removes a server from the cluster. -#### conductor\_transferLeader +#### conductor_transferLeader API related to consensus. @@ -627,7 +629,7 @@ TransferLeader transfers leadership to another server. -#### conductor\_transferLeaderToServer +#### conductor_transferLeaderToServer API related to consensus. @@ -651,7 +653,7 @@ TransferLeaderToServer transfers leadership to a specific server. -#### conductor\_clusterMembership +#### conductor_clusterMembership ClusterMembership returns the current cluster membership configuration. @@ -671,7 +673,7 @@ ClusterMembership returns the current cluster membership configuration. -#### conductor\_active +#### conductor_active API called by `op-node`. @@ -695,7 +697,7 @@ Active returns true if the op-conductor is active (not paused or stopped). -#### conductor\_commitUnsafePayload +#### conductor_commitUnsafePayload API called by `op-node`. @@ -720,8 +722,9 @@ layer. -## Next Steps +## Next steps * Checkout [op-conductor-mon](https://github.com/ethereum-optimism/infra): which monitors multiple op-conductor instances and provides a unified interface for reporting metrics. +* Get familiar with [op-conductor-ops](https://github.com/ethereum-optimism/infra/tree/main/op-conductor-ops)to interact with op-conductor. diff --git a/pages/builders/chain-operators/tools/op-deployer.mdx b/pages/builders/chain-operators/tools/op-deployer.mdx index 4d8edb21b..49c15b723 100644 --- a/pages/builders/chain-operators/tools/op-deployer.mdx +++ b/pages/builders/chain-operators/tools/op-deployer.mdx @@ -19,7 +19,7 @@ and make whatever changes are necessary for them to match. toolchain installed, you can install `op-deployer` by following these steps: - ### **Clone the Monorepo**: + ### **Clone the monorepo**: Run the following command to clone the monorepo: @@ -27,7 +27,7 @@ toolchain installed, you can install `op-deployer` by following these steps: git clone https://github.com/ethereum-optimism/optimism.git ``` - ### **Build the Binary**: + ### **Build the binary**: Run the following commands to build the binary: @@ -36,7 +36,7 @@ toolchain installed, you can install `op-deployer` by following these steps: make op-deployer ``` - ### (Optional) Move `op-deployer` Into `$PATH` + ### (Optional) move `op-deployer` into `$PATH` Run the following command to move the `op-deployer` binary into your `$PATH`. Note that the path for your system may be different: @@ -48,7 +48,7 @@ toolchain installed, you can install `op-deployer` by following these steps: ## Usage -### Configuring your Chain +### Configuring your chain To get started with `op-deployer`, you need to create an intent file that outlines your desired chain configuration. You can use the built-in `op-deployer` utility to generate this file. Just run the following command to create an example intent file for a development chain: @@ -87,7 +87,7 @@ See the code comments above for explanations of each field. By default, `op-depl with those that match our standard config. You can override these defaults by adding them to your intent file, but that won't be covered here. -### Applying your Intent +### Applying your intent Now that you've created your intent file, you can apply it to your chain: @@ -102,7 +102,7 @@ configuration will be set to the Superchain-wide defaults - i.e., your chain wil and will use the same [protocol versions](https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/superchain-upgrades.md) address as other chains on the Superchain. -### Generating Genesis Files +### Generating genesis files With the contracts deployed, you can generate a genesis file for any of your L2s. Run the following command to do so: @@ -117,11 +117,11 @@ else. You can run another member of the `inspect` family, `rollup`, to get the ` ./bin/op-deployer inspect rollup --outfile rollup.json ``` -## More Information +## More information `op-deployer` uses the OP Contracts Manager (OPCM) under the hood to deploy contracts. -## Next Steps +## Next steps -* For more details, check out the tool and documentation in the [op-deployer repository](https://github.com/ethereum-optimism/optimism/tree/develop/op-chain-ops/cmd/op-deployer). +* For more details, check out the tool and documentation in the [op-deployer repository](https://github.com/ethereum-optimism/optimism/tree/develop/op-deployer/cmd/op-deployer). * For more information on OP Contracts Manager, refer to the [OPCM documentation](/stack/opcm). diff --git a/pages/builders/chain-operators/tools/op-txproxy.mdx b/pages/builders/chain-operators/tools/op-txproxy.mdx new file mode 100644 index 000000000..1433b2b68 --- /dev/null +++ b/pages/builders/chain-operators/tools/op-txproxy.mdx @@ -0,0 +1,97 @@ +--- +title: op-txproxy +lang: en-US +description: A passthrough proxy service that can apply additional constraints on transactions prior to reaching the sequencer. +--- + +import { Callout, Steps } from 'nextra/components' + +# op-txproxy + +A [passthrough proxy](https://github.com/ethereum-optimism/infra/tree/main/op-txproxy) for the execution engine endpoint. This proxy does not forward all RPC traffic and only exposes a specific set of methods. Operationally, the ingress router should only re-route requests for these specific methods. + + + [proxyd](./proxyd) as an ingress router supports the mapping of specific methods to unique backends. + +## Methods + +### **eth_sendRawTransactionConditional** + +To safely expose this endpoint publicly, additional stateless constraints are applied. These constraints help scale validation rules horizontally and preemptively reject conditional transactions before they reach the sequencer. + +Various metrics are emitted to guide necessary adjustments. +#### Authentication + +The caller authenticates using any valid ECDSA-secp256k1 key, such as an Ethereum key. The signature is computed over the [EIP-191](https://eips.ethereum.org/EIPS/eip-191) hash of the request body. The calling address does **not need to hold an Ethereum balance**; it is simply used for identification. + +With the signature and signing address, the request is authenticated under the `X-Optimism-Signature` header with the value `: `. + +* Requests with a missing authentication header fail with the `-32003` (transaction rejected) json rpc error code. +* Requests with a mismatch in recovered signer and supplied public key will have the http request failed with status code `400 - Bad Request`. + +Currently, no authorization policies are implemented on this endpoint. However, the authentication mechanism is in place to allow for future implementation of policies such as allowlists, localized rate limits, and other potential restrictions. +#### Runtime shutoff + +This service can be configured with a flag or environment variable to reject conditional transactions without needing to interrupt the execution engine. This feature is useful for diagnosing issues. + +`--sendRawTxConditional.enabled (default: true) ($OP_TXPROXY_SENDRAWTXCONDITIONAL_ENABLED)` + +When disabled, requests will fail with the `-32003` (transaction rejected) json rpc error code with a message stating that the method is disabled. +#### Rate limits + +Even though the op-geth implementation of this endpoint includes rate limits, it is instead applied here to terminate these requests early. + +`--sendRawTxConditional.ratelimit (default: 5000) ($OP_TXPROXY_SENDRAWTXCONDITIONAL_RATELIMIT)` + +#### Stateless validation + +* Conditional cost is below the max +* Conditional values are valid (i.e min \< max) +* Transaction target are only 4337 Entrypoint contracts + + + The motivating factor for this endpoint is to enable permissionless 4337 mempools, hence the restricted usage of this methods to just [Entrypoint](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/core/EntryPoint.sol) transactions. + + Please open up an issue if you'd like this restriction to be optional via configuration to broaden usage of this endpoint. + + +When the request passes validation, it is passed through to the configured backend URL + +`--sendRawTxConditional.backend ($OP_TXPROXY_SENDRAWTXCONDITIONAL_BACKENDS)` + + + + Per the [specification](/stack/features/send-raw-transaction-conditional), conditional transactions are not gossiped between peers. Thus, if you use replicas in an active/passive sequencer setup, this request must be broadcasted to all replicas. + + [proxyd](./proxyd) as an egress router for this method supports this broadcasting functionality. + + +## How it works + +To start using `op-txproxy`, follow these steps: + + + ### Build the binary or pull the Docker image + + 1. Run the following command to build the binary + ```bash + make build + ``` + 2. This will build and output the binary under `/bin/op-txproxy`. + + The image for this binary is also available as a [docker artifact](https://us-docker.pkg.dev/oplabs-tools-artifacts/images/op-txproxy). + + ### Configure + + The binary accepts configuration through CLI flags, which also settable via environment variables. Either set the flags explicitly when starting the binary or set the environment variables of the host starting the proxy. + + See [methods](#methods) on the configuration options available for each method. + + ### Start + + start the service with the following command + + ```bash + op-txproxy // ... with flags if env variables are not set + ``` + diff --git a/pages/stack/operators/features/proxyd.mdx b/pages/builders/chain-operators/tools/proxyd.mdx similarity index 94% rename from pages/stack/operators/features/proxyd.mdx rename to pages/builders/chain-operators/tools/proxyd.mdx index 51476b581..e2b7cf6ef 100644 --- a/pages/stack/operators/features/proxyd.mdx +++ b/pages/builders/chain-operators/tools/proxyd.mdx @@ -10,8 +10,7 @@ import { Steps } from 'nextra/components' `proxyd` is an important RPC request router and proxy used within the OP Stack infrastructure. It enables operators to efficiently route and manage RPC requests across multiple backend services, ensuring performance, fault tolerance, and security. -## Key Features - +## Key features * RPC method whitelisting * Backend request routing * Automatic retries for failed backend requests @@ -26,7 +25,7 @@ import { Steps } from 'nextra/components' To start using `proxyd`, follow these steps: - ### **Build the Binary**: + ### **Build the binary**: * Run the following command to build the `proxyd` binary: ```bash @@ -39,7 +38,7 @@ To start using `proxyd`, follow these steps: * Create a configuration file to define your proxy backends and routing rules. * Refer to [example.config.toml](https://github.com/ethereum-optimism/infra/blob/main/proxyd/example.config.toml) for a full list of options with commentary. - ### **Start the Service**: + ### **Start the service**: Once the configuration file is ready, start the `proxyd` service using the following command: @@ -48,7 +47,7 @@ To start using `proxyd`, follow these steps: ``` -## Consensus Awareness +## Consensus awareness Version 4.0.0 and later include consensus awareness to minimize chain reorganizations. @@ -58,9 +57,9 @@ Set `consensus_aware` to `true` in the configuration to enable: * Resolving consensus groups based on healthiest backends * Enforcing consensus state across client requests -## Caching and Metrics +## Caching and metrics -### Cacheable Methods +### Cacheable methods Certain immutable methods, such as `eth_chainId` and `eth_getBlockByHash`, can be cached using Redis to optimize performance. @@ -68,7 +67,7 @@ Certain immutable methods, such as `eth_chainId` and `eth_getBlockByHash`, can b Extensive metrics are available to monitor request latency, error rates, backend health, and more. These can be configured via `metrics.port` and `metrics.host` in the configuration file. -## Next Steps +## Next steps * Read about the [OP Stack chain architecture](/builders/chain-operators/architecture). * Find out how you can support [snap sync](/builders/chain-operators/management/snap-sync). diff --git a/pages/builders/chain-operators/tutorials/adding-derivation-attributes.mdx b/pages/builders/chain-operators/tutorials/adding-derivation-attributes.mdx index d626282b8..cfbc718ad 100644 --- a/pages/builders/chain-operators/tutorials/adding-derivation-attributes.mdx +++ b/pages/builders/chain-operators/tutorials/adding-derivation-attributes.mdx @@ -1,12 +1,12 @@ --- -title: Adding Attributes to the Derivation Function +title: Adding attributes to the derivation function lang: en-US description: Learn how to modify the derivation function for an OP Stack chain to track the amount of ETH being burned on L1. --- import { Callout, Steps } from 'nextra/components' -# Adding Attributes to the Derivation Function +# Adding attributes to the derivation function OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. diff --git a/pages/builders/chain-operators/tutorials/adding-precompiles.mdx b/pages/builders/chain-operators/tutorials/adding-precompiles.mdx index c1f328d0b..70d8e678d 100644 --- a/pages/builders/chain-operators/tutorials/adding-precompiles.mdx +++ b/pages/builders/chain-operators/tutorials/adding-precompiles.mdx @@ -1,12 +1,12 @@ --- -title: Adding a Precompile +title: Adding a precompile lang: en-US description: Learn how to run an EVM with a new precompile for OP Stack chain operations to speed up calculations that are not currently supported. --- import { Callout, Steps } from 'nextra/components' -# Adding a Precompile +# Adding a precompile OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. diff --git a/pages/builders/chain-operators/tutorials/create-l2-rollup.mdx b/pages/builders/chain-operators/tutorials/create-l2-rollup.mdx index 80396150e..93b2e978f 100644 --- a/pages/builders/chain-operators/tutorials/create-l2-rollup.mdx +++ b/pages/builders/chain-operators/tutorials/create-l2-rollup.mdx @@ -1,5 +1,5 @@ --- -title: Creating Your Own L2 Rollup Testnet +title: Creating your own L2 rollup testnet lang: en-US description: This tutorial walks you through spinning up an OP Stack testnet chain. --- @@ -8,7 +8,7 @@ import { Callout, Steps } from 'nextra/components' import { WipCallout } from '@/components/WipCallout' -# Creating Your Own L2 Rollup Testnet +# Creating your own L2 rollup testnet @@ -33,7 +33,7 @@ Modifications to the OP Stack may prevent a chain from being able to benefit fro Make sure to check out the [Superchain Explainer](/stack/explainer) to learn more. -## Software Dependencies +## Software dependencies | Dependency | Version | Version Check Command | | ------------------------------------------------------------- | -------- | --------------------- | @@ -46,7 +46,7 @@ Make sure to check out the [Superchain Explainer](/stack/explainer) to learn mor | [jq](https://github.com/jqlang/jq) | `^1.6` | `jq --version` | | [direnv](https://direnv.net) | `^2` | `direnv --version` | -### Notes on Specific Dependencies +### Notes on specific dependencies #### `node` @@ -71,7 +71,7 @@ Make sure that you have correctly hooked `direnv` into your shell by modifying y If you haven't edited a config file then you probably haven't configured `direnv` properly (and things might not work later). -## Get Access to a Sepolia Node +## Get access to a sepolia node You'll be deploying a OP Stack Rollup chain that uses a Layer 1 blockchain to host and order transaction data. The OP Stack Rollups were designed to use EVM Equivalent blockchains like Ethereum, OP Mainnet, or standard Ethereum testnets as their L1 chains. @@ -84,7 +84,7 @@ If you want to use an alternative network, make sure to carefully review each co Since you're deploying your OP Stack chain to Sepolia, you'll need to have access to a Sepolia node. You can either use a node provider like [Alchemy](https://www.alchemy.com/) (easier) or run your own Sepolia node (harder). -## Build the Source Code +## Build the source code You're going to be spinning up your OP Stack chain directly from source code instead of using a container system like [Docker](https://www.docker.com/). Although this adds a few extra steps, it means you'll have an easier time modifying the behavior of the stack if you'd like to do so. @@ -96,7 +96,7 @@ You can use any directory you'd like but using the home directory will allow you If you choose to use a different directory, make sure you're using the correct directory in the commands throughout this tutorial. -### Build the Optimism Monorepo +### Build the Optimism monorepo @@ -178,7 +178,7 @@ make geth -## Fill Out Environment Variables +## Fill out environment variables You'll need to fill out a few environment variables before you can start deploying your chain. @@ -207,7 +207,7 @@ Open up the environment variable file and fill out the following variables: -## Generate Addresses +## Generate addresses You'll need four addresses and their private keys when setting up the chain: @@ -279,7 +279,7 @@ It's recommended to fund the addresses with the following amounts when using Sep -## Load Environment variables +## Load environment variables Now that you've filled out the environment variable file, you need to load those variables into your terminal. @@ -357,7 +357,7 @@ It's recommended to keep this file as-is for now so you don't run into any unexp -## Deploy the Create2 Factory (Optional) +## Deploy the Create2 factory (optional) If you're deploying an OP Stack chain to a network other than Sepolia, you may need to deploy a Create2 factory contract to the L1 chain. This factory contract is used to deploy OP Stack smart contracts in a deterministic fashion. @@ -418,7 +418,7 @@ Once you've configured your network, it's time to deploy the L1 contracts necess {

Deploy the L1 contracts

} ```bash -forge script scripts/Deploy.s.sol:Deploy --private-key $GS_ADMIN_PRIVATE_KEY --broadcast --rpc-url $L1_RPC_URL --slow +forge script scripts/deploy/Deploy.s.sol:Deploy --private-key $GS_ADMIN_PRIVATE_KEY --broadcast --rpc-url $L1_RPC_URL --slow ``` @@ -707,13 +707,13 @@ cd ~/optimism/op-proposer -## Connect Your Wallet to Your Chain +## Connect your wallet to your chain You now have a fully functioning OP Stack Rollup with a Sequencer node running on `http://localhost:8545`. You can connect your wallet to this chain the same way you'd connect your wallet to any other EVM chain. If you need an easy way to connect to your chain, just [click here](https://chainid.link?network=opstack-getting-started). -## Get ETH On Your Chain +## Get ETH on your chain Once you've connected your wallet, you'll probably notice that you don't have any ETH to pay for gas on your chain. The easiest way to deposit Sepolia ETH into your chain is to send ETH directly to the `L1StandardBridge` contract. @@ -740,12 +740,12 @@ It may take up to 5 minutes for that ETH to appear in your wallet on L2. -## See Your Rollup in Action +## See your rollup in action You can interact with your Rollup the same way you'd interact with any other EVM chain. Send some transactions, deploy some contracts, and see what happens! -## Next Steps +## Next steps * You can [modify the blockchain in various ways](../hacks/overview). * Check out the [protocol specs](https://specs.optimism.io/) for more detail about the rollup protocol. diff --git a/pages/builders/chain-operators/tutorials/integrating-da-layer.mdx b/pages/builders/chain-operators/tutorials/integrating-da-layer.mdx index a1dbc7c99..8627d4385 100644 --- a/pages/builders/chain-operators/tutorials/integrating-da-layer.mdx +++ b/pages/builders/chain-operators/tutorials/integrating-da-layer.mdx @@ -1,21 +1,21 @@ --- -title: Integrating a New DA Layer with Alt-DA +title: Integrating a new DA layer with Alt-DA lang: en-US description: Learn how to add support for a new DA Layer within the OP Stack. --- import { Callout, Steps } from 'nextra/components' -# Integrating a New DA Layer with Alt-DA +# Integrating a new DA layer with Alt-DA The Alt-DA Mode feature is currently in Beta within the MIT-licensed OP Stack. Beta features are built and reviewed by Optimism Collective core contributors, and provide developers with early access to highly requested configurations. These features may experience stability issues, and we encourage feedback from our early users. -[Alt-DA Mode](/stack/protocol/features/alt-da-mode) enables seamless integration of any DA Layer, regardless of their commitment type, into the OP Stack. After a DA Server is built for a DA Layer, any chain operator can launch an OP Stack chain using that DA Layer for sustainably low costs. +[Alt-DA Mode](/stack/beta-features/alt-da-mode) enables seamless integration of any DA Layer, regardless of their commitment type, into the OP Stack. After a DA Server is built for a DA Layer, any chain operator can launch an OP Stack chain using that DA Layer for sustainably low costs. -## Build Your DA Server +## Build your DA server Our suggestion is for every DA Layer to build and maintain their own DA Server, with support from the OP Labs team along the way. The DA Server will need to be run by every node operator, so we highly recommend making your DA Server open source and MIT licensed. @@ -33,7 +33,7 @@ Our suggestion is for every DA Layer to build and maintain their own DA Server, * Claim your [byte](https://github.com/ethereum-optimism/specs/discussions/135) - ### Implement the DA Server + ### Implement the DA server * Write a simple HTTP server which supports `get` and `put` * `put` is used by the batcher and can return the commitment to the batcher in the body. It should not return until the data is known to be submitted to your DA layer. @@ -44,6 +44,6 @@ Our suggestion is for every DA Layer to build and maintain their own DA Server, ## Run Alt-DA Follow our guide on [how to operate an Alt-DA Mode chain](/builders/chain-operators/features/alt-da-mode), except instead of using the S3 DA server, use the DA server that you built. -## Next Steps +## Next steps * For more detail on implementing the DA Server, [see the specification](https://specs.optimism.io/experimental/alt-da.html#da-server). diff --git a/pages/builders/chain-operators/tutorials/modifying-predeploys.mdx b/pages/builders/chain-operators/tutorials/modifying-predeploys.mdx index ac77fb5a4..4391673c0 100644 --- a/pages/builders/chain-operators/tutorials/modifying-predeploys.mdx +++ b/pages/builders/chain-operators/tutorials/modifying-predeploys.mdx @@ -1,12 +1,12 @@ --- -title: Modifying Predeployed Contracts +title: Modifying predeployed contracts lang: en-US description: Learn how to modify predeployed contracts for an OP Stack chain by upgrading the proxy. --- import { Callout, Steps } from 'nextra/components' -# Modifying Predeployed Contracts +# Modifying predeployed contracts OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. @@ -17,13 +17,13 @@ import { Callout, Steps } from 'nextra/components' OP Stack blockchains have a number of [predeployed contracts](https://github.com/ethereum-optimism/optimism/blob/129032f15b76b0d2a940443a39433de931a97a44/packages/contracts-bedrock/src/constants.ts) that provide important functionality. Most of those contracts are proxies that can be upgraded using the `proxyAdminOwner` which was configured when the network was initially deployed. -## Before You Begin +## Before you begin In this tutorial, you learn how to modify predeployed contracts for an OP Stack chain by upgrading the proxy. The predeploys are controlled from a predeploy called [`ProxyAdmin`](https://github.com/ethereum-optimism/optimism/blob/129032f15b76b0d2a940443a39433de931a97a44/packages/contracts-bedrock/contracts/universal/ProxyAdmin.sol), whose address is `0x4200000000000000000000000000000000000018`. The function to call is [`upgrade(address,address)`](https://github.com/ethereum-optimism/optimism/blob/129032f15b76b0d2a940443a39433de931a97a44/packages/contracts-bedrock/contracts/universal/ProxyAdmin.sol#L205-L229). The first parameter is the proxy to upgrade, and the second is the address of a new implementation. -## Modify the Legacy `L1BlockNumber` contract +## Modify the legacy `L1BlockNumber` contract For example, the legacy `L1BlockNumber` contract is at `0x420...013`. To disable this function, we'll set the implementation to `0x00...00`. diff --git a/pages/builders/chain-operators/tutorials/sdk.mdx b/pages/builders/chain-operators/tutorials/sdk.mdx index cbd660442..207c244d5 100644 --- a/pages/builders/chain-operators/tutorials/sdk.mdx +++ b/pages/builders/chain-operators/tutorials/sdk.mdx @@ -10,8 +10,6 @@ import { WipCallout } from '@/components/WipCallout' # Using the Optimism SDK - - This tutorial will walk you through the process of using the [Optimism SDK](https://sdk.optimism.io) to interact with your OP Stack chain. The Optimism SDK **natively** supports various OP Chains including OP Mainnet and Base. To check whether your OP Chain is already supported, [see the Optimism SDK docs](https://sdk.optimism.io/enums/l2chainid). @@ -27,7 +25,7 @@ Check out the tutorial on [Creating Your Own L2 Rollup Testnet](./create-l2-roll * [pnpm](https://pnpm.io/installation) * [jq](https://github.com/jqlang/jq) -## Find Contract Addresses +## Find contract addresses You will need to find the addresses for a number of smart contracts that are part of your OP Stack chain in order to use the Optimism SDK. If you followed the instructions in the [Creating Your Own L2 Rollup Testnet](./create-l2-rollup) tutorial, you can find the addresses by looking at the JSON artifacts within the directory `optimism/packages/contracts-bedrock/deployments/getting-started`. @@ -54,7 +52,7 @@ OptimismPortalProxy: 0x... Save these addresses somewhere so you can use them in the next section. -## Create a Demo Project +## Create a demo project You're going to use the Optimism SDK for this tutorial. Since the Optimism SDK is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. @@ -99,7 +97,7 @@ node This will bring up a Node REPL prompt that allows you to run javascript code. -## Import Dependencies +## Import dependencies You need to import some dependencies into your Node REPL session. @@ -117,7 +115,7 @@ You need to import some dependencies into your Node REPL session. -## Set Session Variables +## Set session variables You'll need a few variables throughout this tutorial. Let's set those up now. @@ -155,7 +153,7 @@ Simply create the object: Note that you've passed in the RPC providers you created earlier, the addresses of the smart contracts you deployed, and the chain ID of your OP Stack chain. -## Next Steps +## Next steps You can now use the SDK to interact with your OP Stack chain just like you would with other chains like OP Mainnet. See existing tutorials, like the tutorial on [Bridging ETH With the Optimism SDK](/builders/app-developers/tutorials/cross-dom-bridge-eth) or [Bridging ERC-20 Tokens With the Optimism SDK](/builders/app-developers/tutorials/cross-dom-bridge-erc20), for examples of how to use the Optimism SDK. diff --git a/pages/builders/node-operators/architecture.mdx b/pages/builders/node-operators/architecture.mdx index 5ba68808a..014f7b8dc 100644 --- a/pages/builders/node-operators/architecture.mdx +++ b/pages/builders/node-operators/architecture.mdx @@ -1,25 +1,25 @@ --- -title: Node Architecture +title: Node architecture lang: en-US description: Learn about node architecture. --- -# Node Architecture +# Node architecture This page reviews node architecture for all nodes running on the Superchain network. All OP Mainnet nodes are composed of two core software services, the Rollup Node and the Execution Client. OP Mainnet also optionally supports a third component, Legacy Geth, that can serve stateful queries for blocks and transactions created before the [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/). -## Node Flow Diagram +## Node flow diagram The following diagram shows how the Rollup Node, Execution Client, and Legacy Geth components work together to form a complete node running on the Superchain network. This diagram uses the `op-node` and `op-geth` implementations of the Rollup Node and Execution Client respectively, but the same architecture generally applies to other implementations as well. ![OP Mainnet node architecture diagram.](/img/guides/node-operators/node-arch.svg) -## Rollup Node +## Rollup node The Rollup Node is responsible for deriving L2 block payloads from L1 data and passing those payloads to the Execution Client. The Rollup Node can also optionally participate in a peer-to-peer network to receive blocks directly from the Sequencer before those blocks are submitted to L1. The Rollup Node is largely analogous to a [consensus client](https://ethereum.org/en/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) in Ethereum. -## Execution Client +## Execution client The Execution Client is responsible for executing the block payloads it receives from the Rollup Node over JSON-RPC via the standard [Ethereum Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md#engine-api----common-definitions). The Execution Client exposes the standard JSON-RPC API that Ethereum developers are familiar with, and can be used to query blockchain data and submit transactions to the network. @@ -35,7 +35,7 @@ Legacy Geth is the software that was used to run OP Mainnet nodes prior to the B If you run an instance of Legacy Geth alongside your OP Mainnet node, your node will be able to forward requests against historical transactions to the Legacy Geth instance. Legacy Geth is **not** required and is typically only necessary if you want to maintain a complete archive node for OP Mainnet. -## Next Steps +## Next steps * To get your node up and running, start with the [run a node from docker](/builders/node-operators/tutorials/node-from-docker) or [build a node from source](/builders/node-operators/tutorials/node-from-source) tutorial. * If you've already got your node up and running, check out the [Node Metrics and Monitoring Guide](./management/metrics) to learn how to keep tabs on your node and make sure it keeps running smoothly. diff --git a/pages/builders/node-operators/configuration/base-config.mdx b/pages/builders/node-operators/configuration/base-config.mdx index 69fab08ac..610fd7fe6 100644 --- a/pages/builders/node-operators/configuration/base-config.mdx +++ b/pages/builders/node-operators/configuration/base-config.mdx @@ -1,12 +1,12 @@ --- -title: Node Base Configuration +title: Node base configuration lang: en-US description: Learn the node base configuration and recommended flags for op-node, op-geth, and legacy geth. --- import { Callout } from 'nextra/components' -# Node Base Configuration +# Node base configuration Always run `op-node` and `op-geth` in a one-to-one configuration. Don't run multiple `op-geth` instances behind one `op-node`, or vice versa. @@ -37,14 +37,14 @@ Regardless of how `op-geth` is initialized, you'll need to ensure that you have ### Initialize `op-geth` Instructions for each initialization method are below. If you're spinning up an OP Mainnet, use the [Initialization via Data Directory](#initialization-via-data-directory) path. If you're spinning up an OP Sepolia node, use the [Initialization via Network Flags](#initialization-via-network-flags) path. -#### Initialization via Network Flags +#### Initialization via network flags To initialize `op-geth` with the network flags, you simply need to set the `--op-network=` and `--network=` on `op-node`. To see the latest support networks, you can consult the `--help` output for the `op-network` option. -#### Initialization via Genesis File +#### Initialization via genesis file `op-geth` uses JSON files to encode a network's genesis information. For networks that are initialized in this way, you'll receive a URL to the genesis @@ -65,7 +65,7 @@ else fi ``` -#### Initialization via Data Directory +#### Initialization via data directory To initialize `op-geth` with a preconfigured data directory, simply download and extract the data directory to a place of your choosing. The data directory is exported as a tar file. An example command to do this is below: @@ -96,7 +96,7 @@ Then, specify the following flags: * `--authrpc.port`: Sets the port `op-geth`'s authenticated RPC should listen on. The default value is `8551`. * `--authrpc.jwtsecret`: Sets the path to a JWT secret file you generated above. -### Recommended Flags for `op-geth` Configuration +### Recommended flags for `op-geth` configuration You may also want to specify the following flags based on your configuration: @@ -106,7 +106,7 @@ You may also want to specify the following flags based on your configuration: * `--ws`, `--ws.addr`, and `--ws.port`: Enables the WebSocket API. * `--verbosity`: Configures Geth's log level. This is a number between 0 and 5, with 5 being the most verbose. Defaults to 3. -### Working Base Configuration +### Working base configuration A valid command that runs `op-geth` and enables RPC over HTTP and WebSockets looks like: @@ -147,7 +147,7 @@ from a Beacon node. accidentally expose admin controls to the public internet. -### Working Base Configuration +### Working base configuration A minimal valid configuration that runs `op-node` looks like: @@ -167,7 +167,7 @@ You can manually specify a path to a rollup config with the `--rollup.config` fl Each of the above flags can also be defined via an environment variable. Run `op-node --help` to see a list of all available flags and environment variables. -### Configuring Peer-to-Peer Networking +### Configuring peer-to-peer networking Unlike the previous system, the `op-node` participates in a peer-to-peer network. This network is used to distribute blocks that have not been submitted to L1 yet. The `op-node` will automatically discover and connect to peers using a hardcoded set of bootnodes. You can also manually specify peers to connect to via the `--p2p.static` flag. @@ -201,7 +201,7 @@ As mentioned above, don't forget to specify `--rollup.historicalrpc` on `op-geth Since Legacy Geth is read-only, it is safe to run multiple Legacy Geth nodes behind a load balancer. -### Historical Execution vs. Historical Data Routing +### Historical execution vs. historical data routing Only requests for historical execution will be routed to Legacy Geth. Everything else will be served by `op-geth` directly. @@ -216,7 +216,7 @@ The term *historical execution* refers to RPC methods that need to execute trans If you do not need these RPC methods for historical data, then you do not need to run Legacy Geth at all. -## Next Steps +## Next steps * See the [op-node configuration](/builders/node-operators/configuration/consensus-config) guide for additional configuration options for `op-node` and the Consensus-Layer. * Similarly, visit the [op-geth configuration](/builders/node-operators/configuration/execution-config) guide for additional configuration options for `op-geth` and Execution-Layer. * If you run into any problems, please reach out to our [developer support forum](https://github.com/ethereum-optimism/developers/discussions) for help. diff --git a/pages/builders/node-operators/configuration/consensus-config.mdx b/pages/builders/node-operators/configuration/consensus-config.mdx index 96b979584..cac398c3f 100644 --- a/pages/builders/node-operators/configuration/consensus-config.mdx +++ b/pages/builders/node-operators/configuration/consensus-config.mdx @@ -1,5 +1,5 @@ --- -title: Consensus Layer Configuration Options (op-node) +title: Consensus layer configuration options (op-node) lang: en-US description: Learn additional configuration and command line options for op-node and the Consensus-Layer. --- @@ -7,7 +7,7 @@ description: Learn additional configuration and command line options for op-node import { Callout } from 'nextra/components' import { Tabs } from 'nextra/components' -# Consensus Layer Configuration Options (op-node) +# Consensus layer configuration options (op-node) You can configure your node using the command line options below (also called flags). @@ -17,7 +17,7 @@ import { Tabs } from 'nextra/components' This page list all configuration options for `op-node`. `op-node` implements most rollup-specific functionality as Consensus-Layer, similar to a L1 beacon-node. The following options are from the `--help` in [v1.7.5](https://github.com/ethereum-optimism/optimism/releases/tag/op-node/v1.7.5). -## Global Options +## Global options ### conductor.enabled @@ -239,7 +239,7 @@ The lowest log level that will be output. The default value is `info`. `OP_NODE_LOG_LEVEL=info` -### Node Log Levels +### Node log levels Node log levels determine the verbosity of log messages, allowing operators to filter messages based on importance and detail. The log levels for the `op-node` (used in Optimism) are as follows: diff --git a/pages/builders/node-operators/configuration/execution-config.mdx b/pages/builders/node-operators/configuration/execution-config.mdx index 59efab1db..d3d4bfc17 100644 --- a/pages/builders/node-operators/configuration/execution-config.mdx +++ b/pages/builders/node-operators/configuration/execution-config.mdx @@ -1,5 +1,5 @@ --- -title: Execution Layer Configuration Options (op-geth) +title: Execution layer configuration options (op-geth) lang: en-US description: Learn additional configuration and command line options for op-geth and the Execution-Layer. --- @@ -7,7 +7,7 @@ description: Learn additional configuration and command line options for op-geth import { Callout } from 'nextra/components' import { Tabs } from 'nextra/components' -# Execution Layer Configuration Options (op-geth) +# Execution layer configuration options (op-geth) You can configure your node using the command line options below (also called flags). @@ -19,7 +19,7 @@ The following are options from [v1.101308.0](https://github.com/ethereum-optimis Please note that the executable is still named `geth` to maintain a [minimal diff](https://op-geth.optimism.io/). -## Global Options +## Global options ### Account @@ -1783,7 +1783,7 @@ Time interval to regenerate the local transaction journal. The default value is `GETH_TXPOOL_REJOURNAL=1h0m0s` -### Virtual Machine +### Virtual machine #### vmdebug diff --git a/pages/builders/node-operators/management/blobs.mdx b/pages/builders/node-operators/management/blobs.mdx index 4f63e18db..5f738f79f 100644 --- a/pages/builders/node-operators/management/blobs.mdx +++ b/pages/builders/node-operators/management/blobs.mdx @@ -1,5 +1,5 @@ --- -title: Using Blobs +title: Using blobs lang: en-US description: Learn how to handle blobs for your node. --- @@ -7,7 +7,7 @@ description: Learn how to handle blobs for your node. import { Callout, Steps } from 'nextra/components' import { Tabs } from 'nextra/components' -# Using Blobs +# Using blobs The proposed Ecotone upgrade impacts node operators because of the new Beacon endpoint for `op-node`. Soon after the Ecotone activation, batch transactions @@ -15,7 +15,7 @@ will be sent as 4844 blobs, and blobs can only be retrieved from Beacon nodes. This means node operators will need access to a beacon node/consensus client (i.e. Lighthouse, Lodestar, Nimbus, Prysm, Teku, etc.). -## Preparing Your Node +## Preparing your node These steps are necessary for EVERY node operator: @@ -24,7 +24,7 @@ These steps are necessary for EVERY node operator: See the [Software Releases](/builders/node-operators/releases) page for the minimum release version. -### Configure the Ecotone Activation Date +### Configure the Ecotone activation date * If you are operating a node for an OP Chain that has an entry in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), the Ecotone activation date is part of the `op-node` and `op-geth` nodes. So, @@ -56,7 +56,7 @@ These will need to be set on `op-node` and `op-geth` for the sequencer and all o -### Prepare for Activation +### Prepare for activation * All node operators must set an L1 beacon value in your `op-node` as soon as you update to the latest release. @@ -69,7 +69,7 @@ These will need to be set on `op-node` and `op-geth` for the sequencer and all o -## Configure a Blob Archiver (Archive Nodes) +## Configure a blob archiver (archive nodes) There is a configurable `beacon-archiver` that will allow nodes to sync blob data that is older than 18 days - after blobs are 18 days old, normal beacon nodes will "prune" or remove them. If your node is already in sync with the head of the chain, you won't need to use a `beacon-archiver`. diff --git a/pages/builders/node-operators/management/metrics.mdx b/pages/builders/node-operators/management/metrics.mdx index 81a2fccc2..022f44f64 100644 --- a/pages/builders/node-operators/management/metrics.mdx +++ b/pages/builders/node-operators/management/metrics.mdx @@ -4,13 +4,13 @@ lang: en-US description: Learn about the different metrics you can use to monitor the health of your node. --- -# Node Metrics and Monitoring +# Node metrics and monitoring The Optimism `op-node` exposes a variety of metrics to help observe the health of the system and debug issues. Metrics are formatted for use with Prometheus and exposed via a metrics endpoint. The default metrics endpoint is `http://localhost:7300/metrics`. To enable metrics, pass the `--metrics.enabled` flag to the `op-node`. You can customize the metrics port and address via the `--metrics.port` and `--metrics.addr` flags, respectively. -## Important Metrics +## Important metrics To monitor the health of your node, you should monitor the following metrics: @@ -20,7 +20,7 @@ To monitor the health of your node, you should monitor the following metrics: * `engine_forkChoiceUpdatedV1`, `engine_getPayloadV1`, and `engine_newPayloadV1`: These methods are used to execute blocks on `op-geth`. If these methods are slow, it means that sync time is bottlenecked by either `op-geth` itself or your connection to it. * `eth_getBlockByHash`, `eth_getTransactionReceipt`, and `eth_getBlockByNumber`: These methods are used by the `op-node` to fetch transaction data from L1. If these methods are slow, it means that sync time is bottlenecked by your L1 RPC. -## Available Metrics +## Available metrics A complete list of available metrics is below: diff --git a/pages/builders/node-operators/management/snap-sync.mdx b/pages/builders/node-operators/management/snap-sync.mdx index dd86dac6c..68bf869c9 100644 --- a/pages/builders/node-operators/management/snap-sync.mdx +++ b/pages/builders/node-operators/management/snap-sync.mdx @@ -1,5 +1,5 @@ --- -title: Using Snap Sync for Node Operators +title: Using snap sync for node operators lang: en-US description: Learn how to use and enable snap sync on your node. --- @@ -7,7 +7,7 @@ description: Learn how to use and enable snap sync on your node. import { Callout, Steps } from 'nextra/components' import { Tabs } from 'nextra/components' -# Using Snap Sync for Node Operators +# Using snap sync for node operators This guide reviews the optional feature of Snap Sync for node operators, including benefits and how to enable the feature. @@ -19,7 +19,7 @@ This means that performing a Snap Sync is significantly faster than performing a * This also enables nodes to join the network after Ecotone activates without requiring a [blob archiver](blobs). * Archive nodes are also fully supported. -## Enable Snap Sync for Your Node +## Enable snap sync for your node For snap sync, all `op-geth` nodes should expose port `30303` TCP and `30303` UDP to easily find other op-geth nodes to sync from. @@ -81,7 +81,7 @@ Choose one of the following options to enable snap sync: -## Enabling Execution Layer Sync for Alternative Clients +## Enabling execution layer sync for alternative clients In addition to op-geth, you can enable execution-layer syncing with alternative execution clients such as `reth` and `op-erigon`. Unlike `op-geth`, `reth` and `op-erigon` are designed as archive nodes, which means they require the complete history of the chain. @@ -100,7 +100,7 @@ To enable execution layer sync for these clients, set the following flags on `op --l2.enginekind=erigon (not default) ``` -## Next Steps +## Next steps * See the [Node Configuration](/builders/node-operators/configuration/base-config#configuration) guide for additional explanation or customization. * To enable snap sync for your chain, see [Using Snap Sync for Chain Operators](/builders/chain-operators/management/snap-sync). diff --git a/pages/builders/node-operators/management/snapshots.mdx b/pages/builders/node-operators/management/snapshots.mdx index 897d404eb..96d3bd6c1 100644 --- a/pages/builders/node-operators/management/snapshots.mdx +++ b/pages/builders/node-operators/management/snapshots.mdx @@ -6,7 +6,7 @@ description: Find download links for data directories and database snapshots for import { Callout } from 'nextra/components' -# Node Snapshots +# Node snapshots This page contains download links for data directories and node snapshots that can be used to more easily run your own node. Data directories and node snapshots are not required but can significantly simplify the node operation process. @@ -15,7 +15,7 @@ Data directories and node snapshots are not required but can significantly simpl Data directories and node snapshots are **not required** for nodes using [snap sync](snap-sync) but are still required for archive nodes and in instances when you need to trace the entire chain. -## About the Bedrock Migration +## About the Bedrock migration OP Mainnet underwent a large [database migration](https://web.archive.org/web/20240110231645/https://blog.oplabs.co/reproduce-bedrock-migration/) as part of the [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/) in 2023. Node operators must have a migrated OP Mainnet database to run a node. @@ -32,7 +32,7 @@ Migrated OP Mainnet databases can be generated manually or pre-migrated database Using [aria2](https://aria2.github.io/) to download snapshots can significantly speed up the download process. -### OP Mainnet (Full Node) +### OP Mainnet (full node) [Allnodes](https://www.allnodes.com) provides more recent full node snapshots for OP Mainnet and Testnet. You can find them [here](https://www.publicnode.com/snapshots#optimism). @@ -43,7 +43,7 @@ Migrated OP Mainnet databases can be generated manually or pre-migrated database | ------------- | ----- | ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | 2023-06-06 | 325GB | [Mirror 1](https://op.datadirs.xyz/mainnet-bedrock.tar.zst) | `ec4baf47e309a14ffbd586dc85376833de640c0f2a8d7355cb8a9e64c38bfcd1` | -### OP Mainnet (Archive Node) +### OP Mainnet (archive node) You can also download access the [Optimism Foundation datadir explorer](https://datadirs.optimism.io/) to find other snapshots. @@ -53,7 +53,7 @@ Migrated OP Mainnet databases can be generated manually or pre-migrated database | ----------------------------- | ---- | ------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------- | | Latest by Optimism Foundation | >4TB | [Mirror 1](https://datadirs.optimism.io/latest)
[Mirror 2 (torrent)](https://datadirs.optimism.io/latest.torrent) | [sha256sum](https://datadirs.optimism.io/latest.sha256sum/) | -### OP Mainnet (Legacy) +### OP Mainnet (legacy) | Snapshot Date | Size | Download Link | sha256sum | | ------------- | ----- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------- | diff --git a/pages/builders/node-operators/network-upgrades.mdx b/pages/builders/node-operators/network-upgrades.mdx index f64069070..40f2c38f5 100644 --- a/pages/builders/node-operators/network-upgrades.mdx +++ b/pages/builders/node-operators/network-upgrades.mdx @@ -1,5 +1,5 @@ --- -title: Network Upgrades +title: Network upgrades lang: en-US description: Learn more about how network upgrades work and how to keep your nodes up to date. --- @@ -7,7 +7,7 @@ description: Learn more about how network upgrades work and how to keep your nod import Image from 'next/image' import { Steps, Callout } from 'nextra/components' -# Network Upgrade Overview +# Network upgrade overview This section has information on how to upgrade your Mainnet and Testnet nodes for new network upgrades. The network upgrade naming scheme after the Bedrock @@ -29,7 +29,7 @@ that are pending governance approval. | [Delta](https://specs.optimism.io/protocol/delta/overview.html) | [approved](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310) | Thu Feb 22 00:00:00 UTC 2024 (`1708560000`) around block `116480612` | Fri Dec 22 00:00:00 UTC 2023 (`1703203200`) around block `5700330` | | [Canyon](https://specs.optimism.io/protocol/canyon/overview.html) | [approved](https://gov.optimism.io/t/final-upgrade-proposal-2-canyon-network-upgrade/7088) | Thu Jan 11 17:00:01 UTC 2024 (`1704992401`) around block `114696812` | Tue Nov 14 17:00:00 UTC 2023 (`1699981200`) around block `4089330` | -## Summary of Changes +## Summary of changes These are the summaries of each network upgrade changes ordered by the most recent activation. These are a reflection of the [Superchain Upgrades Specifications](https://specs.optimism.io/protocol/superchain-upgrades.html) @@ -112,7 +112,7 @@ The Canyon upgrade uses a *L2 block-timestamp* activation-rule, and is specified rollup-node (`canyon_time`) and execution engine (`config.canyonTime`). Shanghai time in the execution engine should be set to the same time as the Canyon time. -## Upgrade Process +## Upgrade process Network upgrades follow this general process in which the features included in the upgrade are put into a release version cut from the `develop` branch and @@ -155,7 +155,7 @@ then the software is deployed on production networks. * `Upgrade Activated` -## More Information +## More information * To check for the latest node software, see the [Software Releases](/builders/node-operators/releases). * For more information on the governance process see the [governance documentation](https://community.optimism.io/docs/governance/). diff --git a/pages/builders/node-operators/releases.mdx b/pages/builders/node-operators/releases.mdx index f0966bf01..08a2e40d3 100644 --- a/pages/builders/node-operators/releases.mdx +++ b/pages/builders/node-operators/releases.mdx @@ -6,7 +6,7 @@ description: Off chain node software release information and how to stay up to d import { Callout } from 'nextra/components' -# Node Software Releases +# Node software releases This page gives information on the off chain node software release information. @@ -15,27 +15,27 @@ This page gives information on the off chain node software release information. and `op-geth` releases can be found [here](https://github.com/ethereum-optimism/op-geth/releases). -## Production Releases +## Production releases Chain and node operators should always run the latest production releases of the OP Stack's off-chain components. Production releases are always tags, versioned as `/v`. For example, an `op-node` release might be versioned as `op-node/v1.7.5`. Tags of the form `v`, such as `v1.7.6`, indicate releases of all Go code only and DO NOT include smart contracts. This naming scheme is required by Golang. In the above list, these `v` releases contain all `op-*` components and exclude all `contracts-*` components. `op-geth` embeds upstream geth's version inside its own version as follows: `vMAJOR.GETH_MAJOR GETH_MINOR GETH_PATCH.PATCH`. Basically, geth's version is our minor version. For example, if geth is at `v1.12.0`, the corresponding `op-geth` version would be `v1.101200.0`. Note that we pad out to three characters for the geth minor version and two characters for the geth patch version. Since we cannot left-pad with zeroes, the geth major version is not padded. -### Docker Images +### Docker images To make it easier to find and use our Docker images, each release entry below provides links to the corresponding Docker images: * **op-node**: Docker images can be found [here](https://hub.docker.com/r/ethereumoptimism/op-node/tags). * **op-geth**: Docker images can be found [here](https://hub.docker.com/r/ethereumoptimism/op-geth/tags). -### Example Docker Image Tags +### Example Docker image tags We follow a consistent tagging convention to make it easier to find the right image. Here are some examples: * `optimism/op-node:` * `optimism/op-geth:` -## Release Entries +## Release entries | Network | op-node | op-geth | | ---------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | diff --git a/pages/builders/node-operators/rollup-node.mdx b/pages/builders/node-operators/rollup-node.mdx index dcffe980d..19c82347c 100644 --- a/pages/builders/node-operators/rollup-node.mdx +++ b/pages/builders/node-operators/rollup-node.mdx @@ -1,16 +1,16 @@ --- -title: How to Run a Node in the Superchain +title: How to run a node in the Superchain lang: en-US description: Learn how to run an OP Stack rollup node in the Superchain. --- import { Callout, Steps } from 'nextra/components' -# How to Run a Node in the Superchain +# How to run a node in the Superchain This guide provides an overview of how to run an OP Stack rollup node in the Superchain. It walks you through how to build, configure, run, and monitor your node on one of the OP Chains in the Superchain. To skip ahead to building and running a node, you can explore the [node operator tutorials](#node-operator-tutorials). -## Build Your Node +## Build your node Before building your node, you will learn fundamental aspects of OP Stack rollup nodes. @@ -34,7 +34,7 @@ Before building your node, you will learn fundamental aspects of OP Stack rollup * **Option 2:** Follow the [Building a Node from Source](/builders/node-operators/tutorials/node-from-source) tutorial, if you need to use a specific architecture or want to inspect the source code of your OP Stack rollup node. -## Configure Your Node +## Configure your node OP Stack rollup nodes can be configured for individual needs. The following steps will get you started with a working base configuration for OP Stack rollup nodes, along with recommended flags. @@ -55,7 +55,7 @@ OP Stack rollup nodes can be configured for individual needs. The following step -## Run Your Node +## Run your node Now, you will run your node and set your node debugging log level for more granular feedback. @@ -78,7 +78,7 @@ Now, you will run your node and set your node debugging log level for more granu * Update node [log level](/builders/node-operators/configuration/consensus-config#loglevel) based on individual needs. For more details, see the guide on [Geth Logs](https://geth.ethereum.org/docs/fundamentals/logs). -## Monitor Your Node +## Monitor your node It is important to regularly monitor your node, and you can optionally configure prometheus and grafana dashboard to make this process easier for you. @@ -100,13 +100,13 @@ It is important to regularly monitor your node, and you can optionally configure -## Follow Node Updates +## Follow node updates * It's important to keep your node software up to date. Software updates can also include important bug fixes and patches that can help keep your node stable. * Refer to the [Software Releases](/builders/node-operators/releases) page for a detailed look at the latest releases of various rollup node and execution client implementations. * Notifications are also posted to the Optimism Upgrade Announcement Channels on [**Discord**](https://discord.com/channels/667044843901681675/754090866435424270) and [**Telegram**](https://t.me/+LtAJL1Mt1PYyNjBh). -## Node Operator Tutorials +## Node operator tutorials Got an idea for a new tutorial? @@ -121,7 +121,7 @@ It is important to regularly monitor your node, and you can optionally configure | [Running an OP Mainnet Node from Source](tutorials/mainnet) | Learn how to run an OP Mainnet node from source code. | 🟡 Medium | | [Running an OP Sepolia Node from Source](tutorials/testnet) | Learn how to run an OP Sepolia node from source code. | 🟡 Medium | -## Next Steps +## Next steps * If you've already got your node up and running, check out the [Node Metrics and Monitoring Guide](/builders/node-operators/management/metrics) to learn how to keep tabs on your node and make sure it keeps running smoothly. * If you run into any problems, please visit the [Node Troubleshooting Guide](/builders/node-operators/management/troubleshooting) for help. diff --git a/pages/builders/node-operators/tutorials/mainnet.mdx b/pages/builders/node-operators/tutorials/mainnet.mdx index 079171dab..b2906a723 100644 --- a/pages/builders/node-operators/tutorials/mainnet.mdx +++ b/pages/builders/node-operators/tutorials/mainnet.mdx @@ -1,22 +1,22 @@ --- -title: Running an OP Mainnet Node from Source +title: Running an OP Mainnet node from source lang: en-US description: Learn how to run an OP Mainnet node from source code for full nodes and archive nodes. --- import { Callout, Steps } from 'nextra/components' -# Running an OP Mainnet Node from Source +# Running an OP Mainnet node from source This tutorial explains how to run an OP Mainnet node from source code for full nodes and archive nodes. Running an OP Mainnet node from source code is a flexible alternative to using pre-built Docker images. -## Building the Source Code +## Building the source code You'll need to build `op-node` and `op-geth` from their respective source repositories before you can run a node. Make sure to follow the instructions on [Building a Node from Source](./node-from-source) before continuing. -## Hardware Requirements +## Hardware requirements Hardware requirements for OP Mainnet nodes can vary depending on the type of node you plan to run. Archive nodes generally require significantly more resources than full nodes. @@ -25,7 +25,7 @@ Below are suggested minimum hardware requirements for each type of node. * 16GB RAM * Reasonably modern CPU -### SSD Capacity Requirements +### SSD capacity requirements Given the growing size of the blockchain state, choosing the right SSD size is important. Below are the storage needs as of April 2024: @@ -39,14 +39,14 @@ Based on these trends, node operators should plan for future storage needs and c Geth supports a "freezer" feature to store older chain data on HDDs, saving SSD space. Configure this for OP Mainnet using the `--datadir.ancient` flag. See [Geth docs](https://geth.ethereum.org/docs/fundamentals/databases) and [OP docs](../configuration/execution-config#datadirancient) for details. -## Full Nodes +## Full nodes -### Assess Blob Archiver +### Assess blob archiver Assess if you need to configure a blob archiver service by reading the [Configure a Blob Archiver documentation](/builders/node-operators/management/blobs#configure-a-blob-archiver-archive-nodes). -### Create a JWT Secret +### Create a JWT secret `op-geth` and `op-node` communicate over the engine API authrpc. This communication is secured using a shared secret. @@ -169,12 +169,12 @@ Once you've started `op-geth`, you can start `op-node`. -### Synchronization Verification +### Synchronization verification Once you've started `op-geth` and `op-node` you should see the two begin to communicate with each other and synchronize the OP Mainnet chain. -#### Snap Sync (Default) +#### Snap sync (default) Initial synchronization can take several hours to complete. You will see these `op-node` logs at the start of snap sync: @@ -223,7 +223,7 @@ There are two stages on `op-geth` for snap sync: -#### Full Sync +#### Full sync You will need access to the migrated OP Mainnet database to run a full node with full sync. @@ -256,13 +256,13 @@ INFO [06-26|14:02:12.976] Chain head was updated number=4,068, INFO [06-26|14:02:12.982] Starting work on payload id=0x5542117d680dbd4e ``` -## Archive Nodes +## Archive nodes You only need an archive node if you need the historical state. Most node operators should default to full nodes. -### Get the Migrated Data Directory +### Get the migrated data directory OP Mainnet underwent a large database migration as part of the [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/) in 2023. You will need access to the migrated OP Mainnet database to run an archive node. @@ -322,7 +322,7 @@ In this section, you'll learn how to download and verify the pre-migrated databa Set `--syncmode=full` and `--gcmode=archive` on `op-geth`. -### Get the Legacy Geth Directory (Optional) +### Get the legacy Geth directory (optional) Blocks and transactions included in OP Mainnet before the Bedrock Upgrade cannot be executed by modern OP Mainnet nodes. OP Mainnet nodes will **serve** these blocks and transactions but cannot run certain queries against them (e.g. `eth_call`). @@ -367,7 +367,7 @@ If you want to run a full node then you can safely skip this section. ``` -### Start Legacy Geth (Optional) +### Start legacy Geth (optional) If you've chosen to run a Legacy Geth node alongside your OP Mainnet node, you'll need to start it before you start your OP Mainnet node. @@ -390,7 +390,7 @@ If you've chosen to run a Legacy Geth node alongside your OP Mainnet node, you'l ``` -## Next Steps +## Next steps * If you've already got your node up and running, check out the [Node Metrics and Monitoring Guide](../management/metrics) to learn how to keep tabs on your node and make sure it keeps running smoothly. * If you run into any problems, please visit the [Node Troubleshooting Guide](../management/troubleshooting) for help. diff --git a/pages/builders/node-operators/tutorials/node-from-docker.mdx b/pages/builders/node-operators/tutorials/node-from-docker.mdx index b2706a1b2..9f18059fb 100644 --- a/pages/builders/node-operators/tutorials/node-from-docker.mdx +++ b/pages/builders/node-operators/tutorials/node-from-docker.mdx @@ -6,14 +6,14 @@ description: Learn how to run a node using Docker. import { Callout, Steps } from 'nextra/components' -# Running a Node With Docker +# Running a node with Docker Using [Docker](https://docs.docker.com/engine/install/) is an easy way to run an OP Mainnet node. This tutorial will walk you through the process of using [`simple-optimism-node`](https://github.com/smartcontracts/simple-optimism-node) to run an OP Mainnet or OP Sepolia node using Docker. `simple-optimism-node` also provides useful tools like a monitoring dashboard and health checking software. Although less flexible than [running a node from source](./node-from-source) or building your own Docker setup, this is a great way to quickly get started with OP Mainnet. -## What's Included +## What's included `simple-optimism-node` includes all the basic components to run an OP Mainnet or OP Sepolia node. It also includes several additional services to monitor the health of your node and the health of the network you're connected to. @@ -81,7 +81,7 @@ Configuration for `simple-optimism-node` is handled through environment variable * **Base Sepolia** - [https://sepolia.base.org](https://sepolia.base.org) -## Run the Node +## Run the node Once you've configured your `.env` file, you can run the node using Docker Compose. The following command will start the node in the background. @@ -90,7 +90,7 @@ The following command will start the node in the background. docker compose up -d --build ``` -## Upgrade the Node +## Upgrade the node Pull the latest updates from GitHub, Docker Hub and rebuild the container. @@ -100,12 +100,12 @@ docker compose pull docker compose up -d --build --force-recreate ``` -## Operating the Node +## Operating the node You can use Docker Compose to interact with the node and manage the various containers that you started. Refer to the [Operating the Node](https://github.com/smartcontracts/simple-optimism-node#operating-the-node) section of the `simple-optimism-node` README for more information. -## Checking Node Status +## Checking node status `simple-optimism-node` includes a monitoring dashboard that you can use to check the status of your node. You can access the dashboard by visiting `http://localhost:3000` in your browser. diff --git a/pages/builders/node-operators/tutorials/node-from-source.mdx b/pages/builders/node-operators/tutorials/node-from-source.mdx index 326afa65c..97e01389e 100644 --- a/pages/builders/node-operators/tutorials/node-from-source.mdx +++ b/pages/builders/node-operators/tutorials/node-from-source.mdx @@ -1,20 +1,20 @@ --- -title: Building a Node from Source +title: Building a node from source lang: en-US description: Learn how to build your own node without relying on images from Optimism. --- import { Callout, Steps } from 'nextra/components' -# Building a Node from Source +# Building a node from source Docker images are the easiest way to run an OP Mainnet node, but you can always build your own node from source code. You might want to do this if you want to run a node on a specific architecture or if you want to inspect the source code of the node you're running. This guide will walk you through the full process of building a node from source. -## What You're Going to Build +## What you're going to build -### Rollup Node +### Rollup node The Rollup Node is responsible for deriving L2 block payloads from L1 data and passing those payloads to the Execution Client. The Rollup Node can also optionally participate in a peer-to-peer network to receive blocks directly from the Sequencer before those blocks are submitted to L1. @@ -22,7 +22,7 @@ The Rollup Node is largely analogous to a [consensus client](https://ethereum.or In this tutorial you will build the `op-node` implementation of the Rollup Node as found in the [Optimism Monorepo](https://github.com/ethereum-optimism/optimism). -### Execution Client +### Execution client The Execution Client is responsible for executing the block payloads it receives from the Rollup Node over JSON-RPC via the standard [Ethereum Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md#engine-api----common-definitions). The Execution Client exposes the standard JSON-RPC API that Ethereum developers are familiar with, and can be used to query blockchain data and submit transactions to the network. @@ -30,7 +30,7 @@ The Execution Client is largely analogous to an [execution client](https://ether In this tutorial you will build the `op-geth` implementation of the Execution Client as found in the [`op-geth` repository](https://github.com/ethereum-optimism/op-geth). -### Legacy Geth (Optional) +### Legacy Geth (optional) Legacy Geth is an optional component for OP Mainnet archive nodes. Legacy Geth allows you to execute stateful queries like `eth_call` against blocks and transactions that occurred before the OP Mainnet [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/). @@ -39,7 +39,7 @@ Legacy Geth is only relevant to OP Mainnet archive nodes and is not required for Currently, `l2Geth` is the only available implementation of Legacy Geth. In this tutorial you will build the `l2geth` implementation of Legacy Geth as found in the [`optimism-legacy` repository](https://github.com/ethereum-optimism/optimism-legacy). -## Software Dependencies +## Software dependencies | Dependency | Version | Version Check Command | | ------------------------------------------------------------- | -------- | --------------------- | @@ -50,7 +50,7 @@ In this tutorial you will build the `l2geth` implementation of Legacy Geth as fo | [foundry](https://github.com/foundry-rs/foundry#installation) | `^0.2.0` | `forge --version` | | [make](https://linux.die.net/man/1/make) | `^4` | `make --version` | -## Build the Rollup Node +## Build the rollup node First you're going to build the `op-node` implementation of the Rollup Node as found in the [Optimism Monorepo](https://github.com/ethereum-optimism/optimism). @@ -106,7 +106,7 @@ make op-node -## Build the Execution Client +## Build the execution client Next you're going to build the `op-geth` implementation of the Execution Client as found in the [op-geth repository](https://github.com/ethereum-optimism/op-geth). @@ -146,7 +146,7 @@ make geth -## Build Legacy Geth (Optional) +## Build legacy Geth (optional) Legacy Geth is an optional component for OP Mainnet archive nodes. Legacy Geth allows you to execute stateful queries like `eth_call` against blocks and transactions that occurred before the OP Mainnet [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/). @@ -172,7 +172,7 @@ make -## Next Steps +## Next steps * Click here to [Run an OP Mainnet Node from Source Code](mainnet) * Click here to [Run an OP Sepolia Node from Source Code](testnet) diff --git a/pages/builders/node-operators/tutorials/testnet.mdx b/pages/builders/node-operators/tutorials/testnet.mdx index 4d97bf849..bec9846dc 100644 --- a/pages/builders/node-operators/tutorials/testnet.mdx +++ b/pages/builders/node-operators/tutorials/testnet.mdx @@ -1,22 +1,22 @@ --- -title: Running an OP Sepolia Node from Source +title: Running an OP Sepolia node from source lang: en-US description: Learn how to run an OP Sepolia node from source code. --- import { Callout, Steps } from 'nextra/components' -# Running an OP Sepolia Node from Source +# Running an OP Sepolia node from source This tutorial explains how to run an OP Sepolia node from source code. Running an OP Sepolia node from source code is a flexible alternative to using pre-built Docker images. -## Building the Source Code +## Building the source code You'll need to build `op-node` and `op-geth` from their respective source repositories before you can run a node. Make sure to follow the instructions on [Building a Node from Source](./node-from-source) before continuing. -## Hardware Requirements +## Hardware requirements Hardware requirements for OP Sepolia nodes can vary depending on the type of node you plan to run. Archive nodes generally require significantly more resources than full nodes. @@ -26,12 +26,12 @@ Below are suggested minimum hardware requirements for each type of node. * 60 GB SSD (full node) or 200 GB SSD (archive node) * Reasonably modern CPU -## Assess Blob Archiver +## Assess blob archiver Assess if you need to configure a blob archiver service by reading the [Configure a Blob Archiver documentation](/builders/node-operators/management/blobs#configure-a-blob-archiver-archive-nodes). -## Create a JWT Secret +## Create a JWT secret `op-geth` and `op-node` communicate over the engine API authrpc. This communication is secured using a shared secret. @@ -162,12 +162,12 @@ Note that this flag will cause `op-node` to trust the L1 node to provide correct -### Synchronization Verification +### Synchronization verification Once you've started `op-geth` and `op-node` you should see the two begin to communicate with each other and synchronize the OP Mainnet chain. -#### Snap Sync (Default) +#### Snap sync (default) Initial synchronization can take several hours to complete. You will see these `op-node` logs at the start of snap sync: @@ -216,7 +216,7 @@ There are two stages on `op-geth` for snap sync: -#### Full Sync +#### Full sync Initial full synchronization can take several days to complete. @@ -246,7 +246,7 @@ INFO [06-26|14:02:12.976] Chain head was updated number=4,068, INFO [06-26|14:02:12.982] Starting work on payload id=0x5542117d680dbd4e ``` -## Next Steps +## Next steps * If you've already got your node up and running, check out the [Node Metrics and Monitoring Guide](../management/metrics) to learn how to keep tabs on your node and make sure it keeps running smoothly. * If you run into any problems, please visit the [Node Troubleshooting Guide](../management/troubleshooting) for help. diff --git a/pages/builders/notices/fp-changes.mdx b/pages/builders/notices/fp-changes.mdx index 4f7a34d81..0ef6d47cd 100644 --- a/pages/builders/notices/fp-changes.mdx +++ b/pages/builders/notices/fp-changes.mdx @@ -1,12 +1,12 @@ --- -title: Preparing for Fault Proofs Breaking Changes +title: Preparing for fault proofs breaking changes lang: en-US description: Learn how to prepare for Fault Proofs changes. --- import { Steps, Callout } from 'nextra/components' -# Preparing for Fault Proofs Breaking Changes +# Preparing for fault proofs breaking changes OP Labs has submitted a [proposal to governance](https://gov.optimism.io/t/upgrade-proposal-fault-proofs/8161) to upgrade OP Mainnet to support Fault Proofs. If this proposal passes, fault proofs would launch on OP Mainnet approximately June 2024. This document details changes that apply to users, bridges, and centralized exchanges, as well as any custom solutions that use withdrawals. This page outlines changes for OP Mainnet and OP Sepolia only. Details for other OP Chains are forthcoming. @@ -17,7 +17,7 @@ If you experience difficulty at any stage of this process, please reach out to [ **ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reproven after the upgrade is complete. - * Reproving simply requires that you execute the [withdrawal proving flow](https://docs.optimism.io/stack/protocol/rollup/withdrawal-flow) again. + * Reproving simply requires that you execute the [withdrawal proving flow](/stack/transactions/withdrawal-flow) again. * Withdrawals prior to the Fault Proofs upgrade must wait a 7-day challenge period before finalization. As a result, any withdrawal initiated less than 7 days before the upgrade cannot be finalized before the upgrade is executed. You may want to consider waiting until after the upgrade is complete to begin a withdrawal during this 7-day window. @@ -33,7 +33,7 @@ If you experience difficulty at any stage of this process, please reach out to [ As of the Fault Proofs update to OP Sepolia in March 2024, **OP Sepolia withdrawals are no longer instant.** This is because the Fault Proof mechanism now applies to OP Sepolia transactions. -## Overview of Changes +## Overview of changes If you are operating a custom bridge, review this section for changes you need to make. If you are using Optimism SDK or Viem for your bridging, you can [skip to the next section](#for-bridges-and-centralized-exchanges). @@ -56,7 +56,7 @@ Now, developers must look at the `OptimismPortal` contract to determine the `res It is recommended that developers search for a reasonable number of recent games, say 100 games, and pick the first proposal with a sufficient block number. Developers should then verify this proposal locally as the default game type will allow for permissionless proposals and there is no longer a strong guarantee that proposals will be valid. -## For Bridges and Centralized Exchanges +## For bridges and centralized exchanges The proposed Fault Proof upgrade requires developers to enable Fault Proof changes before the Op Mainnet release. This impacts bridges, centralized exchanges, and custom solutions that use withdrawals. @@ -66,7 +66,7 @@ The proposed Fault Proof upgrade requires developers to enable Fault Proof chang - ### Update Logic to Support Fault Proofs + ### Update logic to support fault proofs Most teams use the Optimism SDK or Viem to handle this logic under the hood and will simply need to update their software version ahead of the upgrade. However, any project performing withdrawals programmatically will need to update their client code (see [`OptimismPortal`](#optimismportal) for details). @@ -76,7 +76,7 @@ The proposed Fault Proof upgrade requires developers to enable Fault Proof chang The Optimism SDK changes do not break the API and require no changes other than updating to the correct software version to support the new `OptimismPortal` logic. The Optimism SDK will automatically begin to use the new logic once it detects that the FPM update has gone live. * **Option 2: Viem Update.** Update to the latest version of Viem (version of >=2.9.0). Viem will automatically begin to use the new logic once it detects that the FPM update has gone live. - ### Update Withdrawal Monitor + ### Update withdrawal monitor The Withdrawal Monitor service is an important part of the two-step withdrawal system that checks if anyone has been able to prove withdrawals that do not actually appear on L2. The Withdrawal Monitor is now slightly slower at startup time but is more reliable, simpler, and compatible with more infrastructure to more easily support any OP Stack chain. @@ -85,7 +85,7 @@ The proposed Fault Proof upgrade requires developers to enable Fault Proof chang * **Option 1: Withdrawal from source.** If building or using withdrawal-monitor from source, make sure that you are using the latest develop branch. All withdrawal monitor changes are fully backwards compatible. * **Option 2: Docker image.** If using docker, use the latest chain-mon docker image. - ### Update Dispute Monitor + ### Update dispute monitor The Dispute Monitor service detects when invalid outputs have been proposed. Given the large number of changes to the output proposal system, the current Fault Monitor is being replaced in favor of a new Dispute Monitor purposely built for the fault proof monitor system. @@ -94,7 +94,7 @@ The proposed Fault Proof upgrade requires developers to enable Fault Proof chang -## Next Steps +## Next steps -* See the [Fault Proofs Explainer](/stack/protocol/fault-proofs/explainer) to learn more about the three main components of the Fault Proof System. -* You can also read more about [Cannon FPVM](/stack/protocol/fault-proofs/cannon) and [Mips.sol](/stack/protocol/fault-proofs/mips), the onchain smart contract implementation of Cannon. +* See the [Fault Proofs Explainer](/stack/fault-proofs/explainer) to learn more about the three main components of the Fault Proof System. +* You can also read more about [Cannon FPVM](/stack/fault-proofs/cannon) and [Mips.sol](/stack/fault-proofs/mips), the onchain smart contract implementation of Cannon. diff --git a/pages/builders/notices/granite-changes.mdx b/pages/builders/notices/granite-changes.mdx index b0eaa9871..5fc68df94 100644 --- a/pages/builders/notices/granite-changes.mdx +++ b/pages/builders/notices/granite-changes.mdx @@ -1,12 +1,12 @@ --- -title: Preparing for Granite Breaking Changes +title: Preparing for Granite breaking changes lang: en-US description: Learn how to prepare for Granite upgrade breaking changes. --- import { Steps, Callout } from 'nextra/components' -# Preparing for Granite Breaking Changes +# Preparing for Granite breaking changes This page outlines breaking changes related to the Granite network upgrade for chain operators and node operators. If you experience difficulty at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). @@ -15,21 +15,21 @@ If you experience difficulty at any stage of this process, please reach out to [ The Granite upgrade for OP Sepolia was activated on **1723478400 - Mon Aug 12 16:00:00 UTC**. The Granite OP Mainnet upgrade will be activated at **1726070401 - Wed 11 Sep 2024 16:00:01 UTC**, here is the [governance vote](https://vote.optimism.io/proposals/46514799174839131952937755475635933411907395382311347042580299316635260952272). -## What's Included in Granite +## What's included in Granite -This upgrade is proposed in response to security vulnerabilities identified during a series of third-party security audits by Spearbit, Cantina, and Code4rena. None of the vulnerabilities have been exploited, and user assets are not and were never at risk. However, out of an abundance of caution, the permissioned fallback mechanism has been activated in order to avoid any potential instability while the vulnerabilities are patched. For more information on the permissioned fallback mechanism and the OP Stack's defense-in-depth approach to Fault Proof security, see the [fault proof documentation](https://docs.optimism.io/stack/protocol/fault-proofs/fp-security). +This upgrade is proposed in response to security vulnerabilities identified during a series of third-party security audits by Spearbit, Cantina, and Code4rena. None of the vulnerabilities have been exploited, and user assets are not and were never at risk. However, out of an abundance of caution, the permissioned fallback mechanism has been activated in order to avoid any potential instability while the vulnerabilities are patched. For more information on the permissioned fallback mechanism and the OP Stack's defense-in-depth approach to Fault Proof security, see the [fault proof documentation](/stack/fault-proofs/fp-security). The upgrade includes both a set of smart contract upgrades to fix the vulnerabilities identified in the audit as well as an L2 hardfork to improve the stability and performance of the fault proof system. In addition, we propose extending the capabilities of the Guardian and DeputyGuardian to set the anchor state for the fault proof system in order to prevent referencing invalid anchor states. Aside from implementing these fixes, the primary impact of this upgrade would be to reset user withdrawals at the planned time, similar to the initial Fault Proof upgrade. Please refer to the [governance proposal](https://gov.optimism.io/t/upgrade-proposal-10-granite-network-upgrade/8733) for the full details. -## For Chain Operators +## For chain operators The proposed Granite upgrade impacts OP chains and requires chain operators to upgrade their chain and configure the sequencer for Granite. - ### Prepare Sequencer Node + ### Prepare sequencer node If you are operating an OP Chain that has an entry in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), the Granite activation date is part of the `op-node` and `op-geth` nodes, and are using the [--network](/builders/node-operators/configuration/consensus-config#network) and [--op-network](/builders/node-operators/configuration/execution-config#op-network-betaop-network) flags. No action is needed for the sequencer after preparing the `SystemConfig` transaction. @@ -42,7 +42,7 @@ The proposed Granite upgrade impacts OP chains and requires chain operators to u * Set `override.granite` in both `op-node` and `op-geth` to the UNIX timestamp of the block you want to activate the Granite hardfork or corresponding env vars for this. * In general, run `op-node --help` or `op-geth --help` to see flags, their descriptions and environment variables. - ### Rollup Configuration Breaking Changes + ### Rollup configuration breaking changes Alt-DA mode has had a name change. What was formerly known as Plasma Mode has been renamed and you may need to [update your rollup configuration file](/builders/chain-operators/features/alt-da-mode#breaking-changes-renaming-plasma-mode-to-alt-da-mode). @@ -51,7 +51,7 @@ The proposed Granite upgrade impacts OP chains and requires chain operators to u To verify proper configuration, chain operators should confirm in the startup logs of their `op-node` and `op-geth` that the correct Granite activation timestamps are set. -## For Node Operators +## For node operators Node operators will need to upgrade to Granite before the activation date. The op-node release [v1.9.1](https://github.com/ethereum-optimism/optimism/releases/tag/v1.9.1) @@ -60,12 +60,12 @@ and op-geth release [v1.101408.0](https://github.com/ethereum-optimism/op-geth/r These following steps are necessary for every node operator: - ### Update to the Latest Release + ### Update to the latest release * [`op-node`](https://github.com/ethereum-optimism/optimism/releases/tag/v1.9.1) * [`op-geth`](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101408.0) - ### Configure the Granite Activation Date + ### Configure the Granite activation date If you are operating a node for an OP Chain that has an entry in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), the Granite activation date is part of the `op-node` and `op-geth` nodes. So, no action is needed for the sequencer after upgrading to the latest release. Please skip to [Step 3: Verify Your Configuration](#verify-your-configuration). @@ -76,7 +76,7 @@ These following steps are necessary for every node operator: * **Option 1:** Set the activation time in the `rollup.json` for `op-node`. You will still need to set the `override.granite` flag in `op-geth` if you use this option. * **Option 2:** Set the activation time via overrides (CLI) in both `op-node` and `op-geth`. These will need to be set on `op-node` and `op-geth` for the sequencer and all other nodes. - ### Verify Your Configuration + ### Verify your configuration Make the following checks to verify that your node is properly configured. diff --git a/pages/builders/notices/sdk-deprecation 2.mdx b/pages/builders/notices/sdk-deprecation 2.mdx deleted file mode 100644 index 302f4afba..000000000 --- a/pages/builders/notices/sdk-deprecation 2.mdx +++ /dev/null @@ -1,101 +0,0 @@ ---- -title: Deprecation of the Optimism SDK -lang: en-US -description: This page outlines the details of the Optimism SDK deprecation and guides developers to migrate to using `viem` library. ---- - -## Preparing for Optimism SDK deprecation - -The Optimism SDK will officially be deprecated in Q1 2025. The project is shifting to the `viem` library for a more modern, efficient, and flexible development experience. This change affects all tutorials and resources that previously relied on the Optimism SDK, and relevant documentation has been updated accordingly. - -### Breaking changes to expect - -The migration from the Optimism SDK to `viem` library brings several breaking changes: - -* **Transaction estimation**: Methods for estimating gas fees will now leverage `viem` APIs. -* **Bridging**: All token bridging actions must be updated to use the `viem` library bridging methods. -* **Cross-chain communication**: `viem` library simplifies the cross-domain messaging functionality. -* **SDK method removal**: All deprecated SDK methods will be unavailable after Q1 2025. - -Developers and users are strongly encouraged to transition to `viem` before the deprecation date to avoid disruptions. - -### Updated tutorials - -We are updating our tutorials to use the `viem` library. - - {/* Below, you'll find links to the updated versions of popular tutorials: - -* [Estimating Transaction Costs on OP Mainnet](../tutorials/transaction-cost-estimation)\ - Estimation of transaction costs now uses the `viem` gas estimation utilities. - -* [Triggering OP Mainnet Transactions from Ethereum](../tutorials/trigger-op-transactions)\ - Learn how to trigger transactions using `viem` to interact with the OP Mainnet. - -* [Tracing Deposits and Withdrawals](../tutorials/tracing-deposits-withdrawals)\ - The tracing functionalities have been adapted to use `opstack` for efficient results. - -* [Viewing Deposits and Withdrawals by Address](../tutorials/view-deposits-withdrawals)\ - This tutorial outlines updated methods in `viem` for querying deposits and withdrawals by address. - -* [Bridging Your Standard ERC-20 Token Using the Standard Bridge](../tutorials/bridge-standard-erc20)\ - The standard bridge tutorial now uses `opstack` for token transfers between Ethereum and OP Mainnet. - -* [Bridging Your Custom ERC-20 Token Using the Standard Bridge](../tutorials/bridge-custom-erc20)\ - Custom ERC-20 tokens can now be bridged via `opstack`, making the process more streamlined. - -* [Bridging ERC-20 Tokens to OP Mainnet With the Optimism SDK](../tutorials/bridge-sdk-erc20)\ - **Deprecated** – please use [Bridging Your Custom ERC-20 Token Using the Standard Bridge](../tutorials/bridge-custom-erc20). - -* [Bridging ETH to OP Mainnet With the Optimism SDK](../tutorials/bridge-sdk-eth)\ - **Deprecated** – please use [Estimating Transaction Costs on OP Mainnet](../tutorials/transaction-cost-estimation). - -* [Communicating Between OP Mainnet and Ethereum in Solidity](../tutorials/cross-chain-solidity)\ - Cross-chain communication now leverages `opstack` for all messaging. */} - -### For app developers - -If your application currently depends on the Optimism SDK, you will need to migrate to using the `viem` library. -The tutorials have been updated to reflect these changes, and it is critical to update your applications before the deprecation date to maintain compatibility. - -Here are some key points to consider: - -Install new dependencies: Replace the Optimism SDK with `viem` in your project. - -```bash - pnpm remove @eth-optimism/sdk - pnpm add viem -``` - -* Update imports: Replace Optimism SDK imports with `viem` imports. -* Migrate SDK methods: Refactor your code to use equivalent `viem` methods. Refer to the viem documentation and opstack documentation for guidance. -* Test thoroughly: After migration, extensively test your application to ensure all functionality works as expected. - -### For chain operators - -Chain operators utilizing the SDK for cross-chain operations, bridging, or other functions should switch to the `viem` library. -The `viem` library offers more efficient methods to handle these operations. - -Chain operators should be aware of the following: - -* SDK removal: Remove any dependencies on the Optimism SDK in your infrastructure. -* Update tooling: Ensure all tools and scripts are updated to use `viem`. -* Monitor performance: After migration, closely monitor your chain's performance to ensure smooth operation. - -### For node operators - -Node operators will need to ensure that any scripts or services relying on the Optimism SDK are updated to use `viem` library. -These updates will help align with future improvements and scalability efforts across the OP Stack. - -Node operators should take the following steps: - -* Update node software: Ensure your node software is compatible with the latest `viem` libraries. -* Review configuration: Check and update any configuration files that may reference the Optimism SDK. -* Test thoroughly: Perform comprehensive testing in a staging environment before updating production nodes. - -### Need Help? - -For further assistance or questions about this migration, feel free to reach through the following channels: - -* Join our [community forum](https://community.optimism.io/) for discussions and support -* Connect with us on [Discord](https://discord.gg/optimism) for community support -* Open an [issue on our GitHub repository](https://github.com/ethereum-optimism/docs/issues) for documentation-related concerns diff --git a/pages/builders/notices/sdk-deprecation.mdx b/pages/builders/notices/sdk-deprecation.mdx index 302f4afba..b67ba7eff 100644 --- a/pages/builders/notices/sdk-deprecation.mdx +++ b/pages/builders/notices/sdk-deprecation.mdx @@ -23,35 +23,6 @@ Developers and users are strongly encouraged to transition to `viem` before the We are updating our tutorials to use the `viem` library. - {/* Below, you'll find links to the updated versions of popular tutorials: - -* [Estimating Transaction Costs on OP Mainnet](../tutorials/transaction-cost-estimation)\ - Estimation of transaction costs now uses the `viem` gas estimation utilities. - -* [Triggering OP Mainnet Transactions from Ethereum](../tutorials/trigger-op-transactions)\ - Learn how to trigger transactions using `viem` to interact with the OP Mainnet. - -* [Tracing Deposits and Withdrawals](../tutorials/tracing-deposits-withdrawals)\ - The tracing functionalities have been adapted to use `opstack` for efficient results. - -* [Viewing Deposits and Withdrawals by Address](../tutorials/view-deposits-withdrawals)\ - This tutorial outlines updated methods in `viem` for querying deposits and withdrawals by address. - -* [Bridging Your Standard ERC-20 Token Using the Standard Bridge](../tutorials/bridge-standard-erc20)\ - The standard bridge tutorial now uses `opstack` for token transfers between Ethereum and OP Mainnet. - -* [Bridging Your Custom ERC-20 Token Using the Standard Bridge](../tutorials/bridge-custom-erc20)\ - Custom ERC-20 tokens can now be bridged via `opstack`, making the process more streamlined. - -* [Bridging ERC-20 Tokens to OP Mainnet With the Optimism SDK](../tutorials/bridge-sdk-erc20)\ - **Deprecated** – please use [Bridging Your Custom ERC-20 Token Using the Standard Bridge](../tutorials/bridge-custom-erc20). - -* [Bridging ETH to OP Mainnet With the Optimism SDK](../tutorials/bridge-sdk-eth)\ - **Deprecated** – please use [Estimating Transaction Costs on OP Mainnet](../tutorials/transaction-cost-estimation). - -* [Communicating Between OP Mainnet and Ethereum in Solidity](../tutorials/cross-chain-solidity)\ - Cross-chain communication now leverages `opstack` for all messaging. */} - ### For app developers If your application currently depends on the Optimism SDK, you will need to migrate to using the `viem` library. @@ -92,7 +63,7 @@ Node operators should take the following steps: * Review configuration: Check and update any configuration files that may reference the Optimism SDK. * Test thoroughly: Perform comprehensive testing in a staging environment before updating production nodes. -### Need Help? +### Need help? For further assistance or questions about this migration, feel free to reach through the following channels: diff --git a/pages/builders/tools/build/account-abstraction.mdx b/pages/builders/tools/build/account-abstraction.mdx index 8d9bf410c..266286735 100644 --- a/pages/builders/tools/build/account-abstraction.mdx +++ b/pages/builders/tools/build/account-abstraction.mdx @@ -1,12 +1,12 @@ --- -title: Account Abstraction +title: Account abstraction lang: en-US description: This guide explains how to use account abstraction to remove friction from your app experience --- import { Callout } from 'nextra/components' -# Account Abstraction +# Account abstraction This page includes providers that meet specific [inclusion criteria](#inclusion-criteria), as outlined below. Please visit the [community account abstractions page](https://github.com/ethereum-optimism/developers/blob/main/community/tools/account-abstraction.md) for an additional listing of third-party account abstraction tools. @@ -19,11 +19,21 @@ import { Callout } from 'nextra/components' * Sponsor the gas fees for transactions * Enable users to pay gas in the token(s) of their choice -## Superchain Paymaster +## Bundlers -The Superchain paymaster is an ERC-4337 verifying paymaster that sponsors transactions for smart accounts on the Superchain. Use the Superchain Paymaster to get your transactions sponsored to remove friction from your app experience. [View the implementation guide and tutorials here.](https://github.com/ethereum-optimism/ecosystem/tree/main/docs/superchain-paymaster) +The OP Stack includes support for the `eth_sendRawTransactionConditional` RPC method to assist bundlers on shared 4337 mempools. See the [specification](/stack/features/send-raw-transaction-conditional) for how this method is implemented in op-geth. -## Account Abstraction Tools +If enabled by the chain operator, also see the supplemental [op-txproxy](/builders/chain-operators/tools/op-txproxy) service, if applied, as this enforces request authentication for this method. + + + As of today, this endpoint is not enabled by default in the stack. The operator must explicitly configure this. + + +## Superchain paymaster + +The Superchain paymaster is an ERC-4337 verifying paymaster that sponsors transactions for smart accounts on the Superchain. Use the Superchain Paymaster to get your transactions sponsored to remove friction from your app experience. + +## Account abstraction tools Ready to enable account abstraction experiences in your app? Here's some helpful information on account abstraction infrastructure like ERC-4337 bundler and gas manager APIs that are available on OP Mainnet: @@ -45,12 +55,12 @@ Ready to enable account abstraction experiences in your app? Here's some helpful * [Thirdweb](https://portal.thirdweb.com/connect/account-abstraction/overview): offers the complete tool-kit to leverage account abstraction technology to enable seamless user experiences for your users. This includes Account Factory contracts that lets your users spin up Smart Accounts, Bundler for UserOps support, and Paymaster to enable gas sponsorships. -## Helpful Tips +## Helpful tips * [EIP-1271 Signature Validation](https://eip1271.io/) * [Making smart accounts work with WalletConnect v2](https://safe-global.notion.site/WalletConnect-v2-update-Issues-and-solutions-for-smart-wallets-3fc32fad6af4485fa5823eaebd486819) -## Inclusion Criteria +## Inclusion criteria Developer teams who want to feature products/tools on this page must meet the following criteria: diff --git a/pages/builders/tools/build/block-explorers.mdx b/pages/builders/tools/build/block-explorers.mdx index e72e8da6e..cd179fc87 100644 --- a/pages/builders/tools/build/block-explorers.mdx +++ b/pages/builders/tools/build/block-explorers.mdx @@ -1,12 +1,12 @@ --- -title: Block Explorers +title: Block explorers lang: en-US description: Learn about different block explorers you can use to interact with contracts and view transaction history for OP Mainnet and OP Sepolia. --- import { Callout } from 'nextra/components' -# Block Explorers +# Block explorers This reference guide lists different block explorers you can use to interact with contract source code and view transaction history for OP Mainnet and OP Sepolia. @@ -65,12 +65,12 @@ Once Upon currently supports: * Mainnet - Ethereum, OP Mainnet, Base, Zora, Public Goods Network * Sepolia - Ethereum, OP Sepolia, Base, Zora, Public Goods Network, Lyra, Mode -## Access to Pre-Regenesis History +## Access to pre-regenesis history Because of our final regenesis on 11 November 2021, older transactions are not part of the current blockchain and do not appear on [Etherscan](https://explorer.optimism.io/). However, you **can** access transaction history between 23 June 2021 and the final regenesis using a number of different tools. For detailed instructions, see [Regenesis History](/builders/tools/monitor/regenesis-history). -## Inclusion Criteria +## Inclusion criteria Developer teams who want to feature products/tools on this page must meet the following criteria: diff --git a/pages/builders/tools/build/faucets.mdx b/pages/builders/tools/build/faucets.mdx index 54467f03e..a21e53c08 100644 --- a/pages/builders/tools/build/faucets.mdx +++ b/pages/builders/tools/build/faucets.mdx @@ -1,12 +1,12 @@ --- -title: Testnet Faucets +title: Testnet faucets lang: en-US description: Learn how to get testnet ETH on test networks like Sepolia and OP Sepolia for development and testing purposes. --- import { Callout } from 'nextra/components' -# Testnet Faucets +# Testnet faucets Faucets are developers tools that allow you to get free ETH (and other tokens) on test networks like Sepolia and OP Sepolia so that you can send transactions and create smart contracts. Here you'll find a list of active faucets that you can try out. @@ -22,12 +22,12 @@ Faucets can occasionally also run out of ETH, so if you're having trouble gettin Optimists only take what they need so that others can use faucets too! -## Superchain Faucet +## Superchain faucet The [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) is a developer tool hosted by Optimism that allows developers to get free testnet ETH to test apps on testnet OP Chains like Base Sepolia, OP Sepolia, PGN Sepolia, Zora Sepolia, and other OP Chains in the Superchain. The Superchain Faucet is a great place to start if you're looking for testnet ETH. -## Additional Faucets +## Additional faucets | Faucet Name | Supported Networks | | -------------------------------------------------------------------------------- | -------------------------------------------------------- | @@ -46,7 +46,7 @@ The Superchain Faucet is a great place to start if you're looking for testnet ET If you have testnet ETH on Sepolia, you can bridge it to OP Sepolia (and vice versa) using the [Superchain Bridges UI](https://app.optimism.io/bridge) or this collection of [Superchain Testnet Tools](https://www.superchain.tools/). -## Inclusion Criteria +## Inclusion criteria Developer teams who want to feature products/tools on this page must meet the following criteria: @@ -57,7 +57,7 @@ Developer teams who want to feature products/tools on this page must meet the fo For teams that are supporting but still establishing a user base, we encourage you to share your tool on the [community faucets page](https://github.com/ethereum-optimism/developers/blob/main/community/tools/faucets.md). You can also promote your tool in the [developer forum](https://github.com/ethereum-optimism/developers/discussions/categories/show-and-tell) and signup to share your tool at the next [demo day](https://community.optimism.io/docs/contribute/demo-day/). -## Next Steps +## Next steps * If you're new to onchain development, check out [Optimism Unleashed](https://cryptozombies.io/en/optimism) by CryptoZombies and [Superchain Builder NFT](https://web.archive.org/web/20231218203510/https://blog.thirdweb.com/guides/optimism-superchain-faucet-nft/) by ThirdWeb. * If you're familiar with onchain development, check out the [Optimism Ecosystem's Contributions Dashboard](https://github.com/ethereum-optimism/ecosystem-contributions) for project ideas that the Optimism Collective is looking for. diff --git a/pages/builders/tools/build/nft-tools.mdx b/pages/builders/tools/build/nft-tools.mdx index 270f3f636..bd93d6f3a 100644 --- a/pages/builders/tools/build/nft-tools.mdx +++ b/pages/builders/tools/build/nft-tools.mdx @@ -1,12 +1,12 @@ --- -title: OP Mainnet NFT Tools +title: OP Mainnet NFT tools lang: en-US description: Learn the basics of creating an NFT on OP Mainnet. --- import { Callout } from 'nextra/components' -# OP Mainnet NFT Tools +# OP Mainnet NFT tools ## The OP Mainnet NFT ecosystem @@ -59,7 +59,3 @@ These tools are available on OP Mainnet: * [Tofu](https://tofunft.com/optimism) * [OptiMarket](https://optimarket.io/) * [Circular Art](https://www.circularart.xyz/) - -## Marketplace aggregators - -* [Bluesweep](https://www.bluesweep.xyz/) diff --git a/pages/builders/tools/build/oracles.mdx b/pages/builders/tools/build/oracles.mdx index 378ea8d16..f69f07fac 100644 --- a/pages/builders/tools/build/oracles.mdx +++ b/pages/builders/tools/build/oracles.mdx @@ -18,12 +18,12 @@ For example, a [stablecoin](https://ethereum.org/en/stablecoins/) that accepts E * How many stablecoins can we give a user for a given amount of ETH? * Do we need to liquidate any deposits because they are under collateralized? -## Security and Decentralization +## Security and decentralization Different oracles have different security assumptions and different levels of decentralization. Usually they are either run by the organization that produces the information, or have a mechanism to reward entities that provide accurate information and penalize those that provide incorrect information. -## Types of Oracles +## Types of oracles There are two types of oracles: @@ -37,13 +37,13 @@ There are two types of oracles: 2. Single-transaction oracles, which only require one transaction. The way this works is that the transaction that requests the information includes a callback (address and the call data to provide it). When the oracle is updated (which also happens through a transaction, but one that is not sent by the user), the oracle uses the callback to inform a contract of the result. -## Random Number Generation (RGN) +## Random number generation (RGN) Random number generation in blockchain applications ensures that smart contracts can access unbiased random values. This is essential for certain use cases like generative NFTs, gaming, commit & reveal schemes and more. Various approaches include using a trusted third party, blockhash-based methods, Verifiable Random Functions (VRF), quantum random numbers to name a few. Each method has trade-offs between simplicity, security, and trust assumptions, allowing developers to select the most suitable option for their use case. -## List of Oracles +## List of oracles -### Gas Oracle +### Gas oracle OP Mainnet provides a [Gas Price Oracle](https://github.com/ethereum-optimism/optimism/blob/233ede59d16cb01bdd8e7ff662a153a4c3178bdd/packages/contracts/contracts/L2/predeploys/OVM_GasPriceOracle.sol) that provides information about [gas prices and related parameters](/stack/transactions/fees). It can also calculate the total cost of a transaction for you before you send it. @@ -130,7 +130,7 @@ Builders can choose how they want to consume the data among 3 dedicated models: Interested in integration? [Get in contact](https://discord.com/invite/PVxBZKFr46) with the RedStone team! -## Inclusion Criteria +## Inclusion criteria Developer teams who want to feature products/tools on this page must meet the following criteria: @@ -141,7 +141,7 @@ Developer teams who want to feature products/tools on this page must meet the fo For teams that are supporting but still establishing a user base, we encourage you to share your tool on the [community oracles page](https://github.com/ethereum-optimism/developers/blob/main/community/tools/oracles.md). You can also promote your tool in the [developer forum](https://github.com/ethereum-optimism/developers/discussions/categories/show-and-tell) and signup to share your tool at the next [demo day](https://community.optimism.io/docs/contribute/demo-day/). -## Next Steps +## Next steps * Please visit the [community oracles page](https://github.com/ethereum-optimism/developers/blob/main/community/tools/oracles.md) for a listing of third-party Oracles used by the Optimism developer community. * Looking for other developer tools? See [developer tools overview](/builders/tools/overview) to explore more options! diff --git a/pages/builders/tools/connect/rpc-providers.mdx b/pages/builders/tools/connect/rpc-providers.mdx index 20010e015..e896b1a4e 100644 --- a/pages/builders/tools/connect/rpc-providers.mdx +++ b/pages/builders/tools/connect/rpc-providers.mdx @@ -1,12 +1,12 @@ --- -title: RPC & Node Providers +title: RPC & Node providers lang: en-US description: Learn about different RPC and node providers to help you connect to an Optimism node. --- import { Callout } from 'nextra/components' -# RPC & Node Providers +# RPC & Node providers This reference guide lists different RPC and node providers to help you connect to an Optimism node. @@ -16,42 +16,42 @@ This page includes providers that meet specific [inclusion criteria](#inclusion- ## Ankr -### Description and Pricing +### Description and pricing [Ankr](https://www.ankr.com/) provides a geo-distributed and decentralized (free) public and premium (Pay-as-you-go) [Optimism RPC](https://www.ankr.com/rpc/optimism/) comprised of many independent blockchain nodes running worldwide for low-latency and incredibly reliable connections. Moreover, Ankr offers access to developer tooling on OP Mainnet (and testnets) like SDKs and [Advanced APIs](https://www.ankr.com/advanced-api/) such as NFT, Token and Query API. -### Supported Networks +### Supported networks * OP Mainnet * OP Sepolia ## Alchemy -### Description and Pricing +### Description and pricing [Alchemy](https://docs.alchemy.com/reference/optimism-api-quickstart/?a=818c11a8da) is a popular API provider and developer platform. Its robust, free tier offers access to enhanced features like SDKs and enhanced APIs and hosted OP Mainnet and testnet nodes. -### Supported Networks +### Supported networks * OP Mainnet * OP Sepolia ## Chainstack -### Description and Pricing +### Description and pricing [Chainstack](https://chainstack.com/build-better-with-optimism/) provides global & regional load-balanced nodes that are full & archive with debug & trace APIs. For the free tier, the Developer plan is available and you can sign up with GitHub account or other social logins. Chainstack also has special discounts available. -### Supported Networks +### Supported networks * OP Mainnet * OP Sepolia ## dRPC -### Description and Pricing +### Description and pricing [dRPC](https://drpc.org) provides geo-distributed, auto-scalable OP Mainnet and OP Sepolia nodes. For more information, visit [dRPC's chainlist for Optimism](https://drpc.org/chainlist/optimism). dRPC supports Websocket and all methods, including debug and trace methods. For early-stage startups, dRPC and Optimism Collective provide OP Mainnet 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. @@ -62,42 +62,42 @@ OP Sepolia ## Infura -### Description and Pricing +### Description and pricing [Infura](https://infura.io) is a Web3 infrastructure provider that offers free access to hosted [OP Mainnet and testnet nodes](https://docs.infura.io/infura/networks/optimism), with the option to upgrade to [paid plans](https://www.infura.io/pricing) for more features. With Infura's highly performant Optimism node infrastructure, developers can eliminate the need for syncing or complex setups and get reliable and consistent access to the Optimism blockchain. [Sign up for a free Infura account here](https://app.infura.io/register) -### Supported Networks +### Supported networks * OP Mainnet * OP Sepolia ## Moralis -### Description and Pricing +### Description and pricing [Moralis](https://moralis.io/?utm_source=op-docs&utm_medium=partner-docs) is a popular Node and API provider for both real-time and indexed blockchain data. Moralis is the only major infrastructure provider in blockchain with a SOC2 Type 2 certification. You can use Moralis for free, or upgrade to a [paid plan](https://moralis.io/pricing/?utm_source=op-docs&utm_medium=partner-docs) for more features and benefits. [Sign up for a free Moralis account here](https://admin.moralis.io/register/?utm_source=op-docs&utm_medium=partner-docs) -### Supported Networks +### Supported networks * OP Mainnet ## QuickNode -### Description and Pricing +### Description and pricing [QuickNode](https://www.quicknode.com/) offers access to hosted OP Mainnet (and testnet) nodes for free. With the option to upgrade to a premium plan for additional features, we allow you to focus solely on optimizing your application while we manage the complex infrastructure. -### Supported Networks +### Supported networks * OP Mainnet * OP Sepolia -## Inclusion Criteria +## Inclusion criteria Developer teams who want to feature products/tools on this page must meet the following criteria: @@ -108,7 +108,7 @@ Developer teams who want to feature products/tools on this page must meet the fo For teams that are supporting but still establishing a user base, we encourage you to share your tool on the [community node providers page](https://github.com/ethereum-optimism/developers/blob/main/community/tools/node-providers.md). You can also promote your tool in the [developer forum](https://github.com/ethereum-optimism/developers/discussions/categories/show-and-tell) and signup to share your tool at the next [demo day](https://community.optimism.io/docs/contribute/demo-day/). -## Next Steps +## Next steps * Please visit the [community node providers page](https://github.com/ethereum-optimism/developers/blob/main/community/tools/node-providers.md) for a listing of third-party node providers used by the Optimism developer community. * Looking for other developer tools? See [developer tools overview](/builders/tools/overview) to explore more options! diff --git a/pages/builders/tools/fee-calculator.mdx b/pages/builders/tools/fee-calculator.mdx index 543b71598..053cf3601 100644 --- a/pages/builders/tools/fee-calculator.mdx +++ b/pages/builders/tools/fee-calculator.mdx @@ -1,12 +1,12 @@ --- -title: Fjord Fee Parameter Calculator +title: Fjord fee parameter calculator lang: en-US description: Use the Fjord Fee Parameter Calculator to estimate and calculate fees for transactions. --- import { ChainParametersForm } from '@/components/calculator/ChainParametersForm' -# Fjord Fee Parameter Calculator +# Fjord fee parameter calculator The Fjord Fee Parameter Calculator helps you estimate transaction fees. Use this tool to: diff --git a/pages/builders/tools/monitor/analytics-tools.mdx b/pages/builders/tools/monitor/analytics-tools.mdx index aa3a39031..f7d39d0a7 100644 --- a/pages/builders/tools/monitor/analytics-tools.mdx +++ b/pages/builders/tools/monitor/analytics-tools.mdx @@ -1,12 +1,12 @@ --- -title: Analytics Tools +title: Analytics tools lang: en-US description: Learn about platforms you can use to gather analytics and setup customizations about OP Mainnet. --- import { Callout } from 'nextra/components' -# Analytics Tools +# Analytics tools The following guide lists platforms you can use to gather analytics and setup customizations about OP Mainnet. @@ -31,7 +31,7 @@ It helps you to inspect states at every instance of transaction and gives a plat * [setup real-time alerts for smart contracts](https://blog.tenderly.co/how-to-set-up-real-time-alerting-for-smart-contracts-with-tenderly/) * [automate your responses to alert triggers](https://blog.tenderly.co/tenderly-alert-webhooks/) with custom webhooks -## Dune Analytics +## Dune analytics [Dune Analytics](https://dune.com) allows anyone to create dashboards that present information about OP Chains (OP Mainnet, Base, and Zora are available). See [Dune Docs](https://dune.com/docs/) for more info. You can find a list of community created dashboards for OP Chains [here](https://dune.com/browse/dashboards?q=tags%3Aop%2Coptimism%2Csuperchain\&order=trending\&time_range=24h), or [create your own](https://docs.dune.com/#queries) dashboard. @@ -44,7 +44,7 @@ Here are some of our favorite dashboards so far: * [OP Token House Delegates](https://dune.com/optimismfnd/optimism-op-token-house) * [Superchain NFTs](https://dune.com/oplabspbc/superchain-nfts) -## Additional Tools and Resources +## Additional tools and resources Here are some additional tools and resources for OP Mainnet analytics and development: diff --git a/pages/builders/tools/monitor/regenesis-history.mdx b/pages/builders/tools/monitor/regenesis-history.mdx index 73a469f34..0938a0b58 100644 --- a/pages/builders/tools/monitor/regenesis-history.mdx +++ b/pages/builders/tools/monitor/regenesis-history.mdx @@ -1,12 +1,12 @@ --- -title: Accessing Pre-Regenesis History +title: Accessing pre-regenesis history lang: en-US description: Learn how to use access pre-regenesis history using the Etherscan CSV exporting tool. --- import { Callout, Steps } from 'nextra/components' -# Accessing Pre-Regenesis History +# Accessing pre-regenesis history This tutorial explains how to access transaction history between 23 June 2021 and the final regenesis. Because of our final regenesis on 11 November 2021, older transactions are not part of the current blockchain and do not appear on [Etherscan](https://explorer.optimism.io/). @@ -26,7 +26,7 @@ You have to log on with a Dune account, but their free tier is sufficient. Alternatively, to run custom queries in Dune, you can use the `optimism_legacy_ovm1` schema defined in [Dune Docs here](https://dune.com/docs/data-tables/?h=ovm#optimism). -## Lost Data Directories +## Lost data directories Three data directories that were used by legacy L2Geth Sequencer instances during the period of January 2021 to July 2021 had been errantly deleted during @@ -60,7 +60,7 @@ requests for this data came from individuals who needed access to this informati for the 2021 tax season though this is mostly no longer relevant today (many people who needed this data already retrieved it). -### Going Forward +### Going forward We recognize the inconvenience this has caused some of our community and their uses and we're sorry for the frustrations. In an effort to prevent similar diff --git a/pages/builders/tools/overview.mdx b/pages/builders/tools/overview.mdx index e315426b6..dac27f1e5 100644 --- a/pages/builders/tools/overview.mdx +++ b/pages/builders/tools/overview.mdx @@ -1,12 +1,12 @@ --- -title: Developer Tools +title: Developer tools lang: en-US description: Learn about different developer tools you can use to help you build on Optimism. --- import { Cards, Card } from 'nextra/components' -# Developer Tools +# Developer tools Welcome to the Optimism developer tools! @@ -43,7 +43,7 @@ If you are already familiar with [building on OP Mainnet](/chain/getting-started } /> -## OP Tools +## OP tools } /> diff --git a/pages/chain/addresses.mdx b/pages/chain/addresses.mdx index 4317dbf7d..eb1e0d7ef 100644 --- a/pages/chain/addresses.mdx +++ b/pages/chain/addresses.mdx @@ -1,5 +1,5 @@ --- -title: Contract Addresses +title: Contract addresses lang: en-US description: This reference guide lists all the contract addresses for Mainnet and Testnet. --- diff --git a/pages/chain/differences.mdx b/pages/chain/differences.mdx index 784911879..3e50bf180 100644 --- a/pages/chain/differences.mdx +++ b/pages/chain/differences.mdx @@ -20,7 +20,7 @@ However, there are some minor differences between the behavior of Ethereum and O | `ORIGIN` | `tx.origin` | If the transaction is an L1 ⇒ L2 transaction triggered by a smart contract on L1, then `tx.origin` is set to the [aliased address](#address-aliasing) of the address that triggered the L1 ⇒ L2 transaction. Otherwise, this opcode behaves normally. | | `CALLER` | `msg.sender` | If the transaction is an L1 ⇒ L2 transaction triggered by a smart contract on L1, and this is the first call frame (rather than an internal transaction from one contract to another), the same [address aliasing](#address-aliasing) behavior applies. | -### Address Aliasing +### Address aliasing Address aliasing is an important security feature that impacts the behavior of transactions sent from L1 to L2 by smart contracts. @@ -50,12 +50,12 @@ In all other cases, the transaction sender address is set according to the same ## Transactions -### Transaction Fees +### Transaction fees Transactions on OP Mainnet must pay for an [L1 data fee](/stack/transactions/fees#the-l1-data-fee) on top of the standard [execution gas fee](/stack/transactions/fees#execution-gas-fee) you would expect on Ethereum. Refer to the guide on [OP Mainnet Transaction Fees](/stack/transactions/fees) for more information. -### EIP-1559 Parameters +### EIP-1559 parameters The base fee on OP Mainnet is, like Ethereum, computed via the [EIP-1559](https://notes.ethereum.org/@vbuterin/eip-1559-faq) mechanism. The EIP-1559 parameters used by OP Mainnet differ from those used by Ethereum as follows. @@ -70,7 +70,7 @@ The EIP-1559 parameters used by OP Mainnet differ from those used by Ethereum as | Maximum base fee decrease (per block) | 0.4% | 12.5% | | Block time in seconds | 2 | 12 | -### Mempool Rules +### Mempool rules Unlike Ethereum, OP Mainnet does not have a large public mempool. The OP Mainnet Sequencer mempool is currently only visible to the Sequencer. diff --git a/pages/chain/getting-started.mdx b/pages/chain/getting-started.mdx index 6d4136cf5..cf9703d44 100644 --- a/pages/chain/getting-started.mdx +++ b/pages/chain/getting-started.mdx @@ -1,34 +1,34 @@ --- -title: Getting Started Developing for OP Mainnet +title: Getting started developing for OP Mainnet lang: en-US description: Learn the basics of OP Mainnet development. --- import { Steps } from 'nextra/components' -# Getting Started Developing for OP Mainnet +# Getting started developing for OP Mainnet This guide explains the basics of OP Mainnet development. OP Mainnet 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 OP Mainnet development and Ethereum development are minor. But a few differences [do exist](/chain/differences). -## OP Mainnet and OP Sepolia Endpoint URLs +## OP Mainnet and OP Sepolia endpoint URLs To access any Ethereum type network you need an endpoint. [These providers](/builders/tools/connect/rpc-providers) support our networks. -### Network Choice +### Network choice For development purposes we recommend you use either a local development node or [OP Sepolia](https://sepolia-optimism.etherscan.io). That way you don't need to spend real money. If you need ETH on OP Sepolia for testing purposes, [you can use this faucet](https://console.optimism.io/faucet?utm_source=docs). -## Interacting with Contracts on OP Mainnet or OP Sepolia +## Interacting with contracts on OP Mainnet or OP Sepolia We have Hardhat's Greeter contract on OP Sepolia at address [0x9d334aFBa83865E67a9219830ADA57aaA9406681](https://sepolia-optimism.etherscan.io/address/0x9d334aFBa83865E67a9219830ADA57aaA9406681#code). You can verify your development stack configuration by interacting with it. -## Development Stacks +## Development stacks As you can see in the different development stacks below, the way you deploy contracts and interact with them on OP Mainnet or OP Sepolia is almost identical to the way you do it with L1 Ethereum. The most visible difference is that you have to specify a different endpoint (of course). @@ -42,21 +42,21 @@ The list of other differences is [here](differences). * [Truffle](https://trufflesuite.com/) * [Waffle](https://getwaffle.io/) -## Best Practices +## Best practices -### Use Provided EVM +### Use provided EVM It is best to start development with the EVM provided by the development stack. Not only is it faster, but such EVMs often have extra features, such as the [ability to log messages from Solidity](https://hardhat.org/tutorial/debugging-with-hardhat-network.html) or a [graphical user interface](https://trufflesuite.com/ganache/). -### Debug Before Deploying +### Debug before deploying After you are done with that development, debug your decentralized application using either a [development node](/chain/testing/dev-node) or the [Sepolia test network](/chain/networks). This lets you debug parts that are OP Mainnet specific such as calls to bridges to transfer ETH or tokens between layers. Only when you have a version that works well on a test network should you deploy to the production network, where every transaction has a cost. -### Contract Source Verification +### Contract source verification You don't have to upload your source code to [block explorers](/builders/tools/build/block-explorers), but it is a good idea. On the test network, it lets you issue queries and transactions from the explorer's user interface. diff --git a/pages/chain/identity/about-attestations.mdx b/pages/chain/identity/about-attestations.mdx index 81f7133ca..4c2bdfbba 100644 --- a/pages/chain/identity/about-attestations.mdx +++ b/pages/chain/identity/about-attestations.mdx @@ -1,17 +1,17 @@ --- -title: About Attestations +title: About attestations lang: en-US description: Learn about building decentralized identity apps using Ethereum Attestation Service. --- import { Callout } from 'nextra/components' -# Build Decentralized Identity Apps with Attestations +# Build decentralized identity apps with attestations This guide explains how to build decentralized identity apps using attestations. It will define attestations and review the benefits of using Ethereum Attestation Service for Optimism developers. -## About Attestations +## About attestations Attestations are signed statements about a person, entity, or thing, made by an individual, company, or organization and are one of the building blocks of decentralized identity. @@ -20,7 +20,7 @@ You can think of Ethereum Attestation Service as a multiplayer database for stre ![attestation logo.](/img/op-mainnet/identity/atst-logo.png) -## Benefits of Using Ethereum Attestation Service +## Benefits of using Ethereum attestation service EAS makes it easy to sign any piece of data. In addition, here are a few key benefits: @@ -43,7 +43,7 @@ Here are some best practices to avoid violating users' privacy: Global data privacy laws are complex and multifaceted, and the violations of user privacy can have meaningful compliance as well as practical implications. -## Common Questions +## Common questions **Q: Are attestations replacements for verifiable credentials?** @@ -57,7 +57,7 @@ Here are some best practices to avoid violating users' privacy: **A:** Attestations have two key benefits over soulbound / non-transferable tokens: flexibility of whether the attestations is onchain or offchain and composability. While there is a canonical [decentralized schema registry for attestations](https://optimism.easscan.org/schemas), there is no central registry or specification for soulbound / non-transferable tokens which can lead to poor interoperability between systems and protocols. -## Next Steps +## Next steps Are you inspired and don't know what to build? We have a [project idea list](https://github.com/ethereum-optimism/ecosystem-contributions). Do you have a good idea, but you know you're not the right person to build it? Please open a PR on that list and suggest it. diff --git a/pages/chain/identity/applications.mdx b/pages/chain/identity/applications.mdx index 78cf5294e..7375f3a4b 100644 --- a/pages/chain/identity/applications.mdx +++ b/pages/chain/identity/applications.mdx @@ -4,11 +4,11 @@ lang: en-US description: Learn some of the applications that use attestations. --- -# Attestation Apps +# Attestation apps This guide lists some of the applications that use attestations. -## Ethereum Attestation Service +## Ethereum attestation service These are some of the applications that use the attestations: @@ -18,6 +18,6 @@ These are some of the applications that use the attestations: * [Optimist Profile](https://app.optimism.io/retropgf-signup): The Optimist Profile allows contributors to share the contributions and impact they've made to the Optimism Collective. * [Ethereum Ecosystem onchain reviews](https://www.ethereum-ecosystem.com/new-review): The goal of this Attestation-Based Dapp Rating web app is to allow anyone to review dApps and tools 100% onchain. -## Building with Attestations +## Building with attestations Are you building with attestations? Feel free to add your app to this page using the [attestation GitHub issue template](https://github.com/ethereum-optimism/docs/issues/new?assignees=\&labels=documentation%2Cattestation%2Ccommunity-request\&projects=\&template=suggest_attestation.yaml\&title=%5BATT%5D+Add+PR+title). diff --git a/pages/chain/identity/contracts-eas.mdx b/pages/chain/identity/contracts-eas.mdx index b501aa31a..9c6498d4d 100644 --- a/pages/chain/identity/contracts-eas.mdx +++ b/pages/chain/identity/contracts-eas.mdx @@ -4,12 +4,12 @@ lang: en-US description: Learn the basics of contracts for EAS, EAS contract addresses, and how to read and write attestations. --- -# EAS Contracts +# EAS contracts This guide covers [Ethereum Attestation Service ("EAS")](https://attest.sh/), an open-source public good that is included as a predeploy in the OP Stack. It also covers EAS contract addresses, how to read and write attestations, and indexing. -## EAS Contract Addresses +## EAS contract addresses The [Ethereum Attestation Service](https://docs.attest.sh/docs/welcome) is deployed on these addresses: @@ -18,7 +18,7 @@ The [Ethereum Attestation Service](https://docs.attest.sh/docs/welcome) is deplo | OP Sepolia | [0x4200000000000000000000000000000000000021](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000021) | [0x4200000000000000000000000000000000000020](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000020) | | OP Mainnet | [0x4200000000000000000000000000000000000021](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000021) | [0x4200000000000000000000000000000000000020](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000020) | -## How to Read and Write Attestations +## How to read and write attestations You can read and write attestations in several ways: @@ -35,6 +35,6 @@ Indexing is available via: * [Ponder graph](https://github.com/ethereum-attestation-service/eas-ponder-graph) * [Open source indexer](https://github.com/ethereum-attestation-service/eas-indexing-service) -## Next Steps +## Next steps For more information on working with attestations, see [Build Decentralized Identity Apps with Attestations](about-attestations). diff --git a/pages/chain/identity/individuals.mdx b/pages/chain/identity/individuals.mdx index 197cde2b5..4ed5e6965 100644 --- a/pages/chain/identity/individuals.mdx +++ b/pages/chain/identity/individuals.mdx @@ -4,11 +4,11 @@ lang: en-US description: Learn about how individual identity is represented in the Optimism Collective. --- -## Individual Identity +## Individual identity The Optimism Collective represents individuals using unique identifiers generated through the [Farcaster protocol id registry](https://docs.farcaster.xyz/reference/contracts/reference/id-registry). This system ensures a secure approach to identity management within the collective. -### Registering a User ID +### Registering a user ID To obtain a unique identifier: @@ -18,13 +18,13 @@ To obtain a unique identifier: * Creates a new custody address * Acts as a wallet -### Making Attestations +### Making attestations When you make attestations about individuals: * Leave the recipient address blank * Enter the users id into the attestation metadata -### Further Reading +### Further reading For more details on individual identity in the Optimism Collective, refer to the **[the governance docs](https://community.optimism.io/docs/identity/project-and-individual-identity-in-the-collective/#building-a-digital-identity)** on building a digital identity. diff --git a/pages/chain/identity/overview.mdx b/pages/chain/identity/overview.mdx index 236a11a9f..efa96fd28 100644 --- a/pages/chain/identity/overview.mdx +++ b/pages/chain/identity/overview.mdx @@ -1,5 +1,5 @@ --- -title: Identity Overview +title: Identity overview lang: en-US description: Learn about the basics of decentralized identity solutions. --- @@ -24,7 +24,7 @@ Decentralized identity expands the design space for innovation. It aims to give For more information about identity in the Optimism Collective, see [the governance docs post on the identity stack](https://community.optimism.io/docs/identity/project-and-individual-identity-in-the-collective/). -## Key Components of Identity +## Key components of identity There are three important components to identity within the Optimism Collective: @@ -38,7 +38,7 @@ Individuals and projects are the relevant entities in the Optimism Collective ab Decentralized identity not only supports democratic governance but also enhances innovation and individual financial control within the Optimism Collective ecosystem. -## Next Steps +## Next steps To learn more about identity in the Optimism Collective: diff --git a/pages/chain/identity/projects.mdx b/pages/chain/identity/projects.mdx index f3bca4d01..98ae2a849 100644 --- a/pages/chain/identity/projects.mdx +++ b/pages/chain/identity/projects.mdx @@ -11,15 +11,15 @@ Within the Optimism Collective, [the project entity](https://community.optimism. The project entity is represented onchain by an attestation from the [following schema](https://optimism.easscan.org/schema/view/0xff0b916851c1c5507406cfcaa60e5d549c91b7f642eb74e33b88143cae4b47d0). Projects are identified by the type "project". The attestation UID serves as the project's unique identifier throughout its lifecycle in the Collective. -## Project Metadata +## Project metadata All other project metadata is stored or referenced in the [Project Metadata Attestation](https://optimism.easscan.org/schema/view/0xe035e3fe27a64c8d7291ae54c6e85676addcbc2d179224fe7fc1f7f05a8c6eac). -### Updating Metadata +### Updating metadata * The Project Metadata Attestation is re-issued whenever there's a change in metadata. * Apps displaying project metadata should refer to the most recent attestation for up-to-date information. -## Further Reading +## Further reading For more information about identity in the Optimism Collective, see the [Identity Overview](/chain/identity/overview.mdx). diff --git a/pages/chain/identity/schemas.mdx b/pages/chain/identity/schemas.mdx index 721b4091c..1a562471a 100644 --- a/pages/chain/identity/schemas.mdx +++ b/pages/chain/identity/schemas.mdx @@ -10,14 +10,14 @@ Schemas define the structure and type of data that can be included in an attesta Below you will find a list of relevant schemas that are being used on OP Mainnet. Schemas are built using the [Ethereum Attestation Service](https://docs.attest.sh/docs/welcome). -## General Schemas +## General schemas * **[Gitcoin Passport V1 scores schema UID](https://optimism.easscan.org/schema/view/0x6ab5d34260fca0cfcf0e76e96d439cace6aa7c3c019d7c4580ed52c6845e9c89):** `0x6ab5d34260fca0cfcf0e76e96d439cace6aa7c3c019d7c4580ed52c6845e9c89` * **[Superchain Faucet schema UID](https://optimism.easscan.org/schema/view/0x98ef220cd2f94de79fbc343ef982bfa8f5b315dec6a08f413680ecb7085624d7)**: `0x98ef220cd2f94de79fbc343ef982bfa8f5b315dec6a08f413680ecb7085624d7` ## Schemas related to project creation and Retro Funding application -### [Project and Organization identifier](https://optimism.easscan.org/schema/view/0xff0b916851c1c5507406cfcaa60e5d549c91b7f642eb74e33b88143cae4b47d0) +### [Project and organization identifier](https://optimism.easscan.org/schema/view/0xff0b916851c1c5507406cfcaa60e5d549c91b7f642eb74e33b88143cae4b47d0) Used as the unique identifier for projects and organizations created on or after 23 August 2024. For projects created earlier, please see the archived section at the bottom of this page. @@ -27,7 +27,7 @@ Used as the unique identifier for projects and organizations created on or after | farcasterID | The Farcaster id of the individual who created the project or organization | | type | "Project" or "Organization" | -### [Organization Metadata](https://optimism.easscan.org/schema/view/0xc2b376d1a140287b1fa1519747baae1317cf37e0d27289b86f85aa7cebfd649f) +### [Organization metadata](https://optimism.easscan.org/schema/view/0xc2b376d1a140287b1fa1519747baae1317cf37e0d27289b86f85aa7cebfd649f) Used to associate metadata to an organization. Re-issued each time there is a change to metadata @@ -43,7 +43,7 @@ Used to associate metadata to an organization. Re-issued each time there is a ch | metadataType | How the metadata can be accessed. 1 for ipfs, 2 for http | | metadataUrl | The storage location where the metadata can be retrieved | -### [Project Metadata](https://optimism.easscan.org/schema/view/0xe035e3fe27a64c8d7291ae54c6e85676addcbc2d179224fe7fc1f7f05a8c6eac) +### [Project metadata](https://optimism.easscan.org/schema/view/0xe035e3fe27a64c8d7291ae54c6e85676addcbc2d179224fe7fc1f7f05a8c6eac) Used to associate metadata to a project. Re-issued each time there is a change to metadata. @@ -59,7 +59,7 @@ Used to associate metadata to a project. Re-issued each time there is a change t | metadataType | How the metadata can be accessed. 1 for ipfs, 2 for http | | metadataUrl | The storage location where the metadata can be retrieved | -### [Retro Funding Application](https://optimism.easscan.org/schema/view/0x2169b74bfcb5d10a6616bbc8931dc1c56f8d1c305319a9eeca77623a991d4b80) +### [Retro funding application](https://optimism.easscan.org/schema/view/0x2169b74bfcb5d10a6616bbc8931dc1c56f8d1c305319a9eeca77623a991d4b80) Used to identify a project's application to a specific Retro Funding Round. This attestation is used for Retro Funding Round 6 and beyond. @@ -73,7 +73,7 @@ Used to identify a project's application to a specific Retro Funding Round. This | farcasterID | The individual that submitted this application on behalf of the project. | | metadataSnapshot RefUID | The project metadata at the time the application was submitted. | -### [Retro Funding Application Approval/Rejection](https://optimism.easscan.org/schema/view/0x683b1b399d47aabed79c9aa8f2674729021174b6e5cce1e20675eab404fc82d6) +### [Retro funding application approval/rejection](https://optimism.easscan.org/schema/view/0x683b1b399d47aabed79c9aa8f2674729021174b6e5cce1e20675eab404fc82d6) Used to identify which Retro Funding applications have been approved or rejected. @@ -85,7 +85,7 @@ Used to identify which Retro Funding applications have been approved or rejected | Status | The status of the Retro Funding application. | | Reason | Identifier for the reason an application was rejected. 1 = "Duplicate Application", 2 = "Deceiving Badgeholders", 3 = "Spam", 4 = "Not meeting eligibility criteria" | -### [Retro Funding Rewards](https://optimism.easscan.org/schema/view/0x670ad6e6ffb842d37e050ea6d3a5ab308195c6f584cf2121076067e0d8adde18) +### [Retro funding rewards](https://optimism.easscan.org/schema/view/0x670ad6e6ffb842d37e050ea6d3a5ab308195c6f584cf2121076067e0d8adde18) Used to identify the reward amount each approved project received in a Retro Funding round @@ -109,7 +109,7 @@ Citizen attestations were first issued in Season 6 and are used to represent Cit | FarcasterID | The Citizen's unique identifier | | SelectionMethod | A Code representing the method through which the Citizen was selected. Codes beginning with the number 1 refer to various flavours of Web of Trust selection. | -### [Retro Funding Voters](https://optimism.easscan.org/schema/view/0x41513aa7b99bfea09d389c74aacedaeb13c28fb748569e9e2400109cbe284ee5) +### [Retro funding voters](https://optimism.easscan.org/schema/view/0x41513aa7b99bfea09d389c74aacedaeb13c28fb748569e9e2400109cbe284ee5) These attestations are voting Badges issued for Retro Round 5 and beyond. They are different from the [previous schema](https://optimism.easscan.org/schema/view/0xfdcfdad2dbe7489e0ce56b260348b7f14e8365a8a325aef9834818c00d46b31b) to include new fields like votingGroup, used to assign voters to sub-categories in the round. @@ -121,12 +121,34 @@ These attestations are voting Badges issued for Retro Round 5 and beyond. They a | votingGroup | Used to assign voters to subcategories in case the Round has subcategories | | selectionMethod | The method in which this voter was selected | -### [Retro Funding Governance contribution](https://optimism.easscan.org/schema/view/0x3743be2afa818ee40304516c153427be55931f238d961af5d98653a93192cdb3) +### [MetaGov Contribution](https://optimism.easscan.org/schema/view/0x84260b9102b41041692558a4e0cba6b7e5f9b813be56402c3db820c06dd4a5f1) + +| Schema UID | `0x84260b9102b41041692558a4e0cba6b7e5f9b813be56402c3db820c06dd4a5f1` | +| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Issuer | Currently, the Optimism Foundation issues these from one of the following addresses: `0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9` or `0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F`. | +| Recipient | The address of the individual who made the contribution | +| refUID | The UID of the project, in case this contribution is represented as a project | +| FarcasterID | The id of the individual who made the contribution, if known | +| Impact | This field is not currently being used | +| Season | The season in which the contribution was made | +| Decision Module | The decision module to which the contribution relates | +| Contribution Type | The type of contribution | +| MetadataUrl | This field is not currently being used | + +### [Foundation Mission Request Completed](https://optimism.easscan.org/schema/view/0x649cc6df5af7561b66384405a62682c44e2428584d2f17a202ac3ef4506e2457) + +| Schema UID | `0x649cc6df5af7561b66384405a62682c44e2428584d2f17a202ac3ef4506e2457` | +| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Issuer | Currently, the Optimism Foundation issues these from one of the following addresses: `0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9` or `0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F`. | +| projectRefUID | The UID of the project that represents the work completed as part of the Foundation Mission Request | +| OP Amount | The OP Amount that was awarded for the completion of this Mission Request | +| Season | The season in which this Mission Request was completed | + +### [Retro funding governance contribution](https://optimism.easscan.org/schema/view/0x3743be2afa818ee40304516c153427be55931f238d961af5d98653a93192cdb3) | Schema UID | `0x3743be2afa818ee40304516c153427be55931f238d961af5d98653a93192cdb3` | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Issuer | Currently, the Optimism Foundation issues these from one of the following addresses: `0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9` or `0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F`. | -| Issuer | Currently, the Optimism Foundation issues these from one of the following addresses: `0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9` or `0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F` | | Recipient | The address of the individual who made the contribution | | Rpgf\_round | The round number for which this contribution was made | | RetroPGF\_Contribution | The type of contribution made | @@ -143,11 +165,11 @@ Issued to those who held governance roles in the Collective, such as Grants Coun | govSeason | The season the individual held the role | | govRole | The role held by the individual | -## Archived Schemas +## Archived schemas These schemas are no longer being actively issued, but capture valuable historical data. -### [Retro Funding Application](https://optimism.easscan.org/schema/view/0x88b62595c76fbcd261710d0930b5f1cc2e56758e155dea537f82bf0baadd9a32) +### [Retro funding application](https://optimism.easscan.org/schema/view/0x88b62595c76fbcd261710d0930b5f1cc2e56758e155dea537f82bf0baadd9a32) Used to identify a project's application to a specific Retro Funding Round. This attestation was used for Retro Funding Rounds 4 and 5. @@ -160,7 +182,7 @@ Used to identify a project's application to a specific Retro Funding Round. This | farcasterID | The individual that submitted this application on behalf of the project. | | metadataSnapshot RefUID | The project metadata at the time the application was submitted. | -### [Retro Funding Badgeholders](https://optimism.easscan.org/schema/view/0xfdcfdad2dbe7489e0ce56b260348b7f14e8365a8a325aef9834818c00d46b31b) +### [Retro funding badgeholders](https://optimism.easscan.org/schema/view/0xfdcfdad2dbe7489e0ce56b260348b7f14e8365a8a325aef9834818c00d46b31b) These attestations are considered "voting Badges" and allow an individual to vote in any given iteration of Retro Funding. They were used up to and including Retro Round 4. @@ -172,7 +194,7 @@ These attestations are considered "voting Badges" and allow an individual to vot | referredBy | In early rounds, new Badges were issued by referral. This field captures the address of the referrer, if there was one | | referredMethod | If this voting Badge was issued by referral, this field captures the referral method | -### [Project Identifier](https://optimism.easscan.org/schema/view/0x7ae9f4adabd9214049df72f58eceffc48c4a69e920882f5b06a6c69a3157e5bd) +### [Project identifier](https://optimism.easscan.org/schema/view/0x7ae9f4adabd9214049df72f58eceffc48c4a69e920882f5b06a6c69a3157e5bd) Used as the unique identifier for projects created in the Collective before 23 August 2024. Attestations issued from this schema prior to 23 August 2024 are still used as the unique identifier for projects. New projects created after 23 August 2024 use the new entity identifier (see above). @@ -188,7 +210,7 @@ Used as the unique identifier for projects created in the Collective before 23 A * **[Season 4 Co-grant participant schema UID](https://optimism.easscan.org/schema/view/0x401a80196f3805c57b00482ae2b575a9f270562b6b6de7711af9837f08fa0faf)**: `0x401a80196f3805c57b00482ae2b575a9f270562b6b6de7711af9837f08fa0faf`. Important: Remember to verify the attester address is `0x3C7820f2874b665AC7471f84f5cbd6E12871F4cC` or `0x2a0eB7cAE52B68e94FF6ab0bFcf0dF8EeEB624be` * **[Optimist Profile schema UID](https://optimism.easscan.org/schema/view/0xac4c92fc5c7babed88f78a917cdbcdc1c496a8f4ab2d5b2ec29402736b2cf929):** `​​0xac4c92fc5c7babed88f78a917cdbcdc1c496a8f4ab2d5b2ec29402736b2cf929` -## Next Steps +## Next steps * For more information on working with attestations, see [Build Decentralized Identity Apps with Attestations](/chain/identity/about-attestations). * To see a list of applications using EAS, see [Attestation Apps](/chain/identity/applications). diff --git a/pages/chain/networks.mdx b/pages/chain/networks.mdx index 3fc2c7369..a7e97799d 100644 --- a/pages/chain/networks.mdx +++ b/pages/chain/networks.mdx @@ -1,12 +1,12 @@ --- -title: OP Networks and Public RPC Endpoints +title: OP networks and public RPC endpoints lang: en-US description: Learn about the different OP networks and public RPC endpoints. --- import { Callout } from 'nextra/components' -# OP Networks and Public RPC Endpoints +# OP networks and public RPC endpoints This reference guide provides a listing of the different OP networks and public RPC endpoints. diff --git a/pages/chain/security/faq.mdx b/pages/chain/security/faq.mdx index b000bb446..002244cc8 100644 --- a/pages/chain/security/faq.mdx +++ b/pages/chain/security/faq.mdx @@ -1,24 +1,24 @@ --- -title: OP Mainnet Security Model +title: OP Mainnet security model lang: en-US description: Learn about the OP Mainnet security model and answers to common questions. --- import { Callout } from 'nextra/components' -# OP Mainnet Security Model +# OP Mainnet security model OP Mainnet is a work in progress. Constant, iterative improvement of the security mechanisms that safeguard OP Mainnet users is a top priority for the entire [Optimism Collective](https://community.optimism.io/docs/governance/). The Optimism Collective strives to be clear and transparent about the security of OP Mainnet and the OP Stack as a whole. -## Bottom Line +## Bottom line The security model of any blockchain system is only as strong as its lowest common denominator. At the moment, **it's important to understand that the security of OP Mainnet is dependent on a [multisig](https://etherscan.io/address/0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A)** managed jointly by the [Optimism Security Council](https://gov.optimism.io/t/intro-to-optimisms-security-council/6885) and the Optimism Foundation. OP Mainnet and the OP Stack in general **may also contain unknown bugs that could lead to the loss of some or all of the ETH or tokens held within the system**. -## OP Mainnet Multisig +## OP Mainnet multisig The security of OP Mainnet is currently dependent on a multisig managed jointly by the [Optimism Security Council](https://gov.optimism.io/t/intro-to-optimisms-security-council/6885) and the Optimism Foundation. This multisig is a [2-of-2 nested multisig](https://etherscan.io/address/0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A) which is in turn governed by a [10-of-13 multisig](https://etherscan.io/address/0xc2819DC788505Aac350142A7A707BF9D03E3Bd03) managed by the Optimism Security Council and a [5-of-7 multisig](https://etherscan.io/address/0x847B5c174615B1B7fDF770882256e2D3E95b9D92) managed by the Optimism Foundation. @@ -26,7 +26,7 @@ This multisig is a [2-of-2 nested multisig](https://etherscan.io/address/0x5a0Aa This multisig can be used to upgrade core OP Mainnet smart contracts **without upgrade delays** to allow for quick responses to potential security concerns. All upgrades to the OP Mainnet system must be approved by both component multisigs and either can veto an upgrade. -## Fault Proofs +## Fault proofs It is important to understand that **fault proofs are not a silver bullet** and that **fault proofs provide limited improvements to the security of a system if the system still has a multisig or security council that can instantly upgrade the system**. @@ -38,27 +38,27 @@ Withdrawals are proven against proposals about the state of OP Mainnet that are Proposals can be submitted to the `DisputeGameFactory` contract by any user and submissions do not require any special permissions. Each submitted proposal creates a [`FaultDisputeGame`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/dispute/FaultDisputeGame.sol) contract that allows any other user to challenge the validity of a proposal by participating in a "fault proof" process. -A more detailed explanation of the fault proof game can be found in the [Fault Proofs Explainer](/stack/protocol/fault-proofs/explainer). +A more detailed explanation of the fault proof game can be found in the [Fault Proofs Explainer](/stack/fault-proofs/explainer). Although the fault proof game is permissionless, the Optimism Security Council acting as the [Guardian](/chain/security/privileged-roles#guardian) role provides a backstop in case of a failure in the fault proof game. Each proposal must wait for a delay period during which the Guardian can prevent invalid proposals from being used to withdraw ETH or tokens through a number of safety hatches. The Guardian can also choose to shift the system to use a `PermissionedDisputeGame` in which only specific `PROPOSER` and `CHALLENGER` roles can submit and challenge proposals. -## Bugs and Unknowns +## Bugs and unknowns Please also keep in mind that just like any other system, **the Optimism codebase may contain unknown bugs** that could lead to the loss of some or all of the ETH or tokens held within the system. The OP Stack has been audited [on many occasions](https://github.com/ethereum-optimism/optimism/tree/v1.1.4/technical-documents/security-reviews), but **audits are not a stamp of approval** and **a completed audit does not mean that the audited codebase is free of bugs.** It's important to understand that using OP Mainnet inherently exposes you to the risk of bugs within the Optimism codebase, and that you use OP Mainnet at your own risk. -## Work in Progress +## Work in progress -### Sequencer Decentralization +### Sequencer decentralization The Optimism Foundation currently operates the sole sequencer on OP Mainnet. Although users can always bypass the Sequencer by sending transactions directly to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/5877ee24cc9aaef5848c1372e0e196707fb336a0/packages/contracts-bedrock/src/L1/OptimismPortal.sol) contract, sequencer decentralization can still help mitigate the effect of short-term outages for users. -## Security Model FAQ +## Security model FAQ ### Does OP Mainnet have fault proofs? diff --git a/pages/chain/security/security-policy.mdx b/pages/chain/security/security-policy.mdx index 3434d8664..85a776ff4 100644 --- a/pages/chain/security/security-policy.mdx +++ b/pages/chain/security/security-policy.mdx @@ -1,12 +1,12 @@ --- -title: Security Policy and Bug Bounty Program +title: Security policy and bug bounty program lang: en-US description: Learn about the bug bounty program and best practices for reporting bugs in OP Stack and OP Mainnet codebase. --- import { Callout } from 'nextra/components' -# Security Policy and Bug Bounty Program +# Security policy and bug bounty program This page describes general best practices for reporting bugs and provides specific reporting guidelines for OP Stack and OP Mainnet code contained within the [ethereum-optimism](https://github.com/ethereum-optimism) GitHub organization. @@ -17,24 +17,24 @@ This page describes general best practices for reporting bugs and provides speci * **Do not** test the vulnerability on a publicly available network, either the testnet or the mainnet. -## Optimism Bug Bounty Program +## Optimism bug bounty program The Optimism Bug Bounty Program offers up to [$2,000,042](https://immunefi.com/bounty/optimism/) for critical vulnerabilities found in the OP Mainnet codebase. Below you can find information about the various available bug bounty programs and how to report bugs that are not covered by an existing bounty. -### Main Bounty Page +### Main bounty page Optimism has a very detailed [Bug Bounty Page on Immunefi](https://immunefi.com/bounty/optimism/). In the listing you can find all the information relating to components in scope, reporting, and the payout process. -### Unscoped Bugs +### Unscoped bugs If you think you have found a significant bug or vulnerabilities in OP Stack smart contracts, infrastructure, etc., even if that component is not covered by an existing bug bounty, please report it to via the [OP Mainnet Immunefi program](https://immunefi.com/bounty/optimism/). The impact of any and all reported issues will be considered and the program has previously rewarded security researchers for bugs not within its stated scope. -## Reporting Other Vulnerabilities +## Reporting other vulnerabilities For vulnerabilities in any websites, email servers, or other non-critical infrastructure within the OP Stack, please contact the Foundation's service provider at [security@oplabs.co](mailto:security@oplabs.co) and include detailed instructions for confirming and reproducing the vulnerability. -### Vulnerability Disclosure +### Vulnerability disclosure Each OP Stack component maintainer may determine its own process for vulnerability disclosure. However, the following describes a recommended process for disclosure. @@ -46,7 +46,7 @@ In such a scenario, the disclosure process used is as follows: 2. After 4-8 weeks, disclose that release X contained a security fix. 3. After an additional 4-8 weeks, publish details of the vulnerability, along with credit to the reporter (with express permission from the reporter). -### Rights of Maintainers +### Rights of maintainers Alongside this policy, maintainers also reserve the right to: diff --git a/pages/chain/testing/dev-node.mdx b/pages/chain/testing/dev-node.mdx index 233bb1e18..477176e7d 100644 --- a/pages/chain/testing/dev-node.mdx +++ b/pages/chain/testing/dev-node.mdx @@ -1,12 +1,12 @@ --- -title: Running a Local Development Environment +title: Running a local development environment lang: en-US description: Learn how to setup and run a local development environment of the entire OP Mainnet system. --- import { Steps, Callout, Tabs } from 'nextra/components' -# Running a Local Development Environment +# Running a local development environment This tutorial teaches you how to setup and run a local development environment of the entire OP Mainnet system. @@ -39,7 +39,7 @@ Before you begin, ensure you have the following components installed on your sys - ### Ubuntu Installation + ### Ubuntu installation These instructions were verified on Ubuntu 22.04 LTS. Other versions may require slight modifications. @@ -54,7 +54,7 @@ Before you begin, ensure you have the following components installed on your sys - ### Mac Installation + ### Mac installation * [Install Homebrew]( https://brew.sh/) (if not already installed): @@ -107,7 +107,8 @@ After installation, you can verify Go is correctly installed by running: ## Operations * To start, run (in the root directory of the monorepo) `make devnet-up`.\ - The first time it runs it will be relatively slow because it needs to download the images, after that it will be faster. + The first time it runs it will be relatively slow because it needs to download the images, after that it will be faster.\ + After the devnet starts, the L2 RPC server will be available at `127.0.0.1:9545` and the L1 RPC server will be available at `127.0.0.1:8545`. * To stop, run (in the root directory of the monorepo) `make devnet-down`. diff --git a/pages/chain/testing/testing-apps.mdx b/pages/chain/testing/testing-apps.mdx index 86e9cd3e0..2eac879a2 100644 --- a/pages/chain/testing/testing-apps.mdx +++ b/pages/chain/testing/testing-apps.mdx @@ -1,10 +1,10 @@ --- -title: Testing Apps for OP Mainnet +title: Testing apps for OP Mainnet lang: en-US description: Learn best practices for OP Mainnet testing. --- -# Testing Apps for OP Mainnet +# Testing apps for OP Mainnet For the most part, running applications on OP Mainnet is identical to running them on Ethereum, so the testing is identical too. In this guide, you learn the best practices for OP Mainnet testing where there are differences. diff --git a/pages/chain/tokenlist.mdx b/pages/chain/tokenlist.mdx index 4b590e43c..ac2301614 100644 --- a/pages/chain/tokenlist.mdx +++ b/pages/chain/tokenlist.mdx @@ -1,5 +1,5 @@ --- -title: Bridged Token Addresses +title: Bridged token addresses lang: en-US description: This reference guide lists the correct bridged token addresses for each token. --- @@ -7,7 +7,7 @@ description: This reference guide lists the correct bridged token addresses for import { Callout } from 'nextra/components' import { TokenListTable } from '@/components/TokenListTable' -# Bridged Token Addresses +# Bridged token addresses Various ERC-20 tokens originally deployed to Ethereum also have corresponding "bridged" representations on OP Mainnet. The [Superchain Token List](https://github.com/ethereum-optimism/ethereum-optimism.github.io) exists to help users discover the correct bridged token addresses for each token. diff --git a/pages/connect/contribute/docs-contribute.mdx b/pages/connect/contribute/docs-contribute.mdx index bfe48b94d..d29189de3 100644 --- a/pages/connect/contribute/docs-contribute.mdx +++ b/pages/connect/contribute/docs-contribute.mdx @@ -1,5 +1,5 @@ --- -title: Ways to Contribute to Optimism Docs +title: Ways to contribute to Optimism Docs lang: en-US description: Learn about the different ways you can contribute to Optimism Docs. --- @@ -89,6 +89,6 @@ We use GitPOAPs to recognize our contributors! GitPOAP automatically recognizes You should only use self-custody wallets to claim POAPs. Do not use exchange accounts or other accounts you do not hold the private keys to, as these will not allow you to access and manage your POAPs. -## Still Have Questions? +## Still have questions? You can reach us in our developer support [forum](https://github.com/ethereum-optimism/developers/discussions). We look forward to growing the Collective with you! diff --git a/pages/connect/contribute/stack-contribute.mdx b/pages/connect/contribute/stack-contribute.mdx index 159cdc5aa..22fec79f0 100644 --- a/pages/connect/contribute/stack-contribute.mdx +++ b/pages/connect/contribute/stack-contribute.mdx @@ -14,12 +14,12 @@ The Optimism Collective wins when it works together. ♥️✨ Whether you're a budding chain operator, app developer, node operator, bounty hunter, content creator, or anything in between, the OP Stack always has something for you to contribute to. Every contribution makes a difference — no contribution is too small. If you're ready to contribute, check out one of the following contributor pathways below. -## Component Contributions +## Component contributions The OP Stack is a decentralized development stack and is constantly evolving as new layers and modules are developed. Anyone can contribute components that can be considered part of the OP Stack as long as those components fit the stack's [design principles and goals](/stack/design-principles). To start contributing components to the stack, check out some of these [useful ideas](https://github.com/ethereum-optimism/ecosystem-contributions) and get to building! And don't forget that projects can also receive grants from the Collective via [RetroPGF](https://community.optimism.io/docs/citizen-house/how-retro-funding-works/). -## Codebase Contributions +## Codebase contributions The OP Stack codebase is not a product (in the traditional sense) but rather a collection of software components that power the Optimism ecosystem. If you'd like to contribute to the current release of OP Stack codebase, rather than creating new components, your contribution would be greatly appreciated. @@ -33,15 +33,15 @@ To make your first contribution to the codebase, check out the [open issues](htt Developer support for OP Stack Hacks is limited — when in doubt, stick to the capabilities of the current release! -## Bounty Hunting +## Bounty hunting The OP Stack needs YOU (yes you!) to help review the codebase for bugs and vulnerabilities. If you're interested in bounty hunting, check out our [Security Policy, Vulnerability Reporting, and Bug Bounties page](/chain/security/security-policy). -## Docs Contributions +## Docs contributions Want a new tutorial? See something that could be a little clearer? Check out the [Optimism Docs Contribution page](docs-contribute) for more information on how to help. No contribution is too small! -## Community Contributions +## Community contributions If you're looking for other ways to get involved, here are a few options: diff --git a/pages/connect/contribute/style-guide.mdx b/pages/connect/contribute/style-guide.mdx index ddeead204..786ddee81 100644 --- a/pages/connect/contribute/style-guide.mdx +++ b/pages/connect/contribute/style-guide.mdx @@ -1,5 +1,5 @@ --- -title: Optimism Docs Style Guide +title: Optimism Docs style guide lang: en-US description: This guide explains how to write technical content for Optimism Docs using a consistent voice, tone, and style. --- @@ -97,7 +97,7 @@ See below for when to use title or sentence case. When creating content, ensure it is accessible to screen-reader users, visually impaired individuals, and those using a mouse or keyboard. For more information regarding accessibility guidelines, see [W3C Web Content Accessibility Guidelines 2.0](http://www.w3.org/TR/UNDERSTANDING-WCAG20/Overview.html#contents). -### Alt-Text +### Alt-text * Provide alt text for all images so that the screen reader can interpret the purpose of the image and convey that to the user. The alt text should include any content shown in the image so that screen reader can read it to the user. * Provide alt text for videos by modifying the title attribute of any embedded video content or iframe. The title attribute serves as the alt text for screen readers to provide descriptive information. Video content with speaking or narration must include closed captions. @@ -175,7 +175,7 @@ We aim to use consistent organization that is also user-centered and accessible. * H4 headings are reserved (at this time) for glossary terms. This standardization will make it easier for us to extend glossary functionality across the docs in the future, such as tool tips. -### Listing prerequisites (Before you begin) +### Listing prerequisites (before you begin) * Add a "Before You Begin" section at the top of the document if there are tasks a user needs to complete before continuing with the current task, e.g. installing a module, downloading a software update, etc. * Use the title "Before You Begin"and format as H2. It should follow the page overview/intro section or table of contents. @@ -298,7 +298,7 @@ Developers trust that we will lead them to sites or pages related to their readi * Use absolute or relative links when linking across pages in the site. Absolute links are cleaner and easier to work with when pages are nested, so they are the recommended option. - **Examples**: absolute link `(/protocol/deposit-flow)` versus relative link `(../../protocol/deposit-flow)` + **Examples**: absolute link `(/stack/transactions/deposit-flow)` versus relative link `(../../protocol/deposit-flow)` * Use the exact title of the page when linking to it in a sentence, whenever possible, and display it in title case. The link should use default styling with no other formatting (bold, italics, quotations). diff --git a/pages/connect/resources/glossary.mdx b/pages/connect/resources/glossary.mdx index 22a920398..9261933f2 100644 --- a/pages/connect/resources/glossary.mdx +++ b/pages/connect/resources/glossary.mdx @@ -10,16 +10,16 @@ import { Callout } from 'nextra/components' The glossary provides definitions of important terminology used throughout the Optimism 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). -## Table of Contents +## Table of contents * [General Terms](#general-terms) * [OP Profile & Identity](#op-profile--identity) * [OP Stack & OP Superchain](#op-stack--op-superchain) * [Protocol](#protocol) -## General Terms +## General terms -#### Address Aliasing +#### Address aliasing When a contract submits a [deposit](#deposit) from L1 to L2, it's address (as returned by `ORIGIN` and `CALLER`) will be aliased with a modified representation of the address of a contract. @@ -30,7 +30,7 @@ A sequential list of transactions, along with a couple of properties stored in t It is useful to distinguish between input block properties, which are known before executing the transactions in the block, and output block properties, which are derived after executing the block's transactions (e.g., [Merkle Patricia Trie roots](#merkle-patricia-trie)). -#### Block Time +#### Block time L2 block time is 2 seconds, meaning there is an L2 block at every 2s [time slot](#time-slot). *Post-merge*, it could be said the that L1 block time is 12s as that is the L1 [time slot](#time-slot). However, in @@ -43,11 +43,11 @@ Delegates are individuals who have volunteered to actively participate in the go By delegating your voting power, you enable these delegates to vote on governance matters on your behalf, while you retain full ownership of your tokens and the freedom to use them as you wish. You can also change your chosen delegate at any time, allowing for flexibility in how your voting power is represented in the governance process. -#### EOA or Externally Owned Account +#### EOA or externally owned account Ethereum term to designate addresses operated by users, as opposed to contract addresses. -#### Execution Engine +#### Execution engine Responsible for executing transactions in blocks and computing the resulting state roots, receipts roots, and block hash. Both L1 (*post-merge*) and L2 have an execution engine. On L1, the executed blocks can @@ -55,14 +55,14 @@ come from L1 block synchronization or from a block freshly minted by the executi at the request of the L1 consensus layer. On L2, the executed blocks are freshly minted by the execution engine at the request of the [rollup node](#rollup-node), using transactions [derived from L1 blocks](#l2-chain-derivation). -#### Optimism Collective +#### Optimism collective The Optimism Collective is a band of people, projects, and companies working together to build a better economy for everyone, united by a mutually beneficial pact to adhere to the axiom of impact=profit — the principle that positive impact to the collective should be rewarded with profit to the individual. New model of digital democratic governance optimized to drive rapid and sustained growth of a decentralized ecosystem. -#### OP Token +#### OP token A governance token, referred to as "OP." Content should not discuss the token price or speculate on the price, and content that refers to OP incorrectly will be removed from Optimism platforms and will not be eligible for promotion. @@ -74,19 +74,19 @@ Refers the Ethereum blockchain, used in contrast to [layer 2](#layer-2-l2), whic Refers to the Optimism blockchain and is used in contrast to [layer 1](#layer-1-l1), which refers to the Ethereum blockchain. -#### L2 Output Root +#### L2 output root 32 byte value which serves as a commitment to the current state of the L2 chain. -#### L2 Output Oracle Contract +#### L2 output oracle contract L1 contract to which [L2 output roots](#l2-output-root) are posted by the [sequencer](#sequencer). -#### Predeployed Contract +#### Predeployed contract A contract placed in the L2 genesis state (i.e. at the start of the chain). -#### PGA or Priority Gas Auction +#### PGA or priority gas auction Transactions in ethereum are ordered by the price that the transaction pays to the miner. Priority Gas Auctions (PGAs) occur when multiple parties are competing to be the first transaction in a block. Each party continuously @@ -113,7 +113,7 @@ The rollup node receives L2 transactions from users, which it uses to create L2 then submitted to a [data availability provider](#data-availability-provider) via [batch submission](#batch-submission). The L2 chain derivation then acts as a sanity check and a way to detect L1 chain re-orgs. -#### Time Slot +#### Time slot On L2, there is a block every 2 second (this duration is known as the [block time](#block-time)). We say that there is a "time slot" every multiple of 2s after the timestamp of the [L2 genesis block](#l2-genesis-block). @@ -140,7 +140,7 @@ behavior. A rollup node running in validator mode is sometimes called *a replica \[[return to top](#table-of-contents)] -## OP Profile & Identity +## OP profile & identity #### Attestations @@ -167,7 +167,7 @@ A system that enables individuals to have greater control and ownership over the In decentralized identity, personal information is stored on a blockchain or other decentralized system, and individuals have the ability to grant or revoke access to their data as they see fit. This allows for greater privacy, security, and control over personal information. -#### Ethereum Attestation Service (EAS) +#### Ethereum attestation service (EAS) An Ethereum infrastructure public good for making attestations on or off-chain about anything. @@ -183,19 +183,19 @@ A decentralized model used to establish trust among participants in a network. I ## OP Stack & OP Superchain -#### Attestation-Based Fault Proof +#### Attestation-based fault proof A fault proof where challenges can be successfully made by supplying an [attestation proof](#attestation-proof) which disagrees with the original withdrawal claim. -#### Attestation-Based Validity Proof +#### Attestation-based validity proof A validity proof which can be verified by supplying an [attestation proof](#attestation-proof) which agrees with the withdrawal claim. -#### Attestation Proof +#### Attestation proof A proof which consists of some number of signatures from a pre-agreed upon set of chain attestors. -#### Cannon Fault Proof +#### Cannon fault proof A fault proof where challenges are evaluated using an onchain game which is guaranteed to result in a truthful outcome, given economic rationality assumptions. @@ -203,33 +203,33 @@ A fault proof where challenges are evaluated using an onchain game which is guar A state [transition system](https://en.wikipedia.org/wiki/Transition_system) consisting of an initial state, a state transition function, and a list of inputs (transactions)—which is cryptographically committed to and can be independently replicated with commodity computer hardware and internet connection. -#### Chain Proof +#### Chain proof Difficult to forge evidence of the validity of a particular withdrawal claim. Proofs are commonly used to enable chains to communicate with each other. -#### Challenge Period +#### Challenge period The window of time in which a challenge can be made to disprove a fault proof. -#### Fault Proof +#### Fault proof A proof which relies on the absence of counter-evidence to prove correctness. -#### L1 Origin +#### L1 origin the L1 origin of an L2 block is the L1 block corresponding to its [sequencing epoch](#sequencing-epoch). -#### Merkle Patricia Trie +#### Merkle patricia trie sparse [trie](https://en.wikipedia.org/wiki/Trie), which is a tree-like structure that maps keys to values. The root hash of a MPT is a commitment to the contents of the tree, which allows a proof to be constructed for any key-value mapping encoded in the tree. Such a proof is called a Merkle proof, and can be verified against the Merkle root. -#### Modular Proof +#### Modular proof The ability to use multiple proof systems for the same OP Chain. For instance, it should be possible to prove an OP Chain using a fault proof or a validity proof. -#### Modular Sequencing +#### Modular sequencing The ability to configure the sequencer address during OP Chain deployment. This value can be configured by the OP Chain deployer. diff --git a/pages/stack/_meta.json b/pages/stack/_meta.json index e2e98fa27..47b2dd20d 100644 --- a/pages/stack/_meta.json +++ b/pages/stack/_meta.json @@ -1,17 +1,20 @@ { "getting-started": "Getting Started: OP Stack", "differences": "Differences Between Ethereum and OP Stack Chains", - "components": "OP Stack Components", - "smart-contracts": "Smart Contracts", "explainer": "Superchain Explainer", "design-principles": "Design Philosophy & Principles", - "protocol": "Protocol", + "components": "OP Stack Components", + "smart-contracts": "Smart Contracts", + "rollup": "Rollup", + "fault-proofs": "Fault Proofs", "transactions": "Transactions", + "features": "Features", "security": "Security", - "operators": "Operators", "--- Experimental": { "title": "Experimental", "type": "separator" }, - "opcm": "OP Contracts Manager" + "opcm": "OP Contracts Manager", + "interop": "Interoperability", + "beta-features": "Beta Features" } diff --git a/pages/stack/protocol/features/_meta.json b/pages/stack/beta-features/_meta.json similarity index 97% rename from pages/stack/protocol/features/_meta.json rename to pages/stack/beta-features/_meta.json index bcc657416..22af59364 100644 --- a/pages/stack/protocol/features/_meta.json +++ b/pages/stack/beta-features/_meta.json @@ -1,4 +1,4 @@ { "custom-gas-token": "Custom Gas Token", "alt-da-mode": "Alt-DA Mode" -} \ No newline at end of file +} diff --git a/pages/stack/protocol/features/alt-da-mode.mdx b/pages/stack/beta-features/alt-da-mode.mdx similarity index 97% rename from pages/stack/protocol/features/alt-da-mode.mdx rename to pages/stack/beta-features/alt-da-mode.mdx index 122650d9d..446afe4d8 100644 --- a/pages/stack/protocol/features/alt-da-mode.mdx +++ b/pages/stack/beta-features/alt-da-mode.mdx @@ -1,5 +1,5 @@ --- -title: Alt-DA Mode Explainer +title: Alt-DA Mode explainer lang: en-US description: Learn the basic process, benefits, and considerations for running an Alt-DA mode chain. --- @@ -14,19 +14,19 @@ import { AltCallout } from '@/components/WipCallout' 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 +## 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 +## 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 +## 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: @@ -39,7 +39,7 @@ Just like with the Rollup configuration of the OP Stack, core contributors are c 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 +## 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). diff --git a/pages/stack/protocol/features/custom-gas-token.mdx b/pages/stack/beta-features/custom-gas-token.mdx similarity index 96% rename from pages/stack/protocol/features/custom-gas-token.mdx rename to pages/stack/beta-features/custom-gas-token.mdx index b673f6dd0..9065976c7 100644 --- a/pages/stack/protocol/features/custom-gas-token.mdx +++ b/pages/stack/beta-features/custom-gas-token.mdx @@ -1,12 +1,15 @@ --- -title: Custom Gas Token Explainer +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 + + +# 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: @@ -15,7 +18,7 @@ The Custom Gas Token configuration lets OP Stack chain operators deploy their ch * 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 +## 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. @@ -32,7 +35,7 @@ When deposited, this L1 ERC-20 token will become the native gas token on the L2 * 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 +## How it works This is the general flow of how custom gas tokens work on the OP Stack: @@ -66,7 +69,7 @@ The custom token being used must adhere to the following constraints to be able -## Next Steps +## 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). diff --git a/pages/stack/components.mdx b/pages/stack/components.mdx index a6228362e..fb3ad07f6 100644 --- a/pages/stack/components.mdx +++ b/pages/stack/components.mdx @@ -1,12 +1,12 @@ --- -title: OP Stack Components +title: OP Stack components lang: en-US description: Learn about OP Stack components including the different layers and modules available for development. --- import { Callout } from 'nextra/components' -# OP Stack Components +# OP Stack components **The OP Stack is a common development stack for building L2 blockchain ecosystems, built by the Optimism Collective to power Optimism.** @@ -22,7 +22,7 @@ This doesn't include all of the modules or layers that may exist in the future, ## Layers -### Data Availability +### Data availability The Data Availability Layer defines where the raw inputs to an OP Stack based chain are published. An OP Stack chain can use a single Data Availability module to source its input data. Because an OP Stack chain is derived from the Data Availability Layer, the Data Availability module used has a significant impact on the security model of a system. For example, if a certain piece of data can no longer be retrieved from the Data Availability Layer, it may not be possible to sync the chain. @@ -37,11 +37,11 @@ Ethereum DA is currently the most widely used Data Availability module for the O The Sequencing Layer determines how user transactions on an OP Stack chain are collected and published to the Data Availability Layer module(s) in use. In the default Rollup configuration of the OP Stack, Sequencing is typically handled by a single dedicated Sequencer. Rules defined in the Derivation Layer generally restrict the Sequencer's ability to withhold transactions for more than a specific period of time. In the future, Sequencing will be modular such that chains can easily select and change the mechanism that controls their current Sequencer. -#### Single Sequencer +#### Single sequencer The default Sequencer module for the OP Stack is the Single Sequencer module in which a dedicated actor is given the ability to act as the Sequencer. The Single Sequencer module allows a governance mechanism to determine who may act as the Sequencer at any given time. -#### Multiple Sequencer +#### Multiple sequencer A simple modification to the Single Sequencer module is the Multiple Sequencer module in which the Sequencer at any given time is selected from a pre-defined set of possible actors. Individual OP Stack based chains would be able to determine the exact mechanism that defines the set of possible Sequencers and the mechanism that selects a Sequencer from the set. @@ -71,7 +71,7 @@ The EVM is an Execution Layer module that uses the same state representation and * [Specifications](https://specs.optimism.io/protocol/exec-engine.html) (where it differs from [geth](https://geth.ethereum.org/)) * [Source code](https://github.com/ethereum-optimism/op-geth/tree/09ade3df6d1d3a4f8f308553825348be132bc960) -### Settlement Layer +### Settlement layer The Settlement Layer is a mechanism on external blockchains that establish a **view** of the state of an OP Stack chain (target) on those external, third-party chains (including other OP Stack chains). For each target chain, there may be one or more Settlement mechanisms on one or more external chains. Settlement Layer mechanisms are **read-only** and allow a third-party chain to make decisions, potentially impacting their own state, based on the state of the target OP Stack chain. @@ -79,7 +79,7 @@ The term "Settlement Layer" has its origins in the fact that Settlement Layer me Once a transaction is published and finalized on the corresponding Data Availability layer, the transaction is also finalized on the OP Stack chain. Short of breaking the underlying Data Availability layer, it can no longer be modified or removed. It may not be accepted by the Settlement Layer yet because the Settlement Layer needs to be able to verify transaction *results*, but the transaction itself is already immutable. -#### Attestation-based Fault Proof +#### Attestation-based fault proof An Attestation-based Fault Proof mechanism uses an optimistic protocol to establish a view of an OP Stack chain. In optimistic settlement mechanisms generally, **Proposer** entities can propose what they believe to be the current valid state of the OP Stack chain. If these proposals are not invalidated within a certain period of time (the "challenge period"), then the proposals are assumed by the mechanism to be correct. In the Attestation Proof mechanism in particular, a proposal can be invalidated if some threshold of pre-defined parties provide attestations to a valid state that is different than the state in the proposal. This places a trust assumption on the honesty of at least a threshold number of the pre-defined participants. @@ -98,10 +98,10 @@ A Validity Proof Settlement mechanism uses a mathematical proof to attest to the The Governance Layer refers to the general set of tools and processes used to manage system configuration, upgrades, and design decisions. This is a relatively abstract layer that can contain a wide range of mechanisms on a target OP Stack chain and on third-party chains that impact many of the other layers of the OP Stack. -#### MultiSig Contracts +#### MultiSig contracts MultiSig Contracts are smart contracts that carry out actions when they receive a threshold of signatures from some pre-defined set of participants. These are often used to manage upgrades of components of an OP Stack based system. Currently, this is the mechanism used to manage upgrades of the bridge contracts on OP Mainnet. The security of a MultiSig Contract system depends on many different factors, including the number of participants, the threshold, and the safety procedures of each individual participant. -#### Governance Tokens +#### Governance tokens Governance Tokens are widely used to decentralize decision making. Although the exact functionality of a Governance Token varies on a case-by-case basis, the most common mechanisms allow token holders to vote on some subset of decisions that a project must make. Voting can either be carried out directly or via delegation. diff --git a/pages/stack/design-principles.mdx b/pages/stack/design-principles.mdx index 3ad07f00c..d18a01b23 100644 --- a/pages/stack/design-principles.mdx +++ b/pages/stack/design-principles.mdx @@ -1,16 +1,16 @@ --- -title: Design Philosophy & Design Principles +title: Design philosophy & design principles lang: en-US description: Learn the design philosophy and design principles for contributing to the OP Stack. --- import { Callout } from 'nextra/components' -# Design Philosophy & Design Principles +# Design philosophy & design principles This guide covers design philosophy and design principles for contributing to the OP Stack. -## Design Philosophy +## Design philosophy OP Stack is built according to a strong design philosophy that stands on four main pillars: **simplicity**, **pragmatism**, **sustainability**, and, of course, **optimism**. It's important to understand these pillars as they heavily influence the design of Optimism as a whole. @@ -69,7 +69,7 @@ We keep this in mind whenever we're creating new features or trying to simplify Optimism is as close to Ethereum as possible not only for pragmatic reasons, but because Optimism exists so that Ethereum can succeed. We hope that you can see the influence of this philosophy when looking at Optimism's design. -## Design Principles for USEful Software +## Design principles for USEful software The OP Stack is USEful software. The OP Stack is a set of software components for building L2 blockchain ecosystems, built by the Optimism Collective to power Optimism. Components to be added to the OP Stack should be built according to three key design principles: **U**tility, **S**implicity, **E**xtensibility. diff --git a/pages/stack/differences.mdx b/pages/stack/differences.mdx index ec6ec411f..85e10a265 100644 --- a/pages/stack/differences.mdx +++ b/pages/stack/differences.mdx @@ -20,7 +20,7 @@ However, there are some minor differences between the behavior of Ethereum and O | `ORIGIN` | `tx.origin` | If the transaction is an L1 ⇒ L2 transaction triggered by a smart contract on L1, then `tx.origin` is set to the [aliased address](#address-aliasing) of the address that triggered the L1 ⇒ L2 transaction. Otherwise, this opcode behaves normally. | | `CALLER` | `msg.sender` | If the transaction is an L1 ⇒ L2 transaction triggered by a smart contract on L1, and this is the first call frame (rather than an internal transaction from one contract to another), the same [address aliasing](#address-aliasing) behavior applies. | -### Address Aliasing +### Address aliasing Address aliasing is an important security feature that impacts the behavior of transactions sent from L1 to L2 by smart contracts. @@ -50,7 +50,7 @@ In all other cases, the transaction sender address is set according to the same ## Transactions -### Transaction Fees +### Transaction fees Transactions on OP Stack chains must pay for an [L1 data fee](/stack/transactions/fees#the-l1-data-fee) on top of the standard [execution gas fee](/stack/transactions/fees#execution-gas-fee) you would expect on Ethereum. Refer to the guide on [OP Stack Transaction Fees](/stack/transactions/fees) for more information. @@ -60,7 +60,7 @@ Refer to the guide on [OP Stack Transaction Fees](/stack/transactions/fees) for The base fee on OP Stack is, like Ethereum, computed via the [EIP-1559](https://notes.ethereum.org/@vbuterin/eip-1559-faq) mechanism. The EIP-1559 parameters used by OP Stack differ per chain. -### Mempool Rules +### Mempool rules By default, OP Stack chains do not have a large public mempool like Ethereum. OP Stack mempools are typically only visible to the Sequencer of the given chain and transactions are generally executed in priority fee order (highest fee first). diff --git a/pages/stack/explainer.mdx b/pages/stack/explainer.mdx index 888807a9d..7390e26ee 100644 --- a/pages/stack/explainer.mdx +++ b/pages/stack/explainer.mdx @@ -1,12 +1,12 @@ --- -title: Superchain Explainer +title: Superchain explainer lang: en-US description: Learn about Optimism Superchain components, features, and roadmap. --- import { Callout } from 'nextra/components' -# Superchain Explainer +# Superchain explainer Stay up to date on the Superchain and the OP Stack by subscribing to the [Optimism Developer Blog](https://blog.oplabs.co/) @@ -22,7 +22,7 @@ This is the detailed explanation. [Click here for a less technical introduction] Today, the Superchain is a concept and in-flight project, not a concrete reality. This documentation represents our best current guess as to what the Superchain's components, features, and roadmap will be. Ultimately, its actualization will depend on (and change alongside) contributions from across the entire Optimism Collective. We cannot wait to see where it goes. -## The Scalability Vision +## The scalability vision ### Blockchain tech today is insufficient for the decentralized web @@ -54,7 +54,7 @@ This hypothetical isn't a dream, it's a tangible vision for the future which has With the support of the industry, we think a clear picture for how to architect a truly scalable blockchain is beginning to come into view. We call it the "Superchain". This document lays out the core technical principles underlying the Superchain architecture, as well as a set of tangible projects which, when complete, we believe will finally realize the blockchain scalability vision. It will be a multi-year (if not decade) journey. However, if we know roughly where we're going, we'll get there a little faster. -## Foundational Superchain Concepts +## Foundational Superchain concepts ### Horizontal scalability requires multiple chains… @@ -85,7 +85,7 @@ By using L2 chains to comprise the multi-chain ecosystem, it becomes possible to A decentralized blockchain platform which consists of many chains that share security and a technology stack (OP Stack). The interoperability and standardization enables individual chains to be treated identically by tools and wallets. -## Superchain Overview +## Superchain overview ### The Superchain at a glance @@ -113,7 +113,7 @@ In order for Optimism to upgrade to a Superchain, it must have the following pro Once Optimism has satisfied these properties, it may be considered a Superchain. -## Upgrading Optimism to Become a Superchain +## Upgrading Optimism to become a Superchain We believe the following changes (after the Bedrock release) are required to create an initial Superchain that makes it possible to deploy and upgrade many chains with the same bridge: @@ -217,9 +217,9 @@ If each one of these pain points were addressed, it could be possible to build d The following is an overview of potential future enhancements, which when combined, addresses each one of these pain points. -### Multi-Proof Security +### Multi-proof security -#### Pain Point: +#### Pain point: 1. Withdrawal claims rely on a trusted set of chain attestors. @@ -227,13 +227,13 @@ The following is an overview of potential future enhancements, which when combin It is possible to replace the trusted set of chain attestors by introducing permissionless proofs—such as Cannon—where dispute resolution is entirely onchain. However, the challenge with entirely onchain proofs is there is no fallback mechanism if they were to break. To ensure that they will never fail, it is possible to introduce a multi-proof system which provides safety through redundancy. For more information on the multi-proof design click [here](https://web.archive.org/web/20230331065342/https://medium.com/ethereum-optimism/our-pragmatic-path-to-decentralization-cb5805ca43c1). -### Low Latency L2 to L2 Message Passing +### Low latency L2 to L2 message passing -#### Pain Point: +#### Pain point: 2. Cross-chain transactions are slow because they require waiting a challenge period. -#### Proposed Solution: +#### Proposed solution: Fault proofs introduce a UX burden because they require waiting a challenge period in order to safely finalize. This means that, depending on the length of your challenge period, users may need to wait a long time before their ETH and tokens are migrated from one OP Chain to the next. @@ -250,13 +250,13 @@ This heterogeneous bridging system means that developers can build their applica Mixing multiple proof systems enables developers to provide low-latency bridging for low value state and high-latency for high value state. It is even possible to turn low-security state which was instantly bridged into high-security state by proving the state's validity using a high-security high-latency bridge. This building block enables developers to make interesting security tradeoffs such as using a high threshold attestation proof with a high-security, high-latency fault proof fallback. -### Synchronous Cross-Chain Transactions +### Synchronous cross-chain transactions -#### Pain Point: +#### Pain point: 3. Cross-chain transactions are asynchronous, breaking the ability to perform atomic cross-chain transactions (like flash loans). -#### Proposed Solution: +#### Proposed solution: Traditional cross-chain messaging is done asynchronously, which means that cross-chain transactions are *not* atomic. For example, if a user would like to execute a cross-chain arbitrage transaction—buying token A on chain A, and selling token B on chain B—there is no guarantee that their transaction executes in its entirety. The user might end up buying token A without having sold token B. @@ -264,13 +264,13 @@ It is possible to introduce synchronous cross-chain messaging and enable atomic With the combination of low-latency L2 to L2 message passing as well as shared sequencing, it is possible to perform complex transactions such as cross-chain flash loans. It is even possible to go further and create an EVM abstraction where individual smart contracts (or even individual storage slots) exist on different chains. -### Alt-Data Availability Layer — Plasma Protocol +### Alt-Data availability layer — Plasma Protocol -#### Pain Point: +#### Pain point: 4. Posting transactions to the Superchain is not-scalable because the transaction data must be submitted to L1 which has limited capacity. -#### Proposed Solution: +#### Proposed solution: Today L1 data availability (DA) does not scale nearly enough to be able to support internet-level scale. However, it is possible to extend the amount of data availability accessible to OP Chains by using a Plasma protocol which enables alternative DA providers to supplement the more limited L1 DA. @@ -294,15 +294,15 @@ A generic Plasma protocol is able to scale beyond what is possible on L1 because Because of the ability for hashes to reduce arbitrary size data into a constant size commitment, and the ability to parallelize transaction data hashing, it is possible to achieve near-perfect horizontal scalability of data commitments using Plasma DA. This means that it is possible to put massively scalable applications such as games or social media on Plasma chains. -### Multi-Chain App Frameworks +### Multi-chain app frameworks -#### Pain Points: +#### Pain points: 5. There are no easy-to-use frameworks for building scalable apps which utilize many OP Chains. 6. There is no easy-to-use wallet for managing ETH and tokens and apps across many OP Chains. -#### Proposed Solution (Sketch): +#### Proposed solution (Sketch): This is not a core protocol change, but instead tooling which can be built on top of the core Superchain protocols. The suggestions here are intended to give rough intuitions for how to build tools which improve the experience of deploying to the Superchain. @@ -320,7 +320,7 @@ These are some tools which could make developing on the Superchain a better expe With robust multi-chain app frameworks, it may become as easy to deploy cross-chain apps as it is to deploy apps which target a single chain. -## Get Involved +## Get involved We believe scaling blockchains will radically decentralize the internet and make it easy to create horizontally scalable, secure, and decentralized web applications. We think the Superchain release of the OP Stack could mark a major step towards realizing this vision. However, after the release, it will still take an enormous amount of work to realize the scalability vision. diff --git a/pages/stack/protocol/fault-proofs/_meta.json b/pages/stack/fault-proofs/_meta.json similarity index 100% rename from pages/stack/protocol/fault-proofs/_meta.json rename to pages/stack/fault-proofs/_meta.json diff --git a/pages/stack/protocol/fault-proofs/cannon.mdx b/pages/stack/fault-proofs/cannon.mdx similarity index 98% rename from pages/stack/protocol/fault-proofs/cannon.mdx rename to pages/stack/fault-proofs/cannon.mdx index 4a86b4ce6..4ad45ea78 100644 --- a/pages/stack/protocol/fault-proofs/cannon.mdx +++ b/pages/stack/fault-proofs/cannon.mdx @@ -1,5 +1,5 @@ --- -title: Fault Proof VM - Cannon +title: Fault proof VM - Cannon lang: en-US description: Learn about Cannon and its default operation as part of Optimism's Fault Proof Virtual Machine. --- @@ -7,7 +7,7 @@ description: Learn about Cannon and its default operation as part of Optimism's import Image from 'next/image' import { Callout } from 'nextra/components' -# Fault Proof VM: Cannon +# Fault proof VM: Cannon Cannon is an instance of a Fault Proof Virtual Machine (FPVM) that can be used as part of the Dispute Game for any OP Stack Blockchain. The Dispute Game itself is modular, allowing for any FPVM to be used in a dispute. @@ -23,7 +23,7 @@ Additionally, we will explore the differences between Cannon and the onchain `MI implementation, please refer to [MIPS reference](mips). Now for simplicity, when referring to Cannon in this documentation, we are referring to the offchain implementation. -## Control Flow +## Control flow ![Fault Proof Control Flow.](/img/op-stack/protocol/fault-proof-control-flow.svg) @@ -35,7 +35,7 @@ single L2 block state transition that they disagree on. ### OP-Challenger \<> Cannon -Once an active fault dispute game reaches a depth below attacking / defending L2 block state transitions, [OP-Challenger](/stack/protocol/fault-proofs/challenger) will run +Once an active fault dispute game reaches a depth below attacking / defending L2 block state transitions, [OP-Challenger](/stack/fault-proofs/challenger) will run Cannon to begin processing MIPS instructions within the FPVM. As part of processing MIPS instructions, Cannon will generate state witness hashes, which are the commitment to the results of the MIPS instructions' computation within the FPVM. Now, in the bisection game, OP-Challenger will provide the generated hashes until a single MIPS instruction is identified as the root disagreement between participants in the active dispute. Cannon will then @@ -55,7 +55,7 @@ same inputs will produce not only the same outputs, but the same execution trace OP-Program such that, given the same L2 output root state transition, can generate the same execution traces. This in turn generates the same witness proof for the exact same MIPS instruction that will be run onchain. -## Overview of Offchain Cannon components +## Overview of offchain Cannon components Now, we will go over each major component that makes up Cannon. Components are grouped by what functionality is being performed for Cannon, and may be correlated to one or more Go files. For brevity, each Go file will be explained at a high level, with the @@ -63,7 +63,7 @@ most important features / considerations highlighted. ![Cannon Components Overview.](/img/op-stack/protocol/cannon-internal-overview.svg) -### `mipsevm` State and Memory +### `mipsevm` state and memory As mentioned previously, the `mipsevm` is 32-bit, which means the full addressable address range is `[0, 2^32-1]`. The memory layout uses the typical monolithic memory structure, and the VM operates as though it were interacting directly with physical memory. @@ -114,7 +114,7 @@ The information stored is largely identical to the [VM execution state](mips#pac * Instead of storing just the memory Merkle root, there is a `Memory` Struct pointer for the binary Merkle tree representation of the entire 32-bit memory space. * There is an optional `LastHint` bytes variable, which can be used to communicate a Pre-image hint to avoid having to load in multiple prior Pre-images. -#### Generating the Witness Proof +#### Generating the witness proof Cannon handles two major components in the dispute game: generating state witness hashes for OP-Challenger to post during the execution trace bisection game, and generating the witness proof once a single MIPS instruction is reached as the root of disagreement in the fault dispute game. @@ -164,7 +164,7 @@ unimplemented functionality, any function within the ELF file that would require Patching the binary of these functions involves identifying problematic functions, searching for their corresponding symbols within the ELF file, and effectively stubbing out the function by returning immediately, and adding a `nop` to the delay slot. -### Instruction Stepping +### Instruction stepping Once the MIPS binary is loaded into Cannon, we can then begin to run MIPS instructions one at a time. [`run.go`](https://github.com/ethereum-optimism/optimism/blob/develop/cannon/cmd/run.go) contains the top-level @@ -197,7 +197,7 @@ However, there are differences between the two: 2. The `mipsevm` contains the entire 32-bit monolithic memory space, is responsible for maintaining the memory state based on the results of MIPS instructions, and generates the memory binary Merkle tree, Merkle root, and memory Merkle proofs. `MIPS.sol` is mostly stateless, and does not maintain the full memory space. Instead, it only requires the memory Merkle root, and up to two memory Merkle proofs: 1 for the instruction and 1 for potential load, store, or certain syscall instructions. 3. Unlike `MIPS.sol`, `mips.go` is responsible for writing Pre-images to the PreimageOracle Server, and optionally writing hints to the Server. -### PreimageOracle Interaction +### PreimageOracle interaction As mentioned previously, Cannon is responsible for setting up all state that may be required to run an instruction in `MIPS.sol`. Cannon is also responsible for interacting with the PreimageOracle Server, and directing OP-Challenger to provide Pre-images to diff --git a/pages/stack/protocol/fault-proofs/challenger.mdx b/pages/stack/fault-proofs/challenger.mdx similarity index 97% rename from pages/stack/protocol/fault-proofs/challenger.mdx rename to pages/stack/fault-proofs/challenger.mdx index 3f23d83f3..a70f022e1 100644 --- a/pages/stack/protocol/fault-proofs/challenger.mdx +++ b/pages/stack/fault-proofs/challenger.mdx @@ -1,5 +1,5 @@ --- -title: OP-Challenger Explainer +title: OP-Challenger explainer lang: en-US description: Learn about OP-Challenger and how it operates within the OP Stack's fault proof system. --- @@ -7,9 +7,9 @@ description: Learn about OP-Challenger and how it operates within the OP Stack's import { Callout } from 'nextra/components' import Image from 'next/image' -# OP-Challenger Explainer +# OP-Challenger explainer -The `op-challenger` operates as the *honest actor* in the fault dispute system and defends the chain by securing the `OptimismPortal` and ensuring the game always resolves to the correct state of the chain. For verifying the legitimacy of claims, `op-challenger` relies on a synced, trusted rollup node as well as a trace provider (e.g., [Cannon](/stack/protocol/fault-proofs/cannon)). +The `op-challenger` operates as the *honest actor* in the fault dispute system and defends the chain by securing the `OptimismPortal` and ensuring the game always resolves to the correct state of the chain. For verifying the legitimacy of claims, `op-challenger` relies on a synced, trusted rollup node as well as a trace provider (e.g., [Cannon](/stack/fault-proofs/cannon)). Specifically, `op-challenger` performs the following actions: @@ -38,22 +38,22 @@ graph TD; The `cannon` and `op-program` executables are run in the `op-challenger` docker container as sub-processes when required to generate game trace data. -## Fault Detection Responses +## Fault detection responses `op-challenger` assesses each claim's validity, countering only those deemed invalid, following this logic: 1. If the trusted node agrees with the output, `op-challenger` takes no action. An honest challenger does nothing because there are no claims it disagrees with. It continues to monitor the game in case someone posts a counter-claim to the valid root claim, in which case the challenger will participate in the game to defend the proposal. 2. If the trusted node disagrees, `op-challenger` posts a counter-claim to challenge the proposed output. In contrast to the above, an honest challenger aims to delete any output roots that its trusted node disagrees with in order to claim the bond attached to it. The honest challenger assumes that their rollup node is synced to the canonical state and that the fault proof program is correct, so it is willing to put its money on the line to counter any faults. -## Fault Dispute Game Responses +## Fault dispute game responses `op-challenger` iterates through claims as stored in the contract, ensuring ancestors are processed before their descendants. For each claim, the honest challenger determines and tracks the set of honest responses to all claims, regardless of whether that response already exists in the full game state. -### Root Claim +### Root claim The root claim is considered to be an honest claim if and only if it has a [state witness Hash](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#claims) that agrees with the honest challenger's state witness hash for the root claim. -### Counter Claims +### Counter claims When a new claim is made in a dispute game, the honest challenger processes it and performs a response. The honest challenger should counter a claim if and only if: @@ -64,7 +64,7 @@ When a new claim is made in a dispute game, the honest challenger processes it a This implies the honest challenger never counters its own claim, since there is at most one honest counter to each claim, so an honest claim never has an honest sibling. -### Possible Moves +### Possible moves The challenger monitors each game as new claims are added and reacts according to the [honest actor algorithm](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html) to defend valid proposals and invalidate invalid proposals. A **move** is a challenge against an existing claim and must include an alternate claim asserting a different trace (e.g., attack, defend, or step). @@ -82,7 +82,7 @@ When one side of a `FaultDisputeGame`'s chess clock runs out, the honest challen The `FaultDisputeGame` does not put a time cap on resolution - because of the liveness assumption on honest challengers and the bonds attached to the claims they've countered, challengers are economically motivated to resolve the game quickly, thereby liquidating their funds and securing rewards. -## Next Steps +## Next steps * Ready to get started? Read our guide on how to [configure `op-challenger` on your OP Stack chain](/builders/chain-operators/tools/op-challenger). * For more info about how `op-challenger` works under the hood, [check out the specs](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html). diff --git a/pages/stack/protocol/fault-proofs/explainer.mdx b/pages/stack/fault-proofs/explainer.mdx similarity index 87% rename from pages/stack/protocol/fault-proofs/explainer.mdx rename to pages/stack/fault-proofs/explainer.mdx index 7b1299aa4..df6c46ecb 100644 --- a/pages/stack/protocol/fault-proofs/explainer.mdx +++ b/pages/stack/fault-proofs/explainer.mdx @@ -1,5 +1,5 @@ --- -title: Fault Proofs Explainer +title: Fault proofs explainer lang: en-US description: Learn about the OP Stack's fault proof system. --- @@ -7,7 +7,7 @@ description: Learn about the OP Stack's fault proof system. import { Callout } from 'nextra/components' import Image from 'next/image' -# Fault Proofs Explainer +# Fault proofs explainer Fault Proofs are an important part of an Optimistic Rollup system like the OP Stack. Users withdraw ETH and tokens from OP Stack chains like OP Mainnet by submitting a withdrawal proof that shows the withdrawal was actually included in the OP Stack chain. @@ -25,7 +25,7 @@ Although the fault proof game is permissionless, the Optimism Security Council a Each proposal must wait for a delay period during which the Guardian can prevent invalid proposals from being used to withdraw ETH or tokens through a number of safety hatches. The Guardian can also choose to shift the system to use a PermissionedDisputeGame, in which only specific `PROPOSER` and `CHALLENGER` roles can submit and challenge proposals. -## Permissionless Proposals +## Permissionless proposals "Proposals" or "State Proposals" are claims about the state of an OP Stack chain that are submitted to Ethereum through the `DisputeGameFactory` contract. Proposals can be used for many things but are most commonly used by end-users to prove that they created a withdrawal on an OP Stack chain. @@ -36,28 +36,28 @@ See the permissionless fault proofs diagram below for more details:
Permissionless Fault Proofs flow -## Permissionless Challenges +## Permissionless challenges Because anyone can submit a proposal, it's important that invalid proposals can be challenged. -In [Optimistic Rollups like OP Stack Chains](/stack/protocol/rollup/overview) there is a \~1 week challenge period during which users can challenge a proposal if they believe it to be incorrect. +In [Optimistic Rollups like OP Stack Chains](/stack/rollup/overview) there is a \~1 week challenge period during which users can challenge a proposal if they believe it to be incorrect. With the Fault Proofs upgrade to the OP Stack, challenges become permissionless and can be submitted by anyone. Any user can run a node for the OP Stack chain in question and use the `op-challenger` tool to participate in the dispute process. -## Modular Design and Multi-layer Security +## Modular design and multi-layer security -The OP Stack Fault Proof system is [modular in design](/stack/protocol/fault-proofs/fp-components#system-design--modularity) and lays the groundwork for achieving a "multi-proof" system. This allows the OP Stack to support multiple proof systems alongside the initial [Cannon](/stack/protocol/fault-proofs/cannon) proof system. +The OP Stack Fault Proof system is [modular in design](/stack/fault-proofs/fp-components#system-design--modularity) and lays the groundwork for achieving a "multi-proof" system. This allows the OP Stack to support multiple proof systems alongside the initial [Cannon](/stack/fault-proofs/cannon) proof system. With multiple proof systems in place, the OP Stack can be more resilient to potential attacks and bugs in any one proof system. -Additionally, the following [security safeguards](/stack/protocol/fault-proofs/fp-security) have been built around the game, as follows: +Additionally, the following [security safeguards](/stack/fault-proofs/fp-security) have been built around the game, as follows: * An off chain monitoring system has been set up to monitor all proposed roots and ensure they align with the correct state. See [`op-dispute-mon`](https://github.com/ethereum-optimism/optimism/blob/develop/op-dispute-mon/README.md?plain=1) for more details. * After a root is finalized through a game, an additional delay called the "airgap window" has been added before withdrawals can occur. During this period, the `GUARDIAN` role can reject the root. * A contract called `DelayedWETH` has been set up to hold the bonds and only allow payouts after a delay, so that bonds can be redirected towards the correct recipient in the case that a game resolves incorrectly. -## Next Steps +## Next steps * Ready to get started? Review the [FP Components](fp-components) to learn how the different components work together to enhance decentralization in the Optimism ecosystem. -* See the [Fault Proof Mainnet Security](/stack/protocol/fault-proofs/fp-security) to understand changes to `OptimismPortal` and `FaultDisputeGame` contracts. +* See the [Fault Proof Mainnet Security](/stack/fault-proofs/fp-security) to understand changes to `OptimismPortal` and `FaultDisputeGame` contracts. * For more info about how the FP system works under the hood, [check out the specs](https://specs.optimism.io/fault-proof/index.html). ## FAQs diff --git a/pages/stack/protocol/fault-proofs/fp-components.mdx b/pages/stack/fault-proofs/fp-components.mdx similarity index 97% rename from pages/stack/protocol/fault-proofs/fp-components.mdx rename to pages/stack/fault-proofs/fp-components.mdx index 1027cb406..558ed7372 100644 --- a/pages/stack/protocol/fault-proofs/fp-components.mdx +++ b/pages/stack/fault-proofs/fp-components.mdx @@ -1,5 +1,5 @@ --- -title: FP System Components +title: FP System components lang: en-US description: Learn about fault proof system components and how they work together to enhance decentralization in the Optimism ecosystem. --- @@ -7,7 +7,7 @@ description: Learn about fault proof system components and how they work togethe import Image from 'next/image' import { Callout } from 'nextra/components' -# FP System Components +# FP system components This page explains the fault proof system components and how they work together to enhance decentralization in the Optimism ecosystem. @@ -19,7 +19,7 @@ The modular design of the fault proof system lays the foundation for a multi-pro Visit the [Immunefi bug bounty page](https://immunefi.com/bounty/optimism/) for details on testing and helping to build a robust fault proof system. -## System Design & Modularity +## System design & modularity The Fault Proof System is comprised of three main components: a Fault Proof Program (FPP), a Fault Proof Virtual Machine (FPVM), and a dispute game protocol. These components will work together to challenge malicious or faulty activity on the network to preserve trust and consistency within the system. @@ -33,7 +33,7 @@ The OP Stack's unique, modular design allows the decoupling of the FPP and FPVM, * custom-built fault proof systems comprised of any combination of these isolated components—including validity proofs, attestation proofs, or ZKVM. * dispute games in the dispute protocol backed by multiple security mechanisms. -## Fault Proof Program +## Fault proof program The default for this system component is `op-program`, which implements a fault proof program that runs through the rollup state-transition to verify an L2 output from L1 inputs. This verifiable output can then resolve a disputed output on L1. The FPP is a combination of `op-node` and `op-geth`, so it has both the consensus and execution "parts" of the protocol in a single process. This means Engine API calls that would normally be made over HTTP are instead made as direct method calls to the op-geth code. @@ -42,7 +42,7 @@ The FPP is designed so that it can be run in a deterministic way such that two i All data is retrieved via the [Preimage Oracle API](https://specs.optimism.io/experimental/fault-proof/index.html#pre-image-oracle). The preimages could be provided via the FPVM when onchain or by a native "host" implementation that can download the required data from nodes via JSON-RPC requests. The native host implementation is also provided by `op-program` but doesn't run as part of the onchain execution. Basically, `op-program` has two halves: the "client" Fault Proof Program part covered in this section and the "host" part used to fetch required preimages. -## Fault Proof Virtual Machine +## Fault proof virtual machine The Fault Proof Virtual Machine (FPVM) is one of the modules in the OP Stack's fault proof system. OP Stack's modularity decouples the Fault Proof Program (FPP) from the Fault Proof Virtual Machine (FPVM) to enable next-level composability and efficient parallelized upgrades to both components. The FPP (client-side) that runs within the FPVM is the part that expresses the L2 state-transition, and the interface between FPVM and FPP is standardized and documented in the [specs](https://github.com/ethereum-optimism/optimism/blob/546fb2c7a5796b7fe50b0b7edc7666d3bd281d6f/specs/cannon-fault-proof-vm.md). @@ -57,7 +57,7 @@ To do this, only one instruction is proven at a time. The bisection game will na [Cannon](cannon) is the default FPVM used in all disputes. [MIPS](mips) is the onchain smart contract implementation of Cannon that can be implemented due to the modularity of the dispute game. -## Dispute Game Protocol +## Dispute game protocol In the Dispute protocol, different types of dispute games can be created, managed, and upgraded through the [DisputeGameFactory](https://github.com/ethereum-optimism/optimism/blob/6a53c7a3294edf140d552962f81c0f742bf445f9/packages/contracts-bedrock/src/dispute/DisputeGameFactory.sol#L4). This opens the door to innovative features, like aggregate proof systems and the ability to expand the protocol to allow for disputing things apart from the state of L2, such as a `FaultDisputeGame` geared towards onchain binary verification. @@ -75,7 +75,7 @@ The VM's state transition function, which we'll call `T`, can be anything, so lo The first full implementation of the VM generic in the bisection game includes a single MIPS thread context on top of the EVM to execute a single instruction within an execution trace generated by `Cannon` and the `op-program`. -## Next Steps +## Next steps * For more detail on Cannon and its default operation as part of Optimism's Fault Proof Virtual Machine, see [Cannon FPVM](cannon). * For a detailed walk-thru of significant changes to Fault Proof Mainnet, see [FP Mainnet Security](fp-security). diff --git a/pages/stack/protocol/fault-proofs/fp-security.mdx b/pages/stack/fault-proofs/fp-security.mdx similarity index 94% rename from pages/stack/protocol/fault-proofs/fp-security.mdx rename to pages/stack/fault-proofs/fp-security.mdx index fa7c696ee..453f8d93d 100644 --- a/pages/stack/protocol/fault-proofs/fp-security.mdx +++ b/pages/stack/fault-proofs/fp-security.mdx @@ -1,12 +1,12 @@ --- -title: Fault Proofs Mainnet Security +title: Fault proofs Mainnet security lang: en-US description: Learn about changes to the security model for the Fault Proofs Mainnet System. --- import { Callout } from 'nextra/components' -# Fault Proofs Mainnet Security +# Fault proofs Mainnet security Source code for Fault Proof Mainnet contracts approved by Optimism Governance can be found [here](https://github.com/ethereum-optimism/optimism/tree/op-contracts/v1.5.0). @@ -17,12 +17,12 @@ The most significant change introduced by the Fault Proof Mainnet upgrade is the * The `DisputeGameFactory` contract generates `FaultDisputeGame` contract instances that each act as a host to a proposal about the state of the OP Stack chain at a given block number. * Unlike the `L2OutputOracle`, the `DisputeGameFactory` contract offers users the ability to permissionlessly play "fault dispute games" in which the correctness of the proposal is determined programmatically. -## Security Model +## Security model Fault Proof Mainnet is a large contract upgrade that introduces a number of novel components. Given the relative complexity of these novel components, the approach to security for FPM has been to limit the blast radius of potential bugs to very specific contracts and fallback mechanisms that can be easily audited. -### Handling Invalid Game Results +### Handling invalid game results All of the security mechanisms put in place generally revolve around the possibility that a `FaultDisputeGame` contract may incorrectly finalize an invalid game result. There are two variations of this: @@ -32,7 +32,7 @@ There are two variations of this: Both cases would cause honest challengers to lose bonds (unless the `Guardian` stepped in). Potential impact is managed through the introduction of a number of safeguards within the `OptimismPortal` and `FaultDisputeGame` contracts. -### Safeguards Within `OptimismPortal` +### Safeguards within `OptimismPortal` The `OptimismPortal` contract includes various security mechanisms that allow the `Guardian` and `SystemOwner` roles to collaborate to prevent invalid proposals from impacting withdrawals. @@ -41,23 +41,23 @@ The `OptimismPortal` contract includes various security mechanisms that allow th * The `Guardian` can "blacklist" specific `FaultDisputeGame` contracts that resolve incorrectly. * The `Guardian` can change the respected type of `FaultDisputeGame` contract in the case that an entire class of `FaultDisputeGame` contracts is found to have critical bugs. If desired, the `Guardian` can also choose to revert to a `PermissionedDisputeGame` contract that only allows specific roles to submit and challenge proposals. -### Safeguards Within `FaultDisputeGame` +### Safeguards within `FaultDisputeGame` The `FaultDisputeGame` contracts store bonds within a `DelayedWETH` contract that is managed by the `SystemOwner`. Withdrawals from the `DelayedWETH` contract are delayed which gives the `SystemOwner` the ability to manually recover from situations in which bonds would be incorrectly distributed. This delay is set to 7 days on OP Mainnet to give the `SystemOwner` or `Guardian` sufficient time to respond to potential security concerns. -### Safeguards Within `DelayedWETH` +### Safeguards within `DelayedWETH` * The `SystemOwner` can replace the `Guardian` address. * The `SystemOwner` can hold funds from any specific `DisputeGame` contract. * The `SystemOwner` can remove funds from the `DelayedWETH` contract if the issue extends to so many `DisputeGame` contracts that holding funds from specific contracts is not viable. * The `Guardian` can trigger the global pause mechanism to halt WETH withdrawals. -### Cumulative Security Impact +### Cumulative security impact As with the original system, the cumulative effect of these security capabilities is that the `Guardian` role provides fast response capabilities while the `SystemOwner` can always step in to resolve all classes of bugs that could result in a loss of funds. The most significant change in security model with the introduction of Fault Proof Mainnet is that `SystemOwner` can take a more passive role as invalid proposals will generally be rejected by the Fault Proof system while the `Guardian` can act as a backstop only in case of a failure in the fault proof game. -## Next Steps +## Next steps * See the [FP Components](fp-components) for an overview of FP system components and how they work together to enhance decentralization in the Optimism ecosystem. * See the [specs](https://specs.optimism.io/fault-proof/index.html) for detailed information about the entire FP program, FP virtual machine, and dispute game. diff --git a/pages/stack/protocol/fault-proofs/mips.mdx b/pages/stack/fault-proofs/mips.mdx similarity index 99% rename from pages/stack/protocol/fault-proofs/mips.mdx rename to pages/stack/fault-proofs/mips.mdx index e58cff53c..3623ae991 100644 --- a/pages/stack/protocol/fault-proofs/mips.mdx +++ b/pages/stack/fault-proofs/mips.mdx @@ -1,5 +1,5 @@ --- -title: Fault Proof VM - MIPS.sol +title: Fault proof VM - MIPS.sol lang: en-US description: Learn about the `MIPS.sol` smart contract that works as part of Optimism's Fault Proof Virtual Machine. --- @@ -7,14 +7,14 @@ description: Learn about the `MIPS.sol` smart contract that works as part of Opt import Image from 'next/image' import { Callout } from 'nextra/components' -# Fault Proof VM: MIPS.sol +# Fault proof VM: MIPS.sol The `MIPS.sol` smart contract is an onchain implementation of a virtual machine (VM) that encompasses the 32-bit, Big-Endian, MIPS III Instruction Set Architecture (ISA). This smart contract is the counterpart to the off-chain MIPSEVM golang implementation of the same ISA. Together, the onchain and off-chain VM implementations make up [Cannon](cannon), Optimism's Fault Proof Virtual Machine (FPVM). Cannon is a singular instance of a FPVM that can be used as part of the Dispute Game for Optimism's (and Base's) optimistic rollup L2 blockchain. The Dispute Game itself is modular, allowing for any FPVM to be used in a dispute; however, Cannon is currently the only FPVM implemented and thus will be used in all disputes. -## Control Flow +## Control flow The `FaultDisputeGame.sol` interacts with `MIPS.sol` and then `MIPS.sol` calls into `PreimageOracle.sol`. `MIPS.sol` is only called at the max depth of the game when someone needs to call `step`. `FaultDisputeGame.sol` is the deployed instance of a Fault Dispute Game for an active dispute, and `PreimageOracle.sol` stores Pre-images. @@ -27,7 +27,7 @@ A leaf node represents a single MIPS instruction (in the case that we're using C state to run in the `MIPS.sol` contract, the fault dispute game can determine the true post state (or Post-image). This true post state will then be used to determine the outcome of the fault dispute game by comparing the disputed post-state at the leaf node with the post-state proposed by the disputer. -## Contract State +## Contract state The `MIPS.sol` contract only contains a single immutable variable, which corresponds to the address of the `PreimageOracle.sol` contract. Otherwise, the contract is stateless, meaning that all state related to playing a MIPS instruction onchain comes from either the `FaultDisputeGame.sol` instance, or the `PreimageOracle.sol`. @@ -47,7 +47,7 @@ There is no requirement to read from the `PreimageOracle.sol` during instruction The Pre-image information that has been read in previous off-chain instructions leading up to the execution of a single instruction onchain may still reside in the constructed VM memory. Thus, even when the instruction run onchain does not explicitly read from `PreimageOracle.sol` , Pre-image data may still influence the merkle root that represents the VM's memory. -### Packed VM Execution State +### Packed VM execution state In order to execute a MIPS instruction onchain, the `MIPS.sol` contract needs to know important state information such as the instruction to run, the values in each of the general purpose registers, etc. More specifically, a tightly-packed `State` struct contains all the relevant information that the `MIPS.sol` contract needs to know. This struct is passed to the contract from the `FaultDisputeGame.sol` contract when it invokes the `step` function in `MIPS.sol` (which in-turn executes a single MIPS instruction onchain). @@ -66,7 +66,7 @@ The following information is stored in the `State` struct. See [doc reference](h 11. `step` - Counts the total number of instructions that have been executed. 12. `registers` - Array of 32, 32-bit values that represent the general purpose registers for the MIPS ISA. -### State Hash +### State hash The state hash is the `bytes32` value returned to the active Fault Dispute Game upon the completion of a single MIPS instruction in the `MIPS.sol` contract. The hash is derived by taking the `keccak256` of the above packed VM execution `State` struct, and then replacing the first byte of the hash with a value that represents the status of the VM. @@ -80,7 +80,7 @@ This value is derived from the `exitCode` and `exited` values, and can be: The reason for adding the VM status to the state hash is to communicate to the dispute game whether the VM determined the proposed output root was valid or not. This in turn prevents a user from disputing an output root during a dispute game, but provides the state hash from a cannon trace that actually proves the output root is valid. -### Memory Proofs +### Memory proofs Using a 32-bit ISA means that the total size of the address space (assuming no virtual address space) is `2^32 = 4GiB`. Additionally, the `MIPS.sol` contract is stateless, so it does not store the MIPS memory in contract storage. The primary reason for this is because having to load the entire memory into the `MIPS.sol` contract in order to execute a single instruction onchain is prohibitively expensive. Additionally, the entire memory would need to be loaded per fault proof game, requiring multiple instances of the `MIPS.sol` contract. Therefore, in order to optimize the amount of data that needs to be provided per onchain instruction execution while still maintaining integrity over the entire 32-bit address space, Optimism has converted the memory into a binary merkle tree. @@ -88,7 +88,7 @@ The binary merkle tree (or hash tree) used to store the memory of the MIPS VM ha Reading to memory and writing to memory work similarly, both involve calculating the merkle root. In the case of a memory write, `MIPS.sol` must take care to verify the provided proof for the memory location to write to is correct. Additionally, writing to memory will change the merkle root stored in the VM execution `State` struct. -### State Calculation +### State calculation While the `MIPS.sol` contract may only execute a single instruction onchain, the off-chain Cannon implementation executes all prerequisite MIPS instructions for all state transitions in the disputed L2 state required to reach the disputed instruction that will be executed onchain. This ensures that the MIPS instruction executed onchain has the correct VM state and necessary Pre-images stored in the `PreimageOracle.sol` contract to generate the true post-state that can be used to resolve the dispute game. @@ -177,7 +177,7 @@ The public [`step`](https://github.com/ethereum-optimism/optimism/blob/546fb2c7a The internal pure [`execute`](https://github.com/ethereum-optimism/optimism/blob/546fb2c7a5796b7fe50b0b7edc7666d3bd281d6f/packages/contracts-bedrock/src/cannon/MIPS.sol#L793) function handles the execution of MIPS instructions that are not handled by other functions. The `execute` function primarily handles R-type instructions according to the MIPS specification, however other instructions will pass through this function. Instructions handled by other functions will simply return. Invalid or unsupported instructions will cause the `execute` function to revert. -## Common Bitwise Operation Use Cases +## Common bitwise operation use cases 1. Isolating certain bits from a number can be done using the & operator (and(x,y) in Yul), this is also known as generating a bitmask. 2. Combining bits from two numbers together can be done using the | operator (or(x, y) in Yul). @@ -185,7 +185,7 @@ The internal pure [`execute`](https://github.com/ethereum-optimism/optimism/blob 4. Multiplication using a value with a base of 2 can be expressed using the following bitwise operation: `x * y = x << z, where y = 2^z` Ex. `x * 8 = x << 3, where 8 = 2^3` -## Table Of Supported MIPS Instructions +## Table of supported MIPS instructions | Instruction Name | Opcode Num. | Funct Num. | Other Num. | | ---------------------------------------------- | ----------- | ---------- | ---------- | @@ -253,7 +253,7 @@ The internal pure [`execute`](https://github.com/ethereum-optimism/optimism/blob | SC (Store Conditional Word) | 0x38 | - | - | | SYNC (Synchronize Shared Memory) | 0x00 | 0x0F | - | -## Further Reading +## Further reading * [Cannon Overview](https://github.com/ethereum-optimism/optimism/blob/546fb2c7a5796b7fe50b0b7edc7666d3bd281d6f/cannon/docs/README.md) * [Cannon FPVM Specification](https://specs.optimism.io/experimental/fault-proof/cannon-fault-proof-vm.html) diff --git a/pages/stack/features/_meta.json b/pages/stack/features/_meta.json new file mode 100644 index 000000000..1d8a795f7 --- /dev/null +++ b/pages/stack/features/_meta.json @@ -0,0 +1,3 @@ +{ + "send-raw-transaction-conditional": "SendRawTransactionConditional" +} diff --git a/pages/stack/features/send-raw-transaction-conditional.mdx b/pages/stack/features/send-raw-transaction-conditional.mdx new file mode 100644 index 000000000..5717ae5e8 --- /dev/null +++ b/pages/stack/features/send-raw-transaction-conditional.mdx @@ -0,0 +1,63 @@ +--- +title: SendRawTransactionConditional explainer +lang: en-US +description: Learn about the eth_sendRawTransactionConditional RPC method for conditional transaction inclusion on the OP Stack. +--- + +import { Callout } from 'nextra/components' + +# SendRawTransactionConditional explainer + +A sequencer rpc, `eth_sendRawTransactionConditional`, allowing callers to conditionally include a transaction based on a set of provided options. + +This feature is meant to unblock use cases that require atomic inclusion, otherwise possible on Ethereum through specialized block builders like Flashbots. Some examples: + +* 4337 Bundlers utilizing a shared mempool of UserOperations. Reverted transactions due to conflicting UserOperations would make it too costly for bundlers to operate on L2, forcing the use of private mempools. + +## Specification + +This endpoint is an extension of `eth_sendRawTransaction`, with an extra parameter of "options" with the following structure: + +``` +{ + "knownAccounts": [optional] A map of accounts with expected storage. The key is account address + If the value is hex string, it is the known storage root hash of that account. + If the value is an object, then each member is in the format of "slot": "value", which are explicit slot values within that account storage. + "blockNumberMin": [optional] minimal block number for inclusion + "blockNumberMax": [optional] maximum block number for inclusion + "timestampMin": [optional] minimum block timestamp for inclusion + "timestampMax": [optional] maximum block timestamp for inclusion +} +``` + +The "cost" of a given conditional is *approximately* determined by the number of storage lookups that would be incurred by validating this conditional. There's a predefined max of `1000` that is allowed to prevent DoS. + + + Since the sequencer is not compensated for the additional state checks, otherwise through the GAS of the transaction, a configured rate limit is applied to this cost. + + To also disincentive the use of this endpoint for MEV in comparison to `eth_sendRawTransaction`, the conditional is checked against the parent of the latest block. + + +This conditional is checked once at the RPC layer prior to mempool submission. If rejected against chain state, the RPC will return an error with the following spec + +* error code `-32003` (transaction rejected) with a reason string as to the specific failed check +* error code `-32005` (conditional cost) with a reason string if the conditional cost exceeded the maximum OR the cost was rate limited due to network conditions. + +Successful submission does **NOT** guarantee inclusion! The caller must observe the chain for a receipt with some timeout to determine non-inclusion. The conditional is also re-checked in the block building phase to handle intra-block conflicts. + + + Conditional transactions are tied to the block builder they are submitted to. This means that these transactions **are not gossiped between configured peers!!!** + + If you are running an active/passive setup with replicas that gossip txs to an active sequencer, this endpoint should be fronted by a proxy that can broadcast the request to all replicas. + + +## How to enable + +This feature can be enabled with the addition of a flag to op-geth. + +* `--rollup.sequencertxconditionalenabled` (default: false) a boolean flag which enables the rpc. +* `--rollup.sequencertxconditionalcostratelimit` (default: 5000) an integer flag that sets the rate limit for cost observable per second. + + + It is not advised to publicly expose this sequencer endpoint due to DoS concerns. This supplemental proxy, [op-txproxy](/stack/operators/features/op-txproxy), should be used to apply additional constraints on this endpoint prior to passing through to the sequencer. + diff --git a/pages/stack/getting-started.mdx b/pages/stack/getting-started.mdx index 554a247c7..67096b0dc 100644 --- a/pages/stack/getting-started.mdx +++ b/pages/stack/getting-started.mdx @@ -1,12 +1,12 @@ --- -title: Getting Started with the OP Stack +title: Getting started with the OP Stack lang: en-US description: Learn the basics of OP Stack development. --- import { Callout } from 'nextra/components' -# Getting Started with the OP Stack +# Getting started with the OP Stack **The OP Stack is the standardized, shared, and open-source development stack that powers Optimism, maintained by the Optimism Collective.** @@ -61,7 +61,7 @@ As work on the stack continues, it should become easier to plug in and configure As the [Superchain](explainer) begins to take shape, the OP Stack can evolve alongside it, to include the message-passing infrastructure that allows different chains to interoperate seamlessly. At the end of the day, the OP Stack becomes what Optimism needs. -## Dive Deeper into the OP Stack +## Dive deeper into the OP Stack Ready to dive into the world of the OP Stack? diff --git a/pages/stack/interop/_meta.json b/pages/stack/interop/_meta.json new file mode 100644 index 000000000..d59a68f5d --- /dev/null +++ b/pages/stack/interop/_meta.json @@ -0,0 +1,6 @@ +{ + "explainer": "Interop Explainer", + "cross-chain-message": "Anatomy of Cross-Chain Message", + "supersim": "Supersim Multichain Development Environment", + "superchain-erc20": "SuperchainERC20 Token Standard" +} \ No newline at end of file diff --git a/pages/stack/protocol/interop/cross-chain-message.mdx b/pages/stack/interop/cross-chain-message.mdx similarity index 86% rename from pages/stack/protocol/interop/cross-chain-message.mdx rename to pages/stack/interop/cross-chain-message.mdx index 615d852ab..ae15b27c1 100644 --- a/pages/stack/protocol/interop/cross-chain-message.mdx +++ b/pages/stack/interop/cross-chain-message.mdx @@ -1,5 +1,5 @@ --- -title: Anatomy of a Cross-Chain Message +title: Anatomy of a cross-chain message lang: en-US description: Learn how cross-chain messaging works with OP Stack interoperability. --- @@ -7,11 +7,11 @@ description: Learn how cross-chain messaging works with OP Stack interoperabilit import { Callout } from 'nextra/components' import Image from 'next/image' -# Anatomy of a Cross-Chain Message +# Anatomy of a cross-chain message A cross-chain message applies to any message sent across a chain. This applies to asset transfers using the [SuperchainERC20](https://specs.optimism.io/interop/token-bridging.html) token standard. -## How It Works +## How it works To send a cross-chain message on the Superchain using [Superchain interoperability](explainer), these two aspects must be in place: @@ -29,8 +29,8 @@ To send a cross-chain message on the Superchain using [Superchain interoperabili 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 +## 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](https://github.com/ethereum-optimism/supersim), a local dev environment that simulates Superchain interop for testing applications against a local version of the Superchain. +* 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/protocol/interop/explainer.mdx b/pages/stack/interop/explainer.mdx similarity index 94% rename from pages/stack/protocol/interop/explainer.mdx rename to pages/stack/interop/explainer.mdx index 284420bb0..4da94e360 100644 --- a/pages/stack/protocol/interop/explainer.mdx +++ b/pages/stack/interop/explainer.mdx @@ -1,5 +1,5 @@ --- -title: Interoperability Explainer +title: Interoperability explainer lang: en-US description: Learn the basics of interoperability on the OP Stack. --- @@ -11,7 +11,7 @@ import { InfoCallout } from '@/components/WipCallout' -# Interoperability Explainer +# Interoperability explainer 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 the Superchain (without having to go through L1) via secure message passing. This results in the following benefits: @@ -21,20 +21,20 @@ Native OP Stack interoperability provides the ability to read messages and trans * improved user experience for developers on the Superchain * secure transfer of ETH and ERC-20s across L2s -## Secure Message Passing +## 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](https://specs.optimism.io/interop/messaging.html) 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](https://specs.optimism.io/interop/token-bridging.html) turns message passing into asset transfer between chains in the interop set +* **SuperchainERC20 token specification**: the [SuperchainERC20](https://specs.optimism.io/interop/token-bridging.html) 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/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 +## Low latency Interoperability allows for horizontally scalable blockchains, a key feature of the Superchain. With Superchain interop, latency can be low (~2 seconds) by optimistically accepting cross-chain messages. The fork choice rule enforces eventual consistency, meaning that if an invalid cross-chain message is accepted, it will be reorganized out eventually. The fault proof guarantees that all of the cross-chain messages are accounted for from the perspective of handling withdrawals through the bridge to L1. -## Permissionless Chain Set +## Permissionless chain set It is permissionless to define a dependency on a chain, so chain operators will be able to choose which chains their chains depend on, and it is not a requirement that chains are in each other's dependency set. Chain operators can add or remove chains from the dependency set through the `SystemConfig`. For example, the dependency set for OP Mainnet is managed by Optimism Governance. @@ -50,9 +50,9 @@ Chain operators will need to run additional infrastructure to be part of the int For additional considerations, join the [Interop discussion](https://github.com/ethereum-optimism/specs/discussions/128) in our specs repo. -## Next Steps +## 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](https://github.com/ethereum-optimism/supersim), a local dev environment that simulates interop for testing applications against a local version of the Superchain. +* 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 diff --git a/pages/stack/interop/superchain-erc20.mdx b/pages/stack/interop/superchain-erc20.mdx new file mode 100644 index 000000000..092af2cb4 --- /dev/null +++ b/pages/stack/interop/superchain-erc20.mdx @@ -0,0 +1,90 @@ +--- +title: SuperchainERC20 Token Standard +lang: en-US +description: Learn basic details about the SuperchainERC20 token standard. +--- + +import { Callout } from 'nextra/components' + +# SuperchainERC20 Token Standard + + + 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 a token standard 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**: Provides a consistent, unified standard for tokens across all Superchain-compatible networks and a common crosschain 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. +* **Ethereum-aligned**: Intentionally designed to be generic and supported as an Ethereum-wide standard (RIP coming soon). + +## How it works + +`SuperchainERC20` token standard 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. + +```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 the `SuperchainERC20` standard 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 standards + +`SuperchainERC20` differs from other token standards in its focus and implementation: + +* `SuperchainERC20` has minimal differentiation from a standard ERC20 deployment, only requiring a minimal crosschain mint/burn interface, which aims to be a common pattern for the EVM ecosystem (RIP coming soon). +* `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 standards 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 standard ERC20 tokens with additional built-in functions that allow cross-chain asset movement that will be enabled once Interop goes live. + + + To enable asset interoperability, `SuperchainERC20` token 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. +* 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/supersim.mdx b/pages/stack/interop/supersim.mdx new file mode 100644 index 000000000..674485a66 --- /dev/null +++ b/pages/stack/interop/supersim.mdx @@ -0,0 +1,61 @@ +--- +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/operators/_meta.json b/pages/stack/operators/_meta.json deleted file mode 100644 index 274405469..000000000 --- a/pages/stack/operators/_meta.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "features": "Features" -} \ No newline at end of file diff --git a/pages/stack/operators/features/_meta.json b/pages/stack/operators/features/_meta.json deleted file mode 100644 index 91f5e9e5c..000000000 --- a/pages/stack/operators/features/_meta.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "proxyd": "proxyd" -} \ No newline at end of file diff --git a/pages/stack/protocol/_meta.json b/pages/stack/protocol/_meta.json deleted file mode 100644 index fb4113973..000000000 --- a/pages/stack/protocol/_meta.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "rollup": "Rollup", - "fault-proofs": "Fault Proofs", - "interop": "Interoperability", - "features": "Features", - "outages": "Sequencer Outages", - "derivation-pipeline":"Derivation Pipeline" -} \ No newline at end of file diff --git a/pages/stack/protocol/interop/_meta.json b/pages/stack/protocol/interop/_meta.json deleted file mode 100644 index 5c76b2a4a..000000000 --- a/pages/stack/protocol/interop/_meta.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "explainer": "Interop Explainer", - "cross-chain-message": "Anatomy of Cross-Chain Message" -} \ No newline at end of file diff --git a/pages/stack/protocol/rollup/_meta.json b/pages/stack/protocol/rollup/_meta.json deleted file mode 100644 index bf5f987a5..000000000 --- a/pages/stack/protocol/rollup/_meta.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "overview": "Rollup Overview", - "deposit-flow": "Deposit Flow", - "transaction-flow": "Transaction Flow", - "withdrawal-flow": "Withdrawal Flow", - "forced-transaction": "Forced Transaction" -} \ No newline at end of file diff --git a/pages/stack/rollup/_meta.json b/pages/stack/rollup/_meta.json new file mode 100644 index 000000000..a0e4ff047 --- /dev/null +++ b/pages/stack/rollup/_meta.json @@ -0,0 +1,5 @@ +{ + "overview": "Rollup Overview", + "derivation-pipeline": "Derivation Pipeline", + "outages": "Sequencer Outages" +} \ No newline at end of file diff --git a/pages/stack/protocol/derivation-pipeline.mdx b/pages/stack/rollup/derivation-pipeline.mdx similarity index 93% rename from pages/stack/protocol/derivation-pipeline.mdx rename to pages/stack/rollup/derivation-pipeline.mdx index 4fbad5f31..2c2aad540 100644 --- a/pages/stack/protocol/derivation-pipeline.mdx +++ b/pages/stack/rollup/derivation-pipeline.mdx @@ -1,14 +1,14 @@ --- -title: Derivation Pipeline +title: Derivation pipeline lang: en-US description: Overview of the derivation pipeline in the OP Stack protocol. --- -# Derivation Pipeline +# Derivation pipeline The derivation pipeline is a fundamental component of the OP Stack protocol, responsible for processing and validating transactions in the Optimism network. It ensures the integrity and security of the blockchain by deriving a consistent state from the sequenced transactions and batches submitted by the sequencer. -## Key Functions of the Derivation Pipeline +## Key functions of the derivation pipeline The following are key functions of the derivation pipeline: @@ -16,7 +16,7 @@ The following are key functions of the derivation pipeline: * **Safe Head and Unsafe Blocks**: The derivation pipeline maintains two types of heads: the Safe Head and the Unsafe Head. The Safe Head represents the most recent confirmed state on L1, while Unsafe Blocks are those that have been sequenced but not yet confirmed on L1. * **Reorg and Recovery**: If the sequencing window (typically 12 hours) is exceeded without a valid batch being discovered on L1, the pipeline will revert all Unsafe Blocks from that period. The pipeline then progresses using a default block that is empty except for deposits, allowing the network to recover and continue processing new transactions. -## Sequencer Window +## Sequencer window The sequencer window defines the maximum time allowed for batches to be submitted and confirmed on L1. If this window is exceeded, the derivation pipeline takes corrective actions to ensure the network's integrity and continued operation. @@ -25,11 +25,11 @@ For example: * In a 12-hour sequencing window, if no valid batch is discovered on L1, the pipeline reverts to Unsafe Blocks and uses a default block to move forward. * Increasing the window to 24 hours allows nodes to wait longer before reorging out unsafe blocks, but it may introduce additional challenges such as increased resource constraints and difficulty in processing larger batches. -## Configuration and Adjustments +## Configuration and adjustments The `sequencerWindowSize` parameter is set during the deployment configurations and may be difficult to change once established. It is important for chain operators to carefully consider the appropriate window size to balance network performance and stability. -## Next Steps +## Next steps * For more detailed information, refer to the [derivation pipeline specification](https://specs.optimism.io/protocol/derivation.html). * Have questions? You can ask a question in the [developer support forum](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/stack/protocol/outages.mdx b/pages/stack/rollup/outages.mdx similarity index 97% rename from pages/stack/protocol/outages.mdx rename to pages/stack/rollup/outages.mdx index 12ceed8cc..4f20970e9 100644 --- a/pages/stack/protocol/outages.mdx +++ b/pages/stack/rollup/outages.mdx @@ -1,10 +1,10 @@ --- -title: Sequencer Outages +title: Sequencer outages lang: en-US description: Learn what happens if the Sequencer goes down and how you can be prepared. --- -# Sequencer Outages +# Sequencer outages All OP Stack chains have a Sequencer that can receive, order, and publish L2 transactions to L1. Like any software systems, a Sequencer could potentially become unavailable for any number of different reasons. @@ -18,7 +18,7 @@ Sequencer outages can broadly be categorized into two different types: Both outage types can be circumvented by submitting transactions directly to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L209) contract on L1 with certain important caveats. Keep reading to learn more about these potential outages and how to handle them. -## Sequencer Downtime Outages +## Sequencer downtime outages ### Description @@ -37,7 +37,7 @@ Users may observe that the network appears to be "stuck" at a particular block h Users can always bypass the Sequencer by sending L2 transactions directly to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L209) contract on L1. Refer to the [Bypassing the Sequencer](#bypassing-the-sequencer) section below for more information about this functionality. -## Transaction Submission Outages +## Transaction submission outages ### Description @@ -60,7 +60,7 @@ This can appear to users as a large change in the expected state of the L2 chain Users can always bypass the Sequencer by sending L2 transactions directly to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L209) contract on L1. Refer to the [Bypassing the Sequencer](#bypassing-the-sequencer) section for more information about this functionality. -## Bypassing the Sequencer +## Bypassing the sequencer A core security goal of OP Stack chains is that the Sequencer should not be able to prevent users from submitting transactions to the L2 chain. Users of OP Stack chains can always bypass the sequencer and include transactions in the L2 chain by sending their L2 transactions directly to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L209) contract on L1. @@ -79,13 +79,13 @@ L2 transactions can be triggered on L1 by calling the `depositTransaction` funct Users can send any type of L2 transaction to the `OptimismPortal` contract including contract creations and transactions that carry ETH value. As a security measure, transactions sent via the `OptimismPortal` are indistinguishable from transactions sent via the Sequencer from the perspective of smart contracts on L2. -### Address Aliasing +### Address aliasing Transactions triggered via the `OptimismPortal` contract will appear to have been sent by the L1 address that triggered the transaction **unless** the transaction was sent by a smart contract. L2 transactions sent by smart contracts via the `OptimismPortal` contract will appear to have been sent by an "aliased" version of the smart contract's address. Refer to the [address aliasing](/chain/differences#address-aliasing) explainer for more information about address aliasing. -### Inclusion Rules +### Inclusion rules Transactions sent to the `OptimismPortal` contract are processed according to a set of rules designed to limit the impact of a failed Sequencer. It's important to understand these rules in detail to properly mitigate the effects of an outage. @@ -102,12 +102,12 @@ If the Sequencer is unavailable or transactions are not published to L1 within t Refer to the [L2 Chain Derivation Specification](https://specs.optimism.io/protocol/derivation.html) for a much more detailed explanation of how transactions sent to the `OptimismPortal` contract are processed. -### Inclusion Scenarios +### Inclusion scenarios It can be helpful to understand how transactions sent to the `OptimismPortal` contract are processed in different scenarios. The following scenarios make different assumptions about the state of the Sequencer and the L2 chain to illustrate how transactions sent to the `OptimismPortal` contract are processed. -#### Total Sequencer Outage +#### Total sequencer outage In this scenario we'll assume that the Sequencer is completely unavailable and unable to process any transactions. Users must send transactions directly to the `OptimismPortal` contract to have them included in the L2 chain. @@ -133,7 +133,7 @@ sequenceDiagram OP->>L2: Transaction 1 included in L2 automatically OP->>L2: Transaction 2 included in L2 automatically ``` -#### Partial Sequencer Outage +#### Partial sequencer outage In this scenario we'll assume that the Sequencer is down for some period of time but comes back online before the `sequencer_window` has elapsed. A user sends a transaction to the `OptimismPortal` during the downtime and but the Sequencer comes back online and includes the transaction in an L2 block before the full `sequencer_window` ends. @@ -152,7 +152,7 @@ sequenceDiagram S->>L2: Transaction included by Sequencer ``` -#### Partial Outage Ordering +#### Partial outage ordering Here we'll again assume that the Sequencer is down for some period of time but comes back online before the `sequencer_window` has elapsed. In this scenario, we'll observe the ability that the Sequencer has to include additional transactions in the L2 chain in between transactions sent to the `OptimismPortal` contract. diff --git a/pages/stack/protocol/rollup/overview.mdx b/pages/stack/rollup/overview.mdx similarity index 94% rename from pages/stack/protocol/rollup/overview.mdx rename to pages/stack/rollup/overview.mdx index a275be581..d9a6f23e7 100644 --- a/pages/stack/protocol/rollup/overview.mdx +++ b/pages/stack/rollup/overview.mdx @@ -1,24 +1,24 @@ --- -title: Rollup Protocol Overview +title: Rollup protocol overview lang: en-US description: Learn how Optimistic Rollups work at a high level. --- -# Rollup Protocol Overview +# Rollup protocol overview The big idea that makes Optimism possible is the Optimistic Rollup. We'll go through a brief explainer of *how* Optimistic Rollups work at a high level. Then we'll explain *why* Optimism is built as an Optimistic Rollup and why we believe it's the best option for a system that addresses all of our design goals. Check out the [protocol specs](https://specs.optimism.io/), if you want to more detail about the rollup protocol. -## Optimistic Rollups TL;DR +## Optimistic rollups TL;DR Optimism is an "Optimistic Rollup," which is basically just a fancy way of describing a blockchain that piggy-backs off of the security of another "parent" blockchain. Specifically, Optimistic Rollups leverage the consensus mechanism (like PoW or PoS) of their parent chain instead of providing their own. In OP Mainnet's case, this parent blockchain is Ethereum. ![Ethereum and Optimism Forever Doodle.](/img/op-stack/protocol/ethereum-optimism-forever.png) -## Block Storage +## Block storage In Bedrock, L2 blocks are saved to the Ethereum blockchain using a non-contract address ([`0xff00..0010` on Ethereum](https://etherscan.io/address/0xff00000000000000000000000000000000000010)) to minimize the L1 gas expense. As these blocks are submitted as transactions using EIP-4844 [blobs](/builders/chain-operators/management/blobs), there is no way to modify or censor them after the "transaction" is included in a block that has enough attestations. @@ -27,7 +27,7 @@ This is the way that OP Mainnet inherits the availability and integrity guarante Blocks are written to L1 in [a compressed format](https://specs.optimism.io/protocol/derivation.html#batch-submission-wire-format) to reduce costs. This is important because writing to L1 is [the major cost of OP Mainnet transactions](/stack/transactions/fees). -## Block Production +## Block production Optimism block production is primarily managed by a single party, called the "sequencer," which helps the network by providing the following services: @@ -50,9 +50,9 @@ Transactions get to the sequencer in two ways: This provides OP Mainnet with L1 Ethereum level censorship resistance. You can read more about this mechanism [in the protocol specifications](https://specs.optimism.io/protocol/derivation.html#deriving-the-transaction-list). -For the moment, [The Optimism Foundation](https://www.optimism.io/) runs the only block producer on OP Mainnet. Refer to [Protocol specs](overview) section for more information about how we plan to decentralize the Sequencer role in the future. +For the moment, [The Optimism Foundation](https://www.optimism.io/) runs the only block producer on OP Mainnet. -## Block Execution +## Block execution The execution engine (implemented as the `op-geth` component) receive blocks using two mechanisms: @@ -64,7 +64,7 @@ The execution engine (implemented as the `op-geth` component) receive blocks usi This mechanism is slower, but censorship resistant. You can read more about it [in the specs](https://specs.optimism.io/protocol/exec-engine.html#worst-case-sync). -## Bridging ETH or Tokens Between Layers +## Bridging ETH or tokens between layers Optimism is designed so that users can send arbitrary messages between smart contracts on L2 (OP Mainnet, OP Sepolia, etc.) and the underlying L1 (Ethereum mainnet, Sepolia, etc.). This makes it possible to transfer ETH or tokens, including ERC20 tokens, between the two networks. @@ -96,7 +96,7 @@ Withdrawals (the term is used for any OP Mainnet to Ethereum message) have three [You can read the full withdrawal specifications here](https://specs.optimism.io/protocol/withdrawals.html) -## Fault Proofs +## Fault proofs In an Optimistic Rollup, state commitments are published to L1 (Ethereum in the case of OP Mainnet) without any direct proof of the validity of these commitments. Instead, these commitments are considered pending for a period of time (called the "challenge window"). @@ -110,7 +110,7 @@ The ordering of transactions and the state of OP Mainnet is unchanged by a fault The fault proof process is currently undergoing major redevelopment as a side-effect of the November 11th, 2021 [EVM Equivalence](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) update. -## Next Steps +## Next steps -* If you want to learn more about rollup protocol, check out the guides on [deposit flow](deposit-flow), [withdrawal flow](withdrawal-flow), or [transaction flow](transaction-flow). +* If you want to learn more about rollup protocol, check out the guides on [deposit flow](/stack/transactions/deposit-flow), [withdrawal flow](/stack/transactions/withdrawal-flow), or [transaction flow](/stack/transactions/transaction-flow). * To learn about operating your own L2 rollup, see the guide on [starting a self-hosted chain](/builders/chain-operators/self-hosted) or go directly to the tutorial on [creating your own L2 rollup](/builders/chain-operators/tutorials/create-l2-rollup). diff --git a/pages/stack/security/faq.mdx b/pages/stack/security/faq.mdx index 2df0f86cd..31b892758 100644 --- a/pages/stack/security/faq.mdx +++ b/pages/stack/security/faq.mdx @@ -1,12 +1,12 @@ --- -title: OP Stack Security FAQs +title: OP Stack security FAQs lang: en-US description: Learn answers to common questions about OP Stack security. --- import { Callout } from 'nextra/components' -# OP Stack Security FAQs +# OP Stack security FAQs 🚧 The OP Stack is a work in progress. Constantly pushing to improve the overall security and decentralization of the OP Stack is a top priority. diff --git a/pages/stack/security/pause.mdx b/pages/stack/security/pause.mdx index 41fd67950..2491195e7 100644 --- a/pages/stack/security/pause.mdx +++ b/pages/stack/security/pause.mdx @@ -1,10 +1,10 @@ --- -title: Pausing the Bridge +title: Pausing the bridge lang: en-US description: Learn how the OP Stack bridge can be paused as backup safety mechanism. --- -# Pausing the Bridge +# Pausing the bridge The [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/L1/OptimismPortal.sol) is the low-level L1 message passing contract present on all standard OP Stack chains. This contract handles the L1 side of the communication channel between an OP Stack chain and its L1 parent chain. @@ -15,7 +15,7 @@ This is a backup safety mechanism that can be used to help mitigate potential ac Pause functionality and [two-step withdrawals](https://web.archive.org/web/20230608050641/https://blog.oplabs.co/two-step-withdrawals/) were introduced to the OP Stack to mitigate the risk of withdrawal bugs that have led to exploits in other bridging systems. -## Pause Functionality +## Pause functionality The `OptimismPortal` can be configured to allow a `GUARDIAN` address to pause and unpause L2-to-L1 transactions from being executed. L2-to-L1 transactions allow users and smart contracts on the OP Stack chain to send messages to the L1 parent chain. @@ -25,12 +25,12 @@ L1-to-L2 transactions are not affected by pause functionality. Pauses by the `GUARDIAN` impact all L2-to-L1 transactions for the OP Stack chain in question and cannot be targeted to specific users, smart contracts, or transactions. Pauses are designed to be a backup safety mechanism and are expected to be used only in the event of an active pressing security concern. -## Pause and Unpause Functions +## Pause and unpause functions The `GUARDIAN` can pause and unpause L2-to-L1 transactions at any time by calling the [`pause`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L151-L156) and [`unpause`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L158-L163) functions on the `OptimismPortal` contract. Additional controls on the `GUARDIAN` address can be implemented by configuring the `GUARDIAN` as a smart contract. -## Guardian Address +## Guardian address The `GUARDIAN` address is initially configured when the OP Stack chain is deployed and can be modified by the network's administrative address or smart contract. A chain can choose to remove the `GUARDIAN` role by configuring the `GUARDIAN` to be an inaccessible address such as the [zero address](https://etherscan.io/address/0x0000000000000000000000000000000000000000). diff --git a/pages/stack/smart-contracts.mdx b/pages/stack/smart-contracts.mdx index cfb440e62..973821f2a 100644 --- a/pages/stack/smart-contracts.mdx +++ b/pages/stack/smart-contracts.mdx @@ -1,22 +1,22 @@ --- -title: Smart Contract Overview +title: Smart Contract overview lang: en-US description: Learn about the smart contracts that make up the OP Stack. --- import { Callout } from 'nextra/components' -# Smart Contract Overview +# Smart Contract overview This guide provides an overview of the functionality of the smart contract components. You can also find [contract addresses](/chain/addresses) on OP Mainnet. -## Layer 1 Contracts +## Layer 1 contracts The layer 1 contracts of the OP Stack are deployed on Ethereum. Their primary purpose is to facilitate the cross domain message passing and maintain the valid state root of the layer 2. -### Official Releases +### Official releases The full smart contract release process is documented in the [monorepo](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/VERSIONING.md). All production releases are always tagged, versioned as `/v`. @@ -33,7 +33,7 @@ Contract releases have a component name of `op-contracts` and therefore are tagg smart contracts—only deploy from `op-contracts/vX.Y.Z` -#### op-contracts/v1.6.0 - Fault Proof Fixes +#### op-contracts/v1.6.0 - Fault proof fixes The release fixes security vulnerabilities found in Fault Proof contracts. They were made in response to security vulnerabilities identified during a series of third-party security audits by Spearbit, Cantina, and Code4rena. None of the vulnerabilities have been exploited, and user assets are not and were never at risk. @@ -62,14 +62,14 @@ The upgrade was coupled with the [Granite network upgrade](/builders/node-operat * L1StandardBridge: [2.1.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/L1/L1StandardBridge.sol#L73) * OptimismMintableERC20Factory: [1.9.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/universal/OptimismMintableERC20Factory.sol#L46) * OptimismPortal: [3.10.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/L1/OptimismPortal2.sol#L144) - * SystemConfig: [2.0.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/L1/SystemConfig.sol#L111) + * SystemConfig: [2.2.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/L1/SystemConfig.sol#L111) * DisputeGameFactory: [1.0.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/dispute/DisputeGameFactory.sol#L25) * SuperchainConfig: [1.1.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.2.0/packages/contracts-bedrock/src/L1/SuperchainConfig.sol#L38) * ProtocolVersions: [1.0.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.2.0/packages/contracts-bedrock/src/L1/ProtocolVersions.sol#L39) -#### op-contracts/v1.5.0 - Safe Extensions +#### op-contracts/v1.5.0 - Safe extensions The Safe Extensions protocol upgrade is intended to increase the security and decentralization of the Superchain by: @@ -106,7 +106,7 @@ vote for L2 predeploy upgrades and is a requirement for Stage 1. * L1StandardBridge: [2.1.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/L1/L1StandardBridge.sol#L73) * OptimismMintableERC20Factory: [1.9.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/universal/OptimismMintableERC20Factory.sol#L46) * OptimismPortal: [3.10.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/L1/OptimismPortal2.sol#L144) - * SystemConfig: [2.0.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/L1/SystemConfig.sol#L111) + * SystemConfig: [2.2.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/L1/SystemConfig.sol#L111) * FaultDisputeGame: [1.2.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/dispute/FaultDisputeGame.sol#L73) * PermissionedDisputeGame: [1.2.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/dispute/PermissionedDisputeGame.sol) * DisputeGameFactory: [1.0.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/dispute/DisputeGameFactory.sol#L25) @@ -119,7 +119,7 @@ vote for L2 predeploy upgrades and is a requirement for Stage 1. -#### op-contracts/v1.4.0 - Fault Proofs +#### op-contracts/v1.4.0 - Fault proofs This protocol upgrade reduces the trust assumptions for users of the OP Stack by enabling permissionless output proposals and a permissionless fault proof diff --git a/pages/stack/transactions/_meta.json b/pages/stack/transactions/_meta.json index 8f79b3007..20f41a7f2 100644 --- a/pages/stack/transactions/_meta.json +++ b/pages/stack/transactions/_meta.json @@ -1,3 +1,7 @@ { - "fees": "Transaction Fees" + "fees": "Transaction Fees", + "transaction-flow": "Transaction Flow", + "deposit-flow": "Deposit Flow", + "withdrawal-flow": "Withdrawal Flow", + "forced-transaction": "Forced Transaction" } diff --git a/pages/stack/protocol/rollup/deposit-flow.mdx b/pages/stack/transactions/deposit-flow.mdx similarity index 99% rename from pages/stack/protocol/rollup/deposit-flow.mdx rename to pages/stack/transactions/deposit-flow.mdx index 3253e4032..54e80753b 100644 --- a/pages/stack/protocol/rollup/deposit-flow.mdx +++ b/pages/stack/transactions/deposit-flow.mdx @@ -1,5 +1,5 @@ --- -title: Deposit Flow +title: Deposit flow lang: en-US description: Learn the deposit flow process for L2 deposit transactions, triggered by events on L1. --- @@ -7,7 +7,7 @@ description: Learn the deposit flow process for L2 deposit transactions, trigger import Image from 'next/image' import { Callout } from 'nextra/components' -# Deposit Flow +# Deposit flow This guide explains the deposit flow process for L2 deposit transactions, triggered by transactions or events on L1. In Optimism terminology, "*deposit transaction*" refers to any L2 transaction that is triggered by a transaction or event on L1. @@ -16,7 +16,7 @@ Information is encapsulated in lower layer packets on the sending side and then ![Deposit Flow Diagram.](/img/op-stack/protocol/deposit-flow.svg) -## L1 Processing +## L1 processing 1. An L1 entity, either a smart contract or an externally owned account (EOA), sends a deposit transaction to [`L1CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/L1/L1CrossDomainMessenger.sol), using [`sendMessage`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/universal/CrossDomainMessenger.sol#L249-L289). This function accepts three parameters: @@ -44,7 +44,7 @@ Information is encapsulated in lower layer packets on the sending side and then 4. [The `depositTransaction` function](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/L1/OptimismPortal.sol#L422-L483) runs a few sanity checks, and then emits a [`TransactionDeposited`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/L1/OptimismPortal.sol#L85-L99) event. -## L2 Processing +## L2 processing 1. The `op-node` component [looks for `TransactionDeposited` events on L1](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/op-node/rollup/derive/deposits.go#L13-L33). If it sees any such events, it [parses](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/op-node/rollup/derive/deposit_log.go) them. diff --git a/pages/stack/transactions/fees.mdx b/pages/stack/transactions/fees.mdx index 1a6f3f47b..809137e54 100644 --- a/pages/stack/transactions/fees.mdx +++ b/pages/stack/transactions/fees.mdx @@ -1,12 +1,12 @@ --- -title: Transaction Fees on OP Mainnet +title: Transaction fees on OP Mainnet lang: en-US description: Learn how transaction fees work on OP Mainnet. --- import { Callout } from 'nextra/components' -# Transaction Fees on OP Mainnet +# Transaction fees on OP Mainnet OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), which means it reuses the same Ethereum code you're already familiar with and behaves as much like Ethereum as possible. However, transaction fees on all Layer 2 systems need to diverge from Ethereum to some extent for a number of reasons. @@ -16,7 +16,7 @@ OP Mainnet transaction fees are composed of an [Execution Gas Fee](#execution-ga The total cost of a transaction is the sum of these two fees. Continue reading to learn more about exactly how each of these fee components are charged. -## Execution Gas Fee +## Execution gas fee A transaction's execution gas fee is exactly the same fee that you would pay for the same transaction on Ethereum. This fee is equal to the amount of gas used by the transaction multiplied by the gas price attached to the transaction. @@ -30,7 +30,7 @@ The only difference is that the gas price on OP Mainnet is much lower than the g For this component of the fee, you can estimate the total cost of a transaction using the same tools you would use to estimate the cost of a transaction on Ethereum. You can read more about how Ethereum's gas fees work over on [Ethereum.org](https://ethereum.org/en/developers/docs/gas/). -### Base Fee +### Base fee The [base fee](https://ethereum.org/en/developers/docs/gas/#base-fee) is the minimum price per unit of gas that a transaction must pay to be included in a block. Transactions must specify a maximum base fee higher than the block base fee to be included. @@ -40,7 +40,7 @@ The OP Mainnet base fee behaves exactly like the Ethereum base fee with a few sm None of these parameters should significantly impact your application, but you can read more about each of these parameters on the [OP Mainnet differences](/chain/differences#eip-1559) page. Read more about the base fee in the [Ethereum.org documentation](https://ethereum.org/en/developers/docs/gas/#base-fee). -### Priority Fee +### Priority fee Just like on Ethereum, OP Mainnet transactions can specify a **priority fee**. This priority fee is a price per unit of gas that is paid on top of the base fee. @@ -51,7 +51,7 @@ The priority fee is an optional component of the execution gas fee and can be se If transaction speed is important to your application, you may want to set a higher priority fee to ensure that your transaction is included more quickly. The [`eth_maxPriorityFeePerGas`](https://docs.alchemy.com/reference/eth-maxpriorityfeepergas) RPC method can be used to estimate a priority fee that will get your transaction included quickly. -## L1 Data Fee +## L1 data fee The L1 Data Fee is the only part of the OP Mainnet transaction fee that differs from the Ethereum transaction fee. This fee arises from the fact that the transaction data for all OP Mainnet transactions is published to Ethereum. @@ -210,7 +210,7 @@ The Sequencer Fee Vault collects and holds transaction fees paid to the sequence * **Vault Address**: The Sequencer Fee Vault is predeployed at the address `0x4200000000000000000000000000000000000011` on the OP Mainnet. * **Fee Usage**: Stored fees are eventually transferred to a designated recipient address (e.g., a treasury or distribution contract). -### How it Works +### How it works 1. **Fee Collection**: During the processing of transactions, the sequencer collects fees from users as part of their transaction costs. These fees are primarily used to cover the gas expenses of posting transaction data to Ethereum L1. 2. **Storage**: Collected fees are deposited into the Sequencer Fee Vault contract. @@ -218,7 +218,7 @@ The Sequencer Fee Vault collects and holds transaction fees paid to the sequence This system ensures effective fee management, maintaining the security and operation of the Optimism network. -## Next Steps +## Next steps * Read the [differences between Ethereum and OP Stack Chains](/stack/differences) guide. * Read the [L2 to L1 Transactions](/builders/app-developers/bridging/messaging#for-l1-to-l2-transactions) guide. diff --git a/pages/stack/protocol/rollup/forced-transaction.mdx b/pages/stack/transactions/forced-transaction.mdx similarity index 91% rename from pages/stack/protocol/rollup/forced-transaction.mdx rename to pages/stack/transactions/forced-transaction.mdx index a3b9694d9..bc293fd09 100644 --- a/pages/stack/protocol/rollup/forced-transaction.mdx +++ b/pages/stack/transactions/forced-transaction.mdx @@ -1,46 +1,46 @@ --- -title: Forced Transaction +title: Forced transaction lang: en-US description: Learn the forced transaction flow during sequencer downtime. --- import { Callout } from 'nextra/components' -## Forced Transaction Flow +## Forced transaction flow This guide explains the nuances of forced transactions during sequencer downtime. Users are able to force-include deposit transactions, which can initiate withdrawals, at any time. However, there are important nuances to understand about the chain derivation pipeline and sequencer behavior. -## Key Concepts +## Key concepts * **Sequencing Window**: A 12-hour rolling window to include L2 transactions, including native L2 transactions and deposit transactions. * **Max Time Drift**: 30 minutes, the maximum delay for including a deposit transaction, relative to the L2 chain. * **Sequencer Downtime**: Period when the sequencer is offline or not producing blocks. -## Normal Operation +## Normal operation Under normal circumstances: 1. Deposit transactions are included within 30 minutes. 2. The sequencer processes transactions and produces blocks regularly. -## Sequencer Downtime Scenarios +## Sequencer downtime scenarios -### Short Downtime (< 30 minutes) +### Short downtime (< 30 minutes) * Deposits are still included within the 30-minute max time drift. * Regular L2 transactions may be delayed. -### Extended Downtime (30 minutes to 12 hours) +### Extended downtime (30 minutes to 12 hours) 1. Deposits are force-included within 30 minutes. 2. The L2 chain state remains uncertain until: * The sequencer comes back online, or * The 12-hour sequencing window expires. -### Prolonged Downtime (> 12 hours) +### Prolonged downtime (> 12 hours) 1. After 12 hours, nodes start generating blocks deterministically. 2. These blocks only include deposit transactions. @@ -50,13 +50,13 @@ Under normal circumstances: -## Important Considerations +## Important considerations * Forced transactions, through deposits (no need for deposited value), ensure timely execution of actions, mitigating risks like DEX price divergence during sequencer downtime. * Actions remain speculative for up to 12 hours due to the sequencing window. * The 12-hour window is a balance between operational reliability and minimizing potential L2 reorganizations. -## Example Scenario +## Example scenario If a deposit is initiated after the 30-minute mark but before the sequencing window expires: diff --git a/pages/stack/protocol/rollup/transaction-flow.mdx b/pages/stack/transactions/transaction-flow.mdx similarity index 99% rename from pages/stack/protocol/rollup/transaction-flow.mdx rename to pages/stack/transactions/transaction-flow.mdx index 981a9e460..b076e5c4e 100644 --- a/pages/stack/protocol/rollup/transaction-flow.mdx +++ b/pages/stack/transactions/transaction-flow.mdx @@ -6,7 +6,7 @@ description: Learn the transaction flow process for rollup transactions. import { Callout } from 'nextra/components' -# Transaction Flow +# Transaction flow This guide explains the transaction flow process for rollup transactions. The process for a rollup transaction has two requirements. diff --git a/pages/stack/protocol/rollup/withdrawal-flow.mdx b/pages/stack/transactions/withdrawal-flow.mdx similarity index 96% rename from pages/stack/protocol/rollup/withdrawal-flow.mdx rename to pages/stack/transactions/withdrawal-flow.mdx index dd2ae78b6..14cac6fce 100644 --- a/pages/stack/protocol/rollup/withdrawal-flow.mdx +++ b/pages/stack/transactions/withdrawal-flow.mdx @@ -1,12 +1,12 @@ --- -title: Withdrawal Flow +title: Withdrawal flow lang: en-US description: Learn the withdrawal flow process for transactions sent from L2 to L1. --- import { Callout } from 'nextra/components' -# Withdrawal Flow +# Withdrawal flow In Optimism terminology, a *withdrawal* is a transaction sent from L2 (OP Mainnet, OP Sepolia etc.) to L1 (Ethereum mainnet, Sepolia, etc.). @@ -79,27 +79,22 @@ The next step is to wait the fault challenge period, to ensure that the L2 outpu Finally, once the fault challenge period passes, the withdrawal can be finalized and executed on L1. -## Expected Internal Reverts in Withdrawal Transactions +## Expected internal reverts in withdrawal transactions During the withdrawal process, users may observe internal reverts when viewing the transaction on **Etherscan**. This is a common point of confusion but is expected behavior. These internal reverts often show up in yellow on the Etherscan UI and may cause concern that something went wrong with the transaction. However, these reverts occur due to the non-standard proxy used in Optimism, specifically the **Chugsplash Proxy**. The Chugsplash Proxy sometimes triggers internal calls that revert as part of the designed flow of the withdrawal process. -### Why Do These Reverts Happen? +### Why do these reverts happen? The Chugsplash Proxy operates differently than standard proxies. During a withdrawal transaction, it may trigger internal contract calls that result in reverts, but these reverts do not indicate that the withdrawal has failed. Instead, they are part of the internal logic of the system and are expected in certain scenarios. -### Key Takeaways: +### Key takeaways: * **Internal Reverts Are Expected**: These reverts are part of the normal operation of the Chugsplash Proxy during withdrawal transactions and do not represent an error. * **No Cause for Concern**: Although Etherscan highlights these reverts, they do not affect the final success of the transaction. * **User Assurance**: If you encounter these reverts during a withdrawal transaction, rest assured that the withdrawal will still finalize as expected. -For more information about the withdrawal process and how it works on Optimism, refer to the following resources: - -* [Smart Contracts Overview](https://docs.optimism.io/stack/protocol/rollup/smart-contracts) -* [Withdrawal Flow](https://docs.optimism.io/stack/protocol/rollup/withdrawal-flow#withdrawal-initiating-transaction) - ### Offchain processing 1. A user calls the SDK's [`CrossDomainMessenger.finalizeMessage()`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/sdk/src/cross-chain-messenger.ts#L1473-L1493) with the hash of the L1 message. diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml index 1fbf39bdc..92dd2f1bc 100644 --- a/pnpm-lock.yaml +++ b/pnpm-lock.yaml @@ -30,7 +30,7 @@ importers: version: 0.3.4(react@18.3.1) '@headlessui/react': specifier: ^2.1.8 - version: 2.1.8(react-dom@18.3.1(react@18.3.1))(react@18.3.1) + version: 2.1.10(react-dom@18.3.1(react@18.3.1))(react@18.3.1) algoliasearch: specifier: ^4.23.3 version: 4.23.3 @@ -60,7 +60,7 @@ importers: version: 18.3.1(react@18.3.1) search-insights: specifier: ^2.15.0 - version: 2.15.0 + version: 2.17.2 devDependencies: '@double-great/remark-lint-alt-text': specifier: ^1.0.0 @@ -570,26 +570,26 @@ packages: peerDependencies: react: '>=17' - '@floating-ui/core@1.6.8': - resolution: {integrity: sha512-7XJ9cPU+yI2QeLS+FCSlqNFZJq8arvswefkZrYI1yQBbftw6FyrZOxYSh+9S7z7TpeWlRt9zJ5IhM1WIL334jA==} + '@floating-ui/core@1.6.2': + resolution: {integrity: sha512-+2XpQV9LLZeanU4ZevzRnGFg2neDeKHgFLjP6YLW+tly0IvrhqT4u8enLGjLH3qeh85g19xY5rsAusfwTdn5lg==} - '@floating-ui/dom@1.6.11': - resolution: {integrity: sha512-qkMCxSR24v2vGkhYDo/UzxfJN3D4syqSjyuTFz6C7XcpU1pASPRieNI0Kj5VP3/503mOfYiGY891ugBX1GlABQ==} + '@floating-ui/dom@1.6.5': + resolution: {integrity: sha512-Nsdud2X65Dz+1RHjAIP0t8z5e2ff/IRbei6BqFrl1urT8sDVzM1HMQ+R0XcU5ceRfyO3I6ayeqIfh+6Wb8LGTw==} - '@floating-ui/react-dom@2.1.2': - resolution: {integrity: sha512-06okr5cgPzMNBy+Ycse2A6udMi4bqwW/zgBF/rwjcNqWkyr82Mcg8b0vjX8OJpZFy/FKjJmw6wV7t44kK6kW7A==} + '@floating-ui/react-dom@2.1.0': + resolution: {integrity: sha512-lNzj5EQmEKn5FFKc04+zasr09h/uX8RtJRNj5gUXsSQIXHVWTVh+hVAg1vOMCexkX8EgvemMvIFpQfkosnVNyA==} peerDependencies: react: '>=16.8.0' react-dom: '>=16.8.0' - '@floating-ui/react@0.26.24': - resolution: {integrity: sha512-2ly0pCkZIGEQUq5H8bBK0XJmc1xIK/RM3tvVzY3GBER7IOD1UgmC2Y2tjj4AuS+TC+vTE1KJv2053290jua0Sw==} + '@floating-ui/react@0.26.17': + resolution: {integrity: sha512-ESD+jYWwqwVzaIgIhExrArdsCL1rOAzryG/Sjlu8yaD3Mtqi3uVyhbE2V7jD58Mo52qbzKz2eUY/Xgh5I86FCQ==} peerDependencies: react: '>=16.8.0' react-dom: '>=16.8.0' - '@floating-ui/utils@0.2.8': - resolution: {integrity: sha512-kym7SodPp8/wloecOpcmSnWJsK7M0E5Wg8UcFA+uO4B9s5d0ywXOEro/8HM9x0rW+TljRzul/14UYz3TleT3ig==} + '@floating-ui/utils@0.2.2': + resolution: {integrity: sha512-J4yDIIthosAsRZ5CPYP/jQvUAQtlZTTD/4suA08/FEnlxqW3sKS9iAhgsa9VYLZ6vDHn/ixJgIqRQPotoBjxIw==} '@headlessui/react@1.7.19': resolution: {integrity: sha512-Ll+8q3OlMJfJbAKM/+/Y2q6PPYbryqNTXDbryx7SXLIDamkF6iQFbriYHga0dY44PvDhvvBWCx1Xj4U5+G4hOw==} @@ -598,8 +598,8 @@ packages: react: ^16 || ^17 || ^18 react-dom: ^16 || ^17 || ^18 - '@headlessui/react@2.1.8': - resolution: {integrity: sha512-uajqVkAcVG/wHwG9Fh5PFMcFpf2VxM4vNRNKxRjuK009kePVur8LkuuygHfIE+2uZ7z7GnlTtYsyUe6glPpTLg==} + '@headlessui/react@2.1.10': + resolution: {integrity: sha512-6mLa2fjMDAFQi+/R10B+zU3edsUk/MDtENB2zHho0lqKU1uzhAfJLUduWds4nCo8wbl3vULtC5rJfZAQ1yqIng==} engines: {node: '>=10'} peerDependencies: react: ^18 @@ -816,36 +816,36 @@ packages: '@popperjs/core@2.11.8': resolution: {integrity: sha512-P1st0aksCrn9sGZhp8GMYwBnQsbvAWsZAX44oXNNvLHGqAOcoVxmjZiohstwQ7SqKnbR47akdNi+uleWD8+g6A==} - '@react-aria/focus@3.18.2': - resolution: {integrity: sha512-Jc/IY+StjA3uqN73o6txKQ527RFU7gnG5crEl5Xy3V+gbYp2O5L3ezAo/E0Ipi2cyMbG6T5Iit1IDs7hcGu8aw==} + '@react-aria/focus@3.17.1': + resolution: {integrity: sha512-FLTySoSNqX++u0nWZJPPN5etXY0WBxaIe/YuL/GTEeuqUIuC/2bJSaw5hlsM6T2yjy6Y/VAxBcKSdAFUlU6njQ==} peerDependencies: - react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0 + react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 - '@react-aria/interactions@3.22.2': - resolution: {integrity: sha512-xE/77fRVSlqHp2sfkrMeNLrqf2amF/RyuAS6T5oDJemRSgYM3UoxTbWjucPhfnoW7r32pFPHHgz4lbdX8xqD/g==} + '@react-aria/interactions@3.21.3': + resolution: {integrity: sha512-BWIuf4qCs5FreDJ9AguawLVS0lV9UU+sK4CCnbCNNmYqOWY+1+gRXCsnOM32K+oMESBxilAjdHW5n1hsMqYMpA==} peerDependencies: - react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0 + react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 - '@react-aria/ssr@3.9.5': - resolution: {integrity: sha512-xEwGKoysu+oXulibNUSkXf8itW0npHHTa6c4AyYeZIJyRoegeteYuFpZUBPtIDE8RfHdNsSmE1ssOkxRnwbkuQ==} + '@react-aria/ssr@3.9.4': + resolution: {integrity: sha512-4jmAigVq409qcJvQyuorsmBR4+9r3+JEC60wC+Y0MZV0HCtTmm8D9guYXlJMdx0SSkgj0hHAyFm/HvPNFofCoQ==} engines: {node: '>= 12'} peerDependencies: - react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0 + react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 - '@react-aria/utils@3.25.2': - resolution: {integrity: sha512-GdIvG8GBJJZygB4L2QJP1Gabyn2mjFsha73I2wSe+o4DYeGWoJiMZRM06PyTIxLH4S7Sn7eVDtsSBfkc2VY/NA==} + '@react-aria/utils@3.24.1': + resolution: {integrity: sha512-O3s9qhPMd6n42x9sKeJ3lhu5V1Tlnzhu6Yk8QOvDuXf7UGuUjXf9mzfHJt1dYzID4l9Fwm8toczBzPM9t0jc8Q==} peerDependencies: - react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0 + react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 - '@react-stately/utils@3.10.3': - resolution: {integrity: sha512-moClv7MlVSHpbYtQIkm0Cx+on8Pgt1XqtPx6fy9rQFb2DNc9u1G3AUVnqA17buOkH1vLxAtX4MedlxMWyRCYYA==} + '@react-stately/utils@3.10.1': + resolution: {integrity: sha512-VS/EHRyicef25zDZcM/ClpzYMC5i2YGN6uegOeQawmgfGjb02yaCX0F0zR69Pod9m2Hr3wunTbtpgVXvYbZItg==} peerDependencies: - react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0 + react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 - '@react-types/shared@3.24.1': - resolution: {integrity: sha512-AUQeGYEm/zDTN6zLzdXolDxz3Jk5dDL7f506F07U8tBwxNNI3WRdhU84G0/AaFikOZzDXhOZDr3MhQMzyE7Ydw==} + '@react-types/shared@3.23.1': + resolution: {integrity: sha512-5d+3HbFDxGZjhbMBeFHRQhexMFt4pUce3okyRtUVKbbedQFUrtXSBg9VszgF2RTeQDKDkMCIQDtz5ccP/Lk1gw==} peerDependencies: - react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0 + react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 '@scure/base@1.1.6': resolution: {integrity: sha512-ok9AWwhcgYuGG3Zfhyqg+zwl+Wn5uE+dwC0NV/2qQkx4dABbb/bx96vWu8NSj+BNjjSjno+JRYRjle1jV08k3g==} @@ -1135,8 +1135,8 @@ packages: brace-expansion@2.0.1: resolution: {integrity: sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==} - braces@3.0.3: - resolution: {integrity: sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==} + braces@3.0.2: + resolution: {integrity: sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==} engines: {node: '>=8'} brorand@1.1.0: @@ -1567,8 +1567,8 @@ packages: dom-accessibility-api@0.5.16: resolution: {integrity: sha512-X7BJ2yElsnOJ30pZF4uIIDfBEVgF4XEBxL9Bxhy6dnrm5hkzqmsWHGTiHqRiITNhMyFLyAiWndIJP7Z1NTteDg==} - dompurify@3.1.7: - resolution: {integrity: sha512-VaTstWtsneJY8xzy7DekmYWEOZcmzIe3Qb3zPd4STve1OBTa+e+WmS1ITQec1fZYXI3HCsOZZiSMpG6oxoWMWQ==} + dompurify@3.1.6: + resolution: {integrity: sha512-cTOAhc36AalkjtBpfG6O8JimdTMWNXjiePT2xQH/ppBGi/4uIpmj8eKyIkMJErXWARyINV/sB38yf8JCLF5pbQ==} dot-case@3.0.4: resolution: {integrity: sha512-Kv5nKlh6yRrdrGvxeJ2e5y2eRUpkUosIW4A2AS38zwSz27zu7ufDwQPi5Jhs3XAlGNetl3bmnGhQsMtkKJnj3w==} @@ -1760,8 +1760,8 @@ packages: resolution: {integrity: sha512-XXTUwCvisa5oacNGRP9SfNtYBNAMi+RPwBFmblZEF7N7swHYQS6/Zfk7SRwx4D5j3CH211YNRco1DEMNVfZCnQ==} engines: {node: '>=16.0.0'} - fill-range@7.1.1: - resolution: {integrity: sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==} + fill-range@7.0.1: + resolution: {integrity: sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==} engines: {node: '>=8'} find-up-simple@1.0.0: @@ -2421,8 +2421,8 @@ packages: resolution: {integrity: sha512-LJKTl4iVNTndhL+3Uz/tfkjD0klIWsHlUzgtuNnNrsf7bAlXR30m+xYB7lHr5Z/l6e/yAIsr26Dabx6Buo4VGQ==} engines: {node: '>= 7.6.0'} - mermaid@10.9.0: - resolution: {integrity: sha512-swZju0hFox/B/qoLKK0rOxxgh8Cf7rJSfAUc1u8fezVihYMvrJAS45GzAxTVf4Q+xn9uMgitBcmWk7nWGXOs/g==} + mermaid@10.9.3: + resolution: {integrity: sha512-V80X1isSEvAewIL3xhmz/rVmc27CVljcsbWxkxlWJWY/1kQa4XOABqpDl2qQLGKzpKm6WbTfUEKImBlUfFYArw==} micro-ftch@0.3.1: resolution: {integrity: sha512-/0LLxhzP0tfiR5hcQebtudP56gUurs2CLkGarnCiB/OqEyUFQ6U3paQi/tgLv0hBJYt2rnr9MNpxz4fiiugstg==} @@ -2604,8 +2604,8 @@ packages: micromark@4.0.0: resolution: {integrity: sha512-o/sd0nMof8kYff+TqcDx3VSrgBTcZpSvYcAHIfHhv5VAuNmisCxjhx6YmxS8PFEpb9z5WKWKPdzf0jM23ro3RQ==} - micromatch@4.0.8: - resolution: {integrity: sha512-PXwfBhYu0hBCPw8Dn0E+WDYb7af3dSLVWKi3HGv84IdF4TyFoC0ysxFd0Goxw7nSv4T/PzEJQxsYsEiFCKo2BA==} + micromatch@4.0.5: + resolution: {integrity: sha512-DMy+ERcEW2q8Z2Po+WNXuw3c5YaUSFjAO5GsJqfEl7UjvtIuFKO6ZrKvcItdy98dwFI2N1tg3zNIdKaQT+aNdA==} engines: {node: '>=8.6'} min-indent@1.0.1: @@ -3156,8 +3156,8 @@ packages: scrypt-js@3.0.1: resolution: {integrity: sha512-cdwTTnqPu0Hyvf5in5asVdZocVDTNRmR7XEcJuIzMjJeSHybHl7vpB66AzwTaIg6CLSbtjcxc8fqcySfnTkccA==} - search-insights@2.15.0: - resolution: {integrity: sha512-ch2sPCUDD4sbPQdknVl9ALSi9H7VyoeVbsxznYz6QV55jJ8CI3EtwpO1i84keN4+hF5IeHWIeGvc08530JkVXQ==} + search-insights@2.17.2: + resolution: {integrity: sha512-zFNpOpUO+tY2D85KrxJ+aqwnIfdEGi06UH2+xEb+Bp9Mwznmauqc9djbnBibJO5mpfUPPa8st6Sx65+vbeO45g==} section-matter@1.0.0: resolution: {integrity: sha512-vfD3pmTzGpufjScBh50YHKzEu2lxBWhVEHsNGoEXmCmn2hKGfeNLYMzCJpe8cD7gqX7TJluOVpBkAequ6dgMmA==} @@ -4355,30 +4355,30 @@ snapshots: '@feelback/js': 0.3.4 react: 18.3.1 - '@floating-ui/core@1.6.8': + '@floating-ui/core@1.6.2': dependencies: - '@floating-ui/utils': 0.2.8 + '@floating-ui/utils': 0.2.2 - '@floating-ui/dom@1.6.11': + '@floating-ui/dom@1.6.5': dependencies: - '@floating-ui/core': 1.6.8 - '@floating-ui/utils': 0.2.8 + '@floating-ui/core': 1.6.2 + '@floating-ui/utils': 0.2.2 - '@floating-ui/react-dom@2.1.2(react-dom@18.3.1(react@18.3.1))(react@18.3.1)': + '@floating-ui/react-dom@2.1.0(react-dom@18.3.1(react@18.3.1))(react@18.3.1)': dependencies: - '@floating-ui/dom': 1.6.11 + '@floating-ui/dom': 1.6.5 react: 18.3.1 react-dom: 18.3.1(react@18.3.1) - '@floating-ui/react@0.26.24(react-dom@18.3.1(react@18.3.1))(react@18.3.1)': + '@floating-ui/react@0.26.17(react-dom@18.3.1(react@18.3.1))(react@18.3.1)': dependencies: - '@floating-ui/react-dom': 2.1.2(react-dom@18.3.1(react@18.3.1))(react@18.3.1) - '@floating-ui/utils': 0.2.8 + '@floating-ui/react-dom': 2.1.0(react-dom@18.3.1(react@18.3.1))(react@18.3.1) + '@floating-ui/utils': 0.2.2 react: 18.3.1 react-dom: 18.3.1(react@18.3.1) tabbable: 6.2.0 - '@floating-ui/utils@0.2.8': {} + '@floating-ui/utils@0.2.2': {} '@headlessui/react@1.7.19(react-dom@18.3.1(react@18.3.1))(react@18.3.1)': dependencies: @@ -4387,11 +4387,11 @@ snapshots: react: 18.3.1 react-dom: 18.3.1(react@18.3.1) - '@headlessui/react@2.1.8(react-dom@18.3.1(react@18.3.1))(react@18.3.1)': + '@headlessui/react@2.1.10(react-dom@18.3.1(react@18.3.1))(react@18.3.1)': dependencies: - '@floating-ui/react': 0.26.24(react-dom@18.3.1(react@18.3.1))(react@18.3.1) - '@react-aria/focus': 3.18.2(react@18.3.1) - '@react-aria/interactions': 3.22.2(react@18.3.1) + '@floating-ui/react': 0.26.17(react-dom@18.3.1(react@18.3.1))(react@18.3.1) + '@react-aria/focus': 3.17.1(react@18.3.1) + '@react-aria/interactions': 3.21.3(react@18.3.1) '@tanstack/react-virtual': 3.10.8(react-dom@18.3.1(react@18.3.1))(react@18.3.1) react: 18.3.1 react-dom: 18.3.1(react@18.3.1) @@ -4578,43 +4578,43 @@ snapshots: '@popperjs/core@2.11.8': {} - '@react-aria/focus@3.18.2(react@18.3.1)': + '@react-aria/focus@3.17.1(react@18.3.1)': dependencies: - '@react-aria/interactions': 3.22.2(react@18.3.1) - '@react-aria/utils': 3.25.2(react@18.3.1) - '@react-types/shared': 3.24.1(react@18.3.1) + '@react-aria/interactions': 3.21.3(react@18.3.1) + '@react-aria/utils': 3.24.1(react@18.3.1) + '@react-types/shared': 3.23.1(react@18.3.1) '@swc/helpers': 0.5.2 clsx: 2.1.1 react: 18.3.1 - '@react-aria/interactions@3.22.2(react@18.3.1)': + '@react-aria/interactions@3.21.3(react@18.3.1)': dependencies: - '@react-aria/ssr': 3.9.5(react@18.3.1) - '@react-aria/utils': 3.25.2(react@18.3.1) - '@react-types/shared': 3.24.1(react@18.3.1) + '@react-aria/ssr': 3.9.4(react@18.3.1) + '@react-aria/utils': 3.24.1(react@18.3.1) + '@react-types/shared': 3.23.1(react@18.3.1) '@swc/helpers': 0.5.2 react: 18.3.1 - '@react-aria/ssr@3.9.5(react@18.3.1)': + '@react-aria/ssr@3.9.4(react@18.3.1)': dependencies: '@swc/helpers': 0.5.2 react: 18.3.1 - '@react-aria/utils@3.25.2(react@18.3.1)': + '@react-aria/utils@3.24.1(react@18.3.1)': dependencies: - '@react-aria/ssr': 3.9.5(react@18.3.1) - '@react-stately/utils': 3.10.3(react@18.3.1) - '@react-types/shared': 3.24.1(react@18.3.1) + '@react-aria/ssr': 3.9.4(react@18.3.1) + '@react-stately/utils': 3.10.1(react@18.3.1) + '@react-types/shared': 3.23.1(react@18.3.1) '@swc/helpers': 0.5.2 clsx: 2.1.1 react: 18.3.1 - '@react-stately/utils@3.10.3(react@18.3.1)': + '@react-stately/utils@3.10.1(react@18.3.1)': dependencies: '@swc/helpers': 0.5.2 react: 18.3.1 - '@react-types/shared@3.24.1(react@18.3.1)': + '@react-types/shared@3.23.1(react@18.3.1)': dependencies: react: 18.3.1 @@ -4690,7 +4690,7 @@ snapshots: '@theguild/remark-mermaid@0.0.5(react@18.3.1)': dependencies: - mermaid: 10.9.0 + mermaid: 10.9.3 react: 18.3.1 unist-util-visit: 5.0.0 transitivePeerDependencies: @@ -4911,9 +4911,9 @@ snapshots: dependencies: balanced-match: 1.0.2 - braces@3.0.3: + braces@3.0.2: dependencies: - fill-range: 7.1.1 + fill-range: 7.0.1 brorand@1.1.0: {} @@ -5132,7 +5132,7 @@ snapshots: cspell-glob@8.7.0: dependencies: - micromatch: 4.0.8 + micromatch: 4.0.5 cspell-grammar@8.7.0: dependencies: @@ -5446,7 +5446,7 @@ snapshots: dom-accessibility-api@0.5.16: {} - dompurify@3.1.7: {} + dompurify@3.1.6: {} dot-case@3.0.4: dependencies: @@ -5727,7 +5727,7 @@ snapshots: '@nodelib/fs.walk': 1.2.8 glob-parent: 5.1.2 merge2: 1.4.1 - micromatch: 4.0.8 + micromatch: 4.0.5 fast-json-stable-stringify@2.1.0: {} @@ -5749,7 +5749,7 @@ snapshots: dependencies: flat-cache: 4.0.1 - fill-range@7.1.1: + fill-range@7.0.1: dependencies: to-regex-range: 5.0.1 @@ -6584,7 +6584,7 @@ snapshots: treeify: 1.1.0 web3-utils: 1.10.4 - mermaid@10.9.0: + mermaid@10.9.3: dependencies: '@braintree/sanitize-url': 6.0.4 '@types/d3-scale': 4.0.8 @@ -6595,7 +6595,7 @@ snapshots: d3-sankey: 0.12.3 dagre-d3-es: 7.0.10 dayjs: 1.11.11 - dompurify: 3.1.7 + dompurify: 3.1.6 elkjs: 0.9.3 katex: 0.16.10 khroma: 2.1.0 @@ -7032,9 +7032,9 @@ snapshots: transitivePeerDependencies: - supports-color - micromatch@4.0.8: + micromatch@4.0.5: dependencies: - braces: 3.0.3 + braces: 3.0.2 picomatch: 2.3.1 min-indent@1.0.1: {} @@ -7893,7 +7893,7 @@ snapshots: scrypt-js@3.0.1: {} - search-insights@2.15.0: {} + search-insights@2.17.2: {} section-matter@1.0.0: dependencies: diff --git a/public/_redirects b/public/_redirects index 89f0ac83c..d586cee18 100644 --- a/public/_redirects +++ b/public/_redirects @@ -62,21 +62,43 @@ /transaction-fees/overview /builders/app-developers/transactions/fees /dapp-developers/contracts/meta-tx /builders/app-developers/contracts/optimization /builders/tools/build/overview /builders/tools/overview -/protocol-specifications/optimistic-rollup/block-production /stack/protocol/rollup/overview#block-production +/protocol-specifications/optimistic-rollup/block-production /stack/rollup/overview#block-production /builders/node-operators/metrics /builders/node-operators/management/metrics /stack /stack/getting-started /chain/sec /chain/security/faq /builders/chain-operators/management/tools/explorer /builders/chain-operators/tools/explorer /builders/node-operators/management/configuration /builders/node-operators/configuration/base-config -/stack/protocol/deposit-flow /stack/protocol/rollup/deposit-flow -/stack/protocol/transaction-flow /stack/protocol/rollup/transaction-flow -/stack/protocol/withdrawal-flow /stack/protocol/rollup/withdrawal-flow -/stack/protocol/smart-contracts /stack/protocol/rollup/smart-contracts -/stack/protocol/overview /stack/protocol/rollup/overview +/stack/protocol/deposit-flow /stack/transactions/deposit-flow +/stack/protocol/transaction-flow /stack/transactions/transaction-flow +/stack/protocol/withdrawal-flow /stack/transactions/withdrawal-flow +/stack/protocol/smart-contracts /stack/smart-contracts +/stack/protocol/overview /stack/rollup/overview /stack/protocol/design-principles /stack/design-principles /builders/node-operators/overview /builders/node-operators/rollup-node /builders/notices/ecotone-changes /stack/transactions/fees#ecotone -/stack/protocol/fault-proofs/overview /stack/protocol/fault-proofs/explainer +/stack/protocol/fault-proofs/overview /stack/fault-proofs/explainer /builders/chain-operators/management/configuration /builders/chain-operators/configuration/overview /builders/chain-operators/management/custom-gas-token /builders/chain-operators/features/custom-gas-token -/stack/protocol/rollup/smart-contracts /stack/smart-contracts \ No newline at end of file +/stack/protocol/rollup/smart-contracts /stack/smart-contracts +/stack/protocol/fault-proofs/challenger /stack/fault-proofs/challenger +/stack/protocol/fault-proofs/fp-security /stack/fault-proofs/fp-security +/stack/protocol/fault-proofs/mips /stack/fault-proofs/mips +/stack/protocol/fault-proofs/fp-components /stack/fault-proofs/fp-components +/stack/protocol/fault-proofs/explainer /stack/fault-proofs/explainer +/stack/protocol/fault-proofs/cannon /stack/fault-proofs/cannon +/stack/protocol/interop/supersim /stack/interop/supersim +/stack/protocol/interop/superchain-erc20 /stack/interop/superchain-erc20 +/stack/protocol/interop/explainer /stack/interop/explainer +/stack/protocol/interop/cross-chain-message /stack/interop/cross-chain-message +/stack/protocol/features/alt-da-mode /stack/beta-features/alt-da-mode +/stack/protocol/features/custom-gas-token /stack/beta-features/custom-gas-token +/stack/protocol/features/send-raw-transaction-conditional /stack/features/send-raw-transaction-conditional +/stack/protocol/derivation-pipeline /stack/rollup/derivation-pipeline +/stack/protocol/rollup/overview /stack/rollup/overview +/stack/protocol/rollup/withdrawal-flow /stack/transactions/withdrawal-flow +/stack/protocol/rollup/forced-transaction /stack/transactions/forced-transaction +/stack/protocol/rollup/transaction-flow /stack/transactions/transaction-flow +/stack/protocol/rollup/deposit-flow /stack/transactions/deposit-flow +/stack/protocol/outages /stack/rollup/outages +/stack/operators/features/op-txproxy /builders/chain-operators/tools/op-txproxy +/stack/operators/features/proxyd /builders/chain-operators/tools/proxyd \ No newline at end of file diff --git a/theme.config.tsx b/theme.config.tsx index b720e1a0e..1200969a0 100644 --- a/theme.config.tsx +++ b/theme.config.tsx @@ -31,7 +31,7 @@ const config: DocsThemeConfig = { banner: { key: 'viem/op-stack', text: ( - + 🎉 We are deprecating the Optimism SDK and migrating all tutorials to use viem/op-stack. Read more → ) diff --git a/words.txt b/words.txt index cc52b0867..82df8e4de 100644 --- a/words.txt +++ b/words.txt @@ -9,12 +9,14 @@ airgap Allnodes Allocs allocs +altda ANDI Apeworx Arweave authrpc Badgeholder's Badgeholders +badgeholders basefee BGEZ BGTZ @@ -37,7 +39,6 @@ blocktime BLOOMFILTER bloomfilter BLTZ -Bluesweep Bootcamp BOOTNODES Bootnodes @@ -64,6 +65,7 @@ computependingblock confs corsdomain counterfactually +crosschain Crossmint daserver DATACAP @@ -109,6 +111,7 @@ Faultproof FDLIMIT fdlimit featureset +Flashbots forkable forkchoice FPVM @@ -167,7 +170,6 @@ leveldb lightkdf logfile logfmt -marketshare MAXAGE maxage MAXBACKUPS @@ -202,6 +204,7 @@ MTHI MTLO MULT multiaddr +multichain multiclient multisigs MULTU @@ -258,6 +261,7 @@ POAPs PPROF pprof preconfigured +Predeploy predeploy Predeployed predeployed @@ -298,7 +302,7 @@ replayability reproven REQUIREDBLOCKS requiredblocks -Rollouts +rollouts Rollups rollups Routescan @@ -345,6 +349,8 @@ superchain Superchain's Superchains Superscan +Supersim +supersim SYNCMODE syncmode SYNCTARGET @@ -362,6 +368,7 @@ txfeecap txmgr TXPOOL txpool +txproxy uncountered Unprotect unsubmitted