From 150fd658e8353f489f7735d79fdf54ac33f90af7 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Mon, 13 Jan 2025 18:37:36 +0100 Subject: [PATCH 1/9] improved lychee --- lychee.toml | 34 +++++++++++-------- .../chain-operators/tools/op-deployer.mdx | 2 +- pages/builders/tools/build/nft-tools.mdx | 1 - pages/builders/tools/build/oracles.mdx | 8 ++--- .../assets/transfer-superchainERC20.mdx | 6 ++-- pages/stack/interop/message-passing.mdx | 6 ++-- pages/stack/interop/supersim.mdx | 2 +- 7 files changed, 32 insertions(+), 27 deletions(-) diff --git a/lychee.toml b/lychee.toml index 73b34c1e3..020972dde 100644 --- a/lychee.toml +++ b/lychee.toml @@ -1,18 +1,19 @@ ############################# Display ############################# - -# Verbose program output -verbose = "info" - +# Use error level to only show failed requests +verbose = "error" # Don't show interactive progress bar while checking links. no_progress = true +# Don't show the source file of links +no_show_source = true ############################# Requests ############################ - # URL remapping rules. remap = [ - "file:///(.*?)/pages/img/(.*) file:///$1/public/img/$2", - "file:///(.*?)/pages/resources/(.*) file:///$1/public/resources/$2", - "file:///([^#.?]+)(#.*)?$ file:///$1.mdx$2", + "file:///(.*?)/img/(.*) file:///$1/public/img/$2", + "file:///(.*?)/icons/(.*) file:///$1/public/icons/$2", + "file:///(.*?)/resources/(.*) file:///$1/public/resources/$2", + "file:///(.*?)/audit-reports/(.*) file:///$1/public/audit-reports/$2", + "file:///([^#.?]+)(#.*)?$ file:///$1.mdx$2", "\\\\& &" ] @@ -20,13 +21,10 @@ remap = [ base = "./pages" ############################# Exclusions ########################## - # Exclude loopback IP address range and localhost from checking. exclude_loopback = true - # Exclude all mail addresses from checking. exclude_mail = true - # Exclude RPC URLs from checking. exclude = [ 'https://mainnet.optimism.io', @@ -37,8 +35,16 @@ exclude = [ 'https://web.archive.org', 'https://mainnet.base.org', 'https://sepolia.base.org', - 'https://optimism.easscan.org' + 'https://optimism.easscan.org', + '\.(pdf|zip|png|jpg|jpeg|gif|svg)$' +] + +# Accept all status codes except 404 +accept = [ + "100..=399", + "401..=403", + "405..=999" ] -# Accept these status codes -accept = ["100..=103", "200..=299", "403..=403", "502..=502"] \ No newline at end of file +# Use compact format for cleaner output +format = "compact" \ No newline at end of file diff --git a/pages/builders/chain-operators/tools/op-deployer.mdx b/pages/builders/chain-operators/tools/op-deployer.mdx index 0a814a46e..c611d27a6 100644 --- a/pages/builders/chain-operators/tools/op-deployer.mdx +++ b/pages/builders/chain-operators/tools/op-deployer.mdx @@ -101,7 +101,7 @@ op-deployer apply --workdir .deployer --l1-rpc-url --private-key - The transfer isn't complete until the message is successfully relayed on the destination chain. See the [technical reference guide](https://supersim.pages.dev/guides/interop/manually-relaying-interop-messages-cast) for specific relay instructions. + The transfer isn't complete until the message is successfully relayed on the destination chain. See the [technical reference guide](https://supersim.pages.dev/guides/interop/viem?#viem-to-send-and-relay-interop-messages) for specific relay instructions. ### Step 4: Verify completion @@ -103,13 +103,13 @@ sequenceDiagram 3. The tokens should now be available for use on the destination chain -For detailed technical instructions including contract addresses, specific commands, and message relaying details, refer to our [technical reference guide](https://supersim.pages.dev/guides/interop/manually-relaying-interop-messages-cast). +For detailed technical instructions including contract addresses, specific commands, and message relaying details, refer to our [technical reference guide](https://supersim.pages.dev/guides/interop/viem?#viem-to-send-and-relay-interop-messages). ## Alternative methods You can also use: -* [viem bindings/actions](https://supersim.pages.dev/guides/interop/relay-using-viem) for TypeScript integration +* [viem bindings/actions](https://supersim.pages.dev/guides/interop/viem) for TypeScript integration ## Next steps diff --git a/pages/stack/interop/message-passing.mdx b/pages/stack/interop/message-passing.mdx index 3be6ed39c..af661135b 100644 --- a/pages/stack/interop/message-passing.mdx +++ b/pages/stack/interop/message-passing.mdx @@ -48,7 +48,7 @@ Cross-chain messaging involves four main phases: 4. **Message Execution**: The destination chain receives and processes the message, executing any associated actions or state changes specified in the original message. -For detailed implementation steps and code examples, see our [message passing implementation guide](https://supersim.pages.dev/guides/interop/relay-using-viem.html). +For detailed implementation steps and code examples, see our [message passing implementation guide](https://supersim.pages.dev/guides/interop/viem). ## Common Use Cases @@ -57,10 +57,10 @@ For detailed implementation steps and code examples, see our [message passing im * Cross-chain state synchronization * Token transfers and bridging -For a practical example, see our [cross-chain ping pong tutorial](https://supersim.pages.dev/guides/interop/cross-chain-contract-via-l2cdm). +For a practical example, see our [cross-chain ping pong tutorial](https://supersim.pages.dev/guides/interop/cross-chain-contract-calls-pingpong). ## Next steps * Read about the [anatomy of a cross-chain message](/stack/interop/cross-chain-message) * Try [Supersim](supersim) for testing cross-chain messages locally -* Learn about [manually relaying messages](https://supersim.pages.dev/guides/interop/manually-relaying-interop-messages-cast) +* Learn about [manually relaying messages](https://supersim.pages.dev/guides/interop/viem?#viem-to-send-and-relay-interop-messages) diff --git a/pages/stack/interop/supersim.mdx b/pages/stack/interop/supersim.mdx index 674485a66..5bc896d51 100644 --- a/pages/stack/interop/supersim.mdx +++ b/pages/stack/interop/supersim.mdx @@ -57,5 +57,5 @@ This diagram illustrates how developers interact with Supersim through the CLI, ## Next steps * Check out the dedicated [Supersim docs](https://Supersim.pages.dev/) for tutorials and specific use cases. -* Questions about Interop? Check out the FAQ section in the [Superchain Interop Explainer](/stack/interop/explainer#faqs) or check out this [Superchain interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). +* Questions about Interop? Check out the FAQ section in the [Superchain Interop Explainer](/stack/interop/explainer.mdx#faqs) or check out this [Superchain interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). * For more info about how Superchain interoperability works under the hood, [check out the specs](https://specs.optimism.io/interop/overview.html). From 4a7168c0c38fe2eab78a1090f877a7ee711c208d Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Mon, 13 Jan 2025 18:51:51 +0100 Subject: [PATCH 2/9] update internal links --- lychee.toml | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/lychee.toml b/lychee.toml index 020972dde..c6d12ae72 100644 --- a/lychee.toml +++ b/lychee.toml @@ -9,16 +9,18 @@ no_show_source = true ############################# Requests ############################ # URL remapping rules. remap = [ - "file:///(.*?)/img/(.*) file:///$1/public/img/$2", - "file:///(.*?)/icons/(.*) file:///$1/public/icons/$2", - "file:///(.*?)/resources/(.*) file:///$1/public/resources/$2", - "file:///(.*?)/audit-reports/(.*) file:///$1/public/audit-reports/$2", - "file:///([^#.?]+)(#.*)?$ file:///$1.mdx$2", + # First handle the resource paths relative to pages directory + "file:///(.*?)/img/(.*) file:///./$1/public/img/$2", + "file:///(.*?)/icons/(.*) file:///./$1/public/icons/$2", + "file:///(.*?)/resources/(.*) file:///./$1/public/resources/$2", + "file:///(.*?)/audit-reports/(.*) file:///./$1/public/audit-reports/$2", + # Then handle the internal links for mdx files + "file:///([^#.?]+)(#.*)?$ file:///./pages/$1.mdx$2", "\\\\& &" ] -# Base URL or website root directory to check relative URLs. -base = "./pages" +# Base URL or website root directory to check relative URLs +base = "." ############################# Exclusions ########################## # Exclude loopback IP address range and localhost from checking. From 0ed0f49512f6ffef16f3b4cc7a173980ca423528 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Mon, 13 Jan 2025 19:51:52 +0100 Subject: [PATCH 3/9] Narrowed down the lychee rule --- lychee.toml | 21 ++++++++++++------- .../builders/chain-operators/self-hosted.mdx | 6 +++--- pages/builders/tools/build/oracles.mdx | 4 ++-- 3 files changed, 18 insertions(+), 13 deletions(-) diff --git a/lychee.toml b/lychee.toml index c6d12ae72..f3c5399f3 100644 --- a/lychee.toml +++ b/lychee.toml @@ -9,13 +9,14 @@ no_show_source = true ############################# Requests ############################ # URL remapping rules. remap = [ - # First handle the resource paths relative to pages directory - "file:///(.*?)/img/(.*) file:///./$1/public/img/$2", - "file:///(.*?)/icons/(.*) file:///./$1/public/icons/$2", - "file:///(.*?)/resources/(.*) file:///./$1/public/resources/$2", - "file:///(.*?)/audit-reports/(.*) file:///./$1/public/audit-reports/$2", - # Then handle the internal links for mdx files - "file:///([^#.?]+)(#.*)?$ file:///./pages/$1.mdx$2", + # Handle URL-encoded anchors (%23) first + "file:///([^%]+)%23(.*) file:///./pages/$1.mdx#$2", + # Handle regular anchors + "file:///([^#]+)#(.*) file:///./pages/$1.mdx#$2", + # Handle the resource paths relative to pages directory + + # Handle regular files without anchors + "file:///([^#%]+) file:///./pages/$1.mdx", "\\\\& &" ] @@ -49,4 +50,8 @@ accept = [ ] # Use compact format for cleaner output -format = "compact" \ No newline at end of file +format = "compact" + +############################# Anchors ############################# +# Enable checking for anchors in local files +check_anchors = true \ No newline at end of file diff --git a/pages/builders/chain-operators/self-hosted.mdx b/pages/builders/chain-operators/self-hosted.mdx index 31dc22ac9..f206a840f 100644 --- a/pages/builders/chain-operators/self-hosted.mdx +++ b/pages/builders/chain-operators/self-hosted.mdx @@ -22,8 +22,8 @@ There are two main steps to get started building your own self-hosted OP Chain: * **Chain Architecture**: OP Chains use execution and consensus clients as well as the OP Stack's privileged roles. For more details, see the [Chain Architecture](/builders/chain-operators/architecture) guide. * **Smart Contracts**: OP 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](/stack/smart-contracts#layer-1-contracts), - [L2 predeploy contracts](/stack/smart-contracts#layer-2-contracts-predeploys), + set of [L1 smart contracts](/stack/smart-contracts), + [L2 predeploy contracts](/stack/smart-contracts), and [L2 preinstall contracts](/builders/chain-operators/features/preinstalls) that are deployed when the chain is created. * **Preinstalls**: OP Chains come with [preinstalled core contracts](/builders/chain-operators/features/preinstalls), making them usable as soon as a chain is initialized on the OP Stack. @@ -56,7 +56,7 @@ OP Chains can be configured for throughput, cost, and other decentralization tra {

Set Public RPC Endpoint

} - * Set the [public RPC Endpoint](/builders/chain-operators/architecture#ingress-traffic), so your OP Chain can handle large volumes of RPC requests from your users. + * Set the [public RPC Endpoint](/builders/chain-operators/architecture), so your OP Chain can handle large volumes of RPC requests from your users. {

Enable Analytics for Onchain Data

} diff --git a/pages/builders/tools/build/oracles.mdx b/pages/builders/tools/build/oracles.mdx index 277c8c03e..8b45115e0 100644 --- a/pages/builders/tools/build/oracles.mdx +++ b/pages/builders/tools/build/oracles.mdx @@ -115,10 +115,10 @@ Ready to integrate? Head over to the [Gelato VRF Quick Start Guide](https://docs The Pyth Network is a financial oracle network which delivers over 400 low-latency, high-fidelity price feeds across cryptocurrencies, FX pairs, equities, ETFs, and commodities. * Pyth's price data is sourced from over [95 first-party sources](https://pyth.network/publishers) including exchanges, market makers, and financial services providers. -* Pyth [Price Feeds](https://pyth.network/price-feeds) offer both the real-time spot price of the asset as well as an accompanying confidence interval band around that price +* Pyth [Price Feeds](https://www.pyth.network/developers/price-feed-ids) offer both the real-time spot price of the asset as well as an accompanying confidence interval band around that price * The Pyth [TradingView](https://docs.pyth.network/guides/how-to-create-tradingview-charts) integration allows users to view and display Pyth prices on their own website and UI. -You can explore the full catalog of Pyth Price Feed IDs for [OP Mainnet and Sepolia (EVM Stable)](https://pyth.network/developers/price-feed-ids#pyth-evm-stable). +You can explore the full catalog of Pyth Price Feed IDs for [OP Mainnet and Sepolia (EVM Stable)](https://www.pyth.network/developers/price-feed-ids). * Pyth Entropy allows developers to quickly and easily generate secure random numbers on the blockchain. More details [here](https://pyth.network/blog/secure-random-numbers-for-blockchains) From 16d4477047d527d14abdeda835e802cebe0e1b29 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Tue, 14 Jan 2025 16:29:22 +0100 Subject: [PATCH 4/9] clear errors --- lychee.toml | 21 +- .../transactions/parameters.mdx | 2 +- .../transactions/troubleshooting.mdx | 1 - .../tools/chain-monitoring.mdx | 4 +- pages/chain/security/privileged-roles.mdx | 2 +- pages/connect/resources/glossary.mdx | 184 +++++++++--------- pages/stack/transactions/fees.mdx | 2 +- 7 files changed, 107 insertions(+), 109 deletions(-) diff --git a/lychee.toml b/lychee.toml index f3c5399f3..9c8c225bb 100644 --- a/lychee.toml +++ b/lychee.toml @@ -9,15 +9,14 @@ no_show_source = true ############################# Requests ############################ # URL remapping rules. remap = [ - # Handle URL-encoded anchors (%23) first - "file:///([^%]+)%23(.*) file:///./pages/$1.mdx#$2", - # Handle regular anchors - "file:///([^#]+)#(.*) file:///./pages/$1.mdx#$2", - # Handle the resource paths relative to pages directory - - # Handle regular files without anchors - "file:///([^#%]+) file:///./pages/$1.mdx", - "\\\\& &" + # Handle resource files without adding .mdx extension + "file:///pages/(.*?)\\.(pdf|png|jpg|jpeg|gif|svg|json)$ file:///./pages/$1.$2", + # Handle URL-encoded anchors (%23) for mdx files + "file:///([^%\\.]+)%23(.*) file:///./pages/$1.mdx#$2", + # Handle regular anchors (#) for mdx files + "file:///([^#\\.]+)#(.*) file:///./pages/$1.mdx#$2", + # Handle regular mdx files without anchors + "file:///([^#%\\.]+)$ file:///./pages/$1.mdx", ] # Base URL or website root directory to check relative URLs @@ -28,7 +27,7 @@ base = "." exclude_loopback = true # Exclude all mail addresses from checking. exclude_mail = true -# Exclude RPC URLs from checking. +# Exclude RPC URLs from checking exclude = [ 'https://mainnet.optimism.io', 'https://mainnet-sequencer.optimism.io', @@ -39,7 +38,7 @@ exclude = [ 'https://mainnet.base.org', 'https://sepolia.base.org', 'https://optimism.easscan.org', - '\.(pdf|zip|png|jpg|jpeg|gif|svg)$' + '\.(pdf|zip|png|jpg|jpeg|gif|svg|json)$' ] # Accept all status codes except 404 diff --git a/pages/builders/app-developers/transactions/parameters.mdx b/pages/builders/app-developers/transactions/parameters.mdx index 22e450911..1f1da0aa2 100644 --- a/pages/builders/app-developers/transactions/parameters.mdx +++ b/pages/builders/app-developers/transactions/parameters.mdx @@ -42,7 +42,7 @@ From the block, retrieve the `baseFeePerGas` and `gasUsed` fields. OP Mainnet adjusts the base fee based on the amount of gas used in the previous block. If the previous block used more than 5m gas (of the 30m gas limit), then the base fee will increase by up to 10%. If the previous block used less than 5m gas, then the base fee will decrease by up to 10%. -Refer to the [OP Mainnet EIP-1559 Parameters](/chain/differences#eip-1559-parameters) section for more details. +Refer to the [OP Mainnet EIP-1559 Parameters](/stack/differences#eip-1559-parameters) section for more details. {

Select a base fee per gas

} diff --git a/pages/builders/app-developers/transactions/troubleshooting.mdx b/pages/builders/app-developers/transactions/troubleshooting.mdx index 2a40d74e4..9ab4daeb4 100644 --- a/pages/builders/app-developers/transactions/troubleshooting.mdx +++ b/pages/builders/app-developers/transactions/troubleshooting.mdx @@ -22,7 +22,6 @@ We have a workaround that users and wallet operators can implement immediately, Set the maximum fee per gas for transactions to a relatively high value, such as 0.1 gwei. This will *not* increase the transaction cost because the same base fee, determined by a formula, is charged to all the transactions in the block. -[See here for more details](/builders/cex-wallet-developers/wallet-support#base-fee). To save on the cost of L2 gas you want to minimize the max priority fee. Also, if the [current base fee](https://optimistic.grafana.net/public-dashboards/c84a5a9924fe4e14b270a42a8651ceb8?orgId=1&refresh=5m) is comparable to 0.1 gwei or higher, you might want to suggest to users a higher multiple of the base fee than you would on L1 Ethereum because it can grow faster in the time interval between transaction creation and transaction signing and submission. diff --git a/pages/builders/chain-operators/tools/chain-monitoring.mdx b/pages/builders/chain-operators/tools/chain-monitoring.mdx index 14da3c81b..1dac6ef35 100644 --- a/pages/builders/chain-operators/tools/chain-monitoring.mdx +++ b/pages/builders/chain-operators/tools/chain-monitoring.mdx @@ -97,13 +97,13 @@ To enable metrics, pass the `--metrics.enabled` flag to the op-geth. You can cus To enable metrics, pass the `--metrics.enabled` flag to the op-proposer. You can customize the metrics port and address via the `--metrics.port` and `--metrics.addr` flags, respectively. -You can find more information about these flags in our [Proposer configuration doc](https://docs.optimism.io/builders/chain-operators/configuration/proposer#metricsenabled). +You can find more information about these flags in our [Proposer configuration doc](/builders/chain-operators/configuration/proposer#metricsenabled). ### `op-batcher` To enable metrics, pass the `--metrics.enabled` flag to the op-batcher. You can customize the metrics port and address via the `--metrics.port` and `--metrics.addr` flags, respectively. -You can find more information about these flags in our [Batcher configuration doc](https://docs.optimism.io/builders/chain-operators/configuration/batcher#metricsenabled). +You can find more information about these flags in our [Batcher configuration doc](/builders/chain-operators/configuration/proposer#metricsenabled). ### `op-challenger` diff --git a/pages/chain/security/privileged-roles.mdx b/pages/chain/security/privileged-roles.mdx index 040d2b940..afc4ab129 100644 --- a/pages/chain/security/privileged-roles.mdx +++ b/pages/chain/security/privileged-roles.mdx @@ -33,7 +33,7 @@ The L1 Proxy Admin is an address that can be used to upgrade most OP Mainnet sys ## L2 Proxy Admin -The L2 Proxy Admin is an address that can be used to upgrade most OP Mainnet system contracts on L2. The L2 Proxy Admin owner is the [aliased address](/chain/differences#address-aliasing) of the L1ProxyAdmin owner, which means the L2 ProxyAdmin Owner is equal to the L1 ProxyAdmin Owner, but due to aliasing it's a different address. Here's how that works: +The L2 Proxy Admin is an address that can be used to upgrade most OP Mainnet system contracts on L2. The L2 Proxy Admin owner is the [aliased address](/stack/differences#address-aliasing) of the L1ProxyAdmin owner, which means the L2 ProxyAdmin Owner is equal to the L1 ProxyAdmin Owner, but due to aliasing it's a different address. Here's how that works: * Given an L1 contract address, the aliased L2 address is equal to `L1_contract_address` + `0x1111000000000000000000000000000000001111`. * Using `0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b` as an example, the `0x6B` address is the L2 address that's been aliased, so to figure out the original L1 address you calculate `0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b` - `0x1111000000000000000000000000000000001111`. diff --git a/pages/connect/resources/glossary.mdx b/pages/connect/resources/glossary.mdx index c5a56d8af..e854e770b 100644 --- a/pages/connect/resources/glossary.mdx +++ b/pages/connect/resources/glossary.mdx @@ -19,35 +19,35 @@ The glossary provides definitions of important terminology used throughout the O ## General terms -#### Address aliasing +### Address aliasing When a contract submits a [deposit](#deposit) from L1 to L2, it's address (as returned by `ORIGIN` and `CALLER`) will be aliased with a modified representation of the address of a contract. -#### Block +### Block A sequential list of transactions, along with a couple of properties stored in the '''header''' of the block; can refer to an [L1](#layer-1-l1) block, or to an [L2](#layer-2-l2) block, which are structured similarly. It is useful to distinguish between input block properties, which are known before executing the transactions in the block, and output block properties, which are derived after executing the block's transactions (e.g., [Merkle Patricia Trie roots](#merkle-patricia-trie)). -#### Block time +### Block time L2 block time is 2 seconds, meaning there is an L2 block at every 2s [time slot](#time-slot). *Post-merge*, it could be said that L1 block time is 12s as that is the L1 [time slot](#time-slot). However, in reality the block time is variable as some time slots might be skipped. Pre-merge, the L1 block time is variable, though it is on average 13s. -#### Delegation +### Delegation Refers to the process of assigning the voting power of your tokens to a designated community member, known as a delegate. Delegates are individuals who have volunteered to actively participate in the governance of the Optimism Token House. By delegating your voting power, you enable these delegates to vote on governance matters on your behalf, while you retain full ownership of your tokens and the freedom to use them as you wish. You can also change your chosen delegate at any time, allowing for flexibility in how your voting power is represented in the governance process. -#### EOA or externally owned account +### EOA or externally owned account Ethereum term to designate addresses operated by users, as opposed to contract addresses. -#### Execution engine +### Execution engine Responsible for executing transactions in blocks and computing the resulting state roots, receipts roots, and block hash. Both L1 (*post-merge*) and L2 have an execution engine. On L1, the executed blocks can @@ -55,38 +55,38 @@ come from L1 block synchronization or from a block freshly minted by the executi at the request of the L1 consensus layer. On L2, the executed blocks are freshly minted by the execution engine at the request of the [rollup node](#rollup-node), using transactions [derived from L1 blocks](#l2-chain-derivation). -#### Optimism collective +### Optimism collective The Optimism Collective is a band of people, projects, and companies working together to build a better economy for everyone, united by a mutually beneficial pact to adhere to the axiom of impact=profit — the principle that positive impact to the collective should be rewarded with profit to the individual. New model of digital democratic governance optimized to drive rapid and sustained growth of a decentralized ecosystem. -#### OP token +### OP token A governance token, referred to as "OP." Content should not discuss the token price or speculate on the price, and content that refers to OP incorrectly will be removed from Optimism platforms and will not be eligible for promotion. -#### Layer 1 (L1) +### Layer 1 (L1) Refers the Ethereum blockchain, used in contrast to [layer 2](#layer-2-l2), which refers to Optimism. -#### Layer 2 (L2) +### Layer 2 (L2) Refers to the Optimism blockchain and is used in contrast to [layer 1](#layer-1-l1), which refers to the Ethereum blockchain. -#### L2 output root +### L2 output root 32 byte value which serves as a commitment to the current state of the L2 chain. -#### L2 output oracle contract +### L2 output oracle contract L1 contract to which [L2 output roots](#l2-output-root) are posted by the [sequencer](#sequencer). -#### Predeployed contract +### Predeployed contract A contract placed in the L2 genesis state (i.e. at the start of the chain). -#### PGA or priority gas auction +### PGA or priority gas auction Transactions in ethereum are ordered by the price that the transaction pays to the miner. Priority Gas Auctions (PGAs) occur when multiple parties are competing to be the first transaction in a block. Each party continuously @@ -95,44 +95,44 @@ parties (like being the first deposit or submitting a deposit before there is no PGAs tend to have negative externalities on the network due to a large amount of transactions being submitted in a very short amount of time. -#### Receipt +### Receipt The output generated by a transaction, comprising a status code, the amount of gas used, a list of log entries, and a [bloom filter](https://en.wikipedia.org/wiki/Bloom_filter) indexing these entries. Log entries are most notably used to encode Solidity events. Receipts are not stored in blocks, but blocks store a [Merkle Patricia Trie root](#merkle-patricia-trie) for a tree containing the receipt for every transaction in the block. -#### Rollup Node +### Rollup Node The node responsible for [deriving the L2 chain](#l2-chain-derivation) from the L1 chain (L1 [blocks](#block) and their associated [receipts](#receipt). The rollup node can run either in *[validator](#validator-mode)* or *[sequencer](#sequencer-mode)* mode. -#### Sequencer mode +### Sequencer mode The rollup node receives L2 transactions from users, which it uses to create L2 blocks. These are then submitted to a [data availability provider](#data-availability-provider) via [batch submission](#batch-submission). The L2 chain derivation then acts as a sanity check and a way to detect L1 chain re-orgs. -#### Time slot +### Time slot On L2, there is a block every 2 seconds (this duration is known as the [block time](#block-time)). We say that there is a "time slot" every multiple of 2s after the timestamp of the [L2 genesis block](#l2-genesis-block). On L1, post-merge, the time slots are every 12s. However, an L1 block may not be produced for every time slot, in case of even benign consensus issues. -#### Transaction Type +### Transaction Type Ethereum provides a mechanism as described in [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) for defining different transaction types. Different transaction types can contain different payloads and be handled differently by the protocol. -#### Validator +### Validator An entity (individual or organization) that runs a [rollup node](#rollup-node) in validator mode. Doing so grants a lot of benefits similar to running an Ethereum node, such as the ability to simulate L2 transactions locally, without rate limiting. It also lets the validator verify the work of the [sequencer](#sequencer), by re-deriving [output roots](#l2-output-root) and comparing them against those submitted by the sequencer. In case of a mismatch, the validator can perform a [fault proof](#fault-proof). -#### Validator mode +### Validator mode The rollup node performs derivation as indicated in sequencer mode, but is also able to "run ahead" of the L1 chain by getting blocks directly from the sequencer, in which case derivation serves to validate the sequencer's @@ -142,40 +142,40 @@ behavior. A rollup node running in validator mode is sometimes called *a replica ## OP profile & identity -#### Attestations +### Attestations Statements or evidence of information made by anyone about anything. -#### Attestation recipient +### Attestation recipient The entity or individual that receives the [attestation](#attestations) from the attester. In decentralized identity, the attestation recipient can be a service provider, website, or any other entity that requires verification of a person's identity or personal information. -#### Attestation issuer +### Attestation issuer The entity or individual that performs the attestation process and issues the [attestation](#attestations). In decentralized identity, the attestation issuer can be a government agency, financial institution, or any other trusted entity that is authorized to verify a person's identity or personal information. -#### Attestation verifier +### Attestation verifier The entity or individual that verifies the [attestation](#attestations) and ensures that it is valid and accurate. In decentralized identity, the attestation verifier can be a service provider, website, or any other entity that requires verification of a person's identity or personal information. -#### Decentralized identity +### Decentralized identity A system that enables individuals to have greater control and ownership over their personal data and identity. In decentralized identity, personal information is stored on a blockchain or other decentralized system, and individuals have the ability to grant or revoke access to their data as they see fit. This allows for greater privacy, security, and control over personal information. -#### Ethereum attestation service (EAS) +### Ethereum attestation service (EAS) An Ethereum infrastructure public good for making attestations on or off-chain about anything. -#### Sybil-resistance +### Sybil-resistance A defense mechanism that prevents someone from creating multiple fake identities in a decentralized identity system. -#### Web of trust +### Web of trust A decentralized model used to establish trust among participants in a network. It relies on the concept of participants vouching for the authenticity or trustworthiness of other participants. In a web of trust, trust is built through the accumulation of attestations from trusted individuals. @@ -183,93 +183,93 @@ A decentralized model used to establish trust among participants in a network. I ## OP Stack & OP Superchain -#### Attestation-based fault proof +### Attestation-based fault proof A fault proof where challenges can be successfully made by supplying an [attestation proof](#attestation-proof) which disagrees with the original withdrawal claim. -#### Attestation-based validity proof +### Attestation-based validity proof A validity proof which can be verified by supplying an [attestation proof](#attestation-proof) which agrees with the withdrawal claim. -#### Attestation proof +### Attestation proof A proof which consists of some number of signatures from a pre-agreed upon set of chain attestors. -#### Cannon fault proof +### Cannon fault proof A fault proof where challenges are evaluated using an onchain game which is guaranteed to result in a truthful outcome, given economic rationality assumptions. -#### Chain +### Chain A state [transition system](https://en.wikipedia.org/wiki/Transition_system) consisting of an initial state, a state transition function, and a list of inputs (transactions)—which is cryptographically committed to and can be independently replicated with commodity computer hardware and internet connection. -#### Chain proof +### Chain proof Difficult to forge evidence of the validity of a particular withdrawal claim. Proofs are commonly used to enable chains to communicate with each other. -#### Challenge period +### Challenge period The window of time in which a challenge can be made to disprove a fault proof. -#### Fault proof +### Fault proof A proof which relies on the absence of counter-evidence to prove correctness. -#### L1 origin +### L1 origin the L1 origin of an L2 block is the L1 block corresponding to its [sequencing epoch](#sequencing-epoch). -#### Merkle patricia trie +### Merkle patricia trie sparse [trie](https://en.wikipedia.org/wiki/Trie), which is a tree-like structure that maps keys to values. The root hash of a MPT is a commitment to the contents of the tree, which allows a proof to be constructed for any key-value mapping encoded in the tree. Such a proof is called a Merkle proof, and can be verified against the Merkle root. -#### Modular proof +### Modular proof The ability to use multiple proof systems for the same OP Chain. For instance, it should be possible to prove an OP Chain using a fault proof or a validity proof. -#### Modular sequencing +### Modular sequencing The ability to configure the sequencer address during OP Chain deployment. This value can be configured by the OP Chain deployer. -#### OP Chain +### OP Chain An individual chain within the Optimism Superchain. All chains, regardless of their specific properties are considered OP Chains if they are officially governed by the Optimism Collective, and therefore part of the Superchain. -#### OP Mainnet +### OP Mainnet Layer 2 blockchain powered by the OP Stack. Previously known as just "Optimism,"OP Mainnet is where it all started, and the first chain to commit to the Superchain vision. -#### OP Stack +### OP Stack the modular, open source, MIT-licensed development stack that powers the OP Mainnet, OP Chains, and, in the future, the Superchain. The OP Stack is maintained by the Optimism Collective. -#### OP Stack Fork +### OP Stack Fork Layer 2 blockchain that has been built using the MIT-licensed OP Stack, but is not governed by Optimism's governance or contributing sequencer revenue back to the Collective (and therefore is not on track to become part of the Superchain). This means OP Stack Forks won't necessarily share security or interoperability with OP Chains in the Superchain. -#### Plasma Chain +### Plasma Chain A chain where transaction data is committed to on L1 but not supplied to L1 directly, with a data availability challenge fallback. -#### Rollup Chain +### Rollup Chain A chain where all transaction data is submitted to L1. -#### Rollup transactions +### Rollup transactions Rollup transactions can be included in two ways: through a [deposited transaction](#deposited-transaction) enforced by the system and through a regular transaction embedded in a [sequencer batch](#sequencer-batch). Submitting transactions for inclusion in a batch saves costs by reducing overhead, and enables the sequencer to pre-confirm the transactions before the L1 confirms the data. -#### Sequencer +### Sequencer The specific entity or smart contract which has priority when submitting transactions to an OP Chain, can be either a [rollup node](#rollup-node) run in sequencer mode or the operator of this rollup node. The sequencer receives L2 transactions from L2 users, creates L2 blocks using them, which it then submits to [data availability provider](#data-availability-provider) (via a [batcher](#batcher)). It also submits [output roots](#l2-output-root) to L1. -#### Sequencing Window +### Sequencing Window Range of L1 blocks from which a [sequencing epoch](#sequencing-epoch) can be derived. A sequencing window whose first L1 block has number `N` contains [batcher transactions](#batcher-transaction) for epoch @@ -278,29 +278,29 @@ The current default `SWS` is 3600 epochs. Additionally, the first block in the window defines the [depositing transactions](#depositing-transaction) which determine the [deposits](#deposit) to be included in the first L2 block of the epoch. -#### Sequencing Epoch +### Sequencing Epoch sequential range of L2 blocks derived from a [sequencing window](#sequencing-window) of L1 blocks. Each epoch is identified by an epoch number, which is equal to the block number of the first L1 block in the sequencing window. Epochs can have variable size, subject to some constraints. -#### Superchain +### Superchain A decentralized blockchain platform which consists of many chains that share security and a technology stack (OP Stack). The interoperability and standardization enables individual chains to be treated identically by tools and wallets. -#### Superchain Bridge +### Superchain Bridge The L1 bridge contracts which govern all OP Chains in the Superchain. This bridge can be upgraded by the Optimism Collective. -#### Validity Proof +### Validity Proof A proof of a withdrawal claim which can be immediately validated, without a challenge period. -#### Withdrawal Claim +### Withdrawal Claim A claim about the state of one chain made on another chain. For instance, I can claim that in OP Mainnet I have burned my tokens with the intent to withdraw those tokens back to L1. -#### Zero Knowledge Proof +### Zero Knowledge Proof A validity proof which relies on cryptographic properties and low error margins. @@ -308,20 +308,20 @@ A validity proof which relies on cryptographic properties and low error margins. ## Protocol -#### Batcher +### Batcher Software component (independent program) that is responsible to make channels available on a data availability provider. The batcher communicates with the rollup node in order to retrieve the channels. The channels are then made available using [batcher transactions](#batcher-transaction). -#### Batcher Transaction +### Batcher Transaction Transaction submitted by a [batcher](#batcher) to a data availability provider, in order to make channels available. These transactions carry one or more full frames, which may belong to different channels. A channel's frame may be split between multiple batcher transactions. When submitted to Ethereum calldata, the batcher transaction's receiver must be the sequencer inbox address. The transaction must also be signed by a recognized batch submitter account. -#### Channel +### Channel Sequence of [sequencer batches](#sequencer-batch) (for sequential blocks) compressed together; uniquely identified by its timestamp (UNIX time at which the channel was created) and a random value. The reason to group multiple batches together is simply to obtain @@ -332,13 +332,13 @@ a better compression rate, hence reducing data availability costs. * On the side of the [rollup node](#rollup-node) (which is the consumer of channels), a channel is considered to be *opened* if its final frame (explicitly marked as such) has not been read, or closed otherwise. -#### Channel Frame +### Channel Frame Chunk of data belonging to a [channel](#channel). [Batcher transactions](#batcher-transaction) carry one or multiple frames. The reason to split a channel into frames is that a channel might be too large to include in a single batcher transaction. -#### Channel Timeout +### Channel Timeout Duration (in L1 blocks) during which [channel frames](#channel-frame) may land on L1 within [batcher transactions](#batcher-transaction). The acceptable time range for the frames of a [channel](#channel) is `[channel_id.timestamp, channel_id.timestamp + @@ -355,7 +355,7 @@ of the channel are seen, or else these frames are ignored.) channels. This is particularly relevant during L1 re-orgs. -#### Data Availability +### Data Availability Guarantee that some data will be "available" (i.e. *retrievable*) during a reasonably long time window. In Optimism's case, the data in question are [sequencer batches](#sequencer-batch) that [validators](#validator) @@ -363,17 +363,17 @@ need in order to verify the sequencer's work and validate the L2 chain. The [fin should be taken as the lower bound on the availability window, since that is when data availability is the most crucial, as it is needed to perform a [fault proof](#fault-proof). "Availability" **does not** mean guaranteed long-term storage of the data. -#### Data Availability Provider +### Data Availability Provider Service that can be used to make [data available](#data-availability). Ideally, a good data availability provider provides strong *verifiable* guarantees of data availability, such as Ethereum call data and EIP4844. -#### Deposit +### Deposit L2 transaction derived from an L1 block (by the rollup driver). While transaction deposits are notably (but not only) used to "deposit" (bridge) ETH and tokens to L2, the word *deposit* should be understood as "a transaction *deposited* to L2 from L1". -#### Deposit contract +### Deposit contract L1 contract to which [EOAs](#eoa-or-externally-owned-account) and contracts may send deposits. The deposits are emitted as log records (in Solidity, these are called *events*) for consumption by [rollup nodes](#rollup-node). @@ -384,91 +384,91 @@ emitted as log records (in Solidity, these are called *events*) for consumption [Merkle Patricia Trie roots](#merkle-patricia-trie) included in the L1 block. -#### Deposited Transaction +### Deposited Transaction L2 transaction that was derived from L1 and included in a L2 block. There are two kinds of deposited transactions: L1 attributes deposited transaction (submits the L1 block's attributes to the L1 Attributes Predeployed Contract) and User deposited transactions (transactions derived from an L1 call to the deposit contract). -#### Depositor +### Depositor L1 address (contract or \[EOA]) that makes (is the `msg.sender` of) the [depositing call](#depositing-call). The *depositor* is **NOT** the originator of the [depositing transaction](#depositing-transaction) (i.e. `tx.origin`). -#### Depositing Call +### Depositing Call L1 call to the deposit contract, which will be derived to a [user-deposited transaction](#user-deposited-transaction) by the rollup driver. This call specifies all the data (destination, value, calldata, ...) for the deposited transaction. -#### Depositing Transaction +### Depositing Transaction L1 transaction that makes one or more [depositing calls](#depositing-call). -#### Deposited transaction type +### Deposited transaction type EIP-2718 transaction type, which specifies the input fields and correct handling of a deposited transaction. -#### Event or log data +### Event or log data Data generated by the [depositing call](#depositing-call) and read by the rollup driver to derive the [deposited transaction](#deposited-transaction). -#### Finalized L2 Head +### Finalized L2 Head Highest L2 block that can be derived from *finalized* L1 blocks — i.e. L1 blocks older than two L1 epochs (64 L1 [time slots](#time-slot)). -#### Finalization Period +### Finalization Period The minimum amount of time (in seconds) that must elapse before a withdrawal can be finalized, sometimes called **withdrawal delay**. The finalization period is necessary to afford sufficient time for validators to make a fault proof. -#### L1 Attributes Deposited Transaction +### L1 Attributes Deposited Transaction A [deposited transaction](#deposited-transaction) that is used to register the L1 block attributes (number, timestamp, ...) on L2 via a call to the [L1 Attributes Predeployed Contract](#l1-attributes-predeployed-contract). That contract can then be used to read the attributes of the L1 block corresponding to the current L2 block. -#### L1 Attributes Predeployed Contract +### L1 Attributes Predeployed Contract A [predeployed contract](#predeployed-contract) on L2 that can be used to retrieve the L1 block attributes of L1 blocks with a given block number or a given block hash. -#### L2 Chain Derivation +### L2 Chain Derivation The process that reads [L2 derivation inputs](#l2-derivation-inputs) from L1 in order to derive the L2 chain. -#### L2 Chain Inception +### L2 Chain Inception L1 block number at which the output roots for the [genesis block](#l2-genesis-block) were proposed on the [output oracle](#l2-output-oracle-contract) contract. In the current implementation, this is the L1 block number at which the output oracle contract was deployed or upgraded. -#### L2 Derivation Inputs +### L2 Derivation Inputs Data that is found in L1 blocks and is read by the [rollup node](#rollup-node) to construct [payload attributes](#payload-attributes). L2 derivation inputs include: L1 block attributes (block number, timestamp, basefee), deposits (as log data), sequencer batches (as transaction data), and system configuration updates (as log data). -#### Payload Attributes +### Payload Attributes Object that can be derived from [L2 chain derivation inputs](#l2-derivation-inputs) found on L1, which are then passed to the [execution engine](#execution-engine) to construct L2 blocks. The payload attributes object essentially encodes a [block](#block) without output properties. -#### Relayer +### Relayer EOA on L1 which finalizes a withdrawal by submitting the data necessary to verify its inclusion on L2. -#### Safe L2 Block +### Safe L2 Block L2 block that can be derived entirely from L1 by a [rollup node](#rollup-node). This can vary between different nodes, based on their view of the L1 chain. -#### Safe L2 Head +### Safe L2 Head Highest [safe L2 block](#safe-l2-block) that a [rollup node](#rollup-node) knows about. -#### Sequencer Batch +### Sequencer Batch List of L2 transactions (that were submitted to a sequencer) tagged with an [epoch number](#sequencing-epoch) and an L2 block timestamp (which can trivially be converted to a block number, given our @@ -476,48 +476,48 @@ block time is constant). Sequencer batches are part of the [L2 derivation inputs **one** L2 block (given the existing L2 chain state) — except for the first block of each epoch, which also needs information about deposits (cf. the section on [L2 derivation inputs](#l2-derivation-inputs)). -#### System Configuration +### System Configuration Collection of dynamically configurable rollup parameters maintained by the [`SystemConfig`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/L1/SystemConfig.sol) contract on L1 and read by the L2 [derivation](#l2-chain-derivation) process. These parameters enable keys to be rotated regularly and external cost parameters to be adjusted without the network upgrade overhead of a hardfork. -#### Unsafe L2 Block +### Unsafe L2 Block L2 block that a [rollup node](#rollup-node) knows about, but which was not derived from the L1 chain. In sequencer mode, this will be a block sequenced by the sequencer itself. In validator mode, this will be a block acquired from the sequencer via [unsafe sync](#unsafe-sync). -#### Unsafe L2 Head +### Unsafe L2 Head Highest [unsafe L2 block](#unsafe-l2-block) that a [rollup node](#rollup-node) knows about. -#### Unsafe Block Consolidation +### Unsafe Block Consolidation Process through which the [rollup node](#rollup-node) attempts to move the [safe L2 head](#safe-l2-head) a block forward, so that the oldest [unsafe L2 block](#unsafe-l2-block) becomes the new safe L2 head. In order to perform consolidation, the node verifies that the [payload attributes](#payload-attributes) derived from the L1 chain match the oldest unsafe L2 block exactly. -#### Unsafe Sync +### Unsafe Sync Process through which a [validator](#validator) learns about [unsafe L2 blocks](#unsafe-l2-block) from the [sequencer](#sequencer). These unsafe blocks will later need to be confirmed by the L1 chain (via [unsafe block consolidation](#unsafe-block-consolidation)). -#### User-Deposited Transaction +### User-Deposited Transaction Deposited transaction which is derived from an L1 call to the deposit contract and [depositing call](#depositing-call); explicitly excludes [L1 attributes deposited transactions](#l1-attributes-depositedtransaction). -#### Withdrawal transaction +### Withdrawal transaction Sent from L2 to L1 that may transfer data and/or value; these "transactions" exist at multiple levels (see withdrawal initiating transaction and withdrawal finalizing transaction for details). -#### Withdrawal initiating transaction +### Withdrawal initiating transaction A specific transaction on L2 sent to the Withdrawals predeploy. -#### Withdrawal finalizing transaction +### Withdrawal finalizing transaction A specific L1 transaction which finalizes and relays the withdrawal. diff --git a/pages/stack/transactions/fees.mdx b/pages/stack/transactions/fees.mdx index 0c8ed183d..cba93d183 100644 --- a/pages/stack/transactions/fees.mdx +++ b/pages/stack/transactions/fees.mdx @@ -44,7 +44,7 @@ Transactions must specify a maximum base fee higher than the block base fee to b The actual fee charged is the block base fee, even if the transaction specifies a higher maximum base fee. The OP Mainnet base fee behaves exactly like the Ethereum base fee with a few small parameter changes to account for the much shorter block times on OP Mainnet. -None of these parameters should significantly impact your application, but you can read more about each of these parameters on the [OP Mainnet differences](/chain/differences#eip-1559) page. +None of these parameters should significantly impact your application, but you can read more about each of these parameters on the [OP Mainnet differences](/stack/differences#eip-1559-parameters) page. Read more about the base fee in the [Ethereum.org documentation](https://ethereum.org/en/developers/docs/gas/#base-fee). ### Priority fee From c61aa87ccf4f311c596cc04182aff738028f0190 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Tue, 14 Jan 2025 16:49:17 +0100 Subject: [PATCH 5/9] Complete Lychee config --- pages/builders/chain-operators/features/custom-gas-token.mdx | 2 +- pages/chain/identity/about-attestations.mdx | 1 - pages/chain/identity/projects.mdx | 2 +- pages/stack/differences.mdx | 2 +- pages/stack/interop/supersim.mdx | 2 +- pages/stack/rollup/outages.mdx | 2 +- 6 files changed, 5 insertions(+), 6 deletions(-) diff --git a/pages/builders/chain-operators/features/custom-gas-token.mdx b/pages/builders/chain-operators/features/custom-gas-token.mdx index b62405f19..59064c2ee 100644 --- a/pages/builders/chain-operators/features/custom-gas-token.mdx +++ b/pages/builders/chain-operators/features/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.3` release](https://github.com/ethereum-optimism/optimism/tree/op-contracts/v2.0.0-beta.3) -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) +enables fee withdrawals to L1 and L2. For more details on these values, see the [Withdrawal Network](/builders/chain-operators/configuration/rollup#withdrawal-network) section of the docs. * Deploy the L1 contracts from `contracts-bedrock` using the following command: diff --git a/pages/chain/identity/about-attestations.mdx b/pages/chain/identity/about-attestations.mdx index 4c2bdfbba..65f4fc8b3 100644 --- a/pages/chain/identity/about-attestations.mdx +++ b/pages/chain/identity/about-attestations.mdx @@ -33,7 +33,6 @@ Attestations create log entries that become part of the permanent record of the Here are some best practices to avoid violating users' privacy: * Obtain explicit consent from users for [personal information](https://csrc.nist.gov/glossary/term/PII), which includes a user's legal name and birthdate. - Clearly [inform users](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/personal-information-what-is-it/what-is-personal-information-a-guide/) what data is being collected, why it is being collected, and how it will be used. * Sensitive data should not be stored onchain, in any way. If you need a smart contract to verify it in the future, you can use the hash of the sensitive data rather than the data itself. * Even when storing sensitive data offchain, you need to ensure it is stored securely using encryption, proper authentication and authorization, etc. diff --git a/pages/chain/identity/projects.mdx b/pages/chain/identity/projects.mdx index 98ae2a849..08272ea3b 100644 --- a/pages/chain/identity/projects.mdx +++ b/pages/chain/identity/projects.mdx @@ -22,4 +22,4 @@ All other project metadata is stored or referenced in the [Project Metadata Atte ## Further reading -For more information about identity in the Optimism Collective, see the [Identity Overview](/chain/identity/overview.mdx). +For more information about identity in the Optimism Collective, see the [Identity Overview](/chain/identity/overview). diff --git a/pages/stack/differences.mdx b/pages/stack/differences.mdx index 5f370f4b0..ceb510744 100644 --- a/pages/stack/differences.mdx +++ b/pages/stack/differences.mdx @@ -81,7 +81,7 @@ The Sequencer executes transactions from the mempool in priority fee order (high ## Chain Finality -Unlike L1s such as Ethereum, OP Stack chains have Unsafe, Safe, and Finalized Heads which indicate the state of finality for a given L2 block. Fault proofs do not impact the finalization of the L2 rollup, only the finalization of withdrawal transactions to the L1. You can read more about these [in the docs glossary](/resources/glossary#unsafe-l2-block). +Unlike L1s such as Ethereum, OP Stack chains have Unsafe, Safe, and Finalized Heads which indicate the state of finality for a given L2 block. Fault proofs do not impact the finalization of the L2 rollup, only the finalization of withdrawal transactions to the L1. You can read more about these [in the docs glossary](/connect/resources/glossary#unsafe-l2-block). ## What's Next diff --git a/pages/stack/interop/supersim.mdx b/pages/stack/interop/supersim.mdx index 5bc896d51..674485a66 100644 --- a/pages/stack/interop/supersim.mdx +++ b/pages/stack/interop/supersim.mdx @@ -57,5 +57,5 @@ This diagram illustrates how developers interact with Supersim through the CLI, ## Next steps * Check out the dedicated [Supersim docs](https://Supersim.pages.dev/) for tutorials and specific use cases. -* Questions about Interop? Check out the FAQ section in the [Superchain Interop Explainer](/stack/interop/explainer.mdx#faqs) or check out this [Superchain interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). +* Questions about Interop? Check out the FAQ section in the [Superchain Interop Explainer](/stack/interop/explainer#faqs) or check out this [Superchain interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). * For more info about how Superchain interoperability works under the hood, [check out the specs](https://specs.optimism.io/interop/overview.html). diff --git a/pages/stack/rollup/outages.mdx b/pages/stack/rollup/outages.mdx index 4f20970e9..70faa381c 100644 --- a/pages/stack/rollup/outages.mdx +++ b/pages/stack/rollup/outages.mdx @@ -83,7 +83,7 @@ As a security measure, transactions sent via the `OptimismPortal` are indistingu Transactions triggered via the `OptimismPortal` contract will appear to have been sent by the L1 address that triggered the transaction **unless** the transaction was sent by a smart contract. L2 transactions sent by smart contracts via the `OptimismPortal` contract will appear to have been sent by an "aliased" version of the smart contract's address. -Refer to the [address aliasing](/chain/differences#address-aliasing) explainer for more information about address aliasing. +Refer to the [address aliasing](/stack/differences#address-aliasing) explainer for more information about address aliasing. ### Inclusion rules From eea9d4d29c61f294186d6eab13ac7e7c4c47c4b8 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Tue, 14 Jan 2025 16:56:12 +0100 Subject: [PATCH 6/9] Update pages/connect/resources/glossary.mdx Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- pages/connect/resources/glossary.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/connect/resources/glossary.mdx b/pages/connect/resources/glossary.mdx index e854e770b..88262b47c 100644 --- a/pages/connect/resources/glossary.mdx +++ b/pages/connect/resources/glossary.mdx @@ -470,7 +470,7 @@ Highest [safe L2 block](#safe-l2-block) that a [rollup node](#rollup-node) knows ### Sequencer Batch -List of L2 transactions (that were submitted to a sequencer) tagged with an [epoch +A list of L2 transactions (that were submitted to a sequencer) tagged with an [epoch number](#sequencing-epoch) and an L2 block timestamp (which can trivially be converted to a block number, given our block time is constant). Sequencer batches are part of the [L2 derivation inputs](#l2-derivation-inputs). Each batch represents the inputs needed to build **one** L2 block (given the existing L2 chain state) — except for the first block of each epoch, which also needs From 1dd7b8b1c12764d372518cfb6d6b31b8e60cccc4 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Tue, 14 Jan 2025 17:14:18 +0100 Subject: [PATCH 7/9] fix lint issues --- pages/builders/tools/build/oracles.mdx | 3 +-- pages/chain/identity/schemas.mdx | 2 +- words.txt | 2 -- 3 files changed, 2 insertions(+), 5 deletions(-) diff --git a/pages/builders/tools/build/oracles.mdx b/pages/builders/tools/build/oracles.mdx index 8b45115e0..d9802c4a6 100644 --- a/pages/builders/tools/build/oracles.mdx +++ b/pages/builders/tools/build/oracles.mdx @@ -60,13 +60,12 @@ The L1 gas price, which can be volatile, is only pushed once every 5 minutes, an * [Blocknative](https://docs.blocknative.com/gas-prediction) provides real-time gas estimation powered by predictive modeling to forecast gas price distribution for select OP Stack chains, including OP Mainnet and Base. The [API](https://docs.blocknative.com/gas-prediction) is also available on Ethereum Mainnet to estimate base fee costs. - ### API3 The [API3 Market](https://market.api3.org/optimism) provides access to 200+ price feeds on [Optimism Mainnet](https://market.api3.org/optimism) and [Testnet](https://market.api3.org/optimism-sepolia-testnet). The price feeds operate as a native push oracle and can be activated instantly via the Market UI. The price feeds are delivered by an aggregate of [first-party oracles](https://docs.api3.org/oev-searchers/glossary.html#first-party-oracles) using signed data and support [OEV recapture](). -https://docs.api3.org/dapps/integration/security-considerations.html#oracle-extractable-value-oev +[https://docs.api3.org/dapps/integration/security-considerations.html#oracle-extractable-value-oev](https://docs.api3.org/dapps/integration/security-considerations.html#oracle-extractable-value-oev) Unlike traditional data feeds, reading [API3 price feeds](https://docs.api3.org/oev-searchers/in-depth/dapis/#dapis) enables dApps to auction off the right to update the price feeds to searcher bots which facilitates more efficient liquidation processes for users and LPs of DeFi money markets. The OEV recaptured is returned to the dApp. API3's QRNG provides dApps with truly random numbers based on quantum mechanics at no charge. More details [here](https://api3.org/) diff --git a/pages/chain/identity/schemas.mdx b/pages/chain/identity/schemas.mdx index 4e5d2ea8c..a44565c54 100644 --- a/pages/chain/identity/schemas.mdx +++ b/pages/chain/identity/schemas.mdx @@ -39,7 +39,7 @@ Used to associate metadata to an organization. Re-issued each time there is a ch | farcasterID | The Farcaster id of the individual who published the organization metadata | | name | The name of the organization | | projects | The array of projects that belong to this organization | -| parentOrgUID | The attestation UID of this organization's parent, in case it has one | +| parentOrgUID | The attestation UID of this organization's parent, in case it has one | | metadataType | How the metadata can be accessed. 1 for ipfs, 2 for http | | metadataUrl | The storage location where the metadata can be retrieved | diff --git a/words.txt b/words.txt index 61eb8abc2..19f670b5c 100644 --- a/words.txt +++ b/words.txt @@ -249,7 +249,6 @@ Openfort oplabs opnode's opstack -Opti Pausability pausable pcscdpath @@ -271,7 +270,6 @@ pprof Precommitments precommitments preconfigured -Predeploy predeploy Predeployed predeployed From b59d359fb27fd10d25dbead4d39ec39a0f8fc1a1 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Tue, 14 Jan 2025 18:45:44 +0100 Subject: [PATCH 8/9] update HTTP status codes --- lychee.toml | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/lychee.toml b/lychee.toml index 9c8c225bb..d012db1b1 100644 --- a/lychee.toml +++ b/lychee.toml @@ -4,7 +4,7 @@ verbose = "error" # Don't show interactive progress bar while checking links. no_progress = true # Don't show the source file of links -no_show_source = true +no_show_source = false ############################# Requests ############################ # URL remapping rules. @@ -41,11 +41,9 @@ exclude = [ '\.(pdf|zip|png|jpg|jpeg|gif|svg|json)$' ] -# Accept all status codes except 404 +# Accept all status codes accept = [ - "100..=399", - "401..=403", - "405..=999" + "200..=299", ] # Use compact format for cleaner output From 0072bcea685721220a85dfdb5fe025ddfcc69693 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 15 Jan 2025 14:23:36 +0100 Subject: [PATCH 9/9] updated lychee config --- lychee.toml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lychee.toml b/lychee.toml index d012db1b1..0ad13b998 100644 --- a/lychee.toml +++ b/lychee.toml @@ -41,9 +41,11 @@ exclude = [ '\.(pdf|zip|png|jpg|jpeg|gif|svg|json)$' ] -# Accept all status codes +# Accept all status codes except 404 accept = [ - "200..=299", + "100..=399", + "401..=403", + "405..=999" ] # Use compact format for cleaner output