diff --git a/components/calculator/ChainParametersForm.tsx b/components/calculator/ChainParametersForm.tsx index 04c7d0d35..bfbbfe6e1 100644 --- a/components/calculator/ChainParametersForm.tsx +++ b/components/calculator/ChainParametersForm.tsx @@ -23,7 +23,7 @@ type DataAvailabilityType = "Ethereum" | "AltDA Plasma Mode"; export function ChainParametersForm(): ReactElement { const [transactionsPerDay, setTransactionsPerDay] = useState(500000); const [comparableTransactionType, setComparableTransactionType] = - useState("General OP Mainnet"); + useState("General Metal L2"); const [dataAvailabilityType, setDataAvailabilityType] = useState("Ethereum"); const [isFaultProofEnabled, setIsFaultProofEnabled] = useState("yes"); const [targetDataFeeMargin, setTargetDataFeeMargin] = useState(5); @@ -36,7 +36,7 @@ export function ChainParametersForm(): ReactElement { const [showResult, setShowResult] = useState(false); const comparableTransactionTypeOptions = [ - "General OP Mainnet", + "General Metal L2", "Base", "Zora", "Mint", diff --git a/nouns.txt b/nouns.txt index be98afea6..c4c16624a 100644 --- a/nouns.txt +++ b/nouns.txt @@ -1,5 +1,5 @@ Optimism -OP Mainnet +Metal L2 Ethereum OP Stack MetaMask diff --git a/pages/_meta.json b/pages/_meta.json index e33c96e0d..d04ae8af4 100644 --- a/pages/_meta.json +++ b/pages/_meta.json @@ -92,7 +92,7 @@ }, "chain": { - "title": "OP Mainnet", + "title": "Metal L2", "display": "children" }, diff --git a/pages/builders/app-developers/bridging/custom-bridge.mdx b/pages/builders/app-developers/bridging/custom-bridge.mdx index e0e60e2c4..c6acc5252 100644 --- a/pages/builders/app-developers/bridging/custom-bridge.mdx +++ b/pages/builders/app-developers/bridging/custom-bridge.mdx @@ -1,7 +1,7 @@ --- title: Custom bridges lang: en-US -description: Important considerations when building custom bridges for OP Mainnet. +description: Important considerations when building custom bridges for Metal L2. --- import { Callout } from 'nextra/components' @@ -33,12 +33,5 @@ You can read more about the design of the Standard Bridge in the guide on [Using The [Superchain Token List](/chain/tokenlist) exists to help users and developers find the right bridged representations of tokens native to another blockchain. 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. +You **must** deploy your bridge to Metal L2 Testnet before it can be added to the Superchain Token List. -## Next steps - -You can explore several examples of custom bridges for OP Mainnet: - -* [NFT Bridge](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/L1/L1ERC721Bridge.sol) -* [L2 DAI Token Bridge](https://optimistic.etherscan.io/address/0x467194771dae2967aef3ecbedd3bf9a310c76c65#code) and [deployed addresses](https://github.com/ethereum-optimism/ethereum-optimism.github.io/blob/master/data/DAI/data.json) -* [SNX Bridge](https://github.com/ethereum-optimism/ethereum-optimism.github.io/blob/master/data/SNX/data.json) diff --git a/pages/builders/app-developers/bridging/messaging.mdx b/pages/builders/app-developers/bridging/messaging.mdx index 796339862..b77b684b2 100644 --- a/pages/builders/app-developers/bridging/messaging.mdx +++ b/pages/builders/app-developers/bridging/messaging.mdx @@ -8,7 +8,7 @@ import { Callout } from 'nextra/components' # 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". +Smart contracts on L1 (Ethereum) can interact with smart contracts on L2 (Metal L2) through a process called "bridging". This page explains how bridging works, how to use it, and what to watch out for. @@ -18,8 +18,8 @@ This page explains how bridging works, how to use it, and what to watch out for. ## 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. +It can be easier to understand bridging if you first have a basic understanding of how contracts on EVM-based blockchains like Metal L2 and Ethereum communicate within the *same* network. +The interface for sending messages *between* Ethereum and Metal L2 is designed to mimic the standard contract communication interface as much as possible. Here's how a contract on Ethereum might trigger a function within another contract on Ethereum: @@ -89,7 +89,7 @@ address(_target).call{gas: _minGasLimit}(_message); Except, of course, that you're calling a contract on a completely different network. This is glossing over a lot of the technical details that make this whole thing work under the hood, but this should be enough to get you started. -Want to call a contract on OP Mainnet from a contract on Ethereum? +Want to call a contract on Metal L2 from a contract on Ethereum? It's dead simple: ```solidity @@ -118,22 +118,22 @@ 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. + You can find the addresses of the `L1CrossDomainMessenger` and the `L2CrossDomainMessenger` contracts on Metal L2 and Metal L2 Testnet on the [Contract Addresses](/chain/addresses) page. ## Communication speed -Unlike calls between contracts on the same blockchain, calls between Ethereum and OP Mainnet are *not* instantaneous. +Unlike calls between contracts on the same blockchain, calls between Ethereum and Metal L2 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 -Transactions sent from L1 to L2 take **approximately 1-3 minutes** to get from Ethereum to OP Mainnet, or from Sepolia to OP Sepolia. +Transactions sent from L1 to L2 take **approximately 1-3 minutes** to get from Ethereum to Metal L2, or from Sepolia to Metal L2 Testnet. 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 -Transactions sent from L2 to L1 take **approximately 7 days** to get from OP Mainnet to Ethereum, or from OP Sepolia to Sepolia. +Transactions sent from L2 to L1 take **approximately 7 days** to get from Metal L2 to Ethereum, or from Metal L2 Testnet 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. The process of sending transactions from L2 to L1 involves four distinct steps: @@ -199,7 +199,7 @@ The amount of L1 gas charged increases when more people are sending L1 to L2 tra Each message from L2 to L1 requires three transactions: -1. An L2 transaction that *initiates* the transaction, which is priced the same as any other transaction made on OP Mainnet. +1. An L2 transaction that *initiates* the transaction, which is priced the same as any other transaction made on Metal L2. 2. An L1 transaction that *proves* the transaction. This transaction can only be submitted after L2 block, including your L2 transaction, is proposed on L1. diff --git a/pages/builders/app-developers/bridging/standard-bridge.mdx b/pages/builders/app-developers/bridging/standard-bridge.mdx index ff9d7c467..c5f460b75 100644 --- a/pages/builders/app-developers/bridging/standard-bridge.mdx +++ b/pages/builders/app-developers/bridging/standard-bridge.mdx @@ -8,10 +8,10 @@ import { Callout, Steps } from 'nextra/components' # Using the Standard Bridge -The Standard Bridge is a basic token bridging system available on OP Mainnet and all other standard OP Stack chains. -The Standard Bridge allows you to easily move ETH and most ERC-20 tokens between Ethereum and OP Mainnet. -Transfers from Ethereum to OP Mainnet via the Standard Bridge are usually completed within 1-3 minutes. -Transfers from OP Mainnet to Ethereum are completed in 7 days as a result of the [withdrawal challenge period](./messaging#understanding-the-challenge-period). +The Standard Bridge is a basic token bridging system available on Metal L2 and all other standard OP Stack chains. +The Standard Bridge allows you to easily move ETH and most ERC-20 tokens between Ethereum and Metal L2. +Transfers from Ethereum to Metal L2 via the Standard Bridge are usually completed within 1-3 minutes. +Transfers from Metal L2 to Ethereum are completed in 7 days as a result of the [withdrawal challenge period](./messaging#understanding-the-challenge-period). The Standard Bridge is fully permissionless and supports standard ERC-20 tokens. Other bridging systems also exist that provide different features and security properties. @@ -23,17 +23,17 @@ You may wish to explore some of these options to find the bridge that works best ## Design -The Standard Bridge allows users to convert tokens that are native to one chain (like Ethereum) into a representation of those tokens on the other chain (like OP Mainnet). +The Standard Bridge allows users to convert tokens that are native to one chain (like Ethereum) into a representation of those tokens on the other chain (like Metal L2). Users can then convert these bridged representations back into their original native tokens at any time. -This bridging mechanism functions identically in both directions — tokens native to OP Mainnet can be bridged to Ethereum, just like tokens native to Ethereum can be bridged to OP Mainnet. -Here you'll get to understand how the Standard Bridge works when moving tokens from Ethereum to OP Mainnet. +This bridging mechanism functions identically in both directions — tokens native to Metal L2 can be bridged to Ethereum, just like tokens native to Ethereum can be bridged to Metal L2. +Here you'll get to understand how the Standard Bridge works when moving tokens from Ethereum to Metal L2. Since the bridging mechanism is mirrored on both sides, this will also explain how the bridge works in the opposite direction. ### Architecture -The Standard Bridge is composed of two contracts, the [`L1StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/65ec61dde94ffa93342728d324fecf474d228e1f/packages/contracts-bedrock/contracts/L1/L1StandardBridge.sol) (on `Ethereum`) and the [`L2StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/65ec61dde94ffa93342728d324fecf474d228e1f/packages/contracts-bedrock/contracts/L2/L2StandardBridge.sol) (on `OP Mainnet`). -These two contracts interact with one another via the `CrossDomainMessenger` system for sending messages between Ethereum and OP Mainnet. +The Standard Bridge is composed of two contracts, the [`L1StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/65ec61dde94ffa93342728d324fecf474d228e1f/packages/contracts-bedrock/contracts/L1/L1StandardBridge.sol) (on `Ethereum`) and the [`L2StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/65ec61dde94ffa93342728d324fecf474d228e1f/packages/contracts-bedrock/contracts/L2/L2StandardBridge.sol) (on `Metal L2`). +These two contracts interact with one another via the `CrossDomainMessenger` system for sending messages between Ethereum and Metal L2. You can read more about the `CrossDomainMessenger` in the guide on [Sending Data Between L1 and L2](./messaging). ### Bridged tokens @@ -104,7 +104,7 @@ The process for bridging a native token involves a few steps. {

The minting message is executed

} Once the minting message is sent, it must be relayed to the receiving side. - Message relaying is automatic when sending from Ethereum to OP Mainnet but requires additional user transactions when sending from OP Mainnet to Ethereum. + Message relaying is automatic when sending from Ethereum to Metal L2 but requires additional user transactions when sending from Metal L2 to Ethereum. Read more about the message relaying process in the guide to [Sending Data Between L1 and L2](./messaging#communication-speed). When the message is relayed, the `finalizeBridgeERC20` function will be triggered on the receiving Standard Bridge contract. @@ -126,7 +126,7 @@ The process for bridging a native token involves a few steps. This is part of the [`IOptimismMintableERC20`](https://github.com/ethereum-optimism/optimism/blob/8ed8be8806208976e63421bd68779477d12295b5/packages/contracts-bedrock/src/universal/IOptimismMintableERC20.sol) interface. This completes the process of bridging native tokens. - This process is identical in both the Ethereum to OP Mainnet and OP Mainnet to Ethereum directions. + This process is identical in both the Ethereum to Metal L2 and Metal L2 to Ethereum directions. ### Bridging non-native tokens @@ -139,7 +139,7 @@ The process for bridging a non-native, bridged representation of a token involve {

User calls the bridging function

} Unlike when bridging native tokens, users do not need to provide an approval to trigger a transfer of a bridged token because the Standard Bridge should already have the ability to `burn` these tokens. - Here, the user calls the [`bridgeERC20To`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L193-L217) function on the `StandardBridge` contract on the chain where the bridged token lives (e.g., the `L2StandardBridge` contract if the token is bridged to OP Mainnet). + Here, the user calls the [`bridgeERC20To`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L193-L217) function on the `StandardBridge` contract on the chain where the bridged token lives (e.g., the `L2StandardBridge` contract if the token is bridged to Metal L2). The user must provide the following parameters to this function call: @@ -164,7 +164,7 @@ The process for bridging a non-native, bridged representation of a token involve {

The unlock message is executed

} Once the unlock message is sent, it must be relayed to the receiving side. - Message relaying is automatic when sending from Ethereum to OP Mainnet but requires additional user transactions when sending from OP Mainnet to Ethereum. + Message relaying is automatic when sending from Ethereum to Metal L2 but requires additional user transactions when sending from Metal L2 to Ethereum. Read more about the message relaying process in the guide to [Sending Data Between L1 and L2](./messaging#communication-speed). When the message is relayed, the `finalizeBridgeERC20` function will be triggered on the receiving Standard Bridge contract. @@ -182,17 +182,17 @@ The process for bridging a non-native, bridged representation of a token involve If the unlock message is fully verified, `finalizeBridgeERC20` will [unlock and transfer tokens to the recipient](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L280-L281) equal to the number of tokens originally burned on the other blockchain. This completes the process of bridging native tokens. - This process is identical in both the Ethereum to OP Mainnet and OP Mainnet to Ethereum directions. + This process is identical in both the Ethereum to Metal L2 and Metal L2 to Ethereum directions. ### Bridging ETH -The Standard Bridge contracts can also be used to bridge ETH from Ethereum to OP Mainnet and vice versa. +The Standard Bridge contracts can also be used to bridge ETH from Ethereum to Metal L2 and vice versa. The ETH bridging process is generally less complex than the ERC-20 bridging process. Users simply need to trigger and send ETH to the [`bridgeETH`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L143-L150) or [`bridgeETHTo`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L152-L166) functions on either blockchain. - Users can also deposit ETH from Ethereum to OP Mainnet by sending a basic ETH transfer from an EOA to the `L1StandardBridgeProxy`. + Users can also deposit ETH from Ethereum to Metal L2 by sending a basic ETH transfer from an EOA to the `L1StandardBridgeProxy`. This works because the `L1StandardBridgeProxy` contains a [`receive`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L119-L121) function. You can find the mainnet and testnet addresses on the [Contract Addresses](/chain/addresses) page. @@ -217,7 +217,7 @@ Tokens on the Superchain Token List will automatically appear on certain tools l You should strongly consider using the Superchain Token List to verify that you're using the correct bridged representation of a token when bridging a native token. Doing so can help you avoid accidentally bridging to the wrong token and locking up your native token permanently. -You can easily find the bridged representation of a token for OP Mainnet on the [Bridged Token Addresses](/chain/tokenlist#op-mainnet) page. +You can easily find the bridged representation of a token for Metal L2 on the [Bridged Token Addresses](/chain/tokenlist#op-mainnet) page. If you want to find the bridged representation of a token for another chain, use the following steps. diff --git a/pages/builders/app-developers/quick-start.mdx b/pages/builders/app-developers/quick-start.mdx index 98cc91da0..9899824d5 100644 --- a/pages/builders/app-developers/quick-start.mdx +++ b/pages/builders/app-developers/quick-start.mdx @@ -15,8 +15,8 @@ This quick start uses [`Scaffold-OP`](https://github.com/ethereum-optimism/scaff ## Step 1: Get Testnet ETH from Superchain Faucet -You'll need some testnet ETH on OP Sepolia to pay for the [gas fees](https://ethereum.org/en/developers/docs/gas/) associated with deploying your test application. -Use the [Optimism Superchain Faucet](https://console.optimism.io/faucet?utm_source=scaffoldop) to get some free ETH on OP Sepolia for multiple OP Chains with just one click. +You'll need some testnet ETH on Metal L2 Testnet to pay for the [gas fees](https://ethereum.org/en/developers/docs/gas/) associated with deploying your test application. +Use the [Optimism Superchain Faucet](https://console.optimism.io/faucet?utm_source=scaffoldop) to get some free ETH on Metal L2 Testnet for multiple OP Chains with just one click. You can request testnet ETH from the Superchain Faucet in one of two ways: **connect a wallet** or **login with Github**. Superchain Faucet sign-up options @@ -26,7 +26,7 @@ You can request testnet ETH from the Superchain Faucet in one of two ways: **con Looking for more faucets? - You can also try using [other available OP Sepolia faucets](/builders/tools/build/faucets). + You can also try using [other available Metal L2 Testnet faucets](/builders/tools/build/faucets). ## Step 2: Build a basic app with Scaffold-OP @@ -157,7 +157,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! 🎉 +Congratulations! You now have an Metal L2 app ready for development, which can also be deployed to more OP Chains! 🎉 ## Next steps diff --git a/pages/builders/app-developers/transactions/estimates.mdx b/pages/builders/app-developers/transactions/estimates.mdx index 8f7bcf99c..e8d4c58c3 100644 --- a/pages/builders/app-developers/transactions/estimates.mdx +++ b/pages/builders/app-developers/transactions/estimates.mdx @@ -1,49 +1,49 @@ --- -title: Estimating transaction fees on OP Mainnet +title: Estimating transaction fees on Metal L2 lang: en-US -description: Learn how to properly estimate the total cost of a transaction on OP Mainnet. +description: Learn how to properly estimate the total cost of a transaction on Metal L2. --- import { Callout, Steps } from 'nextra/components' -# Estimating transaction fees on OP Mainnet +# Estimating transaction fees on Metal L2 -Check out the guide on understanding [Transaction Fees on OP Mainnet](./fees) for an in-depth explanation of how OP Mainnet transaction fees work. +Check out the guide on understanding [Transaction Fees on Metal L2](./fees) for an in-depth explanation of how Metal L2 transaction fees work. -It's important to properly estimate the cost of a transaction on OP Mainnet before submitting it to the network. -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. +It's important to properly estimate the cost of a transaction on Metal L2 before submitting it to the network. +Here you'll learn how to estimate both of the components that make up the total cost of an Metal L2 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 Metal L2](./fees) for a detailed look at how these fees work under the hood. ## Execution gas fee -Estimating the execution gas fee on OP Mainnet is just like estimating the execution gas fee on Ethereum. +Estimating the execution gas fee on Metal L2 is just like estimating the execution gas fee on Ethereum. Steps are provided here for reference and convenience, but you can use the same tooling that you'd use to estimate the execution gas fee for a transaction on Ethereum. 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. -Refer to the guide on [Transaction Fees on OP Mainnet](./fees#execution-gas-fee) for more information about the execution gas fee. +Refer to the guide on [Transaction Fees on Metal L2](./fees#execution-gas-fee) for more information about the execution gas fee. When estimating the execution gas fee for a transaction, you'll need to know the gas limit and the [max fee per gas](https://ethereum.org/en/developers/docs/gas/#maxfee) for the transaction. Your transaction fee will then be the product of these two values. -Refer to the guide on [Setting Transaction Gas Parameters on OP Mainnet](./parameters) to learn how to select an appropriate gas limit and max fee per gas for your transaction. +Refer to the guide on [Setting Transaction Gas Parameters on Metal L2](./parameters) to learn how to select an appropriate gas limit and max fee per gas for your transaction. {

Estimate the gas limit

} -Using the same tooling that you'd use to estimate the gas limit for a transaction on Ethereum, estimate the gas limit for your transaction 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) so transactions will use the same amount of gas on OP Mainnet as they would on Ethereum. +Using the same tooling that you'd use to estimate the gas limit for a transaction on Ethereum, estimate the gas limit for your transaction on Metal L2. +Metal L2 is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) so transactions will use the same amount of gas on Metal L2 as they would on Ethereum. This means you can feed your transaction to the [`eth_estimateGas`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_estimategas) JSON-RPC method just like you would on Ethereum. {

Estimate the max fee per gas

} -Like Ethereum, OP Mainnet uses an `EIP-1559` style fee market to determine the current base fee per gas. +Like Ethereum, Metal L2 uses an `EIP-1559` style fee market to determine the current base fee per gas. You can then additionally specify a priority fee (also known as a tip) to incentivize the Sequencer to include your transaction more quickly. -Make sure to check out the guide on [Setting Transaction Gas Parameters on OP Mainnet](./parameters) to learn more about how to select an appropriate max fee per gas for your transaction. +Make sure to check out the guide on [Setting Transaction Gas Parameters on Metal L2](./parameters) to learn more about how to select an appropriate max fee per gas for your transaction. @@ -51,13 +51,13 @@ Make sure to check out the guide on [Setting Transaction Gas Parameters on OP Ma The Viem library provides a convenient method for estimating the L1 data fee for a transaction. -Check out the tutorial on [Estimating Transaction Costs on OP Mainnet](/builders/app-developers/tutorials/sdk-estimate-costs) to learn how to use the Viem library to estimate the L1 data fee for your transaction. +Check out the tutorial on [Estimating Transaction Costs on Metal L2](/builders/app-developers/tutorials/sdk-estimate-costs) to learn how to use the Viem library to estimate the L1 data fee for your transaction. Keep reading if you'd like to learn how to estimate the L1 data fee without the Viem library. The L1 data fee is a fee paid to the Sequencer for the cost of publishing your transaction to Ethereum. This fee is paid in ETH and is calculated based on the size of your transaction in bytes and the current gas price on Ethereum. -Refer to the guide on [Transaction Fees on OP Mainnet](./fees#l1-data-fee) for more information about the L1 data fee. +Refer to the guide on [Transaction Fees on Metal L2](./fees#l1-data-fee) for more information about the L1 data fee. Unlike the execution gas fee, the L1 data fee is an **intrinsic** fee for every transaction. This fee is automatically charged based on the size of your transaction and the current Ethereum gas price. @@ -65,8 +65,8 @@ You currently cannot specify a custom L1 data fee for your transaction. The L1 data fee is paid based on the current Ethereum gas price as tracked within the [`GasPriceOracle`](https://github.com/ethereum-optimism/optimism/blob/233ede59d16cb01bdd8e7ff662a153a4c3178bdd/packages/contracts/contracts/L2/predeploys/OVM_GasPriceOracle.sol) smart contract. -This gas price is updated automatically by the OP Mainnet protocol. -Your transaction will be charged the Ethereum gas price seen by the protocol at the time that your transaction is included in an OP Mainnet block. +This gas price is updated automatically by the Metal L2 protocol. +Your transaction will be charged the Ethereum gas price seen by the protocol at the time that your transaction is included in an Metal L2 block. This means that the L1 data fee for your transaction may differ from your estimated L1 data fee. @@ -80,8 +80,8 @@ For instance, Ethers.js provides the [`ethers.utils.serializeTransaction`](https {

Estimate the L1 data fee

} -Once you have serialized your transaction, you can estimate the L1 data fee by calling the [`getL1Fee`](https://github.com/ethereum-optimism/optimism/blob/233ede59d16cb01bdd8e7ff662a153a4c3178bdd/packages/contracts/contracts/L2/predeploys/OVM_GasPriceOracle.sol#L109-L124) method on the [`GasPriceOracle`](https://github.com/ethereum-optimism/optimism/blob/233ede59d16cb01bdd8e7ff662a153a4c3178bdd/packages/contracts/contracts/L2/predeploys/OVM_GasPriceOracle.sol) smart contract available on OP Mainnet and all OP Stack chains. -This method takes the serialized transaction as input and returns the L1 data fee in wei using the formula described in the [Transaction Fees on OP Mainnet](./fees#l1-data-fee) guide. +Once you have serialized your transaction, you can estimate the L1 data fee by calling the [`getL1Fee`](https://github.com/ethereum-optimism/optimism/blob/233ede59d16cb01bdd8e7ff662a153a4c3178bdd/packages/contracts/contracts/L2/predeploys/OVM_GasPriceOracle.sol#L109-L124) method on the [`GasPriceOracle`](https://github.com/ethereum-optimism/optimism/blob/233ede59d16cb01bdd8e7ff662a153a4c3178bdd/packages/contracts/contracts/L2/predeploys/OVM_GasPriceOracle.sol) smart contract available on Metal L2 and all OP Stack chains. +This method takes the serialized transaction as input and returns the L1 data fee in wei using the formula described in the [Transaction Fees on Metal L2](./fees#l1-data-fee) guide. Fee estimation is typically performed before the transaction is signed. @@ -95,7 +95,7 @@ As a result, the `getL1Fee` method assumes that your input is an **unsigned** Et Several tools are available to help you estimate the L1 Data Fee for your transaction. 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. +* [Viem](https://viem.sh/op-stack#getting-started-with-op-stack) provides first-class support for OP Stack chains, including Metal L2. 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 diff --git a/pages/builders/app-developers/transactions/parameters.mdx b/pages/builders/app-developers/transactions/parameters.mdx index 1f1da0aa2..3af67b4bf 100644 --- a/pages/builders/app-developers/transactions/parameters.mdx +++ b/pages/builders/app-developers/transactions/parameters.mdx @@ -1,16 +1,16 @@ --- -title: Setting transaction gas parameters on OP Mainnet +title: Setting transaction gas parameters on Metal L2 lang: en-US -description: Learn how to set gas parameters for transactions on OP Mainnet. +description: Learn how to set gas parameters for transactions on Metal L2. --- import { Callout, Steps } from 'nextra/components' -# Setting transaction gas parameters on OP Mainnet +# Setting transaction gas parameters on Metal L2 -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. -OP Mainnet also allows transactions to pay a [priority fee](https://ethereum.org/en/developers/docs/gas/#priority-fee) (also known as a tip) to incentivize the Sequencer to include transactions more quickly. +Metal L2 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 Metal L2 nodes. +Like Ethereum, Metal L2 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. +Metal L2 also allows transactions to pay a [priority fee](https://ethereum.org/en/developers/docs/gas/#priority-fee) (also known as a tip) to incentivize the Sequencer to include transactions more quickly. 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. @@ -20,8 +20,8 @@ This guide will walk you through some best practices for determining the base fe 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. -The simplest way to select a base fee is to look at the latest available OP Mainnet block. -Each OP Mainnet block includes the current base fee and the amount of gas used within that block. +The simplest way to select a base fee is to look at the latest available Metal L2 block. +Each Metal L2 block includes the current base fee and the amount of gas used within that block. You can use this information to predict a reasonable maximum fee for your transaction. Note that, like Ethereum, the base fee is not explicitly defined within a transaction. @@ -31,7 +31,7 @@ Instead, the maximum base fee is determined as the difference between the `maxFe {

Retrieve the latest block

} -Using the JSON-RPC API or your favorite Ethereum library, retrieve the latest block on OP Mainnet. +Using the JSON-RPC API or your favorite Ethereum library, retrieve the latest block on Metal L2. {

Retrieve the base fee and gas used

} @@ -39,10 +39,10 @@ From the block, retrieve the `baseFeePerGas` and `gasUsed` fields. {

Predict the next base fee

} -OP Mainnet adjusts the base fee based on the amount of gas used in the previous block. +Metal L2 adjusts the base fee based on the amount of gas used in the previous block. If the previous block used more than 5m gas (of the 30m gas limit), then the base fee will increase by up to 10%. If the previous block used less than 5m gas, then the base fee will decrease by up to 10%. -Refer to the [OP Mainnet EIP-1559 Parameters](/stack/differences#eip-1559-parameters) section for more details. +Refer to the [Metal L2 EIP-1559 Parameters](/stack/differences#eip-1559-parameters) section for more details. {

Select a base fee per gas

} diff --git a/pages/builders/app-developers/transactions/statuses.mdx b/pages/builders/app-developers/transactions/statuses.mdx index ed635a400..dceaf1957 100644 --- a/pages/builders/app-developers/transactions/statuses.mdx +++ b/pages/builders/app-developers/transactions/statuses.mdx @@ -1,12 +1,12 @@ --- -title: Transaction statuses on OP Mainnet +title: Transaction statuses on Metal L2 lang: en-US -description: Learn about the statuses transactions can have on OP Mainnet. +description: Learn about the statuses transactions can have on Metal L2. --- -# Transaction statuses on OP Mainnet +# Transaction statuses on Metal L2 -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. +Transactions on Metal L2 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. ## Pending @@ -48,7 +48,7 @@ Transactions typically become "safe" within a few minutes of becoming "sequencer **Typically within 15-20 minutes, up to 12 hours** A transaction is considered "finalized" when it has been included in a block by the Sequencer, that block has been published to Ethereum, and that block has been finalized. -Once a block has been finalized it is guaranteed to be included in the OP Mainnet blockchain. +Once a block has been finalized it is guaranteed to be included in the Metal L2 blockchain. Applications that require the highest level of certainty that a transaction will be included in the blockchain should wait until the transaction is "finalized" before considering the transaction to be successful. The latest "finalized" 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 `finalized` as the block number. diff --git a/pages/builders/app-developers/tutorials/_meta.json b/pages/builders/app-developers/tutorials/_meta.json index a1f44203f..4c8a9d965 100644 --- a/pages/builders/app-developers/tutorials/_meta.json +++ b/pages/builders/app-developers/tutorials/_meta.json @@ -2,10 +2,10 @@ "cross-dom-solidity": "Communicating between chains in Solidity", "cross-dom-bridge-eth": "Bridging ETH with viem", "cross-dom-bridge-erc20": "Bridging ERC-20 tokens with viem", - "standard-bridge-custom-token": "Bridging your custom ERC-20 token to OP Mainnet", - "standard-bridge-standard-token": "Bridging your standard ERC-20 token to OP Mainnet", + "standard-bridge-custom-token": "Bridging your custom ERC-20 token to Metal L2", + "standard-bridge-standard-token": "Bridging your standard ERC-20 token to Metal L2", "sdk-view-txns": "Viewing deposits and withdrawals by address", "sdk-trace-txns": "Tracing deposits and withdrawals", "sdk-estimate-costs": "Estimating transaction costs", - "send-tx-from-eth": "Triggering OP Mainnet transactions from Ethereum" + "send-tx-from-eth": "Triggering Metal L2 transactions from Ethereum" } 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 883e4908c..8f33f3e59 100644 --- a/pages/builders/app-developers/tutorials/cross-dom-bridge-erc20.mdx +++ b/pages/builders/app-developers/tutorials/cross-dom-bridge-erc20.mdx @@ -1,7 +1,7 @@ --- title: Bridging ERC-20 tokens with the Optimism SDK lang: en-US -description: Learn how to use the Optimism SDK to transfer ERC-20 tokens between Layer 1 (Ethereum or Sepolia) and Layer 2 (OP Mainnet or OP Sepolia). +description: Learn how to use the Optimism SDK to transfer ERC-20 tokens between Layer 1 (Ethereum or Sepolia) and Layer 2 (Metal L2 or Metal L2 Testnet). --- import { Callout, Steps } from 'nextra/components' @@ -9,11 +9,11 @@ import { WipCallout } from '@/components/WipCallout' -# Bridging ERC-20 tokens to OP Mainnet with the Optimism SDK +# Bridging ERC-20 tokens to Metal L2 with the Optimism SDK -This tutorial explains how you can use the [Optimism SDK](https://sdk.optimism.io) to bridge ERC-20 tokens from L1 (Ethereum or Sepolia) to L2 (OP Mainnet or OP Sepolia). +This tutorial explains how you can use the [Optimism SDK](https://sdk.optimism.io) to bridge ERC-20 tokens from L1 (Ethereum or Sepolia) to L2 (Metal L2 or Metal L2 Testnet). The Optimism SDK is an easy way to add bridging functionality to your javascript-based application. It also provides some safety rails to prevent common mistakes that could cause tokens to be made inaccessible. @@ -77,9 +77,9 @@ Since the Optimism SDK is a [Node.js](https://nodejs.org/en/) library, you'll ne the private key. -## Get ETH on Sepolia and OP Sepolia +## Get ETH on Sepolia and Metal L2 Testnet -This tutorial explains how to bridge tokens from Sepolia to OP Sepolia. +This tutorial explains how to bridge tokens from Sepolia to Metal L2 Testnet. You will need to get some ETH on both of these testnets. @@ -93,7 +93,7 @@ You will need to get some ETH on both of these testnets. You need a private key to sign transactions. Set your private key as an environment variable with the `export` command. -Make sure this private key corresponds to an address that has ETH on both Sepolia and OP Sepolia. +Make sure this private key corresponds to an address that has ETH on both Sepolia and Metal L2 Testnet. ```bash export TUTORIAL_PRIVATE_KEY=0x... @@ -144,16 +144,16 @@ Let's set those up now. {

Set the L1 and L2 ERC-20 addresses

} - This tutorial uses existing ERC-20 tokens that have been deployed on Sepolia and OP Sepolia. + This tutorial uses existing ERC-20 tokens that have been deployed on Sepolia and Metal L2 Testnet. These tokens are designed for testing the bridging process. ```js file=/public/tutorials/cross-dom-bridge-erc20.js#L13-L14 hash=d8f0d4c8124782a6cd36097ff31010e5 ``` - If you're coming from the [Bridging Your Standard ERC-20 Token to OP Mainnet + If you're coming from the [Bridging Your Standard ERC-20 Token to Metal L2 Using the Standard Bridge](./standard-bridge-standard-token) or [Bridging Your - Custom ERC-20 Token to OP Mainnet Using the Standard + Custom ERC-20 Token to Metal L2 Using the Standard Bridge](./standard-bridge-custom-token) tutorials, you can use the addresses of your own ERC-20 tokens here instead. @@ -205,7 +205,7 @@ You'll then receive the same number of tokens on L2 in return. Create an instance of the `CrossChainMessenger` class: - ```js file=/public/tutorials/cross-dom-bridge-erc20.js#L29-L34 hash=997b9c4cdd5fb1f9d4e0882a683ae016 + ```js file=/public/tutorials/cross-dom-bridge-erc20.js#L29-L34 hash=adc0408faa333a36eb0adef11789a28f ``` {

Allow the Standard Bridge to access your tokens

} @@ -304,10 +304,10 @@ Now you're going to repeat the process in reverse to bridge some tokens from L2 The final step to withdrawing tokens from L2 to L1 is to relay the withdrawal on L1. This can only happen after the fault proof period has elapsed. - On OP Mainnet, this takes 7 days. + On Metal L2, this takes 7 days. - We're currently testing fault proofs on OP Sepolia, so withdrawal times + We're currently testing fault proofs on Metal L2 Testnet, so withdrawal times reflect Mainnet times. @@ -341,4 +341,4 @@ Now you're going to repeat the process in reverse to bridge some tokens from L2 Congrats! You've just deposited and withdrawn tokens using the Optimism SDK. You should now be able to write applications that use the Optimism SDK to transfer ERC-20 tokens between L1 and L2. -Although this tutorial used Sepolia and OP Sepolia, the same process works for Ethereum and OP Mainnet. +Although this tutorial used Sepolia and Metal L2 Testnet, the same process works for Ethereum and Metal L2. 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 3cbe5253e..d6ff3d30b 100644 --- a/pages/builders/app-developers/tutorials/cross-dom-bridge-eth.mdx +++ b/pages/builders/app-developers/tutorials/cross-dom-bridge-eth.mdx @@ -1,14 +1,14 @@ --- title: Bridging ETH with Viem lang: en-US -description: Learn how to use Viem to transfer ETH between Layer 1 (Ethereum or Sepolia) and Layer 2 (OP Mainnet or OP Sepolia). +description: Learn how to use Viem to transfer ETH between Layer 1 (Ethereum or Sepolia) and Layer 2 (Metal L2 or Metal L2 Testnet). --- import { Callout, Steps, Tabs } from 'nextra/components' -# Bridging ETH to OP Mainnet with Viem +# Bridging ETH to Metal L2 with Viem -This tutorial explains how you can use [Viem](https://viem.sh) to bridge ETH from L1 (Ethereum or Sepolia) to L2 (OP Mainnet or OP Sepolia). +This tutorial explains how you can use [Viem](https://viem.sh) to bridge ETH from L1 (Ethereum or Sepolia) to L2 (Metal L2 or Metal L2 Testnet). Viem is a TypeScript interface for Ethereum that provides low-level stateless primitives for interacting with Ethereum. It offers an easy way to add bridging functionality to your JavaScript-based application. @@ -59,7 +59,7 @@ Since Viem is a [Node.js](https://nodejs.org/en/) library, you'll need to create ## Get ETH on Sepolia -This tutorial explains how to bridge ETH from Sepolia to OP Sepolia. +This tutorial explains how to bridge ETH from Sepolia to Metal L2 Testnet. You will need to get some ETH on Sepolia to follow along. @@ -114,12 +114,12 @@ You need to import some dependencies into your Node REPL session. ``` -{

Create L2 public client for interacting with OP Sepolia

} +{

Create L2 public client for interacting with Metal L2 Testnet

} ```js file=/public/tutorials/cross-dom-bridge-eth.js#L26-L29 hash=dd7868fc9ab8f8a34768c8a83232409b ``` -{

Create L2 wallet client on OP Sepolia

} +{

Create L2 wallet client on Metal L2 Testnet

} ```js file=/public/tutorials/cross-dom-bridge-eth.js#L32-L36 hash=6f91578c5b155d7abfeecf2297ee9f70 ``` @@ -252,13 +252,13 @@ Now you're going to repeat the process in reverse to bridge some ETH from L2 to {

Wait for withdrawal finalization

} Before a withdrawal transaction can be finalized, you will need to wait for the finalization period. - This can only happen after the fault proof period has elapsed. On OP Mainnet, this takes 7 days. + This can only happen after the fault proof period has elapsed. On Metal L2, this takes 7 days. ```js file=/public/tutorials/cross-dom-bridge-eth.js#L94-L97 hash=15e6f754d2e9f11a03f400813efef383 ``` - We're currently testing fault proofs on OP Sepolia, so withdrawal times + We're currently testing fault proofs on Metal L2 Testnet, so withdrawal times reflect Mainnet times. @@ -303,4 +303,4 @@ Now you're going to repeat the process in reverse to bridge some ETH from L2 to You've just deposited and withdrawn ETH using `viem/op-stack`. You should now be able to write applications that use `viem/op-stack` to transfer ETH between L1 and L2. -Although this tutorial used Sepolia and OP Sepolia, the same process works for Ethereum and OP Mainnet. +Although this tutorial used Sepolia and Metal L2 Testnet, the same process works for Ethereum and Metal L2. diff --git a/pages/builders/app-developers/tutorials/cross-dom-solidity.mdx b/pages/builders/app-developers/tutorials/cross-dom-solidity.mdx index 1aa33fb07..8a4c27ae0 100644 --- a/pages/builders/app-developers/tutorials/cross-dom-solidity.mdx +++ b/pages/builders/app-developers/tutorials/cross-dom-solidity.mdx @@ -34,18 +34,18 @@ Read more about message passing in the guide to [Sending Data Between L1 and L2] * [node](https://nodejs.org/en/) * [pnpm](https://pnpm.io/installation) -## Get ETH on Sepolia and OP Sepolia +## Get ETH on Sepolia and Metal L2 Testnet -This tutorial explains how to send messages from Sepolia to OP Sepolia. +This tutorial explains how to send messages from Sepolia to Metal L2 Testnet. You will need to get some ETH on both of these testnets. 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. +You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on Metal L2 Testnet. ## Review the contracts -You're about to use two contracts that have already been deployed to Sepolia and OP Sepolia, the `Greeter` contracts. +You're about to use two contracts that have already been deployed to Sepolia and Metal L2 Testnet, 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). Both contracts have exactly the same source code. @@ -86,7 +86,7 @@ This same function can be used to wait for a message to be relayed from L1 to L2 {

Check the L2 Greeter

} After a few minutes, you should see the greeting on the L2 `Greeter` contract change to the greeting you set. -Open up the [L2 `Greeter` contract on OP Sepolia Etherscan](https://sepolia-optimism.etherscan.io/address/0x5DE8a2957eddb140567fF90ba5d57bc9769f3055#readContract) and click the "Read Contract" button. +Open up the [L2 `Greeter` contract on Metal L2 Testnet Etherscan](https://sepolia-optimism.etherscan.io/address/0x5DE8a2957eddb140567fF90ba5d57bc9769f3055#readContract) and click the "Read Contract" button. Paste your address into the field next to the "greeting" function and click the "Query" button. You should see the message you sent from L1. @@ -110,7 +110,7 @@ You'll do this by sending two transactions on Sepolia, one proving transaction a {

Connect to Etherscan

} Just like before, sending a message to the L1 `Greeter` contract via the L2 `Greeter` contract requires that you call the `sendGreeting` function. -Open up the [L2 `Greeter` contract on OP Sepolia Etherscan](https://sepolia-optimism.etherscan.io/address/0x5DE8a2957eddb140567fF90ba5d57bc9769f3055#writeContract) and click the "Connect to Web3" button. +Open up the [L2 `Greeter` contract on Metal L2 Testnet Etherscan](https://sepolia-optimism.etherscan.io/address/0x5DE8a2957eddb140567fF90ba5d57bc9769f3055#writeContract) and click the "Connect to Web3" button. {

Send your greeting

} @@ -218,7 +218,7 @@ This can only happen after the fault proof period has elapsed. On OP Stack, this takes 7 days. -We're currently testing fault proofs on OP Sepolia, so withdrawal times reflect Mainnet times. +We're currently testing fault proofs on Metal L2 Testnet, so withdrawal times reflect Mainnet times. ```js file=/public/tutorials/cross-dom-solidity.js#L25-L29 hash=88cec1db2fde515ea9008eaa1bbdfd73 @@ -317,7 +317,7 @@ You can follow a similar pattern in your own smart contracts. ## Conclusion -You just learned how you can write Solidity contracts on Sepolia and OP Sepolia that can talk to each other. +You just learned how you can write Solidity contracts on Sepolia and Metal L2 Testnet that can talk to each other. You can follow the same pattern to write contracts that can talk to each other on Ethereum and OP Stack. This sort of cross-chain communication is useful for a variety of reasons. diff --git a/pages/builders/app-developers/tutorials/sdk-estimate-costs.mdx b/pages/builders/app-developers/tutorials/sdk-estimate-costs.mdx index 8b47d81c4..5981fa92b 100644 --- a/pages/builders/app-developers/tutorials/sdk-estimate-costs.mdx +++ b/pages/builders/app-developers/tutorials/sdk-estimate-costs.mdx @@ -8,12 +8,12 @@ import { Callout, Steps, Tabs } from 'nextra/components' # 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 Metal L2. 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. - 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. + Check out the full explainer on [OP Stack transaction fees](/builders/app-developers/transactions/fees) for more information on how Metal L2 charges fees under the hood. ## Supported networks @@ -60,20 +60,20 @@ Since Viem is a [Node.js](https://nodejs.org/en/) library, you'll need to create ## Get ETH on Sepolia -This tutorial explains how to bridge ETH from Sepolia to OP Sepolia. +This tutorial explains how to bridge ETH from Sepolia to Metal L2 Testnet. 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. -## Get ETH on OP Sepolia +## Get ETH on Metal L2 Testnet -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. +This tutorial explains how estimate transaction costs on Metal L2 Testnet. +You will need to get some ETH on Metal L2 Testnet 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 Metal L2 Testnet. ## Add a private key to your environment @@ -127,7 +127,7 @@ Let's set those up now. ## Estimate transaction costs -You're now going to use the Viem to estimate the cost of a transaction on OP Mainnet. +You're now going to use the Viem to estimate the cost of a transaction on Metal L2. Here you'll estimate the cost of a simple transaction that sends a small amount of ETH from your address to the address `0x1000000000000000000000000000000000000000`. diff --git a/pages/builders/app-developers/tutorials/sdk-trace-txns.mdx b/pages/builders/app-developers/tutorials/sdk-trace-txns.mdx index 637d7cb6a..5ed3e4e92 100644 --- a/pages/builders/app-developers/tutorials/sdk-trace-txns.mdx +++ b/pages/builders/app-developers/tutorials/sdk-trace-txns.mdx @@ -1,23 +1,16 @@ --- 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. +description: Learn how to use the viem library to trace deposits and withdrawals between L1 and L2. --- import { Callout, Steps } from 'nextra/components' -import { WipCallout } from '@/components/WipCallout' - # 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. +In this tutorial, you'll learn how to use the [viem](https://viem.sh) library 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). - -Check out the tutorial on [Bridging ERC-20 Tokens With the Optimism SDK](./cross-dom-bridge-erc20) to learn how to create deposits and withdrawals. -You can also check out the tutorial on [Viewing Deposits and Withdrawals by Address](./sdk-view-txns) to find deposits and withdrawals to trace. - - ## Dependencies * [node](https://nodejs.org/en/) @@ -25,203 +18,145 @@ You can also check out the tutorial on [Viewing Deposits and Withdrawals by Addr ## 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. +You're going to use the viem library 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-sample-project -cd op-sample-project -``` - -{

Initialize the Project

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

Install the Optimism SDK

} + ```bash + mkdir trace-trx + cd trace-trx + ``` -```bash -pnpm add @eth-optimism/sdk -``` + {

Initialize the project

} -{

Install ethers.js

} + ```bash + pnpm init + ``` -```bash -pnpm add ethers@^5 -``` + {

Install viem

} + ```bash + pnpm add viem + ``` - ## 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. +You'll be using the `getTransactionReceipt` function from the viem library during this tutorial. This function use event queries to retrieve the receipt for a deposit or withdrawal. Since this function uses large event queries, you'll need to use an RPC provider like [Alchemy](https://alchemy.com) that supports indexed event queries. -Grab an L1 and L2 RPC URL for Sepolia and OP Sepolia, respectively. +Grab an L1 and L2 RPC URL for Sepolia and Metal L2 Testnet, respectively. ```bash -export L1_RPC_URL=... # Sepolia RPC URL -export L2_RPC_URL=... # OP Sepolia RPC URL +export L1_RPC_URL="https://YOUR_L1_ SEPOLIA_RPC_URL_HERE" +export L2_RPC_URL="https://YOUR_L2_OP_SEPOLIA_RPC_URL_HERE" ``` - -The Optimism SDK may be updated in the future to use a different method of retrieving deposits and withdrawals under the hood that does not require indexed event queries. -This tutorial will be updated to reflect those changes if and when they occur. - - ## Start the Node REPL -You're going to use the Node REPL to interact with the Optimism SDK. -To start the Node REPL run the following command in your terminal: +You're going to use the Node REPL to interact with viem. To start the Node REPL, run the following command in your terminal: ```bash node ``` -This will bring up a Node REPL prompt that allows you to run javascript code. +This will bring up a Node REPL prompt that allows you to run JavaScript code. ## Import dependencies You need to import some dependencies into your Node REPL session. - - -{

Import the Optimism SDK

} - -```js file=/public/tutorials/sdk-trace-txns.js#L3 hash=26b2fdb17dd6c8326a54ec51f0769528 -``` - -{

Import ethers.js

} +{

Import viem

} -```js file=/public/tutorials/sdk-trace-txns.js#L4 hash=69a65ef97862612e4978b8563e6dbe3a +```js file=/public/tutorials/sdk-trace-txns.js#L3-L4 hash=57a929d665f2e5e4a7ecd085ad3d0b01 ``` - - - + ## Set session variables -You'll need a few variables throughout this tutorial. -Let's set those up now. +You'll need a few variables throughout this tutorial. Let's set those up now. + {

Import RPC URLs

} -{

Import RPC URLs

} - -```js file=/public/tutorials/sdk-trace-txns.js#L10-L11 hash=02141d8cb077764665c61fc48e18ed04 -``` - -{

Set the deposit to trace

} + ```js file=/public/tutorials/sdk-trace-txns.js#L13-L14 hash=0badc18f525e56b36406e7be8ad1104e + ``` -You'll be tracing a specific deposit in this tutorial. -Deposit tracing is generally based on the transaction hash of the transaction that triggered the deposit. -You can replace this transaction hash with your own if you'd like. + {

Set the deposit to trace

} -```js file=/public/tutorials/sdk-trace-txns.js#L14 hash=a874f1ce83255bb233539f7a188ea1d3 -``` + You'll be tracing a specific deposit in this tutorial. Deposit tracing is generally based on the transaction hash of the transaction that triggered the deposit. You can replace this transaction hash with your own if you'd like. -{

Set the withdrawal to trace

} + ```js file=/public/tutorials/sdk-trace-txns.js#L17 hash=367c797c3e9746addedf43857f789eeb + ``` -You'll also be tracing a specific withdrawal in this tutorial. -Like with deposits, withdrawal tracing is generally based on the transaction hash of the transaction that triggered the withdrawal. -You can replace this transaction hash with your own if you'd like. + {

Set the withdrawal to trace

} -```js file=/public/tutorials/sdk-trace-txns.js#L15 hash=6c5af039dfa0217810295dfaf82ef7c1 -``` + You'll also be tracing a specific withdrawal in this tutorial. Like with deposits, withdrawal tracing is generally based on the transaction hash of the transaction that triggered the withdrawal. You can replace this transaction hash with your own if you'd like. -{

Create the RPC providers

} + ```js file=/public/tutorials/sdk-trace-txns.js#L18 hash=545d1eed00ad0a235e2c79c8a87efd30 + ``` -```js file=/public/tutorials/sdk-trace-txns.js#L17-L18 hash=e86efaea1d4adde679ca66911080dc28 -``` + {

Create the RPC providers

} + ```js file=/public/tutorials/sdk-trace-txns.js#L20-L28 hash=6286672ca3163543e9d8ddeb5b1b6477 + ``` -## Create the CrossDomainMessenger - -The Optimism SDK exports a `CrossChainMessenger` class that makes it easy to interact with the Standard Bridge contracts. +## Trace a Deposit -Create an instance of the `CrossChainMessenger` class: - -```js file=/public/tutorials/sdk-trace-txns.js#L20-L25 hash=158c6888c82bdc2f07c37c3edb3a9a6a -``` - -## Trace a deposit - -You can use the `CrossChainMessenger` instance to trace a deposit. +You can use viem to trace a deposit. + {

Get the deposit status

} -{

Get the deposit status

} - -It's often useful to know the status of a deposit. -Deposits can have a number of statuses depending on where the deposit is within its lifecycle. -Refer to the [Optimism SDK documentation](https://sdk.optimism.io/enums/messagestatus) for a full list of potential deposit statuses. - -```js file=/public/tutorials/sdk-trace-txns.js#L28-L29 hash=11aa5fe48d79feea140691842bf5213c -``` - -{

Get the deposit transaction receipt

} - -You can also use the `CrossChainMessenger` instance to get the transaction receipt for the L2 transaction that executes and completes the deposit. -Note that this function will also return the message status of the deposit and is therefore an alternative to the previous function. -The result of this function is an object with a `messageStatus` property and a `transactionReceipt` property that is identical to the result of the `ethers` function `getTransactionReceipt`. + You can query for the deposit status using the transaction hash of the deposit. -```js file=/public/tutorials/sdk-trace-txns.js#L32-L33 hash=42ce77ccd7c2c7c9b447ac534c0daa4f -``` + ```js file=/public/tutorials/sdk-trace-txns.js#L30-L32 hash=b3693011e87b605cdd29baeffb080b9a + ``` -{

Parse deposit logs

} + {

Get the deposit transaction receipt

} -Like any other transaction receipt, the deposit transaction receipt contains logs that can be parsed to get additional information about the deposit. -You can iterate through these logs and parse them just as you would parse any other receipt. -For instance, you may wish to search for `Mint` events to determine the amount of tokens that were minted as a result of the deposit. + Retrieve the transaction receipt for the deposit using the viem client. -{

Get the deposit transaction

} + ```js file=/public/tutorials/sdk-trace-txns.js#L34-L36 hash=077581a56fc7b26f62589f0a6ae99e0d + ``` -Once you have the transaction receipt, you can directly query for the actual L2 transaction that executed the deposit. + {

Get the deposit transaction

} -```js file=/public/tutorials/sdk-trace-txns.js#L36-L37 hash=13bdc82e94c80eb3c29bf4430b15e456 -``` + You can directly query for the L2 transaction that executed the deposit. + ```js file=/public/tutorials/sdk-trace-txns.js#L38-L40 hash=c67f0abeef0f2f817b7fb04be8f157a6 + ``` ## Trace a withdrawal -You can also use the `CrossChainMessenger` instance to trace a withdrawal. +You can use viem's functions to trace a withdrawal. + {

Get the withdrawal status

} -{

Get the withdrawal status

} - -Like deposits, withdrawals can have a number of statuses depending on where the withdrawal is within its lifecycle. -Refer to the [Optimism SDK documentation](https://sdk.optimism.io/enums/messagestatus) for a full list of potential withdrawal statuses. + Like deposits, withdrawals can have multiple statuses depending on where they are in the process. -```js file=/public/tutorials/sdk-trace-txns.js#L40-L41 hash=24ef2259ff96107ff31bfb8f02a4150a -``` - -{

Get the withdrawal transaction receipt

} + ```js file=/public/tutorials/sdk-trace-txns.js#L42-L44 hash=55ceda3d9d2f9abf037f8b259de14f26 + ``` -You can also use the `CrossChainMessenger` instance to get the transaction receipt for the L1 transaction that executes and completes the withdrawal. -The result of this function is an object with a `messageStatus` property and a `transactionReceipt` property that is identical to the result of the `ethers` function `getTransactionReceipt`. + {

Get the withdrawal transaction receipt

} -```js file=/public/tutorials/sdk-trace-txns.js#L44-L45 hash=e2e9688e7c3cb81740c73f921808cc3e -``` + Retrieve the L1 transaction receipt for the withdrawal. -{

Parse withdrawal logs

} + ```js file=/public/tutorials/sdk-trace-txns.js#L46-L48 hash=d784970abbfd37215d33274d60173ab2 + ``` -Like any other transaction receipt, the withdrawal transaction receipt contains logs that can be parsed to get additional information about the withdrawal. -You can iterate through these logs and parse them just as you would parse any other receipt. -For instance, you may wish to search for `Burn` events to determine the amount of tokens that were burned as a result of the withdrawal. + {

Get the withdrawal transaction

} -{

Get the withdrawal transaction

} + Directly query for the L1 transaction that executed the withdrawal. -Once you have the transaction receipt, you can directly query for the actual L1 transaction that executed the withdrawal. + ```js file=/public/tutorials/sdk-trace-txns.js#L50-L52 hash=48358bc45243db4e69de6ed3d49a67f9 + ``` + -```js file=/public/tutorials/sdk-trace-txns.js#L48-L49 hash=c138a32f8c1e3c887f19d9bc7e87c73b -``` +## Next steps - +* Check out the tutorial on [bridging ERC-20 tokens with the Optimism SDK](./cross-dom-bridge-erc20) to learn how to create deposits and withdrawals. +* You can also check out the tutorial on [viewing deposits and withdrawals by address](./sdk-view-txns) to find deposits and withdrawals to trace. diff --git a/pages/builders/app-developers/tutorials/sdk-view-txns.mdx b/pages/builders/app-developers/tutorials/sdk-view-txns.mdx index d93b63610..af0af44d4 100644 --- a/pages/builders/app-developers/tutorials/sdk-view-txns.mdx +++ b/pages/builders/app-developers/tutorials/sdk-view-txns.mdx @@ -60,11 +60,11 @@ pnpm add ethers@^5 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. Since these functions use large event queries, you'll need to use an RPC provider like [Alchemy](https://alchemy.com) that supports indexed event queries. -Grab an L1 and L2 RPC URL for Sepolia and OP Sepolia, respectively. +Grab an L1 and L2 RPC URL for Sepolia and Metal L2 Testnet, respectively. ```bash export L1_RPC_URL=... # Sepolia RPC URL -export L2_RPC_URL=... # OP Sepolia RPC URL +export L2_RPC_URL=... # Metal L2 Testnet RPC URL ``` @@ -134,7 +134,7 @@ The Optimism SDK exports a `CrossChainMessenger` class that makes it easy to int Create an instance of the `CrossChainMessenger` class: -```js file=/public/tutorials/sdk-view-txns.js#L19-L24 hash=158c6888c82bdc2f07c37c3edb3a9a6a +```js file=/public/tutorials/sdk-view-txns.js#L19-L24 hash=8432353280e044ccf56833995f492047 ``` ## Query for deposits 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 543de2792..2112cd190 100644 --- a/pages/builders/app-developers/tutorials/send-tx-from-eth.mdx +++ b/pages/builders/app-developers/tutorials/send-tx-from-eth.mdx @@ -12,7 +12,7 @@ OP Stack currently uses a single-Sequencer block production model. This means that there is only one Sequencer active on the network at any given time. Single-Sequencer models are simpler than their highly decentralized counterparts but they are also more vulnerable to potential downtime. Sequencer downtime must not be able to prevent users from transacting on the network. As a result, OP Stack includes a mechanism for "forcing" transactions to be included in the blockchain. This mechanism involves triggering a transaction on OP Stack by sending a transaction on Ethereum. -In this tutorial you'll learn how to trigger a transaction on OP Stack from Ethereum using Viem. You'll use the OP Sepolia testnet, but the same logic will apply to OP Stack. +In this tutorial you'll learn how to trigger a transaction on OP Stack from Ethereum using Viem. You'll use the Metal L2 Testnet testnet, but the same logic will apply to OP Stack. ## Dependencies @@ -49,20 +49,20 @@ You're going to use the `viem` package for this tutorial. Since Viem is a [Node. If you have [`cast`](https://book.getfoundry.sh/getting-started/installation) installed you can run `cast wallet new` in your terminal to create a new wallet and get the private key. -## Get ETH on Sepolia and OP Sepolia +## Get ETH on Sepolia and Metal L2 Testnet -This tutorial explains how to bridge tokens from Sepolia to OP Sepolia. You will need to get some ETH on both of these testnets. +This tutorial explains how to bridge tokens from Sepolia to Metal L2 Testnet. You will need to get some ETH on both of these testnets. 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. + You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on Metal L2 Testnet. ## 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. -Make sure this private key corresponds to an address that has ETH on both Sepolia and OP Sepolia. +Make sure this private key corresponds to an address that has ETH on both Sepolia and Metal L2 Testnet. ```bash export TUTORIAL_PRIVATE_KEY=0x... @@ -108,14 +108,14 @@ You'll need a few variables throughout this tutorial. Let's set those up now. ## 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. +You'll be sending a small amount of ETH as part of this tutorial. Quickly check your balance on Metal L2 Testnet so that you know how much you had at the start of the tutorial. ```js file=/public/tutorials/send-tx-from-eth.js#L17-L18 hash=2bbd74b9de0c0fa0daca043ab9030ff0 ``` ## Trigger the transaction -Now you'll use the `OptimismPortal` contract to trigger a transaction on OP Sepolia by sending a transaction on Sepolia. +Now you'll use the `OptimismPortal` contract to trigger a transaction on Metal L2 Testnet by sending a transaction on Sepolia. {

Create the OptimismPortal object

} @@ -154,7 +154,7 @@ Now you'll use the `OptimismPortal` contract to trigger a transaction on OP Sepo ## Check your updated balance -You should have a little less ETH on OP Sepolia now. Check your balance to confirm. +You should have a little less ETH on Metal L2 Testnet now. Check your balance to confirm. ```js file=/public/tutorials/send-tx-from-eth.js#L75-L76 hash=dd456528a8bae103b73c5bcd19216916 ``` @@ -166,4 +166,4 @@ Make sure that the difference is equal to the amount you were expecting to send. ## Next steps -You've successfully triggered a transaction on OP Sepolia by sending a transaction on Sepolia using Viem. 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. You can trigger smart contracts, send ERC-20 tokens, and more. +You've successfully triggered a transaction on Metal L2 Testnet by sending a transaction on Sepolia using Viem. 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. You can trigger smart contracts, send ERC-20 tokens, and more. 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 76d5ee2ec..d4fbe07b9 100644 --- a/pages/builders/app-developers/tutorials/standard-bridge-custom-token.mdx +++ b/pages/builders/app-developers/tutorials/standard-bridge-custom-token.mdx @@ -11,7 +11,7 @@ import { WipCallout } from '@/components/WipCallout' # 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. +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 Metal L2. This tutorial explains how you can create a custom token that conforms to the [`IOptimismMintableERC20`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/universal/IOptimismMintableERC20.sol) interface so that it can be used with the Standard Bridge system. A custom token allows you to do things like trigger extra logic whenever a token is deposited. @@ -33,21 +33,21 @@ This tutorial will show you how to create a custom token that implements this in * [node](https://nodejs.org/en/) * [pnpm](https://pnpm.io/installation) -## Get ETH on Sepolia and OP Sepolia +## Get ETH on Sepolia and Metal L2 Testnet -This tutorial explains how to create a bridged ERC-20 token on OP Sepolia. +This tutorial explains how to create a bridged ERC-20 token on Metal L2 Testnet. You will need to get some ETH on both of these testnets. 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. +You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on Metal L2 Testnet. -## Add OP Sepolia to your wallet +## Add Metal L2 Testnet 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. +You will need to add the Metal L2 Testnet 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 Metal L2 Testnet. ## Get an L1 ERC-20 token address @@ -57,7 +57,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 create a corresponding L2 ERC-20 token on OP Sepolia. +Once you have an L1 ERC-20 token, you can create a corresponding L2 ERC-20 token on Metal L2 Testnet. 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). You can follow the same general process within your favorite framework if you prefer. @@ -99,7 +99,7 @@ If you've disabled auto-compile, you'll need to manually compile the contract by {

Deploy the contract

} Open the deployment tab (this looks like an Ethereum logo with an arrow pointing left). -Make sure that your environment is set to "Injected Provider", your wallet is connected to OP Sepolia, and Remix has access to your wallet. +Make sure that your environment is set to "Injected Provider", your wallet is connected to Metal L2 Testnet, and Remix has access to your wallet. Then, select the `MyCustomL2Token` contract from the deployment dropdown and deploy it with the following parameters: ```text @@ -122,4 +122,4 @@ This is exactly what this tutorial was meant to demonstrate. The [Superchain Token List](https://github.com/ethereum-optimism/ethereum-optimism.github.io#readme) is a common list of tokens deployed on chains within the Optimism Superchain. This list is used by services like the [Superchain Bridges UI](https://app.optimism.io/bridge). -If you want your OP Mainnet token to be included in this list, take a look at the [review process and merge criteria](https://github.com/ethereum-optimism/ethereum-optimism.github.io#review-process-and-merge-criteria). +If you want your Metal L2 token to be included in this list, take a look at the [review process and merge criteria](https://github.com/ethereum-optimism/ethereum-optimism.github.io#review-process-and-merge-criteria). 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 21b517400..b1cffc55c 100644 --- a/pages/builders/app-developers/tutorials/standard-bridge-standard-token.mdx +++ b/pages/builders/app-developers/tutorials/standard-bridge-standard-token.mdx @@ -32,14 +32,14 @@ This tutorial will show you how to use the [`OptimismMintableERC20Factory`](http * [cast](https://book.getfoundry.sh/getting-started/installation) -## Get ETH on Sepolia and OP Sepolia +## Get ETH on Sepolia and Metal L2 Testnet -This tutorial explains how to create a bridged ERC-20 token on OP Sepolia. +This tutorial explains how to create a bridged ERC-20 token on Metal L2 Testnet. You will need to get some ETH on both of these testnets. 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. +You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on Metal L2 Testnet. ## Get an L1 ERC-20 token address @@ -50,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/develop/packages/contracts-bedrock/src/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 Metal L2 Testnet. All tokens created by the factory implement the `IOptimismMintableERC20` interface and are compatible with the Standard Bridge system. @@ -59,15 +59,15 @@ All tokens created by the factory implement the `IOptimismMintableERC20` interfa You'll need a private key in order to sign transactions. Set your private key as an environment variable with the `export` command. -Make sure this private key corresponds to an address that has ETH on OP Sepolia. +Make sure this private key corresponds to an address that has ETH on Metal L2 Testnet. ```bash export TUTORIAL_PRIVATE_KEY=0x... ``` -{

Add an OP Sepolia RPC URL to your environment

} +{

Add an Metal L2 Testnet RPC URL to your environment

} -You'll need an RPC URL in order to connect to OP Sepolia. +You'll need an RPC URL in order to connect to Metal L2 Testnet. Set your RPC URL as an environment variable with the `export` command. ```bash file=/public/tutorials/standard-bridge-standard-token.sh#L1 hash=a1c505198f7753f7d2114f4a018d7889 @@ -75,7 +75,7 @@ Set your RPC URL as an environment variable with the `export` command. {

Add your L1 ERC-20 token address to your environment

} -You'll need to know the address of your L1 ERC-20 token in order to create a bridged representation of it on OP Sepolia. +You'll need to know the address of your L1 ERC-20 token in order to create a bridged representation of it on Metal L2 Testnet. Set your L1 ERC-20 token address as an environment variable with the `export` command. ```bash file=/public/tutorials/standard-bridge-standard-token.sh#L3-L4 hash=c505f3eb6ddd80d8fbdddf4d7b17852a @@ -102,4 +102,4 @@ Check out the tutorial on [Bridging ERC-20 tokens with viem](./cross-dom-bridge- The [Superchain Token List](https://github.com/ethereum-optimism/ethereum-optimism.github.io#readme) is a common list of tokens deployed on chains within the Optimism Superchain. This list is used by services like the [Superchain Bridges UI](https://app.optimism.io/bridge). -If you want your OP Mainnet token to be included in this list, take a look at the [review process and merge criteria](https://github.com/ethereum-optimism/ethereum-optimism.github.io#review-process-and-merge-criteria). +If you want your Metal L2 token to be included in this list, take a look at the [review process and merge criteria](https://github.com/ethereum-optimism/ethereum-optimism.github.io#review-process-and-merge-criteria). diff --git a/pages/builders/node-operators/architecture.mdx b/pages/builders/node-operators/architecture.mdx index 014f7b8dc..556f97043 100644 --- a/pages/builders/node-operators/architecture.mdx +++ b/pages/builders/node-operators/architecture.mdx @@ -6,14 +6,14 @@ description: Learn about 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/). +This page reviews node architecture for all nodes running on the Superchain network. All Metal L2 nodes are composed of two core software services, the Rollup Node and the Execution Client. +Metal L2 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 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) +![Metal L2 node architecture diagram.](/img/guides/node-operators/node-arch.svg) ## Rollup node @@ -27,13 +27,13 @@ The Execution Client is largely analogous to an [execution client](https://ether ## Legacy Geth -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. -Blocks and transactions included in OP Mainnet prior to the Bedrock Upgrade are served by current execution engines but cannot be executed without the help of a special component called Legacy Geth. +Metal L2 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. +Blocks and transactions included in Metal L2 prior to the Bedrock Upgrade are served by current execution engines but cannot be executed without the help of a special component called Legacy Geth. This means that you will need to run Legacy Geth if you want to be able to run RPC calls such as `eth_call` on blocks before the Bedrock Upgrade. -Legacy Geth is the software that was used to run OP Mainnet nodes prior to the Bedrock Upgrade. -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. +Legacy Geth is the software that was used to run Metal L2 nodes prior to the Bedrock Upgrade. +If you run an instance of Legacy Geth alongside your Metal L2 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 Metal L2. ## Next steps diff --git a/pages/builders/node-operators/configuration/base-config.mdx b/pages/builders/node-operators/configuration/base-config.mdx index 610fd7fe6..308d638e3 100644 --- a/pages/builders/node-operators/configuration/base-config.mdx +++ b/pages/builders/node-operators/configuration/base-config.mdx @@ -29,13 +29,13 @@ To configure your node, you will need to do the following: Depending on the network you're running, initialization is done one of three ways: 1. **With Network Flags:** This initializes the genesis information and chain configuration from the [superchain-registry](https://github.com/ethereum-optimism/superchain-registry). -2. **With a Genesis File:** This is for deployments that are not migrated from a legacy network (i.e. OP Sepolia). In this case, you'll use a genesis file and initialize the data directory via `geth init`. -3. **With a Data Directory:** This is used for networks that are migrated from a legacy network. This currently **only** includes OP Mainnet. In this case, you'll download a preconfigured data directory and extract it. No further initialization is necessary in this case, because the data directory contains the network's genesis information. This method can be bypassed if you utilize [snap sync](/builders/node-operators/management/snap-sync). +2. **With a Genesis File:** This is for deployments that are not migrated from a legacy network (i.e. Metal L2 Testnet). In this case, you'll use a genesis file and initialize the data directory via `geth init`. +3. **With a Data Directory:** This is used for networks that are migrated from a legacy network. This currently **only** includes Metal L2. In this case, you'll download a preconfigured data directory and extract it. No further initialization is necessary in this case, because the data directory contains the network's genesis information. This method can be bypassed if you utilize [snap sync](/builders/node-operators/management/snap-sync). -Regardless of how `op-geth` is initialized, you'll need to ensure that you have sufficient disk space available to store the network's data. As of this writing, the OP Mainnet data directory is \~1.6TB for a full node and \~5TB for an archival node. +Regardless of how `op-geth` is initialized, you'll need to ensure that you have sufficient disk space available to store the network's data. As of this writing, the Metal L2 data directory is \~1.6TB for a full node and \~5TB for an archival node. ### 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. +Instructions for each initialization method are below. If you're spinning up an Metal L2, use the [Initialization via Data Directory](#initialization-via-data-directory) path. If you're spinning up an Metal L2 Testnet node, use the [Initialization via Network Flags](#initialization-via-network-flags) path. #### Initialization via network flags @@ -136,7 +136,7 @@ Consult [Geth's documentation](https://geth.ethereum.org/docs/) for more informa ## Configuring `op-node` -`op-node` is a standalone, statically linked binary. It stores no state, and requires no initialization. It consumes configuration parameters either via the command line or environment variables. For some networks, the Rollup Node also requires a configuration file (called `rollup.json` or the "rollup config") that configures network-specific genesis parameters. For official networks like OP Sepolia and OP Mainnet, the genesis config is hardcoded in the `op-node` software and can be specified via a `--network` flag. +`op-node` is a standalone, statically linked binary. It stores no state, and requires no initialization. It consumes configuration parameters either via the command line or environment variables. For some networks, the Rollup Node also requires a configuration file (called `rollup.json` or the "rollup config") that configures network-specific genesis parameters. For official networks like Metal L2 Testnet and Metal L2, the genesis config is hardcoded in the `op-node` software and can be specified via a `--network` flag. Following the [Ecotone upgrade](/builders/node-operators/network-upgrades#ecotone) node operators must set an L1 beacon value to retrieve [blobs](/builders/node-operators/management/blobs) @@ -177,7 +177,7 @@ The default port for the peer-to-peer network is `9003`. You will need to open t ## Legacy Geth -If you are running a node for an upgraded network like OP Mainnet (but not OP Sepolia), you will also need to run Legacy Geth in order to serve historical execution traces. Fundamentally, Legacy Geth is our old `l2geth` binary running against a preconfigured data directory. To configure Legacy Geth, follow the instructions above for using a preconfigured data directory, then execute the following command: +If you are running a node for an upgraded network like Metal L2 (but not Metal L2 Testnet), you will also need to run Legacy Geth in order to serve historical execution traces. Fundamentally, Legacy Geth is our old `l2geth` binary running against a preconfigured data directory. To configure Legacy Geth, follow the instructions above for using a preconfigured data directory, then execute the following command: It is imperative that you specify the `USING_OVM=true` environment variable in the command below. Failing to specify this will cause `l2geth` to return invalid execution traces, or panic at startup. diff --git a/pages/builders/node-operators/json-rpc.mdx b/pages/builders/node-operators/json-rpc.mdx index 1f0ca452c..579f70246 100644 --- a/pages/builders/node-operators/json-rpc.mdx +++ b/pages/builders/node-operators/json-rpc.mdx @@ -1,7 +1,7 @@ --- title: JSON-RPC API lang: en-US -description: Learn about the different OP Mainnet components with an RPC API. +description: Learn about the different Metal L2 components with an RPC API. --- import { Callout } from 'nextra/components' @@ -9,7 +9,7 @@ import { Tabs } from 'nextra/components' # JSON-RPC API -There are several OP Mainnet components with an RPC API, which are reviewed in this guide. +There are several Metal L2 components with an RPC API, which are reviewed in this guide. Use [`eth_gasPrice`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gasprice) instead of `rollup_gasPrices` for the L2 gas price. diff --git a/pages/builders/node-operators/management/snap-sync.mdx b/pages/builders/node-operators/management/snap-sync.mdx index 73dff898f..ac6df2f95 100644 --- a/pages/builders/node-operators/management/snap-sync.mdx +++ b/pages/builders/node-operators/management/snap-sync.mdx @@ -15,7 +15,7 @@ Snap Sync significantly improves the experience of syncing an OP Stack node. Sna 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. -* For OP Mainnet, node operators will be able to sync without having to download the [bedrock datadir](snapshots). +* For Metal L2, node operators will be able to sync without having to download the [bedrock datadir](snapshots). * This also enables nodes to join the network after Ecotone activates without requiring a [blob archiver](blobs). * Archive nodes are also fully supported. @@ -30,7 +30,7 @@ For snap sync, all `op-geth` nodes should expose port `30303` TCP and `30303` UD Choose one of the following options to enable snap sync: -* **Option 1:** Snap sync, no required datadir on OP Mainnet. This is the recommended option because `op-node` tells `op-geth` to snap sync and then `op-geth` downloads the state at tip and once complete switches to inserting blocks one by one. +* **Option 1:** Snap sync, no required datadir on Metal L2. This is the recommended option because `op-node` tells `op-geth` to snap sync and then `op-geth` downloads the state at tip and once complete switches to inserting blocks one by one. @@ -46,7 +46,7 @@ Choose one of the following options to enable snap sync: -* **Option 2:** Archive sync with required [datadir](snapshots) for OP Mainnet, but no required datadir for other OP Stack networks. +* **Option 2:** Archive sync with required [datadir](snapshots) for Metal L2, but no required datadir for other OP Stack networks. This option is faster for archive nodes than other options because `--syncmode=full` means `op-geth` executes every block in the chain. @@ -87,7 +87,7 @@ In addition to op-geth, you can enable execution-layer syncing with alternative Unlike `op-geth`, `reth` and `op-erigon` are designed as archive nodes, which means they require the complete history of the chain. However, these clients can still retrieve block headers and data through the P2P network instead of deriving each individual block, resulting in a faster initial sync. -For OP Mainnet, the [bedrock datadir](snapshots) is required. For other OP Stack networks, no datadir is required. +For Metal L2, the [bedrock datadir](snapshots) is required. For other OP Stack networks, no datadir is required. To enable execution layer sync for these clients, set the following flags on `op-node`: ```shell diff --git a/pages/builders/node-operators/management/snapshots.mdx b/pages/builders/node-operators/management/snapshots.mdx index 3c463eb70..396ec41a8 100644 --- a/pages/builders/node-operators/management/snapshots.mdx +++ b/pages/builders/node-operators/management/snapshots.mdx @@ -17,9 +17,9 @@ Data directories and node snapshots are not required but can significantly simpl ## 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. -Migrated OP Mainnet databases can be generated manually or pre-migrated databases can be downloaded from the links on this page. +Metal L2 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 Metal L2 database to run a node. +Migrated Metal L2 databases can be generated manually or pre-migrated databases can be downloaded from the links on this page. ## Snapshots @@ -39,7 +39,7 @@ Migrated OP Mainnet databases can be generated manually or pre-migrated database {/* ### Metal L2 (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). + [Allnodes](https://www.allnodes.com) provides more recent full node snapshots for Metal L2 and Testnet. You can find them [here](https://www.publicnode.com/snapshots#optimism). **Please note:** Allnodes is a 3rd party provider, and the Optimism Foundation hasn't verified the snapshots. diff --git a/pages/builders/node-operators/releases.mdx b/pages/builders/node-operators/releases.mdx index bcd6cf49a..d7d7cee0c 100644 --- a/pages/builders/node-operators/releases.mdx +++ b/pages/builders/node-operators/releases.mdx @@ -37,7 +37,7 @@ We follow a consistent tagging convention to make it easier to find the right im ## Release entries -| Network | op-node | op-geth | -| ---------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | -| OP Mainnet | [v1.7.7](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.7) | [v1.101315.2](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101315.2) | -| OP Sepolia | [v1.7.7](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.7) | [v1.101315.2](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101315.2) | +| Network | op-node | op-geth | +| ---------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | +| Metal L2 | [v1.7.7](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.7) | [v1.101315.2](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101315.2) | +| Metal L2 Testnet | [v1.7.7](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.7) | [v1.101315.2](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101315.2) | diff --git a/pages/builders/node-operators/rollup-node.mdx b/pages/builders/node-operators/rollup-node.mdx index 19c82347c..04e366133 100644 --- a/pages/builders/node-operators/rollup-node.mdx +++ b/pages/builders/node-operators/rollup-node.mdx @@ -23,7 +23,7 @@ Before building your node, you will learn fundamental aspects of OP Stack rollup * **Network Upgrades**: Network upgrades for OP Stack rollup nodes are generally [activated by timestamps](/builders/node-operators/network-upgrades#activations). Failing to upgrade your node before the timestamp causes a chain divergence, requiring you to resync your node to reconcile the chain. Follow the established [Node Upgrade Process](/builders/node-operators/network-upgrades#upgrade-process) to avoid chain divergence. - If you are building an archive node on OP Mainnet, then you'll need a [node snapshot](/builders/node-operators/management/snapshots). This is **not required** for nodes using [snap sync](/builders/node-operators/management/snap-sync). + If you are building an archive node on Metal L2, then you'll need a [node snapshot](/builders/node-operators/management/snapshots). This is **not required** for nodes using [snap sync](/builders/node-operators/management/snap-sync). {

Build Your OP Stack Node

} @@ -31,7 +31,7 @@ Before building your node, you will learn fundamental aspects of OP Stack rollup Now, you are ready to build your OP Stack rollup node. You have two options for this: * **Option 1:** Follow the [Running a Node with Docker](/builders/node-operators/tutorials/node-from-docker) tutorial, which gets your OP Stack rollup node up and running without having to build it from source. - * **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. + * **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 @@ -46,9 +46,9 @@ OP Stack rollup nodes can be configured for individual needs. The following step * Configure `op-node` using the [base configuration](/builders/node-operators/configuration/base-config#working-base-configuration-1). {

Enable Snap Sync

} - - * Enable [snap sync](/builders/node-operators/management/snap-sync) for your node to significantly improve the experience and speed of syncing an OP Stack node. - This is an **optional** feature but highly recommended for node providers. + + * Enable [snap sync](/builders/node-operators/management/snap-sync) for your node to significantly improve the experience and speed of syncing an OP Stack node. + This is an **optional** feature but highly recommended for node providers. Additional configuration options exist for [`op-geth`](/builders/node-operators/configuration/execution-config) and [`op-node`](/builders/node-operators/configuration/consensus-config), respectively. @@ -62,14 +62,14 @@ Now, you will run your node and set your node debugging log level for more granu {

Run Your Node From Source

} - You will now run your node from source for your Superchain network. Here are your options. + You will now run your node from source for your Superchain network. Here are your options. The tutorial [Building a Node from Source](/builders/node-operators/tutorials/node-from-source) is a **pre-requisite** to running your node from source and must be completed first. - * **Option 1:** Follow the [Running an OP Sepolia Node from Source](/builders/node-operators/tutorials/testnet) tutorial. - * **Option 2:** Follow the [Running an OP Mainnet Node from Source](/builders/node-operators/tutorials/mainnet) tutorial, if you plan to run a full node or archive node. + * **Option 1:** Follow the [Running an Metal L2 Testnet Node from Source](/builders/node-operators/tutorials/testnet) tutorial. + * **Option 2:** Follow the [Running an Metal L2 Node from Source](/builders/node-operators/tutorials/mainnet) tutorial, if you plan to run a full node or archive node. {

Update Node Log Level

} @@ -91,13 +91,12 @@ It is important to regularly monitor your node, and you can optionally configure {

Setup Prometheus & Grafana

} - The following steps are intended for `go-ethereum`, so it must be tweaked to work for rollup nodes running within the Superchain. + The following steps are intended for `go-ethereum`, so it must be tweaked to work for rollup nodes running within the Superchain. * Setup [influxdb](https://geth.ethereum.org/docs/monitoring/dashboards#setting-up-influxdb) to hold metrics data. * Setup [prometheus](https://geth.ethereum.org/docs/monitoring/dashboards#setting-up-prometheus) to read your endpoint. * Setup your [grafana dashboard](https://geth.ethereum.org/docs/monitoring/dashboards#setting-up-grafana) to provide UI for metrics. - ## Follow node updates @@ -114,12 +113,12 @@ It is important to regularly monitor your node, and you can optionally configure Head over to GitHub to [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). -| Tutorial Name | Description | Difficulty Level | -| ----------------------------------------------------------- | ------------------------------------------------------ | ---------------- | -| [Running a Node With Docker](tutorials/node-from-docker) | Learn how to run a node with Docker. | 🟢 Easy | -| [Building a Node From Source](tutorials/node-from-source) | Learn how to compile node components from source code. | 🟢 Easy | -| [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 | +| Tutorial Name | Description | Difficulty Level | +| ----------------------------------------------------------------- | ----------------------------------------------------------- | ---------------- | +| [Running a Node With Docker](tutorials/node-from-docker) | Learn how to run a node with Docker. | 🟢 Easy | +| [Building a Node From Source](tutorials/node-from-source) | Learn how to compile node components from source code. | 🟢 Easy | +| [Running an Metal L2 Node from Source](tutorials/mainnet) | Learn how to run an Metal L2 node from source code. | 🟡 Medium | +| [Running an Metal L2 Testnet Node from Source](tutorials/testnet) | Learn how to run an Metal L2 Testnet node from source code. | 🟡 Medium | ## Next steps diff --git a/pages/builders/node-operators/tutorials.mdx b/pages/builders/node-operators/tutorials.mdx index de908fd0f..8d7ad3489 100644 --- a/pages/builders/node-operators/tutorials.mdx +++ b/pages/builders/node-operators/tutorials.mdx @@ -10,14 +10,14 @@ import { Card, Cards } from 'nextra/components' # Tutorials -This section provides information on various node operations. It covers running an OP Mainnet node from source, running a node with Docker, building a node from source, and running an OP Sepolia node from source. You'll find tutorials and guides to help you understand and work with these topics. +This section provides information on various node operations. It covers running an Metal L2 node from source, running a node with Docker, building a node from source, and running an Metal L2 Testnet node from source. You'll find tutorials and guides to help you understand and work with these topics. - + - + diff --git a/pages/builders/node-operators/tutorials/_meta.json b/pages/builders/node-operators/tutorials/_meta.json index cff8f7900..5b4ea4975 100644 --- a/pages/builders/node-operators/tutorials/_meta.json +++ b/pages/builders/node-operators/tutorials/_meta.json @@ -1,6 +1,6 @@ { "node-from-docker": "Running a node with Docker", "node-from-source": "Building a node from source", - "mainnet": "Running OP Mainnet from source", - "testnet": "Running OP Sepolia from source" + "mainnet": "Running Metal L2 from source", + "testnet": "Running Metal L2 Testnet from source" } diff --git a/pages/builders/node-operators/tutorials/mainnet.mdx b/pages/builders/node-operators/tutorials/mainnet.mdx index 4ae527e4e..e7dceac26 100644 --- a/pages/builders/node-operators/tutorials/mainnet.mdx +++ b/pages/builders/node-operators/tutorials/mainnet.mdx @@ -1,15 +1,15 @@ --- -title: Running an OP Mainnet node from source +title: Running an Metal L2 node from source lang: en-US -description: Learn how to run an OP Mainnet node from source code for full nodes and archive nodes. +description: Learn how to run an Metal L2 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 Metal L2 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. +This tutorial explains how to run an Metal L2 node from source code for full nodes and archive nodes. +Running an Metal L2 node from source code is a flexible alternative to using pre-built Docker images. ## Building the source code @@ -18,7 +18,7 @@ Make sure to follow the instructions on [Building a Node from Source](./node-fro ## Hardware requirements -Hardware requirements for OP Mainnet nodes can vary depending on the type of node you plan to run. +Hardware requirements for Metal L2 nodes can vary depending on the type of node you plan to run. Archive nodes generally require significantly more resources than full nodes. Below are suggested minimum hardware requirements for each type of node. @@ -36,7 +36,7 @@ Below are the storage needs as of April 2024: Based on these trends, node operators should plan for future storage needs and choose SSDs that can handle these increasing requirements. - 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. + Geth supports a "freezer" feature to store older chain data on HDDs, saving SSD space. Configure this for Metal L2 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 @@ -108,7 +108,7 @@ You can still start `op-geth` without yet running `op-node`, but the `op-geth` i ### Start `op-node` Once you've started `op-geth`, you can start `op-node`. -`op-node` will connect to `op-geth` and begin synchronizing the OP Mainnet state. +`op-node` will connect to `op-geth` and begin synchronizing the Metal L2 state. `op-node` will begin sending block payloads to `op-geth` when it derives enough blocks from Ethereum. @@ -172,7 +172,7 @@ Once you've started `op-geth`, you can start `op-node`. ### 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. +communicate with each other and synchronize the Metal L2 chain. #### Snap sync (default) @@ -226,12 +226,12 @@ There are two stages on `op-geth` for snap sync: #### Full sync -You will need access to the migrated OP Mainnet database to run a full node with full sync. +You will need access to the migrated Metal L2 database to run a full node with full sync. You can [migrate your own data directory](https://web.archive.org/web/20240110231645/https://blog.oplabs.co/reproduce-bedrock-migration/) or follow the options available for [archive nodes](#get-the-migrated-data-directory). Initial full synchronization can take several days or weeks to complete. During this time, you will initially observe `op-node` deriving blocks from Ethereum without sending these blocks to `op-geth`. -This means that `op-node` is requesting blocks from Ethereum one-by-one and determining the corresponding OP Mainnet blocks that were published to Ethereum. +This means that `op-node` is requesting blocks from Ethereum one-by-one and determining the corresponding Metal L2 blocks that were published to Ethereum. You should see logs like the following from `op-node`: ```text @@ -264,18 +264,18 @@ INFO [06-26|14:02:12.982] Starting work on payload id=0x5542117d ### 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. +Metal L2 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 Metal L2 database to run an archive node. You can [migrate your own data directory](https://web.archive.org/web/20240110231645/https://blog.oplabs.co/reproduce-bedrock-migration/) or simply download database that has already been migrated. In this section, you'll learn how to download and verify the pre-migrated database. {

Download the Migrated Data Directory

} - Click the link below to find the latest publicly available database snapshots for OP Mainnet. + Click the link below to find the latest publicly available database snapshots for Metal L2. Snapshots are available for multiple dates and snapshots get larger as they get closer to the current date. Snapshots are large files and may take some time to download. - [OP Mainnet Snapshots](/builders/node-operators/management/snapshots#op-mainnet) + [Metal L2 Snapshots](/builders/node-operators/management/snapshots#op-mainnet) {

Verify the Download

} @@ -300,7 +300,7 @@ In this section, you'll learn how to download and verify the pre-migrated databa ``` Your exact output will depend on the snapshot you've downloaded. - Check the [OP Mainnet Snapshots](/builders/node-operators/management/snapshots#op-mainnet) page for the correct checksum for the snapshot you've downloaded. + Check the [Metal L2 Snapshots](/builders/node-operators/management/snapshots#op-mainnet) page for the correct checksum for the snapshot you've downloaded. {

Extract the Data Directory

} @@ -324,11 +324,11 @@ In this section, you'll learn how to download and verify the pre-migrated databa ### 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`). -If you need to run stateful queries like `eth_call` against these older blocks and transactions, you will need to run a Legacy Geth node alongside your OP Mainnet node. +Blocks and transactions included in Metal L2 before the Bedrock Upgrade cannot be executed by modern Metal L2 nodes. +Metal L2 nodes will **serve** these blocks and transactions but cannot run certain queries against them (e.g. `eth_call`). +If you need to run stateful queries like `eth_call` against these older blocks and transactions, you will need to run a Legacy Geth node alongside your Metal L2 node. -Running a Legacy Geth node is entirely optional and typically only useful for operators who want to run complete archive nodes of the OP Mainnet state. +Running a Legacy Geth node is entirely optional and typically only useful for operators who want to run complete archive nodes of the Metal L2 state. If you want to run a full node then you can safely skip this section. @@ -369,7 +369,7 @@ If you want to run a full node then you can safely skip this section. ### 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. +If you've chosen to run a Legacy Geth node alongside your Metal L2 node, you'll need to start it before you start your Metal L2 node. {

Navigate to your Legacy Geth directory

} diff --git a/pages/builders/node-operators/tutorials/node-from-docker.mdx b/pages/builders/node-operators/tutorials/node-from-docker.mdx index 9f18059fb..2488fe180 100644 --- a/pages/builders/node-operators/tutorials/node-from-docker.mdx +++ b/pages/builders/node-operators/tutorials/node-from-docker.mdx @@ -8,14 +8,14 @@ import { Callout, Steps } from 'nextra/components' # 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. +Using [Docker](https://docs.docker.com/engine/install/) is an easy way to run an Metal L2 node. +This tutorial will walk you through the process of using [`simple-optimism-node`](https://github.com/smartcontracts/simple-optimism-node) to run an Metal L2 or Metal L2 Testnet 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. +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 Metal L2. ## What's included -`simple-optimism-node` includes all the basic components to run an OP Mainnet or OP Sepolia node. +`simple-optimism-node` includes all the basic components to run an Metal L2 or Metal L2 Testnet node. It also includes several additional services to monitor the health of your node and the health of the network you're connected to. See the [What's Included](https://github.com/smartcontracts/simple-optimism-node#whats-included) section of the `simple-optimism-node` README for more details. @@ -52,8 +52,8 @@ Configuration for `simple-optimism-node` is handled through environment variable **NETWORK_NAME** - Choose which Optimism network layer you want to operate on: - * `op-mainnet` - OP Mainnet - * `op-sepolia` - OP Sepolia (Testnet) + * `op-mainnet` - Metal L2 + * `op-sepolia` - Metal L2 Testnet (Testnet) * `base-mainnet` - Base Mainnet * `base-sepolia` - Base Sepolia (Testnet) @@ -75,8 +75,8 @@ Configuration for `simple-optimism-node` is handled through environment variable **HEALTHCHECK__REFERENCE_RPC_PROVIDER** - Specify the public RPC endpoint for Layer 2 network you want to operate on for healthcheck. For instance: - * **OP Mainnet** - [https://mainnet.optimism.io](https://mainnet.optimism.io) - * **OP Sepolia** - [https://sepolia.optimism.io](https://sepolia.optimism.io) + * **Metal L2** - [https://mainnet.optimism.io](https://mainnet.optimism.io) + * **Metal L2 Testnet** - [https://sepolia.optimism.io](https://sepolia.optimism.io) * **Base Mainnet** - [https://mainnet.base.org](https://mainnet.base.org) * **Base Sepolia** - [https://sepolia.base.org](https://sepolia.base.org) diff --git a/pages/builders/node-operators/tutorials/node-from-source.mdx b/pages/builders/node-operators/tutorials/node-from-source.mdx index 97e01389e..43838e0fc 100644 --- a/pages/builders/node-operators/tutorials/node-from-source.mdx +++ b/pages/builders/node-operators/tutorials/node-from-source.mdx @@ -8,7 +8,7 @@ import { Callout, Steps } from 'nextra/components' # 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. +Docker images are the easiest way to run an Metal L2 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. @@ -32,9 +32,9 @@ In this tutorial you will build the `op-geth` implementation of the Execution Cl ### 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/). -Legacy Geth is only relevant to OP Mainnet archive nodes and is not required for full nodes or OP Sepolia nodes. +Legacy Geth is an optional component for Metal L2 archive nodes. +Legacy Geth allows you to execute stateful queries like `eth_call` against blocks and transactions that occurred before the Metal L2 [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/). +Legacy Geth is only relevant to Metal L2 archive nodes and is not required for full nodes or Metal L2 Testnet nodes. 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). @@ -77,7 +77,7 @@ git checkout Make sure to read the Releases page carefully to determine the correct branch to check out. -Some releases may only be required for the OP Sepolia testnet. +Some releases may only be required for the Metal L2 Testnet testnet. {

Install Node.js dependencies

} @@ -133,7 +133,7 @@ git checkout Make sure to read the Releases page carefully to determine the correct branch to check out. -Some releases may only be required for the OP Sepolia testnet. +Some releases may only be required for the Metal L2 Testnet testnet. {

Build op-geth

} @@ -148,9 +148,9 @@ make geth ## 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/). -Legacy Geth is only relevant to OP Mainnet archive nodes and is not required for full nodes or OP Sepolia nodes. +Legacy Geth is an optional component for Metal L2 archive nodes. +Legacy Geth allows you to execute stateful queries like `eth_call` against blocks and transactions that occurred before the Metal L2 [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/). +Legacy Geth is only relevant to Metal L2 archive nodes and is not required for full nodes or Metal L2 Testnet nodes. @@ -174,6 +174,6 @@ make ## 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) +* Click here to [Run an Metal L2 Node from Source Code](mainnet) +* Click here to [Run an Metal L2 Testnet Node from Source Code](testnet) * If you run into any problems, please visit the [Node Troubleshooting Guide](../management/troubleshooting) for help. diff --git a/pages/builders/node-operators/tutorials/testnet.mdx b/pages/builders/node-operators/tutorials/testnet.mdx index bec9846dc..4c7c53808 100644 --- a/pages/builders/node-operators/tutorials/testnet.mdx +++ b/pages/builders/node-operators/tutorials/testnet.mdx @@ -1,15 +1,15 @@ --- -title: Running an OP Sepolia node from source +title: Running an Metal L2 Testnet node from source lang: en-US -description: Learn how to run an OP Sepolia node from source code. +description: Learn how to run an Metal L2 Testnet node from source code. --- import { Callout, Steps } from 'nextra/components' -# Running an OP Sepolia node from source +# Running an Metal L2 Testnet 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. +This tutorial explains how to run an Metal L2 Testnet node from source code. +Running an Metal L2 Testnet node from source code is a flexible alternative to using pre-built Docker images. ## Building the source code @@ -18,7 +18,7 @@ Make sure to follow the instructions on [Building a Node from Source](./node-fro ## Hardware requirements -Hardware requirements for OP Sepolia nodes can vary depending on the type of node you plan to run. +Hardware requirements for Metal L2 Testnet nodes can vary depending on the type of node you plan to run. Archive nodes generally require significantly more resources than full nodes. Below are suggested minimum hardware requirements for each type of node. @@ -101,7 +101,7 @@ Refer to the `op-geth` [configuration documentation](/builders/node-operators/co ## Start `op-node` Once you've started `op-geth`, you can start `op-node`. -`op-node` will connect to `op-geth` and begin synchronizing the OP Sepolia state. +`op-node` will connect to `op-geth` and begin synchronizing the Metal L2 Testnet state. `op-node` will begin sending block payloads to `op-geth` when it derives enough blocks from Sepolia. @@ -165,7 +165,7 @@ Note that this flag will cause `op-node` to trust the L1 node to provide correct ### 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. +communicate with each other and synchronize the Metal L2 chain. #### Snap sync (default) @@ -221,7 +221,7 @@ There are two stages on `op-geth` for snap sync: Initial full synchronization can take several days to complete. During this time, you will initially observe `op-node` deriving blocks from Ethereum without sending these blocks to `op-geth`. -This means that `op-node` is requesting blocks from Ethereum one-by-one and determining the corresponding OP Mainnet blocks that were published to Ethereum. +This means that `op-node` is requesting blocks from Ethereum one-by-one and determining the corresponding Metal L2 blocks that were published to Ethereum. You should see logs like the following from `op-node`: ```text diff --git a/pages/builders/notices.mdx b/pages/builders/notices.mdx index 781fe852e..ae337c153 100644 --- a/pages/builders/notices.mdx +++ b/pages/builders/notices.mdx @@ -8,8 +8,5 @@ import { Card, Cards } from 'nextra/components' # Notices -Documentation covering changes in the Metal L2 ecosystem. +Upcoming changes in the Metal L2 ecosystem to be aware of. - - - diff --git a/pages/builders/notices/_meta.json b/pages/builders/notices/_meta.json index 88db5df64..2c63c0851 100644 --- a/pages/builders/notices/_meta.json +++ b/pages/builders/notices/_meta.json @@ -1,3 +1,2 @@ { - "holocene-changes": "Preparing for Holocene breaking changes" } diff --git a/pages/builders/notices/holocene-changes.mdx b/pages/builders/notices/holocene-changes.mdx deleted file mode 100644 index da88e832b..000000000 --- a/pages/builders/notices/holocene-changes.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Preparing for Holocene Breaking Changes -lang: en-US -description: Learn how to prepare for Holocene upgrade breaking changes. ---- - -import { Steps, Callout } from 'nextra/components' - -# Preparing for Holocene breaking changes - -This page outlines breaking changes related to the Holocene network upgrade for chain operators, and node operators. -If you experience difficulty at any stage of this process, please reach out on our [discord channel](https://discord.com/channels/360460943378874381/1180364506690498591). - - - The Holocene upgrade for Metal L2 is scheduled for **Thu 9 Jan 2025 18:00:01 UTC**, [governance approval](https://vote.optimism.io/proposals/20127877429053636874064552098716749508236019236440427814457915785398876262515). - - -## What's included in Holocene - -Holocene contains three changes: - -* **Holocene block derivation**: a set of changes that render the derivation pipeline stricter and simpler, improving worst-case scenarios for the Fault Proof System and Interoperability. -* **EIP-1559 configurability**: The elasticity and denominator EIP-1559 parameters become configurable via the `SystemConfig` L1 contract, allowing the gas target and gas limit to be configured independently. -* **MIPS contract upgrade**: Updates to support additional calls made by the new `op-program` version. - -For more information on the Holocene implementation details, please review [Holocene specification](https://specs.optimism.io/protocol/holocene/overview.html). - -## For node operators - -Node operators will need to upgrade to the respective Holocene releases before the activation dates. Please reach out to your Metal L2 contact for assistance. diff --git a/pages/builders/tools/build/block-explorers.mdx b/pages/builders/tools/build/block-explorers.mdx index fa3a588fd..19471e9f8 100644 --- a/pages/builders/tools/build/block-explorers.mdx +++ b/pages/builders/tools/build/block-explorers.mdx @@ -34,7 +34,7 @@ Blockscout also has some OP-Stack specific features: [Superscan](https://superscan.network) is the dev-focused Superchain explorer unified at the ecosystem level, powered by [Routescan](https://routescan.io). On the Superscan, developers can quickly glance at transactions, blocks, addresses, deployed contracts and more across the Superchain in unified pages. The Superscan currently includes: -* Mainnet - OP Mainnet, Base, Zora, Mode, Cyber, Orderly, Fraxtal, Public Goods Network +* Mainnet - Metal L2, Base, Zora, Mode, Cyber, Orderly, Fraxtal, Public Goods Network * Testnet - Zora, Mode, Orderly, Fraxtal */} diff --git a/pages/builders/tools/build/faucets.mdx b/pages/builders/tools/build/faucets.mdx index 34bc7bee2..eb4eb2114 100644 --- a/pages/builders/tools/build/faucets.mdx +++ b/pages/builders/tools/build/faucets.mdx @@ -1,14 +1,14 @@ --- 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. +description: Learn how to get testnet ETH on test networks like Sepolia and Metal L2 Testnet for development and testing purposes. --- import { Callout } from 'nextra/components' # 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. +Faucets are developers tools that allow you to get free ETH (and other tokens) on test networks like Sepolia and Metal L2 Testnet so that you can send transactions and create smart contracts. Here you'll find a list of active faucets that you can try out. Different faucets use different authentication methods, so you may have to try a few before you find one that works for you. Faucets can occasionally also run out of ETH, so if you're having trouble getting ETH from a faucet, try another one. @@ -18,31 +18,31 @@ Faucets can occasionally also run out of ETH, so if you're having trouble gettin - Tokens on test networks like Sepolia or OP Sepolia have no value and are only meant for testing. + Tokens on test networks like Sepolia or Metal L2 Testnet have no value and are only meant for testing. Metal L2 contributors only take what they need so that others can use faucets too! ## 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](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, Metal L2 Testnet, 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 -| Faucet Name | Supported Networks | -| ------------------------------------------------------------------------------------------ | --------------------------------- | -| [Alchemy Faucet](https://sepoliafaucet.com) | Sepolia | -| [Infura Faucet](https://www.infura.io/faucet/sepolia) | Sepolia | -| [QuickNode Faucet](https://faucet.quicknode.com/optimism/) | Sepolia, OP Sepolia | -| [Farcaster Frame Faucet by LearnWeb3](https://warpcast.com/haardikkk/0x28f4237d) | Sepolia, OP Sepolia | -| [LearnWeb3 Web App Faucet](https://learnweb3.io/faucets) | Sepolia, OP Sepolia | -| [Native USDC Faucet](https://faucet.circle.com/) | Sepolia, OP Sepolia | -| [Ethereum Ecosystem Faucets](https://www.ethereum-ecosystem.com/faucets) | Sepolia, OP Sepolia, Base Sepolia | -| [thirdweb Sepolia Faucet](https://thirdweb.com/sepolia?utm_source=opdocs\&utm_medium=docs) | Sepolia | +| Faucet Name | Supported Networks | +| ------------------------------------------------------------------------------------------ | --------------------------------------- | +| [Alchemy Faucet](https://sepoliafaucet.com) | Sepolia | +| [Infura Faucet](https://www.infura.io/faucet/sepolia) | Sepolia | +| [QuickNode Faucet](https://faucet.quicknode.com/optimism/) | Sepolia, Metal L2 Testnet | +| [Farcaster Frame Faucet by LearnWeb3](https://warpcast.com/haardikkk/0x28f4237d) | Sepolia, Metal L2 Testnet | +| [LearnWeb3 Web App Faucet](https://learnweb3.io/faucets) | Sepolia, Metal L2 Testnet | +| [Native USDC Faucet](https://faucet.circle.com/) | Sepolia, Metal L2 Testnet | +| [Ethereum Ecosystem Faucets](https://www.ethereum-ecosystem.com/faucets) | Sepolia, Metal L2 Testnet, Base Sepolia | +| [thirdweb Sepolia Faucet](https://thirdweb.com/sepolia?utm_source=opdocs\&utm_medium=docs) | Sepolia | ## Bridge from Sepolia -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/). +If you have testnet ETH on Sepolia, you can bridge it to Metal L2 Testnet (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 diff --git a/pages/builders/tools/build/oracles.mdx b/pages/builders/tools/build/oracles.mdx index c06d9d882..c3b4a1f39 100644 --- a/pages/builders/tools/build/oracles.mdx +++ b/pages/builders/tools/build/oracles.mdx @@ -51,7 +51,7 @@ The [API3 Market](https://market.api3.org/metal) provides access to 200+ price f ### Chronicle -The first Oracle on Ethereum, Chronicle's decentralized Oracle network was originally built within MakerDAO for the development of DAI and is now available to builders on OP Mainnet and the Superchain. +The first Oracle on Ethereum, Chronicle's decentralized Oracle network was originally built within MakerDAO for the development of DAI and is now available to builders on Metal L2 and the Superchain. * **Data Feeds**: Builders can choose from 65+ data feeds, including crypto assets, yield rates, and RWAs. Chronicle's data is sourced via custom-built data models, only utilizing Tier 1 Primary Sources, such as the markets where tokens are actively traded, including Coinbase, Binance, Uniswap, and Curve. * **Transparency & Integrity**: Chronicle's Oracle network is fully transparent and verifiable. Via [The Chronicle](https://chroniclelabs.org/dashboard/oracle/DAI/USD?blockchain=OPT\&txn=0x53e60e6e79eb938e5ca3ca6c56b0795e003dd6b3a17cfd810ca5042b3d33b680\&contract=0x104916d38828DA8B83a88A1775Aa058e1F0B1647), the data supply chain for any Oracle can be viewed in real-time and historically, including data sources and the identity of all Validators/Signers. Users can cryptographically challenge the integrity of every Oracle update using the 'verify' feature. Data is independently sourced by a [community of Validators](https://chroniclelabs.org/validators), including Gitcoin, Etherscan, Infura, DeFi Saver, and MakerDAO. diff --git a/pages/builders/tools/monitor/analytics-tools.mdx b/pages/builders/tools/monitor/analytics-tools.mdx index f7d39d0a7..95cd400b2 100644 --- a/pages/builders/tools/monitor/analytics-tools.mdx +++ b/pages/builders/tools/monitor/analytics-tools.mdx @@ -1,14 +1,14 @@ --- title: Analytics tools lang: en-US -description: Learn about platforms you can use to gather analytics and setup customizations about OP Mainnet. +description: Learn about platforms you can use to gather analytics and setup customizations about Metal L2. --- import { Callout } from 'nextra/components' # Analytics tools -The following guide lists platforms you can use to gather analytics and setup customizations about OP Mainnet. +The following guide lists platforms you can use to gather analytics and setup customizations about Metal L2. ## Blocknative @@ -21,7 +21,7 @@ The following guide lists platforms you can use to gather analytics and setup cu ## Tenderly -[Tenderly](https://tenderly.co/) monitoring stack lets you [inspect any transaction execution on OP Mainnet or OP Sepolia](https://docs.tenderly.co/debugger#how-to-use-tenderly-debugger). +[Tenderly](https://tenderly.co/) monitoring stack lets you [inspect any transaction execution on Metal L2 or Metal L2 Testnet](https://docs.tenderly.co/debugger#how-to-use-tenderly-debugger). You can inspect the state of your verified contract in any step of the transaction's execution, as well as step into or over function calls. The level of detail the Tenderly dashboard presents will reduce your development time as well as help you understand the execution flow of transactions. @@ -33,7 +33,7 @@ It helps you to inspect states at every instance of transaction and gives a plat ## 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. +[Dune Analytics](https://dune.com) allows anyone to create dashboards that present information about OP Chains (Metal L2, 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. Here are some of our favorite dashboards so far: @@ -46,9 +46,9 @@ Here are some of our favorite dashboards so far: ## Additional tools and resources -Here are some additional tools and resources for OP Mainnet analytics and development: +Here are some additional tools and resources for Metal L2 analytics and development: -* DeFi Stats: [OP Mainnet's DeFiLlama Page](https://defillama.com/chain/Optimism/) +* DeFi Stats: [Metal L2's DeFiLlama Page](https://defillama.com/chain/Optimism/) * L2 Usage and Comparison: [growthepie](https://www.growthepie.xyz/) * OP Analytics (Incentive Tracking, Helper Functions, Public Analysis): [OP Analytics on GitHub](https://github.com/ethereum-optimism/op-analytics) * Contribute to NumbaNERDs: [Issues on GitHub](https://github.com/ethereum-optimism/op-analytics/issues) diff --git a/pages/builders/tools/monitor/regenesis-history.mdx b/pages/builders/tools/monitor/regenesis-history.mdx index c262e7ae3..501b233df 100644 --- a/pages/builders/tools/monitor/regenesis-history.mdx +++ b/pages/builders/tools/monitor/regenesis-history.mdx @@ -54,7 +54,7 @@ No state, balances, or user assets were lost. Most of the impact is felt by data providers who want complete data sets for analysis purposes and by individuals who may want this information for tax purposes. -Since this was very early during the history of OP Mainnet there are relatively +Since this was very early during the history of Metal L2 there are relatively few transactions in this period and this data is infrequently requested. Most requests for this data came from individuals who needed access to this information for the 2021 tax season though this is mostly no longer relevant today (many diff --git a/pages/builders/tools/op-tools.mdx b/pages/builders/tools/op-tools.mdx index 18b46bd0a..fc07852e7 100644 --- a/pages/builders/tools/op-tools.mdx +++ b/pages/builders/tools/op-tools.mdx @@ -13,7 +13,7 @@ import { Card, Cards } from 'nextra/components' This section provides information on Metal L2 tools. - + diff --git a/pages/chain/security/faq.mdx b/pages/chain/security/faq.mdx index 76f5b4470..8b3e124e3 100644 --- a/pages/chain/security/faq.mdx +++ b/pages/chain/security/faq.mdx @@ -6,35 +6,35 @@ description: Learn about the Metal L2 security model and answers to common quest import { Callout } from 'nextra/components' -{/* # OP Mainnet Security Model +{/* # Metal L2 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. +Metal L2 is a work in progress. +Constant, iterative improvement of the security mechanisms that safeguard Metal L2 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 Metal L2 and the OP Stack as a whole. ## 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**. +At the moment, **it's important to understand that the security of Metal L2 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. +Metal L2 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 +## Metal L2 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. +The security of Metal L2 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. -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. +This multisig can be used to upgrade core Metal L2 smart contracts **without upgrade delays** to allow for quick responses to potential security concerns. +All upgrades to the Metal L2 system must be approved by both component multisigs and either can veto an upgrade. ## 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**. - OP Mainnet is following a multi-client and multi-proof approach designed to eventually remove the need for instant upgrades entirely. + Metal L2 is following a multi-client and multi-proof approach designed to eventually remove the need for instant upgrades entirely. -Users can withdraw ETH and tokens from OP Mainnet to Ethereum by submitting a withdrawal proof that shows the withdrawal was actually included inside of OP Mainnet. -Withdrawals are proven against proposals about the state of OP Mainnet that are published through the [`DisputeGameFactory`](https://github.com/ethereum-optimism/optimism/blob/363c5d7f4fb14180a0e2a28cc948fe2146f03dce/packages/contracts-bedrock/src/dispute/DisputeGameFactory.sol) contract. +Users can withdraw ETH and tokens from Metal L2 to Ethereum by submitting a withdrawal proof that shows the withdrawal was actually included inside of Metal L2. +Withdrawals are proven against proposals about the state of Metal L2 that are published through the [`DisputeGameFactory`](https://github.com/ethereum-optimism/optimism/blob/363c5d7f4fb14180a0e2a28cc948fe2146f03dce/packages/contracts-bedrock/src/dispute/DisputeGameFactory.sol) contract. 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. @@ -49,31 +49,31 @@ The Guardian can also choose to shift the system to use a `PermissionedDisputeGa 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. +It's important to understand that using Metal L2 inherently exposes you to the risk of bugs within the Optimism codebase, and that you use Metal L2 at your own risk. ## Work in progress ### Sequencer decentralization -The Optimism Foundation currently operates the sole sequencer on OP Mainnet. +The Optimism Foundation currently operates the sole sequencer on Metal L2. 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 -### Does OP Mainnet have fault proofs? +### Does Metal L2 have fault proofs? -**Yes**, OP Mainnet has fault proofs. +**Yes**, Metal L2 has fault proofs. It is important to note 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**. -A system with fast upgrade keys, such as OP Mainnet, is fully dependent on the upgrade keys for security. -OP Mainnet's goal is to be the first system that deploys fault proofs that can secure the system by themselves, without fast upgrade keys. +A system with fast upgrade keys, such as Metal L2, is fully dependent on the upgrade keys for security. +Metal L2's goal is to be the first system that deploys fault proofs that can secure the system by themselves, without fast upgrade keys. ### How is Optimism planning to remove the multisig? -Check out Optimism's detailed [Pragmatic Path to Decentralization](https://web.archive.org/web/20230331065342/https://medium.com/ethereum-optimism/our-pragmatic-path-to-decentralization-cb5805ca43c1) post for a detailed view into how the multisig may be removed in a way that makes OP Mainnet the first chain with true fault proof security. +Check out Optimism's detailed [Pragmatic Path to Decentralization](https://web.archive.org/web/20230331065342/https://medium.com/ethereum-optimism/our-pragmatic-path-to-decentralization-cb5805ca43c1) post for a detailed view into how the multisig may be removed in a way that makes Metal L2 the first chain with true fault proof security. -### How can I help make OP Mainnet more secure? +### How can I help make Metal L2 more secure? -[OP Mainnet has one of the biggest bug bounties (ever)](/chain/security/security-policy). +[Metal L2 has one of the biggest bug bounties (ever)](/chain/security/security-policy). You can earn up to $2,000,042 by finding critical bugs in the Optimism codebase. You can also run your own verifier node to detect network faults. diff --git a/pages/chain/security/privileged-roles.mdx b/pages/chain/security/privileged-roles.mdx index 5f86e067d..0bc44de0c 100644 --- a/pages/chain/security/privileged-roles.mdx +++ b/pages/chain/security/privileged-roles.mdx @@ -33,12 +33,12 @@ The L1 Proxy Admin is an address that can be used to upgrade most Metal L2 syste {/* ## L2 Proxy Admin -The L2 Proxy Admin is an address that can be used to upgrade most OP Mainnet system contracts on L2. The L2 Proxy Admin owner is the [aliased address](/stack/differences#address-aliasing) of the L1ProxyAdmin owner, which means the L2 ProxyAdmin Owner is equal to the L1 ProxyAdmin Owner, but due to aliasing it's a different address. Here's how that works: +The L2 Proxy Admin is an address that can be used to upgrade most Metal L2 system contracts on L2. The L2 Proxy Admin owner is the [aliased address](/stack/differences#address-aliasing) of the L1ProxyAdmin owner, which means the L2 ProxyAdmin Owner is equal to the L1 ProxyAdmin Owner, but due to aliasing it's a different address. Here's how that works: * Given an L1 contract address, the aliased L2 address is equal to `L1_contract_address` + `0x1111000000000000000000000000000000001111`. * Using `0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b` as an example, the `0x6B` address is the L2 address that's been aliased, so to figure out the original L1 address you calculate `0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b` - `0x1111000000000000000000000000000000001111`. * That result gives an L1 contract address of `0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A`, which should be the 2/2 Safe owned by Foundation + Security Council that is L1 ProxyAdmin Owner. -* No one has the private key for `0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b` on OP Mainnet, which means the only way for the L2 ProxyAdmin owner to send transactions is via deposit transactions from the L1 `0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A` address. +* No one has the private key for `0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b` on Metal L2, which means the only way for the L2 ProxyAdmin owner to send transactions is via deposit transactions from the L1 `0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A` address. * For help with the calculations, see the [`AddressAliasHelper` library](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/vendor/AddressAliasHelper.sol). ### Risks @@ -58,8 +58,8 @@ The L2 Proxy Admin is an address that can be used to upgrade most OP Mainnet sys read the descriptions above for more details. -* **OP Mainnet**: [`0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b`](https://optimistic.etherscan.io/address/0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b) -* **OP Sepolia:** [`0x2FC3ffc903729a0f03966b917003800B145F67F3`](https://sepolia-optimism.etherscan.io/address/0x2FC3ffc903729a0f03966b917003800B145F67F3) */} +* **Metal L2**: [`0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b`](https://optimistic.etherscan.io/address/0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b) +* **Metal L2 Testnet:** [`0x2FC3ffc903729a0f03966b917003800B145F67F3`](https://sepolia-optimism.etherscan.io/address/0x2FC3ffc903729a0f03966b917003800B145F67F3) */} {/* ## System Config Owner @@ -86,8 +86,8 @@ The System Config Owner is an address that can be used to change the values with ### Description -The Batcher is a software service that submits batches of transactions to Ethereum on behalf of the current OP Mainnet Sequencer. -OP Mainnet nodes will look for transactions from this address to find new batches of L2 transactions to process. +The Batcher is a software service that submits batches of transactions to Ethereum on behalf of the current Metal L2 Sequencer. +Metal L2 nodes will look for transactions from this address to find new batches of L2 transactions to process. ### Risks @@ -162,13 +162,13 @@ The Challenger is an address that can participate in and challenge `Permissioned ### Description -The Guardian is an address that can be used to pause several system contracts on OP Mainnet. +The Guardian is an address that can be used to pause several system contracts on Metal L2. This is a backup safety mechanism that allows for a temporary halt, particularly of withdrawal logic, in the event of a security concern. The Guardian can also manage various aspects of the `OptimismPortal` contract to address active security concerns. ### Capabilities -* Pause several system contracts on OP Mainnet. +* Pause several system contracts on Metal L2. * Disable the ability for specific dispute game types from being used to execute withdrawals. * Disable the ability for specific dispute game instances from being used to execute withdrawals. @@ -188,7 +188,7 @@ The Guardian can also manage various aspects of the `OptimismPortal` contract to {/* ## Mint Manager Owner -The Mint Manager Owner is an address that controls the [`MintManager`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/governance/MintManager.sol) contract that can be used to mint new OP tokens on OP Mainnet. +The Mint Manager Owner is an address that controls the [`MintManager`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/governance/MintManager.sol) contract that can be used to mint new OP tokens on Metal L2. ### Risks diff --git a/pages/connect/contribute/style-guide.mdx b/pages/connect/contribute/style-guide.mdx index b629a5fa4..f589aa377 100644 --- a/pages/connect/contribute/style-guide.mdx +++ b/pages/connect/contribute/style-guide.mdx @@ -163,8 +163,8 @@ We aim to use consistent organization that is also user-centered and accessible. * Outline the page content according to main topics first. Those will be your headings (tagged as H2). If there are subtopics that belong under a category, display those as subheaders (tagged as H3).
**Example**:
- (H1) Supporting OP Mainnet in Your Wallet (H1 page title uses "ing"verb ending)
- (H2) Connect to OP Mainnet (H2 does not use "ing"verb ending)
+ (H1) Supporting Metal L2 in Your Wallet (H1 page title uses "ing"verb ending)
+ (H2) Connect to Metal L2 (H2 does not use "ing"verb ending)
(H2) Locate Canonical Token Addresses (second H2 does not use "ing"verb ending)
diff --git a/pages/connect/resources/glossary.mdx b/pages/connect/resources/glossary.mdx index 3db9c161e..cba7bc9b8 100644 --- a/pages/connect/resources/glossary.mdx +++ b/pages/connect/resources/glossary.mdx @@ -231,19 +231,19 @@ The ability to configure the sequencer address during OP Chain deployment. This An individual chain within the Optimism Superchain. All chains, regardless of their specific properties are considered OP Chains if they are officially governed by the Optimism Collective, and therefore part of the Superchain. -### OP Mainnet +### Metal L2 -Layer 2 blockchain powered by the OP Stack. Previously known as just "Optimism,"OP Mainnet is where it all started, and the first chain to commit to the Superchain vision. +Layer 2 blockchain powered by the OP Stack. Previously known as just "Optimism,"Metal L2 is where it all started, and the first chain to commit to the Superchain vision. ### OP Stack -the modular, open source, MIT-licensed development stack that powers the OP Mainnet, OP Chains, and, in the future, the Superchain. The OP Stack is maintained by the Optimism Collective. +the modular, open source, MIT-licensed development stack that powers the Metal L2, OP Chains, and, in the future, the Superchain. The OP Stack is maintained by the Optimism Collective. ### OP Stack Fork Layer 2 blockchain that has been built using the MIT-licensed OP Stack, but is not governed by Optimism's governance or contributing sequencer revenue back to the Collective (and therefore is not on track to become part of the Superchain). This means OP Stack Forks won't necessarily share security or interoperability with OP Chains in the Superchain. -### Plasma Chain +### Alt-DA Chain A chain where transaction data is committed to on L1 but not supplied to L1 directly, with a data availability challenge fallback. @@ -292,7 +292,7 @@ A proof of a withdrawal claim which can be immediately validated, without a chal ### Withdrawal Claim -A claim about the state of one chain made on another chain. For instance, I can claim that in OP Mainnet I have burned my tokens with the intent to withdraw those tokens back to L1. +A claim about the state of one chain made on another chain. For instance, I can claim that in Metal L2 I have burned my tokens with the intent to withdraw those tokens back to L1. ### Zero Knowledge Proof diff --git a/pages/stack/components.mdx b/pages/stack/components.mdx index b89bd4a2e..3a04a7aad 100644 --- a/pages/stack/components.mdx +++ b/pages/stack/components.mdx @@ -100,7 +100,7 @@ The Governance Layer refers to the general set of tools and processes used to ma #### 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. +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 Metal L2. 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 diff --git a/pages/stack/differences.mdx b/pages/stack/differences.mdx index c4fa7120a..5bbbba9df 100644 --- a/pages/stack/differences.mdx +++ b/pages/stack/differences.mdx @@ -27,7 +27,7 @@ Withdrawal transactions are how the state of the L2 rollup can be proven to the | Opcode | Solidity Equivalent | Behavior | | ------------ | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `COINBASE` | `block.coinbase` | Returns the address of the current Sequencer's fee wallet. Effectively the same as Ethereum with the caveat that the value typically does not change from block to block. | -| `PREVRANDAO` | `block.prevrandao` | Returns the PREVRENDAO (the most recent [RANDAO](https://eips.ethereum.org/EIPS/eip-4399)) value of L1 at the current L1 origin block. | +| `PREVRANDAO` | `block.prevrandao` | Returns the PREVRANDAO (the most recent [RANDAO](https://eips.ethereum.org/EIPS/eip-4399)) value of L1 at the current L1 origin block. | | `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. | diff --git a/pages/stack/fact-sheet.mdx b/pages/stack/fact-sheet.mdx new file mode 100644 index 000000000..e7443ec6a --- /dev/null +++ b/pages/stack/fact-sheet.mdx @@ -0,0 +1,32 @@ +--- +title: OP Stack Fact Sheet +lang: en-US +description: Get an overview of features associated with an OP Stack chain +--- + +# Overview + +Get an overview of the capabilities associated with an OP Stack chain. + +While the OP Stack allows for full customization, chains in the Superchain adhere to a [standard set of technical and governance parameters](/superchain/blockspace-charter), facilitating Superchain interoperability, network security, and ease of upgrading your chain. + +# Technical stack + +| Feature | Superchain | OP Stack | +| --------------------------------- | ----------------------------- | --------------------------- | +| **Parent chain** | Ethereum | Any L1, any L2 | +| **Throughput1** | 22Mgas/s | 50Mgas/s | +| **Gas limit2** | 200M | 200M | +| **Blocktimes3** | 250ms | 250ms | +| **Data availability support** | Ethereum | Ethereum, Celestia, EigenDA | +| **Gas token support4** | ETH | ETH | +| **Upgrades** | Facilitated via OP Governance | Self-managed | +| **EVM compatibility** | Equivalent | Variable | + +1Data for Superchain from [Base](https://etherscan.io/address/0x73a79Fab69143498Ed3712e519A88a918e1f4072#readProxyContract#F14). Data for OP Stack from [opBNB](https://docs.bnbchain.org/bnb-opbnb/core-concepts/opbnb-metrics/). + +2The standard blockspace charter has a max gas limit of [200m](https://specs.optimism.io/protocol/configurability.html#gas-limit). Both gas limit and gas target can be configured through the system config. + +3While protocol blocktimes can be lowered to 1 second, subsecond blocktimes can be achieved using [Rollup Boost and Flashblocks](https://writings.flashbots.net/introducing-rollup-boost). + +4Although ETH is the gas token, chain operators can achieve the same UX of a custom gas token by using an ERC-20 paymaster. diff --git a/pages/stack/fault-proofs/cannon.mdx b/pages/stack/fault-proofs/cannon.mdx index 4ad45ea78..fc933496b 100644 --- a/pages/stack/fault-proofs/cannon.mdx +++ b/pages/stack/fault-proofs/cannon.mdx @@ -16,7 +16,7 @@ However, Cannon is Optimism's default Fault Proof Virtual Machine (FPVM). Cannon * Onchain `MIPS.sol`: EVM implementation to verify execution of a single MIPS instruction. * Offchain `mipsevm`: Go implementation to produce a proof for any MIPS instruction to verify onchain. -Note that Cannon is just one example of a FPVM that can be used to resolve disputes. +Note that Cannon is just one example of an FPVM that can be used to resolve disputes. This documentation will go into detail about the subcomponents that make up the offchain Cannon implementation as a whole. Additionally, we will explore the differences between Cannon and the onchain `MIPS.sol`. For more information about the onchain @@ -52,7 +52,7 @@ where the code that has been compiled into MIPS instructions is OP-Program. OP-Program is golang code that will be compiled into MIPS instructions and run within the Cannon FPVM. OP-Program, whether run as standalone golang code or in Cannon, fetches all necessary data used for deriving the state of the L2. It is built such that the same inputs will produce not only the same outputs, but the same execution trace. This allows all participants in a fault dispute game to run -OP-Program such that, given the same L2 output root state transition, can generate the same execution traces. This in turn generates the same +OP-Program such that, given the same L2 output root state transition, they 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 @@ -155,7 +155,7 @@ is used to parse all the symbols stored in the ELF file. Understanding which ELF they are located is important for other functionality, such as understanding if the current `PC` is running within a specific function. Another step that occurs while loading the ELF file is patching the binary of any incompatible functions. This step is crucial, as a key design decision -important**, as a key design decision in both the onchain and offchain `mipsevm` implementations is that neither implementation +in both the onchain and offchain `mipsevm` implementations is that neither implementation has access to a kernel. This is primarily due to the limitations within the EVM itself, and since the offchain Cannon implementation must match functionality exactly with its onchain counterpart, kernel access is also not available within Cannon. This means that the VMs cannot replicate behavior that would otherwise be performed by a kernel 1:1, which primarily impacts system calls (syscalls). @@ -169,9 +169,9 @@ within the ELF file, and effectively stubbing out the function by returning imme 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 code responsible for stepping through MIPS instructions. Additionally, before each MIPS instruction, `run.go` will determine whether -separate action(s) needs to be performed. The actions to be performed are configured by the user, and can include logging information, +separate action(s) need(s) to be performed. The action(s) to be performed are configured by the user, and can include logging information, stopping at a certain instruction, taking a snapshot at a certain instruction, or signaling to the VM to generate the witness proof. -Actions to be performed are instantiated and checked by [`matcher.go`](https://github.com/ethereum-optimism/optimism/blob/develop/cannon/cmd/matcher.go), +The action(s) to be performed are instantiated and checked by [`matcher.go`](https://github.com/ethereum-optimism/optimism/blob/develop/cannon/cmd/matcher.go), which generates a match function that triggers when the configured regular expression is true. Within `run.go`, the `StepFn` is the wrapper that initiates the MIPS instruction to be run. diff --git a/pages/stack/fault-proofs/challenger.mdx b/pages/stack/fault-proofs/challenger.mdx index 69e5b20c9..e98abcdab 100644 --- a/pages/stack/fault-proofs/challenger.mdx +++ b/pages/stack/fault-proofs/challenger.mdx @@ -43,7 +43,7 @@ graph TD; `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. +2. If the trusted node disagrees, `op-challenger` posts a counter-claim to challenge the proposed output. In contrast to the above scenario, 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 diff --git a/pages/stack/fault-proofs/explainer.mdx b/pages/stack/fault-proofs/explainer.mdx index 3afad066f..ca82fc0be 100644 --- a/pages/stack/fault-proofs/explainer.mdx +++ b/pages/stack/fault-proofs/explainer.mdx @@ -10,10 +10,10 @@ import Image from 'next/image' # 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. +Users withdraw ETH and tokens from OP Stack chains like Metal L2 by submitting a withdrawal proof that shows the withdrawal was actually included in the OP Stack chain. Fault Proofs allow users to permissionlessly submit and challenge the proposals about the state of an OP Stack chain that are used to prove withdrawals. -On June 10, 2024, Fault Proofs were officially added to the OP Stack and were activated on OP Mainnet. +On June 10, 2024, Fault Proofs were officially added to the OP Stack and were activated on Metal L2. This Fault Proofs upgrade moves the OP Stack closer to technical decentralization by: * allowing anyone to make proposals about the state of the L2 * allowing anyone to challenge proposals made by other users @@ -81,9 +81,9 @@ Documentation for `op-challenger` is forthcoming. ### How much ETH should a chain operator put aside to operate the Fault Proof System? The nominal operating cost of running FPs (i.e., assuming no invalid proposals or malicious actors) will depend on the initial bond set for the `FaultDisputeGame` and the frequency of posting proposals. -Assuming OP Mainnet parameters, where proposals will be posted hourly, that's 0.08 ETH per hour. +Assuming Metal L2 parameters, where proposals will be posted hourly, that's 0.08 ETH per hour. Assuming a 7 day dispute window, you'll need roughly 14 ETH (including gas costs) to make proposals. -If chains are using the similar FP deploy configs as OP Mainnet, it's recommended to stick to a 0.08 ETH initial bond. +If chains are using the similar FP deploy configs as Metal L2, it's recommended to stick to a 0.08 ETH initial bond. However, the capital requirements for operating a FP chain in itself is much larger than 14 ETH. An operator that secures their chain using FPs must be willing to stake a lot of ETH to secure the chain. @@ -93,7 +93,7 @@ The capital requirements will be improved in the later stages of Fault Proofs to ### How large are the bonds expected to be needed to sustain and win a dispute? The bonds are sized based on the anticipated cost to post a counter-claim as well as to deter spamming invalid claims. -As an example, on OP Sepolia, the game [`0xcf8f181497DAD07277781517A76cb131C54A1BEE`](https://sepolia.etherscan.io/address/0xcf8f181497DAD07277781517A76cb131C54A1BEE) shows the escalating bond sizes. +As an example, on Metal L2 Testnet, the game [`0xcf8f181497DAD07277781517A76cb131C54A1BEE`](https://sepolia.etherscan.io/address/0xcf8f181497DAD07277781517A76cb131C54A1BEE) shows the escalating bond sizes. The list-claims subcommand of op-challenger can also provide a good view of the claims in the game: ``` diff --git a/pages/stack/fault-proofs/fp-security.mdx b/pages/stack/fault-proofs/fp-security.mdx index 6f070fb06..1cb33ce19 100644 --- a/pages/stack/fault-proofs/fp-security.mdx +++ b/pages/stack/fault-proofs/fp-security.mdx @@ -43,7 +43,7 @@ The `OptimismPortal` contract includes various security mechanisms that allow th ### 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. +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 Metal L2 to give the `SystemOwner` or `Guardian` sufficient time to respond to potential security concerns. ### Safeguards within `DelayedWETH` @@ -55,7 +55,7 @@ The `FaultDisputeGame` contracts store bonds within a `DelayedWETH` contract tha ### 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. +With the introduction of Fault Proof Mainnet, The most significant change in the security model is that `SystemOwner` can take a more passive role. 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 diff --git a/pages/stack/fault-proofs/mips.mdx b/pages/stack/fault-proofs/mips.mdx index 3623ae991..987027520 100644 --- a/pages/stack/fault-proofs/mips.mdx +++ b/pages/stack/fault-proofs/mips.mdx @@ -22,7 +22,7 @@ The `FaultDisputeGame.sol` interacts with `MIPS.sol` and then `MIPS.sol` calls i * Pre-images contain data from both L1 and L2, which includes information such as block headers, transactions, receipts, world state nodes, and more. Pre-images are used as the inputs to the derivation process used to calculate the true L2 state, and subsequently the true L2 state is used to resolve a dispute game. * A Fault Dispute Game, at a high-level, will effectively determine what L2 state is currently agreed-upon, and move through L2 state until the first disagreed-upon state is found. How the Pre-images are determined and populated into the `PreimageOracle.sol` contract is out-of-scope for this reference document on the `MIPS.sol` contract, as that contract only consumes Pre-images that have already been populated by the off-chain Cannon implementation. -The `MIPS.sol` contract is called by a running instance of a dispute game i.e. by a `FaultDisputeGame.sol` contract, and is only called once a dispute game reaches a leaf node in the state transition tree that is currently being disputed. +The `MIPS.sol` contract is called by a running instance of a dispute game (i.e. by a `FaultDisputeGame.sol` contract), and is only called once a dispute game reaches a leaf node in the state transition tree that is currently being disputed. A leaf node represents a single MIPS instruction (in the case that we're using Cannon as the FPVM) that can then be run onchain. Given a Pre-image, which is the previously agreed-upon L2 state up until this instruction, and the instruction 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. @@ -69,7 +69,7 @@ The following information is stored in the `State` struct. See [doc reference](h ### 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. +The hash is derived by taking the `keccak256` of the above packed VM execution `State` struct, then replacing the first byte of the hash with a value that represents the status of the VM. This value is derived from the `exitCode` and `exited` values, and can be: * Valid (0) @@ -78,19 +78,19 @@ This value is derived from the `exitCode` and `exited` values, and can be: * Unfinished (3) 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. +This in turn prevents a user from disputing an output root during a dispute game, while providng the state hash from a cannon trace that actually proves the output root is valid. ### 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. -The binary merkle tree (or hash tree) used to store the memory of the MIPS VM has leaf values that are 32 bytes and has a fixed depth of 27 levels. This in turn allows the binary merkle tree to span the full 32-bit address space: `2^27 * 32 = 2^32` (See [memory proofs](https://github.com/ethereum-optimism/optimism/blob/546fb2c7a5796b7fe50b0b7edc7666d3bd281d6f/cannon/docs/README.md#memory-proofs) for more details). In order to ensure the integrity of the entire address space each time memory is read or written to, one or more memory proofs are provided by the FaultDisputeGame.sol contract each time a MIPS instruction is executed onchain in MIPS.sol. A memory proof consists of the current leaf value and 27 sibling nodes (28, 32-byte values in total), where the sibling nodes are the `keccak256` hash of its own child nodes. Using the leaf value, its 27 sibling nodes, and the memory address converted to its binary representation as a guide (0 or 1 tells the order to concatenate left and right values), we can calculate a merkle root. This merkle root should be exactly the same as the merkle root stored in the VM execution State struct. +The binary merkle tree (i.e. hash tree) used to store the memory of the MIPS VM has leaf values that are 32 bytes and has a fixed depth of 27 levels. This in turn allows the binary merkle tree to span the full 32-bit address space: `2^27 * 32 = 2^32` (See [memory proofs](https://github.com/ethereum-optimism/optimism/blob/546fb2c7a5796b7fe50b0b7edc7666d3bd281d6f/cannon/docs/README.md#memory-proofs) for more details). In order to ensure the integrity of the entire address space each time memory is read or written to, one or more memory proofs are provided by the FaultDisputeGame.sol contract each time a MIPS instruction is executed onchain in MIPS.sol. A memory proof consists of the current leaf value and 27 sibling nodes (28, 32-byte values in total), where the sibling nodes are the `keccak256` hash of its own child nodes. Using the leaf value, its 27 sibling nodes, and the memory address converted to its binary representation as a guide (0 or 1 tells the order to concatenate left and right values), we can calculate a merkle root. This merkle root should be exactly the same as the merkle root stored in the VM execution State struct. -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. +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 that 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 -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. +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. These transitions are 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. ## Functions diff --git a/pages/stack/features/send-raw-transaction-conditional.mdx b/pages/stack/features/send-raw-transaction-conditional.mdx index 75cb7e8c5..71bca0a59 100644 --- a/pages/stack/features/send-raw-transaction-conditional.mdx +++ b/pages/stack/features/send-raw-transaction-conditional.mdx @@ -8,7 +8,7 @@ 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. +A sequencer RPC method, `eth_sendRawTransactionConditional`, allows 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: diff --git a/pages/stack/getting-started.mdx b/pages/stack/getting-started.mdx index 3545f5968..e03837b5a 100644 --- a/pages/stack/getting-started.mdx +++ b/pages/stack/getting-started.mdx @@ -19,7 +19,7 @@ The OP Stack is built as a public good for the Ethereum and Optimism ecosystems. ## The OP Stack powers Metal L2 -The OP Stack is the set of software that powers Metal L2 — currently in the form of the software behind OP Mainnet and eventually in the form of the Optimism Superchain and its governance. +The OP Stack is the set of software that powers Metal L2 — currently in the form of the software behind Metal L2 and eventually in the form of the Optimism Superchain and its governance. With the advent of the Superchain concept, it has become increasingly important for Optimism to easily support the secure creation of new chains that can interoperate within the proposed Superchain ecosystem. As a result, the OP Stack is primarily focused around the creation of a shared, high-quality, and fully open-source system for creating new L2 blockchains. @@ -63,7 +63,6 @@ At the end of the day, the OP Stack becomes what Optimism needs. Ready to dive into the world of the OP Stack? -* If you're interested in learning more about the current release of the OP Stack, check out the Bedrock Release page. * If you're interested in understanding the OP Stack in more depth, start with the [Design Principles](design-principles) and [Components Overview](components). The OP Stack is the next frontier for Ethereum. You're already here, so what are you waiting for? diff --git a/pages/stack/public-devnets.mdx b/pages/stack/public-devnets.mdx new file mode 100644 index 000000000..b2aa6cec4 --- /dev/null +++ b/pages/stack/public-devnets.mdx @@ -0,0 +1,57 @@ +--- +title: Public Devnets +lang: en-US +description: Learn about alphanets and betanets - the development networks for testing upcoming OP Stack releases. +--- + +# Overview + +OP Labs maintains development networks (devnets) to test new OP Stack features. +There are two different kinds of public devnets: alphanets and betanets, which serve different purposes and are deployed on different timelines. + +## Network types + +### Alphanets + +**Alphanets** are monthly devnets that include production-bound protocol upgrades that are ready for testing. +We rely on alphanets to move faster while improving the reliability of upgrades. +If a feature is ready by the monthly deployment date (typically the third Wednesday of the month), the feature will be included in that month's devnet. +Otherwise, the feature must wait for the next alphanet. +Features must be included on an alphanet before they can be deployed on a betanet. + +Alphanets decouple feature development and testing from hardfork scheduling, allowing teams to test and iterate on features well in advance of their release on mainnet. + +They're designed to stay fresh: Each one is deployed monthly and replaced, so they won't be useable as long-term networks. +Each alphanet is launched from genesis, meaning that new features are encoded in genesis rather than undergoing a network upgrade from a preexisting version. +The alphanet is then tested, with an emphasis on acceptance testing for new features followed by fault injection testing and performance / load testing. +After five weeks, the alphanet is spun down and a new alphanet takes its place, with whatever new features have been developed in that time. + +Alphanets are named after animals and ordered alphabetically. + +### Betanets + +**Betanets** are devnets that are deployed on an as-needed basis, typically ahead of an upcoming hardfork. +Features are activated using hardfork timestamps, mimicking the production upgrade process. + +Betanets are used to solidify the scope of the next hardfork before deploying to the production testnet (e.g., Metal L2 Testnet). +A betanet includes the exact set of features planned for inclusion in the next network upgrade. +Features must be included on a betanet before they can be deployed on a testnet. + +## Devnet comparison + +| Network type | Alphanet | Betanet | +| ------------------ | ------------------------------------------ | -------------------------------------- | +| Purpose | Early testing of production-bound features | Final validation for the next hardfork | +| Deployment | Monthly | As-needed | +| Feature activation | Included and activated at genesis | Activated through a network upgrade | +| Lifecycle | 5 weeks | Until replaced by the next betanet | + +## Current devnets + +**Alpaca** + +* Launch date: 2025-01-15 +* Anticipated end-of-life: 2025-02-19 +* Scope: Adds updates to the L1 contracts to support upgrades via OP Contracts Manager. +* RPC endpoint: `` +* `manifest.yaml`: `` diff --git a/pages/stack/rollup.mdx b/pages/stack/rollup.mdx index ca95c2564..09d75273b 100644 --- a/pages/stack/rollup.mdx +++ b/pages/stack/rollup.mdx @@ -11,9 +11,9 @@ import { Card, Cards } from 'nextra/components' 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 l... + + - - diff --git a/pages/stack/rollup/derivation-pipeline.mdx b/pages/stack/rollup/derivation-pipeline.mdx index 2c2aad540..2f0995104 100644 --- a/pages/stack/rollup/derivation-pipeline.mdx +++ b/pages/stack/rollup/derivation-pipeline.mdx @@ -13,7 +13,7 @@ The derivation pipeline is a fundamental component of the OP Stack protocol, res The following are key functions of the derivation pipeline: * **Batch Submission and Sequencing**: Transactions are collected and sequenced into batches by the sequencer. These batches are then submitted to Layer 1 (L1) for finality and inclusion in the blockchain. -* **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. +* **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 the Unsafe Head represents the highest unsafe L2 block that the rollup node knows about. Unsafe Blocks are those that have been sequenced but not yet confirmed on L1 (i.e. those from above the Safe Head up to and including the Unsafe Head). * **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 diff --git a/pages/stack/rollup/outages.mdx b/pages/stack/rollup/outages.mdx index 70faa381c..52677d7e9 100644 --- a/pages/stack/rollup/outages.mdx +++ b/pages/stack/rollup/outages.mdx @@ -23,7 +23,7 @@ Keep reading to learn more about these potential outages and how to handle them. ### Description Sequencer downtime outages occur when the Sequencer is unable to receive and/or process L2 transactions from users. -Outages of this type may be caused by any number of different issues including bugs in client software, cloud outages, or other similar errors. +Outages of this type may be caused by any number of different issues, including bugs in client software, cloud outages, or other similar errors. Exact causes of Sequencer downtime outages can be dependent on the specific infrastructure used to run the Sequencer for any given OP Stack chain. ### Impact diff --git a/pages/stack/rollup/overview.mdx b/pages/stack/rollup/overview.mdx index b83816a31..38126599f 100644 --- a/pages/stack/rollup/overview.mdx +++ b/pages/stack/rollup/overview.mdx @@ -9,12 +9,12 @@ description: Learn how Optimistic Rollups work at a high level. 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. +Check out the [protocol specs](https://specs.optimism.io/), if you want more details about the rollup protocol. ## 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. +Specifically, Optimistic Rollups leverage the consensus mechanism (like PoW or PoS) of their parent chain instead of providing their own. In Metal L2's case, this parent blockchain is Ethereum. ![Ethereum and Optimism Forever Doodle.](/img/op-stack/protocol/ethereum-optimism-forever.png) @@ -22,10 +22,10 @@ Specifically, Optimistic Rollups leverage the consensus mechanism (like PoW or P 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, there is no way to modify or censor them after the "transaction" is included in a block that has enough attestations. -This is the way that OP Mainnet inherits the availability and integrity guarantees of Ethereum. +This is the way that Metal L2 inherits the availability and integrity guarantees of Ethereum. 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). +This is important because writing to L1 is [the major cost of Metal L2 transactions](/stack/transactions/fees). ## Block production @@ -36,7 +36,7 @@ Optimism block production is primarily managed by a single party, called the "se * Submitting user transactions to L1. In Bedrock, the sequencer does have a mempool, similar to L1 Ethereum, but the mempool is private to avoid opening opportunities for MEV. -In OP Mainnet, blocks are produced every two seconds, regardless of whether they are empty (no transactions), filled up to the block gas limit with transactions, or anything in between. +In Metal L2, blocks are produced every two seconds, regardless of whether they are empty (no transactions), filled up to the block gas limit with transactions, or anything in between. Transactions get to the sequencer in two ways: @@ -47,17 +47,17 @@ Transactions get to the sequencer in two ways: Every L2 block is identified by the "epoch" (the L1 block to which it corresponds, which typically has happened a few minutes before the L2 block) and its serial number within that epoch. The first block of the epoch includes all the deposits that happened in the L1 block to which it corresponds. If the sequencer attempts to ignore a legitimate L1 transaction, it ends up with a state that is inconsistent with the verifiers, same as if the sequencer tried to fake the state by other means. - This provides OP Mainnet with L1 Ethereum level censorship resistance. + This provides Metal L2 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. +For the moment, [The Optimism Foundation](https://www.optimism.io/) runs the only block producer on Metal L2. ## Block execution -The execution engine (implemented as the `op-geth` component) receive blocks using two mechanisms: +The execution engine (implemented as the `op-geth` component) receives blocks using two mechanisms: -1. The execution engine can update itself using peer to peer network with other execution engines. - This operates the same way that the L1 execution clients synchronize the state across the network. +1. The execution engine can update itself using a peer-to-peer network with other execution engines. + This operates in the same way that the L1 execution clients synchronize the state across the network. You can read more about it [in the specs](https://specs.optimism.io/protocol/exec-engine.html#happy-path-sync). 2. The rollup node (implemented as the `op-node` component) derives the L2 blocks from L1. @@ -66,31 +66,31 @@ The execution engine (implemented as the `op-geth` component) receive blocks usi ## 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.). +Optimism is designed so that users can send arbitrary messages between smart contracts on L2 (Metal L2, Metal L2 Testnet, 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. The exact mechanism by which this communication occurs differs depending on the direction in which messages are being sent. -OP Mainnet uses this functionality in the Standard bridge to allow users to deposit tokens from Ethereum to OP Mainnet and also allow withdrawals of the same tokens from OP Mainnet back to Ethereum. +Metal L2 uses this functionality in the Standard bridge to allow users to deposit tokens from Ethereum to Metal L2 and also to allow withdrawals of the same tokens from Metal L2 back to Ethereum. See the [developer documentation and examples](/builders/app-developers/bridging/standard-bridge) for details on the inner workings of the Standard bridge. -### Moving from Ethereum to OP Mainnet +### Moving from Ethereum to Metal L2 -In Optimism terminology, transactions going from Ethereum (L1) to OP Mainnet (L2) are called *deposits*. +In Optimism terminology, transactions going from Ethereum (L1) to Metal L2 (L2) are called *deposits*. You use [`L1CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/L1/L1CrossDomainMessenger.sol) or [`L1StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/L1/L1StandardBridge.sol). Deposit transactions become part of the canonical blockchain in the first L2 block of the "epoch" corresponding to the L1 block where the deposits were made. This L2 block will usually be created a few minutes after the corresponding L1 block. You can read more about this [in the specs](https://specs.optimism.io/protocol/deposits.html). -### Moving from OP Mainnet to Ethereum +### Moving from Metal L2 to Ethereum -Withdrawals (the term is used for any OP Mainnet to Ethereum message) have three stages: +Withdrawals (the term is used for any Metal L2 to Ethereum message) have three stages: 1. You initialize withdrawals with an L2 transaction. 2. Wait for the next output root to be submitted to L1 (you can see this on [the SDK](https://sdk.optimism.io)) and then submit the withdrawal proof using `proveWithdrawalTransaction`. This new step enables offchain monitoring of the withdrawals, which makes it easier to identify incorrect withdrawals or output roots. - This protects OP Mainnet users against a whole class of potential bridge vulnerabilities. + This protects Metal L2 users against a whole class of potential bridge vulnerabilities. 3. After the fault challenge period ends (a week on mainnet, less than that on the test network), finalize the withdrawal. @@ -98,15 +98,15 @@ Withdrawals (the term is used for any OP Mainnet to Ethereum message) have three ## 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. +In an Optimistic Rollup, state commitments are published to L1 (Ethereum in the case of Metal L2) 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"). If a proposed state commitment goes unchallenged for the duration of the challenge window (currently set to 7 days), then it is considered final. -Once a commitment is considered final, smart contracts on Ethereum can safely accept withdrawal proofs about the state of OP Mainnet based on that commitment. +Once a commitment is considered final, smart contracts on Ethereum can safely accept withdrawal proofs about the state of Metal L2 based on that commitment. When a state commitment is challenged, it can be invalidated through a "fault proof" ([formerly known as a "fraud proof"](https://specs.optimism.io/experimental/fault-proof/index.html)) process. If the commitment is successfully challenged, then it is removed from the `StateCommitmentChain` to eventually be replaced by another proposed commitment. -It's important to note that a successful challenge does not roll back OP Mainnet itself, only the published commitments about the state of the chain. -The ordering of transactions and the state of OP Mainnet is unchanged by a fault proof challenge. +It's important to note that a successful challenge does not roll back Metal L2 itself, only the published commitments about the state of the chain. +The ordering of transactions and the state of Metal L2 is unchanged by a fault proof challenge. 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. diff --git a/pages/stack/security/faq.mdx b/pages/stack/security/faq.mdx index fd73ef329..e99923411 100644 --- a/pages/stack/security/faq.mdx +++ b/pages/stack/security/faq.mdx @@ -32,13 +32,13 @@ As with anything, modify the OP Stack at your own risk. There is no guarantee th ### Can I use fault proofs? -**Not yet.** The OP Stack does not currently have a Fault Proof System. **Note that fault proofs do not meaningfully improve the security of a system if that system can be upgraded within the 7-day challenge window ("fast upgrade keys")**. A system with fast upgrade keys is fully dependent on the upgrade keys for security. +**Yes!** On June 10, 2024, Fault Proofs were officially added to the OP Stack and were activated on Metal L2. Please refer to the [documentation on fault proofs](/stack/fault-proofs/explainer) for more information. Fault proofs are a key milestone and top priority for the OP Stack. In the meantime, the OP Stack can be shipped with several other excellent security options for systems that want to improve security before fault proofs are available in production. ### How can I help make the OP Stack more secure? -One of the easiest ways to help secure the OP Stack is to look for bugs and vulnerabilities. [OP Mainnet, a user of the OP Stack, has one of the biggest bug bounties (ever)](https://immunefi.com/bounty/optimism/). You can earn up to $2,000,042 by finding critical bugs in the OP Mainnet codebase (and by extension the OP Stack). +One of the easiest ways to help secure the OP Stack is to look for bugs and vulnerabilities. [Metal L2, a user of the OP Stack, has one of the biggest bug bounties (ever)](https://immunefi.com/bounty/optimism/). You can earn up to $2,000,042 by finding critical bugs in the Metal L2 codebase (and by extension the OP Stack). Don't forget that the OP Stack is a decentralized development stack. Anyone can start to contribute to the OP Stack by building software that follows [the stack's design principles](/stack/design-principles). You can always help make the OP Stack more secure by building components, like alternative client or proof implementations, that users of the OP Stack can take advantage of. diff --git a/pages/stack/smart-contracts.mdx b/pages/stack/smart-contracts.mdx index 0729fada9..71ab860f2 100644 --- a/pages/stack/smart-contracts.mdx +++ b/pages/stack/smart-contracts.mdx @@ -8,7 +8,7 @@ import { Callout } from 'nextra/components' # 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. +This guide provides an overview of the functionality of the smart contract components. You can also find [contract addresses](/chain/addresses) on Metal L2. ## Layer 1 contracts @@ -73,14 +73,14 @@ The upgrade was coupled with the [Granite network upgrade](/builders/node-operat The Safe Extensions protocol upgrade is intended to increase the security and decentralization of the Superchain by: -1. Increasing the Security Council Safe's signing threshold, from 4 to 10, out -of 13 owners. This meets the 75% threshold requirement for a Stage 1 rollup -outlined in [L2Beat's Stages framework](https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52) -2. Reassigning the role of Guardian from the Foundation to a new Guardian Safe -with the Security Council Safe as its sole owner. This moves the Superchain -closer to satisfying the 1 week exit window requirement for Stage 1. - * Additionally the Foundation is appointed to the new DeputyGuardian role - which is able to act as Guardian through the Guardian Safe. This +1. Increasing the Security Council Safe's signing threshold, from 4 to 10, out + of 13 owners. This meets the 75% threshold requirement for a Stage 1 rollup + outlined in [L2Beat's Stages framework](https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52) +2. Reassigning the role of Guardian from the Foundation to a new Guardian Safe + with the Security Council Safe as its sole owner. This moves the Superchain + closer to satisfying the 1 week exit window requirement for Stage 1. + * Additionally the Foundation is appointed to the new DeputyGuardian role + which is able to act as Guardian through the Guardian Safe. This appointment can be revoked by the Security Council Safe at any time. 3. Reassigning the owner of the L2ProxyAdmin contract from the Foundation to the Security Council. This ensures the Security Council Safe has a blocking @@ -127,7 +127,7 @@ the ability for the guardian to override if necessary to maintain security. As a result, withdrawals no longer depend on the privileged proposer role posting an output root, allowing the entire withdrawal process to be completed without any privileged actions. The trust assumption is reduced to requiring -only that the guardian role does not act to intervene. +only that the Guardian role does not act to intervene. Combined with the Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes 23 proposals, this satisfies the criteria to have OP Chains @@ -323,7 +323,7 @@ to use this interface instead of interacting with lower-level contracts directly #### L1ERC721Bridge The `L1ERC721bridge` is a contract which works together with the `L2ERC721Bridge` -to make it possible to transfer ERC721 tokens from Ethereum to OP Mainnet. This +to make it possible to transfer ERC721 tokens from Ethereum to Metal L2. This contract acts as an escrow for ERC721 tokens deposited into L2. #### L1StandardBridge @@ -353,51 +353,63 @@ optionally halt if using the wrong version. #### SystemConfig -The `SystemConfig` contract helps manage configuration of an OP Stack -network. Much of the network's configuration is stored on L1 and picked up by -L2 as part of the derivation of the L2 chain. The contract also contains +The `SystemConfig` contract helps manage configuration of an OP Stack +network. Much of the network's configuration is stored on L1 and picked up by +L2 as part of the derivation of the L2 chain. The contract also contains references to all other contract addresses for the chain. #### DisputeGameFactory -The `DisputeGameFactory` contract generates `FaultDisputeGame` contract -instances. +The `DisputeGameFactory` deploys instances of `FaultDisputeGame` and `PermissionedDisputeGame` +to resolve disputes about the OP Stack chain state at specific block numbers. +It serves as the entry point for creating and managing dispute games. +The factory uses the `AnchorStateRegistry` for initialization, +and integrates the `DelayedWETH` contract to manage participant bonds. #### FaultDisputeGame -The `FaultDisputeGame` contract is deployed by the `DisputeGameFactory`. Each -deployed instance of the contract acts as a host to a proposal about the state -of the OP Stack chain at a given block number. +The `FaultDisputeGame` resolves disputes about the OP Stack chain state by +allowing participants to propose or challenge states. +It is deployed by the `DisputeGameFactory` and includes logic to finalize disputes. +The contract uses the `AnchorStateRegistry` to start from trusted states, +`MIPS` to execute fault proofs, the `PreimageOracle` to validate hash-based claims, +and the `DelayedWETH` contract to handle bonds. #### PermissionedDisputeGame -The `Guardian` can also choose to revert to a `PermissionedDisputeGame` -contract that only allows specific roles to submit and challenge proposals. +The `PermissionedDisputeGame` is also deployed by the `DisputeGameFactory`, +and inherits logic and dependencies from `FaultDisputeGame` while adding role-based restrictions. +It restricts participation to specific roles, such as designated proposers or challengers. +It is used when stricter access controls are required, as enforced by the Guardian. #### AnchorStateRegistry -The `AnchorStateRegistry` is a contract that stores the latest "anchor" state -for each available `FaultDisputeGame` type. The anchor state is the latest -state that has been proposed on L1 and was not challenged within the challenge -period. By using stored anchor states, new `FaultDisputeGame` instances can -be initialized with a more recent starting state which reduces the amount of -required offchain computation. +The `AnchorStateRegistry` stores the latest "anchor" state for each dispute game type. +An anchor state is the most recent state proposed on L1 that was not challenged within the challenge period. +These states allow new dispute games to start from a trusted, recent state, reducing offchain computation requirements. #### DelayedWETH -The `DelayedWETH` contract 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. +The `DelayedWETH` contract manages bonds posted by participants during disputes. +It delays payouts to allow time for verification, ensuring that funds are distributed correctly. +This mechanism ensures participants are financially committed and disputes are finalized securely. #### MIPS -The `MIPS` smart contract is an onchain implementation of a virtual machine -(VM) that encompasses the 32-bit, Big-Endian, MIPS III Instruction Set -Architecture (ISA). +The `MIPS` contract provides an on-chain implementation of a 32-bit, Big-Endian MIPS III virtual machine, +designed to execute fault proofs for disputes by processing a standardized instruction set. +This enables instances of `FaultDisputeGame` and `PermissionedDisputeGame` to resolve disputes +over state transitions accurately and consistently. +The process starts from the trusted anchor state provided by the `AnchorStateRegistry`, +ensuring that the dispute is based on a reliable foundation. +The `PreimageOracle` is then used to retrieve pre-images of hash-based claims, +validating the data used in the computation and ensuring its integrity. #### PreimageOracle -The `PreimageOracle` contract is used for storing permissioned pre-images. +The `PreimageOracle` maps hashes to their corresponding pre-images for secure and permissioned data retrieval. +It validates hash-based claims used in disputes, such as state transitions or computational steps. +This ensures the integrity of fault proofs in `FaultDisputeGame` and `PermissionedDisputeGame` instances. #### DEPRECATED - L2OutputOracle @@ -628,18 +640,18 @@ The `EAS` predeploy implements the Ethereum Attestation Service protocol. EAS contracts are deployed on these networks: -| Network | Attestation Contract | Schema Registry Contract | -| ---------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -| 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) | +| Network | Attestation Contract | Schema Registry Contract | +| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | +| Metal L2 Testnet | [0x4200000000000000000000000000000000000021](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000021) | [0x4200000000000000000000000000000000000020](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000020) | +| Metal L2 | [0x4200000000000000000000000000000000000021](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000021) | [0x4200000000000000000000000000000000000020](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000020) | ### How to use EAS You can interact with the Ethereum Attestation Service in several ways: 1. **Using the EAS Scan UI:** - * [EAS Scan for OP Mainnet](https://optimism.easscan.org/) - * [EAS Scan for OP Sepolia](https://optimism-sepolia.easscan.org/) + * [EAS Scan for Metal L2](https://optimism.easscan.org/) + * [EAS Scan for Metal L2 Testnet](https://optimism-sepolia.easscan.org/) 2. **Using the JavaScript SDK:** * [EAS SDK Documentation](https://docs.attest.sh/docs/developer-tools/eas-sdk) diff --git a/pages/stack/transactions.mdx b/pages/stack/transactions.mdx index 4f82dfc0f..c5749c781 100644 --- a/pages/stack/transactions.mdx +++ b/pages/stack/transactions.mdx @@ -8,10 +8,9 @@ import { Card, Cards } from 'nextra/components' # Transactions -Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Transaction Flow, Transactions, Withdrawal Flow in the Transactions section of the OP Stack ecosystem. +Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Transaction Flow, Withdrawal Flow in the Transactions section of the OP Stack ecosystem. - @@ -23,7 +22,6 @@ Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Tra - diff --git a/pages/stack/transactions/deposit-flow.mdx b/pages/stack/transactions/deposit-flow.mdx index 54e80753b..ec75a47de 100644 --- a/pages/stack/transactions/deposit-flow.mdx +++ b/pages/stack/transactions/deposit-flow.mdx @@ -14,7 +14,7 @@ This guide explains the deposit flow process for L2 deposit transactions, trigge The process is somewhat similar to the way [most networking stacks work](https://en.wikipedia.org/wiki/Encapsulation_\(networking\)). Information is encapsulated in lower layer packets on the sending side and then retrieved and used by those layers on the receiving side while going up the stack to the receiving application. -![Deposit Flow Diagram.](/img/op-stack/protocol/deposit-flow.svg) +![Deposit Flow Diagram.](/img/op-stack/protocol/deposit-flow-dark-mode.svg) ## L1 processing @@ -77,7 +77,7 @@ It is possible to replay a failed deposit, possibly with more gas. ### Replays in action -To see how replays work, you can use [this contract on OP Sepolia](https://sepolia-optimism.etherscan.io/address/0xEF60cF6C6D0C1c755be104843bb72CDa3D778630#code). +To see how replays work, you can use [this contract on Metal L2 Testnet](https://sepolia-optimism.etherscan.io/address/0xEF60cF6C6D0C1c755be104843bb72CDa3D778630#code). 1. Call `stopChanges`, using this Foundry command: diff --git a/pages/stack/transactions/fees.mdx b/pages/stack/transactions/fees.mdx index 9234614fd..c1067f03c 100644 --- a/pages/stack/transactions/fees.mdx +++ b/pages/stack/transactions/fees.mdx @@ -1,7 +1,7 @@ --- -title: Transaction fees on OP Mainnet +title: Transaction fees on Metal L2 lang: en-US -description: Learn how transaction fees work on OP Mainnet. +description: Learn how transaction fees work on Metal L2. --- import { Callout } from 'nextra/components' @@ -13,13 +13,13 @@ import { Callout } from 'nextra/components' For a detailed comparison of gas limits between Optimism and Ethereum, see the [Optimism Chain Differences documentation](https://docs.optimism.io/chain/differences#transaction-fees). -# Transaction fees on OP Mainnet +# Transaction fees on Metal L2 -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. +Metal L2 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. -This page provides a detailed look at exactly how transaction fees work on OP Mainnet so you can properly account for them in your application. +This page provides a detailed look at exactly how transaction fees work on Metal L2 so you can properly account for them in your application. -OP Mainnet transaction fees are composed of an [Execution Gas Fee](#execution-gas-fee) and an [L1 Data Fee](#l1-data-fee). +Metal L2 transaction fees are composed of an [Execution Gas Fee](#execution-gas-fee) and an [L1 Data Fee](#l1-data-fee). 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. @@ -27,12 +27,12 @@ Continue reading to learn more about exactly how each of these fee components ar 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. -Like Ethereum, OP Mainnet uses the [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) mechanism to set the [base fee](https://ethereum.org/en/developers/docs/gas/#base-fee) for transactions. +Like Ethereum, Metal L2 uses the [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) mechanism to set the [base fee](https://ethereum.org/en/developers/docs/gas/#base-fee) for transactions. The total price per unit gas that a transaction pays is the sum of the [base fee](https://ethereum.org/en/developers/docs/gas/#base-fee) and the optional additional [priority fee](https://ethereum.org/en/developers/docs/gas/#priority-fee). -Because OP Mainnet is EVM equivalent, **the gas used by a transaction on OP Mainnet is exactly the same as the gas used by the same transaction on Ethereum**. -If a transaction costs 100,000 gas on Ethereum, it will cost 100,000 gas on OP Mainnet. -The only difference is that the gas price on OP Mainnet is much lower than the gas price on Ethereum so you'll end up paying much less in ETH. +Because Metal L2 is EVM equivalent, **the gas used by a transaction on Metal L2 is exactly the same as the gas used by the same transaction on Ethereum**. +If a transaction costs 100,000 gas on Ethereum, it will cost 100,000 gas on Metal L2. +The only difference is that the gas price on Metal L2 is much lower than the gas price on Ethereum so you'll end up paying much less in ETH. 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/). @@ -43,41 +43,41 @@ The [base fee](https://ethereum.org/en/developers/docs/gas/#base-fee) is the min Transactions must specify a maximum base fee higher than the block base fee to be included. The actual fee charged is the block base fee, even if the transaction specifies a higher maximum base fee. -The OP Mainnet base fee behaves exactly like the Ethereum base fee with a few small parameter changes to account for the much shorter block times on OP Mainnet. -None of these parameters should significantly impact your application, but you can read more about each of these parameters on the [OP Mainnet differences](/stack/differences#eip-1559-parameters) page. +The Metal L2 base fee behaves exactly like the Ethereum base fee, with a few small parameter changes to account for the much shorter block times on Metal L2. +None of these parameters should significantly impact your application, but you can read more about each of these parameters on the [Metal L2 differences](/stack/differences#eip-1559-parameters) page. Read more about the base fee in the [Ethereum.org documentation](https://ethereum.org/en/developers/docs/gas/#base-fee). ### Priority fee -Just like on Ethereum, OP Mainnet transactions can specify a **priority fee**. +Just like on Ethereum, Metal L2 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. For example, if the block base fee is 1 gwei and the transaction specifies a priority fee of 1 gwei, the total price per unit of gas is 2 gwei. -The priority fee(tip) is an optional component of the execution gas fee and can technically be set to 0. +The priority fee(i.e. tip) is an optional component of the execution gas fee and can technically be set to 0. However, while EIP-1559 does not define a minimum priority fee, certain wallets and mempool implementations (like Geth) may enforce a minimum value. For instance, Geth typically defaults to a minimum priority fee of 1 gwei, but this can be configured to other values. -**The OP Mainnet sequencer will prioritize transactions with a higher priority fee** and execute them before any transactions with a lower priority fee. +**The Metal L2 sequencer will prioritize transactions with a higher priority fee** and execute them before any transactions with a lower priority fee. 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 -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. +The L1 Data Fee is the only part of the Metal L2 transaction fee that differs from the Ethereum transaction fee. +This fee arises from the fact that the transaction data for all Metal L2 transactions is published to Ethereum. This guarantees that the transaction data is available for nodes to download and execute. -The L1 Data Fee accounts for the cost to publish an OP Mainnet transaction to Ethereum and is primarily determined +The L1 Data Fee accounts for the cost to publish an Metal L2 transaction to Ethereum and is primarily determined by the current base fee on Ethereum. After the Ecotone upgrade, OP Stack chains will have the option of posting transactions using [`blobs`](https://www.eip4844.com/). For blob-enabled chains, the current Ethereum blob data gas price will largely determine the L1 data fee. ### Mechanism -The L1 Data Fee is automatically charged for any transaction that is included in an OP Mainnet block. +The L1 Data Fee is automatically charged for any transaction that is included in an Metal L2 block. This fee is deducted directly from the address that sent the transaction. The exact amount paid depends on the estimated size of the transaction in bytes after compression, the current Ethereum gas price and/or blob gas price, and several small parameters. The L1 Data Fee is most heavily influenced by the Ethereum base fee that is continuously and trustlessly relayed from Ethereum to -OP Mainnet. With the Ecotone upgrade, the Ethereum blob base fee also gets relayed to OP Mainnet, and will become the most +Metal L2. With the Ecotone upgrade, the Ethereum blob base fee also gets relayed to Metal L2, and will become the most important factor for chains configured to use blobs instead of base fee. The base fee and blob base fee are updated on OP Mainnet for every Ethereum block, and each fluctuates at most by 12.5% between updates. As a result, short-term fluctuations of the L1 Data Fee are generally quite small and should not impact the average transaction. @@ -96,12 +96,12 @@ the L1 Data Fee are generally quite small and should not impact the average tran The L1 Data Fee formula changed with the Ecotone upgrade. - Refer to the [Network Upgrade Overview](/builders/node-operators/network-upgrades) for network upgrade activation timestamps for OP Sepolia and OP Mainnet. + Refer to the [Network Upgrade Overview](/builders/node-operators/network-upgrades) for network upgrade activation timestamps for Metal L2 Testnet and Metal L2. Prior to the Ecotone upgrade, the L1 Data Fee is calculated based on the following parameters: -* The **signed** transaction serialized according to [the standard Ethereum transaction RLP encoding](https://github.com/ethereum-optimism/op-geth/blob/11a890f1ee0348a17687149abc72f394f9faa5ce/core/types/transaction.go#L131-L141). +* The **signed** transaction, serialized according to [the standard Ethereum transaction RLP encoding](https://github.com/ethereum-optimism/op-geth/blob/11a890f1ee0348a17687149abc72f394f9faa5ce/core/types/transaction.go#L131-L141). * The current Ethereum base fee (trustlessly relayed from Ethereum). * A fixed overhead cost for publishing a transaction (currently set to 188 gas). * A dynamic overhead cost which scales with the size of the transaction (currently set to 0.684). @@ -130,7 +130,7 @@ l1_data_fee = tx_total_gas * ethereum_base_fee The L1 Data Fee formula changed with the Ecotone upgrade. - Refer to the [Network Upgrade Overview](/builders/node-operators/network-upgrades) for network upgrade activation timestamps for OP Sepolia and OP Mainnet. + Refer to the [Network Upgrade Overview](/builders/node-operators/network-upgrades) for network upgrade activation timestamps for Metal L2 Testnet and Metal L2. The pricing function changes with Ecotone upgrade because of the introduction of the option to @@ -161,7 +161,7 @@ gas price multiplier. weighted_gas_price = 16*base_fee_scalar*base_fee + blob_base_fee_scalar*blob_base_fee ``` -The l1 data fee is then: +The L1 data fee is then: ```python l1_data_fee = tx_compressed_size * weighted_gas_price @@ -177,10 +177,10 @@ Chain operators can use the [Ecotone fee parameter calculator](https://docs.goog #### Fjord - The L1 Data Fee formula changed with the Fjord upgrade. Refer to the [Network Upgrade Overview](/builders/node-operators/network-upgrades) for network upgrade activation timestamps for OP Sepolia and OP Mainnet. + The L1 Data Fee formula changed with the Fjord upgrade. Refer to the [Network Upgrade Overview](/builders/node-operators/network-upgrades) for network upgrade activation timestamps for Metal L2 Testnet and Metal L2. -The pricing function changes with Fjord upgrade because of the FastLZ compression estimator, which more accurately charges for L1 data usage on a per-transaction basis. +The pricing function changes with the Fjord upgrade because of the FastLZ compression estimator, which more accurately charges for L1 data usage on a per-transaction basis. The updated function uses the following parameters: * The FastLZ-compressed size of the signed transaction. @@ -192,7 +192,7 @@ The Fjord L1 Data Fee calculation begins with estimating the transaction size us estimatedSizeScaled = max(minTransactionSize * 1e6, intercept + fastlzCoef*fastlzSize) ``` -The model parameters `intercept` and `fastlzCoef` were determined by performing a linear regression analysis over a dataset of previous L2 transactions minimizing the root mean square error against the change in batch size, when compressed with Brotli, over historical OP mainnet data. These parameters are fixed in Fjord. The `minTransactionSize`, `intercept`, and `fastlzCoef` values are scaled by 1e6. +The model parameters `intercept` and `fastlzCoef` were determined by performing a linear regression analysis over a dataset of previous L2 transactions minimizing the root mean square error against the change in batch size, when compressed with Brotli, over historical Metal L2 data. These parameters are fixed in Fjord. The `minTransactionSize`, `intercept`, and `fastlzCoef` values are scaled by 1e6. Next, the two chain parameters **base fee scalar** and **blob base fee scalar** are used to compute a weighted gas price multiplier. @@ -206,16 +206,16 @@ Both scalars are scaled by 1e6. The final L1 Data Fee is then l1Cost = estimatedSizeScaled * l1FeeScaled / 1e12 ``` -The new cost function takes into account the compression ratio, so chain operators will need to adjust their `baseFeeScalar` and `blobFeeScalar` to account for any previous compression ratios that they encountered on their chains. Chain operators can use the [Fjord fee parameter calculator](https://docs.google.com/spreadsheets/d/1V3CWpeUzXv5Iopw8lBSS8tWoSzyR4PDDwV9cu2kKOrs/edit#gid=186414307) to get a better estimate of scalar values to use for your chain. +The new cost function takes into account the compression ratio, so chain operators will need to adjust their `baseFeeScalar` and `blobFeeScalar` to account for any previous compression ratios that they encountered on their chains. Chain operators can use the [Fjord fee parameter calculator](https://docs.google.com/spreadsheets/d/1V3CWpeUzXv5Iopw8lBSS8tWoSzyR4PDDwV9cu2kKOrs/edit#gid=186414307) to get a better estimate of scalar values to use for their chain. ## Sequencer Fee Vault -The Sequencer Fee Vault collects and holds transaction fees paid to the sequencer during block production on OP Mainnet. These fees cover the cost of posting transaction data to L1, ensuring network sustainability and data availability. +The Sequencer Fee Vault collects and holds transaction fees paid to the sequencer during block production on Metal L2. These fees cover the cost of posting transaction data to L1, ensuring network sustainability and data availability. ### Fee Collection and Distribution * **Purpose**: The sequencer deposits collected fees into the Sequencer Fee Vault. These fees reimburse the sequencer for gas costs when submitting transaction batches to L1. -* **Vault Address**: The Sequencer Fee Vault is predeployed at the address `0x4200000000000000000000000000000000000011` on the OP Mainnet. +* **Vault Address**: The Sequencer Fee Vault is predeployed at the address `0x4200000000000000000000000000000000000011` on the Metal L2. * **Fee Usage**: Stored fees are eventually transferred to a designated recipient address (e.g., a treasury or distribution contract). ### How it works diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 5dd7d7528..8bb4db697 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -24,7 +24,7 @@ OP Stack chains in the standard configuration are Rollups that use Ethereum's co Transactions on OP Stack chains go through the following process to reach finality: 1. A user submits a transaction to the network, which forwards it to the Sequencer. -2. The Sequencer includes the transaction in a block and distributes it over a public peer-to-peer network. At this point, the transaction is considered **"unsafe"**, a technical term indicating that the transaction is in a block but its data has not yet been posted to Ethereum. This process typically takes a few seconds from transaction submission. +2. The Sequencer includes the transaction in a block and distributes it over a public peer-to-peer network. At this point, the transaction is considered **"unsafe"**- a technical term indicating that the transaction is in a block but its data has not yet been posted to Ethereum. This process typically takes a few seconds from transaction submission. 3. The Sequencer publishes this block's data to Ethereum, either as [blob data](https://www.eip4844.com/) or as calldata attached to a standard Ethereum transaction. Once included in an Ethereum block, the transaction is considered **"safe"**. This step usually takes 5–10 minutes from transaction submission. 4. The Ethereum block containing the Sequencer's transaction is finalized. At this point, the transaction reaches a **"finalized"** state. Ethereum finalization typically takes about 2 epochs (approximately 12.8 minutes from transaction submission) under normal network conditions, but may take longer during adverse conditions. Finality depends entirely on [Ethereum's consensus mechanism](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). diff --git a/pages/stack/transactions/transaction-flow.mdx b/pages/stack/transactions/transaction-flow.mdx index b076e5c4e..fb0af08f5 100644 --- a/pages/stack/transactions/transaction-flow.mdx +++ b/pages/stack/transactions/transaction-flow.mdx @@ -15,9 +15,9 @@ This guide explains the transaction flow process for rollup transactions. The pr * The transaction needs to be executed to modify the state (by `op-geth`). Afterwards, `op-proposer` writes a [commitment](https://en.wikipedia.org/wiki/Commitment_scheme) to the post-transaction state to L1. - Note that `op-proposer` does not need to write a commitment after each transaction to L1, it is OK to commit to the state after a block of transactions. + Note that `op-proposer` does not need to write a commitment after each transaction to L1; it is OK to commit to the state after a block of transactions. -![Overall process.](/img/op-stack/protocol/transaction-flow.svg) +![Overall process.](/img/op-stack/protocol/transaction-flow-dark-mode.svg) ## Writing the transaction to L1 @@ -35,8 +35,8 @@ You can read more about this process [in the specs](https://specs.optimism.io/pr When a channel is full or times out it is compressed and written. The maximum time that a channel can be open, from the first transaction to the last, is specified in units of L1 block time (so a value of 5 means 5\*12=60 seconds). -You can specify it either as an environment variable (`OP_BATCHER_MAX_CHANNEL_DURATION`) or a command line parameters (`--max-channel-duration`). -Alternatively, you can set it to zero (the default) to avoid posting smaller, less cost efficient, transactions. +You can specify it either as an environment variable (`OP_BATCHER_MAX_CHANNEL_DURATION`) or a command line parameter (`--max-channel-duration`). +Alternatively, you can set it to zero (the default) to avoid posting smaller, less cost efficient transactions. A channel is full when the anticipated compressed size is the target L1 transaction size. This is controlled by two parameters: @@ -84,14 +84,14 @@ The directions here are for [Foundry](https://book.getfoundry.sh/), but the conc ``` 2. Get the number of the latest finalized block. - If the result is greater than the block number of the transaction, or equal, the transaction is finalized. + If the result is greater than or equal to the block number of the transaction, the transaction is finalized. ```sh cast block finalized --field number ``` 3. Get the number of the latest safe block. - If the result is greater than the block number of the transaction, or equal, the transaction is safe. + If the result is greater than or equal to the block number of the transaction, the transaction is safe. ```sh cast block safe --field number diff --git a/pages/stack/transactions/transactions.mdx b/pages/stack/transactions/transactions.mdx deleted file mode 100644 index 02d703c69..000000000 --- a/pages/stack/transactions/transactions.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Transactions -description: Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Transaction Flow, Withdrawal Flow in the Transactions section of the OP Stack ecosystem. -lang: en-US ---- - -import { Card, Cards } from 'nextra/components' - -# Transactions - -Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Transaction Flow, Withdrawal Flow in the Transactions section of the OP Stack ecosystem. - - - - - - - - - - - - - - diff --git a/pages/stack/transactions/withdrawal-flow.mdx b/pages/stack/transactions/withdrawal-flow.mdx index 14cac6fce..bd3d514e2 100644 --- a/pages/stack/transactions/withdrawal-flow.mdx +++ b/pages/stack/transactions/withdrawal-flow.mdx @@ -8,7 +8,7 @@ import { Callout } from 'nextra/components' # Withdrawal flow -In Optimism terminology, a *withdrawal* is a transaction sent from L2 (OP Mainnet, OP Sepolia etc.) to L1 (Ethereum mainnet, Sepolia, etc.). +In Optimism terminology, a *withdrawal* is a transaction sent from L2 (Metal L2, Metal L2 Testnet etc.) to L1 (Ethereum mainnet, Sepolia, etc.). Withdrawals require the user to submit three transactions: diff --git a/pages/superchain/_meta.json b/pages/superchain/_meta.json index 8fcebc30b..47b18a2f5 100644 --- a/pages/superchain/_meta.json +++ b/pages/superchain/_meta.json @@ -1,5 +1,6 @@ { "superchain-explainer": "The Superchain explainer", "superchain-registry": "The Superchain Registry", - "blockspace-charter": "Blockspace Charters and the Standard Rollup Charter" + "blockspace-charter": "Blockspace Charters and the Standard Rollup Charter", + "standard-configuration": "What makes a chain standard" } diff --git a/pages/superchain/superchain-explainer.mdx b/pages/superchain/superchain-explainer.mdx index a1fb71bef..7e997c321 100644 --- a/pages/superchain/superchain-explainer.mdx +++ b/pages/superchain/superchain-explainer.mdx @@ -14,7 +14,7 @@ import { Callout } from 'nextra/components' The next major scalability improvement to the OP Stack after Bedrock is to introduce the concept of *a Superchain*: a network of chains that share bridging, decentralized governance, upgrades, a communication layer and more—all built on the OP Stack. -The launch of the Superchain would merge OP Mainnet and other chains into a single unified network of OP Chains (i.e., chains within the Superchain), and mark a major step towards bringing scalable and decentralized compute to the world. The goal of this document is to describe the scalability vision, the Superchain concept, and some changes to the OP Stack required to make this vision a reality. +The launch of the Superchain would merge Metal L2 and other chains into a single unified network of OP Chains (i.e., chains within the Superchain), and mark a major step towards bringing scalable and decentralized compute to the world. The goal of this document is to describe the scalability vision, the Superchain concept, and some changes to the OP Stack required to make this vision a reality. This is the detailed explanation. [Click here for a less technical introduction](https://www.superchain.eco/). @@ -143,7 +143,7 @@ In order to address these issues, we can introduce two features: Withdrawal claims - A claim about the state of one chain made on another chain. For instance, I can claim that in OP Mainnet I have burned my tokens with the intent to withdraw those tokens back to L1. + A claim about the state of one chain made on another chain. For instance, I can claim that in Metal L2 I have burned my tokens with the intent to withdraw those tokens back to L1. We can enable these two features first by introducing a permissionless proof system to the Optimism bridge contracts. With the modular proof design introduced in Bedrock, proofs may come in the form of fault proofs or validity proofs (e.g. zero knowledge proofs). However, until validity proofs are productionized, we assume withdrawals will use a Fault Proof System. @@ -264,7 +264,7 @@ 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 — Alt-DA Protocol #### Pain point: @@ -272,27 +272,27 @@ With the combination of low-latency L2 to L2 message passing as well as shared s #### 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. +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 Alt-DA protocol which enables alternative DA providers to supplement the more limited L1 DA. - Plasma chain + Alt-DA chain A chain where transaction data is committed to on L1 but not supplied to L1 directly, with a data availability challenge fallback. -A generic Plasma protocol is able to scale beyond what is possible on L1 because only the users who are interested in the transaction data will download the Plasma data, whereas on L1 every Ethereum node downloads all of the transaction data on L1. This means that Plasma data is extremely cheap. However, Plasma has a worse security model than L1 — it is possible for Plasma chain data to temporarily become unavailable, meaning users must withdraw from the chain. Note, this security model still guarantees safety of the Plasma chains, just not liveness. +A generic Alt-DA protocol is able to scale beyond what is possible on L1 because only the users who are interested in the transaction data will download the Alt-DA data, whereas on L1 every Ethereum node downloads all of the transaction data on L1. This means that Alt-DA data is extremely cheap. However, Alt-DA has a worse security model than L1 — it is possible for Alt-DA chain data to temporarily become unavailable, meaning users must withdraw from the chain. Note, this security model still guarantees safety of the Alt-DA chains, just not liveness. -**Plasma protocol overview:** +**Alt-DA protocol overview:** * Data Availability (DA) Providers receive transaction data from users. -* DA Providers then hash the transaction data and submit the hash to the Plasma Contract. +* DA Providers then hash the transaction data and submit the hash to the Alt-DA Contract. * Once the hash has been submitted, the DA Provider sends a proof to the user which proves inclusion of their transaction data in the hash. The DA Provider can misbehave by withholding the proof, i.e., not sending it to the user. -* If the DA Provider does not send the proof to the user, the user may submit a DA challenge. This forces the DA Provider to post the transaction data onchain. If the DA Provider does not submit the proof onchain, the hash is deleted. This ensures the user can always (after the challenge period) sync the Plasma chain. +* If the DA Provider does not send the proof to the user, the user may submit a DA challenge. This forces the DA Provider to post the transaction data onchain. If the DA Provider does not submit the proof onchain, the hash is deleted. This ensures the user can always (after the challenge period) sync the Alt-DA chain. * DA challenge periods may be extended in case of heavy L1 congestion. -* The user may also submit an L1 transaction to withdraw from the Plasma chain in order to switch their DA Provider. -* Settlement of Plasma chains use a near identical Fault Proof System to Rollup chains with the only difference being that additional data is derived from the chain using the hashes that are finalized in the Plasma Contract. +* The user may also submit an L1 transaction to withdraw from the Alt-DA chain in order to switch their DA Provider. +* Settlement of Alt-DA chains use a near identical Fault Proof System to Rollup chains with the only difference being that additional data is derived from the chain using the hashes that are finalized in the Alt-DA Contract. -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. +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 Alt-DA DA. This means that it is possible to put massively scalable applications such as games or social media on Alt-DA chains. ### Multi-chain app frameworks diff --git a/public/_redirects b/public/_redirects index 53f42325d..476db7624 100644 --- a/public/_redirects +++ b/public/_redirects @@ -112,10 +112,12 @@ /builders/cex-wallet-developers/cex-support /builders/app-developers/overview /builders/cex-wallet-developers/wallet-support /builders/app-developers/overview /builders/cex-wallet-developers /builders/app-developers/overview -/stack/interop/superchain-erc20 /stack/interop/assets/superchain-erc20 -/stack/interop/superchain-weth /stack/interop/assets/superchain-weth -/stack/interop/transfer-superchainERC20 /stack/interop/assets/transfer-superchainERC20 -/builders/app-developers/contracts/superchain-erc20 /stack/interop/assets/superchain-erc20 +/stack/interop/assets/superchain-erc20 /stack/interop/superchain-erc20 +/stack/interop/assets/superchain-weth /stack/interop/superchain-weth +/stack/interop/transfer-superchainERC20 /stack/interop/tutorials/transfer-superchainERC20 +/stack/interop/assets/transfer-superchainERC20 /stack/interop/tutorials/transfer-superchainERC20 +/stack/interop/assets/deploy-superchain-erc20 /stack/interop/tutorials/deploy-superchain-erc20 +/builders/app-developers/contracts/superchain-erc20 /stack/interop/superchain-erc20 /builders/chain-operators/tutorials/sdk /builders/app-developers/overview /stack/explainer /superchain/superchain-explainer /stack/interop/architecture /stack/interop/explainer#interoperability-architecture diff --git a/public/img/op-stack/protocol/deposit-flow-dark-mode.svg b/public/img/op-stack/protocol/deposit-flow-dark-mode.svg new file mode 100644 index 000000000..0b020e9f2 --- /dev/null +++ b/public/img/op-stack/protocol/deposit-flow-dark-mode.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/public/img/op-stack/protocol/transaction-flow-dark-mode.svg b/public/img/op-stack/protocol/transaction-flow-dark-mode.svg new file mode 100644 index 000000000..931eb7d5d --- /dev/null +++ b/public/img/op-stack/protocol/transaction-flow-dark-mode.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/public/tutorials/cross-dom-bridge-erc20.js b/public/tutorials/cross-dom-bridge-erc20.js index 8244f367e..88ac3b6f9 100644 --- a/public/tutorials/cross-dom-bridge-erc20.js +++ b/public/tutorials/cross-dom-bridge-erc20.js @@ -28,7 +28,7 @@ const oneToken = 1000000000000000000n const messenger = new optimism.CrossChainMessenger({ l1ChainId: 11155111, // 11155111 for Sepolia, 1 for Ethereum - l2ChainId: 11155420, // 11155420 for OP Sepolia, 10 for OP Mainnet + l2ChainId: 11155420, // 11155420 for Metal L2 Testnet, 10 for Metal L2 l1SignerOrProvider: l1Wallet, l2SignerOrProvider: l2Wallet, }) diff --git a/public/tutorials/sdk-trace-txns.js b/public/tutorials/sdk-trace-txns.js index aada45ea2..430660c9b 100644 --- a/public/tutorials/sdk-trace-txns.js +++ b/public/tutorials/sdk-trace-txns.js @@ -1,51 +1,54 @@ (async () => { -const optimism = require("@eth-optimism/sdk") -const ethers = require("ethers") + const { createPublicClient, http } = require('viem'); + const { optimismSepolia, sepolia } = require('viem/chains'); + const L1_RPC_URL= "https://rpc.ankr.com/eth_sepolia"; + const L2_RPC_URL= "https://sepolia.optimism.io"; // Need to use Alchemy or something here because the getDepositsByAddress and // getWithdrawalsByAddress functions use a large block range that the public RPC doesn't support // because it uses Ankr. Maybe the SDK should be updated to use smaller block ranges depending // on the RPC but that's a separate issue. -const l1RpcUrl = process.env.L1_RPC_URL -const l2RpcUrl = process.env.L2_RPC_URL + +const l1RpcUrl = process.env.L1_RPC_URL; +const l2RpcUrl = process.env.L2_RPC_URL; // Docs CI wallet, will have deposits and withdrawals. -const deposit = '0x5896d6e4a47b465e0d925723bab838c62ef53468139a5e9ba501efd70f90cccb' -const withdrawal = '0x18b8b4022b8d9e380fd89417a2e897adadf31e4f41ca17442870bf89ad024f42' +const depositHash = '0x5896d6e4a47b465e0d925723bab838c62ef53468139a5e9ba501efd70f90cccb' +const withdrawalHash = '0x18b8b4022b8d9e380fd89417a2e897adadf31e4f41ca17442870bf89ad024f42' -const l1Provider = new ethers.providers.StaticJsonRpcProvider(l1RpcUrl) -const l2Provider = new ethers.providers.StaticJsonRpcProvider(l2RpcUrl) +const l1Client = createPublicClient({ + chain: sepolia, + transport: http(l1RpcUrl), +}); -const messenger = new optimism.CrossChainMessenger({ - l1ChainId: 11155111, // 11155111 for Sepolia, 1 for Ethereum - l2ChainId: 11155420, // 11155420 for OP Sepolia, 10 for OP Mainnet - l1SignerOrProvider: l1Provider, - l2SignerOrProvider: l2Provider, -}) +const l2Client = createPublicClient({ + chain: optimismSepolia, + transport: http(l2RpcUrl), +}); console.log('Grabbing deposit status...') -const depositStatus = await messenger.getMessageStatus(deposit) -console.log(depositStatus) +const depositStatus = await l2Client.getTransactionReceipt({ hash: depositHash }); +console.log(depositStatus); console.log('Grabbing deposit receipt...') -const depositReceipt = await messenger.getMessageReceipt(deposit) -console.log(depositReceipt) +const depositReceipt = await l2Client.getTransaction({ hash: depositHash }); +console.log(depositReceipt); console.log('Grabbing deposit txn...') -const depositTx = await l2Provider.getTransaction(depositReceipt.transactionReceipt.transactionHash) -console.log(depositTx) +const depositTransaction = await l2Client.getTransaction({ hash: depositHash }); +console.log(depositTransaction); console.log('Grabbing withdrawal status...') -const withdrawalStatus = await messenger.getMessageStatus(withdrawal) -console.log(withdrawalStatus) +const withdrawalStatus = await l1Client.getTransactionReceipt({ hash: withdrawalHash }); +console.log(withdrawalStatus); console.log('Grabbing withdrawal receipt...') -const withdrawalReceipt = await messenger.getMessageReceipt(withdrawal) -console.log(withdrawalReceipt) +const withdrawalReceipt = await l1Client.getTransaction({ hash: withdrawalHash }); +console.log(withdrawalReceipt); console.log('Grabbing withdrawal txn...') -const withdrawalTx = await l1Provider.getTransaction(withdrawalReceipt.transactionReceipt.transactionHash) -console.log(withdrawalTx) +const withdrawalTransaction = await l1Client.getTransaction({ hash: withdrawalHash }); +console.log(withdrawalTransaction); })() diff --git a/public/tutorials/sdk-view-txns.js b/public/tutorials/sdk-view-txns.js index 24858023d..8d2cd9532 100644 --- a/public/tutorials/sdk-view-txns.js +++ b/public/tutorials/sdk-view-txns.js @@ -18,7 +18,7 @@ const l2Provider = new ethers.providers.StaticJsonRpcProvider(l2RpcUrl) const messenger = new optimism.CrossChainMessenger({ l1ChainId: 11155111, // 11155111 for Sepolia, 1 for Ethereum - l2ChainId: 11155420, // 11155420 for OP Sepolia, 10 for OP Mainnet + l2ChainId: 11155420, // 11155420 for Metal L2 Testnet, 10 for Metal L2 l1SignerOrProvider: l1Provider, l2SignerOrProvider: l2Provider, }) diff --git a/utils/networks.ts b/utils/networks.ts index 1db57da3a..0b6323e4a 100644 --- a/utils/networks.ts +++ b/utils/networks.ts @@ -24,7 +24,7 @@ const chains: { explorer: 'https://etherscan.io', }, opmainnet: { - name: 'OP Mainnet', + name: 'Metal L2', id: 10, explorer: 'https://optimistic.etherscan.io', }, @@ -34,7 +34,7 @@ const chains: { explorer: 'https://sepolia.etherscan.io', }, opsepolia: { - name: 'OP Sepolia', + name: 'Metal L2 Testnet', id: 11155420, explorer: 'https://sepolia-optimistic.etherscan.io/', }, diff --git a/utils/transaction-types.ts b/utils/transaction-types.ts index 70f154ad6..66410d279 100644 --- a/utils/transaction-types.ts +++ b/utils/transaction-types.ts @@ -1,5 +1,5 @@ export const transactionTypes = { - "General OP Mainnet": { + "General Metal L2": { TransactionsPerDay: 489109, AvgCalldataBytesPerTx: 1007.8, AvgEstimatedSizePerTx: 474.6, diff --git a/words.txt b/words.txt index 50bd05956..68791db57 100644 --- a/words.txt +++ b/words.txt @@ -8,9 +8,17 @@ ADDU airgap Allnodes allocs +Alphanet +alphanet +Alphanets +alphanets ANDI Apeworx authrpc +Betanet +betanet +Betanets +betanets BGEZ BGTZ Biconomy @@ -27,6 +35,8 @@ blockprofilerate Blockscout Blockspace blockspace +Blocktimes +blocktimes BLOOMFILTER bloomfilter BLTZ @@ -38,6 +48,7 @@ bottlenecked Brotli Callouts callouts +Celestia chainlist chaosnet Chugsplash @@ -58,6 +69,8 @@ DATADIR datadir Devnet devnet +Devnets +devnets devx DISABLETXPOOLGOSSIP disabletxpoolgossip @@ -65,6 +78,7 @@ Discv discv DIVU Drippie +Eigen ENABLEDEPRECATEDPERSONAL enabledeprecatedpersonal enginekind @@ -85,6 +99,7 @@ Farcaster FDLIMIT fdlimit featureset +Flashblocks Flashbots forkable forkchoice @@ -150,6 +165,7 @@ merkle metall MFHI MFLO +Mgas MINFREEDISK minfreedisk MINSUGGESTEDPRIORITYFEE @@ -163,7 +179,6 @@ MTHI MTLO MULT multiaddr -multichain multiclient multisigs MULTU @@ -222,7 +237,7 @@ Preimage PREIMAGES preimages prestate -PREVRENDAO +PREVRANDAO PRICEBUMP pricebump PRICELIMIT @@ -230,6 +245,7 @@ pricelimit productionize productionized Protip +providng Proxied pseudorandomly Quicknode @@ -274,16 +290,14 @@ stablecoins subcomponents subgame subheaders +subsecond SUBU SUPERCHAIN Superchain superchain Superchain's -Superchainerc Superchains Superscan -Supersim -supersim SYNCMODE syncmode SYNCTARGET @@ -312,6 +326,7 @@ vhosts Viem viem Viem's +viem's VMDEBUG vmdebug VMODULE