diff --git a/pages/builders/chain-operators/_meta.json b/pages/builders/chain-operators/_meta.json index aa0d27141..3481fe628 100644 --- a/pages/builders/chain-operators/_meta.json +++ b/pages/builders/chain-operators/_meta.json @@ -1,9 +1,11 @@ { "architecture": "Architecture", "self-hosted": "Start a Self-Hosted Chain", - "tutorials": "Tutorials", + "configuration": "Chain Configuration", "management": "Chain Management", "features": "Chain Features", + "deploy": "Deployment", + "tutorials": "Tutorials", "tools": "Chain Tools", "hacks": "OP Stack Hacks" } diff --git a/pages/builders/chain-operators/configuration/_meta.json b/pages/builders/chain-operators/configuration/_meta.json new file mode 100644 index 000000000..66363b285 --- /dev/null +++ b/pages/builders/chain-operators/configuration/_meta.json @@ -0,0 +1,6 @@ +{ + "overview": "Overview", + "rollup": "Rollup Configuration", + "batcher": "Batcher Configuration", + "proposer": "Proposer Configuration" +} \ No newline at end of file diff --git a/pages/builders/chain-operators/configuration/batcher.mdx b/pages/builders/chain-operators/configuration/batcher.mdx new file mode 100644 index 000000000..ac07942aa --- /dev/null +++ b/pages/builders/chain-operators/configuration/batcher.mdx @@ -0,0 +1,675 @@ +--- +title: Batcher Configuration +lang: en-US +description: Learn the OP Stack batcher configurations. +--- + +import { Callout, Tabs } from 'nextra/components' + +# Batcher Configuration + +This page lists all configuration options for the op-batcher. The op-batcher posts +L2 sequencer data to the L1, to make it available for verifiers. The following +options are from the `--help` in [v1.7.6](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.6). + +## Global Options + +### active-sequencer-check-duration + +The duration between checks to determine the active sequencer endpoint. The +default value is `2m0s`. + + + `--active-sequencer-check-duration=` + `--active-sequencer-check-duration=2m0s` + `OP_BATCHER_ACTIVE_SEQUENCER_CHECK_DURATION=2m0s` + + +### approx-compr-ratio + +The approximate compression ratio (`<=1.0`). Only relevant for ratio +compressor. The default value is `0.6`. + + + `--approx-compr-ratio=` + `--approx-compr-ratio=0.6` + `OP_BATCHER_APPROX_COMPR_RATIO=0.6` + + +### batch-type + +The batch type. 0 for `SingularBatch` and 1 for `SpanBatch`. The default value +is `0` for `SingularBatch`. + + + `--batch-type=` + `--batch-type=singular` + `OP_BATCHER_BATCH_TYPE=` + + +### check-recent-txs-depth + +Indicates how many blocks back the batcher should look during startup for a +recent batch tx on L1. This can speed up waiting for node sync. It should be +set to the verifier confirmation depth of the sequencer (e.g. 4). The default +value is `0`. + + + `--check-recent-txs-depth=` + `--check-recent-txs-depth=0` + `OP_BATCHER_CHECK_RECENT_TXS_DEPTH=0` + + +### compression-algo + +The compression algorithm to use. Valid options: zlib, brotli, brotli-9, +brotli-10, brotli-11. The default value is `zlib`. + + + `--compression-algo=` + `--compression-algo=zlib` + `OP_BATCHER_COMPRESSION_ALGO=zlib` + + +### compressor + +The type of compressor. Valid options: none, ratio, shadow. The default value +is `shadow`. + + + `--compressor=` + `--compressor=shadow` + `OP_BATCHER_COMPRESSOR=shadow` + + +### data-availability-type + +The data availability type to use for submitting batches to the L1. Valid +options: calldata, blobs. The default value is `calldata`. + + + `--data-availability-type=` + `--data-availability-type=calldata` + `OP_BATCHER_DATA_AVAILABILITY_TYPE=calldata` + + +### fee-limit-multiplier + +The multiplier applied to fee suggestions to put a hard limit on fee increases. +The default value is `5`. + + + `--fee-limit-multiplier=` + `--fee-limit-multiplier=5` + `OP_BATCHER_TXMGR_FEE_LIMIT_MULTIPLIER=5` + + +### hd-path + +The HD path used to derive the sequencer wallet from the mnemonic. The mnemonic +flag must also be set. + + + `--hd-path=` + `--hd-path=` + `OP_BATCHER_HD_PATH=` + + +### l1-eth-rpc + +HTTP provider URL for L1. + + + `--l1-eth-rpc=` + `--l1-eth-rpc` + `OP_BATCHER_L1_ETH_RPC=` + + +### l2-eth-rpc + +HTTP provider URL for L2 execution engine. A comma-separated list enables the +active L2 endpoint provider. Such a list needs to match the number of +rollup-rpcs provided. + + + `--l2-eth-rpc=` + `--l2-eth-rpc=` + `OP_BATCHER_L2_ETH_RPC=` + + +### log.color + +Color the log output if in terminal mode. The default value is `false`. + + + `--log.color=` + `--log.color=false` + `OP_BATCHER_LOG_COLOR=false` + + +### log.format + +Format the log output. Supported formats: 'text', 'terminal', 'logfmt', 'json', +'json-pretty'. The default value is `text`. + + + `--log.format=` + `--log.format=text` + `OP_BATCHER_LOG_FORMAT=text` + + +### log.level + +The lowest log level that will be output. The default value is `INFO`. + + + `--log.level=` + `--log.level=INFO` + `OP_BATCHER_LOG_LEVEL=INFO` + + +### max-channel-duration + +The maximum duration of L1-blocks to keep a channel open. 0 to disable. The +default value is `0`. + + + `--max-channel-duration=` + `--max-channel-duration=0` + `OP_BATCHER_MAX_CHANNEL_DURATION=0` + + +### max-l1-tx-size-bytes + +The maximum size of a batch tx submitted to L1. Ignored for blobs, where max +blob size will be used. The default value is `120000`. + + + `--max-l1-tx-size-bytes=` + `--max-l1-tx-size-bytes=120000` + `OP_BATCHER_MAX_L1_TX_SIZE_BYTES=120000` + + +### max-pending-tx + +The maximum number of pending transactions. 0 for no limit. The default value +is `1`. + + + `--max-pending-tx=` + `--max-pending-tx=1` + `OP_BATCHER_MAX_PENDING_TX=1` + + +### metrics.addr + +Metrics listening address. The default value is `0.0.0.0`. + + + `--metrics.addr=` + `--metrics.addr=0.0.0.0` + `OP_BATCHER_METRICS_ADDR=0.0.0.0` + + +### metrics.enabled + +Enable the metrics server. The default value is `false`. + + + `--metrics.enabled=` + `--metrics.enabled=false` + `OP_BATCHER_METRICS_ENABLED=false` + + +### metrics.port + +Metrics listening port. The default value is `7300`. + + + `--metrics.port=` + `--metrics.port=7300` + `OP_BATCHER_METRICS_PORT=7300` + + +### mnemonic + +The mnemonic used to derive the wallets for either the service. + + + `--mnemonic=` + `--mnemonic=` + `OP_BATCHER_MNEMONIC=` + + +### network-timeout + +Timeout for all network operations. The default value is `10s`. + + + `--network-timeout=` + `--network-timeout=10s` + `OP_BATCHER_NETWORK_TIMEOUT=10s` + + +### num-confirmations + +Number of confirmations which we will wait after sending a transaction. The +default value is `10`. + + + `--num-confirmations=` + `--num-confirmations=10` + `OP_BATCHER_NUM_CONFIRMATIONS=10` + + +### plasma.da-server + +HTTP address of a DA Server. + + + `--plasma.da-server=` + `--plasma.da-server=` + `OP_BATCHER_PLASMA_DA_SERVER=` + + +### plasma.da-service + +Use DA service type where commitments are generated by plasma server. The +default value is `false`. + + + `--plasma.da-service=` + `--plasma.da-service=false` + `OP_BATCHER_PLASMA_DA_SERVICE=false` + + +### plasma.enabled + +Enable plasma mode. The default value is `false`. + + + `--plasma.enabled=` + `--plasma.enabled=false` + `OP_BATCHER_PLASMA_ENABLED=false` + + +### plasma.verify-on-read + +Verify input data matches the commitments from the DA storage service. The +default value is `true`. + + + `--plasma.verify-on-read=` + `--plasma.verify-on-read=true` + `OP_BATCHER_PLASMA_VERIFY_ON_READ=true` + + +### poll-interval + +How frequently to poll L2 for new blocks. The default value is `6s`. + + + `--poll-interval=` + `--poll-interval=6s` + `OP_BATCHER_POLL_INTERVAL=6s` + + +### pprof.addr + +pprof listening address. The default value is `0.0.0.0`. + + + `--pprof.addr=` + `--pprof.addr=0.0.0.0` + `OP_BATCHER_PPROF_ADDR=0.0.0.0` + + +### pprof.enabled + +Enable the pprof server. The default value is `false`. + + + `--pprof.enabled=` + `--pprof.enabled=false` + `OP_BATCHER_PPROF_ENABLED=false` + + +### pprof.path + +pprof file path. If it is a directory, the path is `{dir}/{profileType}.prof`. + + + `--pprof.path=` + `--pprof.path=` + `OP_BATCHER_PPROF_PATH=` + + +### pprof.port + +pprof listening port. The default value is `6060`. + + + `--pprof.port=` + `--pprof.port=6060` + `OP_BATCHER_PPROF_PORT=6060` + + +### pprof.type + +pprof profile type. One of cpu, heap, goroutine, threadcreate, block, mutex, +allocs. + + + `--pprof.type=` + `--pprof.type` + `OP_BATCHER_PPROF_TYPE=` + + +### private-key + +The private key to use with the service. Must not be used with mnemonic. + + + `--private-key=` + `--private-key=` + `OP_BATCHER_PRIVATE_KEY=` + + +### resubmission-timeout + +Duration we will wait before resubmitting a transaction to L1. The default +value is `48s`. + + + `--resubmission-timeout=` + `--resubmission-timeout=48s` + `OP_BATCHER_RESUBMISSION_TIMEOUT=48s` + + +### rollup-rpc + +HTTP provider URL for Rollup node. A comma-separated list enables the active L2 +endpoint provider. Such a list needs to match the number of l2-eth-rpcs +provided. + + + `--rollup-rpc=` + `--rollup-rpc=` + `OP_BATCHER_ROLLUP_RPC=` + + +### rpc.addr + +rpc listening address. The default value is `0.0.0.0`. + + + `--rpc.addr=` + `--rpc.addr=0.0.0.0` + `OP_BATCHER_RPC_ADDR=0.0.0.0` + + +### rpc.enable-admin + +Enable the admin API. The default value is `false`. + + + `--rpc.enable-admin=` + `--rpc.enable-admin=false` + `OP_BATCHER_RPC_ENABLE_ADMIN=false` + + +### rpc.port + +rpc listening port. The default value is `8545`. + + + `--rpc.port=` + `--rpc.port=8545` + `OP_BATCHER_RPC_PORT=8545` + + +### safe-abort-nonce-too-low-count + +Number of ErrNonceTooLow observations required to give up on a tx at a +particular nonce without receiving confirmation. The default value is `3`. + + + `--safe-abort-nonce-too-low-count=` + `--safe-abort-nonce-too-low-count=3` + `OP_BATCHER_SAFE_ABORT_NONCE_TOO_LOW_COUNT=3` + + +### sequencer-hd-path + +DEPRECATED: The HD path used to derive the sequencer wallet from the mnemonic. +The mnemonic flag must also be set. + + + `--sequencer-hd-path=` + `--sequencer-hd-path` + `OP_BATCHER_SEQUENCER_HD_PATH=` + + +### signer.address + +Address the signer is signing transactions for. + + + `--signer.address=` + `--signer.address=` + `OP_BATCHER_SIGNER_ADDRESS=` + + +### signer.endpoint + +Signer endpoint the client will connect to. + + + `--signer.endpoint=` + `--signer.endpoint=` + `OP_BATCHER_SIGNER_ENDPOINT=` + + +### signer.tls.ca + +tls ca cert path. The default value is `tls/ca.crt`. + + + `--signer.tls.ca=` + `--signer.tls.ca=tls/ca.crt` + `OP_BATCHER_SIGNER_TLS_CA=tls/ca.crt` + + +### signer.tls.cert + +tls cert path. The default value is `tls/tls.crt`. + + + `--signer.tls.cert=` + `--signer.tls.cert=tls/tls.crt` + `OP_BATCHER_SIGNER_TLS_CERT=` + + +### signer.tls.key + +tls key. The default value is `tls/tls.key`. + + + `--signer.tls.key=` + `--signer.tls.key=tls/tls.key` + `OP_BATCHER_SIGNER_TLS_KEY=` + + +### stopped + +Initialize the batcher in a stopped state. The batcher can be started using the +admin_startBatcher RPC. The default value is `false`. + + + `--stopped=` + `--stopped=false` + `OP_BATCHER_STOPPED=false` + + +### sub-safety-margin + +The batcher tx submission safety margin (in #L1-blocks) to subtract from a +channel's timeout and sequencing window, to guarantee safe inclusion of a +channel on L1. The default value is `10`. + + + `--sub-safety-margin=` + `--sub-safety-margin=10` + `OP_BATCHER_SUB_SAFETY_MARGIN=10s` + + +### target-num-frames + +The target number of frames to create per channel. Controls number of blobs per +blob tx, if using Blob DA. The default value is `1`. + + + `--target-num-frames=` + `--target-num-frames=1` + `OP_BATCHER_TARGET_NUM_FRAMES=1` + + +### txmgr.fee-limit-threshold + +The minimum threshold (in GWei) at which fee bumping starts to be capped. +Allows arbitrary fee bumps below this threshold. The default value is `100`. + + + `--txmgr.fee-limit-threshold=` + `--txmgr.fee-limit-threshold=100` + `OP_BATCHER_TXMGR_FEE_LIMIT_THRESHOLD=100` + + +### txmgr.min-basefee + +Enforces a minimum base fee (in GWei) to assume when determining tx fees. 1 +GWei by default. The default value is `1`. + + + `--txmgr.min-basefee=` + `--txmgr.min-basefee=1` + `OP_BATCHER_TXMGR_MIN_BASEFEE=1` + + +### txmgr.min-tip-cap + +Enforces a minimum tip cap (in GWei) to use when determining tx fees. 1 GWei by +default. The default value is `1`. + + + `--txmgr.min-tip-cap=` + `--txmgr.min-tip-cap=1` + `OP_BATCHER_TXMGR_MIN_TIP_CAP=1` + + +### txmgr.not-in-mempool-timeout + +Timeout for aborting a tx send if the tx does not make it to the mempool. The +default value is `2m0s`. + + + `--txmgr.not-in-mempool-timeout=` + `--txmgr.not-in-mempool-timeout=2m0s` + `OP_BATCHER_TXMGR_TX_NOT_IN_MEMPOOL_TIMEOUT=2m0s` + + +### txmgr.receipt-query-interval + +Frequency to poll for receipts. The default value is `12s`. + + + `--txmgr.receipt-query-interval=` + `--txmgr.receipt-query-interval=12s` + `OP_BATCHER_TXMGR_RECEIPT_QUERY_INTERVAL=12s` + + +### txmgr.send-timeout + +Timeout for sending transactions. If 0 it is disabled. The default value is +`0s`. + + + `--txmgr.send-timeout=` + `--txmgr.send-timeout=0s` + `OP_BATCHER_TXMGR_TX_SEND_TIMEOUT=0s` + + +### wait-node-sync + +Indicates if, during startup, the batcher should wait for a recent batcher tx +on L1 to finalize (via more block confirmations). This should help avoid +duplicate batcher txs. The default value is `false`. + + + `--wait-node-sync=` + `--wait-node-sync=false` + `OP_BATCHER_WAIT_NODE_SYNC=false` + + +## Miscellaneous + +### help + +Show help. The default value is false. + + + `--help=` + `--help=false` + + +### version + +Print the version. The default value is false. + + + `--version=` + `--version=false` + + +## Recommendations + +### Set Your `OP_BATCHER_MAX_CHANNEL_DURATION` + + + The default value inside `op-batcher`, if not specified, is still `0`, which means channel duration tracking is disabled. + For very low throughput chains, this would mean to fill channels until close to the sequencing window and post the channel to `L1 SUB_SAFETY_MARGIN` L1 blocks before the sequencing window expires. + + +To minimize costs, we recommend setting your `OP_BATCHER_MAX_CHANNEL_DURATION` to target 5 hours, with a value of `1500` L1 blocks. When non-zero, this parameter is the max time (in L1 blocks, which are 12 seconds each) between which batches will be submitted to the L1. If you have this set to 5 for example, then your batcher will send a batch to the L1 every 5\*12=60 seconds. When using blobs, because 130kb blobs need to be purchased in full, if your chain doesn't generate at least \~130kb of data in those 60 seconds, then you'll be posting only partially full blobs and wasting storage. + +* We do not recommend setting any values higher than targeting 5 hours, as batches have to be submitted within the sequencing window which defaults to 12 hours for OP chains, otherwise your chain may experience a 12 hour long chain reorg. 5 hours is the longest length of time we recommend that still sits snugly within that 12 hour window to avoid affecting stability. +* If your chain fills up full blobs of data before the `OP_BATCHER_MAX_CHANNEL_DURATION` elapses, a batch will be submitted anyways - (e.g. even if the OP Mainnet batcher sets an `OP_BATCHER_MAX_CHANNEL_DURATION` of 5 hours, it will still be submitting batches every few minutes) + + + While setting an`OP_BATCHER_MAX_CHANNEL_DURATION` of `1500` results in the cheapest fees, it also means that your [safe head](https://github.com/ethereum-optimism/specs/blob/main/specs/glossary.md#safe-l2-head) can stall for up to 5 hours. + + * This will negatively impact apps on your chain that rely on the safe head for operation. While many apps can likely operate simply by following the unsafe head, often Centralized Exchanges or third party bridges wait until transactions are marked safe before processing deposits and withdrawal. + * Thus a larger gap between posting batches can result in significant delays in the operation of certain types of high-security applications. + + +### Configure Your Batcher to Use Multiple Blobs + +The `op-batcher` has the capabilities to send multiple blobs per single blob transaction. This is accomplished by the use of multi-frame channels, see the [specs](https://specs.optimism.io/protocol/derivation.html#frame-format) for more technical details on channels and frames. + +A minimal batcher configuration (with env vars) to enable 6-blob batcher transactions is: + +``` + - OP_BATCHER_BATCH_TYPE=1 # span batches, optional + - OP_BATCHER_DATA_AVAILABILITY_TYPE=blobs + - OP_BATCHER_TARGET_NUM_FRAMES=6 # 6 blobs per tx + - OP_BATCHER_TXMGR_MIN_BASEFEE=2.0 # 2 gwei, might need to tweak, depending on gas market + - OP_BATCHER_TXMGR_MIN_TIP_CAP=2.0 # 2 gwei, might need to tweak, depending on gas market + - OP_BATCHER_RESUBMISSION_TIMEOUT=240s # wait 4 min before bumping fees +``` + +This enables blob transactions and sets the target number of frames to 6, which translates to 6 blobs per transaction. +The minimum tip cap and base fee are also lifted to 2 gwei because it is uncertain how easy it will be to get 6-blob transactions included and slightly higher priority fees should help. +The resubmission timeout is increased to a few minutes to give more time for inclusion before bumping the fees because current transaction pool implementations require a doubling of fees for blob transaction replacements. + +Multi-blob transactions are particularly useful for medium to high-throughput chains, where enough transaction volume exists to fill up 6 blobs in a reasonable amount of time. +You can use [this calculator](https://docs.google.com/spreadsheets/d/12VIiXHaVECG2RUunDSVJpn67IQp9NHFJqUsma2PndpE/edit) for your chain to determine what number of blobs are right for you, and what gas scalar configuration to use. Please also refer to guide on [Using Blobs](/builders/chain-operators/management/blobs) for chain operators. diff --git a/pages/builders/chain-operators/configuration/overview.mdx b/pages/builders/chain-operators/configuration/overview.mdx new file mode 100644 index 000000000..8a5c74f08 --- /dev/null +++ b/pages/builders/chain-operators/configuration/overview.mdx @@ -0,0 +1,48 @@ +--- +title: Chain Operator Configurations +lang: en-US +description: Learn the how to configure an OP Stack chain. +--- + +import { Callout, Steps } from 'nextra/components' + +# Chain Operator Configurations + +OP Stack chains can be configured for the Chain Operator's needs. Each +component of the stack has its own considerations. See the following for +documentation for details on configuring each piece. + + + + {

Rollup Configuration

} + + Deploying your OP Stack contracts requires creating a deployment configuration + JSON file. This defines the behavior of your network at its genesis. + + * [Rollup Configuration Documentation](/builders/chain-operators/configuration/rollup) + + {

Batcher Configuration

} + + The batcher is the service that submits the L2 Sequencer data to L1, to make + it available for verifiers. These configurations determine the batcher's + behavior. + + * [Batcher Configuration Documentation](/builders/chain-operators/configuration/batcher) + + {

Proposer Configuration

} + + The proposer is the service that submits the output roots to the L1. These + configurations determine the proposer's behavior. + + * [Proposer Configuration Documentation](/builders/chain-operators/configuration/proposer) + + {

Node Configuration

} + + The rollup node has a wide array of configurations for both the consensus and + execution clients. + + * [Node Configuration Documentation](/builders/node-operators/configuration/base-config) + + + + diff --git a/pages/builders/chain-operators/configuration/proposer.mdx b/pages/builders/chain-operators/configuration/proposer.mdx new file mode 100644 index 000000000..da7b24846 --- /dev/null +++ b/pages/builders/chain-operators/configuration/proposer.mdx @@ -0,0 +1,492 @@ +--- +title: Proposer Configuration +lang: en-US +description: Learn the OP Stack proposer configurations. +--- + +import { Tabs } from 'nextra/components' + +# Proposer Configuration + +This page list all configuration options for op-proposer. The op-proposer posts +the output roots to the L1, to make it available for verifiers. The following +options are from the `--help` in [v1.7.6](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.6). + +## Global Options + +### active-sequencer-check-duration + +The duration between checks to determine the active sequencer endpoint. The +default value is `2m0s`. + + + `--active-sequencer-check-duration=` + `--active-sequencer-check-duration=2m0s` + `OP_PROPOSER_ACTIVE_SEQUENCER_CHECK_DURATION=2m0s` + + +### allow-non-finalized + +Allow the proposer to submit proposals for L2 blocks from non-finalized L1 +blocks. The default value is false. + + + `--allow-non-finalized=` + `--allow-non-finalized=false` + `OP_PROPOSER_ALLOW_NON_FINALIZED=false` + + +### fee-limit-multiplier + +The multiplier applied to fee suggestions to limit fee increases. The default +value is 5. + + + `--fee-limit-multiplier=` + `--fee-limit-multiplier=5` + `OP_PROPOSER_TXMGR_FEE_LIMIT_MULTIPLIER=5` + + +### game-factory-address + +Address of the DisputeGameFactory contract. + + + `--game-factory-address=` + `--game-factory-address=` + `OP_PROPOSER_GAME_FACTORY_ADDRESS=` + + +### game-type + +Dispute game type to create via the configured DisputeGameFactory. The default +value is 0. + + + `--game-type=` + `--game-type=0` + `OP_PROPOSER_GAME_TYPE=0` + + +### hd-path + +The HD path used to derive the sequencer wallet from the mnemonic. + + + `--hd-path=` + `--hd-path=` + `OP_PROPOSER_HD_PATH=` + + +### l1-eth-rpc + +HTTP provider URL for L1. + + + `--l1-eth-rpc=` + `--l1-eth-rpc=` + `OP_PROPOSER_L1_ETH_RPC=` + + +### l2-output-hd-path + +DEPRECATED: The HD path used to derive the l2output wallet from the mnemonic. + + + `--l2-output-hd-path=` + `--l2-output-hd-path=` + `OP_PROPOSER_L2_OUTPUT_HD_PATH=` + + +### l2oo-address + +Address of the L2OutputOracle contract. + + + `--l2oo-address=` + `--l2oo-address=` + `OP_PROPOSER_L2OO_ADDRESS=` + + +### log.color + +Color the log output if in terminal mode. The default value is false. + + + `--log.color=` + `--log.color=false` + `OP_PROPOSER_LOG_COLOR=false` + + +### log.format + +Format the log output. Supported formats: 'text', 'terminal', 'logfmt', 'json', +'json-pretty'. The default value is text. + + + `--log.format=` + `--log.format=text` + `OP_PROPOSER_LOG_FORMAT=text` + + +### log.level + +The lowest log level that will be output. The default value is INFO. + + + `--log.level=` + `--log.level=INFO` + `OP_PROPOSER_LOG_LEVEL=INFO` + + +### metrics.addr + +Metrics listening address. The default value is "0.0.0.0". + + + `--metrics.addr=` + `--metrics.addr=0.0.0.0` + `OP_PROPOSER_METRICS_ADDR=0.0.0.0` + + +### metrics.enabled + +Enable the metrics server. The default value is false. + + + `--metrics.enabled=` + `--metrics.enabled=false` + `OP_PROPOSER_METRICS_ENABLED=false` + + +### metrics.port + +Metrics listening port. The default value is 7300. + + + `--metrics.port=` + `--metrics.port=7300` + `OP_PROPOSER_METRICS_PORT=7300` + + +### mnemonic + +The mnemonic used to derive the wallets for the service. + + + `--mnemonic=` + `--mnemonic=` + `OP_PROPOSER_MNEMONIC=` + + +### network-timeout + +Timeout for all network operations. The default value is 10s. + + + `--network-timeout=` + `--network-timeout=10s` + `OP_PROPOSER_NETWORK_TIMEOUT=10s` + + +### num-confirmations + +Number of confirmations to wait after sending a transaction. The default value +is 10. + + + `--num-confirmations=` + `--num-confirmations=10` + `OP_PROPOSER_NUM_CONFIRMATIONS=10` + + +### poll-interval + +How frequently to poll L2 for new blocks. The default value is 6s. + + + `--poll-interval=` + `--poll-interval=6s` + `OP_PROPOSER_POLL_INTERVAL=6s` + + +### pprof.addr + +pprof listening address. The default value is "0.0.0.0". + + + `--pprof.addr=` + `--pprof.addr=0.0.0.0` + `OP_PROPOSER_PPROF_ADDR=0.0.0.0` + + +### pprof.enabled + +Enable the pprof server. The default value is false. + + + `--pprof.enabled=` + `--pprof.enabled=false` + `OP_PROPOSER_PPROF_ENABLED=false` + + +### pprof.path + +pprof file path. If it is a directory, the path is `{dir}/{profileType}.prof` + + + `--pprof.path=` + `--pprof.path=` + `OP_PROPOSER_PPROF_PATH=` + + +### pprof.port + +pprof listening port. The default value is 6060. + + + `--pprof.port=` + `--pprof.port=6060` + `OP_PROPOSER_PPROF_PORT=6060` + + +### pprof.type + +pprof profile type. One of cpu, heap, goroutine, threadcreate, block, mutex, +allocs + + + `--pprof.type=` + `--pprof.type=` + `OP_PROPOSER_PPROF_TYPE=` + + +### private-key + +The private key to use with the service. Must not be used with mnemonic. + + + `--private-key=` + `--private-key=` + `OP_PROPOSER_PRIVATE_KEY=` + + +### proposal-interval + +Interval between submitting L2 output proposals when the dispute game factory +address is set. The default value is 0s. + + + `--proposal-interval=` + `--proposal-interval=0s` + `OP_PROPOSER_PROPOSAL_INTERVAL=0s` + + +### resubmission-timeout + +Duration we will wait before resubmitting a transaction to L1. The default +value is 48s. + + + `--resubmission-timeout=` + `--resubmission-timeout=48s` + `OP_PROPOSER_RESUBMISSION_TIMEOUT=48s` + + +### rollup-rpc + +HTTP provider URL for the rollup node. A comma-separated list enables the +active rollup provider. + + + `--rollup-rpc=` + `--rollup-rpc=` + `OP_PROPOSER_ROLLUP_RPC=` + + +### rpc.addr + +rpc listening address. The default value is "0.0.0.0". + + + `--rpc.addr=` + `--rpc.addr=0.0.0.0` + `OP_PROPOSER_RPC_ADDR=0.0.0.0` + + +### rpc.enable-admin + +Enable the admin API. The default value is false. + + + `--rpc.enable-admin=` + `--rpc.enable-admin=false` + `OP_PROPOSER_RPC_ENABLE_ADMIN=false` + + +### rpc.port + +rpc listening port. The default value is 8545. + + + `--rpc.port=` + `--rpc.port=8545` + `OP_PROPOSER_RPC_PORT=8545` + + +### safe-abort-nonce-too-low-count + +Number of ErrNonceTooLow observations required to give up on a tx at a +particular nonce without receiving confirmation. The default value is 3. + + + `--safe-abort-nonce-too-low-count=` + `--safe-abort-nonce-too-low-count=3` + `OP_PROPOSER_SAFE_ABORT_NONCE_TOO_LOW_COUNT=3` + + +### signer.address + +Address the signer is signing transactions for. + + + `--signer.address=` + `--signer.address=` + `OP_PROPOSER_SIGNER_ADDRESS=` + + +### signer.endpoint + +Signer endpoint the client will connect to. + + + `--signer.endpoint=` + `--signer.endpoint=` + `OP_PROPOSER_SIGNER_ENDPOINT=` + + +### signer.tls.ca + +tls ca cert path. The default value is "tls/ca.crt". + + + `--signer.tls.ca=` + `--signer.tls.ca=tls/ca.crt` + `OP_PROPOSER_SIGNER_TLS_CA=tls/ca.crt` + + +### signer.tls.cert + +tls cert path. The default value is "tls/tls.crt". + + + `--signer.tls.cert=` + `--signer.tls.cert=tls/tls.crt` + `OP_PROPOSER_SIGNER_TLS_CERT=tls/tls.crt` + + +### signer.tls.key + +tls key. The default value is "tls/tls.key". + + + `--signer.tls.key=` + `--signer.tls.key=tls/tls.key` + `OP_PROPOSER_SIGNER_TLS_KEY=tls/tls.key` + + +### txmgr.fee-limit-threshold + +The minimum threshold (in GWei) at which fee bumping starts to be capped. The +default value is 100. + + + `--txmgr.fee-limit-threshold=` + `--txmgr.fee-limit-threshold=100` + `OP_PROPOSER_TXMGR_FEE_LIMIT_THRESHOLD=100` + + +### txmgr.min-basefee + +Enforces a minimum base fee (in GWei) to assume when determining tx fees. The +default value is 1. + + + `--txmgr.min-basefee=` + `--txmgr.min-basefee=1` + `OP_PROPOSER_TXMGR_MIN_BASEFEE=1` + + +### txmgr.min-tip-cap + +Enforces a minimum tip cap (in GWei) to use when determining tx fees. The +default value is 1. + + + `--txmgr.min-tip-cap=` + `--txmgr.min-tip-cap=1` + `OP_PROPOSER_TXMGR_MIN_TIP_CAP=1` + + +### txmgr.not-in-mempool-timeout + +Timeout for aborting a tx send if the tx does not make it to the mempool. The +default value is 2m0s. + + + `--txmgr.not-in-mempool-timeout=` + `--txmgr.not-in-mempool-timeout=2m0s` + `OP_PROPOSER_TXMGR_TX_NOT_IN_MEMPOOL_TIMEOUT=2m0s` + + +### txmgr.receipt-query-interval + +Frequency to poll for receipts. The default value is 12s. + + + `--txmgr.receipt-query-interval=` + `--txmgr.receipt-query-interval=12s` + `OP_PROPOSER_TXMGR_RECEIPT_QUERY_INTERVAL=12s` + + +### txmgr.send-timeout + +Timeout for sending transactions. If 0 it is disabled. The default value is 0s. + + + `--txmgr.send-timeout=` + `--txmgr.send-timeout=0s` + `OP_PROPOSER_TXMGR_TX_SEND_TIMEOUT=0s` + + +### wait-node-sync + +Indicates if, during startup, the proposer should wait for the rollup node to +sync to the current L1 tip before proceeding with its driver loop. The default +value is false. + + + `--wait-node-sync=` + `--wait-node-sync=false` + `OP_PROPOSER_WAIT_NODE_SYNC=false` + + +## Miscellaneous + +### help + +Show help. The default value is false. + + + `--help=` + `--help=false` + + +### version + +Print the version. The default value is false. + + + `--version=` + `--version=false` + diff --git a/pages/builders/chain-operators/configuration/rollup.mdx b/pages/builders/chain-operators/configuration/rollup.mdx new file mode 100644 index 000000000..14da9553e --- /dev/null +++ b/pages/builders/chain-operators/configuration/rollup.mdx @@ -0,0 +1,984 @@ +--- +title: Rollup Configuration +lang: en-US +description: Learn the OP Stack rollup configurations. +--- + +import { Callout } from 'nextra/components' + +# Rollup Configuration + +New OP Stack blockchains are currently configured with a JSON file inside the +Optimism repository. You can see example configurations in the +[deploy-config directory](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock/deploy-config). + + + The Rollup configuration is an active work in progress and will likely evolve + significantly as time goes on. If something isn't working about your + configuration, you can refer to the [source code](https://github.com/ethereum-optimism/optimism/blob/develop/op-chain-ops/genesis/config.go). + + + + Standard configuration is the set of requirements for an OP Stack chain to be + considered a Standard Chain within the superchain. These requirements are + currently a draft, pending governance approval. For more details, please see + this [governance thread](https://gov.optimism.io/t/season-6-draft-standard-rollup-charter/8135). + + +## Configuration Values + +### Offset Values + +These offset values determine when network upgrades (hardforks) activate on +your blockchain. + +#### l2GenesisRegolithTimeOffset + +L2GenesisRegolithTimeOffset is the number of seconds after genesis block that +Regolith hard fork activates. Set it to 0 to activate at genesis. Nil to +disable Regolith. + +* **Type:** Number of seconds +* **Default:** nil + +*** + +#### l2GenesisCanyonTimeOffset + +L2GenesisCanyonTimeOffset is the number of seconds after genesis block that +Canyon hard fork activates. Set it to 0 to activate at genesis. Nil to +disable Canyon. + +* **Type:** Number of seconds +* **Default:** nil + +*** + +#### l2GenesisDeltaTimeOffset + +L2GenesisDeltaTimeOffset is the number of seconds after genesis block that +Delta hard fork activates. Set it to 0 to activate at genesis. Nil to disable +Delta. + +* **Type:** Number of seconds +* **Default:** nil + +*** + +#### l2GenesisEcotoneTimeOffset + +L2GenesisEcotoneTimeOffset is the number of seconds after genesis block that +Ecotone hard fork activates. Set it to 0 to activate at genesis. Nil to disable +Ecotone. + +* **Type:** Number of seconds +* **Default:** nil + +*** + +#### l2GenesisFjordTimeOffset + +L2GenesisFjordTimeOffset is the number of seconds after genesis block that +Fjord hard fork activates. Set it to 0 to activate at genesis. Nil to +disable Fjord. + +* **Type:** Number of seconds +* **Default:** nil + +*** + +#### l2GenesisInteropTimeOffset + +L2GenesisInteropTimeOffset is the number of seconds after genesis block that +the Interop hard fork activates. Set it to 0 to activate at genesis. Nil to +disable Interop. + +* **Type:** Number of seconds +* **Default:** nil + +*** + +#### l1CancunTimeOffset + +When Cancun activates. Relative to L1 genesis. + +* **Type:** Number of seconds +* **Default:** None + +*** + +### Admin addresses + +#### finalSystemOwner + +FinalSystemOwner is the L1 system owner. It owns any ownable L1 contracts. + +* **Type:** L1 Address +* **Default value:** None +* **Recommended value:** It is recommended to have a single admin + address to retain a common security model. +* **Notes:** Must not be `address(0)` + +*** + +#### proxyAdminOwner + +ProxyAdmin contract owner on the L2, which owns all of the Proxy contracts for +every predeployed contract in the range `0x42...0000` to `0x42...2048`. This +makes predeployed contracts easily upgradeable. + +* **Type:** L2 Address +* **Default value:** None +* **Recommended value:** It is recommended to have a single admin + address to retain a common security model. +* **Notes:** Must not be `address(0)` + +*** + +### Proxy Addresses + +#### l1StandardBridgeProxy + +L1StandardBridgeProxy represents the address of the L1StandardBridgeProxy on L1 +and is used as part of building the L2 genesis state. + +* **Type:** L1 Address +* **Default value:** None +* **Notes:** Must not be `address(0)` + +*** + +#### l1CrossDomainMessengerProxy + +L1CrossDomainMessengerProxy represents the address of the +L1CrossDomainMessengerProxy on L1 and is used as part of building the L2 +genesis state. + +* **Type:** L1 Address +* **Default value:** None +* **Notes:** Must not be `address(0)` + +*** + +#### l1ERC721BridgeProxy + +L1ERC721BridgeProxy represents the address of the L1ERC721Bridge on L1 and is +used as part of building the L2 genesis state. + +* **Type:** L1 Address +* **Default value:** None +* **Notes:** Must not be `address(0)` + +*** + +#### systemConfigProxy + +SystemConfigProxy represents the address of the SystemConfigProxy on L1 and is +used as part of the derivation pipeline. + +* **Type:** L1 Address +* **Default value:** None +* **Notes:** Must not be `address(0)` + +*** + +#### optimismPortalProxy + +OptimismPortalProxy represents the address of the OptimismPortalProxy on L1 and +is used as part of the derivation pipeline. + +* **Type:** L1 Address +* **Default value:** None +* **Notes:** Must not be `address(0)` + +*** + +### Blocks + +These fields apply to L2 blocks: Their timing, when they need to be written to L1, and how they get written. + +#### l2BlockTime + +Number of seconds between each L2 block. Must be \< = L1 block time (12 on mainnet and Sepolia). + +* **Type:** Number of seconds +* **Default value:** None +* **Notes:** Must not be `0`. Must be less than the L1 blocktime and a whole number. +* **Standard Config Requirement:** 2 seconds. High security and + interoperability compatibility requirement, until de-risked/solved at app + layer. + +*** + +#### maxSequencerDrift + +How far the L2 timestamp can differ from the actual L1 timestamp. + +* **Type:** Number of seconds +* **Default value:** None +* **Notes:** Must not be `0`. 1800 (30 minutes) is the constant that takes +effect with the [Fjord activation](/builders/node-operators/network-upgrades#fjord). + +*** + +#### sequencerWindowSize + +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. + +* **Type:** Number of blocks +* **Default value:** None +* **Notes:* Must not be `0`. 3600 (12 hours) is suggested. +* **Standard Config Requirement:** 3\_600 base layer blocks (12 hours for an + L2 on Ethereum, assuming 12 second L1 blocktime). This is an important value + for constraining the sequencer's ability to re-order transactions; higher + values would pose a risk to user protections. + +*** + +#### channelTimeout + +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. + +* **Type:** Number of blocks +* **Default value:** None +* **Notes:** 300 (1 hour) is suggested + +*** + +#### p2pSequencerAddress + +Address of the key that the Sequencer uses to sign blocks on the p2p network. + +* **Type:** L1 Address +* **Default value:** None +* **Notes:** Sequencer, an address for which you own the private key + +*** + +#### batchInboxAddress + +Address that Sequencer transaction batches are sent to on L1. + +* **Type:** L1 Address +* **Default value:** None +* **Standard Config Requirement:** Current convention is + `0xff000...000{chainId}`. + +*** + +#### batchSenderAddress + +Address 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. + +* **Type:** L1 Address +* **Default value:** Batcher, an address for which you own the private key. +* **Notes:** Must not be `address(0)` + +*** + +#### systemConfigStartBlock + +SystemConfigStartBlock represents the block at which the op-node should start +syncing from. It is an override to set this value on legacy networks where it +is not set by default. It can be removed once all networks have this value set +in their storage. + +* **Type:** L2 Block Number +* **Default value:** None +* **Standard Config Requirement:** The block where the SystemConfig was + initialized. + +*** + +### Chain Information + +#### l1StartingBlockTag + +Block tag for the L1 block where the L2 chain will begin syncing from. +It is generally recommended to use a finalized block to avoid issues with reorgs. + +* **Type:** Block hash +* **Default value:** None +* **Notes:* Must not be `0`. + +*** + +#### l1ChainID + +Chain ID of the L1 chain. + +* **Type:** Number +* **Default value:** None +* **Notes:* Must not be `0`. 1 for L1 Ethereum mainnet, 11155111 for the + Sepolia test network, and See [here](https://chainlist.org/?testnets=true) + for other blockchains. + +*** + +#### l2ChainID + +Chain ID of the L2 chain. + +* **Type:** Number +* **Default value:** None +* **Notes:* Must not be `0`. For security reasons, should be unique. +* **Standard Config Requirement:** Foundation-approved, globally unique value + +*** + +#### l2GenesisBlockExtraData + +L2GenesisBlockExtraData is configurable extradata. Will default to +\[]byte("BEDROCK") if left unspecified. + +* **Type:** Number +* **Default value:** \[]byte("BEDROCK") + +*** + +#### superchainConfigGuardian + +SuperchainConfigGuardian represents the GUARDIAN account in the +SuperchainConfig. Has the ability to pause withdrawals. + +* **Type:** L1 Address +* **Default value:** None +* **Notes:** Must not be `address(0)` + +*** + +### Gas + +* **Standard Config Requirement:** Set such that Fee Margin is between 0 and + 50%. +* **Standard Config Requirement:** No higher than 200\_000\_000 gas. Chain + operators are driven to maintain a stable and reliable chain. When considering + a change to this value, careful deliberation is necessary. + +#### eip1559Elasticity + +EIP1559Elasticity is the elasticity of the EIP1559 fee market. + +* **Type:** Number +* **Default value:** None +* **Notes:* Must not be `0`. + +*** + +#### eip1559Denominator + +EIP1559Denominator is the denominator of EIP1559 base fee market. + +* **Type:** Number +* **Default value:** None +* **Notes:* Must not be `0`. + +*** + +#### eip1559DenominatorCanyon + +EIP1559DenominatorCanyon is the denominator of EIP1559 base fee market when +Canyon is active. + +* **Type:** Number +* **Default value:** None +* **Notes:* Must not be `0` if Canyon is activated. + +*** + +#### gasPriceOracleBaseFeeScalar + +GasPriceOracleBaseFeeScalar represents the value of the base fee scalar used +for fee calculations. + +* **Type:** Number +* **Default value:** None +* **Notes:* Should not be `0`. + +*** + +#### gasPriceOracleBlobBaseFeeScalar + +GasPriceOracleBlobBaseFeeScalar represents the value of the blob base fee +scalar used for fee calculations. + +* **Type:** Number +* **Default value:** None +* **Notes:* Should not be `0`. + +*** + +### Proposal Fields + +These fields apply to output root proposals. The +l2OutputOracleSubmissionInterval is configurable, see the section below for +guidance. + +#### l2OutputOracleStartingBlockNumber + +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 OP Mainnet). Will be removed with the addition of permissionless +proposals. + +* **Type:** Number +* **Default value:** None +* **Notes:* Should be `0` for new chains. + +*** + +#### l2OutputOracleStartingTimestamp + +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. + +* **Type:** Number +* **Default value:** None +* **Notes:* his MUST be the timestamp corresponding to the block defined by + the l1StartingBlockTag. + +*** + +#### l2OutputOracleSubmissionInterval + +Number of blocks between proposals to the L2OutputOracle. Will be removed with +the addition of permissionless proposals. + +* **Type:** Number of blocks +* **Default value:** None +* **Notes:* Must not be `0`. 120 (4 minutes) is suggested. + +*** + +#### finalizationPeriodSeconds + +Number of seconds that a proposal must be available to challenge before it is +considered finalized by the OptimismPortal contract. + +* **Type:** Number of seconds +* **Default value:** None +* **Notes:* Must not be `0`. Recommend 12 on test networks, seven days on + production ones. +* **Standard Config Requirement:** 7 days. High security. Excessively safe + upper bound that leaves enough time to consider social layer solutions to a + hack if necessary. Allows enough time for other network participants to + challenge the integrity of the corresponding output root. + +*** + +#### l2OutputOracleProposer + +Address that is allowed to submit output proposals to the L2OutputOracle +contract. Will be removed when the OP Stack has permissionless proposals. + +* **Type:** L1 Address +* **Default value:** None +* **Notes:** Must not be `address(0)` + +*** + +#### l2OutputOracleChallenger + +Address that is allowed to challenge output proposals submitted to the +L2OutputOracle. Will be removed when the OP Stack has permissionless +challenges. + +* **Type:** L1 Address +* **Default value:** None +* **Notes:** Must not be `address(0)`. It is recommended to have a single admin + address to retain a common security model. + +*** + +### Fee recipients + +#### baseFeeVaultRecipient + +BaseFeeVaultRecipient represents the recipient of fees accumulated in the +BaseFeeVault. Can be an account on L1 or L2, depending on the +BaseFeeVaultWithdrawalNetwork value. + +* **Type:** L1 or L2 Address +* **Default value:** None +* **Notes:** Must not be `address(0)`. It is recommended to have a single admin + address to retain a common security model. + +*** + +#### l1FeeVaultRecipient + +L1FeeVaultRecipient represents the recipient of fees accumulated in the +L1FeeVault. Can be an account on L1 or L2, depending on the +L1FeeVaultWithdrawalNetwork value. + +* **Type:** L1 or L2 Address +* **Default value:** None +* **Notes:** Must not be `address(0)`. It is recommended to have a single admin + address to retain a common security model. + +*** + +#### sequencerFeeVaultRecipient + +SequencerFeeVaultRecipient represents the recipient of fees accumulated in the +SequencerFeeVault. Can be an account on L1 or L2, depending on the +SequencerFeeVaultWithdrawalNetwork value. + +* **Type:** L1 or L2 Address +* **Default value:** None +* **Notes:** Must not be `address(0)`. It is recommended to have a single admin + address to retain a common security model. + +*** + +### Minimum Fee Withdrawal Amounts + +Withdrawals to L1 are expensive and the minimum fee is to prevent overhead +costs of continuous tiny withdrawals. If the withdrawal execution costs more +than the fee-reward, then the fee Must not be collected economically. + +*** + +#### baseFeeVaultMinimumWithdrawalAmount + +BaseFeeVaultMinimumWithdrawalAmount represents the minimum withdrawal amount +for the BaseFeeVault. + +* **Type:** Number in wei +* **Default value:** None + +*** + +#### l1FeeVaultMinimumWithdrawalAmount + +L1FeeVaultMinimumWithdrawalAmount represents the minimum withdrawal amount for +the L1FeeVault. + +* **Type:** Number in wei +* **Default value:** None + +*** + +#### sequencerFeeVaultWithdrawalAmount + +SequencerFeeVaultMinimumWithdrawalAmount represents the minimum withdrawal +amount for the SequencerFeeVault. + +* **Type:** Number in wei +* **Default value:** None + +*** + +### Withdrawal Network + +*** + +#### baseFeeVaultWithdrawalNetwork + +BaseFeeVaultWithdrawalNetwork represents the withdrawal network for the +BaseFeeVault. value of 0 will withdraw ETH to the recipient address on L1 and +a value of 1 will withdraw ETH to the recipient address on L2. + +* **Type:** Number representing network enum +* **Default value:** None +* **Notes:** Withdrawals to Ethereum are more expensive. + +*** + +#### l1FeeVaultWithdrawalNetwork + +L1FeeVaultWithdrawalNetwork represents the withdrawal network for the +L1FeeVault. A value of 0 will withdraw ETH to the recipient address on L1 and a +value of 1 will withdraw ETH to the recipient address on L2. + +* **Type:** Number representing network enum +* **Default value:** None +* **Notes:** Withdrawals to Ethereum are more expensive. + +*** + +#### sequencerFeeVaultWithdrawalNetwork + +SequencerFeeVaultWithdrawalNetwork represents the withdrawal network for the +SequencerFeeVault. A value of 0 will withdraw ETH to the recipient address on +L1 and a value of 1 will withdraw ETH to the recipient address on L2. + +* **Type:** Number representing network enum +* **Default value:** None +* **Notes:** Withdrawals to Ethereum are more expensive. + +*** + +### Fault Proofs + +*** + +#### faultGameAbsolutePrestate + +FaultGameAbsolutePrestate is the absolute prestate of Cannon. This is computed +by generating a proof from the 0th -> 1st instruction and grabbing the prestate +from the output JSON. All honest challengers should agree on the setup state of +the program. + +* **Type:** Hash +* **Default value:** None + +*** + +#### faultGameMaxDepth + +FaultGameMaxDepth is the maximum depth of the position tree within the fault +dispute game. `2^{FaultGameMaxDepth}` is how many instructions the execution +trace bisection game supports. Ideally, this should be conservatively set so +that there is always enough room for a full Cannon trace. + +* **Type:** Number +* **Default value:** None + +*** + +#### faultGameClockExtension + +FaultGameClockExtension is the amount of time that the dispute game will set +the potential grandchild claim's, clock to, if the remaining time is less than +this value at the time of a claim's creation. + +* **Type:** Number +* **Default value:** None + +*** + +#### faultGameMaxClockDuration + +FaultGameMaxClockDuration is the maximum amount of time that may accumulate on +a team's chess clock before they may no longer respond. + +* **Type:** Number +* **Default value:** None + +*** + +#### faultGameGenesisBlock + +FaultGameGenesisBlock is the block number for genesis. + +* **Type:** Number +* **Default value:** None + +*** + +#### faultGameGenesisOutputRoot + +FaultGameGenesisOutputRoot is the output root for the genesis block. + +* **Type:** Hash +* **Default value:** None + +*** + +#### faultGameSplitDepth + +FaultGameSplitDepth is the depth at which the fault dispute game splits from +output roots to execution trace claims. + +* **Type:** Number +* **Default value:** None + +*** + +#### faultGameWithdrawalDelay + +FaultGameWithdrawalDelay is the number of seconds that users must wait before +withdrawing ETH from a fault game. + +* **Type:** Number +* **Default value:** None + +*** + +#### preimageOracleMinProposalSize + +PreimageOracleMinProposalSize is the minimum number of bytes that a large +preimage oracle proposal can be. + +* **Type:** Number +* **Default value:** None + +*** + +#### preimageOracleChallengePeriod + +PreimageOracleChallengePeriod is the number of seconds that challengers have to +challenge a large preimage proposal. + +* **Type:** Number of Seconds +* **Default value:** None + +*** + +#### proofMaturityDelaySeconds + +ProofMaturityDelaySeconds is the number of seconds that a proof must be mature +before it can be used to finalize a withdrawal. + +* **Type:** Number +* **Default value:** None +* **Notes:* Should not be `0`. + +*** + +#### disputeGameFinalityDelaySeconds + +DisputeGameFinalityDelaySeconds is an additional number of seconds a dispute +game must wait before it can be used to finalize a withdrawal. + +* **Type:** Number +* **Default value:** None +* **Notes:* Should not be `0`. + +*** + +#### respectedGameType + +RespectedGameType is the dispute game type that the OptimismPortal contract +will respect for finalizing withdrawals. + +* **Type:** Number +* **Default value:** None + +*** + +#### useFaultProofs + +UseFaultProofs is a flag that indicates if the system is using fault proofs +instead of the older output oracle mechanism. + +* **Type:** Boolean +* **Default value:** None +* **Notes:* You should understand the implications of running a Fault Proof + chain. + +*** + +### Custom Gas Token + +*** + +#### useCustomGasToken + +UseCustomGasToken is a flag to indicate that a custom gas token should be used. + +* **Type:** boolean +* **Default value:** None + +*** + +#### customGasTokenAddress + +CustomGasTokenAddress is the address of the ERC20 token to be used to pay for +gas on L2. + +* **Type:** Address +* **Default value:** None +* **Notes:** Must not be `address(0)`. + +### Alt-DA Mode / Plasma Mode + +*** + +#### usePlasma + +UsePlasma is a flag that indicates if the system is using op-plasma + +* **Type:** bool +* **Default value:** None +* **Notes:** + +*** + +#### daCommitmentType + +DACommitmentType specifies the allowed commitment + +* **Type:** string +* **Default value:** None +* **Notes:** DACommitmentType must be either KeccakCommitment or + GenericCommitment + +*** + +#### daChallengeWindow + +DAChallengeWindow represents the block interval during which the availability +of a data commitment can be challenged. + +* **Type:** Number +* **Default value:** None +* **Notes:** DAChallengeWindow must not be 0 when using plasma mode + +*** + +#### daResolveWindow + +DAResolveWindow represents the block interval during which a data availability +challenge can be resolved. + +* **Type:** Number +* **Default value:** None +* **Notes:** DAChallengeWindow must no be 0 when using plasma mode + +*** + +#### daBondSize + +DABondSize represents the required bond size to initiate a data availability +challenge. + +* **Type:** Number +* **Default value:** None + +*** + +#### daResolverRefundPercentage + +DAResolverRefundPercentage represents the percentage of the resolving cost to +be refunded to the resolver such as 100 means 100% refund. + +* **Type:** Number +* **Default value:** None + +*** + +#### daChallengeProxy + +DAChallengeProxy represents the L1 address of the DataAvailabilityChallenge +contract. + +* **Type:** Address +* **Default value:** None +* **Notes:** Must not be address(0) when using plasma mode + +*** + +### Interoperability + +*** + +#### useInterop + +UseInterop is a flag that indicates if the system is using interop. + +* **Type:** boolean +* **Default value:** None + +*** + +### Governance + +*** + +#### enableGovernance + +EnableGovernance determines whether to include governance token predeploy. + +* **Type:** boolean +* **Default value:** None + +*** + +#### governanceTokenSymbol + +GovernanceTokenSymbol represents the ERC20 symbol of the GovernanceToken. + +* **Type**: string +* **Default value:** None + +*** + +#### governanceTokenName + +GovernanceTokenName represents the ERC20 name of the GovernanceToken + +* **Type**: string +* **Default value:** None + +*** + +#### governanceTokenOwner + +GovernanceTokenOwner represents the owner of the GovernanceToken. Has the +ability to mint and burn tokens. + +* **Type**: L2 Address +* **Default value:** None + +*** + +### Miscellaneous + +*** + +#### fundDevAccounts + +FundDevAccounts determines whether to fund the dev accounts. Should only +be used during devnet deployments. + +* **Type**: Boolean + +*** + +#### requiredProtocolVersion + +RequiredProtocolVersion indicates the protocol version that nodes are +recommended to adopt, to stay in sync with the network. + +* **Type**: String + +*** + +#### recommendedProtocolVersion + +RecommendedProtocolVersion indicates the protocol version that nodes are +recommended to adopt, to stay in sync with the network. + +* **Type**: String + +*** + +### Deprecated + +*** + +#### (**DEPRECATED**) gasPriceOracleScalar + +GasPriceOracleScalar represents the initial value of the gas scalar in the +GasPriceOracle predeploy. Deprecated: Since Ecotone, this field is superseded +by GasPriceOracleBaseFeeScalar and GasPriceOracleBlobBaseFeeScalar. + +*** + +#### (**DEPRECATED**) gasPriceOracleOverhead + +GasPriceOracleOverhead represents the initial value of the gas overhead in the +GasPriceOracle predeploy. Deprecated: Since Ecotone, this field is superseded +by GasPriceOracleBaseFeeScalar and GasPriceOracleBlobBaseFeeScalar. + +*** + +#### (**DEPRECATED**) deploymentWaitConfirmations + +DeploymentWaitConfirmations is the number of confirmations to wait during +deployment. This is DEPRECATED and should be removed in a future PR. + +*** + +#### (**DEPRECATED**) numDeployConfirmations + +Number of confirmations to wait when deploying smart contracts to L1. diff --git a/pages/builders/chain-operators/deploy/_meta.json b/pages/builders/chain-operators/deploy/_meta.json new file mode 100644 index 000000000..288270a75 --- /dev/null +++ b/pages/builders/chain-operators/deploy/_meta.json @@ -0,0 +1,6 @@ +{ + "overview": "Overview", + "smart-contracts": "Contract Deployment", + "genesis": "Genesis Creation" + } + \ No newline at end of file diff --git a/pages/builders/chain-operators/deploy/genesis.mdx b/pages/builders/chain-operators/deploy/genesis.mdx new file mode 100644 index 000000000..221620cf8 --- /dev/null +++ b/pages/builders/chain-operators/deploy/genesis.mdx @@ -0,0 +1,84 @@ +--- +title: OP Stack Genesis Creation +lang: en-US +description: Learn how to create a genesis file for the OP Stack. +--- + +import { Callout } from 'nextra/components' + +# OP Stack Genesis Creation + +The following guide shows you how to generate the L2 allocs. This is a JSON +file that represents the L2 genesis state. You will provide this file to the +execution client (op-geth) to initialize your network. + +## Solidity Script + +At the time of this writing, the preferred method for genesis generation is to use the foundry script located in the monorepo. It can be found at +[packages/contracts-bedrock/scripts/L2Genesis.s.sol](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/scripts/L2Genesis.s.sol). + +### Configuration + +Create or modify a file `.json` inside the `deploy-config` +folder in the monorepo. The script will read the latest active fork from the +deploy config and the L2 genesis allocs generated will be compatible with this +fork. The automatically detected fork can be overwritten by setting the +environment variable `FORK` either to the lower-case fork name (currently +`delta`, `ecotone`, or `fjord`) or to `latest`, which will select the latest fork +available (currently `fjord`). + +By default, the script will dump the L2 genesis allocs of the detected or +selected fork only, to the file at `STATE_DUMP_PATH`. The optional environment +variable `OUTPUT_MODE` allows you to modify this behavior by setting it to one of +the following values: + +* `latest` (default) - only dump the selected fork's allocs. +* `all` - also dump all intermediary fork's allocs. This only works if + `STATE_DUMP_PATH` is not set. In this case, all allocs will be written to files + `/state-dump-.json`. Another path cannot currently be specified for this + use case. +* `none` - won't dump any allocs. Only makes sense for internal test usage. + +### Creation + +* `CONTRACT_ADDRESSES_PATH` represents the deployment artifact that was + generated during a contract deployment. +* `DEPLOY_CONFIG_PATH` represents a path on the filesystem that points to a + deployment config. The same deploy config JSON file should be used for L1 contracts + deployment as when generating the L2 genesis allocs. +* `STATE_DUMP_PATH` represents the filepath at which the allocs will be + written to on disk. + +```bash +CONTRACT_ADDRESSES_PATH=deployments/artifact.json \ +DEPLOY_CONFIG_PATH= \ +STATE_DUMP_PATH= \ + forge script scripts/L2Genesis.s.sol:L2Genesis \ + --sig 'runWithStateDump()' +``` + +## Subcommand (op-node genesis l2) + +Historically, the genesis file creation was handled by the `genesis l2` +subcommand, provided by the `op-node`. The following is an example of its usage +from [v1.7.6](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.6). + +```bash +go run cmd/main.go genesis l2 \ + --deploy-config= \ + --l1-deployments value= \ + --outfile.l2= \ + --outfile.rollup= \ + --l1-rpc=> +``` + +Alternatively, you can omit `--l1-rpc` and use `--l1-starting-block`. This option +lets you provide a path to a JSON file containing the L1 starting block. This +overrides the need for using an L1 RPC to fetch the block. It cannot be used +with `--l1-rpc`. + +## Next Steps + +* Learn how to [initialize](/builders/node-operators/configuration/base-config#initialization-via-genesis-file) + `op-geth` with your genesis file +* Learn more about the off chain [architecture](/builders/chain-operators/architecture). diff --git a/pages/builders/chain-operators/deploy/overview.mdx b/pages/builders/chain-operators/deploy/overview.mdx new file mode 100644 index 000000000..8d4156c61 --- /dev/null +++ b/pages/builders/chain-operators/deploy/overview.mdx @@ -0,0 +1,123 @@ +--- +title: OP Stack Deployment Overview +lang: en-US +description: Learn about the different components of deploying the OP Stack. +--- + +import { Callout } from 'nextra/components' + +# OP Stack Deployment Overview + +When deploying an OP Stack chain, you'll be setting up four different +components. It's useful to understand what each of these components does before +you start deploying your chain. The OP Stack can be deployed as a L3, which +includes additional considerations. The following information assumes you're +deploying a L2 Rollup on Ethereum. + +## Smart Contracts + +The OP Stack uses a set of smart contracts on the L1 blockchain to manage +aspects of the Rollup. Each OP Stack chain has its own set of L1 smart +contracts that are deployed when the chain is created. + + + Standard OP Stack chains should only use governance approved and audited + smart contracts. The monorepo has them tagged with the following pattern + `op-contracts/vX.X.X` and you can review the release notes for details on the + changes. Read more about the details on our [Smart Contract Release Section](/stack/protocol/rollup/smart-contracts#releases). + + +## Sequencer Node + +OP Stack chains use a Sequencer node to gather proposed transactions from users +and publish them to the L1 blockchain. OP Stack chains rely on at least one of +these Sequencer nodes. You can also run additional replica (non-Sequencer) +nodes. + +### Consensus Client + +OP Stack Rollup nodes, like Ethereum nodes, have a consensus client. The +consensus client is responsible for determining the list and ordering of blocks +and transactions that are part of your blockchain. Several implementations of +the OP Stack consensus client exist, including `op-node` (maintained by the +Optimism Foundation), [`magi`](https://github.com/a16z/magi) (maintained by +a16z) and [`hildr`](https://github.com/optimism-java/hildr) (maintained by OptimismJ). + +### Execution Client + +OP Stack nodes, like Ethereum nodes, also have an execution client. The +execution client is responsible for executing transactions and maintaining the +state of the blockchain. Various implementations of the OP Stack execution +client exist, including `op-geth` (maintained by Optimism Foundation), +[`op-erigon`](https://github.com/testinprod-io/op-erigon) +(maintained by Test in Prod), and [`op-nethermind`](https://docs.nethermind.io/get-started/installing-nethermind/#supported-networks). + +## Batcher + +The Batcher is a service that publishes transactions from the Rollup to the L1 +blockchain. The Batcher runs continuously alongside the Sequencer and publishes +The Batcher continuously publishes transactions alongside the Sequencer in regular batches. + +## Proposer + +The Proposer is a service responsible for publishing transactions *results* (in +the form of L2 state roots) to the L1 blockchain. This allows smart contracts +on L1 to read the state of the L2, which is necessary for cross-chain +communication and reconciliation between state changes. + +## Software Dependencies + +| Dependency | Version | Version Check Command | +| ------------------------------------------------------------- | -------- | --------------------- | +| [git](https://git-scm.com/) | `^2` | `git --version` | +| [go](https://go.dev/) | `^1.21` | `go version` | +| [node](https://nodejs.org/en/) | `^20` | `node --version` | +| [pnpm](https://pnpm.io/installation) | `^8` | `pnpm --version` | +| [foundry](https://github.com/foundry-rs/foundry#installation) | `^0.2.0` | `forge --version` | +| [make](https://linux.die.net/man/1/make) | `^3` | `make --version` | +| [jq](https://github.com/jqlang/jq) | `^1.6` | `jq --version` | +| [direnv](https://direnv.net) | `^2` | `direnv --version` | + +### Notes on Specific Dependencies + +#### `node` + +We recommend using the latest LTS version of Node.js (currently v20). +[`nvm`](https://github.com/nvm-sh/nvm) is a useful tool that can help you +manage multiple versions of Node.js on your machine. You may experience +unexpected errors on older versions of Node.js. + +#### `foundry` + +It's recommended to use the scripts in the monorepo's `package.json` for +managing `foundry` to ensure you're always working with the correct version. +This approach simplifies the installation, update, and version checking +process. + +#### `direnv` + +Parts of our tutorial use [`direnv`](https://direnv.net) as a way of loading +environment variables from `.envrc` files into your shell. This means you won't +have to manually export environment variables every time you want to use them. +`direnv` only ever has access to files that you explicitly allow it to see. + +After [installing `direnv`](https://direnv.net/docs/installation.html), you +will need to **make sure that [`direnv` is hooked into your shell](https://direnv.net/docs/hook.html)**. +Make sure you've followed [the guide on the `direnv` website](https://direnv.net/docs/hook.html), +then **close your terminal and reopen it** so that the changes take effect (or +`source` your config file if you know how to do that). + + + Make sure that you have correctly hooked `direnv` into your shell by modifying + your shell configuration file (like `~/.bashrc` or `~/.zshrc`). If you haven't + edited a config file then you probably haven't configured `direnv` properly + (and things might not work later). + + +## Next Steps + +* Learn how to [deploy the smart contracts](/builders/chain-operators/deploy/smart-contracts). +* Learn how to create your [genesis file](/builders/chain-operators/deploy/genesis). +* Discover how to [deploy the smart contracts](/builders/chain-operators/deploy/smart-contracts). +* Find out how to create your [genesis file](/builders/chain-operators/deploy/genesis). +* Explore some chain operator [best practices](/builders/chain-operators/management/best-practices). diff --git a/pages/builders/chain-operators/deploy/smart-contracts.mdx b/pages/builders/chain-operators/deploy/smart-contracts.mdx new file mode 100644 index 000000000..1e835c237 --- /dev/null +++ b/pages/builders/chain-operators/deploy/smart-contracts.mdx @@ -0,0 +1,89 @@ +--- +title: OP Stack Smart Contract Deployment +lang: en-US +description: Learn how to deploy the OP Stack L1 smart contracts. +--- + +import { Callout } from 'nextra/components' + +# OP Stack Smart Contract Deployment + +The following guide shows you how to deploy the OP Stack L1 smart contracts. +The primary development branch is `develop`. It contains the most up-to-date +software that remains backwards compatible with the latest experimental +network deployments. **Changes to the smart contracts are generally not considered backwards compatible.** + + + Standard OP Stack chains should use governance approved and audited versions + of the smart contract code. + + +## Deployment Configuration + +Deploying your OP Stack contracts requires creating a deployment configuration +JSON file. For the full set of options, you can see the [rollup configuration page](/builders/chain-operators/configuration/rollup). + +## Deployment Script + +The smart contracts are deployed using [foundry](https://github.com/foundry-rs) +and you can find the script's source code in the monorepo at +[packages/contracts-bedrock/scripts/Deploy.s.sol](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/scripts/Deploy.s.sol). + +### State Diff + +Before deploying the contracts, you can verify the state diff by using the `runWithStateDiff()` function signature in the deployment script, which produces +the outputs inside [`snapshots/state-diff/`](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock/snapshots/state-diff). +Run the deployment with state diffs by executing: + +```bash +forge script -vvv scripts/Deploy.s.sol:Deploy --sig 'runWithStateDiff()' --rpc-url $ETH_RPC_URL --broadcast --private-key $PRIVATE_KEY +``` + +### Execution + +* Set the `ETHERSCAN_API_KEY` and add the `--verify` flag to verify your + contracts. +* `DEPLOYMENT_OUTFILE` will determine the filepath that the deployment + artifact is written to on disk after the deployment. It comes in the form of a + JSON file where keys are the names of the contracts and the values are the + addresses the contract was deployed to. +* `DEPLOY_CONFIG_PATH` is the path on the filesystem that points to a deployment + config. The same deployment config JSON file should be used for L1 contracts + deployment as when generating the L2 genesis allocs. See the [deploy-config](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock/deploy-config) + directory for examples and the [rollup configuration page](/builders/chain-operators/configuration/rollup) + for descriptions of the values. +* `IMPL_SALT` env var can be used to set the create2 salt for deploying the + implementation contracts. + +This will deploy an entire new system of L1 smart contracts, including a new +SuperchainConfig. In the future, there will be an easy way to deploy only +proxies and use shared implementations for each of the contracts as well as a +shared SuperchainConfig contract. + +``` +DEPLOYMENT_OUTFILE=deployments/artifact.json \ +DEPLOY_CONFIG_PATH= \ + forge script scripts/Deploy.s.sol:Deploy \ + --broadcast --private-key $PRIVATE_KEY \ + --rpc-url $ETH_RPC_URL +``` + +### Deploying a single contract +All functions for deploying a single contract are public, meaning that +All functions for deploying a single contract are public, meaning that +the `--sig` argument to forge script can be used to target the deployment of a +single contract. + +## Best Practices + +Production users should deploy their L1 contracts from a contracts release. +All contracts releases are on git tags with the following format: +`op-contracts/vX.Y.Z`. If you're deploying a new standard chain, you should +deploy the [Multi-Chain Prep (MCP) L1 release](https://github.com/ethereum-optimism/optimism/releases/tag/op-contracts%2Fv1.3.0). +We're working on writing more documentation to prepare OP Stack chain operators +to run a fault proof chain effectively. + +## Next Steps + +* Learn how to [create your genesis file](/builders/chain-operators/deploy/genesis) +* See all [configuration options](/builders/chain-operators/configuration/rollup) and example configurations diff --git a/pages/builders/chain-operators/management/_meta.json b/pages/builders/chain-operators/management/_meta.json index d37c43c2b..ec1a79d5a 100644 --- a/pages/builders/chain-operators/management/_meta.json +++ b/pages/builders/chain-operators/management/_meta.json @@ -1,9 +1,9 @@ { - "configuration": "Configuration", "blobs": "Using Blobs", "snap-sync": "Using Snap Sync", "custom-gas-token": "Run a Custom Gas Token Chain", "operations": "Node Operations", "key-management": "Key Management", - "troubleshooting": "Troubleshooting" + "troubleshooting": "Troubleshooting", + "best-practices": "Best Practices" } diff --git a/pages/builders/chain-operators/management/best-practices.mdx b/pages/builders/chain-operators/management/best-practices.mdx new file mode 100644 index 000000000..25dd42d7a --- /dev/null +++ b/pages/builders/chain-operators/management/best-practices.mdx @@ -0,0 +1,47 @@ +--- +title: Chain Operator Best Practices +lang: en-US +description: Learn some best practices for managing the OP Stack's off-chain components. +--- + +import { Callout } from 'nextra/components' + +# Chain Operator Best Practices + +The following information has some best practices around running the OP Stack's +off-chain components. + +## Correct Release Versions + +Chain and node operators should always run the latest production releases of +the OP Stack's off chain components. Our latest releases, notes, and changelogs +can be found on GitHub. `op-node` releases can be found [here](https://github.com/ethereum-optimism/optimism/releases) +and `op-geth` releases can be found [here](https://github.com/ethereum-optimism/op-geth/releases). + +* Production releases are always tags, versioned as + `/v`. For example, an `op-node` release might be + versioned as `op-node/v1.7.5`. +* Tags of the form `v`, such as `v1.7.7`, indicate releases of all + Go code only, and **DO NOT** include smart contracts. +* In the monorepo, this means these `v` releases contain all `op-*` + components, and exclude all `contracts-*` components. +* `op-geth` embeds upstream geth's version inside its own version as follows: + `vMAJOR.GETH_MAJOR GETH_MINOR GETH_PATCH.PATCH`. Basically, geth's version is + our minor version. For example, if geth is at `v1.12.0`, the corresponding + `op-geth` version would be `v1.101200.0`. Note that we pad out to three + characters for the geth minor version and two characters for the geth patch + version. Since we cannot left-pad with zeroes, the geth major version is not + padded. + +## Incremental Upgrade Rollouts + +When upgrading your nodes, take a staggered approach. This means deploying the +upgrade gradually across your infrastructure and ensuring things work as +expected before making changes to every node. + +## Isolate Your Sequencer + +You can isolate your sequencer node, by not connecting it directly to the +internet. Instead, you could handle your ingress traffic behind a proxy. Have +the proxy forward traffic to replicas and have them gossip the transactions +internally. diff --git a/pages/builders/chain-operators/management/blobs.mdx b/pages/builders/chain-operators/management/blobs.mdx index e362e4545..066e9c818 100644 --- a/pages/builders/chain-operators/management/blobs.mdx +++ b/pages/builders/chain-operators/management/blobs.mdx @@ -23,7 +23,7 @@ This guide walks you through how to switch to using blobs for your chain after E The first step to switching to submit data with Blobs is to calculate the scalar values you wish to set for the formula to charge users fees. To determine the scalar values to use for your chain, you can utilize this [fee parameter calculator](https://docs.google.com/spreadsheets/d/12VIiXHaVECG2RUunDSVJpn67IQp9NHFJqUsma2PndpE/edit) - to get a better estimate for scalar values on your chain. Input the average transaction per day your chain is processing, the types of transactions that occur on your chain, the [`OP_BATCHER_MAX_CHANNEL_DURATION`](https://docs.optimism.io/builders/chain-operators/management/configuration#setting-your--op_batcher_max_channel_duration) you have parameterized on your `op-batcher`, and the target margin you wish to charge users on top of your L1 costs. The following + to get a better estimate for scalar values on your chain. Input the average transaction per day your chain is processing, the types of transactions that occur on your chain, the [`OP_BATCHER_MAX_CHANNEL_DURATION`](/builders/chain-operators/configuration/batcher#setting-your--op_batcher_max_channel_duration) you have parameterized on your `op-batcher`, and the target margin you wish to charge users on top of your L1 costs. The following information is tuned to a network like OP Mainnet. For more details on fee scalar, see [Transaction Fees, Ecotone section](/stack/transactions/fees#ecotone). @@ -98,8 +98,8 @@ This guide walks you through how to switch to using blobs for your chain after E Steps to configure the batcher: * Configure `OP_BATCHER_DATA_AVAILABILITY_TYPE=blobs`. The batcher will have to be restarted for it to take effect. - * Ensure your `OP_BATCHER_MAX_CHANNEL_DURATION` is properly set to maximize your fee savings. See [OP Batcher Max Channel Configuration](/builders/chain-operators/management/configuration#set-your--op_batcher_max_channel_duration) for more details. - * Optionally, you can configure your batcher to support multi-blobs. See [Multi-Blob Batcher Configuration](/builders/chain-operators/management/configuration#configure-your-multi-blob-batcher) for more details. + * Ensure your `OP_BATCHER_MAX_CHANNEL_DURATION` is properly set to maximize your fee savings. See [OP Batcher Max Channel Configuration](/builders/chain-operators/configuration/batcher#set-your--op_batcher_max_channel_duration) for more details. + * Optionally, you can configure your batcher to support multi-blobs. See [Multi-Blob Batcher Configuration](/builders/chain-operators/configuration/batcher#configure-your-multi-blob-batcher) for more details. ## Switch Back to Using Calldata @@ -141,7 +141,7 @@ blobs back to using calldata. * Configure `OP_BATCHER_DATA_AVAILABILITY_TYPE=calldata`. The batcher will have to be restarted for it to take effect. - * Ensure your `OP_BATCHER_MAX_CHANNEL_DURATION` is properly set to maximize savings. **NOTE:** While setting a high value here will lower costs, it will be less meaningful than for low throughput chains using blobs. See [OP Batcher Max Channel Configuration](/builders/chain-operators/management/configuration#set-your--op_batcher_max_channel_duration) for more details. + * Ensure your `OP_BATCHER_MAX_CHANNEL_DURATION` is properly set to maximize savings. **NOTE:** While setting a high value here will lower costs, it will be less meaningful than for low throughput chains using blobs. See [OP Batcher Max Channel Configuration](/builders/chain-operators/configuration/batcher#set-your--op_batcher_max_channel_duration) for more details. ## Other Considerations diff --git a/pages/builders/chain-operators/management/configuration.mdx b/pages/builders/chain-operators/management/configuration.mdx deleted file mode 100644 index c6cb32840..000000000 --- a/pages/builders/chain-operators/management/configuration.mdx +++ /dev/null @@ -1,193 +0,0 @@ ---- -title: Chain Configuration -lang: en-US -description: Learn how to configure your OP Stack chain using the JSON file from the Optimism repo. ---- - -import { Callout } from 'nextra/components' - -# Chain Configuration - -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 OP Stack chain deployment, look no further. - - - 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 `/packages/contracts-bedrock/deploy-config/.json`. For example, [this is the configuration file for the tutorial blockchain](https://github.com/ethereum-optimism/optimism/blob/129032f15b76b0d2a940443a39433de931a97a44/packages/contracts-bedrock/deploy-config/getting-started.json). - -### Admin addresses - -| 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 address 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 address to retain a common security model. | - -### Fee recipients - -| Key | Type | Description | Default value | -| ---------------------------- | ---------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | -| `baseFeeVaultRecipient` | L1 or L2 Address | Address that the base fees from all transactions on the L2 can be withdrawn to. | It is recommended to have a single admin address to retain a common security model. | -| `l1FeeVaultRecipient` | L1 or L2 Address | Address that the L1 data fees from all transactions on the L2 can be withdrawn to. | It is recommended to have a single admin address to retain a common security model. | -| `sequencerFeeVaultRecipient` | L1 or L2 Address | Address that the tip fees from all transactions on the L2 can be withdrawn to. | It is recommended to have a single admin address to retain a common security model. | - -### Minimum Fee Withdrawal Amounts - -| Key | Type | Description | Default value | -| ------------------------------------- | ------------- | ------------------------------------------------------------------------------------------ | ------------- | -| `baseFeeVaultMinimumWithdrawalAmount` | Number in wei | The minimum amount of ETH the `BaseFeeVault` contract must have for a fee withdrawal. | 10 ether | -| `l1FeeVaultMinimumWithdrawalAmount` | Number in wei | The minimum amount of ETH the `L1FeeVault` contract must have for a fee withdrawal. | 10 ether | -| `sequencerFeeVaultWithdrawalAmount` | Number in wei | The minimum amount of ETH the `SequencerFeeVault` contract must have for a fee withdrawal. | 10 ether | - -### Withdrawal Network - -| Key | Type | Description | Default value | -| ------------------------------------ | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------- | -| `baseFeeVaultWithdrawalNetwork` | Number representing network enum | A value of `0` will withdraw ETH to the recipient address on L1 and a value of `1` will withdraw ETH to the recipient address on L2. | | -| `l1FeeVaultWithdrawalNetwork` | Number representing network enum | A value of `0` will withdraw ETH to the recipient address on L1 and a value of `1` will withdraw ETH to the recipient address on L2. | | -| `sequencerFeeVaultWithdrawalNetwork` | Number representing network enum | A value of `0` will withdraw ETH to the recipient address on L1 and a value of `1` will withdraw ETH to the recipient address on L2. | | - -### 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, 11155111 for the Sepolia test network. [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. Must be \< = L1 block time (12 on mainnet and Sepolia) | 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 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. The `l2OutputOracleSubmissionInterval` is configurable, see the section below for guidance. - -| 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 OP 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 (4 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. | 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 the OP Stack has permissionless proposals. | | -| `l2OutputOracleChallenger` | L1 Address | Address that is allowed to challenge output proposals submitted to the `L2OutputOracle`. Will be removed when the OP Stack has permissionless challenges. | It is recommended to have a single admin address to retain a common security model. | - -#### Setting your `l2OutputOracleSubmissionInterval` - -When deploying your contracts, you can set the `l2OutputOracleSubmissionInterval` to any value you wish to save on costs (e.g., 24 hours or 12 hours). On OP mainnet, `l2OutputOracleSubmissionInterval` is set to `1800 L2 blocks = 1 hr`. -The tradeoff here is that users will only be able to prove withdrawals after an output root is posted, so users will have to submit their L2 withdrawal transaction, wait up to the number of hours in the submission interval, then prove on L1, then wait 1 week, then finalize. - - - After fault proofs are shipped to Mainnet, output roots can be submitted as infrequently as you wish, and there won't be a submission interval anymore. - - -### L1 data fee - -#### Bedrock & Regolith - -These fields apply to the cost of the [L1 data fee](/stack/transactions/fees#the-l1-data-fee) for L2 transactions prior to the Ecotone upgrade. - -| Key | Type | Description | Default value | -| ------------------------ | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | -| `gasPriceOracleOverhead` | Number | Fixed L1 gas overhead per transaction. | 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 | - -#### Ecotone - -For information on L1 Data Fee changes related to the Ecotone upgrade, visit the [Transaction Fees page](/stack/transactions/fees#ecotone). - -| Key | Type | Description | Default value | -| --------------------------------- | ------ | --------------------------------------------------------------------------------------------------- | ------------- | -| `gasPriceOracleBaseFeeScalar` | Number | Scalar applied to the Ethereum base fee in the L1 data fee cost function, given in 6 decimals. | 1000000 | -| `gasPriceOracleBlobBaseFeeScalar` | Number | Scalar applied to the Ethereum blob base fee in the L1 data fee cost function, given in 6 decimals. | 0 | - -### 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](/stack/transactions/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 OP 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 | - -### OP-Batcher Configuration - -The `op-batcher` is configurable, see the sections below for guidance. - -| Key | Type | Description | Default value | -| ----------------------------------- | ------ | ---------------------------------------------------------------------------------------------------------- | ------------- | -| `OP_BATCHER_MAX_CHANNEL_DURATION` | Number | The maximum duration of L1-blocks to keep a channel open. Set to `0` to disable. | 0 | -| `OP_BATCHER_BATCH_TYPE` | Number | The batch type. Set to `0` for SingularBatch and `1` for SpanBatch. | 0 | -| `OP_BATCHER_DATA_AVAILABILITY_TYPE` | String | The data availability type to use for submitting batches to the L1. Valid options: `calldata`, `blobs` | calldata | -| `OP_BATCHER_TARGET_NUM_FRAMES` | Number | The target number of frames to create per channel. Controls number of blobs per blob tx, if using Blob DA. | 1 | -| `OP_BATCHER_TXMGR_MIN_BASEFEE` | Number | Enforces a minimum base fee (in GWei) to assume when determining tx fees. 1 GWei by default. | 1 | -| `OP_BATCHER_TXMGR_MIN_TIP_CAP` | Number | Enforces a minimum tip cap (in GWei) to use when determining tx fees. 1 GWei by default. | 1 | -| `OP_BATCHER_RESUBMISSION_TIMEOUT` | Number | Duration to wait before resubmitting a transaction to L1. | 48s | - -#### Set Your `OP_BATCHER_MAX_CHANNEL_DURATION` - - - The default value inside `op-batcher`, if not specified, is still `0`, which means channel duration tracking is disabled. - For very low throughput chains, this would mean to fill channels until close to the sequencing window and post the channel to `L1 SUB_SAFETY_MARGIN` L1 blocks before the sequencing window expires. - - -To minimize costs, we recommend setting your `OP_BATCHER_MAX_CHANNEL_DURATION` to target 5 hours, with a value of `1500` L1 blocks. When non-zero, this parameter is the max time (in L1 blocks, which are 12 seconds each) between which batches will be submitted to the L1. If you have this set to 5 for example, then your batcher will send a batch to the L1 every 5\*12=60 seconds. When using blobs, because 130kb blobs need to be purchased in full, if your chain doesn't generate at least \~130kb of data in those 60 seconds, then you'll be posting only partially full blobs and wasting storage. - -* We do not recommend setting any values higher than targeting 5 hours, as batches have to be submitted within the sequencing window which defaults to 12 hours for OP chains, otherwise your chain may experience a 12 hour long chain reorg. 5 hours is the longest length of time we recommend that still sits snugly within that 12 hour window to avoid affecting stability. -* If your chain fills up full blobs of data before the `OP_BATCHER_MAX_CHANNEL_DURATION` elapses, a batch will be submitted anyways - (e.g. even if the OP Mainnet batcher sets an `OP_BATCHER_MAX_CHANNEL_DURATION` of 5 hours, it will still be submitting batches every few minutes) - - - While setting an`OP_BATCHER_MAX_CHANNEL_DURATION` of `1500` results in the cheapest fees, it also means that your [safe head](https://github.com/ethereum-optimism/specs/blob/main/specs/glossary.md#safe-l2-head) can stall for up to 5 hours. - - * This will negatively impact apps on your chain that rely on the safe head for operation. While many apps can likely operate simply by following the unsafe head, often Centralized Exchanges or third party bridges wait until transactions are marked safe before processing deposits and withdrawal. - * Thus a larger gap between posting batches can result in significant delays in the operation of certain types of high-security applications. - - -#### Configure Your Batcher to Use Multiple Blobs - -The `op-batcher` has the capabilities to send multiple blobs per single blob transaction. This is accomplished by the use of multi-frame channels, see the [specs](https://specs.optimism.io/protocol/derivation.html#frame-format) for more technical details on channels and frames. - -A minimal batcher configuration (with env vars) to enable 6-blob batcher transactions is: - -``` - - OP_BATCHER_BATCH_TYPE=1 # span batches, optional - - OP_BATCHER_DATA_AVAILABILITY_TYPE=blobs - - OP_BATCHER_TARGET_NUM_FRAMES=6 # 6 blobs per tx - - OP_BATCHER_TXMGR_MIN_BASEFEE=2.0 # 2 gwei, might need to tweak, depending on gas market - - OP_BATCHER_TXMGR_MIN_TIP_CAP=2.0 # 2 gwei, might need to tweak, depending on gas market - - OP_BATCHER_RESUBMISSION_TIMEOUT=240s # wait 4 min before bumping fees -``` - -This enables blob transactions and sets the target number of frames to 6, which translates to 6 blobs per transaction. -The minimum tip cap and base fee are also lifted to 2 gwei because it is uncertain how easy it will be to get 6-blob transactions included and slightly higher priority fees should help. -The resubmission timeout is increased to a few minutes to give more time for inclusion before bumping the fees because current transaction pool implementations require a doubling of fees for blob transaction replacements. - -Multi-blob transactions are particularly useful for medium to high-throughput chains, where enough transaction volume exists to fill up 6 blobs in a reasonable amount of time. -You can use [this calculator](https://docs.google.com/spreadsheets/d/12VIiXHaVECG2RUunDSVJpn67IQp9NHFJqUsma2PndpE/edit) for your chain to determine what number of blobs are right for you, and what gas scalar configuration to use. Please also refer to guide on [Using Blobs](/builders/chain-operators/management/blobs) for chain operators. diff --git a/pages/builders/chain-operators/management/custom-gas-token.mdx b/pages/builders/chain-operators/management/custom-gas-token.mdx index 1139e4f26..5b1413422 100644 --- a/pages/builders/chain-operators/management/custom-gas-token.mdx +++ b/pages/builders/chain-operators/management/custom-gas-token.mdx @@ -48,7 +48,7 @@ An OP Stack chain that uses the custom gas token feature enables an end user to * The [`v2.0.0-beta.2` release](https://github.com/ethereum-optimism/optimism/tree/op-contracts/v2.0.0-beta.2) -enables fee withdrawals to L1 and L2. For more details on these values, see the [Withdrawal Network](./configuration#withdrawal-network) +enables fee withdrawals to L1 and L2. For more details on these values, see the [Withdrawal Network](/builders/chain-operators/configuration/rollup.mdx#withdrawal-network) section of the docs. * Deploy the L1 contracts from `contracts-bedrock` using the following command: diff --git a/pages/builders/chain-operators/management/key-management.mdx b/pages/builders/chain-operators/management/key-management.mdx index 50d8b8c9b..3fc1d38e8 100644 --- a/pages/builders/chain-operators/management/key-management.mdx +++ b/pages/builders/chain-operators/management/key-management.mdx @@ -34,8 +34,9 @@ RPC method. ## Cold Wallets The addresses for the cold wallets cannot be used without human intervention. -These can be setup as multisig contracts, so they can be controlled by groups -of community members and avoid a single point of failure. +These can be set up as multisig contracts, so they can be controlled by groups +of community members and avoid a single point of failure. The signers behind a +multisig should probably also use a hardware wallet. Refer to the [privileged roles](/chain/security/privileged-roles) documentation diff --git a/pages/builders/chain-operators/self-hosted.mdx b/pages/builders/chain-operators/self-hosted.mdx index 328a6fd0f..655c55e49 100644 --- a/pages/builders/chain-operators/self-hosted.mdx +++ b/pages/builders/chain-operators/self-hosted.mdx @@ -45,7 +45,7 @@ OP Chains can be configured for throughput, cost, and other decentralization tra {

Make Standard Chain Configurations

} - * Configure your [OP Chain parameters](/builders/chain-operators/management/configuration) based on your particular tradeoffs. You'll need to configure the **rollup**, **batcher**, and **proposer** for optimal performance. + * Configure your [OP Chain parameters](/builders/chain-operators/configuration/overview) based on your particular tradeoffs. You'll need to configure the **rollup**, **batcher**, and **proposer** for optimal performance. * Update your batcher to [post transaction data within blobs](/builders/chain-operators/management/blobs) instead of call data to maximize your fee savings. * Enable [snap sync](/builders/chain-operators/management/snap-sync) on your OP Chain to significantly improve the experience and speed of syncing an OP Stack node. diff --git a/pages/builders/chain-operators/tutorials/create-l2-rollup.mdx b/pages/builders/chain-operators/tutorials/create-l2-rollup.mdx index ef92bb63a..2b9e8a891 100644 --- a/pages/builders/chain-operators/tutorials/create-l2-rollup.mdx +++ b/pages/builders/chain-operators/tutorials/create-l2-rollup.mdx @@ -21,6 +21,10 @@ You don't want to miss any important steps that might cause issues down the line This tutorial is **designed for developers** who want to learn about the OP Stack by spinning up an OP Stack testnet chain. You'll walk through the full deployment process and teach you all of the components that make up the OP Stack, and **you'll end up with your very own OP Stack testnet**. +It's useful to understand what each of these components does before +you start deploying your chain. To learn about the different components please +read the [deployment overview page](/builders/chain-operators/deploy/overview). + You can use this testnet to experiment and perform tests, or you can choose to modify the chain to adapt it to your own needs. **The OP Stack is free and open source software licensed entirely under the MIT license**. You don't need permission from anyone to modify or deploy the stack in any configuration you want. @@ -30,58 +34,6 @@ Modifications to the OP Stack may prevent a chain from being able to benefit fro Make sure to check out the [Superchain Explainer](/stack/explainer) to learn more. -## What You're Going to Deploy - -When deploying an OP Stack chain, you'll be setting up four different components. -It's useful to understand what each of these components does before you start deploying your chain. - -### Smart Contracts - -The OP Stack gives you the ability to deploy your own Rollup chains that use a Layer 1 blockchain to host and order transaction data. -OP Stack chains use several smart contracts on the L1 blockchain to manage aspects of the Rollup. -Each OP Stack chain has its own set of L1 smart contracts that are deployed when the chain is created. -You'll be using the L1 Bedrock smart contracts found in the [`contracts-bedrock` package](https://github.com/ethereum-optimism/optimism/tree/op-contracts/v1.0.0/packages/contracts-bedrock) within the [Optimism Monorepo](https://github.com/ethereum-optimism/optimism). - - - You should only use governance approved and audited smart contracts. - The monorepo has them tagged with the following pattern `op-contracts/vX.X.X` - and you can review the release notes for details on the changes. Read more - about the details on our [Smart Contract Overview](/stack/protocol/rollup/smart-contracts). - - -### Sequencer Node - -OP Stack chains use Sequencer nodes to gather proposed transactions from users and publish them to the L1 blockchain. -Vanilla (unmodified) OP Stack chains rely on at least one of these Sequencer nodes, so you'll have to run one. -You can also run additional non-Sequencer nodes if you'd like (not included in this tutorial). - -#### Consensus Client - -OP Stack nodes, like Ethereum nodes, have a consensus client. -The consensus client is responsible for determining the list and ordering of blocks and transactions that are part of your blockchain. -Several implementations of the OP Stack consensus client exist, including `op-node` (maintained by Optimism Foundation), [`magi`](https://github.com/a16z/magi) (maintained by a16z) and [`hildr`](https://github.com/optimism-java/hildr) (maintained by OptimismJ). -In this tutorial you'll be using the [`op-node` implementation](https://github.com/ethereum-optimism/optimism/tree/v1.1.4/op-node) found within the [Optimism Monorepo](https://github.com/ethereum-optimism/optimism). - -#### Execution Client - -OP Stack nodes, like Ethereum nodes, also have an execution client. -The execution client is responsible for executing transactions and storing/updating the state of the blockchain. -Various implementations of the OP Stack execution client exist, including `op-geth` (maintained by Optimism Foundation), [`op-erigon`](https://github.com/testinprod-io/op-erigon) (maintained by Test in Prod), and `op-nethermind` (coming soon). -In this tutorial you'll be using the [`op-geth` implementation](https://github.com/ethereum-optimism/op-geth) found within the [`op-geth` repository](https://github.com/ethereum-optimism/op-geth). - -### Batcher - -The Batcher is a service that publishes transactions from the Sequencer to the L1 blockchain. -The Batcher runs continuously alongside the Sequencer and publishes transactions in batches (hence the name) on a regular basis. -You'll be using the [`op-batcher` implementation](https://github.com/ethereum-optimism/optimism/tree/v1.1.4/op-batcher) of the Batcher component found within the [Optimism Monorepo](https://github.com/ethereum-optimism/optimism). - -### Proposer - -The Proposer is a service responsible for publishing transactions *results* (in the form of L2 state roots) to the L1 blockchain. -This allows smart contracts on L1 to read the state of the L2, which is necessary for cross-chain communication and reconciliation between state changes. -It's likely that the Proposer will be removed in the future, but for now it's a necessary component of the OP Stack. -You'll be using the [`op-proposer` implementation](https://github.com/ethereum-optimism/optimism/tree/v1.1.4/op-proposer) of the Proposer component found within the [Optimism Monorepo](https://github.com/ethereum-optimism/optimism). - ## Software Dependencies | Dependency | Version | Version Check Command | diff --git a/pages/builders/node-operators/releases.mdx b/pages/builders/node-operators/releases.mdx index f80efd0c9..1edc492c4 100644 --- a/pages/builders/node-operators/releases.mdx +++ b/pages/builders/node-operators/releases.mdx @@ -1,26 +1,40 @@ --- title: Node Software Releases lang: en-US -description: This page lists required versions of the node software and how to stay up to date. +description: Off chain node software release information and how to stay up to date. --- import { Callout } from 'nextra/components' # Node Software Releases -This page lists required versions of the node software. +This page gives information on the off chain node software release information. Our latest releases, notes, and changelogs can be found on GitHub. `op-node` releases can be found [here](https://github.com/ethereum-optimism/optimism/releases) and `op-geth` releases can be found [here](https://github.com/ethereum-optimism/op-geth/releases). -## Minimum Required Version by Network +## Production Releases -These are the minimal required versions for the `op-node` and `op-geth` by network. It is always -recommended to run the latest stable releases found on the GitHub release pages. +Chain and node operators should always run the latest production releases of +the OP Stack's off chain components. Production releases are always tags, +versioned as `/v`. For example, an `op-node` release +might be versioned as `op-node/v1.7.5`. Tags of the form `v`, such as +`v1.7.6`, indicate releases of all Go code only, and DO NOT include smart +contracts. This naming scheme is required by Golang. In the above list, this +means these `v` releases contain all `op-*` components, and exclude +all `contracts-*` components. -| Network | op-node | op-geth | -| ---------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | -| OP Mainnet | [v1.7.7](https://github.com/ethereum-optimism/optimism/releases/tag/op-node%2Fv1.7.7) | [v1.101315.2](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101315.2) | -| OP Sepolia | [v1.7.7](https://github.com/ethereum-optimism/optimism/releases/tag/op-node%2Fv1.7.7) | [v1.101315.2](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101315.2) | +`op-geth` embeds upstream geth's version inside its own version as follows: +`vMAJOR.GETH_MAJOR GETH_MINOR GETH_PATCH.PATCH`. Basically, geth's version is +our minor version. For example, if geth is at `v1.12.0`, the corresponding +`op-geth` version would be `v1.101200.0`. Note that we pad out to three +characters for the geth minor version and two characters for the geth patch +version. Since we cannot left-pad with zeroes, the geth major version is not +padded. + +| Network | op-node | op-geth | +| ---------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | +| OP Mainnet | [v1.7.7](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.7) | [v1.101315.2](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101315.2) | +| OP Sepolia | [v1.7.7](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.7) | [v1.101315.2](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101315.2) | diff --git a/public/_redirects b/public/_redirects index 11bcca253..5f25c7b17 100644 --- a/public/_redirects +++ b/public/_redirects @@ -77,3 +77,4 @@ /builders/node-operators/overview /builders/node-operators/rollup-node /builders/notices/ecotone-changes /stack/transactions/fees#ecotone /stack/protocol/fault-proofs/overview /stack/protocol/fault-proofs/explainer +/builders/chain-operators/management/configuration /builders/chain-operators/configuration/overview diff --git a/words.txt b/words.txt index 95b0e0a2c..9754248c7 100644 --- a/words.txt +++ b/words.txt @@ -14,6 +14,7 @@ Arweave authrpc Badgeholder's Badgeholders +basefee BGEZ BGTZ Biconomy @@ -28,6 +29,7 @@ blocklogs BLOCKPROFILERATE blockprofilerate Blockscout +blocktime BLOOMFILTER bloomfilter BLTZ @@ -37,6 +39,7 @@ BOOTNODES Bootnodes bootnodes bottlenecked +brotli Brotli Callouts callouts @@ -49,6 +52,7 @@ chaosnet Clabby codebases collateralized +compr COMPUTEPENDINGBLOCK computependingblock confs @@ -141,6 +145,7 @@ journalremotes JSPATH jspath jwtsecret +Keccak leveldb lightkdf logfile @@ -233,10 +238,12 @@ Predeployed predeployed predeploys Preimage +preimage PREIMAGES preimages Preinstalls preinstalls +Prestate prestate PRICEBUMP pricebump @@ -261,10 +268,12 @@ replayability reproven REQUIREDBLOCKS requiredblocks +Rollouts Rollups rpckind RPCPREFIX rpcprefix +rpcs RPGF Rpgf rpgf @@ -309,6 +318,7 @@ timeseries trustlessly trustrpc txfeecap +txmgr TXPOOL txpool Unprotect