Skip to content

N
nebula
Commit 0a83d43b authored by Ori Pomerantz's avatar Ori Pomerantz Committed by Kelvin Fichter
Browse files
Options

feat(docs/op-stack): First real version

parent 03012bd0
Expand all Show whitespace changes
Inline Side-by-side
Showing with 1857 additions and 2539 deletions
docs/op-stack/src/.vuepress/config.js
View file @ 0a83d43b
......@@ -36,27 +36,27 @@ module.exports = {
apiKey: '2c1a86142192f96dab9a5066ad0c1d50',
indexName: 'optimism'
},
nav: [
/* When you update here, don't forget to update the tiles src/README.md */
nav: false, /* [
{
text: 'How Optimism Works',
link: '/docs/how-optimism-works/'
text: 'Understanding the OP Stack',
link: '/docs/understand/'
},
{
text: 'Protocol Specs',
link: '/docs/protocol/'
text: 'Releases',
link: '/docs/releases/'
},
{
text: 'Security',
link: '/docs/security-model/',
text: 'Building',
link: '/docs/build/'
},
{
text: 'Developer Docs',
link: '/docs/developers/',
text: 'Contribute',
link: '/docs/CONTRIB.md'
},
{
text: 'Contribute',
link: '/docs/contribute/',
text: 'Security',
link: '/docs/security/'
},
{
text: 'Community',
......@@ -110,39 +110,70 @@ module.exports = {
}
]
}
],
], */
searchPlaceholder: 'Search the docs',
sidebar: {
'/docs/how-optimism-works': [
'/docs/how-optimism-works/design-philosophy.md',
'/docs/how-optimism-works/rollup-protocol.md',
],
'/docs/protocol/': [
'/docs/protocol/contract-overview.md',
],
'/docs/security-model/': [
'/docs/security-model/optimism-security-model.md',
'/docs/security-model/bounties.md',
],
'/docs/developers/': [
'/docs': [
{
title: "OP Stack: Bedrock",
title: "Understanding the OP Stack",
collapsable: false,
children: [
'/docs/developers/opstack/explainer.md',
'/docs/developers/opstack/differences.md',
'/docs/developers/opstack/public-testnets.md',
'/docs/developers/opstack/node-operator-guide.md',
'/docs/developers/opstack/upgrade-guide.md',
'/docs/developers/opstack/metrics.md'
'/docs/understand/intro.md',
'/docs/understand/design-principles.md',
'/docs/understand/landscape.md',
]
},
'/docs/developers/releases.md'
{
title: "Releases",
collapsable: false,
children: [
'/docs/releases/releases.md',
'/docs/releases/bedrock.md',
]
},
{
title: "Building OP Stack Rollups",
collapsable: false,
children: [
{
title: "Running a Bedrock Rollup",
children: [
'/docs/build/getting-started.md',
'/docs/build/conf.md'
]
},
{
title: "OP Stack Hacks",
collapsable: true,
children: [
'/docs/build/hacks.md',
'/docs/build/featured.md',
'/docs/build/data-avail.md',
'/docs/build/derivation.md',
'/docs/build/execution.md',
'/docs/build/settlement.md',
{
title: "Tutorials",
children: [
"/docs/build/tutorials/add-attr.md",
"/docs/build/tutorials/new-precomp.md",
]
} // End of tutorials
],
'/docs/contribute/': [
'/docs/contribute/README.md'
}, // End of OP Stack hacks
],
}, // End of Building OP Stack Rollups
'/docs/CONTRIB.md',
{
title: "Security",
collapsable: false,
children: [
'/docs/security/faq.md',
'/docs/security/policy.md',
]
}
},
], // end of '/docs'
}, // end of sidebar
plugins: [
"@vuepress/pwa",
[
......@@ -154,5 +185,6 @@ module.exports = {
"plausible-analytics"
]
}
}
module.exports.themeConfig.sidebar["/docs/useful-tools/"] = module.exports.themeConfig.sidebar["/docs/developers/"]
// module.exports.themeConfig.sidebar["/docs/useful-tools/"] = module.exports.themeConfig.sidebar["/docs/developers/"]
docs/op-stack/src/.vuepress/theme/components/Anchor.js
View file @ 0a83d43b
......@@ -63,7 +63,7 @@ export default Vue.extend({
" Discord community"
])
]),
h("a", { attrs: { href: "https://optimismpbc.typeform.com/get-in-touch", target: "_blank" } }, [
h("a", { attrs: { href: "https://oplabs.typeform.com/get-in-touch", target: "_blank" } }, [
h("div", [
h("i", { attrs: { class: "far fa-comment-dots" } }),
" Get support for going live"
......
docs/op-stack/src/.vuepress/theme/components/PageMeta.vue
View file @ 0a83d43b
......@@ -33,7 +33,7 @@
</a>
</li>
<li>
<a href="https://optimismpbc.typeform.com/get-in-touch" target="_blank" rel="noopener noreferrer">
<a href="https://oplabs.typeform.com/get-in-touch" target="_blank" rel="noopener noreferrer">
<i class="far fa-comment-dots"></i> Get support for going live
</a>
</li>
......
docs/op-stack/src/README.md
View file @ 0a83d43b
......@@ -3,7 +3,7 @@ home: true
icon: home
title: Home
heroImage: /assets/logos/header.png
heroText: The Optimism Docs
heroText: OP Stack
features:
- title: How Optimism works
......
docs/op-stack/src/docs/CONTRIB.md 0 → 100644
View file @ 0a83d43b
---
title: Contributing
lang: en-US
---
The OP Stack is a collaborative, decentralized development stack that only gets more powerful as more people contribute. Code for the OP Stack should follow the stack’s [design principles](./understand/design-principles.md), which means it should be entirely open source and accessible for people to hack on, contribute to, and extend. The Optimism Collective wins when it works together. ♥️✨
Whether you’re a budding protocol developer, dapp developer, bounty hunter, documentation editor, content creator, or anything in between, the OP Stack always has something for you to contribute to. Every contribution makes a difference — no contribution is too small.
If you’re looking to find a way to contribute, check out one of the following contributor pathways below. Come make your first contribution today!
## Component contributions
The OP Stack is a decentralized development stack. Anyone can contribute components that can be considered part of the OP Stack as long as as those components fit [the stack’s design principles and goals](./understand/design-principles.md). To start contributing components to the stack, check out some of [these useful ideas](https://github.com/ethereum-optimism/optimism-project-ideas) and get to building! And don’t forget that projects can also receive funding from the Collective via RetroPGF.
If you’d like to contribute to existing OP Stack code, rather than creating new components, check out [the current release of the OP Stack](./releases/README.md#current-release). Any contributions to existing OP Stack components are highly appreciated. If you’re looking for a good way to make your first contribution, check out the [Good First Issues](https://github.com/ethereum-optimism/optimism/contribute) on the Optimism Monorepo.
## Bounty hunting
The OP Stack needs YOU (yes you!) to help review the codebase for bugs and vulnerabilities. If you’re interested in bounty hunting, check out our Security Policy, Vulnerability Reporting, and Bug Bounties page.
## Documentation help
Spot a typo in these docs? See something that could be a little clearer? Head over to the Optimism Monorepo where the OP Stack docs are hosted and make a pull request. No contribution is too small!
## Community contributions
If you’re looking for other ways to get involved, here are a few options:
- Grab an idea from the [project ideas list](https://github.com/ethereum-optimism/optimism-project-ideas) to and building
- Suggest a new idea for the [project ideas list](https://github.com/ethereum-optimism/optimism-project-ideas)
- Improve the [Optimism Community Hub](https://community.optimism.io/) [documentation](https://github.com/ethereum-optimism/community-hub) or [tutorials](https://github.com/ethereum-optimism/optimism-tutorial)
- Become an Optimism Ambassador, Support Nerd, and more in the [Optimism Discord](https://discord-gateway.optimism.io/)
\ No newline at end of file
docs/op-stack/src/docs/README.md 0 → 100644
View file @ 0a83d43b
---
title: The OP Stack
lang: en-US
---
The OP Stack is the decentralized development stack that powers Optimism. The current release of the OP Stack (named “Bedrock”) was designed to facilitate the creation of L2 blockchains that can interoperate with the proposed [Optimism Superchain](https://optimism.mirror.xyz/fLk5UGjZDiXFuvQh6R_HscMQuuY9ABYNF7PI76-qJYs). The Superchain is a proposed network of rollups that share a security model, communication protocols, and a common development stack (the OP Stack itself). **The best way to get started building with the OP Stack today is to launch your own Bedrock-based Rollup by following our guide to [Getting started with an OP Stack chain](./build/getting-started.md)**. Bedrock Rollups will be compatible with the Superchain.
## Blog posts
- [Introducing the OP Stack (Oct. 17, 2022)](https://optimism.mirror.xyz/fLk5UGjZDiXFuvQh6R_HscMQuuY9ABYNF7PI76-qJYs)
<!--
## Videos
- Karl’s Dev Bogota talk (Oct. 14, 2022)
<iframe width="560" height="315" src="[https://www.youtube.com/embed/HiU-g8XHi5s](https://www.youtube.com/embed/HiU-g8XHi5s)" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
-->
\ No newline at end of file
docs/op-stack/src/docs/build/README.md 0 → 100644
View file @ 0a83d43b
---
title: Building with the OP Stack
lang: en-US
---
The OP Stack is the decentralized development stack that powers Optimism. The current release of the OP Stack (named “Bedrock”) was designed to facilitate the creation of L2 blockchains that can interoperate with the proposed [Optimism Superchain](https://optimism.mirror.xyz/fLk5UGjZDiXFuvQh6R_HscMQuuY9ABYNF7PI76-qJYs). The Superchain is a proposed network of rollups that share a security model, communication protocols, and a common development stack (the OP Stack itself). **The best way to get started building with the OP Stack today is to launch your own Bedrock-based Rollup by following our guide to [Running a Bedrock Rollup](./getting-started.md)**. Bedrock Rollups will be compatible with the Superchain.
You can also experiment with the OP Stack by making modifications to its various components. The OP Stack, as of the Bedrock release, is not explicitly designed to handle any significant modifications out of the box. By modifying the components of the OP Stack, you will likely no longer be compatible with the Superchain. Please also note that there is limited developer support available for modifications to the OP Stack. Have fun, but modify the stack at your own risk!
docs/op-stack/src/docs/build/conf.md 0 → 100644
View file @ 0a83d43b
---
title: Configuration
lang: en-US
---
The OP Stack is a flexible platform with various configuration values that you can tweak to fit your specific needs. If you’re looking to fine-tune your deployment, look no further.
::: warning 🚧 Work in Progress
OP Stack configuration is an active work in progress and will likely evolve significantly as time goes on. If something isn’t working about your configuration, check back with this page to see if anything has changed.
:::
## New Blockchain Configuration
New OP Stack blockchains are currently configured with a JSON file inside the Optimism repository. The file is `<optimism repository>/packages/contracts-bedrock/deploy-config/<chain name>.json`. For example, [this is the configuration file for the tutorial blockchain](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/deploy-config/getting-started.json).
### Admin accounts
| Key | Type | Description | Default / Recommended value |
| --- | --- | --- | --- |
| `finalSystemOwner` | L1 Address | Address that will own all ownable contracts on L1 once the deployment is finished, including the `ProxyAdmin` contract. | It is recommended to have a single admin account to retain a common security model. |
| `controller` | L1 Address | Address that will own the `SystemDictator` contract and can therefore control the flow of the deployment or upgrade. | It is recommended to have a single admin account to retain a common security model. |
| `proxyAdminOwner` | L2 Address | Address that will own the `ProxyAdmin` contract on L2. The L2 `ProxyAdmin` contract owns all of the `Proxy` contracts for every predeployed contract in the range `0x42...0000` to `0x42..2048`. This makes predeployed contracts easily upgradeable. | It is recommended to have a single admin account to retain a common security model. |
### Fee recipients
| Key | Type | Description | Default value |
| --- | --- | --- | --- |
| `baseFeeVaultRecipient` | L1 Address | L1 address that the base fees from all transactions on the L2 can be withdrawn to. | It is recommended to have a single admin account to retain a common security model. |
| `l1FeeVaultRecipient` | L1 Address | L1 address that the L1 data fees from all transactions on the L2 can be withdrawn to. | It is recommended to have a single admin account to retain a common security model. |
| `sequencerFeeVaultRecipient` | L1 Address | L1 address that the tip fees from all transactions on the L2 can be withdrawn to. | It is recommended to have a single admin account to retain a common security model. |
### Misc.
| Key | Type | Description | Default value |
| --- | --- | --- | --- |
| `numDeployConfirmations` | Number of blocks | Number of confirmations to wait when deploying smart contracts to L1. | 1 |
| `l1StartingBlockTag` | Block hash | Block tag for the L1 block where the L2 chain will begin syncing from. Generally recommended to use a finalized block to avoid issues with reorgs. | |
| `l1ChainID` | Number | Chain ID of the L1 chain. | 1 for L1 Ethereum mainnet, <br> 5 for the Goerli test network. <br> [See here for other blockchains](https://chainlist.org/?testnets=true). |
| `l2ChainID` | Number | Chain ID of the L2 chain. | 42069 |
### Blocks
These fields apply to L2 blocks: Their timing, when do they need to be written to L1, and how they get written.
| Key | Type | Description | Default value |
| --- | --- | --- | --- |
| `l2BlockTime` | Number of seconds | Number of seconds between each L2 block. | 2 |
| `maxSequencerDrift` | Number of seconds | How far the L2 timestamp can differ from the actual L1 timestamp | 600 (10 minutes) |
| `sequencerWindowSize` | Number of blocks | Maximum number of L1 blocks that a Sequencer can wait to incorporate the information in a specific L1 block. For example, if the window is `10` then the information in L1 block `n` must be incorporated by L1 block `n+10`. | 3600 (12 hours) |
| `channelTimeout` | Number of blocks | Maximum number of L1 blocks that a transaction channel frame can be considered valid. A transaction channel frame is a chunk of a compressed batch of transactions. After the timeout, the frame is dropped. | 300 (1 hour) |
| `p2pSequencerAddress` | L1 Address | Address of the key that the Sequencer uses to sign blocks on the p2p network. | Sequencer, an address for which you own the private key |
| `batchInboxAddress` | L1 Address | Address that Sequencer transaction batches are sent to on L1. | 0xff00…0042069 |
| `batchSenderAddress` | L1 Address | Address of the account that nodes will filter for when searching for Sequencer transaction batches being sent to the `batchInboxAddress`. Can be updated later via the `SystemConfig` contract on L1. | Batcher, an address for which you own the private key |
### Proposal fields
These fields apply to output root proposals.
| Key | Type | Description | Default value |
| --- | --- | --- | --- |
| `l2OutputOracleStartingBlockNumber` | Number | Block number of the first OP Stack block. Typically this should be zero, but this may be non-zero for networks that have been upgraded from a legacy system (like Optimism Mainnet). Will be removed with the addition of permissionless proposals. | 0 |
| `l2OutputOracleStartingTimestamp` | Number | Timestamp of the first OP Stack block. This MUST be the timestamp corresponding to the block defined by the `l1StartingBlockTag`. Will be removed with the addition of permissionless proposals. | |
| `l2OutputOracleSubmissionInterval` | Number of blocks | Number of blocks between proposals to the `L2OutputOracle`. Will be removed with the addition of permissionless proposals. | 120 (24 minutes) |
| `finalizationPeriodSeconds` | Number of seconds | Number of seconds that a proposal must be available to challenge before it is considered finalized by the `OptimismPortal` contract. | We recommend 12 on test networks, seven days on production ones |
| `l2OutputOracleProposer` | L1 Address | Address that is allowed to submit output proposals to the `L2OutputOracle` contract. Will be removed when we have permissionless proposals. | |
| `l2OutputOracleChallenger` | L1 Address | Address that is allowed to challenge output proposals submitted to the `L2OutputOracle`. Will be removed when we have permissionless challenges. | It is recommended to have a single admin account to retain a common security model. |
### L1 data fee
These fields apply to the cost of the [L1 data fee](https://community.optimism.io/docs/developers/build/transaction-fees/#the-l1-data-fee) for L2 transactions.
| Key | Type | Description | Default value |
| --- | --- | --- | --- |
| `gasPriceOracleOverhead` | Number | Fixed L1 gas overhead per transaction. Default value will likely be adjusted with more information from the Optimism Goerli deployment. | 2100 |
| `gasPriceOracleScalar` | Number | Dynamic L1 gas overhead per transaction, given in 6 decimals. Default value of 1000000 implies a dynamic gas overhead of exactly 1x (no overhead). | 1000000 |
### EIP 1559 gas algorithm
These fields apply to [the EIP 1559 algorithm](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md) used for the [L2 execution costs](https://community.optimism.io/docs/developers/build/transaction-fees/#the-l2-execution-fee) of transactions on the blockchain.
| Key | Type | Description | Default value | Value on L1 Ethereum |
| --- | --- | --- | --- | --- |
| `eip1559Denominator` | Number | Denominator used for the [EIP1559 gas pricing mechanism on L2](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md). A larger denominator decreases the amount by which the base fee can change in a single block. | 50 | 8 |
| `eip1559Elasticity` | Number | Elasticity for the [EIP1559 gas pricing mechanism on L2](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md). A larger elasticity increases the maximum allowable gas limit per block. | 10 | 2 |
| `l2GenesisBlockGasLimit` | String | Initial block gas limit, represented as a hex string. Default is 25m, implying a 2.5m target when combined with a 10x elasticity. | 0x17D7840 | |
| `l2GenesisBlockBaseFeePerGas` | String | Initial base fee, used to avoid an unstable EIP1559 calculation out of the gate. Initial value is 1 gwei. | 0x3b9aca00 | |
### Governance token
The governance token is a side-effect of use of the OP Stack in the Optimism Mainnet network. It may not be included by default in future releases.
| Key | Type | Description | Default value |
| --- | --- | --- | --- |
| `governanceTokenOwner` | L2 Address | Address that will own the token contract deployed by default to every OP Stack based chain. | |
| `governanceTokenSymbol` | String | Symbol for the token deployed by default to each OP Stack chain. | OP |
| `governanceTokenName` | String | Name for the token deployed by default to each OP Stack chain. | Optimism |
\ No newline at end of file
docs/op-stack/src/docs/build/data-avail.md 0 → 100644
View file @ 0a83d43b
---
title: Data Availability Hacks
lang: en-US
---
::: warning 🚧 OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use
OP Stack Hacks are not for the faint of heart. You will not be able to receive significant developer support for OP Stack Hacks — be prepared to get your hands dirty and to work without support.
:::
## Overview
The Data Availability Layer is responsible for the *ordering* and *storage* of the raw input data that forms the backbone of an OP Stack based chain (transactions, state roots, calls from other blockchains, etc.). You can conceptually think of this as an array of inputs — the ordering of this array should remain stable and the contents of this array should remain available. Unstable ordering of inputs will lead to reorgs of the OP Stack chain, while unavailable inputs will cause the OP Stack chain to halt entirely.
## Default
The default Data Availability Layer module for an OP Stack chain is the Ethereum DA module. When using the Ethereum DA module, all raw input data is expected to be found on Ethereum. Any data that is accessible on Ethereum can be queried when using this module, including calldata, events, and other block data.
## Security
OP Stack based chains are functions of the raw input data found on the Data Availability Layer module(s) used. If a required piece of data is not available, nodes will not be able to properly sync the chain. This also means that these nodes will not be able to dispute any invalid state proposals made to a Settlement Layer module. An OP Stack based chain cannot be safer than the Data Availability module.
You should be careful to understand the security properties of any Data Availability module(s) that you use. The standard Ethereum DA module generally provides the best security guarantees at the cost of higher transaction fees. Alternative DA modules may be appropriate depending on your particular use-case and risk tolerance.
## Modding
### Alternative EVM DA
A simple modification is to use an EVM-based blockchain other than Ethereum as the Data Availability Layer. Doing so simply requires using an L1 RPC other than Ethereum.
### EVM-Ordered Alternative DA
A more involved modification to the Data Availability Layer is an "EVM-Ordered" Alternative DA module. This involves using an EVM-based chain to maintain the *ordering* of transaction data while using a different data storage system to host the underlying data. Generally, ordering is maintained by publishing hashes of the data to the EVM-based chain while publishing the preimages to those hashes to the alternative data source.
An EVM-Ordered Alternative DA module significantly reduces costs by only publishing hashes and not full input data to the EVM chain. Using an EVM chain for ordering also reduces the number of changes that must be made to the standard Rollup configuration to achieve this result.
An example of an EVM-Ordered Alternative DA module can be found within [this modification to the OP Stack](https://github.com/celestiaorg/optimism/pull/3) that uses the Celestia blockchain as a third-party data availability provider.
### Non-EVM DA
A non-EVM DA module uses a chain not based on the EVM to manage both the ordering and storage of raw input data. Such a modification would require relatively significant modifications to the [derivation portion](https://github.com/ethereum-optimism/optimism/tree/develop/op-node/rollup/derive) of the `op-node`. No such fully-independent DA modules have been developed yet — be the first!
### Multiple DA
It is possible to use multiple Data Availability Layer modules at the same time. For instance, one could source data from two EVM-based chains simultaneously in order to form a bridge between the two chains. When using multiple Data Availability Layer modules, it is imperative to establish a global ordering between the two chains. One option for establishing this ordering is to use the timestamps of blocks from each chain.
Like a non-EVM DA module, a system with multiple Data Availability modules would need to make significant modifications to the [derivation portion](https://github.com/ethereum-optimism/optimism/tree/develop/op-node/rollup/derive) of the `op-node`. No such projects have been constructed yet.
\ No newline at end of file
docs/op-stack/src/docs/build/derivation.md 0 → 100644
View file @ 0a83d43b
---
title: Derivation Hacks
lang: en-US
---
::: warning 🚧 OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use
OP Stack Hacks are not for the faint of heart. You will not be able to receive significant developer support for OP Stack Hacks — be prepared to get your hands dirty and to work without support.
:::
## Overview
The Derivation layer is responsible for parsing the raw inputs from the Data Availability layer and converting them into [Engine API](https://github.com/ethereum/execution-apis/tree/main/src/engine) payloads to be sent to the Execution layer. The Derivation Layer is generally tightly coupled to the Data Availability layer because it must understand both the APIs for the Data Availability layer module(s) of choice and the format of the raw data published to the chosen module(s).
## Default
The default Derivation layer module is the Rollup module. This module derives transactions from three sources: Sequencer transactions, user deposits, and L1 blocks. The Rollup module also enforces certain ordering properties that, for example, guarantee that user deposits are always included in the L2 chain within a certain configurable amount of time.
## Security
Modifying the Derivation layer can have unintended consequences. For example, removing or extending the time window in which user deposits must be included can allow a Sequencer to censor the L2 chain. Because of the flexibility of the Derivation layer, the exact impact of any change is likely to be unique to the specifics of the change. The negative impacts of any modifications should be carefully considered on a case-by-case basis.
## Modding
### EVM Event-Triggered Transactions
The default Rollup configuration of the OP Stack includes “deposited” transactions that are triggered whenever a specific event is emitted by the `OptimismPortal` contract on L1. Using the same principle, an OP Stack chain can derive transactions from events emitted by *any* contract on an EVM-based DA. Refer to [attributes.go](https://github.com/ethereum-optimism/optimism/blob/e468b66efedc5f47f4e04dc1acc803d4db2ce383/op-node/rollup/derive/attributes.go#L70) to understand how deposited transactions are derived and how custom transactions can be created.
### EVM Block-Triggered Transactions
Like with events, transactions on an OP Stack chain can be triggered whenever a new block is published on an EVM-based DA. The default Rollup configuration of the OP Stack already includes a block-triggered transaction in the form of [the “L1 info” transaction](https://github.com/ethereum-optimism/optimism/blob/e468b66efedc5f47f4e04dc1acc803d4db2ce383/op-node/rollup/derive/attributes.go#L103) that relays information like the latest block hash, timestamp, and base fee into L2. The Getting Started guide demonstrates the addition of a new block-triggered transaction in the form of a new transaction that reports the amount of gas burned via the base fee on L1.
### And much, much more…
The Derivation layer is one of the most flexible layers of the stack. Transactions can be generated from all sorts of raw input data and can be triggered from all sorts of conditions. You can derive transactions from any piece of data that can be found in the Data Availability layer modules!
[Tutorial: Adding attributes to the derivation function](./tutorials/add-attr.md).
\ No newline at end of file
docs/op-stack/src/docs/build/execution.md 0 → 100644
View file @ 0a83d43b
---
title: Execution Hacks
lang: en-US
---
::: warning 🚧 OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use
OP Stack Hacks are not for the faint of heart. You will not be able to receive significant developer support for OP Stack Hacks — be prepared to get your hands dirty and to work without support.
:::
## Overview
The Execution Layer is responsible for defining the format of state and the state transition function on L2. It is expected to trigger the state transition function when it receives a payload via the [Engine API](https://github.com/ethereum/execution-apis/tree/main/src/engine). Although the default Execution Layer module is the EVM, you can replace the EVM with any alternative VM as long as it sits behind the Engine API.
## Default
The default Execution Layer module is the Rollup EVM module. The Rollup EVM module utilizes a very lightly modified EVM that adds support for transactions that are triggered by smart contracts on L1 and introduces an L1 data fee to each transaction that accounts for the cost of publishing user transactions to L1. You can find the full set of differences between the standard EVM and the Rollup EVM [on this page](https://op-geth.optimism.io/).
## Security
As with modifications to the Derivation Layer, modifications to the Execution Layer can have unintended consequences. For instance, modifications to the EVM may break existing tooling or may open the door to denial of service attacks. Consider the impact of each modification carefully on a case-by-case basis.
## Modding
### EVM Tweaks
The default Execution Layer module is the EVM. It’s possible to modify the EVM in many different ways like adding new precompiles or inserting predeployed smart contracts into the genesis state. Precompiles can help make common smart contract operations cheaper and can therefore further reduce the cost of execution for your specific use-case. These modifications should be made directly to [the execution client](https://github.com/ethereum-optimism/op-geth).
It’s also possible to create alternative execution client implementations to improve the security properties of your chain. Note that if you modify the EVM, you must apply the same modifications to every execution client that you would like to support.
### Alternative VMs
The OP Stack allows you to replace the EVM with *any* state transition function, as long as the transition can be triggered via the Engine API. This has, for example, been used to implement an OP Stack chain that runs a GameBoy emulator rather than the EVM.
[Tutorial: Adding a precompile](./tutorials/new-precomp.md).
\ No newline at end of file
docs/op-stack/src/docs/build/featured.md 0 → 100644
View file @ 0a83d43b
---
title: Featured Hacks
lang: en-US
---
::: warning 🚧 OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use
OP Stack Hacks are not for the faint of heart. You will not be able to receive significant developer support for OP Stack Hacks — be prepared to get your hands dirty and to work without support.
:::
## Overview
Featured Hacks is a compilation of some of the cool stuff people are building on top of the OP Stack!
## OPCraft
### Author
[Lattice](https://lattice.xyz/)
### Description
OPCraft was an OP Stack chain that ran a modified EVM as the backend for a fully on-chain 3D voxel game built with [MUD](https://mud.dev/).
### OP Stack Configuration
- Data Availability: Ethereum DA (Goerli)
- Sequencer: Single Sequencer
- Derivation: Standard Rollup
- Execution: Modified Rollup EVM
### Links
- [Announcing OPCraft: an Autonomous World built on the OP Stack](https://dev.optimism.io/opcraft-autonomous-world/)
- [OPCraft Explorer](https://opcraft.mud.dev/)
- [OPCraft on GitHub](https://github.com/latticexyz/opcraft)
- [MUD](https://mud.dev/)
## Ticking Optimism
### Author
[@therealbytes](https://twitter.com/therealbytes)
### Description
Ticking Optimism is a proof-of-concept implementation of an OP Stack chain that calls a `tick` function every block. By using the OP Stack, Ticking Optimism avoids the need for off-chain infrastructure to execute a function on a regular basis. Ticking Conway is a system that uses Ticking Optimism to build [Conway’s Game of Life](https://conwaylife.com/) on-chain.
### OP Stack Configuration
- Data Availability: Ethereum DA (any)
- Sequencer: Single Sequencer
- Derivation: Standard Rollup with custom `tick` function
- Execution: Rollup EVM
### Links
- [Ticking Optimism on GitHub](https://github.com/therealbytes/ticking-optimism)
- [Ticking Conway on GitHub](https://github.com/therealbytes/ticking-conway)
\ No newline at end of file
docs/op-stack/src/docs/build/getting-started.md 0 → 100644
View file @ 0a83d43b
This diff is collapsed.
docs/op-stack/src/docs/build/hacks.md 0 → 100644
View file @ 0a83d43b
---
title: Introduction to OP Stack Hacks
lang: en-US
---
Welcome to OP Stack Hacks, the **highly experimental** region of the OP Stack docs. OP Stack Hacks are an unofficial guide for messing around with the OP Stack. Here you’ll find information about ways that the OP Stack can be modified in interesting ways.
OP Stack Hacks create blockchains that aren’t exactly OP Stack, and may be insecure.. Hacked OP Stack chains can break key invariants that are required to interoperate with the Optimism Superchain (link). **Developers of chains that wish to interoperate with the Optimism Superchain should *not* include any hacks**. When in doubt, stick with the official components within [the current release of the OP Stack](../releases/README.md#current-release).
::: warning 🚧 OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use
OP Stack Hacks are not for the faint of heart. You will not be able to receive significant developer support for OP Stack Hacks — be prepared to get your hands dirty and to work without support.
:::
docs/op-stack/src/docs/build/settlement.md 0 → 100644
View file @ 0a83d43b
---
title: Settlement Hacks
lang: en-US
---
::: warning 🚧 OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use
OP Stack Hacks are not for the faint of heart. You will not be able to receive significant developer support for OP Stack Hacks — be prepared to get your hands dirty and to work without support.
:::
# Overview
The Settlement Layer includes modules that are used by third-party chains to establish a *view* of the state of your OP Stack chain. This view can then be used by applications on those chains to make decisions based on the state of your OP Stack chain. Third-party chains can be any other blockchain, including other OP Stack chains. One common Settlement Layer mechanism is a withdrawal system that allows users to send assets from your OP Stack chain to the third-party chain. Modifications to this layer typically involve introducing new modules or tweaking the security model of existing modules.
## Default
The default Settlement Layer module is currently the Attestation Proof Optimistic Settlement module. This module allows a third-party chain to become aware of the state of an OP Stack chain through an Optimistic protocol where challenges can be executed alongside a threshold of attestations from a pre-defined set of addresses over a state that differs from the proposed state. Once the Cannon fault proof is shipped to production, this default module will be replaced with a module that allows anyone to challenge proposals by playing the Cannon dispute game.
## Security
Modifications to the Settlement Layer can strongly impact the security of common mechanisms like user withdrawals. A decreased withdrawal delay can, for instance, open the door to gas spam attacks that make challenges exceedingly expensive. It is generally not recommended to modify the Settlement Layer unless you know what you’re doing.
## Modding
### Tweaked parameters
One simple modification to the Settlement Layer is to tweak the parameters of the default Optimistic asset withdrawal mechanism. For example, the withdrawal period can be reduced if a smaller withdrawal period would be sufficient to secure your system.
### Custom proofs
Settlement Layer modules use a proof system to verify the correctness of the state of your OP Stack chain as proposed on the third-party chain. In general, these proofs are either Optimistic proofs that require a withdrawal delay or Validity proofs that use a mathematical proof system to assert the validity of the proposal. The current Attestation Proof Optimistic Settlement module could be replaced with a fault proof system.
### Multiple modules
There is no requirement that a system only have one Settlement Layer module. It is possible to use one or more Settlement Layer modules on one or more third-party chains. A system that aims to bridge assets between two chains will likely need to use one Data Availability Layer module and one Settlement Layer module per chain.
\ No newline at end of file
docs/op-stack/src/docs/build/tutorials/add-attr.md 0 → 100644
View file @ 0a83d43b
This diff is collapsed.
docs/op-stack/src/docs/build/tutorials/new-precomp.md 0 → 100644
View file @ 0a83d43b
---
title: Adding a Precompile
lang: en-US
---
::: warning 🚧 OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use
OP Stack Hacks are not for the faint of heart. You will not be able to receive significant developer support for OP Stack Hacks — be prepared to get your hands dirty and to work without support.
:::
One possible use of OP Stack is to run an EVM with a new precompile for operations to speed up calculations that are not currently supported. In this case we’ll make a simple precompile that returns a constant value if it’s called with four or less bytes, or an error if it is called with more than that.
To create a new precompile, the file to modify is `[op-geth/core/vm/contracts.go](https://github.com/ethereum-optimism/op-geth/blob/optimism-history/core/vm/contracts.go)`.
1. Add to `PrecompiledContractsBerlin` on line 82 (or a later fork, if the list of precompiles changes again) a structure named after your new precompile, with an address that is unlikely to ever clash with a standard precompile (0x100, for example):
```go
common.BytesToAddress([]byte{1,0}): &retConstant{},
```
1. Add the lines for the precompile.
```go
type retConstant struct{}
func (c *retConstant) RequiredGas(input []byte) uint64 {
return uint64(1024)
}
var (
errConstInvalidInputLength = errors.New("invalid input length")
)
func (c *retConstant) Run(input []byte) ([]byte, error) {
// Only allow input up to four bytes (function signature)
if len(input) > 4 {
return nil, errConstInvalidInputLength
}
output := make([]byte, 6)
for i := 0; i < 6; i++ {
output[i] = byte(64+i)
}
return output, nil
}
```
1. Stop `op-geth` and recompile:
```bash
cd ~/op-geth
make geth
```
1. Restart `op-geth`.
1. Run these command to see the result of calling the precompile successfully, and the result of an error:
```bash
cast call 0x0000000000000000000000000000000000000100 "whatever()"
cast call 0x0000000000000000000000000000000000000100 "whatever(string)" "fail"
```
## How does it work?
This is the precompile interface definition:
```go
type PrecompiledContract interface {
RequiredGas(input []byte) uint64 // RequiredPrice calculates the contract gas use
Run(input []byte) ([]byte, error) // Run runs the precompiled contract
}
```
It means that for every precompile we need two functions:
- `RequiredGas` which returns the gas cost for the call. This function takes an array of bytes as input, and returns a single value, the gas cost.
- `Run` which runs the actual precompile. This function also takes an array of bytes, but it returns two values: the call’s output (a byte array) and an error.
For every fork that changes the precompiles we have a [`map`](https://www.w3schools.com/go/go_maps.php)from addresses to the `PrecompiledContract` definitions:
```go
// PrecompiledContractsBerlin contains the default set of pre-compiled Ethereum
// contracts used in the Berlin release.
var PrecompiledContractsBerlin = map[common.Address]PrecompiledContract{
common.BytesToAddress([]byte{1}): &ecrecover{},
.
.
.
common.BytesToAddress([]byte{9}): &blake2F{},
common.BytesToAddress([]byte{1,0}): &retConstant{},
}
```
The key of the map is an address. We create those from bytes using `common.BytesToAddress([]byte{<bytes to convert to address go here>})`. In this case we have two bytes, `0x01` and `0x00`. Together we get the address `0x0…0100`.
The syntax for a precompiled contract interface is `&<variable name>{}`.
The next step is to define the precompiled contract itself.
```go
type retConstant struct{}
```
First we create a structure for the precompile.
```go
func (c *retConstant) RequiredGas(input []byte) uint64 {
return uint64(1024)
}
```
Then we define a function as part of that structure. Here we just require a constant amount of gas, but of course the calculation can be a lot more sophisticated.
```go
var (
errConstInvalidInputLength = errors.New("invalid input length")
)
```
Next we define a variable for the error.
```go
func (c *retConstant) Run(input []byte) ([]byte, error) {
```
This is the function that actually executes the precompile.
```go
// Only allow input up to four bytes (function signature)
if len(input) > 4 {
return nil, errConstInvalidInputLength
}
```
Return an error if warranted. The reason this precompile allows up to four bytes of input is that any standard call (for example, using `cast`) is going to have at least four bytes for the function signature.
`return a, b` is the way we return two values from a function in Go. The normal output is `nil`, nothing, because we return an error.
```go
output := make([]byte, 6)
for i := 0; i < 6; i++ {
output[i] = byte(64+i)
}
return output, nil
}
```
Finally, we create the output buffer, fill it, and then return it.
## Conclusion
An OP Stack chain with additional precompiles can be useful, for example, to further reduce the computational effort required for cryptographic operations by moving them from interpreted EVM code to compiled Go code.
\ No newline at end of file
docs/op-stack/src/docs/contribute/README.md deleted 100644 → 0
View file @ 03012bd0
---
title: Contribute to Optimism
lang: en-US
---
🎈 Thanks for your help improving the project! We are so happy to have you!
There are plenty of ways to contribute, in particular we appreciate support in the following areas:
## Code contributions
The Optimism codebase is maintained in a monorepo at [https://github.com/ethereum-optimism/optimism](https://github.com/ethereum-optimism/optimism). It's a [collection of packages](https://github.com/ethereum-optimism/optimism#directory-structure) all requiring different skills to maintain and evolve ranging from NodeJS and TypeScript, Solidity and EVM, Go and Geth to Docker and Kubernetes. The following are good entry points into using your coding skills to help us build Optimism:
- Reporting issues. For security issues see [Security policy](https://github.com/ethereum-optimism/.github/blob/master/SECURITY.md).
- Participate in the [Bug Bouty programme](https://immunefi.com/bounty/optimism/).
- Fixing and responding to existing issues. You can start off with those tagged ["good first issue"](https://github.com/ethereum-optimism/optimism/contribute) which are meant as introductory issues for external contributors.
- Work on open [bounties on Gitcoin](https://gitcoin.co/ethereum-optimism).
::: tip
Following the guidelines on [Contributing](https://github.com/ethereum-optimism/optimism/blob/master/CONTRIBUTING.md) and [Code of Conduct](https://github.com/ethereum-optimism/.github/blob/master/CODE_OF_CONDUCT.md) in all your interactions with the project will ensure your contributions are processed by the team.
:::
## Community contributions
- Pick an idea from the [project ideas list](https://github.com/ethereum-optimism/optimism-project-ideas) to start building
- Improve the [community site](https://community.optimism.io/) [documentation](https://github.com/ethereum-optimism/community-hub) or [tutorials](https://github.com/ethereum-optimism/optimism-tutorial).
- Become an "Optimizer" and answer questions in the [Optimism Discord](https://discord-gateway.optimism.io).
docs/op-stack/src/docs/developers/README.md deleted 100644 → 0
View file @ 03012bd0
---
title: Developer docs
lang: en-US
---
Welcome to the Optimism developer docs!
Whether you're just looking to [deploy a basic contract](https://github.com/ethereum-optimism/optimism-tutorial/tree/main/getting-started) or you're ready to [build a cross-chain app](./bridge/messaging.md), you'll be able to find everything you need to start building on Optimism within this section.
If you're looking for third-party tools that make building on Optimism easier, check out the [Tools for Developers](../useful-tools) section.
## Where should I start?
### Just getting started with Optimism?
If you're brand new to Optimism, we recommend checking out the [guide to deploying a basic contract](https://github.com/ethereum-optimism/optimism-tutorial/tree/main/getting-started).
It'll get you familiar with the core steps required to get a contract deployed to the network.
Luckily, Optimism is [EVM equivalent](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), so it's 100% the same as deploying a contract to Ethereum.
If you're a bit more familiar with Optimism and Ethereum, you can try walking through one of the various [tutorials](https://github.com/ethereum-optimism/optimism-tutorial) put together by the Optimism community.
They'll help you get a headstart when building your first Optimistic project.
### Ready to deploy a contract?
If you're looking to deploy your contracts to the Optimism mainnet or the Optimism Goerli testnet, take a look at our page on [using your favorite tools](./build/using-tools.md).
It contains sample configuration files for deploying your contracts from common frameworks like Hardhat, Truffle, and Brownie.
You might also want to check out our guides for [running a local development environment](./build/dev-node.md) or [running your own Optimism node](./build/run-a-node.md).
These guides are designed to help you feel totally confident in your Optimism deployment.
### Want to explore the cross-chain frontier?
We've got detailed guides for that.
If you want to bridge a token from Ethereum to Optimism (or vice versa!), you should learn more about our [Standard Token Bridge](./bridge/standard-bridge.md).
The Standard Token Bridge makes the process of moving tokens between chains as easy as possible.
If you're looking for something more advanced, we recommend reading through our page on [sending data between L1 and L2](./bridge/messaging.md).
Contracts on one chain can trigger contract functions on the other chain, it's pretty cool!
We even dogfood the same infrastructure and use it under the hood of the Standard Token Bridge.
## Still don't know where to look?
If you can't find the content you're looking for you've got a few options to get extra help.
We recommend first searching through this documentation (search bar at the top right).
If you've already done this and come up short, you can try [asking us a question in Discord](https://discord-gateway.optimism.io), [checking the Help Center](https://help.optimism.io/hc/en-us), or [making an issue on GitHub](https://github.com/ethereum-optimism/community-hub/issues).
docs/op-stack/src/docs/developers/building-with-op-stack.md deleted 100644 → 0
View file @ 03012bd0
---
title: Building with OP Stack
lang: en-US
---
Stuff goes here
docs/op-stack/src/docs/developers/opstack/explainer.md deleted 100644 → 0
View file @ 03012bd0
This diff is collapsed.
docs/op-stack/src/docs/developers/opstack/metrics.md deleted 100644 → 0
View file @ 03012bd0
---
title: Metrics
lang: en-US
---
The Bedrock `op-node` exposes a variety of metrics to help observe the health of the system and debug issues. Metrics are formatted for use with Prometheus, and exposed via a metrics endpoint. The default metrics endpoint is `http://localhost:7300/metrics`.
To enable metrics, pass the `--metrics.enabled` flag to the `op-node`. You can customize the metrics port and address via the `--metrics.port` and `--metrics.addr` flags, respectively.
## Important Metrics
To monitor the health of your node, you should monitor the following metrics:
- `op_node_default_refs_number`: This metric represents the `op-node`'s current L1/L2 reference block number for different sync types. If it stops increasing, it means that the node is not syncing. If it goes backwards, it means your node is reorging.
- `op_node_default_peer_count`: This metric represents how many peers the `op-node` is connected to. Without peers, the `op-node` cannot sync unsafe blocks and your node will lag behind the sequencer as it will fall back to syncing purely from L1.
- `op_node_default_rpc_client_request_duration_seconds`: This metrics measures the latency of RPC requests initiated by the `op-node`. This metric is important when debugging sync performance, as it will reveal which specific RPC calls are slowing down sync. This metric exposes one timeseries per RPC method. The most important RPC methods to monitor are:
- `engine_forkChoiceUpdatedV1`, `engine_getPayloadV1`, and `engine_newPayloadV1`: These methods are used to execute blocks on `op-geth`. If these methods are slow, it means that sync time is bottlenecked by either `op-geth` itself or your connection to it.
- `eth_getBlockByHash`, `eth_getTransactionReceipt`, and `eth_getBlockByNumber`: These methods are used by the `op-node` to fetch transaction data from L1. If these methods are slow, it means that sync time is bottlenecked by your L1 RPC.
## Available Metrics
A complete list of available metrics is below:
| METRIC | DESCRIPTION | LABELS | TYPE |
|-----------------------------------------------------|--------------------------------------------------------------------------------------------------|--------------|-----------|
| op_node_default_info | Pseudo-metric tracking version and config info | version | gauge |
| op_node_default_up | 1 if the op node has finished starting up | | gauge |
| op_node_default_rpc_server_requests_total | Total requests to the RPC server | method | counter |
| op_node_default_rpc_server_request_duration_seconds | Histogram of RPC server request durations | method | histogram |
| op_node_default_rpc_client_requests_total | Total RPC requests initiated by the opnode's RPC client | method | counter |
| op_node_default_rpc_client_request_duration_seconds | Histogram of RPC client request durations | method | histogram |
| op_node_default_rpc_client_responses_total | Total RPC request responses received by the opnode's RPC client | method,error | counter |
| op_node_default_l1_source_cache_size | L1 Source cache cache size | type | gauge |
| op_node_default_l1_source_cache_get | L1 Source cache lookups, hitting or not | type,hit | counter |
| op_node_default_l1_source_cache_add | L1 Source cache additions, evicting previous values or not | type,evicted | counter |
| op_node_default_l2_source_cache_size | L2 Source cache cache size | type | gauge |
| op_node_default_l2_source_cache_get | L2 Source cache lookups, hitting or not | type,hit | counter |
| op_node_default_l2_source_cache_add | L2 Source cache additions, evicting previous values or not | type,evicted | counter |
| op_node_default_derivation_idle | 1 if the derivation pipeline is idle | | gauge |
| op_node_default_pipeline_resets_total | Count of derivation pipeline resets events | | counter |
| op_node_default_last_pipeline_resets_unix | Timestamp of last derivation pipeline resets event | | gauge |
| op_node_default_unsafe_payloads_total | Count of unsafe payloads events | | counter |
| op_node_default_last_unsafe_payloads_unix | Timestamp of last unsafe payloads event | | gauge |
| op_node_default_derivation_errors_total | Count of derivation errors events | | counter |
| op_node_default_last_derivation_errors_unix | Timestamp of last derivation errors event | | gauge |
| op_node_default_sequencing_errors_total | Count of sequencing errors events | | counter |
| op_node_default_last_sequencing_errors_unix | Timestamp of last sequencing errors event | | gauge |
| op_node_default_publishing_errors_total | Count of p2p publishing errors events | | counter |
| op_node_default_last_publishing_errors_unix | Timestamp of last p2p publishing errors event | | gauge |
| op_node_default_unsafe_payloads_buffer_len | Number of buffered L2 unsafe payloads | | gauge |
| op_node_default_unsafe_payloads_buffer_mem_size | Total estimated memory size of buffered L2 unsafe payloads | | gauge |
| op_node_default_refs_number | Gauge representing the different L1/L2 reference block numbers | layer,type | gauge |
| op_node_default_refs_time | Gauge representing the different L1/L2 reference block timestamps | layer,type | gauge |
| op_node_default_refs_hash | Gauge representing the different L1/L2 reference block hashes truncated to float values | layer,type | gauge |
| op_node_default_refs_seqnr | Gauge representing the different L2 reference sequence numbers | type | gauge |
| op_node_default_refs_latency | Gauge representing the different L1/L2 reference block timestamps minus current time, in seconds | layer,type | gauge |
| op_node_default_l1_reorg_depth | Histogram of L1 Reorg Depths | | histogram |
| op_node_default_transactions_sequenced_total | Count of total transactions sequenced | | gauge |
| op_node_default_p2p_peer_count | Count of currently connected p2p peers | | gauge |
| op_node_default_p2p_stream_count | Count of currently connected p2p streams | | gauge |
| op_node_default_p2p_gossip_events_total | Count of gossip events by type | type | counter |
| op_node_default_p2p_bandwidth_bytes_total | P2P bandwidth by direction | direction | gauge |
| op_node_default_sequencer_building_diff_seconds | Histogram of Sequencer building time, minus block time | | histogram |
| op_node_default_sequencer_building_diff_total | Number of sequencer block building jobs | | counter |
| op_node_default_sequencer_sealing_seconds | Histogram of Sequencer block sealing time | | histogram |
| op_node_default_sequencer_sealing_total | Number of sequencer block sealing jobs | | counter |
docs/op-stack/src/docs/developers/opstack/public-testnets.md deleted 100644 → 0
View file @ 03012bd0
---
title: Public Testnets
lang: en-US
---
## Goerli
The Optimism Goerli testnet was migrated to Bedrock on January 12, 2023.
<table width="100%">
<tbody>
<tr>
<td colspan="2"><strong>Chain Parameters</strong></td>
</tr>
<tr>
<td>L1 Chain</td>
<td>Goerli</td>
</tr>
<tr>
<td>L1 Chain ID</td>
<td>5</td>
</tr>
<tr>
<td>L2 Chain ID</td>
<td><code>420</code></td>
</tr>
<tr>
<td>Rollup Config</td>
<td>This network does not require a rollup config. Specify <code>--network=goerli</code> on the command line
when official images are released.
</td>
</tr>
<tr>
<td>Bedrock Data Directory</td>
<td><a href="https://storage.googleapis.com/oplabs-goerli-data/goerli-bedrock.tar">https://storage.googleapis.com/oplabs-goerli-data/goerli-bedrock.tar</a>
</td>
</tr>
<tr>
<td>Legacy Geth Data Directory</td>
<td><a href="https://storage.googleapis.com/oplabs-goerli-data/goerli-legacy-archival.tar">https://storage.googleapis.com/oplabs-goerli-data/goerli-legacy-archival.tar</a>
</td>
</tr>
<tr>
<td>Block Explorer</td>
<td>
<a href="https://goerli-optimism.etherscan.io">https://goerli-optimism.etherscan.io</a>
</td>
</tr>
<tr>
<td>Public RPC Endpoint</td>
<td>
<a href="https://goerli.optimism.io">https://goerli.optimism.io</a>
</td>
</tr>
<tr>
<td>Sequencer Endpoint</td>
<td>
<a href="https://goerli-sequencer.optimism.io">https://goerli-sequencer.optimism.io</a>
</td>
</tr>
<tr>
<td>Withdrawal Period</td>
<td>2 Seconds</td>
</tr>
<tr>
<td colspan="2"><strong>Software Images</strong></td>
</tr>
<tr>
<td>op-node</td>
<td><code>us-docker.pkg.dev/oplabs-tools-artifacts/images/op-node:v0.10.9</code></td>
</tr>
<tr>
<td>op-geth</td>
<td><code>ethereumoptimism/op-geth:v1.10.26-166f27c</code></td>
</tr>
<tr>
<td>Legacy Geth</td>
<td><code>ethereumoptimism/l2geth:0.5.29</code></td>
</tr>
<tr>
<td colspan="2"><strong>Contract Addresses</strong></td>
</tr>
<tr>
<td><a href="https://goerli.etherscan.io/address/0xAe851f927Ee40dE99aaBb7461C00f9622ab91d60">SystemConfigProxy</a>
</td>
<td><code>0xAe851f927Ee40dE99aaBb7461C00f9622ab91d60</code></td>
</tr>
<tr>
<td><a href="https://goerli.etherscan.io/address/0xE6Dfba0953616Bacab0c9A8ecb3a9BBa77FC15c0">L2OutputOracleProxy</a>
</td>
<td><code>0xE6Dfba0953616Bacab0c9A8ecb3a9BBa77FC15c0</code></td>
</tr>
<tr>
<td><a href="https://goerli.etherscan.io/address/0x5b47E1A08Ea6d985D6649300584e6722Ec4B1383">OptimismPortalProxy</a>
</td>
<td><code>0x5b47E1A08Ea6d985D6649300584e6722Ec4B1383</code></td>
</tr>
<tr>
<td><a href="https://goerli.etherscan.io/address/0x883dcF8B05364083D849D8bD226bC8Cb4c42F9C5">OptimismMintableERC20FactoryProxy</a>
</td>
<td><code>0x883dcF8B05364083D849D8bD226bC8Cb4c42F9C5</code></td>
</tr>
<tr>
<td><a href="https://goerli.etherscan.io/address/0x1f0613A44c9a8ECE7B3A2e0CdBdF0F5B47A50971">SystemDictatorProxy</a>
</td>
<td><code>0x1f0613A44c9a8ECE7B3A2e0CdBdF0F5B47A50971</code></td>
</tr>
<tr>
<td>
<a href="https://goerli.etherscan.io/address/0xa6f73589243a6A7a9023b1Fa0651b1d89c177111">Lib_AddressManager</a>
</td>
<td>
<code>0xa6f73589243a6A7a9023b1Fa0651b1d89c177111</code>
</td>
</tr>
<tr>
<td>
<a href="https://goerli.etherscan.io/address/0x5086d1eEF304eb5284A0f6720f79403b4e9bE294">Proxy__OVM_L1CrossDomainMessenger</a>
</td>
<td>
<code>0x5086d1eEF304eb5284A0f6720f79403b4e9bE294</code>
</td>
</tr>
<tr>
<td>
<a href="https://goerli.etherscan.io/address/0x636Af16bf2f682dD3109e60102b8E1A089FedAa8">Proxy__OVM_L1StandardBridge</a>
</td>
<td>
<code>0x636Af16bf2f682dD3109e60102b8E1A089FedAa8</code>
</td>
</tr>
</tbody>
</table>
\ No newline at end of file
docs/op-stack/src/docs/developers/opstack/upgrade-guide.md deleted 100644 → 0
View file @ 03012bd0
---
title: Upgrade Guide
lang: en-US
---
::: warning This guide is for bedrock
This guide is for the *bedrock* upgrade, which is coming in Q1, 2023, subject to approval by Optimism governance.
Do not attempt to use this in production prior to that upgrade. Keep an eye on these docs or [our official Twitter](https://twitter.com/OPLabsPBC) for announcements.
:::
This document provides an overview of how the Bedrock upgrade will be executed and how it will impact node operators and dApp developers.
## Upgrade Overview
Unlike previous upgrades, the Bedrock upgrade will not be a "regenesis" event where historical transaction data is lost and the chain resets at block zero. Instead, the Bedrock upgrade will resemble a hard fork where the new Bedrock chain will be a continuation of the old one. This ensures that the upgrade is as seamless as possible.
The upgrade will proceed as follows on upgrade day:
1. Deposits and withdrawals on the legacy network will be paused.
2. Transactions on the legacy sequencer will no longer be accepted.
3. The smart contracts on L1 will be upgraded and an irregular state transition on L2 will be performed.
4. The Bedrock sequencer will start up.
5. Deposits and withdrawals will be re-enabled.
6. The contract addresses, binaries, and data directories required to interact with the new system will be distributed.
Backwards compatibility is one of the upgrade's key design goals.
Potential incompatibilities and their workarounds are highlighted in the sections below.
## Optimism Mainnet Upgrade
The Bedrock upgrade to the Optimism Mainnet Network is yet to be scheduled.
We plan to announce an official date and time in February 2023 at least 3 weeks in advance of the upgrade, subject to approval by Optimism governance.
## For Node Operators
:::tip Prerequisites
This section assumes that you have read and understood our [Node Operator Guide](./node-operator-guide.md). Please read that first if you haven't already.
:::
From a node operator perspective, the old system will be completely _replaced_ on upgrade day. This means that rather than upgrading legacy infrastructure, node operators will be standing up entirely new infrastructure to run the Bedrock network.
On upgrade day, we will provide node operators with the following information:
1. The correct `op-node` and `op-geth` images and binaries to use.
2. A URL to an upgraded data directory containing the genesis state for the new system.
3. A URL to a legacy data directory containing data for Legacy Geth.
4. A set of bootnodes to use as part of the peer-to-peer network.
We will embed the rollup config into the `op-node` itself. Then, on upgrade day, you will need to:
1. Initialize `op-geth`'s data directory using the upgraded genesis state from the provided URL. See the [Initialization via Data Directory](./node-operator-guide.md#initialization-via-data-directory) section of the Node Operator Guide for more information.
2. Specify the `op-node`'s network via the `--network` flag or `OP_NODE_NETWORK` environment variable. Its value will be `goerli` for the Goerli upgrade, or `mainnet` for the mainnet upgrade.
3. Initialize Legacy Geth's data directory using the legacy genesis state from the provided URL. See the [Initialization via Data Directory](./node-operator-guide.md#initialization-via-data-directory) and [Legacy Geth](./node-operator-guide.md#legacy-geth) sections of the Node Operator Guide for more information.
4. Set the `op-geth` `--rollup.historicalrpc` parameter to point to Legacy Geth's RPC endpoint.
5. Start `op-geth` and `op-node` as usual.
The best way to prepare for the upgrade is to participate in one of our public testnets. Please see the [public testnets](./public-testnets.md) page for how to connect to our testnet.
## For dApp and Wallet Developers
On upgrade day, deposits and withdrawals will be paused, along with ingress on the sequencer. This means that all transactions on Optimism will be halted for the duration of the upgrade.
Once the upgrade is complete, everything should be identical to how it was before the upgrade. All balances, contract addresses, transaction data, block data, and historical execution traces will be preserved. The new network is EVM-equivalent, so all existing Ethereum tooling will continue to work with the new system. Differences are described in [How is Bedrock Different?](./how-is-bedrock-different.md).
## FAQs
### When is the upgrade taking place?
The Goerli upgrade is tentatively scheduled for January 2023. The mainnet upgrade is tentatively scheduled for February 2023. The Goerli upgrade will be live for at least a month before the mainnet upgrade.
### Is this a hard fork, or a new network?
This is a hard fork. The network will retain the same chain ID, transaction history, and state. The first block of the new network will be the last block of the new network + 1.
### How long will the upgrade take?
We expect the upgrade to take less than 4 hours.
### How can I best prepare for the upgrade?
The best way to prepare for the upgrade is to participate in one of our public testnets. Please see the [Beta Testnet](https://www.notion.so/External-Optimism-Bedrock-Beta-Testnet-454a37e469af4658b89a9d766334e331) page for how to connect to our current testnet.
### Why is Legacy Geth necessary?
The upgraded data directory used to initialize `op-geth` contains the current state of the network as well as all historical block, transaction, and receipt data. However, providing historical execution would require bundling the legacy system's EVM implementation with `op-geth`. In an effort to keep our diff between `op-geth` and upstream `go-ethereum` small, we instead route requests for historical execution traces to Legacy Geth which already contains the correct execution engine.
You only need to run Legacy Geth if you need historical execution traces.
### What version of upstream Geth is op-geth based off of?
`op-geth` is currently based off of the `1.10.x` version of `go-ethereum`.
`op-geth` is periodically updated include the latest upstream changes.
### How can I see the difference between upstream Geth and op-geth?
A single-commit diff is maintained in the `op-geth` repository. See [here](https://github.com/ethereum-optimism/op-geth/compare/master...optimism) for the comparison.
### Will transaction tracing for post-Bedrock data be faster?
Yes. `op-geth` uses the latest transaction tracers from upstream, which have much better performance than tracers legacy `l2geth` uses.
\ No newline at end of file
docs/op-stack/src/docs/developers/releases.md deleted 100644 → 0
View file @ 03012bd0
---
title: Releases
lang: en-US
---
## Our release cycle
Optimism releases new software every Tuesday and Thursday at 7PM UTC.
Software is released on Goerli first, followed by mainnet a week later.
## Up to date information
* [Changelog](https://changelog.optimism.io/)
* [Release announcement mailing list](https://groups.google.com/a/optimism.io/g/optimism-announce)
* [RSS feed](https://changelog.optimism.io/feed.xml)
If you [run your own replica](build/run-a-node.md), it is important that you subscribe either to the release announcement mailing list or the RSS feed to know when you need to upgrade.
docs/op-stack/src/docs/how-optimism-works/README.md deleted 100644 → 0
View file @ 03012bd0
---
title: How Optimism works
lang: en-US
---
Here you can see the [design philosophy](design-philosophy.md) for Optimism, as well as the [rollup protocol](rollup-protocol.md).
docs/op-stack/src/docs/how-optimism-works/design-philosophy.md deleted 100644 → 0
View file @ 03012bd0
---
title: Design Philosophy
lang: en-US
---
Optimism is built according to a strong design philosophy that stands on four main pillars: simplicity, pragmatism, sustainability, and, of course, optimism.
It's important to understand these pillars as they heavily influence the design of Optimism as a whole.
## Simplicity
Optimism is designed to be as simple as possible for the featureset it provides.
Ideally, Optimism should be composed of the minimum number of moving parts required for a secure, scalable, and flexible L2 system.
This simplicity gives Optimism's design a number of significant advantages over other more complex L2 constructions.
Simplicity reduces engineering overhead, which in turn means we can spend our time working on new features instead of re-creating existing ones.
Optimism prefers to use existing battle-tested Ethereum code and infrastructure where possible.
The most visible example of this philosophy in practice is the choice to use Geth as Optimism's client software.
When dealing with critical infrastructure, simplicity is also security.
Every line of code we write is an opportunity to introduce unintentional bugs.
A simple protocol means there's less code to write and, as a result, less surface area for potential mistakes.
A clean and minimal codebase is also more accessible to external contributors and auditors.
All of this serves to maximize the security and correctness of the Optimism protocol.
Simplicity is also important for the long-term vision of Optimism.
By limiting the amount of code that we write on top of Ethereum tooling, we're able to spend most of our time working directly with existing codebases.
Engineering effort that goes into Optimism can also directly benefit Ethereum, and vice versa.
This will only become more pronounced as the Optimism protocol solidifies and existing resources can be redirected towards core Ethereum infrastructure.
## Pragmatism
For all its idealism, the design process behind Optimism is ultimately driven by pragmatism.
The core Optimism team has real-world constraints, the projects that build on Optimism have real-world needs, and the users that engage with Optimism have real-world problems.
Optimism's design philosophy prioritizes user and developer needs over theoretical perfection.
Sometimes the best solution isn't the prettiest one.
Optimism is also developed with the understanding that any core team will have limited areas of expertise.
Optimism is developed iteratively and strives to continously pull feedback from users.
Many core Optimism features today (like [EVM Equivalence](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306)) were only made possible by this iterative approach to protocol development.
## Sustainability
Optimism is in it for the long haul.
Application developers need assurance that the platform they're building on will remain not only operational but competitive over long periods of time.
Optimism's design process is built around the idea of long-term sustainability and not taking shortcuts to scalability.
At the end of the day, a scalable system means nothing without the ecosystem that sustains it.
Sustainability actively influences Optimism's protocol design in ways that go hand-in-hand with our philosophy of simplicity.
The more complex a codebase, the more difficult it is for people outside of the core development team to actively contribute.
By keeping our codebase simple we're able to build a bigger community of contributors who can help maintain the protocol long-term.
## Optimism
Of course, none of this would be possible without a sense of optimism.
Our optimism about the Ethereum vision keeps this project moving forward.
We believe in an optimistic future for Ethereum, a future where we get to redesign our relationships to the institutions that coordinate our lives.
Although Optimism looks like a standalone blockchain, it's ultimately designed as an extension to Ethereum.
We keep this in mind whenever we're creating new features or trying to simplify existing ones.
Optimism is as close to Ethereum as possible not only for pragmatic reasons, but because Optimism exists so that Ethereum can succeed.
We hope that you can see the influence of this philosophy when looking at Optimism's design.
docs/op-stack/src/docs/how-optimism-works/rollup-protocol.md deleted 100644 → 0
View file @ 03012bd0
---
title: Rollup Protocol
lang: en-US
---
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.
## 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 take advantage of the consensus mechanism (like PoW or PoS) of their parent chain instead of providing their own.
In Optimism's case this parent blockchain is Ethereum.
<div align="center">
<img width="400" src="../../assets/docs/how-optimism-works/1.png">
</div>
## Block storage
In Bedrock L2 blocks are saved to the Ethereum blockchain using a non-contract address ([`0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0001`](https://etherscan.io/address/0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0001)), to minimize the L1 gas expense.
As these blocks are submitted as transaction calldata on Ethereum, 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 Optimism inherits the availability and integrity guarantees of Ethereum.
Blocks are written to L1 in [a compressed format](https://github.com/ethereum-optimism/optimism/blob/develop/specs/derivation.md#batch-submission-wire-format) to reduce costs.
This is important because writing to L1 is [the major cost of Optimism transactions](../developers/build/transaction-fees.md).
## Block production
Optimism block production is primarily managed by a single party, called the "sequencer," which helps the network by providing the following services:
- Providing transaction confirmations and state updates.
- Constructing and executing L2 blocks.
- 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.
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* whether they have assets attached or not) 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.
This provides Optimism with L1 Ethereum level censorship resistance.
You can read more about this mechanism [is the protocol specifications](https://github.com/ethereum-optimism/optimism/blob/develop/specs/derivation.md#deriving-the-transaction-list).
1. Transactions submitted directly to the sequnecer.
These transactions are a lot cheaper to submit (because you do not need the expense of a separate L1 transaction), but of course they cannot be made censorship resistant, because the sequencer is the only entity that knows about them.
For the moment, [The Optimism Foundation](https://www.optimism.io/) runs the only block producer. Refer to [Protocol specs](../protocol/README.md) section for more information about how we plan to decentralize the Sequencer role in the future.
## Block execution
The execution engine (implemented as the `op-geth` component) receive 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.
You can read more about it [in the specs](https://github.com/ethereum-optimism/optimism/blob/develop/specs/exec-engine.md#happy-path-sync).
1. The rollup node (implemented as the `op-node` component) derives the L2 blocks from L1.
This mechanism is slower, but censorship resistant.
You can read more about it [in the specs](https://github.com/ethereum-optimism/optimism/blob/develop/specs/exec-engine.md#worst-case-sync).
## Bridging assets between layers
Optimism is designed so that users can send arbitrary messages between smart contracts on Optimism and Ethereum.
This makes it possible to transfer assets, 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.
Optimism uses this functionality in the Standard bridge to allow users to deposit assets (ERC20s and ETH) from Ethereum to Optimism and also allow withdrawals of the same from Optimism back to Ethereum.
See the [developer documentation and examples](../developers/bridge/standard-bridge/) on details on the inner workings of the Standard bridge.
### Moving from Ethereum to Optimism
In Optimism terminology, transactions going from Ethereum (L1) to Optimism (L2) are called *deposits*, even if they do not have any assets attached to them.
You use [`L1CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism-tutorial/tree/main/cross-dom-comm) or [`L1StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/contracts/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://github.com/ethereum-optimism/optimism/blob/develop/specs/deposits.md).
### Moving from Optimism to Ethereum
Withdrawals (the term is used for any Optimism to Ethereum message, regardless of whether it has attached assets or not) have three stages:
1. You initialize withdrawals with an L2 transaction.
1. Wait for the next output root to be submitted to L1 (you can see this on [the SDK](../sdk/js-client.md)) and then submit the withdrawal proof using `proveWithdrawalTransaction`.
This new step enables off-chain monitoring of the withdrawals, which makes it easier to identify incorrect withdrawals or output roots.
This protects Optimism users against a whole class of potential bridge vulnerabilities.
1. After the fault challenge period ends (a week on mainnet, less than that on the test network), finalize the withdrawal.
[You can read the full withdrawal specifications here](https://github.com/ethereum-optimism/optimism/blob/develop/specs/withdrawals.md)
## Fault proofs
In an Optimistic Rollup, state commitments are published to Ethereum 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 Optimism 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://github.com/ethereum-optimism/optimistic-specs/discussions/53)) 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 Optimism itself, only the published commitments about the state of the chain.
The ordering of transactions and the state of Optimism is unchanged by a fault proof challenge.
The fault proof process is currently undergoing major redevelopment as a side-effect of the November 11th [EVM Equivalence](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) update.
You can read more about this process within the [Protocol specs](../protocol/README.md) section of this website.
docs/op-stack/src/docs/protocol/README.md deleted 100644 → 0
View file @ 03012bd0
---
title: Protocol specs
lang: en-US
---
With the OVM 2.0 upgrade, which happened on November 11th, 2021, the Optimism protocol went through its biggest upgrade to date. The primary focus of this upgrade was [EVM Equivalence](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), a new design for Optimism that brought it close to 1:1 parity with Ethereum. For a high level overview of the current protocol version, see ['How Optimism works'](./2-rollup-protocol.md) section.
## Roadmap
Below is a brief summary of some of the planned [Optimism roadmap](https://www.optimism.io/about) releases.
## Next gen fault proofs
As part of the OVM 2.0 upgrade, the **Optimism fault proof mechanism had to be temporarily disabled**. This means that users of the Optimism network currently need to trust the Sequencer node (run by Optimism PBC) to publish valid state roots to Ethereum. **You can read more about our security model [here](../security-model/optimism-security-model.md)**.
We're making progress on the upgrade fault proof mechanism and we expect to productionize our work in 2022. You can keep up with developments in the [Cannon repository](https://github.com/ethereum-optimism/cannon/).
## Decentralizing the sequencer
Currently, Optimism runs the sole sequencer on Optimism. This does not mean that Optimism can censor user transactions. However, it is still desirable to decentralize the sequencer over time, eliminating Optimism's role entirely so that anyone can participate in the network as a block producer.
The first step to decentralizing the sequencer is to still have one sequencer at a time, but rotate that sequencer with some frequency. The precise mechanic for sequencer rotation is not yet finalized, but will involve two components:
- an **economic mechanism** which creates a competitive market for sequencing, and redirects excess sequencer profits [towards protocol development](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c).
- a **governance mechanism** which prevents sequencers from prioritizing short-term profits over the long-term health of the network.
After this, the next step is to support multiple concurrent sequencers. This can be simply achieved by adopting a standard BFT consensus protocol, as used by other L1 protocols and sidechains like Polygon and Cosmos.
You can keep up with the roadmap progress in [Cannon repository](https://github.com/ethereum-optimism/cannon/) for the fault proofs and [Optimism specs repository](https://github.com/ethereum-optimism/optimistic-specs) for the overall protocol work.
\ No newline at end of file
docs/op-stack/src/docs/protocol/contract-overview.md deleted 100644 → 0
View file @ 03012bd0
This diff is collapsed.
docs/op-stack/src/docs/releases/README.md 0 → 100644
View file @ 0a83d43b
---
title: Releases
lang: en-US
---
The OP Stack is a decentralized development stack maintained by the Optimism Collective and built to power Optimism.
The OP Stack is constantly evolving as new layers and modules are developed. The OP Stack is also not a product (in the traditional sense) but rather a collection of software components that power the Optimism ecosystem.
**A “Release” of the OP Stack is a particular set of software components that are production-ready and which fit the stack’s design principles and goals.**
Only the software components included within the Current Release of the OP Stack are considered in the scope of the OP Stack. Anything usage of the OP Stack outside of the official, intended capabilities of the Current Release are considered [OP Stack Hacks](../build/hacks.md) — unofficial modifications that are useful for experimentation but could have unforeseen results, such as security vulnerabilities, and are likely cause your chain to no longer be interoperable with the Optimism Superchain (link). **Developer support for OP Stack Hacks is limited — when in doubt, stick to the capabilities of the Current Release!**
## Current Release
[OP Stack V1: Bedrock](./bedrock.md)
## Past Releases
N/A
\ No newline at end of file
docs/op-stack/src/docs/releases/bedrock.md 0 → 100644
View file @ 0a83d43b
---
title: OP Stack V1 - Bedrock
lang: en-US
---
## Overview
The first release of the OP Stack is called **Bedrock**.
The Bedrock release primarily consists of the core software required to run L2 blockchains and was originally designed to power an upgrade to the Optimism Mainnet network.
## Resources
### Rollup Protocol
Learn about the basics of the Rollup protocol used by Bedrock on the Rollup Protocol page.
### Bedrock Explainer
Learn all about the Bedrock release of the OP Stack by reading the Bedrock Explainer.
### Specifications
Dive deep into the specifications for the Bedrock release in the [specs folder of the Optimism Monorepo](https://github.com/ethereum-optimism/optimism/blob/develop/specs/README.md).
## Components
- [`op-node`](https://github.com/ethereum-optimism/optimism/tree/develop/op-node)
- [`op-geth`](https://github.com/ethereum-optimism/op-geth)
- [`op-batcher`](https://github.com/ethereum-optimism/optimism/tree/develop/op-batcher)
- [`op-proposer`](https://github.com/ethereum-optimism/optimism/tree/develop/op-proposer)
- [`contracts-bedrock`](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock)
- [`fault-detector`](https://github.com/ethereum-optimism/optimism/tree/develop/packages/fault-detector)
- [`sdk`](https://github.com/ethereum-optimism/optimism/tree/develop/packages/sdk)
- [`chain-mon`](https://github.com/ethereum-optimism/optimism/tree/develop/packages/chain-mon)
\ No newline at end of file
docs/op-stack/src/docs/releases/releases.md 0 → 120000
View file @ 0a83d43b
README.md
\ No newline at end of file
docs/op-stack/src/docs/security-model/README.md deleted 100644 → 0
View file @ 03012bd0
---
title: Optimism's Security Model
lang: en-US
---
Security in crypto is vital. Users, developers and infrastructure providers expect the code to work as intended. When it doesn't, these same groups (rightfully) demand a fast, secure, and clearly communicated fix.
Over the years at Optimism we have learned a great deal about this delicate balance, and the importance of transparency around security models. It is not good enough to just be transparent, it also needs to be accessible. If the average user cannot understand your security model then it does not matter how transparent it is.
In line with this philosophy of transparency we have a very accessible run down of [Optimism's security model](./optimism-security-model.md) that anyone can understand.
We also have a long standing [bug bounty program](./bounties.md) that has paid out one of the largest open source software bounties ever!
We take your trust very seriously and we are super excited to have you along for our decentralisation journey.
\ No newline at end of file
docs/op-stack/src/docs/security-model/bounties.md deleted 100644 → 0
View file @ 03012bd0
---
title: Bug Bounties
lang: en-US
---
## Optimism Bug Bounty Program
Optimism takes security seriously and as such, we have a massive bug bounty program. We don't just talk about it either! We have given out one of the [largest bounty payouts ever](https://medium.com/ethereum-optimism/disclosure-fixing-a-critical-bug-in-optimisms-geth-fork-a836ebdf7c94)! You can read more about that bug [here](https://www.saurik.com/optimism.html). Below are the various bug bounty programs we have, as well as how to reach out to us if your bug is not covered by an existing bounty.
### Main Bounty Page
Optimism has a very detailed [Bug bounty Page on Immunefi](https://immunefi.com/bounty/optimism/). In the listing you can find all the information relating to assets in scope, reporting, and the payout process.
### Bedrock Bounty
With our upcoming launch of [Bedrock](../developers/bedrock/how-is-bedrock-different.md) we will be launching a specific bug bounty program. Follow our [Twitter](https://twitter.com/optimismFND) or keep an eye on [Immunefi](https://immunefi.com/bounty/optimism/) for more information.
### Unscoped Bug
If you think you have found a critical or major bug that is not covered by our existing bug bounty, please report it to us via the Immunefi program regardless. We will seriously consider the impact of any issues, and have previously rewarded security researchers for bugs not within the stated scope of the program.
\ No newline at end of file
docs/op-stack/src/docs/security-model/optimism-security-model.md deleted 100644 → 0
View file @ 03012bd0
---
title: Optimism's Security Model
lang: en-US
---
The Optimism blockchain is a work in progress.
Constantly pushing to improve the security guarantees that users have while using Optimism is a top priority.
At the moment, **it’s important to understand that the security of the Optimism blockchain is dependent on a [multisig wallet](https://www.coindesk.com/tech/2020/11/10/multisignature-wallets-can-keep-your-coins-safer-if-you-use-them-right/)** managed by several anonymous individuals.
This multisig wallet can be used to upgrade core Optimism smart contracts without upgrade delays.
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 assets held within the system.
[Optimism’s smart contract codebase has been audited repeatedly](https://github.com/ethereum-optimism/optimism/tree/develop/technical-documents/audits) 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 Optimism inherently exposes you to the risk of bugs within the Optimism codebase.
## Security Model FAQ
### Does Optimism have fault proofs?
**No**, Optimism does not currently have fault proofs.
**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, such as Optimism, is fully dependent on the upgrade keys for security.
Optimism’s goal is to be the first system that deploys fault proofs that can secure the system by themselves, without fast upgrade keys.
### Who manages the multisig?
The multisig is managed by an anonymous set of individuals.
Members are anonymous in order to make the multisig more difficult to compromise.
### How is Optimism planning to remove the multisig?
Check out Optimism’s detailed [Pragmatic Path to Decentralization](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 Optimism the first chain with true fault proof security.
### How can I help make Optimism more secure?
[Optimism 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 Optimism codebase.
You can also [run your own verifier node](https://github.com/smartcontracts/simple-optimism-node/) to detect network faults.
docs/op-stack/src/docs/security/README.md 0 → 100644
View file @ 0a83d43b
---
title: Security FAQs
lang: en-US
---
::: warning 🚧 Work in Progress
The OP Stack is a work in progress. Constantly pushing to improve the overall security and decentralization of the OP Stack is a top priority.
:::
## Security in the decentralized context
The OP Stack is a decentralized development stack that powers Optimism. Components of the OP Stack may be maintained by various different teams within the Optimism Collective. It is generally easier to talk about the security model of specific chains built on the OP Stack rather than the security model of the stack itself. **The OP Stack security baseline is to create safe defaults while still giving developers the flexibility to make modifications and extend the stack.**
## FAQ
### Is every OP Stack chain safe?
The security model of an OP Stack based blockchain depends on the modules used for its components. Because of the flexibility provided by OP Stack, it is always possible to set up an insecure blockchain using OP Stack components. **The goal of the OP Stack is to provide safe defaults.**
Please also keep in mind that just like any other system, **the OP Stack may contain unknown bugs** that could lead to the loss of some or all of the assets held within an OP Stack based system. [Many components of the OP Stack codebase have been audited](https://github.com/ethereum-optimism/optimism/tree/develop/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 the OP Stack inherently exposes you to the risk of bugs within the OP Stack codebase.
### Is the OP Stack safe to modify?
As with anything, modify the OP Stack at your own risk. There is no guarantee that modifications to the stack will be safe. If you aren’t entirely sure about what you’re doing, stick with the safer defaults that the OP Stack provides. At the moment, the OP Stack is not particularly amenable to modifications and **you should not expect any technical support for modifications that fall outside of the standard Rollup configuration of the stack**.
### 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.
Fault proofs are a key roadmap item 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. [Optimism 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 Optimism Mainnet 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](../understand/design-principles.md). 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.
### Where do I report bugs?
[See here](./policy.md)
\ No newline at end of file
docs/op-stack/src/docs/security/faq.md 0 → 120000
View file @ 0a83d43b
README.md
\ No newline at end of file
docs/op-stack/src/docs/security/policy.md 0 → 100644
View file @ 0a83d43b
---
title: Security Policy, Vulnerability Reporting, and Bug Bounties
lang: en-US
---
## Reporting in the decentralized context
It's important to remember that the OP Stack is a decentralized software development stack built by the Optimism Collective. Different components of the OP Stack may be maintained by different teams that have different reporting processes. **This page describes general best practices for reporting bugs and provides specific reporting guidelines for the OP Stack code contained within the [ethereum-optimism](https://github.com/ethereum-optimism) GitHub organization**.
## Reporting bugs and vulnerabilities
::: danger 🚫 How NOT to disclose a vulnerability
Do *not* disclose vulnerabilities publicly or by executing them against a production network. If you do, will you not only be putting users at risk, but you will forfeit your right to a reward. Always follow the appropriate reporting pathways as described below.
- Do *not* disclose the vulnerability publicly, for example by filing a public ticket.
- Do *not* test the vulnerability on a publicly available network, either the testnet or the mainnet.
:::
### OP Stack bounty programs
The security of OP Stack smart contracts and blockchain infrastructure is paramount. Below are the various OP Stack-related bug bounty programs, as well as how to reach out if your bug is not covered by an existing bounty.
#### Optimism Mainnet bounty program
Optimism Mainnet is covered by a comprehensive [bug bounty program on Immunefi](https://immunefi.com/bounty/optimism/), which has already resulted in one of the [largest bounty payouts ever](https://medium.com/ethereum-optimism/disclosure-fixing-a-critical-bug-in-optimisms-geth-fork-a836ebdf7c94). In the listing you can find all the information relating to assets in scope, reporting, and the payout process. Because Optimism Mainnet is currently the primary user of the OP Stack, bugs in OP Stack software can generally be reported via the Optimism Mainnet bounty program.
#### Unscoped bugs
If you think you have found a significant bug or vulnerabilities in OP Stack smart contracts, infrastructure, etc., even if that component is not covered by an existing bug bounty, please report it to via the [Optimism Mainnet Immunefi program](https://immunefi.com/bounty/optimism/). The impact of any and all reported issues will be considered and the program has previously rewarded security researchers for bugs not within its stated scope.
### Other vulnerabilities
For vulnerabilities in any websites, email servers, or other non-critical infrastructure within the OP Stack, please email [OP Labs](https://www.oplabs.co/) at [security@oplabs.co](mailto:security@oplabs.co) and include detailed instructions for confirming and reproducing the vulnerability.
## Vulnerability disclosure
Each OP Stack component maintainer may determine its own process for vulnerability disclosure. However, the following describes a recommended process for disclosure that is currently in use by [OP Labs](https://www.oplabs.co/).
In the event that an OP Stack component maintainer learns of a critical security vulnerability, the maintainer reserves the right to silently fix it without immediately publicly disclosing the existence of nature of the vulnerability.
In such a scenario, the disclosure process used by [OP Labs](https://www.oplabs.co/) is as follows:
1. Silently fix the vulnerability and include the fix in release X.
1. After 4-8 weeks, disclose that release X contained a security fix.
1. After an additional 4-8 weeks, publish details of the vulnerability, along with credit to the reporter (with express permission from the reporter).
Alongside this policy, maintainers also reserve the right to:
- Bypass this policy and publish details on a shorter timeline.
- Directly notify a subset of downstream users prior to making a public announcement.
This policy is based the [Geth](https://geth.ethereum.org/) team’s [silent patch policy](https://geth.ethereum.org/docs/vulnerabilities/vulnerabilities#why-silent-patches).
\ No newline at end of file
docs/op-stack/src/docs/understand/README.md 0 → 100644
View file @ 0a83d43b
---
title: Introduction to the OP Stack
lang: en-US
---
**The OP Stack is the standardized, shared, and open-source development stack that powers Optimism, maintained by the Optimism Collective.**
The OP Stack consists of the many different software components managed and maintained by the Optimism Collective that, together, form the backbone of Optimism.
The OP Stack is built as a public good for the Ethereum and Optimism ecosystems.
## The OP Stack powers Optimism
The OP Stack is the set of software that powers Optimism — currently in the form of the software behind Optimism Mainnet 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.
By coordinating on shared standards, the Optimism Collective can avoid rebuilding the same software in silos repeatedly.
Although the OP Stack today significantly simplifies the process of creating L2 blockchains, it’s important to note that this does not fundamentally define what the OP Stack **is**.
The OP Stack is *all* of the software that powers Optimism.
As Optimism evolves, so will the OP Stack.
**The OP Stack can be thought of as software components that either help define a specific layer of the Optimism ecosystem or fill a role as a module within an existing layer**
Although the current heart of the OP Stack is infrastructure for running L2 blockchains, the OP Stack theoretically extends to layers on top of the underlying blockchain including tools like block explorers, message passing mechanisms, governance systems, and more.
Layers are generally more tightly defined towards the bottom of the stack (like the Data Availability Layer) but become more loosely defined towards the top of the stack (like the Governance Layer).
## The OP Stack today
Optimism Bedrock is the current iteration of the OP Stack.
The Bedrock release provides the tools for launching a production-quality Optimistic Rollup blockchain.
At this point in time, the APIs for the different layers of the OP Stack are still tightly coupled to this Rollup configuration of the stack.
If you'd like to learn more about the current state of the OP Stack, check out [the page describing the Bedrock release](../releases/bedrock.md).
The OP Stack of today was built to support the Optimism Superchain (link), a proposed network of L2s that share security, communication layers, and a common development stack (the OP Stack itself).
The Bedrock release of the OP Stack makes it easy to spin up an L2 that will be compatible with the Superchain when it launches.
If you'd like to launch a Superchain-ready L2, check out our guide for running a chain based on the Bedrock release of the OP Stack.
It is possible to modify components of the OP Stack to build novel L2 systems.
If you're interested in experimenting with the OP Stack, check out [the OP Stack Hacks section of this site](../build/hacks.md).
Please note that, as of the Bedrock release, the OP Stack is *not* designed to support these modifications and you will very much be *hacking* on the codebase.
As a result, **you should, for the moment, expect limited (if any) developer support for OP Stack Hacks.**
OP Stack Hacks will likely make your chain incompatible with the Optimism Superchain.
Have fun, but at your own risk and **stick to the Bedrock release if you're looking to join the Superchain!**
## The OP Stack tomorrow
The OP Stack is an evolving concept.
As Optimism grows, so will the OP Stack.
Today, the Bedrock Release of the OP Stack simplifies the process of deploying new L2 Rollups.
As work on the stack continues, it should become easier to plug in and configure different modules.
As the Superchain (link) begins to take shape, the OP Stack can evolve alongside it, to include the message-passing infrastructure that allows different chains to interoperate seamlessly.
At the end of the day, the OP Stack becomes what Optimism needs.
## Dive Deeper into the OP Stack
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.md) and [Landscape Overview](./landscape.md).
- If you're excited to join the Superchain, launch your first Superchain-ready L2 with our [Getting Started guide](../build/getting-started.md) or dive directly into the OP Stack codebase to learn more.
The OP Stack is the next frontier for Ethereum. You’re already here, so what are you waiting for?
\ No newline at end of file
docs/op-stack/src/docs/understand/design-principles.md 0 → 100644
View file @ 0a83d43b
---
title: Design Principles for USEful Software
lang: en-US
---
::: tip The OP Stack is USEful software
The OP Stack is a set of software components for building L2 blockchain ecosystems, built by the Optimism Collective to power Optimism.
Components to be added to the OP Stack should be built according to three key design principles:
- **U**tility
- **S**implicity
- **E**xtensibility.
Software that follows these principles is **USE**ful software for the Optimism Collective!
:::
## Utility
For something to be part of the OP Stack, it should help power the Optimism Collective.
This condition helps guide the type of software that can be included in the stack.
For instance, a powerful open-source block explorer that makes it easier for users to inspect the Superchain would be a great addition to the OP Stack.
Although utility is important for inclusion in the OP Stack, you shouldn’t be afraid to experiment.
Do something crazy.
Build something that’s never been built before, even if it doesn’t have any clear utility. Make a blockchain for Emojis, or whatever. Have fun!
## Simplicity
Complex code does not scale.
Code that makes it into the OP Stack should be simple.
Simplicity reduces engineering overhead, which in turn means the Collective can spend its time working on new features instead of re-creating existing ones.
The OP Stack prefers to use existing battle-tested code and infrastructure where possible.
The most visible example of this philosophy in practice is the choice to use Geth as the OP Stack’s default execution engine.
When dealing with critical infrastructure, simplicity is also security and maintainability.
Every line of code written is an opportunity to introduce bugs and vulnerabilities.
A simple protocol means there's less code to write and, as a result, less surface area for potential mistakes.
A clean and minimal codebase is also more accessible to external contributors and auditors.
All of this serves to maximize the security and correctness of the OP Stack.
## Extensibility
Good OP Stack code is inherently open, collaborative, and extensible.
Collaboration allows us to break out of siloed development.
Collaboration allows us spend more time building on top of one another's work and less time rebuilding the same components over and over again.
Collaboration is how we win, *together*.
Extensible code should be designed with the mindset that others will want to build with and on top of that code.
In practice, this means that the code should be open source (under a permissive license), expose clean APIs, and generally be modular such that another developer can relatively easily extend the functionality of the code.
Extensibility is a key design principle that unlocks the superpower of collaboration within the Optimism Collective ecosystem.
## Contributing to the OP Stack
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 of these docs](../CONTRIB.md).
Of course, software that has impact for the Optimism Collective can receive Retroactive Public Goods Funding.
Build for the OP Stack — get rewarded for writing great open source software. What's not to love?
\ No newline at end of file
docs/op-stack/src/docs/understand/intro.md 0 → 120000
View file @ 0a83d43b
README.md
\ No newline at end of file
docs/op-stack/src/docs/understand/landscape.md 0 → 100644
View file @ 0a83d43b
This diff is collapsed.
docs/op-stack/src/docs/useful-tools/README.md deleted 100644 → 0
View file @ 03012bd0
---
title: Developer tools
lang: en-US
---
Welcome to the Optimism developer tools!
If you are already familiar with [building on Optimism](../developers/README.md) and just need the tools to get cracking, you are in the right place!
## Connecting
You have the list of [networks](./networks.md) and [node providers](./providers.md) to help you connect to an Optimism node.
## Deploying
To get some ETH bridged over for deployment gas fees, use one of the available [faucets](./faucets.md) or just bridge ETH using the [Optimism Gateway](https://gateway.optimism.io/).
## Monitoring
Your app is live in production? Watch it grow using one of the [monitoring tools](./monitoring.md). We also have a set of [troubleshooting tools](./debugging.md) and [block explorers](./explorers.md) to help you provide a stellar service to your users.
docs/op-stack/src/docs/useful-tools/debugging.md deleted 100644 → 0
View file @ 03012bd0
---
title: Transaction Debugging Tools
lang: en-US
---
::: tip EVM Equivalence
As Optimism is [EVM Equivalent](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), most debugging tools work out the box with Optimism.
:::
## Tenderly
[Tenderly](https://tenderly.co/) lets you inspect any transaction execution on the Optimism mainnet.
You can inspect the state of your verified contract in any step of the transactions execution, as well as step into or over function calls.
## Etherscan
[Etherscan](https://explorer.optimism.io) allows you to see events as well as revert messages for transactions that have been mined on Optimism (mainnet) as well as [Optimism Goerli (testnet)](https://goerli-explorer.optimism.io).
You can see more information about all the L2 features Etherscan offers in our [Explorers page](./explorers.md#etherscan).
## Blockscout
[Blockscout](https://blockscout.com/optimism/goerli/) allows you to see events on our Goerli testnet.
## Know other good tools?
Reach out to us in our [Discord](https://discord-gateway.optimism.io) or [make a PR](https://github.com/ethereum-optimism/community-hub/pulls).
We'd love your help in expanding the tools available to build Optimistically.
docs/op-stack/src/docs/useful-tools/explorers.md deleted 100644 → 0
View file @ 03012bd0
---
title: Block Explorers
lang: en-US
---
## Blockscout
We have a Blockscout explorer for the [Goerli testnet](https://blockscout.com/optimism/goerli/). It includes:
- [Verified contract source code, along with the ability to interact with it](https://blockscout.com/optimism/goerli/address/0x106941459A8768f5A92b770e280555FAF817576f/contracts#address-tabs)
- [Detailed transaction information](https://blockscout.com/optimism/goerli/tx/0xeb98c8279983cfee472c6067d2405acc130dca37e7536d6c83930e29aaa40e3e)
## Etherscan
We have Etherscan explorers for the [Optimism mainnet](https://explorer.optimism.io) and the [Optimism Goerli testnet](https://goerli-explorer.optimism.io).
Etherscan has lots of tools to help you debug transactions.
Optimistic Etherscan has all the tools you expect from Etherscan, such as:
- [Verified contract source code, along with the ability to interact with it](https://explorer.optimism.io/address/0x420000000000000000000000000000000000000F#code)
- [Detailed transaction information](https://explorer.optimism.io/tx/0x292423266d6da24126dc4e0e81890c22a67295cc8b1a987e71ad84748511452f)
- And everything else you might find on Etherscan!
It's also got some Optimism-specific features:
- [A list of L1-to-L2 transactions](https://explorer.optimism.io/txsEnqueued)
- [A list of L2-to-L1 transactions](https://explorer.optimism.io/txsExit)
- [A tool for finalizing L2-to-L1 transactions](https://explorer.optimism.io/messagerelayer)
- And more! Just check it out and click around to find all of the available features.
## Access to pre-regenesis history
Because of our final regenesis on 11 November 2021, older transactions are not part of the current blockchain.
As such, they do not appear, for example, on [Etherscan](https://explorer.optimism.io/).
However, you **can** access transaction history between 23 June 2021 and the final regenesis using the Etherscan CSV exporting tool.
### Etherscan access
[Browse here](https://explorer.optimism.io/exportDataMain) and select your address and the type of report you want.
![export data](../../assets/docs/useful-tools/explorers/export.png)
### Dune access
[Click here](https://dune.com/optimismfnd/OVM1.0-User-Address-Transactions).
<!--
If none of the Etherscan CSV files contains the information you need, you can use a query on [Dune Analytics](https://dune.xyz), similar to [this query](https://dune.xyz/queries/354886?addr=%5Cx25E1c58040f27ECF20BBd4ca83a09290326896B3).
You have to log on with a Dune account, but their free tier is sufficient.
```sql
SELECT * FROM optimism.transactions
WHERE "from"='{{addr}}' or "to"='{{addr}}'
LIMIT 100
```
Notes:
- Make sure to select the data source **Optimism (OVM 1.0)**
- This is how you specify parameters in Dune, `{{` followed by the parameter name and then `}}`.
- Addresses are specified as `\x<hex address>` rather than `0x<hex address>`.
- The limit is not required, but here to save resources
-->
### Pre 23 June 2021 history
Follow these steps:
1. Clone go-ethereum (the standard version) and checkout version v1.9.10:
```sh
git clone https://github.com/ethereum/go-ethereum.git
cd go-ethereum
git checkout v1.9.10
```
1. Download the following three datadir folders:
- [Generation #1 (Jan to April)](https://storage.googleapis.com/sequencer-datadirs/datadir-gen1.zip)
- [Generation #2 (April to May)](https://storage.googleapis.com/sequencer-datadirs/datadir-gen2.zip)
- [Generation #3 (May to June)](https://storage.googleapis.com/sequencer-datadirs/datadir-gen3.zip)
1. Build and run the standard geth v1.9.10 with:
```sh
./build/bin/geth --datadir ./path/to/datadir --rpc
```
You can then use ERC20 events filters to get the events that you want for each address. Note that you will have to repeat this process for each datadir to get the full event history.
If you are non-technical and need help requesting this data please reach out to us in Discord and we will be happy to help.
docs/op-stack/src/docs/useful-tools/faucets.md deleted 100644 → 0
View file @ 03012bd0
---
title: Network Faucets
lang: en-US
---
## Testnet Faucets
#### Paradigm MultiFaucet
[Paradigm's MultiFaucet](https://faucet.paradigm.xyz/) is an easy way to get ETH on many different testnets at the same time.
One of those networks is Optimism Goerli.
#### Coinbase Wallet
Users of [Coinbase Wallet](https://www.coinbase.com/wallet) can get test ETH on Optimism Goerli directly from the wallet.
### Goerli Faucets
These are faucets you can use to get test ETH on Goerli.
We recommend getting Goerli ETH from Alchemy's faucet [here](https://goerlifaucet.com/?a=818c11a8da).
Alchemy's Goerli faucet provides 0.25 Goerli ETH per day.
Once you have that Goerli ETH, use [the Optimism Bridge](https://app.optimism.io/bridge) to get it on Optimism Goerli.
## Mainnet Faucets
If you need to get ETH on mainnet for a contract deployment, you should [bridge ETH onto L2](https://gateway.optimism.io/).
This process is relatively cheap and takes about 20 minutes to complete.
You can also get some ETH for expenses by [bridging enough USDC](https://optifaucet.com/) courtesy of [Perpetual Protocol](https://perp.com/).
docs/op-stack/src/docs/useful-tools/meta-tx.md deleted 100644 → 0
View file @ 03012bd0
---
title: Meta Transactions
lang: en-US
---
## What are those?
Meta-transactions let users sign transactions that are then submitted (and the gas paid for) by somebody else.
Optimism is a good place for meta-transactions because the low gas costs make it possible to explore business models that allow for payment for transactions by other means.
Here are some example use cases for meta-transactions:
- **On boarding**.
Users who aren't committed to web3 yet need to pay and go through [KYC](https://www.thalesgroup.com/en/markets/digital-identity-and-security/banking-payment/issuance/id-verification/know-your-customer) before they can do anything.
This is a bad initial experience that can cause people to decide they prefer to investigate something else, especially for non-
- **Privacy**.
It's easy to use a new address for privacy purposes.
It is a lot harder to transfer ETH to the new address privately without creating a connection between it and your identity.
- **Transaction payment by other means**.
With meta-transactions you can collect payment for transactions either using a different token (ERC-20) or a off-chain means (for example a credit card).
## OpenGSN
The [Gas Station Network](https://opengsn.org/) is distributed infrastructure for meta-transaction that allows you to create your own relay, or pay other relays to relay your users' traffic.
Relays have to post a bond, which they lose if they attempt to censor transactions (by pretending to accept them without sending them on chain).
See here for [their documentation](https://docs.opengsn.org/).
### Supported networks:
- [Optimism mainnet](https://docs.opengsn.org/networks/optimism/optimism.html)
- [Optimism Goerli](https://docs.opengsn.org/networks/optimism/goerli-optimism.html)
## Gelato
[Gelato](https://docs.gelato.network/developer-services/relay/what-is-relaying) uses a list of white-listed executors to relay transactions.
### Supported networks:
- Optimism mainnet
- Optimism Goerli
docs/op-stack/src/docs/useful-tools/monitoring.md deleted 100644 → 0
View file @ 03012bd0
---
title: Monitoring
lang: en-US
---
## Status Page
Check out the [Optimism status page](https://status.optimism.io/).
This page includes public APIs, the gateway, deposits, withdraws and transaction sequencing for both Optimism mainnet and Optimism Goerli.
## Public Grafana Dashboard
[Optimism](https://optimism.io) maintains a [public Grafana dashboard](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m) that tracks gas prices, transaction volume, and network uptime in one place.
You can view information about both the Optimism mainnet and the Optimism Goerli testnet on this dashboard.
## Block explorers
### Etherscan
Etherscan provides a lot of detailed information about what's happening on Optimism.
Check out the [Optimism mainnet explorer](https://explorer.optimism.io) as well as the [Optimism Goerli explorer](https://goerli-explorer.optimism.io) to get a look for yourself.
### Blockscout
Another block explorer for the Georli test network is [Blockscout](https://blockscout.com/optimism/goerli/).
## Dashboards on Dune Analytics
[Dune Analytics](https://dune.xyz) allows anyone to create dashboards that present information about Optimism Ethereum.
You can find a full list of community created dashboards for Optimism [here](https://dune.xyz/browse/dashboards?q=optimism), or [create your own](https://docs.dune.xyz/#queries) dashboard.
Here are some of our favorite dashboards so far:
- [General Optimism dashboard](https://dune.xyz/Marcov/Optimism-Ethereum)
- [Uniswap usage comparison, Ethereum vs. Optimism](https://dune.xyz/msilb7/Uniswap-v3-Usage-Comparison-on-Ethereum-vs-Optimism-(OVM-2.0))
docs/op-stack/src/docs/useful-tools/networks.md deleted 100644 → 0
View file @ 03012bd0
---
title: Networks, Public RPC Endpoints, & APIs
lang: en-US
---
::: tip Developer Tip
We recommend using [Alchemy](https://www.alchemy.com/optimism) for its scalablity, reliability, and data accuracy.
:::
::: warning
Some API calls, such as the those in the [personal namespace](https://geth.ethereum.org/docs/rpc/ns-personal) make no sense in a shared environment.
Such RPCs are either totally unsupported, or will return nonsensical values.
:::
## Optimism (mainnet)
::: tip Pre-Bedrock
We are currently testing the [Bedrock](../developers/bedrock/bedrock.md) release.
The mainnet network has still not been updated.
:::
| Parameter | Value |
| --------- | ----- |
| Network Name | **`Optimism`** |
| Description | **`Mainnet`** |
| Chain ID | **`10`** |
| Explorer | **[https://explorer.optimism.io](https://explorer.optimism.io)** |
| HTTP Endpoint<sup>1</sup> | We recommend [Alchemy](https://docs.alchemy.com/reference/optimism-api-quickstart/?a=818c11a8da). Optimism also provides this endpoint: **`https://mainnet.optimism.io`.** _But it is not for production systems and is rate limited._ |
| L1 Contract Addresses | [link](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts/deployments/mainnet#layer-1-contracts) |
| L2 Contract Addresses | [link](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts/deployments/mainnet#layer-2-contracts) |
| chainid.link | [https://chainid.link/?network=optimism](https://chainid.link/?network=optimism)
::: tip Developer Tip
If you are seeing rate limit issues when testing with the public end point, or if you need websocket functionality, we recommend signing up for [Alchemy's](https://www.alchemy.com/optimism) free trial.
:::
(1) Some API calls, such as those in the [personal namespace](https://geth.ethereum.org/docs/rpc/ns-personal) make no sense in a shared environment.
Such RPCs are either not supported, or will return nonsensical values.
### API Options:
1. Get free access to Optimism through [Alchemy](https://www.alchemy.com/optimism)
2. For small scale tests, you can use our public API:
- HTTP endpoint: [https://mainnet.optimism.io](https://mainnet.optimism.io) (note, this is for testing. For production, use Alchemy)
You can run a large application for free using [Alchemy](https://www.alchemy.com/optimism). We’ve done extensive diligence and Alchemy is our recommendation due to reliability, scalability, and data correctness. They're the default API provider and developer platform for top projects like OpenSea and Facebook.
## Optimism Goerli
::: tip Purpose
This is our test network.
It has already been updated to the [Bedrock](../developers/bedrock/bedrock.md) release.
:::
| Parameter | Value |
| --------- | ----- |
| Network Name | **`Optimism Goerli`** |
| Description | **`Testnet (public)`** |
| Chain ID | **`420`** |
| Explorer | **[https://goerli-explorer.optimism.io](https://goerli-explorer.optimism.io)** |
| HTTP Endpoint | **`https://goerli.optimism.io`** |
| chainid.link | [https://chainid.link/?network=optimism-goerli](https://chainid.link/?network=optimism-goerli)
### Contract addresses
The authoritative list of contract addresses is [in the monorepo](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock/deployments/goerli).
They are reproduced here for convenience
| Contract name | Address |
| - | -
| L1CrossDomainMessenger | [`0x5086d1eEF304eb5284A0f6720f79403b4e9bE294`](https://goerli.etherscan.io/address/0x5086d1eEF304eb5284A0f6720f79403b4e9bE294)
| L1ERC721Bridge | [`0x0F9C590b958002E8B10a7431979c1aF882772E88`](https://goerli.etherscan.io/address/0x0F9C590b958002E8B10a7431979c1aF882772E88)
| L1StandardBridge | [`0x636Af16bf2f682dD3109e60102b8E1A089FedAa8`](https://goerli.etherscan.io/address/0x636Af16bf2f682dD3109e60102b8E1A089FedAa8)
| L2OutputOracle | [`0xE6Dfba0953616Bacab0c9A8ecb3a9BBa77FC15c0`](https://goerli.etherscan.io/address/0xE6Dfba0953616Bacab0c9A8ecb3a9BBa77FC15c0)
| Lib_AddressManager | [`0xa6f73589243a6A7a9023b1Fa0651b1d89c177111`](https://goerli.etherscan.io/address/0xa6f73589243a6A7a9023b1Fa0651b1d89c177111)
| OptimismMintableERC20Factory | [`0x883dcF8B05364083D849D8bD226bC8Cb4c42F9C5`](https://goerli.etherscan.io/address/0x883dcF8B05364083D849D8bD226bC8Cb4c42F9C5)
| OptimismPortal | [`0x5b47E1A08Ea6d985D6649300584e6722Ec4B1383`](https://goerli.etherscan.io/address/0x5b47E1A08Ea6d985D6649300584e6722Ec4B1383) |
| PortalSender | [`0xe7FACd39531ee3C313330E93B4d7a8B8A3c84Aa4`](https://goerli.etherscan.io/address/0xe7FACd39531ee3C313330E93B4d7a8B8A3c84Aa4)
| ProxyAdmin | [`0x01d3670863c3F4b24D7b107900f0b75d4BbC6e0d`](https://goerli.etherscan.io/address/0x01d3670863c3F4b24D7b107900f0b75d4BbC6e0d)
| SystemConfig | [`0xAe851f927Ee40dE99aaBb7461C00f9622ab91d60`](https://goerli.etherscan.io/address/0xAe851f927Ee40dE99aaBb7461C00f9622ab91d60)
| SystemDictator | [`0x1f0613A44c9a8ECE7B3A2e0CdBdF0F5B47A50971`](https://goerli.etherscan.io/address/0x1f0613A44c9a8ECE7B3A2e0CdBdF0F5B47A50971)
### API Options
1. Get free access to Optimism through [Alchemy](https://www.alchemy.com/optimism)
2. For small scale tests, you can use our public API:
- HTTP endpoint: [https://goerli.optimism.io](https://goerli.optimism.io) (note, this is for testing. For production, use Alchemy)
You can run a large application for free using [Alchemy](https://www.alchemy.com/optimism). We’ve done extensive diligence and Alchemy is our recommendation due to reliability, scalability, and data correctness.
They're the default API provider and developer platform for top projects like OpenSea and Facebook.
They also support websocket functionality, which our public endpoint does not.
To see the full list of providers visit [Node & API Providers](./providers.md).
### Test ETH
[The Optimism Faucet](https://optimismfaucet.xyz/) provides Optimism Goerli ETH.
Alternatively, if you already have Goerli ETH, you can [bridge it](https://app.optimism.io/bridge). For more faucet options see [Network Faucets](./faucets.md).
::: warning Ignore other networks
Optimism mainnet and Optimism Goerli are, from Optimism's perspective, production networks. This means our Goerli network is something you can rely on for consistent state and uptime. We have other testnets that we use to test our code (such as the Goerli Nightly network) that we use to test new features. These networks are for _us_ to test, and therefore might not have reliable state & uptime.
If you want to test out our new infrastructure before it is stable, or are interested in working on the latest and greatest protocols please check these networks out! If not, they are best ignored.
We try to make sure they work and preserve the state.
In the months prior to a major release, such as Bedrock, we may have a different network for testing dapps on that release.
However, we also have other networks such as [Goerli Nightly](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts/deployments/goerli-nightly).
These are networks that are used for internal Optimism development.
Unless you are working on the Optimism protocol (rather than building things on top of it), ignore these network.
:::
docs/op-stack/src/docs/useful-tools/oracles.md deleted 100644 → 0
View file @ 03012bd0
---
title: Oracles
lang: en-US
---
[Oracles](https://ethereum.org/en/developers/docs/oracles/) provide off-chain data on chain.
This allows code running on a blockchain to access a wide variety of information.
For example, a [stablecoin](https://ethereum.org/en/stablecoins/) that accepts ETH as collateral needs to know the ETH/USD exchange rate:
- How many stablecoins can we give a user for a given amount of ETH?
- Do we need to liquidate any deposits because they are under collateralized?
Different oracles have different security assumptions and different levels of decentralization.
Usually they are either run by the organization that produces the information, or have a mechanism to reward entites that provide accurate information and penalize those that provide incorrect information.
## Types of oracles
There are two types of oracles:
1. **Push oracles** are updated continously and always have up to date information available on chain.
1. **Pull oracles** are only updated when information is requested by a contract.
Pull oracles are themselves divided into two types:
1. Double-transaction oracles, which require two transactions.
The first transaction is the request for information, which usually causes the oracle to emit an event that triggers some off-chain mechanism to provide the answer (through its own transaction).
The second transaction actually reads on-chain the result from the oracle and uses it.
1. Single-transaction oracles, which only require one transaction, such as [Chainlink's random nunber generator](https://docs.chain.link/docs/get-a-random-number/#request-random-values).
The way this works is that the transaction that requests the information includes a callback (address and the call data to provide it).
When the oracle is updated (which also happens through a transaction, but one that is not sent by the user), the oracle uses the callback to inform a contract of the result.
## Gas Oracle
Optimism provides a [Gas Price Oracle](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/predeploys/OVM_GasPriceOracle.sol) that provides information about [gas prices and related parameters](../developers/build/transaction-fees.md).
It can also calculate the total cost of a transaction for you before you send it.
This contract is a predeploy at address `0x420000000000000000000000000000000000000F`:
- [On the production Optimism network](https://explorer.optimism.io/address/0x420000000000000000000000000000000000000F#readContract)
- [On the Optimism Goerli test network](https://goerli-explorer.optimism.io/address/0x420000000000000000000000000000000000000F)
This is a push Oracle.
Optimism updates the gas price parameters on chain whenever those parameters change.
The L1 gas price, which can be volatile, is only pushed once every 5 minutes, and each time can change only by up to 20%.
## Chainlink
On Optimism [Chainlink](https://chain.link/) provides a number of [price feeds](https://docs.chain.link/docs/optimism-price-feeds/).
Those feeds are available on the production network.
This is a push Oracle.
You can always get up to date information (see, for example, [here (scroll down to **latestAnswer**)](https://explorer.optimism.io/address/0x13e3Ee699D1909E989722E753853AE30b17e08c5#readContract)).
[See this guide to learn how to use the Chainlink feeds](https://docs.chain.link/docs/get-the-latest-price/).
## Portal
[Portal](https://portal-docs.readthedocs.io/en/latest/index.html) offers users private, scalable, and fast compute power at low costs.
### Verifiable Randomness Function (VRF)
#### Portal
Portal providers a source of randomness on chain (for now on Optimism Goerli, but eventually also on the Optimism mainnet).
[You can learn how to use it here](https://portal-docs.readthedocs.io/en/latest/user-vrf-docs.html).
It is a single-transaction pull oracle.
#### Band
[Band](https://bandprotocol.com/vrf) provides a source of [on-chain randomness](https://bandprotocol.com/vrf).
[You can learn how to use it here](https://docs.bandchain.org/vrf/getting-started.html).
It is a single-transaction pull oracle.
## Universal Market Access (UMA)
[UMA](https://umaproject.org/) is a generic oracle.
It lets any contract request information (ask a question), and any staked entity can provide an answer.
Other external entities can dispute the proposed answer by providing their own answer and a putting up their own stake.
In the case of dispute the question goes to a vote of token holders.
The token holders that vote with the majority are assumed to be truthful and get rewarded.
The external entities that proposed the correct answer are rewarded.
Those that proposed the wrong answer lose their stake.
[See here for the UMA addresses on Optimism](https://github.com/UMAprotocol/protocol/blob/master/packages/core/networks/10.json).
[See here for instructions how to use UMA](https://docs.umaproject.org/build-walkthrough/build-process).
UMA is a pull Oracle, it does not get information until it is requested by a contract.
This means that an decentralized application needs to issue two transactions.
First, a transaction that causes a contract on the blockchain to ask for the information.
Later (in the case of UMA 48 hours later if there is no dispute, longer if there is), a second transaction need to be triggered to causes the contract to read from the Oracle and see the response to the request.
## Uniswap
Technically speaking [Uniswap](https://uniswap.io/) is not an oracle, because the information comes from on-chain sources.
However, Uniswap pools do provide [quotes that give the relative costs of assets](https://docs.uniswap.org/protocol/concepts/V3-overview/oracle).
::: warning
Using onchain asset prices, especially those in low liquidity pools, makes you vulnerable to price manipulation.
:::
To use Uniswap as an Oracle:
1. See [the list of pools on Optimism](https://info.uniswap.org/#/optimism/).
1. To find the pool address, [look at the Uniswap factory](https://explorer.optimism.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#readContract).
Use **getPool** with these parameters:
| Parameter | Meaning |
| ------------------- | ----------------------------------- |
| One token address | [Address of the ERC-20 contract for that token on Optimism (chainId 10)](https://static.optimism.io/optimism.tokenlist.json) |
| Other token address | [Address of the ERC-20 contract for that token on Optimism (chainId 10)](https://static.optimism.io/optimism.tokenlist.json) |
| Pool fee | The pool fee percentage times ten thousand. For example, for 0.3% enter `3000` |
1. In your contract, use [IUniswapV3PoolState](https://github.com/Uniswap/v3-core/blob/main/contracts/interfaces/pool/IUniswapV3PoolState.sol) and [IUniswapV3PoolDerivedState](https://github.com/Uniswap/v3-core/blob/main/contracts/interfaces/pool/IUniswapV3PoolDerivedState.sol) to get the pool state.
docs/op-stack/src/docs/useful-tools/providers.md deleted 100644 → 0
View file @ 03012bd0
---
title: Node & API Providers
lang: en-US
---
## Alchemy
::: warning
Some API calls, such as the those in the [personal namespace](https://geth.ethereum.org/docs/rpc/ns-personal) make no sense in a shared environment.
Such RPCs are either totally unsupported, or will return nonsensical values.
:::
::: tip
**We strongly recommend all developers use [Alchemy](https://www.alchemy.com/optimism).**
**We’ve done extensive diligence and Alchemy powers our public API.**
We recommend Alchemy due to (a) the reliability, scalability and data correctness of its developer platform and (b) the comprehensive set of tooling and APIs they provide. You can run large applications on their massive free tier.
:::
### Alchemy's Description & Pricing
[Alchemy](https://docs.alchemy.com/reference/optimism-api-quickstart/?a=818c11a8da) is our recommended Optimism API provider and developer platform. Its robust, free tier offers access to (1) enhanced features like SDKs and enhanced APIs and (2) hosted Optimism nodes.
_(1) Alchemy's enhanced features_
Alchemy's free private RPC endpoint provides a complimentary suite of proprietary tools.
These include a custom-built [Ethers.js SDK](https://www.alchemy.com/sdk/?a=818c11a8da) (which are supersets of the Ethers.js Provider and Wallet libraries) and [enhanced APIs](https://www.alchemy.com/enhanced-apis/?a=818c11a8da) such as NFT, Transfers, and Notify APIs.
https://www.alchemy.com/optimism/sdk
_(2) Alchemy's hosted Optimism nodes_
Alchemy hosts our public API because of its data accuracy, reliability, and scalability.
It counts companies like OpenSea, dYdX, and Facebook among its customers.
Its API takes only a few lines of codes to get up and running. Alchemy isn't just a node provider, but also a developer platform and API provider.
### Alchemy's Supported Networks
- Optimism Ethereum
- Optimism Goerli
[Sign up for a free Alchemy account here](https://www.alchemy.com/optimism).
## Ankr
### Description and Pricing
[Ankr](https://www.ankr.com/) provides a geo-distributed and decentralized (free) public and premium (Pay-as-you-go) [Optimism RPC](https://www.ankr.com/rpc/optimism/) comprised of many independent blockchain nodes running worldwide for low-latency and incredibly reliable connections.
Moreover, Ankr offers access to developer tooling on Optimism like SDKs and [Advanced APIs](https://www.ankr.com/advanced-api/) such as NFT, Token and Query API.
### Supported Networks
- Optimism Ethereum
- Optimism Goerli
## Blast
### Description and Pricing
[Blast](https://blastapi.io/) offers access to dedicated Optimism nodes with free data access up to 12M API calls per month and 25 req/s. Paid subscription tiers are available for all development needs.
On the platform, there are also [Public APIs](https://blastapi.io/public-api/optimism) available that can be added easily in Metamask.
### Supported Networks
- Optimism Ethereum
- Optimism Goerli
## BlockVision
[BlockVision](https://blockvision.org/) is a one-stop development platform and on-chain data retrieval portal for developers that boasts impressively low-latencies and high availability.
### Supported Networks
- Optimism Ethereum
## GetBlock
[GetBlock developer](https://getblock.io/en/nodes/optimism/) tools and valuable insights guarantee a simple and reliable API access to multiple blockchains.
### Supported Networks
- Optimism Ethereum
- Optimism Goerli
## Infura
### Description and Pricing
[Infura](https://infura.io) offers access to hosted Optimism nodes via addon.
This addon is currently free but Infura seems to intend to charge $200/month for this addon in the future.
### Supported Networks
- Optimism Ethereum
- Optimism Goerli
## NodeReal
### Description and pricing
[NodeReal](https://nodereal.io/) is a one-stop blockchain infrastructure and services provider, we provide scalable, reliable, and efficient blockchain solutions for everyone, aiming to support the massive adoption, growth, and long-term success of the Web3 ecosystem. You can connect to the Optimism MegaNode for free every month. Details are [here](https://nodereal.io/pricing)
[Sign up for your free account here](https://nodereal.io/meganode).
### Supported Networks
- Optimism Ethereum
## NOWNodes
### Description and pricing
[NOWNodes](https://nownodes.io/nodes/optimism) provide access to mainnet Optimism node. Shared and Dedicated nodes are Available. You can connect to the shared Optimism node for free for one month with 5,000 requests/per day or for €20 with 1,000,000 requests/per month.
The URL format is `https://optimism.nownodes.io/?API_key=<API key from NOWNodes`.
### Supported Networks
- Optimism Ethereum
## Pocket Network
### Description and pricing
[Pocket](https://www.portal.pokt.network/) offers access to a highly-available dedicated pool of Optimism nodes coordinated autonomously by the Pocket Network protocol. Through the Pocket Portal, developers may mint Optimism RPC endpoints with a generous free tier of 1M requests per day (per endpoint, max 2 per account).
### Supported Networks
- Optimism Ethereum
## QuickNode
### Description and Pricing
[QuickNode](https://www.quicknode.com/) offers access to hosted Optimism nodes for $9/month at its cheapest tier.
You can select addons, like "Archive Mode" or "Trace Mode" for an additional cost.
### Supported Networks
- Optimism Ethereum
- Optimism Goerli
## Don't see your company here?
We try to keep this list up to date as we find out about more infrastructure providers who maintain Optimism nodes.
If you're a node provider and you'd like to be included in this list, please message us in our [Discord](https://discord-gateway.optimism.io) or [make a PR](https://github.com/ethereum-optimism/community-hub/pulls).
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment