From 54aea3ef2d1361c7314b9c5fa21855a64f58475a Mon Sep 17 00:00:00 2001 From: Paul Razvan Berg Date: Tue, 21 May 2024 21:39:43 +0100 Subject: [PATCH 1/3] docs: enhancements and typos --- pages/chain/differences.mdx | 2 +- pages/stack/design-principles.mdx | 3 +- pages/stack/differences.mdx | 2 +- pages/stack/explainer.mdx | 62 ++++++++++--------- pages/stack/protocol/outages.mdx | 2 +- pages/stack/protocol/rollup/deposit-flow.mdx | 16 +++-- pages/stack/protocol/rollup/overview.mdx | 16 ++--- .../stack/protocol/rollup/smart-contracts.mdx | 13 ++-- .../stack/protocol/rollup/withdrawal-flow.mdx | 4 +- 9 files changed, 60 insertions(+), 60 deletions(-) diff --git a/pages/chain/differences.mdx b/pages/chain/differences.mdx index c3ac377f4..784911879 100644 --- a/pages/chain/differences.mdx +++ b/pages/chain/differences.mdx @@ -52,7 +52,7 @@ In all other cases, the transaction sender address is set according to the same ### Transaction Fees -Transactions OP Mainnet must pay for an [L1 data fee](/stack/transactions/fees#the-l1-data-fee) on top of the standard [execution gas fee](/stack/transactions/fees#execution-gas-fee) you would expect on Ethereum. +Transactions on OP Mainnet must pay for an [L1 data fee](/stack/transactions/fees#the-l1-data-fee) on top of the standard [execution gas fee](/stack/transactions/fees#execution-gas-fee) you would expect on Ethereum. Refer to the guide on [OP Mainnet Transaction Fees](/stack/transactions/fees) for more information. ### EIP-1559 Parameters diff --git a/pages/stack/design-principles.mdx b/pages/stack/design-principles.mdx index 997e3e850..3ad07f00c 100644 --- a/pages/stack/design-principles.mdx +++ b/pages/stack/design-principles.mdx @@ -115,5 +115,4 @@ Extensibility is a key design principle that unlocks the superpower of collabora The OP Stack is a decentralized software stack that anyone can contribute to. If you're interested in contributing to the OP Stack, check out [the Contributing section on our Community pages](https://community.optimism.io). -Of course, software that has impact for the Optimism Collective is eligible to receive [Retroactive Public Goods Funding](https://app.optimism.io/retropgf). -Build for the OP Stack — get rewarded for writing great open source software. What's not to love? +Of course, software that has impact for the Optimism Collective is eligible to receive [Retroactive Public Goods Funding](https://app.optimism.io/retropgf). Build for the OP Stack — get rewarded for writing great open source software. What's not to love? diff --git a/pages/stack/differences.mdx b/pages/stack/differences.mdx index 9e24e788b..ec6ec411f 100644 --- a/pages/stack/differences.mdx +++ b/pages/stack/differences.mdx @@ -52,7 +52,7 @@ In all other cases, the transaction sender address is set according to the same ### Transaction Fees -Transactions OP Stack chains must pay for an [L1 data fee](/stack/transactions/fees#the-l1-data-fee) on top of the standard [execution gas fee](/stack/transactions/fees#execution-gas-fee) you would expect on Ethereum. +Transactions on OP Stack chains must pay for an [L1 data fee](/stack/transactions/fees#the-l1-data-fee) on top of the standard [execution gas fee](/stack/transactions/fees#execution-gas-fee) you would expect on Ethereum. Refer to the guide on [OP Stack Transaction Fees](/stack/transactions/fees) for more information. ### EIP-1559 Parameters diff --git a/pages/stack/explainer.mdx b/pages/stack/explainer.mdx index f15941f1b..a3a08d9e2 100644 --- a/pages/stack/explainer.mdx +++ b/pages/stack/explainer.mdx @@ -115,11 +115,11 @@ Once Optimism has satisfied these properties, it may be considered a Superchain. ## Upgrading Optimism to Become a Superchain -We believe the following changes (after the Bedrock release) are required to create a initial Superchain that makes it possible to deploy and upgrade many chains with the same bridge: +We believe the following changes (after the Bedrock release) are required to create an initial Superchain that makes it possible to deploy and upgrade many chains with the same bridge: ### Upgrade the Bedrock bridge to be a chain factory -Bedrock introduced the [SystemConfig contract](https://github.com/ethereum-optimism/optimism/blob/74a63c94d881442b4edd4df6492513e0113eb064/packages/contracts-bedrock/contracts/L1/SystemConfig.sol) which began to define the L2 chain directly with L1 smart contracts. This can be extended to put *all information* defining the L2 chain, onchain. Including generating a unique chain ID, key configuration values such as block gas limit, etc. +Bedrock introduced the [SystemConfig contract](https://github.com/ethereum-optimism/optimism/blob/74a63c94d881442b4edd4df6492513e0113eb064/packages/contracts-bedrock/contracts/L1/SystemConfig.sol) which began to define some of the L2 chain directly with L1 smart contracts. This can be extended to put *all information* defining the L2 onchain on L1. Including generating a unique chain ID, key configuration values such as block gas limit, etc. Once the chain data is entirely onchain, we can create a factory which deploys the configuration and all other required contracts for each chain. This can be extended further by making the contract addresses deterministic with CREATE2, meaning that given a chain config it is possible to determine all bridge addresses associated with that chain. This also enables chains to be interacted with without having to deploy their bridge contracts, making (counterfactual) chain deployment virtually free, and allowing chains to inherit standard security properties. @@ -137,8 +137,8 @@ In Bedrock, there is a permissioned role (the "proposer" role) that is required In order to address these issues, we can introduce two features: -1. Withdrawal claims (a.k.a. Permissionless proposals) — allow anyone to submit a withdrawal (aka a proposal), not just a designated proposer. This removes the permissioned role from the system, enabling users to submit their own withdrawal messages. -2. Remove proposal submission interval — enable withdrawal claims to be made *only* when a user needs to withdraw. This removes the overhead incurred when deploying a new OP Chain. +1. Withdrawal claims (a.k.a. Permissionless proposals) — allow anyone to submit a withdrawal (a.k.a. a proposal), not just a designated proposer. This removes the permissioned role from the system, enabling users to submit their own withdrawal messages. +2. On-demand proposals without submission intervals — enable withdrawal claims to be made *only* when a user needs to withdraw. This removes the overhead incurred when deploying a new OP Chain. Withdrawal claims @@ -180,16 +180,20 @@ Modular sequencing also enables permissionless experimentation with different se To ship the initial Superchain with high confidence in security and decentralization, a decentralized security council should be introduced to govern upgrades. The security council should be able to update the set of chain attestors, initiate contract upgrades with a delay, and hit an emergency bridge pause button which also cancels pending upgrades. -The ability to pause the bridge in case of emergency means that in the worst case, where the requisite threshold of the security council participants had their private keys leaked, the result would be that withdrawals are indefinitely paused and bridge upgrades would be perpetually canceled. In other words, the L1 bridge would be frozen. This follows the design principle of safety over liveness—the principle that one should always prevent the loss of ETH or tokens (i.e. enforce safety) even if it means the ETh or tokens get locked (i.e. sacrifice liveness). +The ability to pause the bridge in case of emergency means that in the worst case, where the requisite threshold of the security council participants had their private keys leaked, the result would be that withdrawals are indefinitely paused and bridge upgrades would be perpetually canceled. In other words, the L1 bridge would be frozen. This follows the design principle of safety over liveness—the principle that one should always prevent the loss of ETH or tokens (i.e. enforce safety) even if it means the ETH or tokens get locked (i.e. sacrifice liveness). #### Unfreezing the bridge via L1 soft fork -In order to address the frozen bridge, there is a potential final recovery mechanism which has been discussed by the L2 community, which we call the "L1 Soft Fork Upgrade Recovery"mechanism. This mechanism enables L1 to initiate a bridge upgrade with a soft fork, bypassing all other permissions within the Superchain bridge contracts. This approach may [introduce systemic risk](https://web.archive.org/web/20231102063913/https://vitalik.ca/general/2023/05/21/dont_overload.html) to Ethereum and requires research and community buy-in before implementation. It is not required for implementing the Superchain and is being documented for research completeness. Without further research into the implications and safety, it is not an approach the team currently endorses. +In order to address the frozen bridge, there is a potential final recovery mechanism which has been discussed by the L2 community, which we call the "L1 Soft Fork Upgrade Recovery" mechanism. This mechanism enables L1 to initiate a bridge upgrade with a soft fork, bypassing all other permissions within the Superchain bridge contracts. The mechanism is as follows: *Anyone* may propose an upgrade by submitting a transaction to a special bridge contract, along with a very large bond. This begins a two week challenge period. During this challenge period, anyone may submit a challenge which immediately cancels the upgrade and claims the bond. Under normal circumstances, it is impossible that an upgrade would go uncancelled for the required two weeks, due to the large incentive provided for anyone to cancel the upgrade. However, if the upgrade is accompanied by a modification to Ethereum L1 validator software (the L1 soft fork), which ignores blocks that contain the cancellation transaction, then it may succeed. + + This mechanism may [introduce systemic risk](https://web.archive.org/web/20231102063913/https://vitalik.ca/general/2023/05/21/dont_overload.html) to Ethereum and requires research and community buy-in before implementation. It is not required for implementing the Superchain and is being documented for research completeness. Without further research into the implications and safety, it is not an approach the team currently endorses. + + While a successful upgrade of this type would represent a soft fork of Ethereum L1, it would not incur long term technical debt to the Ethereum codebase because the soft fork logic can be removed once the upgrade has completed. We expect this escape hatch will never be used, but its very existence could deter malicious behavior. @@ -198,16 +202,16 @@ We expect this escape hatch will never be used, but its very existence could det We believe these upgrades can provide a shared bridge for all OP Chains, cheap OP Chain deployment, important configuration options for the OP Chains, as well as secure transactions and cross-chain messages. Because the Bedrock release already provides the property of a shared L1 blockchain, after these changes we will have achieved all the core properties required for the Superchain. -## Extending the Superchain—enhancements to realize the vision +## Extending the Superchain-enhancements to realize the vision We expect that, if successful, the post-Bedrock Superchain release will mark a major milestone in the scalability and decentralization of Optimism. However, there will still be significant pain points which must be addressed before the full scalable blockchain vision has been realized. Anticipated pain points include: -1. Withdrawal claims rely on a trusted set of chain attestors. -2. Cross-Chain transactions are slow because they require waiting a challenge period. -3. Cross-Chain transactions are asynchronous, breaking the ability to perform atomic cross-chain transactions (like flash loans). -4. Posting transactions to the Superchain is not-scalable because the transaction data must be submitted to L1 which has limited capacity. -5. There are no easy frameworks for building scalable apps which utilize many OP Chains. -6. There is no easy wallet for managing tokens and apps across many OP Chains. +1. Withdrawal claims rely on a trusted set of chain attestors. +2. Cross-chain transactions are slow because they require waiting a challenge period. +3. Cross-chain transactions are asynchronous, breaking the ability to perform atomic cross-chain transactions (like flash loans). +4. Posting transactions to the Superchain is not-scalable because the transaction data must be submitted to L1 which has limited capacity. +5. There are no easy-to-use frameworks for building scalable apps which utilize many OP Chains. +6. There is no easy-to-use wallet for managing tokens and apps across many OP Chains. If each one of these pain points were addressed, it could be possible to build decentralized alternatives to even the most complex web2 applications. @@ -227,30 +231,30 @@ It is possible to replace the trusted set of chain attestors by introducing perm #### Pain Point: -2. Cross-Chain transactions are slow because they require waiting a challenge period. +2. Cross-chain transactions are slow because they require waiting a challenge period. #### Proposed Solution: -Fault proofs introduce a UX burden because they require waiting a challenge period in order to safely finalize. This means that, depending on your challenge period length, users need to wait a long time before their ETH and tokens are migrated from one OP Chain to the next. +Fault proofs introduce a UX burden because they require waiting a challenge period in order to safely finalize. This means that, depending on the length of your challenge period, users may need to wait a long time before their ETH and tokens are migrated from one OP Chain to the next. On the other hand, validity proofs do not have this problem. Validity proofs don't have a challenge period and therefore provide instant withdrawals from one OP Chain to the next. This is extremely important if users are expected to migrate between chains frequently, even during normal app execution. However, validity proofs are commonly implemented using zero-knowledge proofs (ZKPs), which are expensive and bug-prone. It will likely take years to truly productionize ZKPs enough such that they can be the primary cross-chain communication protocol. -However, while ZKPs are being productionized, it is possible to achieve low latency L2 to L2 message passing using the OP Stack's modular proof system. With modular proofs it is possible to use two proof systems for the same chain. This opens up the possibility to provide low latency bridging which trades off security while *also* providing high security high latency bridging. +While ZKPs are being productionized, it is possible to achieve low-latency L2 to L2 message passing using OP Stack's modular proof system. With modular proofs, it is possible to use two proof systems for the same chain. This opens up the possibility to use one proof system to provide low-latency bridging (which trades off security) while *also* using the other proof system to provide high-security, high-latency bridging. This heterogeneous bridging system means that developers can build their applications using one of many bridge types, such as: -1. High security, high latency fault proof (standard high security bridge) -2. Low security, low latency fault proof (a short challenge period to achieve low latency) -3. Low security, low latency validity proof (using trusted chain attestors in place of a ZKP) -4. High security, low latency validity proof (once ZKPs are ready) +1. High-security, high-latency fault proof (standard high-security bridge) +2. Low-security, low-latency fault proof (a short challenge period to achieve low-latency) +3. Low-security, low-latency validity proof (using trusted chain attestors in place of a ZKP) +4. High-security, low-latency validity proof (once ZKPs are ready) -Mixing multiple proof systems enables developers to provide low latency bridging for low value state and high latency for high value state. It is even possible to turn low security state which was instantly bridged into high security state by proving the state's validity using a high security high latency bridge. This building block enables developers to make interesting security tradeoffs such as using a high threshold attestation proof with a high security high latency fault proof fallback. +Mixing multiple proof systems enables developers to provide low-latency bridging for low value state and high-latency for high value state. It is even possible to turn low-security state which was instantly bridged into high-security state by proving the state's validity using a high-security high-latency bridge. This building block enables developers to make interesting security tradeoffs such as using a high threshold attestation proof with a high-security, high-latency fault proof fallback. ### Synchronous Cross-Chain Transactions #### Pain Point: -3. Cross-Chain transactions are asynchronous, breaking the ability to perform atomic cross-chain transactions (like flash loans). +3. Cross-chain transactions are asynchronous, breaking the ability to perform atomic cross-chain transactions (like flash loans). #### Proposed Solution: @@ -258,7 +262,7 @@ Traditional cross-chain messaging is done asynchronously, which means that cross It is possible to introduce synchronous cross-chain messaging and enable atomic cross-chain interactions by using a shared sequencing protocol on both OP Chains. In our example, the sequencers on chain A and chain B would each receive the arbitrage transaction, come to consensus on when they will include it, and then atomically include each transaction in the linked block. Fees would only be paid if the transaction was indeed included on each chain, meaning the sequencers take the synchronization risk as opposed to the user in our initial example. These shared sequencing protocols can be implemented permissionlessly on top of the modular sequencing layer of the post-Bedrock Superchain. -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. +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 @@ -270,19 +274,19 @@ With the combination of low latency L2 to L2 message passing as well as shared s 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. -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, where 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. - Plasma 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. + **Plasma 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. -* 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. If the DA Provider is misbehaving, they will withhold the proof, not sending it to the user. +* 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. * 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. @@ -294,9 +298,9 @@ Because of the ability for hashes to reduce arbitrary size data into a constant #### Pain Points: -5. There are no easy frameworks for building scalable apps which utilize many OP Chains. +5. There are no easy-to-use frameworks for building scalable apps which utilize many OP Chains. -6. There is no easy wallet for managing ETH and tokens and apps across many OP Chains. +6. There is no easy-to-use wallet for managing ETH and tokens and apps across many OP Chains. #### Proposed Solution (Sketch): @@ -320,7 +324,7 @@ With robust multi-chain app frameworks, it may become as easy to deploy cross-ch We believe scaling blockchains will radically decentralize the internet and make it easy to create horizontally scalable, secure, and decentralized web applications. We think the Superchain release of the OP Stack could mark a major step towards realizing this vision. However, after the release, it will still take an enormous amount of work to realize the scalability vision. -However, with great challenge comes great opportunity! The work needed to arrive at the initial Superchain release of the OP stack, as well as the resulting ecosystem should create exciting greenfield opportunities for developers who want to contribute. There will be an enormous amount of low-hanging fruit contributions unlocked. We can't pick it alone! The only way we can hope to achieve it is through open-source contributions from folks like you! And with [retroactive public goods funding](https://web.archive.org/web/20231217000541/https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) your open source contributions may be rewarded too! +However, with great challenge comes great opportunity! The work needed to arrive at the initial Superchain release of the OP stack, as well as the resulting ecosystem should create exciting greenfield opportunities for developers who want to contribute. There will be an enormous amount of low-hanging fruit contributions unlocked. We can't pick it alone! The only way we can hope to achieve it is through open-source contributions from folks like you! And with [retroactive public goods funding](https://web.archive.org/web/20231217000541/https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c), your open source contributions may be rewarded too! Exciting times ahead. diff --git a/pages/stack/protocol/outages.mdx b/pages/stack/protocol/outages.mdx index 2321fb0e6..12ceed8cc 100644 --- a/pages/stack/protocol/outages.mdx +++ b/pages/stack/protocol/outages.mdx @@ -35,7 +35,7 @@ Users may observe that the network appears to be "stuck" at a particular block h ### Mitigation Users can always bypass the Sequencer by sending L2 transactions directly to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L209) contract on L1. -Refer to the [Bypassing the Sequencer](#bypassing-the-sequencer) section for more information about this functionality. +Refer to the [Bypassing the Sequencer](#bypassing-the-sequencer) section below for more information about this functionality. ## Transaction Submission Outages diff --git a/pages/stack/protocol/rollup/deposit-flow.mdx b/pages/stack/protocol/rollup/deposit-flow.mdx index 68fd2ed38..91c64927a 100644 --- a/pages/stack/protocol/rollup/deposit-flow.mdx +++ b/pages/stack/protocol/rollup/deposit-flow.mdx @@ -23,8 +23,7 @@ Information is encapsulated in lower layer packets on the sending side and then * `_target`, target address on L2. * `_message`, the L2 transaction's calldata, formatted as per the [ABI](https://docs.soliditylang.org/en/v0.8.19/abi-spec.html) of the target account. - * `_minGasLimit`, the minimum gas limit allowed for the transaction on L2. Note that this is a *minimum* and the actual amount provided on L2 may be higher (but never lower) than the specified gas limit. - Note that the actual amount provided on L2 will be higher, because the portal contract on L2 needs to do some processing before submitting the call to `_target`. + * `_minGasLimit`, the minimum gas limit allowed for the transaction on L2. Note that this is a *minimum* and the actual amount provided on L2 may be higher (but never lower) than the specified gas limit. The actual amount provided on L2 will be higher because the portal contract on L2 needs to do some processing before submitting the call to `_target`. 2. The L1 cross domain messenger calls [its own `_send` function](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/L1/L1CrossDomainMessenger.sol#L42-L52). It uses these parameters: @@ -52,7 +51,7 @@ Information is encapsulated in lower layer packets on the sending side and then 2. Next, `op-node` [converts](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/op-node/rollup/derive/deposits.go#L35-L51) those `TransactionDeposited` events into [deposit transactions](https://specs.optimism.io/protocol/deposits.html#user-deposited-transactions). -3. In most cases user deposit transactions call the [`relayMessage`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/universal/CrossDomainMessenger.sol#L291-L413) function of [`L2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/universal/CrossDomainMessenger.sol). +3. In most cases, user deposit transactions call the [`relayMessage`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/universal/CrossDomainMessenger.sol#L291-L413) function of [`L2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/universal/CrossDomainMessenger.sol). 4. `relayMessage` runs a few sanity checks and then, if everything is good, [calls the real target contract with the relayed calldata](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/universal/CrossDomainMessenger.sol#L394). @@ -60,7 +59,7 @@ Information is encapsulated in lower layer packets on the sending side and then As with all other L1 transactions, the L1 costs of a deposit are borne by the transaction's originator. However, the L2 processing of the transaction is performed by the Optimism nodes. -If there were no cost attached, an attacker could be able to submit a transaction that had high costs of run on L2, and that way perform a denial of service attack. +If there were no cost attached, an attacker could submit a transaction that had high execution costs on L2, and that way perform a denial of service attack. To avoid this DoS vector, [`depositTransaction`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/L1/OptimismPortal.sol#L422-L483), and the functions that call it, require a gas limit parameter. [This gas limit is encoded into the \[\]`TransactionDeposited` event](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/L1/OptimismPortal.sol#L469-L477), and used as the gas limit for the user deposit transaction on L2. @@ -74,7 +73,7 @@ Deposits transactions can fail due to several reasons: * Not enough gas provided. * The state on L2 does not allow the transaction to be successful. -It is possible to replay a failed deposit, possibly with more gas, +It is possible to replay a failed deposit, possibly with more gas. ### Replays in action @@ -124,7 +123,7 @@ To see how replays work, you can use [this contract on OP Sepolia](https://sepol 5. The next step is to find the hash of the failed relay. The easiest way to do this is to look in [the internal transactions of the destination contract](https://sepolia-optimism.etherscan.io/address/0xEF60cF6C6D0C1c755be104843bb72CDa3D778630#internaltx), and select the latest one that appears as a failure. - It should be a call to L2CrossDomainMessenger at address `0x420...007`. This is the call you need to replay. + It should be a call to `L2CrossDomainMessenger` at address `0x420...007`. This is the call you need to replay. If the latest internal transaction is a success, it probably means your transaction hasn't relayed yet. Wait until it is, that may take a few minutes. @@ -185,10 +184,9 @@ To see how replays work, you can use [this contract on OP Sepolia](https://sepol ## Debugging -To debug deposit transactions you can ask the L2 cross domain messenger for the state of the transaction. +To debug deposit transactions, you can ask the L2 cross domain messenger for the state of the transaction. -1. Look on Etherscan to see the `FailedRelayedMessage` event. - Set `MSG_HASH` to that value. +1. Look on Etherscan to see the `FailedRelayedMessage` event. Set `MSG_HASH` to that value. 2. To check if the message is listed as failed, run this: diff --git a/pages/stack/protocol/rollup/overview.mdx b/pages/stack/protocol/rollup/overview.mdx index ad25d1120..a275be581 100644 --- a/pages/stack/protocol/rollup/overview.mdx +++ b/pages/stack/protocol/rollup/overview.mdx @@ -36,20 +36,20 @@ 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 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. Transactions get to the sequencer in two ways: -1. Transactions submitted on L1 (called *deposits*) are included in the chain in the appropriate L2 block. +1. Transactions submitted directly to the sequencer. + These transactions are a lot cheaper to submit, as they do not require the expense of a separate L1 transaction. However, they cannot be made censorship resistant since the sequencer is the only participant that knows about them. + +2. Transactions submitted on L1 (called *deposits*) are included in the chain in the appropriate L2 block. 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. + 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. You can read more about this mechanism [in the protocol specifications](https://specs.optimism.io/protocol/derivation.html#deriving-the-transaction-list). -2. Transactions submitted directly to the sequencer. - These transactions are a lot cheaper to submit, as they do not require the expense of a separate L1 transaction. However, they cannot be made censorship resistant since the sequencer is the only participant that knows about them. - For the moment, [The Optimism Foundation](https://www.optimism.io/) runs the only block producer on OP Mainnet. Refer to [Protocol specs](overview) section for more information about how we plan to decentralize the Sequencer role in the future. ## Block Execution @@ -70,8 +70,8 @@ Optimism is designed so that users can send arbitrary messages between smart con 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 from OP Mainnet back to Ethereum. -See the [developer documentation and examples](/builders/app-developers/bridging/standard-bridge) on details on the inner workings of the Standard bridge. +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. +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 diff --git a/pages/stack/protocol/rollup/smart-contracts.mdx b/pages/stack/protocol/rollup/smart-contracts.mdx index 41044536d..a3af040ae 100644 --- a/pages/stack/protocol/rollup/smart-contracts.mdx +++ b/pages/stack/protocol/rollup/smart-contracts.mdx @@ -8,8 +8,7 @@ import { Callout } from 'nextra/components' # Smart Contract Overview -This guide provides an overview of smart contract functionality -for 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 OP Mainnet. ## L1 contracts @@ -19,8 +18,8 @@ This contract enables a delay before a call is forwarded to a target contract, and during the delay period the call can be vetoed by the authorized vetoer. This contract does not support value transfers, only data is forwarded. Additionally, this contract cannot be used to forward calls with data beginning -with the function selector of the queuedAt(bytes32) function. This is because -of input validation checks which solidity performs at runtime on functions +with the function selector of the `queuedAt(bytes32)` function. This is because +of input validation checks performed by Solidity at runtime on functions which take an argument. ### [L1CrossDomainMessenger](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/L1/L1CrossDomainMessenger.sol) @@ -63,7 +62,7 @@ Users are encouraged to use the `L1CrossDomainMessenger` for a higher-level inte ### [ProtocolVersions](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/L1/ProtocolVersions.sol) -The `ProtocolVersions` contract is used to manage superchain protocol version information. +The `ProtocolVersions` contract is used to manage Superchain protocol version information. ### [ResourceMetering](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/L1/ResourceMetering.sol) @@ -72,7 +71,7 @@ updates automatically based on current demand. ### [SuperchainConfig](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/L1/SuperchainConfig.sol) -The `SuperchainConfig` contract is used to manage configuration of global superchain values. +The `SuperchainConfig` contract is used to manage configuration of global Superchain values. ### [SystemConfig](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/L1/SystemConfig.sol) @@ -161,7 +160,7 @@ transaction processing and block production. ## Legacy Contracts -Those are legacy contracts from the old version of the OP Stack. +These are legacy contracts from the old version of the OP Stack. ### [AddressManager](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/legacy/AddressManager.sol) diff --git a/pages/stack/protocol/rollup/withdrawal-flow.mdx b/pages/stack/protocol/rollup/withdrawal-flow.mdx index d39d2156b..19834c55f 100644 --- a/pages/stack/protocol/rollup/withdrawal-flow.mdx +++ b/pages/stack/protocol/rollup/withdrawal-flow.mdx @@ -13,7 +13,7 @@ In Optimism terminology, a *withdrawal* is a transaction sent from L2 (OP Mainne Withdrawals require the user to submit three transactions: 1. **Withdrawal initiating transaction**, which the user submits on L2. -2. **Withdrawal proving transaction**, which the user submits on L1 to prove that the withdrawal is legitimate (based on a merkle patricia trie root that commits to the state of the `L2ToL1MessagePasser`'s storage on L2) +2. **Withdrawal proving transaction**, which the user submits on L1 to prove that the withdrawal is legitimate (based on a Merkle-Patricia trie root that commits to the state of the `L2ToL1MessagePasser`'s storage on L2) 3. **Withdrawal finalizing transaction**, which the user submits on L1 after the fault challenge period has passed, to actually run the transaction on L1. @@ -22,7 +22,7 @@ Withdrawals require the user to submit three transactions: ## Withdrawal initiating transaction -1. On L2 somebody (either an externally owned account (EOA) directly or a contract acting on behalf of an EOA) calls the [`sendMessage`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/universal/CrossDomainMessenger.sol#L249-L289) function of [`L2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/universal/CrossDomainMessenger.sol). +1. On L2, a user, either an externally owned account (EOA) directly or a contract acting on behalf of an EOA, calls the [`sendMessage`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/universal/CrossDomainMessenger.sol#L249-L289) function of the [`L2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/universal/CrossDomainMessenger.sol) contract. This function accepts three parameters: From c802029d958d348bc2fc146d5c8ae37d07794348 Mon Sep 17 00:00:00 2001 From: Paul Razvan Berg Date: Wed, 22 May 2024 11:54:16 +0100 Subject: [PATCH 2/3] Update pages/stack/protocol/rollup/deposit-flow.mdx Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- pages/stack/protocol/rollup/deposit-flow.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/protocol/rollup/deposit-flow.mdx b/pages/stack/protocol/rollup/deposit-flow.mdx index 91c64927a..3253e4032 100644 --- a/pages/stack/protocol/rollup/deposit-flow.mdx +++ b/pages/stack/protocol/rollup/deposit-flow.mdx @@ -23,7 +23,7 @@ Information is encapsulated in lower layer packets on the sending side and then * `_target`, target address on L2. * `_message`, the L2 transaction's calldata, formatted as per the [ABI](https://docs.soliditylang.org/en/v0.8.19/abi-spec.html) of the target account. - * `_minGasLimit`, the minimum gas limit allowed for the transaction on L2. Note that this is a *minimum* and the actual amount provided on L2 may be higher (but never lower) than the specified gas limit. The actual amount provided on L2 will be higher because the portal contract on L2 needs to do some processing before submitting the call to `_target`. + * `_minGasLimit`, the minimum gas limit allowed for the transaction on L2. Note that this is a *minimum* and the actual amount provided on L2 may be higher (but never lower) than the specified gas limit. The actual amount provided on L2 is often higher because the portal contract on L2 performs some processing before submitting the call to `_target`. 2. The L1 cross domain messenger calls [its own `_send` function](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/L1/L1CrossDomainMessenger.sol#L42-L52). It uses these parameters: From 94f789a122989a32292b14fddacf068ba5412cb4 Mon Sep 17 00:00:00 2001 From: cpengilly <29023967+cpengilly@users.noreply.github.com> Date: Sun, 9 Jun 2024 13:34:47 -0700 Subject: [PATCH 3/3] linter fix --- pages/stack/explainer.mdx | 12 ++++++------ words.txt | 1 - 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/pages/stack/explainer.mdx b/pages/stack/explainer.mdx index a3a08d9e2..68e8f6330 100644 --- a/pages/stack/explainer.mdx +++ b/pages/stack/explainer.mdx @@ -206,12 +206,12 @@ We believe these upgrades can provide a shared bridge for all OP Chains, cheap O We expect that, if successful, the post-Bedrock Superchain release will mark a major milestone in the scalability and decentralization of Optimism. However, there will still be significant pain points which must be addressed before the full scalable blockchain vision has been realized. Anticipated pain points include: -1. Withdrawal claims rely on a trusted set of chain attestors. -2. Cross-chain transactions are slow because they require waiting a challenge period. -3. Cross-chain transactions are asynchronous, breaking the ability to perform atomic cross-chain transactions (like flash loans). -4. Posting transactions to the Superchain is not-scalable because the transaction data must be submitted to L1 which has limited capacity. -5. There are no easy-to-use frameworks for building scalable apps which utilize many OP Chains. -6. There is no easy-to-use wallet for managing tokens and apps across many OP Chains. +1. Withdrawal claims rely on a trusted set of chain attestors. +2. Cross-chain transactions are slow because they require waiting a challenge period. +3. Cross-chain transactions are asynchronous, breaking the ability to perform atomic cross-chain transactions (like flash loans). +4. Posting transactions to the Superchain is not-scalable because the transaction data must be submitted to L1 which has limited capacity. +5. There are no easy-to-use frameworks for building scalable apps which utilize many OP Chains. +6. There is no easy-to-use wallet for managing tokens and apps across many OP Chains. If each one of these pain points were addressed, it could be possible to build decentralized alternatives to even the most complex web2 applications. diff --git a/words.txt b/words.txt index bc41681df..dd03aa2ae 100644 --- a/words.txt +++ b/words.txt @@ -134,7 +134,6 @@ journalremotes JSPATH jspath jwtsecret -leadup leveldb lightkdf logfile