diff --git a/.coderabbit.yaml b/.coderabbit.yaml index 7c55f0ea1..a313f94de 100644 --- a/.coderabbit.yaml +++ b/.coderabbit.yaml @@ -4,18 +4,25 @@ reviews: high_level_summary: false poem: false review_status: false - collapse_walkthrough: false + collapse_walkthrough: true + changed_files_summary: false path_instructions: - path: "**/*.mdx" instructions: | "ALWAYS review Markdown content THOROUGHLY with the following criteria: - Use proper nouns in place of personal pronouns like 'We' and 'Our' to maintain consistency in communal documentation. - Avoid gender-specific language and use the imperative form. - - Monitor capitalization for emphasis. Use **bold** for prominence instead of all caps or italics. + - Monitor capitalization for emphasis. Avoid using all caps, italics, or bold for emphasis. - Ensure proper nouns are capitalized in sentences. - Apply the Oxford comma. - - Use proper title case for headers, buttons, tab names, page names, and links. Sentence case should be used for body content and short phrases, even in links. + - Use proper title case for buttons, tab names, page names, and links. Sentence case should be used for body content and short phrases, even in links. - Use correct spelling and grammar at all times (IMPORTANT). + - For H1, H2, and H3 headers: + 1. Use sentence case, capitalizing only the first word. + 2. Preserve the capitalization of proper nouns, technical terms, and acronyms as defined in the 'nouns.txt' file located in the root directory of the project. + 3. Do not automatically lowercase words that appear in the 'nouns.txt' file, regardless of their position in the header. + - Flag any headers that seem to inconsistently apply these rules for manual review. + - When reviewing capitalization, always refer to the 'nouns.txt' file for the correct capitalization of proper nouns and technical terms specific to the project. " auto_review: enabled: true diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 4d868357f..a418fda56 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -1,16 +1,8 @@ * @ethereum-optimism/docs-reviewers -# Giving Node Squad review privileges to the following sections -/pages/builders/chain-operators/ @ethereum-optimism/docs-reviewers @ethereum-optimism/node-squad -/pages/chain/ @ethereum-optimism/docs-reviewers @ethereum-optimism/node-squad -/pages/stack/ @ethereum-optimism/docs-reviewers @ethereum-optimism/node-squad - # Giving Marine privileges to review RPC providers, account abstraction, oracles, alt-da, and block explorers /pages/builders/tools/connect/rpc-providers.mdx @ethereum-optimism/docs-reviewers @0xmariniere /pages/builders/tools/build/block-explorers.mdx @ethereum-optimism/docs-reviewers @0xmariniere /pages/builders/tools/build/oracles.mdx @ethereum-optimism/docs-reviewers @0xmariniere /pages/builders/chain-operators/features/alt-da-mode.mdx @ethereum-optimism/docs-reviewers @0xmariniere /pages/builders/tools/build/account-abstraction.mdx @ethereum-optimism/docs-reviewers @0xmariniere - -# Giving Binji privileges to review NFT tools -/pages/builders/tools/build/nft-tools.mdx @ethereum-optimism/docs-reviewers @binjix23 diff --git a/.github/ISSUE_TEMPLATE/docs_audit_results.md b/.github/ISSUE_TEMPLATE/docs_audit_results.md index 616dc0dd9..1bcbdc9c5 100644 --- a/.github/ISSUE_TEMPLATE/docs_audit_results.md +++ b/.github/ISSUE_TEMPLATE/docs_audit_results.md @@ -9,13 +9,32 @@ labels: 'docs-audit-2024-Q4,op-labs' ## Description of the updates required -> Write a description of the current state of the page. + + +### Acceptance criteria + + + +### Resources + + + +### Action items + + ## Github issue label criteria > Choose the appropriate github issue labels for each page.
+ Priority - `p-on-hold`: (Defer) Tasks that are currently not actionable due to various reasons like waiting for external inputs, dependencies, or resource constraints. These are reviewed periodically to decide if they can be moved to a more active status. @@ -23,10 +42,10 @@ labels: 'docs-audit-2024-Q4,op-labs' - `p-medium`: (Could do) Tasks that need to be done but are less critical than high-priority tasks. These often improve processes or efficiency but can be postponed if necessary without immediate severe repercussions. - `p-high`: (Should do) Important tasks that contribute significantly to long-term goals but may not have an immediate deadline. Delaying these tasks could have considerable negative effects but are not as immediate as critical tasks. - `p-critical`: Tasks that have immediate deadlines or significant consequences if not completed on time. These are non-negotiable and often linked to core business functions or legal requirements. -
+ T-shirt size - `s-XS`: (< 1 day) Very simple tasks that require minimal time and effort. @@ -34,7 +53,16 @@ labels: 'docs-audit-2024-Q4,op-labs' - `s-M`: (1-2 weeks) Tasks that involve a moderate level of complexity and collaboration. - `s-L`: (several weeks) Complex tasks that require significant time investment and coordination across multiple teams. - `s-XL`: (> 1 month) Very large and complex projects that involve extensive planning, execution, and testing. +
+
+ +Content evaluation +- `a-delete`: don't need this page +- `a-duplicate`: some content lives elsewhere +- `a-minor`: needs small revisions +- `a-moderate`: needs moderate revisions +- `a-critical`: needs a lot of work
## MDX Metadata format @@ -53,6 +81,7 @@ description: "A short description of the content."
Component tags + ``` op-node op-geth @@ -104,11 +133,13 @@ zdd-service snapman security-tools superchain-ops +op-deployer ```
Engineering tags + ``` eng-platforms eng-growth diff --git a/.github/ISSUE_TEMPLATE/suggest_attestation.yaml b/.github/ISSUE_TEMPLATE/suggest_attestation.yaml deleted file mode 100644 index 502aafe7d..000000000 --- a/.github/ISSUE_TEMPLATE/suggest_attestation.yaml +++ /dev/null @@ -1,59 +0,0 @@ -name: Suggest an attestation app -description: Suggest an attestation app for developers to use when building with Optimism -title: "[ATT] Add PR title" -labels: ["documentation,attestation,community-request"] -body: - - type: markdown - attributes: - value: | - Before submitting this suggestion, be sure to read the [listing of current attestation apps](https://docs.optimism.io/identity/applications). - - type: markdown - id: project_info - attributes: - value: "## Project Info" - - type: input - id: att_name - attributes: - label: Attestation App Name - validations: - required: true - - type: textarea - id: att_description - attributes: - label: Attestation App Description - validations: - required: true - - type: input - id: att_URL - attributes: - label: Attestation App URL - description: Please provide the URL for us to link in the project description above. - validations: - required: true - - type: input - id: att_live_date - attributes: - label: When did the product go live? - description: We prioritize products that are battle-tested. - validations: - required: true - - type: dropdown - id: att_open_source - attributes: - label: Is the product open source? - description: We prioritize open source projects when possible. - options: - - "Yes" - - "No" - validations: - required: true - - type: input - id: att_github - attributes: - label: GitHub URL - description: If the project is open source, please provide a link to the product's repo. - - type: textarea - id: att_additional_context - attributes: - label: Additional context - description: Add any other context or screenshots about the product here. diff --git a/.github/ISSUE_TEMPLATE/suggest_faucet.yaml b/.github/ISSUE_TEMPLATE/suggest_faucet.yaml deleted file mode 100644 index 4ff2eb200..000000000 --- a/.github/ISSUE_TEMPLATE/suggest_faucet.yaml +++ /dev/null @@ -1,84 +0,0 @@ -name: Suggest a faucet -description: Suggest a faucet for developers to use when building with Optimism -title: "[FAUCET] Add PR title" -labels: ["documentation,faucet,community-request"] -body: - - type: markdown - attributes: - value: | - Before submitting this suggestion, be sure to read the [listing of current Faucets](https://github.com/ethereum-optimism/developers/blob/main/community/tools/faucets.md). - - type: markdown - id: project_info - attributes: - value: "## Project Info" - - type: input - id: faucet_name - attributes: - label: Faucet Name - validations: - required: true - - type: textarea - id: faucet_description - attributes: - label: Faucet Description - validations: - required: true - - type: input - id: faucet_URL - attributes: - label: Faucet URL - description: Please provide the URL for us to link in the project description above. - validations: - required: true - - type: checkboxes - id: faucet_networks - attributes: - label: Supported Networks - options: - - label: "OP Goerli" - required: false - - label: "OP Sepolia" - required: false - - label: "Base Goerli" - required: false - - label: "Base Sepolia" - required: false - - label: "Lyra Sepolia" - required: false - - label: "Mode Sepolia" - required: false - - label: "Orderly Sepolia" - required: false - - label: "PGN Sepolia" - required: false - - label: "Zora Sepolia" - required: false - validations: - required: true - - type: input - id: faucet_live_date - attributes: - label: When did the product go live? - description: We prioritize products that are battle-tested. - validations: - required: true - - type: dropdown - id: faucet_open_source - attributes: - label: Is the product open source? - description: We prioritize open source projects when possible. - options: - - "Yes" - - "No" - validations: - required: true - - type: input - id: faucet_github - attributes: - label: GitHub URL - description: If the project is open source, please provide a link to the product's repo. - - type: textarea - id: faucet_additional_context - attributes: - label: Additional context - description: Add any other context or screenshots about the product here. diff --git a/.github/ISSUE_TEMPLATE/suggest_glossary_term.yaml b/.github/ISSUE_TEMPLATE/suggest_glossary_term.yaml index 0302b4e1a..b08efa08c 100644 --- a/.github/ISSUE_TEMPLATE/suggest_glossary_term.yaml +++ b/.github/ISSUE_TEMPLATE/suggest_glossary_term.yaml @@ -18,7 +18,7 @@ body: options: - label: This is a term not already found in the glossary (for similar terms, please consider the benefits of a new term vs updating an existing term) required: true - - label: This term/definition is not a product advertisement or contain other promotional content + - label: This term/definition is not a product advertisement and does not contain other promotional content required: true - label: This term/definition is directly relevant to Optimism required: true @@ -39,7 +39,7 @@ body: - type: textarea id: glossary_term_sources attributes: - label: Sources, if any (please do not submit copywrited content without appropriate approval) + label: Sources, if any (please do not submit copyrighted content without appropriate approval) description: Please list any sources utilized validations: required: false @@ -47,7 +47,7 @@ body: id: glossary_terms_optimismdotio_links attributes: label: Optimism.io links - description: If appropriate/available, please suggest an internal optimism.io link that would expand someones learning of this term + description: If appropriate/available, please suggest an internal optimism.io link that would expand someone's learning of this term - type: textarea id: glossary_term_additional_context attributes: diff --git a/.github/ISSUE_TEMPLATE/suggest_rpc_provider.yaml b/.github/ISSUE_TEMPLATE/suggest_rpc_provider.yaml deleted file mode 100644 index 5c1cf16c7..000000000 --- a/.github/ISSUE_TEMPLATE/suggest_rpc_provider.yaml +++ /dev/null @@ -1,79 +0,0 @@ -name: Suggest an RPC provider -description: Suggest an RPC provider for developers to use when building with Optimism -title: "[RPC PROVIDER] Add PR title" -labels: ["documentation,rpc-provider,community-request"] -body: - - type: markdown - attributes: - value: | - Before submitting this suggestion, be sure to read the [listing of current RPC and Node Providers](https://github.com/ethereum-optimism/developers/blob/main/community/tools/node-providers.md). - - type: markdown - id: project_info - attributes: - value: "## Project Info" - - type: input - id: rpc_provider_name - attributes: - label: RPC Provider Name - validations: - required: true - - type: textarea - id: rpc_provider_description - attributes: - label: RPC Provider Description & Pricing - validations: - required: true - - type: input - id: rpc_provider_URL - attributes: - label: RPC Provider URL - description: Please provide the URL for us to link in the project description above. - validations: - required: true - - type: checkboxes - id: rpc_provider_networks - attributes: - label: Supported Networks - options: - - label: "OP Mainnet" - required: false - - label: "OP Goerli" - required: false - - label: "OP Sepolia" - required: false - validations: - required: true - - type: input - id: rpc_provider_live_date - attributes: - label: When did the product go live? - description: We prioritize products that are battle-tested. - validations: - required: true - - type: dropdown - id: rpc_provider_open_source - attributes: - label: Is the product open source? - description: We prioritize open source projects when possible. - options: - - "Yes" - - "No" - validations: - required: true - - type: input - id: rpc_provider_github - attributes: - label: GitHub URL - description: If the project is open source, please provide a link to the product's repo. - - type: input - id: rpc_provider_docs - attributes: - label: Documentation URL - description: Please provide a link to the product's technical documentation. - validations: - required: true - - type: textarea - id: rpc_provider_additional_context - attributes: - label: Additional context - description: Add any other context or screenshots about the product here. diff --git a/.github/ISSUE_TEMPLATE/suggest_tutorial.yaml b/.github/ISSUE_TEMPLATE/suggest_tutorial.yaml index f8259e873..890af9b74 100644 --- a/.github/ISSUE_TEMPLATE/suggest_tutorial.yaml +++ b/.github/ISSUE_TEMPLATE/suggest_tutorial.yaml @@ -22,7 +22,7 @@ body: id: tutorial_description attributes: label: Tutorial description - description: Summarize what the user should be able to accomplish by following tutorial + description: Summarize what the user should be able to accomplish by following the tutorial validations: required: true - type: input diff --git a/.github/workflows/breadcrumbs.yml b/.github/workflows/breadcrumbs.yml new file mode 100644 index 000000000..a077cf137 --- /dev/null +++ b/.github/workflows/breadcrumbs.yml @@ -0,0 +1,32 @@ +name: Check Breadcrumbs + +on: + push: + branches: [ main ] + pull_request: + branches: [ main ] + paths: + - 'pages/**/*.mdx' + - 'pages/**/*.md' + +jobs: + check-breadcrumbs: + runs-on: ubuntu-latest + + steps: + - name: Check out code + uses: actions/checkout@v2 + + - name: Set up Node.js + uses: actions/setup-node@v2 + with: + node-version: '20.x' + + - name: Install pnpm + run: npm install -g pnpm + + - name: Install dependencies + run: pnpm install + + - name: Run breadcrumb check + run: pnpm check-breadcrumbs \ No newline at end of file diff --git a/.github/workflows/monthly-issue-metircs.yml b/.github/workflows/monthly-issue-metircs.yml index a8abad4f4..97b6ed183 100644 --- a/.github/workflows/monthly-issue-metircs.yml +++ b/.github/workflows/monthly-issue-metircs.yml @@ -41,6 +41,8 @@ jobs: token: ${{ secrets.GITHUB_TOKEN }} content-filepath: ./issue_metrics.md assignees: sbvegan + labels: | + monthly-report - name: Run issue-metrics tool for issues last month uses: github/issue-metrics@v2 diff --git a/.github/workflows/tutorials.yml b/.github/workflows/tutorials.yml index 74e8870c7..7018045f1 100644 --- a/.github/workflows/tutorials.yml +++ b/.github/workflows/tutorials.yml @@ -10,7 +10,7 @@ concurrency: cancel-in-progress: false jobs: - cross-dom-bridge-erc20: + cross-dom-bridge-eth: runs-on: ubuntu-latest steps: @@ -32,7 +32,7 @@ jobs: env: TUTORIAL_PRIVATE_KEY: ${{ secrets.TUTORIAL_PRIVATE_KEY }} run: - node ./public/tutorials/cross-dom-bridge-erc20.js + node ./public/tutorials/cross-dom-bridge-eth.js - name: Notify Slack on failure uses: ravsamhq/notify-slack-action@v2 @@ -47,8 +47,8 @@ jobs: env: SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }} - cross-dom-bridge-eth: - needs: cross-dom-bridge-erc20 + send-tx-from-eth: + needs: cross-dom-bridge-eth runs-on: ubuntu-latest steps: @@ -70,7 +70,7 @@ jobs: env: TUTORIAL_PRIVATE_KEY: ${{ secrets.TUTORIAL_PRIVATE_KEY }} run: - node ./public/tutorials/cross-dom-bridge-eth.js + node ./public/tutorials/send-tx-from-eth.js - name: Notify Slack on failure uses: ravsamhq/notify-slack-action@v2 @@ -86,7 +86,7 @@ jobs: SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }} sdk-estimate-costs: - needs: cross-dom-bridge-eth + needs: send-tx-from-eth runs-on: ubuntu-latest steps: diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 26bf56263..b7e4cd152 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -73,7 +73,7 @@ To submit your contribution for review: 1. Create a new [pull request on GitHub](https://github.com/ethereum-optimism/docs/issues/new/choose). 2. Select a PR type from the list or choose **Open a blank issue** at the bottom of the page. 3. Complete the form as requested. For blank PR issues, please provide a clear title and accurate description/context. -4. Click the "Create pull request"button to create the pull request effectively. +4. Click the "Create pull request" button to create the pull request effectively. >If your pull request is not ready for review yet, choose the "[Create draft pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request)"in the dropdown. The Optimism documentation team will review your pull request only when you mark it as "[Ready for review](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request)". diff --git a/README.md b/README.md index 62aeb0d12..8089de3dc 100644 --- a/README.md +++ b/README.md @@ -20,5 +20,5 @@ You can track documentation [issues](https://github.com/ethereum-optimism/docs/i ## License -This project is licensed under the MIT License. +This project is licensed under the [MIT License](https://github.com/ethereum-optimism/optimism/blob/develop/LICENSE). diff --git a/components/WipCallout.tsx b/components/WipCallout.tsx index ebd8590ba..ae3600044 100644 --- a/components/WipCallout.tsx +++ b/components/WipCallout.tsx @@ -1,21 +1,24 @@ /** * The WipCallout function renders a custom callout component with optional context text for * displaying maintenance messages. - * @param {Props} - The code snippet you provided is a React component named `WipCallout` that - * renders a special callout message. The component takes an optional prop `context` of type string, - * which can be used to customize the message displayed in the callout. - * @returns The WipCallout component is being returned, which is a React element representing a - * custom callout with a message. The message displayed depends on the value of the `context` prop - * passed to the component. If `context` is provided, it will display the provided context message. If - * `context` is not provided, it will display a default maintenance message. + * @param {Props} props - An object containing the optional `context` property, a string used + * to customize the message displayed in the callout. + * @returns {ReactElement} The WipCallout component, representing a custom callout message. */ import type { ReactElement } from 'react'; +import { useState } from 'react'; + interface Props { context?: string; } export function WipCallout({ context }: Props): ReactElement { + const [closeCallout, setCloseCallout] = useState(false); return ( -
+
{context ? ( context @@ -34,44 +37,78 @@ export function WipCallout({ context }: Props): ReactElement {
)}
+
); } -export function InfoCallout({ context }: Props): ReactElement { +export function InteropCallout({ context }: Props): ReactElement { + const [closeCallout, setCloseCallout] = useState(false); return ( -
+
{context ? ( context ) : (
- Interop is currently in active development and not yet ready for production use. - The information provided here may change frequently. + Interop is currently in active development and not + yet ready for production use. The information provided here may + change frequently.

- We recommend checking back - regularly for the most up-to-date information. + We recommend checking back regularly for the most up-to-date + information.

)}
+
); } -export function AltCallout({ context }: Props): ReactElement { +interface BetaCalloutProps extends Props { + featureName: string; +} + +function BetaCallout({ context, featureName }: BetaCalloutProps): ReactElement { return (
-
+
{context ? ( context ) : ( -
- The Alt-DA Mode feature is currently in Beta within the MIT-licensed OP Stack. Beta features are built and reviewed by the Optimism Collective’s core contributors, and provide developers with early access to highly requested configurations. -These features may experience stability issues, and we encourage feedback from our early users. +
+ The {featureName} feature is currently in Beta within + the MIT-licensed OP Stack. Beta features are built and reviewed by + the Optimism Collective's core contributors, and provide developers + with early access to highly requested configurations. These features + may experience stability issues, and we encourage feedback from our + early users.
)}
); } + +export function AltCallout(props: Props): ReactElement { + return ; +} + +export function CGTCallout(props: Props): ReactElement { + return ; +} diff --git a/components/calculator/ChainParametersForm.tsx b/components/calculator/ChainParametersForm.tsx new file mode 100644 index 000000000..04c7d0d35 --- /dev/null +++ b/components/calculator/ChainParametersForm.tsx @@ -0,0 +1,279 @@ +import type { ReactElement } from "react"; +import { useState } from "react"; +import { TextInput, SelectInput } from "./Inputs"; +import { ResultsParams, ResultsTable } from "./ResultsTable"; +import { + displayL1BaseFeeScalar, + displayL1BlobBaseFeeScalar, + calculateOverallL1DataAndStateCostsMargin, + calculateModeledDAPlusStateRevenueOnL2, + calculateTotalL1StateProposalCostsInETH, + determineDAInUse, + calculateImpliedDataGasFeePerTxUsingBlobs, + calculateImpliedDataGasFeePerTxUsingL1Calldata, + calculateImpliedDataGasFeePerTxUsingAltDAPlasmaMode, + resultsFeeScalarsAssumed, + impliedDataGasFee +} from "@/utils/calculator-helpers"; +import { Loader } from "./Loader"; + +type ComparableTransactionType = "Base" | "Zora" | "Mint" | "Mode"; +type DataAvailabilityType = "Ethereum" | "AltDA Plasma Mode"; + +export function ChainParametersForm(): ReactElement { + const [transactionsPerDay, setTransactionsPerDay] = useState(500000); + const [comparableTransactionType, setComparableTransactionType] = + useState("General OP Mainnet"); + const [dataAvailabilityType, setDataAvailabilityType] = useState("Ethereum"); + const [isFaultProofEnabled, setIsFaultProofEnabled] = useState("yes"); + const [targetDataFeeMargin, setTargetDataFeeMargin] = useState(5); + const [maxBlobsPerL1Transaction, setMaxBlobsPerL1Transaction] = useState(5); + const [maxChannelDuration, setMaxChannelDuration] = useState(5); + const [outputRootPostFrequency, setOutputRootPostFrequency] = useState(1 ); + const [isIncludeOutputRootCosts, setIsIncludeOutputRootCosts] = useState("yes"); + const [resultsParams, setResultsParams] = useState({}); + const [isLoading, setIsLoading] = useState(false); + const [showResult, setShowResult] = useState(false); + + const comparableTransactionTypeOptions = [ + "General OP Mainnet", + "Base", + "Zora", + "Mint", + "Mode", + ]; + const dataAvailabilityTypeOptions = ["Ethereum", "AltDA Plasma Mode"]; + const booleanOptions = ["Yes", "No"]; + + const handleSubmit = async (e: any) => { + e.preventDefault(); + setIsLoading(true); + setShowResult(false) + + //e37 + const l1BlobBaseFeeScalar = await displayL1BlobBaseFeeScalar( + stringToBoolean(isIncludeOutputRootCosts), + stringToBoolean(isFaultProofEnabled), + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTransactionType, + dataAvailabilityType, + targetDataFeeMargin + ); + + //e38 + const l1BaseFeeScalar = await displayL1BaseFeeScalar( + isIncludeOutputRootCosts, + isFaultProofEnabled, + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTransactionType, + targetDataFeeMargin, + dataAvailabilityType + ); + + // e58 + const overallL1DataAndStateCostsMargin = + await calculateOverallL1DataAndStateCostsMargin( + transactionsPerDay, + comparableTransactionType, + l1BlobBaseFeeScalar, + l1BaseFeeScalar, + dataAvailabilityType, + maxChannelDuration, + outputRootPostFrequency, + isFaultProofEnabled + ); + + //e56 + const totalL1StateProposalCostsInETH = + await calculateTotalL1StateProposalCostsInETH( + outputRootPostFrequency, + isFaultProofEnabled + ); + + // e118 + const modeledDAPlusStateRevenueOnL2 = + await calculateModeledDAPlusStateRevenueOnL2( + transactionsPerDay, + comparableTransactionType, + l1BlobBaseFeeScalar, + l1BaseFeeScalar + ); + + // e64 + const impliedDataGasFeePerTxUsingBlobs = + await calculateImpliedDataGasFeePerTxUsingBlobs( + isIncludeOutputRootCosts, + isFaultProofEnabled, + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTransactionType, + dataAvailabilityType, + targetDataFeeMargin + ); + + // e67 + const impliedDataGasFeePerTxUsingL1Calldata = + await calculateImpliedDataGasFeePerTxUsingL1Calldata( + isIncludeOutputRootCosts, + isFaultProofEnabled, + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTransactionType, + dataAvailabilityType, + targetDataFeeMargin + ); + + // e66 + const impliedDataGasFeePerTxUsingAltDAPlasmaMode = + await calculateImpliedDataGasFeePerTxUsingAltDAPlasmaMode( + isIncludeOutputRootCosts, + isFaultProofEnabled, + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTransactionType, + dataAvailabilityType, + targetDataFeeMargin + ); + + const dataAvailabilityInUse = determineDAInUse(dataAvailabilityType); + + const assumedFeeScalarMessage = resultsFeeScalarsAssumed( + comparableTransactionType, // e15 + transactionsPerDay, // e14 + dataAvailabilityType, // E16 + targetDataFeeMargin, // E18 + isIncludeOutputRootCosts, // E24 + maxChannelDuration // E22 + ); + const impliedDataGasFeeMessage = await impliedDataGasFee(dataAvailabilityType) + + const data = { + dataAvailabilityType, // e16 + l1BlobBaseFeeScalar, // e37 + l1BaseFeeScalar, // e38 + overallL1DataAndStateCostsMargin, // e58 + totalL1StateProposalCostsInETH, // e56 + modeledDAPlusStateRevenueOnL2, // e118 + dataAvailabilityInUse, // F35 + impliedDataGasFeePerTxUsingBlobs, // e64 + impliedDataGasFeePerTxUsingL1Calldata, // e67 + impliedDataGasFeePerTxUsingAltDAPlasmaMode, // e66 + assumedFeeScalarMessage, + impliedDataGasFeeMessage, + }; + setResultsParams(data); + setIsLoading(false); + setShowResult(true) + }; + + const stringToBoolean = (value: string): boolean => { + return value === "yes" || value === "Yes" ? true : false; + } + + return ( +
+
+
+

Chain Inputs

+ + + + + + + + + +
+
+

Advanced Inputs

+ + + + + +
+ +
+ {isLoading && } + {!isLoading && showResult && } +
+ ); +} diff --git a/components/calculator/Inputs/CheckboxInput.tsx b/components/calculator/Inputs/CheckboxInput.tsx new file mode 100644 index 000000000..3e63f5ac6 --- /dev/null +++ b/components/calculator/Inputs/CheckboxInput.tsx @@ -0,0 +1,31 @@ +import React from "react"; + +type Props = { + otherProps?: any; + className?: string; + label?: string; + description?:string; + handleToggle: (e: any) => void; +}; + +export const CheckboxInput: React.FC = React.memo( + ({ otherProps, label, description, className, handleToggle }) => { + function onCheckboxChange(e: any) { + const isChecked = e.target.checked; + handleToggle(isChecked); + } + return ( +
+ {label && } +

{description}

+ +
+ ); + } +); +CheckboxInput.displayName = "CheckboxInput"; diff --git a/components/calculator/Inputs/SelectInput.tsx b/components/calculator/Inputs/SelectInput.tsx new file mode 100644 index 000000000..8ed61b844 --- /dev/null +++ b/components/calculator/Inputs/SelectInput.tsx @@ -0,0 +1,51 @@ +import React from "react"; + +type Props = { + className?: string; + label?: string; + data: any[]; + otherProps?: any; + description?: string; + labelClass?: string; + onSelect?: (e: any) => void; +}; + +export const SelectInput: React.FC = React.memo( + ({ className, labelClass, description, otherProps, label, data, onSelect }) => { + const handleSelect = (e: any) => { + const value = e.target.value + onSelect(value) + } + return ( +
+ {label && ( + + )} +

+ {description} +

+
+ + {/* */} +
+
+ ); + } +); +SelectInput.displayName = "SelectInput"; diff --git a/components/calculator/Inputs/TextInput.tsx b/components/calculator/Inputs/TextInput.tsx new file mode 100644 index 000000000..65b92bf75 --- /dev/null +++ b/components/calculator/Inputs/TextInput.tsx @@ -0,0 +1,50 @@ +import React from "react"; + +type Props = { + placeholder?: string; + className?: string; + type: "text" | "email" | "password" | "number"; + label?: string; + labelClass?: string; + otherProps?: any; + description?: string; + error?: string; + isDisabled?: boolean; + onInputChange?: (e: any) => void; +}; + +export const TextInput = ({ + label, + placeholder, + className, + type, + otherProps, + isDisabled, + description, + labelClass, + onInputChange, +}: Props) => { + const handleInputChange = (e: any) => { + const val = e.target.value; + onInputChange(val); + }; + return ( +
+ {label && ( + + )} +

{description}

+ + +
+ ); +}; diff --git a/components/calculator/Inputs/index.ts b/components/calculator/Inputs/index.ts new file mode 100644 index 000000000..1447fe40e --- /dev/null +++ b/components/calculator/Inputs/index.ts @@ -0,0 +1,5 @@ +"use client"; + +export * from "./TextInput"; +export * from "./SelectInput"; +export * from "./CheckboxInput"; diff --git a/components/calculator/Loader.tsx b/components/calculator/Loader.tsx new file mode 100644 index 000000000..9e4ebbb85 --- /dev/null +++ b/components/calculator/Loader.tsx @@ -0,0 +1,66 @@ +import React from "react"; + +export const Loader: React.FC = () => { + return ( +
+ + + + + + + + + + + +
+ ); + } + +Loader.displayName = "Loader"; diff --git a/components/calculator/ResultsTable.tsx b/components/calculator/ResultsTable.tsx new file mode 100644 index 000000000..e20a0d7f8 --- /dev/null +++ b/components/calculator/ResultsTable.tsx @@ -0,0 +1,166 @@ +import { convertToMillionUnits } from "@/utils/calculator-helpers"; +import type { ReactElement } from "react"; + +export type ResultsParams = { + data: { + dataAvailabilityType: string; // e16 + l1BlobBaseFeeScalar: number; // e37 + l1BaseFeeScalar: number; // e38 + overallL1DataAndStateCostsMargin: number; // e58 + totalL1StateProposalCostsInETH: number; // e56 + modeledDAPlusStateRevenueOnL2: number; // e118 + dataAvailabilityInUse: string; // f35 + impliedDataGasFeePerTxUsingBlobs: number; // e64 + impliedDataGasFeePerTxUsingL1Calldata: number; // e67 + impliedDataGasFeePerTxUsingAltDAPlasmaMode: number; // e66, + assumedFeeScalarMessage: string; + impliedDataGasFeeMessage: string; + }; +}; + +export function ResultsTable({ + data +}: ResultsParams): ReactElement { + + const { + dataAvailabilityType, + l1BlobBaseFeeScalar, + l1BaseFeeScalar, + overallL1DataAndStateCostsMargin, + totalL1StateProposalCostsInETH, + modeledDAPlusStateRevenueOnL2, + dataAvailabilityInUse, + impliedDataGasFeePerTxUsingBlobs, + impliedDataGasFeePerTxUsingAltDAPlasmaMode, + impliedDataGasFeePerTxUsingL1Calldata, + assumedFeeScalarMessage, + impliedDataGasFeeMessage, + } = data; + + function calculateConstructionMessage( + _overallL1DataAndStateCostsMargin: number, // Corresponds to E58 + _totalL1StateProposalCostsInETH: number, // Corresponds to E56 + _modeledDAPlusStateRevenueOnL2: number // Corresponds to E118 + ): string { + const roundedE58IfNegative = + Math.round(_overallL1DataAndStateCostsMargin * -1000) / 1000; + const roundedE56 = + Math.round(_totalL1StateProposalCostsInETH * 1000) / 1000; + const roundedE58IfPositive = + Math.round(_overallL1DataAndStateCostsMargin * 1000) / 1000; + const marginPercentage = + Math.round(100 * (_overallL1DataAndStateCostsMargin / _modeledDAPlusStateRevenueOnL2) * 10) / 10; + const messageIfE58Negative = `This construction has ${roundedE58IfNegative} ETH / day of estimated State Output root costs, not covered by Data Margin (${roundedE56} ETH Total Output Root Cost / Day) at inputted Blob/L1 Gas Prices.`; + const messageIfE58Positive = `This construction is expected to have +${roundedE58IfPositive} ETH Margin on Data Costs (${marginPercentage}% Margin) at inputted L1 Gas Prices.`; + return _overallL1DataAndStateCostsMargin < 0 ? messageIfE58Negative : messageIfE58Positive + } + + function calculateDataGasFee( + _dataAvailabilityType: string, // Corresponds to E16 + _dataAvailabilityInUse: string, // Corresponds to F35 + _impliedDataGasFeePerTxUsingAltDAPlasmaMode: number, // Corresponds to E66 + _impliedDataGasFeePerTxUsingBlobs: number, // Corresponds to E64 + _impliedDataGasFeePerTxUsingL1Calldata: number // Corresponds to E67 + ): string { + let gasFee: number; + _dataAvailabilityType === "AltDA Plasma Mode" + ? (gasFee = _impliedDataGasFeePerTxUsingAltDAPlasmaMode) + : _dataAvailabilityInUse === "EIP-4844" + ? (gasFee = _impliedDataGasFeePerTxUsingBlobs) + : (gasFee = _impliedDataGasFeePerTxUsingL1Calldata); + + // Round the gas fee to 4 decimal places + const roundedGasFee = Math.round(gasFee * 10000) / 10000; + return `Implied Data Gas Fee per User Transaction: $${roundedGasFee}`; + } + + return ( +
+
+

+ {calculateConstructionMessage( + overallL1DataAndStateCostsMargin, + totalL1StateProposalCostsInETH, + modeledDAPlusStateRevenueOnL2 + )} +

+

+ {calculateDataGasFee( + dataAvailabilityType, + dataAvailabilityInUse, + impliedDataGasFeePerTxUsingAltDAPlasmaMode, + impliedDataGasFeePerTxUsingBlobs, + impliedDataGasFeePerTxUsingL1Calldata + )} +

+
+
+

Results

+ +
+

+ Fee Scalar Recommendations - Values to Set as Chain Inputs{" "} +

+

+ Recommended fee scalar configurations to achieve your target Data + Margin, given the transaction type and volume are shown below{" "} +

+

+ Note: This is an estimation,{" "} + + read how to determine scalar values using blobs + +

+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
DA Recommendation:{`${ + dataAvailabilityInUse === "EIP-4844" + ? `Blobs (EIP-4844)` + : dataAvailabilityInUse + }`}
Scalar TypeChain InputDecimal-Adjusted (6 decimals)
l1BlobBaseBaseScalar{l1BlobBaseFeeScalar}{convertToMillionUnits(l1BlobBaseFeeScalar)}
l1BaseFeeScalar{l1BaseFeeScalar}{convertToMillionUnits(l1BaseFeeScalar)}
+
+

+ Using Blobs (EIP-4844), posting transaction data will be 99.7% + cheaper than using L1 Calldata{" "} +

+
+
+

+ {assumedFeeScalarMessage} +

+

+ {impliedDataGasFeeMessage} +

+
+
+
+
+ ); +} diff --git a/content/OpProposerDescriptionShort.md b/content/OpProposerDescriptionShort.md index 08f3f9282..babd3da55 100644 --- a/content/OpProposerDescriptionShort.md +++ b/content/OpProposerDescriptionShort.md @@ -1 +1 @@ -`op-proposer` is the service that submits the output roots to the L1. This is to enable trustless execution of L2-to-L1 messaging and creates the view into the L2 state from the L1's perspective. \ No newline at end of file +`op-proposer` is the service that submits the output roots to the L1. This is to enable trustless execution of L2-to-L1 messaging and creates the view of the L2 state from the L1's perspective. diff --git a/lychee.toml b/lychee.toml index b5131db61..73b34c1e3 100644 --- a/lychee.toml +++ b/lychee.toml @@ -36,8 +36,9 @@ exclude = [ 'https://archive.org', 'https://web.archive.org', 'https://mainnet.base.org', - 'https://sepolia.base.org' + 'https://sepolia.base.org', + 'https://optimism.easscan.org' ] # Accept these status codes -accept = ["100..=103", "200..=299", "403..=403", "502..=502"] +accept = ["100..=103", "200..=299", "403..=403", "502..=502"] \ No newline at end of file diff --git a/notes/breadcrumbs.md b/notes/breadcrumbs.md new file mode 100644 index 000000000..c05467848 --- /dev/null +++ b/notes/breadcrumbs.md @@ -0,0 +1,42 @@ +# Documentation Breadcrumbs Script + +Quick guide on using our breadcrumbs automation script for the OP Stack documentation. + +## What the Script Does + +* Creates `.mdx` files for each folder (breadcrumb pages) +* Populates Card components linking to contained files +* Preserves existing descriptions that already +* Maintains consistent navigation structure + +## Using the Script + +* Breadcrumbs for the docs can be generated by running: + +```bash +pnpm breadcrumbs +``` + +* To check files with missing breadcrumbs, run: + +```bash +pnpm fix +``` + +### What to Watch For + +1. **Before Running** + * Commit your current changes + * Ensure you're in the docs root directory + * Target folders should exist: `builders`, `chain`, `stack`, `connect` + +2. **After Running** + * Review generated `.mdx` files in each folder + * Check updated descriptions, please update the description. + * Verify Card components and links + +## Common Issues + +* ***Script fails**: Ensure you're in the root directory +* **No files generated**: Check folder structure matches expected paths +* **Unexpected content**: Review git diff before committing \ No newline at end of file diff --git a/notes/content-reuse.md b/notes/content-reuse.md index d11dcbfd8..7bc43516a 100644 --- a/notes/content-reuse.md +++ b/notes/content-reuse.md @@ -10,7 +10,7 @@ The content directory contains markdown files that can be imported across the ne Create a `.md` file in the `/content` directory. -### How to Use a Single Reusable Content Components +### How to Use a Single Reusable Content Component 1. Import it at the top of `.mdx` file: diff --git a/notes/fix-redirects.md b/notes/fix-redirects.md new file mode 100644 index 000000000..fdb47fdb1 --- /dev/null +++ b/notes/fix-redirects.md @@ -0,0 +1,83 @@ +# Redirect links management guide + +## Scripts overview +Two scripts help maintain internal links when pages are redirected: + +* `check-redirects`: Identifies links that need updating based on the `_redirects` file. +* `fix-redirects`: Automatically updates links to match `_redirects` entries. + +## Checking for broken links + +Run the check script: + +```bash +pnpm lint //OR +pnpm check-redirects +``` +## What it does + +* Scans all `.mdx` files in the docs +* Compares internal links against `_redirects` file +* Reports any outdated links that need updating +* Provides a summary of total, broken, and valid links + +## Example output + +```bash +File "builders/overview.mdx" contains outdated link "/chain/overview" - should be updated to "/stack/overview" + +Summary: +Total pages πŸ” - 50 +Pages broken 🚫 - 2 +Pages OK βœ… - 48 + +``` + +## Fixing broken links + +Fix links automatically: + +```bash +pnpm fix //OR +pnpm fix-redirects +``` + +## What it does + +* Updates all internal links to match `_redirects` entries +* Preserves other content and formatting +* Shows which files and links were updated +* Provides a summary of changes made + +## Example output + +```bash +Fixed in "builders/overview.mdx": /chain/overview β†’ /stack/overview + +Summary: +Total files πŸ” - 50 +Files fixed βœ… - 2 +Files skipped ⏭️ - 48 +``` + +## Best practices + +1. Before running + + * Commit current changes + * Review `_redirects` file is up-to-date + * Run `check-redirects` first to preview changes + + +2. After running + + * Review git diff of updated files + * Test updated links locally + * Commit changes with descriptive message + + + +## Common issues + +* Script fails: Ensure `_redirects` file exists in public folder, it should always be there! +* No broken links found: Verify `_redirects` entries are correct. \ No newline at end of file diff --git a/nouns.txt b/nouns.txt new file mode 100644 index 000000000..be98afea6 --- /dev/null +++ b/nouns.txt @@ -0,0 +1,20 @@ +Optimism +OP Mainnet +Ethereum +OP Stack +MetaMask +SuperchainERC20 +ZK +Security Council +Sequencer PBS +Superchain Registry +Retro Funding +Alt-DA +Teleportr +Dev Console +Granite +Holocene +Monitorism +Kubernetes +Fault Proof System +Viem \ No newline at end of file diff --git a/package.json b/package.json index 7ea954ca7..733b523eb 100644 --- a/package.json +++ b/package.json @@ -3,11 +3,15 @@ "version": "0.0.1", "description": "Optimism Docs", "scripts": { - "lint": "eslint . --ext mdx --max-warnings 0 && pnpm spellcheck:lint", - "fix": "eslint . --ext mdx --fix && pnpm spellcheck:fix", + "lint": "eslint . --ext mdx --max-warnings 0 && pnpm spellcheck:lint && pnpm check-breadcrumbs && pnpm check-redirects", + "fix": "eslint . --ext mdx --fix && pnpm spellcheck:fix && pnpm check-breadcrumbs && pnpm fix-redirects", "spellcheck:lint": "cspell lint \"**/*.mdx\"", "spellcheck:fix": "cspell --words-only --unique \"**/*.mdx\" | sort --ignore-case | uniq > words.txt", "linkcheck": "lychee --config ./lychee.toml --quiet \"./pages\"", + "breadcrumbs":"npx ts-node --skip-project utils/create-breadcrumbs.ts", + "check-redirects": "npx ts-node --skip-project utils/redirects.ts", + "fix-redirects": "npx ts-node --skip-project utils/fix-redirects.ts", + "check-breadcrumbs":"npx ts-node --skip-project utils/breadcrumbs.ts", "index:docs": "npx ts-node --skip-project utils/algolia-indexer.ts", "dev": "next dev", "build": "next build", @@ -18,17 +22,18 @@ "@eth-optimism/contracts-ts": "^0.17.0", "@eth-optimism/tokenlist": "^9.0.9", "@feelback/react": "^0.3.4", - "@headlessui/react": "^2.1.0", + "@headlessui/react": "^2.1.8", "algoliasearch": "^4.23.3", "clsx": "^2.1.1", "escape-string-regexp": "^5.0.0", - "next": "13.5.1", + "next": "14.2.10", "next-sitemap": "^4.2.3", "nextra": "2.13.2", "nextra-theme-docs": "2.13.2", "react": "^18.2.0", "react-dom": "^18.2.0", - "search-insights": "^2.15.0" + "search-insights": "^2.15.0", + "viem": "^2.21.18" }, "devDependencies": { "@double-great/remark-lint-alt-text": "^1.0.0", diff --git a/pages/404.mdx b/pages/404.mdx index ee0616b0c..0726bb9a0 100644 --- a/pages/404.mdx +++ b/pages/404.mdx @@ -1,7 +1,7 @@ --- title: Page Not Found lang: en-US -description: 404 page not found and directs users to submit an git issue. +description: 404 page not found and directs users to submit a GitHub issue. --- # Page Not Found diff --git a/pages/_meta.json b/pages/_meta.json index 918298637..fe5e52428 100644 --- a/pages/_meta.json +++ b/pages/_meta.json @@ -1,6 +1,6 @@ { "index": { - "title": "Getting Started", + "title": "Getting started", "display": "hidden", "theme": { "breadcrumb": false, @@ -38,13 +38,13 @@ }, "faucet": { - "title": "Superchain Faucet", + "title": "Superchain faucet", "type": "page", "href": "https://console.optimism.io/faucet?utm_source=docs", "newWindow": true }, "gas": { - "title": "Gas Tracker", + "title": "Gas tracker", "type": "page", "href": "https://optimistic.grafana.net/public-dashboards/c84a5a9924fe4e14b270a42a8651ceb8?orgId=1&refresh=5m", "newWindow": true @@ -65,29 +65,29 @@ "display": "children" }, - "+++ OP MAINNET": { + "+++ OP STACK": { "title": "", "type": "separator" }, - "--- OP MAINNET": { - "title": "OP MAINNET", + "--- OP STACK": { + "title": "OP STACK", "type": "separator" }, - "chain": { - "title": "OP Mainnet", + "stack": { + "title": "OP Stack", "display": "children" }, - "+++ OP STACK": { + "+++ OP MAINNET": { "title": "", "type": "separator" }, - "--- OP STACK": { - "title": "OP STACK", + "--- OP MAINNET": { + "title": "OP MAINNET", "type": "separator" }, - "stack": { - "title": "OP Stack", + "chain": { + "title": "OP Mainnet", "display": "children" }, diff --git a/pages/builders.mdx b/pages/builders.mdx new file mode 100644 index 000000000..98f4178cf --- /dev/null +++ b/pages/builders.mdx @@ -0,0 +1,20 @@ +--- +title: Builders +lang: en-US +description: Learn about deploying contracts, cross-chain messaging, and tutorials to help you build applications on OP Mainnet. +--- + +import { Card, Cards } from 'nextra/components' + +# Builders + +Welcome to the Builders section. Here you'll find resources and guides for developers, operators, and other stakeholders involved in building on OP Stack. Explore the categories below to find the information you need. + + + + + + + + + diff --git a/pages/builders/_meta.json b/pages/builders/_meta.json index 06f702862..17ea9b121 100644 --- a/pages/builders/_meta.json +++ b/pages/builders/_meta.json @@ -1,8 +1,7 @@ { "notices": "Notices (README)", - "app-developers": "App Developers", - "chain-operators": "Chain Operators", - "node-operators": "Node Operators", - "cex-wallet-developers": "Wallets & CEXs", - "tools": "Developer Tools" + "app-developers": "App developers", + "chain-operators": "Chain operators", + "node-operators": "Node operators", + "tools": "Developer tools" } diff --git a/pages/builders/app-developers.mdx b/pages/builders/app-developers.mdx new file mode 100644 index 000000000..c5dc109d2 --- /dev/null +++ b/pages/builders/app-developers.mdx @@ -0,0 +1,27 @@ +--- +title: App Developers +description: If you're a developer looking to build on OP Stack, you've come to the right place. In this area of the Optimism Docs you'll find everything you ... +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# App Developers + +If you're a developer looking to build on OP Mainnet, you've come to the right place. In this area of the Optimism Docs you'll find everything you ... + + + + + + + + + + + + + + + + diff --git a/pages/builders/app-developers/_meta.json b/pages/builders/app-developers/_meta.json index 692b45575..b2cbaa949 100644 --- a/pages/builders/app-developers/_meta.json +++ b/pages/builders/app-developers/_meta.json @@ -1,9 +1,8 @@ { "overview": "Overview", - "quick-start": "Superchain App Quick Start", + "quick-start": "Superchain app quick start", "tutorials": "Tutorials", - "contracts": "Smart Contracts", "transactions": "Transactions", "bridging": "Bridging", - "tools": "App Tools" + "tools": "App tools" } diff --git a/pages/builders/app-developers/bridging.mdx b/pages/builders/app-developers/bridging.mdx new file mode 100644 index 000000000..893cb6db6 --- /dev/null +++ b/pages/builders/app-developers/bridging.mdx @@ -0,0 +1,21 @@ +--- +title: Bridging +lang: en-US +description: Learn about bridging basics, custom bridges, data transmission between L1 and L2, and using the standard bridge in OP Stack. +--- + +import { Card, Cards } from 'nextra/components' + +# Bridging + +This section provides information on bridging basics, custom bridges, sending data between l1 and l2 and using the standard bridge. You'll find guide, overview to help you understand and work with these topics. + + + + + + + + + + diff --git a/pages/builders/app-developers/bridging/_meta.json b/pages/builders/app-developers/bridging/_meta.json index 3c3ce0437..c6c56f200 100644 --- a/pages/builders/app-developers/bridging/_meta.json +++ b/pages/builders/app-developers/bridging/_meta.json @@ -1,6 +1,6 @@ { - "basics": "Basics of Bridging", + "basics": "Basics of bridging", "standard-bridge": "The Standard Bridge", - "custom-bridge": "Custom Token Bridges", - "messaging": "Sending Data Between L1 and L2" + "custom-bridge": "Custom token bridges", + "messaging": "Sending data between L1 and L2" } diff --git a/pages/builders/app-developers/bridging/basics.mdx b/pages/builders/app-developers/bridging/basics.mdx index 5b8edaba1..f2085f5fe 100644 --- a/pages/builders/app-developers/bridging/basics.mdx +++ b/pages/builders/app-developers/bridging/basics.mdx @@ -1,34 +1,34 @@ --- -title: Bridging Basics +title: Bridging basics lang: en-US description: Learn about the fundamentals of sending data and tokens between Ethereum and OP Mainnet. --- -# Bridging Basics +# Bridging basics OP Mainnet is a "Layer 2" system and is fundamentally connected to Ethereum. However, OP Mainnet is also a distinct blockchain with its own blocks and transactions. App developers commonly need to move data and tokens between OP Mainnet and Ethereum. This process of moving data and tokens between the two networks is called "bridging". -## Sending Tokens +## Sending tokens One of the most common use cases for bridging is the need to send ETH or ERC-20 tokens between OP Mainnet and Ethereum. OP Mainnet has a system called the [Standard Bridge](./standard-bridge) that makes it easy to move tokens in both directions. If you mostly need to bridge tokens, make sure to check out the [Standard Bridge](./standard-bridge) guide. -## Sending Data +## Sending data Under the hood, the Standard Bridge is just an application that uses the OP Mainnet [message passing system to send arbitrary data between Ethereum and OP Mainnet](./messaging). Applications can use this system to have a contract on Ethereum interact with a contract on OP Mainnet, and vice versa. All of this is easily accessible with a simple, clean API. -## Next Steps +## Next steps Ready to start bridging? Check out these tutorials to get up to speed fast. -* [Learn how to bridge ERC-20 tokens with the Optimism SDK](/builders/app-developers/tutorials/cross-dom-bridge-erc20) -* [Learn how to bridge ETH with the Optimism SDK](/builders/app-developers/tutorials/cross-dom-bridge-eth) +* [Learn how to bridge ERC-20 tokens with viem](/builders/app-developers/tutorials/cross-dom-bridge-erc20) +* [Learn how to bridge ETH with viem](/builders/app-developers/tutorials/cross-dom-bridge-eth) * [Learn how to create a standard bridged token](/builders/app-developers/tutorials/standard-bridge-standard-token) * [Learn how to create a custom bridged token](/builders/app-developers/tutorials/standard-bridge-custom-token) diff --git a/pages/builders/app-developers/bridging/custom-bridge.mdx b/pages/builders/app-developers/bridging/custom-bridge.mdx index 23ea17319..e0e60e2c4 100644 --- a/pages/builders/app-developers/bridging/custom-bridge.mdx +++ b/pages/builders/app-developers/bridging/custom-bridge.mdx @@ -1,12 +1,12 @@ --- -title: Custom Bridges +title: Custom bridges lang: en-US description: Important considerations when building custom bridges for OP Mainnet. --- import { Callout } from 'nextra/components' -# Custom Bridges +# Custom bridges Custom token bridges are any bridges other than the [Standard Bridge](./standard-bridge). You may find yourself in a position where you need to build a custom token bridge because the Standard Bridge doesn't completely support your use case. @@ -35,7 +35,7 @@ The [Superchain Token List](/chain/tokenlist) exists to help users and developer Once you've built and tested your custom bridge, make sure to register any tokens meant to flow through this bridge by [making a pull request against the Superchain Token List repository](https://github.com/ethereum-optimism/ethereum-optimism.github.io#adding-a-token-to-the-list). You **must** deploy your bridge to OP Sepolia before it can be added to the Superchain Token List. -## Next Steps +## Next steps You can explore several examples of custom bridges for OP Mainnet: diff --git a/pages/builders/app-developers/bridging/messaging.mdx b/pages/builders/app-developers/bridging/messaging.mdx index 0d8cd9e6a..c52e6642f 100644 --- a/pages/builders/app-developers/bridging/messaging.mdx +++ b/pages/builders/app-developers/bridging/messaging.mdx @@ -1,12 +1,12 @@ --- -title: Sending Data Between L1 and L2 +title: Sending data between L1 and L2 lang: en-US description: Learn how bridging works between L1 and L2, how to use it, and what to watch out for. --- import { Callout } from 'nextra/components' -# Sending Data Between L1 and L2 +# Sending data between L1 and L2 Smart contracts on L1 (Ethereum) can interact with smart contracts on L2 (OP Mainnet) through a process called "bridging". This page explains how bridging works, how to use it, and what to watch out for. @@ -16,7 +16,7 @@ This page explains how bridging works, how to use it, and what to watch out for. For a step-by-step tutorial on how to send data between L1 and L2, check out the [Solidity tutorial](/builders/app-developers/tutorials/cross-dom-solidity). -## Understanding Contract Calls +## Understanding contract calls It can be easier to understand bridging if you first have a basic understanding of how contracts on EVM-based blockchains like OP Mainnet and Ethereum communicate within the *same* network. The interface for sending messages *between* Ethereum and OP Mainnet is designed to mimic the standard contract communication interface as much as possible. @@ -57,7 +57,7 @@ Here you're using the [low-level "call" function](https://docs.soliditylang.org/ Although these two code snippets look a bit different, they're doing the exact same thing. Because of limitations of Solidity, **the OP Stack's bridging interface is designed to look like the second code snippet**. -## Basics of Communication Between Layers +## Basics of communication between layers At a high level, the process for sending data between L1 and L2 is pretty similar to the process for sending data between two contracts on Ethereum (with a few caveats). Communication between L1 and L2 is made possible by a pair of special smart contracts called the "messenger" contracts. @@ -121,17 +121,17 @@ contract MyContract { You can find the addresses of the `L1CrossDomainMessenger` and the `L2CrossDomainMessenger` contracts on OP Mainnet and OP Sepolia on the [Contract Addresses](/chain/addresses) page. -## Communication Speed +## Communication speed Unlike calls between contracts on the same blockchain, calls between Ethereum and OP Mainnet are *not* instantaneous. The speed of a cross-chain transaction depends on the direction in which the transaction is sent. -### For L1 to L2 Transactions +### For L1 to L2 transactions Transactions sent from L1 to L2 take **approximately 1-3 minutes** to get from Ethereum to OP Mainnet, or from Sepolia to OP Sepolia. This is because the Sequencer waits for a certain number of L1 blocks to be created before including L1 to L2 transactions to avoid potentially annoying [reorgs](https://www.alchemy.com/overviews/what-is-a-reorg). -### For L2 to L1 Transactions +### For L2 to L1 transactions Transactions sent from L2 to L1 take **approximately 7 days** to get from OP Mainnet to Ethereum, or from OP Sepolia to Sepolia. This is because the bridge contract on L1 must wait for the L2 state to be *proven* to the L1 chain before it can relay the message. @@ -177,9 +177,9 @@ modifier onlyOwner() { } ``` -## Fees For Sending Data Between L1 and L2 +## Fees for sending data between L1 and L2 -### For L1 to L2 Transactions +### For L1 to L2 transactions The majority of the cost of an L1 to L2 transaction comes from the smart contract execution on L1. When sending an L1 to L2 transaction, you send to the [`L1CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/L1CrossDomainMessenger.sol) contract, which then sends a call to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol) contract. @@ -195,7 +195,7 @@ The amount of L1 gas charged increases when more people are sending L1 to L2 tra You should always add a buffer of at least 20% to the gas limit for your L1 to L2 transaction to avoid running out of gas. -### For L2 to L1 Transactions +### For L2 to L1 transactions Each message from L2 to L1 requires three transactions: @@ -211,11 +211,11 @@ Each message from L2 to L1 requires three transactions: The total cost of an L2 to L1 transaction is therefore the combined cost of the L2 initialization transaction and the two L1 transactions. The L1 proof and finalization transactions are typically significantly more expensive than the L2 initialization transaction. -## Understanding the Challenge Period +## Understanding the challenge period One of the most important things to understand about L1 ⇔ L2 interaction is that **mainnet messages sent from Layer 2 to Layer 1 cannot be relayed for at least 7 days**. This means that any messages you send from Layer 2 will only be received on Layer 1 after this one week period has elapsed. -We call this period of time the "challenge period" because it is the time during which a transaction can be challenged with a [fault proof](/stack/protocol/rollup/overview#fault-proofs). +We call this period of time the "challenge period" because it is the time during which a transaction can be challenged with a [fault proof](/stack/rollup/overview#fault-proofs). Optimistic Rollups are "optimistic" because they're based around the idea of publishing the *result* of a transaction to Ethereum without actually executing the transaction on Ethereum. In the "optimistic" case, this transaction result is correct and one can completely avoid the need to perform complicated (and expensive) logic on Ethereum. diff --git a/pages/builders/app-developers/bridging/standard-bridge.mdx b/pages/builders/app-developers/bridging/standard-bridge.mdx index da23a5059..73eb844d6 100644 --- a/pages/builders/app-developers/bridging/standard-bridge.mdx +++ b/pages/builders/app-developers/bridging/standard-bridge.mdx @@ -36,7 +36,7 @@ The Standard Bridge is composed of two contracts, the [`L1StandardBridge`](https These two contracts interact with one another via the `CrossDomainMessenger` system for sending messages between Ethereum and OP Mainnet. You can read more about the `CrossDomainMessenger` in the guide on [Sending Data Between L1 and L2](./messaging). -### Bridged Tokens +### Bridged tokens The Standard Bridge utilizes bridged representations of tokens that are native to another blockchain. Before a token native to one chain can be bridged to the other chain, a bridged representation of that token must be created on the receiving side. @@ -50,7 +50,7 @@ A native token may have more than one bridged representation at the same time. Users must always specify which bridged token they wish to use when using the bridge. Different bridged representations of the same native token are considered entirely independent tokens. -### Bridging Native Tokens +### Bridging native tokens The Standard Bridge uses a "lock-and-mint" mechanism to convert native tokens into their bridged representations. This means that **native tokens are locked** into the Standard Bridge on one side, after which **bridged tokens are minted** on the other side. @@ -129,7 +129,7 @@ The process for bridging a native token involves a few steps. This process is identical in both the Ethereum to OP Mainnet and OP Mainnet to Ethereum directions. -### Bridging Non-Native Tokens +### Bridging non-native tokens The Standard Bridge uses a "burn-and-unlock" mechanism to convert bridged representations of tokens back into their native tokens. This means that **bridged tokens are burned** on the Standard Bridge on one side, after which **native tokens are unlocked** on the other side. @@ -199,8 +199,8 @@ Users simply need to trigger and send ETH to the [`bridgeETH`](https://github.co ## Tutorials -* [Learn how to bridge ERC-20 tokens with the Optimism SDK](/builders/app-developers/tutorials/cross-dom-bridge-erc20) -* [Learn how to bridge ETH with the Optimism SDK](/builders/app-developers/tutorials/cross-dom-bridge-eth) +* [Learn how to bridge ERC-20 tokens with viem](/builders/app-developers/tutorials/cross-dom-bridge-erc20) +* [Learn how to bridge ETH with viem](/builders/app-developers/tutorials/cross-dom-bridge-eth) * [Learn how to create a standard bridged token](/builders/app-developers/tutorials/standard-bridge-standard-token) * [Learn how to create a custom bridged token](/builders/app-developers/tutorials/standard-bridge-custom-token) @@ -237,7 +237,7 @@ The address of this entry is the address of the bridged representation of the to -## Special Considerations +## Special considerations ### USDC diff --git a/pages/builders/app-developers/contracts/_meta.json b/pages/builders/app-developers/contracts/_meta.json deleted file mode 100644 index f8ed2c3be..000000000 --- a/pages/builders/app-developers/contracts/_meta.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "compatibility": "Solidity Compatibility", - "system-contracts": "System Contracts", - "optimization": "Cost Optimization" -} diff --git a/pages/builders/app-developers/contracts/compatibility.mdx b/pages/builders/app-developers/contracts/compatibility.mdx deleted file mode 100644 index ed9cc7d7b..000000000 --- a/pages/builders/app-developers/contracts/compatibility.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Solidity Compatibility -lang: en-US -description: Learn about the differences between OP Mainnet and Ethereum when building Solidity contracts. ---- - -# Solidity Compatibility - -OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), which means OP Mainnet looks exactly like Ethereum in every way possible. -Almost all Ethereum tooling works out of the box on OP Mainnet, including the [Solidity](https://soliditylang.org/) smart contract language. -However, there are a few minor differences between OP Mainnet and Ethereum that you should be aware of when building Solidity contracts. - -## EVM/Opcode Differences - -Most smart contracts will work on OP Mainnet without any changes. -Check out the [Differences Between Ethereum and OP Mainnet](/chain/differences#opcodes) page for a detailed list of the few differences you should know about. - -## Gas Differences - -OP Mainnet uses the same gas costs as Ethereum. -However, OP Mainnet also charges an [L1 Data Fee](/stack/transactions/fees#l1-data-fee) for the cost of publishing an L2 transaction to L1. -This fee is charged based on the size of a transaction in bytes. -As a result, smart contract optimization techniques can differ slightly on OP Mainnet. -Refer to the [Contract Optimization guide](./optimization) for more information. diff --git a/pages/builders/app-developers/contracts/optimization.mdx b/pages/builders/app-developers/contracts/optimization.mdx deleted file mode 100644 index 7d599718c..000000000 --- a/pages/builders/app-developers/contracts/optimization.mdx +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: Contract Optimization on OP Mainnet -lang: en-US -description: Learn how to optimize contracts for OP Mainnet and what to look out for when you do so. ---- - -import { Callout } from 'nextra/components' - -# Contract Optimization on OP Mainnet - -OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), which means OP Mainnet looks exactly like Ethereum in every way possible. -One large and mostly unavoidable discrepancy between OP Mainnet and Ethereum is a slight [difference in transaction fee models](/stack/transactions/fees). -This difference means that there are some opportunities to optimize OP Mainnet contracts to better take advantage of the OP Mainnet fee model. - -This guide explains the basic concepts that allow you to optimize OP Mainnet contracts and provides several examples of how you might take advantage of these concepts. -You'll also get a better understanding of the tradeoffs and risks involved with potential contract optimizations. -By the end of this guide you should have a clear understanding of how OP Mainnet contracts can be optimized and whether or not these optimizations make sense for your application. - - -Contract optimizations are powerful but can also create additional contract complexity. -Some types of optimizations may also become unnecessary as OP Mainnet evolves. -Make sure to read through all of the considerations on this page before committing to any optimizations. - - -## Fundamentals - -App developers might already be familiar with the concept of [gas optimization](https://github.com/0xisk/awesome-solidity-gas-optimization) to decrease the cost of interacting with smart contracts. -Gas optimization can reduce the amount of gas used by a contract and make your application cheaper (and therefore improve user experience). - -OP Mainnet contracts can be gas optimized to reduce overall transaction costs, just like contracts on Ethereum. -However, OP Mainnet transactions must also pay for another fee called the L1 Data Fee which accounts for the cost of publishing transaction data to Ethereum. -At the time this guide was written, this L1 Data Fee made up the majority of the cost of most transactions on OP Mainnet. - -Because the L1 Data Fee tends to be larger than the execution gas fee, **OP Mainnet contracts can be further optimized by increasing the amount of storage/execution used in order to decrease the amount of user-provided data in each transaction.** -This is the basic premise that makes OP Mainnet contract optimization slightly different than on Ethereum. - -## Considerations - -### Additional Complexity - -Contract optimizations can create additional complexity, which can in turn create additional risk. -Developers should always consider whether this added complexity is worth the reduction in cost. - -### Changing Economics - -Various potential upgrades to OP Mainnet may also make optimizations to the L1 Data Fee less relevant. -For instance, [EIP-4844](https://www.eip4844.com/), if adopted, should significantly reduce the cost of publishing data to Ethereum and would therefore also decrease the L1 Data Fee. - -OP Mainnet also uses an [EIP-1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md) mechanism that automatically increases the base fee as chain usage increases. -Optimizations based on reducing the L1 Data Fee may become less relevant if the base fee becomes a larger part of the total transaction cost. - - -Generally speaking, **developers should assume that L1 Data Fee optimizations will become less useful as time goes on**. -If you expect your contracts to be used for long periods of time, you may wish to avoid optimizations that can potentially decrease long-term gas efficiency. -If you expect your contracts to be used mostly in the short term or you have the ability to upgrade contracts in the future, optimizations may be better suited for you. - - -## Techniques - -### Calldata Compression - -Compressing user data on the client side and decompressing it on the contract side can be an effective way to decrease costs on OP Mainnet. -This technique decreases the amount of data provided by the user in exchange for a significant increase in onchain computation. - -Although several libraries exist to perform this calldata compression, none of these libraries have been audited as of the writing of this page. -As a result, links to these libraries have been explicitly omitted here to avoid encouraging developers from using potentially buggy software. -Most of these libraries can be found with a quick search online but, as always, be careful with code you find on the internet. - -### Custom Encoding - -The [Solidity ABI encoding scheme](https://docs.soliditylang.org/en/v0.8.23/abi-spec.html#argument-encoding) is not particularly data efficient. -Contracts can often reduce the amount of calldata provided by defining a custom argument encoding protocol. - -Custom argument encodings can be combined with stored data to further reduce costs. -For example, `address` arguments could potentially be replaced with a `uint64` pointer that performs a lookup in a stored mapping of `uint64 => address`. -This would cut out a significant number of bytes with further reductions if the total number of addresses that need to be looked up is small (which would allow `uint64` to be reduced to `uint32` or less). - -Custom encodings are typically less complex that general-purpose calldata compression libraries but carry additional complexity no matter what. -When combined with stored data, application-specific custom encodings can be significantly more efficient than general-purpose compression mechanisms. diff --git a/pages/builders/app-developers/contracts/system-contracts.mdx b/pages/builders/app-developers/contracts/system-contracts.mdx deleted file mode 100644 index 2e01eebe1..000000000 --- a/pages/builders/app-developers/contracts/system-contracts.mdx +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: Using OP Mainnet System Contracts -lang: en-US -description: Learn how to work with OP Mainnet contracts directly from other contracts and how to work with contracts from the client side. ---- - -import { Steps } from 'nextra/components' - -# Using OP Mainnet System Contracts - -System contracts on Ethereum (L1) and OP Mainnet (L2) are an important part of the OP Mainnet ecosystem. -You may want to interact with these system contracts for any number of reasons, including: - -* Sending messages between L1 and L2 -* Sending tokens between L1 and L2 -* Querying information about the current [L1 data fee](/stack/transactions/fees#the-l1-data-fee) -* And lots more! - -In this tutorial, you'll learn how to work with OP Mainnet contracts directly from other contracts and how to work with them from the client side. - -## Before You Begin - -You'll need to find the address of the particular contract that you want to interact with before you can actually interact with it. - -* Check out the [Networks and Connection Details page](/chain/networks) for links to public RPC endpoints and contract addresses. -* Find the addresses for all networks on the [Contract Addresses](/chain/addresses) page. -* Use the JSON file including contract addresses for all Superchain networks in the [Superchain Registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/extra/addresses/addresses.json). - -## Using System Contracts in Solidity - -All you need to interact with the OP Mainnet system contracts from another contract is an address and an interface. -You can follow [the instructions above](#finding-contract-addresses) to find the address of the contract you want to interact with. -Now you simply need to import the appropriate contracts. - - -### Installing via NPM - -You can use the [`@eth-optimism/contracts-bedrock`](https://www.npmjs.com/package/@eth-optimism/contracts-bedrock?activeTab=readme) npm package to import system contracts and their interfaces. -Install the package as follows: - -```bash -npm install @eth-optimism/contracts-bedrock -``` - -### Importing Contracts - -Simply import the desired contract or interface from the `@eth-optimism/contracts-bedrock` package: - -```solidity -import { SomeOptimismContract } from "@eth-optimism/contracts-bedrock/path/to/SomeOptimismContract.sol"; -``` - -Please note that `path/to/SomeOptimismContract` is the path to the contract [within this folder](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src). -For example, if you wanted to import the [`L1CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/L1/L1CrossDomainMessenger.sol) contract, you would use the following import: - -```solidity -import { L1CrossDomainMessenger } from "@eth-optimism/contracts/L1/messaging/L1CrossDomainMessenger.sol"; -``` - -### Getting L2 Contract Addresses - -System contracts on L2 are "pre-deployed" to special addresses that are the same on most OP Stack chains. -You can find these addresses on the [Contract Addresses](/chain/addresses) page. -These addresses are also provided as constants in the [`Predeploys`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/libraries/Predeploys.sol) contract for use in Solidity. - - -## Using System Contracts in JavaScript - -You can also interact with the OP Mainnet system contracts from the client side. - -### Installing via NPM - -You can use the [`@eth-optimism/contracts-ts`](https://www.npmjs.com/package/@eth-optimism/contracts-ts?activeTab=readme) npm package to import system contracts and their interfaces. -Install the package as follows: - -```bash -npm install @eth-optimism/contracts-ts -``` - -### Getting Contract Artifacts and Interfaces - -You can use the `@eth-optimism/contracts-ts` package to easily access the address or ABI of any OP Mainnet contract. - -Here's an example of how you can grab the ABI and address of the `L2OutputOracleProxy` contract on OP Mainnet (chain ID 10): - -```ts -import { - l2OutputOracleProxyABI, - l2OutputOracleAddresses, -} from '@eth-optimism/contracts-ts' - -// Note that the address is keyed by chain ID! -console.log(l2OutputOracleAddresses[10], abi) -``` -### Interacting with the Contract -You can then feed this address and ABI into your favorite web3 library to interact with the contract. - -`@eth-optimism/contracts-ts` also exports [React hooks](https://wagmi.sh/cli/api/plugins/react) and [wagmi actions](https://wagmi.sh/react/api/actions) for interacting with OP Mainnet contracts. -Check out the full [README](https://github.com/ethereum-optimism/optimism/tree/v1.1.4/packages/contracts-ts#readme) for more information. - diff --git a/pages/builders/app-developers/overview.mdx b/pages/builders/app-developers/overview.mdx index cf5222e13..e38817e46 100644 --- a/pages/builders/app-developers/overview.mdx +++ b/pages/builders/app-developers/overview.mdx @@ -1,34 +1,34 @@ --- -title: App Developer Overview +title: App developer overview lang: en-US description: Learn about deploying contracts, cross-chain messaging, and tutorials to help you build applications on OP Mainnet. --- import { Cards, Card } from 'nextra/components' -# App Developer Overview +# App developer overview If you're a developer looking to build on OP Mainnet, you've come to the right place. In this area of the Optimism Docs you'll find everything you need to know about building OP Mainnet applications. -## Getting Started +## Getting started If you're brand new to OP Mainnet, try starting with the guide on [deploying a basic contract](/chain/getting-started). It'll get you familiar with the basic steps required to get a contract deployed to the network. OP Mainnet is [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) so you can feel confident that your existing Ethereum smart contract skills will carry over to OP Mainnet. -Just make sure to be aware of the few small [differences between Ethereum and OP Mainnet](/chain/differences). +Just make sure to be aware of the few small [differences between Ethereum and OP Mainnet](/stack/differences). You might also want to check out the [testing on OP Networks guide](/chain/testing/testing-apps) and the tutorial on [running a local development environment](/chain/testing/dev-node) to help you feel totally confident in your OP Mainnet deployment. - } /> + } /> - } /> + } /> } /> -## Bridging and Messaging +## Bridging and messaging Looking to build an application that sends ETH, tokens, or data between OP Mainnet and Ethereum? You'll find some useful guides and tutorials in this area of the docs. @@ -51,21 +51,21 @@ The Standard Token Bridge for OP Mainnet even uses this same message-passing inf If you're a bit more familiar with OP Mainnet and Ethereum, you can try walking through one of the tutorials put together by the Optimism community. They'll help you get a head start when building your first Optimistic project. -| Tutorial Name | Description | Difficulty Level | -| --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | -| [Deploying Your First Contract on OP Mainnet](tutorials/first-contract) | Learn how to deploy your first contract to OP Mainnet with Remix and MetaMask. | 🟒 Easy | -| [Bridging ETH With the Optimism SDK](tutorials/cross-dom-bridge-eth) | Learn how to use the Optimism SDK to transfer ETH between Layer 1 (Ethereum or Sepolia) and Layer 2 (OP Mainnet or OP Sepolia). | 🟒 Easy | -| [Bridging ERC-20 Tokens With the Optimism SDK](tutorials/cross-dom-bridge-erc20) | Learn how to use the Optimism SDK to transfer ERC-20 tokens between Layer 1 (Ethereum or Sepolia) and Layer 2 (OP Mainnet or OP Sepolia). | 🟒 Easy | -| [Bridging your Standard ERC-20 token using the Standard Bridge](tutorials/standard-bridge-standard-token) | Learn how to bridge your standard ERC-20 token to layer 2 using the standard bridge. | 🟑 Medium | -| [Bridging your Custom ERC-20 token using the Standard Bridge](tutorials/standard-bridge-custom-token) | Learn how to bridge your custom ERC-20 token to layer 2 using the standard bridge. | 🟑 Medium | -| [Tracing Deposits and Withdrawals With the Optimism SDK](tutorials/sdk-trace-txns) | Learn how to use the Optimism SDK to trace deposits and withdrawals. | 🟒 Easy | -| [Viewing Deposits and Withdrawals by Address With the Optimism SDK](tutorials/sdk-view-txns) | Learn how to use the Optimism SDK to view deposits and withdrawals by address. | 🟒 Easy | -| [Estimating Transaction Costs With the Optimism SDK](tutorials/sdk-view-txns) | Learn how to use the Optimism SDK to estimate the cost of a transaction on OP Mainnet. | 🟒 Easy | -| [Sending OP Mainnet Transactions from Ethereum](tutorials/send-tx-from-eth) | Learn how to send transactions to OP Mainnet from Ethereum. | 🟒 Easy | +| Tutorial Name | Description | Difficulty Level | +| --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ---------------- | +| [Deploying Your First Contract on OP Mainnet](tutorials/first-contract) | Learn how to deploy your first contract to OP Mainnet with Remix and MetaMask. | 🟒 Easy | +| [Bridging ETH With viem](tutorials/cross-dom-bridge-eth) | Learn how to use viem to transfer ETH between Layer 1 (Ethereum or Sepolia) and Layer 2 (OP Mainnet or OP Sepolia). | 🟒 Easy | +| [Bridging ERC-20 Tokens With viem](tutorials/cross-dom-bridge-erc20) | Learn how to use viem to transfer ERC-20 tokens between Layer 1 (Ethereum or Sepolia) and Layer 2 (OP Mainnet or OP Sepolia). | 🟒 Easy | +| [Bridging your Standard ERC-20 token using the Standard Bridge](tutorials/standard-bridge-standard-token) | Learn how to bridge your standard ERC-20 token to layer 2 using the standard bridge. | 🟑 Medium | +| [Bridging your Custom ERC-20 token using the Standard Bridge](tutorials/standard-bridge-custom-token) | Learn how to bridge your custom ERC-20 token to layer 2 using the standard bridge. | 🟑 Medium | +| [Tracing Deposits and Withdrawals with viem](tutorials/sdk-trace-txns) | Learn how to use viem to trace deposits and withdrawals. | 🟒 Easy | +| [Viewing Deposits and Withdrawals by address with viem](tutorials/sdk-view-txns) | Learn how to use viem to view deposits and withdrawals by address. | 🟒 Easy | +| [Estimating Transaction Costs With the viem](tutorials/sdk-view-txns) | Learn how to use viem to estimate the cost of a transaction on OP Mainnet. | 🟒 Easy | +| [Sending OP Mainnet Transactions from Ethereum](tutorials/send-tx-from-eth) | Learn how to send transactions to OP Mainnet from Ethereum. | 🟒 Easy | You can also [suggest a new tutorial](https://github.com/ethereum-optimism/docs/issues/new?assignees=\&labels=tutorial%2Cdocumentation%2Ccommunity-request\&projects=\&template=suggest_tutorial.yaml\&title=%5BTUTORIAL%5D+Add+PR+title) if you have something specific in mind. We'd love to grow this list! -## Next Steps +## Next steps If you still can't find the content you're looking for, there's a few options to get extra help. diff --git a/pages/builders/app-developers/quick-start.mdx b/pages/builders/app-developers/quick-start.mdx index 34482b0c1..98cc91da0 100644 --- a/pages/builders/app-developers/quick-start.mdx +++ b/pages/builders/app-developers/quick-start.mdx @@ -1,5 +1,5 @@ --- -title: Superchain App Quick Start +title: Superchain app quick start lang: en-US description: Learn how to quickly build and deploy an app to any OP Chain using Scaffold-OP. --- @@ -8,7 +8,7 @@ import { Callout, Steps } from 'nextra/components' import Image from 'next/image' import { Tabs } from 'nextra/components' -# Superchain App Quick Start +# Superchain App quick start This quick start walks you through an easy three-step process to deploy an app to any OP Chain – in under 15 minutes. This quick start uses [`Scaffold-OP`](https://github.com/ethereum-optimism/scaffold-op) to build the Superchain App, covers the setup process, and links to more detailed guides, so you can dive a bit deeper when needed. @@ -29,7 +29,7 @@ You can request testnet ETH from the Superchain Faucet in one of two ways: **con You can also try using [other available OP Sepolia faucets](/builders/tools/build/faucets). -## Step 2: Build a Basic App with Scaffold-OP +## Step 2: Build a basic app with Scaffold-OP Scaffold-OP is a fork of [`scaffold-ETH2`](https://docs.scaffoldeth.io/) with minimal differences: additional app examples, native support for Superchain testnets, and more low-level instructions. Scaffold-OP is an open-source toolkit for building decentralized applications on the Ethereum blockchain and is designed to make it easier for developers to create and deploy smart contracts and @@ -104,7 +104,7 @@ Before you begin, you need to install the following tools: * Edit your deployment scripts in `packages/hardhat/deploy` -## Step 3: Deploy Contracts to Superchain Testnets +## Step 3: Deploy contracts to Superchain Testnets You will follow the steps below to deploy contracts to a remote testnet (e.g., Optimism Sepolia). Please ensure you have enough Sepolia ETH on all these Superchains before deploying (See [Step 1 above](#step-1-get-testnet-eth-from-superchain-faucet)). @@ -159,7 +159,7 @@ Please ensure you have enough Sepolia ETH on all these Superchains before deploy Congratulations! You now have an OP Mainnet app ready for development, which can also be deployed to more OP Chains! πŸŽ‰ -## Next Steps +## Next steps * Share feedback about this quick start or `scaffold-op` in the [developer forum](https://github.com/ethereum-optimism/developers/discussions/262). * You can also [add Foundry to Scaffold-OP](https://github.com/ethereum-optimism/scaffold-op?tab=readme-ov-file#adding-foundry) for more robust and faster testing. diff --git a/pages/builders/app-developers/tools.mdx b/pages/builders/app-developers/tools.mdx new file mode 100644 index 000000000..7aeb81f23 --- /dev/null +++ b/pages/builders/app-developers/tools.mdx @@ -0,0 +1,17 @@ +--- +title: Tools +lang: en-US +description: Information on open-source code repositories for OP Stack builders and SuperSim. +--- + +import { Card, Cards } from 'nextra/components' + +# Tools + +This section provides information on open-source code repositories for OP Stack builders and SuperSim. Users will find references to help understand and work with these topics. + + + + + + diff --git a/pages/builders/app-developers/tools/_meta.json b/pages/builders/app-developers/tools/_meta.json index 9f3f9aa63..f751e54e9 100644 --- a/pages/builders/app-developers/tools/_meta.json +++ b/pages/builders/app-developers/tools/_meta.json @@ -1,5 +1,6 @@ { - "ecosystem-overview": "Open Source Code Repo", + "ecosystem-overview": "Open source code repo", + "supersim": "Supersim Multichain Development Environment", "console": { "title": "Superchain Dev Console", "href": "https://console.optimism.io/?utm_source=docs", diff --git a/pages/builders/app-developers/tools/ecosystem-overview.mdx b/pages/builders/app-developers/tools/ecosystem-overview.mdx index 10fe3a21b..e6f08ef4c 100644 --- a/pages/builders/app-developers/tools/ecosystem-overview.mdx +++ b/pages/builders/app-developers/tools/ecosystem-overview.mdx @@ -1,17 +1,17 @@ --- -title: Open Source Code Repo +title: Open source code repo lang: en-US description: Learn about an ecosystem of libraries and utilities tailored to help you deploy applications on the OP Stack. --- import { Cards, Card } from 'nextra/components' -# Open Source Code Repo for OP Stack Builders +# Open source code repo for OP Stack builders The [ecosystem repository](https://github.com/ethereum-optimism/ecosystem) is a comprehensive resource of libraries, utilities, and forkable code examples specifically tailored for builders deploying applications on the OP stack. The ecosystem repository was developed to help ease and expedite the development process for all builders working on the OP stack, helping them deliver value to the community without the necessity of mastering every detail of how the protocol itself operates. -## Getting Started +## Getting started Our initial launch includes an example [bridge application](https://github.com/ethereum-optimism/ecosystem/tree/main/apps/bridge-app) that demonstrates how to bridge ETH and any ERC20 tokens listed in the [Superchain Token List](/chain/tokenlist). This application serves as a reference for anyone looking to build their own bridge, offering a clearer understanding of how to interact with the protocol on both the L1 and L2 sides. diff --git a/pages/builders/app-developers/tools/supersim.mdx b/pages/builders/app-developers/tools/supersim.mdx new file mode 100644 index 000000000..57a0d8e40 --- /dev/null +++ b/pages/builders/app-developers/tools/supersim.mdx @@ -0,0 +1,11 @@ +--- +title: Supersim +lang: en-US +description: >- + Learn about supersim in the Optimism ecosystem. This guide provides detailed + information and resources about supersim. +--- + +import Supersim from '@/pages/stack/interop/supersim.mdx' + + diff --git a/pages/builders/app-developers/transactions.mdx b/pages/builders/app-developers/transactions.mdx new file mode 100644 index 000000000..e845de2d1 --- /dev/null +++ b/pages/builders/app-developers/transactions.mdx @@ -0,0 +1,25 @@ +--- +title: Transactions +lang: en-US +description: >- + Guide to understanding and working with transactions on OP Stack, including + fee estimation, gas parameters, and troubleshooting. +--- + +import { Card, Cards } from 'nextra/components' + +# Transactions + +This section provides information on transactions in OP Mainnet, including fee estimation, gas parameters, transaction statuses, and troubleshooting. You'll find guides to help you understand and work with these topics. + + + + + + + + + + + + diff --git a/pages/builders/app-developers/transactions/_meta.json b/pages/builders/app-developers/transactions/_meta.json index 5a89efbd7..916fc5e3d 100644 --- a/pages/builders/app-developers/transactions/_meta.json +++ b/pages/builders/app-developers/transactions/_meta.json @@ -1,7 +1,7 @@ { - "fees": "Transaction Fees", - "estimates": "Estimating Fees", - "parameters": "Setting Gas Parameters", - "statuses": "Transaction Statuses", + "fees": "Transaction fees", + "estimates": "Estimating fees", + "parameters": "Setting gas parameters", + "statuses": "Transaction statuses", "troubleshooting": "Troubleshooting" } diff --git a/pages/builders/app-developers/transactions/estimates.mdx b/pages/builders/app-developers/transactions/estimates.mdx index 6b7008b18..62d3668f4 100644 --- a/pages/builders/app-developers/transactions/estimates.mdx +++ b/pages/builders/app-developers/transactions/estimates.mdx @@ -1,12 +1,12 @@ --- -title: Estimating Transaction Fees on OP Mainnet +title: Estimating transaction fees on OP Mainnet lang: en-US description: Learn how to properly estimate the total cost of a transaction on OP Mainnet. --- import { Callout, Steps } from 'nextra/components' -# Estimating Transaction Fees on OP Mainnet +# Estimating transaction fees on OP Mainnet Check out the guide on understanding [Transaction Fees on OP Mainnet](./fees) for an in-depth explanation of how OP Mainnet transaction fees work. @@ -16,7 +16,7 @@ It's important to properly estimate the cost of a transaction on OP Mainnet befo Here you'll learn how to estimate both of the components that make up the total cost of an OP Mainnet transaction, the [execution gas fee](./fees#execution-gas-fee) and the [L1 data fee](./fees#l1-data-fee). Make sure to read the guide on [Transaction Fees on OP Mainnet](./fees) for a detailed look at how these fees work under the hood. -## Execution Gas Fee +## Execution gas fee Estimating the execution gas fee on OP Mainnet is just like estimating the execution gas fee on Ethereum. @@ -41,38 +41,18 @@ This means you can feed your transaction to the [`eth_estimateGas`](https://ethe {

Estimate the max fee per gas

} -Like Ethereum, OP Mainnet uses an EIP-1559 style fee market to determine the current base fee per gas. +Like Ethereum, OP Mainnet uses an `EIP-1559` style fee market to determine the current base fee per gas. You can then additionally specify a priority fee (also known as a tip) to incentivize the Sequencer to include your transaction more quickly. Make sure to check out the guide on [Setting Transaction Gas Parameters on OP Mainnet](./parameters) to learn more about how to select an appropriate max fee per gas for your transaction. -{

Calculate the execution gas fee

} - -Once you've estimated the gas limit and the max fee per gas for your transaction, you can calculate the execution gas fee by multiplying these two values together. - -For instance, suppose that your transaction has a gas limit of `420000 gas`, a base fee of `0.05 gwei`, and a priority fee of `0.1 gwei`. -The execution gas fee for your transaction would be: - -```javascript -// Start with your parameters -gas_limit = 420000 -base_fee_per_gas = 0.05 gwei -priority_fee_per_gas = 0.1 gwei - -// Max fee per gas is the sum of the base fee and the priority fee -max_fee_per_gas = base_fee_per_gas + priority_fee_per_gas = 0.15 gwei - -// Execution gas fee is the product of the gas limit and the max fee per gas -execution_gas_fee = gas_limit * max_fee_per_gas = 420000 * 0.15 gwei = 0.000063 ETH -``` - -## L1 Data Fee +## L1 data fee -The Optimism SDK provides a convenient method for estimating the L1 data fee for a transaction. -Check out the tutorial on [Estimating Transaction Costs on OP Mainnet](/builders/app-developers/tutorials/sdk-estimate-costs) to learn how to use the Optimism SDK to estimate the L1 data fee for your transaction. -Keep reading if you'd like to learn how to estimate the L1 data fee without the Optimism SDK. +The Viem library provides a convenient method for estimating the L1 data fee for a transaction. +Check out the tutorial on [Estimating Transaction Costs on OP Mainnet](/builders/app-developers/tutorials/sdk-estimate-costs) to learn how to use the Viem library to estimate the L1 data fee for your transaction. +Keep reading if you'd like to learn how to estimate the L1 data fee without the Viem library. The L1 data fee is a fee paid to the Sequencer for the cost of publishing your transaction to Ethereum. @@ -96,7 +76,7 @@ This means that the L1 data fee for your transaction may differ from your estima The L1 data fee is calculated based on the size of your serialized transaction in bytes. Most Ethereum tooling will provide a method for serializing a transaction. -For instance, Ethersjs provides the [`ethers.utils.serializeTransaction`](https://docs.ethers.org/v5/api/utils/transactions/#utils-serializeTransaction) method. +For instance, Ethers.js provides the [`ethers.utils.serializeTransaction`](https://docs.ethers.org/v5/api/utils/transactions/#utils-serializeTransaction) method. {

Estimate the L1 data fee

} @@ -116,10 +96,8 @@ Several tools are available to help you estimate the L1 Data Fee for your transa Selecting the right tool for your use case will depend on your specific needs. * [Viem](https://viem.sh/op-stack#getting-started-with-op-stack) provides first-class support for OP Stack chains, including OP Mainnet. You can use Viem to estimate gas costs and send cross-chain transactions (like transactions through the Standard Bridge system). It's strongly recommended to use Viem if you are able to do so as it will provide the best native support at the moment. -* If you are using Ethers v5, the [Optimism SDK](https://sdk.optimism.io/) provides methods for estimating the L1 Data Fee for your transactions and for sending cross-chain transactions. The Optimism SDK is designed to be used alongside Ethers v5 and does not yet support Ethers v6. -* If you are using Ethers v6, the [Optimistic Utilities Extension](https://github.com/ethers-io/ext-utils-optimism) provides methods for estimating the L1 Data Fee. The Ethers v6 extension does not yet support sending cross-chain transactions. Use Viem or the Optimism SDK if you need to send cross-chain transactions. -### Future Proofing +### Future proofing The L1 Data Fee formula is subject to change in the future, especially as the data availability landscape evolves. As a result, it's important to future proof your transaction fee estimation code to ensure that it will continue to function properly as the L1 Data Fee formula changes. diff --git a/pages/builders/app-developers/transactions/fees.mdx b/pages/builders/app-developers/transactions/fees.mdx index 09af8f1c0..cc3b2e6f3 100644 --- a/pages/builders/app-developers/transactions/fees.mdx +++ b/pages/builders/app-developers/transactions/fees.mdx @@ -1,4 +1,9 @@ --- +title: TransactionFees +lang: en-US +description: >- + Learn about fees in the Optimism ecosystem. This guide provides detailed + information and resources about fees. --- import TransactionFees from '@/pages/stack/transactions/fees.mdx' diff --git a/pages/builders/app-developers/transactions/parameters.mdx b/pages/builders/app-developers/transactions/parameters.mdx index e5e18aa3e..22e450911 100644 --- a/pages/builders/app-developers/transactions/parameters.mdx +++ b/pages/builders/app-developers/transactions/parameters.mdx @@ -1,12 +1,12 @@ --- -title: Setting Transaction Gas Parameters on OP Mainnet +title: Setting transaction gas parameters on OP Mainnet lang: en-US description: Learn how to set gas parameters for transactions on OP Mainnet. --- import { Callout, Steps } from 'nextra/components' -# Setting Transaction Gas Parameters on OP Mainnet +# Setting transaction gas parameters on OP Mainnet OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) which means that it is as compatible with Ethereum as possible, down to the client software used to run OP Mainnet nodes. Like Ethereum, OP Mainnet has an EIP-1559 style fee mechanism that dynamically adjusts a [base fee](https://ethereum.org/en/developers/docs/gas/#base-fee) that acts as the minimum fee that a transaction must pay to be included in a block. @@ -15,7 +15,7 @@ OP Mainnet also allows transactions to pay a [priority fee](https://ethereum.org Setting the base fee and the priority fee appropriately is important to ensure that your transactions are included in a timely manner. This guide will walk you through some best practices for determining the base fee and priority fee for your transactions. -## Selecting the Base Fee +## Selecting the base fee The base fee is the minimum fee that a transaction must pay to be included in a block. Transactions that specify a maximum fee per gas that is less than the current base fee cannot be included in the blockchain. @@ -53,7 +53,7 @@ If you are less sensitive to the base fee, you may wish to simply use a large mu -## Selecting the Priority Fee +## Selecting the priority fee The priority fee is an optional tip that can be paid to the Sequencer to incentivize them to include your transaction more quickly. The priority fee is paid in addition to the base fee. diff --git a/pages/builders/app-developers/transactions/statuses.mdx b/pages/builders/app-developers/transactions/statuses.mdx index 0427ab651..ed635a400 100644 --- a/pages/builders/app-developers/transactions/statuses.mdx +++ b/pages/builders/app-developers/transactions/statuses.mdx @@ -1,10 +1,10 @@ --- -title: Transaction Statuses on OP Mainnet +title: Transaction statuses on OP Mainnet lang: en-US description: Learn about the statuses transactions can have on OP Mainnet. --- -# Transaction Statuses on OP Mainnet +# Transaction statuses on OP Mainnet Transactions on OP Mainnet can have a number of different statuses depending on where a transaction is in the process of being included in the blockchain. Understanding these statuses can help you troubleshoot issues, build safer applications, and display more accurate information to your users. @@ -19,7 +19,7 @@ At this point the transaction is not part of the blockchain and there is no guar The list of all pending transactions can be retrieved by calling the standard JSON-RPC method [`eth_getBlockByNumber`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbynumber) with the parameter `pending` as the block number. -## Sequencer Confirmed / Unsafe +## Sequencer confirmed or unsafe **Typically within 2-4 seconds** @@ -30,7 +30,7 @@ Applications should make sure to consider this possibility when displaying infor The latest "sequencer confirmed" block can be retrieved by calling the standard JSON-RPC method [`eth_getBlockByNumber`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbynumber) with the parameter `safe` as the block number and comparing this to the result returned for the `latest` block. If the `safe` block is behind the `latest` block, then the earliest "sequencer confirmed" block is the `safe` block plus one. -## Published to Ethereum / Safe +## Published to Ethereum or safe **Typically within 5-10 minutes, up to 12 hours** diff --git a/pages/builders/app-developers/transactions/troubleshooting.mdx b/pages/builders/app-developers/transactions/troubleshooting.mdx index fdf67ab8b..22a7e06e5 100644 --- a/pages/builders/app-developers/transactions/troubleshooting.mdx +++ b/pages/builders/app-developers/transactions/troubleshooting.mdx @@ -1,12 +1,12 @@ --- -title: Troubleshooting Transactions +title: Troubleshooting transactions lang: en-US description: Learn how to troubleshoot common problems with transactions. --- -# Troubleshooting Transactions +# Troubleshooting transactions -## Transactions Stuck in the Transaction Pool +## Transactions stuck in the transaction pool OP Chain uses EIP-1559, but with different parameters than L1 Ethereum. As a result, while the base fee on L1 can grow by up to 12.5% in a twelve second period (in the case of a single 30M gas block), the L2 base fee can grow by up to 77% (in the case of six 30M gas blocks). @@ -14,7 +14,7 @@ However, it still shrinks by only up to 12.5% in the same twelve second period ( If the maximum fee per gas specified by the transaction is less than the block base fee, it does not get included until the base fee drops to below the value in the transaction. When this happens, some users may see their transaction become stuck. -No ETH are lost, but the transaction does not clear on its own. +No ETH is lost, but the transaction does not clear on its own. We have a workaround that users and wallet operators can implement immediately, and we expect a protocol-level fix to be live by the end of Q4. diff --git a/pages/builders/app-developers/tutorials.mdx b/pages/builders/app-developers/tutorials.mdx new file mode 100644 index 000000000..34a2f40e4 --- /dev/null +++ b/pages/builders/app-developers/tutorials.mdx @@ -0,0 +1,31 @@ +--- +title: Tutorials +lang: en-US +description: A collection of tutorials for app developers building on OP Stack, covering topics such as bridging tokens, deploying contracts, and estimating transaction costs. +--- + +import { Card, Cards } from 'nextra/components' + +# Tutorials + +This section provides information on bridging erc 20 tokens to op mainnet with viem, bridging eth to op mainnet with viem, communicating between op mainnet and ethereum in solidity, deploying your first contract on op mainnet, estimating transaction costs on op mainnet, tracing deposits and withdrawals, viewing deposits and withdrawals by address, triggering op mainnet transactions from ethereum, bridging your custom erc 20 token using the standard bridge and bridging your standard erc 20 token using the standard bridge. You'll find tutorial to help you understand and work with these topics. + + + + + + + + + + + + + + + + + + + + diff --git a/pages/builders/app-developers/tutorials/_meta.json b/pages/builders/app-developers/tutorials/_meta.json index 0f6a0b800..a1f44203f 100644 --- a/pages/builders/app-developers/tutorials/_meta.json +++ b/pages/builders/app-developers/tutorials/_meta.json @@ -1,12 +1,11 @@ { - "first-contract": "Deploying Your First Contract on OP Mainnet", - "cross-dom-solidity": "Communicating Between Chains in Solidity", - "cross-dom-bridge-eth": "Bridging ETH With the Optimism SDK", - "cross-dom-bridge-erc20": "Bridging ERC-20 Tokens With the Optimism SDK", - "standard-bridge-custom-token": "Bridging Your Custom ERC-20 Token to OP Mainnet", - "standard-bridge-standard-token": "Bridging Your Standard ERC-20 Token to OP Mainnet", - "sdk-view-txns": "Viewing Deposits and Withdrawals by Address", - "sdk-trace-txns": "Tracing Deposits and Withdrawals", - "sdk-estimate-costs": "Estimating Transaction Costs", - "send-tx-from-eth": "Triggering OP Mainnet Transactions From Ethereum" + "cross-dom-solidity": "Communicating between chains in Solidity", + "cross-dom-bridge-eth": "Bridging ETH with viem", + "cross-dom-bridge-erc20": "Bridging ERC-20 tokens with viem", + "standard-bridge-custom-token": "Bridging your custom ERC-20 token to OP Mainnet", + "standard-bridge-standard-token": "Bridging your standard ERC-20 token to OP Mainnet", + "sdk-view-txns": "Viewing deposits and withdrawals by address", + "sdk-trace-txns": "Tracing deposits and withdrawals", + "sdk-estimate-costs": "Estimating transaction costs", + "send-tx-from-eth": "Triggering OP Mainnet transactions from Ethereum" } diff --git a/pages/builders/app-developers/tutorials/cross-dom-bridge-erc20.mdx b/pages/builders/app-developers/tutorials/cross-dom-bridge-erc20.mdx index bbddc794d..883e4908c 100644 --- a/pages/builders/app-developers/tutorials/cross-dom-bridge-erc20.mdx +++ b/pages/builders/app-developers/tutorials/cross-dom-bridge-erc20.mdx @@ -9,7 +9,7 @@ import { WipCallout } from '@/components/WipCallout' -# Bridging ERC-20 Tokens to OP Mainnet With the Optimism SDK +# Bridging ERC-20 tokens to OP Mainnet with the Optimism SDK @@ -27,18 +27,18 @@ Make sure to check out the [Standard Bridge guide](/builders/app-developers/brid because they can cause bridge accounting errors. -## Supported Networks +## Supported networks The Optimism SDK supports any of the [Superchain networks](/chain/networks). [Some Superchain networks](https://sdk.optimism.io/enums/l2chainid) are already included in the SDK by default. -If you want to use a network that isn't included by default, you can simply [instantiate the SDK with the appropriate contract addresses](/builders/chain-operators/tutorials/sdk). +If you want to use a network that isn't included by default, you can simply [instantiate the SDK with the appropriate contract addresses](/builders/app-developers/overview). ## Dependencies * [node](https://nodejs.org/en/) * [pnpm](https://pnpm.io/installation) -## Create a Demo Project +## Create a demo project You're going to use the Optimism SDK for this tutorial. Since the Optimism SDK is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. @@ -89,7 +89,7 @@ You will need to get some ETH on both of these testnets. Sepolia. -## Add a Private Key to Your Environment +## Add a private key to your environment You need a private key to sign transactions. Set your private key as an environment variable with the `export` command. @@ -110,7 +110,7 @@ node This will bring up a Node REPL prompt that allows you to run javascript code. -## Import Dependencies +## Import dependencies You need to import some dependencies into your Node REPL session. @@ -126,7 +126,7 @@ You need to import some dependencies into your Node REPL session. ``` -## Set Session Variables +## Set session variables You'll need a few variables throughout this tutorial. Let's set those up now. @@ -159,7 +159,7 @@ Let's set those up now. -## Get L1 Tokens +## Get L1 tokens You're going to need some tokens on L1 that you can bridge to L2. The L1 testing token located at [`0x5589BB8228C07c4e15558875fAf2B859f678d129`](https://sepolia.etherscan.io/address/0x5589BB8228C07c4e15558875fAf2B859f678d129) has a `faucet` function that makes it easy to get tokens. @@ -186,7 +186,7 @@ The L1 testing token located at [`0x5589BB8228C07c4e15558875fAf2B859f678d129`](h ``` -## Deposit Tokens +## Deposit tokens Now that you have some tokens on L1, you can deposit those tokens into the `L1StandardBridge` contract. You'll then receive the same number of tokens on L2 in return. @@ -259,7 +259,7 @@ You'll then receive the same number of tokens on L2 in return. ``` -## Withdraw Tokens +## Withdraw tokens You just bridged some tokens from L1 to L2. Nice! @@ -336,7 +336,7 @@ Now you're going to repeat the process in reverse to bridge some tokens from L2 ``` -## Next Steps +## Next steps Congrats! You've just deposited and withdrawn tokens using the Optimism SDK. diff --git a/pages/builders/app-developers/tutorials/cross-dom-bridge-eth.mdx b/pages/builders/app-developers/tutorials/cross-dom-bridge-eth.mdx index 5c7d442c8..4d5e6a95c 100644 --- a/pages/builders/app-developers/tutorials/cross-dom-bridge-eth.mdx +++ b/pages/builders/app-developers/tutorials/cross-dom-bridge-eth.mdx @@ -1,72 +1,60 @@ --- -title: Bridging ETH with the Optimism SDK +title: Bridging ETH with Viem lang: en-US -description: Learn how to use the Optimism SDK to transfer ETH between Layer 1 (Ethereum or Sepolia) and Layer 2 (OP Mainnet or OP Sepolia). +description: Learn how to use Viem to transfer ETH between Layer 1 (Ethereum or Sepolia) and Layer 2 (OP Mainnet or OP Sepolia). --- -import { Callout, Steps } from 'nextra/components' -import { WipCallout } from '@/components/WipCallout' +import { Callout, Steps, Tabs } from 'nextra/components' - +# Bridging ETH to OP Mainnet with Viem -# Bridging ETH to OP Mainnet With the Optimism SDK +This tutorial explains how you can use [Viem](https://viem.sh) to bridge ETH from L1 (Ethereum or Sepolia) to L2 (OP Mainnet or OP Sepolia). +Viem is a TypeScript interface for Ethereum that provides low-level stateless primitives for interacting with Ethereum. +It offers an easy way to add bridging functionality to your JavaScript-based application. - - -This tutorial explains how you can use the [Optimism SDK](https://sdk.optimism.io) to bridge ETH from L1 (Ethereum or Sepolia) to L2 (OP Mainnet or OP Sepolia). -The Optimism SDK is an easy way to add bridging functionality to your JavaScript-based application. -It also provides some safety rails to prevent common mistakes that could cause ETH or ERC-20 tokens to be made inaccessible. - -Behind the scenes, the Optimism SDK uses the [Standard Bridge](/builders/app-developers/bridging/standard-bridge) contracts to transfer ETH and ERC-20 tokens. +Behind the scenes, Viem uses the [Standard Bridge](/builders/app-developers/bridging/standard-bridge) contracts to transfer ETH and ERC-20 tokens. Make sure to check out the [Standard Bridge guide](/builders/app-developers/bridging/standard-bridge) if you want to learn more about how the bridge works under the hood. -## Supported Networks +## Supported networks -The Optimism SDK supports any of the [Superchain networks](/chain/networks). -[Some Superchain networks](https://sdk.optimism.io/enums/l2chainid) are already included in the SDK by default. -If you want to use a network that isn't included by default you can simply [instantiate the SDK with the appropriate contract addresses](/builders/chain-operators/tutorials/sdk). +Viem supports any of the [Superchain networks](/chain/networks). +The OP Stack networks are included in Viem by default. +If you want to use a network that isn't included by default, you can add it to Viem's chain configurations. ## Dependencies * [node](https://nodejs.org/en/) * [pnpm](https://pnpm.io/installation) -## Create a Demo Project +## Create a demo project -You're going to use the Optimism SDK for this tutorial. -Since the Optimism SDK is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. +You're going to use Viem for this tutorial. +Since Viem is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. -{

Make a Project Folder

} + {

Make a project folder

} -```bash -mkdir op-sample-project -cd op-sample-project -``` + ```bash + mkdir bridge-eth + cd bridge-eth + ``` -{

Initialize the Project

} + {

Initialize the project

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

Install the Optimism SDK

} - -```bash -pnpm add @eth-optimism/sdk -``` - -{

Install ethers.js

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

Install the Viem library

} + ```bash + pnpm add viem + ``` -Want to create a new wallet for this tutorial? -If you have [`cast`](https://book.getfoundry.sh/getting-started/installation) installed you can run `cast wallet new` in your terminal to create a new wallet and get the private key. + Want to create a new wallet for this tutorial? + If you have [`cast`](https://book.getfoundry.sh/getting-started/installation) installed you can run `cast wallet new` in your terminal to create a new wallet and get the private key. ## Get ETH on Sepolia @@ -75,13 +63,13 @@ This tutorial explains how to bridge ETH from Sepolia to OP Sepolia. You will need to get some ETH on Sepolia to follow along. -You can use [this faucet](https://sepoliafaucet.com) to get ETH on Sepolia. + You can use [this faucet](https://sepoliafaucet.com) to get ETH on Sepolia. -## Add a Private Key to Your Environment +## Add a private key to your environment You need a private key in order to sign transactions. -Set your private key as an environment variable with the `export` command. +Set your private key as an environment variable with the export command. Make sure this private key corresponds to an address that has ETH on Sepolia. ```bash @@ -90,116 +78,126 @@ export TUTORIAL_PRIVATE_KEY=0x... ## Start the Node REPL -You're going to use the Node REPL to interact with the Optimism SDK. +You're going to use the Node REPL to interact with Viem. To start the Node REPL run the following command in your terminal: ```bash node ``` -This will bring up a Node REPL prompt that allows you to run javascript code. +This will bring up a Node REPL prompt that allows you to run JavaScript code. -## Import Dependencies +## Import dependencies You need to import some dependencies into your Node REPL session. +{

Import Viem and other packages

} + +```js file=/public/tutorials/cross-dom-bridge-eth.js#L3-L6 hash=88319dda3322e76accb9e50222d30abc +``` -{

Import the Optimism SDK

} +{

Load private key and set account

} -```js file=/public/tutorials/cross-dom-bridge-eth.js#L3 hash=26b2fdb17dd6c8326a54ec51f0769528 +```js file=/public/tutorials/cross-dom-bridge-eth.js#L9-L10 hash=251ec91fdff9dbc613b459ca3b9fb8bd ``` -{

Import ethers.js

} +{

Create L1 public client for reading from the Sepolia network

} -```js file=/public/tutorials/cross-dom-bridge-eth.js#L4 hash=69a65ef97862612e4978b8563e6dbe3a +```js file=/public/tutorials/cross-dom-bridge-eth.js#L13-L16 hash=6f2335d67920c219b5fd3590f8450cac ``` - -## Set Session Variables +{

Create L1 wallet client for sending transactions on Sepolia

} -You'll need a few variables throughout this tutorial. -Let's set those up now. +```js file=/public/tutorials/cross-dom-bridge-eth.js#L19-L23 hash=a9b217aef7c065eaf3f2a7222494a3e1 +``` - -{

Load your private key

} +{

Create L2 public client for interacting with OP Sepolia

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

Create the RPC providers and wallets

} +{

Create L2 wallet client on OP Sepolia

} -```js file=/public/tutorials/cross-dom-bridge-eth.js#L8-L11 hash=9afdce50665ae93bce602068071ffaa1 +```js file=/public/tutorials/cross-dom-bridge-eth.js#L32-L36 hash=6f91578c5b155d7abfeecf2297ee9f70 ``` -## Get ETH +## Get ETH on Sepolia You're going to need some ETH on L1 that you can bridge to L2. You can get some Sepolia ETH from [this faucet](https://sepoliafaucet.com). ## Deposit ETH -Now that you have some ETH on L1 you can deposit that ETH into the `L1StandardBridge` contract. -You'll then receive the same number of ETH on L2 in return. +Now that you have some ETH on L1 you can deposit that ETH into the `L1StandardBridge` contract. You'll then receive the same number of ETH on L2 in return. - + + + + {

Check your wallet balance on L1

} -{

Check your wallet balance on L1

} + See how much ETH you have on L1 so you can confirm that the deposit worked later on. -See how much ETH you have on L1 so you can confirm that the deposit worked later on. + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L38-L39 hash=a77304eb0a056ba30aaa21eee60bcafa + ``` -```js file=/public/tutorials/cross-dom-bridge-eth.js#L14 hash=3be1dd9a6019e9f59ad6fab38e168e99 -``` + + We used `formatEther` method from `viem` to format the balance to ether. + -{

Create a CrossChainMessenger instance

} + {

Create the deposit transaction

} -The Optimism SDK exports a `CrossChainMessenger` class that makes it easy to interact with the `L1StandardBridge` contract. + Use `buildDepositTransaction` to build the deposit transaction parameters on the L2. -Create an instance of the `CrossChainMessenger` class: + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L44-L47 hash=01a8dadb00216636f18b72758236d4b0 + ``` -```js file=/public/tutorials/cross-dom-bridge-eth.js#L16-L21 hash=997b9c4cdd5fb1f9d4e0882a683ae016 -``` -{

Deposit your ETH

} + {

Send the deposit transaction

} -Now you can deposit your ETH into the Standard Bridge contract. -You'll deposit a small amount of ETH just to demonstrate the process. + Send the deposit transaction on L1 and log the L1 transaction hash. -```js file=/public/tutorials/cross-dom-bridge-eth.js#L24-L25 hash=8bd6fdfe984274e8ec2368dc735118b4 -``` + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L49-L50 hash=6c47f29f428cc4c7f6d4ad322e4feaec + ``` - -Using a smart contract wallet? -As a safety measure, `depositETH` will fail if you try to deposit ETH from a smart contract wallet without specifying a `recipient`. -Add the `recipient` option to the `depositETH` call to fix this. -Check out the [Optimism SDK docs](https://sdk.optimism.io/classes/crosschainmessenger#depositETH-2) for more info on the options you can pass to `depositETH`. - + {

Wait for L1 transaction

} -{

Wait for the deposit to be relayed

} + Wait for the L1 transaction to be processed and log the receipt. -You can use the `waitForMessageStatus` function to wait for the deposit to be relayed to L2. + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L52-L53 hash=0de1fe6dd17f753ab80d356b38d9ca41 + ``` -```js file=/public/tutorials/cross-dom-bridge-eth.js#L28 hash=659971675ab8d53bc2bd5196f72c873b -``` + {

Extract the L2 transaction hash

} -{

Check your wallet balance on L1

} + Extracts the corresponding L2 transaction hash from the L1 receipt, and logs it. + This hash represents the deposit transaction on L2. -You should now have less ETH on L1. + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L55-L56 hash=07a053f25193bcfcb9dae397091d755a + ``` -```js file=/public/tutorials/cross-dom-bridge-eth.js#L31 hash=3be1dd9a6019e9f59ad6fab38e168e99 -``` + {

Wait for the L2 transaction to be processed

} -{

Check your wallet balance on L2

} + Wait for the L2 transaction to be processed and confirmed and logs the L2 receipt to verify completion. -You should now have more ETH on L2. + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L58-L62 hash=4ab7fdff1700699951ced567db6d4710 + ``` + + -```js file=/public/tutorials/cross-dom-bridge-eth.js#L34 hash=7884641849eab1590b148118d709f0fd -``` + + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L3-L63 hash=b7d72a54dcdbb9b89c6874e2862fde00 + ``` + + - + + Using a smart contract wallet? + As a safety measure, `depositETH` will fail if you try to deposit ETH from a smart contract wallet without specifying a `recipient`. + Add the `recipient` option to the `depositETH` call to fix this. + ## Withdraw ETH @@ -207,81 +205,102 @@ You just bridged some ETH from L1 to L2. Nice! Now you're going to repeat the process in reverse to bridge some ETH from L2 to L1. - + + + + {

Create the withdrawal transaction

} -{

Start your withdrawal on L2

} + Uses `buildWithdrawalTransaction` to create the withdrawal parameters. + Converts the withdrawal amount to `wei` and specifies the recipient on L1. -The first step to withdrawing ETH from L2 to L1 is to start the withdrawal on L2. + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L68-L72 hash=cd22b075bb05dc05ac92c5502aa0568f + ``` -```js file=/public/tutorials/cross-dom-bridge-eth.js#L37-L38 hash=e9880eb7e7e95253637b5b88a4772074 -``` + {

Executing the withdrawal

} -{

Check your wallet balance on L2

} + This sends the withdrawal transaction on L2, which initiates the withdrawal process on L2 and logs a transaction hash for tracking the withdrawal. -You should now have less ETH on L2, but your wallet balance on L1 will not have changed yet. + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L74-L75 hash=e5f3d46ba9f417fddfa4b861f3f6f208 + ``` -```js file=/public/tutorials/cross-dom-bridge-eth.js#L41 hash=7884641849eab1590b148118d709f0fd -``` + {

Confirming L2 transaction

} -{

Wait until the withdrawal is ready to prove

} + Wait one hour (max) for the L2 Output containing the transaction to be proposed, and log the receipt, which contains important details like the block number etc. -The second step to withdrawing ETH from L2 to L1 is to prove to the bridge on L1 that the withdrawal happened on L2. -You first need to wait until the withdrawal is ready to prove. + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L77-L78 hash=37f83c57e384910a0e5bf7040c52aa7a + ``` -```js file=/public/tutorials/cross-dom-bridge-eth.js#L44 hash=e8b55ec0f16f90ba4d4197cf47ff8e6d -``` + {

Wait for withdrawal prove

} - -This step can take a few minutes. -Feel free to take a quick break while you wait. - + Next, is to prove to the bridge on L1 that the withdrawal happened on L2. To achieve that, you first need to wait until the withdrawal is ready to prove. -{

Prove the withdrawal on L1

} + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L80-L83 hash=c1c63ecb4c7f47bc2779fedabb5f70ab + ``` -Once the withdrawal is ready to be proven, you'll send an L1 transaction to prove that the withdrawal happened on L2. + Build parameters to prove the withdrawal on the L2. -```js file=/public/tutorials/cross-dom-bridge-eth.js#L47 hash=fee5f5e924472ee9daceb681ccae1cb9 -``` + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L85-L88 hash=2bc88cda19bd39bfa89451906e4e1ae7 + ``` -{

Wait until the withdrawal is ready for relay

} + {

Prove the withdrawal on the L1

} -The final step to withdrawing ETH from L2 to L1 is to relay the withdrawal on L1. -This can only happen after the fault proof period has elapsed. -On OP Mainnet, this takes 7 days. + Once the withdrawal is ready to be proven, you'll send an L1 transaction to prove that the withdrawal happened on L2. - -We're currently testing fault proofs on OP Sepolia, so withdrawal times reflect Mainnet times. - + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L90-L92 hash=312b1d49267d75ec0475bc507ae9a742 + ``` -```js file=/public/tutorials/cross-dom-bridge-eth.js#L50 hash=55a41ac5586b8a688ffd6dfbb20f2d15 -``` + {

Wait for withdrawal finalization

} -{

Relay the withdrawal on L1

} + Before a withdrawal transaction can be finalized, you will need to wait for the finalization period. + This can only happen after the fault proof period has elapsed. On OP Mainnet, this takes 7 days. -Once the withdrawal is ready to be relayed you can finally complete the withdrawal process. + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L94-L97 hash=15e6f754d2e9f11a03f400813efef383 + ``` -```js file=/public/tutorials/cross-dom-bridge-eth.js#L66 hash=f8d30944dad1664d82b9fdf14da59f9e -``` + + We're currently testing fault proofs on OP Sepolia, so withdrawal times + reflect Mainnet times. + -{

Wait until the withdrawal is relayed

} + {

Finalize the withdrawal

} -Now you simply wait until the message is relayed. + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L99-L102 hash=02f0f111055d889d627785754e6935ae + ``` -```js file=/public/tutorials/cross-dom-bridge-eth.js#L69 hash=c2c14a739c44011a058e9848a0019f15 -``` + {

Wait until the withdrawal is finalized

} -{

Check your wallet balance on L1

} + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L104-L106 hash=b3e63b66595ba34594c366e69a451abe + ``` -You should now have more ETH on L1. + {

Check the withdrawal status

} -```js file=/public/tutorials/cross-dom-bridge-eth.js#L72 hash=3be1dd9a6019e9f59ad6fab38e168e99 -``` + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L108-L112 hash=3bd3e14a6c32270cc75d6b691e7b0c91 + ``` + + - + + + ```js file=/public/tutorials/cross-dom-bridge-eth.js#L68-L111 hash=4a8d4d442b95aaf0853147420eb131af + ``` + + + + +## Important Considerations + + + * Challenge period: The 7-day withdrawal challenge Period is crucial for security. + * Gas costs: Withdrawals involve transactions on both L2 and L1, each incurring gas fees. + * Private Key handling: Use secure key management practices in real applications. + * RPC endpoint security: Keep your API key (or any RPC endpoint) secure. + ## Next Steps -Congrats! -You've just deposited and withdrawn ETH using the Optimism SDK. -You should now be able to write applications that use the Optimism SDK to transfer ETH between L1 and L2. +* Develop a user interface for easier interaction with these bridging functions. +* Implement robust error handling and retry mechanisms for production use. + +You've just deposited and withdrawn ETH using `viem/op-stack`. +You should now be able to write applications that use `viem/op-stack` to transfer ETH between L1 and L2. Although this tutorial used Sepolia and OP Sepolia, the same process works for Ethereum and OP Mainnet. diff --git a/pages/builders/app-developers/tutorials/cross-dom-solidity.mdx b/pages/builders/app-developers/tutorials/cross-dom-solidity.mdx index b846658c1..1aa33fb07 100644 --- a/pages/builders/app-developers/tutorials/cross-dom-solidity.mdx +++ b/pages/builders/app-developers/tutorials/cross-dom-solidity.mdx @@ -1,36 +1,32 @@ --- -title: Communicating Between OP Mainnet and Ethereum in Solidity +title: Communicating between OP Stack and Ethereum in Solidity lang: en-US -description: Learn how to write Solidity contracts on OP Mainnet and Ethereum that can talk to each other. +description: Learn how to write Solidity contracts on OP Stack and Ethereum that can talk to each other. --- import { Steps, Callout, Tabs } from 'nextra/components' -import { WipCallout } from '@/components/WipCallout' - -# Communicating Between OP Mainnet and Ethereum in Solidity +# Communicating between OP Stack and Ethereum in Solidity - - -This tutorial explains how to write Solidity contracts on OP Mainnet and Ethereum that can talk to each other. -Here you'll use a contract on OP Mainnet that can set a "greeting" variable on a contract on Ethereum, and vice-versa. +This tutorial explains how to write Solidity contracts on OP Stack and Ethereum that can talk to each other. +Here you'll use a contract on OP Stack that can set a "greeting" variable on a contract on Ethereum, and vice-versa. This is a simple example, but the same technique can be used to send any kind of message between the two chains. You won't actually be deploying any smart contracts as part of this tutorial. -Instead, you'll reuse existing contracts that have already been deployed to OP Mainnet and Ethereum. +Instead, you'll reuse existing contracts that have already been deployed to OP Stack and Ethereum. Later in the tutorial you'll learn exactly how these contracts work so you can follow the same pattern to deploy your own contracts. -Just looking to bridge tokens between OP Mainnet and Ethereum? -Check out the tutorial on [Bridging ERC-20 Tokens to OP Mainnet With the Optimism SDK](./cross-dom-bridge-erc20). +Just looking to bridge tokens between OP Stack and Ethereum? +Check out the tutorial on [Bridging ERC-20 Tokens to OP Stack With the viem](./cross-dom-bridge-erc20). -## Message Passing Basics +## Message passing basics -OP Mainnet uses a smart contract called the `CrossDomainMessenger` to pass messages between OP Mainnet and Ethereum. +OP Stack uses a smart contract called the `CrossDomainMessenger` to pass messages between OP Stack and Ethereum. Both chains have a version of this contract (the `L1CrossDomainMessenger` and the `L2CrossDomainMessenger`). -Messages sent from Ethereum to OP Mainnet are automatically relayed behind the scenes. -Messages sent from OP Mainnet to Ethereum must be explicitly relayed with a second transaction on Ethereum. +Messages sent from Ethereum to OP Stack are automatically relayed behind the scenes. +Messages sent from OP Stack to Ethereum must be explicitly relayed with a second transaction on Ethereum. Read more about message passing in the guide to [Sending Data Between L1 and L2](/builders/app-developers/bridging/messaging). ## Dependencies @@ -48,7 +44,7 @@ You can use [this faucet](https://sepoliafaucet.com/) to get ETH on Sepolia. You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on OP Sepolia. -## Review the Contracts +## Review the contracts You're about to use two contracts that have already been deployed to Sepolia and OP Sepolia, the `Greeter` contracts. You can review the source code for the L1 `Greeter` contract [here on Etherscan](https://sepolia.etherscan.io/address/0x31A6Dd971306bb72f2ffF771bF30b1B98dB8B2c5#code). You can review the source code for the L2 `Greeter` contract [here on Etherscan](https://sepolia-optimism.etherscan.io/address/0x5DE8a2957eddb140567fF90ba5d57bc9769f3055#code). @@ -57,7 +53,7 @@ Both contracts have exactly the same source code. Feel free to review the source code for these two contracts now if you'd like. This tutorial will explain how these contracts work in detail later on in the [How It Works](#how-it-works) section below. -## Interact With the L1 Greeter +## Interact with the L1 Greeter You're first going to use the L1 `Greeter` contract to set the greeting on the L2 `Greeter` contract. You'll send a transaction directly to the L1 `Greeter` contract which will ask the `L1CrossDomainMessenger` to send a message to the L2 `Greeter` contract. @@ -82,8 +78,8 @@ It will take a few minutes for your message to reach L2. Feel free to take a quick break while you wait. -You can use the Optimism SDK to programmatically check the status of any message between L1 and L2. -Later on in this tutorial you'll learn how to use the Optimism SDK and the `waitForMessageStatus` function to wait for various message statuses. +You can use Viem to programmatically check the status of any message between L1 and L2. +Later on in this tutorial you'll learn how to use Viem and the `waitToProve` function to wait for various message statuses. This same function can be used to wait for a message to be relayed from L1 to L2. @@ -102,7 +98,7 @@ L2 transactions triggered on L1 are typically processed within one minute but ca -## Interact With the L2 Greeter +## Interact with the L2 Greeter Now you're going to use the L2 `Greeter` contract to set the greeting on the L1 `Greeter` contract. You'll send a transaction directly to the L2 `Greeter` contract which will ask the `L2CrossDomainMessenger` to send a message to the L1 `Greeter` contract. @@ -129,15 +125,14 @@ Feel free to keep this tab open so you can easily copy the transaction hash late {

Create a demo project folder

} -You're going to use the Optimism SDK to prove and relay your message to L1. -Since the Optimism SDK is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. +You're going to use the viem to prove and relay your message to L1. ```bash -mkdir op-sample-project -cd op-sample-project +mkdir cross-dom +cd cross-dom ``` -{

Initialize the Project

} +{

Initialize the project

} Set up the project as a basic Node.js project with `pnpm` or your favorite package manager. @@ -145,20 +140,12 @@ Set up the project as a basic Node.js project with `pnpm` or your favorite packa pnpm init ``` -{

Install the Optimism SDK

} +{

Install viem

} -Install the Optimism SDK with `pnpm` or your favorite package manager. +Install Viem with `pnpm` or your favorite package manager. ```bash -pnpm add @eth-optimism/sdk -``` - -{

Install ethers.js

} - -Install `ethers` with `pnpm` or your favorite package manager. - -```bash -pnpm add ethers@^5 +pnpm add viem ``` {

Add your private key to your environment

} @@ -189,46 +176,27 @@ Start the Node.js REPL with the `node` command. node ``` -{

Import the Optimism SDK

} - -```js file=/public/tutorials/cross-dom-solidity.js#L3 hash=26b2fdb17dd6c8326a54ec51f0769528 -``` - -{

Import ethers.js

} +{

Import Viem

} -```js file=/public/tutorials/cross-dom-solidity.js#L4 hash=69a65ef97862612e4978b8563e6dbe3a -``` - -{

Load your private key

} - -```js file=/public/tutorials/cross-dom-solidity.js#L6 hash=755b77a7ffc7dfdc186f36c37d3d847a +```js file=/public/tutorials/cross-dom-solidity.js#L3-L5 hash=65b9a5ad5b634bc2e424f5664e6e1f84 ``` {

Load your transaction hash

} -```js file=/public/tutorials/cross-dom-solidity.js#L8 hash=320cd4f397d7bed8d914d4be0c99f8dc +```js file=/public/tutorials/cross-dom-solidity.js#L7 hash=320cd4f397d7bed8d914d4be0c99f8dc ``` {

Create the RPC providers and wallets

} -```js file=/public/tutorials/cross-dom-solidity.js#L10-L13 hash=9afdce50665ae93bce602068071ffaa1 -``` - -{

Create a CrossChainMessenger instance

} - -The Optimism SDK exports a `CrossChainMessenger` class that makes it easy to prove and relay cross-chain messages. - -Create an instance of the `CrossChainMessenger` class: - -```js file=/public/tutorials/cross-dom-solidity.js#L15-L20 hash=997b9c4cdd5fb1f9d4e0882a683ae016 +```js file=/public/tutorials/cross-dom-solidity.js#L8-L9 hash=d47e4991c5153e1e1dc55de5047a8a3e ``` {

Wait until the message is ready to prove

} -The second step to send messages from L2 to L1 is to prove that the message was sent on L2. +Next, you will send messages from L2 to L1 is to prove that the message was sent on L2. You first need to wait until the message is ready to prove. -```js file=/public/tutorials/cross-dom-solidity.js#L23 hash=25a072666b6147f8d8983d8223f045b8 +```js file=/public/tutorials/cross-dom-solidity.js#L12-L16 hash=df275e659d954eb72b8c5765d9baf6de ``` @@ -240,34 +208,34 @@ Feel free to take a quick break while you wait. Once the message is ready to be proven, you'll send an L1 transaction to prove that the message was sent on L2. -```js file=/public/tutorials/cross-dom-solidity.js#L26 hash=17922abea43b3d379404fedd87422dde +```js file=/public/tutorials/cross-dom-solidity.js#L18-L23 hash=e4d608ac2c2ceb5a744c8474679bd8cb ``` {

Wait until the message is ready for relay

} The final step to sending messages from L2 to L1 is to relay the messages on L1. This can only happen after the fault proof period has elapsed. -On OP Mainnet, this takes 7 days. +On OP Stack, this takes 7 days. We're currently testing fault proofs on OP Sepolia, so withdrawal times reflect Mainnet times. -```js file=/public/tutorials/cross-dom-solidity.js#L29 hash=45d995aab47ec29afee4bb4577ae9303 +```js file=/public/tutorials/cross-dom-solidity.js#L25-L29 hash=88cec1db2fde515ea9008eaa1bbdfd73 ``` {

Relay the message on L1

} Once the withdrawal is ready to be relayed you can finally complete the message sending process. -```js file=/public/tutorials/cross-dom-solidity.js#L32 hash=b5515811ffcf8b9ada15dea8ae666e44 +```js file=/public/tutorials/cross-dom-solidity.js#L31-L33 hash=d7e47c9787d92e2140622a6bdcc6d7bb ``` {

Wait until the message is relayed

} Now you simply wait until the message is relayed. -```js file=/public/tutorials/cross-dom-solidity.js#L35 hash=d6e7f89e929eea0ac3217a6751b7e578 +```js file=/public/tutorials/cross-dom-solidity.js#L35-L36 hash=4ff3cdc48f17cfd7de4a6ef2d2671dc2 ``` {

Check the L1 Greeter

} @@ -279,14 +247,14 @@ You should see the message you sent from L2. -## How It Works +## How it works Congratulations! You've successfully sent a message from L1 to L2 and from L2 to L1. This section will explain how the `Greeter` contracts work so you can follow the same pattern to deploy your own contracts. Luckily, both `Greeter` contracts are exactly the same so it's easy to see how everything comes together. -### The Messenger Variable +### The Messenger variable The `Greeter` contract has a `MESSENGER` variable that keeps track of the `CrossDomainMessenger` contract on the current chain. Check out the [Contract Addresses page](/chain/addresses) to see the addresses of the `CrossDomainMessenger` contracts on whichever network you'll be using. @@ -294,7 +262,7 @@ Check out the [Contract Addresses page](/chain/addresses) to see the addresses o ```solidity file=/public/tutorials/cross-dom-solidity.sol#L14 hash=ce8be857d4b4e1992cd3c16b8f2864b9 ``` -### The Other Greeter Variable +### The other Greeter variable The `Greeter` contract also has an `OTHER_GREETER` variable that keeps track of the `Greeter` contract on the other chain. On L1, this variable is set to the address of the L2 `Greeter` contract, and vice-versa. @@ -302,7 +270,7 @@ On L1, this variable is set to the address of the L2 `Greeter` contract, and vic ```solidity file=/public/tutorials/cross-dom-solidity.sol#L15 hash=eedd8c3050a83e56f37f367c6faa6f5d ``` -### The Greetings Mapping +### The Greetings mapping The `Greeter` contract keeps track of the different greetings that users have sent inside a `greetings` mapping. By using a mapping, this contract can keep track of greetings from different users at the same time. @@ -317,7 +285,7 @@ The `Greeter` has a simple constructor that sets the `MESSENGER` and `OTHER_GREE ```solidity file=/public/tutorials/cross-dom-solidity.sol#L18-L24 hash=718f3dc498975548eec30da99e47adf2 ``` -### The Send Greeting Function +### The sendGreeting function The `sendGreeting` function is the most important function in the `Greeter` contract. This is what you called earlier to send messages in both directions. @@ -330,7 +298,7 @@ The final parameter is the gas limit that gets used when the message is relayed ```solidity file=/public/tutorials/cross-dom-solidity.sol#L26-L38 hash=3104a6775fe3a505cf2f84b71b078aee ``` -### The Set Greeting Function +### The setGreeting function The `setMessage` function is the function that actually sets the greeting. This function is called by the `CrossDomainMessenger` contract on the other chain. @@ -350,10 +318,10 @@ You can follow a similar pattern in your own smart contracts. ## Conclusion You just learned how you can write Solidity contracts on Sepolia and OP Sepolia that can talk to each other. -You can follow the same pattern to write contracts that can talk to each other on Ethereum and OP Mainnet. +You can follow the same pattern to write contracts that can talk to each other on Ethereum and OP Stack. This sort of cross-chain communication is useful for a variety of reasons. -For example, the [Standard Bridge](/builders/app-developers/bridging/standard-bridge) contracts use this same system to bridge ETH and ERC-20 tokens between Ethereum and OP Mainnet. +For example, the [Standard Bridge](/builders/app-developers/bridging/standard-bridge) contracts use this same system to bridge ETH and ERC-20 tokens between Ethereum and OP Stack. -One cool way to take advantage of cross-chain communication is to do most of your heavy lifting on OP Mainnet and then send a message to Ethereum only when you have important results to share. -This way you can take advantage of the low gas costs on OP Mainnet while still being able to use Ethereum when you need it. +One cool way to take advantage of cross-chain communication is to do most of your heavy lifting on OP Stack and then send a message to Ethereum only when you have important results to share. +This way you can take advantage of the low gas costs on OP Stack while still being able to use Ethereum when you need it. diff --git a/pages/builders/app-developers/tutorials/first-contract.mdx b/pages/builders/app-developers/tutorials/first-contract.mdx deleted file mode 100644 index 52bd22337..000000000 --- a/pages/builders/app-developers/tutorials/first-contract.mdx +++ /dev/null @@ -1,367 +0,0 @@ ---- -title: Deploying Your First Contract on OP Mainnet -lang: en-US -description: Learn how to write and deploy your first contract on OP Mainnet using the MetaMask browser extension. ---- - -import { Callout, Steps } from 'nextra/components' - -# Deploying Your First Contract on OP Mainnet - - -**This tutorial is meant for developers who are new to OP Mainnet and Solidity.** -If you're already familiar with Solidity, consider reading the [OP Mainnet Differences](/chain/differences) guide to understand how OP Mainnet differs from Ethereum. -OP Mainnet is designed to "just work" with existing Ethereum tooling, so you can use the tools you already know like [Hardhat](https://hardhat.org/) or [Foundry](https://getfoundry.sh) just like you would on Ethereum. - - -This tutorial walks you through the process of deploying your first smart contract to OP Mainnet using the [Remix](https://remix.ethereum.org) in-browser Solidity IDE. - -## Dependencies - -* Firefox or any Chromium-based browser (Chrome, Brave, Edge, etc.) - -## Wallet Setup - -You'll need access to an [Ethereum wallet](https://ethereum.org/en/wallets/) if you want to deploy a smart contract. -This tutorial uses [MetaMask](https://metamask.io), a popular browser extension wallet, just to get you started. -MetaMask is also available as a mobile application, but it's typically easier to use the browser extension for development. -If you already have MetaMask installed, you can skip this section. - - -Browser-based wallets like MetaMask are convenient for development, but they're not the most secure option. -You should never store large amounts of ETH or ERC-20 tokens in a browser-based wallet. -If you're planning to store a significant amount of ETH or ERC-20 tokens, consider using a hardware wallet instead. - - - - -{

Install the MetaMask extension for your browser

} - -Head over to [metamask.io](https://metamask.io) and click the "Download" button. -You'll then be given an option to install the MetaMask extension for your browser. -If using a Chromium-based browser, you may be prompted to install the MetaMask extension from the Chrome Web Store. -An onboarding page will pop up once the extension is installed. - -![MetaMask download page.](/img/builders/app-developers/tutorials/first-contract/mm-install.png) - -{

Continue to create a new wallet

} - -MetaMask will ask you to accept their terms of service. -Read them carefully, then tick the box to accept them. -Once you've accepted the terms of service, you can create a new wallet by clicking the "Create a new wallet" button. - -![MetaMask wallet creation page.](/img/builders/app-developers/tutorials/first-contract/mm-start.png) - -{

Decide if you want to share usage data

} - -After starting the wallet creation process you'll be asked if you'd like to share usage data with MetaMask. -This is entirely up to you. -Select "I agree" or "No thanks" depending on your preference. - -{

Create a password

} - -You'll be asked to create a password for your wallet. -This password will be used to encrypt your wallet, so make sure it's a strong one that you won't forget. - -You'll be asked to confirm that you understand MetaMask cannot recover your password if you lose it. -You may want to store this password in a password manager. -Remember, browser-based wallets are great for development but are not the most secure option. -Consider looking into a hardware wallet if you're planning to store a significant amount of ETH or ERC-20 tokens. - -Once you've written down your password, click "Create a new wallet" to continue. - -![MetaMask password creation page.](/img/builders/app-developers/tutorials/first-contract/mm-password.png) - -{

Watch the short security video

} - -MetaMask will now show you a short video about wallet security. -If this is your first time using MetaMask or a browser-based wallet, it's recommended that you watch the video. - -{

Secure your wallet

} - -You'll be presented with the option to "Secure my wallet (recommended)" or "Remind me later (not recommended)". -It's strongly recommended to continue with the "Secure my wallet (recommended)" option. -This will prompt you to back up your wallet and might prevent you from losing access to your wallet down the line. - -![MetaMask security video page.](/img/builders/app-developers/tutorials/first-contract/mm-secure.png) - -{

Write down your secret recovery phrase

} - -After continuing with "Secure my wallet (recommended)", you'll be asked to write down a 12 word secret recovery phrase. -This phrase can be used to recover your wallet if you lose your password or the browser extension somehow becomes corrupted. -Write these words down somewhere safe and keep them secret. -For a development wallet, it's fine to keep the phrase in a password manager. -Just don't place too much importance in this wallet. - -![MetaMask recovery phrase page.](/img/builders/app-developers/tutorials/first-contract/mm-seed.png) - -{

Confirm your secret recovery phrase

} - -After writing down your secret recovery phrase, you'll be asked to confirm it. -This is to make sure you wrote it down correctly. -MetaMask will ask you to input a few of the words you wrote down. -Make sure to input them in the correct order. - -![MetaMask recovery confirmation page.](/img/builders/app-developers/tutorials/first-contract/mm-confirm.png) - -{

Complete the wallet creation process

} - -You're all done! -Read through the final page to get some more tips from MetaMask, then click "Got it!" when you're ready to continue. - - - - -Want to explore wallets other than MetaMask? -There are many different kinds of wallets out there. -You can use [Ethereum.org's "Find a wallet" feature](https://ethereum.org/en/wallets/find-wallet/) to find one that works for you. - - -## Add OP Sepolia to MetaMask - -This tutorial will show you how to deploy a smart contract to OP Sepolia, the testnet for OP Mainnet. -Once you know how to deploy a smart contract to OP Sepolia, you'll be able to deploy a smart contract to OP Mainnet in exactly the same way. -In order to interact with OP Sepolia using MetaMask, you'll need to add it as a custom network. - - - -{

Open the OP Sepolia connection link

} - -Click [this link](https://chainid.link/?network=op-sepolia) to open the OP Sepolia connection link. -This link will show you the connection details for OP Sepolia and give you the option to add it to MetaMask. -Once you're ready to connect to OP Sepolia, click the "connect" button. - -![OP Sepolia connection website content.](/img/builders/app-developers/tutorials/first-contract/net-connect.png) - -{

Allow the site to add the network

} - -You'll be presented with a popup from MetaMask asking if you'd like to add the network. -Click "Approve" to add OP Sepolia to MetaMask. - -
-![MetaMask window with the network approval pane open.](/img/builders/app-developers/tutorials/first-contract/net-approve.png) -
- -{

Switch to the OP Sepolia network

} - -After you approve the network, MetaMask will automatically try to switch to the OP Sepolia network. -Click "Switch network" to continue. - -
-![MetaMask window with the network switching pane open.](/img/builders/app-developers/tutorials/first-contract/net-switch.png) -
- - - -## Get ETH on OP Sepolia - -You'll need some ETH on OP Sepolia to pay for the [gas fees](https://ethereum.org/en/developers/docs/gas/) associated with deploying a smart contract. -You can use the [Optimism Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get some free ETH on OP Sepolia. - - -Having issues with the Optimism Superchain Faucet? -You can try using [other available OP Sepolia faucets](/builders/tools/build/faucets) instead. - - -## Check Your Wallet Balance - -After you get some ETH on OP Sepolia, you can check your wallet balance in MetaMask. -Make sure that your balance has updated before continuing. -If you don't see any ETH in your wallet, double check that your MetaMask is connected to the OP Sepolia network. - -## Write Your First Contract - -The most popular smart contract development language today is [Solidity](https://docs.soliditylang.org/en/latest/). -In this tutorial, you'll be using a browser-based integrated development environment (IDE) called [Remix](https://remix.ethereum.org/). -Remix is a great tool for learning Solidity because it requires minimal setup and runs in your browser. - - - -{

Open Remix

} - -Head over to [remix.ethereum.org](https://remix.ethereum.org/) to open Remix. -You'll be presented with a welcome screen and a popup asking if you'd like to share usage data with Remix. -Accept or decline this request depending on your preferences. - -{

Step through the tutorial

} - -Remix has a small built-in tutorial that will walk you through the basics of the IDE. -Click the "Next" button to step through the tutorial. -Read through the tips to get a sense of the IDE. - -{

Create an empty contract file

} - -Click on the "File" icon in the left sidebar to create a new file. -Name the file "MyFirstContract.sol" and hit enter to create it. - -![Remix window displaying the empty MyFirstContract file.](/img/builders/app-developers/tutorials/first-contract/remix-empty.png) - -{

Write your first contract

} - -This tutorial will show you how to deploy a simple contract that has a storage variable you can read and write. -You'll be able to update this variable with a transaction and then retrieve the updated value. -This is just a simple example to get you started. -Solidity is a powerful language that can be used to write complex smart contracts, check out the [Next Steps](#next-steps) section below after you've finished this tutorial for some more advanced examples! - -Copy and paste the following code into the file you just created. -Remix will detect copy/pasted code and give you a warning about it. -This is meant to prevent you from accidentally running malicious code. -Always be careful when copy/pasting code from the internet! - -```solidity file=/public/tutorials/first-contract.sol#L1-L10 hash=a008d0629d499be56a6629495bc55910 -``` - -{

Compile your contract

} - -By default, Remix will automatically compile your contract when you save it. -You can also manually compile your contract by clicking the "Solidity Compiler" icon in the left sidebar and then clicking the "Compile" button. -It's usually easier to leave automatic compilation enabled. -You shouldn't see any compilation errors for this contract. - -![Remix window with the compilation tab highlighted.](/img/builders/app-developers/tutorials/first-contract/remix-compile.png) - - - -## Deploy Your Contract - -Now that you've written your first contract, you can deploy it to OP Sepolia. -Deploying contracts with Remix is pretty straightforward. - - - -{

Open the Deploy tab

} - -Click on the "Deploy & run transactions" icon in the left sidebar to open the Deploy tab (it looks like an Ethereum logo with an arrow pointing to the right). -You'll see some deployment options and a list of contracts that are currently compiled. -Since you only have one contract, you should see a single contract called "MyFirstContract" in the list. - -![Remix window with the deployment tab highlighted.](/img/builders/app-developers/tutorials/first-contract/remix-deploytab.png) - -{

Change your environment

} - -By default, Remix will try to deploy your contract to a local, in-memory blockchain. -This is useful for testing, but you'll need to change your environment to deploy to OP Sepolia for this tutorial. -Click on the dropdown underneath the "Environment" heading and select "Injected Provider - MetaMask". - -![Remix window with the environment dropdown highlighted.](/img/builders/app-developers/tutorials/first-contract/remix-network.png) - -{

Accept the connection request

} - -Once you've selected the "Injected Provider - MetaMask" option, MetaMask will show you a popup asking if you'd like to connect to Remix. -Accept this request by clicking the "Connect" button. - -{

Deploy your contract

} - -You're now ready to deploy your contract! -Click the orange "Deploy" button to deploy your contract to OP Sepolia. -You'll be presented with another MetaMask popup asking you to confirm the transaction. -Click the "Confirm" button to continue. - -
-![MetaMask contract deployment approval popup.](/img/builders/app-developers/tutorials/first-contract/remix-deploy.png) -
- -{

Wait for your transaction to confirm

} - -OP Sepolia is relatively fast, so transactions should confirm within just a few seconds. -Remix will automatically detect when your transaction has confirmed and will show you your newly deployed contract under the "Deployed Contracts" heading within the Deploy tab. - - - -## Interact With Your Contract - -Now that you've deployed your contract, you can interact with it. -Remix makes it easy to interact with your contract by providing a built-in user interface. -You can use this interface to call functions on your contract and read its state. - - - -{

Expand your contract

} - -Click on the arrow next to the name of your contract under the "Deployed Contracts" heading to expand it. -You should see a list of functions that you can call on your contract. - -![Remix window with the deployed contract area highlighted.](/img/builders/app-developers/tutorials/first-contract/remix-deployed.png) - -{

Call the setMessage function

} - -Now you'll update the message variable in your contract. -Type a message into the input box next to the orange "setMessage" button and click on the "setMessage" button. -Just like when you deployed your contract, you'll be presented with a MetaMask popup asking you to confirm the transaction. -Click the "Confirm" button to continue. - -![Remix window with the setMessage function button highlighted.](/img/builders/app-developers/tutorials/first-contract/remix-setmessage.png) - -{

Wait for your transaction to confirm

} - -Once again, Remix will automatically detect when your transaction has confirmed. -You'll see a green checkmark appear in the console at the bottom of the screen. - -{

Read the updated message variable

} - -Click on the "message" button to read the updated message variable. -You should see the message you set in the previous step appear underneath the "message" button. -Congrats, you've successfully deployed and interacted with your first smart contract on OP Sepolia! - -![Remix window with the message reading function button highlighted.](/img/builders/app-developers/tutorials/first-contract/remix-message.png) - - - -## How Your Contract Works - -Now that you've deployed your contract, you might be wondering how it works. -Let's take a closer look at the code you wrote. - -### License Identifier - -The first line of most Solidity files is the license identifier. -This line is used to specify the license under which the code is released. -In this case, the code written is released under the [MIT license](https://opensource.org/licenses/MIT). - -```solidity file=/public/tutorials/first-contract.sol#L1 hash=8384d75c38c570f3edb87cf9f64f2ec2 -``` - -### Pragma Directive - -The next line is a [pragma directive](https://docs.soliditylang.org/en/latest/layout-of-source-files.html#pragma). -This line tells the Solidity compiler which version of the Solidity language to use. -In this case, the code is written for Solidity version 0.8.0 or higher. - -```solidity file=/public/tutorials/first-contract.sol#L2 hash=70ebe002bc5488bb81baa0504de273c1 -``` - -### Contract Definition - -The next line defines a contract called `MyFirstContract`. -A contract is a collection of code and data that is stored at a specific address on the blockchain. -You can think of a contract as a class in an object-oriented programming language. -The contract definition is followed by a pair of curly braces that contain the contract's code. - -```solidity file=/public/tutorials/first-contract.sol#L4 hash=8f3ace25e5f9ea06d8cb388eb3ab1775 -``` - -### Message Variable - -The first thing you'll notice inside the contract definition is a variable called `message`. -This variable is declared as a `string`, which is a Solidity type that represents a string of characters. -The `public` keyword means that this variable can be read from outside the contract. - -```solidity file=/public/tutorials/first-contract.sol#L5 hash=42a1bdfe81e5b3bba6b99d3255ef4f2b -``` - -### Message Update Function - -The next thing you'll notice is a function called `setMessage`. -This function takes a single argument called `_message` of type `string`. -The `public` keyword means that this function can be called from outside the contract by anyone. -Since this function doesn't have any access control, anyone can update the `message` variable. - -```solidity file=/public/tutorials/first-contract.sol#L7-L9 hash=b7e5531c48425b183e794f9f251c5540 -``` - -## Next Steps - -To learn more about Solidity, check out the [Solidity documentation](https://docs.soliditylang.org/en/latest/) for more information about the language itself. If you learn best by reading source code, check out [this annotated code for an ERC-20 token contract](https://ethereum.org/en/developers/tutorials/erc20-annotated-code/). - -Now that you know how to deploy a smart contract to OP Sepolia, you can deploy a smart contract to OP Mainnet in exactly the same way. -If you're up for a challenge, try [creating a token on Sepolia and OP Sepolia](./standard-bridge-standard-token) and then [using the Optimism SDK](./cross-dom-bridge-erc20) to bridge some tokens between the two networks. diff --git a/pages/builders/app-developers/tutorials/sdk-estimate-costs.mdx b/pages/builders/app-developers/tutorials/sdk-estimate-costs.mdx index 25b0f7894..8b47d81c4 100644 --- a/pages/builders/app-developers/tutorials/sdk-estimate-costs.mdx +++ b/pages/builders/app-developers/tutorials/sdk-estimate-costs.mdx @@ -1,66 +1,70 @@ --- -title: Estimating Transaction Costs on OP Mainnet +title: Estimating transaction costs on OP Stack lang: en-US -description: Learn how to use the Optimism SDK to estimate the cost of a transaction on OP Mainnet. +description: Learn how to use viem to estimate the cost of a transaction on OP Stack. --- -import { Callout, Steps } from 'nextra/components' -import { WipCallout } from '@/components/WipCallout' +import { Callout, Steps, Tabs } from 'nextra/components' - -# Estimating Transaction Costs on OP Mainnet +# Estimating transaction costs on OP Stack - -In this tutorial, you'll learn how to use the [Optimism SDK](https://sdk.optimism.io) to estimate the cost of a transaction on OP Mainnet. +In this tutorial, you'll learn how to use [viem](https://viem.sh/op-stack/) to estimate the cost of a transaction on OP Mainnet. You'll learn how to estimate the [execution gas fee](/builders/app-developers/transactions/fees#execution-gas-fee) and the [L1 data fee](/builders/app-developers/transactions/fees#l1-data-fee) independently. You'll also learn how to estimate the total cost of the transaction all at once. -Check out the full explainer on [OP Mainnet transaction fees](/builders/app-developers/transactions/fees) for more information on how OP Mainnet charges fees under the hood. + Check out the full explainer on [OP Stack transaction fees](/builders/app-developers/transactions/fees) for more information on how OP Mainnet charges fees under the hood. +## Supported networks + +Viem supports any of the [Superchain networks](/chain/networks). +The OP Stack networks are included in Viem by default. +If you want to use a network that isn't included by default, you can add it to Viem's chain configurations. + ## Dependencies * [node](https://nodejs.org/en/) * [pnpm](https://pnpm.io/installation) -## Create a Demo Project +## Create a demo project -You're going to use the Optimism SDK for this tutorial. -Since the Optimism SDK is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. +You're going to use Viem for this tutorial. +Since Viem is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. + {

Make a project folder

} -{

Make a Project Folder

} + ```bash + mkdir op-est-cost-tutorial + cd op-est-cost-tutorial + ``` -```bash -mkdir op-sample-project -cd op-sample-project -``` + {

Initialize the project

} -{

Initialize the Project

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

Install the Optimism SDK

} + {

Install viem

} -```bash -pnpm add @eth-optimism/sdk -``` + ```bash + pnpm add viem + ``` + -{

Install ethers.js

} + + Want to create a new wallet for this tutorial? + If you have [`cast`](https://book.getfoundry.sh/getting-started/installation) installed you can run `cast wallet new` in your terminal to create a new wallet and get the private key. + -```bash -pnpm add ethers@^5 -``` +## Get ETH on Sepolia - +This tutorial explains how to bridge ETH from Sepolia to OP Sepolia. +You will need to get some ETH on Sepolia to follow along. -Want to create a new wallet for this tutorial? -If you have [`cast`](https://book.getfoundry.sh/getting-started/installation) installed you can run `cast wallet new` in your terminal to create a new wallet and get the private key. + You can use [this faucet](https://sepoliafaucet.com) to get ETH on Sepolia. ## Get ETH on OP Sepolia @@ -69,14 +73,14 @@ This tutorial explains how estimate transaction costs on OP Sepolia. You will need to get some ETH on OP Sepolia in order to run the code in this tutorial. -You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on OP Sepolia. + You can use the [Superchain faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on OP Sepolia. -## Add a Private Key to Your Environment +## Add a private key to your environment You need a private key in order to sign transactions. Set your private key as an environment variable with the `export` command. -Make sure this private key corresponds to an address that has ETH on OP Sepolia. +Make sure this private key corresponds to an address that has ETH on Sepolia. ```bash export TUTORIAL_PRIVATE_KEY=0x... @@ -84,136 +88,114 @@ export TUTORIAL_PRIVATE_KEY=0x... ## Start the Node REPL -You're going to use the Node REPL to interact with the Optimism SDK. +You're going to use the Node REPL to interact with Viem. To start the Node REPL run the following command in your terminal: ```bash node ``` -This will bring up a Node REPL prompt that allows you to run javascript code. - -## Import Dependencies - -You need to import some dependencies into your Node REPL session. - - - -{

Import the Optimism SDK

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

Import ethers.js

} +This will bring up a Node REPL prompt that allows you to run JavaScript code. -```js file=/public/tutorials/sdk-estimate-costs.js#L4 hash=69a65ef97862612e4978b8563e6dbe3a -``` - - - -## Set Session Variables +## Set session variables You'll need a few variables throughout this tutorial. Let's set those up now. -{

Load your private key

} +{

Import viem and other necessary modules

} -```js file=/public/tutorials/sdk-estimate-costs.js#L6 hash=755b77a7ffc7dfdc186f36c37d3d847a +```js file=/public/tutorials/sdk-estimate-costs.js#L3-L6 hash=32ecaac58846bfe7e785e2cc35562120 ``` -{

Create the RPC provider

} - -Here you're creating a standard Ethers RPC provider and wrapping it as an `L2Provider`, a class provided by the Optimism SDK. -This will add a few extra functions to the provider object that you'll use later in this tutorial. +{

Set up the account

} -```js file=/public/tutorials/sdk-estimate-costs.js#L8 hash=1db780739476f924536f5fa58794b67f +```js file=/public/tutorials/sdk-estimate-costs.js#L8-L9 hash=165490e75b825c786a937fba7b8e159d ``` -{

Create the wallet instance

} +{

Create the public client

} -```js file=/public/tutorials/sdk-estimate-costs.js#L9 hash=d315a1ba59b2ee3f43d178bab816e930 +```js file=/public/tutorials/sdk-estimate-costs.js#L11-L14 hash=42293ff382c932f806beb7252803a848 ``` +{

Create the wallet client

} + +```js file=/public/tutorials/sdk-estimate-costs.js#L16-L19 hash=e7b6423850765242512e71589382791b +``` -## Estimate Transaction Costs +## Estimate transaction costs -You're now going to use the Optimism SDK to estimate the cost of a transaction on OP Mainnet. +You're now going to use the Viem to estimate the cost of a transaction on OP Mainnet. Here you'll estimate the cost of a simple transaction that sends a small amount of ETH from your address to the address `0x1000000000000000000000000000000000000000`. + {

Create the unsigned transaction

} -{

Create the unsigned transaction

} - -Ethers makes it easy to create unsigned transactions so you can estimate the cost of a transaction before you a user to sign it. -Here you'll create an unsigned transaction that sends a small amount of ETH from your address to the address `0x1000000000000000000000000000000000000000`. -You can also create unsigned transactions that interact with contracts using [`Contract.populateTransaction`](https://docs.ethers.org/v5/api/contract/contract/#contract-populateTransaction). + Viem makes it easy to create unsigned transactions so you can estimate the cost of a transaction before you a user to sign it. + Here you'll create an unsigned transaction that sends a small amount of ETH from your address to the address `0x1000000000000000000000000000000000000000`. -```js file=/public/tutorials/sdk-estimate-costs.js#L11-L15 hash=22d44a7322d2d378e886a0ba5a0c6fec +```js file=/public/tutorials/sdk-estimate-costs.js#L21-L26 hash=d2f3fc3df8298253bd45a226dd171dcf ``` -{

Estimate the execution gas fee

} + {

Estimate the total cost

} -You can estimate the execution gas fee the same way you'd estimate the gas fee for any transaction on Ethereum. -Simply multiply the gas limit by the effective gas price. + With Viem you can estimate the total cost of a transaction using the [estimateTotalFee](https://viem.sh/op-stack/actions/estimateTotalFee) method. -```js file=/public/tutorials/sdk-estimate-costs.js#L18-L21 hash=8090c6513655722e1194d4d9f0f794af +```js file=/public/tutorials/sdk-estimate-costs.js#L28-L29 hash=db562f050d0affe866e2114779656d3a ``` -{

Estimate the L1 data fee

} + {

Send the transaction

} -You can estimate the L1 data fee with the [`estimateL1GasCost`](https://sdk.optimism.io/modules#estimateL1GasCost) function. -Under the hood, this function is estimating the amount of Ethereum gas required to publish this transaction on Ethereum and multiplying it by the current Ethereum gas price (as tracked by the L2). -This function returns the current cost estimate in wei. + Now that you've estimated the total cost of the transaction, go ahead and send it to the network. + This will make it possible to see the actual cost of the transaction to compare to your estimate. -```js file=/public/tutorials/sdk-estimate-costs.js#L24-L25 hash=c5b1b1754aede507d071419fa051e3d7 +```js file=/public/tutorials/sdk-estimate-costs.js#L31-L35 hash=419162648c0c6c0d5e82ca8f6d4942d5 ``` -{

Estimate the total cost

} + {

Check the actual execution gas fee

} -Once you've individually estimated the execution gas fee and the L1 data fee, you can sum these two values together to get the total cost of the transaction. + Once you get back the transaction receipt, check the actual execution gas fee. + You can do so by accessing the `gasUsed` and `effectiveGasPrice` from the transaction receipt. + You can then multiply these values to get the actual L2 cost of the transaction -```js file=/public/tutorials/sdk-estimate-costs.js#L28-L29 hash=f7315f3dbf96423569a42c902eeee45c +```js file=/public/tutorials/sdk-estimate-costs.js#L37-L38 hash=57dba68f78481bea90e7629270a1f58b ``` -{

Send the transaction

} + {

Check the actual L1 data fee

} -Now that you've estimated the total cost of the transaction, go ahead and send it to the network. -This will make it possible to see the actual cost of the transaction to compare to your estimate. + You can also check the actual L1 data fee. -```js file=/public/tutorials/sdk-estimate-costs.js#L32-L34 hash=f0cc7ae37a28a884aa7f47f13b381681 +```js file=/public/tutorials/sdk-estimate-costs.js#L40-L41 hash=e728708954c71fe52c55912dbe778042 ``` -{

Check the actual execution gas fee

} + {

Check the actual total cost

} -Once you get back the transaction receipt, check the actual execution gas fee. + Sum these two together to get the actual total cost of the transaction. -```js file=/public/tutorials/sdk-estimate-costs.js#L37-L38 hash=3b3ce48412906a44c1d2f6861a99c8a0 +```js file=/public/tutorials/sdk-estimate-costs.js#L43-L44 hash=38a1eadb48d89d476ea51658514d23c0 ``` -{

Check the actual L1 data fee

} + {

Check the difference

} -You can also check the actual L1 data fee. + Finally, check the difference between the estimated total cost and the actual total cost. + This will give you a sense of how accurate your estimate was. + Estimates will never be entirely accurate, but they should be close! -```js file=/public/tutorials/sdk-estimate-costs.js#L41-L42 hash=3438ad167823b837f3511759a06e73f3 +```js file=/public/tutorials/sdk-estimate-costs.js#L46-L47 hash=20c8c60af1cc39e842b207cfd2dfa2cb ``` + -{

Check the actual total cost

} - -Sum these two together to get the actual total cost of the transaction. - -```js file=/public/tutorials/sdk-estimate-costs.js#L45-L46 hash=d23b6db1b716cba154932fd3d261995e -``` - -{

Check the difference

} - -Finally, check the difference between the estimated total cost and the actual total cost. -This will give you a sense of how accurate your estimate was. -Estimates will never be entirely accurate, but they should be close! + +Estimates will never be entirely accurate due to network conditions and gas price fluctuations, but they should be close to the actual costs. + -```js file=/public/tutorials/sdk-estimate-costs.js#L49-L50 hash=358adb5552c9f00484a6bb0580109fd8 -``` +## Next steps - +* Always estimate before sending: Estimating costs before sending a transaction helps prevent unexpected fees and failed transactions. +* Account for gas price volatility: Gas prices can change rapidly. Consider adding a buffer to your estimates or implementing a gas price oracle for more accurate pricing. +* Optimize transaction data: Minimize the amount of data in your transactions to reduce L1 data fees. +* Monitor network conditions: Keep an eye on network congestion and adjust your estimates accordingly. +* Use appropriate gas limits: Setting too low a gas limit can cause transactions to fail, while setting it too high can result in unnecessary costs. +* Implement retry mechanisms: If a transaction fails due to underestimated gas, implement a retry mechanism with adjusted gas parameters. diff --git a/pages/builders/app-developers/tutorials/sdk-trace-txns.mdx b/pages/builders/app-developers/tutorials/sdk-trace-txns.mdx index 3a70bacec..637d7cb6a 100644 --- a/pages/builders/app-developers/tutorials/sdk-trace-txns.mdx +++ b/pages/builders/app-developers/tutorials/sdk-trace-txns.mdx @@ -1,5 +1,5 @@ --- -title: Tracing Deposits and Withdrawals +title: Tracing deposits and withdrawals lang: en-US description: Learn how to use the Optimism SDK to trace deposits and withdrawals between L1 and L2. --- @@ -8,9 +8,7 @@ import { Callout, Steps } from 'nextra/components' import { WipCallout } from '@/components/WipCallout' -# Tracing Deposits and Withdrawals - - +# Tracing deposits and withdrawals In this tutorial, you'll learn how to use the [Optimism SDK](https://sdk.optimism.io) to trace a [Standard Bridge](../bridging/standard-bridge) deposit or withdrawal between L1 and L2. You'll specifically learn how to determine the status of a deposit or withdrawal and how to retrieve the transaction receipt for the executed transaction on L1 (for withdrawals) or L2 (for deposits). @@ -25,7 +23,7 @@ You can also check out the tutorial on [Viewing Deposits and Withdrawals by Addr * [node](https://nodejs.org/en/) * [pnpm](https://pnpm.io/installation) -## Create a Demo Project +## Create a demo project You're going to use the Optimism SDK for this tutorial. Since the Optimism SDK is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. @@ -60,7 +58,7 @@ pnpm add ethers@^5 -## Add RPC URLs to Your Environment +## Add RPC URLs to your environment You'll be using the `getMessageReceipt` function from the Optimism SDK during this tutorial. This function use event queries to retrieve the receipt for a deposit or withdrawal. @@ -88,7 +86,7 @@ node This will bring up a Node REPL prompt that allows you to run javascript code. -## Import Dependencies +## Import dependencies You need to import some dependencies into your Node REPL session. @@ -106,7 +104,7 @@ You need to import some dependencies into your Node REPL session. -## Set Session Variables +## Set session variables You'll need a few variables throughout this tutorial. Let's set those up now. @@ -152,7 +150,7 @@ Create an instance of the `CrossChainMessenger` class: ```js file=/public/tutorials/sdk-trace-txns.js#L20-L25 hash=158c6888c82bdc2f07c37c3edb3a9a6a ``` -## Trace a Deposit +## Trace a deposit You can use the `CrossChainMessenger` instance to trace a deposit. @@ -191,7 +189,7 @@ Once you have the transaction receipt, you can directly query for the actual L2 -## Trace a Withdrawal +## Trace a withdrawal You can also use the `CrossChainMessenger` instance to trace a withdrawal. diff --git a/pages/builders/app-developers/tutorials/sdk-view-txns.mdx b/pages/builders/app-developers/tutorials/sdk-view-txns.mdx index 7287680de..d93b63610 100644 --- a/pages/builders/app-developers/tutorials/sdk-view-txns.mdx +++ b/pages/builders/app-developers/tutorials/sdk-view-txns.mdx @@ -1,5 +1,5 @@ --- -title: Viewing Deposits and Withdrawals by Address +title: Viewing deposits and withdrawals by address lang: en-US description: Learn how to use the Optimism SDK to view all deposits and withdrawals triggered by a given address. --- @@ -8,9 +8,7 @@ import { Callout, Steps } from 'nextra/components' import { WipCallout } from '@/components/WipCallout' -# Viewing Deposits and Withdrawals by Address - - +# Viewing deposits and withdrawals by address In this tutorial, you'll learn how to use the [Optimism SDK](https://sdk.optimism.io) to view all of the [Standard Bridge](../bridging/standard-bridge) deposits and withdrawals triggered by a given address. @@ -23,7 +21,7 @@ Check out the tutorial on [Bridging ERC-20 Tokens With the Optimism SDK](./cross * [node](https://nodejs.org/en/) * [pnpm](https://pnpm.io/installation) -## Create a Demo Project +## Create a demo project You're going to use the Optimism SDK for this tutorial. Since the Optimism SDK is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. @@ -57,7 +55,7 @@ pnpm add ethers@^5 -## Add RPC URLs to Your Environment +## Add RPC URLs to your environment You'll be using the `getDepositsByAddress` and `getWithdrawalsByAddress` functions from the Optimism SDK during this tutorial. These functions use event queries to retrieve the deposits and withdrawals made by a given address. @@ -85,7 +83,7 @@ node This will bring up a Node REPL prompt that allows you to run javascript code. -## Import Dependencies +## Import dependencies You need to import some dependencies into your Node REPL session. @@ -103,7 +101,7 @@ You need to import some dependencies into your Node REPL session. -## Set Session Variables +## Set session variables You'll need a few variables throughout this tutorial. Let's set those up now. @@ -139,7 +137,7 @@ Create an instance of the `CrossChainMessenger` class: ```js file=/public/tutorials/sdk-view-txns.js#L19-L24 hash=158c6888c82bdc2f07c37c3edb3a9a6a ``` -## Query for Deposits +## Query for deposits You'll first query for all of the deposits made by the target address. The `CrossChainMessenger` has a convenient function called `getDepositsByAddress` that makes this easy. @@ -158,7 +156,7 @@ The `CrossChainMessenger` has a convenient function called `getDepositsByAddress -## Query for Withdrawals +## Query for withdrawals You'll next query for all of the withdrawals made by the target address. The `CrossChainMessenger` has a convenient function called `getWithdrawalsByAddress` that makes this easy. diff --git a/pages/builders/app-developers/tutorials/send-tx-from-eth.mdx b/pages/builders/app-developers/tutorials/send-tx-from-eth.mdx index d7a53efe3..543de2792 100644 --- a/pages/builders/app-developers/tutorials/send-tx-from-eth.mdx +++ b/pages/builders/app-developers/tutorials/send-tx-from-eth.mdx @@ -1,89 +1,64 @@ --- -title: Triggering OP Mainnet Transactions from Ethereum +title: Triggering OP Stack transactions from Ethereum lang: en-US -description: Learn how to force transaction inclusion without the OP Mainnet Sequencer. +description: Learn how to force transaction inclusion without the OP Stack Sequencer using Viem. --- import { Callout, Steps } from 'nextra/components' -import { WipCallout } from '@/components/WipCallout' - -# Triggering OP Mainnet Transactions from Ethereum +# Triggering OP Stack transactions from Ethereum +OP Stack currently uses a single-Sequencer block production model. +This means that there is only one Sequencer active on the network at any given time. Single-Sequencer models are simpler than their highly decentralized counterparts but they are also more vulnerable to potential downtime. - -OP Mainnet currently uses a single-Sequencer block production model. -This means that there is only one Sequencer active on the network at any given time. -Single-Sequencer models are simpler than their highly decentralized counterparts but they are also more vulnerable to potential downtime. - -Sequencer downtime must not be able to prevent users from transacting on the network. -As a result, OP Mainnet includes a mechanism for "forcing" transactions to be included in the blockchain. -This mechanism involves triggering a transaction on OP Mainnet by sending a transaction on Ethereum. - -In this tutorial you'll learn how to trigger a transaction on OP Mainnet from Ethereum. -You'll use the OP Sepolia testnet, but the same logic will apply to OP Mainnet. +Sequencer downtime must not be able to prevent users from transacting on the network. As a result, OP Stack includes a mechanism for "forcing" transactions to be included in the blockchain. This mechanism involves triggering a transaction on OP Stack by sending a transaction on Ethereum. +In this tutorial you'll learn how to trigger a transaction on OP Stack from Ethereum using Viem. You'll use the OP Sepolia testnet, but the same logic will apply to OP Stack. ## Dependencies * [node](https://nodejs.org/en/) * [pnpm](https://pnpm.io/installation) -## Create a Demo Project +## Create a demo project -You're going to use the `@eth-optimism/contracts-ts` package for this tutorial. -Since the `@eth-optimism/contracts-ts` package is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. +You're going to use the `viem` package for this tutorial. Since Viem is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. + {

Make a Project Folder

} -{

Make a Project Folder

} - -```bash -mkdir op-sample-project -cd op-sample-project -``` - -{

Initialize the Project

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

Install the Contracts Package

} - -```bash -pnpm add @eth-optimism/contracts-ts -``` - -{

Install the Utils Package

} + ```bash + mkdir trigger-transaction + cd trigger-transaction + ``` -```bash -pnpm add @eth-optimism/core-utils -``` + {

Initialize the Project

} -{

Install ethers.js

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

Install Viem

} + ```bash + pnpm add viem + ``` -Want to create a new wallet for this tutorial? -If you have [`cast`](https://book.getfoundry.sh/getting-started/installation) installed you can run `cast wallet new` in your terminal to create a new wallet and get the private key. + Want to create a new wallet for this tutorial? + If you have [`cast`](https://book.getfoundry.sh/getting-started/installation) installed you can run `cast wallet new` in your terminal to create a new wallet and get the private key. ## Get ETH on Sepolia and OP Sepolia -This tutorial explains how to bridge tokens from Sepolia to OP Sepolia. -You will need to get some ETH on both of these testnets. +This tutorial explains how to bridge tokens from Sepolia to OP Sepolia. You will need to get some ETH on both of these testnets. -You can use [this faucet](https://sepoliafaucet.com) to get ETH on Sepolia. -You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on OP Sepolia. + You can use [this faucet](https://sepoliafaucet.com) to get ETH on Sepolia. + You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on OP Sepolia. -## Add a Private Key to Your Environment +## Add a private key to your environment You need a private key in order to sign transactions. Set your private key as an environment variable with the `export` command. @@ -95,7 +70,7 @@ export TUTORIAL_PRIVATE_KEY=0x... ## Start the Node REPL -You're going to use the Node REPL to interact with the Optimism SDK. +You're going to use the Node REPL to interact with Viem. To start the Node REPL run the following command in your terminal: ```bash @@ -104,117 +79,91 @@ node This will bring up a Node REPL prompt that allows you to run javascript code. -## Import Dependencies +## Import dependencies You need to import some dependencies into your Node REPL session. + {

Import Viem

} -{

Import the Contracts Package

} - -```js file=/public/tutorials/send-tx-from-eth.js#L3 hash=02e8ca4ffb8e411c4b43d969c5533e24 -``` - -{

Import the Utils Package

} - -```js file=/public/tutorials/send-tx-from-eth.js#L4 hash=6e350dd75d29dff73d09b1f0cdd1fe78 -``` - -{

Import ethers.js

} - -```js file=/public/tutorials/send-tx-from-eth.js#L5 hash=69a65ef97862612e4978b8563e6dbe3a -``` - + ```js file=/public/tutorials/send-tx-from-eth.js#L3-L6 hash=1e06dede41cb7ba0bd9414a8962521c6 + ``` -## Set Session Variables +## Set session variables -You'll need a few variables throughout this tutorial. -Let's set those up now. +You'll need a few variables throughout this tutorial. Let's set those up now. + {

Load your private key

} -{

Load your private key

} - -```js file=/public/tutorials/send-tx-from-eth.js#L7 hash=755b77a7ffc7dfdc186f36c37d3d847a -``` + ```js file=/public/tutorials/send-tx-from-eth.js#L8-L9 hash=46ba01375a5d8844b2315f0e579dfac3 + ``` -{

Create the RPC providers and wallets

} - -```js file=/public/tutorials/send-tx-from-eth.js#L9-L12 hash=9afdce50665ae93bce602068071ffaa1 -``` + {

Create the RPC providers and wallets

} + ```js file=/public/tutorials/send-tx-from-eth.js#L11-L13 hash=d5a5a1252f4b6ff026cd58de8e6ae7f1 + ``` -## Check Your Initial Balance +## Check your initial balance -You'll be sending a small amount of ETH as part of this tutorial. -Quickly check your balance on OP Sepolia so that you know how much you had at the start of the tutorial. +You'll be sending a small amount of ETH as part of this tutorial. Quickly check your balance on OP Sepolia so that you know how much you had at the start of the tutorial. -```js file=/public/tutorials/send-tx-from-eth.js#L15-L16 hash=062c80bbd70e12144fe45532611a1846 +```js file=/public/tutorials/send-tx-from-eth.js#L17-L18 hash=2bbd74b9de0c0fa0daca043ab9030ff0 ``` -## Trigger the Transaction +## Trigger the transaction -Now you'll use the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/L1/OptimismPortal.sol) contract to trigger a transaction on OP Sepolia by sending a transaction on Sepolia. +Now you'll use the `OptimismPortal` contract to trigger a transaction on OP Sepolia by sending a transaction on Sepolia. + {

Create the OptimismPortal object

} -{

Create the OptimismPortal object

} + ```js file=/public/tutorials/send-tx-from-eth.js#L20-L31 hash=b062257111aacc2f3a985542e451269c + ``` -```js file=/public/tutorials/send-tx-from-eth.js#L18-L22 hash=75e09aebd1fe33724587ce7464f91940 -``` + {

Estimate the required gas

} -{

Estimate the required gas

} + When sending transactions via the `OptimismPortal` contract it's important to always include a gas buffer. This is because the `OptimismPortal` charges a variable amount of gas depending on the current demand for L2 transactions triggered via L1. If you do not include a gas buffer, your transactions may fail. -When sending transactions via the `OptimismPortal` contract it's important to always include a gas buffer. -This is because the `OptimismPortal` charges a variable amount of gas depending on the current demand for L2 transactions triggered via L1. -If you do not include a gas buffer, your transactions may fail. + ```js file=/public/tutorials/send-tx-from-eth.js#L33-L45 hash=f5d0d92f161514a3359997143804af0b + ``` -```js file=/public/tutorials/send-tx-from-eth.js#L25-L31 hash=a5ed372cf7ae78a6fea1e7a65c582cee -``` + {

Send the transaction

} -{

Send the transaction

} + Now you'll send the transaction. Note that you are including a buffer of 20% on top of the gas estimate. -Now you'll send the transaction. -Note that you are including a buffer of 20% on top of the gas estimate. + ```js file=/public/tutorials/send-tx-from-eth.js#L50-L61 hash=59e3ee527809087e9e615f28caa49083 + ``` -```js file=/public/tutorials/send-tx-from-eth.js#L34-L43 hash=57a69ed74c2fb3bf2242b0452ed00f88 -``` + {

Wait for the L1 transaction

} -{

Wait for the L1 transaction

} + First you'll need to wait for the L1 transaction to be mined. -First you'll need to wait for the L1 transaction to be mined. + ```js file=/public/tutorials/send-tx-from-eth.js#L60 hash=0efd9bd3369de7f5f36ea5540a5d8078 + ``` -```js file=/public/tutorials/send-tx-from-eth.js#L46 hash=efcac85d794ab4711595112fbe2c7a8e -``` - -{

Wait for the L2 transaction

} + {

Wait for the L2 transaction

} -Now you'll need to wait for the corresponding L2 transaction to be included in a block. -This transaction is automatically created as a result of your L1 transaction. -Here you'll determine the hash of the L2 transaction using the `@eth-optimism/core-utils` library and then wait for that transaction to be included in the L2 blockchain. - -```js file=/public/tutorials/send-tx-from-eth.js#L49-L50 hash=28b3fcba963fc4b960e89cc96b20aea2 -``` + Now you'll need to wait for the corresponding L2 transaction to be included in a block. This transaction is automatically created as a result of your L1 transaction. Here you'll determine the hash of the L2 transaction and then wait for that transaction to be included in the L2 blockchain. + ```js file=/public/tutorials/send-tx-from-eth.js#L67-L73 hash=bf903509fb370c2b4e85dbfbf05650ee + ``` -## Check Your Updated Balance +## Check your updated balance -You should have a little less ETH on OP Sepolia now. -Check your balance to confirm. +You should have a little less ETH on OP Sepolia now. Check your balance to confirm. -```js file=/public/tutorials/send-tx-from-eth.js#L53-L54 hash=b907d1590d7b39e8cfba4fb84886a8f9 +```js file=/public/tutorials/send-tx-from-eth.js#L75-L76 hash=dd456528a8bae103b73c5bcd19216916 ``` Make sure that the difference is equal to the amount you were expecting to send. -```js file=/public/tutorials/send-tx-from-eth.js#L57-L58 hash=e44227b3ca6f46e6a16a10689b11ad39 +```js file=/public/tutorials/send-tx-from-eth.js#L78-L79 hash=3885097e127ff18b3c2c2fc1d3d5a7c0 ``` -## Next Steps +## Next steps -You've successfully triggered a transaction on OP Sepolia by sending a transaction on Sepolia. -Although this tutorial demonstrated the simple example of sending a basic ETH transfer from your L2 address via the OptimismPortal contract, you can use this same technique to trigger any transaction you want. -You can trigger smart contracts, send ERC-20 tokens, and more. +You've successfully triggered a transaction on OP Sepolia by sending a transaction on Sepolia using Viem. Although this tutorial demonstrated the simple example of sending a basic ETH transfer from your L2 address via the OptimismPortal contract, you can use this same technique to trigger any transaction you want. You can trigger smart contracts, send ERC-20 tokens, and more. diff --git a/pages/builders/app-developers/tutorials/standard-bridge-custom-token.mdx b/pages/builders/app-developers/tutorials/standard-bridge-custom-token.mdx index d6e2a5dbd..76d5ee2ec 100644 --- a/pages/builders/app-developers/tutorials/standard-bridge-custom-token.mdx +++ b/pages/builders/app-developers/tutorials/standard-bridge-custom-token.mdx @@ -1,5 +1,5 @@ --- -title: Bridging Your Custom ERC-20 Token Using the Standard Bridge +title: Bridging your custom ERC-20 token using the Standard Bridge lang: en-US description: Learn how to bridge your custom ERC-20 token using the standard bridge. --- @@ -8,9 +8,7 @@ import { Callout, Steps } from 'nextra/components' import { WipCallout } from '@/components/WipCallout' -# Bridging Your Custom ERC-20 Token Using the Standard Bridge - - +# Bridging your custom ERC-20 token using the Standard Bridge In this tutorial you'll learn how to bridge a custom ERC-20 token from Ethereum to an OP Stack chain using the Standard Bridge system. This tutorial is meant for developers who already have an existing ERC-20 token on Ethereum and want to create a bridged representation of that token on OP Mainnet. @@ -45,19 +43,19 @@ You can use [this faucet](https://sepoliafaucet.com/) to get ETH on Sepolia. You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on OP Sepolia. -## Add OP Sepolia to Your Wallet +## Add OP Sepolia to your wallet This tutorial uses [Remix](https://remix.ethereum.org) to deploy contracts. You will need to add the OP Sepolia network to your wallet in order to follow this tutorial. You can use [this website](https://chainid.link?network=op-sepolia) to connect your wallet to OP Sepolia. -## Get an L1 ERC-20 Token Address +## Get an L1 ERC-20 token address You will need an L1 ERC-20 token for this tutorial. If you already have an L1 ERC-20 token deployed on Sepolia, you can skip this step. Otherwise, you can use the testing token located at [`0x5589BB8228C07c4e15558875fAf2B859f678d129`](https://sepolia.etherscan.io/address/0x5589BB8228C07c4e15558875fAf2B859f678d129) that includes a `faucet()` function that can be used to mint tokens. -## Create an L2 ERC-20 Token +## Create an L2 ERC-20 token Once you have an L1 ERC-20 token, you can create a corresponding L2 ERC-20 token on OP Sepolia. This tutorial will use [Remix](https://remix.ethereum.org) so you can easily deploy a token without a framework like [Hardhat](https://hardhat.org) or [Foundry](https://getfoundry.sh). @@ -113,10 +111,10 @@ _SYMBOL: "MCL2T" -## Bridge Some Tokens +## Bridge some tokens Now that you have an L2 ERC-20 token, you can bridge some tokens from L1 to L2. -Check out the tutorial on [Bridging ERC-20 tokens with the Optimism SDK](./cross-dom-bridge-erc20) to learn how to bridge your L1 ERC-20 to L2s using the Optimism SDK. +Check out the tutorial on [Bridging ERC-20 tokens with viem](./cross-dom-bridge-erc20) to learn how to bridge your L1 ERC-20 to L2s using viem. Remember that the withdrawal step will *not* work for the token you just created! This is exactly what this tutorial was meant to demonstrate. diff --git a/pages/builders/app-developers/tutorials/standard-bridge-standard-token.mdx b/pages/builders/app-developers/tutorials/standard-bridge-standard-token.mdx index 57c589f68..2506176f1 100644 --- a/pages/builders/app-developers/tutorials/standard-bridge-standard-token.mdx +++ b/pages/builders/app-developers/tutorials/standard-bridge-standard-token.mdx @@ -1,5 +1,5 @@ --- -title: Bridging Your Standard ERC-20 Token Using the Standard Bridge +title: Bridging your standard ERC-20 token using the Standard Bridge lang: en-US description: Learn how to bridge your standard ERC-20 token using the standard bridge. --- @@ -10,12 +10,10 @@ import { WipCallout } from '@/components/WipCallout' # Bridging Your Standard ERC-20 Token Using the Standard Bridge - - In this tutorial you'll learn how to bridge a standard ERC-20 token from Ethereum to an OP Stack chain using the Standard Bridge system. This tutorial is meant for developers who already have an existing ERC-20 token on Ethereum and want to create a bridged representation of that token on layer 2. -This tutorial explains how to use the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/186e46a47647a51a658e699e9ff047d39444c2de/packages/contracts-bedrock/contracts/universal/OptimismMintableERC20Factory.sol) to deploy a standardized ERC-20 token on layer 2. +This tutorial explains how to use the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/universal/OptimismMintableERC20Factory.sol) to deploy a standardized ERC-20 token on layer 2. Tokens created by this factory contract are compatible with the Standard Bridge system and include basic logic for deposits, transfers, and withdrawals. If you want to include specialized logic within your L2 token, see the tutorial on [Bridging Your Custom ERC-20 Token Using the Standard Bridge](./standard-bridge-custom-token) instead. @@ -28,7 +26,7 @@ The Standard Bridge **does not** support [**fee on transfer tokens**](https://gi The Standard Bridge system requires that L2 representations of L1 tokens implement the [`IOptimismMintableERC20`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/universal/IOptimismMintableERC20.sol) interface. This interface is a superset of the standard ERC-20 interface and includes functions that allow the bridge to properly verify deposits/withdrawals and mint/burn tokens as needed. Your L2 token contract must implement this interface in order to be bridged using the Standard Bridge system. -This tutorial will show you how to use the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/186e46a47647a51a658e699e9ff047d39444c2de/packages/contracts-bedrock/contracts/universal/OptimismMintableERC20Factory.sol) to create a basic standardized ERC-20 token on layer 2. +This tutorial will show you how to use the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/universal/OptimismMintableERC20Factory.sol) to create a basic standardized ERC-20 token on layer 2. ## Dependencies @@ -44,7 +42,7 @@ You can use [this faucet](https://sepoliafaucet.com) to get ETH on Sepolia. You can use the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) to get ETH on OP Sepolia. -## Get an L1 ERC-20 Token Address +## Get an L1 ERC-20 token address You will need an L1 ERC-20 token for this tutorial. If you already have an L1 ERC-20 token deployed on Sepolia, you can skip this step. @@ -52,7 +50,7 @@ Otherwise, you can use the testing token located at [`0x5589BB8228C07c4e15558875 ## Create an L2 ERC-20 Token -Once you have an L1 ERC-20 token, you can use the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/186e46a47647a51a658e699e9ff047d39444c2de/packages/contracts-bedrock/contracts/universal/OptimismMintableERC20Factory.sol) to create a corresponding L2 ERC-20 token on OP Sepolia. +Once you have an L1 ERC-20 token, you can use the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/universal/OptimismMintableERC20Factory.sol) to create a corresponding L2 ERC-20 token on OP Sepolia. All tokens created by the factory implement the `IOptimismMintableERC20` interface and are compatible with the Standard Bridge system. @@ -85,7 +83,7 @@ Set your L1 ERC-20 token address as an environment variable with the `export` co {

Deploy your L2 ERC-20 token

} -You can now deploy our L2 ERC-20 token using the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/186e46a47647a51a658e699e9ff047d39444c2de/packages/contracts-bedrock/contracts/universal/OptimismMintableERC20Factory.sol). +You can now deploy our L2 ERC-20 token using the [`OptimismMintableERC20Factory`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/universal/OptimismMintableERC20Factory.sol). Use the `cast` command to trigger the deployment function on the factory contract. This example command creates a token with the name "My Standard Demo Token" and the symbol "L2TKN". The resulting L2 ERC-20 token address is printed to the console. @@ -95,10 +93,10 @@ The resulting L2 ERC-20 token address is printed to the console. -## Bridge Some Tokens +## Bridge some tokens Now that you have an L2 ERC-20 token, you can bridge some tokens from L1 to L2. -Check out the tutorial on [Bridging ERC-20 tokens with the Optimism SDK](./cross-dom-bridge-erc20) to learn how to bridge your L1 ERC-20 to L2s using the Optimism SDK. +Check out the tutorial on [Bridging ERC-20 tokens with viem](./cross-dom-bridge-erc20) to learn how to bridge your L1 ERC-20 to L2s using viem. ## Add to the Superchain Token List diff --git a/pages/builders/cex-wallet-developers/_meta.json b/pages/builders/cex-wallet-developers/_meta.json deleted file mode 100644 index 2034019cc..000000000 --- a/pages/builders/cex-wallet-developers/_meta.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "cex-support": "Guide for Exchanges", - "wallet-support": "Guide for Wallets" -} diff --git a/pages/builders/cex-wallet-developers/cex-support.mdx b/pages/builders/cex-wallet-developers/cex-support.mdx deleted file mode 100644 index 044c5118e..000000000 --- a/pages/builders/cex-wallet-developers/cex-support.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: Supporting OP Mainnet in Your Exchange -lang: en-US -description: Learn how to support OP Mainnet in your exchange. ---- - -import { Callout } from 'nextra/components' - -# Supporting OP Mainnet in Your Exchange - -Check out this guide to get an overview of everything you need to know to properly support OP Mainnet within your exchange. - -## Connecting to OP Mainnet - -OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) and supports all of the same tooling as Ethereum. -You can use your favorite Ethereum libraries and tools to work with OP Mainnet. -Head over to the [Networks and RPC Endpoints](/chain/networks) page for network connection details and check out the [RPC Providers](/builders/tools/connect/rpc-providers) page for an updated list of RPC providers that support OP Mainnet. -If you need to run your own OP Mainnet node, head over to the [Node Operator](/builders/node-operators/rollup-node) guide. - -## Native Gas Token (ETH) - -OP Mainnet uses ETH as its native gas token. -Transactions are paid for in ETH and account balances are denominated in ETH. - -## Transaction Fees - -OP Mainnet charges the standard gas fee for transactions, but also charges an additional L1 data fee for the cost of publishing transaction data to Ethereum. -Check out the [Transaction Fees](/stack/transactions/fees) page for more information about how transaction fees work on OP Mainnet. - -## Smart Contracts - -Smart contracts on OP Mainnet function the same way they do on Ethereum. -This includes ERC-20 token contracts. -You can use your existing logic for managing withdrawals and deposits of ERC-20 tokens. - -## Token Addresses - -The ERC-20 contract address for a token on OP Mainnet may differ from the address for the same token on Ethereum. -Make sure to reference the [Bridged Token Addresses](/chain/tokenlist) to confirm that you are using the correct token addresses in your application. - -## Bridging ETH and ERC-20s - -You may need to transfer ETH or ERC-20 tokens between OP Mainnet and Ethereum. -For instance, you may need to use this functionality to balance the supply of ETH on OP Mainnet and Ethereum depending on the demand for withdrawals and deposits on the two networks. -Refer to the [Basics of Bridging](/builders/app-developers/bridging/basics) and the [Standard Bridge](/builders/app-developers/bridging/standard-bridge) guides for more information about how to bridge ETH and ERC-20 tokens between OP Mainnet and Ethereum. - -## Transaction Statuses - -OP Mainnet transactions have a number of different statuses during the transaction lifecycle. -Refer to the [Transaction Statuses](/builders/app-developers/transactions/statuses) page for more information about the different transaction statuses and how to handle them in your application. - - -Transaction statuses can be critical for the security of your application. -For instance, you may only want to credit a deposit if the transaction is finalized. -Make sure to understand the various transaction statuses to avoid security issues in your application. - - -## Audits and Security Reviews - -The OP Stack codebase upon which OP Mainnet is built has undergone a number of security reviews. -Visit [GitHub](https://github.com/ethereum-optimism/optimism/tree/develop/docs/security-reviews) for a full list of the most recent reports. -Additionally, refer to the [Security Model & FAQ](/chain/security/faq) page for more information about the security model of OP Mainnet. diff --git a/pages/builders/cex-wallet-developers/wallet-support.mdx b/pages/builders/cex-wallet-developers/wallet-support.mdx deleted file mode 100644 index 31c085699..000000000 --- a/pages/builders/cex-wallet-developers/wallet-support.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Supporting OP Mainnet in Your Wallet -lang: en-US -description: Learn how to support OP Mainnet in your wallet. ---- - -import { Callout } from 'nextra/components' - -# Supporting OP Mainnet in Your Wallet - -Check out this guide to get an overview of everything you need to know to properly support OP Mainnet within your wallet. - -## Connecting to OP Mainnet - -OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) and supports all of the same tooling as Ethereum. -You can use your favorite Ethereum libraries and tools to work with OP Mainnet. -Head over to the [Networks and RPC Endpoints](/chain/networks) page for network connection details and check out the [RPC Providers](/builders/tools/connect/rpc-providers) page for an updated list of RPC providers that support OP Mainnet. -If you need to run your own OP Mainnet node, head over to the [Node Operator](/builders/node-operators/rollup-node) guide. - -## Native Gas Token (ETH) - -OP Mainnet uses ETH as its native gas token. -Transactions are paid for in ETH and account balances are denominated in ETH. - -## Transaction Fees - -OP Mainnet charges the standard gas fee for transactions, but also charges an additional L1 data fee for the cost of publishing transaction data to Ethereum. -Check out the [Transaction Fees](/stack/transactions/fees) page for more information about how transaction fees work on OP Mainnet. - - -Transactions on OP Mainnet must pay for an additional "L1 data fee" that often heavily outweighs the standard gas fee. -Make sure that your wallet is configured to display this fee to your users so that they are aware of the total cost of their transaction. - - -## Smart Contracts - -Smart contracts on OP Mainnet function the same way they do on Ethereum. -You can use your favorite Ethereum libraries and tools to interact with smart contracts on OP Mainnet. - -## Token Addresses - -The ERC-20 contract address for a token on OP Mainnet may differ from the address for the same token on Ethereum. -Addresses for many common tokens will differ between OP Mainnet and Ethereum. -Make sure to reference the [Bridged Token Addresses](/chain/tokenlist) to confirm that you are using the correct token addresses in your application. - -## Bridging ETH and ERC-20s - -You may need to transfer ETH or ERC-20 tokens between OP Mainnet and Ethereum. -This is a useful feature for users who want to move tokens between the two networks. -Refer to the [Basics of Bridging](/builders/app-developers/bridging/basics) and the [Standard Bridge](/builders/app-developers/bridging/standard-bridge) guides for more information about how to bridge ETH and ERC-20 tokens between OP Mainnet and Ethereum. - -## Transaction Statuses - -OP Mainnet transactions have a number of different statuses during the transaction lifecycle. -The status of a transaction can be useful for users. -Refer to the [Transaction Statuses](/builders/app-developers/transactions/statuses) page for more information about the different transaction statuses and how to handle them in your application. diff --git a/pages/builders/chain-operators.mdx b/pages/builders/chain-operators.mdx new file mode 100644 index 000000000..73c0e4bb9 --- /dev/null +++ b/pages/builders/chain-operators.mdx @@ -0,0 +1,31 @@ +--- +title: Chain Operators +description: Documentation covering Architecture, Configuration, Deploy, Features, Hacks, Management, Self Hosted, Tools, Tutorials in the Chain Operators section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Chain Operators + +Documentation covering Architecture, Configuration, Deploy, Features, Hacks, Management, Self Hosted, Tools, Tutorials in the Chain Operators section of the OP Stack ecosystem. + + + + + + + + + + + + + + + + + + + + diff --git a/pages/builders/chain-operators/_meta.json b/pages/builders/chain-operators/_meta.json index 3481fe628..e26e786c5 100644 --- a/pages/builders/chain-operators/_meta.json +++ b/pages/builders/chain-operators/_meta.json @@ -1,11 +1,11 @@ { "architecture": "Architecture", - "self-hosted": "Start a Self-Hosted Chain", - "configuration": "Chain Configuration", - "management": "Chain Management", - "features": "Chain Features", + "self-hosted": "Start a self-hosted chain", + "configuration": "Chain configuration", + "management": "Chain management", + "features": "Chain features", "deploy": "Deployment", "tutorials": "Tutorials", - "tools": "Chain Tools", - "hacks": "OP Stack Hacks" + "tools": "Chain tools", + "hacks": "OP Stack hacks" } diff --git a/pages/builders/chain-operators/architecture.mdx b/pages/builders/chain-operators/architecture.mdx index a719bc439..36fe57400 100644 --- a/pages/builders/chain-operators/architecture.mdx +++ b/pages/builders/chain-operators/architecture.mdx @@ -1,5 +1,5 @@ --- -title: Chain Architecture +title: Chain architecture lang: en-US description: Learn about the OP chain architecture. --- @@ -8,7 +8,7 @@ import Image from 'next/image' import { Callout } from 'nextra/components' import {OpProposerDescriptionShort} from '@/content/index.js' -# Chain Architecture +# Chain architecture This page contains information about the components of the rollup protocol and how they work together to build the layer 2 blockchain from the Chain Operator's @@ -18,7 +18,7 @@ clients. The OP Stack also has some privileged roles that produce L2 blocks. If you want a more detailed view of the OP Stack protocol, check out the [OP Stack section](/stack/getting-started) of our documentation. -## Permissioned Components +## Permissioned components These clients and services work together to enable the block production on the L2 network. Sequencer nodes (`op-geth` + `op-node`) gather proposed transactions from users. @@ -49,7 +49,7 @@ amount of data required to reproduce L2 blocks. -## Ingress Traffic +## Ingress traffic It is important to setup a robust chain architecture to handle large volumes of RPC requests from your users. The Sequencer node has the important job of working with @@ -83,7 +83,7 @@ handle the state changing RPC request `eth_sendRawTransaction`. It can be peered replica nodes to gossip new `unsafe` blocks to the rest of the network. -To run a rollup, you need a minimum of one archive node. This is required by the proposer as the the data that it needs can be older than the data available to a full node. Note that since the proposer doesn't care what archive node it points to, you can technically point it towards an archive node that isn't the sequencer. +To run a rollup, you need a minimum of one archive node. This is required by the proposer as the data that it needs can be older than the data available to a full node. Note that since the proposer doesn't care what archive node it points to, you can technically point it towards an archive node that isn't the sequencer. Sequencer Node Diagram @@ -96,7 +96,7 @@ replicas can help horizontally scale RPC requests. Replica Node Diagram -## Next Steps +## Next steps * Find out how you can support [snap sync](/builders/chain-operators/management/snap-sync) on your chain. diff --git a/pages/builders/chain-operators/configuration.mdx b/pages/builders/chain-operators/configuration.mdx new file mode 100644 index 000000000..f8ea320f4 --- /dev/null +++ b/pages/builders/chain-operators/configuration.mdx @@ -0,0 +1,21 @@ +--- +title: Configuration +lang: en-US +description: Overview of configuration options for batchers, chain operators, proposers, and rollup deployments. +--- + +import { Card, Cards } from 'nextra/components' + +# Configuration + +This section provides information on batcher configuration, chain operator configurations, proposer configuration, and rollup deployment configuration. Users will find API references and overviews to help understand and work with these topics. + + + + + + + + + + diff --git a/pages/builders/chain-operators/configuration/_meta.json b/pages/builders/chain-operators/configuration/_meta.json index 90116f74a..cfa1aaf62 100644 --- a/pages/builders/chain-operators/configuration/_meta.json +++ b/pages/builders/chain-operators/configuration/_meta.json @@ -1,6 +1,6 @@ { "overview": "Overview", - "rollup": "Rollup Deployment Configuration", - "batcher": "Batcher Configuration", - "proposer": "Proposer Configuration" + "rollup": "Rollup deployment 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 index ac07942aa..3b0dca073 100644 --- a/pages/builders/chain-operators/configuration/batcher.mdx +++ b/pages/builders/chain-operators/configuration/batcher.mdx @@ -1,18 +1,18 @@ --- -title: Batcher Configuration +title: Batcher configuration lang: en-US description: Learn the OP Stack batcher configurations. --- import { Callout, Tabs } from 'nextra/components' -# Batcher Configuration +# 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 +## Global options ### active-sequencer-check-duration @@ -633,7 +633,7 @@ Print the version. The default value is false. ## Recommendations -### Set Your `OP_BATCHER_MAX_CHANNEL_DURATION` +### 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. @@ -652,7 +652,7 @@ To minimize costs, we recommend setting your `OP_BATCHER_MAX_CHANNEL_DURATION` * 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 +### 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. diff --git a/pages/builders/chain-operators/configuration/overview.mdx b/pages/builders/chain-operators/configuration/overview.mdx index 8a5c74f08..ecf678b17 100644 --- a/pages/builders/chain-operators/configuration/overview.mdx +++ b/pages/builders/chain-operators/configuration/overview.mdx @@ -6,7 +6,7 @@ description: Learn the how to configure an OP Stack chain. import { Callout, Steps } from 'nextra/components' -# Chain Operator Configurations +# 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 diff --git a/pages/builders/chain-operators/configuration/proposer.mdx b/pages/builders/chain-operators/configuration/proposer.mdx index da7b24846..4702f208c 100644 --- a/pages/builders/chain-operators/configuration/proposer.mdx +++ b/pages/builders/chain-operators/configuration/proposer.mdx @@ -6,13 +6,13 @@ description: Learn the OP Stack proposer configurations. import { Tabs } from 'nextra/components' -# Proposer Configuration +# 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 +## Global options ### active-sequencer-check-duration diff --git a/pages/builders/chain-operators/configuration/rollup.mdx b/pages/builders/chain-operators/configuration/rollup.mdx index 6dd615624..52600572a 100644 --- a/pages/builders/chain-operators/configuration/rollup.mdx +++ b/pages/builders/chain-operators/configuration/rollup.mdx @@ -1,12 +1,12 @@ --- -title: Rollup Deployment Configuration +title: Rollup deployment configuration lang: en-US description: Learn about the OP Stack rollup deployment configurations. --- import { Callout } from 'nextra/components' -# Rollup Deployment Configuration +# Rollup deployment configuration New OP Stack blockchains are currently configured with a deployment configuration JSON file inside that is passed into the smart contract @@ -29,12 +29,12 @@ This document highlights the deployment configurations and their values. and the actual requirements in the [OP Stack Configurability Specification](https://specs.optimism.io/protocol/configurability.html). -## Deployment Configuration Values +## Deployment configuration values These values are provided to the deployment configuration JSON file when deploying the L1 contracts. -### Offset Values +### Offset values These offset values determine when network upgrades (hardforks) activate on your blockchain. @@ -168,7 +168,7 @@ makes predeployed contracts easily upgradeable. *** -### Proxy Addresses +### Proxy addresses #### l1StandardBridgeProxy @@ -179,7 +179,7 @@ and is used as part of building the L2 genesis state. * **Default value:** None * **Recommended value:** * **Notes:** Must not be `address(0)` -* **Standard Config Requirement:** Implementation contract must the most +* **Standard Config Requirement:** Implementation contract must be the most up-to-date, governance-approved version of the OP Stack codebase, and, if the chain has been upgraded in the past, that the previous versions were a standard release of the codebase. @@ -196,7 +196,7 @@ genesis state. * **Default value:** None * **Recommended value:** * **Notes:** Must not be `address(0)` -* **Standard Config Requirement:** Implementation contract must the most +* **Standard Config Requirement:** Implementation contract must be the most up-to-date, governance-approved version of the OP Stack codebase, and, if the chain has been upgraded in the past, that the previous versions were a standard release of the codebase. @@ -212,7 +212,7 @@ used as part of building the L2 genesis state. * **Default value:** None * **Recommended value:** * **Notes:** Must not be `address(0)` -* **Standard Config Requirement:** Implementation contract must the most +* **Standard Config Requirement:** Implementation contract must be the most up-to-date, governance-approved version of the OP Stack codebase, and, if the chain has been upgraded in the past, that the previous versions were a standard release of the codebase. @@ -228,7 +228,7 @@ used as part of the derivation pipeline. * **Default value:** None * **Recommended value:** * **Notes:** Must not be `address(0)` -* **Standard Config Requirement:** Implementation contract must the most +* **Standard Config Requirement:** Implementation contract must be the most up-to-date, governance-approved version of the OP Stack codebase, and, if the chain has been upgraded in the past, that the previous versions were a standard release of the codebase. @@ -244,7 +244,7 @@ is used as part of the derivation pipeline. * **Default value:** None * **Recommended value:** * **Notes:** Must not be `address(0)` -* **Standard Config Requirement:** Implementation contract must the most +* **Standard Config Requirement:** Implementation contract must be the most up-to-date, governance-approved version of the OP Stack codebase, and, if the chain has been upgraded in the past, that the previous versions were a standard release of the codebase. @@ -257,15 +257,13 @@ These fields apply to L2 blocks: Their timing, when they need to be written to L #### l2BlockTime -Number of seconds between each L2 block. Must be \< = L1 block time (12 on mainnet and Sepolia). +Number of seconds between each L2 block. Must be \< L1 block time (12 on mainnet and Sepolia). * **Type:** Number of seconds * **Default value:** None * **Recommended value:** * **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. +* **Standard Config Requirement:** 1 or 2 seconds *** @@ -542,7 +540,7 @@ scalar used for fee calculations. *** -### Proposal Fields +### Proposal fields These fields apply to output root proposals. The l2OutputOracleSubmissionInterval is configurable, see the section below for @@ -572,7 +570,7 @@ addition of permissionless proposals. * **Type:** Number * **Default value:** None * **Recommended value:** -* **Notes:** his MUST be the timestamp corresponding to the block defined by +* **Notes:** this MUST be the timestamp corresponding to the block defined by the l1StartingBlockTag. * **Standard Config Requirement:** @@ -686,7 +684,7 @@ SequencerFeeVaultWithdrawalNetwork value. *** -### Minimum Fee Withdrawal Amounts +### 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 @@ -733,7 +731,7 @@ amount for the SequencerFeeVault. *** -### Withdrawal Network +### Withdrawal network *** @@ -779,7 +777,7 @@ L1 and a value of 1 will withdraw ETH to the recipient address on L2. *** -### Fault Proofs +### Fault proofs *** @@ -973,7 +971,7 @@ instead of the older output oracle mechanism. The Custom Gas Token configuration lets OP Stack chain operators deploy their chain allowing a specific ERC-20 token to be deposited in as the native token -to pay for gas fees. Learn more [here](/stack/protocol/features/custom-gas-token). +to pay for gas fees. Learn more [here](/stack/beta-features/custom-gas-token). *** @@ -1005,7 +1003,7 @@ gas on L2. Alt-DA Mode enables seamless integration of various Data Availability (DA) Layers, regardless of their commitment type, into the OP Stack. This allows any chain operator to launch an OP Stack chain using their favorite DA Layer -for sustainably low costs. Lean more [here](/stack/protocol/features/alt-da-mode). +for sustainably low costs. Learn more [here](/stack/beta-features/alt-da-mode). *** diff --git a/pages/builders/chain-operators/deploy.mdx b/pages/builders/chain-operators/deploy.mdx new file mode 100644 index 000000000..87e4184f6 --- /dev/null +++ b/pages/builders/chain-operators/deploy.mdx @@ -0,0 +1,19 @@ +--- +title: Deploy +lang: en-US +description: Information on OP Stack genesis creation, deployment overview, and smart contract deployment. +--- + +import { Card, Cards } from 'nextra/components' + +# Deploy + +This section provides information on OP Stack genesis creation, deployment overview, and smart contract deployment. You'll find guides and overviews to help you understand and work with these topics. + + + + + + + + diff --git a/pages/builders/chain-operators/deploy/_meta.json b/pages/builders/chain-operators/deploy/_meta.json index 288270a75..1cf642283 100644 --- a/pages/builders/chain-operators/deploy/_meta.json +++ b/pages/builders/chain-operators/deploy/_meta.json @@ -1,6 +1,6 @@ { "overview": "Overview", - "smart-contracts": "Contract Deployment", - "genesis": "Genesis Creation" + "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 index a6bf9aa69..7004e07d8 100644 --- a/pages/builders/chain-operators/deploy/genesis.mdx +++ b/pages/builders/chain-operators/deploy/genesis.mdx @@ -1,19 +1,24 @@ --- -title: OP Stack Genesis Creation +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 +# OP Stack genesis creation + + +This page is out of date and shows the legacy method for genesis file creation. +For the latest recommended method, use [op-deployer](/builders/chain-operators/tools/op-deployer). + The following guide shows you how to generate the L2 genesis file `genesis.json`. This is a JSON file that represents the L2 genesis. You will provide this file to the execution client (op-geth) to initialize your network. There is also the rollup configuration file, `rollup.json`, which will be provided to the consensus client (op-node). -## Solidity Script +## Solidity script At the time of this writing, the preferred method for genesis generation is to use the foundry script located in the monorepo to generate an "L2 state dump" and then pass this into the op-node genesis subcommand. @@ -79,10 +84,10 @@ go run cmd/main.go genesis l2 \ --l2-allocs= \ --outfile.l2= \ --outfile.rollup= \ - --l1-rpc=> + --l1-rpc=> ``` -## Next Steps +## Next steps * Learn how to [initialize](/builders/node-operators/configuration/base-config#initialization-via-genesis-file) `op-geth` with your `genesis.json` file. diff --git a/pages/builders/chain-operators/deploy/overview.mdx b/pages/builders/chain-operators/deploy/overview.mdx index d5f3f004c..1d3617644 100644 --- a/pages/builders/chain-operators/deploy/overview.mdx +++ b/pages/builders/chain-operators/deploy/overview.mdx @@ -1,12 +1,12 @@ --- -title: OP Stack Deployment Overview +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 +# 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 @@ -14,7 +14,7 @@ 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 +## 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 @@ -27,14 +27,14 @@ contracts that are deployed when the chain is created. changes. Read more about the details on our [Smart Contract Release Section](/stack/smart-contracts#official-releases). -## Sequencer Node +## 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 +### 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 @@ -43,7 +43,7 @@ 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 +### Execution client OP Stack nodes, like Ethereum nodes, also have an execution client. The execution client is responsible for executing transactions and maintaining the @@ -56,7 +56,7 @@ client exist, including `op-geth` (maintained by Optimism Foundation), 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. +transactions in regular batches. ## Proposer @@ -65,7 +65,7 @@ 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 +## Software dependencies | Dependency | Version | Version Check Command | | ------------------------------------------------------------- | -------- | --------------------- | @@ -78,7 +78,7 @@ communication and reconciliation between state changes. | [jq](https://github.com/jqlang/jq) | `^1.6` | `jq --version` | | [direnv](https://direnv.net) | `^2` | `direnv --version` | -### Notes on Specific Dependencies +### Notes on specific dependencies #### `node` @@ -114,7 +114,7 @@ then **close your terminal and reopen it** so that the changes take effect (or (and things might not work later). -## Next Steps +## Next steps * 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). diff --git a/pages/builders/chain-operators/deploy/smart-contracts.mdx b/pages/builders/chain-operators/deploy/smart-contracts.mdx index 63a3512f1..2a26e2f10 100644 --- a/pages/builders/chain-operators/deploy/smart-contracts.mdx +++ b/pages/builders/chain-operators/deploy/smart-contracts.mdx @@ -6,7 +6,12 @@ description: Learn how to deploy the OP Stack L1 smart contracts. import { Callout } from 'nextra/components' -# OP Stack Smart Contract Deployment +# OP Stack smart contract deployment + + +This page is out of date and shows the legacy method for smart contract deployment. +For the latest recommended method, use [op-deployer](/builders/chain-operators/tools/op-deployer). + The following guide shows you how to deploy the OP Stack L1 smart contracts. The primary development branch is `develop`, however **you should only deploy @@ -18,7 +23,7 @@ generally not considered backwards compatible. Standard OP Stack chains should use the latest governance approved and audited versions of the smart contract code. -## Deployment Configuration +## Deployment configuration Deploying your OP Stack contracts requires creating a deployment configuration JSON file. You will create a new deployment configuration file in the following @@ -26,20 +31,20 @@ monorepo subdirectory: [packages/contracts-bedrock/deploy-config](https://github For the full set of deployment configuration options and their meanings, you can see the [rollup deployment configuration page](/builders/chain-operators/configuration/rollup). -## Deployment Script +## 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/Deploy.s.sol](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/scripts/deploy/Deploy.s.sol). -### State Diff +### 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 +forge script -vvv scripts/deploy/Deploy.s.sol:Deploy --sig 'runWithStateDiff()' --rpc-url $ETH_RPC_URL --broadcast --private-key $PRIVATE_KEY ``` ### Execution @@ -66,7 +71,7 @@ shared SuperchainConfig contract. ``` DEPLOYMENT_OUTFILE=deployments/artifact.json \ DEPLOY_CONFIG_PATH= \ - forge script scripts/Deploy.s.sol:Deploy \ + forge script scripts/deploy/Deploy.s.sol:Deploy \ --broadcast --private-key $PRIVATE_KEY \ --rpc-url $ETH_RPC_URL ``` @@ -77,7 +82,7 @@ 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 +## Best practices Production users should deploy their L1 contracts from a contracts release. All contracts releases are on git tags with the following format: @@ -90,7 +95,7 @@ running the additional infrastructure requirements: [op-challenger](https://gith additional changes to the economics of operating a permissionless fault proof that chain operators should have a firm understanding of. -## Next Steps +## 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/features.mdx b/pages/builders/chain-operators/features.mdx new file mode 100644 index 000000000..e2a22d516 --- /dev/null +++ b/pages/builders/chain-operators/features.mdx @@ -0,0 +1,25 @@ +--- +title: Features +lang: en-US +description: >- + Learn about features in the Optimism ecosystem. This guide provides detailed + information and resources about features. +--- + +import { Card, Cards } from 'nextra/components' + +# Features + +This section provides information on various features for chain operators. You'll find guides and overviews to help you understand and work with topics such as running an alternative data availability mode chain, implementing the bridged USDC standard on the OP Stack, running a custom gas token chain, OP Stack preinstalls, and span batches. + + + + + + + + + + + + diff --git a/pages/builders/chain-operators/features/_meta.json b/pages/builders/chain-operators/features/_meta.json index 5bb139e4b..4e76c33b5 100644 --- a/pages/builders/chain-operators/features/_meta.json +++ b/pages/builders/chain-operators/features/_meta.json @@ -1,7 +1,7 @@ { "preinstalls": "Preinstalls", - "alt-da-mode": "Run an Alt-DA Mode Chain", - "custom-gas-token": "Run a Custom Gas Token Chain", - "span-batches": "Use and Enable Span Batches on your Chain", + "alt-da-mode": "Run an Alt-DA Mode chain", + "custom-gas-token": "Run a custom gas token chain", + "span-batches": "Use and enable span batches on your chain", "bridged-usdc-standard": "Bridged USDC Standard for the OP Stack" } \ No newline at end of file diff --git a/pages/builders/chain-operators/features/alt-da-mode.mdx b/pages/builders/chain-operators/features/alt-da-mode.mdx index e6f6397c7..409190053 100644 --- a/pages/builders/chain-operators/features/alt-da-mode.mdx +++ b/pages/builders/chain-operators/features/alt-da-mode.mdx @@ -1,19 +1,19 @@ --- -title: How to Run an Alt-DA Mode Chain +title: How to run an Alt-DA mode chain lang: en-US description: Learn how to configure and run an Alt-DA mode chain within the OP Stack. --- import { Callout, Steps } from 'nextra/components' -# How to Run an Alt-DA Mode Chain +# How to run an Alt-DA mode chain The Alt-DA Mode feature is currently in Beta within the MIT-licensed OP Stack. Beta features are built and reviewed by Optimism Collective core contributors, and provide developers with early access to highly requested configurations. These features may experience stability issues, and we encourage feedback from our early users. -This guide provides a walkthrough for chain operators who want to run an Alt-DA Mode chain. See the [Alt-DA Mode Explainer](/stack/protocol/features/alt-da-mode) for a general overview of this OP Stack configuration. +This guide provides a walkthrough for chain operators who want to run an Alt-DA Mode chain. See the [Alt-DA Mode Explainer](/stack/beta-features/alt-da-mode) for a general overview of this OP Stack configuration. An Alt-DA Mode OP Stack chain enables a chain operator to post and read data to any alternative data availability layer that has built a functioning OP Stack DA Server. @@ -35,7 +35,7 @@ You should use at least the following compatible op\* versions when running your - ### Setup Your DA Server + ### Setup your DA server DA Servers are not built or maintained by Optimism Collective Core Contributors. DA servers are maintained by third parties and run at your own risk. Please reach out to the team who built the DA Server you are trying to run with any questions or issues. @@ -44,10 +44,10 @@ You should use at least the following compatible op\* versions when running your * Celestia's docs on how to run the [Celestia DA server](https://github.com/celestiaorg/op-plasma-celestia/blob/main/README.md) * EigenDA's docs on how to run the [EigenDA DA server](https://github.com/Layr-Labs/op-plasma-eigenda/blob/main/README.md) * Avail's docs on how to run the [AvailDA DA Server](https://docs.availproject.org/docs/build-with-avail/Optimium/op-stack/op-stack#setup-avail-da-server) - * 0gDA's docs on how to run the [0gDA DA Server](https://github.com/0glabs/0g-da-op-plasma/blob/op0g/README.md) + * 0gDA's docs on how to run the [0gDA DA Server](https://github.com/0glabs/0g-da-op-plasma) * Near DA's docs on how to run the [Near DA Server](https://github.com/Nuffle-Labs/data-availability/blob/84b484de98f58a91bf12c8abe8df27f5e753f63a/docs/OP-Alt-DA.md) - ### Configure Your `op-node` + ### Configure your `op-node` * Spin up your OP chain as usual but set `--altda.enabled=true` and point both `op-batcher` and `op-node` to the DA server. * No configuration changes are required for `op-geth` or `op-proposer`. @@ -67,7 +67,7 @@ You should use at least the following compatible op\* versions when running your ``` - ### Configure Your Batcher + ### Configure your batcher * Set `--altda.enabled=true` and `--altda.da-service=true`. * Provide the URL for `--atlda.da-server=$DA_SERVER_HTTP_URL`. @@ -88,7 +88,7 @@ You should use at least the following compatible op\* versions when running your After completing steps 1-3 above, you will have an Alt-DA mode chain up and running. - ### Set Your Fee Configuration + ### Set your fee configuration * Chain operators are not posting everything to Ethereum, just commitments, so chain operators will need to determine fee scalars values to charge users. The fee scalar values are network throughput dependent, so values will need to be adjusted by chain operators as needed. * Cost structure for Alt-DA Mode: The transaction data is split up into 128kb chunks and then submitted to your DA Layer. Then, 32 byte commitments are submitted (goes to batch inbox address) to L1 for each 128kb chunk. Then, figure out how much that costs relative to the amount of transactions your chain is putting through. @@ -105,12 +105,12 @@ You should use at least the following compatible op\* versions when running your -## For Node Operators (Full and Archive Nodes) +## For node operators (full and archive nodes) * Run a DA server as laid out in [Step 1](#setup-your-da-server) * Provide the same `--altda.enabled=true, --altda.da-server...` on `op-node` as listed in [Step 2](#configure-your-op-node) -## Inclusion Criteria +## Inclusion criteria Alt DA teams who want to be featured on this page must meet the following criteria: @@ -118,17 +118,17 @@ Alt DA teams who want to be featured on this page must meet the following criter * Supporting detailed documentation, to be referenced [here](#setup-your-da-server) * Functioning OP Stack devnet using your DA server with linked configuration, contract addresses, and RPC address -## Breaking Changes: Renaming Plasma Mode to Alt-DA Mode +## Breaking changes: renaming Plasma Mode to Alt-DA Mode This feature has been renamed from Plasma Mode to Alt-DA Mode in the monorepo at: [0bb2ff5](https://github.com/ethereum-optimism/optimism/commit/0bb2ff57c8133f1e3983820c0bf238001eca119b). There are several breaking changes you should be aware of. These include changes to configuration file parameters, environment variables, and CLI commands. Before proceeding with the migration, ensure you are using [OP Stack v1.9.1](https://github.com/ethereum-optimism/optimism/releases/tag/v1.9.1) or later. -### Modify `rollup.json` Config: +### Modify `rollup.json` config: Update your `rollup.json` configuration file by replacing the old Plasma config with the new Alt-DA config. There are two possible formats for the old Plasma config: -### Legacy Plasma Config +### Legacy plasma config If your config looks like this: @@ -140,7 +140,7 @@ If your config looks like this: "da_resolve_window": 2000, ``` -### Recent Plasma Config +### Recent plasma config Or if it looks like this: @@ -153,7 +153,7 @@ Or if it looks like this: } ``` -### New Alt-DA Config +### New Alt-DA config Replace either of the above configurations with: @@ -170,9 +170,9 @@ Replace either of the above configurations with: Only include fields in the new config that were present in your old config. -## Updating OP Stack Runtime Config Parameters +## Updating OP Stack runtime config parameters -### CLI Parameters +### CLI parameters Update the following CLI parameters for both `op-node` and `op-batcher`: @@ -183,7 +183,7 @@ Update the following CLI parameters for both `op-node` and `op-batcher`: | `--plasma.verify-on-read` | `--altda.verify-on-read` | | `--plasma.da-service` | `--altda.da-service` | -### Environment Variables +### Environment variables #### op-node @@ -222,8 +222,8 @@ After making these changes, your system should be properly configured to use the Remember to thoroughly test your configuration in testnet before going mainnet. -## Next Steps +## Next steps -* Additional questions? See the FAQ section in the [Alt-DA Mode Explainer](/stack/protocol/features/alt-da-mode#faqs). +* Additional questions? See the FAQ section in the [Alt-DA Mode Explainer](/stack/beta-features/alt-da-mode#faqs). * For more detailed info on Alt-DA Mode, see the [specs](https://specs.optimism.io/experimental/alt-da.html). * If you experience any problems, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/features/bridged-usdc-standard.mdx b/pages/builders/chain-operators/features/bridged-usdc-standard.mdx index f352c5e12..9158881b2 100644 --- a/pages/builders/chain-operators/features/bridged-usdc-standard.mdx +++ b/pages/builders/chain-operators/features/bridged-usdc-standard.mdx @@ -12,7 +12,7 @@ This explainer provides a high-level overview of the Bridged USDC Standard and h ## Bridged USDC Standard -USDC is one of the most bridged assets across the crypto ecosystem, and USDC is often bridged to new chains prior to any action from Circle. This can create a challenge when bridged USDC achieves substantial marketshare, but native USDC (issued by Circle) is preferred by the ecosystem, leading to fragmentation between multiple versions of USDC. Circle introduced the [Bridged USDC Standard](https://www.circle.com/en/bridged-usdc) to ensure that chain operators can easily deploy a form of bridged USDC that is capable of being upgraded in-place by Circle to native USDC, if and when appropriate, and prevent the fragmentation problem. +USDC is one of the most bridged assets across the crypto ecosystem, and USDC is often bridged to new chains prior to any action from Circle. This can create a challenge when bridged USDC achieves substantial market share, but native USDC (issued by Circle) is preferred by the ecosystem, leading to fragmentation between multiple versions of USDC. Circle introduced the [Bridged USDC Standard](https://www.circle.com/en/bridged-usdc) to ensure that chain operators can easily deploy a form of bridged USDC that is capable of being upgraded in-place by Circle to native USDC, if and when appropriate, and prevent the fragmentation problem. Bridged USDC Standard for the OP Stack allows for an efficient and modular solution for expanding the Bridged USDC Standard across the Superchain ecosystem. @@ -28,7 +28,7 @@ Chain operators can use the Bridged USDC Standard for the OP Stack to get bridge The referenced implementation for the OP Stack has undergone [audits from Spearbit](https://github.com/defi-wonderland/opUSDC/blob/main/audits/spearbit.pdf) and is recommended for production use. -## Next Steps +## Next steps * Ready to get started? Read the setup guide for the [Bridged USDC Standard for the OP Stack](https://github.com/defi-wonderland/opUSDC#setup). * If you experience any problems, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/features/custom-gas-token.mdx b/pages/builders/chain-operators/features/custom-gas-token.mdx index f2a42c986..b62405f19 100644 --- a/pages/builders/chain-operators/features/custom-gas-token.mdx +++ b/pages/builders/chain-operators/features/custom-gas-token.mdx @@ -1,22 +1,22 @@ --- -title: How to Run a Custom Gas Token Chain +title: How to run a custom gas token chain lang: en-US description: Learn how to run a custom gas token chain. --- import { Callout, Steps } from 'nextra/components' -# How to Run a Custom Gas Token Chain +# How to Run a custom gas token chain The Custom Gas Token feature is a Beta feature of the MIT licensed OP Stack. While it has received initial review from core contributors, it is still undergoing testing, and may have bugs or other issues. -This guide provides a walkthrough for chain operators who want to run a custom gas token chain. See the [Custom Gas Token Explainer](/stack/protocol/features/custom-gas-token) for a general overview of this OP Stack feature. +This guide provides a walkthrough for chain operators who want to run a custom gas token chain. See the [Custom Gas Token Explainer](/stack/beta-features/custom-gas-token) for a general overview of this OP Stack feature. An OP Stack chain that uses the custom gas token feature enables an end user to deposit an L1 native ERC20 token into L2 where that asset is minted as the native L2 asset and can be used to pay for gas on L2. - ### Deploying Your Contracts + ### Deploying your contracts * Checkout the [`v2.0.0-beta.3` of the contracts](https://github.com/ethereum-optimism/optimism/tree/op-contracts/v2.0.0-beta.3) and use the commit to deploy. @@ -56,7 +56,7 @@ section of the docs. ```bash DEPLOYMENT_OUTFILE=deployments/artifact.json \ DEPLOY_CONFIG_PATH= \ - forge script scripts/Deploy.s.sol:Deploy \ + forge script scripts/deploy/Deploy.s.sol:Deploy \ --broadcast --private-key $PRIVATE_KEY \ --rpc-url $ETH_RPC_URL ``` @@ -87,7 +87,7 @@ section of the docs. * `DEPLOY_CONFIG_PATH` is the path to the file for the deploy config used to deploy * `STATE_DUMP_PATH` is a path to the generated L2 allocs file, this is the genesis state and is required for the next step. - ### Generating L2 Genesis + ### Generating L2 genesis The `op-node` is used to generate the final L2 genesis file. It takes the allocs created by the forge script as input for the `--l2-allocs` flag. @@ -101,7 +101,7 @@ section of the docs. --outfile.rollup ``` - ### Spinning Up Your Infrastructure + ### Spinning up your infrastructure Ensure that the end to end system is running. @@ -125,7 +125,7 @@ section of the docs. cast call --rpc-url $L1_ETH_RPC_URL 'isCustomGasToken()(bool)' ``` - ### Depositing Custom Gas Token into the Chain + ### Depositing custom gas token into the chain * To deposit the custom gas token into the chain, users must use the **`OptimismPortalProxy.depositERC20Transaction`** method * Users MUST first `approve()` the `OptimismPortal` before they can deposit tokens using `depositERC20Transaction`. @@ -141,7 +141,7 @@ section of the docs. ) public; ``` - ### Withdrawing Custom Gas Tokens out of the Chain + ### Withdrawing custom gas tokens out of the chain * To withdraw your native custom gas token from the chain, users must use the **`L2ToL1MessagePasser.initiateWithdrawal`** method. Proving and finalizing withdrawals is identical to the process on chains that use ETH as the native gas token. @@ -154,8 +154,8 @@ section of the docs. ``` -## Next Steps +## Next steps -* Additional questions? See the FAQ section in the [Custom Gas Token Explainer](/stack/protocol/features/custom-gas-token#faqs). +* Additional questions? See the FAQ section in the [Custom Gas Token Explainer](/stack/beta-features/custom-gas-token#faqs). * For more detailed info on custom gas tokens, see the [specs](https://specs.optimism.io/experimental/custom-gas-token.html). * If you experience any problems, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/features/preinstalls.mdx b/pages/builders/chain-operators/features/preinstalls.mdx index 1b571d9aa..7c21d6596 100644 --- a/pages/builders/chain-operators/features/preinstalls.mdx +++ b/pages/builders/chain-operators/features/preinstalls.mdx @@ -6,7 +6,7 @@ description: Learn how to use preinstalls on your chain. import { Callout, Steps } from 'nextra/components' -# OP Stack Preinstalls +# OP Stack preinstalls This guide explains OP Stack preinstalls and what it brings to developers. To go to production on a new chain, developers need their core contracts: Gnosis Safes, the 4337 entrypoint, create2deployer, etc. On a blank EVM, these contracts can take weeks to be deployed. Now, core contracts come *preinstalled* on the OP Stack -- no third party deployment necessary. @@ -19,7 +19,7 @@ With these contracts preinstalled at set addresses, developers can also expect a Preinstalls are automatically enabled for all new OP chains after Ecotone. -## Contracts and Deployed Addresses +## Contracts and deployed addresses This table lists the specific contracts to be pre/deployed for new OP Chains. @@ -36,6 +36,6 @@ This table lists the specific contracts to be pre/deployed for new OP Chains. | [`permit2`](https://github.com/Uniswap/permit2) | `0x000000000022D473030F116dDEE9F6B43aC78BA3` | | [ERC-4337 Entrypoint `v0.6.0`](https://github.com/eth-infinitism/account-abstraction/tree/v0.6.0) | `0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789`
`SenderCreator` dependency @ `0x7fc98430eaedbb6070b35b39d798725049088348` on ETH mainnet | -## Resources and Next Steps +## Resources and next steps * Still Have Questions? You can reach us in our [developer support forum](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/features/span-batches.mdx b/pages/builders/chain-operators/features/span-batches.mdx index ccddabd3c..250257df5 100644 --- a/pages/builders/chain-operators/features/span-batches.mdx +++ b/pages/builders/chain-operators/features/span-batches.mdx @@ -6,7 +6,7 @@ description: Learn how to use and enable span batches on your chain. import { Callout, Steps } from 'nextra/components' -# Span Batches +# Span batches Span batches are an important feature that optimizes batch processing within the chain. This section provides an overview of span batches, instructions on how to enable them, and links to detailed design documents. @@ -14,7 +14,7 @@ Span batches are an important feature that optimizes batch processing within the Span batches allow for efficient processing of multiple batches in a single operation, reducing overhead and improving performance. By grouping transactions together, span batches can help optimize the throughput of the network. -## Enabling Span Batches +## Enabling span batches To enable span batches, follow these steps: @@ -41,7 +41,7 @@ To enable span batches, follow these steps: * You should see log entries indicating that batches are being processed according to the configured settings. -## Links to Related Pages +## Links to related pages For more detailed information on the design and implementation of span batches, refer to the following resources: diff --git a/pages/builders/chain-operators/hacks.mdx b/pages/builders/chain-operators/hacks.mdx new file mode 100644 index 000000000..5a30e8912 --- /dev/null +++ b/pages/builders/chain-operators/hacks.mdx @@ -0,0 +1,27 @@ +--- +title: Hacks +lang: en-US +description: >- + Learn about hacks in the Optimism ecosystem. This guide provides detailed + information and resources about hacks. +--- + +import { Card, Cards } from 'nextra/components' + +# Hacks + +This section provides information on various types of hacks related to OP Stack, including data availability, derivation, execution, and settlement. You'll find an overview and introduction to help you understand and work with these topics, as well as featured hacks for practical examples. + + + + + + + + + + + + + + diff --git a/pages/builders/chain-operators/hacks/_meta.json b/pages/builders/chain-operators/hacks/_meta.json index eb1022312..d4650c2da 100644 --- a/pages/builders/chain-operators/hacks/_meta.json +++ b/pages/builders/chain-operators/hacks/_meta.json @@ -1,8 +1,8 @@ { - "overview": "Intro to OP Stack Hacks", - "featured-hacks": "Featured Hacks", - "data-availability": "Data Availability Hacks", - "derivation": "Derivation Hacks", - "execution": "Execution Hacks", - "settlement": "Settlement Hacks" + "overview": "Intro to OP Stack hacks", + "featured-hacks": "Featured hacks", + "data-availability": "Data availability hacks", + "derivation": "Derivation hacks", + "execution": "Execution hacks", + "settlement": "Settlement hacks" } \ No newline at end of file diff --git a/pages/builders/chain-operators/hacks/data-availability.mdx b/pages/builders/chain-operators/hacks/data-availability.mdx index 4f33176a5..32218c494 100644 --- a/pages/builders/chain-operators/hacks/data-availability.mdx +++ b/pages/builders/chain-operators/hacks/data-availability.mdx @@ -1,12 +1,12 @@ --- -title: Data Availability Hacks +title: Data availability hacks lang: en-US description: Learn how to modify the default Data Availability Layer module for an OP Stack chain. --- import { Callout } from 'nextra/components' -# Data Availability Hacks +# Data availability hacks OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. diff --git a/pages/builders/chain-operators/hacks/derivation.mdx b/pages/builders/chain-operators/hacks/derivation.mdx index d8ab14d4c..47651c308 100644 --- a/pages/builders/chain-operators/hacks/derivation.mdx +++ b/pages/builders/chain-operators/hacks/derivation.mdx @@ -1,12 +1,12 @@ --- -title: Derivation Hacks +title: Derivation hacks lang: en-US description: Learn how to modify the default Derivation layer module for an OP Stack chain. --- import { Callout } from 'nextra/components' -# Derivation Hacks +# Derivation hacks OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. @@ -28,11 +28,11 @@ Modifying the Derivation layer can have unintended consequences. For example, re ## Modding -### EVM Event-Triggered Transactions +### EVM event-triggered transactions -The default Rollup configuration of the OP Stack includes "deposited"transactions that are triggered whenever a specific event is emitted by the `OptimismPortal` contract on L1. Using the same principle, an OP Stack chain can derive transactions from events emitted by *any* contract on an EVM-based DA. Refer to [attributes.go](https://github.com/ethereum-optimism/optimism/blob/e468b66efedc5f47f4e04dc1acc803d4db2ce383/op-node/rollup/derive/attributes.go#L70) to understand how deposited transactions are derived and how custom transactions can be created. +The default Rollup configuration of the OP Stack includes "deposited" transactions that are triggered whenever a specific event is emitted by the `OptimismPortal` contract on L1. Using the same principle, an OP Stack chain can derive transactions from events emitted by *any* contract on an EVM-based DA. Refer to [attributes.go](https://github.com/ethereum-optimism/optimism/blob/e468b66efedc5f47f4e04dc1acc803d4db2ce383/op-node/rollup/derive/attributes.go#L70) to understand how deposited transactions are derived and how custom transactions can be created. -### EVM Block-Triggered Transactions +### EVM block-triggered transactions Like with events, transactions on an OP Stack chain can be triggered whenever a new block is published on an EVM-based DA. The default Rollup configuration of the OP Stack already includes a block-triggered transaction in the form of [the "L1 info"transaction](https://github.com/ethereum-optimism/optimism/blob/e468b66efedc5f47f4e04dc1acc803d4db2ce383/op-node/rollup/derive/attributes.go#L103) that relays information like the latest block hash, timestamp, and base fee into L2. The Getting Started guide demonstrates the addition of a new block-triggered transaction in the form of a new transaction that reports the amount of gas burned via the base fee on L1. diff --git a/pages/builders/chain-operators/hacks/execution.mdx b/pages/builders/chain-operators/hacks/execution.mdx index 1a8f9c338..495ceb8a1 100644 --- a/pages/builders/chain-operators/hacks/execution.mdx +++ b/pages/builders/chain-operators/hacks/execution.mdx @@ -1,12 +1,12 @@ --- -title: Execution Hacks +title: Execution hacks lang: en-US description: Learn how to modify the default Execution Layer module for an OP Stack chain. --- import { Callout } from 'nextra/components' -# Execution Hacks +# Execution hacks OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. @@ -28,7 +28,7 @@ As with modifications to the Derivation Layer, modifications to the Execution La ## Modding -### EVM Tweaks +### EVM tweaks The default Execution Layer module is the EVM. It's possible to modify the EVM in many different ways like adding new precompiles or inserting predeployed smart contracts into the genesis state. Precompiles can help make common smart contract operations cheaper and can therefore further reduce the cost of execution for your specific use-case. These modifications should be made directly to [the execution client](https://github.com/ethereum-optimism/op-geth). diff --git a/pages/builders/chain-operators/hacks/featured-hacks.mdx b/pages/builders/chain-operators/hacks/featured-hacks.mdx index 81e4e0645..f844e08eb 100644 --- a/pages/builders/chain-operators/hacks/featured-hacks.mdx +++ b/pages/builders/chain-operators/hacks/featured-hacks.mdx @@ -1,12 +1,12 @@ --- -title: Featured Hacks +title: Featured hacks lang: en-US description: Learn about some of the customizations stack developers have made for an OP Stack chain. --- import { Callout } from 'nextra/components' -# Featured Hacks +# Featured hacks OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. @@ -28,7 +28,7 @@ Featured Hacks is a compilation of some of the cool stuff people are building on OPCraft was an OP Stack chain that ran a modified EVM as the backend for a fully onchain 3D voxel game built with [MUD](https://mud.dev/). -### OP Stack Configuration +### OP Stack configuration * Data Availability: Ethereum DA (Goerli) * Sequencer: Single Sequencer @@ -52,7 +52,7 @@ OPCraft was an OP Stack chain that ran a modified EVM as the backend for a fully Ticking Optimism is a proof-of-concept implementation of an OP Stack chain that calls a `tick` function every block. By using the OP Stack, Ticking Optimism avoids the need for off-chain infrastructure to execute a function on a regular basis. Ticking Conway is a system that uses Ticking Optimism to build [Conway's Game of Life](https://conwaylife.com/) onchain. -### OP Stack Configuration +### OP Stack configuration * Data Availability: Ethereum DA (any) * Sequencer: Single Sequencer diff --git a/pages/builders/chain-operators/hacks/overview.mdx b/pages/builders/chain-operators/hacks/overview.mdx index 8a8221f8c..cf7a56dd6 100644 --- a/pages/builders/chain-operators/hacks/overview.mdx +++ b/pages/builders/chain-operators/hacks/overview.mdx @@ -1,12 +1,12 @@ --- -title: Introduction to OP Stack Hacks +title: Introduction to OP Stack hacks lang: en-US description: Learn general information on how to experiment and customize an OP Stack chain. --- import { Callout } from 'nextra/components' -# Introduction to OP Stack Hacks +# Introduction to OP Stack hacks Welcome to OP Stack Hacks, the **highly experimental** region of the OP Stack docs. OP Stack Hacks are an unofficial guide for messing around with the OP Stack. Here you'll find information about ways that the OP Stack can be modified in interesting ways. @@ -18,7 +18,7 @@ OP Stack Hacks create blockchains that aren't exactly OP Stack, and may be insec OP Stack Hacks are not for the faint of heart. You will not be able to receive significant developer support for OP Stack Hacks β€” be prepared to get your hands dirty and to work without support. -## OP Stack Hack Guides +## OP Stack hack guides We have curated a list of guides to walk you through different OP stack modules that you can customize as a developer. @@ -28,7 +28,7 @@ We have curated a list of guides to walk you through different OP stack modules * [Settlement Hacks](settlement) * [Featured Hacks](featured-hacks) -## OP Stack Hack Tutorials +## OP Stack hack tutorials We also have a handful of tutorials offering step-by-step instructions on how to make customizations to an OP Stack chain. **As a reminder, you will not be able to receive significant developer support for OP Stack Hacks β€” be prepared to get your hands dirty and to work without support.** diff --git a/pages/builders/chain-operators/hacks/settlement.mdx b/pages/builders/chain-operators/hacks/settlement.mdx index 87baf9d44..2b96be231 100644 --- a/pages/builders/chain-operators/hacks/settlement.mdx +++ b/pages/builders/chain-operators/hacks/settlement.mdx @@ -1,12 +1,12 @@ --- -title: Settlement Hacks +title: Settlement hacks lang: en-US description: Learn how to modify the default Settlement Layer module for an OP Stack chain. --- import { Callout } from 'nextra/components' -# Settlement Hacks +# Settlement hacks OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. @@ -34,7 +34,7 @@ One simple modification to the Settlement Layer is to tweak the parameters of th ### Custom proofs -Settlement Layer modules use a proof system to verify the correctness of the state of your OP Stack chain as proposed on the third-party chain. In general, these proofs are either Optimistic proofs that require a withdrawal delay or Validity proofs that use a mathematical proof system to assert the validity of the proposal. The current Attestation Proof Optimistic Settlement module could be replaced with a fault proof system. +Settlement Layer modules use a proof system to verify the correctness of the state of your OP Stack chain as proposed on the third-party chain. In general, these proofs are either Optimistic proofs that require a withdrawal delay or Validity proofs that use a mathematical proof system to assert the validity of the proposal. The current Attestation Proof Optimistic Settlement module could be replaced with a Fault Proof System. ### Multiple modules diff --git a/pages/builders/chain-operators/management.mdx b/pages/builders/chain-operators/management.mdx new file mode 100644 index 000000000..df32978e5 --- /dev/null +++ b/pages/builders/chain-operators/management.mdx @@ -0,0 +1,27 @@ +--- +title: Management +lang: en-US +description: >- + Learn about management in the Optimism ecosystem. This guide provides detailed + information and resources about management. +--- + +import { Card, Cards } from 'nextra/components' + +# Management + +This section provides information on chain operator best practices, using blobs, managing keys, rollup operations, using snap sync for chain operators, and troubleshooting chain operations. You'll find guides and tutorials to help you understand and work with these topics. + + + + + + + + + + + + + + diff --git a/pages/builders/chain-operators/management/_meta.json b/pages/builders/chain-operators/management/_meta.json index 1b54b76aa..a33e1fbfb 100644 --- a/pages/builders/chain-operators/management/_meta.json +++ b/pages/builders/chain-operators/management/_meta.json @@ -1,8 +1,8 @@ { - "blobs": "Using Blobs", + "blobs": "Using blobs", "snap-sync": "Using Snap Sync", - "operations": "Node Operations", - "key-management": "Key Management", + "operations": "Node operations", + "key-management": "Key management", "troubleshooting": "Troubleshooting", - "best-practices": "Best Practices" + "best-practices": "Best practices" } diff --git a/pages/builders/chain-operators/management/best-practices.mdx b/pages/builders/chain-operators/management/best-practices.mdx index 33184b384..d5bcd8ae6 100644 --- a/pages/builders/chain-operators/management/best-practices.mdx +++ b/pages/builders/chain-operators/management/best-practices.mdx @@ -1,19 +1,17 @@ --- -title: Chain Operator Best Practices +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 +# Chain operator best practices The following information has some best practices around running the OP Stack's off-chain components. -## Best Practices - -### Correct Release Versions +## 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 @@ -35,7 +33,7 @@ and `op-geth` releases can be found [here](https://github.com/ethereum-optimism/ version. Since we cannot left-pad with zeroes, the geth major version is not padded. -### Keep Deployment Artifacts +## Keep deployment artifacts After deploying your contracts on Ethereum, you should keep a record of all the deployment artifacts: @@ -49,20 +47,20 @@ created in [packages/contracts-bedrock/deployments](https://github.com/ethereum- deployment * The genesis file that you generated after the contract deployment -### Incremental Upgrade Rollouts +## 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 +## 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. -### Improve Reliability of Peer-to-Peer transactions +## Improve reliability of peer-to-peer transactions These flags can improve the reliability of peer-to-peer transactions from internal replica nodes and the sequencer node. @@ -84,6 +82,9 @@ GETH_TXPOOL_NOLOCALS: "true" For additional information about these flags, check out our [Execution Layer Configuration Options](/builders/node-operators/configuration/execution-config) doc. +## Write your own runbooks + +Create custom runbooks to prepare for operating an OP Stack chain. For a deeper understanding of daily operations and best practices, explore the public [OP Mainnet Runbooks](https://oplabs.notion.site/OP-Mainnet-Runbooks-120f153ee1628045b230d5cd3df79f63) to see how these practices could be applied to your own chain. ## Assumptions diff --git a/pages/builders/chain-operators/management/blobs.mdx b/pages/builders/chain-operators/management/blobs.mdx index 398d7c08d..605e1b296 100644 --- a/pages/builders/chain-operators/management/blobs.mdx +++ b/pages/builders/chain-operators/management/blobs.mdx @@ -1,5 +1,5 @@ --- -title: Using Blobs +title: Using blobs lang: en-US description: Learn how to switch to using blobs for your chain. --- @@ -15,10 +15,10 @@ This guide walks you through how to switch to using blobs for your chain after E This guide is intended for chains already upgraded to Ecotone. -## Switch to Using Blobs +## Switch to using blobs - ### Determine Scalar Values for Using Blobs + ### Determine scalar values for using blobs 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. @@ -27,7 +27,7 @@ This guide walks you through how to switch to using blobs for your chain after E information is tuned to a network like OP Mainnet. For more details on fee scalar, see [Transaction Fees, Ecotone section](/stack/transactions/fees#ecotone). - #### Adjust Fees to Change Margins + #### Adjust fees to change margins As a chain operator, you may want to scale your scalar values up or down either because the throughput of your chain has changed and you are either filling significantly more or less of blobs, or because you wish to simply increase your margin to cover operational expenses. So, to increase or decrease your margin on L1 data costs, you would simply scale both the `l1baseFeeScalar` and the `l1blobBaseFeeScalar` by the same multiple. @@ -39,7 +39,7 @@ This guide walks you through how to switch to using blobs for your chain after E newBlobBaseFeeScalar = prevBlobBaseFeeScalar * 1.1 ``` - ### Update Your Scalar Values for Blobs + ### Update your scalar values for blobs Once you have determined your ideal `BaseFeeScalar` and `BlobBaseFeeScalar`, you will need to apply those values for your chain. The first step is to encode both values into a single value to be set in your L1 Config: @@ -74,7 +74,7 @@ This guide walks you through how to switch to using blobs for your chain after E - ### Update Your Batcher to Post Blobs + ### Update your batcher to post blobs Now that the fee config has been updated, you should immediately configure your batcher! @@ -89,7 +89,7 @@ This guide walks you through how to switch to using blobs for your chain after E * 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 +## Switch back to using calldata As a chain operator, if the `blobBaseFee` is expensive enough and your chain is not processing enough transactions to meaningfully fill blobs within your @@ -98,7 +98,7 @@ back to posting data to calldata. Utilize the [fee parameter calculator](https:/ blobs back to using calldata. - ### Determine Your Scalar Values for Using Calldata + ### Determine your scalar values for using calldata If you are using calldata, then you can set your `BaseFeeScalar` similarly to how you would have set "scalar" prior to Ecotone, though with a 5-10% bump to @@ -115,11 +115,11 @@ blobs back to using calldata. BlobBaseFeeScalar = 0 ``` - ### Update Your Scalar Values for Using Calldata + ### Update your scalar values for using calldata To set your scalar values, follow the same process as laid out in [Update your Scalar values for Blobs](#update-your-scalar-values-for-blobs). - ### Update Your Batcher to Post Calldata + ### Update your batcher to post calldata Now that the fee config has been updated, you will want to immediately configure your batcher. @@ -131,7 +131,7 @@ blobs back to using calldata. * 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 +## Other considerations * For information on L1 Data Fee changes related to the Ecotone upgrade, visit the [Transaction Fees page](/stack/transactions/fees#ecotone). * If you want to enable archive nodes, you will need to access a blob archiver service. You can use [Optimism's](/builders/node-operators/management/snapshots#op-mainnet-archive-node) or [run your own](/builders/chain-operators/tools/explorer#create-an-archive-node). diff --git a/pages/builders/chain-operators/management/key-management.mdx b/pages/builders/chain-operators/management/key-management.mdx index 3fc1d38e8..870b0f4e9 100644 --- a/pages/builders/chain-operators/management/key-management.mdx +++ b/pages/builders/chain-operators/management/key-management.mdx @@ -1,19 +1,19 @@ --- -title: Key Management +title: Key management lang: en-US description: A guide for chain operators on managing private keys on their chain, covering hot and cold wallets, and the use of a HSM. --- import { Callout } from 'nextra/components' -# Managing Your Keys +# Managing your keys This guide informs chain operators on important key management considerations. There are certain [privileged roles](/chain/security/privileged-roles) that need careful consideration. The privileged roles are categorized as hot wallets or cold wallets. -## Hot Wallets +## Hot wallets The addresses for the `Batcher` and the `Proposer` need to have their private keys online somewhere for a component of the system to work. If these addresses @@ -21,7 +21,7 @@ are compromised, the system can be exploited. It is up to the chain operator to make the decision on how they want to manage these keys. One suggestion is to use a Hardware Security Module (HSM) to provide -a safer environment for key management. Cloud providers often times provide +a safer environment for key management. Cloud providers oftentimes provide Key Management Systems (KMS) that can work with your developer operations configurations. This can be used in conjunction with the `eth_signTransaction` RPC method. @@ -31,7 +31,7 @@ RPC method. if you're interested in whats happening under the hood. -## Cold Wallets +## Cold wallets The addresses for the cold wallets cannot be used without human intervention. These can be set up as multisig contracts, so they can be controlled by groups diff --git a/pages/builders/chain-operators/management/operations.mdx b/pages/builders/chain-operators/management/operations.mdx index 0cbc68941..b85102f96 100644 --- a/pages/builders/chain-operators/management/operations.mdx +++ b/pages/builders/chain-operators/management/operations.mdx @@ -1,15 +1,15 @@ --- -title: Rollup Operations +title: Rollup operations lang: en-US description: Learn basics of rollup operations, such as how to start and stop your rollup, get your rollup config, and how to add nodes. --- import { Callout, Steps } from 'nextra/components' -# Rollup Operations +# Rollup operations This guide reviews the basics of rollup operations, such as how to start your rollup, stop your rollup, get your rollup config, and add nodes. -## Stopping Your Rollup +## Stopping your rollup An orderly shutdown is done in the reverse order to the order in which components were started: @@ -30,7 +30,7 @@ An orderly shutdown is done in the reverse order to the order in which component Make sure you use **CTRL-C** to avoid database corruption. If Geth stops unexpectedly the database can be corrupted. This is known as an "[unclean shutdown](https://geth.ethereum.org/docs/fundamentals/databases#unclean-shutdowns)" and it can lead to a variety of problems for the node when it is restarted. -## Starting Your Rollup +## Starting your rollup To restart the blockchain, use the same order of components you did when you initialized it. @@ -60,7 +60,7 @@ Just wait until it is. -## Getting Your Rollup Config +## Getting your rollup config Use this tool to get your rollup config from `op-node`. This will only work if your chain is **already** in the [superchain-registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json) and `op-node` has been updated to pull those changes in from the registry. @@ -113,13 +113,13 @@ You'll need to run this tool: "use_plasma": false } ``` -### Check the Flags +### Check the flags Ensure that you are using the appropriate flag. The `--network=sepolia` flag allows the tool to pick up the appropriate data from the registry, and uses the OPChains mapping under the hood. -## Adding Nodes +## Adding nodes To add nodes to the rollup, you need to initialize `op-node` and `op-geth`, similar to what you did for the first node. You should *not* add an `op-batcher` because there should be only one. @@ -162,7 +162,7 @@ If you do it this way, you won't have to wait until the transactions are written ### Start `op-node` (using the same command line you used on the initial node) -## Next Steps +## Next steps * See the [Node Configuration](/builders/node-operators/configuration/base-config) guide for additional explanation or customization. * If you experience difficulty at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/management/snap-sync.mdx b/pages/builders/chain-operators/management/snap-sync.mdx index 07baefa52..97e372754 100644 --- a/pages/builders/chain-operators/management/snap-sync.mdx +++ b/pages/builders/chain-operators/management/snap-sync.mdx @@ -1,23 +1,23 @@ --- -title: Using Snap Sync for Chain Operators +title: Using snap sync for chain operators lang: en-US description: Learn how to use and enable snap sync on your OP chain. --- import { Callout, Steps } from 'nextra/components' -# Using Snap Sync for Chain Operators +# Using snap sync for chain operators -This guide reviews the optional feature of Snap Sync for OP chains, including benefits and how to enable the feature. +This guide reviews the optional feature of snap sync for OP chains, including benefits and how to enable the feature. -Snap Sync significantly improves the experience of syncing an OP Stack node. Snap Sync is a native feature of go-ethereum that is now optionally enabled on `op-node` & `op-geth`. -Snap Sync works by downloading a snapshot of the state from other nodes on the network and is then able to start executing blocks from the completed state rather than having to re-execute every single block. -This means that performing a Snap Sync is significantly faster than performing a full sync. +Snap sync significantly improves the experience of syncing an OP Stack node. Snap sync is a native feature of go-ethereum that is now optionally enabled on `op-node` & `op-geth`. +Snap sync works by downloading a snapshot of the state from other nodes on the network and is then able to start executing blocks from the completed state rather than having to re-execute every single block. +This means that performing a snap sync is significantly faster than performing a full sync. * Snap sync enables node operators on your network to sync faster. * Snap sync removes the need for nodes on your post Ecotone network to run a [blob archiver](/builders/node-operators/management/blobs). -## Enable Snap Sync for Chains +## Enable snap sync for chains To enable snap sync, chain operators need to spin up a node which is exposed to the network and has transaction gossip disabled. @@ -29,17 +29,17 @@ For snap sync, all `op-geth` nodes should expose port `30303` TCP and `30303` UD - ### Setup a Snap Sync Node + ### Setup a snap sync node * Expose port `30303` (`op-geth`'s default discovery port) to the internet on TCP and UDP. * Disable transaction gossip with the [`--rollup.disabletxpoolgossip`](/builders/node-operators/configuration/execution-config#rollupdisabletxpoolgossip) flag - ### Enable Snap Sync on Your Network + ### Enable snap sync on your network - * Follow the [Node Operator Snap Sync Guide](/builders/node-operators/management/snap-sync#enable-snap-sync-for-your-node) to enable snap sync for your chain network. + * Follow the [Node operator snap sync guide](/builders/node-operators/management/snap-sync#enable-snap-sync-for-your-node) to enable snap sync for your chain network. ## Next Steps -* See the [Node Configuration](/builders/node-operators/configuration/base-config#configuration) guide for additional explanation or customization. +* See the [Node configuration](/builders/node-operators/configuration/base-config#configuration) guide for additional explanation or customization. * If you experience difficulty at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/management/troubleshooting.mdx b/pages/builders/chain-operators/management/troubleshooting.mdx index f24f8561d..05a0de551 100644 --- a/pages/builders/chain-operators/management/troubleshooting.mdx +++ b/pages/builders/chain-operators/management/troubleshooting.mdx @@ -1,14 +1,14 @@ --- -title: Troubleshooting Chain Operations +title: Troubleshooting chain operations lang: en-US description: Learn solutions to common problems when troubleshooting chain operations. --- -# Troubleshooting: Chain Operations +# Troubleshooting: chain operations This page lists common troubleshooting scenarios and solutions for chain operators. -## EvmError in Contract Deployment +## EvmError in contract deployment L1 smart contract deployment fails with the following error: @@ -31,9 +31,9 @@ You can generate a random salt value using the following command: export IMPL_SALT=$(openssl rand -hex 32) ``` -## Failed to Find the L2 Heads to Start From +## Failed to find the L2 Heads to start from -`op-node` fails to execute the derviation process with the following error: +`op-node` fails to execute the derivation process with the following error: ```text WARN [02-16|21:22:02.868] Derivation process temporary error attempts=14 err="stage 0 failed resetting: temp: failed to find the L2 Heads to start from: failed to fetch L2 block by hash 0x0000000000000000000000000000000000000000000000000000000000000000: failed to determine block-hash of hash 0x0000000000000000000000000000000000000000000000000000000000000000, could not get payload: not found" @@ -54,7 +54,7 @@ If you are not following the tutorial, make sure to take the following steps: 4. Reinitialize `op-geth` with the `genesis.json` file. 5. Restart `op-geth` and `op-node`. -## Batcher Unable to Publish Transaction +## Batcher unable to publish transaction `op-batcher` fails to publish transactions with the following error: diff --git a/pages/builders/chain-operators/self-hosted.mdx b/pages/builders/chain-operators/self-hosted.mdx index 200eb7f4b..31dc22ac9 100644 --- a/pages/builders/chain-operators/self-hosted.mdx +++ b/pages/builders/chain-operators/self-hosted.mdx @@ -1,16 +1,16 @@ --- -title: How to Start a Self-Hosted Chain +title: How to start a self-hosted chain lang: en-US description: Learn how to start a self-hosted OP Chain with standard configuration. --- import { Callout, Steps } from 'nextra/components' -# How to Start a Self-Hosted Chain +# How to start a self-hosted chain This guide provides an overview of how to start a self-hosted OP Chain with standard configuration. It walks you through how to build, configure, test, and launch your OP Chain. To skip ahead to custom features or settings, you can explore the [chain operator tutorials](#chain-operator-tutorials). -## Build Your Chain +## Build your chain There are two main steps to get started building your own self-hosted OP Chain: learn fundamental components of OP chains and spin up an OP Stack testnet chain. @@ -24,7 +24,7 @@ There are two main steps to get started building your own self-hosted OP Chain: 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), - and [L2 preinstall contracts](/builders/chain-operators/features/preinstalls). + 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. @@ -38,7 +38,7 @@ There are two main steps to get started building your own self-hosted OP Chain: * Just follow the [Creating Your Own L2 Rollup Testnet](/builders/chain-operators/tutorials/create-l2-rollup) tutorial to get started. -## Configure Your Chain +## Configure your chain OP Chains can be configured for throughput, cost, and other decentralization tradeoffs. The following steps are intended for standard configuration of OP Chains. @@ -63,7 +63,7 @@ OP Chains can be configured for throughput, cost, and other decentralization tra * Enable [analytics tracking for your OP Chain](/builders/node-operators/management/metrics), to immediately generate onchain metrics after mainnet launch. -## Test Your Chain +## Test your chain Before launching on Mainnet, thoroughly test and debug OP Chain contracts, features, and security. Here are your options. @@ -84,11 +84,11 @@ Before launching on Mainnet, thoroughly test and debug OP Chain contracts, featu * Run [basic transaction tests](https://metamask.io/) using Metamask. -## Launch Your Chain on Mainnet +## Launch your chain on Mainnet After testing is complete, you are ready to launch your OP Chain on Mainnet. Optionally, you can also request [launch support](https://share.hsforms.com/1yENj8CV9TzGYBASD0JC8_gqoshb) and subscribe to [receive chain upgrade notifications](https://github.com/ethereum-optimism/developers/discussions/categories/announcements). -## Chain Operator Tutorials +## Chain operator tutorials Here's a curated collection of chain operator tutorials put together by the Optimism community. They'll help you get a head start deploying your first OP Stack chain. @@ -105,7 +105,7 @@ They'll help you get a head start deploying your first OP Stack chain. You can also [suggest a new tutorial](https://github.com/ethereum-optimism/docs/issues/new?assignees=\&labels=tutorial%2Cdocumentation%2Ccommunity-request\&projects=\&template=suggest_tutorial.yaml\&title=%5BTUTORIAL%5D+Add+PR+title) if you have something specific in mind. We'd love to grow this list! -## Next Steps +## Next steps * After deploying your chain, check the [Rollup Operations](./management/operations) guide for common operations you'll need to run with your rollup. * If you run into any problems, please visit the [Chain Troubleshooting Guide](./management/troubleshooting) for help. diff --git a/pages/builders/chain-operators/tools.mdx b/pages/builders/chain-operators/tools.mdx new file mode 100644 index 000000000..c8018d508 --- /dev/null +++ b/pages/builders/chain-operators/tools.mdx @@ -0,0 +1,29 @@ +--- +title: Tools +lang: en-US +description: >- + Learn about tools in the Optimism ecosystem. This guide provides detailed + information and resources about tools. +--- + +import { Card, Cards } from 'nextra/components' + +# Tools + +This section provides information on chain monitoring options, deploying a block explorer, configuring a challenger for your chain, conductor, and deployer. You'll find guides, overviews, and tools to help you understand and work with these topics. + + + + + + + + + + + + + + + + diff --git a/pages/builders/chain-operators/tools/_meta.json b/pages/builders/chain-operators/tools/_meta.json index 826e2e1db..990ea87a2 100644 --- a/pages/builders/chain-operators/tools/_meta.json +++ b/pages/builders/chain-operators/tools/_meta.json @@ -1,5 +1,9 @@ { - "op-challenger": "Configure Challenger For Your Chain", + "chain-monitoring": "Chain monitoring", + "explorer": "Block explorer", + "op-challenger": "op-challenger", "op-conductor": "op-conductor", - "explorer": "Block Explorer" + "op-deployer": "op-deployer", + "op-txproxy": "op-txproxy", + "proxyd": "proxyd" } diff --git a/pages/builders/chain-operators/tools/chain-monitoring.mdx b/pages/builders/chain-operators/tools/chain-monitoring.mdx new file mode 100644 index 000000000..14da3c81b --- /dev/null +++ b/pages/builders/chain-operators/tools/chain-monitoring.mdx @@ -0,0 +1,128 @@ +--- +title: Chain monitoring options +lang: en-US +description: Learn about onchain and offchain monitoring options for your OP Stack chain. +--- + +import { Callout } from 'nextra/components' + +# Chain monitoring options + +This explainer covers the basics of onchain and offchain monitoring options for your OP Stack chain. Onchain monitoring services allow chain operators to monitor the overall system and onchain events. +Offchain monitoring lets chain operators to monitor the operation and behavior of nodes and other offchain components. + +## Onchain monitoring services + +Onchain monitoring services provide insights into the overall system, helping chain operators track and monitor on-chain events. Some examples of onchain monitoring services include `monitorism` and `dispute-mon`. + +### `monitorism` + +Monitorism is a tooling suite that supports monitoring and active remediation actions for the OP Stack chain. Monitorism uses monitors as passive security providing automated monitoring for the OP Stack. They are used to monitor the OP stack and alert on specific events that could be a sign of a security incident. + +Currently, the list of monitors includes: + +Security integrity monitors: These are monitors necessary for making sure Bridges between L2 and L1 are safe and work as expected. These monitors are divided in two subgroups: + +* Pre-Faultproof Chain Monitors: + * Fault Monitor: checks for changes in output roots posted to the L2OutputOracle contract. When a change is detected, it reconstructs the output root from a trusted L2 source and looks for a match. + * Withdrawals Monitor: checks for new withdrawals that have been proven to the OptimismPortal contract. Each withdrawal is checked against the `L2ToL1MessagePasser` contract. +* Faultproof chain monitors: + * Faultproof Withdrawal: The Faultproof Withdrawal component monitors `ProvenWithdrawals` events on the `OptimismPortal` contract and performs checks to detect any violations of invariant conditions on the chain. If a violation is detected, the issue is logged, and a Prometheus metric is set for the event. This component is designed to work exclusively with chains that are already utilizing the Fault Proofs system. This is a new version of the deprecated `chain-mon`, `faultproof-wd-mon`. For detailed information on how the component works and the algorithms used, please refer to the component README. + +Security monitors: Those tools monitor other aspects of several contracts used in optimism: + +* Global Events Monitor: made for taking YAML rules as configuration and monitoring the events that are emitted on the chain. +* Liveness Expiration Monitor: monitors the liveness expiration on Safes. +* Balances Monitor: emits a metric reporting the balances for the configured accounts. +* Multisig Monitor: The multisig monitor reports the paused status of the OptimismPortal contract. If set, reports the latest nonce of the configured Safe address and the latest presigned nonce stored in One Password.. The latest presigned nonce is identified by looking for items in the configured vault that follow a `ready-.json` name. The highest nonce of this item name format is reported. +* Drippie Monitor: tracks the execution and executability of drips within a Drippie contract. +* Secrets Monitor: takes a Drippie contract as a parameter and monitors for any drips within that contract that use the `CheckSecrets` dripcheck contract. `CheckSecrets` is a dripcheck that allows a drip to begin once a specific secret has been revealed (after a delay period) and cancels the drip if a second secret is revealed. Monitoring these secrets is important, as their revelation may indicate that the secret storage platform has been compromised and someone is attempting to exfiltrate the ETH controlled by the drip. + +For more information on these monitors and how to use them, [check out the repo](https://github.com/ethereum-optimism/monitorism?tab=readme-ov-file#monitorism). + +### `dispute-mon` + +Chain operators should consider running `op-dispute-mon`. It's an essential security monitoring service that tracks game statuses, providing visibility over the last 28 days. + +`dispute-mon` is set up and built the same way as `op-challenger`. This means that you can run it the same way (run `make op-dispute-mon` in the directory). + +A basic configuration option would look like this: + +``` +OP_DISPUTE_MON_LOG_FORMAT=logfmt +OP_DISPUTE_MON_METRICS_ENABLED=true +OP_DISPUTE_MON_METRICS_ADDR=0.0.0.0 +OP_DISPUTE_MON_METRICS_PORT=7300 + +OP_DISPUTE_MON_L1_ETH_RPC=.. +OP_DISPUTE_MON_ROLLUP_RPC=.. +OP_DISPUTE_MON_GAME_FACTORY_ADDRESS=.. + +OP_DISPUTE_MON_HONEST_ACTORS=.. +``` + +`OP_DISPUTE_MON_HONEST_ACTORS` is a CSV (no spaces) list of addresses that are used for the honest `op-challenger` instances. + +Additional flags: + +* `OP_DISPUTE_MON_GAME_WINDOW`: This is the window of time to report on games. It should leave a buffer beyond the max game duration for bond claiming. If Fault Proof game parameters are not changes (e.g. MAX\_CLOCK\_DURATION), it is recommended to leave this as the default. +* `OP_DISPUTE_MON_MONITOR_INTERVAL`: The interval at which to check for new games. Defaults to 30 seconds currently. +* `OP_DISPUTE_MON_MAX_CONCURRENCY`: The max thread count. Defaults to 5 currently. + +You can find more info on `op-dispute-mon` on [the repo](https://github.com/ethereum-optimism/optimism/tree/develop/op-dispute-mon). + +Chain operators can easily create their grafana dashboard for Dispute Monitor using the following json file: [Download the Dispute Monitor JSON](/resources/grafana/dispute-monitor-1718214549035.json). + +## Offchain component monitoring + +Offchain monitoring allows chain operators to monitor the operation and behavior of nodes and other offchain components. Some of the more common components that you'll likely want to monitor include `op-node`, `op-geth`, `op-proposer`, `op-batcher`, and `op-challenger`. +The general steps for enabling offchain monitoring are pretty consistent for all the OP components: + +1. Expose the monitoring port by enabling the `--metrics.enabled` flag +2. Customize the metrics port and address via the `--metrics.port` and `--metrics.addr` flags, respectively +3. Use [Prometheus](https://prometheus.io/) to scrape data from the metrics port +4. Save the data in `influxdb` +5. Share the data with [Grafana](https://grafana.com/) to build your custom dashboard + +### `op-node` + +`op-node` metrics and monitoring is detailed in the [Node Metrics and Monitoring](/builders/node-operators/management/metrics) guide. To enable metrics, pass the `--metrics.enabled` flag to `op-node` and follow the steps above for customization options. +See [this curated list](/builders/node-operators/management/metrics#important-metrics) for important metrics to track specifically for `op-node`. + +### `op-geth` + +To enable metrics, pass the `--metrics.enabled` flag to the op-geth. You can customize the metrics port and address via the `--metrics.port` and `--metrics.addr` flags, respectively. + +### `op-proposer` + +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). + +### `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). + +### `op-challenger` + +The `op-challenger` operates as the *honest actor* in the fault dispute system and defends the chain by securing the `OptimismPortal` and ensuring the game always resolves to the correct state of the chain. +For verifying the legitimacy of claims, `op-challenger` relies on a synced, trusted rollup node as well as a trace provider (e.g., [Cannon](/stack/fault-proofs/cannon)). See the [OP-Challenger Explainer](/stack/fault-proofs/challenger) for more information on this service. + +To enable metrics, pass the `--metrics.enabled` flag to `op-challenger` and follow the steps above for customization options. + +``` + --metrics.addr value (default: "0.0.0.0") ($OP_CHALLENGER_METRICS_ADDR) + Metrics listening address + + --metrics.enabled (default: false) ($OP_CHALLENGER_METRICS_ENABLED) + Enable the metrics server + + --metrics.port value (default: 7300) ($OP_CHALLENGER_METRICS_PORT) + Metrics listening port +``` + +## Next steps + +* If you encounter difficulties at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/tools/explorer.mdx b/pages/builders/chain-operators/tools/explorer.mdx index fe42693ac..3046fe498 100644 --- a/pages/builders/chain-operators/tools/explorer.mdx +++ b/pages/builders/chain-operators/tools/explorer.mdx @@ -1,12 +1,12 @@ --- -title: Block Explorer +title: Block explorer lang: en-US description: Learn how to deploy a Blockscout block explorer for your OP Stack chain. --- import { Callout } from 'nextra/components' -# Deploying a Block Explorer +# Deploying a block explorer [Blockscout](https://www.blockscout.com/) is an open source block explorer that supports OP Stack chains. Keep reading for a quick overview on how to deploy Blockscout for your OP Stack chain. @@ -19,7 +19,7 @@ Keep reading for a quick overview on how to deploy Blockscout for your OP Stack * [Docker](https://docs.docker.com/get-docker/) -## Create an Archive Node +## Create an archive node Blockscout needs access to an [archive node](https://www.alchemy.com/overviews/archive-nodes#archive-nodes) for your OP Stack chain to properly index transactions, blocks, and internal interactions. If using `op-geth`, you can run a node in archive mode with the `--gcmode=archive` flag. diff --git a/pages/builders/chain-operators/tools/op-challenger.mdx b/pages/builders/chain-operators/tools/op-challenger.mdx index 760af2647..ff1927eae 100644 --- a/pages/builders/chain-operators/tools/op-challenger.mdx +++ b/pages/builders/chain-operators/tools/op-challenger.mdx @@ -1,17 +1,17 @@ --- -title: How to Configure Challenger For Your Chain +title: How to configure challenger for your chain lang: en-US description: Learn how to configure challenger for your OP Stack chain. --- import { Callout, Steps } from 'nextra/components' -# How to Configure Challenger For Your Chain +# How to configure challenger for your chain -This guide provides a walkthrough of setting up the configuration and monitoring options for `op-challenger`. See the [OP-Challenger Explainer](/stack/protocol/fault-proofs/challenger) for a general overview of this fault proofs feature. +This guide provides a walkthrough of setting up the configuration and monitoring options for `op-challenger`. See the [OP-Challenger Explainer](/stack/fault-proofs/challenger) for a general overview of this fault proofs feature. - ### Build the Executable + ### Build the executable * Clone the monorepo @@ -19,7 +19,7 @@ This guide provides a walkthrough of setting up the configuration and monitoring git clone https://github.com/ethereum-optimism/optimism.git ``` - * Check out the [latest release of `op-challenger`](https://github.com/ethereum-optimism/optimism/releases/tag/op-challenger%2Fv1.0.1) and use the commit to deploy. Alternatively, chain operators can use the prebuilt [challenger docker images](https://us-docker.pkg.dev/oplabs-tools-artifacts/images/op-challenger:v1.0.1). + * Check out the [latest release of `op-challenger`](https://github.com/ethereum-optimism/optimism/releases) and use the commit to deploy. Alternatively, chain operators can use the prebuilt challenger docker images included in the release notes. If a Docker image is used, it already comes with `op-program` server and an executable for Cannon embedded, so the Cannon bin doesn't need to be specified. ```bash @@ -38,7 +38,7 @@ This guide provides a walkthrough of setting up the configuration and monitoring make op-challenger ``` - ### Configure Challenger + ### Configure challenger * Configure challenger with the required flags. Tip: Use the `op-challenger --help` to view all subcommands, command line, and environment variable options. * The example config file below shows the flags to configure in this step: @@ -81,12 +81,12 @@ This guide provides a walkthrough of setting up the configuration and monitoring #### `--rollup-rpc` - * This needs to be an`op-node` archive node because challenger needs access to output roots from back when the games start. See below for important configuration details: + * This needs to be an `op-node` archive node because challenger needs access to output roots from back when the games start. See below for important configuration details: 1. Safe Head Database (SafeDB) Configuration for op-node: * The `op-node` behind the `op-conductor` must have the SafeDB enabled to ensure it is not stateless. - * To Enable SafeDB, set the `--safedb.path` value in your configuration. This specifies the file path used to persist safe head update data. + * To enable SafeDB, set the `--safedb.path` value in your configuration. This specifies the file path used to persist safe head update data. * Example Configuration: ``` @@ -138,7 +138,7 @@ This guide provides a walkthrough of setting up the configuration and monitoring # if you use the wrong one, you will lose the game # if you deploy your own contracts, you specify the hash, the root of the json file # op mainnet are tagged versions of op-program - # make reproducable prestate + # make reproducible prestate # challenger verifies that onchain --cannon-prestate ./op-program/bin/prestate.json \ # load the game factory address from system config or superchain registry @@ -164,7 +164,7 @@ This guide provides a walkthrough of setting up the configuration and monitoring * There are two ways to specify the prestate to use: * `--cannon-prestate`: specifies a path to a single Cannon pre-state Json file * `--cannon-prestates-url`: specifies a URL to load pre-states from. This enables participating in games that use different prestates, for example due to a network upgrade. The prestates are stored in this directory named by their hash. - * Example final Url for a prestate: + * Example final URL for a prestate: * [https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json](https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json) * This file contains the cannon memory state. @@ -172,7 +172,7 @@ This guide provides a walkthrough of setting up the configuration and monitoring Challenger will refuse to interact with any games if it doesn't have the matching prestate. - ### Execute Challenger + ### Execute challenger The final step is to execute challenger with the required flags. It will look something like this (but with required flags added): @@ -193,9 +193,9 @@ This guide provides a walkthrough of setting up the configuration and monitoring --hd-path "m/44'/60'/0'/0/8" \ ``` - ### Test and Debug Challenger (Optional) + ### Test and debug challenger (optional) - This is an optional step to use `op-challenger` subcommands, which allow chain operators to interact with the fault proof system onchain for testing and debugging purposes. For example, it is possible to test and explore the system in the following ways: + This is an optional step to use `op-challenger` subcommands, which allow chain operators to interact with the Fault Proof System onchain for testing and debugging purposes. For example, it is possible to test and explore the system in the following ways: * create games yourself, and it doesn't matter if the games are valid or invalid. * perform moves in games and then claim and resolve things. @@ -212,12 +212,12 @@ This guide provides a walkthrough of setting up the configuration and monitoring | `resolve` | Resolves the specified dispute game if possible | | `resolve-claim` | Resolves the specified claim if possible | - Additionally, chain operators should consider running `op-dispute-mon`. It's an incredibly useful securities monitoring service to keep an eye on games, basically giving chain operators visibility into all the status of the games for the last 28 days. + Additionally, chain operators should consider running `op-dispute-mon`. It's an incredibly useful security monitoring service to keep an eye on games, basically giving chain operators visibility into all the status of the games for the last 28 days. Chain operators can easily create their grafana dashboard for Dispute Monitor using the following json file: [Download the Dispute Monitor JSON](/resources/grafana/dispute-monitor-1718214549035.json). -## Next Steps +## Next steps -* Additional questions? See the FAQ section in the [OP Challenger Explainer](/stack/protocol/fault-proofs/challenger). +* Additional questions? See the FAQ section in the [OP Challenger Explainer](/stack/fault-proofs/challenger). * For more detailed info on `op-challenger`, see the [specs](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html). * If you experience any problems, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/builders/chain-operators/tools/op-conductor.mdx b/pages/builders/chain-operators/tools/op-conductor.mdx index 6d4d6cff0..8dc4b6695 100644 --- a/pages/builders/chain-operators/tools/op-conductor.mdx +++ b/pages/builders/chain-operators/tools/op-conductor.mdx @@ -12,7 +12,7 @@ This page will teach you what the `op-conductor` service is and how it works on a high level. It will also get you started on setting it up in your own environment. -## Enhancing Sequencer Reliability and Availability +## Enhancing sequencer reliability and availability The [op-conductor](https://github.com/ethereum-optimism/optimism/tree/develop/op-conductor) is an auxiliary service designed to enhance the reliability and availability of @@ -26,7 +26,7 @@ It is important to note that the `op-conductor` does not incorporate Byzantine fault tolerance (BFT). This means the system operates under the assumption that all participating nodes are honest and act correctly. -### Summary of Guarantees +### Summary of guarantees The design of the `op-conductor` provides the following guarantees: @@ -40,14 +40,14 @@ The design of the `op-conductor` provides the following guarantees: **On a high level, `op-conductor` serves the following functions:** -### Raft Consensus Layer Participation +### Raft consensus layer participation -* **Leader Determination:** Participates in the Raft consensus algorithm to +* **Leader determination:** Participates in the Raft consensus algorithm to determine the leader among sequencers. -* **State Management:** Stores the latest unsafe block ensuring consistency +* **State management:** Stores the latest unsafe block ensuring consistency across the system. -### RPC Request Handling +### RPC request handling * **Admin RPC:** Provides administrative RPCs for manual recovery scenarios, including, but not limited to: stopping the leadership vote and removing itself @@ -55,18 +55,18 @@ The design of the `op-conductor` provides the following guarantees: * **Health RPC:** Offers health RPCs for the `op-node` to determine whether it should allow the publishing of transactions and unsafe blocks. -### Sequencer Health Monitoring +### Sequencer health monitoring * Continuously monitors the health of the sequencer (op-node) to ensure optimal performance and reliability. -### Control Loop Management +### Control loop management * Implements a control loop to manage the status of the sequencer (op-node), including starting and stopping operations based on different scenarios and health checks. -## Conductor State Transition +## Conductor state transition The following is a state machine diagram of how the op-conductor manages the sequencers Raft consensus. @@ -84,6 +84,8 @@ At OP Labs, op-conductor is deployed as a kubernetes statefulset because it requires a persistent volume to store the raft log. This guide describes setting up conductor on an existing network without incurring downtime. +You can utilize the [op-conductor-ops](https://github.com/ethereum-optimism/infra/tree/main/op-conductor-ops) tool to confirm the conductor status between the steps. + ### Assumptions This setup guide has the following assumptions: @@ -138,7 +140,7 @@ This setup guide has the following assumptions: {

Pause two conductors

} - Pause `sequencer-0` &` sequencer-1` conductors with [conductor\_pause](#conductor_pause) + Pause `sequencer-0` &` sequencer-2` conductors with [conductor_pause](#conductor_pause) RPC request. {

Update op-node configuration and switch the active sequencer

} @@ -150,8 +152,8 @@ This setup guide has the following assumptions: * all sequencer op-node configs: ```yaml - OP_NODE_CONDUCTOR_ENABLED: "true" - OP_NODE_RPC_ADMIN_STATE: "" # this flag cant be used with conductor + OP_NODE_CONDUCTOR_ENABLED: "true" # this is what commits unsafe blocks to the raft logs + OP_NODE_RPC_ADMIN_STATE: "" # this flag can't be used with conductor ``` {

Confirm sequencer switch was successful

} @@ -162,7 +164,7 @@ This setup guide has the following assumptions: {

Add voting nodes

} - Add voting nodes to cluster using [conductor\_AddServerAsVoter](#conductor_addServerAsVoter) + Add voting nodes to cluster using [conductor_AddServerAsVoter](#conductor_addserverasvoter) RPC request to the leader conductor (`sequencer-1`) {

Confirm state

} @@ -188,11 +190,11 @@ This setup guide has the following assumptions: {

Confirm state

} - Confirm all conductors successfully resumed with [conductor\_paused](#conductor_paused) + Confirm all conductors successfully resumed with [conductor_paused](#conductor_paused) - {

Tranfer leadership

} + {

Transfer leadership

} - Trigger leadership transfer to `sequencer-0` using [conductor\_transferLeaderToServer](#conductor_transferLeaderToServer) + Trigger leadership transfer to `sequencer-0` using [conductor_transferLeaderToServer](#conductor_transferleadertoserver) {

Confirm state

} @@ -214,7 +216,7 @@ This setup guide has the following assumptions: `OP_CONDUCTOR_PAUSED: true` flag and `OP_CONDUCTOR_RAFT_BOOTSTRAP` flag. -#### Blue/Green Deployment +#### Blue/green deployment In order to ensure there is no downtime when setting up conductor, you need to have a deployment script that can update sequencers without network downtime. @@ -238,7 +240,7 @@ An example of this workflow might look like: 5. Deploy the change to the original sequencer, wait for it to sync to the chain head. Execute health checks. -#### Post-Conductor Launch Deployments +#### Post-conductor launch deployments After conductor is live, a similar canary style workflow is used to ensure minimal downtime in case there is an issue with deployment: @@ -252,7 +254,7 @@ minimal downtime in case there is an issue with deployment: 1. If not, then there is likely an issue with the deployment. Roll back. 5. Upgrade the remaining sequencers, run healthchecks. -### Configuration Options +### Configuration options It is configured via its [flags / environment variables](https://github.com/ethereum-optimism/optimism/blob/develop/op-conductor/flags/flags.go) @@ -357,7 +359,7 @@ It is configured via its [flags / environment variables](https://github.com/ethe Conductor exposes [admin RPCs](https://github.com/ethereum-optimism/optimism/blob/develop/op-conductor/rpc/api.go#L17) on the `conductor` namespace. -#### conductor\_overrideLeader +#### conductor_overrideLeader `OverrideLeader` is used to override the leader status, this is only used to return true for `Leader()` & `LeaderWithID()` calls. It does not impact the @@ -382,7 +384,7 @@ manually started sequencer. -#### conductor\_pause +#### conductor_pause `Pause` pauses op-conductor. @@ -402,7 +404,7 @@ manually started sequencer. -#### conductor\_resume +#### conductor_resume `Resume` resumes op-conductor. @@ -422,7 +424,7 @@ manually started sequencer. -#### conductor\_paused +#### conductor_paused Paused returns true if the op-conductor is paused. @@ -442,7 +444,7 @@ Paused returns true if the op-conductor is paused. -#### conductor\_stopped +#### conductor_stopped Stopped returns true if the op-conductor is stopped. @@ -482,7 +484,7 @@ SequencerHealthy returns true if the sequencer is healthy. -#### conductor\_leader +#### conductor_leader API related to consensus. @@ -506,7 +508,7 @@ Leader returns true if the server is the leader. -#### conductor\_leaderWithID +#### conductor_leaderWithID API related to consensus. @@ -530,13 +532,13 @@ LeaderWithID returns the current leader's server info. -#### conductor\_addServerAsVoter +#### conductor_addServerAsVoter - API related to consensus. + API related to consensus. The address parameter is the raft consensus address, not the RPC address. -AddServerAsVoter adds a server as a voter to the cluster. +AddServerAsVoter adds a server as a voter to the cluster. @@ -549,12 +551,12 @@ AddServerAsVoter adds a server as a voter to the cluster. ```sh - cast rpc conductor_addServerAsVoter --rpc-url http://127.0.0.1:50050 + cast rpc conductor_addServerAsVoter --rpc-url http://127.0.0.1:50050 ``` -#### conductor\_addServerAsNonvoter +#### conductor_addServerAsNonvoter API related to consensus. @@ -579,7 +581,7 @@ The non-voter will not participate in the leader election. -#### conductor\_removeServer +#### conductor_removeServer API related to consensus. @@ -603,7 +605,7 @@ RemoveServer removes a server from the cluster. -#### conductor\_transferLeader +#### conductor_transferLeader API related to consensus. @@ -627,7 +629,7 @@ TransferLeader transfers leadership to another server. -#### conductor\_transferLeaderToServer +#### conductor_transferLeaderToServer API related to consensus. @@ -651,7 +653,7 @@ TransferLeaderToServer transfers leadership to a specific server. -#### conductor\_clusterMembership +#### conductor_clusterMembership ClusterMembership returns the current cluster membership configuration. @@ -671,7 +673,7 @@ ClusterMembership returns the current cluster membership configuration. -#### conductor\_active +#### conductor_active API called by `op-node`. @@ -695,7 +697,7 @@ Active returns true if the op-conductor is active (not paused or stopped). -#### conductor\_commitUnsafePayload +#### conductor_commitUnsafePayload API called by `op-node`. @@ -720,8 +722,9 @@ layer. -## Next Steps +## Next steps * Checkout [op-conductor-mon](https://github.com/ethereum-optimism/infra): which monitors multiple op-conductor instances and provides a unified interface for reporting metrics. +* Get familiar with [op-conductor-ops](https://github.com/ethereum-optimism/infra/tree/main/op-conductor-ops)to interact with op-conductor. diff --git a/pages/builders/chain-operators/tools/op-deployer.mdx b/pages/builders/chain-operators/tools/op-deployer.mdx new file mode 100644 index 000000000..cd522696f --- /dev/null +++ b/pages/builders/chain-operators/tools/op-deployer.mdx @@ -0,0 +1,172 @@ +--- +title: Deployer +lang: en-US +tags: ["op-deployer","eng-platforms"] +description: Learn how op-deployer can simplify deploying a standard OP Stack Chain. +--- + +import {Callout, Steps} from 'nextra/components' + +# Deployer + +`op-deployer` simplifies the process of deploying the OP Stack. It works similarly to [Terraform](https://www.terraform.io). Like Terraform, you define a declarative config file called an "intent," then run a command to apply the intent to your chain. `op-deployer` will compare the state of your chain against the intent, and make whatever changes are necessary for them to match. In its current state, it is intended to deploy new standard chains that utilize the Superchain wide contracts. + +## Installation + +The recommended way to install `op-deployer` is to download the latest release from the monorepo's +[release page](https://github.com/ethereum-optimism/optimism/releases). To install a release, download the binary +for your platform then extract it somewhere on your `PATH`. The rest of this tutorial will assume that you have +installed `op-deployer` using this method. + +To alternatively install from source, follow the steps below. You will need to install the Go toolchain and `just` as prerequisites. + + + ### **Clone the monorepo**: + + Run the following command to clone the monorepo: + + ```bash + git clone https://github.com/ethereum-optimism/optimism.git + ``` + + ### **Build the binary**: + + Run the following commands to build the binary: + + ```bash + cd op-deployer + just build + ``` + + The binary will be in the `bin` directory. + + +## Deployment usage + +The base use case for `op-deployer` is deploying new OP Chains. This process is broken down into three steps: + + + +### `init`: configure your chain + +To get started with `op-deployer`, create an intent file that defines your desired chain configuration. Use the built-in `op-deployer` utility to generate this file: + +``` +./bin/op-deployer init --l1-chain-id 11155111 --l2-chain-ids --workdir .deployer +``` + +This command will create a directory called `.deployer` in your current working directory containing the intent file and an empty `state.json` file. `state.json` is populated with the results of your deployment, and never needs to be edited directly. + +Your intent file will need to be modified to your parameters, but it will initially look something like this: + + + Do not use the default addresses in the intent for a production chain! They are generated from the `test... junk` + mnemonic. **Any funds they hold will be stolen on a live chain.** + + + +```toml +deploymentStrategy = "live" # Deploying a chain to a live network i.e. Sepolia +l1ChainID = 11155111 # The chain ID of the L1 chain you'll be deploying to +fundDevAccounts = true # Whether or not to fund dev accounts using the test... junk mnemonic on L2. +l1ContractsLocator = "tag://op-contracts/v1.6.0" # L1 smart contracts versions +l2ContractsLocator = "tag://op-contracts/v1.7.0-beta.1+l2-contracts" # L2 smart contracts versions + +# Delete this table if you are using the shared Superchain contracts on the L1 +# If you are deploying your own SuperchainConfig and ProtocolVersions contracts, fill in these details +[superchainRoles] + proxyAdminOwner = "0xb9cdf788704088a4c0191d045c151fcbe2db14a4" + protocolVersionsOwner = "0x85d646ed26c3f46400ede51236d8d7528196849b" + guardian = "0x8c7e4a51acb17719d225bd17598b8a94b46c8767" + +# List of L2s to deploy. op-deployer can deploy multiple L2s at once +[[chains]] + # Your chain's ID, encoded as a 32-byte hex string + id = "0x0000000000000000000000000000000000000000000000000000000000003039" + # Update the fee recipient contract + baseFeeVaultRecipient = "0x0000000000000000000000000000000000000000" + l1FeeVaultRecipient = "0x0000000000000000000000000000000000000000" + sequencerFeeVaultRecipient = "0x0000000000000000000000000000000000000000" + eip1559Denominator = 50 + eip1559Elasticity = 6 + # Various ownership roles for your chain. When you use op-deployer init, these roles are generated using the + # test... junk mnemonic. You should replace these with your own addresses for production chains. + [chains.roles] + l1ProxyAdminOwner = "0x1a66b55a4f0139c32eddf4f8c60463afc3832e76" + l2ProxyAdminOwner = "0x7759a8a43aa6a7ee9434ddb597beed64180c40fd" + systemConfigOwner = "0x8e35d9523a0c4c9ac537d254079c2398c6f3b35f" + unsafeBlockSigner = "0xbb19dce4ce51f353a98dbab31b5fa3bc80dc7769" + batcher = "0x0e9c62712ab826e06b16b2236ce542f711eaffaf" + proposer = "0x86dfafe0689e20685f7872e0cb264868454627bc" + challenger = "0xf1658da627dd0738c555f9572f658617511c49d5" + +``` + +By default, `op-deployer` will fill in all other configuration variables with those that match the [standard configuration](https://specs.optimism.io/protocol/configurability.html). You can override these default settings by adding them to your intent file using the table below: + +```toml +[globalDeployOverrides] + l2BlockTime = 1 # 1s L2blockTime is also standard, op-deployer defaults to 2s +``` + +You can also do chain by chain configurations in the `chains` table. + +### `apply`: deploy your chain + + + Hardware wallets are not supported, but you can use ephemeral hot wallets since this deployer key has no privileges. + + +Now that you've created your intent file, you can apply it to your chain to deploy the L1 smart contracts: + +``` +op-deployer apply --workdir .deployer --l1-rpc-url --private-key +``` + +This command will deploy the OP Stack to L1. It will deploy all L2s specified in the intent file. Superchain +configuration will be set to the Superchain-wide defaults - i.e., your chain will be opted into the [Superchain pause](https://specs.optimism.io/protocol/superchain-configuration.html#pausability) +and will use the same [protocol versions](https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/superchain-upgrades.md) +address as other chains on the Superchain. + +### `inspect`: generate genesis files and chain information + + + To add your chain to the [Superchain Registry](https://github.com/ethereum-optimism/superchain-registry) you will need to provide the chain artifacts. To get these chain artifacts, you will need to write the output of these commands to new files. + + +Inspect the `state.json` file by navigating to your working directory. With the contracts deployed, generate the genesis and rollup configuration files by running the following commands:" + +``` +cd .deployer +op-deployer inspect genesis --workdir .deployer > genesis.json +op-deployer inspect rollup --workdir .deployer > rollup.json +``` + +Now that you have your `genesis.json` and `rollup.json` you can spin up a node on your network. You can also use the following inspect subcommands to get additional data: + +``` +op-deployer inspect l1 --workdir .deployer # outputs all L1 contract addresses for an L2 chain +op-deployer inspect deploy-config --workdir .deployer # outputs the deploy config for an L2 chain +op-deployer inspect l2-semvers --workdir .deployer # outputs the semvers for all L2 chains +``` + + +## Bootstrap usage + +You can also use `op-deployer` to deploy the contracts needed to run the `init`... `apply` flow on new chains. This process, called 'bootstrapping,' is useful when you want to use `op-deployer` with L3s, new testnets, or other custom settlement chains. + +### OPCM bootstrap + +To deploy OPCM to a new chain, run the following command: + +```bash +op-deployer bootstrap opcm \ + --l1-rpc-url \ + --private-key \ + --artifacts-locator tag://op-contracts/v1.6.0 +``` + +## Next steps + +* For more details, check out the tool and documentation in the [op-deployer repository](https://github.com/ethereum-optimism/optimism/tree/develop/op-deployer/cmd/op-deployer). +* For more information on OP Contracts Manager, refer to the [OPCM documentation](/stack/opcm). diff --git a/pages/builders/chain-operators/tools/op-txproxy.mdx b/pages/builders/chain-operators/tools/op-txproxy.mdx new file mode 100644 index 000000000..83f7c7a97 --- /dev/null +++ b/pages/builders/chain-operators/tools/op-txproxy.mdx @@ -0,0 +1,86 @@ +--- +title: op-txproxy +lang: en-US +description: A passthrough proxy service that can apply additional constraints on transactions prior to reaching the sequencer. +--- + +import { Callout, Steps } from 'nextra/components' + +# op-txproxy + +A [passthrough proxy](https://github.com/ethereum-optimism/infra/tree/main/op-txproxy) for the execution engine endpoint. This proxy does not forward all RPC traffic and only exposes a specific set of methods. Operationally, the ingress router should only re-route requests for these specific methods. + + + [proxyd](./proxyd) as an ingress router supports the mapping of specific methods to unique backends. + +## Methods + +### **eth_sendRawTransactionConditional** + +To safely expose this endpoint publicly, additional stateless constraints are applied. These constraints help scale validation rules horizontally and preemptively reject conditional transactions before they reach the sequencer. + +Various metrics are emitted to guide necessary adjustments. +#### Runtime shutoff + +This service can be configured with a flag or environment variable to reject conditional transactions without needing to interrupt the execution engine. This feature is useful for diagnosing issues. + +`--sendRawTxConditional.enabled (default: true) ($OP_TXPROXY_SENDRAWTXCONDITIONAL_ENABLED)` + +When disabled, requests will fail with the `-32003` (transaction rejected) json rpc error code with a message stating that the method is disabled. +#### Rate limits + +Even though the op-geth implementation of this endpoint includes rate limits, it is instead applied here to terminate these requests early. + +`--sendRawTxConditional.ratelimit (default: 5000) ($OP_TXPROXY_SENDRAWTXCONDITIONAL_RATELIMIT)` + +#### Stateless validation + +* Conditional cost is below the max +* Conditional values are valid (i.e min \< max) +* Transaction target are only 4337 Entrypoint contracts + + + The motivating factor for this endpoint is to enable permissionless 4337 mempools, hence the restricted usage of this methods to just [Entrypoint](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/core/EntryPoint.sol) transactions. + + Please open up an issue if you'd like this restriction to be optional via configuration to broaden usage of this endpoint. + + +When the request passes validation, it is passed through to the configured backend URL + +`--sendRawTxConditional.backend ($OP_TXPROXY_SENDRAWTXCONDITIONAL_BACKENDS)` + + + Per the [specification](/stack/features/send-raw-transaction-conditional), conditional transactions are not gossiped between peers. Thus, if you use replicas in an active/passive sequencer setup, this request must be broadcasted to all replicas. + + [proxyd](./proxyd) as an egress router for this method supports this broadcasting functionality. + + +## How it works + +To start using `op-txproxy`, follow these steps: + + + ### Build the binary or pull the Docker image + + 1. Run the following command to build the binary + ```bash + make build + ``` + 2. This will build and output the binary under `/bin/op-txproxy`. + + The image for this binary is also available as a [docker artifact](https://us-docker.pkg.dev/oplabs-tools-artifacts/images/op-txproxy). + + ### Configure + + The binary accepts configuration through CLI flags, which also settable via environment variables. Either set the flags explicitly when starting the binary or set the environment variables of the host starting the proxy. + + See [methods](#methods) on the configuration options available for each method. + + ### Start + + start the service with the following command + + ```bash + op-txproxy // ... with flags if env variables are not set + ``` + diff --git a/pages/stack/operators/features/proxyd.mdx b/pages/builders/chain-operators/tools/proxyd.mdx similarity index 94% rename from pages/stack/operators/features/proxyd.mdx rename to pages/builders/chain-operators/tools/proxyd.mdx index 51476b581..e2b7cf6ef 100644 --- a/pages/stack/operators/features/proxyd.mdx +++ b/pages/builders/chain-operators/tools/proxyd.mdx @@ -10,8 +10,7 @@ import { Steps } from 'nextra/components' `proxyd` is an important RPC request router and proxy used within the OP Stack infrastructure. It enables operators to efficiently route and manage RPC requests across multiple backend services, ensuring performance, fault tolerance, and security. -## Key Features - +## Key features * RPC method whitelisting * Backend request routing * Automatic retries for failed backend requests @@ -26,7 +25,7 @@ import { Steps } from 'nextra/components' To start using `proxyd`, follow these steps: - ### **Build the Binary**: + ### **Build the binary**: * Run the following command to build the `proxyd` binary: ```bash @@ -39,7 +38,7 @@ To start using `proxyd`, follow these steps: * Create a configuration file to define your proxy backends and routing rules. * Refer to [example.config.toml](https://github.com/ethereum-optimism/infra/blob/main/proxyd/example.config.toml) for a full list of options with commentary. - ### **Start the Service**: + ### **Start the service**: Once the configuration file is ready, start the `proxyd` service using the following command: @@ -48,7 +47,7 @@ To start using `proxyd`, follow these steps: ``` -## Consensus Awareness +## Consensus awareness Version 4.0.0 and later include consensus awareness to minimize chain reorganizations. @@ -58,9 +57,9 @@ Set `consensus_aware` to `true` in the configuration to enable: * Resolving consensus groups based on healthiest backends * Enforcing consensus state across client requests -## Caching and Metrics +## Caching and metrics -### Cacheable Methods +### Cacheable methods Certain immutable methods, such as `eth_chainId` and `eth_getBlockByHash`, can be cached using Redis to optimize performance. @@ -68,7 +67,7 @@ Certain immutable methods, such as `eth_chainId` and `eth_getBlockByHash`, can b Extensive metrics are available to monitor request latency, error rates, backend health, and more. These can be configured via `metrics.port` and `metrics.host` in the configuration file. -## Next Steps +## Next steps * Read about the [OP Stack chain architecture](/builders/chain-operators/architecture). * Find out how you can support [snap sync](/builders/chain-operators/management/snap-sync). diff --git a/pages/builders/chain-operators/tutorials.mdx b/pages/builders/chain-operators/tutorials.mdx new file mode 100644 index 000000000..6b2387f7a --- /dev/null +++ b/pages/builders/chain-operators/tutorials.mdx @@ -0,0 +1,27 @@ +--- +title: Tutorials +lang: en-US +description: >- + Learn about tutorials in the Optimism ecosystem. This guide provides detailed + information and resources about tutorials. +--- + +import { Card, Cards } from 'nextra/components' + +# Tutorials + +This section provides information on adding attributes to the derivation function, adding a precompile, creating your own l2 rollup testnet, integrating a new da layer with alt da, modifying predeployed contracts and using viem. You'll find overview, tutorial, guide to help you understand and work with these topics. + + + + + + + + + + + + + + diff --git a/pages/builders/chain-operators/tutorials/adding-derivation-attributes.mdx b/pages/builders/chain-operators/tutorials/adding-derivation-attributes.mdx index d626282b8..1bb3c9864 100644 --- a/pages/builders/chain-operators/tutorials/adding-derivation-attributes.mdx +++ b/pages/builders/chain-operators/tutorials/adding-derivation-attributes.mdx @@ -1,12 +1,12 @@ --- -title: Adding Attributes to the Derivation Function +title: Adding attributes to the derivation function lang: en-US description: Learn how to modify the derivation function for an OP Stack chain to track the amount of ETH being burned on L1. --- import { Callout, Steps } from 'nextra/components' -# Adding Attributes to the Derivation Function +# Adding attributes to the derivation function OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. @@ -271,6 +271,6 @@ cast call "total()" | cast --from-wei ## Conclusion -With just a few tiny changes to the `op-node`, you were just able to implement a change to the OP Stack that allows you to keep track of the L1 ETH burn on L2. With a live Cannon fault proof system, you should not only be able to track the L1 burn on L2, you should be able to *prove* the burn to contracts back on L1. That's crazy! +With just a few tiny changes to the `op-node`, you were just able to implement a change to the OP Stack that allows you to keep track of the L1 ETH burn on L2. With a live Cannon Fault Proof System, you should not only be able to track the L1 burn on L2, you should be able to *prove* the burn to contracts back on L1. That's crazy! The OP Stack is an extremely powerful platform that allows you to perform a large amount of computation trustlessly. It's a superpower for smart contracts. Tracking the L1 burn is just one of the many, many wild things you can do with the OP Stack. If you're looking for inspiration or you want to see what others are building on the OP Stack, check out the OP Stack Hacks page. Maybe you'll find a project you want to work on, or maybe you'll get the inspiration you need to build the next killer smart contract. diff --git a/pages/builders/chain-operators/tutorials/adding-precompiles.mdx b/pages/builders/chain-operators/tutorials/adding-precompiles.mdx index c1f328d0b..98b352c73 100644 --- a/pages/builders/chain-operators/tutorials/adding-precompiles.mdx +++ b/pages/builders/chain-operators/tutorials/adding-precompiles.mdx @@ -1,12 +1,12 @@ --- -title: Adding a Precompile +title: Adding a precompile lang: en-US description: Learn how to run an EVM with a new precompile for OP Stack chain operations to speed up calculations that are not currently supported. --- import { Callout, Steps } from 'nextra/components' -# Adding a Precompile +# Adding a precompile OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. @@ -88,7 +88,7 @@ It means that for every precompile you need two functions: * `RequiredGas` which returns the gas cost for the call. This function takes an array of bytes as input, and returns a single value, the gas cost. * `Run` which runs the actual precompile. This function also takes an array of bytes, but it returns two values: the call's output (a byte array) and an error. -For every fork that changes the precompiles you have a [`map`](https://www.w3schools.com/go/go_maps.php)from addresses to the `PrecompiledContract` definitions: +For every fork that changes the precompiles you have a [`map`](https://www.w3schools.com/go/go_maps.php) from addresses to the `PrecompiledContract` definitions: ```go // PrecompiledContractsBerlin contains the default set of pre-compiled Ethereum diff --git a/pages/builders/chain-operators/tutorials/integrating-da-layer.mdx b/pages/builders/chain-operators/tutorials/integrating-da-layer.mdx index a1dbc7c99..8627d4385 100644 --- a/pages/builders/chain-operators/tutorials/integrating-da-layer.mdx +++ b/pages/builders/chain-operators/tutorials/integrating-da-layer.mdx @@ -1,21 +1,21 @@ --- -title: Integrating a New DA Layer with Alt-DA +title: Integrating a new DA layer with Alt-DA lang: en-US description: Learn how to add support for a new DA Layer within the OP Stack. --- import { Callout, Steps } from 'nextra/components' -# Integrating a New DA Layer with Alt-DA +# Integrating a new DA layer with Alt-DA The Alt-DA Mode feature is currently in Beta within the MIT-licensed OP Stack. Beta features are built and reviewed by Optimism Collective core contributors, and provide developers with early access to highly requested configurations. These features may experience stability issues, and we encourage feedback from our early users. -[Alt-DA Mode](/stack/protocol/features/alt-da-mode) enables seamless integration of any DA Layer, regardless of their commitment type, into the OP Stack. After a DA Server is built for a DA Layer, any chain operator can launch an OP Stack chain using that DA Layer for sustainably low costs. +[Alt-DA Mode](/stack/beta-features/alt-da-mode) enables seamless integration of any DA Layer, regardless of their commitment type, into the OP Stack. After a DA Server is built for a DA Layer, any chain operator can launch an OP Stack chain using that DA Layer for sustainably low costs. -## Build Your DA Server +## Build your DA server Our suggestion is for every DA Layer to build and maintain their own DA Server, with support from the OP Labs team along the way. The DA Server will need to be run by every node operator, so we highly recommend making your DA Server open source and MIT licensed. @@ -33,7 +33,7 @@ Our suggestion is for every DA Layer to build and maintain their own DA Server, * Claim your [byte](https://github.com/ethereum-optimism/specs/discussions/135) - ### Implement the DA Server + ### Implement the DA server * Write a simple HTTP server which supports `get` and `put` * `put` is used by the batcher and can return the commitment to the batcher in the body. It should not return until the data is known to be submitted to your DA layer. @@ -44,6 +44,6 @@ Our suggestion is for every DA Layer to build and maintain their own DA Server, ## Run Alt-DA Follow our guide on [how to operate an Alt-DA Mode chain](/builders/chain-operators/features/alt-da-mode), except instead of using the S3 DA server, use the DA server that you built. -## Next Steps +## Next steps * For more detail on implementing the DA Server, [see the specification](https://specs.optimism.io/experimental/alt-da.html#da-server). diff --git a/pages/builders/chain-operators/tutorials/modifying-predeploys.mdx b/pages/builders/chain-operators/tutorials/modifying-predeploys.mdx index ac77fb5a4..4391673c0 100644 --- a/pages/builders/chain-operators/tutorials/modifying-predeploys.mdx +++ b/pages/builders/chain-operators/tutorials/modifying-predeploys.mdx @@ -1,12 +1,12 @@ --- -title: Modifying Predeployed Contracts +title: Modifying predeployed contracts lang: en-US description: Learn how to modify predeployed contracts for an OP Stack chain by upgrading the proxy. --- import { Callout, Steps } from 'nextra/components' -# Modifying Predeployed Contracts +# Modifying predeployed contracts OP Stack Hacks are explicitly things that you can do with the OP Stack that are *not* currently intended for production use. @@ -17,13 +17,13 @@ import { Callout, Steps } from 'nextra/components' OP Stack blockchains have a number of [predeployed contracts](https://github.com/ethereum-optimism/optimism/blob/129032f15b76b0d2a940443a39433de931a97a44/packages/contracts-bedrock/src/constants.ts) that provide important functionality. Most of those contracts are proxies that can be upgraded using the `proxyAdminOwner` which was configured when the network was initially deployed. -## Before You Begin +## Before you begin In this tutorial, you learn how to modify predeployed contracts for an OP Stack chain by upgrading the proxy. The predeploys are controlled from a predeploy called [`ProxyAdmin`](https://github.com/ethereum-optimism/optimism/blob/129032f15b76b0d2a940443a39433de931a97a44/packages/contracts-bedrock/contracts/universal/ProxyAdmin.sol), whose address is `0x4200000000000000000000000000000000000018`. The function to call is [`upgrade(address,address)`](https://github.com/ethereum-optimism/optimism/blob/129032f15b76b0d2a940443a39433de931a97a44/packages/contracts-bedrock/contracts/universal/ProxyAdmin.sol#L205-L229). The first parameter is the proxy to upgrade, and the second is the address of a new implementation. -## Modify the Legacy `L1BlockNumber` contract +## Modify the legacy `L1BlockNumber` contract For example, the legacy `L1BlockNumber` contract is at `0x420...013`. To disable this function, we'll set the implementation to `0x00...00`. diff --git a/pages/builders/chain-operators/tutorials/sdk.mdx b/pages/builders/chain-operators/tutorials/sdk.mdx deleted file mode 100644 index cbd660442..000000000 --- a/pages/builders/chain-operators/tutorials/sdk.mdx +++ /dev/null @@ -1,161 +0,0 @@ ---- -title: Using the Optimism SDK -lang: en-US -description: Learn how to use the Optimism SDK to interact with your OP Stack chain. ---- - -import { Callout, Steps } from 'nextra/components' -import { WipCallout } from '@/components/WipCallout' - - -# Using the Optimism SDK - - - -This tutorial will walk you through the process of using the [Optimism SDK](https://sdk.optimism.io) to interact with your OP Stack chain. -The Optimism SDK **natively** supports various OP Chains including OP Mainnet and Base. -To check whether your OP Chain is already supported, [see the Optimism SDK docs](https://sdk.optimism.io/enums/l2chainid). - - -You will need to already have created your own OP Stack chain to follow this tutorial. -Check out the tutorial on [Creating Your Own L2 Rollup Testnet](./create-l2-rollup) if you haven't done so already. - - -## Dependencies - -* [node](https://nodejs.org/en/) -* [pnpm](https://pnpm.io/installation) -* [jq](https://github.com/jqlang/jq) - -## Find Contract Addresses - -You will need to find the addresses for a number of smart contracts that are part of your OP Stack chain in order to use the Optimism SDK. -If you followed the instructions in the [Creating Your Own L2 Rollup Testnet](./create-l2-rollup) tutorial, you can find the addresses by looking at the JSON artifacts within the directory `optimism/packages/contracts-bedrock/deployments/getting-started`. - -Simply run the following command from inside the directory `optimism/packages/contracts-bedrock` to print the list of addresses you'll need: - -```bash -./scripts/print-addresses.sh getting-started --sdk -``` - - -Make sure you have [`jq`](https://github.com/jqlang/jq) installed when running this command. - - -You should see output similar to the following: - -```text -AddressManager: 0x... -L1CrossDomainMessengerProxy: 0x... -L1StandardBridgeProxy: 0x... -L2OutputOracleProxy: 0x... -OptimismPortalProxy: 0x... -``` - -Save these addresses somewhere so you can use them in the next section. - -## Create a Demo Project - -You're going to use the Optimism SDK for this tutorial. -Since the Optimism SDK is a [Node.js](https://nodejs.org/en/) library, you'll need to create a Node.js project to use it. - - - -{

Make a Project Folder

} - -```bash -mkdir op-sdk-sample-project -cd op-sdk-sample-project -``` - -{

Initialize the Project

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

Install the Optimism SDK

} - -```bash -pnpm add @eth-optimism/sdk -``` - -{

Install ethers.js

} - -```bash -pnpm add ethers@^5 -``` - - - -## Start the Node REPL - -You're going to use the Node REPL to interact with the Optimism SDK. -To start the Node REPL run the following command in your terminal: - -```bash -node -``` - -This will bring up a Node REPL prompt that allows you to run javascript code. - -## Import Dependencies - -You need to import some dependencies into your Node REPL session. - - - -{

Import the Optimism SDK

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

Import ethers.js

} - -```js file=/public/tutorials/sdk-stack.js#L4 hash=69a65ef97862612e4978b8563e6dbe3a -``` - - - -## Set Session Variables - -You'll need a few variables throughout this tutorial. -Let's set those up now. - - - -{

Create the RPC providers

} - -```js file=/public/tutorials/sdk-stack.js#L6-L7 hash=53fc69364fffe9faa00ab558446cbe13 -``` - -{

Set the contract addresses

} - -Using the addresses you accessed earlier, set the contract addresses in the following variables: - -```js file=/public/tutorials/sdk-stack.js#L9-L13 hash=c32c35e3e6eebb1b3c9c68dece1cb93f -``` - -{

Set the chain IDs

} - -```js file=/public/tutorials/sdk-stack.js#L15-L16 hash=f33189a08efe81f43a03bbc4a6812a1a -``` - - - -## Initialize the Optimism SDK - -You can now create an instance of the `CrossChainMessenger` object from the Optimism SDK. -This will allow you to easily handle cross-domain messages between L1 and L2. - -Simply create the object: - -```js file=/public/tutorials/sdk-stack.js#L18-L39 hash=216bd2437a5893704acfad2c768b9544 -``` - -Note that you've passed in the RPC providers you created earlier, the addresses of the smart contracts you deployed, and the chain ID of your OP Stack chain. - -## Next Steps - -You can now use the SDK to interact with your OP Stack chain just like you would with other chains like OP Mainnet. -See existing tutorials, like the tutorial on [Bridging ETH With the Optimism SDK](/builders/app-developers/tutorials/cross-dom-bridge-eth) or [Bridging ERC-20 Tokens With the Optimism SDK](/builders/app-developers/tutorials/cross-dom-bridge-erc20), for examples of how to use the Optimism SDK. diff --git a/pages/builders/node-operators.mdx b/pages/builders/node-operators.mdx new file mode 100644 index 000000000..537743b2f --- /dev/null +++ b/pages/builders/node-operators.mdx @@ -0,0 +1,29 @@ +--- +title: Node Operators +description: Documentation covering Architecture, Configuration, Json Rpc, Management, Network Upgrades, Releases, Rollup Node, Tutorials in the Node Operators section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Node Operators + +Documentation covering Architecture, Configuration, Json Rpc, Management, Network Upgrades, Releases, Rollup Node, Tutorials in the Node Operators section of the OP Stack ecosystem. + + + + + + + + + + + + + + + + + + diff --git a/pages/builders/node-operators/_meta.json b/pages/builders/node-operators/_meta.json index 07df62fb7..818311233 100644 --- a/pages/builders/node-operators/_meta.json +++ b/pages/builders/node-operators/_meta.json @@ -1,10 +1,10 @@ { "architecture": "Architecture", - "rollup-node": "Run a Node in the Superchain", + "rollup-node": "Run a node in the Superchain", "tutorials": "Tutorials", "configuration": "Configuration", - "management": "Node Management", - "network-upgrades": "Network Upgrades", + "management": "Node management", + "network-upgrades": "Network upgrades", "json-rpc": "JSON-RPC API", - "releases": "Software Releases" + "releases": "Software releases" } diff --git a/pages/builders/node-operators/architecture.mdx b/pages/builders/node-operators/architecture.mdx index 5ba68808a..014f7b8dc 100644 --- a/pages/builders/node-operators/architecture.mdx +++ b/pages/builders/node-operators/architecture.mdx @@ -1,25 +1,25 @@ --- -title: Node Architecture +title: Node architecture lang: en-US description: Learn about node architecture. --- -# Node Architecture +# Node architecture This page reviews node architecture for all nodes running on the Superchain network. All OP Mainnet nodes are composed of two core software services, the Rollup Node and the Execution Client. OP Mainnet also optionally supports a third component, Legacy Geth, that can serve stateful queries for blocks and transactions created before the [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/). -## Node Flow Diagram +## Node flow diagram The following diagram shows how the Rollup Node, Execution Client, and Legacy Geth components work together to form a complete node running on the Superchain network. This diagram uses the `op-node` and `op-geth` implementations of the Rollup Node and Execution Client respectively, but the same architecture generally applies to other implementations as well. ![OP Mainnet node architecture diagram.](/img/guides/node-operators/node-arch.svg) -## Rollup Node +## Rollup node The Rollup Node is responsible for deriving L2 block payloads from L1 data and passing those payloads to the Execution Client. The Rollup Node can also optionally participate in a peer-to-peer network to receive blocks directly from the Sequencer before those blocks are submitted to L1. The Rollup Node is largely analogous to a [consensus client](https://ethereum.org/en/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) in Ethereum. -## Execution Client +## Execution client The Execution Client is responsible for executing the block payloads it receives from the Rollup Node over JSON-RPC via the standard [Ethereum Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md#engine-api----common-definitions). The Execution Client exposes the standard JSON-RPC API that Ethereum developers are familiar with, and can be used to query blockchain data and submit transactions to the network. @@ -35,7 +35,7 @@ Legacy Geth is the software that was used to run OP Mainnet nodes prior to the B If you run an instance of Legacy Geth alongside your OP Mainnet node, your node will be able to forward requests against historical transactions to the Legacy Geth instance. Legacy Geth is **not** required and is typically only necessary if you want to maintain a complete archive node for OP Mainnet. -## Next Steps +## Next steps * To get your node up and running, start with the [run a node from docker](/builders/node-operators/tutorials/node-from-docker) or [build a node from source](/builders/node-operators/tutorials/node-from-source) tutorial. * If you've already got your node up and running, check out the [Node Metrics and Monitoring Guide](./management/metrics) to learn how to keep tabs on your node and make sure it keeps running smoothly. diff --git a/pages/builders/node-operators/configuration.mdx b/pages/builders/node-operators/configuration.mdx new file mode 100644 index 000000000..da2c8f8a8 --- /dev/null +++ b/pages/builders/node-operators/configuration.mdx @@ -0,0 +1,21 @@ +--- +title: Configuration +lang: en-US +description: >- + Learn about configuration in the Optimism ecosystem. This guide provides + detailed information and resources about configuration. +--- + +import { Card, Cards } from 'nextra/components' + +# Configuration + +This section provides information on node base configuration, consensus layer configuration options (OP Node), and execution layer configuration options (OP Geth). You'll find information to help you understand and work with these topics. + + + + + + + + diff --git a/pages/builders/node-operators/configuration/_meta.json b/pages/builders/node-operators/configuration/_meta.json index f38d96dcd..8794a3782 100644 --- a/pages/builders/node-operators/configuration/_meta.json +++ b/pages/builders/node-operators/configuration/_meta.json @@ -1,5 +1,5 @@ { - "base-config": "Base Configuration", - "consensus-config": "Consensus Layer Configuration", - "execution-config": "Execution Layer Configuration" + "base-config": "Base configuration", + "consensus-config": "Consensus layer configuration", + "execution-config": "Execution layer configuration" } \ No newline at end of file diff --git a/pages/builders/node-operators/configuration/base-config.mdx b/pages/builders/node-operators/configuration/base-config.mdx index 69fab08ac..610fd7fe6 100644 --- a/pages/builders/node-operators/configuration/base-config.mdx +++ b/pages/builders/node-operators/configuration/base-config.mdx @@ -1,12 +1,12 @@ --- -title: Node Base Configuration +title: Node base configuration lang: en-US description: Learn the node base configuration and recommended flags for op-node, op-geth, and legacy geth. --- import { Callout } from 'nextra/components' -# Node Base Configuration +# Node base configuration Always run `op-node` and `op-geth` in a one-to-one configuration. Don't run multiple `op-geth` instances behind one `op-node`, or vice versa. @@ -37,14 +37,14 @@ Regardless of how `op-geth` is initialized, you'll need to ensure that you have ### Initialize `op-geth` Instructions for each initialization method are below. If you're spinning up an OP Mainnet, use the [Initialization via Data Directory](#initialization-via-data-directory) path. If you're spinning up an OP Sepolia node, use the [Initialization via Network Flags](#initialization-via-network-flags) path. -#### Initialization via Network Flags +#### Initialization via network flags To initialize `op-geth` with the network flags, you simply need to set the `--op-network=` and `--network=` on `op-node`. To see the latest support networks, you can consult the `--help` output for the `op-network` option. -#### Initialization via Genesis File +#### Initialization via genesis file `op-geth` uses JSON files to encode a network's genesis information. For networks that are initialized in this way, you'll receive a URL to the genesis @@ -65,7 +65,7 @@ else fi ``` -#### Initialization via Data Directory +#### Initialization via data directory To initialize `op-geth` with a preconfigured data directory, simply download and extract the data directory to a place of your choosing. The data directory is exported as a tar file. An example command to do this is below: @@ -96,7 +96,7 @@ Then, specify the following flags: * `--authrpc.port`: Sets the port `op-geth`'s authenticated RPC should listen on. The default value is `8551`. * `--authrpc.jwtsecret`: Sets the path to a JWT secret file you generated above. -### Recommended Flags for `op-geth` Configuration +### Recommended flags for `op-geth` configuration You may also want to specify the following flags based on your configuration: @@ -106,7 +106,7 @@ You may also want to specify the following flags based on your configuration: * `--ws`, `--ws.addr`, and `--ws.port`: Enables the WebSocket API. * `--verbosity`: Configures Geth's log level. This is a number between 0 and 5, with 5 being the most verbose. Defaults to 3. -### Working Base Configuration +### Working base configuration A valid command that runs `op-geth` and enables RPC over HTTP and WebSockets looks like: @@ -147,7 +147,7 @@ from a Beacon node. accidentally expose admin controls to the public internet. -### Working Base Configuration +### Working base configuration A minimal valid configuration that runs `op-node` looks like: @@ -167,7 +167,7 @@ You can manually specify a path to a rollup config with the `--rollup.config` fl Each of the above flags can also be defined via an environment variable. Run `op-node --help` to see a list of all available flags and environment variables. -### Configuring Peer-to-Peer Networking +### Configuring peer-to-peer networking Unlike the previous system, the `op-node` participates in a peer-to-peer network. This network is used to distribute blocks that have not been submitted to L1 yet. The `op-node` will automatically discover and connect to peers using a hardcoded set of bootnodes. You can also manually specify peers to connect to via the `--p2p.static` flag. @@ -201,7 +201,7 @@ As mentioned above, don't forget to specify `--rollup.historicalrpc` on `op-geth Since Legacy Geth is read-only, it is safe to run multiple Legacy Geth nodes behind a load balancer. -### Historical Execution vs. Historical Data Routing +### Historical execution vs. historical data routing Only requests for historical execution will be routed to Legacy Geth. Everything else will be served by `op-geth` directly. @@ -216,7 +216,7 @@ The term *historical execution* refers to RPC methods that need to execute trans If you do not need these RPC methods for historical data, then you do not need to run Legacy Geth at all. -## Next Steps +## Next steps * See the [op-node configuration](/builders/node-operators/configuration/consensus-config) guide for additional configuration options for `op-node` and the Consensus-Layer. * Similarly, visit the [op-geth configuration](/builders/node-operators/configuration/execution-config) guide for additional configuration options for `op-geth` and Execution-Layer. * If you run into any problems, please reach out to our [developer support forum](https://github.com/ethereum-optimism/developers/discussions) for help. diff --git a/pages/builders/node-operators/configuration/consensus-config.mdx b/pages/builders/node-operators/configuration/consensus-config.mdx index 38e720412..cac398c3f 100644 --- a/pages/builders/node-operators/configuration/consensus-config.mdx +++ b/pages/builders/node-operators/configuration/consensus-config.mdx @@ -1,5 +1,5 @@ --- -title: Consensus Layer Configuration Options (op-node) +title: Consensus layer configuration options (op-node) lang: en-US description: Learn additional configuration and command line options for op-node and the Consensus-Layer. --- @@ -7,7 +7,7 @@ description: Learn additional configuration and command line options for op-node import { Callout } from 'nextra/components' import { Tabs } from 'nextra/components' -# Consensus Layer Configuration Options (op-node) +# Consensus layer configuration options (op-node) You can configure your node using the command line options below (also called flags). @@ -17,7 +17,7 @@ import { Tabs } from 'nextra/components' This page list all configuration options for `op-node`. `op-node` implements most rollup-specific functionality as Consensus-Layer, similar to a L1 beacon-node. The following options are from the `--help` in [v1.7.5](https://github.com/ethereum-optimism/optimism/releases/tag/op-node/v1.7.5). -## Global Options +## Global options ### conductor.enabled @@ -239,7 +239,7 @@ The lowest log level that will be output. The default value is `info`. `OP_NODE_LOG_LEVEL=info` -### Node Log Levels +### Node log levels Node log levels determine the verbosity of log messages, allowing operators to filter messages based on importance and detail. The log levels for the `op-node` (used in Optimism) are as follows: @@ -360,6 +360,16 @@ Manually specify the fjord fork timestamp, overriding the bundled setting. The d `OP_NODE_OVERRIDE_FJORD=0` +### override.granite + +Manually specify the granite fork timestamp, overriding the bundled setting. The default value is `0`. + + + `--override.granite=` + `--override.granite=0` + `OP_NODE_OVERRIDE_GRANITE=0` + + ### p2p.advertise.ip The IP address to advertise in Discv5, put into the ENR of the node. This may also be a hostname/domain name to resolve to an IP. @@ -723,6 +733,16 @@ RPC listening port. Default is `9545`. `OP_NODE_RPC_PORT=9545` +### safedb.path + +File path used to persist safe head update data. Disabled if not set. + + + `--safedb.path=` + `--safedb.path=/db` + `SAFEDB_PATH=/db` + + ### sequencer.enabled Enable sequencing of new L2 blocks. A separate batch submitter has to be deployed to publish the data for verifiers. Default is `false`. diff --git a/pages/builders/node-operators/configuration/execution-config.mdx b/pages/builders/node-operators/configuration/execution-config.mdx index c4da902d9..d3d4bfc17 100644 --- a/pages/builders/node-operators/configuration/execution-config.mdx +++ b/pages/builders/node-operators/configuration/execution-config.mdx @@ -1,5 +1,5 @@ --- -title: Execution Layer Configuration Options (op-geth) +title: Execution layer configuration options (op-geth) lang: en-US description: Learn additional configuration and command line options for op-geth and the Execution-Layer. --- @@ -7,7 +7,7 @@ description: Learn additional configuration and command line options for op-geth import { Callout } from 'nextra/components' import { Tabs } from 'nextra/components' -# Execution Layer Configuration Options (op-geth) +# Execution layer configuration options (op-geth) You can configure your node using the command line options below (also called flags). @@ -19,7 +19,7 @@ The following are options from [v1.101308.0](https://github.com/ethereum-optimis Please note that the executable is still named `geth` to maintain a [minimal diff](https://op-geth.optimism.io/). -## Global Options +## Global options ### Account @@ -1603,7 +1603,7 @@ blocks, with `0` representing the entire chain. #### history.transactions Number of recent blocks to maintain transactions index for. -The default is about one year (`2350000` blocks), with `0` representing the entire chain. +The default is about two months (`2350000` blocks), with `0` representing the entire chain. `--history.transactions=` @@ -1783,7 +1783,7 @@ Time interval to regenerate the local transaction journal. The default value is `GETH_TXPOOL_REJOURNAL=1h0m0s` -### Virtual Machine +### Virtual machine #### vmdebug diff --git a/pages/builders/node-operators/json-rpc.mdx b/pages/builders/node-operators/json-rpc.mdx index c7d95b1b9..be9d30fee 100644 --- a/pages/builders/node-operators/json-rpc.mdx +++ b/pages/builders/node-operators/json-rpc.mdx @@ -973,13 +973,13 @@ TODO: add description ```sh curl -X POST -H "Content-Type: application/json" --data \ - '{"jsonrpc":"2.0","method":"admin_sequencerActive","params":[todo],"id":1}' \ + '{"jsonrpc":"2.0","method":"admin_sequencerActive","params":[],"id":1}' \ http://localhost:9545 ``` ```sh - cast rpc admin_sequencerActive [todo: add paramater options] --rpc-url http://localhost:9545 + cast rpc admin_sequencerActive [] --rpc-url http://localhost:9545 ``` diff --git a/pages/builders/node-operators/management.mdx b/pages/builders/node-operators/management.mdx new file mode 100644 index 000000000..428a4593d --- /dev/null +++ b/pages/builders/node-operators/management.mdx @@ -0,0 +1,25 @@ +--- +title: Management +lang: en-US +description: >- + Learn about management in the Optimism ecosystem. This guide provides detailed + information and resources about management. +--- + +import { Card, Cards } from 'nextra/components' + +# Management + +This section provides information on using blobs, node metrics and monitoring, snap sync for node operators, node snapshots, and troubleshooting. Users will find APIs, references, and guides to help understand and work with these topics. + + + + + + + + + + + + diff --git a/pages/builders/node-operators/management/_meta.json b/pages/builders/node-operators/management/_meta.json index f6278a6d8..1f68207f3 100644 --- a/pages/builders/node-operators/management/_meta.json +++ b/pages/builders/node-operators/management/_meta.json @@ -1,7 +1,7 @@ { - "blobs": "Using Blobs", + "blobs": "Using blobs", "snap-sync": "Using Snap Sync", - "snapshots": "Snapshot Downloads", + "snapshots": "Snapshot downloads", "metrics": "Monitoring", "troubleshooting": "Troubleshooting" } diff --git a/pages/builders/node-operators/management/blobs.mdx b/pages/builders/node-operators/management/blobs.mdx index 4f63e18db..5f738f79f 100644 --- a/pages/builders/node-operators/management/blobs.mdx +++ b/pages/builders/node-operators/management/blobs.mdx @@ -1,5 +1,5 @@ --- -title: Using Blobs +title: Using blobs lang: en-US description: Learn how to handle blobs for your node. --- @@ -7,7 +7,7 @@ description: Learn how to handle blobs for your node. import { Callout, Steps } from 'nextra/components' import { Tabs } from 'nextra/components' -# Using Blobs +# Using blobs The proposed Ecotone upgrade impacts node operators because of the new Beacon endpoint for `op-node`. Soon after the Ecotone activation, batch transactions @@ -15,7 +15,7 @@ will be sent as 4844 blobs, and blobs can only be retrieved from Beacon nodes. This means node operators will need access to a beacon node/consensus client (i.e. Lighthouse, Lodestar, Nimbus, Prysm, Teku, etc.). -## Preparing Your Node +## Preparing your node These steps are necessary for EVERY node operator: @@ -24,7 +24,7 @@ These steps are necessary for EVERY node operator: See the [Software Releases](/builders/node-operators/releases) page for the minimum release version. -### Configure the Ecotone Activation Date +### Configure the Ecotone activation date * If you are operating a node for an OP Chain that has an entry in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), the Ecotone activation date is part of the `op-node` and `op-geth` nodes. So, @@ -56,7 +56,7 @@ These will need to be set on `op-node` and `op-geth` for the sequencer and all o -### Prepare for Activation +### Prepare for activation * All node operators must set an L1 beacon value in your `op-node` as soon as you update to the latest release. @@ -69,7 +69,7 @@ These will need to be set on `op-node` and `op-geth` for the sequencer and all o -## Configure a Blob Archiver (Archive Nodes) +## Configure a blob archiver (archive nodes) There is a configurable `beacon-archiver` that will allow nodes to sync blob data that is older than 18 days - after blobs are 18 days old, normal beacon nodes will "prune" or remove them. If your node is already in sync with the head of the chain, you won't need to use a `beacon-archiver`. diff --git a/pages/builders/node-operators/management/metrics.mdx b/pages/builders/node-operators/management/metrics.mdx index 81a2fccc2..85fbebb2c 100644 --- a/pages/builders/node-operators/management/metrics.mdx +++ b/pages/builders/node-operators/management/metrics.mdx @@ -4,13 +4,13 @@ lang: en-US description: Learn about the different metrics you can use to monitor the health of your node. --- -# Node Metrics and Monitoring +# Node metrics and monitoring The Optimism `op-node` exposes a variety of metrics to help observe the health of the system and debug issues. Metrics are formatted for use with Prometheus and exposed via a metrics endpoint. The default metrics endpoint is `http://localhost:7300/metrics`. To enable metrics, pass the `--metrics.enabled` flag to the `op-node`. You can customize the metrics port and address via the `--metrics.port` and `--metrics.addr` flags, respectively. -## Important Metrics +## Important metrics To monitor the health of your node, you should monitor the following metrics: @@ -20,7 +20,7 @@ To monitor the health of your node, you should monitor the following metrics: * `engine_forkChoiceUpdatedV1`, `engine_getPayloadV1`, and `engine_newPayloadV1`: These methods are used to execute blocks on `op-geth`. If these methods are slow, it means that sync time is bottlenecked by either `op-geth` itself or your connection to it. * `eth_getBlockByHash`, `eth_getTransactionReceipt`, and `eth_getBlockByNumber`: These methods are used by the `op-node` to fetch transaction data from L1. If these methods are slow, it means that sync time is bottlenecked by your L1 RPC. -## Available Metrics +## Available metrics A complete list of available metrics is below: @@ -33,10 +33,10 @@ A complete list of available metrics is below: | op\_node\_default\_rpc\_client\_requests\_total | Total RPC requests initiated by the opnode's RPC client | method | counter | | op\_node\_default\_rpc\_client\_request\_duration\_seconds | Histogram of RPC client request durations | method | histogram | | op\_node\_default\_rpc\_client\_responses\_total | Total RPC request responses received by the opnode's RPC client | method,error | counter | -| op\_node\_default\_l1\_source\_cache\_size | L1 Source cache cache size | type | gauge | +| op\_node\_default\_l1\_source\_cache\_size | L1 Source cache size | type | gauge | | op\_node\_default\_l1\_source\_cache\_get | L1 Source cache lookups, hitting or not | type,hit | counter | | op\_node\_default\_l1\_source\_cache\_add | L1 Source cache additions, evicting previous values or not | type,evicted | counter | -| op\_node\_default\_l2\_source\_cache\_size | L2 Source cache cache size | type | gauge | +| op\_node\_default\_l2\_source\_cache\_size | L2 Source cache size | type | gauge | | op\_node\_default\_l2\_source\_cache\_get | L2 Source cache lookups, hitting or not | type,hit | counter | | op\_node\_default\_l2\_source\_cache\_add | L2 Source cache additions, evicting previous values or not | type,evicted | counter | | op\_node\_default\_derivation\_idle | 1 if the derivation pipeline is idle | | gauge | diff --git a/pages/builders/node-operators/management/snap-sync.mdx b/pages/builders/node-operators/management/snap-sync.mdx index dd86dac6c..68bf869c9 100644 --- a/pages/builders/node-operators/management/snap-sync.mdx +++ b/pages/builders/node-operators/management/snap-sync.mdx @@ -1,5 +1,5 @@ --- -title: Using Snap Sync for Node Operators +title: Using snap sync for node operators lang: en-US description: Learn how to use and enable snap sync on your node. --- @@ -7,7 +7,7 @@ description: Learn how to use and enable snap sync on your node. import { Callout, Steps } from 'nextra/components' import { Tabs } from 'nextra/components' -# Using Snap Sync for Node Operators +# Using snap sync for node operators This guide reviews the optional feature of Snap Sync for node operators, including benefits and how to enable the feature. @@ -19,7 +19,7 @@ This means that performing a Snap Sync is significantly faster than performing a * This also enables nodes to join the network after Ecotone activates without requiring a [blob archiver](blobs). * Archive nodes are also fully supported. -## Enable Snap Sync for Your Node +## Enable snap sync for your node For snap sync, all `op-geth` nodes should expose port `30303` TCP and `30303` UDP to easily find other op-geth nodes to sync from. @@ -81,7 +81,7 @@ Choose one of the following options to enable snap sync: -## Enabling Execution Layer Sync for Alternative Clients +## Enabling execution layer sync for alternative clients In addition to op-geth, you can enable execution-layer syncing with alternative execution clients such as `reth` and `op-erigon`. Unlike `op-geth`, `reth` and `op-erigon` are designed as archive nodes, which means they require the complete history of the chain. @@ -100,7 +100,7 @@ To enable execution layer sync for these clients, set the following flags on `op --l2.enginekind=erigon (not default) ``` -## Next Steps +## Next steps * See the [Node Configuration](/builders/node-operators/configuration/base-config#configuration) guide for additional explanation or customization. * To enable snap sync for your chain, see [Using Snap Sync for Chain Operators](/builders/chain-operators/management/snap-sync). diff --git a/pages/builders/node-operators/management/snapshots.mdx b/pages/builders/node-operators/management/snapshots.mdx index 897d404eb..96d3bd6c1 100644 --- a/pages/builders/node-operators/management/snapshots.mdx +++ b/pages/builders/node-operators/management/snapshots.mdx @@ -6,7 +6,7 @@ description: Find download links for data directories and database snapshots for import { Callout } from 'nextra/components' -# Node Snapshots +# Node snapshots This page contains download links for data directories and node snapshots that can be used to more easily run your own node. Data directories and node snapshots are not required but can significantly simplify the node operation process. @@ -15,7 +15,7 @@ Data directories and node snapshots are not required but can significantly simpl Data directories and node snapshots are **not required** for nodes using [snap sync](snap-sync) but are still required for archive nodes and in instances when you need to trace the entire chain. -## About the Bedrock Migration +## About the Bedrock migration OP Mainnet underwent a large [database migration](https://web.archive.org/web/20240110231645/https://blog.oplabs.co/reproduce-bedrock-migration/) as part of the [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/) in 2023. Node operators must have a migrated OP Mainnet database to run a node. @@ -32,7 +32,7 @@ Migrated OP Mainnet databases can be generated manually or pre-migrated database Using [aria2](https://aria2.github.io/) to download snapshots can significantly speed up the download process. -### OP Mainnet (Full Node) +### OP Mainnet (full node) [Allnodes](https://www.allnodes.com) provides more recent full node snapshots for OP Mainnet and Testnet. You can find them [here](https://www.publicnode.com/snapshots#optimism). @@ -43,7 +43,7 @@ Migrated OP Mainnet databases can be generated manually or pre-migrated database | ------------- | ----- | ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | 2023-06-06 | 325GB | [Mirror 1](https://op.datadirs.xyz/mainnet-bedrock.tar.zst) | `ec4baf47e309a14ffbd586dc85376833de640c0f2a8d7355cb8a9e64c38bfcd1` | -### OP Mainnet (Archive Node) +### OP Mainnet (archive node) You can also download access the [Optimism Foundation datadir explorer](https://datadirs.optimism.io/) to find other snapshots. @@ -53,7 +53,7 @@ Migrated OP Mainnet databases can be generated manually or pre-migrated database | ----------------------------- | ---- | ------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------- | | Latest by Optimism Foundation | >4TB | [Mirror 1](https://datadirs.optimism.io/latest)
[Mirror 2 (torrent)](https://datadirs.optimism.io/latest.torrent) | [sha256sum](https://datadirs.optimism.io/latest.sha256sum/) | -### OP Mainnet (Legacy) +### OP Mainnet (legacy) | Snapshot Date | Size | Download Link | sha256sum | | ------------- | ----- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------- | diff --git a/pages/builders/node-operators/network-upgrades.mdx b/pages/builders/node-operators/network-upgrades.mdx index 9560bcf95..e82206f6a 100644 --- a/pages/builders/node-operators/network-upgrades.mdx +++ b/pages/builders/node-operators/network-upgrades.mdx @@ -1,118 +1,33 @@ --- -title: Network Upgrades +title: Network upgrades lang: en-US -description: Learn more about how network upgrades work and how to keep your nodes up to date. +description: Learn more about Superchain network activations. --- import Image from 'next/image' import { Steps, Callout } from 'nextra/components' -# Network Upgrade Overview +# Network upgrade overview -This section has information on how to upgrade your Mainnet and Testnet nodes -for new network upgrades. The network upgrade naming scheme after the Bedrock -upgrade has a geology themed name based on the next letter in the english -alphabet. +This page provides hardfork activation timestamps and links to detailed specifications. +The documentation outlines the hardfork release process. +The network upgrade naming scheme after the Bedrock upgrade follows a geology theme based on the next letter in the English alphabet. ## Activations -Network upgrades are activated by timestamps. Failing to upgrade your node -before the timestamp will cause a chain divergence. You will need to resync -your node to reconcile the chain. Optimistic activation times refer to times -that are pending governance approval. +Network upgrades are activated by timestamps. Failing to upgrade your OP Stack software before the timestamp will cause a chain divergence and you will need to resync the chain. Optimistic activation times refer to times that are pending governance approval. -| Upgrade | Governance Approval | [OP Mainnet Activations](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/superchain.toml) | [OP Sepolia Activations](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/sepolia/superchain.toml) | -| ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | -| [Granite](https://specs.optimism.io/protocol/granite/overview.html) | [approved](https://gov.optimism.io/t/upgrade-proposal-10-granite-network-upgrade/8733) | Wed Sep 11 16:00:01 UTC 2024 (`1726070401`) | Mon Aug 12 16:00:00 UTC 2024 (`1723478400`) | -| [Fjord](https://specs.optimism.io/protocol/fjord/overview.html) | [approved](https://gov.optimism.io/t/upgrade-proposal-9-fjord-network-upgrade/8236) | Wed Jul 10 16:00:01 UTC 2024 (`1720627201`) | Wed May 29 16:00:00 UTC 2024 (`1720627201`) | -| [Ecotone](https://specs.optimism.io/protocol/ecotone/overview.html) | [approved](https://gov.optimism.io/t/upgrade-proposal-5-ecotone-network-upgrade/7669) | Thu Mar 14 00:00:01 UTC 2024 (`1710374401`) | Wed Feb 21 17:00:00 UTC 2024 (`1708534800`) | -| [Delta](https://specs.optimism.io/protocol/delta/overview.html) | [approved](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310) | Thu Feb 22 00:00:00 UTC 2024 (`1708560000`) | Fri Dec 22 00:00:00 UTC 2023 (`1703203200`) | -| [Canyon](https://specs.optimism.io/protocol/canyon/overview.html) | [approved](https://gov.optimism.io/t/final-upgrade-proposal-2-canyon-network-upgrade/7088) | Thu Jan 11 17:00:01 UTC 2024 (`1704992401`) | Tue Nov 14 17:00:00 UTC 2023 (`1699981200`) | +| Upgrade | Governance Approval | [Mainnet Activations](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/superchain.toml) | [Sepolia Activations](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/sepolia/superchain.toml) | +| --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | +| [Holocene](https://specs.optimism.io/protocol/holocene/overview.html) | TBD | TBD | Tue Nov 26 15:00:00 UTC 2024 (`1732633200`) | +| [Granite](https://specs.optimism.io/protocol/granite/overview.html) | [approved](https://gov.optimism.io/t/upgrade-proposal-10-granite-network-upgrade/8733) | Wed Sep 11 16:00:01 UTC 2024 (`1726070401`) around block `125235812` | Mon Aug 12 16:00:00 UTC 2024 (`1723478400`) around block `15837930` | +| [Fjord](https://specs.optimism.io/protocol/fjord/overview.html) | [approved](https://gov.optimism.io/t/upgrade-proposal-9-fjord-network-upgrade/8236) | Wed Jul 10 16:00:01 UTC 2024 (`1720627201`) around block `122514212` | Wed May 29 16:00:00 UTC 2024 (`1716998400`) around block `12597930` | +| [Ecotone](https://specs.optimism.io/protocol/ecotone/overview.html) | [approved](https://gov.optimism.io/t/upgrade-proposal-5-ecotone-network-upgrade/7669) | Thu Mar 14 00:00:01 UTC 2024 (`1710374401`) around block `117387812` | Wed Feb 21 17:00:00 UTC 2024 (`1708534800`) around block `8366130` | +| [Delta](https://specs.optimism.io/protocol/delta/overview.html) | [approved](https://gov.optimism.io/t/final-upgrade-proposal-3-delta-network-upgrade/7310) | Thu Feb 22 00:00:00 UTC 2024 (`1708560000`) around block `116480612` | Fri Dec 22 00:00:00 UTC 2023 (`1703203200`) around block `5700330` | +| [Canyon](https://specs.optimism.io/protocol/canyon/overview.html) | [approved](https://gov.optimism.io/t/final-upgrade-proposal-2-canyon-network-upgrade/7088) | Thu Jan 11 17:00:01 UTC 2024 (`1704992401`) around block `114696812` | Tue Nov 14 17:00:00 UTC 2023 (`1699981200`) around block `4089330` | +| Bedrock | [approved](https://gov.optimism.io/t/final-upgrade-1-bedrock-protocol-upgrade-v2/5548) | Tue Jun 06 2023 16:28:23 UTC (`1686079703`) at block `105235063` | N/A | -## Summary of Changes - -These are the summaries of each network upgrade changes ordered by the most -recent activation. These are a reflection of the [Superchain Upgrades Specifications](https://specs.optimism.io/protocol/superchain-upgrades.html) - -### [Granite](https://specs.optimism.io/protocol/granite/overview.html) - -The Granite upgrade limits `bn256Pairing` precompile input size and reduces the Channel Timeout. - -* [Limit `bn256Pairing` precompile input size](https://specs.optimism.io/protocol/granite/exec-engine.html#bn256pairing-precompile-input-restriction) -* [Reduce Channel Timeout to 50](https://specs.optimism.io/protocol/granite/derivation.html#reduce-channel-timeout) - -### [Fjord](https://specs.optimism.io/protocol/fjord/overview.html) - -The Fjord upgrade includes the RIP-7212 precompile, FastLZ gas pricing, Brotli channel compression, and several protocol parameter changes. - -* [RIP-7212: Precompile for secp256r1](https://specs.optimism.io/protocol/precompiles.html#P256VERIFY) -* [Brotli channel compression](https://specs.optimism.io/fjord/exec-engine.html#fees) -* FastLZ gas pricing - * [FastLZ L1 fee cost calculation](https://specs.optimism.io/fjord/exec-engine.html#fees) - * [Upgraded GasPriceOracle to compute FastLZ](https://specs.optimism.io/fjord/derivation.html#gaspriceoracle-deployment) - * [L1 gas cost changes](https://specs.optimism.io/fjord/predeploys.html#l1-gas-usage-estimation) -* Protocol parameter changes - * [Max sequencer drift becomes constant](https://specs.optimism.io/fjord/derivation.html#constant-maximum-sequencer-drift) - * [Channel constant increases](https://specs.optimism.io/fjord/derivation.html#increasing-max_rlp_bytes_per_channel-and-max_channel_bank_size) -* [Fjord hardfork activation block](https://specs.optimism.io/fjord/derivation.html#network-upgrade-automation-transactions) - -### [Ecotone](https://specs.optimism.io/protocol/ecotone/overview.html) - -The Ecotone upgrade contains the Dencun upgrade from L1, and adopts EIP-4844 blobs for data-availability. - -Cancun (Execution Layer): - -* [EIP-1153: Transient storage opcodes](https://eips.ethereum.org/EIPS/eip-1153) -* [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) -* [Blob transactions are disabled](https://specs.optimism.io/protocol/exec-engine.html#ecotone-disable-blob-transactions) -* [EIP-4788: Beacon block root in the EVM](https://eips.ethereum.org/EIPS/eip-4788) -* [The L1 beacon block root is embedded into L2](https://specs.optimism.io/protocol/exec-engine.html#ecotone-beacon-block-root) -* [The Beacon roots contract deployment is automated](https://specs.optimism.io/protocol/derivation.html#ecotone-beacon-block-roots-contract-deployment-eip-4788) -* [EIP-5656: MCOPY - Memory copying instruction](https://eips.ethereum.org/EIPS/eip-5656) -* [EIP-6780: SELFDESTRUCT only in same transaction](https://eips.ethereum.org/EIPS/eip-6780) -* [EIP-7516: BLOBBASEFEE opcode](https://eips.ethereum.org/EIPS/eip-7516) -* [BLOBBASEFEE always pushes 1 onto the stack](https://specs.optimism.io/protocol/exec-engine.html#ecotone-disable-blob-transactions) - -Deneb (Consensus Layer): *not applicable to L2* - -* [EIP-7044: Perpetually Valid Signed Voluntary Exits](https://eips.ethereum.org/EIPS/eip-7044) -* [EIP-7045: Increase Max Attestation Inclusion Slot](https://eips.ethereum.org/EIPS/eip-7045) -* [EIP-7514: Add Max Epoch Churn Limit](https://eips.ethereum.org/EIPS/eip-7514) - -Data Availability (DA) upgrade: - -* Blobs Data Availability: support blobs DA the [L1 Data-retrieval stage](https://specs.optimism.io/protocol/derivation.html#ecotone-blob-retrieval). -* Rollup fee update: support blobs DA in [L1 Data Fee computation](https://specs.optimism.io/protocol/exec-engine.html#ecotone-l1-cost-fee-changes-eip-4844-da) -* Auto-upgrading and extension of the [L1 Attributes Predeployed Contract](https://specs.optimism.io/protocol/deposits.html#ecotone-l1block-upgrade) - (also known as `L1Block` predeploy) - -### [Delta](https://specs.optimism.io/protocol/delta/overview.html) - -The Delta upgrade consists of a single consensus-layer feature: [Span Batches](https://specs.optimism.io/protocol/delta/span-batches.html). - -The Delta upgrade uses a *L2 block-timestamp* activation-rule, and is specified only in the rollup-node (`delta_time`). - -### [Canyon](https://specs.optimism.io/protocol/canyon/overview.html) - -The Canyon upgrade contains the Shapella upgrade from L1 and some minor protocol fixes. - -* [EIP-3651: Warm COINBASE](https://eips.ethereum.org/EIPS/eip-3651) -* [EIP-3855: PUSH0 instruction](https://eips.ethereum.org/EIPS/eip-3855) -* [EIP-3860: Limit and meter initcode](https://eips.ethereum.org/EIPS/eip-3860) -* [EIP-4895: Beacon chain push withdrawals as operations](https://eips.ethereum.org/EIPS/eip-4895) -* [Withdrawals are prohibited in P2P Blocks](https://specs.optimism.io/protocol/rollup-node-p2p.html#block-validation) -* [Withdrawals should be set to the empty array with Canyon](https://specs.optimism.io/protocol/derivation.html#building-individual-payload-attributes) -* [EIP-6049: Deprecate SELFDESTRUCT](https://eips.ethereum.org/EIPS/eip-6049) -* [Modifies the EIP-1559 Denominator](https://specs.optimism.io/protocol/exec-engine.html#1559-parameters) -* [Channel Ordering Fix](https://specs.optimism.io/protocol/derivation.html#reading) -* [Adds the deposit nonce & deposit nonce version to the deposit receipt hash](https://specs.optimism.io/protocol/deposits.html#deposit-receipt) -* [Deploys the create2Deployer to `0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2`](https://specs.optimism.io/protocol/predeploys.html#create2deployer) - -The Canyon upgrade uses a *L2 block-timestamp* activation-rule, and is specified in both the -rollup-node (`canyon_time`) and execution engine (`config.canyonTime`). Shanghai time in the -execution engine should be set to the same time as the Canyon time. - -## Upgrade Process +## Upgrade process Network upgrades follow this general process in which the features included in the upgrade are put into a release version cut from the `develop` branch and @@ -155,7 +70,7 @@ then the software is deployed on production networks. * `Upgrade Activated` -## More Information +## More information * To check for the latest node software, see the [Software Releases](/builders/node-operators/releases). * For more information on the governance process see the [governance documentation](https://community.optimism.io/docs/governance/). diff --git a/pages/builders/node-operators/releases.mdx b/pages/builders/node-operators/releases.mdx index f0966bf01..4c7ad18c7 100644 --- a/pages/builders/node-operators/releases.mdx +++ b/pages/builders/node-operators/releases.mdx @@ -1,12 +1,12 @@ --- -title: Node Software Releases +title: Node software releases lang: en-US description: Off chain node software release information and how to stay up to date. --- import { Callout } from 'nextra/components' -# Node Software Releases +# Node software releases This page gives information on the off chain node software release information. @@ -15,27 +15,27 @@ This page gives information on the off chain node software release information. and `op-geth` releases can be found [here](https://github.com/ethereum-optimism/op-geth/releases). -## Production Releases +## Production releases 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, 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. -### Docker Images +### Docker images To make it easier to find and use our Docker images, each release entry below provides links to the corresponding Docker images: * **op-node**: Docker images can be found [here](https://hub.docker.com/r/ethereumoptimism/op-node/tags). * **op-geth**: Docker images can be found [here](https://hub.docker.com/r/ethereumoptimism/op-geth/tags). -### Example Docker Image Tags +### Example Docker image tags We follow a consistent tagging convention to make it easier to find the right image. Here are some examples: * `optimism/op-node:` * `optimism/op-geth:` -## Release Entries +## Release entries | Network | op-node | op-geth | | ---------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | diff --git a/pages/builders/node-operators/rollup-node.mdx b/pages/builders/node-operators/rollup-node.mdx index dcffe980d..19c82347c 100644 --- a/pages/builders/node-operators/rollup-node.mdx +++ b/pages/builders/node-operators/rollup-node.mdx @@ -1,16 +1,16 @@ --- -title: How to Run a Node in the Superchain +title: How to run a node in the Superchain lang: en-US description: Learn how to run an OP Stack rollup node in the Superchain. --- import { Callout, Steps } from 'nextra/components' -# How to Run a Node in the Superchain +# How to run a node in the Superchain This guide provides an overview of how to run an OP Stack rollup node in the Superchain. It walks you through how to build, configure, run, and monitor your node on one of the OP Chains in the Superchain. To skip ahead to building and running a node, you can explore the [node operator tutorials](#node-operator-tutorials). -## Build Your Node +## Build your node Before building your node, you will learn fundamental aspects of OP Stack rollup nodes. @@ -34,7 +34,7 @@ Before building your node, you will learn fundamental aspects of OP Stack rollup * **Option 2:** Follow the [Building a Node from Source](/builders/node-operators/tutorials/node-from-source) tutorial, if you need to use a specific architecture or want to inspect the source code of your OP Stack rollup node. -## Configure Your Node +## Configure your node OP Stack rollup nodes can be configured for individual needs. The following steps will get you started with a working base configuration for OP Stack rollup nodes, along with recommended flags. @@ -55,7 +55,7 @@ OP Stack rollup nodes can be configured for individual needs. The following step -## Run Your Node +## Run your node Now, you will run your node and set your node debugging log level for more granular feedback. @@ -78,7 +78,7 @@ Now, you will run your node and set your node debugging log level for more granu * Update node [log level](/builders/node-operators/configuration/consensus-config#loglevel) based on individual needs. For more details, see the guide on [Geth Logs](https://geth.ethereum.org/docs/fundamentals/logs). -## Monitor Your Node +## Monitor your node It is important to regularly monitor your node, and you can optionally configure prometheus and grafana dashboard to make this process easier for you. @@ -100,13 +100,13 @@ It is important to regularly monitor your node, and you can optionally configure -## Follow Node Updates +## Follow node updates * It's important to keep your node software up to date. Software updates can also include important bug fixes and patches that can help keep your node stable. * Refer to the [Software Releases](/builders/node-operators/releases) page for a detailed look at the latest releases of various rollup node and execution client implementations. * Notifications are also posted to the Optimism Upgrade Announcement Channels on [**Discord**](https://discord.com/channels/667044843901681675/754090866435424270) and [**Telegram**](https://t.me/+LtAJL1Mt1PYyNjBh). -## Node Operator Tutorials +## Node operator tutorials Got an idea for a new tutorial? @@ -121,7 +121,7 @@ It is important to regularly monitor your node, and you can optionally configure | [Running an OP Mainnet Node from Source](tutorials/mainnet) | Learn how to run an OP Mainnet node from source code. | 🟑 Medium | | [Running an OP Sepolia Node from Source](tutorials/testnet) | Learn how to run an OP Sepolia node from source code. | 🟑 Medium | -## Next Steps +## Next steps * If you've already got your node up and running, check out the [Node Metrics and Monitoring Guide](/builders/node-operators/management/metrics) to learn how to keep tabs on your node and make sure it keeps running smoothly. * If you run into any problems, please visit the [Node Troubleshooting Guide](/builders/node-operators/management/troubleshooting) for help. diff --git a/pages/builders/node-operators/tutorials.mdx b/pages/builders/node-operators/tutorials.mdx new file mode 100644 index 000000000..de908fd0f --- /dev/null +++ b/pages/builders/node-operators/tutorials.mdx @@ -0,0 +1,23 @@ +--- +title: Tutorials +lang: en-US +description: >- + Learn about tutorials in the Optimism ecosystem. This guide provides detailed + information and resources about tutorials. +--- + +import { Card, Cards } from 'nextra/components' + +# Tutorials + +This section provides information on various node operations. It covers running an OP Mainnet node from source, running a node with Docker, building a node from source, and running an OP Sepolia node from source. You'll find tutorials and guides to help you understand and work with these topics. + + + + + + + + + + diff --git a/pages/builders/node-operators/tutorials/_meta.json b/pages/builders/node-operators/tutorials/_meta.json index d391ba66f..cff8f7900 100644 --- a/pages/builders/node-operators/tutorials/_meta.json +++ b/pages/builders/node-operators/tutorials/_meta.json @@ -1,6 +1,6 @@ { - "node-from-docker": "Running a Node With Docker", - "node-from-source": "Building a Node from Source", - "mainnet": "Running OP Mainnet from Source", - "testnet": "Running OP Sepolia from Source" + "node-from-docker": "Running a node with Docker", + "node-from-source": "Building a node from source", + "mainnet": "Running OP Mainnet from source", + "testnet": "Running OP Sepolia from source" } diff --git a/pages/builders/node-operators/tutorials/mainnet.mdx b/pages/builders/node-operators/tutorials/mainnet.mdx index 4a2bf206c..4ae527e4e 100644 --- a/pages/builders/node-operators/tutorials/mainnet.mdx +++ b/pages/builders/node-operators/tutorials/mainnet.mdx @@ -1,22 +1,22 @@ --- -title: Running an OP Mainnet Node from Source +title: Running an OP Mainnet node from source lang: en-US description: Learn how to run an OP Mainnet node from source code for full nodes and archive nodes. --- import { Callout, Steps } from 'nextra/components' -# Running an OP Mainnet Node from Source +# Running an OP Mainnet node from source This tutorial explains how to run an OP Mainnet node from source code for full nodes and archive nodes. Running an OP Mainnet node from source code is a flexible alternative to using pre-built Docker images. -## Building the Source Code +## Building the source code You'll need to build `op-node` and `op-geth` from their respective source repositories before you can run a node. Make sure to follow the instructions on [Building a Node from Source](./node-from-source) before continuing. -## Hardware Requirements +## Hardware requirements Hardware requirements for OP Mainnet nodes can vary depending on the type of node you plan to run. Archive nodes generally require significantly more resources than full nodes. @@ -25,7 +25,7 @@ Below are suggested minimum hardware requirements for each type of node. * 16GB RAM * Reasonably modern CPU -### SSD Capacity Requirements +### SSD capacity requirements Given the growing size of the blockchain state, choosing the right SSD size is important. Below are the storage needs as of April 2024: @@ -36,17 +36,17 @@ Below are the storage needs as of April 2024: Based on these trends, node operators should plan for future storage needs and choose SSDs that can handle these increasing requirements. - Geth supports a "freezer" feature to store older chain data on HDDs, saving SSD space. Configure this for OP Mainnet using the `--datadir.ancient` flag. See [Geth docs](https://geth.ethereum.org/docs/fundamentals/databases) and [OP docs](https://docs.optimism.io/builders/node-operators/configuration/execution-config#datadirancient) for details. + Geth supports a "freezer" feature to store older chain data on HDDs, saving SSD space. Configure this for OP Mainnet using the `--datadir.ancient` flag. See [Geth docs](https://geth.ethereum.org/docs/fundamentals/databases) and [OP docs](../configuration/execution-config#datadirancient) for details. -## Full Nodes +## Full nodes -### Assess Blob Archiver +### Assess blob archiver Assess if you need to configure a blob archiver service by reading the [Configure a Blob Archiver documentation](/builders/node-operators/management/blobs#configure-a-blob-archiver-archive-nodes). -### Create a JWT Secret +### Create a JWT secret `op-geth` and `op-node` communicate over the engine API authrpc. This communication is secured using a shared secret. @@ -169,12 +169,12 @@ Once you've started `op-geth`, you can start `op-node`. -### Synchronization Verification +### Synchronization verification Once you've started `op-geth` and `op-node` you should see the two begin to communicate with each other and synchronize the OP Mainnet chain. -#### Snap Sync (Default) +#### Snap sync (default) Initial synchronization can take several hours to complete. You will see these `op-node` logs at the start of snap sync: @@ -223,7 +223,7 @@ There are two stages on `op-geth` for snap sync: -#### Full Sync +#### Full sync You will need access to the migrated OP Mainnet database to run a full node with full sync. @@ -256,13 +256,13 @@ INFO [06-26|14:02:12.976] Chain head was updated number=4,068, INFO [06-26|14:02:12.982] Starting work on payload id=0x5542117d680dbd4e ``` -## Archive Nodes +## Archive nodes You only need an archive node if you need the historical state. Most node operators should default to full nodes. -### Get the Migrated Data Directory +### Get the migrated data directory OP Mainnet underwent a large database migration as part of the [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/) in 2023. You will need access to the migrated OP Mainnet database to run an archive node. @@ -273,7 +273,7 @@ In this section, you'll learn how to download and verify the pre-migrated databa {

Download the Migrated Data Directory

} Click the link below to find the latest publicly available database snapshots for OP Mainnet. - Snapshots are available for multiple dates and snapshots get larger as they get closer the current date. + Snapshots are available for multiple dates and snapshots get larger as they get closer to the current date. Snapshots are large files and may take some time to download. [OP Mainnet Snapshots](/builders/node-operators/management/snapshots#op-mainnet) @@ -293,7 +293,7 @@ In this section, you'll learn how to download and verify the pre-migrated databa sha256sum mainnet-bedrock.tar.zst ``` - You should see then following output: + You should see the following output: ```bash ec4baf47e309a14ffbd586dc85376833de640c0f2a8d7355cb8a9e64c38bfcd1 mainnet-bedrock.tar.zst @@ -322,7 +322,7 @@ In this section, you'll learn how to download and verify the pre-migrated databa Set `--syncmode=full` and `--gcmode=archive` on `op-geth`. -### Get the Legacy Geth Directory (Optional) +### Get the legacy Geth directory (optional) Blocks and transactions included in OP Mainnet before the Bedrock Upgrade cannot be executed by modern OP Mainnet nodes. OP Mainnet nodes will **serve** these blocks and transactions but cannot run certain queries against them (e.g. `eth_call`). @@ -367,7 +367,7 @@ If you want to run a full node then you can safely skip this section. ``` -### Start Legacy Geth (Optional) +### Start legacy Geth (optional) If you've chosen to run a Legacy Geth node alongside your OP Mainnet node, you'll need to start it before you start your OP Mainnet node. @@ -390,7 +390,7 @@ If you've chosen to run a Legacy Geth node alongside your OP Mainnet node, you'l ``` -## Next Steps +## Next steps * If you've already got your node up and running, check out the [Node Metrics and Monitoring Guide](../management/metrics) to learn how to keep tabs on your node and make sure it keeps running smoothly. * If you run into any problems, please visit the [Node Troubleshooting Guide](../management/troubleshooting) for help. diff --git a/pages/builders/node-operators/tutorials/node-from-docker.mdx b/pages/builders/node-operators/tutorials/node-from-docker.mdx index b2706a1b2..9f18059fb 100644 --- a/pages/builders/node-operators/tutorials/node-from-docker.mdx +++ b/pages/builders/node-operators/tutorials/node-from-docker.mdx @@ -6,14 +6,14 @@ description: Learn how to run a node using Docker. import { Callout, Steps } from 'nextra/components' -# Running a Node With Docker +# Running a node with Docker Using [Docker](https://docs.docker.com/engine/install/) is an easy way to run an OP Mainnet node. This tutorial will walk you through the process of using [`simple-optimism-node`](https://github.com/smartcontracts/simple-optimism-node) to run an OP Mainnet or OP Sepolia node using Docker. `simple-optimism-node` also provides useful tools like a monitoring dashboard and health checking software. Although less flexible than [running a node from source](./node-from-source) or building your own Docker setup, this is a great way to quickly get started with OP Mainnet. -## What's Included +## What's included `simple-optimism-node` includes all the basic components to run an OP Mainnet or OP Sepolia node. It also includes several additional services to monitor the health of your node and the health of the network you're connected to. @@ -81,7 +81,7 @@ Configuration for `simple-optimism-node` is handled through environment variable * **Base Sepolia** - [https://sepolia.base.org](https://sepolia.base.org) -## Run the Node +## Run the node Once you've configured your `.env` file, you can run the node using Docker Compose. The following command will start the node in the background. @@ -90,7 +90,7 @@ The following command will start the node in the background. docker compose up -d --build ``` -## Upgrade the Node +## Upgrade the node Pull the latest updates from GitHub, Docker Hub and rebuild the container. @@ -100,12 +100,12 @@ docker compose pull docker compose up -d --build --force-recreate ``` -## Operating the Node +## Operating the node You can use Docker Compose to interact with the node and manage the various containers that you started. Refer to the [Operating the Node](https://github.com/smartcontracts/simple-optimism-node#operating-the-node) section of the `simple-optimism-node` README for more information. -## Checking Node Status +## Checking node status `simple-optimism-node` includes a monitoring dashboard that you can use to check the status of your node. You can access the dashboard by visiting `http://localhost:3000` in your browser. diff --git a/pages/builders/node-operators/tutorials/node-from-source.mdx b/pages/builders/node-operators/tutorials/node-from-source.mdx index 326afa65c..97e01389e 100644 --- a/pages/builders/node-operators/tutorials/node-from-source.mdx +++ b/pages/builders/node-operators/tutorials/node-from-source.mdx @@ -1,20 +1,20 @@ --- -title: Building a Node from Source +title: Building a node from source lang: en-US description: Learn how to build your own node without relying on images from Optimism. --- import { Callout, Steps } from 'nextra/components' -# Building a Node from Source +# Building a node from source Docker images are the easiest way to run an OP Mainnet node, but you can always build your own node from source code. You might want to do this if you want to run a node on a specific architecture or if you want to inspect the source code of the node you're running. This guide will walk you through the full process of building a node from source. -## What You're Going to Build +## What you're going to build -### Rollup Node +### Rollup node The Rollup Node is responsible for deriving L2 block payloads from L1 data and passing those payloads to the Execution Client. The Rollup Node can also optionally participate in a peer-to-peer network to receive blocks directly from the Sequencer before those blocks are submitted to L1. @@ -22,7 +22,7 @@ The Rollup Node is largely analogous to a [consensus client](https://ethereum.or In this tutorial you will build the `op-node` implementation of the Rollup Node as found in the [Optimism Monorepo](https://github.com/ethereum-optimism/optimism). -### Execution Client +### Execution client The Execution Client is responsible for executing the block payloads it receives from the Rollup Node over JSON-RPC via the standard [Ethereum Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md#engine-api----common-definitions). The Execution Client exposes the standard JSON-RPC API that Ethereum developers are familiar with, and can be used to query blockchain data and submit transactions to the network. @@ -30,7 +30,7 @@ The Execution Client is largely analogous to an [execution client](https://ether In this tutorial you will build the `op-geth` implementation of the Execution Client as found in the [`op-geth` repository](https://github.com/ethereum-optimism/op-geth). -### Legacy Geth (Optional) +### Legacy Geth (optional) Legacy Geth is an optional component for OP Mainnet archive nodes. Legacy Geth allows you to execute stateful queries like `eth_call` against blocks and transactions that occurred before the OP Mainnet [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/). @@ -39,7 +39,7 @@ Legacy Geth is only relevant to OP Mainnet archive nodes and is not required for Currently, `l2Geth` is the only available implementation of Legacy Geth. In this tutorial you will build the `l2geth` implementation of Legacy Geth as found in the [`optimism-legacy` repository](https://github.com/ethereum-optimism/optimism-legacy). -## Software Dependencies +## Software dependencies | Dependency | Version | Version Check Command | | ------------------------------------------------------------- | -------- | --------------------- | @@ -50,7 +50,7 @@ In this tutorial you will build the `l2geth` implementation of Legacy Geth as fo | [foundry](https://github.com/foundry-rs/foundry#installation) | `^0.2.0` | `forge --version` | | [make](https://linux.die.net/man/1/make) | `^4` | `make --version` | -## Build the Rollup Node +## Build the rollup node First you're going to build the `op-node` implementation of the Rollup Node as found in the [Optimism Monorepo](https://github.com/ethereum-optimism/optimism). @@ -106,7 +106,7 @@ make op-node -## Build the Execution Client +## Build the execution client Next you're going to build the `op-geth` implementation of the Execution Client as found in the [op-geth repository](https://github.com/ethereum-optimism/op-geth). @@ -146,7 +146,7 @@ make geth -## Build Legacy Geth (Optional) +## Build legacy Geth (optional) Legacy Geth is an optional component for OP Mainnet archive nodes. Legacy Geth allows you to execute stateful queries like `eth_call` against blocks and transactions that occurred before the OP Mainnet [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/). @@ -172,7 +172,7 @@ make -## Next Steps +## Next steps * Click here to [Run an OP Mainnet Node from Source Code](mainnet) * Click here to [Run an OP Sepolia Node from Source Code](testnet) diff --git a/pages/builders/node-operators/tutorials/testnet.mdx b/pages/builders/node-operators/tutorials/testnet.mdx index 4d97bf849..bec9846dc 100644 --- a/pages/builders/node-operators/tutorials/testnet.mdx +++ b/pages/builders/node-operators/tutorials/testnet.mdx @@ -1,22 +1,22 @@ --- -title: Running an OP Sepolia Node from Source +title: Running an OP Sepolia node from source lang: en-US description: Learn how to run an OP Sepolia node from source code. --- import { Callout, Steps } from 'nextra/components' -# Running an OP Sepolia Node from Source +# Running an OP Sepolia node from source This tutorial explains how to run an OP Sepolia node from source code. Running an OP Sepolia node from source code is a flexible alternative to using pre-built Docker images. -## Building the Source Code +## Building the source code You'll need to build `op-node` and `op-geth` from their respective source repositories before you can run a node. Make sure to follow the instructions on [Building a Node from Source](./node-from-source) before continuing. -## Hardware Requirements +## Hardware requirements Hardware requirements for OP Sepolia nodes can vary depending on the type of node you plan to run. Archive nodes generally require significantly more resources than full nodes. @@ -26,12 +26,12 @@ Below are suggested minimum hardware requirements for each type of node. * 60 GB SSD (full node) or 200 GB SSD (archive node) * Reasonably modern CPU -## Assess Blob Archiver +## Assess blob archiver Assess if you need to configure a blob archiver service by reading the [Configure a Blob Archiver documentation](/builders/node-operators/management/blobs#configure-a-blob-archiver-archive-nodes). -## Create a JWT Secret +## Create a JWT secret `op-geth` and `op-node` communicate over the engine API authrpc. This communication is secured using a shared secret. @@ -162,12 +162,12 @@ Note that this flag will cause `op-node` to trust the L1 node to provide correct -### Synchronization Verification +### Synchronization verification Once you've started `op-geth` and `op-node` you should see the two begin to communicate with each other and synchronize the OP Mainnet chain. -#### Snap Sync (Default) +#### Snap sync (default) Initial synchronization can take several hours to complete. You will see these `op-node` logs at the start of snap sync: @@ -216,7 +216,7 @@ There are two stages on `op-geth` for snap sync: -#### Full Sync +#### Full sync Initial full synchronization can take several days to complete. @@ -246,7 +246,7 @@ INFO [06-26|14:02:12.976] Chain head was updated number=4,068, INFO [06-26|14:02:12.982] Starting work on payload id=0x5542117d680dbd4e ``` -## Next Steps +## Next steps * If you've already got your node up and running, check out the [Node Metrics and Monitoring Guide](../management/metrics) to learn how to keep tabs on your node and make sure it keeps running smoothly. * If you run into any problems, please visit the [Node Troubleshooting Guide](../management/troubleshooting) for help. diff --git a/pages/builders/notices.mdx b/pages/builders/notices.mdx new file mode 100644 index 000000000..5ca3a4b7f --- /dev/null +++ b/pages/builders/notices.mdx @@ -0,0 +1,17 @@ +--- +title: Notices +description: Documentation covering Sdk Deprecation in the Notices section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Notices + +Documentation covering Sdk Deprecation in the Notices section of the OP Stack ecosystem. + + + + + + diff --git a/pages/builders/notices/_meta.json b/pages/builders/notices/_meta.json index 0b387da16..4b21e6372 100644 --- a/pages/builders/notices/_meta.json +++ b/pages/builders/notices/_meta.json @@ -1,4 +1,4 @@ { - "granite-changes": "Preparing for Granite Breaking Changes", - "fp-changes": "Preparing for Fault Proofs Breaking Changes" + "holocene-changes": "Preparing for Holocene breaking changes", + "sdk-deprecation": "Preparing for Optimism SDK deprecation" } diff --git a/pages/builders/notices/fp-changes.mdx b/pages/builders/notices/fp-changes.mdx deleted file mode 100644 index 4f7a34d81..000000000 --- a/pages/builders/notices/fp-changes.mdx +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: Preparing for Fault Proofs Breaking Changes -lang: en-US -description: Learn how to prepare for Fault Proofs changes. ---- - -import { Steps, Callout } from 'nextra/components' - -# Preparing for Fault Proofs Breaking Changes - -OP Labs has submitted a [proposal to governance](https://gov.optimism.io/t/upgrade-proposal-fault-proofs/8161) to upgrade OP Mainnet to support Fault Proofs. If this proposal passes, fault proofs would launch on OP Mainnet approximately June 2024. This document details changes that apply to users, bridges, and centralized exchanges, as well as any custom solutions that use withdrawals. This page outlines changes for OP Mainnet and OP Sepolia only. Details for other OP Chains are forthcoming. - -If you experience difficulty at any stage of this process, please reach out to [OP Labs Developer Support](https://github.com/ethereum-optimism/developers/discussions). - - - **Important Notice for Bridges and Users** - -**ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reproven after the upgrade is complete. - - * Reproving simply requires that you execute the [withdrawal proving flow](https://docs.optimism.io/stack/protocol/rollup/withdrawal-flow) again. - * Withdrawals prior to the Fault Proofs upgrade must wait a 7-day challenge period before finalization. As a result, any withdrawal initiated less than 7 days before the upgrade cannot be finalized before the upgrade is executed. You may want to consider waiting until after the upgrade is complete to begin a withdrawal during this 7-day window. - - - - **Important Notice for Bridges and Users** - - Maximum withdrawal delay times are increasing with the Fault Proofs upgrade. - * Withdrawals will generally take 7 days to finalize (unchanged from before Fault Proofs). - * Withdrawals that are proven against an output proposal that receives a validity challenge are delayed by an additional 3.5 days. Valid proposals that are challenged maliciously can be delayed by up to an additional 9 days at a very high cost to the malicious actor. Additional delays of this type are expected to be infrequent. - - - - As of the Fault Proofs update to OP Sepolia in March 2024, **OP Sepolia withdrawals are no longer instant.** This is because the Fault Proof mechanism now applies to OP Sepolia transactions. - - -## Overview of Changes - -If you are operating a custom bridge, review this section for changes you need to make. If you are using Optimism SDK or Viem for your bridging, you can [skip to the next section](#for-bridges-and-centralized-exchanges). - -The `L2OutputOracle` is being entirely removed and replaced by the `OptimismPortal` and `DisputeGameFactory`. The `L2OutputOracle` smart contract is currently used by the trusted Proposer role to store L2 state output proposals. -Presently, developers use these outputs to prove that their withdrawals actually happened on L2. But with fault proofs, developers will have to change how their client software proves withdrawals in the first step of the two-step withdrawal process. - -### `L2OutputOracle` - -The `OptimismPortal` is changing slightly with Fault Proof Mainnet because it now points to the `DisputeGameFactory` contract instead of the `L2OutputOracle` contract. -Most notable change for developers is that withdrawals will have to be proven against the `rootClaim` of some dispute game rather than referencing an output in the `L2OutputOracle` contract. - -### `OptimismPortal` - -The `OptimismPortal` smart contract is the low-level contract on L1 used to execute deposits and withdrawals. -Previously, developers would look at the `L2OutputOracle` to find the exact next output that included their withdrawal. -Now, developers must look at the `OptimismPortal` contract to determine the `respectedGameType` and then use this information to query the `DisputeGameFactory` for a list of recent `DisputeGame` contracts with the correct game type. - -### `DisputeGameFactory` - -It is recommended that developers search for a reasonable number of recent games, say 100 games, and pick the first proposal with a sufficient block number. -Developers should then verify this proposal locally as the default game type will allow for permissionless proposals and there is no longer a strong guarantee that proposals will be valid. - -## For Bridges and Centralized Exchanges - -The proposed Fault Proof upgrade requires developers to enable Fault Proof changes before the Op Mainnet release. This impacts bridges, centralized exchanges, and custom solutions that use withdrawals. - - - Withdrawals that haven't finalized before the upgrade occurs will be unable to be finalized post-upgrade without reproving. This means these withdrawals will need to go through a new 7-day period. The time accrued before the upgrade will not count. - This means the withdrawal time could be as long as 13-14 days during the upgrade window. (If you submit it \~6 days before the upgrade, then must re-prove after the upgrade, you will have to wait a new seven days.) - - - - ### Update Logic to Support Fault Proofs - - - Most teams use the Optimism SDK or Viem to handle this logic under the hood and will simply need to update their software version ahead of the upgrade. However, any project performing withdrawals programmatically will need to update their client code (see [`OptimismPortal`](#optimismportal) for details). - - - * **Option 1: Optimism SDK Update.** If you use OptimismSDK for bridging, simply update to version 3.2.0 or higher. - The Optimism SDK changes do not break the API and require no changes other than updating to the correct software version to support the new `OptimismPortal` logic. The Optimism SDK will automatically begin to use the new logic once it detects that the FPM update has gone live. - * **Option 2: Viem Update.** Update to the latest version of Viem (version of >=2.9.0). Viem will automatically begin to use the new logic once it detects that the FPM update has gone live. - - ### Update Withdrawal Monitor - - The Withdrawal Monitor service is an important part of the two-step withdrawal system that checks if anyone has been able to prove withdrawals that do not actually appear on L2. - The Withdrawal Monitor is now slightly slower at startup time but is more reliable, simpler, and compatible with more infrastructure to more easily support any OP Stack chain. - Changes to the Withdrawal Monitor are entirely backwards compatible. - - * **Option 1: Withdrawal from source.** If building or using withdrawal-monitor from source, make sure that you are using the latest develop branch. All withdrawal monitor changes are fully backwards compatible. - * **Option 2: Docker image.** If using docker, use the latest chain-mon docker image. - - ### Update Dispute Monitor - - The Dispute Monitor service detects when invalid outputs have been proposed. Given the large number of changes to the output proposal system, the current Fault Monitor is being replaced in favor of a new Dispute Monitor purposely built for the fault proof monitor system. - - - Any team running the current Fault Monitor will see the monitor stop functioning when the Fault Proof Monitor upgrade goes live. These teams should run the new service and update their alerting accordingly. - - - -## Next Steps - -* See the [Fault Proofs Explainer](/stack/protocol/fault-proofs/explainer) to learn more about the three main components of the Fault Proof System. -* You can also read more about [Cannon FPVM](/stack/protocol/fault-proofs/cannon) and [Mips.sol](/stack/protocol/fault-proofs/mips), the onchain smart contract implementation of Cannon. diff --git a/pages/builders/notices/granite-changes.mdx b/pages/builders/notices/granite-changes.mdx deleted file mode 100644 index b0eaa9871..000000000 --- a/pages/builders/notices/granite-changes.mdx +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Preparing for Granite Breaking Changes -lang: en-US -description: Learn how to prepare for Granite upgrade breaking changes. ---- - -import { Steps, Callout } from 'nextra/components' - -# Preparing for Granite Breaking Changes - -This page outlines breaking changes related to the Granite network upgrade for chain operators and node operators. -If you experience difficulty at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). - - - The Granite upgrade for OP Sepolia was activated on **1723478400 - Mon Aug 12 16:00:00 UTC**. The Granite OP Mainnet upgrade will be activated at **1726070401 - Wed 11 Sep 2024 16:00:01 UTC**, here is the [governance vote](https://vote.optimism.io/proposals/46514799174839131952937755475635933411907395382311347042580299316635260952272). - - -## What's Included in Granite - -This upgrade is proposed in response to security vulnerabilities identified during a series of third-party security audits by Spearbit, Cantina, and Code4rena. None of the vulnerabilities have been exploited, and user assets are not and were never at risk. However, out of an abundance of caution, the permissioned fallback mechanism has been activated in order to avoid any potential instability while the vulnerabilities are patched. For more information on the permissioned fallback mechanism and the OP Stack's defense-in-depth approach to Fault Proof security, see the [fault proof documentation](https://docs.optimism.io/stack/protocol/fault-proofs/fp-security). - -The upgrade includes both a set of smart contract upgrades to fix the vulnerabilities identified in the audit as well as an L2 hardfork to improve the stability and performance of the fault proof system. In addition, we propose extending the capabilities of the Guardian and DeputyGuardian to set the anchor state for the fault proof system in order to prevent referencing invalid anchor states. Aside from implementing these fixes, the primary impact of this upgrade would be to reset user withdrawals at the planned time, similar to the initial Fault Proof upgrade. - -Please refer to the [governance proposal](https://gov.optimism.io/t/upgrade-proposal-10-granite-network-upgrade/8733) for the full details. - -## For Chain Operators - -The proposed Granite upgrade impacts OP chains and requires chain operators to upgrade their chain and configure the sequencer for Granite. - - - - ### Prepare Sequencer Node - - - If you are operating an OP Chain that has an entry in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), the Granite activation date is part of the `op-node` and `op-geth` nodes, and are using the [--network](/builders/node-operators/configuration/consensus-config#network) and [--op-network](/builders/node-operators/configuration/execution-config#op-network-betaop-network) flags. No action is needed for the sequencer after preparing the `SystemConfig` transaction. - - - For custom chains not included in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), you will need to manually configure the [activation timestamp](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/superchain.toml). You have two configuration options for your sequencer node: - - * **Option 1:** Set the Granite activation date in your `rollup.json` config file. You will still need to set the `override.granite` flag in `op-geth` with the UNIX timestamp. - * **Option 2:** Alternatively, chain operators can use the override flags to configure your sequencer node by specifying a time in the future when Granite will activate. - * Set `override.granite` in both `op-node` and `op-geth` to the UNIX timestamp of the block you want to activate the Granite hardfork or corresponding env vars for this. - * In general, run `op-node --help` or `op-geth --help` to see flags, their descriptions and environment variables. - - ### Rollup Configuration Breaking Changes - - Alt-DA mode has had a name change. What was formerly known as Plasma Mode has been renamed and you may need to [update your rollup configuration file](/builders/chain-operators/features/alt-da-mode#breaking-changes-renaming-plasma-mode-to-alt-da-mode). - - - - To verify proper configuration, chain operators should confirm in the startup logs of their `op-node` and `op-geth` that the correct Granite activation timestamps are set. - - -## For Node Operators - -Node operators will need to upgrade to Granite before the activation date. -The op-node release [v1.9.1](https://github.com/ethereum-optimism/optimism/releases/tag/v1.9.1) -and op-geth release [v1.101408.0](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101408.0) contain these changes. - -These following steps are necessary for every node operator: - - - ### Update to the Latest Release - - * [`op-node`](https://github.com/ethereum-optimism/optimism/releases/tag/v1.9.1) - * [`op-geth`](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101408.0) - - ### Configure the Granite Activation Date - - - If you are operating a node for an OP Chain that has an entry in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), the Granite activation date is part of the `op-node` and `op-geth` nodes. So, no action is needed for the sequencer after upgrading to the latest release. Please skip to [Step 3: Verify Your Configuration](#verify-your-configuration). - - - For node operators of custom chains not included in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), you will need to manually configure the [activation timestamp](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/superchain.toml). This can be done one of two ways: - - * **Option 1:** Set the activation time in the `rollup.json` for `op-node`. You will still need to set the `override.granite` flag in `op-geth` if you use this option. - * **Option 2:** Set the activation time via overrides (CLI) in both `op-node` and `op-geth`. These will need to be set on `op-node` and `op-geth` for the sequencer and all other nodes. - - ### Verify Your Configuration - - Make the following checks to verify that your node is properly configured. - - * `op-node` and `op-geth` will log their configurations at startup - * Check that the Granite time is set to `activation-timestamp` in the op-node startup logs - * Check that the Granite time is set to `activation-timestamp` in the op-geth startup logs - diff --git a/pages/builders/notices/holocene-changes.mdx b/pages/builders/notices/holocene-changes.mdx new file mode 100644 index 000000000..7fd4d0aee --- /dev/null +++ b/pages/builders/notices/holocene-changes.mdx @@ -0,0 +1,84 @@ +--- +title: Preparing for Holocene Breaking Changes +lang: en-US +description: Learn how to prepare for Holocene upgrade breaking changes. +--- + +import { Steps, Callout } from 'nextra/components' + +# Preparing for Holocene breaking changes + +This page outlines breaking changes related to the Holocene network upgrade for chain operators, and node operators. +If you experience difficulty at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). + + + The Holocene upgrade for the Sepolia Superchain will be activated at **Tue Nov 26 at 15:00:00 UTC** (`1732633200`). + + The Holocene upgrade for the Mainnet Superchain is optimistically scheduled for **Thu 9 Jan 2025 18:00:01 UTC**, pending governance approval. + + +## What's included in Holocene + +Holocene contains three changes: + +* **Holocene block derivation**: a set of changes that render the derivation pipeline stricter and simpler, improving worst-case scenarios for the Fault Proof System and Interoperability. +* **EIP-1559 configurability**: The elasticity and denominator EIP-1559 parameters become configurable via the `SystemConfig` L1 contract, allowing the gas target and gas limit to be configured independently. +* **MIPS contract upgrade**: Updates to support additional calls made by the new `op-program` version. + +For more information on the Holocene implementation details, please review [Holocene specification](https://specs.optimism.io/protocol/holocene/overview.html). + +## For chain operators + +Chain operators should upgrade their nodes ahead of the activation times to a release that contains the Holocene changes and has the activation times for their chains baked in, or set the activation times manually via overrides. + +Besides this, chain operators must upgrade their chain's `SystemConfig` to the latest OP Contracts [v1.8.0-rc.2 release](https://github.com/ethereum-optimism/optimism/releases/tag/op-contracts%2Fv1.8.0-rc.2) to utilize the EIP-1559 configurability. The updated `SystemConfig` implementations are deployed at addresses: + +* Sepolia: `0x29d06Ed7105c7552EFD9f29f3e0d250e5df412CD` +* Mainnet: TBD + +Chain operators need to update their proxy contracts to point to these new implementations. An upgrade script in the monorepo can be used to facilitate the upgrade, please follow the instructions in this [README](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.8.0-rc.2/packages/contracts-bedrock/scripts/upgrades/holocene/README.md). Note that it is recommended to upgrade the SystemConfig after the Holocene activation. You need to upgrade if you want to reconfigure your EIP-1559 parameters. + +### For fault proof enabled chains + +Since the Holocene upgrade changes the execution and derivation rules, the version of `op-program` used in the fault proof system has to be upgraded to a version that includes the Holocene activation date for the chain. The `op-program` version used is specified via the `faultGameAbsolutePrestate` setting, deployed as part of `FaultDisputeGame` and `PermissionedDisputeGame` contracts. Additionally, the `MIPS` contract must be upgraded to support additional calls made by the new `op-program`. + +The `FaultDisputeGame` and `PermissionedDisputeGame` contracts must be deployed separately for each chain. The `MIPS` contract implementation can be shared by all chains and is deployed at: + +* Sepolia: `0x6f86b56d26F60a86Ccd13048993C1cE410565DC1` +* Mainnet: TBD + +Chain operators need to update the `DisputeGameFactory` to use the new `FaultDisputeGame` and `PermissionedDisputeGame` contracts by calling `DisputeGameFactory.setImplementation`. The same upgrade script in the monorepo can be used to facilitate the upgrade, please follow the instructions in this [README](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.8.0-rc.2/packages/contracts-bedrock/scripts/upgrades/holocene/README.md). + +## For node operators + +Node operators will need to upgrade to the respective Holocene releases before the activation dates. + +These following steps are necessary for every node operator: + + + ### Update to the latest release + + * [`op-node` at `v1.10.0`](https://github.com/ethereum-optimism/optimism/releases/tag/op-node%2Fv1.10.0) + * [`op-geth` at `v1.101411.2`](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101411.2) + + ### Configure the Holocene activation date + + + If you are operating a node for an OP Chain that have opted into the [hardfork activation inheritance behavior](https://github.com/ethereum-optimism/superchain-registry/blob/main/docs/hardfork-activation-inheritance.md), the Holocene activation date is part of the `op-node` and `op-geth` nodes. So, no action is needed for the sequencer after upgrading to the latest release. Please skip to [Step 3: Verify Your Configuration](#verify-your-configuration). + + For Sepolia that is: `OP Sepolia`, `Base Sepolia`, `Mode Sepolia`, `Zora Sepolia`, and `Metal Sepolia`. + + + For node operators of not included in the [hardfork activation inheritance behavior](https://github.com/ethereum-optimism/superchain-registry/blob/main/docs/hardfork-activation-inheritance.md), you will need to manually configure the activation. This can be done one of two ways: + + * **Option 1:** Set the activation time in the `rollup.json` for `op-node`. You will still need to set the `override.holocene` flag in `op-geth` if you use this option. + * **Option 2:** Set the activation time via overrides (CLI) in both `op-node` and `op-geth`. These will need to be set on `op-node` and `op-geth` for the sequencer and all other nodes. + + ### Verify Your Configuration + + Make the following checks to verify that your node is properly configured. + + * `op-node` and `op-geth` will log their configurations at startup + * Check that the Holocene time is set to `activation-timestamp` in the op-node startup logs + * Check that the Holocene time is set to `activation-timestamp` in the op-geth startup logs + diff --git a/pages/builders/notices/sdk-deprecation.mdx b/pages/builders/notices/sdk-deprecation.mdx new file mode 100644 index 000000000..4ec4765e9 --- /dev/null +++ b/pages/builders/notices/sdk-deprecation.mdx @@ -0,0 +1,72 @@ +--- +title: Deprecation of the Optimism SDK +lang: en-US +description: This page outlines the details of the Optimism SDK deprecation and guides developers to migrate to using `viem` library. +--- + +## Preparing for Optimism SDK deprecation + +The Optimism SDK will officially be deprecated in Q1 2025. The project is shifting to the `viem` library for a more modern, efficient, and flexible development experience. This change affects all tutorials and resources that previously relied on the Optimism SDK, and relevant documentation has been updated accordingly. + +### Breaking changes to expect + +The migration from the Optimism SDK to [viem](https://viem.sh/op-stack) library brings several breaking changes: + +* **Transaction estimation**: Methods for estimating gas fees will now leverage `viem` APIs. +* **Bridging**: All token bridging actions must be updated to use the `viem` library bridging methods. +* **Cross-chain communication**: `viem` library simplifies the cross-domain messaging functionality. +* **SDK method removal**: All deprecated SDK methods will be unavailable after Q1 2025. + +Developers and users are strongly encouraged to transition to `viem` before the deprecation date to avoid disruptions. + +### Updated tutorials + +We are updating our tutorials to use the `viem` library. + +### For app developers + +If your application currently depends on the Optimism SDK, you will need to migrate to using the `viem` library. +The tutorials have been updated to reflect these changes, and it is critical to update your applications before the deprecation date to maintain compatibility. + +Here are some key points to consider: + +Install new dependencies: Replace the Optimism SDK with `viem` in your project. + +```bash + pnpm remove @eth-optimism/sdk + pnpm add viem +``` + +* Update imports: Replace Optimism SDK imports with `viem` imports. +* Migrate SDK methods: Refactor your code to use equivalent `viem` methods. Refer to the viem documentation and opstack documentation for guidance. +* Test thoroughly: After migration, extensively test your application to ensure all functionality works as expected. + +### For chain operators + +Chain operators utilizing the SDK for cross-chain operations, bridging, or other functions should switch to the `viem` library. +The `viem` library offers more efficient methods to handle these operations. + +Chain operators should be aware of the following: + +* SDK removal: Remove any dependencies on the Optimism SDK in your infrastructure. +* Update tooling: Ensure all tools and scripts are updated to use `viem`. +* Monitor performance: After migration, closely monitor your chain's performance to ensure smooth operation. + +### For node operators + +Node operators will need to ensure that any scripts or services relying on the Optimism SDK are updated to use `viem` library. +These updates will help align with future improvements and scalability efforts across the OP Stack. + +Node operators should take the following steps: + +* Update node software: Ensure your node software is compatible with the latest `viem` libraries. +* Review configuration: Check and update any configuration files that may reference the Optimism SDK. +* Test thoroughly: Perform comprehensive testing in a staging environment before updating production nodes. + +### Need help? + +For further assistance or questions about this migration, feel free to reach through the following channels: + +* Connect with us on [Discord](https://discord.gg/optimism) for community support +* Join us on our [developer forum](https://github.com/ethereum-optimism/developers/discussions) for discussions, questions, and general support. +* Open an [issue on our GitHub repository](https://github.com/ethereum-optimism/docs/issues) for documentation-related concerns diff --git a/pages/builders/tools.mdx b/pages/builders/tools.mdx new file mode 100644 index 000000000..354ca94dd --- /dev/null +++ b/pages/builders/tools.mdx @@ -0,0 +1,25 @@ +--- +title: Tools +description: Welcome to the Optimism developer tools! +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Tools + +Welcome to the Optimism developer tools! + + + + + + + + + + + + + + diff --git a/pages/builders/tools/_meta.json b/pages/builders/tools/_meta.json index d89d5d509..440d418b9 100644 --- a/pages/builders/tools/_meta.json +++ b/pages/builders/tools/_meta.json @@ -3,5 +3,6 @@ "connect": "Connecting", "build": "Building", "monitor": "Monitoring", - "op-tools": "OP Tools" + "op-tools": "OP tools", + "fee-calculator": "Fee calculator" } diff --git a/pages/builders/tools/build.mdx b/pages/builders/tools/build.mdx new file mode 100644 index 000000000..0d039842e --- /dev/null +++ b/pages/builders/tools/build.mdx @@ -0,0 +1,25 @@ +--- +title: Build +lang: en-US +description: >- + Learn about build in the Optimism ecosystem. This guide provides detailed + information and resources about build. +--- + +import { Card, Cards } from 'nextra/components' + +# Build + +This section provides information on account abstraction, block explorers, testnet faucets, op mainnet nft tools and oracles. You'll find guide, reference, tool, api to help you understand and work with these topics. + + + + + + + + + + + + diff --git a/pages/builders/tools/build/_meta.json b/pages/builders/tools/build/_meta.json index 249678234..cbd6ef41d 100644 --- a/pages/builders/tools/build/_meta.json +++ b/pages/builders/tools/build/_meta.json @@ -1,7 +1,7 @@ { "faucets": "Faucets", "oracles": "Oracles", - "nft-tools": "NFT Tools", - "block-explorers": "Block Explorers", - "account-abstraction": "Account Abstraction" + "nft-tools": "NFT tools", + "block-explorers": "Block explorers", + "account-abstraction": "Account abstraction" } \ No newline at end of file diff --git a/pages/builders/tools/build/account-abstraction.mdx b/pages/builders/tools/build/account-abstraction.mdx index 8d9bf410c..2bf29a299 100644 --- a/pages/builders/tools/build/account-abstraction.mdx +++ b/pages/builders/tools/build/account-abstraction.mdx @@ -1,12 +1,12 @@ --- -title: Account Abstraction +title: Account abstraction lang: en-US description: This guide explains how to use account abstraction to remove friction from your app experience --- import { Callout } from 'nextra/components' -# Account Abstraction +# Account abstraction This page includes providers that meet specific [inclusion criteria](#inclusion-criteria), as outlined below. Please visit the [community account abstractions page](https://github.com/ethereum-optimism/developers/blob/main/community/tools/account-abstraction.md) for an additional listing of third-party account abstraction tools. @@ -19,11 +19,21 @@ import { Callout } from 'nextra/components' * Sponsor the gas fees for transactions * Enable users to pay gas in the token(s) of their choice -## Superchain Paymaster +## Bundlers -The Superchain paymaster is an ERC-4337 verifying paymaster that sponsors transactions for smart accounts on the Superchain. Use the Superchain Paymaster to get your transactions sponsored to remove friction from your app experience. [View the implementation guide and tutorials here.](https://github.com/ethereum-optimism/ecosystem/tree/main/docs/superchain-paymaster) +The OP Stack includes support for the `eth_sendRawTransactionConditional` RPC method to assist bundlers on shared 4337 mempools. See the [specification](/stack/features/send-raw-transaction-conditional) for how this method is implemented in op-geth. -## Account Abstraction Tools +If used by the chain operator, also see the supplemental [op-txproxy](/builders/chain-operators/tools/op-txproxy) service which may apply additional restrictions prior to reaching the block builder. + + + As of today, this endpoint is not enabled by default in the stack. The operator must explicitly configure this. + + +## Superchain paymaster + +The Superchain paymaster is an ERC-4337 verifying paymaster that sponsors transactions for smart accounts on the Superchain. Use the Superchain Paymaster to get your transactions sponsored to remove friction from your app experience. + +## Account abstraction tools Ready to enable account abstraction experiences in your app? Here's some helpful information on account abstraction infrastructure like ERC-4337 bundler and gas manager APIs that are available on OP Mainnet: @@ -42,15 +52,15 @@ Ready to enable account abstraction experiences in your app? Here's some helpful * [Stackup](https://docs.stackup.sh/docs): provides smart account tooling for building account abstraction within your apps. They offer Paymaster and Bundler APIs for sponsoring gas and sending account abstraction transactions. -* [Thirdweb](https://portal.thirdweb.com/connect/account-abstraction/overview): +* [thirdweb](https://portal.thirdweb.com/react/v5/account-abstraction/get-started?utm_source=opdocs&utm_medium=docs): offers the complete tool-kit to leverage account abstraction technology to enable seamless user experiences for your users. This includes Account Factory contracts that lets your users spin up Smart Accounts, Bundler for UserOps support, and Paymaster to enable gas sponsorships. -## Helpful Tips +## Helpful tips * [EIP-1271 Signature Validation](https://eip1271.io/) * [Making smart accounts work with WalletConnect v2](https://safe-global.notion.site/WalletConnect-v2-update-Issues-and-solutions-for-smart-wallets-3fc32fad6af4485fa5823eaebd486819) -## Inclusion Criteria +## Inclusion criteria Developer teams who want to feature products/tools on this page must meet the following criteria: diff --git a/pages/builders/tools/build/block-explorers.mdx b/pages/builders/tools/build/block-explorers.mdx index e72e8da6e..cd179fc87 100644 --- a/pages/builders/tools/build/block-explorers.mdx +++ b/pages/builders/tools/build/block-explorers.mdx @@ -1,12 +1,12 @@ --- -title: Block Explorers +title: Block explorers lang: en-US description: Learn about different block explorers you can use to interact with contracts and view transaction history for OP Mainnet and OP Sepolia. --- import { Callout } from 'nextra/components' -# Block Explorers +# Block explorers This reference guide lists different block explorers you can use to interact with contract source code and view transaction history for OP Mainnet and OP Sepolia. @@ -65,12 +65,12 @@ Once Upon currently supports: * Mainnet - Ethereum, OP Mainnet, Base, Zora, Public Goods Network * Sepolia - Ethereum, OP Sepolia, Base, Zora, Public Goods Network, Lyra, Mode -## Access to Pre-Regenesis History +## Access to pre-regenesis history Because of our final regenesis on 11 November 2021, older transactions are not part of the current blockchain and do not appear on [Etherscan](https://explorer.optimism.io/). However, you **can** access transaction history between 23 June 2021 and the final regenesis using a number of different tools. For detailed instructions, see [Regenesis History](/builders/tools/monitor/regenesis-history). -## Inclusion Criteria +## Inclusion criteria Developer teams who want to feature products/tools on this page must meet the following criteria: diff --git a/pages/builders/tools/build/faucets.mdx b/pages/builders/tools/build/faucets.mdx index 54467f03e..8c815513a 100644 --- a/pages/builders/tools/build/faucets.mdx +++ b/pages/builders/tools/build/faucets.mdx @@ -1,12 +1,12 @@ --- -title: Testnet Faucets +title: Testnet faucets lang: en-US description: Learn how to get testnet ETH on test networks like Sepolia and OP Sepolia for development and testing purposes. --- import { Callout } from 'nextra/components' -# Testnet Faucets +# Testnet faucets Faucets are developers tools that allow you to get free ETH (and other tokens) on test networks like Sepolia and OP Sepolia so that you can send transactions and create smart contracts. Here you'll find a list of active faucets that you can try out. @@ -22,31 +22,31 @@ Faucets can occasionally also run out of ETH, so if you're having trouble gettin Optimists only take what they need so that others can use faucets too! -## Superchain Faucet +## Superchain faucet The [Superchain Faucet](https://console.optimism.io/faucet?utm_source=docs) is a developer tool hosted by Optimism that allows developers to get free testnet ETH to test apps on testnet OP Chains like Base Sepolia, OP Sepolia, PGN Sepolia, Zora Sepolia, and other OP Chains in the Superchain. The Superchain Faucet is a great place to start if you're looking for testnet ETH. -## Additional Faucets - -| Faucet Name | Supported Networks | -| -------------------------------------------------------------------------------- | -------------------------------------------------------- | -| [Alchemy Faucet](https://sepoliafaucet.com) | Sepolia | -| [Infura Faucet](https://www.infura.io/faucet/sepolia) | Sepolia | -| [QuickNode Faucet](https://faucet.quicknode.com/optimism/) | Sepolia, OP Sepolia | -| [Farcaster Frame Faucet by LearnWeb3](https://warpcast.com/haardikkk/0x28f4237d) | Sepolia, OP Sepolia | -| [LearnWeb3 Web App Faucet](https://learnweb3.io/faucets) | Sepolia, OP Sepolia | -| [Native USDC Faucet](https://faucet.circle.com/) | Sepolia, OP Sepolia | -| [ETHGlobal Testnet Faucet](https://ethglobal.com/faucet) | Sepolia, OP Sepolia, Base Sepolia, Zora Sepolia, Holesky | -| [Ethereum Ecosystem Faucets](https://www.ethereum-ecosystem.com/faucets) | Sepolia, OP Sepolia, Base Sepolia | -| [Thirdweb Sepolia Faucet](https://thirdweb.com/sepolia) | Sepolia | -| [Thirdweb OP Sepolia Faucet](https://thirdweb.com/op-sepolia-testnet) | OP Sepolia | +## Additional faucets + +| Faucet Name | Supported Networks | +| -------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | +| [Alchemy Faucet](https://sepoliafaucet.com) | Sepolia | +| [Infura Faucet](https://www.infura.io/faucet/sepolia) | Sepolia | +| [QuickNode Faucet](https://faucet.quicknode.com/optimism/) | Sepolia, OP Sepolia | +| [Farcaster Frame Faucet by LearnWeb3](https://warpcast.com/haardikkk/0x28f4237d) | Sepolia, OP Sepolia | +| [LearnWeb3 Web App Faucet](https://learnweb3.io/faucets) | Sepolia, OP Sepolia | +| [Native USDC Faucet](https://faucet.circle.com/) | Sepolia, OP Sepolia | +| [ETHGlobal Testnet Faucet](https://ethglobal.com/faucet) | Sepolia, OP Sepolia, Base Sepolia, Zora Sepolia, Holesky | +| [Ethereum Ecosystem Faucets](https://www.ethereum-ecosystem.com/faucets) | Sepolia, OP Sepolia, Base Sepolia | +| [thirdweb Sepolia Faucet](https://thirdweb.com/sepolia?utm_source=opdocs\&utm_medium=docs) | Sepolia | +| [thirdweb OP Sepolia Faucet](https://thirdweb.com/op-sepolia-testnet?utm_source=opdocs\&utm_medium=docs) | OP Sepolia | ## Bridge from Sepolia If you have testnet ETH on Sepolia, you can bridge it to OP Sepolia (and vice versa) using the [Superchain Bridges UI](https://app.optimism.io/bridge) or this collection of [Superchain Testnet Tools](https://www.superchain.tools/). -## Inclusion Criteria +## Inclusion criteria Developer teams who want to feature products/tools on this page must meet the following criteria: @@ -57,7 +57,7 @@ Developer teams who want to feature products/tools on this page must meet the fo For teams that are supporting but still establishing a user base, we encourage you to share your tool on the [community faucets page](https://github.com/ethereum-optimism/developers/blob/main/community/tools/faucets.md). You can also promote your tool in the [developer forum](https://github.com/ethereum-optimism/developers/discussions/categories/show-and-tell) and signup to share your tool at the next [demo day](https://community.optimism.io/docs/contribute/demo-day/). -## Next Steps +## Next steps * If you're new to onchain development, check out [Optimism Unleashed](https://cryptozombies.io/en/optimism) by CryptoZombies and [Superchain Builder NFT](https://web.archive.org/web/20231218203510/https://blog.thirdweb.com/guides/optimism-superchain-faucet-nft/) by ThirdWeb. * If you're familiar with onchain development, check out the [Optimism Ecosystem's Contributions Dashboard](https://github.com/ethereum-optimism/ecosystem-contributions) for project ideas that the Optimism Collective is looking for. diff --git a/pages/builders/tools/build/nft-tools.mdx b/pages/builders/tools/build/nft-tools.mdx index 270f3f636..3e0f650bc 100644 --- a/pages/builders/tools/build/nft-tools.mdx +++ b/pages/builders/tools/build/nft-tools.mdx @@ -1,12 +1,12 @@ --- -title: OP Mainnet NFT Tools +title: OP Mainnet NFT tools lang: en-US description: Learn the basics of creating an NFT on OP Mainnet. --- import { Callout } from 'nextra/components' -# OP Mainnet NFT Tools +# OP Mainnet NFT tools ## The OP Mainnet NFT ecosystem @@ -23,7 +23,7 @@ These tools are available on OP Mainnet: * [NiftyKit](https://niftykit.com/) * [nft-inator](https://nft-inator.com/) * [Unlock](https://unlock-protocol.com/) (time-bound NFTs for membership) -* [ThirdWeb](https://thirdweb.com/) +* [thirdweb](https://thirdweb.com/?utm_source=opdocs\&utm_medium=docs) * [Crossmint](https://crossmint.com/?utm_source=backlinks\&utm_medium=docs\&utm_campaign=optimism) ## Feature comparison @@ -32,21 +32,21 @@ These tools are available on OP Mainnet: This list was last updated early February 2024, but new features are implemented all the time. -| | NiftyKit | NFT-Inator | Mintplex | Zero Code NFT | ThirdWeb | Crossmint | -| ------------------ | -------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------- | -------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Multi-chain | 3 | 5 | 6 | 11 | 1100+ [(all EVM chains)](https://thirdweb.com/dashboard/infrastructure/rpc-edge) | 9 | -| Generator | ❌ | βœ… | ❌ | ❌ | ❌ | ❌ | -| ERC-20 support | ❌ | ❌ | βœ… | βœ… | βœ… | ❌ | -| ERC-721A support | βœ… | βœ… | βœ… | βœ… | βœ… | βœ… | -| ERC-1155 support | ❌ | ❌ | βœ… | ❌ | βœ… | βœ… | -| DAO support | ❌ | ❌ | ❌ | βœ… | βœ… | ❌ | -| No Code deployment | βœ… | βœ… | βœ… | βœ… | βœ… | βœ… | -| Pricing / Fee | [Flat membership fee plus 2.5%-10% of the sales](https://app.niftykit.com) | 2% commission on primary sales | Paywall for premium features | Test for free, $499 for OpenSea setup | See the [pricing page](https://thirdweb.com/pricing) for more details | [Mint API Pricing](https://docs.crossmint.com/docs/pricing?utm_source=backlinks\&utm_medium=docs\&utm_campaign=optimism). NFT Checkouts free for seller (Unlimited transactions). | -| Image Hosting | [NFT storage](https://nft.storage/) / [Pinata](https://www.pinata.cloud/) | [NFT storage](https://nft.storage/) / [Pinata](https://www.pinata.cloud/) | Up to creators. Recommend [Pinata](https://www.pinata.cloud/) | [IPFS](https://ipfs.tech/) | [IPFS](https://ipfs.tech/) | [IPFS](https://ipfs.tech/) and [Arweave](https://www.arweave.org/). | +| | NiftyKit | NFT-Inator | Mintplex | Zero Code NFT | thirdweb | Crossmint | +| ------------------ | -------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Multi-chain | 3 | 5 | 6 | 11 | 2500+ [(all EVM chains)](https://thirdweb.com/dashboard/infrastructure/rpc-edge?utm_source=opdocs\&utm_medium=docs) | 9 | +| Generator | ❌ | βœ… | ❌ | ❌ | ❌ | ❌ | +| ERC-20 support | ❌ | ❌ | βœ… | βœ… | βœ… | ❌ | +| ERC-721A support | βœ… | βœ… | βœ… | βœ… | βœ… | βœ… | +| ERC-1155 support | ❌ | ❌ | βœ… | ❌ | βœ… | βœ… | +| DAO support | ❌ | ❌ | ❌ | βœ… | βœ… | ❌ | +| No Code deployment | βœ… | βœ… | βœ… | βœ… | βœ… | βœ… | +| Pricing / Fee | [Flat membership fee plus 2.5%-10% of the sales](https://app.niftykit.com) | 2% commission on primary sales | Paywall for premium features | Test for free, $499 for OpenSea setup | See the [pricing page](https://thirdweb.com/pricing) for more details | [Mint API Pricing](https://docs.crossmint.com/docs/pricing?utm_source=backlinks\&utm_medium=docs\&utm_campaign=optimism). NFT Checkouts free for seller (Unlimited transactions). | +| Image Hosting | [NFT storage](https://nft.storage/) / [Pinata](https://www.pinata.cloud/) | [NFT storage](https://nft.storage/) / [Pinata](https://www.pinata.cloud/) | Up to creators. Recommend [Pinata](https://www.pinata.cloud/) | [IPFS](https://ipfs.tech/) | [IPFS](https://ipfs.tech/) | [IPFS](https://ipfs.tech/) and [Arweave](https://www.arweave.org/). | ## NFT data APIs -* [Moralis](https://docs.moralis.io/web3-data-api/evm/reference/nft-api?utm_source=op-docs&utm_medium=partner-docs) +* [Moralis](https://docs.moralis.io/web3-data-api/evm/reference/nft-api?utm_source=op-docs\&utm_medium=partner-docs) * [Alchemy](https://docs.alchemy.com/reference/nft-api-quickstart) * [SimpleHash](https://simplehash.com/) * [QuickNode](https://www.quicknode.com/nft-api) @@ -59,7 +59,3 @@ These tools are available on OP Mainnet: * [Tofu](https://tofunft.com/optimism) * [OptiMarket](https://optimarket.io/) * [Circular Art](https://www.circularart.xyz/) - -## Marketplace aggregators - -* [Bluesweep](https://www.bluesweep.xyz/) diff --git a/pages/builders/tools/build/oracles.mdx b/pages/builders/tools/build/oracles.mdx index 378ea8d16..d3da77ea8 100644 --- a/pages/builders/tools/build/oracles.mdx +++ b/pages/builders/tools/build/oracles.mdx @@ -2,6 +2,7 @@ title: Oracles lang: en-US description: Learn about different oracles and how you can use them to access offchain data onchain as well as random number generation. +tags: ["devops-tooling", "performance-tooling", "eng-devx"] --- import { Callout } from 'nextra/components' @@ -18,12 +19,12 @@ For example, a [stablecoin](https://ethereum.org/en/stablecoins/) that accepts E * How many stablecoins can we give a user for a given amount of ETH? * Do we need to liquidate any deposits because they are under collateralized? -## Security and Decentralization +## Security and decentralization Different oracles have different security assumptions and different levels of decentralization. Usually they are either run by the organization that produces the information, or have a mechanism to reward entities that provide accurate information and penalize those that provide incorrect information. -## Types of Oracles +## Types of oracles There are two types of oracles: @@ -37,13 +38,13 @@ There are two types of oracles: 2. Single-transaction oracles, which only require one transaction. The way this works is that the transaction that requests the information includes a callback (address and the call data to provide it). When the oracle is updated (which also happens through a transaction, but one that is not sent by the user), the oracle uses the callback to inform a contract of the result. -## Random Number Generation (RGN) +## Random number generation (RGN) Random number generation in blockchain applications ensures that smart contracts can access unbiased random values. This is essential for certain use cases like generative NFTs, gaming, commit & reveal schemes and more. Various approaches include using a trusted third party, blockhash-based methods, Verifiable Random Functions (VRF), quantum random numbers to name a few. Each method has trade-offs between simplicity, security, and trust assumptions, allowing developers to select the most suitable option for their use case. -## List of Oracles +## List of oracles -### Gas Oracle +### Gas oracle OP Mainnet provides a [Gas Price Oracle](https://github.com/ethereum-optimism/optimism/blob/233ede59d16cb01bdd8e7ff662a153a4c3178bdd/packages/contracts/contracts/L2/predeploys/OVM_GasPriceOracle.sol) that provides information about [gas prices and related parameters](/stack/transactions/fees). It can also calculate the total cost of a transaction for you before you send it. @@ -57,6 +58,9 @@ This is a push Oracle. OP Mainnet (and the testnets) updates the gas price parameters onchain whenever those parameters change. The L1 gas price, which can be volatile, is only pushed once every 5 minutes, and each time can change only by up to 20%. +* [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. @@ -130,7 +134,7 @@ Builders can choose how they want to consume the data among 3 dedicated models: Interested in integration? [Get in contact](https://discord.com/invite/PVxBZKFr46) with the RedStone team! -## Inclusion Criteria +## Inclusion criteria Developer teams who want to feature products/tools on this page must meet the following criteria: @@ -141,7 +145,7 @@ Developer teams who want to feature products/tools on this page must meet the fo For teams that are supporting but still establishing a user base, we encourage you to share your tool on the [community oracles page](https://github.com/ethereum-optimism/developers/blob/main/community/tools/oracles.md). You can also promote your tool in the [developer forum](https://github.com/ethereum-optimism/developers/discussions/categories/show-and-tell) and signup to share your tool at the next [demo day](https://community.optimism.io/docs/contribute/demo-day/). -## Next Steps +## Next steps * Please visit the [community oracles page](https://github.com/ethereum-optimism/developers/blob/main/community/tools/oracles.md) for a listing of third-party Oracles used by the Optimism developer community. * Looking for other developer tools? See [developer tools overview](/builders/tools/overview) to explore more options! diff --git a/pages/builders/tools/connect.mdx b/pages/builders/tools/connect.mdx new file mode 100644 index 000000000..50154b1f4 --- /dev/null +++ b/pages/builders/tools/connect.mdx @@ -0,0 +1,19 @@ +--- +title: Connect +lang: en-US +description: >- + Learn about connect in the Optimism ecosystem. This guide provides detailed + information and resources about connect. +--- + +import { Card, Cards } from 'nextra/components' + +# Connect + +This section provides information on networks and rpc & node providers. You'll find reference to help you understand and work with these topics. + + + + + + diff --git a/pages/builders/tools/connect/_meta.json b/pages/builders/tools/connect/_meta.json index f0051842b..5c7bf46ce 100644 --- a/pages/builders/tools/connect/_meta.json +++ b/pages/builders/tools/connect/_meta.json @@ -1,4 +1,4 @@ { - "networks": "Networks and RPC Endpoints", - "rpc-providers": "RPC Providers" + "networks": "Networks and RPC endpoints", + "rpc-providers": "RPC providers" } \ No newline at end of file diff --git a/pages/builders/tools/connect/networks.mdx b/pages/builders/tools/connect/networks.mdx index f7a9e91cb..7440c93ec 100644 --- a/pages/builders/tools/connect/networks.mdx +++ b/pages/builders/tools/connect/networks.mdx @@ -1,4 +1,9 @@ --- +title: OPNetworks +lang: en-US +description: >- + Learn about networks in the Optimism ecosystem. This guide provides detailed + information and resources about networks. --- import OPNetworks from '@/pages/chain/networks.mdx' diff --git a/pages/builders/tools/connect/rpc-providers.mdx b/pages/builders/tools/connect/rpc-providers.mdx index 20010e015..2b2d13afa 100644 --- a/pages/builders/tools/connect/rpc-providers.mdx +++ b/pages/builders/tools/connect/rpc-providers.mdx @@ -1,59 +1,72 @@ --- -title: RPC & Node Providers +title: RPC & Node providers lang: en-US description: Learn about different RPC and node providers to help you connect to an Optimism node. --- import { Callout } from 'nextra/components' -# RPC & Node Providers +# RPC & Node providers This reference guide lists different RPC and node providers to help you connect to an Optimism node. -This page includes providers that meet specific [inclusion criteria](#inclusion-criteria), as outlined below. Please visit the [community node providers page](https://github.com/ethereum-optimism/developers/blob/main/community/tools/node-providers.md) for an additional listing of third-party node providers. + This page includes providers that meet specific [inclusion criteria](#inclusion-criteria), as outlined below. Please visit the [community node providers page](https://github.com/ethereum-optimism/developers/blob/main/community/tools/node-providers.md) for an additional listing of third-party node providers. ## Ankr -### Description and Pricing +### Description and pricing [Ankr](https://www.ankr.com/) provides a geo-distributed and decentralized (free) public and premium (Pay-as-you-go) [Optimism RPC](https://www.ankr.com/rpc/optimism/) comprised of many independent blockchain nodes running worldwide for low-latency and incredibly reliable connections. Moreover, Ankr offers access to developer tooling on OP Mainnet (and testnets) like SDKs and [Advanced APIs](https://www.ankr.com/advanced-api/) such as NFT, Token and Query API. -### Supported Networks +### Supported networks * OP Mainnet * OP Sepolia ## Alchemy -### Description and Pricing +### Description and pricing [Alchemy](https://docs.alchemy.com/reference/optimism-api-quickstart/?a=818c11a8da) is a popular API provider and developer platform. Its robust, free tier offers access to enhanced features like SDKs and enhanced APIs and hosted OP Mainnet and testnet nodes. -### Supported Networks +### Supported networks * OP Mainnet * OP Sepolia +## Blockdaemon + +### Description and pricing + +Blockdaemon provides institutional-grade blockchain infrastructure, including node, staking, and API solutions, with premium RPC services optimized for [Optimism](https://docs.blockdaemon.com/reference/how-to-access-optimism-api). With free and enhanced options, Blockdaemon's RPC API allows developers to securely interact with on-chain data, broadcast transactions, and build dApps with minimal setup, offering streamlined access to enriched blockchain data and 99.9% uptime reliability to meet diverse needs. + +[Sign up for a free Blockdaemon account here](https://app.blockdaemon.com/signin/register) + +### Supported networks + +* OP Mainnet + ## Chainstack -### Description and Pricing +### Description and pricing [Chainstack](https://chainstack.com/build-better-with-optimism/) provides global & regional load-balanced nodes that are full & archive with debug & trace APIs. For the free tier, the Developer plan is available and you can sign up with GitHub account or other social logins. Chainstack also has special discounts available. -### Supported Networks +### Supported networks * OP Mainnet * OP Sepolia ## dRPC -### Description and Pricing -[dRPC](https://drpc.org) provides geo-distributed, auto-scalable OP Mainnet and OP Sepolia nodes. For more information, visit [dRPC's chainlist for Optimism](https://drpc.org/chainlist/optimism). dRPC supports Websocket and all methods, including debug and trace methods. -For early-stage startups, dRPC and Optimism Collective provide OP Mainnet nodes from 3 geo clusters without method restrictions and are totally free! +### Description and pricing + +[dRPC](https://drpc.org) provides geo-distributed, auto-scalable OP Mainnet and OP Sepolia nodes. For more information, visit [dRPC's chainlist for Optimism](https://drpc.org/chainlist/optimism). dRPC supports Websocket and all methods, including debug and trace methods. +For early-stage startups, dRPC and Optimism Collective provide OP Mainnet nodes from 3 geo clusters without method restrictions and are totally free! For commercial nodes, dRPC uses a pay-as-you-go model without hidden fees and rate limits. Feel free to try fast and reliable nodes. Supported Networks @@ -62,42 +75,42 @@ OP Sepolia ## Infura -### Description and Pricing +### Description and pricing [Infura](https://infura.io) is a Web3 infrastructure provider that offers free access to hosted [OP Mainnet and testnet nodes](https://docs.infura.io/infura/networks/optimism), with the option to upgrade to [paid plans](https://www.infura.io/pricing) for more features. With Infura's highly performant Optimism node infrastructure, developers can eliminate the need for syncing or complex setups and get reliable and consistent access to the Optimism blockchain. [Sign up for a free Infura account here](https://app.infura.io/register) -### Supported Networks +### Supported networks * OP Mainnet * OP Sepolia ## Moralis -### Description and Pricing +### Description and pricing -[Moralis](https://moralis.io/?utm_source=op-docs&utm_medium=partner-docs) is a popular Node and API provider for both real-time and indexed blockchain data. Moralis is the only major infrastructure provider in blockchain with a SOC2 Type 2 certification. You can use Moralis for free, or upgrade to a [paid plan](https://moralis.io/pricing/?utm_source=op-docs&utm_medium=partner-docs) for more features and benefits. +[Moralis](https://moralis.io/?utm_source=op-docs\&utm_medium=partner-docs) is a popular Node and API provider for both real-time and indexed blockchain data. Moralis is the only major infrastructure provider in blockchain with a SOC2 Type 2 certification. You can use Moralis for free, or upgrade to a [paid plan](https://moralis.io/pricing/?utm_source=op-docs\&utm_medium=partner-docs) for more features and benefits. -[Sign up for a free Moralis account here](https://admin.moralis.io/register/?utm_source=op-docs&utm_medium=partner-docs) +[Sign up for a free Moralis account here](https://admin.moralis.io/register/?utm_source=op-docs\&utm_medium=partner-docs) -### Supported Networks +### Supported networks * OP Mainnet ## QuickNode -### Description and Pricing +### Description and pricing [QuickNode](https://www.quicknode.com/) offers access to hosted OP Mainnet (and testnet) nodes for free. With the option to upgrade to a premium plan for additional features, we allow you to focus solely on optimizing your application while we manage the complex infrastructure. -### Supported Networks +### Supported networks * OP Mainnet * OP Sepolia -## Inclusion Criteria +## Inclusion criteria Developer teams who want to feature products/tools on this page must meet the following criteria: @@ -108,7 +121,7 @@ Developer teams who want to feature products/tools on this page must meet the fo For teams that are supporting but still establishing a user base, we encourage you to share your tool on the [community node providers page](https://github.com/ethereum-optimism/developers/blob/main/community/tools/node-providers.md). You can also promote your tool in the [developer forum](https://github.com/ethereum-optimism/developers/discussions/categories/show-and-tell) and signup to share your tool at the next [demo day](https://community.optimism.io/docs/contribute/demo-day/). -## Next Steps +## Next steps * Please visit the [community node providers page](https://github.com/ethereum-optimism/developers/blob/main/community/tools/node-providers.md) for a listing of third-party node providers used by the Optimism developer community. * Looking for other developer tools? See [developer tools overview](/builders/tools/overview) to explore more options! diff --git a/pages/builders/tools/fee-calculator.mdx b/pages/builders/tools/fee-calculator.mdx new file mode 100644 index 000000000..053cf3601 --- /dev/null +++ b/pages/builders/tools/fee-calculator.mdx @@ -0,0 +1,22 @@ +--- +title: Fjord fee parameter calculator +lang: en-US +description: Use the Fjord Fee Parameter Calculator to estimate and calculate fees for transactions. +--- + +import { ChainParametersForm } from '@/components/calculator/ChainParametersForm' + +# Fjord fee parameter calculator + +The Fjord Fee Parameter Calculator helps you estimate transaction fees. Use this tool to: + +* Calculate potential fees for different transaction types. +* Understand how network parameters affect fee calculations. + +## How to use the calculator + +1. Input the relevant parameters in the form below. +2. The calculator will automatically update the fee estimates based on your inputs. +3. Adjust the parameters as needed to see how they affect the fee calculations. + + diff --git a/pages/builders/tools/monitor.mdx b/pages/builders/tools/monitor.mdx new file mode 100644 index 000000000..848483480 --- /dev/null +++ b/pages/builders/tools/monitor.mdx @@ -0,0 +1,19 @@ +--- +title: Monitor +lang: en-US +description: >- + Learn about monitor in the Optimism ecosystem. This guide provides detailed + information and resources about monitor. +--- + +import { Card, Cards } from 'nextra/components' + +# Monitor + +This section provides information on analytics tools and accessing pre regenesis history. You'll find guide, tool to help you understand and work with these topics. + + + + + + diff --git a/pages/builders/tools/monitor/_meta.json b/pages/builders/tools/monitor/_meta.json index c2459cfce..f37b60762 100644 --- a/pages/builders/tools/monitor/_meta.json +++ b/pages/builders/tools/monitor/_meta.json @@ -1,4 +1,4 @@ { "analytics-tools": "Analytics", - "regenesis-history": "Historical Data" + "regenesis-history": "Historical data" } \ No newline at end of file diff --git a/pages/builders/tools/monitor/analytics-tools.mdx b/pages/builders/tools/monitor/analytics-tools.mdx index aa3a39031..f7d39d0a7 100644 --- a/pages/builders/tools/monitor/analytics-tools.mdx +++ b/pages/builders/tools/monitor/analytics-tools.mdx @@ -1,12 +1,12 @@ --- -title: Analytics Tools +title: Analytics tools lang: en-US description: Learn about platforms you can use to gather analytics and setup customizations about OP Mainnet. --- import { Callout } from 'nextra/components' -# Analytics Tools +# Analytics tools The following guide lists platforms you can use to gather analytics and setup customizations about OP Mainnet. @@ -31,7 +31,7 @@ It helps you to inspect states at every instance of transaction and gives a plat * [setup real-time alerts for smart contracts](https://blog.tenderly.co/how-to-set-up-real-time-alerting-for-smart-contracts-with-tenderly/) * [automate your responses to alert triggers](https://blog.tenderly.co/tenderly-alert-webhooks/) with custom webhooks -## Dune Analytics +## Dune analytics [Dune Analytics](https://dune.com) allows anyone to create dashboards that present information about OP Chains (OP Mainnet, Base, and Zora are available). See [Dune Docs](https://dune.com/docs/) for more info. You can find a list of community created dashboards for OP Chains [here](https://dune.com/browse/dashboards?q=tags%3Aop%2Coptimism%2Csuperchain\&order=trending\&time_range=24h), or [create your own](https://docs.dune.com/#queries) dashboard. @@ -44,7 +44,7 @@ Here are some of our favorite dashboards so far: * [OP Token House Delegates](https://dune.com/optimismfnd/optimism-op-token-house) * [Superchain NFTs](https://dune.com/oplabspbc/superchain-nfts) -## Additional Tools and Resources +## Additional tools and resources Here are some additional tools and resources for OP Mainnet analytics and development: diff --git a/pages/builders/tools/monitor/regenesis-history.mdx b/pages/builders/tools/monitor/regenesis-history.mdx index c3e08c990..c262e7ae3 100644 --- a/pages/builders/tools/monitor/regenesis-history.mdx +++ b/pages/builders/tools/monitor/regenesis-history.mdx @@ -1,29 +1,19 @@ --- -title: Accessing Pre-Regenesis History +title: Accessing pre-regenesis history lang: en-US description: Learn how to use access pre-regenesis history using the Etherscan CSV exporting tool. --- import { Callout, Steps } from 'nextra/components' -# Accessing Pre-Regenesis History +# Accessing pre-regenesis history -This tutorial explains how to access transaction history between 23 June 2021 and the final regenesis using the Etherscan CSV exporting tool. +This tutorial explains how to access transaction history between 23 June 2021 and the final regenesis. Because of our final regenesis on 11 November 2021, older transactions are not part of the current blockchain and do not appear on [Etherscan](https://explorer.optimism.io/). -## Etherscan access - - - ### Browse to the [Optimism Explorer](https://explorer.optimism.io/exportDataMain). - - ### Select your address and the type of report you want. - - ![Etherscan data export page.](/img/op-mainnet/tools/export.png) - - ## Dune access -If none of the Etherscan CSV files contains the information you need, you can use a query on [Dune Analytics](https://dune.com), similar to [this query](https://dune.com/queries/354886?addr=%5Cx25E1c58040f27ECF20BBd4ca83a09290326896B3). +You can use a query on [Dune Analytics](https://dune.com), similar to [this query](https://dune.com/queries/354886?addr=%5Cx25E1c58040f27ECF20BBd4ca83a09290326896B3). You have to log on with a Dune account, but their free tier is sufficient. @@ -36,7 +26,7 @@ You have to log on with a Dune account, but their free tier is sufficient. Alternatively, to run custom queries in Dune, you can use the `optimism_legacy_ovm1` schema defined in [Dune Docs here](https://dune.com/docs/data-tables/?h=ovm#optimism). -## Lost Data Directories +## Lost data directories Three data directories that were used by legacy L2Geth Sequencer instances during the period of January 2021 to July 2021 had been errantly deleted during @@ -70,9 +60,9 @@ requests for this data came from individuals who needed access to this informati for the 2021 tax season though this is mostly no longer relevant today (many people who needed this data already retrieved it). -### Going Forward +### Going forward We recognize the inconvenience this has caused some of our community and their -uses and we're sorry for the frustrations. In an effort to prevent similar +users and we're sorry for the frustrations. In an effort to prevent similar situations from happening again in the future, we are evaluating and updating existing processes and frameworks. diff --git a/pages/builders/tools/op-tools.mdx b/pages/builders/tools/op-tools.mdx new file mode 100644 index 000000000..4335cef41 --- /dev/null +++ b/pages/builders/tools/op-tools.mdx @@ -0,0 +1,15 @@ +--- +title: Op Tools +lang: en-US +description: >- + Learn about op tools in the Optimism ecosystem. This guide provides detailed + information and resources about op tools. +--- + +import { Card, Cards } from 'nextra/components' + +# Op Tools + +This section provides information on . + + diff --git a/pages/builders/tools/op-tools/_meta.json b/pages/builders/tools/op-tools/_meta.json index fcc07acdc..4886952ac 100644 --- a/pages/builders/tools/op-tools/_meta.json +++ b/pages/builders/tools/op-tools/_meta.json @@ -1,11 +1,11 @@ { "block-explorer": { - "title": "OP Mainnet Explorer", + "title": "OP Mainnet explorer", "href": "https://optimistic.etherscan.io/", "newWindow": true }, "bridge": { - "title": "Superchain Bridges", + "title": "Superchain bridges", "href": "https://app.optimism.io/bridge", "newWindow": true }, @@ -15,18 +15,18 @@ "newWindow": true }, "faucet": { - "title": "Superchain Faucet", + "title": "Superchain faucet", "type": "page", "href": "https://console.optimism.io/faucet?utm_source=docs", "newWindow": true }, "console": { - "title": "Superchain Dev Console", + "title": "Superchain dev console", "href": "https://console.optimism.io/?utm_source=docs", "newWindow": true }, "gas": { - "title": "Gas Tracker", + "title": "Gas tracker", "type": "page", "href": "https://optimistic.grafana.net/public-dashboards/c84a5a9924fe4e14b270a42a8651ceb8?orgId=1&refresh=5m", "newWindow": true diff --git a/pages/builders/tools/overview.mdx b/pages/builders/tools/overview.mdx index cb146b2fa..c3069e116 100644 --- a/pages/builders/tools/overview.mdx +++ b/pages/builders/tools/overview.mdx @@ -1,12 +1,12 @@ --- -title: Developer Tools +title: Developer tools lang: en-US description: Learn about different developer tools you can use to help you build on Optimism. --- import { Cards, Card } from 'nextra/components' -# Developer Tools +# Developer tools Welcome to the Optimism developer tools! @@ -43,18 +43,21 @@ If you are already familiar with [building on OP Mainnet](/chain/getting-started } /> -## OP Tools +## OP tools } /> } /> - } /> + } /> } /> } /> } /> + + } /> + diff --git a/pages/chain/_meta.json b/pages/chain/_meta.json index 120d2dc16..6c45f77d2 100644 --- a/pages/chain/_meta.json +++ b/pages/chain/_meta.json @@ -1,9 +1,8 @@ { - "getting-started": "Getting Started: OP Mainnet", - "differences": "Differences Between Ethereum and OP Mainnet", + "getting-started": "Getting started: OP Mainnet", "networks": "Networks and RPC Endpoints", - "addresses": "Contract Addresses", - "tokenlist": "Bridged Token Addresses", + "addresses": "Contract addresses", + "tokenlist": "Bridged token addresses", "identity": "Identity", "testing": "Testing", "security": "Security" diff --git a/pages/chain/addresses.mdx b/pages/chain/addresses.mdx index 4317dbf7d..b768b476d 100644 --- a/pages/chain/addresses.mdx +++ b/pages/chain/addresses.mdx @@ -1,5 +1,5 @@ --- -title: Contract Addresses +title: Contract addresses lang: en-US description: This reference guide lists all the contract addresses for Mainnet and Testnet. --- @@ -15,7 +15,7 @@ This reference guide lists all the contract addresses for Mainnet and Testnet, a See the [Smart Contracts Overview](/stack/smart-contracts) for high-level details and access to the source code. -This page is automatically generated from packages in the [superchain-registry](https://github.com/ethereum-optimism/superchain-registry/tree/main) which keeps the content synched and up-to-date. +This page is automatically generated from packages in the [superchain-registry](https://github.com/ethereum-optimism/superchain-registry/tree/main) which keeps the content synced and up-to-date. ## Mainnet diff --git a/pages/chain/differences.mdx b/pages/chain/differences.mdx deleted file mode 100644 index 784911879..000000000 --- a/pages/chain/differences.mdx +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: Differences between Ethereum and OP Mainnet -lang: en-US -description: Learn the minor differences between the behavior of OP Mainnet and Ethereum. ---- - -import { Callout } from 'nextra/components' - -# Differences between Ethereum and OP Mainnet - -OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) and introduces as few changes as possible to the Ethereum protocol. -However, there are some minor differences between the behavior of Ethereum and OP Mainnet that developers should be aware of. - -## Opcodes - -| Opcode | Solidity Equivalent | Behavior | -| ------------ | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `COINBASE` | `block.coinbase` | Returns the address of the current Sequencer's fee wallet. Effectively the same as Ethereum with the caveat the value typically does not change from block to block. | -| `PREVRANDAO` | `block.prevrandao` | Set **pseudorandomly** for each block by the Sequencer as opposed to the stronger guarantees provided by [RANDAO](https://eips.ethereum.org/EIPS/eip-4399) on Ethereum. | -| `ORIGIN` | `tx.origin` | If the transaction is an L1 β‡’ L2 transaction triggered by a smart contract on L1, then `tx.origin` is set to the [aliased address](#address-aliasing) of the address that triggered the L1 β‡’ L2 transaction. Otherwise, this opcode behaves normally. | -| `CALLER` | `msg.sender` | If the transaction is an L1 β‡’ L2 transaction triggered by a smart contract on L1, and this is the first call frame (rather than an internal transaction from one contract to another), the same [address aliasing](#address-aliasing) behavior applies. | - -### Address Aliasing - - - Address aliasing is an important security feature that impacts the behavior of transactions sent from L1 to L2 by smart contracts. - Make sure to read this section carefully if you are working with cross-chain transactions. - Note that the `CrossChainMessenger` contracts will handle address aliasing internally on your behalf. - - -When transactions are sent from L1 to L2 by an Externally Owned Account, the address of the sender of the transaction on L2 will be set to the address of the sender of the transaction on L1. -**However, the address of the sender of a transaction on L2 will be different if the transaction was triggered by a smart contract on L1**. - -Because of the behavior of the `CREATE` opcode, it is possible to create a contract on both L1 and on L2 that share the same address but have different bytecode. -Even though these contracts share the same address, they are fundamentally two different smart contracts and cannot be treated as the same contract. -As a result, the sender of a transaction sent from L1 to L2 by a smart contract cannot be the address of the smart contract on L1 or the smart contract on L1 could act as if it were the smart contract on L2 (because the two contracts share the same address). - -To prevent this sort of impersonation, the sender of a transaction is slightly modified when a transaction is sent from L1 to L2 by a smart contract. -Instead of appearing to be sent from the actual L1 contract address, the L2 transaction appears to be sent from an "aliased" version of the L1 contract address. -This aliased address is a constant offset from the actual L1 contract address such that the aliased address will never conflict with any other address on L2 and the original L1 address can easily be recovered from the aliased address. - -This change in sender address is only applied to L2 transactions sent by L1 smart contracts. -In all other cases, the transaction sender address is set according to the same rules used by Ethereum. - -| Transaction Source | Sender Address | -| ------------------------------------------------------- | ------------------------------------------------------------------ | -| L2 user (Externally Owned Account) | The user's address (same as in Ethereum) | -| L1 user (Externally Owned Account) | The user's address (same as in Ethereum) | -| L1 contract (using `OptimismPortal.depositTransaction`) | `L1_contract_address + 0x1111000000000000000000000000000000001111` | - -## Transactions - -### Transaction Fees - -Transactions on OP Mainnet must pay for an [L1 data fee](/stack/transactions/fees#the-l1-data-fee) on top of the standard [execution gas fee](/stack/transactions/fees#execution-gas-fee) you would expect on Ethereum. -Refer to the guide on [OP Mainnet Transaction Fees](/stack/transactions/fees) for more information. - -### EIP-1559 Parameters - -The base fee on OP Mainnet is, like Ethereum, computed via the [EIP-1559](https://notes.ethereum.org/@vbuterin/eip-1559-faq) mechanism. -The EIP-1559 parameters used by OP Mainnet differ from those used by Ethereum as follows. - -| Parameter | OP Mainnet value | Ethereum value (for reference) | -| ------------------------------------- | ---------------: | -----------------------------: | -| Block gas limit | 30,000,000 gas | 30,000,000 gas | -| Block gas target | 5,000,000 gas | 15,000,000 gas | -| EIP-1559 elasticity multiplier | 6 | 2 | -| EIP-1559 denominator | 250 | 8 | -| Maximum base fee increase (per block) | 2% | 12.5% | -| Maximum base fee decrease (per block) | 0.4% | 12.5% | -| Block time in seconds | 2 | 12 | - -### Mempool Rules - -Unlike Ethereum, OP Mainnet does not have a large public mempool. -The OP Mainnet Sequencer mempool is currently only visible to the Sequencer. -The Sequencer executes transactions from the mempool in priority fee order (highest fee first). diff --git a/pages/chain/getting-started.mdx b/pages/chain/getting-started.mdx index 6d4136cf5..d4af9faea 100644 --- a/pages/chain/getting-started.mdx +++ b/pages/chain/getting-started.mdx @@ -1,34 +1,34 @@ --- -title: Getting Started Developing for OP Mainnet +title: Getting started developing for OP Mainnet lang: en-US description: Learn the basics of OP Mainnet development. --- import { Steps } from 'nextra/components' -# Getting Started Developing for OP Mainnet +# Getting started developing for OP Mainnet This guide explains the basics of OP Mainnet development. OP Mainnet is [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), meaning we run a slightly modified version of the same `geth` you run on mainnet. Therefore, the differences between OP Mainnet development and Ethereum development are minor. -But a few differences [do exist](/chain/differences). +But a few differences [do exist](/stack/differences). -## OP Mainnet and OP Sepolia Endpoint URLs +## OP Mainnet and OP Sepolia endpoint URLs To access any Ethereum type network you need an endpoint. [These providers](/builders/tools/connect/rpc-providers) support our networks. -### Network Choice +### Network choice For development purposes we recommend you use either a local development node or [OP Sepolia](https://sepolia-optimism.etherscan.io). That way you don't need to spend real money. If you need ETH on OP Sepolia for testing purposes, [you can use this faucet](https://console.optimism.io/faucet?utm_source=docs). -## Interacting with Contracts on OP Mainnet or OP Sepolia +## Interacting with contracts on OP Mainnet or OP Sepolia We have Hardhat's Greeter contract on OP Sepolia at address [0x9d334aFBa83865E67a9219830ADA57aaA9406681](https://sepolia-optimism.etherscan.io/address/0x9d334aFBa83865E67a9219830ADA57aaA9406681#code). You can verify your development stack configuration by interacting with it. -## Development Stacks +## Development stacks As you can see in the different development stacks below, the way you deploy contracts and interact with them on OP Mainnet or OP Sepolia is almost identical to the way you do it with L1 Ethereum. The most visible difference is that you have to specify a different endpoint (of course). @@ -42,21 +42,21 @@ The list of other differences is [here](differences). * [Truffle](https://trufflesuite.com/) * [Waffle](https://getwaffle.io/) -## Best Practices +## Best practices -### Use Provided EVM +### Use provided EVM It is best to start development with the EVM provided by the development stack. Not only is it faster, but such EVMs often have extra features, such as the [ability to log messages from Solidity](https://hardhat.org/tutorial/debugging-with-hardhat-network.html) or a [graphical user interface](https://trufflesuite.com/ganache/). -### Debug Before Deploying +### Debug before deploying After you are done with that development, debug your decentralized application using either a [development node](/chain/testing/dev-node) or the [Sepolia test network](/chain/networks). This lets you debug parts that are OP Mainnet specific such as calls to bridges to transfer ETH or tokens between layers. Only when you have a version that works well on a test network should you deploy to the production network, where every transaction has a cost. -### Contract Source Verification +### Contract source verification You don't have to upload your source code to [block explorers](/builders/tools/build/block-explorers), but it is a good idea. On the test network, it lets you issue queries and transactions from the explorer's user interface. diff --git a/pages/chain/identity.mdx b/pages/chain/identity.mdx new file mode 100644 index 000000000..87c4b79e5 --- /dev/null +++ b/pages/chain/identity.mdx @@ -0,0 +1,29 @@ +--- +title: Identity +description: This guide explains the role of decentralized identity in the Optimism Collective and its key components. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Identity + +This guide explains the role of decentralized identity in the Optimism Collective and its key components. + + + + + + + + + + + + + + + + + + diff --git a/pages/chain/identity/_meta.json b/pages/chain/identity/_meta.json index 734d61bbf..3e4e40939 100644 --- a/pages/chain/identity/_meta.json +++ b/pages/chain/identity/_meta.json @@ -1,6 +1,6 @@ { "overview": "Overview", - "about-attestations": "About Attestations", + "about-attestations": "About attestations", "contracts-eas": "Contracts (EAS)", "schemas": "Schemas", "applications": "Apps", diff --git a/pages/chain/identity/about-attestations.mdx b/pages/chain/identity/about-attestations.mdx index 81f7133ca..4c2bdfbba 100644 --- a/pages/chain/identity/about-attestations.mdx +++ b/pages/chain/identity/about-attestations.mdx @@ -1,17 +1,17 @@ --- -title: About Attestations +title: About attestations lang: en-US description: Learn about building decentralized identity apps using Ethereum Attestation Service. --- import { Callout } from 'nextra/components' -# Build Decentralized Identity Apps with Attestations +# Build decentralized identity apps with attestations This guide explains how to build decentralized identity apps using attestations. It will define attestations and review the benefits of using Ethereum Attestation Service for Optimism developers. -## About Attestations +## About attestations Attestations are signed statements about a person, entity, or thing, made by an individual, company, or organization and are one of the building blocks of decentralized identity. @@ -20,7 +20,7 @@ You can think of Ethereum Attestation Service as a multiplayer database for stre ![attestation logo.](/img/op-mainnet/identity/atst-logo.png) -## Benefits of Using Ethereum Attestation Service +## Benefits of using Ethereum attestation service EAS makes it easy to sign any piece of data. In addition, here are a few key benefits: @@ -43,7 +43,7 @@ Here are some best practices to avoid violating users' privacy: Global data privacy laws are complex and multifaceted, and the violations of user privacy can have meaningful compliance as well as practical implications. -## Common Questions +## Common questions **Q: Are attestations replacements for verifiable credentials?** @@ -57,7 +57,7 @@ Here are some best practices to avoid violating users' privacy: **A:** Attestations have two key benefits over soulbound / non-transferable tokens: flexibility of whether the attestations is onchain or offchain and composability. While there is a canonical [decentralized schema registry for attestations](https://optimism.easscan.org/schemas), there is no central registry or specification for soulbound / non-transferable tokens which can lead to poor interoperability between systems and protocols. -## Next Steps +## Next steps Are you inspired and don't know what to build? We have a [project idea list](https://github.com/ethereum-optimism/ecosystem-contributions). Do you have a good idea, but you know you're not the right person to build it? Please open a PR on that list and suggest it. diff --git a/pages/chain/identity/applications.mdx b/pages/chain/identity/applications.mdx index 78cf5294e..7375f3a4b 100644 --- a/pages/chain/identity/applications.mdx +++ b/pages/chain/identity/applications.mdx @@ -4,11 +4,11 @@ lang: en-US description: Learn some of the applications that use attestations. --- -# Attestation Apps +# Attestation apps This guide lists some of the applications that use attestations. -## Ethereum Attestation Service +## Ethereum attestation service These are some of the applications that use the attestations: @@ -18,6 +18,6 @@ These are some of the applications that use the attestations: * [Optimist Profile](https://app.optimism.io/retropgf-signup): The Optimist Profile allows contributors to share the contributions and impact they've made to the Optimism Collective. * [Ethereum Ecosystem onchain reviews](https://www.ethereum-ecosystem.com/new-review): The goal of this Attestation-Based Dapp Rating web app is to allow anyone to review dApps and tools 100% onchain. -## Building with Attestations +## Building with attestations Are you building with attestations? Feel free to add your app to this page using the [attestation GitHub issue template](https://github.com/ethereum-optimism/docs/issues/new?assignees=\&labels=documentation%2Cattestation%2Ccommunity-request\&projects=\&template=suggest_attestation.yaml\&title=%5BATT%5D+Add+PR+title). diff --git a/pages/chain/identity/contracts-eas.mdx b/pages/chain/identity/contracts-eas.mdx index b501aa31a..9c6498d4d 100644 --- a/pages/chain/identity/contracts-eas.mdx +++ b/pages/chain/identity/contracts-eas.mdx @@ -4,12 +4,12 @@ lang: en-US description: Learn the basics of contracts for EAS, EAS contract addresses, and how to read and write attestations. --- -# EAS Contracts +# EAS contracts This guide covers [Ethereum Attestation Service ("EAS")](https://attest.sh/), an open-source public good that is included as a predeploy in the OP Stack. It also covers EAS contract addresses, how to read and write attestations, and indexing. -## EAS Contract Addresses +## EAS contract addresses The [Ethereum Attestation Service](https://docs.attest.sh/docs/welcome) is deployed on these addresses: @@ -18,7 +18,7 @@ The [Ethereum Attestation Service](https://docs.attest.sh/docs/welcome) is deplo | OP Sepolia | [0x4200000000000000000000000000000000000021](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000021) | [0x4200000000000000000000000000000000000020](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000020) | | OP Mainnet | [0x4200000000000000000000000000000000000021](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000021) | [0x4200000000000000000000000000000000000020](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000020) | -## How to Read and Write Attestations +## How to read and write attestations You can read and write attestations in several ways: @@ -35,6 +35,6 @@ Indexing is available via: * [Ponder graph](https://github.com/ethereum-attestation-service/eas-ponder-graph) * [Open source indexer](https://github.com/ethereum-attestation-service/eas-indexing-service) -## Next Steps +## Next steps For more information on working with attestations, see [Build Decentralized Identity Apps with Attestations](about-attestations). diff --git a/pages/chain/identity/individuals.mdx b/pages/chain/identity/individuals.mdx index 197cde2b5..4ed5e6965 100644 --- a/pages/chain/identity/individuals.mdx +++ b/pages/chain/identity/individuals.mdx @@ -4,11 +4,11 @@ lang: en-US description: Learn about how individual identity is represented in the Optimism Collective. --- -## Individual Identity +## Individual identity The Optimism Collective represents individuals using unique identifiers generated through the [Farcaster protocol id registry](https://docs.farcaster.xyz/reference/contracts/reference/id-registry). This system ensures a secure approach to identity management within the collective. -### Registering a User ID +### Registering a user ID To obtain a unique identifier: @@ -18,13 +18,13 @@ To obtain a unique identifier: * Creates a new custody address * Acts as a wallet -### Making Attestations +### Making attestations When you make attestations about individuals: * Leave the recipient address blank * Enter the users id into the attestation metadata -### Further Reading +### Further reading For more details on individual identity in the Optimism Collective, refer to the **[the governance docs](https://community.optimism.io/docs/identity/project-and-individual-identity-in-the-collective/#building-a-digital-identity)** on building a digital identity. diff --git a/pages/chain/identity/overview.mdx b/pages/chain/identity/overview.mdx index 236a11a9f..efa96fd28 100644 --- a/pages/chain/identity/overview.mdx +++ b/pages/chain/identity/overview.mdx @@ -1,5 +1,5 @@ --- -title: Identity Overview +title: Identity overview lang: en-US description: Learn about the basics of decentralized identity solutions. --- @@ -24,7 +24,7 @@ Decentralized identity expands the design space for innovation. It aims to give For more information about identity in the Optimism Collective, see [the governance docs post on the identity stack](https://community.optimism.io/docs/identity/project-and-individual-identity-in-the-collective/). -## Key Components of Identity +## Key components of identity There are three important components to identity within the Optimism Collective: @@ -38,7 +38,7 @@ Individuals and projects are the relevant entities in the Optimism Collective ab Decentralized identity not only supports democratic governance but also enhances innovation and individual financial control within the Optimism Collective ecosystem. -## Next Steps +## Next steps To learn more about identity in the Optimism Collective: diff --git a/pages/chain/identity/projects.mdx b/pages/chain/identity/projects.mdx index f3bca4d01..98ae2a849 100644 --- a/pages/chain/identity/projects.mdx +++ b/pages/chain/identity/projects.mdx @@ -11,15 +11,15 @@ Within the Optimism Collective, [the project entity](https://community.optimism. The project entity is represented onchain by an attestation from the [following schema](https://optimism.easscan.org/schema/view/0xff0b916851c1c5507406cfcaa60e5d549c91b7f642eb74e33b88143cae4b47d0). Projects are identified by the type "project". The attestation UID serves as the project's unique identifier throughout its lifecycle in the Collective. -## Project Metadata +## Project metadata All other project metadata is stored or referenced in the [Project Metadata Attestation](https://optimism.easscan.org/schema/view/0xe035e3fe27a64c8d7291ae54c6e85676addcbc2d179224fe7fc1f7f05a8c6eac). -### Updating Metadata +### Updating metadata * The Project Metadata Attestation is re-issued whenever there's a change in metadata. * Apps displaying project metadata should refer to the most recent attestation for up-to-date information. -## Further Reading +## Further reading For more information about identity in the Optimism Collective, see the [Identity Overview](/chain/identity/overview.mdx). diff --git a/pages/chain/identity/schemas.mdx b/pages/chain/identity/schemas.mdx index 8c38788a5..1a562471a 100644 --- a/pages/chain/identity/schemas.mdx +++ b/pages/chain/identity/schemas.mdx @@ -10,14 +10,14 @@ Schemas define the structure and type of data that can be included in an attesta Below you will find a list of relevant schemas that are being used on OP Mainnet. Schemas are built using the [Ethereum Attestation Service](https://docs.attest.sh/docs/welcome). -## General Schemas +## General schemas * **[Gitcoin Passport V1 scores schema UID](https://optimism.easscan.org/schema/view/0x6ab5d34260fca0cfcf0e76e96d439cace6aa7c3c019d7c4580ed52c6845e9c89):** `0x6ab5d34260fca0cfcf0e76e96d439cace6aa7c3c019d7c4580ed52c6845e9c89` * **[Superchain Faucet schema UID](https://optimism.easscan.org/schema/view/0x98ef220cd2f94de79fbc343ef982bfa8f5b315dec6a08f413680ecb7085624d7)**: `0x98ef220cd2f94de79fbc343ef982bfa8f5b315dec6a08f413680ecb7085624d7` ## Schemas related to project creation and Retro Funding application -### [Project and Organization identifier](https://optimism.easscan.org/schema/view/0xff0b916851c1c5507406cfcaa60e5d549c91b7f642eb74e33b88143cae4b47d0) +### [Project and organization identifier](https://optimism.easscan.org/schema/view/0xff0b916851c1c5507406cfcaa60e5d549c91b7f642eb74e33b88143cae4b47d0) Used as the unique identifier for projects and organizations created on or after 23 August 2024. For projects created earlier, please see the archived section at the bottom of this page. @@ -27,7 +27,7 @@ Used as the unique identifier for projects and organizations created on or after | farcasterID | The Farcaster id of the individual who created the project or organization | | type | "Project" or "Organization" | -### [Organization Metadata](https://optimism.easscan.org/schema/view/0xc2b376d1a140287b1fa1519747baae1317cf37e0d27289b86f85aa7cebfd649f) +### [Organization metadata](https://optimism.easscan.org/schema/view/0xc2b376d1a140287b1fa1519747baae1317cf37e0d27289b86f85aa7cebfd649f) Used to associate metadata to an organization. Re-issued each time there is a change to metadata @@ -43,7 +43,7 @@ Used to associate metadata to an organization. Re-issued each time there is a ch | metadataType | How the metadata can be accessed. 1 for ipfs, 2 for http | | metadataUrl | The storage location where the metadata can be retrieved | -### [Project Metadata](https://optimism.easscan.org/schema/view/0xe035e3fe27a64c8d7291ae54c6e85676addcbc2d179224fe7fc1f7f05a8c6eac) +### [Project metadata](https://optimism.easscan.org/schema/view/0xe035e3fe27a64c8d7291ae54c6e85676addcbc2d179224fe7fc1f7f05a8c6eac) Used to associate metadata to a project. Re-issued each time there is a change to metadata. @@ -59,20 +59,21 @@ Used to associate metadata to a project. Re-issued each time there is a change t | metadataType | How the metadata can be accessed. 1 for ipfs, 2 for http | | metadataUrl | The storage location where the metadata can be retrieved | -### [Retro Funding Application](https://optimism.easscan.org/schema/view/0x88b62595c76fbcd261710d0930b5f1cc2e56758e155dea537f82bf0baadd9a32) +### [Retro funding application](https://optimism.easscan.org/schema/view/0x2169b74bfcb5d10a6616bbc8931dc1c56f8d1c305319a9eeca77623a991d4b80) -Used to identify a project's application to a specific Retro Funding Round. +Used to identify a project's application to a specific Retro Funding Round. This attestation is used for Retro Funding Round 6 and beyond. -| Schema UID | `0x88b62595c76fbcd261710d0930b5f1cc2e56758e155dea537f82bf0baadd9a32` | +| Schema UID | `0x2169b74bfcb5d10a6616bbc8931dc1c56f8d1c305319a9eeca77623a991d4b80` | | ----------------------- | ---------------------------------------------------------------------------------------------------------------- | | Issuer | Attestations issued as part of Retro Funding sign up are issued by: `0xF6872D315CC2E1AfF6abae5dd814fd54755fE97C` | | Recipient | Null | | round | The round number for which this application was submitted | -| projectRefUID | The unique identifier of the project that submitted this application | +| metadataType | How the metadata can be accessed. 1 for ipfs, 2 for http | +| metadataUrl | The storage location where the metadata can be retrieved | | farcasterID | The individual that submitted this application on behalf of the project. | | metadataSnapshot RefUID | The project metadata at the time the application was submitted. | -### [Retro Funding Application Approval/Rejection](https://optimism.easscan.org/schema/view/0x683b1b399d47aabed79c9aa8f2674729021174b6e5cce1e20675eab404fc82d6) +### [Retro funding application approval/rejection](https://optimism.easscan.org/schema/view/0x683b1b399d47aabed79c9aa8f2674729021174b6e5cce1e20675eab404fc82d6) Used to identify which Retro Funding applications have been approved or rejected. @@ -84,7 +85,7 @@ Used to identify which Retro Funding applications have been approved or rejected | Status | The status of the Retro Funding application. | | Reason | Identifier for the reason an application was rejected. 1 = "Duplicate Application", 2 = "Deceiving Badgeholders", 3 = "Spam", 4 = "Not meeting eligibility criteria" | -### [Retro Funding Rewards](https://optimism.easscan.org/schema/view/0x670ad6e6ffb842d37e050ea6d3a5ab308195c6f584cf2121076067e0d8adde18) +### [Retro funding rewards](https://optimism.easscan.org/schema/view/0x670ad6e6ffb842d37e050ea6d3a5ab308195c6f584cf2121076067e0d8adde18) Used to identify the reward amount each approved project received in a Retro Funding round @@ -108,7 +109,7 @@ Citizen attestations were first issued in Season 6 and are used to represent Cit | FarcasterID | The Citizen's unique identifier | | SelectionMethod | A Code representing the method through which the Citizen was selected. Codes beginning with the number 1 refer to various flavours of Web of Trust selection. | -### [Retro Funding Voters](https://optimism.easscan.org/schema/view/0x41513aa7b99bfea09d389c74aacedaeb13c28fb748569e9e2400109cbe284ee5) +### [Retro funding voters](https://optimism.easscan.org/schema/view/0x41513aa7b99bfea09d389c74aacedaeb13c28fb748569e9e2400109cbe284ee5) These attestations are voting Badges issued for Retro Round 5 and beyond. They are different from the [previous schema](https://optimism.easscan.org/schema/view/0xfdcfdad2dbe7489e0ce56b260348b7f14e8365a8a325aef9834818c00d46b31b) to include new fields like votingGroup, used to assign voters to sub-categories in the round. @@ -120,12 +121,34 @@ These attestations are voting Badges issued for Retro Round 5 and beyond. They a | votingGroup | Used to assign voters to subcategories in case the Round has subcategories | | selectionMethod | The method in which this voter was selected | -### [Retro Funding Governance contribution](https://optimism.easscan.org/schema/view/0x3743be2afa818ee40304516c153427be55931f238d961af5d98653a93192cdb3) +### [MetaGov Contribution](https://optimism.easscan.org/schema/view/0x84260b9102b41041692558a4e0cba6b7e5f9b813be56402c3db820c06dd4a5f1) + +| Schema UID | `0x84260b9102b41041692558a4e0cba6b7e5f9b813be56402c3db820c06dd4a5f1` | +| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Issuer | Currently, the Optimism Foundation issues these from one of the following addresses: `0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9` or `0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F`. | +| Recipient | The address of the individual who made the contribution | +| refUID | The UID of the project, in case this contribution is represented as a project | +| FarcasterID | The id of the individual who made the contribution, if known | +| Impact | This field is not currently being used | +| Season | The season in which the contribution was made | +| Decision Module | The decision module to which the contribution relates | +| Contribution Type | The type of contribution | +| MetadataUrl | This field is not currently being used | + +### [Foundation Mission Request Completed](https://optimism.easscan.org/schema/view/0x649cc6df5af7561b66384405a62682c44e2428584d2f17a202ac3ef4506e2457) + +| Schema UID | `0x649cc6df5af7561b66384405a62682c44e2428584d2f17a202ac3ef4506e2457` | +| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Issuer | Currently, the Optimism Foundation issues these from one of the following addresses: `0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9` or `0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F`. | +| projectRefUID | The UID of the project that represents the work completed as part of the Foundation Mission Request | +| OP Amount | The OP Amount that was awarded for the completion of this Mission Request | +| Season | The season in which this Mission Request was completed | + +### [Retro funding governance contribution](https://optimism.easscan.org/schema/view/0x3743be2afa818ee40304516c153427be55931f238d961af5d98653a93192cdb3) | Schema UID | `0x3743be2afa818ee40304516c153427be55931f238d961af5d98653a93192cdb3` | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Issuer | Currently, the Optimism Foundation issues these from one of the following addresses: `0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9` or `0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F`. | -| Issuer | Currently, the Optimism Foundation issues these from one of the following addresses: `0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9` or `0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F` | | Recipient | The address of the individual who made the contribution | | Rpgf\_round | The round number for which this contribution was made | | RetroPGF\_Contribution | The type of contribution made | @@ -142,11 +165,24 @@ Issued to those who held governance roles in the Collective, such as Grants Coun | govSeason | The season the individual held the role | | govRole | The role held by the individual | -## Archived Schemas +## Archived schemas These schemas are no longer being actively issued, but capture valuable historical data. -### [Retro Funding Badgeholders](https://optimism.easscan.org/schema/view/0xfdcfdad2dbe7489e0ce56b260348b7f14e8365a8a325aef9834818c00d46b31b) +### [Retro funding application](https://optimism.easscan.org/schema/view/0x88b62595c76fbcd261710d0930b5f1cc2e56758e155dea537f82bf0baadd9a32) + +Used to identify a project's application to a specific Retro Funding Round. This attestation was used for Retro Funding Rounds 4 and 5. + +| Schema UID | `0x88b62595c76fbcd261710d0930b5f1cc2e56758e155dea537f82bf0baadd9a32` | +| ----------------------- | ---------------------------------------------------------------------------------------------------------------- | +| Issuer | Attestations issued as part of Retro Funding sign up are issued by: `0xF6872D315CC2E1AfF6abae5dd814fd54755fE97C` | +| Recipient | Null | +| round | The round number for which this application was submitted | +| projectRefUID | The unique identifier of the project that submitted this application | +| farcasterID | The individual that submitted this application on behalf of the project. | +| metadataSnapshot RefUID | The project metadata at the time the application was submitted. | + +### [Retro funding badgeholders](https://optimism.easscan.org/schema/view/0xfdcfdad2dbe7489e0ce56b260348b7f14e8365a8a325aef9834818c00d46b31b) These attestations are considered "voting Badges" and allow an individual to vote in any given iteration of Retro Funding. They were used up to and including Retro Round 4. @@ -158,7 +194,7 @@ These attestations are considered "voting Badges" and allow an individual to vot | referredBy | In early rounds, new Badges were issued by referral. This field captures the address of the referrer, if there was one | | referredMethod | If this voting Badge was issued by referral, this field captures the referral method | -### [Project Identifier](https://optimism.easscan.org/schema/view/0x7ae9f4adabd9214049df72f58eceffc48c4a69e920882f5b06a6c69a3157e5bd) +### [Project identifier](https://optimism.easscan.org/schema/view/0x7ae9f4adabd9214049df72f58eceffc48c4a69e920882f5b06a6c69a3157e5bd) Used as the unique identifier for projects created in the Collective before 23 August 2024. Attestations issued from this schema prior to 23 August 2024 are still used as the unique identifier for projects. New projects created after 23 August 2024 use the new entity identifier (see above). @@ -174,7 +210,7 @@ Used as the unique identifier for projects created in the Collective before 23 A * **[Season 4 Co-grant participant schema UID](https://optimism.easscan.org/schema/view/0x401a80196f3805c57b00482ae2b575a9f270562b6b6de7711af9837f08fa0faf)**: `0x401a80196f3805c57b00482ae2b575a9f270562b6b6de7711af9837f08fa0faf`. Important: Remember to verify the attester address is `0x3C7820f2874b665AC7471f84f5cbd6E12871F4cC` or `0x2a0eB7cAE52B68e94FF6ab0bFcf0dF8EeEB624be` * **[Optimist Profile schema UID](https://optimism.easscan.org/schema/view/0xac4c92fc5c7babed88f78a917cdbcdc1c496a8f4ab2d5b2ec29402736b2cf929):** `​​0xac4c92fc5c7babed88f78a917cdbcdc1c496a8f4ab2d5b2ec29402736b2cf929` -## Next Steps +## Next steps * For more information on working with attestations, see [Build Decentralized Identity Apps with Attestations](/chain/identity/about-attestations). * To see a list of applications using EAS, see [Attestation Apps](/chain/identity/applications). diff --git a/pages/chain/networks.mdx b/pages/chain/networks.mdx index 3fc2c7369..a7e97799d 100644 --- a/pages/chain/networks.mdx +++ b/pages/chain/networks.mdx @@ -1,12 +1,12 @@ --- -title: OP Networks and Public RPC Endpoints +title: OP networks and public RPC endpoints lang: en-US description: Learn about the different OP networks and public RPC endpoints. --- import { Callout } from 'nextra/components' -# OP Networks and Public RPC Endpoints +# OP networks and public RPC endpoints This reference guide provides a listing of the different OP networks and public RPC endpoints. diff --git a/pages/chain/security.mdx b/pages/chain/security.mdx new file mode 100644 index 000000000..e4f10a998 --- /dev/null +++ b/pages/chain/security.mdx @@ -0,0 +1,19 @@ +--- +title: Security +description: Documentation covering Faq, Privileged Roles, Security Policy in the Security section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Security + +Documentation covering Faq, Privileged Roles, Security Policy in the Security section of the OP Stack ecosystem. + + + + + + + + diff --git a/pages/chain/security/_meta.json b/pages/chain/security/_meta.json index 7ffeab759..0c83dd2a3 100644 --- a/pages/chain/security/_meta.json +++ b/pages/chain/security/_meta.json @@ -1,7 +1,7 @@ { - "faq": "Security Model & FAQ", - "privileged-roles": "Privileged Roles", - "security-policy": "Security Policy", + "faq": "Security model & FAQ", + "privileged-roles": "Privileged roles", + "security-policy": "Security policy", "bug-bounty": { "title": "Bug Bounty Program", "href": "https://immunefi.com/bounty/optimism/", diff --git a/pages/chain/security/faq.mdx b/pages/chain/security/faq.mdx index 59da94f59..002244cc8 100644 --- a/pages/chain/security/faq.mdx +++ b/pages/chain/security/faq.mdx @@ -1,32 +1,32 @@ --- -title: OP Mainnet Security Model +title: OP Mainnet security model lang: en-US description: Learn about the OP Mainnet security model and answers to common questions. --- import { Callout } from 'nextra/components' -# OP Mainnet Security Model +# OP Mainnet security model OP Mainnet is a work in progress. Constant, iterative improvement of the security mechanisms that safeguard OP Mainnet users is a top priority for the entire [Optimism Collective](https://community.optimism.io/docs/governance/). The Optimism Collective strives to be clear and transparent about the security of OP Mainnet and the OP Stack as a whole. -## Bottom Line +## Bottom line The security model of any blockchain system is only as strong as its lowest common denominator. At the moment, **it's important to understand that the security of OP Mainnet is dependent on a [multisig](https://etherscan.io/address/0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A)** managed jointly by the [Optimism Security Council](https://gov.optimism.io/t/intro-to-optimisms-security-council/6885) and the Optimism Foundation. OP Mainnet and the OP Stack in general **may also contain unknown bugs that could lead to the loss of some or all of the ETH or tokens held within the system**. -## OP Mainnet Multisig +## OP Mainnet multisig The security of OP Mainnet is currently dependent on a multisig managed jointly by the [Optimism Security Council](https://gov.optimism.io/t/intro-to-optimisms-security-council/6885) and the Optimism Foundation. -This multisig is a [2-of-2 nested multisig](https://etherscan.io/address/0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A) which is in turn governed by a [4-of-13 multisig](https://etherscan.io/address/0xc2819DC788505Aac350142A7A707BF9D03E3Bd03) managed by the Optimism Security Council and a [5-of-7 multisig](https://etherscan.io/address/0x847B5c174615B1B7fDF770882256e2D3E95b9D92) managed by the Optimism Foundation. +This multisig is a [2-of-2 nested multisig](https://etherscan.io/address/0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A) which is in turn governed by a [10-of-13 multisig](https://etherscan.io/address/0xc2819DC788505Aac350142A7A707BF9D03E3Bd03) managed by the Optimism Security Council and a [5-of-7 multisig](https://etherscan.io/address/0x847B5c174615B1B7fDF770882256e2D3E95b9D92) managed by the Optimism Foundation. This multisig can be used to upgrade core OP Mainnet smart contracts **without upgrade delays** to allow for quick responses to potential security concerns. All upgrades to the OP Mainnet system must be approved by both component multisigs and either can veto an upgrade. -## Fault Proofs +## Fault proofs It is important to understand that **fault proofs are not a silver bullet** and that **fault proofs provide limited improvements to the security of a system if the system still has a multisig or security council that can instantly upgrade the system**. @@ -38,27 +38,27 @@ Withdrawals are proven against proposals about the state of OP Mainnet that are Proposals can be submitted to the `DisputeGameFactory` contract by any user and submissions do not require any special permissions. Each submitted proposal creates a [`FaultDisputeGame`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/dispute/FaultDisputeGame.sol) contract that allows any other user to challenge the validity of a proposal by participating in a "fault proof" process. -A more detailed explanation of the fault proof game can be found in the [Fault Proofs Explainer](/stack/protocol/fault-proofs/explainer). +A more detailed explanation of the fault proof game can be found in the [Fault Proofs Explainer](/stack/fault-proofs/explainer). Although the fault proof game is permissionless, the Optimism Security Council acting as the [Guardian](/chain/security/privileged-roles#guardian) role provides a backstop in case of a failure in the fault proof game. Each proposal must wait for a delay period during which the Guardian can prevent invalid proposals from being used to withdraw ETH or tokens through a number of safety hatches. The Guardian can also choose to shift the system to use a `PermissionedDisputeGame` in which only specific `PROPOSER` and `CHALLENGER` roles can submit and challenge proposals. -## Bugs and Unknowns +## Bugs and unknowns Please also keep in mind that just like any other system, **the Optimism codebase may contain unknown bugs** that could lead to the loss of some or all of the ETH or tokens held within the system. The OP Stack has been audited [on many occasions](https://github.com/ethereum-optimism/optimism/tree/v1.1.4/technical-documents/security-reviews), but **audits are not a stamp of approval** and **a completed audit does not mean that the audited codebase is free of bugs.** It's important to understand that using OP Mainnet inherently exposes you to the risk of bugs within the Optimism codebase, and that you use OP Mainnet at your own risk. -## Work in Progress +## Work in progress -### Sequencer Decentralization +### Sequencer decentralization The Optimism Foundation currently operates the sole sequencer on OP Mainnet. Although users can always bypass the Sequencer by sending transactions directly to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/5877ee24cc9aaef5848c1372e0e196707fb336a0/packages/contracts-bedrock/src/L1/OptimismPortal.sol) contract, sequencer decentralization can still help mitigate the effect of short-term outages for users. -## Security Model FAQ +## Security model FAQ ### Does OP Mainnet have fault proofs? diff --git a/pages/chain/security/security-policy.mdx b/pages/chain/security/security-policy.mdx index 3434d8664..1e50b5093 100644 --- a/pages/chain/security/security-policy.mdx +++ b/pages/chain/security/security-policy.mdx @@ -1,40 +1,40 @@ --- -title: Security Policy and Bug Bounty Program +title: Security policy and bug bounty program lang: en-US description: Learn about the bug bounty program and best practices for reporting bugs in OP Stack and OP Mainnet codebase. --- import { Callout } from 'nextra/components' -# Security Policy and Bug Bounty Program +# Security policy and bug bounty program This page describes general best practices for reporting bugs and provides specific reporting guidelines for OP Stack and OP Mainnet code contained within the [ethereum-optimism](https://github.com/ethereum-optimism) GitHub organization. - **Do not** disclose vulnerabilities publicly or by executing them against a production network. If you do, will you not only be putting users at risk, but you will forfeit your right to a reward. Always follow the appropriate reporting pathways as described below. + **Do not** disclose vulnerabilities publicly or by executing them against a production network. If you do, you will not only be putting users at risk, but you will forfeit your right to a reward. Always follow the appropriate reporting pathways as described below. * **Do not** disclose the vulnerability publicly, for example by filing a public ticket. * **Do not** test the vulnerability on a publicly available network, either the testnet or the mainnet. -## Optimism Bug Bounty Program +## Optimism bug bounty program The Optimism Bug Bounty Program offers up to [$2,000,042](https://immunefi.com/bounty/optimism/) for critical vulnerabilities found in the OP Mainnet codebase. Below you can find information about the various available bug bounty programs and how to report bugs that are not covered by an existing bounty. -### Main Bounty Page +### Main bounty page Optimism has a very detailed [Bug Bounty Page on Immunefi](https://immunefi.com/bounty/optimism/). In the listing you can find all the information relating to components in scope, reporting, and the payout process. -### Unscoped Bugs +### Unscoped bugs If you think you have found a significant bug or vulnerabilities in OP Stack smart contracts, infrastructure, etc., even if that component is not covered by an existing bug bounty, please report it to via the [OP Mainnet Immunefi program](https://immunefi.com/bounty/optimism/). The impact of any and all reported issues will be considered and the program has previously rewarded security researchers for bugs not within its stated scope. -## Reporting Other Vulnerabilities +## Reporting other vulnerabilities For vulnerabilities in any websites, email servers, or other non-critical infrastructure within the OP Stack, please contact the Foundation's service provider at [security@oplabs.co](mailto:security@oplabs.co) and include detailed instructions for confirming and reproducing the vulnerability. -### Vulnerability Disclosure +### Vulnerability disclosure Each OP Stack component maintainer may determine its own process for vulnerability disclosure. However, the following describes a recommended process for disclosure. @@ -46,11 +46,11 @@ In such a scenario, the disclosure process used is as follows: 2. After 4-8 weeks, disclose that release X contained a security fix. 3. After an additional 4-8 weeks, publish details of the vulnerability, along with credit to the reporter (with express permission from the reporter). -### Rights of Maintainers +### Rights of maintainers Alongside this policy, maintainers also reserve the right to: * Bypass this policy and publish details on a shorter timeline. * Directly notify a subset of downstream users prior to making a public announcement. -This policy is based the [Geth](https://geth.ethereum.org/) team's [silent patch policy](https://geth.ethereum.org/docs/developers/geth-developer/disclosures#why-silent-patches). +This policy is based on the [Geth](https://geth.ethereum.org/) team's [silent patch policy](https://geth.ethereum.org/docs/developers/geth-developer/disclosures#why-silent-patches). diff --git a/pages/chain/testing.mdx b/pages/chain/testing.mdx new file mode 100644 index 000000000..fc2af6d47 --- /dev/null +++ b/pages/chain/testing.mdx @@ -0,0 +1,17 @@ +--- +title: Testing +description: Documentation covering Dev Node, Testing Apps in the Testing section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Testing + +Documentation covering Dev Node, Testing Apps in the Testing section of the OP Stack ecosystem. + + + + + + diff --git a/pages/chain/testing/_meta.json b/pages/chain/testing/_meta.json index 9402c85f8..f6228db4f 100644 --- a/pages/chain/testing/_meta.json +++ b/pages/chain/testing/_meta.json @@ -1,4 +1,4 @@ { - "dev-node": "Running a Local Development Environment", - "testing-apps": "Testing Apps on OP Mainnet" + "dev-node": "Running a local development environment", + "testing-apps": "Testing apps on OP Mainnet" } diff --git a/pages/chain/testing/testing-apps.mdx b/pages/chain/testing/testing-apps.mdx index 86e9cd3e0..2eac879a2 100644 --- a/pages/chain/testing/testing-apps.mdx +++ b/pages/chain/testing/testing-apps.mdx @@ -1,10 +1,10 @@ --- -title: Testing Apps for OP Mainnet +title: Testing apps for OP Mainnet lang: en-US description: Learn best practices for OP Mainnet testing. --- -# Testing Apps for OP Mainnet +# Testing apps for OP Mainnet For the most part, running applications on OP Mainnet is identical to running them on Ethereum, so the testing is identical too. In this guide, you learn the best practices for OP Mainnet testing where there are differences. diff --git a/pages/chain/tokenlist.mdx b/pages/chain/tokenlist.mdx index 4b590e43c..ac2301614 100644 --- a/pages/chain/tokenlist.mdx +++ b/pages/chain/tokenlist.mdx @@ -1,5 +1,5 @@ --- -title: Bridged Token Addresses +title: Bridged token addresses lang: en-US description: This reference guide lists the correct bridged token addresses for each token. --- @@ -7,7 +7,7 @@ description: This reference guide lists the correct bridged token addresses for import { Callout } from 'nextra/components' import { TokenListTable } from '@/components/TokenListTable' -# Bridged Token Addresses +# Bridged token addresses Various ERC-20 tokens originally deployed to Ethereum also have corresponding "bridged" representations on OP Mainnet. The [Superchain Token List](https://github.com/ethereum-optimism/ethereum-optimism.github.io) exists to help users discover the correct bridged token addresses for each token. diff --git a/pages/connect/contribute.mdx b/pages/connect/contribute.mdx new file mode 100644 index 000000000..a7cf78027 --- /dev/null +++ b/pages/connect/contribute.mdx @@ -0,0 +1,17 @@ +--- +title: Contribute +description: Documentation covering Docs Contribute, Stack Contribute, Style Guide in the Contribute section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Contribute + +Documentation covering Docs Contribute, Stack Contribute, Style Guide in the Contribute section of the OP Stack ecosystem. + + + + + + diff --git a/pages/connect/contribute/_meta.json b/pages/connect/contribute/_meta.json index 39ebe0e09..dbfae0745 100644 --- a/pages/connect/contribute/_meta.json +++ b/pages/connect/contribute/_meta.json @@ -1,5 +1,5 @@ { - "docs-contribute": "Contribute to Optimism Docs", + "docs-contribute": "Contribute to Optimism docs", "stack-contribute": "Contribute to OP Stack", - "style-guide": "Docs Style Guide" + "style-guide": "Docs style guide" } \ No newline at end of file diff --git a/pages/connect/contribute/docs-contribute.mdx b/pages/connect/contribute/docs-contribute.mdx index bfe48b94d..d29189de3 100644 --- a/pages/connect/contribute/docs-contribute.mdx +++ b/pages/connect/contribute/docs-contribute.mdx @@ -1,5 +1,5 @@ --- -title: Ways to Contribute to Optimism Docs +title: Ways to contribute to Optimism Docs lang: en-US description: Learn about the different ways you can contribute to Optimism Docs. --- @@ -89,6 +89,6 @@ We use GitPOAPs to recognize our contributors! GitPOAP automatically recognizes You should only use self-custody wallets to claim POAPs. Do not use exchange accounts or other accounts you do not hold the private keys to, as these will not allow you to access and manage your POAPs. -## Still Have Questions? +## Still have questions? You can reach us in our developer support [forum](https://github.com/ethereum-optimism/developers/discussions). We look forward to growing the Collective with you! diff --git a/pages/connect/contribute/stack-contribute.mdx b/pages/connect/contribute/stack-contribute.mdx index 159cdc5aa..22fec79f0 100644 --- a/pages/connect/contribute/stack-contribute.mdx +++ b/pages/connect/contribute/stack-contribute.mdx @@ -14,12 +14,12 @@ The Optimism Collective wins when it works together. β™₯️✨ Whether you're a budding chain operator, app developer, node operator, bounty hunter, content creator, or anything in between, the OP Stack always has something for you to contribute to. Every contribution makes a difference β€” no contribution is too small. If you're ready to contribute, check out one of the following contributor pathways below. -## Component Contributions +## Component contributions The OP Stack is a decentralized development stack and is constantly evolving as new layers and modules are developed. Anyone can contribute components that can be considered part of the OP Stack as long as those components fit the stack's [design principles and goals](/stack/design-principles). To start contributing components to the stack, check out some of these [useful ideas](https://github.com/ethereum-optimism/ecosystem-contributions) and get to building! And don't forget that projects can also receive grants from the Collective via [RetroPGF](https://community.optimism.io/docs/citizen-house/how-retro-funding-works/). -## Codebase Contributions +## Codebase contributions The OP Stack codebase is not a product (in the traditional sense) but rather a collection of software components that power the Optimism ecosystem. If you'd like to contribute to the current release of OP Stack codebase, rather than creating new components, your contribution would be greatly appreciated. @@ -33,15 +33,15 @@ To make your first contribution to the codebase, check out the [open issues](htt Developer support for OP Stack Hacks is limited β€” when in doubt, stick to the capabilities of the current release! -## Bounty Hunting +## Bounty hunting The OP Stack needs YOU (yes you!) to help review the codebase for bugs and vulnerabilities. If you're interested in bounty hunting, check out our [Security Policy, Vulnerability Reporting, and Bug Bounties page](/chain/security/security-policy). -## Docs Contributions +## Docs contributions Want a new tutorial? See something that could be a little clearer? Check out the [Optimism Docs Contribution page](docs-contribute) for more information on how to help. No contribution is too small! -## Community Contributions +## Community contributions If you're looking for other ways to get involved, here are a few options: diff --git a/pages/connect/contribute/style-guide.mdx b/pages/connect/contribute/style-guide.mdx index 0c058bd9c..f1ab6193d 100644 --- a/pages/connect/contribute/style-guide.mdx +++ b/pages/connect/contribute/style-guide.mdx @@ -1,15 +1,17 @@ --- -title: Optimism Docs Style Guide +title: Optimism Docs style guide lang: en-US description: This guide explains how to write technical content for Optimism Docs using a consistent voice, tone, and style. --- import { Callout } from 'nextra/components' -# Docs Style Guide +# Docs style guide This Style Guide aims to assist Optimists in writing technical content with a consistent voice, tone, and style. See the [glossary](/connect/resources/glossary) for an alphabetical listing of commonly used words, terms, and concepts used throughout the technical docs and across the OP Collective. +This doc doesn't cover all questions or use-cases. Our guide is based on the [Microsoft Writing Style Guide](https://learn.microsoft.com/en-us/style-guide/welcome/). Please reference their guide for any use-case or situation we do not cover here. + * For docs-related questions or comments, create an issue in the [docs repo](https://github.com/ethereum-optimism/docs/issues). * For support-related questions or comments, create an issue in the [developers repo](https://github.com/ethereum-optimism/developers/issues). @@ -23,9 +25,9 @@ This Style Guide aims to assist Optimists in writing technical content with a co * [Content Types](#content-types) * [General Formatting](#general-formatting) -## Files, Folders, and Naming Conventions +## Files, folders, and naming conventions -### Folder Structure +### Folder structure The folder structure for the [docs.optimism.io](https://github.com/ethereum-optimism/docs) repository is organized into several high-level categories under the main `pages` folder such as `builders`, `chain`, `connect`, and `stack`. @@ -41,19 +43,19 @@ In general, filenames should be as short as possible (\~2 to 4 words) and all lo **Example:** `writing-a-guide.mdx` or `run-node.mdx` -### File Paths +### File paths File paths, when mentioned **within** a docs page, should be formatted as code snippets for readability and wrapped in backticks. **Example**: `/source/docs/assets/images/` -## Writing Style +## Writing style -### Voice and Tone +### Voice and tone Write in a friendly, yet professional tone. We are upbeat, knowledgeable, and **optimistic** about the development of the Optimism Collective, which we try our best to convey in our technical documentation. -### Clear and Concise Language +### Clear and concise language * Be consistent. Use the same terminology, voice, and tone throughout the documentation. * Be concise. Focus on providing key information and avoid including superfluous information. @@ -67,7 +69,7 @@ Write in a friendly, yet professional tone. We are upbeat, knowledgeable, and ** See below for when to use title or sentence case. -* Avoid using all caps as it slows down reading comprehension. If you need to make content prominent, use **bold** rather than all caps or italics. +* Avoid using all caps as it slows down reading comprehension. * Capitalize proper nouns in sentences.
**Example**: I use Visual Studio on my local machine. @@ -95,7 +97,7 @@ See below for when to use title or sentence case. When creating content, ensure it is accessible to screen-reader users, visually impaired individuals, and those using a mouse or keyboard. For more information regarding accessibility guidelines, see [W3C Web Content Accessibility Guidelines 2.0](http://www.w3.org/TR/UNDERSTANDING-WCAG20/Overview.html#contents). -### Alt-Text +### Alt-text * Provide alt text for all images so that the screen reader can interpret the purpose of the image and convey that to the user. The alt text should include any content shown in the image so that screen reader can read it to the user. * Provide alt text for videos by modifying the title attribute of any embedded video content or iframe. The title attribute serves as the alt text for screen readers to provide descriptive information. Video content with speaking or narration must include closed captions. @@ -110,20 +112,20 @@ When creating content, ensure it is accessible to screen-reader users, visually * Don't use images of text, code samples, or terminal output. Use actual text. * Use SVG instead of PNG if available. SVGs stay sharp when users zoom in on the image. -## Content Organization +## Content organization We aim to use consistent organization that is also user-centered and accessible. This requires intentional work and planning to group technical content into sections instead of using long, dense paragraphs. This also gives readers a visual rest from a usability perspective and improves reading comprehension. * Use structured headings (H1, H2 or #, ##) to guide readers through the technical documentation. * Use numbered lists for chronological steps. * Use bulleted lists to visually separate content that does not require a specific order. -* Format text for optimal readability (bold vs. italics). Avoid using italics in web content as it decreases readability. Use bold if you need to make content prominent but use it sparingly. For instance, **bold** is appropriate to use when referring to a specific button or page name in technical documentation. +* Format text for optimal readability (bold vs. italics). Avoid using italics in web content as it decreases readability. For instance, **bold** is appropriate to use when referring to a specific button or page name in technical documentation. * Organize technical content to cover only one major concept or task at a time. - * **General rule of thumb**: documents with > 3 levels of structured headings (H4 or ####) and/or > than 20 minutes estimated reading time (ERT) need Revisions will typically involve editing for conciseness, splitting the document into multiple pages, or both. - * revisions will usually require editing for concision, breaking the document apart into multiple pages, or some combination of the two. + * **General rule of thumb**: documents with more than 3 levels of structured headings (H4 or ####) and/or more than than 20 minutes estimated reading time (ERT) need revisions will typically involve editing for conciseness, splitting the document into multiple pages, or both. + * Revisions will usually require editing for concision, breaking the document apart into multiple pages, or some combination of the two. * Organize content based on the audience's varying needs and prior knowledge. If pre-requisite knowledge is necessary to complete a task or understand a concept, then share it with users (including links to learn more), so they can easily get up to speed. -### Meta Tags +### Meta tags * Define the meta **title**, **language**, and **description** for each page to improve SEO ranking of the docs. Place meta tags at the top of the page before the H1 tag, with 3 dashes surrounding the block of text on either side. @@ -147,7 +149,7 @@ We aim to use consistent organization that is also user-centered and accessible. β€”-
 -### Page Titles (H1) +### Page titles (H1) * Create concise page titles and format as H1. The title should be able to fit on 1-2 lines. * Every page must have an H1 heading, in addition to the page title being defined in the SEO meta tags. @@ -169,14 +171,14 @@ We aim to use consistent organization that is also user-centered and accessible. * Use headings in a logical manner, and the site will automatically generate anchor links for H2 and H3 tags and place them in a Table of Contents (TOC) in the right column. -* Avoid H4 levels and above within guide and template pages. As stated elsewhere in this style guide, technical documents with > 3 levels of structured headings (H4 or ####) usually indicates clarity, organization, or structural issues and should be revised. +* Avoid H4 levels and above within guide and template pages. As stated elsewhere in this style guide, technical documents with more than 3 levels of structured headings (H4 or ####) usually indicates clarity, organization, or structural issues and should be revised. * H4 headings are reserved (at this time) for glossary terms. This standardization will make it easier for us to extend glossary functionality across the docs in the future, such as tool tips. -### Listing Prerequisites (Before You Begin) +### Listing prerequisites (before you begin) * Add a "Before You Begin" section at the top of the document if there are tasks a user needs to complete before continuing with the current task, e.g. installing a module, downloading a software update, etc. -* Use the title "Before You Begin"and format as H2. It should follow the page overview/intro section or table of contents. +* Use the title "Before You Begin" and format as H2. It should follow the page overview/intro section or table of contents. * Include all the tasks the user needs to complete, including links to aid in usability. Use a bulleted list for more than 2 prerequisite items. **Example**:
@@ -186,7 +188,7 @@ We aim to use consistent organization that is also user-centered and accessible. ### Callouts -* Use callouts to direct users to information necessary to complete a task or information of special importance. When adding a callout to a document, use sentence case and use bold text sparingly. +* Use callouts to direct users to information necessary to complete a task or information of special importance. When adding a callout to a document, use sentence case. * Use the correct callout type based on the type of issue: a) info/general, b) warning, c) error. Our documentation platform supports 4 different callout types. * The default and info callouts are used to share non-sensitive, non-breaking info with users, such as suggestions or best practices that might make the installation or deployment easier. @@ -207,7 +209,7 @@ We aim to use consistent organization that is also user-centered and accessible. * Use callouts sparingly as too many can be confusing to readers. **As a general rule of thumb:** pages with more than 2 callouts likely needs revision and/or a discussion with an Optimism developer or product manager to ensure guide content accuracy. -### Code Samples +### Code samples * Use code samples as often as possible to help explain concepts. Can be used in guides or tutorials, but every tutorial should have at least one code sample to be useful to developers. * Any bits of code should be wrapped in backticks and use built-in syntax highlighting. Most documentation platforms automatically apply syntax highlighting when properly defined inside the code block. @@ -231,7 +233,7 @@ console.log('hello, world') * adding or showing the line numbers within the code block (easily refer to a certain code lines within the documentation) * highlighting lines or strings in the code block to draw user's attention to specific areas -### Images, Screenshots, & Icons +### Images, screenshots, & icons * Images, screenshots, and icons are stored in the `public/img` directory in the root folder. * Every image and screenshot should have descriptive alt text. @@ -280,7 +282,7 @@ clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allo Developers trust that we will lead them to sites or pages related to their reading content. In order to maintain that trust, it's important that links are transparent, up-to-date, and lead to legitimate resources. -### Internal Links +### Internal links * Internal links are automatically generated based on the H2 and H3 title tags. @@ -292,11 +294,11 @@ Developers trust that we will lead them to sites or pages related to their readi * To link to an anchor, such as an H3 tag within a page, you need to append it to the page name preceded by `#`, like this **example**: `[any descriptive text](/chain/getting-started/overview#test-your-application)`. -### Linking Across Pages +### Linking across pages * Use absolute or relative links when linking across pages in the site. Absolute links are cleaner and easier to work with when pages are nested, so they are the recommended option. - **Examples**: absolute link `(/protocol/deposit-flow)` versus relative link `(../../protocol/deposit-flow)` + **Examples**: absolute link `(/stack/transactions/deposit-flow)` versus relative link `(../../protocol/deposit-flow)` * Use the exact title of the page when linking to it in a sentence, whenever possible, and display it in title case. The link should use default styling with no other formatting (bold, italics, quotations). @@ -314,19 +316,19 @@ Developers trust that we will lead them to sites or pages related to their readi **Example**: For more information, see [Article Title](/builders/app-developers/bridging/standard-bridge). -## Content Types +## Content types Content types help manage technical content by defining the purpose and common structure for each file type. All content types used in these technical docs have attributes or properties, as defined below. -| Document type | Purpose | Examples | -| ------------------ | ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------- | -| Overviews | General introduction to a product or feature, provides a happy-path for readers | [Smart Contract Overview](/stack/smart-contracts) | -| Guides | Explain what things are and how they work | [Standard Bridge Guide](/builders/app-developers/bridging/standard-bridge) | -| Quick Start Guides | Briefly explain how to "minimally" get started with a product, often in 30 minutes or less | [Superchain App Quick Start](/builders/app-developers/quick-start) | -| Tutorials | Provide task-oriented guidance with step-by-step "learn by doing" instructions | [Bridging ERC-20 tokens with the Optimism SDK](/builders/app-developers/tutorials/cross-dom-bridge-erc20) | -| FAQs | Address frequently asked questions | [FAQ: OP Mainnet Security Model](/chain/security/faq) | -| Troubleshooting | List common troubleshooting scenarios and solutions | [Troubleshooting: Run a Node](/builders/node-operators/management/troubleshooting) | -| Reference | Provide deep, theoretical knowledge of the internal workings of a system, such as API endpoints and specifications | [Node and RPC Providers](/builders/tools/connect/rpc-providers) | +| Document type | Purpose | Examples | +| ------------------ | ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------- | +| Overviews | General introduction to a product or feature, provides a happy-path for readers | [Smart Contract Overview](/stack/smart-contracts) | +| Guides | Explain what things are and how they work | [Standard Bridge Guide](/builders/app-developers/bridging/standard-bridge) | +| Quick Start Guides | Briefly explain how to "minimally" get started with a product, often in 30 minutes or less | [Superchain App Quick Start](/builders/app-developers/quick-start) | +| Tutorials | Provide task-oriented guidance with step-by-step "learn by doing" instructions | [Bridging ERC-20 tokens with viem](/builders/app-developers/tutorials/cross-dom-bridge-erc20) | +| FAQs | Address frequently asked questions | [FAQ: OP Mainnet Security Model](/chain/security/faq) | +| Troubleshooting | List common troubleshooting scenarios and solutions | [Troubleshooting: Run a Node](/builders/node-operators/management/troubleshooting) | +| Reference | Provide deep, theoretical knowledge of the internal workings of a system, such as API endpoints and specifications | [Node and RPC Providers](/builders/tools/connect/rpc-providers) | ### Overviews @@ -356,9 +358,9 @@ To maintain consistency, guides should include all these items: * one or more visual elements (e.g., images, screenshots, illustrations, and/or code samples) * next steps section: links to related tutorials, other guides, troubleshooting, etc. -### Quick Starts +### Quick starts -A Quick Start Guide should be brief (thus "quick"), easy to read, and focused on helping customers get started with only the basics of your product or service. It is usually a condensed version of a longer getting started guide (or a longer tutorial), so it is not a replacement but an accompaniment or companion piece to the docs set. +A Quick start guide should be brief (thus "quick"), easy to read, and focused on helping customers get started with only the basics of your product or service. It is usually a condensed version of a longer getting started guide (or a longer tutorial), so it is not a replacement but an accompaniment or companion piece to the docs set. As a rule, this content type should describe only one scenario. It's value lies in its simplicity and ability to speed up onboarding (e.g., installation, deployment, etc.) and developers' first steps, thus improving the developer experience. To maintain consistency, quick start guides should include these items: @@ -403,6 +405,8 @@ When writing tutorials or quick starts, steps should be written in parallel styl ### FAQs +Whenever possible, we should avoid using FAQs due to their lack of readability and difficulty of maintenance. + FAQs address common questions developers have/might ask about a product, feature, or service. FAQs should be written from the developer's perspective. If there are more than two steps in the answer, use a numbered list. Place FAQs onto their own separate pages, whenever possible, and link to the FAQ from within the respective guide or tutorial. To maintain consistency, FAQs should include all of these items: @@ -433,7 +437,7 @@ The heading level for FAQs will vary based on if it's an FAQ-only doc or if FAQs Include a category heading when you need to group related FAQ content (e.g., See the Optimism Glossary for a detailed example). Category headings are optional, but helpful, for longer FAQs. -### Troubleshooting Guides +### Troubleshooting guides Troubleshooting guides list common problems a developer might encounter while using a product or service, identifies the symptoms, and offers solutions to these problems. It is important to accurately capture symptoms produced by the system or interface (e.g., error messages, unexpected page refresh/reload, spinning wheel, etc.), so developers know if their system response aligns with one of the common problems identified in the troubleshooting guide. @@ -448,7 +452,7 @@ To maintain consistency, troubleshooting guides should include all of these item * solution (step-by-step) * next steps section: links to related tutorials, other guides, etc. -### Technical Reference +### Technical reference Technical references provide deep, theoretical knowledge of the internal workings of a system. These often come in the form of requirements or system specifications developers need to run the product efficiently, so lists and tables, such as API endpoints and error codes are commonplace. A technical reference page is usually quite long, so it is best practice to embed a table of contents (TOC) at the top of the page to help organize material for developers. From a usability perspective, this practice shows developers what will be covered in the reference in advance, and allows them to jump to a specific section, if desired. @@ -463,21 +467,21 @@ To maintain consistency, technical references should include all these items: Technical references often include more links throughout the document than other content types, often linking to other technical references, guides, tutorials, glossary definitions, etc. Since the purpose of technical reference material is to educate developers on a deeper level about the topic of their choosing, this is a common and expected practice and is a good indication of a strong technical reference. -## General Formatting +## General formatting ### Fonts Fonts in Optimism technical documentation are setup to follow brand guidelines established by marketing (e.g., heading fonts are different than body or paragraph font). Please do not change them. -### Bullets & Unordered Lists +### Bullets & unordered lists Please use `*` instead of `-` for items in a list. This maintains consistency across the docs. -### Date & Numbers +### Date & numbers * Use the full month, day, year format for dates whenever possible. Do not abbreviate the month. In a form or when space is limited, use slashes in the format of month/day/year without any leading zeros. - **Examples**: `January 10, 2014` or `1/10/2014` + **Examples**: `January 10, 2014` or `2024/01/10` * Spell out all numbers under 10. For numbers 10 and above, use the numeral. @@ -497,7 +501,7 @@ Please use `*` instead of `-` for items in a list. This maintains consistency ac ### Punctuation -* **Ampersand (&)** Only use "&"in headings where items are grouped or in proper names. Do not use in sentences. +* **Ampersand (&)** Only use "&" in headings where items are grouped or in proper names. Do not use in sentences. * **Colon (:)** Use to introduce a list or series. @@ -519,4 +523,4 @@ Please use `*` instead of `-` for items in a list. This maintains consistency ac **Example**: `developer-focused product` or `company-wide holiday` -* **Slash (/)** Avoid using as the slash is reserved for file names (see above). Use "or," "and,"or "or both"instead. +* **Slash (/)** Avoid using as the slash is reserved for file names (see above). Use "or," "and," or "both" instead. diff --git a/pages/connect/resources.mdx b/pages/connect/resources.mdx new file mode 100644 index 000000000..a4ae2c526 --- /dev/null +++ b/pages/connect/resources.mdx @@ -0,0 +1,15 @@ +--- +title: Resources +description: Documentation covering Glossary in the Resources section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Resources + +Documentation covering Glossary in the Resources section of the OP Stack ecosystem. + + + + diff --git a/pages/connect/resources/glossary.mdx b/pages/connect/resources/glossary.mdx index 22a920398..e1c411053 100644 --- a/pages/connect/resources/glossary.mdx +++ b/pages/connect/resources/glossary.mdx @@ -10,16 +10,16 @@ import { Callout } from 'nextra/components' The glossary provides definitions of important terminology used throughout the Optimism Developer Documentation. To make revisions to this page, please [submit an issue](https://github.com/ethereum-optimism/docs/issues/new?assignees=\&labels=glossary%2Cdocumentation%2Ccommunity-request\&projects=\&template=suggest_glossary_term.yaml\&title=%5BGLOSSARY%5D+Add+PR+title). -## Table of Contents +## Table of contents * [General Terms](#general-terms) * [OP Profile & Identity](#op-profile--identity) * [OP Stack & OP Superchain](#op-stack--op-superchain) * [Protocol](#protocol) -## General Terms +## 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. @@ -30,10 +30,10 @@ A sequential list of transactions, along with a couple of properties stored in t 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 the that L1 block time is 12s as that is the L1 [time slot](#time-slot). However, in +*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 @@ -43,11 +43,11 @@ Delegates are individuals who have volunteered to actively participate in the go 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,14 +55,14 @@ 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. @@ -74,19 +74,19 @@ Refers the Ethereum blockchain, used in contrast to [layer 2](#layer-2-l2), whic 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 @@ -113,7 +113,7 @@ The rollup node receives L2 transactions from users, which it uses to create L2 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 second (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). @@ -140,7 +140,7 @@ behavior. A rollup node running in validator mode is sometimes called *a replica \[[return to top](#table-of-contents)] -## OP Profile & Identity +## OP profile & identity #### Attestations @@ -167,7 +167,7 @@ A system that enables individuals to have greater control and ownership over the 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. @@ -183,19 +183,19 @@ 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. @@ -203,33 +203,33 @@ A fault proof where challenges are evaluated using an onchain game which is guar 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. @@ -335,7 +335,7 @@ a better compression rate, hence reducing data availability costs. #### 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 too large to include in a single +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 diff --git a/pages/index.mdx b/pages/index.mdx index 6c276002e..6d4853af9 100644 --- a/pages/index.mdx +++ b/pages/index.mdx @@ -11,37 +11,41 @@ import { Cards, Card } from 'nextra/components' Welcome to the Optimism Docs, the unified home of the [Optimism Collective's](/connect/resources/glossary#optimism-collective) technical documentation and information about the [OP Stack](/stack/getting-started). Information about the Optimism Collective's governance, community, and mission can be found on the [Optimism Community Hub](https://community.optimism.io/docs/governance/). -## Guides for Builders +## Guides for builders -Whether you're a developer building a app on OP Mainnet, a node operator running an OP Mainnet node, or a chain operator launching your own OP Stack chain, you'll find everything you need to get started right here. +Whether you're a developer building an app on OP Mainnet, a node operator running an OP Mainnet node, or a chain operator launching your own OP Stack chain, you'll find everything you need to get started right here. - } /> + } /> - } /> + } /> - } /> + } /> - } /> + } /> - } /> + } /> + -## Featured Tools +## Featured tools Check out these amazing tools, so you can get building with Optimism. - } /> + } /> } /> } /> - } /> + } /> + + } /> + -## Learn About Optimism +## Learn about Optimism OP Mainnet is an [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) Layer 2 blockchain connected to Ethereum. The OP Stack is the standardized, shared, and open-source development stack that makes it easy to spin up your own production-ready Layer 2 blockchain just like OP Mainnet. diff --git a/pages/stack/_meta.json b/pages/stack/_meta.json index a56d9ee02..fb6fe060f 100644 --- a/pages/stack/_meta.json +++ b/pages/stack/_meta.json @@ -1,12 +1,21 @@ { - "getting-started": "Getting Started: OP Stack", - "differences": "Differences Between Ethereum and OP Stack Chains", - "components": "OP Stack Components", - "smart-contracts": "Smart Contracts", - "explainer": "Superchain Explainer", - "design-principles": "Design Philosophy & Principles", - "protocol": "Protocol", + "getting-started": "Getting started: OP Stack", + "differences": "Differences between Ethereum and OP Stack chains", + "explainer": "Superchain explainer", + "design-principles": "Design philosophy & principles", + "components": "OP Stack components", + "smart-contracts": "Smart contracts", + "rollup": "Rollup", + "fault-proofs": "Fault proofs", "transactions": "Transactions", + "features": "Features", "security": "Security", - "operators": "Operators" + "--- EXPERIMENTAL": { + "title": "EXPERIMENTAL", + "type": "separator" + }, + "opcm": "OP Contracts Manager", + "interop": "Interoperability", + "beta-features": "Beta features", + "research": "Research" } diff --git a/pages/stack/beta-features.mdx b/pages/stack/beta-features.mdx new file mode 100644 index 000000000..24257e8e3 --- /dev/null +++ b/pages/stack/beta-features.mdx @@ -0,0 +1,17 @@ +--- +title: Beta Features +description: Documentation covering Alt Da Mode, Custom Gas Token in the Beta Features section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Beta Features + +Documentation covering Alt Da Mode, Custom Gas Token in the Beta Features section of the OP Stack ecosystem. + + + + + + diff --git a/pages/stack/beta-features/_meta.json b/pages/stack/beta-features/_meta.json new file mode 100644 index 000000000..032cb72c0 --- /dev/null +++ b/pages/stack/beta-features/_meta.json @@ -0,0 +1,4 @@ +{ + "custom-gas-token": "Custom gas token", + "alt-da-mode": "Alt-DA Mode" +} diff --git a/pages/stack/protocol/features/alt-da-mode.mdx b/pages/stack/beta-features/alt-da-mode.mdx similarity index 97% rename from pages/stack/protocol/features/alt-da-mode.mdx rename to pages/stack/beta-features/alt-da-mode.mdx index 122650d9d..446afe4d8 100644 --- a/pages/stack/protocol/features/alt-da-mode.mdx +++ b/pages/stack/beta-features/alt-da-mode.mdx @@ -1,5 +1,5 @@ --- -title: Alt-DA Mode Explainer +title: Alt-DA Mode explainer lang: en-US description: Learn the basic process, benefits, and considerations for running an Alt-DA mode chain. --- @@ -14,19 +14,19 @@ import { AltCallout } from '@/components/WipCallout' Alt-DA Mode enables seamless integration of various Data Availability (DA) Layers, regardless of their commitment type, into the OP Stack. This allows any chain operator to launch an OP Stack chain using their favorite DA Layer for sustainably low costs. -## Sustainably Low Costs +## Sustainably low costs In order to function securely, OP Stack chains need to ensure that L2 transaction data is available to all node operators. EIP-4844 has massively reduced Ethereum L1 data costs for OP Stack rollups, but blobspace is on the path to congestion, which will lead to higher blob fees and increased chain operator costs. Over the past few years, alternative DA Layers have been built as an alternative place for L2s to post L2 data that is cheap, with more throughput, but remains stable and minimizes security and decentralization tradeoffs. -## How It Works +## How it works Alt-DA Mode introduces a standard interface for reading and writing data to Alt-DA Layers and allows any DA Layer team to build and maintain their own [DA Server](https://specs.optimism.io/experimental/alt-da.html#da-server) to enable the OP Stack to communicate with their DA Layer. The DA Server handles any of the custom DA Layer logic, such as key management, interfacing with a DA Layer node, etc. This abstraction ensures that new features and improvements to Alt-DA Mode will come to all chains using Alt-DA Mode, regardless of the DA Layer they choose to use. Although the Data Availability Challenge (DA Challenge) will be disabled at launch, this integration provides a solution compatible with upcoming OP Stack features. -## Future Improvements +## Future improvements Just like with the Rollup configuration of the OP Stack, core contributors are continuously improving the decentralization, security, and cost-effectiveness of Alt-DA Mode. Some of the future features that core contributors are looking to build are: @@ -39,7 +39,7 @@ Just like with the Rollup configuration of the OP Stack, core contributors are c Alt-DA Mode will always have more trust assumptions than simply posting data to L1 Ethereum. In its current initial iteration, Alt-DA Mode with generic commitments fully trusts the chain operator to make data available by both posting all data to the DA Layer and posting corresponding commitments to L1 Ethereum. If a chain operator posts incorrect commitments or does not post data to the DA Layer, it will not be accessible by node operators. The future improvements mentioned above are intended to address this trust assumption. After DA Bridges are integrated, then as long as the DA Layer and its DA Bridge are decentralized and functioning as intended, then once data is posted to the DA Layer, the L1 commitments would be bridged without relying on a single trusted party. It is important to remember that, even after integrating the DA Bridges and Fault Proofs, there will still be an added trust assumption that the DA Layer and DA Bridge are secure and functioning as intended. -## Next Steps +## Next steps * Ready to get started? Read our guide on how to [deploy your Alt-DA Mode chain](/builders/chain-operators/features/alt-da-mode). * For more info about how Alt-DA Mode works under the hood, [check out the specs](https://specs.optimism.io/experimental/alt-da.html). diff --git a/pages/stack/protocol/features/custom-gas-token.mdx b/pages/stack/beta-features/custom-gas-token.mdx similarity index 96% rename from pages/stack/protocol/features/custom-gas-token.mdx rename to pages/stack/beta-features/custom-gas-token.mdx index b673f6dd0..9065976c7 100644 --- a/pages/stack/protocol/features/custom-gas-token.mdx +++ b/pages/stack/beta-features/custom-gas-token.mdx @@ -1,12 +1,15 @@ --- -title: Custom Gas Token Explainer +title: Custom Gas token explainer lang: en-US description: Learn the basic process, benefits, and considerations for running a custom gas token chain. --- import { Callout } from 'nextra/components' +import { CGTCallout } from '@/components/WipCallout' -# Custom Gas Token Explainer + + +# Custom gas token explainer The Custom Gas Token configuration lets OP Stack chain operators deploy their chain allowing a specific ERC-20 token to be deposited in as the native token to pay for gas fees. Chain operators can now customize their gas token to: @@ -15,7 +18,7 @@ The Custom Gas Token configuration lets OP Stack chain operators deploy their ch * facilitate in-game economies, allowing players to pay for gas with their in-game currency * build alignment with the community of any token. -## Native Gas Tokens +## Native gas tokens By default, L2 OP Stack chains allow users to deposit ETH from L1 into the L2 chain as native L2 token that can then be used to pay for gas fees. Chain operators wanted to configure the stack to use a custom token to pay for gas, other than ETH. @@ -32,7 +35,7 @@ When deposited, this L1 ERC-20 token will become the native gas token on the L2 * Understand the [constraints required for your chain to be able to join the Superchain](#considerations) when setting the custom gas token for your chain. -## How It Works +## How it works This is the general flow of how custom gas tokens work on the OP Stack: @@ -66,7 +69,7 @@ The custom token being used must adhere to the following constraints to be able -## Next Steps +## Next steps * Ready to get started? Read our guide on how to [deploy your custom gas token chain](/builders/chain-operators/features/custom-gas-token). * For more info about how the custom gas token feature works under the hood, [check out the specs](https://specs.optimism.io/experimental/custom-gas-token.html). diff --git a/pages/stack/components.mdx b/pages/stack/components.mdx index a6228362e..fb3ad07f6 100644 --- a/pages/stack/components.mdx +++ b/pages/stack/components.mdx @@ -1,12 +1,12 @@ --- -title: OP Stack Components +title: OP Stack components lang: en-US description: Learn about OP Stack components including the different layers and modules available for development. --- import { Callout } from 'nextra/components' -# OP Stack Components +# OP Stack components **The OP Stack is a common development stack for building L2 blockchain ecosystems, built by the Optimism Collective to power Optimism.** @@ -22,7 +22,7 @@ This doesn't include all of the modules or layers that may exist in the future, ## Layers -### Data Availability +### Data availability The Data Availability Layer defines where the raw inputs to an OP Stack based chain are published. An OP Stack chain can use a single Data Availability module to source its input data. Because an OP Stack chain is derived from the Data Availability Layer, the Data Availability module used has a significant impact on the security model of a system. For example, if a certain piece of data can no longer be retrieved from the Data Availability Layer, it may not be possible to sync the chain. @@ -37,11 +37,11 @@ Ethereum DA is currently the most widely used Data Availability module for the O The Sequencing Layer determines how user transactions on an OP Stack chain are collected and published to the Data Availability Layer module(s) in use. In the default Rollup configuration of the OP Stack, Sequencing is typically handled by a single dedicated Sequencer. Rules defined in the Derivation Layer generally restrict the Sequencer's ability to withhold transactions for more than a specific period of time. In the future, Sequencing will be modular such that chains can easily select and change the mechanism that controls their current Sequencer. -#### Single Sequencer +#### Single sequencer The default Sequencer module for the OP Stack is the Single Sequencer module in which a dedicated actor is given the ability to act as the Sequencer. The Single Sequencer module allows a governance mechanism to determine who may act as the Sequencer at any given time. -#### Multiple Sequencer +#### Multiple sequencer A simple modification to the Single Sequencer module is the Multiple Sequencer module in which the Sequencer at any given time is selected from a pre-defined set of possible actors. Individual OP Stack based chains would be able to determine the exact mechanism that defines the set of possible Sequencers and the mechanism that selects a Sequencer from the set. @@ -71,7 +71,7 @@ The EVM is an Execution Layer module that uses the same state representation and * [Specifications](https://specs.optimism.io/protocol/exec-engine.html) (where it differs from [geth](https://geth.ethereum.org/)) * [Source code](https://github.com/ethereum-optimism/op-geth/tree/09ade3df6d1d3a4f8f308553825348be132bc960) -### Settlement Layer +### Settlement layer The Settlement Layer is a mechanism on external blockchains that establish a **view** of the state of an OP Stack chain (target) on those external, third-party chains (including other OP Stack chains). For each target chain, there may be one or more Settlement mechanisms on one or more external chains. Settlement Layer mechanisms are **read-only** and allow a third-party chain to make decisions, potentially impacting their own state, based on the state of the target OP Stack chain. @@ -79,7 +79,7 @@ The term "Settlement Layer" has its origins in the fact that Settlement Layer me Once a transaction is published and finalized on the corresponding Data Availability layer, the transaction is also finalized on the OP Stack chain. Short of breaking the underlying Data Availability layer, it can no longer be modified or removed. It may not be accepted by the Settlement Layer yet because the Settlement Layer needs to be able to verify transaction *results*, but the transaction itself is already immutable. -#### Attestation-based Fault Proof +#### Attestation-based fault proof An Attestation-based Fault Proof mechanism uses an optimistic protocol to establish a view of an OP Stack chain. In optimistic settlement mechanisms generally, **Proposer** entities can propose what they believe to be the current valid state of the OP Stack chain. If these proposals are not invalidated within a certain period of time (the "challenge period"), then the proposals are assumed by the mechanism to be correct. In the Attestation Proof mechanism in particular, a proposal can be invalidated if some threshold of pre-defined parties provide attestations to a valid state that is different than the state in the proposal. This places a trust assumption on the honesty of at least a threshold number of the pre-defined participants. @@ -98,10 +98,10 @@ A Validity Proof Settlement mechanism uses a mathematical proof to attest to the The Governance Layer refers to the general set of tools and processes used to manage system configuration, upgrades, and design decisions. This is a relatively abstract layer that can contain a wide range of mechanisms on a target OP Stack chain and on third-party chains that impact many of the other layers of the OP Stack. -#### MultiSig Contracts +#### MultiSig contracts MultiSig Contracts are smart contracts that carry out actions when they receive a threshold of signatures from some pre-defined set of participants. These are often used to manage upgrades of components of an OP Stack based system. Currently, this is the mechanism used to manage upgrades of the bridge contracts on OP Mainnet. The security of a MultiSig Contract system depends on many different factors, including the number of participants, the threshold, and the safety procedures of each individual participant. -#### Governance Tokens +#### Governance tokens Governance Tokens are widely used to decentralize decision making. Although the exact functionality of a Governance Token varies on a case-by-case basis, the most common mechanisms allow token holders to vote on some subset of decisions that a project must make. Voting can either be carried out directly or via delegation. diff --git a/pages/stack/design-principles.mdx b/pages/stack/design-principles.mdx index 3ad07f00c..d18a01b23 100644 --- a/pages/stack/design-principles.mdx +++ b/pages/stack/design-principles.mdx @@ -1,16 +1,16 @@ --- -title: Design Philosophy & Design Principles +title: Design philosophy & design principles lang: en-US description: Learn the design philosophy and design principles for contributing to the OP Stack. --- import { Callout } from 'nextra/components' -# Design Philosophy & Design Principles +# Design philosophy & design principles This guide covers design philosophy and design principles for contributing to the OP Stack. -## Design Philosophy +## Design philosophy OP Stack is built according to a strong design philosophy that stands on four main pillars: **simplicity**, **pragmatism**, **sustainability**, and, of course, **optimism**. It's important to understand these pillars as they heavily influence the design of Optimism as a whole. @@ -69,7 +69,7 @@ We keep this in mind whenever we're creating new features or trying to simplify Optimism is as close to Ethereum as possible not only for pragmatic reasons, but because Optimism exists so that Ethereum can succeed. We hope that you can see the influence of this philosophy when looking at Optimism's design. -## Design Principles for USEful Software +## Design principles for USEful software The OP Stack is USEful software. The OP Stack is a set of software components for building L2 blockchain ecosystems, built by the Optimism Collective to power Optimism. Components to be added to the OP Stack should be built according to three key design principles: **U**tility, **S**implicity, **E**xtensibility. diff --git a/pages/stack/differences.mdx b/pages/stack/differences.mdx index ec6ec411f..5f370f4b0 100644 --- a/pages/stack/differences.mdx +++ b/pages/stack/differences.mdx @@ -1,6 +1,7 @@ --- title: Differences between Ethereum and OP Stack Chains lang: en-US +tags: ["eng-protocol"] description: Learn the minor differences between the behavior of Ethereum and OP Stack chains. --- @@ -11,6 +12,16 @@ import { Callout } from 'nextra/components' OP Stack chains are designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) and introduces as few changes as possible to the Ethereum protocol. However, there are some minor differences between the behavior of Ethereum and OP Stack chains that developers should be aware of. +## Bridging + +### Bridging - Deposit Transactions + +Deposit transactions don't exist on L1's, and are how transactions on an L2 can be initiated from the L1. Importantly, this is how bridge applications can get L1 ETH or tokens into an L2 OP Stack chain. You can read more on deposit transactions [here](/stack/transactions/deposit-flow). + +### Bridging - Withdrawal Transactions and Fault Proofs + +Withdrawal transactions are how the state of the L2 rollup can be proven to the L1. Often this involves users withdrawing tokens or ETH to the L1. Fault proofs are the mechanism by which withdrawal transactions are currently proven to the L1. You can read more about fault proofs [here](/stack/fault-proofs/explainer). + ## Opcodes | Opcode | Solidity Equivalent | Behavior | @@ -20,7 +31,7 @@ However, there are some minor differences between the behavior of Ethereum and O | `ORIGIN` | `tx.origin` | If the transaction is an L1 β‡’ L2 transaction triggered by a smart contract on L1, then `tx.origin` is set to the [aliased address](#address-aliasing) of the address that triggered the L1 β‡’ L2 transaction. Otherwise, this opcode behaves normally. | | `CALLER` | `msg.sender` | If the transaction is an L1 β‡’ L2 transaction triggered by a smart contract on L1, and this is the first call frame (rather than an internal transaction from one contract to another), the same [address aliasing](#address-aliasing) behavior applies. | -### Address Aliasing +### Address aliasing Address aliasing is an important security feature that impacts the behavior of transactions sent from L1 to L2 by smart contracts. @@ -50,18 +61,32 @@ In all other cases, the transaction sender address is set according to the same ## Transactions -### Transaction Fees +### Transaction fees Transactions on OP Stack chains must pay for an [L1 data fee](/stack/transactions/fees#the-l1-data-fee) on top of the standard [execution gas fee](/stack/transactions/fees#execution-gas-fee) you would expect on Ethereum. Refer to the guide on [OP Stack Transaction Fees](/stack/transactions/fees) for more information. -### EIP-1559 Parameters +You can use the [JS library viem](https://viem.sh/op-stack) to estimate the entire transaction gas costs, including the L1 Data Fee. + +### EIP-1559 parameters The base fee on OP Stack is, like Ethereum, computed via the [EIP-1559](https://notes.ethereum.org/@vbuterin/eip-1559-faq) mechanism. The EIP-1559 parameters used by OP Stack differ per chain. -### Mempool Rules +### Mempool rules + +Unlike Ethereum, OP Stack chains do not have a public mempool. +The OP Stack mempool is currently only visible to the Sequencer. +The Sequencer executes transactions from the mempool in priority fee order (highest fee first). + +## 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). + +## What's Next + +There are various useful tools linked above. Here are a few more tools and links you may want to check out: + +* [OP-viem](https://viem.sh/op-stack): JS framework that can handle many of these unique functions on OP Chains. It is similar to Ethers.js for OP Stack chains. -By default, OP Stack chains do not have a large public mempool like Ethereum. -OP Stack mempools are typically only visible to the Sequencer of the given chain and transactions are generally executed in priority fee order (highest fee first). -This is not a required behavior and certain chains may choose to have a public mempool. +* [Specs](https://specs.optimism.io/root.html): For more in-depth technical explanations and examples. diff --git a/pages/stack/explainer.mdx b/pages/stack/explainer.mdx index 888807a9d..a1fb71bef 100644 --- a/pages/stack/explainer.mdx +++ b/pages/stack/explainer.mdx @@ -1,12 +1,12 @@ --- -title: Superchain Explainer +title: Superchain explainer lang: en-US description: Learn about Optimism Superchain components, features, and roadmap. --- import { Callout } from 'nextra/components' -# Superchain Explainer +# Superchain explainer Stay up to date on the Superchain and the OP Stack by subscribing to the [Optimism Developer Blog](https://blog.oplabs.co/) @@ -22,7 +22,7 @@ This is the detailed explanation. [Click here for a less technical introduction] Today, the Superchain is a concept and in-flight project, not a concrete reality. This documentation represents our best current guess as to what the Superchain's components, features, and roadmap will be. Ultimately, its actualization will depend on (and change alongside) contributions from across the entire Optimism Collective. We cannot wait to see where it goes. -## The Scalability Vision +## The scalability vision ### Blockchain tech today is insufficient for the decentralized web @@ -54,7 +54,7 @@ This hypothetical isn't a dream, it's a tangible vision for the future which has With the support of the industry, we think a clear picture for how to architect a truly scalable blockchain is beginning to come into view. We call it the "Superchain". This document lays out the core technical principles underlying the Superchain architecture, as well as a set of tangible projects which, when complete, we believe will finally realize the blockchain scalability vision. It will be a multi-year (if not decade) journey. However, if we know roughly where we're going, we'll get there a little faster. -## Foundational Superchain Concepts +## Foundational Superchain concepts ### Horizontal scalability requires multiple chains… @@ -85,7 +85,7 @@ By using L2 chains to comprise the multi-chain ecosystem, it becomes possible to 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 Overview +## Superchain overview ### The Superchain at a glance @@ -113,7 +113,7 @@ In order for Optimism to upgrade to a Superchain, it must have the following pro Once Optimism has satisfied these properties, it may be considered a Superchain. -## Upgrading Optimism to Become a Superchain +## Upgrading Optimism to become a Superchain We believe the following changes (after the Bedrock release) are required to create an initial Superchain that makes it possible to deploy and upgrade many chains with the same bridge: @@ -146,9 +146,9 @@ In order to address these issues, we can introduce two features: 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. -We can enable these two features first by introducing a permissionless proof system to the Optimism bridge contracts. With the modular proof design introduced in Bedrock, proofs may come in the form of fault proofs or validity proofs (e.g. zero knowledge proofs). However, until validity proofs are productionized, we assume withdrawals will use a fault proof system. +We can enable these two features first by introducing a permissionless proof system to the Optimism bridge contracts. With the modular proof design introduced in Bedrock, proofs may come in the form of fault proofs or validity proofs (e.g. zero knowledge proofs). However, until validity proofs are productionized, we assume withdrawals will use a Fault Proof System. -In the envisioned fault proof system, anyone can submit a withdrawal claim, and these withdrawal claims can be submitted at any time. Submitting withdrawal claims can be permissionless when claims come with bonds attached to them, as these bonds act as collateral if the claim is proven to be invalid. If a challenger successfully challenges the claim, the bond is paid out to the challenger for their participation in securing the system, thereby preventing spam even within this permissionless system. Additionally, there is no need to submit them at a regular interval because the fault proof game can efficiently prove the entire history of the chain since genesis. +In the envisioned Fault Proof System, anyone can submit a withdrawal claim, and these withdrawal claims can be submitted at any time. Submitting withdrawal claims can be permissionless when claims come with bonds attached to them, as these bonds act as collateral if the claim is proven to be invalid. If a challenger successfully challenges the claim, the bond is paid out to the challenger for their participation in securing the system, thereby preventing spam even within this permissionless system. Additionally, there is no need to submit them at a regular interval because the fault proof game can efficiently prove the entire history of the chain since genesis. The fault proof implementation may initially rely on a trusted set of chain attestors to be the final arbiter of disputes. Challengers must request attestations from a large number of chain attestors and combine these attestations into a single transaction called an attestation proof. The attestation proof is then used to challenge invalid claims. @@ -217,9 +217,9 @@ If each one of these pain points were addressed, it could be possible to build d The following is an overview of potential future enhancements, which when combined, addresses each one of these pain points. -### Multi-Proof Security +### Multi-proof security -#### Pain Point: +#### Pain point: 1. Withdrawal claims rely on a trusted set of chain attestors. @@ -227,13 +227,13 @@ The following is an overview of potential future enhancements, which when combin It is possible to replace the trusted set of chain attestors by introducing permissionless proofsβ€”such as Cannonβ€”where dispute resolution is entirely onchain. However, the challenge with entirely onchain proofs is there is no fallback mechanism if they were to break. To ensure that they will never fail, it is possible to introduce a multi-proof system which provides safety through redundancy. For more information on the multi-proof design click [here](https://web.archive.org/web/20230331065342/https://medium.com/ethereum-optimism/our-pragmatic-path-to-decentralization-cb5805ca43c1). -### Low Latency L2 to L2 Message Passing +### Low latency L2 to L2 message passing -#### Pain Point: +#### Pain point: 2. Cross-chain transactions are slow because they require waiting a challenge period. -#### Proposed Solution: +#### Proposed solution: Fault proofs introduce a UX burden because they require waiting a challenge period in order to safely finalize. This means that, depending on the length of your challenge period, users may need to wait a long time before their ETH and tokens are migrated from one OP Chain to the next. @@ -250,13 +250,13 @@ This heterogeneous bridging system means that developers can build their applica Mixing multiple proof systems enables developers to provide low-latency bridging for low value state and high-latency for high value state. It is even possible to turn low-security state which was instantly bridged into high-security state by proving the state's validity using a high-security high-latency bridge. This building block enables developers to make interesting security tradeoffs such as using a high threshold attestation proof with a high-security, high-latency fault proof fallback. -### Synchronous Cross-Chain Transactions +### Synchronous cross-chain transactions -#### Pain Point: +#### Pain point: 3. Cross-chain transactions are asynchronous, breaking the ability to perform atomic cross-chain transactions (like flash loans). -#### Proposed Solution: +#### Proposed solution: Traditional cross-chain messaging is done asynchronously, which means that cross-chain transactions are *not* atomic. For example, if a user would like to execute a cross-chain arbitrage transactionβ€”buying token A on chain A, and selling token B on chain Bβ€”there is no guarantee that their transaction executes in its entirety. The user might end up buying token A without having sold token B. @@ -264,13 +264,13 @@ It is possible to introduce synchronous cross-chain messaging and enable atomic With the combination of low-latency L2 to L2 message passing as well as shared sequencing, it is possible to perform complex transactions such as cross-chain flash loans. It is even possible to go further and create an EVM abstraction where individual smart contracts (or even individual storage slots) exist on different chains. -### Alt-Data Availability Layer β€” Plasma Protocol +### Alt-Data availability layer β€” Plasma Protocol -#### Pain Point: +#### Pain point: 4. Posting transactions to the Superchain is not-scalable because the transaction data must be submitted to L1 which has limited capacity. -#### Proposed Solution: +#### Proposed solution: Today L1 data availability (DA) does not scale nearly enough to be able to support internet-level scale. However, it is possible to extend the amount of data availability accessible to OP Chains by using a Plasma protocol which enables alternative DA providers to supplement the more limited L1 DA. @@ -290,19 +290,19 @@ A generic Plasma protocol is able to scale beyond what is possible on L1 because * If the DA Provider does not send the proof to the user, the user may submit a DA challenge. This forces the DA Provider to post the transaction data onchain. If the DA Provider does not submit the proof onchain, the hash is deleted. This ensures the user can always (after the challenge period) sync the Plasma chain. * DA challenge periods may be extended in case of heavy L1 congestion. * The user may also submit an L1 transaction to withdraw from the Plasma chain in order to switch their DA Provider. -* Settlement of Plasma chains use a near identical fault proof system to Rollup chains with the only difference being that additional data is derived from the chain using the hashes that are finalized in the Plasma Contract. +* Settlement of Plasma chains use a near identical Fault Proof System to Rollup chains with the only difference being that additional data is derived from the chain using the hashes that are finalized in the Plasma Contract. Because of the ability for hashes to reduce arbitrary size data into a constant size commitment, and the ability to parallelize transaction data hashing, it is possible to achieve near-perfect horizontal scalability of data commitments using Plasma DA. This means that it is possible to put massively scalable applications such as games or social media on Plasma chains. -### Multi-Chain App Frameworks +### Multi-chain app frameworks -#### Pain Points: +#### Pain points: 5. There are no easy-to-use frameworks for building scalable apps which utilize many OP Chains. 6. There is no easy-to-use wallet for managing ETH and tokens and apps across many OP Chains. -#### Proposed Solution (Sketch): +#### Proposed solution (Sketch): This is not a core protocol change, but instead tooling which can be built on top of the core Superchain protocols. The suggestions here are intended to give rough intuitions for how to build tools which improve the experience of deploying to the Superchain. @@ -320,7 +320,7 @@ These are some tools which could make developing on the Superchain a better expe With robust multi-chain app frameworks, it may become as easy to deploy cross-chain apps as it is to deploy apps which target a single chain. -## Get Involved +## Get involved We believe scaling blockchains will radically decentralize the internet and make it easy to create horizontally scalable, secure, and decentralized web applications. We think the Superchain release of the OP Stack could mark a major step towards realizing this vision. However, after the release, it will still take an enormous amount of work to realize the scalability vision. diff --git a/pages/stack/fault-proofs.mdx b/pages/stack/fault-proofs.mdx new file mode 100644 index 000000000..4da08bb26 --- /dev/null +++ b/pages/stack/fault-proofs.mdx @@ -0,0 +1,25 @@ +--- +title: Fault Proofs +description: Documentation covering Cannon, Challenger, Explainer, Fp Components, Fp Security, Mips in the Fault Proofs section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Fault Proofs + +Documentation covering Cannon, Challenger, Explainer, Fp Components, Fp Security, Mips in the Fault Proofs section of the OP Stack ecosystem. + + + + + + + + + + + + + + diff --git a/pages/stack/fault-proofs/_meta.json b/pages/stack/fault-proofs/_meta.json new file mode 100644 index 000000000..0bf43dd6e --- /dev/null +++ b/pages/stack/fault-proofs/_meta.json @@ -0,0 +1,8 @@ +{ + "explainer": "Fault proofs explainer", + "fp-components": "FP system components", + "cannon": "FPVM: Cannon", + "challenger": "OP-Challenger", + "mips": "MIPS.sol", + "fp-security": "FP Mainnet security" +} \ No newline at end of file diff --git a/pages/stack/protocol/fault-proofs/cannon.mdx b/pages/stack/fault-proofs/cannon.mdx similarity index 98% rename from pages/stack/protocol/fault-proofs/cannon.mdx rename to pages/stack/fault-proofs/cannon.mdx index 4a86b4ce6..4ad45ea78 100644 --- a/pages/stack/protocol/fault-proofs/cannon.mdx +++ b/pages/stack/fault-proofs/cannon.mdx @@ -1,5 +1,5 @@ --- -title: Fault Proof VM - Cannon +title: Fault proof VM - Cannon lang: en-US description: Learn about Cannon and its default operation as part of Optimism's Fault Proof Virtual Machine. --- @@ -7,7 +7,7 @@ description: Learn about Cannon and its default operation as part of Optimism's import Image from 'next/image' import { Callout } from 'nextra/components' -# Fault Proof VM: Cannon +# Fault proof VM: Cannon Cannon is an instance of a Fault Proof Virtual Machine (FPVM) that can be used as part of the Dispute Game for any OP Stack Blockchain. The Dispute Game itself is modular, allowing for any FPVM to be used in a dispute. @@ -23,7 +23,7 @@ Additionally, we will explore the differences between Cannon and the onchain `MI implementation, please refer to [MIPS reference](mips). Now for simplicity, when referring to Cannon in this documentation, we are referring to the offchain implementation. -## Control Flow +## Control flow ![Fault Proof Control Flow.](/img/op-stack/protocol/fault-proof-control-flow.svg) @@ -35,7 +35,7 @@ single L2 block state transition that they disagree on. ### OP-Challenger \<> Cannon -Once an active fault dispute game reaches a depth below attacking / defending L2 block state transitions, [OP-Challenger](/stack/protocol/fault-proofs/challenger) will run +Once an active fault dispute game reaches a depth below attacking / defending L2 block state transitions, [OP-Challenger](/stack/fault-proofs/challenger) will run Cannon to begin processing MIPS instructions within the FPVM. As part of processing MIPS instructions, Cannon will generate state witness hashes, which are the commitment to the results of the MIPS instructions' computation within the FPVM. Now, in the bisection game, OP-Challenger will provide the generated hashes until a single MIPS instruction is identified as the root disagreement between participants in the active dispute. Cannon will then @@ -55,7 +55,7 @@ same inputs will produce not only the same outputs, but the same execution trace OP-Program such that, given the same L2 output root state transition, can generate the same execution traces. This in turn generates the same witness proof for the exact same MIPS instruction that will be run onchain. -## Overview of Offchain Cannon components +## Overview of offchain Cannon components Now, we will go over each major component that makes up Cannon. Components are grouped by what functionality is being performed for Cannon, and may be correlated to one or more Go files. For brevity, each Go file will be explained at a high level, with the @@ -63,7 +63,7 @@ most important features / considerations highlighted. ![Cannon Components Overview.](/img/op-stack/protocol/cannon-internal-overview.svg) -### `mipsevm` State and Memory +### `mipsevm` state and memory As mentioned previously, the `mipsevm` is 32-bit, which means the full addressable address range is `[0, 2^32-1]`. The memory layout uses the typical monolithic memory structure, and the VM operates as though it were interacting directly with physical memory. @@ -114,7 +114,7 @@ The information stored is largely identical to the [VM execution state](mips#pac * Instead of storing just the memory Merkle root, there is a `Memory` Struct pointer for the binary Merkle tree representation of the entire 32-bit memory space. * There is an optional `LastHint` bytes variable, which can be used to communicate a Pre-image hint to avoid having to load in multiple prior Pre-images. -#### Generating the Witness Proof +#### Generating the witness proof Cannon handles two major components in the dispute game: generating state witness hashes for OP-Challenger to post during the execution trace bisection game, and generating the witness proof once a single MIPS instruction is reached as the root of disagreement in the fault dispute game. @@ -164,7 +164,7 @@ unimplemented functionality, any function within the ELF file that would require Patching the binary of these functions involves identifying problematic functions, searching for their corresponding symbols within the ELF file, and effectively stubbing out the function by returning immediately, and adding a `nop` to the delay slot. -### Instruction Stepping +### Instruction stepping Once the MIPS binary is loaded into Cannon, we can then begin to run MIPS instructions one at a time. [`run.go`](https://github.com/ethereum-optimism/optimism/blob/develop/cannon/cmd/run.go) contains the top-level @@ -197,7 +197,7 @@ However, there are differences between the two: 2. The `mipsevm` contains the entire 32-bit monolithic memory space, is responsible for maintaining the memory state based on the results of MIPS instructions, and generates the memory binary Merkle tree, Merkle root, and memory Merkle proofs. `MIPS.sol` is mostly stateless, and does not maintain the full memory space. Instead, it only requires the memory Merkle root, and up to two memory Merkle proofs: 1 for the instruction and 1 for potential load, store, or certain syscall instructions. 3. Unlike `MIPS.sol`, `mips.go` is responsible for writing Pre-images to the PreimageOracle Server, and optionally writing hints to the Server. -### PreimageOracle Interaction +### PreimageOracle interaction As mentioned previously, Cannon is responsible for setting up all state that may be required to run an instruction in `MIPS.sol`. Cannon is also responsible for interacting with the PreimageOracle Server, and directing OP-Challenger to provide Pre-images to diff --git a/pages/stack/protocol/fault-proofs/challenger.mdx b/pages/stack/fault-proofs/challenger.mdx similarity index 97% rename from pages/stack/protocol/fault-proofs/challenger.mdx rename to pages/stack/fault-proofs/challenger.mdx index 3f23d83f3..17be766d5 100644 --- a/pages/stack/protocol/fault-proofs/challenger.mdx +++ b/pages/stack/fault-proofs/challenger.mdx @@ -1,15 +1,15 @@ --- -title: OP-Challenger Explainer +title: OP-Challenger explainer lang: en-US -description: Learn about OP-Challenger and how it operates within the OP Stack's fault proof system. +description: Learn about OP-Challenger and how it operates within the OP Stack's Fault Proof System. --- import { Callout } from 'nextra/components' import Image from 'next/image' -# OP-Challenger Explainer +# OP-Challenger explainer -The `op-challenger` operates as the *honest actor* in the fault dispute system and defends the chain by securing the `OptimismPortal` and ensuring the game always resolves to the correct state of the chain. For verifying the legitimacy of claims, `op-challenger` relies on a synced, trusted rollup node as well as a trace provider (e.g., [Cannon](/stack/protocol/fault-proofs/cannon)). +The `op-challenger` operates as the *honest actor* in the fault dispute system and defends the chain by securing the `OptimismPortal` and ensuring the game always resolves to the correct state of the chain. For verifying the legitimacy of claims, `op-challenger` relies on a synced, trusted rollup node as well as a trace provider (e.g., [Cannon](/stack/fault-proofs/cannon)). Specifically, `op-challenger` performs the following actions: @@ -38,22 +38,22 @@ graph TD; The `cannon` and `op-program` executables are run in the `op-challenger` docker container as sub-processes when required to generate game trace data. -## Fault Detection Responses +## Fault detection responses `op-challenger` assesses each claim's validity, countering only those deemed invalid, following this logic: 1. If the trusted node agrees with the output, `op-challenger` takes no action. An honest challenger does nothing because there are no claims it disagrees with. It continues to monitor the game in case someone posts a counter-claim to the valid root claim, in which case the challenger will participate in the game to defend the proposal. 2. If the trusted node disagrees, `op-challenger` posts a counter-claim to challenge the proposed output. In contrast to the above, an honest challenger aims to delete any output roots that its trusted node disagrees with in order to claim the bond attached to it. The honest challenger assumes that their rollup node is synced to the canonical state and that the fault proof program is correct, so it is willing to put its money on the line to counter any faults. -## Fault Dispute Game Responses +## Fault dispute game responses `op-challenger` iterates through claims as stored in the contract, ensuring ancestors are processed before their descendants. For each claim, the honest challenger determines and tracks the set of honest responses to all claims, regardless of whether that response already exists in the full game state. -### Root Claim +### Root claim The root claim is considered to be an honest claim if and only if it has a [state witness Hash](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#claims) that agrees with the honest challenger's state witness hash for the root claim. -### Counter Claims +### Counter claims When a new claim is made in a dispute game, the honest challenger processes it and performs a response. The honest challenger should counter a claim if and only if: @@ -64,7 +64,7 @@ When a new claim is made in a dispute game, the honest challenger processes it a This implies the honest challenger never counters its own claim, since there is at most one honest counter to each claim, so an honest claim never has an honest sibling. -### Possible Moves +### Possible moves The challenger monitors each game as new claims are added and reacts according to the [honest actor algorithm](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html) to defend valid proposals and invalidate invalid proposals. A **move** is a challenge against an existing claim and must include an alternate claim asserting a different trace (e.g., attack, defend, or step). @@ -82,7 +82,7 @@ When one side of a `FaultDisputeGame`'s chess clock runs out, the honest challen The `FaultDisputeGame` does not put a time cap on resolution - because of the liveness assumption on honest challengers and the bonds attached to the claims they've countered, challengers are economically motivated to resolve the game quickly, thereby liquidating their funds and securing rewards. -## Next Steps +## Next steps * Ready to get started? Read our guide on how to [configure `op-challenger` on your OP Stack chain](/builders/chain-operators/tools/op-challenger). * For more info about how `op-challenger` works under the hood, [check out the specs](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html). diff --git a/pages/stack/protocol/fault-proofs/explainer.mdx b/pages/stack/fault-proofs/explainer.mdx similarity index 86% rename from pages/stack/protocol/fault-proofs/explainer.mdx rename to pages/stack/fault-proofs/explainer.mdx index 7b1299aa4..b22ce591a 100644 --- a/pages/stack/protocol/fault-proofs/explainer.mdx +++ b/pages/stack/fault-proofs/explainer.mdx @@ -1,13 +1,13 @@ --- -title: Fault Proofs Explainer +title: Fault proofs explainer lang: en-US -description: Learn about the OP Stack's fault proof system. +description: Learn about the OP Stack's Fault Proof System. --- import { Callout } from 'nextra/components' import Image from 'next/image' -# Fault Proofs Explainer +# Fault proofs explainer Fault Proofs are an important part of an Optimistic Rollup system like the OP Stack. Users withdraw ETH and tokens from OP Stack chains like OP Mainnet by submitting a withdrawal proof that shows the withdrawal was actually included in the OP Stack chain. @@ -25,7 +25,7 @@ Although the fault proof game is permissionless, the Optimism Security Council a Each proposal must wait for a delay period during which the Guardian can prevent invalid proposals from being used to withdraw ETH or tokens through a number of safety hatches. The Guardian can also choose to shift the system to use a PermissionedDisputeGame, in which only specific `PROPOSER` and `CHALLENGER` roles can submit and challenge proposals. -## Permissionless Proposals +## Permissionless proposals "Proposals" or "State Proposals" are claims about the state of an OP Stack chain that are submitted to Ethereum through the `DisputeGameFactory` contract. Proposals can be used for many things but are most commonly used by end-users to prove that they created a withdrawal on an OP Stack chain. @@ -36,28 +36,28 @@ See the permissionless fault proofs diagram below for more details:
Permissionless Fault Proofs flow -## Permissionless Challenges +## Permissionless challenges Because anyone can submit a proposal, it's important that invalid proposals can be challenged. -In [Optimistic Rollups like OP Stack Chains](/stack/protocol/rollup/overview) there is a \~1 week challenge period during which users can challenge a proposal if they believe it to be incorrect. +In [Optimistic Rollups like OP Stack Chains](/stack/rollup/overview) there is a \~1 week challenge period during which users can challenge a proposal if they believe it to be incorrect. With the Fault Proofs upgrade to the OP Stack, challenges become permissionless and can be submitted by anyone. Any user can run a node for the OP Stack chain in question and use the `op-challenger` tool to participate in the dispute process. -## Modular Design and Multi-layer Security +## Modular design and multi-layer security -The OP Stack Fault Proof system is [modular in design](/stack/protocol/fault-proofs/fp-components#system-design--modularity) and lays the groundwork for achieving a "multi-proof" system. This allows the OP Stack to support multiple proof systems alongside the initial [Cannon](/stack/protocol/fault-proofs/cannon) proof system. +The OP Stack Fault Proof System is [modular in design](/stack/fault-proofs/fp-components#system-design--modularity) and lays the groundwork for achieving a "multi-proof" system. This allows the OP Stack to support multiple proof systems alongside the initial [Cannon](/stack/fault-proofs/cannon) proof system. With multiple proof systems in place, the OP Stack can be more resilient to potential attacks and bugs in any one proof system. -Additionally, the following [security safeguards](/stack/protocol/fault-proofs/fp-security) have been built around the game, as follows: +Additionally, the following [security safeguards](/stack/fault-proofs/fp-security) have been built around the game, as follows: * An off chain monitoring system has been set up to monitor all proposed roots and ensure they align with the correct state. See [`op-dispute-mon`](https://github.com/ethereum-optimism/optimism/blob/develop/op-dispute-mon/README.md?plain=1) for more details. * After a root is finalized through a game, an additional delay called the "airgap window" has been added before withdrawals can occur. During this period, the `GUARDIAN` role can reject the root. * A contract called `DelayedWETH` has been set up to hold the bonds and only allow payouts after a delay, so that bonds can be redirected towards the correct recipient in the case that a game resolves incorrectly. -## Next Steps +## Next steps * Ready to get started? Review the [FP Components](fp-components) to learn how the different components work together to enhance decentralization in the Optimism ecosystem. -* See the [Fault Proof Mainnet Security](/stack/protocol/fault-proofs/fp-security) to understand changes to `OptimismPortal` and `FaultDisputeGame` contracts. +* See the [Fault Proof Mainnet Security](/stack/fault-proofs/fp-security) to understand changes to `OptimismPortal` and `FaultDisputeGame` contracts. * For more info about how the FP system works under the hood, [check out the specs](https://specs.optimism.io/fault-proof/index.html). ## FAQs @@ -78,7 +78,7 @@ It's not expected that normal users run `op-proposer` to regularly propose outpu Users would generally just propose a single output root if they need to withdraw and the chain operator isn't proposing outputs for them via direct calls to the `DisputeGameFactory` via Etherscan or using the [`create-game`](https://github.com/ethereum-optimism/optimism/tree/develop/op-challenger#create-game) subcommand of `op-challenger`. Documentation for `op-challenger` is forthcoming. -### How much ETH should a chain operator put aside to operate the fault proof system? +### How much ETH should a chain operator put aside to operate the Fault Proof System? The nominal operating cost of running FPs (i.e., assuming no invalid proposals or malicious actors) will depend on the initial bond set for the `FaultDisputeGame` and the frequency of posting proposals. Assuming OP Mainnet parameters, where proposals will be posted hourly, that's 0.08 ETH per hour. diff --git a/pages/stack/protocol/fault-proofs/fp-components.mdx b/pages/stack/fault-proofs/fp-components.mdx similarity index 95% rename from pages/stack/protocol/fault-proofs/fp-components.mdx rename to pages/stack/fault-proofs/fp-components.mdx index 1027cb406..d3132d21e 100644 --- a/pages/stack/protocol/fault-proofs/fp-components.mdx +++ b/pages/stack/fault-proofs/fp-components.mdx @@ -1,25 +1,25 @@ --- -title: FP System Components +title: FP System components lang: en-US -description: Learn about fault proof system components and how they work together to enhance decentralization in the Optimism ecosystem. +description: Learn about Fault Proof System components and how they work together to enhance decentralization in the Optimism ecosystem. --- import Image from 'next/image' import { Callout } from 'nextra/components' -# FP System Components +# FP system components This page explains the fault proof system components and how they work together to enhance decentralization in the Optimism ecosystem. The Fault Proof System is comprised of three main components: a Fault Proof Program (FPP), a Fault Proof Virtual Machine (FPVM), and a dispute game protocol. The system is designed to eventually enable secure bridging without central fallback. -The modular design of the fault proof system lays the foundation for a multi-proof future, inclusive of ZK proofs, and significantly increases the opportunities for ecosystem contributors to build alternative fault proof components to secure the system. +The modular design of the Fault Proof System lays the foundation for a multi-proof future, inclusive of ZK proofs, and significantly increases the opportunities for ecosystem contributors to build alternative fault proof components to secure the system. Visit the [Immunefi bug bounty page](https://immunefi.com/bounty/optimism/) for details on testing and helping to build a robust fault proof system. -## System Design & Modularity +## System design & modularity The Fault Proof System is comprised of three main components: a Fault Proof Program (FPP), a Fault Proof Virtual Machine (FPVM), and a dispute game protocol. These components will work together to challenge malicious or faulty activity on the network to preserve trust and consistency within the system. @@ -30,10 +30,10 @@ See the video below for a full technical walkthrough of the OP Stack's first fau The OP Stack's unique, modular design allows the decoupling of the FPP and FPVM, resulting in the following: * development of multiple proof systems, unique dispute games, and a variety of FPVMs in the future. -* custom-built fault proof systems comprised of any combination of these isolated componentsβ€”including validity proofs, attestation proofs, or ZKVM. +* custom-built Fault Proof Systems comprised of any combination of these isolated componentsβ€”including validity proofs, attestation proofs, or ZKVM. * dispute games in the dispute protocol backed by multiple security mechanisms. -## Fault Proof Program +## Fault proof program The default for this system component is `op-program`, which implements a fault proof program that runs through the rollup state-transition to verify an L2 output from L1 inputs. This verifiable output can then resolve a disputed output on L1. The FPP is a combination of `op-node` and `op-geth`, so it has both the consensus and execution "parts" of the protocol in a single process. This means Engine API calls that would normally be made over HTTP are instead made as direct method calls to the op-geth code. @@ -42,7 +42,7 @@ The FPP is designed so that it can be run in a deterministic way such that two i All data is retrieved via the [Preimage Oracle API](https://specs.optimism.io/experimental/fault-proof/index.html#pre-image-oracle). The preimages could be provided via the FPVM when onchain or by a native "host" implementation that can download the required data from nodes via JSON-RPC requests. The native host implementation is also provided by `op-program` but doesn't run as part of the onchain execution. Basically, `op-program` has two halves: the "client" Fault Proof Program part covered in this section and the "host" part used to fetch required preimages. -## Fault Proof Virtual Machine +## Fault proof virtual machine The Fault Proof Virtual Machine (FPVM) is one of the modules in the OP Stack's fault proof system. OP Stack's modularity decouples the Fault Proof Program (FPP) from the Fault Proof Virtual Machine (FPVM) to enable next-level composability and efficient parallelized upgrades to both components. The FPP (client-side) that runs within the FPVM is the part that expresses the L2 state-transition, and the interface between FPVM and FPP is standardized and documented in the [specs](https://github.com/ethereum-optimism/optimism/blob/546fb2c7a5796b7fe50b0b7edc7666d3bd281d6f/specs/cannon-fault-proof-vm.md). @@ -57,7 +57,7 @@ To do this, only one instruction is proven at a time. The bisection game will na [Cannon](cannon) is the default FPVM used in all disputes. [MIPS](mips) is the onchain smart contract implementation of Cannon that can be implemented due to the modularity of the dispute game. -## Dispute Game Protocol +## Dispute game protocol In the Dispute protocol, different types of dispute games can be created, managed, and upgraded through the [DisputeGameFactory](https://github.com/ethereum-optimism/optimism/blob/6a53c7a3294edf140d552962f81c0f742bf445f9/packages/contracts-bedrock/src/dispute/DisputeGameFactory.sol#L4). This opens the door to innovative features, like aggregate proof systems and the ability to expand the protocol to allow for disputing things apart from the state of L2, such as a `FaultDisputeGame` geared towards onchain binary verification. @@ -75,7 +75,7 @@ The VM's state transition function, which we'll call `T`, can be anything, so lo The first full implementation of the VM generic in the bisection game includes a single MIPS thread context on top of the EVM to execute a single instruction within an execution trace generated by `Cannon` and the `op-program`. -## Next Steps +## Next steps * For more detail on Cannon and its default operation as part of Optimism's Fault Proof Virtual Machine, see [Cannon FPVM](cannon). * For a detailed walk-thru of significant changes to Fault Proof Mainnet, see [FP Mainnet Security](fp-security). diff --git a/pages/stack/protocol/fault-proofs/fp-security.mdx b/pages/stack/fault-proofs/fp-security.mdx similarity index 92% rename from pages/stack/protocol/fault-proofs/fp-security.mdx rename to pages/stack/fault-proofs/fp-security.mdx index fa7c696ee..6f070fb06 100644 --- a/pages/stack/protocol/fault-proofs/fp-security.mdx +++ b/pages/stack/fault-proofs/fp-security.mdx @@ -1,12 +1,12 @@ --- -title: Fault Proofs Mainnet Security +title: Fault proofs Mainnet security lang: en-US description: Learn about changes to the security model for the Fault Proofs Mainnet System. --- import { Callout } from 'nextra/components' -# Fault Proofs Mainnet Security +# Fault proofs Mainnet security Source code for Fault Proof Mainnet contracts approved by Optimism Governance can be found [here](https://github.com/ethereum-optimism/optimism/tree/op-contracts/v1.5.0). @@ -17,12 +17,12 @@ The most significant change introduced by the Fault Proof Mainnet upgrade is the * The `DisputeGameFactory` contract generates `FaultDisputeGame` contract instances that each act as a host to a proposal about the state of the OP Stack chain at a given block number. * Unlike the `L2OutputOracle`, the `DisputeGameFactory` contract offers users the ability to permissionlessly play "fault dispute games" in which the correctness of the proposal is determined programmatically. -## Security Model +## Security model Fault Proof Mainnet is a large contract upgrade that introduces a number of novel components. Given the relative complexity of these novel components, the approach to security for FPM has been to limit the blast radius of potential bugs to very specific contracts and fallback mechanisms that can be easily audited. -### Handling Invalid Game Results +### Handling invalid game results All of the security mechanisms put in place generally revolve around the possibility that a `FaultDisputeGame` contract may incorrectly finalize an invalid game result. There are two variations of this: @@ -32,7 +32,7 @@ There are two variations of this: Both cases would cause honest challengers to lose bonds (unless the `Guardian` stepped in). Potential impact is managed through the introduction of a number of safeguards within the `OptimismPortal` and `FaultDisputeGame` contracts. -### Safeguards Within `OptimismPortal` +### Safeguards within `OptimismPortal` The `OptimismPortal` contract includes various security mechanisms that allow the `Guardian` and `SystemOwner` roles to collaborate to prevent invalid proposals from impacting withdrawals. @@ -41,23 +41,23 @@ The `OptimismPortal` contract includes various security mechanisms that allow th * The `Guardian` can "blacklist" specific `FaultDisputeGame` contracts that resolve incorrectly. * The `Guardian` can change the respected type of `FaultDisputeGame` contract in the case that an entire class of `FaultDisputeGame` contracts is found to have critical bugs. If desired, the `Guardian` can also choose to revert to a `PermissionedDisputeGame` contract that only allows specific roles to submit and challenge proposals. -### Safeguards Within `FaultDisputeGame` +### Safeguards within `FaultDisputeGame` The `FaultDisputeGame` contracts store bonds within a `DelayedWETH` contract that is managed by the `SystemOwner`. Withdrawals from the `DelayedWETH` contract are delayed which gives the `SystemOwner` the ability to manually recover from situations in which bonds would be incorrectly distributed. This delay is set to 7 days on OP Mainnet to give the `SystemOwner` or `Guardian` sufficient time to respond to potential security concerns. -### Safeguards Within `DelayedWETH` +### Safeguards within `DelayedWETH` * The `SystemOwner` can replace the `Guardian` address. * The `SystemOwner` can hold funds from any specific `DisputeGame` contract. * The `SystemOwner` can remove funds from the `DelayedWETH` contract if the issue extends to so many `DisputeGame` contracts that holding funds from specific contracts is not viable. * The `Guardian` can trigger the global pause mechanism to halt WETH withdrawals. -### Cumulative Security Impact +### Cumulative security impact As with the original system, the cumulative effect of these security capabilities is that the `Guardian` role provides fast response capabilities while the `SystemOwner` can always step in to resolve all classes of bugs that could result in a loss of funds. -The most significant change in security model with the introduction of Fault Proof Mainnet is that `SystemOwner` can take a more passive role as invalid proposals will generally be rejected by the Fault Proof system while the `Guardian` can act as a backstop only in case of a failure in the fault proof game. +The most significant change in security model with the introduction of Fault Proof Mainnet is that `SystemOwner` can take a more passive role as invalid proposals will generally be rejected by the Fault Proof System while the `Guardian` can act as a backstop only in case of a failure in the fault proof game. -## Next Steps +## Next steps * See the [FP Components](fp-components) for an overview of FP system components and how they work together to enhance decentralization in the Optimism ecosystem. * See the [specs](https://specs.optimism.io/fault-proof/index.html) for detailed information about the entire FP program, FP virtual machine, and dispute game. diff --git a/pages/stack/protocol/fault-proofs/mips.mdx b/pages/stack/fault-proofs/mips.mdx similarity index 99% rename from pages/stack/protocol/fault-proofs/mips.mdx rename to pages/stack/fault-proofs/mips.mdx index e58cff53c..3623ae991 100644 --- a/pages/stack/protocol/fault-proofs/mips.mdx +++ b/pages/stack/fault-proofs/mips.mdx @@ -1,5 +1,5 @@ --- -title: Fault Proof VM - MIPS.sol +title: Fault proof VM - MIPS.sol lang: en-US description: Learn about the `MIPS.sol` smart contract that works as part of Optimism's Fault Proof Virtual Machine. --- @@ -7,14 +7,14 @@ description: Learn about the `MIPS.sol` smart contract that works as part of Opt import Image from 'next/image' import { Callout } from 'nextra/components' -# Fault Proof VM: MIPS.sol +# Fault proof VM: MIPS.sol The `MIPS.sol` smart contract is an onchain implementation of a virtual machine (VM) that encompasses the 32-bit, Big-Endian, MIPS III Instruction Set Architecture (ISA). This smart contract is the counterpart to the off-chain MIPSEVM golang implementation of the same ISA. Together, the onchain and off-chain VM implementations make up [Cannon](cannon), Optimism's Fault Proof Virtual Machine (FPVM). Cannon is a singular instance of a FPVM that can be used as part of the Dispute Game for Optimism's (and Base's) optimistic rollup L2 blockchain. The Dispute Game itself is modular, allowing for any FPVM to be used in a dispute; however, Cannon is currently the only FPVM implemented and thus will be used in all disputes. -## Control Flow +## Control flow The `FaultDisputeGame.sol` interacts with `MIPS.sol` and then `MIPS.sol` calls into `PreimageOracle.sol`. `MIPS.sol` is only called at the max depth of the game when someone needs to call `step`. `FaultDisputeGame.sol` is the deployed instance of a Fault Dispute Game for an active dispute, and `PreimageOracle.sol` stores Pre-images. @@ -27,7 +27,7 @@ A leaf node represents a single MIPS instruction (in the case that we're using C state to run in the `MIPS.sol` contract, the fault dispute game can determine the true post state (or Post-image). This true post state will then be used to determine the outcome of the fault dispute game by comparing the disputed post-state at the leaf node with the post-state proposed by the disputer. -## Contract State +## Contract state The `MIPS.sol` contract only contains a single immutable variable, which corresponds to the address of the `PreimageOracle.sol` contract. Otherwise, the contract is stateless, meaning that all state related to playing a MIPS instruction onchain comes from either the `FaultDisputeGame.sol` instance, or the `PreimageOracle.sol`. @@ -47,7 +47,7 @@ There is no requirement to read from the `PreimageOracle.sol` during instruction The Pre-image information that has been read in previous off-chain instructions leading up to the execution of a single instruction onchain may still reside in the constructed VM memory. Thus, even when the instruction run onchain does not explicitly read from `PreimageOracle.sol` , Pre-image data may still influence the merkle root that represents the VM's memory. -### Packed VM Execution State +### Packed VM execution state In order to execute a MIPS instruction onchain, the `MIPS.sol` contract needs to know important state information such as the instruction to run, the values in each of the general purpose registers, etc. More specifically, a tightly-packed `State` struct contains all the relevant information that the `MIPS.sol` contract needs to know. This struct is passed to the contract from the `FaultDisputeGame.sol` contract when it invokes the `step` function in `MIPS.sol` (which in-turn executes a single MIPS instruction onchain). @@ -66,7 +66,7 @@ The following information is stored in the `State` struct. See [doc reference](h 11. `step` - Counts the total number of instructions that have been executed. 12. `registers` - Array of 32, 32-bit values that represent the general purpose registers for the MIPS ISA. -### State Hash +### State hash The state hash is the `bytes32` value returned to the active Fault Dispute Game upon the completion of a single MIPS instruction in the `MIPS.sol` contract. The hash is derived by taking the `keccak256` of the above packed VM execution `State` struct, and then replacing the first byte of the hash with a value that represents the status of the VM. @@ -80,7 +80,7 @@ This value is derived from the `exitCode` and `exited` values, and can be: The reason for adding the VM status to the state hash is to communicate to the dispute game whether the VM determined the proposed output root was valid or not. This in turn prevents a user from disputing an output root during a dispute game, but provides the state hash from a cannon trace that actually proves the output root is valid. -### Memory Proofs +### Memory proofs Using a 32-bit ISA means that the total size of the address space (assuming no virtual address space) is `2^32 = 4GiB`. Additionally, the `MIPS.sol` contract is stateless, so it does not store the MIPS memory in contract storage. The primary reason for this is because having to load the entire memory into the `MIPS.sol` contract in order to execute a single instruction onchain is prohibitively expensive. Additionally, the entire memory would need to be loaded per fault proof game, requiring multiple instances of the `MIPS.sol` contract. Therefore, in order to optimize the amount of data that needs to be provided per onchain instruction execution while still maintaining integrity over the entire 32-bit address space, Optimism has converted the memory into a binary merkle tree. @@ -88,7 +88,7 @@ The binary merkle tree (or hash tree) used to store the memory of the MIPS VM ha Reading to memory and writing to memory work similarly, both involve calculating the merkle root. In the case of a memory write, `MIPS.sol` must take care to verify the provided proof for the memory location to write to is correct. Additionally, writing to memory will change the merkle root stored in the VM execution `State` struct. -### State Calculation +### State calculation While the `MIPS.sol` contract may only execute a single instruction onchain, the off-chain Cannon implementation executes all prerequisite MIPS instructions for all state transitions in the disputed L2 state required to reach the disputed instruction that will be executed onchain. This ensures that the MIPS instruction executed onchain has the correct VM state and necessary Pre-images stored in the `PreimageOracle.sol` contract to generate the true post-state that can be used to resolve the dispute game. @@ -177,7 +177,7 @@ The public [`step`](https://github.com/ethereum-optimism/optimism/blob/546fb2c7a The internal pure [`execute`](https://github.com/ethereum-optimism/optimism/blob/546fb2c7a5796b7fe50b0b7edc7666d3bd281d6f/packages/contracts-bedrock/src/cannon/MIPS.sol#L793) function handles the execution of MIPS instructions that are not handled by other functions. The `execute` function primarily handles R-type instructions according to the MIPS specification, however other instructions will pass through this function. Instructions handled by other functions will simply return. Invalid or unsupported instructions will cause the `execute` function to revert. -## Common Bitwise Operation Use Cases +## Common bitwise operation use cases 1. Isolating certain bits from a number can be done using the & operator (and(x,y) in Yul), this is also known as generating a bitmask. 2. Combining bits from two numbers together can be done using the | operator (or(x, y) in Yul). @@ -185,7 +185,7 @@ The internal pure [`execute`](https://github.com/ethereum-optimism/optimism/blob 4. Multiplication using a value with a base of 2 can be expressed using the following bitwise operation: `x * y = x << z, where y = 2^z` Ex. `x * 8 = x << 3, where 8 = 2^3` -## Table Of Supported MIPS Instructions +## Table of supported MIPS instructions | Instruction Name | Opcode Num. | Funct Num. | Other Num. | | ---------------------------------------------- | ----------- | ---------- | ---------- | @@ -253,7 +253,7 @@ The internal pure [`execute`](https://github.com/ethereum-optimism/optimism/blob | SC (Store Conditional Word) | 0x38 | - | - | | SYNC (Synchronize Shared Memory) | 0x00 | 0x0F | - | -## Further Reading +## Further reading * [Cannon Overview](https://github.com/ethereum-optimism/optimism/blob/546fb2c7a5796b7fe50b0b7edc7666d3bd281d6f/cannon/docs/README.md) * [Cannon FPVM Specification](https://specs.optimism.io/experimental/fault-proof/cannon-fault-proof-vm.html) diff --git a/pages/stack/features.mdx b/pages/stack/features.mdx new file mode 100644 index 000000000..84cad55a4 --- /dev/null +++ b/pages/stack/features.mdx @@ -0,0 +1,15 @@ +--- +title: Features +description: Documentation covering Send Raw Transaction Conditional in the Features section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Features + +Documentation covering Send Raw Transaction Conditional in the Features section of the OP Stack ecosystem. + + + + diff --git a/pages/stack/features/_meta.json b/pages/stack/features/_meta.json new file mode 100644 index 000000000..1d8a795f7 --- /dev/null +++ b/pages/stack/features/_meta.json @@ -0,0 +1,3 @@ +{ + "send-raw-transaction-conditional": "SendRawTransactionConditional" +} diff --git a/pages/stack/features/send-raw-transaction-conditional.mdx b/pages/stack/features/send-raw-transaction-conditional.mdx new file mode 100644 index 000000000..75cb7e8c5 --- /dev/null +++ b/pages/stack/features/send-raw-transaction-conditional.mdx @@ -0,0 +1,63 @@ +--- +title: SendRawTransactionConditional explainer +lang: en-US +description: Learn about the eth_sendRawTransactionConditional RPC method for conditional transaction inclusion on the OP Stack. +--- + +import { Callout } from 'nextra/components' + +# SendRawTransactionConditional explainer + +A sequencer rpc, `eth_sendRawTransactionConditional`, allowing callers to conditionally include a transaction based on a set of provided options. + +This feature is meant to unblock use cases that require atomic inclusion, otherwise possible on Ethereum through specialized block builders like Flashbots. Some examples: + +* 4337 Bundlers utilizing a shared mempool of UserOperations. Reverted transactions due to conflicting UserOperations would make it too costly for bundlers to operate on L2, forcing the use of private mempools. + +## Specification + +This endpoint is an extension of `eth_sendRawTransaction`, with an extra parameter of "options" with the following structure: + +``` +{ + "knownAccounts": [optional] A map of accounts with expected storage. The key is account address + If the value is hex string, it is the known storage root hash of that account. + If the value is an object, then each member is in the format of "slot": "value", which are explicit slot values within that account storage. + "blockNumberMin": [optional] minimal block number for inclusion + "blockNumberMax": [optional] maximum block number for inclusion + "timestampMin": [optional] minimum block timestamp for inclusion + "timestampMax": [optional] maximum block timestamp for inclusion +} +``` + +The "cost" of a given conditional is *approximately* determined by the number of storage lookups that would be incurred by validating this conditional. There's a predefined max of `1000` that is allowed to prevent DoS. + + + Since the sequencer is not compensated for the additional state checks, otherwise through the GAS of the transaction, a configured rate limit is applied to this cost. + + To also disincentive the use of this endpoint for MEV in comparison to `eth_sendRawTransaction`, the conditional is checked against the parent of the latest block. + + +This conditional is checked once at the RPC layer prior to mempool submission. If rejected against chain state, the RPC will return an error with the following spec + +* error code `-32003` (transaction rejected) with a reason string as to the specific failed check +* error code `-32005` (conditional cost) with a reason string if the conditional cost exceeded the maximum OR the cost was rate limited due to network conditions. + +Successful submission does **NOT** guarantee inclusion! The caller must observe the chain for a receipt with some timeout to determine non-inclusion. The conditional is also re-checked in the block building phase to handle intra-block conflicts. + + + Conditional transactions are tied to the block builder they are submitted to. This means that these transactions **are not gossiped between configured peers!!!** + + If you are running an active/passive setup with replicas that gossip txs to an active sequencer, this endpoint should be fronted by a proxy that can broadcast the request to all replicas. + + +## How to enable + +This feature can be enabled with the addition of a flag to op-geth. + +* `--rollup.sequencertxconditionalenabled` (default: false) a boolean flag which enables the rpc. +* `--rollup.sequencertxconditionalcostratelimit` (default: 5000) an integer flag that sets the rate limit for cost observable per second. + + + It is not advised to publicly expose this sequencer endpoint due to DoS concerns. This supplemental proxy, [op-txproxy](/builders/chain-operators/tools/op-txproxy), should be used to apply additional constraints on this endpoint prior to passing through to the sequencer. + diff --git a/pages/stack/getting-started.mdx b/pages/stack/getting-started.mdx index 554a247c7..a3f5a13a2 100644 --- a/pages/stack/getting-started.mdx +++ b/pages/stack/getting-started.mdx @@ -1,12 +1,12 @@ --- -title: Getting Started with the OP Stack +title: Getting started with the OP Stack lang: en-US description: Learn the basics of OP Stack development. --- import { Callout } from 'nextra/components' -# Getting Started with the OP Stack +# Getting started with the OP Stack **The OP Stack is the standardized, shared, and open-source development stack that powers Optimism, maintained by the Optimism Collective.** @@ -16,7 +16,7 @@ import { Callout } from 'nextra/components' The OP Stack consists of the many different software components managed and maintained by the Optimism Collective that, together, form the backbone of Optimism. The OP Stack is built as a public good for the Ethereum and Optimism ecosystems. -To understand how to operate an OP Stack chain, including roll-up and chain deployment basics, visit [Chain Operator guide](/builders/chain-operators/self-hosted). Check out these guides to get an overview of everything you need to know to properly support OP mainnet within your [exchange](/builders/cex-wallet-developers/cex-support) and [wallet](/builders/cex-wallet-developers/wallet-support). +To understand how to operate an OP Stack chain, including roll-up and chain deployment basics, visit [Chain Operator guide](/builders/chain-operators/self-hosted). Check out these guides to get an overview of everything you need to know to properly support OP mainnet within your [exchange](/builders/app-developers/overview) and [wallet](/builders/app-developers/overview). ## The OP Stack powers Optimism @@ -61,7 +61,7 @@ As work on the stack continues, it should become easier to plug in and configure As the [Superchain](explainer) begins to take shape, the OP Stack can evolve alongside it, to include the message-passing infrastructure that allows different chains to interoperate seamlessly. At the end of the day, the OP Stack becomes what Optimism needs. -## Dive Deeper into the OP Stack +## Dive deeper into the OP Stack Ready to dive into the world of the OP Stack? diff --git a/pages/stack/interop.mdx b/pages/stack/interop.mdx new file mode 100644 index 000000000..466533c36 --- /dev/null +++ b/pages/stack/interop.mdx @@ -0,0 +1,27 @@ +--- +title: Interop +description: Documentation covering Cross Chain Message, Explainer, Message Passing, Op Supervisor, Superchain Erc20, Superchain Weth, Supersim, Transfer Superchainerc20 in the Interop section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Interop + +Documentation covering Cross Chain Message, Explainer, Message Passing, Op Supervisor, Superchain Erc20, Superchain Weth, Supersim, Transfer Superchainerc20 in the Interop section of the OP Stack ecosystem. + + + + + + + + + + + + + + + + diff --git a/pages/stack/interop/_meta.json b/pages/stack/interop/_meta.json new file mode 100644 index 000000000..ac5d2f1f3 --- /dev/null +++ b/pages/stack/interop/_meta.json @@ -0,0 +1,9 @@ +{ + "explainer": "Interop explainer", + "devnet": "Interop devnet", + "supersim": "Supersim Multichain Development Environment", + "cross-chain-message": "Anatomy of cross-chain message", + "message-passing": "Interop message passing", + "op-supervisor": "OP Supervisor", + "assets": "Assets" +} \ No newline at end of file diff --git a/pages/stack/interop/assets.mdx b/pages/stack/interop/assets.mdx new file mode 100644 index 000000000..4d287b5f9 --- /dev/null +++ b/pages/stack/interop/assets.mdx @@ -0,0 +1,23 @@ +--- +title: Assets +description: Documentation covering Cross Chain Message, Explainer, Message Passing, Op Supervisor, Superchain Erc20, Superchain Weth, Supersim, Transfer Superchainerc20 in the Interop section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Interop + +Documentation covering SuperchainERC20, Superchain WETH, Supersim, and how to transfer a SuperchainERC20. + + + + + + + + + + + + diff --git a/pages/stack/interop/assets/_meta.json b/pages/stack/interop/assets/_meta.json new file mode 100644 index 000000000..1db8c901e --- /dev/null +++ b/pages/stack/interop/assets/_meta.json @@ -0,0 +1,7 @@ +{ + "superchain-erc20": "SuperchainERC20", + "transfer-superchainERC20": "How to transfer a SuperchainERC20", + "deploy-superchain-erc20": "Deploy assets using SuperchainERC20", + "superchainerc20-best-practices": "SuperchainERC20 best practices", + "superchain-weth": "SuperchainWETH (Interoperable ETH)" +} \ No newline at end of file diff --git a/pages/stack/interop/assets/deploy-superchain-erc20.mdx b/pages/stack/interop/assets/deploy-superchain-erc20.mdx new file mode 100644 index 000000000..19b1917aa --- /dev/null +++ b/pages/stack/interop/assets/deploy-superchain-erc20.mdx @@ -0,0 +1,49 @@ +--- +title: Deploy assets using SuperchainERC20 +lang: en-US +description: Learn about the basic details of deploying assets on SuperchainERC20 +--- + +import { Callout } from 'nextra/components' +import { Steps } from 'nextra/components' + +# Issuing new assets with SuperchainERC20 + + + Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. + + +This guide explains how to issue new assets with the `SuperchainERC20` and bridge them effectively using the `SuperchainERC20Bridge`. If you want more information about the `SuperchainERC20 standard`, see our [`SuperchainERC20` standard explainer](/stack/interop/assets/superchain-erc20) + +Note that bridging assets through the Superchain using `SuperchainERC20` never affects the total supply of your asset. The supply remains fixed, and bridging only changes the chain on which your asset is located. This keeps the token's total amount the same across all networks, ensuring its value stays stable during the move and that the `SuperchainERC20` retains a unified, global supply count. + +## Steps to issue and bridge assets + + + ### Deploy the `SuperchainERC20` Token Contract + + To ensure fungibility across chains, the SuperchainERC20 assets need to have the same contract address on all chains. Achieving this requires deterministic deployment methods, such as: + + * `Create2Deployer`: A smart contract that enables deploying contracts with predictable addresses. + * `OptimismSuperchainERC20Factory`: A factory contract designed for L1-native tokens to ensure uniform deployments across chains. + + There are [many ways to do this](https://github.com/Arachnid/deterministic-deployment-proxy), but [here's an example smart contract to start](https://github.com/ethereum-optimism/superchainerc20-starter/blob/main/packages/contracts/src/L2NativeSuperchainERC20.sol). For an in-depth guide on how to deploy a `SuperchainERC20` use the [SuperchainERC20 Starter Kit](https://console.optimism.io/build). + + By deploying assets at identical addresses across multiple chains, we abstract away the complexity of cross-chain validation. + + ### Implement the IERC7802 interface + + Implementations of `SuperchainERC20` will be required to implement the [IERC7802](https://specs.optimism.io/interop/token-bridging.html#ierc7802) interface, that includes two external functions and two events. + + The interface defines two functions for bridging: + + * `sendERC20`: Initializes a cross-chain transfer of a `SuperchainERC20` by burning the tokens locally and sending a message to the `SuperchainERC20Bridge` on the target chain using the `L2toL2CrossDomainMessenger`. This ensures that asset supply remains constant, as sending an asset moves it from one chain to another without creating additional supply. + * `relayERC20`: Processes incoming messages from the L2toL2CrossDomainMessenger and mints the corresponding amount of the SuperchainERC20. + + [Here's an example implementation of the `SuperchainERC20Bridge`](https://specs.optimism.io/interop/token-bridging.html#implementation) + + +## Next steps +* Use the [SuperchainERC20 Starter Kit](https://console.optimism.io/build) to deploy your token across the Superchain +* Explore the [SuperchainERC20 specifications](https://specs.optimism.io/interop/token-bridging.html) for in-depth implementation details. +* Review the [Superchain Interop Explainer](explainer) for answers to common questions about interoperability. diff --git a/pages/stack/interop/assets/superchain-erc20.mdx b/pages/stack/interop/assets/superchain-erc20.mdx new file mode 100644 index 000000000..0fb654df9 --- /dev/null +++ b/pages/stack/interop/assets/superchain-erc20.mdx @@ -0,0 +1,95 @@ +--- +title: SuperchainERC20 +lang: en-US +description: Learn about the basic details of the SuperchainERC20 implementation. +--- + +import { Callout } from 'nextra/components' + +# SuperchainERC20 + + + Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. + + +`SuperchainERC20` is an implementation of [ERC-7802](https://ethereum-magicians.org/t/erc-7802-crosschain-token-interface/21508) designed to enable asset interoperability in the Superchain. +Asset interoperability allows for tokens to securely move across chains without asset wrapping or liquidity pools for maximal capital efficiency, thus unifying liquidity and simplifying the user experience. + +Additional features: + +* **Simplified deployments**: 0-infrastructure cost to make your token cross-chain. Provides a consistent, unified implementation for tokens across all Superchain-compatible networks and a common cross-chain interface for the EVM ecosystem at large. +* **Permissionless propagation**: Easily clone an existing token contract to a new OP Stack chain using `create2` without requiring the original owner, which enables movement of assets to the new chain once Interop goes live. Importantly, permissionless propagation retains the integrity of the original owner on the contract and preserves security but proliferates the contract's availability to new chains. +* **Common standard**: Implements ERC-7802, a unified interface that can be used across all of Ethereum to enable cross-chain mint/burn functionality. + +## How it works + +`SuperchainERC20` facilitates secure token transfers between chains in the Superchain networks via native burning and minting. + +* **Token Burning**: Initiating message where token is **burned** on the source chain. A user initiates a transfer of token from one blockchain to another and specifies the recipient wallet address on the destination chain. A specified amount of token is burned on the source chain. +* **Token Minting**: Executing message where token is **minted** on the destination chain. The specified amount of token is minted on the destination chain directly to the recipient wallet address. + +An important thing to note is using `crosschainBurn` and `crosschainMint` on the `SuperchainERC20` to move your asset across the Superchain only affects which chain your asset is located on and does not change the overall supply of the token. This keeps the token's total amount the same across all networks, ensuring its value stays stable during the move and that the `SuperchainERC20` retains a unified, global supply count. + +```mermaid +sequenceDiagram + box rgba(255, 4, 32, 0.1) ChainA + participant User-chainA + participant SuperchainERC20-chainA + participant SuperchainERC20Bridge-chainA + end + box rgba(248, 61, 213, 0.1) ChainB + participant SuperchainERC20Bridge-chainB + participant SuperchainERC20-chainB + participant User-chainB + end + + + User-chainA->>SuperchainERC20-chainA: Initiate token transfer + SuperchainERC20-chainA->>SuperchainERC20Bridge-chainA: Bridge to chainB + SuperchainERC20Bridge-chainA->>SuperchainERC20-chainA: Burn tokens + SuperchainERC20Bridge-chainA-->>SuperchainERC20Bridge-chainA: Emit cross-chain event + SuperchainERC20Bridge-chainB-->>SuperchainERC20Bridge-chainB: Validates message + SuperchainERC20Bridge-chainB-->>SuperchainERC20-chainB: Mint tokens + SuperchainERC20-chainB->>User-chainB: User receives tokens +``` + +This diagram illustrates the process where tokens are burned on the source chain and minted on the destination chain, enabling seamless cross-chain transfers without the need for asset wrapping or liquidity pools. + +## Major components + +* **Token Contract**: implements `SuperchainERC20` with bridging functionality. +* **Factory Predeploy**: uses a `create2`-based factory for deploying `SuperchainERC20` tokens consistently across chains. +* **Bridging Functions**: using methods like `sendERC20` and `relayERC20` for cross-chain transfers. + +## Comparison to other token implementations + +`SuperchainERC20` differs from other token implementations in its focus and implementation: + +* `SuperchainERC20` implements ERC-7802, which provides a minimal crosschain mint/burn interface designed to be a common pattern for the EVM ecosystem. +* `SuperchainERC20` shares trust assumptions across all chains in the Superchain, such that custom assumptions around security and latency are not required to account for when executing transfers. + + + Projects moving from other token implementations may need to adapt to the `SuperchainERC20` specification. + + +## Implementation details + +Application developers must do two things to make their tokens `SuperchainERC20` compatible. Doing this setup now ensures that tokens can benefit from Interop once the Interop upgrade happens. + +1. Permission only `SuperchainERC20Bridge` to call `crosschainMint` and `crosschainBurn`. +2. Deployment at same address on every chain in the Superchain using `create2` function. + +For now, application developers should view `SuperchainERC20`as ERC20 tokens with additional built-in functions that allow cross-chain asset movement that will be enabled once Interop goes live. + +For step-by-step information on implementing SuperchainERC20, see [Deploy assets using SuperchainERC20](/stack/interop/assets/deploy-superchain-erc20) + + + To enable asset interoperability, `SuperchainERC20` must give access to the address where the future `SuperchainERC20Bridge` will live. + + +## Next steps + +* Explore the [SuperchainERC20 specifications](https://specs.optimism.io/interop/token-bridging.html) for in-depth implementation details. +* Check out the [Superchain ERC20 starter kit](https://github.com/ethereum-optimism/superchainerc20-starter) to get started with implementation. +* Watch the [Superchain interop design video walkthrough](https://www.youtube.com/watch?v=FKc5RgjtGes) for a visual explanation of the concepts. +* Review the [Superchain Interop Explainer](explainer) for answers to common questions about interoperability. diff --git a/pages/stack/interop/assets/superchain-weth.mdx b/pages/stack/interop/assets/superchain-weth.mdx new file mode 100644 index 000000000..3799681ba --- /dev/null +++ b/pages/stack/interop/assets/superchain-weth.mdx @@ -0,0 +1,86 @@ +--- +title: SuperchainWETH (Interoperable ETH) +lang: en-US +description: Learn basic details about SuperchainWETH or Interoperable ETH. +--- + +import { Callout } from 'nextra/components' + +# SuperchainWETH (Interoperable ETH) + + + Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. + + +Superchain WETH or Interoperable ETH is a specialized version of the standard WETH (Wrapped Ether) contract designed to enable seamless movement of ETH across the Superchain. It addresses the liquidity constraints and usability issues that arise when transferring ETH between different chains. + +## Features and benefits + +* Enables seamless ETH transfers across different chains in the Superchain +* Maintains fungibility of ETH across the Superchain +* Provides liquidity for cross-chain transactions +* Improves user experience by abstracting complex bridging processes + + + The `SuperchainTokenBridge` can only rebalance assets across chains. It cannot mint or increase/decrease the total circulating supply. + + +## How it works + +Currently, L2-to-L2 ETH transfers between two interoperable chains require four separate transactions: + +1. Wrap `ETH` to `SuperchainWETH`. +2. Call `SuperchainTokenBridge#SendERC20` to burn `SuperchainWETH` on source chain and relay a message to the destination chain that mints `SuperchainWETH` to the recipient (`crosschainBurn` is used). +3. Execute the message on the destination chain, triggering `SuperchainTokenBridge#RelayERC20` to mint `SuperchainWETH` to the recipient (`crosschainMint` is used). If the destination is a non-custom gas token chain, ETH is sourced from the `ETHLiquidity` contract. +4. Unwrap the received `SuperchainWETH` to `ETH`. + + +Abstraction is a possible future consideration to reduce this process to two transactions, which can be followed in the [design docs](https://github.com/ethereum-optimism/design-docs/pull/146/files). + + +```mermaid +sequenceDiagram + participant User + participant Source Chain + participant Cross-Chain Messenger + participant Destination Chain + + User->>Source Chain: 1. Wrap ETH to SuperchainWETH + Source Chain->>Cross-Chain Messenger: 2. Burn SuperchainWETH and relay message + Cross-Chain Messenger->>Destination Chain: 3. Mint SuperchainWETH to recipient + User->>Destination Chain: 4. Unwrap SuperchainWETH to ETH +``` +_Figure 1: Superchain WETH transfer process between two interoperable L2 chains._ + + + `crosschainBurn` and `crosschainMint`can only be called by the `SuperchainTokenBridge`. + + +## Major components + +### `SuperchainWETH` contract + +This contract implements the core functionality for wrapping, unwrapping, and cross-chain transfer of ETH. It integrates with the `SuperchainTokenBridge` for interoperable actions. + +* Contract address: `0x4200000000000000000000000000000000000024` + +### `ETHLiquidity` contract + +A predeploy contract with a large pool of ETH that provides liquidity for cross-chain transfers. It allows "burning" and "minting" of ETH for cross-chain transfers. ETH is associated with bridge ETH from the L1 lockbox, making ETH available to interop chains through a shared lockbox rather than fragmented amongst the existing portal contracts. + +* Contract address: `0x4200000000000000000000000000000000000025` + +### `L2ToL2CrossDomainMessenger` contract + +This predeploy contract facilitates general message passing between different chains in the Superchain. It also securely transfers ERC20 tokens between L2 chains. + +* Contract address: `0x4200000000000000000000000000000000000023` + + + `SuperchainWETH` implements strict access controls to ensure security (e.g., only `SuperchainWETH` can call `ETHLiquidity` functions). + + +## Next steps + +* Explore the [`SuperchainWETH`](https://specs.optimism.io/interop/superchain-weth.html) specs for in-depth implementation details. +* Review the [Superchain Interop Explainer](explainer) for answers to common questions about interoperability. diff --git a/pages/stack/interop/assets/superchainerc20-best-practices.mdx b/pages/stack/interop/assets/superchainerc20-best-practices.mdx new file mode 100644 index 000000000..a483ce43c --- /dev/null +++ b/pages/stack/interop/assets/superchainerc20-best-practices.mdx @@ -0,0 +1,31 @@ +--- +title: Best practices for managing SuperchainERC20 tokens +lang: en-US +description: Essential best practices for deploying and managing SuperchainERC20 assets across Superchain networks. +--- + +# Best practices for managing SuperchainERC20 tokens + +The following best practices are essential for deploying and managing `SuperchainERC20` assets across the Superchain. These guidelines help ensure optimal cross-chain functionality. + +Note that the total supply of your tokens never fluctuates across the Superchain. Cross-chain burning and minting only affects the location of a token across the Superchain. + +## Consistent addresses across chains + +Use predefined addresses: Assign and verify the same address for each `SuperchainERC20` instance on every chain. Predefined addresses reduce deployment conflicts and ensure tokens are accurately recognized across chains. Otherwise, the SuperchainERC20Bridge would need a way to verify if the tokens they mint on destination correspond to the tokens that were burned on source. + +Consider using `Create2Deployer` or one of our [predeploys](https://specs.optimism.io/interop/predeploys.html) to ensure this. + +## Testing before mainnet deployment + +Test with production-like conditions: Deploy to staging environments that simulate mainnet conditions, especially for functions like `crosschainBurn` and `crosschainMint`. Test under realistic transaction loads to validate performance. + +We recommend using [Supersim](https://supersim.pages.dev/introduction) as an easy way to simulate the Superchain and test your SuperchainERC20 deployment. + +Test edge cases such as maximum balance transfers and interchain latency to ensure asset reliability across different scenarios. + +## Next steps + +* Explore the [SuperchainERC20 specifications](https://specs.optimism.io/interop/token-bridging.html) for in-depth implementation details. +* Watch the [Superchain interop design video walkthrough](https://www.youtube.com/watch?v=FKc5RgjtGes) for a visual explanation of the concepts. +* Review the [Superchain Interop Explainer](explainer) for answers to common questions about interoperability. diff --git a/pages/stack/interop/assets/transfer-superchainERC20.mdx b/pages/stack/interop/assets/transfer-superchainERC20.mdx new file mode 100644 index 000000000..18e9fa29a --- /dev/null +++ b/pages/stack/interop/assets/transfer-superchainERC20.mdx @@ -0,0 +1,117 @@ +--- +title: How to transfer a SuperchainERC20 +lang: en-US +description: Learn how to transfer a SuperchainERC20 between chains using L2ToL2CrossDomainMessenger. +--- + +import { Callout, Steps } from 'nextra/components' + +# How to transfer a SuperchainERC20 + + + Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. + + +This guide provides an overview of transferring `SuperchainERC20` tokens between chains. + +## Overview + +Transferring SuperchainERC20 tokens between chains involves two main phases: + +1. **Source Chain Operations** + * Mint tokens if needed + * Initiate the transfer using the bridge +2. **Destination Chain Operations** + * Relay the transfer message + * Verify the transfer completion + + + Always verify your addresses and amounts before sending transactions. Cross-chain transfers cannot be reversed. + + +## How it works + +This diagram illustrates the process of a SuperchainERC20 token transfer between chains. +Through the `L2ToL2CrossDomainMessenger` contract, tokens are burned on the source chain and a transfer message is emitted. +This message must then be relayed to the destination chain, where an equivalent amount of tokens will be minted to the specified recipient address - ensuring secure cross-chain transfers while maintaining the total token supply across all chains. + +```mermaid +sequenceDiagram + actor User + participant SourceChain + participant Bridge as L2ToL2CrossDomainMessenger + participant DestChain + + Note over User,DestChain: Step 1: Prepare Tokens + User->>SourceChain: Check token balance + alt + User->>SourceChain: Mint or acquire tokens + end + + Note over User,DestChain: Step 2: Initiate Transfer + User->>SourceChain: Approve bridge contract + User->>Bridge: Call sendERC20 + Bridge->>SourceChain: Burn tokens + Bridge-->>Bridge: Emit transfer message + + Note over User,DestChain: Step 3: Complete Transfer + User->>Bridge: Get message details + User->>Bridge: Relay message on destination + Bridge->>DestChain: Mint tokens to recipient + + Note over User,DestChain: Step 4: Verify + User->>DestChain: Check token balance +``` + + + ### Step 1: Prepare your tokens + + Ensure you have tokens on the source chain using one of these methods: + + * Use existing tokens you already own + * Mint new tokens using the [SuperchainERC20](https://github.com/ethereum-optimism/supersim/blob/main/contracts/src/L2NativeSuperchainERC20.sol) contract if you have minting permissions + * Acquire tokens through a supported exchange or transfer + + ### Step 2: Initiate the transfer + + To start the transfer: + + 1. Choose the destination chain where you want to receive the tokens + 2. Specify the recipient address and the amount to transfer + 3. Call the bridge contract, which will: + * Lock or burn your tokens on the source chain + * Emit a message that will be used to mint tokens on the destination chain + + ### Step 3: Complete the transfer + + To finalize the transfer on the destination chain: + + 1. Get the message details from the source chain event + 2. Use the `L2ToL2CrossDomainMessenger` contract to relay the message + 3. The message relay will trigger the minting of tokens on the destination chain + + + 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. + + + ### Step 4: Verify completion + + After relaying the message: + + 1. Check your token balance on the destination chain + 2. Confirm the transferred amount matches what you sent + 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). + +## Alternative methods + +You can also use: + +* [viem bindings/actions](https://supersim.pages.dev/guides/interop/relay-using-viem) for TypeScript integration + +## Next steps + +* Read 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) +* Use [Supersim](supersim), a local dev environment that simulates Superchain interop for testing applications against a local version of the Superchain diff --git a/pages/stack/protocol/interop/cross-chain-message.mdx b/pages/stack/interop/cross-chain-message.mdx similarity index 56% rename from pages/stack/protocol/interop/cross-chain-message.mdx rename to pages/stack/interop/cross-chain-message.mdx index 933f23917..bd201b6e5 100644 --- a/pages/stack/protocol/interop/cross-chain-message.mdx +++ b/pages/stack/interop/cross-chain-message.mdx @@ -1,5 +1,5 @@ --- -title: Anatomy of a Cross-Chain Message +title: Anatomy of a cross-chain message lang: en-US description: Learn how cross-chain messaging works with OP Stack interoperability. --- @@ -7,13 +7,13 @@ description: Learn how cross-chain messaging works with OP Stack interoperabilit import { Callout } from 'nextra/components' import Image from 'next/image' -# Anatomy of a Cross-Chain Message +# Anatomy of a cross-chain message -A cross-chain message applies to any message sent across a chain. This applies to asset transfers using the [SuperchainERC20](https://specs.optimism.io/interop/token-bridging.html) token standard. +A cross-chain message refers to any communication sent using Superchain interop. This includes messages sent between different chains within an interop cluster, as well as messages sent on a single chain for interoperable. This functionality enables asset transfers that utilize the [SuperchainERC20](superchain-erc20) token standard. -## How It Works +## How it works -To send a cross-chain message on the Superchain using [native OP Stack interoperability](explainer), these two aspects must be in place: +To send a cross-chain message on the Superchain using [Superchain interoperability](explainer), these two aspects must be in place: 1. Each interoperable chain runs a verifying node for each chain in the interoperable set. 2. Each cross-chain message has an **initiating transaction** on the source chain and a **finalizing transaction** on the destination chain. @@ -29,8 +29,8 @@ To send a cross-chain message on the Superchain using [native OP Stack interoper In the example above, `Ox123` sends 1 OP from OP Mainnet to Base, but this applies to any asset using the SuperchainERC20 token standard. -## Next Steps +## Next steps -* More questions? Check out the FAQ section in the [OP Stack's Native Interop Explainer](explainer#faqs) or check out this [interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). -* Ready to get started? Use [SuperSim](https://github.com/ethereum-optimism/supersim), a local dev environment that simulates interop for testing applications against a local version of the Superchain. -* For more info about how OP Stack interoperability works under the hood, [check out the specs](https://specs.optimism.io/interop/overview.html). +* More questions? Check out the FAQ section in the [Superchain Interop Explainer](explainer#faqs) or check out this [Superchain interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). +* Ready to get started? Use [Supersim](supersim), a local dev environment that simulates Superchain interop for testing applications against a local version of the Superchain. +* 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/interop/devnet.mdx b/pages/stack/interop/devnet.mdx new file mode 100644 index 000000000..3edbca365 --- /dev/null +++ b/pages/stack/interop/devnet.mdx @@ -0,0 +1,65 @@ +--- +title: Interop devnet +lang: en-US +description: Details on the public interoperability devnets. +--- + +import { Callout, Tabs, Steps } from 'nextra/components' + +# Interop devnet + + + Interop devnet is currently in active development and may experience periods of instability, including potential outages, as the networks is regularly updated and improved. Developers should expect some level of unreliability when interacting with the devnet. The devnet is intended for testing and development purposes only, and should not be relied upon for mission-critical applications. + + +The Interop devnet is a temporary public network of two OP Stack Sepolia instances that supports SuperERC20 tokens, native cross-chain messaging, and cross-chain ETH transfers. As we iterate on Superchain interop, these networks will be deprecated once the next devnets are released. + +NOTE: The current Interop devnet has been deprecated. This page will be updated once the next Interop devnet is live. + +## Interop devnet 0 + +| Parameter | Value | +| --------------------------- | ----- | +| Network Name | `TBA` | +| Chain ID | `TBA` | +| Currency Symbol1 | ETH | +| Explorer | 'TBA' | +| Public RPC URL | 'TBA' | +| Sequencer URL | 'TBA' | +| OptimismPortal2 | `TBD` | + +## Interop devnet 1 + +| Parameter | Value | +| --------------------------- | ----- | +| Network Name | `TBA` | +| Chain ID | `TBA` | +| Currency Symbol1 | ETH | +| Explorer | 'TBA' | +| Public RPC URL | 'TBA' | +| Sequencer URL | 'TBA' | +| OptimismPortal2 | `TBD` | + +1. The "currency symbol" is required by some wallets like MetaMask. +2. The `OptimismPortal` is a low-level contract responsible for passing messages between L1 and L2. Messages sent directly to the `OptimismPortal` have no form of replayability. You can send ether directly to the portal to receive it to the sender address on the L2. + +## Sending ETH to the interop devnets + + + ### Get Sepolia ETH + + You can utilize the [Superchain Faucet](https://console.optimism.io/faucet) to get ether on Sepolia. + + ### Send the Sepolia ETH to the devnet + + You can send ether directly to the `OptimismPortal` address and it will go to the same sender address on the devnet. + + ### Wait for bridging to complete + + It'll take approximately 2 minutes for the bridging process to complete and the ether to appear in your wallet. + + +## Next steps + +* Want to start with local development? Use [Supersim](/stack/interop/supersim), a local dev environment that simulates interop for testing applications against a local version of the Superchain. +* Read about [interop message passing](/stack/interop/cross-chain-message) to see how you can implement it yourself on this devnet. diff --git a/pages/stack/protocol/interop/explainer.mdx b/pages/stack/interop/explainer.mdx similarity index 51% rename from pages/stack/protocol/interop/explainer.mdx rename to pages/stack/interop/explainer.mdx index 31964d896..96a6fb6b9 100644 --- a/pages/stack/protocol/interop/explainer.mdx +++ b/pages/stack/interop/explainer.mdx @@ -1,5 +1,5 @@ --- -title: Interoperability Explainer +title: Interoperability explainer lang: en-US description: Learn the basics of interoperability on the OP Stack. --- @@ -7,41 +7,84 @@ description: Learn the basics of interoperability on the OP Stack. import { Callout } from 'nextra/components' import Image from 'next/image' -import { InfoCallout } from '@/components/WipCallout' +import { InteropCallout } from '@/components/WipCallout' - + -# Interoperability Explainer +# Interoperability explainer Interoperability is the ability for a blockchain to securely read the state of another blockchain. -Native OP Stack interoperability provides the ability to read messages and transfer assets across the Superchain (without having to go through L1) via secure message passing. This results in the following benefits: -* fungible and portable assets and liquidity -* lower fees and lower latency -* less fragmentation across the Superchain +Native OP Stack interoperability provides the ability to read messages and transfer assets across the Superchain (without having to go through L1) via low-latency, secure message passing. This results in the following benefits: +* 1-block latency asset movement that is both maximally capital efficient and non-fragmenting * improved user experience for developers on the Superchain +* secure transfer of ETH and ERC-20s across L2s +* horizontally scalable applications -## Secure Message Passing +In a practical sense, this allows users to securely and easily move ETH and tokens from one OP Stack chain to another by leveraging OP governed blockspace security. +## Secure message passing Superchain interop includes both the protocol layer message passing and the Superchain ERC20 token specification. -* **Message passing protocol:** the initial + finalizing/executing [message](https://specs.optimism.io/interop/messaging.html) that fire events to be consumed by the chains in the [dependency set](https://specs.optimism.io/interop/dependency-set.html) -* **SupERC20 token specification**: the [SuperchainERC20](https://specs.optimism.io/interop/token-bridging.html) turns message passing into asset transfer between chains in the interop set +* **Message passing protocol:** the initial + finalizing/executing [message](cross-chain-message) that fire events to be consumed by the chains in the [dependency set](https://specs.optimism.io/interop/dependency-set.html) +* **SuperchainERC20 token specification**: the [SuperchainERC20](superchain-erc20) turns message passing into asset transfer between chains in the interop set. Learn more about how the SuperchainERC20 token standard enables asset interoperability in the Superchain [here](/stack/interop/assets/superchain-erc20) This means ETH and ERC-20s can seamlessly and securely move across L2s, and intent-based protocols (i.e., bridges) can build better experiences on top of the message passing protocol. -## Low Latency -Interoperability allows for horizontally scalable blockchains, a key feature of the Superchain. With Superchain interop, latency can be low (~2 seconds) by optimistically accepting cross-chain messages. -The fork choice rule enforces eventual consistency, meaning that if an invalid cross-chain message is accepted, it will be reorganized out eventually. -The fault proof guarantees that all of the cross-chain messages are accounted for from the perspective of handling withdrawals through the bridge to L1. +## Low latency +Interoperability allows for horizontally scalable blockchains, a key feature of the Superchain. With Superchain interop, latency can be 1-block (~2 seconds) by optimistically accepting cross-chain messages. -## Permissionless Chain Set -It is permissionless to define a dependency on a chain, so chain operators will be able to choose which chains their chains depend on, and it is not a requirement that chains are in each other's dependency set. -Chain operators can add or remove chains from the dependency set through the `SystemConfig`. For example, the dependency set for OP Mainnet is managed by Optimism Governance. +## Permissionless dependency set +The interop protocol works via a dependency set which is configured on a per chain basis and is a unidirectional relationship that defines the set of chains that a chain will accept incoming messages from. -However, since the nature of defining a dependency is one way, it is impossible for a chain to know of all of the other chains that depend on it. +This gives the OP Stack an unopinionated and flexible foundation, so chain operators can choose which chains their chains depend on, and it is not a requirement that chains are in each other's dependency set. +## Superchain interop cluster +The Superchain builds on top of the interop protocol and implements a single mesh network with complete dependencies. In this model, each blockchain in the Superchain interop cluster would have direct connections to every other blockchain, creating a fully connected mesh network. Compared to a hub and spoke model, this provides the highest level of interoperability, as any blockchain can transact directly with any other. + +Each blockchain that is part of the Superchain interop cluster will have the same security model to mitigate the weakest-link scenario and will be managed by Optimism Governance. + + +## New predeploys + +The following predeploys have been added to enable interoperability. Predeployed smart contracts exist at predetermined addresses in the genesis state. They are similar to precompiles but instead run directly in the EVM instead of running native code outside the EVM. + +### CrossL2Inbox + +The `CrossL2Inbox` is the system predeploy for cross chain messaging. Anyone can trigger the execution or validation of cross chain messages, on behalf of any user. + +* **Address:** `0x4200000000000000000000000000000000000022` +* **Specs:** [CrossL2Inbox](https://specs.optimism.io/interop/predeploys.html#crossl2inbox) + +### L2ToL2CrossDomainMessenger + +The `L2ToL2CrossDomainMessenger` is a higher level abstraction on top of the `CrossL2Inbox` that provides general message passing, utilized for secure transfers ERC20 tokens between L2 chains. Messages sent through the `L2ToL2CrossDomainMessenger` on the source chain receive both replay protection and domain binding, ie the executing transaction can only be valid on a single chain. + +* **Address:** `0x4200000000000000000000000000000000000023` +* **Specs:** [L2ToL2CrossDomainMessenger](https://specs.optimism.io/interop/predeploys.html#l2tol2crossdomainmessenger) + +### OptimismSuperchainERC20Factory + +The `OptimismSuperchainERC20Factory` creates ERC20 contracts that implement the SuperchainERC20 standard, grants mint-burn rights to the `L2StandardBridge` (`OptimismSuperchainERC20`), and includes a remoteToken variable. These ERC20s are called `OptimismSuperchainERC20` and can be converted back and forth with `OptimismMintableERC20` tokens. The goal of the `OptimismSuperchainERC20` is to extend functionalities of the `OptimismMintableERC20` so that they are interop compatible. + +* **Address:** `0x4200000000000000000000000000000000000026` +* **Specs:** [OptimismSuperchainERC20Factory](https://specs.optimism.io/interop/predeploys.html#optimismsuperchainerc20factory) + + +### BeaconContract + +The `BeaconContract` predeploy gets called by the `OptimismSuperchainERC20` BeaconProxies deployed by the SuperchainERC20Factory. The Beacon Contract implements the interface defined in [EIP-1967](https://eips.ethereum.org/EIPS/eip-1967). + +* **Address:** `0x4200000000000000000000000000000000000027` +* **Specs:** [BeaconContract](https://specs.optimism.io/interop/predeploys.html#beaconcontract) + +### SuperchainERC20Bridge + +The `SuperchainERC20Bridge` is an abstraction on top of the `L2toL2CrossDomainMessenger` that facilitates token bridging using interop. It has mint and burn rights over `SuperchainERC20` tokens, as described in the [token bridging spec](https://specs.optimism.io/interop/token-bridging.html). + +* **Address:** `0x4200000000000000000000000000000000000028` +* **Specs:** [SuperchainERC20Bridge](https://specs.optimism.io/interop/predeploys.html#superchainerc20bridge) ## Considerations Chain operators will need to run additional infrastructure to be part of the interoperable set. -* The Superchain-backend service, `op-supervisor`, will be a requirement for running an OP Stack chain that has interop enabled. +* The Superchain-backend service, [`op-supervisor`](op-supervisor), will be a requirement for running an OP Stack chain that has interop enabled. `op-supervisor` is responsible for validating all cross-chain messages and will need to have an RPC configured for each chain in the dependency set. * In the future, to reduce infrastructure costs, `op-supervisor` will rely on the P2P network and cryptographic schemes for validating cross-chain messages. @@ -49,9 +92,9 @@ Chain operators will need to run additional infrastructure to be part of the int For additional considerations, join the [Interop discussion](https://github.com/ethereum-optimism/specs/discussions/128) in our specs repo. -## Next Steps +## Next steps * Want to learn more? Read our guide on the anatomy of a [cross-chain message](cross-chain-message) or check out this [interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). -* Ready to get started? Use [SuperSim](https://github.com/ethereum-optimism/supersim), a local dev environment that simulates interop for testing applications against a local version of the Superchain. +* Ready to get started? Use [Supersim](supersim), a local dev environment that simulates interop for testing applications against a local version of the Superchain. * For more info about how OP Stack interoperability works under the hood, [check out the specs](https://specs.optimism.io/interop/overview.html). ## FAQs @@ -68,6 +111,9 @@ See this [dune dashboard](https://dune.com/oplabspbc/op-stack-chains-l1-activity ### What is stopping a sequencer from censoring a cross-chain message? There is nothing stopping a sequencer from censoring a transaction when it is sent directly to the sequencer. This does not mean the network has no censorship resistance, users can always send a deposit transaction for censorship resistance as strong as L1 guarantees. The tradeoff here is the latency, instead of being confirmed in ~2 seconds, the transaction can be confirmed at the rate of L1 block production. It may be possible to adopt something like [EIP-7547](https://eips.ethereum.org/EIPS/eip-7547) in the future to enable low latency censorship resistance. +### What is the weakest link scenario? +Without shared security, there is a risk that interacting chains could enter a conflicting state due to cross-chain interactions. If a weaker chain in the network is attacked or experiences a reorganization, it could change its state independently. This would leave the entire interop cluster in an inconsistent state, as the security of interactions across chains is only as strong as the weakest chain. + ### Are callback style transactions possible? If two blocks are being built at the same time with shared knowledge of their contents, it is possible to build blocks where a transaction calls to another chain, does compute and then a transaction calls back with the results. This requires no protocol level changes, it just requires more sophisticated block builder infrastructure. @@ -81,3 +127,4 @@ Sequencers only have to trust each other, if they are accepting executing messag Chains that have non-fungible blockspace are chains that have different features - it could be that they use Plasma for data availability, a custom gas paying token or have a large execution gas limit. As long as the chain can be fault proven, it can work with Superchain interoperability. At the application layer, it is important for chains to have legibility into the type of chain that the message originated from. This ensures that applications do not accept messages from chains they consider not secure enough. See this [discussion](https://github.com/ethereum-optimism/specs/issues/121) for additional thoughts. When it comes to chains that have different gas limits that are interoperable, it creates a set of transactions that can execute on one chain but not the other. This happens when the transaction consumes more than the gas limit of the smaller chain but less than of the bigger chain. At 2024 usages levels, these sorts of transactions are very rare. In the future, it may be the case that these transactions become more common, it will be up to the chain operators to ensure quality of service for their users. + diff --git a/pages/stack/interop/message-passing.mdx b/pages/stack/interop/message-passing.mdx new file mode 100644 index 000000000..3be6ed39c --- /dev/null +++ b/pages/stack/interop/message-passing.mdx @@ -0,0 +1,66 @@ +--- +title: Interop message passing overview +lang: en-US +description: Learn about cross-chain message passing in the Superchain. +--- + +import { Callout, Steps } from 'nextra/components' + +# Interop message passing overview + + + Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. + + +This guide provides an overview of cross-chain message passing in the Superchain. + +## Overview + +The Superchain uses a pull-based event system for cross-chain communication. Messages are sent through the `L2ToL2CrossDomainMessenger` contract, which provides a secure and standardized way to pass information between chains. + +## How it works + +The following diagram illustrates how messages flow between chains through the `L2ToL2CrossDomainMessenger` contract, which acts as a bridge for cross-chain communication. When a contract on the source chain initiates a message, it's processed through several stages before reaching its destination, ensuring secure and reliable message delivery. + +```mermaid +sequenceDiagram + participant Source as Source Chain + participant Messenger as L2ToL2CrossDomainMessenger + participant Dest as Destination Chain + + Note over Source,Dest: Message Creation + Source->>Messenger: Emit message event + Note over Source,Dest: Message Serialization + Messenger-->>Messenger: Convert to standard format + Note over Source,Dest: Identifier Creation + Messenger-->>Messenger: Generate unique ID + Note over Source,Dest: Message Execution + Messenger->>Dest: Process message +``` + +Cross-chain messaging involves four main phases: + +1. **Message Creation**: The source chain contract emits an event containing the message data and destination information. This event serves as the initiating message that will be relayed across chains. + +2. **Message Serialization**: The messenger contract converts the event data into a standardized format that can be consistently processed across different chains in the Superchain. + +3. **Identifier Creation**: A unique identifier is generated for the message, containing information about its `origin`, `timestamp`, and other `metadata`. This identifier helps track and verify the message. + +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). + +## Common Use Cases + +* Simple messages between identical contracts +* Complex multi-contract interactions +* 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). + +## 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) diff --git a/pages/stack/interop/op-supervisor.mdx b/pages/stack/interop/op-supervisor.mdx new file mode 100644 index 000000000..7afafb83b --- /dev/null +++ b/pages/stack/interop/op-supervisor.mdx @@ -0,0 +1,72 @@ +--- +title: OP Supervisor +lang: en-US +description: Learn the basics of OP Supervisor. +--- + +import { Callout, Tabs, Steps } from 'nextra/components' + +# OP Supervisor + + + Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. + + +OP Supervisor is a service that verifies cross-chain messages and manages interoperability between chains in the OP Stack. It serves as a hub where each `op-node` can index the data needed for cross-chain verification. Chain operators and teams running full nodes like RPC providers are expected to run this service. +Some features and benefits include: + +* Enables secure cross-chain message passing on the Superchain +* Provides a unified point for managing interoperability data +* Supports multiple networks simultaneously +* Offers potential for public endpoints to aid in node synchronization + +## How cross-chain message verification works + +OP Supervisor verifies messages between different chains in the OP Stack, reducing the risk of invalid or malicious cross-chain interactions.⁠ It centralizes the verification process, which reduces the complexity of operating individual nodes⁠.⁠ + +* `op-geth`: queries `op-supervisor` during block-building to verify if a message is sufficiently safe to include. This process involves checking each executing message and potentially undoing transactions if conflicts or unknown states are encountered. +* `op-node`: queries cross-chain safety information and coordinates safety updates between OP stack nodes and `op-supervisor`. It uses the API provided by `op-supervisor` to perform actions like: + * Updating and retrieving various safety levels + * Checking and returning the `cross-unsafe` head for a given chain + * Attempting to promote a block to `cross-safe` status + * Attempting to finalize an L2 block based on L1 finality + +## Log data indexing and management + +OP Supervisor acts as a hub for indexing data that every `op-node` needs to cross-verify with other chains, centralizing the process of managing interoperability data. Maintains the integrity of cross-chain interactions by tracking safety changes⁠ across the Superchain, ensuring consistent application of invalid dependency resolutions. ⁠ + +`op-supervisor` indexes two types of cross-chain dependencies: + +* Interop messages (events): `op-supervisor` maintains an events-index per L2 chain, which determines message-dependencies to check if blocks are safe +* L1 DA (data availability): `op-supervisor` tracks the L1 DA for L2 blocks and maintains a DA safety-index per L2 chain, which helps determine how to rewind L2 chains to resolve invalid dependencies + +## API for cross-chain safety + +OP Supervisor provides an interface for `op-node` to query cross-chain safety information and coordinate safety updates between OP stack nodes and `op-supervisor⁠⁠`. OP-Supervisor uses a global read API to determine **message safety** and **block safety,** utilizing both the events index and the safety index (See op-supervisor's [log data indexing](#log-data-indexing-and-management)). The API is designed to handle potential L1 reorgs that can affect the validity of cross-chain messages⁠. + +Key API methods include: + +| Method | Description | +| ----------------------------------------- | ------------------------------------------------------------------------------------- | +| `UnsafeView` and `SafeView` | Returns the Local and Cross heads for their respective levels | +| `DerivedFrom` | OP Nodes use to check the L1 source of the Supervisor (needed for Safe Head tracking) | +| `UpdateLocalSafe` and `UpdateLocalUnsafe` | Tells the Supervisor when the Node's heads change | +| `Finalized` | Returns the Finalized Head | +| `UpdateFinalizedL1` | Signals to the Supervisor new finality signals | +| `CheckMessage` | Checks logs in the DB directly in tests | + +For a full listing of API names, see the [`op-supervisor` client](https://github.com/ethereum-optimism/optimism/blob/develop/op-service/sources/supervisor_client.go). + +## RPC access to all chains + +OP Supervisor requires RPC access to all chains in the dependency set. This allows `op-supervisor` to verify cross-chain messages and sync data across multiple networks simultaneously, such as OP Mainnet and Base nodes using the same instance. + +Benefits: + +* Scalability: As the number of chains in the Superchain grows, `op-supervisor` can handle the increasing complexity of cross-chain interactions. +* Improved reliability: It enables a more redundant setup, which is good for stability in the growing ecosystem. + +## Next steps + +* Want to learn more? Read our guide on the anatomy of a [cross-chain message](/stack/interop/cross-chain-message) or check out this [interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes). +* For more info about how OP Stack interoperability works under the hood, [check out the specs](https://specs.optimism.io/interop/overview.html). diff --git a/pages/stack/interop/supersim.mdx b/pages/stack/interop/supersim.mdx new file mode 100644 index 000000000..674485a66 --- /dev/null +++ b/pages/stack/interop/supersim.mdx @@ -0,0 +1,61 @@ +--- +title: Supersim multichain development environment +lang: en-US +description: Learn how to use the Supersim local dev environment tool designed to simulate the Optimism Superchain. +--- + +import { Callout } from 'nextra/components' + +# Supersim multichain development environment + + + Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. + + +[Supersim](https://github.com/ethereum-optimism/Supersim) is a local development environment tool designed to simulate the Optimism Superchain for developers building multi-chain applications. It provides a simplified way to test and develop applications that interact with multiple chains within the Superchain ecosystem. + +## Supersim workflow + +```mermaid +graph LR + A[Write Smart Contracts] --> B[Deploy on Supersim] + B --> C[Test Cross-Chain Interactions] + C --> D[Debug and Refine] + D --> B + C --> E[Ready for Production] +``` + +This diagram illustrates the typical workflow for developers using Supersim, from writing smart contracts to testing and refining cross-chain interactions. + +## Features and benefits + +* Simulates multiple OP Stack chains locally (e.g., chain 901, 902) +* Supports testing of cross-chain messaging and interactions +* Includes pre-deployed interoperability contracts +* Offers a CLI interface for starting and managing Supersim instances +* Provides local JSON-RPC endpoints for each simulated chain +* Allows for custom configuration of chain parameters +* Facilitates testing of Superchain-specific features like SuperchainERC20 tokens +* Easy to use with common Ethereum development tools +* Supports chain forking + +## Supersim CLI interaction + +```mermaid +graph TD + A[Developer] --> B[Supersim CLI] + B --> C[Chain 901] + B --> D[Chain 902] + B --> E[...] + C --> F[JSON-RPC Endpoint] + D --> G[JSON-RPC Endpoint] + E --> H[JSON-RPC Endpoint] +``` + +This diagram illustrates how developers interact with Supersim through the CLI, which simulates OP Stack specific features (specifically interop) on locally run chains, each with its own JSON-RPC endpoint and pre-deployed interoperability contracts. + +## 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). +* 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/opcm.mdx b/pages/stack/opcm.mdx new file mode 100644 index 000000000..aa4bac0c5 --- /dev/null +++ b/pages/stack/opcm.mdx @@ -0,0 +1,32 @@ +--- +title: OP Contracts Manager +lang: en-US +tags: ["opcm","eng-security"] +description: Learn how OP Contracts Manager deploys of the OP Stack with one transaction. +--- + +import { Callout, Tabs, Steps } from 'nextra/components' + +# OP Contracts Manager + +The OP Contracts Manager is a contract that deploys the L1 contracts for an OP Stack chain in a single transaction. It provides a minimal set of user-configurable parameters to ensure that the resulting chain meets the standard configuration requirements. + +The version deployed is always a governance-approved contract release. The set of governance approved contract releases can be found on the Optimism Monorepo releases page, and is the set of releases named `op-contracts/vX.Y.Z`. It deploys the [Fault Proof System](/stack/fault-proofs/explainer), using the [PermissionedDisputeGame](/stack/smart-contracts#permissioneddisputegame). + +* Ethereum address: [0x18cec91779995ad14c880e4095456b9147160790](https://etherscan.io/address/0x18cec91779995ad14c880e4095456b9147160790) +* Sepolia address: [0xf564eea7960ea244bfebcbbb17858748606147bf](https://sepolia.etherscan.io/address/0xf564eea7960ea244bfebcbbb17858748606147bf) + +## Purpose + +OPCM simplifies the L1 contract deployments for new OP Stack chains. It addresses three aspects of deploying the OP Stack's L1 contracts: + +1. **Deploy Superchain Contracts.** Superchain contracts are shared between many OP chains, so this occurs only occasionally in production. +2. **Deploy Shared Implementation Contracts.** This occurs once per contracts release in production. +3. **Deploy OP Chain Contracts.** This occurs for every OP chain deployment in production. + +In a future iteration, it also is meant to handle upgrading the smart contracts. + +## Learn more + +* Checkout the [OPCM specs](https://specs.optimism.io/experimental/op-contracts-manager.html) +* Checkout the [OPCM design document](https://github.com/ethereum-optimism/design-docs/blob/main/protocol/op-contracts-manager-arch.md) diff --git a/pages/stack/operators/_meta.json b/pages/stack/operators/_meta.json deleted file mode 100644 index 274405469..000000000 --- a/pages/stack/operators/_meta.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "features": "Features" -} \ No newline at end of file diff --git a/pages/stack/operators/features/_meta.json b/pages/stack/operators/features/_meta.json deleted file mode 100644 index 91f5e9e5c..000000000 --- a/pages/stack/operators/features/_meta.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "proxyd": "proxyd" -} \ No newline at end of file diff --git a/pages/stack/protocol/_meta.json b/pages/stack/protocol/_meta.json deleted file mode 100644 index fb4113973..000000000 --- a/pages/stack/protocol/_meta.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "rollup": "Rollup", - "fault-proofs": "Fault Proofs", - "interop": "Interoperability", - "features": "Features", - "outages": "Sequencer Outages", - "derivation-pipeline":"Derivation Pipeline" -} \ No newline at end of file diff --git a/pages/stack/protocol/fault-proofs/_meta.json b/pages/stack/protocol/fault-proofs/_meta.json deleted file mode 100644 index 344cdb1d7..000000000 --- a/pages/stack/protocol/fault-proofs/_meta.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "explainer": "Fault Proofs Explainer", - "fp-components": "FP System Components", - "cannon": "FPVM: Cannon", - "challenger": "OP-Challenger", - "mips": "MIPS.sol", - "fp-security": "FP Mainnet Security" -} \ No newline at end of file diff --git a/pages/stack/protocol/features/_meta.json b/pages/stack/protocol/features/_meta.json deleted file mode 100644 index bcc657416..000000000 --- a/pages/stack/protocol/features/_meta.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "custom-gas-token": "Custom Gas Token", - "alt-da-mode": "Alt-DA Mode" -} \ No newline at end of file diff --git a/pages/stack/protocol/interop/_meta.json b/pages/stack/protocol/interop/_meta.json deleted file mode 100644 index 5c76b2a4a..000000000 --- a/pages/stack/protocol/interop/_meta.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "explainer": "Interop Explainer", - "cross-chain-message": "Anatomy of Cross-Chain Message" -} \ No newline at end of file diff --git a/pages/stack/protocol/rollup/_meta.json b/pages/stack/protocol/rollup/_meta.json deleted file mode 100644 index 0e5361de9..000000000 --- a/pages/stack/protocol/rollup/_meta.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "overview": "Rollup Overview", - "deposit-flow": "Deposit Flow", - "transaction-flow": "Transaction Flow", - "withdrawal-flow": "Withdrawal Flow" -} \ No newline at end of file diff --git a/pages/stack/research.mdx b/pages/stack/research.mdx new file mode 100644 index 000000000..1a485ee0f --- /dev/null +++ b/pages/stack/research.mdx @@ -0,0 +1,15 @@ +--- +title: Research +description: Documentation covering Block Time Research in the Research section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Research + +Documentation covering Block Time Research in the Research section of the OP Stack ecosystem. + + + + diff --git a/pages/stack/research/_meta.json b/pages/stack/research/_meta.json new file mode 100644 index 000000000..470d7e645 --- /dev/null +++ b/pages/stack/research/_meta.json @@ -0,0 +1,4 @@ +{ + "block-time-research": "Block time research" +} + \ No newline at end of file diff --git a/pages/stack/research/block-time-research.mdx b/pages/stack/research/block-time-research.mdx new file mode 100644 index 000000000..ca8678765 --- /dev/null +++ b/pages/stack/research/block-time-research.mdx @@ -0,0 +1,79 @@ +--- +title: Block time research +lang: en-US +tags: ["op-geth", "op-reth", "eng-platforms"] +description: Sunnyside Labs' (formerly Test in Prod) and OP Labs 1 second block time research. +--- + +# Block time research + +Sunnyside Labs (formerly Test in Prod) and OP Labs have researched whether we can drop OP Chains' block time to one second. + +To validate if dropping the block time is safe, we should check if nodes can build a block under a second when the block spends maximum gas in the production environment–i.e., block building time should take less than one second when the block spends maximum gas. We benchmarked the block-building time of every block at Base and grouped the data in various gas ranges using multiple clients–op-geth & op-reth. + +## Method and raw data + +This [GitHub repository](https://github.com/testinprod-io/block-building-stats/tree/main) contains the test methods, data sets, client versions, and raw data. + +The following benchmarks are available in this [notebook](https://github.com/testinprod-io/block-building-stats/blob/main/stats.ipynb). + +## Benchmarks + +| ![Figure 1: op-geth / archive node / block 5492540 \~ 9816497.](/img/op-stack/protocol/block-time-research-figure-1.png) | +| :----------------------------------------------------------------------------------------------------------------------: | +| **Figure 1**: op-geth / archive node / block 5492540 \~ 9816497 | + +| ![Figure 2: op-geth / full node / block 5492540 \~ 9816497.](/img/op-stack/protocol/block-time-research-figure-2.png) | +| :-------------------------------------------------------------------------------------------------------------------: | +| **Figure 2**: op-geth / full node / block 5492540 \~ 9816497 | + +Figures 1 and 2 show the Base nodes' block-building time distribution with op-geth archive node & full node from block 5492540 to 9816497. We can see that the average block building time takes 0.58 and 0.36 seconds each for blocks that spent 25M \~ 30M gas, which is less than one second. + +| ![Figure 3: op-reth / archive node / block 5492540 \~ 9816497.](/img/op-stack/protocol/block-time-research-figure-3.png) | +| :----------------------------------------------------------------------------------------------------------------------: | +| **Figure 3**: op-reth / archive node / block 5492540 \~ 9816497 | + +Figure 3 shows the Base nodes' block-building time distribution using the op-reth archive node from block 5492540 to 9816497. Compared to op-geth's archive node, we can see that op-reth shows a better performance in all ranges. + +| ![Figure 4: op-geth / archive node / block 13686867 \~ 15074141.](/img/op-stack/protocol/block-time-research-figure-4.png) | +| :------------------------------------------------------------------------------------------------------------------------: | +| **Figure 4:** op-geth / archive node / block 13686867 \~ 15074141 | + +| ![Figure 5: op-geth / full node / block 14567037 \~ 15074141.](/img/op-stack/protocol/block-time-research-figure-5.png) | +| :---------------------------------------------------------------------------------------------------------------------: | +| **Figure 5:** op-geth / full node / block 14567037 \~ 15074141 | + +Throughout the research, we found that the node meaningfully takes longer to build a block as the chain stores more states and transactions to access more historical data. Therefore, we benchmarked the latest blocks in Figures 4 and 5. On average, both the full node and archive node could build a congested block on time. It is worth noting that the average block-building time of high gas spending range is similar to the older blocks, but the average block-building time is higher on the newer blocks. + +| ![Figure 6: op-geth / archive node / block 13686867 \~ 15074141 / histogram of 25m\~30m gas range.](/img/op-stack/protocol/block-time-research-figure-6.png) | +| :----------------------------------------------------------------------------------------------------------------------------------------------------------: | +| **Figure 6**: op-geth / archive node / block 13686867 \~ 15074141 / histogram of 25m\~30m gas range | + +If we zoom in on the 25m\~30m gas range of the archive node, the average could be potentially concerning–0.51 sec. It is worth noting that we can see the average is diverged from p50 (0.4 sec) because of outliers in the histogram (Figure 6), and p50 is a more important metric than the average for the block progression (Sequencer) because of its asynchronous nature. + +When the sequencer seals the block after the block time, it stops to include the transactions and yields the current processing transactions to the next block. Therefore, the sequencer can include most transactions that took less than one second in the block on time and include outliers in the next block. Therefore, we can expect the system to be able to build blocks in one second in most cases, even in the highest gas range (25m\~30m gas). + +As a result, we can learn that nodes can build the latest blocks of Base Mainnet with the highest level of production loads in one second with an [i3en.3xlarge instance](https://aws.amazon.com/ec2/instance-types/i3en/) (or similar specs). + +## Expected impacts + +### Verifier + +* Sync from genesis: If OP Chains' block time drops to one second, verifiers may need longer to sync the chain from the genesis with L1 derivation. However, we expect it won't be a notable issue for verifiers as OP Stack supports the [engine sync](/builders/node-operators/management/snap-sync). +* Following the tip: The research suggests that verifiers are less likely to have a problem following the tip because nodes could build a block under one second at the highest gas range, especially since most verifiers are full nodes. + +### Sequencer + +* Block progression: As the previous paragraph mentioned, the data suggests we don't expect problems on a shorter block time. + +## Limitation + +The data suggests we don't expect a problem dropping the block time to one second for now, as the average block building time of the latest blocks takes 0.19 seconds for the Base Mainnet. One concerning point: the benchmark shows that it takes longer to build a block as the chain progresses. When the chain stores more states over time and usage surges to a peak like 2017 Ethereum, we might need performance patches then. + +However, it is also worth noting that the research assumes that the Base Mainnet handles 2x of their current traffic–dropping the block time to half but still spending gas as current (when it runs two seconds of block time). Plus, the Base Mainnet's average block gas spending is 10M. To make all blocks reach the highest gas level that this research focuses on (25M), it's another 2.5x. + +Therefore, this research assumes the chain processes approximately 5x traffic compared to the current Base Mainnet (2x in block time \* 2.5x in gas spending). + +## Reference + +Base's prior research for raising gas limit: [replayor](https://github.com/danyalprout/replayor) diff --git a/pages/stack/rollup.mdx b/pages/stack/rollup.mdx new file mode 100644 index 000000000..ca95c2564 --- /dev/null +++ b/pages/stack/rollup.mdx @@ -0,0 +1,19 @@ +--- +title: Rollup +description: The big idea that makes Optimism possible is the Optimistic Rollup. We'll go through a brief explainer of *how* Optimistic Rollups work at a high l... +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Rollup + +The big idea that makes Optimism possible is the Optimistic Rollup. We'll go through a brief explainer of *how* Optimistic Rollups work at a high l... + + + + + + + + diff --git a/pages/stack/rollup/_meta.json b/pages/stack/rollup/_meta.json new file mode 100644 index 000000000..def933fd0 --- /dev/null +++ b/pages/stack/rollup/_meta.json @@ -0,0 +1,5 @@ +{ + "overview": "Rollup overview", + "derivation-pipeline": "Derivation pipeline", + "outages": "Sequencer outages" +} \ No newline at end of file diff --git a/pages/stack/protocol/derivation-pipeline.mdx b/pages/stack/rollup/derivation-pipeline.mdx similarity index 93% rename from pages/stack/protocol/derivation-pipeline.mdx rename to pages/stack/rollup/derivation-pipeline.mdx index 4fbad5f31..2c2aad540 100644 --- a/pages/stack/protocol/derivation-pipeline.mdx +++ b/pages/stack/rollup/derivation-pipeline.mdx @@ -1,14 +1,14 @@ --- -title: Derivation Pipeline +title: Derivation pipeline lang: en-US description: Overview of the derivation pipeline in the OP Stack protocol. --- -# Derivation Pipeline +# Derivation pipeline The derivation pipeline is a fundamental component of the OP Stack protocol, responsible for processing and validating transactions in the Optimism network. It ensures the integrity and security of the blockchain by deriving a consistent state from the sequenced transactions and batches submitted by the sequencer. -## Key Functions of the Derivation Pipeline +## Key functions of the derivation pipeline The following are key functions of the derivation pipeline: @@ -16,7 +16,7 @@ The following are key functions of the derivation pipeline: * **Safe Head and Unsafe Blocks**: The derivation pipeline maintains two types of heads: the Safe Head and the Unsafe Head. The Safe Head represents the most recent confirmed state on L1, while Unsafe Blocks are those that have been sequenced but not yet confirmed on L1. * **Reorg and Recovery**: If the sequencing window (typically 12 hours) is exceeded without a valid batch being discovered on L1, the pipeline will revert all Unsafe Blocks from that period. The pipeline then progresses using a default block that is empty except for deposits, allowing the network to recover and continue processing new transactions. -## Sequencer Window +## Sequencer window The sequencer window defines the maximum time allowed for batches to be submitted and confirmed on L1. If this window is exceeded, the derivation pipeline takes corrective actions to ensure the network's integrity and continued operation. @@ -25,11 +25,11 @@ For example: * In a 12-hour sequencing window, if no valid batch is discovered on L1, the pipeline reverts to Unsafe Blocks and uses a default block to move forward. * Increasing the window to 24 hours allows nodes to wait longer before reorging out unsafe blocks, but it may introduce additional challenges such as increased resource constraints and difficulty in processing larger batches. -## Configuration and Adjustments +## Configuration and adjustments The `sequencerWindowSize` parameter is set during the deployment configurations and may be difficult to change once established. It is important for chain operators to carefully consider the appropriate window size to balance network performance and stability. -## Next Steps +## Next steps * For more detailed information, refer to the [derivation pipeline specification](https://specs.optimism.io/protocol/derivation.html). * Have questions? You can ask a question in the [developer support forum](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/stack/protocol/outages.mdx b/pages/stack/rollup/outages.mdx similarity index 97% rename from pages/stack/protocol/outages.mdx rename to pages/stack/rollup/outages.mdx index 12ceed8cc..4f20970e9 100644 --- a/pages/stack/protocol/outages.mdx +++ b/pages/stack/rollup/outages.mdx @@ -1,10 +1,10 @@ --- -title: Sequencer Outages +title: Sequencer outages lang: en-US description: Learn what happens if the Sequencer goes down and how you can be prepared. --- -# Sequencer Outages +# Sequencer outages All OP Stack chains have a Sequencer that can receive, order, and publish L2 transactions to L1. Like any software systems, a Sequencer could potentially become unavailable for any number of different reasons. @@ -18,7 +18,7 @@ Sequencer outages can broadly be categorized into two different types: Both outage types can be circumvented by submitting transactions directly to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L209) contract on L1 with certain important caveats. Keep reading to learn more about these potential outages and how to handle them. -## Sequencer Downtime Outages +## Sequencer downtime outages ### Description @@ -37,7 +37,7 @@ Users may observe that the network appears to be "stuck" at a particular block h Users can always bypass the Sequencer by sending L2 transactions directly to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L209) contract on L1. Refer to the [Bypassing the Sequencer](#bypassing-the-sequencer) section below for more information about this functionality. -## Transaction Submission Outages +## Transaction submission outages ### Description @@ -60,7 +60,7 @@ This can appear to users as a large change in the expected state of the L2 chain Users can always bypass the Sequencer by sending L2 transactions directly to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L209) contract on L1. Refer to the [Bypassing the Sequencer](#bypassing-the-sequencer) section for more information about this functionality. -## Bypassing the Sequencer +## Bypassing the sequencer A core security goal of OP Stack chains is that the Sequencer should not be able to prevent users from submitting transactions to the L2 chain. Users of OP Stack chains can always bypass the sequencer and include transactions in the L2 chain by sending their L2 transactions directly to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L209) contract on L1. @@ -79,13 +79,13 @@ L2 transactions can be triggered on L1 by calling the `depositTransaction` funct Users can send any type of L2 transaction to the `OptimismPortal` contract including contract creations and transactions that carry ETH value. As a security measure, transactions sent via the `OptimismPortal` are indistinguishable from transactions sent via the Sequencer from the perspective of smart contracts on L2. -### Address Aliasing +### Address aliasing 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. -### Inclusion Rules +### Inclusion rules Transactions sent to the `OptimismPortal` contract are processed according to a set of rules designed to limit the impact of a failed Sequencer. It's important to understand these rules in detail to properly mitigate the effects of an outage. @@ -102,12 +102,12 @@ If the Sequencer is unavailable or transactions are not published to L1 within t Refer to the [L2 Chain Derivation Specification](https://specs.optimism.io/protocol/derivation.html) for a much more detailed explanation of how transactions sent to the `OptimismPortal` contract are processed. -### Inclusion Scenarios +### Inclusion scenarios It can be helpful to understand how transactions sent to the `OptimismPortal` contract are processed in different scenarios. The following scenarios make different assumptions about the state of the Sequencer and the L2 chain to illustrate how transactions sent to the `OptimismPortal` contract are processed. -#### Total Sequencer Outage +#### Total sequencer outage In this scenario we'll assume that the Sequencer is completely unavailable and unable to process any transactions. Users must send transactions directly to the `OptimismPortal` contract to have them included in the L2 chain. @@ -133,7 +133,7 @@ sequenceDiagram OP->>L2: Transaction 1 included in L2 automatically OP->>L2: Transaction 2 included in L2 automatically ``` -#### Partial Sequencer Outage +#### Partial sequencer outage In this scenario we'll assume that the Sequencer is down for some period of time but comes back online before the `sequencer_window` has elapsed. A user sends a transaction to the `OptimismPortal` during the downtime and but the Sequencer comes back online and includes the transaction in an L2 block before the full `sequencer_window` ends. @@ -152,7 +152,7 @@ sequenceDiagram S->>L2: Transaction included by Sequencer ``` -#### Partial Outage Ordering +#### Partial outage ordering Here we'll again assume that the Sequencer is down for some period of time but comes back online before the `sequencer_window` has elapsed. In this scenario, we'll observe the ability that the Sequencer has to include additional transactions in the L2 chain in between transactions sent to the `OptimismPortal` contract. diff --git a/pages/stack/protocol/rollup/overview.mdx b/pages/stack/rollup/overview.mdx similarity index 94% rename from pages/stack/protocol/rollup/overview.mdx rename to pages/stack/rollup/overview.mdx index a275be581..d9a6f23e7 100644 --- a/pages/stack/protocol/rollup/overview.mdx +++ b/pages/stack/rollup/overview.mdx @@ -1,24 +1,24 @@ --- -title: Rollup Protocol Overview +title: Rollup protocol overview lang: en-US description: Learn how Optimistic Rollups work at a high level. --- -# Rollup Protocol Overview +# Rollup protocol overview The big idea that makes Optimism possible is the Optimistic Rollup. We'll go through a brief explainer of *how* Optimistic Rollups work at a high level. Then we'll explain *why* Optimism is built as an Optimistic Rollup and why we believe it's the best option for a system that addresses all of our design goals. Check out the [protocol specs](https://specs.optimism.io/), if you want to more detail about the rollup protocol. -## Optimistic Rollups TL;DR +## Optimistic rollups TL;DR Optimism is an "Optimistic Rollup," which is basically just a fancy way of describing a blockchain that piggy-backs off of the security of another "parent" blockchain. Specifically, Optimistic Rollups leverage the consensus mechanism (like PoW or PoS) of their parent chain instead of providing their own. In OP Mainnet's case, this parent blockchain is Ethereum. ![Ethereum and Optimism Forever Doodle.](/img/op-stack/protocol/ethereum-optimism-forever.png) -## Block Storage +## Block storage In Bedrock, L2 blocks are saved to the Ethereum blockchain using a non-contract address ([`0xff00..0010` on Ethereum](https://etherscan.io/address/0xff00000000000000000000000000000000000010)) to minimize the L1 gas expense. As these blocks are submitted as transactions using EIP-4844 [blobs](/builders/chain-operators/management/blobs), there is no way to modify or censor them after the "transaction" is included in a block that has enough attestations. @@ -27,7 +27,7 @@ This is the way that OP Mainnet inherits the availability and integrity guarante Blocks are written to L1 in [a compressed format](https://specs.optimism.io/protocol/derivation.html#batch-submission-wire-format) to reduce costs. This is important because writing to L1 is [the major cost of OP Mainnet transactions](/stack/transactions/fees). -## Block Production +## Block production Optimism block production is primarily managed by a single party, called the "sequencer," which helps the network by providing the following services: @@ -50,9 +50,9 @@ Transactions get to the sequencer in two ways: This provides OP Mainnet with L1 Ethereum level censorship resistance. You can read more about this mechanism [in the protocol specifications](https://specs.optimism.io/protocol/derivation.html#deriving-the-transaction-list). -For the moment, [The Optimism Foundation](https://www.optimism.io/) runs the only block producer on OP Mainnet. Refer to [Protocol specs](overview) section for more information about how we plan to decentralize the Sequencer role in the future. +For the moment, [The Optimism Foundation](https://www.optimism.io/) runs the only block producer on OP Mainnet. -## Block Execution +## Block execution The execution engine (implemented as the `op-geth` component) receive blocks using two mechanisms: @@ -64,7 +64,7 @@ The execution engine (implemented as the `op-geth` component) receive blocks usi This mechanism is slower, but censorship resistant. You can read more about it [in the specs](https://specs.optimism.io/protocol/exec-engine.html#worst-case-sync). -## Bridging ETH or Tokens Between Layers +## Bridging ETH or tokens between layers Optimism is designed so that users can send arbitrary messages between smart contracts on L2 (OP Mainnet, OP Sepolia, etc.) and the underlying L1 (Ethereum mainnet, Sepolia, etc.). This makes it possible to transfer ETH or tokens, including ERC20 tokens, between the two networks. @@ -96,7 +96,7 @@ Withdrawals (the term is used for any OP Mainnet to Ethereum message) have three [You can read the full withdrawal specifications here](https://specs.optimism.io/protocol/withdrawals.html) -## Fault Proofs +## Fault proofs In an Optimistic Rollup, state commitments are published to L1 (Ethereum in the case of OP Mainnet) without any direct proof of the validity of these commitments. Instead, these commitments are considered pending for a period of time (called the "challenge window"). @@ -110,7 +110,7 @@ The ordering of transactions and the state of OP Mainnet is unchanged by a fault The fault proof process is currently undergoing major redevelopment as a side-effect of the November 11th, 2021 [EVM Equivalence](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) update. -## Next Steps +## Next steps -* If you want to learn more about rollup protocol, check out the guides on [deposit flow](deposit-flow), [withdrawal flow](withdrawal-flow), or [transaction flow](transaction-flow). +* If you want to learn more about rollup protocol, check out the guides on [deposit flow](/stack/transactions/deposit-flow), [withdrawal flow](/stack/transactions/withdrawal-flow), or [transaction flow](/stack/transactions/transaction-flow). * To learn about operating your own L2 rollup, see the guide on [starting a self-hosted chain](/builders/chain-operators/self-hosted) or go directly to the tutorial on [creating your own L2 rollup](/builders/chain-operators/tutorials/create-l2-rollup). diff --git a/pages/stack/security.mdx b/pages/stack/security.mdx new file mode 100644 index 000000000..fbf62b199 --- /dev/null +++ b/pages/stack/security.mdx @@ -0,0 +1,17 @@ +--- +title: Security +description: Documentation covering Faq, Pause in the Security section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Security + +Documentation covering Faq, Pause in the Security section of the OP Stack ecosystem. + + + + + + diff --git a/pages/stack/security/_meta.json b/pages/stack/security/_meta.json index 672af59c4..d84287eaa 100644 --- a/pages/stack/security/_meta.json +++ b/pages/stack/security/_meta.json @@ -1,4 +1,4 @@ { "faq": "Security FAQs", - "pause": "Pause and Unpause the Bridge" + "pause": "Pause and unpause the Bridge" } \ No newline at end of file diff --git a/pages/stack/security/faq.mdx b/pages/stack/security/faq.mdx index 2df0f86cd..def6ace78 100644 --- a/pages/stack/security/faq.mdx +++ b/pages/stack/security/faq.mdx @@ -1,12 +1,12 @@ --- -title: OP Stack Security FAQs +title: OP Stack security FAQs lang: en-US description: Learn answers to common questions about OP Stack security. --- import { Callout } from 'nextra/components' -# OP Stack Security FAQs +# OP Stack security FAQs 🚧 The OP Stack is a work in progress. Constantly pushing to improve the overall security and decentralization of the OP Stack is a top priority. @@ -32,7 +32,7 @@ As with anything, modify the OP Stack at your own risk. There is no guarantee th ### Can I use fault proofs? -**Not yet.** The OP Stack does not currently have a fault proof system. **Note that fault proofs do not meaningfully improve the security of a system if that system can be upgraded within the 7 day challenge window ("fast upgrade keys")**. A system with fast upgrade keys is fully dependent on the upgrade keys for security. +**Not yet.** The OP Stack does not currently have a Fault Proof System. **Note that fault proofs do not meaningfully improve the security of a system if that system can be upgraded within the 7 day challenge window ("fast upgrade keys")**. A system with fast upgrade keys is fully dependent on the upgrade keys for security. Fault proofs are a key milestone and top priority for the OP Stack. In the meantime, the OP Stack can be shipped with several other excellent security options for systems that want to improve security before fault proofs are available in production. diff --git a/pages/stack/security/pause.mdx b/pages/stack/security/pause.mdx index 41fd67950..2491195e7 100644 --- a/pages/stack/security/pause.mdx +++ b/pages/stack/security/pause.mdx @@ -1,10 +1,10 @@ --- -title: Pausing the Bridge +title: Pausing the bridge lang: en-US description: Learn how the OP Stack bridge can be paused as backup safety mechanism. --- -# Pausing the Bridge +# Pausing the bridge The [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/L1/OptimismPortal.sol) is the low-level L1 message passing contract present on all standard OP Stack chains. This contract handles the L1 side of the communication channel between an OP Stack chain and its L1 parent chain. @@ -15,7 +15,7 @@ This is a backup safety mechanism that can be used to help mitigate potential ac Pause functionality and [two-step withdrawals](https://web.archive.org/web/20230608050641/https://blog.oplabs.co/two-step-withdrawals/) were introduced to the OP Stack to mitigate the risk of withdrawal bugs that have led to exploits in other bridging systems. -## Pause Functionality +## Pause functionality The `OptimismPortal` can be configured to allow a `GUARDIAN` address to pause and unpause L2-to-L1 transactions from being executed. L2-to-L1 transactions allow users and smart contracts on the OP Stack chain to send messages to the L1 parent chain. @@ -25,12 +25,12 @@ L1-to-L2 transactions are not affected by pause functionality. Pauses by the `GUARDIAN` impact all L2-to-L1 transactions for the OP Stack chain in question and cannot be targeted to specific users, smart contracts, or transactions. Pauses are designed to be a backup safety mechanism and are expected to be used only in the event of an active pressing security concern. -## Pause and Unpause Functions +## Pause and unpause functions The `GUARDIAN` can pause and unpause L2-to-L1 transactions at any time by calling the [`pause`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L151-L156) and [`unpause`](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L158-L163) functions on the `OptimismPortal` contract. Additional controls on the `GUARDIAN` address can be implemented by configuring the `GUARDIAN` as a smart contract. -## Guardian Address +## Guardian address The `GUARDIAN` address is initially configured when the OP Stack chain is deployed and can be modified by the network's administrative address or smart contract. A chain can choose to remove the `GUARDIAN` role by configuring the `GUARDIAN` to be an inaccessible address such as the [zero address](https://etherscan.io/address/0x0000000000000000000000000000000000000000). diff --git a/pages/stack/smart-contracts.mdx b/pages/stack/smart-contracts.mdx index cfb440e62..bb6a29f5d 100644 --- a/pages/stack/smart-contracts.mdx +++ b/pages/stack/smart-contracts.mdx @@ -1,22 +1,22 @@ --- -title: Smart Contract Overview +title: Smart Contract overview lang: en-US description: Learn about the smart contracts that make up the OP Stack. --- import { Callout } from 'nextra/components' -# Smart Contract Overview +# Smart Contract overview This guide provides an overview of the functionality of the smart contract components. You can also find [contract addresses](/chain/addresses) on OP Mainnet. -## Layer 1 Contracts +## Layer 1 contracts The layer 1 contracts of the OP Stack are deployed on Ethereum. Their primary purpose is to facilitate the cross domain message passing and maintain the valid state root of the layer 2. -### Official Releases +### Official releases The full smart contract release process is documented in the [monorepo](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/VERSIONING.md). All production releases are always tagged, versioned as `/v`. @@ -33,11 +33,11 @@ Contract releases have a component name of `op-contracts` and therefore are tagg smart contractsβ€”only deploy from `op-contracts/vX.Y.Z` -#### op-contracts/v1.6.0 - Fault Proof Fixes +#### op-contracts/v1.6.0 - Fault proof fixes The release fixes security vulnerabilities found in Fault Proof contracts. They were made in response to security vulnerabilities identified during a series of third-party security audits by Spearbit, Cantina, and Code4rena. None of the vulnerabilities have been exploited, and user assets are not and were never at risk. -The upgrade was coupled with the [Granite network upgrade](/builders/node-operators/network-upgrades#granite) to improve the stability and performance of the fault proof system. In addition, the capabilities of the Guardian and DeputyGuardian have been extended to set the anchor state for the fault proof system in order to prevent referencing invalid anchor states. +The upgrade was coupled with the [Granite network upgrade](/builders/node-operators/network-upgrades#granite) to improve the stability and performance of the Fault Proof System. In addition, the capabilities of the Guardian and DeputyGuardian have been extended to set the anchor state for the Fault Proof System in order to prevent referencing invalid anchor states. * [Official - Fault Proof Fixes Release](https://github.com/ethereum-optimism/optimism/releases/tag/op-contracts%2Fv1.6.0) * [Governance Post](https://gov.optimism.io/t/upgrade-proposal-10-granite-network-upgrade/8733) @@ -62,14 +62,14 @@ The upgrade was coupled with the [Granite network upgrade](/builders/node-operat * L1StandardBridge: [2.1.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/L1/L1StandardBridge.sol#L73) * OptimismMintableERC20Factory: [1.9.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/universal/OptimismMintableERC20Factory.sol#L46) * OptimismPortal: [3.10.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/L1/OptimismPortal2.sol#L144) - * SystemConfig: [2.0.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/L1/SystemConfig.sol#L111) + * SystemConfig: [2.2.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/L1/SystemConfig.sol#L111) * DisputeGameFactory: [1.0.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/dispute/DisputeGameFactory.sol#L25) * SuperchainConfig: [1.1.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.2.0/packages/contracts-bedrock/src/L1/SuperchainConfig.sol#L38) * ProtocolVersions: [1.0.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.2.0/packages/contracts-bedrock/src/L1/ProtocolVersions.sol#L39)
-#### op-contracts/v1.5.0 - Safe Extensions +#### op-contracts/v1.5.0 - Safe extensions The Safe Extensions protocol upgrade is intended to increase the security and decentralization of the Superchain by: @@ -106,7 +106,7 @@ vote for L2 predeploy upgrades and is a requirement for Stage 1. * L1StandardBridge: [2.1.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/L1/L1StandardBridge.sol#L73) * OptimismMintableERC20Factory: [1.9.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/universal/OptimismMintableERC20Factory.sol#L46) * OptimismPortal: [3.10.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/L1/OptimismPortal2.sol#L144) - * SystemConfig: [2.0.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/L1/SystemConfig.sol#L111) + * SystemConfig: [2.2.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/L1/SystemConfig.sol#L111) * FaultDisputeGame: [1.2.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/dispute/FaultDisputeGame.sol#L73) * PermissionedDisputeGame: [1.2.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/dispute/PermissionedDisputeGame.sol) * DisputeGameFactory: [1.0.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/dispute/DisputeGameFactory.sol#L25) @@ -119,7 +119,7 @@ vote for L2 predeploy upgrades and is a requirement for Stage 1. -#### op-contracts/v1.4.0 - Fault Proofs +#### op-contracts/v1.4.0 - Fault proofs This protocol upgrade reduces the trust assumptions for users of the OP Stack by enabling permissionless output proposals and a permissionless fault proof diff --git a/pages/stack/transactions.mdx b/pages/stack/transactions.mdx new file mode 100644 index 000000000..4f82dfc0f --- /dev/null +++ b/pages/stack/transactions.mdx @@ -0,0 +1,31 @@ +--- +title: Transactions +description: Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Transaction Flow, Transactions, Withdrawal Flow in the Transactions section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Transactions + +Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Transaction Flow, Transactions, Withdrawal Flow in the Transactions section of the OP Stack ecosystem. + + + + + + + + + + + + + + + + + + + + diff --git a/pages/stack/transactions/_meta.json b/pages/stack/transactions/_meta.json index 8f79b3007..ebc6603e2 100644 --- a/pages/stack/transactions/_meta.json +++ b/pages/stack/transactions/_meta.json @@ -1,3 +1,9 @@ { - "fees": "Transaction Fees" + "fees": "Transaction fees", + "transaction-flow": "Transaction flow", + "transaction-finality" : "Transaction finality", + "deposit-flow": "Deposit flow", + "withdrawal-flow": "Withdrawal flow", + "forced-transaction": "Forced transaction", + "cross-domain": "Cross domain transaction" } diff --git a/pages/stack/transactions/cross-domain.mdx b/pages/stack/transactions/cross-domain.mdx new file mode 100644 index 000000000..846141f22 --- /dev/null +++ b/pages/stack/transactions/cross-domain.mdx @@ -0,0 +1,62 @@ +--- +title: Cross-Domain +lang: en-US +description: An overview of the lifecycle of an OP Stack cross-chain transaction, detailing the flow of transactions between Layer 2 and Layer 1. +--- + +import { Callout, Steps } from 'nextra/components' + +# Cross-Domain Overview + +This overview provides a detailed walkthrough of the lifecycle of cross-chain transactions, covering deposits, withdrawals, and transaction flows between L1 and L2. The diagram below illustrates the main components and steps involved. + +![Lifecycle of an OP Stack Crosschain Transaction.](/img/op-stack/protocol/op-cross-chain-txn.jpeg) +_Figure 1: The Lifecycle of an OP Stack Crosschain Transaction_ + +Cross-domain communication in the OP Stack involves moving assets and messages between L1 and L2. Key components, such as bridges, messengers, and portals, ensure these transactions are executed securely and transparently. This page breaks down the lifecycle of a cross-chain transaction into three main flows: Deposit Flow, Transaction Flow (Tx Flow), and Withdrawal Flow. + +## Deposit Flow + +Depositing assets from L1 to L2 follows a structured process that ensures funds are securely transferred and credited to the user's L2 account. The steps are as follows: + +1. **User Initiation (L1 Standard Bridge):** + The user initiates a deposit by sending assets (e.g., ETH or tokens) to the L1 Standard Bridge contract. This contract receives the assets and prepares a message to relay to L2. + +2. **Message Relaying (L1 CrossDomain Messenger):** + The L1 Standard Bridge sends a message to the L1 CrossDomain Messenger, which is responsible for handling inter-layer communication. The messenger emits a `TransactionDeposited` event to signal the start of the deposit process. + +3. **Processing on L2 (OptimismPortal):** + The message is received by the OptimismPortal on L2. Here, the deposited assets are held securely until the transaction is finalized. The portal initiates the deposit transaction, updating the user's balance on L2. + +4. **Finalization (L2 CrossDomain Messenger):** + The L2 CrossDomain Messenger processes the deposit by updating the user's account balance, and making the assets available for use on L2. + +## Transaction (Tx) Flow + +The transaction flow covers the steps involved in cross-domain message passing and state updates between L1 and L2: + +1. **Message Queuing (L2ToL1MessagePasser):** +During cross-layer communication, certain messages are queued for processing. The `L2ToL1MessagePasser` prepares these messages for state updates or withdrawals, ensuring they are available for proving and relaying. + +2. **State Reading and Proving (L2OutputOracle):** +The `L2OutputOracle` plays a critical role in validating state changes between L1 and L2. It reads the current state and submits a proposal using `proposeL2Output()`. This proposal includes information about queued messages or state changes that need to be relayed to L1. + +3. **Message Relay (CrossDomain Messengers):** +Messages are relayed between the L1 and L2 CrossDomain Messengers as part of transaction execution. This includes updating state or finalizing transactions on the target layer. + + +## Withdrawal Flow + +Withdrawing assets from L2 back to L1 involves a multi-step process to ensure the transaction is validated and executed correctly: + +1. **User Initiation (L2 Standard Bridge):** +The withdrawal process starts when the user calls the `withdraw()` function on the L2 Standard Bridge, specifying the amount and asset to be withdrawn. + +2. **Message Relay (L2 CrossDomain Messenger):** +The L2 CrossDomain Messenger receives the withdrawal request and relays the message for processing. It may involve queuing the message in the `L2ToL1MessagePasser` for further steps. + +3. **Proving and Finalization (L2OutputOracle):** +The withdrawal message is proven using the `L2OutputOracle`, which submits a state output proving that the withdrawal is legitimate. This step involves reading the state and generating the required proofs during the proving time. + +4. **Finalization (L1 CrossDomain Messenger and L1 Standard Bridge):** +Once the withdrawal is proven, the message is finalized by the L1 CrossDomain Messenger. The L1 Standard Bridge completes the process by releasing the withdrawn assets to the user's L1 account. diff --git a/pages/stack/protocol/rollup/deposit-flow.mdx b/pages/stack/transactions/deposit-flow.mdx similarity index 99% rename from pages/stack/protocol/rollup/deposit-flow.mdx rename to pages/stack/transactions/deposit-flow.mdx index 3253e4032..54e80753b 100644 --- a/pages/stack/protocol/rollup/deposit-flow.mdx +++ b/pages/stack/transactions/deposit-flow.mdx @@ -1,5 +1,5 @@ --- -title: Deposit Flow +title: Deposit flow lang: en-US description: Learn the deposit flow process for L2 deposit transactions, triggered by events on L1. --- @@ -7,7 +7,7 @@ description: Learn the deposit flow process for L2 deposit transactions, trigger import Image from 'next/image' import { Callout } from 'nextra/components' -# Deposit Flow +# Deposit flow This guide explains the deposit flow process for L2 deposit transactions, triggered by transactions or events on L1. In Optimism terminology, "*deposit transaction*" refers to any L2 transaction that is triggered by a transaction or event on L1. @@ -16,7 +16,7 @@ Information is encapsulated in lower layer packets on the sending side and then ![Deposit Flow Diagram.](/img/op-stack/protocol/deposit-flow.svg) -## L1 Processing +## L1 processing 1. An L1 entity, either a smart contract or an externally owned account (EOA), sends a deposit transaction to [`L1CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/L1/L1CrossDomainMessenger.sol), using [`sendMessage`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/universal/CrossDomainMessenger.sol#L249-L289). This function accepts three parameters: @@ -44,7 +44,7 @@ Information is encapsulated in lower layer packets on the sending side and then 4. [The `depositTransaction` function](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/L1/OptimismPortal.sol#L422-L483) runs a few sanity checks, and then emits a [`TransactionDeposited`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/contracts-bedrock/contracts/L1/OptimismPortal.sol#L85-L99) event. -## L2 Processing +## L2 processing 1. The `op-node` component [looks for `TransactionDeposited` events on L1](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/op-node/rollup/derive/deposits.go#L13-L33). If it sees any such events, it [parses](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/op-node/rollup/derive/deposit_log.go) them. diff --git a/pages/stack/transactions/fees.mdx b/pages/stack/transactions/fees.mdx index 1a6f3f47b..31340544a 100644 --- a/pages/stack/transactions/fees.mdx +++ b/pages/stack/transactions/fees.mdx @@ -1,12 +1,19 @@ --- -title: Transaction Fees on OP Mainnet +title: Transaction fees on OP Mainnet lang: en-US description: Learn how transaction fees work on OP Mainnet. --- import { Callout } from 'nextra/components' -# Transaction Fees on OP Mainnet + + The OP Stack maintains a distinct gas limit compared to the Ethereum mainnet. + While both chains use the same underlying transaction formats, Optimism's gas limits are tailored for optimal Layer 2 performance and scalability. + As a result, transactions on Optimism may behave differently from the mainnet regarding gas usage and fee estimation. + For a detailed comparison of gas limits between Optimism and Ethereum, see the [Optimism Chain Differences documentation](https://docs.optimism.io/chain/differences#transaction-fees). + + +# Transaction fees on OP Mainnet OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), which means it reuses the same Ethereum code you're already familiar with and behaves as much like Ethereum as possible. However, transaction fees on all Layer 2 systems need to diverge from Ethereum to some extent for a number of reasons. @@ -16,7 +23,7 @@ OP Mainnet transaction fees are composed of an [Execution Gas Fee](#execution-ga The total cost of a transaction is the sum of these two fees. Continue reading to learn more about exactly how each of these fee components are charged. -## Execution Gas Fee +## Execution gas fee A transaction's execution gas fee is exactly the same fee that you would pay for the same transaction on Ethereum. This fee is equal to the amount of gas used by the transaction multiplied by the gas price attached to the transaction. @@ -30,7 +37,7 @@ The only difference is that the gas price on OP Mainnet is much lower than the g For this component of the fee, you can estimate the total cost of a transaction using the same tools you would use to estimate the cost of a transaction on Ethereum. You can read more about how Ethereum's gas fees work over on [Ethereum.org](https://ethereum.org/en/developers/docs/gas/). -### Base Fee +### Base fee The [base fee](https://ethereum.org/en/developers/docs/gas/#base-fee) is the minimum price per unit of gas that a transaction must pay to be included in a block. Transactions must specify a maximum base fee higher than the block base fee to be included. @@ -40,18 +47,19 @@ The OP Mainnet base fee behaves exactly like the Ethereum base fee with a few sm 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. Read more about the base fee in the [Ethereum.org documentation](https://ethereum.org/en/developers/docs/gas/#base-fee). -### Priority Fee +### Priority fee Just like on Ethereum, OP Mainnet transactions can specify a **priority fee**. This priority fee is a price per unit of gas that is paid on top of the base fee. For example, if the block base fee is 1 gwei and the transaction specifies a priority fee of 1 gwei, the total price per unit of gas is 2 gwei. -The priority fee is an optional component of the execution gas fee and can be set to 0. +The priority fee(tip) is an optional component of the execution gas fee and can technically be set to 0. +However, while EIP-1559 does not define a minimum priority fee, certain wallets and mempool implementations (like Geth) may enforce a minimum value. For instance, Geth typically defaults to a minimum priority fee of 1 gwei, but this can be configured to other values. **The OP Mainnet sequencer will prioritize transactions with a higher priority fee** and execute them before any transactions with a lower priority fee. If transaction speed is important to your application, you may want to set a higher priority fee to ensure that your transaction is included more quickly. The [`eth_maxPriorityFeePerGas`](https://docs.alchemy.com/reference/eth-maxpriorityfeepergas) RPC method can be used to estimate a priority fee that will get your transaction included quickly. -## L1 Data Fee +## L1 data fee The L1 Data Fee is the only part of the OP Mainnet transaction fee that differs from the Ethereum transaction fee. This fee arises from the fact that the transaction data for all OP Mainnet transactions is published to Ethereum. @@ -210,7 +218,7 @@ The Sequencer Fee Vault collects and holds transaction fees paid to the sequence * **Vault Address**: The Sequencer Fee Vault is predeployed at the address `0x4200000000000000000000000000000000000011` on the OP Mainnet. * **Fee Usage**: Stored fees are eventually transferred to a designated recipient address (e.g., a treasury or distribution contract). -### How it Works +### How it works 1. **Fee Collection**: During the processing of transactions, the sequencer collects fees from users as part of their transaction costs. These fees are primarily used to cover the gas expenses of posting transaction data to Ethereum L1. 2. **Storage**: Collected fees are deposited into the Sequencer Fee Vault contract. @@ -218,7 +226,7 @@ The Sequencer Fee Vault collects and holds transaction fees paid to the sequence This system ensures effective fee management, maintaining the security and operation of the Optimism network. -## Next Steps +## Next steps * Read the [differences between Ethereum and OP Stack Chains](/stack/differences) guide. * Read the [L2 to L1 Transactions](/builders/app-developers/bridging/messaging#for-l1-to-l2-transactions) guide. diff --git a/pages/stack/transactions/forced-transaction.mdx b/pages/stack/transactions/forced-transaction.mdx new file mode 100644 index 000000000..bc293fd09 --- /dev/null +++ b/pages/stack/transactions/forced-transaction.mdx @@ -0,0 +1,73 @@ +--- +title: Forced transaction +lang: en-US +description: Learn the forced transaction flow during sequencer downtime. +--- + +import { Callout } from 'nextra/components' + +## Forced transaction flow + +This guide explains the nuances of forced transactions during sequencer downtime. + +Users are able to force-include deposit transactions, which can initiate withdrawals, at any time. +However, there are important nuances to understand about the chain derivation pipeline and sequencer behavior. + +## Key concepts + +* **Sequencing Window**: A 12-hour rolling window to include L2 transactions, including native L2 transactions and deposit transactions. +* **Max Time Drift**: 30 minutes, the maximum delay for including a deposit transaction, relative to the L2 chain. +* **Sequencer Downtime**: Period when the sequencer is offline or not producing blocks. + +## Normal operation + +Under normal circumstances: + +1. Deposit transactions are included within 30 minutes. +2. The sequencer processes transactions and produces blocks regularly. + +## Sequencer downtime scenarios + +### Short downtime (< 30 minutes) + +* Deposits are still included within the 30-minute max time drift. +* Regular L2 transactions may be delayed. + +### Extended downtime (30 minutes to 12 hours) + +1. Deposits are force-included within 30 minutes. +2. The L2 chain state remains uncertain until: + * The sequencer comes back online, or + * The 12-hour sequencing window expires. + +### Prolonged downtime (> 12 hours) + +1. After 12 hours, nodes start generating blocks deterministically. +2. These blocks only include deposit transactions. +3. When the sequencer returns: + * All deposit transactions are included first. + * No regular L2 transactions are included until the L2 chain is within 12 hours of the chain. + + + +## Important considerations + +* Forced transactions, through deposits (no need for deposited value), ensure timely execution of actions, mitigating risks like DEX price divergence during sequencer downtime. +* Actions remain speculative for up to 12 hours due to the sequencing window. +* The 12-hour window is a balance between operational reliability and minimizing potential L2 reorganizations. + +## Example scenario + +If a deposit is initiated after the 30-minute mark but before the sequencing window expires: + +1. The deposit will be effective when the sequencing window expires (up to ~11 hours later). +2. Nodes reading data from L1 will produce a block with the deposit after the sequencing window expires. +3. The eventual L2 chain will include the deposit in a block with an onchain timestamp close to the L1 block where the deposit originated. + + + The sequencing window is a rolling 12-hour delay from when an L1 block is first known. This design allows the sequencer a grace period to come back online without causing L2 chain reorganizations. + + +## Conclusion + +The forced transaction mechanism on OP Stack chains provides a robust way to handle sequencer downtime, ensuring that critical transactions are included in a timely manner. While the 12-hour sequencer window introduces a degree of uncertainty during downtime, the system is designed to guarantee eventual consistency and transaction inclusion. diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx new file mode 100644 index 000000000..5dd7d7528 --- /dev/null +++ b/pages/stack/transactions/transaction-finality.mdx @@ -0,0 +1,85 @@ +--- +title: Transaction finality +lang: en-US +description: Learn when transactions on OP Stack chains can be considered finalized. +--- + +import Image from 'next/image' +import { Callout } from 'nextra/components' + +# Transaction finality + +This guide explains when transactions on OP Stack chains are considered finalized and addresses common misconceptions about transaction finality on the OP Stack. + +## Basics of finality + +Transaction finality refers to the point at which a transaction becomes irreversible under certain assumptions. For example, Ethereum transactions are considered finalized when specific conditions in Ethereum's consensus mechanism are met. Many applications built on Ethereum rely on this property when making decisions, such as crediting a user's account after they deposit funds. + +## OP Stack finality + +OP Stack chains in the standard configuration are Rollups that use Ethereum's consensus mechanism to order and finalize transactions rather than running a separate consensus protocol. Therefore, OP Stack chains inherit Ethereum's ordering and finality properties. + +## Steps to finality + +Transactions on OP Stack chains go through the following process to reach finality: + +1. A user submits a transaction to the network, which forwards it to the Sequencer. +2. The Sequencer includes the transaction in a block and distributes it over a public peer-to-peer network. At this point, the transaction is considered **"unsafe"**, a technical term indicating that the transaction is in a block but its data has not yet been posted to Ethereum. This process typically takes a few seconds from transaction submission. +3. The Sequencer publishes this block's data to Ethereum, either as [blob data](https://www.eip4844.com/) or as calldata attached to a standard Ethereum transaction. Once included in an Ethereum block, the transaction is considered **"safe"**. This step usually takes 5–10 minutes from transaction submission. +4. The Ethereum block containing the Sequencer's transaction is finalized. At this point, the transaction reaches a **"finalized"** state. Ethereum finalization typically takes about 2 epochs (approximately 12.8 minutes from transaction submission) under normal network conditions, but may take longer during adverse conditions. Finality depends entirely on [Ethereum's consensus mechanism](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). + +```mermaid + +sequenceDiagram + participant User + participant Network + participant Sequencer + participant Ethereum + + User->>Network: Submit transaction + Network->>Sequencer: Forward transaction + Sequencer->>Sequencer: Include transaction in block + Sequencer->>Network: Distribute block over P2P network + Note right of Sequencer: Transaction status: "unsafe"
(block data not yet posted to Ethereum)
~a few seconds + + Sequencer->>Ethereum: Publish block data (as blob data
or calldata) + Note right of Ethereum: Transaction status: "safe"
(included in Ethereum block)
~5–10 minutes + + Ethereum->>Ethereum: Finalize block (~65 blocks or ~13 mins) + Note right of Ethereum: Transaction status: "finalized"
~13 minutes (may vary) + + +``` +## Common misconceptions + +### Transactions take 7 days to finalize + +A common misconception is that transactions on OP Stack chains take 7 days to finalize. **This is incorrect.** Transactions on OP Stack chains become finalized when their data is included in a finalized Ethereum block, typically around 20–30 minutes after submission. To reorg a finalized OP Stack chain transaction, a reorg of the corresponding Ethereum block would be required. + +This misconception often arises due to the OP Stack's Standard Bridge, which includes a 7-day delay on *withdrawals* of ETH and ERC-20 tokens. Withdrawing tokens from an OP Stack chain to Ethereum using the Standard Bridge requires a minimum 7-day wait. This delay affects only withdrawals through the Standard Bridge and does not impact transaction finality on the OP Stack chain. + +### Challenges in the Standard Bridge can cause a chain reorg + +Another misconception related to the belief that [finalization takes 7 days](#misconception-transactions-take-7-days-to-finalize) is that **Fault Proof challenges** created in response to withdrawals in the Standard Bridge can reorganize the OP Stack chain. **This is incorrect.** OP Stack transactions are not reorganized in response to Fault Proof challenges. + +The [Standard Bridge](/builders/app-developers/bridging/standard-bridge) is a bridge application that is included by default with any OP Stack chain and connects the chain to its "parent" blockchain (usually Ethereum). It offers a high level of security for ETH and ERC-20 tokens moved through the bridge. + +When using the Standard Bridge, users who send ETH or ERC-20 tokens to Ethereum must first burn those tokens on the OP Stack chain and then create a **withdrawal claim** on Ethereum. + +Because the Standard Bridge cannot immediately verify withdrawal claims, it delays the claim by 7 days to allow the OP Stack Fault Proof system to filter out any invalid claims. Challenges only remove bad claims without affecting the Standard Bridge or the OP Stack chain. + +### The Sequencer can always reorg the chain + +A common misconception is that the Sequencer can trigger reorganizations of the OP Stack chain at any time. However, while the Sequencer can reorganize **"unsafe"** blocks (not yet published to Ethereum), reorganizations become more challenging once blocks are **"safe"** and become effectively impossible once blocks are **"finalized."** + +* **Unsafe blocks:** The Sequencer can reorganize these blocks (typically within \~5–10 minutes). +* **Safe blocks:** The Sequencer would need to trigger a reorg on Ethereum itself, which is complex and unlikely. +* **Finalized blocks:** Once blocks are included in a finalized Ethereum block (typically after \~15–30 minutes), the Sequencer cannot reorganize them without compromising Ethereum's finality guarantees. + +### Ethereum reorgs cause OP Stack chain reorgs + +If Ethereum experiences a reorg, OP Stack chains will attempt a graceful recovery. OP Stack nodes will downgrade **"safe"** transactions to **"unsafe"** if needed, while the Sequencer republishes transaction data to maintain chain continuity. Although extreme Ethereum network conditions could potentially affect the OP Stack chain, **"finalized"** OP Stack transactions are protected from reorgs. + +## Conclusion + +Transaction finality on the OP Stack is simpler than it may seem. OP Stack chains inherit Ethereum's finality guarantees, so once a transaction is **"finalized,"** it cannot be reversed. diff --git a/pages/stack/protocol/rollup/transaction-flow.mdx b/pages/stack/transactions/transaction-flow.mdx similarity index 99% rename from pages/stack/protocol/rollup/transaction-flow.mdx rename to pages/stack/transactions/transaction-flow.mdx index 981a9e460..b076e5c4e 100644 --- a/pages/stack/protocol/rollup/transaction-flow.mdx +++ b/pages/stack/transactions/transaction-flow.mdx @@ -6,7 +6,7 @@ description: Learn the transaction flow process for rollup transactions. import { Callout } from 'nextra/components' -# Transaction Flow +# Transaction flow This guide explains the transaction flow process for rollup transactions. The process for a rollup transaction has two requirements. diff --git a/pages/stack/transactions/transactions.mdx b/pages/stack/transactions/transactions.mdx new file mode 100644 index 000000000..02d703c69 --- /dev/null +++ b/pages/stack/transactions/transactions.mdx @@ -0,0 +1,25 @@ +--- +title: Transactions +description: Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Transaction Flow, Withdrawal Flow in the Transactions section of the OP Stack ecosystem. +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# Transactions + +Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Transaction Flow, Withdrawal Flow in the Transactions section of the OP Stack ecosystem. + + + + + + + + + + + + + + diff --git a/pages/stack/protocol/rollup/withdrawal-flow.mdx b/pages/stack/transactions/withdrawal-flow.mdx similarity index 96% rename from pages/stack/protocol/rollup/withdrawal-flow.mdx rename to pages/stack/transactions/withdrawal-flow.mdx index dd2ae78b6..14cac6fce 100644 --- a/pages/stack/protocol/rollup/withdrawal-flow.mdx +++ b/pages/stack/transactions/withdrawal-flow.mdx @@ -1,12 +1,12 @@ --- -title: Withdrawal Flow +title: Withdrawal flow lang: en-US description: Learn the withdrawal flow process for transactions sent from L2 to L1. --- import { Callout } from 'nextra/components' -# Withdrawal Flow +# Withdrawal flow In Optimism terminology, a *withdrawal* is a transaction sent from L2 (OP Mainnet, OP Sepolia etc.) to L1 (Ethereum mainnet, Sepolia, etc.). @@ -79,27 +79,22 @@ The next step is to wait the fault challenge period, to ensure that the L2 outpu Finally, once the fault challenge period passes, the withdrawal can be finalized and executed on L1. -## Expected Internal Reverts in Withdrawal Transactions +## Expected internal reverts in withdrawal transactions During the withdrawal process, users may observe internal reverts when viewing the transaction on **Etherscan**. This is a common point of confusion but is expected behavior. These internal reverts often show up in yellow on the Etherscan UI and may cause concern that something went wrong with the transaction. However, these reverts occur due to the non-standard proxy used in Optimism, specifically the **Chugsplash Proxy**. The Chugsplash Proxy sometimes triggers internal calls that revert as part of the designed flow of the withdrawal process. -### Why Do These Reverts Happen? +### Why do these reverts happen? The Chugsplash Proxy operates differently than standard proxies. During a withdrawal transaction, it may trigger internal contract calls that result in reverts, but these reverts do not indicate that the withdrawal has failed. Instead, they are part of the internal logic of the system and are expected in certain scenarios. -### Key Takeaways: +### Key takeaways: * **Internal Reverts Are Expected**: These reverts are part of the normal operation of the Chugsplash Proxy during withdrawal transactions and do not represent an error. * **No Cause for Concern**: Although Etherscan highlights these reverts, they do not affect the final success of the transaction. * **User Assurance**: If you encounter these reverts during a withdrawal transaction, rest assured that the withdrawal will still finalize as expected. -For more information about the withdrawal process and how it works on Optimism, refer to the following resources: - -* [Smart Contracts Overview](https://docs.optimism.io/stack/protocol/rollup/smart-contracts) -* [Withdrawal Flow](https://docs.optimism.io/stack/protocol/rollup/withdrawal-flow#withdrawal-initiating-transaction) - ### Offchain processing 1. A user calls the SDK's [`CrossDomainMessenger.finalizeMessage()`](https://github.com/ethereum-optimism/optimism/blob/62c7f3b05a70027b30054d4c8974f44000606fb7/packages/sdk/src/cross-chain-messenger.ts#L1473-L1493) with the hash of the L1 message. diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml index 03596b6ff..408b01112 100644 --- a/pnpm-lock.yaml +++ b/pnpm-lock.yaml @@ -21,16 +21,16 @@ importers: dependencies: '@eth-optimism/contracts-ts': specifier: ^0.17.0 - version: 0.17.2(typescript@5.4.5)(zod@3.23.8) + version: 0.17.0(typescript@5.3.2)(zod@3.22.4) '@eth-optimism/tokenlist': specifier: ^9.0.9 - version: 9.0.51 + version: 9.0.9 '@feelback/react': specifier: ^0.3.4 - version: 0.3.4(react@18.3.1) + version: 0.3.4(react@18.2.0) '@headlessui/react': - specifier: ^2.1.0 - version: 2.1.0(react-dom@18.3.1(react@18.3.1))(react@18.3.1) + specifier: ^2.1.8 + version: 2.1.8(react-dom@18.2.0(react@18.2.0))(react@18.2.0) algoliasearch: specifier: ^4.23.3 version: 4.23.3 @@ -41,54 +41,57 @@ importers: specifier: ^5.0.0 version: 5.0.0 next: - specifier: 13.5.1 - version: 13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1) + specifier: 14.2.10 + version: 14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0) next-sitemap: specifier: ^4.2.3 - version: 4.2.3(next@13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1)) + version: 4.2.3(next@14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0)) nextra: specifier: 2.13.2 - version: 2.13.2(patch_hash=a4rp2hgojklggjmthmkiyqaek4)(next@13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1))(react-dom@18.3.1(react@18.3.1))(react@18.3.1) + version: 2.13.2(patch_hash=a4rp2hgojklggjmthmkiyqaek4)(next@14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0))(react-dom@18.2.0(react@18.2.0))(react@18.2.0) nextra-theme-docs: specifier: 2.13.2 - version: 2.13.2(next@13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1))(nextra@2.13.2(patch_hash=a4rp2hgojklggjmthmkiyqaek4)(next@13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1))(react-dom@18.3.1(react@18.3.1))(react@18.3.1))(react-dom@18.3.1(react@18.3.1))(react@18.3.1) + version: 2.13.2(next@14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0))(nextra@2.13.2(patch_hash=a4rp2hgojklggjmthmkiyqaek4)(next@14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0))(react-dom@18.2.0(react@18.2.0))(react@18.2.0))(react-dom@18.2.0(react@18.2.0))(react@18.2.0) react: specifier: ^18.2.0 - version: 18.3.1 + version: 18.2.0 react-dom: specifier: ^18.2.0 - version: 18.3.1(react@18.3.1) + version: 18.2.0(react@18.2.0) search-insights: specifier: ^2.15.0 version: 2.15.0 + viem: + specifier: ^2.21.18 + version: 2.21.37(typescript@5.3.2)(zod@3.22.4) devDependencies: '@double-great/remark-lint-alt-text': specifier: ^1.0.0 version: 1.0.0 '@eth-optimism/core-utils': specifier: ^0.13.1 - version: 0.13.2 + version: 0.13.1 '@eth-optimism/sdk': specifier: ^3.1.6 - version: 3.3.0(ethers@5.7.2) + version: 3.1.6(ethers@5.7.2) '@types/node': specifier: 18.11.10 version: 18.11.10 cspell: specifier: ^8.1.3 - version: 8.7.0 + version: 8.1.3 eslint: specifier: ^8.53.0 - version: 8.57.0 + version: 8.54.0 eslint-plugin-mdx: specifier: ^2.2.0 - version: 2.3.4(eslint@8.57.0) + version: 2.2.0(eslint@8.54.0) ethers: specifier: ^5 version: 5.7.2 globby: specifier: ^11.0.4 - version: 11.1.0 + version: 11.0.4 gray-matter: specifier: ^4.0.3 version: 4.0.3 @@ -133,7 +136,7 @@ importers: version: 6.1.3 typescript: specifier: ^5.2.2 - version: 5.4.5 + version: 5.3.2 unified-lint-rule: specifier: ^2.1.2 version: 2.1.2 @@ -143,9 +146,16 @@ importers: packages: + '@aashutoshrathi/word-wrap@1.2.6': + resolution: {integrity: sha512-1Yjs2SvM8TflER/OD3cOjhWWOZb58A2t7wpE2S9XfBYTiIl+XFhQG2bjy4Pu1I+EAlCNUzRDYDdFwFYUKvXcIA==} + engines: {node: '>=0.10.0'} + '@adraffy/ens-normalize@1.10.0': resolution: {integrity: sha512-nA9XHtlAkYfJxY7bce8DcN7eKxWWCWkU+1GR9d+U6MbNpfwQp8TI7vqOsBsMcHoT4mBu2kypKoSKnghEzOOq5Q==} + '@adraffy/ens-normalize@1.11.0': + resolution: {integrity: sha512-/3DDPKHqqIqxUULp8yP4zODUY1i+2xvVWsv8A79xGWdCAG+8sb0hRh0Rk2QyOJUnnbyPUAZYcpBuRe3nS2OIUg==} + '@algolia/cache-browser-local-storage@4.23.3': resolution: {integrity: sha512-vRHXYCpPlTDE7i6UOy2xE03zHF2C8MEFjPN2v7fRbqVpcOvAUQK81x3Kc21xyb5aSIpYCjWCZbYZuz8Glyzyyg==} @@ -195,20 +205,20 @@ packages: resolution: {integrity: sha512-g/VW9ZQEFJAOwAyUb8JFf7MLiLy2uEB4rU270rGzDwICxnxMlPy0O11KVePSgS36K1NI29gSlK84n5INGhd4Ag==} engines: {node: '>= 16'} - '@babel/code-frame@7.24.2': - resolution: {integrity: sha512-y5+tLQyV8pg3fsiln67BVLD1P13Eg4lh5RW9mF0zUuvLrv9uIQ4MCL+CRT+FTsBlBjcIan6PGsLcBN0m3ClUyQ==} + '@babel/code-frame@7.23.4': + resolution: {integrity: sha512-r1IONyb6Ia+jYR2vvIDhdWdlTGhqbBoFqLTQidzZ4kepUFH15ejXvFHxCVbtl7BOXIudsIubf4E81xeA3h3IXA==} engines: {node: '>=6.9.0'} '@babel/helper-validator-identifier@7.22.20': resolution: {integrity: sha512-Y4OZ+ytlatR8AI+8KZfKuL5urKp7qey08ha31L8b3BwewJAoJamTzyvxPR/5D+KkdJCGPq/+8TukHBlY10FX9A==} engines: {node: '>=6.9.0'} - '@babel/highlight@7.24.2': - resolution: {integrity: sha512-Yac1ao4flkTxTteCDZLEvdxg2fZfz1v8M4QpaGypq/WPDqg3ijHYbDfs+LG5hvzSoqaSZ9/Z9lKSP3CjZjv+pA==} + '@babel/highlight@7.23.4': + resolution: {integrity: sha512-acGdbYSfp2WheJoJm/EBBBLh/ID8KDc64ISZ9DYtBmC8/Q204PZJLHyzeB5qMzJ5trcOkybd78M4x2KWsUq++A==} engines: {node: '>=6.9.0'} - '@babel/runtime@7.24.4': - resolution: {integrity: sha512-dkxf7+hn8mFBwKjs9bvBlArzLVxVbS8usaPUDd5p2a9JCL9tB8OaOVN1isD4+Xyk4ns89/xeOmbQvgdK7IIVdA==} + '@babel/runtime@7.23.2': + resolution: {integrity: sha512-mM8eg4yl5D6i3lu2QKPuPH4FArvJ8KhTofbE7jwMUv9KX5mBvwPAqnV3MlyBNqdp9RyRKP6Yck8TrfYrPvX3bg==} engines: {node: '>=6.9.0'} '@braintree/sanitize-url@6.0.4': @@ -217,47 +227,47 @@ packages: '@corex/deepmerge@4.0.43': resolution: {integrity: sha512-N8uEMrMPL0cu/bdboEWpQYb/0i2K5Qn8eCsxzOmxSggJbbQte7ljMRoXm917AbntqTGOzdTu+vP3KOOzoC70HQ==} - '@cspell/cspell-bundled-dicts@8.7.0': - resolution: {integrity: sha512-B5YQI7Dd9m0JHTmHgs7PiyP4BWXzl8ixpK+HGOwhxzh7GyfFt1Eo/gxMxBDX/9SaewEzeb2OjRpRKEFtEsto3A==} + '@cspell/cspell-bundled-dicts@8.1.3': + resolution: {integrity: sha512-TwLyL2bCtetXGhMudjOIgFPAsWF2UkT0E7T+DAZG8aUBfHoC/eco/sTmR6UJVpi6Crjs0YOQkFUBGrQ2pxJPcA==} engines: {node: '>=18'} - '@cspell/cspell-json-reporter@8.7.0': - resolution: {integrity: sha512-LTQPEvXvCqnc+ok9WXpSISZyt4/nGse9fVEM430g0BpGzKpt3RMx49B8uasvvnanzCuikaW9+wFLmwgvraERhA==} + '@cspell/cspell-json-reporter@8.1.3': + resolution: {integrity: sha512-9iOU0Y733XuF0cqC7xwzJkOKFdJ65rYGnHFdUHzr5lxEqeG9X/jhlkzyHuGGOhPxkUeFP1x9XoLhXo1isMDbKA==} engines: {node: '>=18'} - '@cspell/cspell-pipe@8.7.0': - resolution: {integrity: sha512-ePqddIQ4arqPQgOkC146SkZxvZb9/jL7xIM5Igy2n3tiWTC5ijrX/mbHpPZ1VGcFck+1M0cJUuyhuJk+vMj3rg==} + '@cspell/cspell-pipe@8.1.3': + resolution: {integrity: sha512-/dcnyLDeyFuoX4seZv7VsDQyRpt3ZY0vjZiDpqFul8hPydM8czLyRPPMD6Za+Gqg6dZmh9+VsQWK52hVsqc0QA==} engines: {node: '>=18'} - '@cspell/cspell-resolver@8.7.0': - resolution: {integrity: sha512-grZwDFYqcBYQDaz4AkUtdyqc4UUH2J3/7yWVkBbYDPE+FQHa9ofFXzXxyjs56GJlPfi9ULpe5/Wz6uVLg8rQkQ==} + '@cspell/cspell-resolver@8.1.3': + resolution: {integrity: sha512-bGyJYqkHRilqhyKGL/NvODN5U+UvCuQo7kxgt0i3Vd7m7k6XYLsSLYZ4w6r1S5IQ/ybU8I5lh6/6fNqKwvo9eg==} engines: {node: '>=18'} - '@cspell/cspell-service-bus@8.7.0': - resolution: {integrity: sha512-KW48iu0nTDzbedixc7iB7K7mlAZQ7QeMLuM/akxigOlvtOdVJrRa9Pfn44lwejts1ANb/IXil3GH8YylkVi76Q==} + '@cspell/cspell-service-bus@8.1.3': + resolution: {integrity: sha512-8E5ZveQKneNfK+cuFMy0y6tDsho71UPppEHNoLZsEFDbIxDdtQcAfs0pk4nwEzxPBt+dBB+Yl8KExQ6x2FAYQw==} engines: {node: '>=18'} - '@cspell/cspell-types@8.7.0': - resolution: {integrity: sha512-Rb+LCE5I9JEb/LE8nSViVSF8z1CWv/z4mPBIG37VMa7aUx2gAQa6gJekNfpY9YZiMzx4Tv3gDujN80ytks4pGA==} + '@cspell/cspell-types@8.1.3': + resolution: {integrity: sha512-j14FENj+DzWu6JjzTl+0X5/OJv9AEckpEp6Jaw9YglxirrBBzTkZGfoLePe/AWo/MlIYp0asl92C1UHEjgz+FQ==} engines: {node: '>=18'} '@cspell/dict-ada@4.0.2': resolution: {integrity: sha512-0kENOWQeHjUlfyId/aCM/mKXtkEgV0Zu2RhUXCBr4hHo9F9vph+Uu8Ww2b0i5a4ZixoIkudGA+eJvyxrG1jUpA==} - '@cspell/dict-aws@4.0.1': - resolution: {integrity: sha512-NXO+kTPQGqaaJKa4kO92NAXoqS+i99dQzf3/L1BxxWVSBS3/k1f3uhmqIh7Crb/n22W793lOm0D9x952BFga3Q==} + '@cspell/dict-aws@4.0.0': + resolution: {integrity: sha512-1YkCMWuna/EGIDN/zKkW+j98/55mxigftrSFgsehXhPld+ZMJM5J9UuBA88YfL7+/ETvBdd7mwW6IwWsC+/ltQ==} '@cspell/dict-bash@4.1.3': resolution: {integrity: sha512-tOdI3QVJDbQSwPjUkOiQFhYcu2eedmX/PtEpVWg0aFps/r6AyjUQINtTgpqMYnYuq8O1QUIQqnpx21aovcgZCw==} - '@cspell/dict-companies@3.0.31': - resolution: {integrity: sha512-hKVpV/lcGKP4/DpEPS8P4osPvFH/YVLJaDn9cBIOH6/HSmL5LbFgJNKpMGaYRbhm2FEX56MKE3yn/MNeNYuesQ==} + '@cspell/dict-companies@3.0.28': + resolution: {integrity: sha512-UinHkMYB/1pUkLKm1PGIm9PBFYxeAa6YvbB1Rq/RAAlrs0WDwiDBr3BAYdxydukG1IqqwT5z9WtU+8D/yV/5lw==} - '@cspell/dict-cpp@5.1.3': - resolution: {integrity: sha512-sqnriXRAInZH9W75C+APBh6dtben9filPqVbIsiRMUXGg+s02ekz0z6LbS7kXeJ5mD2qXoMLBrv13qH2eIwutQ==} + '@cspell/dict-cpp@5.0.10': + resolution: {integrity: sha512-WCRuDrkFdpmeIR6uXQYKU9loMQKNFS4bUhtHdv5fu4qVyJSh3k/kgmtTm1h1BDTj8EwPRc/RGxS+9Z3b2mnabA==} - '@cspell/dict-cryptocurrencies@5.0.0': - resolution: {integrity: sha512-Z4ARIw5+bvmShL+4ZrhDzGhnc9znaAGHOEMaB/GURdS/jdoreEDY34wdN0NtdLHDO5KO7GduZnZyqGdRoiSmYA==} + '@cspell/dict-cryptocurrencies@4.0.0': + resolution: {integrity: sha512-EiZp91ATyRxTmauIQfOX9adLYCunKjHEh092rrM7o2eMXP9n7zpXAL9BK7LviL+LbB8VDOm21q+s83cKrrRrsg==} '@cspell/dict-csharp@4.0.2': resolution: {integrity: sha512-1JMofhLK+4p4KairF75D3A924m5ERMgd1GvzhwK2geuYgd2ZKuGW72gvXpIV7aGf52E3Uu1kDXxxGAiZ5uVG7g==} @@ -283,14 +293,14 @@ packages: '@cspell/dict-elixir@4.0.3': resolution: {integrity: sha512-g+uKLWvOp9IEZvrIvBPTr/oaO6619uH/wyqypqvwpmnmpjcfi8+/hqZH8YNKt15oviK8k4CkINIqNhyndG9d9Q==} - '@cspell/dict-en-common-misspellings@2.0.0': - resolution: {integrity: sha512-NOg8dlv37/YqLkCfBs5OXeJm/Wcfb/CzeOmOZJ2ZXRuxwsNuolb4TREUce0yAXRqMhawahY5TSDRJJBgKjBOdw==} + '@cspell/dict-en-common-misspellings@1.0.2': + resolution: {integrity: sha512-jg7ZQZpZH7+aAxNBlcAG4tGhYF6Ksy+QS5Df73Oo+XyckBjC9QS+PrRwLTeYoFIgXy5j3ICParK5r3MSSoL4gw==} '@cspell/dict-en-gb@1.1.33': resolution: {integrity: sha512-tKSSUf9BJEV+GJQAYGw5e+ouhEe2ZXE620S7BLKe3ZmpnjlNG9JqlnaBhkIMxKnNFkLY2BP/EARzw31AZnOv4g==} - '@cspell/dict-en_us@4.3.19': - resolution: {integrity: sha512-tHcXdkmm0t9LlRct1vgu3+h0KW/wlXCInkTiR4D/rl730q1zu2qVEgiy1saMiTUSNmdu7Hiy+Mhb+1braVqnZQ==} + '@cspell/dict-en_us@4.3.12': + resolution: {integrity: sha512-1bsUxFjgxF30FTzcU5uvmCvH3lyqVKR9dbwsJhomBlUM97f0edrd6590SiYBXDm7ruE68m3lJd4vs0Ev2D6FtQ==} '@cspell/dict-filetypes@3.0.3': resolution: {integrity: sha512-J9UP+qwwBLfOQ8Qg9tAsKtSY/WWmjj21uj6zXTI9hRLD1eG1uUOLcfVovAmtmVqUWziPSKMr87F6SXI3xmJXgw==} @@ -304,11 +314,11 @@ packages: '@cspell/dict-fullstack@3.1.5': resolution: {integrity: sha512-6ppvo1dkXUZ3fbYn/wwzERxCa76RtDDl5Afzv2lijLoijGGUw5yYdLBKJnx8PJBGNLh829X352ftE7BElG4leA==} - '@cspell/dict-gaming-terms@1.0.5': - resolution: {integrity: sha512-C3riccZDD3d9caJQQs1+MPfrUrQ+0KHdlj9iUR1QD92FgTOF6UxoBpvHUUZ9YSezslcmpFQK4xQQ5FUGS7uWfw==} + '@cspell/dict-gaming-terms@1.0.4': + resolution: {integrity: sha512-hbDduNXlk4AOY0wFxcDMWBPpm34rpqJBeqaySeoUH70eKxpxm+dvjpoRLJgyu0TmymEICCQSl6lAHTHSDiWKZg==} - '@cspell/dict-git@3.0.0': - resolution: {integrity: sha512-simGS/lIiXbEaqJu9E2VPoYW1OTC2xrwPPXNXFMa2uo/50av56qOuaxDrZ5eH1LidFXwoc8HROCHYeKoNrDLSw==} + '@cspell/dict-git@2.0.0': + resolution: {integrity: sha512-n1AxyX5Kgxij/sZFkxFJlzn3K9y/sCcgVPg/vz4WNJ4K9YeTsUmyGLA2OQI7d10GJeiuAo2AP1iZf2A8j9aj2w==} '@cspell/dict-golang@6.0.5': resolution: {integrity: sha512-w4mEqGz4/wV+BBljLxduFNkMrd3rstBNDXmoX5kD4UTzIb4Sy0QybWCtg2iVT+R0KWiRRA56QKOvBsgXiddksA==} @@ -325,9 +335,6 @@ packages: '@cspell/dict-java@5.0.6': resolution: {integrity: sha512-kdE4AHHHrixyZ5p6zyms1SLoYpaJarPxrz8Tveo6gddszBVVwIUZ+JkQE1bWNLK740GWzIXdkznpUfw1hP9nXw==} - '@cspell/dict-julia@1.0.1': - resolution: {integrity: sha512-4JsCLCRhhLMLiaHpmR7zHFjj1qOauzDI5ZzCNQS31TUMfsOo26jAKDfo0jljFAKgw5M2fEG7sKr8IlPpQAYrmQ==} - '@cspell/dict-k8s@1.0.2': resolution: {integrity: sha512-tLT7gZpNPnGa+IIFvK9SP1LrSpPpJ94a/DulzAPOb1Q2UBFwdpFd82UWhio0RNShduvKG/WiMZf/wGl98pn+VQ==} @@ -343,44 +350,41 @@ packages: '@cspell/dict-makefile@1.0.0': resolution: {integrity: sha512-3W9tHPcSbJa6s0bcqWo6VisEDTSN5zOtDbnPabF7rbyjRpNo0uHXHRJQF8gAbFzoTzBBhgkTmrfSiuyQm7vBUQ==} - '@cspell/dict-monkeyc@1.0.6': - resolution: {integrity: sha512-oO8ZDu/FtZ55aq9Mb67HtaCnsLn59xvhO/t2mLLTHAp667hJFxpp7bCtr2zOrR1NELzFXmKln/2lw/PvxMSvrA==} - '@cspell/dict-node@4.0.3': resolution: {integrity: sha512-sFlUNI5kOogy49KtPg8SMQYirDGIAoKBO3+cDLIwD4MLdsWy1q0upc7pzGht3mrjuyMiPRUV14Bb0rkVLrxOhg==} - '@cspell/dict-npm@5.0.15': - resolution: {integrity: sha512-sX0X5YWNW54F4baW7b5JJB6705OCBIZtUqjOghlJNORS5No7QY1IX1zc5FxNNu4gsaCZITAmfMi4ityXEsEThA==} + '@cspell/dict-npm@5.0.13': + resolution: {integrity: sha512-uPb3DlQA/FvlmzT5RjZoy7fy91mxMRZW1B+K3atVM5A/cmP1QlDaSW/iCtde5kHET1MOV7uxz+vy0Yha2OI5pQ==} - '@cspell/dict-php@4.0.6': - resolution: {integrity: sha512-ySAXisf7twoVFZqBV2o/DKiCLIDTHNqfnj0EfH9OoOUR7HL3rb6zJkm0viLUFDO2G/8SyIi6YrN/6KX+Scjjjg==} + '@cspell/dict-php@4.0.4': + resolution: {integrity: sha512-fRlLV730fJbulDsLIouZxXoxHt3KIH6hcLFwxaupHL+iTXDg0lo7neRpbqD5MScr/J3idEr7i9G8XWzIikKFug==} '@cspell/dict-powershell@5.0.3': resolution: {integrity: sha512-lEdzrcyau6mgzu1ie98GjOEegwVHvoaWtzQnm1ie4DyZgMr+N6D0Iyj1lzvtmt0snvsDFa5F2bsYzf3IMKcpcA==} - '@cspell/dict-public-licenses@2.0.6': - resolution: {integrity: sha512-bHqpSpJvLCUcWxj1ov/Ki8WjmESpYwRpQlqfdchekOTc93Huhvjm/RXVN1R4fVf4Hspyem1QVkCGqAmjJMj6sw==} + '@cspell/dict-public-licenses@2.0.5': + resolution: {integrity: sha512-91HK4dSRri/HqzAypHgduRMarJAleOX5NugoI8SjDLPzWYkwZ1ftuCXSk+fy8DLc3wK7iOaFcZAvbjmnLhVs4A==} - '@cspell/dict-python@4.1.11': - resolution: {integrity: sha512-XG+v3PumfzUW38huSbfT15Vqt3ihNb462ulfXifpQllPok5OWynhszCLCRQjQReV+dgz784ST4ggRxW452/kVg==} + '@cspell/dict-python@4.1.10': + resolution: {integrity: sha512-ErF/Ohcu6Xk4QVNzFgo8p7CxkxvAKAmFszvso41qOOhu8CVpB35ikBRpGVDw9gsCUtZzi15Yl0izi4do6WcLkA==} '@cspell/dict-r@2.0.1': resolution: {integrity: sha512-KCmKaeYMLm2Ip79mlYPc8p+B2uzwBp4KMkzeLd5E6jUlCL93Y5Nvq68wV5fRLDRTf7N1LvofkVFWfDcednFOgA==} - '@cspell/dict-ruby@5.0.2': - resolution: {integrity: sha512-cIh8KTjpldzFzKGgrqUX4bFyav5lC52hXDKo4LbRuMVncs3zg4hcSf4HtURY+f2AfEZzN6ZKzXafQpThq3dl2g==} + '@cspell/dict-ruby@5.0.1': + resolution: {integrity: sha512-rruTm7Emhty/BSYavSm8ZxRuVw0OBqzJkwIFXcV0cX7To8D1qbmS9HFHRuRg8IL11+/nJvtdDz+lMFBSmPUagQ==} - '@cspell/dict-rust@4.0.2': - resolution: {integrity: sha512-RhziKDrklzOntxAbY3AvNR58wnFGIo3YS8+dNeLY36GFuWOvXDHFStYw5Pod4f/VXbO/+1tXtywCC4zWfB2p1w==} + '@cspell/dict-rust@4.0.1': + resolution: {integrity: sha512-xJSSzHDK2z6lSVaOmMxl3PTOtfoffaxMo7fTcbZUF+SCJzfKbO6vnN9TCGX2sx1RHFDz66Js6goz6SAZQdOwaw==} '@cspell/dict-scala@5.0.0': resolution: {integrity: sha512-ph0twaRoV+ylui022clEO1dZ35QbeEQaKTaV2sPOsdwIokABPIiK09oWwGK9qg7jRGQwVaRPEq0Vp+IG1GpqSQ==} - '@cspell/dict-software-terms@3.3.20': - resolution: {integrity: sha512-KmPwCxYWEu7SGyT/0m/n6i6R4ZgxbmN3XcerzA6Z629Wm5iZTVfJaMWqDK2RKAyBawS7OMfxGz0W/wYU4FhJlA==} + '@cspell/dict-software-terms@3.3.12': + resolution: {integrity: sha512-6aa4T9VqOMc0SFNBt6gxp0CWjvRqMg/uxvgpRbil+ToHWcU+Q+As0WKhPLaOniuTdCM85WWzRouD0O1XUGqg5Q==} - '@cspell/dict-sql@2.1.3': - resolution: {integrity: sha512-SEyTNKJrjqD6PAzZ9WpdSu6P7wgdNtGV2RV8Kpuw1x6bV+YsSptuClYG+JSdRExBTE6LwIe1bTklejUp3ZP8TQ==} + '@cspell/dict-sql@2.1.2': + resolution: {integrity: sha512-Pi0hAcvsSGtZZeyyAN1VfGtQJbrXos5x2QjJU0niAQKhmITSOrXU/1II1Gogk+FYDjWyV9wP2De0U2f7EWs6oQ==} '@cspell/dict-svelte@1.0.2': resolution: {integrity: sha512-rPJmnn/GsDs0btNvrRBciOhngKV98yZ9SHmg8qI6HLS8hZKvcXc0LMsf9LLuMK1TmS2+WQFAan6qeqg6bBxL2Q==} @@ -388,21 +392,18 @@ packages: '@cspell/dict-swift@2.0.1': resolution: {integrity: sha512-gxrCMUOndOk7xZFmXNtkCEeroZRnS2VbeaIPiymGRHj5H+qfTAzAKxtv7jJbVA3YYvEzWcVE2oKDP4wcbhIERw==} - '@cspell/dict-terraform@1.0.0': - resolution: {integrity: sha512-Ak+vy4HP/bOgzf06BAMC30+ZvL9mzv21xLM2XtfnBLTDJGdxlk/nK0U6QT8VfFLqJ0ZZSpyOxGsUebWDCTr/zQ==} - - '@cspell/dict-typescript@3.1.4': - resolution: {integrity: sha512-jUcPa0rsPca5ur1+G56DXnSc5hbbJkzvPHHvyQtkbPXBQd3CXPMNfrTVCgzex/7cY/7FONcpFCUwgwfni9Jqbw==} + '@cspell/dict-typescript@3.1.2': + resolution: {integrity: sha512-lcNOYWjLUvDZdLa0UMNd/LwfVdxhE9rKA+agZBGjL3lTA3uNvH7IUqSJM/IXhJoBpLLMVEOk8v1N9xi+vDuCdA==} '@cspell/dict-vue@3.0.0': resolution: {integrity: sha512-niiEMPWPV9IeRBRzZ0TBZmNnkK3olkOPYxC1Ny2AX4TGlYRajcW0WUtoSHmvvjZNfWLSg2L6ruiBeuPSbjnG6A==} - '@cspell/dynamic-import@8.7.0': - resolution: {integrity: sha512-xlEPdiHVDu+4xYkvwjL9MgklxOi9XB+Pr1H9s3Ww9WEq+q6BA3xOHxLIU/k8mhqFTMZGFZRCsdy/EwMu6SyRhQ==} + '@cspell/dynamic-import@8.1.3': + resolution: {integrity: sha512-/lXFLa92v4oOcZ2PbdRpOqBvnqWlYmGaV7iCy8+QhIWlMdzi+7tBX3LVTm9Jzvt/rJseVHQQ6RvfTsSmhbUMFQ==} engines: {node: '>=18.0'} - '@cspell/strong-weak-map@8.7.0': - resolution: {integrity: sha512-0bo0WwDr2lzGoCP7vbpWbDpPyuOrHKK+218txnUpx6Pn1EDBLfcDQsiZED5B6zlpwgbGi6y3vc0rWtJbjKvwzg==} + '@cspell/strong-weak-map@8.1.3': + resolution: {integrity: sha512-GhWyximzk8tumo0zhrDV3+nFYiETYefiTBWAEVbXJMibuvitFocVZwddqN85J0UdZ2M7q6tvBleEaI9ME/16gA==} engines: {node: '>=18'} '@double-great/alt-text@3.1.0': @@ -421,22 +422,22 @@ packages: resolution: {integrity: sha512-Cu96Sd2By9mCNTx2iyKOmq10v22jUVQv0lQnlGNy16oE9589yE+QADPbrMGCkA51cKZSg3Pu/aTJVTGfL/qjUA==} engines: {node: ^12.0.0 || ^14.0.0 || >=16.0.0} - '@eslint/eslintrc@2.1.4': - resolution: {integrity: sha512-269Z39MS6wVJtsoUl10L60WdkhJVdPG24Q4eZTH3nnF6lpvSShEK3wQjDX9JRWAUPvPh7COouPpU9IrqaZFvtQ==} + '@eslint/eslintrc@2.1.3': + resolution: {integrity: sha512-yZzuIG+jnVu6hNSzFEN07e8BxF3uAzYtQb6uDkaYZLo6oYZDCq454c5kB8zxnzfCYyP4MIuyBn10L0DqwujTmA==} engines: {node: ^12.22.0 || ^14.17.0 || >=16.0.0} - '@eslint/js@8.57.0': - resolution: {integrity: sha512-Ys+3g2TaW7gADOJzPt83SJtCDhMjndcDMFVQ/Tj9iA1BfJzFKD9mAUXT3OenpuPHbI6P/myECxRJrofUsDx/5g==} + '@eslint/js@8.54.0': + resolution: {integrity: sha512-ut5V+D+fOoWPgGGNj83GGjnntO39xDy6DWxO0wb7Jp3DcMX0TfIqdzHF85VTQkerdyGmuuMD9AKAo5KiNlf/AQ==} engines: {node: ^12.22.0 || ^14.17.0 || >=16.0.0} - '@eth-optimism/contracts-bedrock@0.17.2': - resolution: {integrity: sha512-YVwPHpBZgFwFX9qY8+iToVAAH7mSnVIVmih+YfHhqjAhlLvLZfYjvj+hRNgcB9eRyl1SOOB0jevp4JOOV1v2BA==} + '@eth-optimism/contracts-bedrock@0.16.2': + resolution: {integrity: sha512-a2+f7soDbrd6jV74U02EpyMwQt2iZeDZ4c2ZwgkObcxXUZLZQ2ELt/VRFBf8TIL3wYcBOGpUa1aXAE2oHQ7oRA==} - '@eth-optimism/contracts-ts@0.17.2': - resolution: {integrity: sha512-5aM+pn1uK8Hx9r9+PHCF6NQTYKVHmrm7Gc7LQ6sO9MQItVP1WdIWNcQYT7TQhkxGKHYG2arF06rbHGeGNqzBeg==} + '@eth-optimism/contracts-ts@0.17.0': + resolution: {integrity: sha512-V4uJtS4ngAQ8tLSeIHWAK7ZNrz3a5Mf4YN3vf5U3u2/c+bKWIkGYgmD/GPQuyMmALOv67tJpFn3GRDTb9LgG1g==} peerDependencies: - '@wagmi/core': ^2.6.3 - wagmi: ^2.5.5 + '@wagmi/core': '>1.0.0' + wagmi: '>1.0.0' peerDependenciesMeta: '@wagmi/core': optional: true @@ -451,16 +452,16 @@ packages: '@eth-optimism/core-utils@0.12.0': resolution: {integrity: sha512-qW+7LZYCz7i8dRa7SRlUKIo1VBU8lvN0HeXCxJR+z+xtMzMQpPds20XJNCMclszxYQHkXY00fOT6GvFw9ZL6nw==} - '@eth-optimism/core-utils@0.13.2': - resolution: {integrity: sha512-u7TOKm1RxH1V5zw7dHmfy91bOuEAZU68LT/9vJPkuWEjaTl+BgvPDRDTurjzclHzN0GbWdcpOqPZg4ftjkJGaw==} + '@eth-optimism/core-utils@0.13.1': + resolution: {integrity: sha512-1FvzbUmCEy9zSKPG1QWg2VfA2Cy90xBA9Wkp11lXXrz91zUPCNCNSRTujXWYIC86ketNsZp7p4njSf6lTycHCw==} - '@eth-optimism/sdk@3.3.0': - resolution: {integrity: sha512-0Wt9roWe3itdzp08caCQLoFqhmT47ssquKAzBe7yXI6saVL+f2vWl6VgEaq0aYe2FsWvD9L0tSAJHLx1FiquNw==} + '@eth-optimism/sdk@3.1.6': + resolution: {integrity: sha512-YU3Sx4jPFfdXW4gs0PvnFDFPrJjbsaFxAJrsqxDpkUH3fMC3MmQgECYdkj8y1xTO6CTHm9gWLNC2WQdYTdNJsQ==} peerDependencies: ethers: ^5 - '@eth-optimism/tokenlist@9.0.51': - resolution: {integrity: sha512-GfKk4euEfNLniyRisP7sB/N9Kp96M+2t529mkvwC6nXITouzH4faDP8JdtwU6AOcgC4UlrFjXJ9w8ecnWWNQbw==} + '@eth-optimism/tokenlist@9.0.9': + resolution: {integrity: sha512-Wz0ZbvJKBUIikZpAjX1dqXYlSq0mHCnVXfGST+rZOhpCnY9Qwf9PEpSEK9kMeUz2ySDVV1mqtXtLgVjZb6z3Pg==} '@ethereumjs/rlp@4.0.1': resolution: {integrity: sha512-tqsQiBQDQdmPWE1xkkBq4rlSW5QZpLOUJ5RJh2/9fug+q9tnUhuZoVLk7s0scUIKTOzEtR72DFBXI4WiZcMpvw==} @@ -570,53 +571,51 @@ packages: peerDependencies: react: '>=17' - '@floating-ui/core@1.6.2': - resolution: {integrity: sha512-+2XpQV9LLZeanU4ZevzRnGFg2neDeKHgFLjP6YLW+tly0IvrhqT4u8enLGjLH3qeh85g19xY5rsAusfwTdn5lg==} + '@floating-ui/core@1.6.8': + resolution: {integrity: sha512-7XJ9cPU+yI2QeLS+FCSlqNFZJq8arvswefkZrYI1yQBbftw6FyrZOxYSh+9S7z7TpeWlRt9zJ5IhM1WIL334jA==} - '@floating-ui/dom@1.6.5': - resolution: {integrity: sha512-Nsdud2X65Dz+1RHjAIP0t8z5e2ff/IRbei6BqFrl1urT8sDVzM1HMQ+R0XcU5ceRfyO3I6ayeqIfh+6Wb8LGTw==} + '@floating-ui/dom@1.6.11': + resolution: {integrity: sha512-qkMCxSR24v2vGkhYDo/UzxfJN3D4syqSjyuTFz6C7XcpU1pASPRieNI0Kj5VP3/503mOfYiGY891ugBX1GlABQ==} - '@floating-ui/react-dom@2.1.0': - resolution: {integrity: sha512-lNzj5EQmEKn5FFKc04+zasr09h/uX8RtJRNj5gUXsSQIXHVWTVh+hVAg1vOMCexkX8EgvemMvIFpQfkosnVNyA==} + '@floating-ui/react-dom@2.1.2': + resolution: {integrity: sha512-06okr5cgPzMNBy+Ycse2A6udMi4bqwW/zgBF/rwjcNqWkyr82Mcg8b0vjX8OJpZFy/FKjJmw6wV7t44kK6kW7A==} peerDependencies: react: '>=16.8.0' react-dom: '>=16.8.0' - '@floating-ui/react@0.26.17': - resolution: {integrity: sha512-ESD+jYWwqwVzaIgIhExrArdsCL1rOAzryG/Sjlu8yaD3Mtqi3uVyhbE2V7jD58Mo52qbzKz2eUY/Xgh5I86FCQ==} + '@floating-ui/react@0.26.25': + resolution: {integrity: sha512-hZOmgN0NTOzOuZxI1oIrDu3Gcl8WViIkvPMpB4xdd4QD6xAMtwgwr3VPoiyH/bLtRcS1cDnhxLSD1NsMJmwh/A==} peerDependencies: react: '>=16.8.0' react-dom: '>=16.8.0' - '@floating-ui/utils@0.2.2': - resolution: {integrity: sha512-J4yDIIthosAsRZ5CPYP/jQvUAQtlZTTD/4suA08/FEnlxqW3sKS9iAhgsa9VYLZ6vDHn/ixJgIqRQPotoBjxIw==} + '@floating-ui/utils@0.2.8': + resolution: {integrity: sha512-kym7SodPp8/wloecOpcmSnWJsK7M0E5Wg8UcFA+uO4B9s5d0ywXOEro/8HM9x0rW+TljRzul/14UYz3TleT3ig==} - '@headlessui/react@1.7.19': - resolution: {integrity: sha512-Ll+8q3OlMJfJbAKM/+/Y2q6PPYbryqNTXDbryx7SXLIDamkF6iQFbriYHga0dY44PvDhvvBWCx1Xj4U5+G4hOw==} + '@headlessui/react@1.7.17': + resolution: {integrity: sha512-4am+tzvkqDSSgiwrsEpGWqgGo9dz8qU5M3znCkC4PgkpY4HcCZzEDEvozltGGGHIKl9jbXbZPSH5TWn4sWJdow==} engines: {node: '>=10'} peerDependencies: react: ^16 || ^17 || ^18 react-dom: ^16 || ^17 || ^18 - '@headlessui/react@2.1.0': - resolution: {integrity: sha512-/MizQk2xqR5ELkmCI1xWy3VgJULvR8gcAXtZhcK7sY53TNRCPeMdeODEXKSv9LPSSRlEAyzW1+NGJiaXq6dLRw==} + '@headlessui/react@2.1.8': + resolution: {integrity: sha512-uajqVkAcVG/wHwG9Fh5PFMcFpf2VxM4vNRNKxRjuK009kePVur8LkuuygHfIE+2uZ7z7GnlTtYsyUe6glPpTLg==} engines: {node: '>=10'} peerDependencies: react: ^18 react-dom: ^18 - '@humanwhocodes/config-array@0.11.14': - resolution: {integrity: sha512-3T8LkOmg45BV5FICb15QQMsyUSWrQ8AygVfC7ZG32zOalnqrilm018ZVCw0eapXux8FtA33q8PSRSstjee3jSg==} + '@humanwhocodes/config-array@0.11.13': + resolution: {integrity: sha512-JSBDMiDKSzQVngfRjOdFXgFfklaXI4K9nLF49Auh21lmBWRLIK3+xTErTWD4KU54pb6coM6ESE7Awz/FNU3zgQ==} engines: {node: '>=10.10.0'} - deprecated: Use @eslint/config-array instead '@humanwhocodes/module-importer@1.0.1': resolution: {integrity: sha512-bxveV4V8v5Yb4ncFTT3rPSgZBOpCkjfK0y4oVVVJwIuDVBRMDXrPyXRL988i5ap9m9bnyEEjWfm5WkBmtffLfA==} engines: {node: '>=12.22'} - '@humanwhocodes/object-schema@2.0.3': - resolution: {integrity: sha512-93zYdMES/c1D69yZiKDBj0V24vqNzB/koF26KPaagAfd3P/4gUlh3Dys5ogAK+Exi9QyzlD8x/08Zt7wIKcDcA==} - deprecated: Use @eslint/object-schema instead + '@humanwhocodes/object-schema@2.0.1': + resolution: {integrity: sha512-dvuCeX5fC9dXgJn9t+X5atfmgQAzUOWqS1254Gh0m6i8wKd10ebXkfNKiRK+1GWi/yTvvLDHpoxLr0xxxeslWw==} '@isaacs/cliui@8.0.2': resolution: {integrity: sha512-O8jcjabXaleOG9DQ0+ARXWZBTfnP4WNAqzuiJK7ll44AmxGKv/J2M4TPjxjY3znBCfvBXFzucm1twdyFybFqEA==} @@ -633,153 +632,157 @@ packages: peerDependencies: react: '>=16' - '@napi-rs/simple-git-android-arm-eabi@0.1.16': - resolution: {integrity: sha512-dbrCL0Pl5KZG7x7tXdtVsA5CO6At5ohDX3myf5xIYn9kN4jDFxsocl8bNt6Vb/hZQoJd8fI+k5VlJt+rFhbdVw==} + '@napi-rs/simple-git-android-arm-eabi@0.1.9': + resolution: {integrity: sha512-9D4JnfePMpgL4pg9aMUX7/TIWEUQ+Tgx8n3Pf8TNCMGjUbImJyYsDSLJzbcv9wH7srgn4GRjSizXFJHAPjzEug==} engines: {node: '>= 10'} cpu: [arm] os: [android] - '@napi-rs/simple-git-android-arm64@0.1.16': - resolution: {integrity: sha512-xYz+TW5J09iK8SuTAKK2D5MMIsBUXVSs8nYp7HcMi8q6FCRO7yJj96YfP9PvKsc/k64hOyqGmL5DhCzY9Cu1FQ==} + '@napi-rs/simple-git-android-arm64@0.1.9': + resolution: {integrity: sha512-Krilsw0gPrrASZzudNEl9pdLuNbhoTK0j7pUbfB8FRifpPdFB/zouwuEm0aSnsDXN4ftGrmGG82kuiR/2MeoPg==} engines: {node: '>= 10'} cpu: [arm64] os: [android] - '@napi-rs/simple-git-darwin-arm64@0.1.16': - resolution: {integrity: sha512-XfgsYqxhUE022MJobeiX563TJqyQyX4FmYCnqrtJwAfivESVeAJiH6bQIum8dDEYMHXCsG7nL8Ok0Dp8k2m42g==} + '@napi-rs/simple-git-darwin-arm64@0.1.9': + resolution: {integrity: sha512-H/F09nDgYjv4gcFrZBgdTKkZEepqt0KLYcCJuUADuxkKupmjLdecMhypXLk13AzvLW4UQI7NlLTLDXUFLyr2BA==} engines: {node: '>= 10'} cpu: [arm64] os: [darwin] - '@napi-rs/simple-git-darwin-x64@0.1.16': - resolution: {integrity: sha512-tkEVBhD6vgRCbeWsaAQqM3bTfpIVGeitamPPRVSbsq8qgzJ5Dx6ZedH27R7KSsA/uao7mZ3dsrNLXbu1Wy5MzA==} + '@napi-rs/simple-git-darwin-x64@0.1.9': + resolution: {integrity: sha512-jBR2xS9nVPqmHv0TWz874W0m/d453MGrMeLjB+boK5IPPLhg3AWIZj0aN9jy2Je1BGVAa0w3INIQJtBBeB6kFA==} engines: {node: '>= 10'} cpu: [x64] os: [darwin] - '@napi-rs/simple-git-linux-arm-gnueabihf@0.1.16': - resolution: {integrity: sha512-R6VAyNnp/yRaT7DV1Ao3r67SqTWDa+fNq2LrNy0Z8gXk2wB9ZKlrxFtLPE1WSpWknWtyRDLpRlsorh7Evk7+7w==} + '@napi-rs/simple-git-linux-arm-gnueabihf@0.1.9': + resolution: {integrity: sha512-3n0+VpO4YfZxndZ0sCvsHIvsazd+JmbSjrlTRBCnJeAU1/sfos3skNZtKGZksZhjvd+3o+/GFM8L7Xnv01yggA==} engines: {node: '>= 10'} cpu: [arm] os: [linux] - '@napi-rs/simple-git-linux-arm64-gnu@0.1.16': - resolution: {integrity: sha512-LAGI0opFKw/HBMCV2qIBK3uWSEW9h4xd2ireZKLJy8DBPymX6NrWIamuxYNyCuACnFdPRxR4LaRFy4J5ZwuMdw==} + '@napi-rs/simple-git-linux-arm64-gnu@0.1.9': + resolution: {integrity: sha512-lIzf0KHU2SKC12vMrWwCtysG2Sdt31VHRPMUiz9lD9t3xwVn8qhFSTn5yDkTeG3rgX6o0p5EKalfQN5BXsJq2w==} engines: {node: '>= 10'} cpu: [arm64] os: [linux] - '@napi-rs/simple-git-linux-arm64-musl@0.1.16': - resolution: {integrity: sha512-I57Ph0F0Yn2KW93ep+V1EzKhACqX0x49vvSiapqIsdDA2PifdEWLc1LJarBolmK7NKoPqKmf6lAKKO9lhiZzkg==} + '@napi-rs/simple-git-linux-arm64-musl@0.1.9': + resolution: {integrity: sha512-KQozUoNXrxrB8k741ncWXSiMbjl1AGBGfZV21PANzUM8wH4Yem2bg3kfglYS/QIx3udspsT35I9abu49n7D1/w==} engines: {node: '>= 10'} cpu: [arm64] os: [linux] - '@napi-rs/simple-git-linux-x64-gnu@0.1.16': - resolution: {integrity: sha512-AZYYFY2V7hlcQASPEOWyOa3e1skzTct9QPzz0LiDM3f/hCFY/wBaU2M6NC5iG3d2Kr38heuyFS/+JqxLm5WaKA==} + '@napi-rs/simple-git-linux-x64-gnu@0.1.9': + resolution: {integrity: sha512-O/Niui5mnHPcK3iYC3ui8wgERtJWsQ3Y74W/09t0bL/3dgzGMl4oQt0qTj9dWCsnoGsIEYHPzwCBp/2vqYp/pw==} engines: {node: '>= 10'} cpu: [x64] os: [linux] - '@napi-rs/simple-git-linux-x64-musl@0.1.16': - resolution: {integrity: sha512-9TyMcYSBJwjT8jwjY9m24BZbu7ozyWTjsmYBYNtK3B0Um1Ov6jthSNneLVvouQ6x+k3Ow+00TiFh6bvmT00r8g==} + '@napi-rs/simple-git-linux-x64-musl@0.1.9': + resolution: {integrity: sha512-L9n+e8Wn3hKr3RsIdY8GaB+ry4xZ4BaGwyKExgoB8nDGQuRUY9oP6p0WA4hWfJvJnU1H6hvo36a5UFPReyBO7A==} engines: {node: '>= 10'} cpu: [x64] os: [linux] - '@napi-rs/simple-git-win32-arm64-msvc@0.1.16': - resolution: {integrity: sha512-uslJ1WuAHCYJWui6xjsyT47SjX6KOHDtClmNO8hqKz1pmDSNY7AjyUY8HxvD1lK9bDnWwc4JYhikS9cxCqHybw==} + '@napi-rs/simple-git-win32-arm64-msvc@0.1.9': + resolution: {integrity: sha512-Z6Ja/SZK+lMvRWaxj7wjnvSbAsGrH006sqZo8P8nxKUdZfkVvoCaAWr1r0cfkk2Z3aijLLtD+vKeXGlUPH6gGQ==} engines: {node: '>= 10'} cpu: [arm64] os: [win32] - '@napi-rs/simple-git-win32-x64-msvc@0.1.16': - resolution: {integrity: sha512-SoEaVeCZCDF1MP+M9bMSXsZWgEjk4On9GWADO5JOulvzR1bKjk0s9PMHwe/YztR9F0sJzrCxwtvBZowhSJsQPg==} + '@napi-rs/simple-git-win32-x64-msvc@0.1.9': + resolution: {integrity: sha512-VAZj1UvC+R2MjKOD3I/Y7dmQlHWAYy4omhReQJRpbCf+oGCBi9CWiIduGqeYEq723nLIKdxP7XjaO0wl1NnUww==} engines: {node: '>= 10'} cpu: [x64] os: [win32] - '@napi-rs/simple-git@0.1.16': - resolution: {integrity: sha512-C5wRPw9waqL2jk3jEDeJv+f7ScuO3N0a39HVdyFLkwKxHH4Sya4ZbzZsu2JLi6eEqe7RuHipHL6mC7B2OfYZZw==} + '@napi-rs/simple-git@0.1.9': + resolution: {integrity: sha512-qKzDS0+VjMvVyU28px+C6zlD1HKy83NIdYzfMQWa/g/V1iG/Ic8uwrS2ihHfm7mp7X0PPrmINLiTTi6ieUIKfw==} engines: {node: '>= 10'} - '@next/env@13.5.1': - resolution: {integrity: sha512-CIMWiOTyflFn/GFx33iYXkgLSQsMQZV4jB91qaj/TfxGaGOXxn8C1j72TaUSPIyN7ziS/AYG46kGmnvuk1oOpg==} - '@next/env@13.5.6': resolution: {integrity: sha512-Yac/bV5sBGkkEXmAX5FWPS9Mmo2rthrOPRQQNfycJPkjUAUclomCPH7QFVCDQ4Mp2k2K1SSM6m0zrxYrOwtFQw==} - '@next/swc-darwin-arm64@13.5.1': - resolution: {integrity: sha512-Bcd0VFrLHZnMmJy6LqV1CydZ7lYaBao8YBEdQUVzV8Ypn/l5s//j5ffjfvMzpEQ4mzlAj3fIY+Bmd9NxpWhACw==} + '@next/env@14.2.10': + resolution: {integrity: sha512-dZIu93Bf5LUtluBXIv4woQw2cZVZ2DJTjax5/5DOs3lzEOeKLy7GxRSr4caK9/SCPdaW6bCgpye6+n4Dh9oJPw==} + + '@next/swc-darwin-arm64@14.2.10': + resolution: {integrity: sha512-V3z10NV+cvMAfxQUMhKgfQnPbjw+Ew3cnr64b0lr8MDiBJs3eLnM6RpGC46nhfMZsiXgQngCJKWGTC/yDcgrDQ==} engines: {node: '>= 10'} cpu: [arm64] os: [darwin] - '@next/swc-darwin-x64@13.5.1': - resolution: {integrity: sha512-uvTZrZa4D0bdWa1jJ7X1tBGIxzpqSnw/ATxWvoRO9CVBvXSx87JyuISY+BWsfLFF59IRodESdeZwkWM2l6+Kjg==} + '@next/swc-darwin-x64@14.2.10': + resolution: {integrity: sha512-Y0TC+FXbFUQ2MQgimJ/7Ina2mXIKhE7F+GUe1SgnzRmwFY3hX2z8nyVCxE82I2RicspdkZnSWMn4oTjIKz4uzA==} engines: {node: '>= 10'} cpu: [x64] os: [darwin] - '@next/swc-linux-arm64-gnu@13.5.1': - resolution: {integrity: sha512-/52ThlqdORPQt3+AlMoO+omicdYyUEDeRDGPAj86ULpV4dg+/GCFCKAmFWT0Q4zChFwsAoZUECLcKbRdcc0SNg==} + '@next/swc-linux-arm64-gnu@14.2.10': + resolution: {integrity: sha512-ZfQ7yOy5zyskSj9rFpa0Yd7gkrBnJTkYVSya95hX3zeBG9E55Z6OTNPn1j2BTFWvOVVj65C3T+qsjOyVI9DQpA==} engines: {node: '>= 10'} cpu: [arm64] os: [linux] - '@next/swc-linux-arm64-musl@13.5.1': - resolution: {integrity: sha512-L4qNXSOHeu1hEAeeNsBgIYVnvm0gg9fj2O2Yx/qawgQEGuFBfcKqlmIE/Vp8z6gwlppxz5d7v6pmHs1NB6R37w==} + '@next/swc-linux-arm64-musl@14.2.10': + resolution: {integrity: sha512-n2i5o3y2jpBfXFRxDREr342BGIQCJbdAUi/K4q6Env3aSx8erM9VuKXHw5KNROK9ejFSPf0LhoSkU/ZiNdacpQ==} engines: {node: '>= 10'} cpu: [arm64] os: [linux] - '@next/swc-linux-x64-gnu@13.5.1': - resolution: {integrity: sha512-QVvMrlrFFYvLtABk092kcZ5Mzlmsk2+SV3xYuAu8sbTuIoh0U2+HGNhVklmuYCuM3DAAxdiMQTNlRQmNH11udw==} + '@next/swc-linux-x64-gnu@14.2.10': + resolution: {integrity: sha512-GXvajAWh2woTT0GKEDlkVhFNxhJS/XdDmrVHrPOA83pLzlGPQnixqxD8u3bBB9oATBKB//5e4vpACnx5Vaxdqg==} engines: {node: '>= 10'} cpu: [x64] os: [linux] - '@next/swc-linux-x64-musl@13.5.1': - resolution: {integrity: sha512-bBnr+XuWc28r9e8gQ35XBtyi5KLHLhTbEvrSgcWna8atI48sNggjIK8IyiEBO3KIrcUVXYkldAzGXPEYMnKt1g==} + '@next/swc-linux-x64-musl@14.2.10': + resolution: {integrity: sha512-opFFN5B0SnO+HTz4Wq4HaylXGFV+iHrVxd3YvREUX9K+xfc4ePbRrxqOuPOFjtSuiVouwe6uLeDtabjEIbkmDA==} engines: {node: '>= 10'} cpu: [x64] os: [linux] - '@next/swc-win32-arm64-msvc@13.5.1': - resolution: {integrity: sha512-EQGeE4S5c9v06jje9gr4UlxqUEA+zrsgPi6kg9VwR+dQHirzbnVJISF69UfKVkmLntknZJJI9XpWPB6q0Z7mTg==} + '@next/swc-win32-arm64-msvc@14.2.10': + resolution: {integrity: sha512-9NUzZuR8WiXTvv+EiU/MXdcQ1XUvFixbLIMNQiVHuzs7ZIFrJDLJDaOF1KaqttoTujpcxljM/RNAOmw1GhPPQQ==} engines: {node: '>= 10'} cpu: [arm64] os: [win32] - '@next/swc-win32-ia32-msvc@13.5.1': - resolution: {integrity: sha512-1y31Q6awzofVjmbTLtRl92OX3s+W0ZfO8AP8fTnITcIo9a6ATDc/eqa08fd6tSpFu6IFpxOBbdevOjwYTGx/AQ==} + '@next/swc-win32-ia32-msvc@14.2.10': + resolution: {integrity: sha512-fr3aEbSd1GeW3YUMBkWAu4hcdjZ6g4NBl1uku4gAn661tcxd1bHs1THWYzdsbTRLcCKLjrDZlNp6j2HTfrw+Bg==} engines: {node: '>= 10'} cpu: [ia32] os: [win32] - '@next/swc-win32-x64-msvc@13.5.1': - resolution: {integrity: sha512-+9XBQizy7X/GuwNegq+5QkkxAPV7SBsIwapVRQd9WSvvU20YO23B3bZUpevdabi4fsd25y9RJDDncljy/V54ww==} + '@next/swc-win32-x64-msvc@14.2.10': + resolution: {integrity: sha512-UjeVoRGKNL2zfbcQ6fscmgjBAS/inHBh63mjIlfPg/NG8Yn2ztqylXt5qilYb6hoHIwaU2ogHknHWWmahJjgZQ==} engines: {node: '>= 10'} cpu: [x64] os: [win32] + '@noble/curves@1.1.0': + resolution: {integrity: sha512-091oBExgENk/kGj3AZmtBDMpxQPDtxQABR2B9lb1JbVTs6ytdzZNwvhxQ4MWasRNEzlbEH8jCWFCwhF/Obj5AA==} + '@noble/curves@1.2.0': resolution: {integrity: sha512-oYclrNgRaM9SsBUBVbb8M6DTV7ZHRTKugureoYEncY5c65HOmRzvSiTE3y5CYaPYJA/GVkrhXEoF0M3Ya9PMnw==} - '@noble/curves@1.3.0': - resolution: {integrity: sha512-t01iSXPuN+Eqzb4eBX0S5oubSqXbK/xXa1Ne18Hj8f9pStxztHCE2gfboSp/dZRLSqfuLpRK2nDXDK+W9puocA==} + '@noble/curves@1.6.0': + resolution: {integrity: sha512-TlaHRXDehJuRNR9TfZDNQ45mMEd5dwUwmicsafcIX4SsNiqnCHKjE/1alYPd/lDRVhxdhUAlv8uEhMCI5zjIJQ==} + engines: {node: ^14.21.3 || >=16} - '@noble/hashes@1.3.2': - resolution: {integrity: sha512-MVC8EAQp7MvEcm30KWENFjgR+Mkmf+D189XJTkFIlwohU5hcBbn1ZkKq7KVTi2Hme3PMGF390DaL52beVrIihQ==} + '@noble/hashes@1.3.1': + resolution: {integrity: sha512-EbqwksQwz9xDRGfDST86whPBgM65E0OH/pCgqW0GBVzO22bNE+NuIbeTb714+IfSjU3aRk47EUvXIb5bTsenKA==} engines: {node: '>= 16'} - '@noble/hashes@1.3.3': - resolution: {integrity: sha512-V7/fPHgl+jsVPXqqeOzT8egNj2iBIVt+ECeMMG8TdcnTikP3oaBtUVqpT/gYCR68aEBJSF+XbYUxStjbFMqIIA==} + '@noble/hashes@1.3.2': + resolution: {integrity: sha512-MVC8EAQp7MvEcm30KWENFjgR+Mkmf+D189XJTkFIlwohU5hcBbn1ZkKq7KVTi2Hme3PMGF390DaL52beVrIihQ==} engines: {node: '>= 16'} - '@noble/hashes@1.4.0': - resolution: {integrity: sha512-V1JJ1WTRUqHHrOSh597hURcMqVKVGL/ea3kv0gSnEdsEZ0/+VyPghM1lMNGc00z7CIQorSvbKpuJkxvuHbvdbg==} - engines: {node: '>= 16'} + '@noble/hashes@1.5.0': + resolution: {integrity: sha512-1j6kQFb7QRru7eKN3ZDvRcP13rugwdxZqCjbiAVZfIJwgj2A65UmT4TgARXGlXgnRkORLTDTrO19ZErt7+QXgA==} + engines: {node: ^14.21.3 || >=16} '@nodelib/fs.scandir@2.1.5': resolution: {integrity: sha512-vq24Bq3ym5HEQm2NKCr3yXDwjc7vTsEThRDnkp2DK9p1uqLR+DHurm/NOTo0KG7HYHU7eppKZj3MyqYuMBf62g==} @@ -793,12 +796,12 @@ packages: resolution: {integrity: sha512-oGB+UxlgWcgQkgwo8GcEGwemoTFt3FIO9ababBmaGwXIoBKZ+GTy0pP185beGg7Llih/NSHSV2XAs1lnznocSg==} engines: {node: '>= 8'} - '@npmcli/config@6.4.1': - resolution: {integrity: sha512-uSz+elSGzjCMANWa5IlbGczLYPkNI/LeR+cHrgaTqTrTSh9RHhOFA4daD2eRUz6lMtOW+Fnsb+qv7V2Zz8ML0g==} + '@npmcli/config@6.4.0': + resolution: {integrity: sha512-/fQjIbuNVIT/PbXvw178Tm97bxV0E0nVUFKHivMKtSI2pcs8xKdaWkHJxf9dTI0G/y5hp/KuCvgcUu5HwAtI1w==} engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0} - '@npmcli/map-workspaces@3.0.6': - resolution: {integrity: sha512-tkYs0OYnzQm6iIRdfy+LcLBjcKuQCeE5YLb8KnrIlutJfheNaPvPpgoFEyEFgbjzl5PLZ3IA/BWAwRU0eHuQDA==} + '@npmcli/map-workspaces@3.0.4': + resolution: {integrity: sha512-Z0TbvXkRbacjFFLpVpV0e2mheCh+WzQpcqL+4xp49uNJOxOnIAPZyXtUxZ5Qn3QBTGKA11Exjd9a5411rBrhDg==} engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0} '@npmcli/name-from-folder@2.0.0': @@ -809,77 +812,89 @@ packages: resolution: {integrity: sha512-+1VkjdD0QBLPodGrJUeqarH8VAIvQODIbwh9XpP5Syisf7YoQgsJKPNFoqqLQlu+VQ/tVSshMR6loPMn8U+dPg==} engines: {node: '>=14'} - '@pkgr/core@0.1.1': - resolution: {integrity: sha512-cq8o4cWH0ibXh9VGi5P20Tu9XF/0fFXl9EUinr9QfTM7a7p0oTA4iJRCQWppXR1Pg8dSM0UCItCkPwsk9qWWYA==} + '@pkgr/utils@2.4.2': + resolution: {integrity: sha512-POgTXhjrTfbTV63DiFXav4lBHiICLKKwDeaKn9Nphwj7WH6m0hMMCaJkMyRWjgtPFyRKRVoMXXjczsTQRDEhYw==} engines: {node: ^12.20.0 || ^14.18.0 || >=16.0.0} '@popperjs/core@2.11.8': resolution: {integrity: sha512-P1st0aksCrn9sGZhp8GMYwBnQsbvAWsZAX44oXNNvLHGqAOcoVxmjZiohstwQ7SqKnbR47akdNi+uleWD8+g6A==} - '@react-aria/focus@3.17.1': - resolution: {integrity: sha512-FLTySoSNqX++u0nWZJPPN5etXY0WBxaIe/YuL/GTEeuqUIuC/2bJSaw5hlsM6T2yjy6Y/VAxBcKSdAFUlU6njQ==} + '@react-aria/focus@3.18.4': + resolution: {integrity: sha512-91J35077w9UNaMK1cpMUEFRkNNz0uZjnSwiyBCFuRdaVuivO53wNC9XtWSDNDdcO5cGy87vfJRVAiyoCn/mjqA==} peerDependencies: - react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 + react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0 - '@react-aria/interactions@3.21.3': - resolution: {integrity: sha512-BWIuf4qCs5FreDJ9AguawLVS0lV9UU+sK4CCnbCNNmYqOWY+1+gRXCsnOM32K+oMESBxilAjdHW5n1hsMqYMpA==} + '@react-aria/interactions@3.22.4': + resolution: {integrity: sha512-E0vsgtpItmknq/MJELqYJwib+YN18Qag8nroqwjk1qOnBa9ROIkUhWJerLi1qs5diXq9LHKehZDXRlwPvdEFww==} peerDependencies: - react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 + react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0 - '@react-aria/ssr@3.9.4': - resolution: {integrity: sha512-4jmAigVq409qcJvQyuorsmBR4+9r3+JEC60wC+Y0MZV0HCtTmm8D9guYXlJMdx0SSkgj0hHAyFm/HvPNFofCoQ==} + '@react-aria/ssr@3.9.6': + resolution: {integrity: sha512-iLo82l82ilMiVGy342SELjshuWottlb5+VefO3jOQqQRNYnJBFpUSadswDPbRimSgJUZuFwIEYs6AabkP038fA==} engines: {node: '>= 12'} peerDependencies: - react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 + react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0 - '@react-aria/utils@3.24.1': - resolution: {integrity: sha512-O3s9qhPMd6n42x9sKeJ3lhu5V1Tlnzhu6Yk8QOvDuXf7UGuUjXf9mzfHJt1dYzID4l9Fwm8toczBzPM9t0jc8Q==} + '@react-aria/utils@3.25.3': + resolution: {integrity: sha512-PR5H/2vaD8fSq0H/UB9inNbc8KDcVmW6fYAfSWkkn+OAdhTTMVKqXXrZuZBWyFfSD5Ze7VN6acr4hrOQm2bmrA==} peerDependencies: - react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 + react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0 - '@react-stately/utils@3.10.1': - resolution: {integrity: sha512-VS/EHRyicef25zDZcM/ClpzYMC5i2YGN6uegOeQawmgfGjb02yaCX0F0zR69Pod9m2Hr3wunTbtpgVXvYbZItg==} + '@react-stately/utils@3.10.4': + resolution: {integrity: sha512-gBEQEIMRh5f60KCm7QKQ2WfvhB2gLUr9b72sqUdIZ2EG+xuPgaIlCBeSicvjmjBvYZwOjoOEnmIkcx2GHp/HWw==} peerDependencies: - react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 + react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0 - '@react-types/shared@3.23.1': - resolution: {integrity: sha512-5d+3HbFDxGZjhbMBeFHRQhexMFt4pUce3okyRtUVKbbedQFUrtXSBg9VszgF2RTeQDKDkMCIQDtz5ccP/Lk1gw==} + '@react-types/shared@3.25.0': + resolution: {integrity: sha512-OZSyhzU6vTdW3eV/mz5i6hQwQUhkRs7xwY2d1aqPvTdMe0+2cY7Fwp45PAiwYLEj73i9ro2FxF9qC4DvHGSCgQ==} peerDependencies: - react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 + react: ^16.8.0 || ^17.0.0-rc.1 || ^18.0.0 || ^19.0.0 - '@scure/base@1.1.6': - resolution: {integrity: sha512-ok9AWwhcgYuGG3Zfhyqg+zwl+Wn5uE+dwC0NV/2qQkx4dABbb/bx96vWu8NSj+BNjjSjno+JRYRjle1jV08k3g==} + '@scure/base@1.1.3': + resolution: {integrity: sha512-/+SgoRjLq7Xlf0CWuLHq2LUZeL/w65kfzAPG5NH9pcmBhs+nunQTn4gvdwgMTIXnt9b2C/1SeL2XiysZEyIC9Q==} + + '@scure/base@1.1.9': + resolution: {integrity: sha512-8YKhl8GHiNI/pU2VMaofa2Tor7PJRAjwQLBBuilkJ9L5+13yVbC7JO/wS7piioAvPSwR3JKM1IJ/u4xQzbcXKg==} + + '@scure/bip32@1.3.1': + resolution: {integrity: sha512-osvveYtyzdEVbt3OfwwXFr4P2iVBL5u1Q3q4ONBfDY/UpOuXmOlbgwc1xECEboY8wIays8Yt6onaWMUdUbfl0A==} '@scure/bip32@1.3.2': resolution: {integrity: sha512-N1ZhksgwD3OBlwTv3R6KFEcPojl/W4ElJOeCZdi+vuI5QmTFwLq3OFf2zd2ROpKvxFdgZ6hUpb0dx9bVNEwYCA==} - '@scure/bip32@1.3.3': - resolution: {integrity: sha512-LJaN3HwRbfQK0X1xFSi0Q9amqOgzQnnDngIt+ZlsBC3Bm7/nE7K0kwshZHyaru79yIVRv/e1mQAjZyuZG6jOFQ==} + '@scure/bip32@1.5.0': + resolution: {integrity: sha512-8EnFYkqEQdnkuGBVpCzKxyIwDCBLDVj3oiX0EKUFre/tOjL/Hqba1D6n/8RcmaQy4f95qQFrO2A8Sr6ybh4NRw==} '@scure/bip39@1.2.1': resolution: {integrity: sha512-Z3/Fsz1yr904dduJD0NpiyRHhRYHdcnyh73FZWiV+/qhWi83wNJ3NWolYqCEN+ZWsUz2TWwajJggcRE9r1zUYg==} - '@scure/bip39@1.2.2': - resolution: {integrity: sha512-HYf9TUXG80beW+hGAt3TRM8wU6pQoYur9iNypTROm42dorCGmLnFe3eWjz3gOq6G62H2WRh0FCzAR1PI+29zIA==} + '@scure/bip39@1.4.0': + resolution: {integrity: sha512-BEEm6p8IueV/ZTfQLp/0vhw4NPnT9oWf5+28nvmeUICjP99f4vr2d+qc7AVGDDtwRep6ifR43Yed9ERVmiITzw==} + + '@swc/counter@0.1.3': + resolution: {integrity: sha512-e2BR4lsJkkRlKZ/qCHPw9ZaSxc0MVUd7gtbtaB7aMvHeJVYe8sOB8DBZkP2DtISHGSku9sCK6T6cnY0CtXrOCQ==} '@swc/helpers@0.5.2': resolution: {integrity: sha512-E4KcWTpoLHqwPHLxidpOqQbcrZVgi0rsmmZXUle1jXmJfuIf/UWpczUJ7MZZ5tlxytgJXyp0w4PGkkeLiuIdZw==} - '@tanstack/react-virtual@3.5.0': - resolution: {integrity: sha512-rtvo7KwuIvqK9zb0VZ5IL7fiJAEnG+0EiFZz8FUOs+2mhGqdGmjKIaT1XU7Zq0eFqL0jonLlhbayJI/J2SA/Bw==} + '@swc/helpers@0.5.5': + resolution: {integrity: sha512-KGYxvIOXcceOAbEk4bi/dVLEK9z8sZ0uBB3Il5b1rhfClSpcX0yfRO0KmTkqR2cnQDymwLB+25ZyMzICg/cm/A==} + + '@tanstack/react-virtual@3.10.8': + resolution: {integrity: sha512-VbzbVGSsZlQktyLrP5nxE+vE1ZR+U0NFAWPbJLoG2+DKPwd2D7dVICTVIIaYlJqX1ZCEnYDbaOpmMwbsyhBoIA==} peerDependencies: react: ^16.8.0 || ^17.0.0 || ^18.0.0 react-dom: ^16.8.0 || ^17.0.0 || ^18.0.0 - '@tanstack/virtual-core@3.5.0': - resolution: {integrity: sha512-KnPRCkQTyqhanNC0K63GBG3wA8I+D1fQuVnAvcBF8f13akOKeQp1gSbu6f77zCxhEk727iV5oQnbHLYzHrECLg==} + '@tanstack/virtual-core@3.10.8': + resolution: {integrity: sha512-PBu00mtt95jbKFi6Llk9aik8bnR3tR/oQP1o3TSi+iG//+Q2RTIzCEgKkHG8BB86kxMNW6O8wku+Lmi+QFR6jA==} - '@testing-library/dom@9.3.4': - resolution: {integrity: sha512-FlS4ZWlp97iiNWig0Muq8p+3rVDjRiYE+YKGbAqXOu9nwJFFOdL00kFpz42M+4huzYi86vAK1sOOfyOG45muIQ==} + '@testing-library/dom@9.3.3': + resolution: {integrity: sha512-fB0R+fa3AUqbLHWyxXa2kGVtf1Fe1ZZFr0Zp6AIbIAzXb2mKbEXl+PCQNUOaq5lbTab5tfctfXRNsWXxa2f7Aw==} engines: {node: '>=14'} - '@testing-library/react@14.3.1': - resolution: {integrity: sha512-H99XjUhWQw0lTgyMN05W3xQG1Nh4lq574D8keFf1dDoNTJgp66VbJozRaczoF+wsiaPJNt/TcnfpLGufGxSrZQ==} + '@testing-library/react@14.1.2': + resolution: {integrity: sha512-z4p7DVBTPjKM5qDZ0t5ZjzkpSNb+fZy1u6bzO7kk8oeGagpPCAtgh4cx1syrfp7a+QWkM021jGqjJaxJJnXAZg==} engines: {node: '>=14'} peerDependencies: react: ^18.0.0 @@ -906,80 +921,83 @@ packages: '@types/concat-stream@2.0.3': resolution: {integrity: sha512-3qe4oQAPNwVNwK4C9c8u+VJqv9kez+2MR4qJpoPFfXtgxxif1QbFusvXzK0/Wra2VX07smostI2VMmJNSpZjuQ==} - '@types/d3-scale-chromatic@3.0.3': - resolution: {integrity: sha512-laXM4+1o5ImZv3RpFAsTRn3TEkzqkytiOY0Dz0sq5cnd1dtNlk6sHLon4OvqaiJb28T0S/TdsBI3Sjsy+keJrw==} + '@types/d3-scale-chromatic@3.0.1': + resolution: {integrity: sha512-Ob7OrwiTeQXY/WBBbRHGZBOn6rH1h7y3jjpTSKYqDEeqFjktql6k2XSgNwLrLDmAsXhEn8P9NHDY4VTuo0ZY1w==} - '@types/d3-scale@4.0.8': - resolution: {integrity: sha512-gkK1VVTr5iNiYJ7vWDI+yUFFlszhNMtVeneJ6lUTKPjprsvLLI9/tgEGiXJOnlINJA8FyA88gfnQsHbybVZrYQ==} + '@types/d3-scale@4.0.7': + resolution: {integrity: sha512-/YEbMIOtqSFSELqUT8desdT3a7iybPkSQiIx/wN4CZ/5b7wrCvmyXWELTMUYB10k0N5rzHVu4f/OkhulG1b3Lw==} - '@types/d3-time@3.0.3': - resolution: {integrity: sha512-2p6olUZ4w3s+07q3Tm2dbiMZy5pCDfYwtLXXHUnVzXgQlZ/OyPtUz6OL382BkOuGlLXqfT+wqv8Fw2v8/0geBw==} + '@types/d3-time@3.0.2': + resolution: {integrity: sha512-kbdRXTmUgNfw5OTE3KZnFQn6XdIc4QGroN5UixgdrXATmYsdlPQS6pEut9tVlIojtzuFD4txs/L+Rq41AHtLpg==} - '@types/debug@4.1.12': - resolution: {integrity: sha512-vIChWdVG3LG1SMxEvI/AK+FWJthlrqlTu7fbrlywTkkaONwk/UAGaULXRlf8vkzFBLVm0zkMdCquhL5aOjhXPQ==} + '@types/debug@4.1.11': + resolution: {integrity: sha512-R2qflTjHDs4CL6D/6TkqBeIHr54WzZfIxN729xvCNlYIVp2LknlnCro5Yo3frNaX2E5gO9pZ3/QAPVdGmu+q9w==} - '@types/estree-jsx@1.0.5': - resolution: {integrity: sha512-52CcUVNFyfb1A2ALocQw/Dd1BQFNmSdkuC3BkZ6iqhdMfQz7JWOFRuJFloOzjk+6WijU56m9oKXFAXc7o3Towg==} + '@types/estree-jsx@1.0.3': + resolution: {integrity: sha512-pvQ+TKeRHeiUGRhvYwRrQ/ISnohKkSJR14fT2yqyZ4e9K5vqc7hrtY2Y1Dw0ZwAzQ6DQsxsaCUuSIIi8v0Cq6w==} '@types/estree@1.0.5': resolution: {integrity: sha512-/kYRxGDLWzHOB7q+wtSUQlFrtcdUccpfy+X+9iMBpHK8QLLhx2wIPYuS5DYtR9Wa/YlZAbIovy7qVdB1Aq6Lyw==} - '@types/hast@2.3.10': - resolution: {integrity: sha512-McWspRw8xx8J9HurkVBfYj0xKoE25tOFlHGdx4MJ5xORQrMGZNqJhVQWaIbm6Oyla5kYOXtDiopzKRJzEOkwJw==} + '@types/hast@2.3.7': + resolution: {integrity: sha512-EVLigw5zInURhzfXUM65eixfadfsHKomGKUakToXo84t8gGIJuTcD2xooM2See7GyQ7DRtYjhCHnSUQez8JaLw==} - '@types/hast@3.0.4': - resolution: {integrity: sha512-WPs+bbQw5aCj+x6laNGWLH3wviHtoCv/P3+otBhbOhJgG8qtpdAMlTCxLtsTWA7LH1Oh/bFCHsBn0TPS5m30EQ==} + '@types/hast@3.0.2': + resolution: {integrity: sha512-B5hZHgHsXvfCoO3xgNJvBnX7N8p86TqQeGKXcokW4XXi+qY4vxxPSFYofytvVmpFxzPv7oxDQzjg5Un5m2/xiw==} '@types/is-empty@1.2.3': resolution: {integrity: sha512-4J1l5d79hoIvsrKh5VUKVRA1aIdsOb10Hu5j3J2VfP/msDnfTdGPmNp2E1Wg+vs97Bktzo+MZePFFXSGoykYJw==} - '@types/js-yaml@4.0.9': - resolution: {integrity: sha512-k4MGaQl5TGo/iipqb2UDG2UwjXziSWkh0uysQelTlJpX1qGlpUZYm8PnO4DxG1qBomtJUdYJ6qR6xdIah10JLg==} + '@types/js-yaml@4.0.8': + resolution: {integrity: sha512-m6jnPk1VhlYRiLFm3f8X9Uep761f+CK8mHyS65LutH2OhmBF0BeMEjHgg05usH8PLZMWWc/BUR9RPmkvpWnyRA==} '@types/json-schema@7.0.15': resolution: {integrity: sha512-5+fP8P8MFNC+AyZCDxrB2pkZFPGzqQWUzpSeuuVLvm8VMcorNYavBqoFcxK8bQz4Qsbn4oUEEem4wDLfcysGHA==} - '@types/katex@0.16.7': - resolution: {integrity: sha512-HMwFiRujE5PjrgwHQ25+bsLJgowjGjm5Z8FVSf0N6PwgJrwxH0QxzHYDcKsTfV3wva0vzrpqMTJS2jXPr5BMEQ==} + '@types/katex@0.16.5': + resolution: {integrity: sha512-DD2Y3xMlTQvAnN6d8803xdgnOeYZ+HwMglb7/9YCf49J9RkJL53azf9qKa40MkEYhqVwxZ1GS2+VlShnz4Z1Bw==} '@types/lodash.clonedeep@4.5.9': resolution: {integrity: sha512-19429mWC+FyaAhOLzsS8kZUsI+/GmBAQ0HFiCPsKGU+7pBXOQWhyrY6xNNDwUSX8SMZMJvuFVMF9O5dQOlQK9Q==} - '@types/lodash@4.17.0': - resolution: {integrity: sha512-t7dhREVv6dbNj0q17X12j7yDG4bD/DHYX7o5/DbDxobP0HnGPgpRz2Ej77aL7TZT3DSw13fqUTj8J4mMnqa7WA==} + '@types/lodash@4.14.202': + resolution: {integrity: sha512-OvlIYQK9tNneDlS0VN54LLd5uiPCBOp7gS5Z0f1mjoJYBrtStzgmJBxONW3U6OZqdtNzZPmn9BS/7WI7BFFcFQ==} - '@types/mdast@3.0.15': - resolution: {integrity: sha512-LnwD+mUEfxWMa1QpDraczIn6k0Ee3SMicuYSSzS6ZYl2gKS09EClnJYGd8Du6rfc5r/GZEk5o1mRb8TaTj03sQ==} + '@types/mdast@3.0.14': + resolution: {integrity: sha512-gVZ04PGgw1qLZKsnWnyFv4ORnaJ+DXLdHTVSFbU8yX6xZ34Bjg4Q32yPkmveUP1yItXReKfB0Aknlh/3zxTKAw==} - '@types/mdast@4.0.3': - resolution: {integrity: sha512-LsjtqsyF+d2/yFOYaN22dHZI1Cpwkrj+g06G8+qtUKlhovPW89YhqSnfKtMbkgmEtYpH2gydRNULd6y8mciAFg==} + '@types/mdast@4.0.2': + resolution: {integrity: sha512-tYR83EignvhYO9iU3kDg8V28M0jqyh9zzp5GV+EO+AYnyUl3P5ltkTeJuTiFZQFz670FSb3EwT/6LQdX+UdKfw==} - '@types/mdx@2.0.13': - resolution: {integrity: sha512-+OWZQfAYyio6YkJb3HLxDrvnx6SWWDbC0zVPfBRzUk0/nqoDyf6dNxQi3eArPe8rJ473nobTMQ/8Zk+LxJ+Yuw==} + '@types/mdx@2.0.9': + resolution: {integrity: sha512-OKMdj17y8Cs+k1r0XFyp59ChSOwf8ODGtMQ4mnpfz5eFDk1aO41yN3pSKGuvVzmWAkFp37seubY1tzOVpwfWwg==} - '@types/ms@0.7.34': - resolution: {integrity: sha512-nG96G3Wp6acyAgJqGasjODb+acrI7KltPiRxzHPXnP3NgI28bpQDRv53olbqGXbfcgF5aiiHmO3xpwEpS5Ld9g==} + '@types/ms@0.7.33': + resolution: {integrity: sha512-AuHIyzR5Hea7ij0P9q7vx7xu4z0C28ucwjAZC0ja7JhINyCnOw8/DnvAPQQ9TfOlCtZAmCERKQX9+o1mgQhuOQ==} '@types/node@18.11.10': resolution: {integrity: sha512-juG3RWMBOqcOuXC643OAdSA525V44cVgGV6dUDuiFtss+8Fk5x1hI93Rsld43VeJVIeqlP9I7Fn9/qaVqoEAuQ==} - '@types/prop-types@15.7.12': - resolution: {integrity: sha512-5zvhXYtRNRluoE/jAp4GVsSduVUzNWKkOZrCDBWYtE7biZywwdC2AcEzg+cSMLFRfVgeAFqpfNabiPjxFddV1Q==} + '@types/prop-types@15.7.9': + resolution: {integrity: sha512-n1yyPsugYNSmHgxDFjicaI2+gCNjsBck8UX9kuofAKlc0h1bL+20oSF72KeNaW2DUlesbEVCFgyV2dPGTiY42g==} - '@types/react-dom@18.3.0': - resolution: {integrity: sha512-EhwApuTmMBmXuFOikhQLIBUn6uFg81SwLMOAUgodJF14SOBOCMdU04gDoYi0WOJJHD144TL32z4yDqCW3dnkQg==} + '@types/react-dom@18.2.16': + resolution: {integrity: sha512-766c37araZ9vxtYs25gvY2wNdFWsT2ZiUvOd0zMhTaoGj6B911N8CKQWgXXJoPMLF3J82thpRqQA7Rf3rBwyJw==} - '@types/react@18.3.1': - resolution: {integrity: sha512-V0kuGBX3+prX+DQ/7r2qsv1NsdfnCLnTgnRJ1pYnxykBhGMz+qj+box5lq7XsO5mtZsBqpjwwTu/7wszPfMBcw==} + '@types/react@18.2.36': + resolution: {integrity: sha512-o9XFsHYLLZ4+sb9CWUYwHqFVoG61SesydF353vFMMsQziiyRu8np4n2OYMUSDZ8XuImxDr9c5tR7gidlH29Vnw==} + + '@types/scheduler@0.16.5': + resolution: {integrity: sha512-s/FPdYRmZR8SjLWGMCuax7r3qCWQw9QKHzXVukAuuIJkXkDRwp+Pu5LMIVFi0Fxbav35WURicYr8u1QsoybnQw==} '@types/supports-color@8.1.3': resolution: {integrity: sha512-Hy6UMpxhE3j1tLpl27exp1XqHD7n8chAiNPzWfz16LPZoMMoSc4dzLl6w9qijkEb/r5O1ozdu1CWGA2L83ZeZg==} - '@types/unist@2.0.10': - resolution: {integrity: sha512-IfYcSBWE3hLpBg8+X2SEa8LVkJdJEkT2Ese2aaLs3ptGdVtABxndrMaxuFlQ1qdFf9Q5rDvDpxI3WwgvKFAsQA==} + '@types/unist@2.0.9': + resolution: {integrity: sha512-zC0iXxAv1C1ERURduJueYzkzZ2zaGyc+P2c95hgkikHPr3z8EdUZOlgEQ5X0DRmwDZn+hekycQnoeiiRVrmilQ==} - '@types/unist@3.0.2': - resolution: {integrity: sha512-dqId9J8K/vGi5Zr7oo212BGii5m3q5Hxlkwy3WpYuKPklmBEvsbMYYyLxAQpSffdLl/gdW0XUpKWFvYmyoWCoQ==} + '@types/unist@3.0.1': + resolution: {integrity: sha512-ue/hDUpPjC85m+PM9OQDMZr3LywT+CT6mPsQq8OJtCLiERkGRcQUFvu9XASF5XWqyZFXbf15lvb3JFJ4dRLWPg==} '@ungap/structured-clone@1.2.0': resolution: {integrity: sha512-zuVdFrMJiuCDQUMCzQaD6KL28MjnqqN8XnAqiEq9PNm/hCPTSGfrXCOfwj1ow4LFb/tNymJPwsNbVePc1xFqrQ==} @@ -988,8 +1006,19 @@ packages: resolution: {integrity: sha512-6/mh1E2u2YgEsCHdY0Yx5oW+61gZU+1vXaoiHHrpKeuRNNgFvS+/jrwHiQhB5apAf5oB7UB7E19ol2R2LKH8hQ==} engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0} - abitype@1.0.0: - resolution: {integrity: sha512-NMeMah//6bJ56H5XRj8QCV4AwuW6hB6zqz2LnhhLdcWVQOsXki6/Pn3APeqxCma62nXIcmZWdu1DlHWS74umVQ==} + abitype@0.9.8: + resolution: {integrity: sha512-puLifILdm+8sjyss4S+fsUN09obiT1g2YW6CtcQF+QDzxR0euzgEB29MZujC6zMk2a6SVmtttq1fc6+YFA7WYQ==} + peerDependencies: + typescript: '>=5.0.4' + zod: ^3 >=3.19.1 + peerDependenciesMeta: + typescript: + optional: true + zod: + optional: true + + abitype@1.0.6: + resolution: {integrity: sha512-MMSqYh4+C/aVqI2RQaWqbvI4Kxo5cQV40WQ4QFtDnNzCkqChm8MuENhElmynZlO0qUy/ObkEUaXtKqYnx1Kp3A==} peerDependencies: typescript: '>=5.0.4' zod: ^3 >=3.22.0 @@ -1004,8 +1033,8 @@ packages: peerDependencies: acorn: ^6.0.0 || ^7.0.0 || ^8.0.0 - acorn@8.11.3: - resolution: {integrity: sha512-Y9rRfJG5jcKOE0CLisYbojUjIrIEE7AGMzA/Sm4BslANhbS+cDMpgBdcPT91oJ7OuJ9hYJBx59RjbhxVnrF8Xg==} + acorn@8.11.2: + resolution: {integrity: sha512-nc0Axzp/0FILLEVsm4fNwLCwMttvhEI263QtVPQcbpfZZ3ts0hLsZGOpE6czNlid7CJ9MlyH8reXkpsf3YUY4w==} engines: {node: '>=0.4.0'} hasBin: true @@ -1071,9 +1100,8 @@ packages: aria-query@5.1.3: resolution: {integrity: sha512-R5iJ5lkuHybztUfuOAznmboyjWq8O6sqNqtK7CLOqdydi54VNbORp49mb14KbWgG1QD3JFO9hJdZ+y4KutfdOQ==} - array-buffer-byte-length@1.0.1: - resolution: {integrity: sha512-ahC5W1xgou+KTXix4sAO8Ki12Q+jf4i0+tmk3sC+zgcynshkHxzpXdImBehiUYKKKDwvfFiJl1tZt6ewscS1Mg==} - engines: {node: '>= 0.4'} + array-buffer-byte-length@1.0.0: + resolution: {integrity: sha512-LPuwb2P+NrQw3XhxGc36+XSvuBPopovXYTR9Ew++Du9Yb/bx5AzBfrIsBoj0EZUifjQU+sHL21sseZ3jerWO/A==} array-timsort@1.0.3: resolution: {integrity: sha512-/+3GRL7dDAGEfM6TseQk/U+mi18TU2Ms9I3UlLdUMhz2hbvGNTKdj9xniwXfUqgYhHxRx0+8UnKkvlNwVU+cWQ==} @@ -1089,8 +1117,8 @@ packages: resolution: {integrity: sha512-ISvCdHdlTDlH5IpxQJIex7BWBywFWgjJSVdwst+/iQCoEYnyOaQ95+X1JGshuBjGp6nxKUy1jMgE3zPqN7fQdg==} hasBin: true - available-typed-arrays@1.0.7: - resolution: {integrity: sha512-wvUjBtSGN7+7SjNpq/9M2Tg350UZD3q62IFZLbRAR1bSMlCo1ZaeW+BJ+D090e4hIIZLBcTDWe4Mh4jvUDajzQ==} + available-typed-arrays@1.0.5: + resolution: {integrity: sha512-DMD0KiN46eipeziST1LPP/STfDU0sufISXmjSgvVsoU2tqxctQeASejWcfNtxYKqETM1UxQ8sp2OrSBWpHY6sw==} engines: {node: '>= 0.4'} bail@2.0.2: @@ -1102,6 +1130,10 @@ packages: bech32@1.1.4: resolution: {integrity: sha512-s0IrSOzLlbvX7yp4WBfPITzpAU8sqQcpsmwXDiKwrG4r491vwCO/XpejasRNl0piBMe/DvP4Tz0mIS/X1DPJBQ==} + big-integer@1.6.52: + resolution: {integrity: sha512-QxD8cf2eVqJOOz63z6JIN9BzvVs/dlySa5HGSBH5xtR8dPteIRQnBxxKqkNTiT6jbDTF6jAfrd4oMcND9RGbQg==} + engines: {node: '>=0.6'} + bignumber.js@9.1.2: resolution: {integrity: sha512-2/mKyZH9K85bzOEfhXDBFZTGd1CTs+5IHpeFQo9luiBG7hghdC851Pj2WAhb6E3R6b9tZj/XKhbg4fum+Kepug==} @@ -1114,14 +1146,18 @@ packages: bn.js@5.2.1: resolution: {integrity: sha512-eXRvHzWyYPBuB4NBy0cmYQjGitUrtqwbvlzP3G6VFnNRbsZQIxQ10PbKKHt8gZ/HW/D/747aDl+QkDqg3KQLMQ==} + bplist-parser@0.2.0: + resolution: {integrity: sha512-z0M+byMThzQmD9NILRniCUXYsYpjwnlO8N5uCFaCqIOpqRsJCrQL9NK3JsD67CN5a08nF5oIL2bD6loTdHOuKw==} + engines: {node: '>= 5.10.0'} + brace-expansion@1.1.11: resolution: {integrity: sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==} brace-expansion@2.0.1: resolution: {integrity: sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==} - braces@3.0.3: - resolution: {integrity: sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==} + braces@3.0.2: + resolution: {integrity: sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==} engines: {node: '>=8'} brorand@1.1.0: @@ -1137,13 +1173,16 @@ packages: resolution: {integrity: sha512-9oR3zNdupcg/Ge2sSHQF3GX+kmvL/fTPvD0nd5AGLq8SjUYnTz+SlFjK/GXidndbZtIj+pVKXiWeR9w6e9wKCA==} engines: {node: '>=14.0.0'} + bundle-name@3.0.0: + resolution: {integrity: sha512-PKA4BeSvBpQKQ8iPOGCSiell+N8P+Tf1DlwqmYhpe2gAhKPHn8EYOxVT+ShuGmhg8lN8XiSlS80yiExKXrURlw==} + engines: {node: '>=12'} + busboy@1.6.0: resolution: {integrity: sha512-8SFQbg/0hQ9xy3UNTB0YEnsNBbWfhf7RtnzpL7TkBiTBRfrQ9Fxcnz7VJsleJpyp6rVLvXiuORqjlHi5q+PYuA==} engines: {node: '>=10.16.0'} - call-bind@1.0.7: - resolution: {integrity: sha512-GHTSNSYICQ7scH7sZ+M2rFopRoLh8t2bLSW6BbgrtLsahOIB5iyAVJf9GjWK3cYTDaMj4XdBpM1cA6pIS0Kv2w==} - engines: {node: '>= 0.4'} + call-bind@1.0.5: + resolution: {integrity: sha512-C3nQxfFZxFRVoJoGKKI8y3MOEo129NQ+FgQ08iye+Mk4zNZZGdjfs06bVTr+DBSlA66Q2VEcMki/cUCP4SercQ==} callsites@3.1.0: resolution: {integrity: sha512-P8BjAsXvZS+VIDUI11hHCQEv74YT67YUi5JJFNWIqL235sBmjX4+qx9Muvls5ivyNENctx46xQLQ3aTuE7ssaQ==} @@ -1152,8 +1191,8 @@ packages: camel-case@4.1.2: resolution: {integrity: sha512-gxGWBrTT1JuMx6R+o5PTXMmUnhnVzLQ9SNutD4YqKtI6ap897t3tKECYla6gCWEkplXnlNybEkZg9GEGxKFCgw==} - caniuse-lite@1.0.30001614: - resolution: {integrity: sha512-jmZQ1VpmlRwHgdP1/uiKzgiAuGOfLEJsYFP4+GBou/QQ4U6IOJCB4NP1c+1p9RGLpwObcT94jA5/uO+F1vBbog==} + caniuse-lite@1.0.30001669: + resolution: {integrity: sha512-DlWzFDJqstqtIVx1zeSpIMLjunf5SmwOw0N2Ck/QSQdS8PLS4+9HrLaYei4w8BIAL7IB/UEDu889d8vhCTPA0w==} capital-case@1.0.4: resolution: {integrity: sha512-ds37W8CytHgwnhGGTi88pcPyR15qoNkOpYwmMMfnWqqWgESapLqvDx6huFjQ5vqWSn2Z06173XNA7LtMOeUh1A==} @@ -1161,8 +1200,8 @@ packages: ccount@2.0.1: resolution: {integrity: sha512-eyrF0jiFpY+3drT6383f1qhkbGsLSifNAjA61IUjZjmLCWjItY6LB9ft9YhoDgwfmclB2zhu51Lc7+95b8NRAg==} - chai@4.4.1: - resolution: {integrity: sha512-13sOfMv2+DWduEU+/xbun3LScLoqN17nBeTLUsmDfKdoiC1fr0n9PU4guu4AhRcOVFk/sW8LyZWHuhWtQZiF+g==} + chai@4.3.10: + resolution: {integrity: sha512-0UXG04VuVbruMUYbJ6JctvH0YnC/4q3/AkT18q4NaITo91CUm0liMS9VqzT9vZhVQ/1eqPanMWjBM+Juhfb/9g==} engines: {node: '>=4'} chalk-template@1.1.0: @@ -1212,8 +1251,8 @@ packages: check-error@1.0.3: resolution: {integrity: sha512-iKEoDYaRmd1mxM90a2OEfWhjsjPpYPuQ+lMYsoxB126+t8fw7ySEO48nmDg5COTjxDI65/Y2OWpeEHk3ZOe8zg==} - ci-info@4.0.0: - resolution: {integrity: sha512-TdHqgGf9odd8SXNuxtUBVx8Nv+qZOejE6qyqiy5NtbYYQOeFa6zmHkxlPzmaLxWWHsU6nJmB7AETdVPi+2NBUg==} + ci-info@3.9.0: + resolution: {integrity: sha512-NIxF55hv4nSqQswkAeiOi1r83xy8JldOFDTWiug55KBu9Jnblncd2U6ViHmYgHf01TPZS77NJBhBMKdWj9HQMQ==} engines: {node: '>=8'} clear-module@4.1.2: @@ -1247,9 +1286,9 @@ packages: comma-separated-tokens@2.0.3: resolution: {integrity: sha512-Fu4hJdvzeylCfQPp9SGWidpzrMs7tTrlu6Vb8XGaRGck8QSNZJJp538Wrb60Lax4fPwR64ViY468OIUTbRlGZg==} - commander@12.0.0: - resolution: {integrity: sha512-MwVNWlYjDTtOjX5PiD7o5pK0UrFU/OYgcJfjjK4RaHZETNtjJqrZa9Y9ds88+A+f+d5lv+561eZ+yCKoS3gbAA==} - engines: {node: '>=18'} + commander@11.1.0: + resolution: {integrity: sha512-yPVavfyCcRhmorC7rWlkHn15b4wDVgVmBA7kV4QVBsF7kv/9TKJAbAXVTxvTnwP8HHKjRCJDClKbciiYS7p0DQ==} + engines: {node: '>=16'} commander@7.2.0: resolution: {integrity: sha512-QrWXB+ZQSVPmIWIhtEO9H+gwHaMGYiF5ChvoJ+K9ZGHG/sVsa6yiesAD1GC/x46sET00Xlwo1u49RVVVzvcSkw==} @@ -1286,6 +1325,9 @@ packages: cose-base@1.0.3: resolution: {integrity: sha512-s9whTXInMSgAp/NVXVNuVxVKzGH2qck3aQlVHxDCdAEPgtMKwc4Wq6/QKhgdEdgbLSi9rBTAcPoRa6JpiG4ksg==} + cose-base@2.2.0: + resolution: {integrity: sha512-AzlgcsCbUMymkADOJtQm3wO9S3ltPfYOFD5033keQn9NJzIbtnZj+UdBJe7DYml/8TdbtHJW3j58SOnKhWY/5g==} + cross-spawn@5.1.0: resolution: {integrity: sha512-pTgQJ5KC0d2hcY8eyL1IzlBPYjTkyH72XRZPnLyKus2mBfNjQs3klqbJU2VILqZryAZUt9JOb3h/mWMy23/f5A==} @@ -1300,55 +1342,60 @@ packages: resolution: {integrity: sha512-x8dy3RnvYdlUcPOjkEHqozhiwzKNSq7GcPuXFbnyMOCHxX8V3OgIg/pYuabl2sbUPfIJaeAQB7PMOK8DFIdoRA==} engines: {node: '>=12'} - cspell-config-lib@8.7.0: - resolution: {integrity: sha512-depsd01GbLBo71/tfRrL5iECWQLS4CjCxA9C01dVkFAJqVB0s+K9KLKjTlq5aHOhcvo9Z3dHV+bGQCf5/Q7bfw==} + cspell-config-lib@8.1.3: + resolution: {integrity: sha512-whzJYxcxos3vnywn0alCFZ+Myc0K/C62pUurfOGhgvIba7ArmlXhNRaL2r5noBxWARtpBOtzz3vrzSBK7Lq6jg==} engines: {node: '>=18'} - cspell-dictionary@8.7.0: - resolution: {integrity: sha512-S6IpZSzIMxlOO/33NgCOuP0TPH2mZbw8d5CP44z5jajflloq8l74MeJLkeDzYfCRcm0Rtk0A5drBeMg+Ai34OA==} + cspell-dictionary@8.1.3: + resolution: {integrity: sha512-nkRQDPNnA6tw+hJFBqq26M0nK306q5rtyv/AUIWa8ZHhQkwzACnpMSpuJA7/DV5GVvPKltMK5M4A6vgfpoaFHw==} engines: {node: '>=18'} - cspell-gitignore@8.7.0: - resolution: {integrity: sha512-yvUZ86qyopUpDgn+YXP1qTpUe/lp65ZFvpMtw21lWHTFlg1OWKntr349EQU/5ben/K6koxk1FiElCBV7Lr4uFg==} + cspell-gitignore@8.1.3: + resolution: {integrity: sha512-NHx5lg44eCKb6yJmUPOCz4prcuYowzoo5GJ5hOcCfbk7ZEBWV1E2/kDRuQMOK2W0y1hNGr45CSxO3UxWJlYg7w==} engines: {node: '>=18'} hasBin: true - cspell-glob@8.7.0: - resolution: {integrity: sha512-AMdfx0gvROA/aIL8t8b5Y5NtMgscGZELFj6WhCSZiQSuWRxXUKiLGGLUFjx2y0hgXN9LUYOo6aBjvhnxI/v71g==} + cspell-glob@8.1.3: + resolution: {integrity: sha512-Likr7UVUXBpthQnM5r6yao3X0YBNRbJ9AHWXTC2RJfzwZOFKF+pKPfeo3FU+Px8My96M4RC2bVMbrbZUwN5NJw==} engines: {node: '>=18'} - cspell-grammar@8.7.0: - resolution: {integrity: sha512-SGcXc7322wU2WNRi7vtpToWDXTqZHhxqvR+aIXHT2kkxlMSWp3Rvfpshd0ckgY54nZtgw7R/JtKND2jeACRpwQ==} + cspell-grammar@8.1.3: + resolution: {integrity: sha512-dTOwNq6a5wcVzOsi4xY5/tq2r2w/+wLVU+WfyySTsPe66Rjqx/QceFl4OinImks/ZMKF7Zyjd3WGyQ5TcSsJFQ==} engines: {node: '>=18'} hasBin: true - cspell-io@8.7.0: - resolution: {integrity: sha512-o7OltyyvVkRG1gQrIqGpN5pUkHNnv6rvihb7Qu6cJ8jITinLGuWJuEQpgt0eF5yIr624jDbFwSzAxsFox8riQg==} + cspell-io@8.1.3: + resolution: {integrity: sha512-QkcFeYd79oIl7PgSqFSZyvwXnZQhXmdCI733n54IN2+iXDcf7W0mwptxoC/cE19RkEwAwEFLG81UAy6L/BXI6A==} engines: {node: '>=18'} - cspell-lib@8.7.0: - resolution: {integrity: sha512-qDSHZGekwiDmouYRECTQokE+hgAuPqREm+Hb+G3DoIo3ZK5H47TtEUo8fNCw22XsKefcF8X28LiyoZwiYHVpSg==} + cspell-lib@8.1.3: + resolution: {integrity: sha512-Kk8bpHVkDZO4MEiPkDvRf/LgJ0h5mufbKLTWModq6k0Ca8EkZ/qgQlZ0ve0rIivbleSqebuWjpJHKDM+IHmzHA==} engines: {node: '>=18'} - cspell-trie-lib@8.7.0: - resolution: {integrity: sha512-W3Nh2cO7gMV91r+hLqyTMgKlvRl4W5diKs5YiyOxjZumRkMBy42IzcNYtgIIacOxghklv96F5Bd1Vx/zY6ylGA==} + cspell-trie-lib@8.1.3: + resolution: {integrity: sha512-EDSYU9MCtzPSJDrfvDrTKmc0rzl50Ehjg1c5rUCqn33p2LCRe/G8hW0FxXe0mxrZxrMO2b8l0PVSGlrCXCQ8RQ==} engines: {node: '>=18'} - cspell@8.7.0: - resolution: {integrity: sha512-77nRPgLl240C6FK8RKVKo34lP15Lzp/6bk+SKYJFwUKKXlcgWXDis+Lw4JolA741/JgHtuxmhW1C8P7dCKjJ3w==} + cspell@8.1.3: + resolution: {integrity: sha512-SU4Su6002bPoJYaiMeNV4wwLoS8TwaOgIwaTxhys3GDbJIxZV6CrDgwksezHcG7TZrC4yrveDVsdpnrzmQ7T5Q==} engines: {node: '>=18'} hasBin: true - csstype@3.1.3: - resolution: {integrity: sha512-M1uQkMl8rQK/szD0LNhtqxIPLpimGm8sOBwU7lLnCpSbTyY3yeU1Vc7l4KT5zT4s/yOxHH5O7tIuuLOCnLADRw==} + csstype@3.1.2: + resolution: {integrity: sha512-I7K1Uu0MBPzaFKg4nI5Q7Vs2t+3gWWW648spaF+Rg7pI9ds18Ugn+lvg4SHczUdKlHI5LWBXyqfS8+DufyBsgQ==} cytoscape-cose-bilkent@4.1.0: resolution: {integrity: sha512-wgQlVIUJF13Quxiv5e1gstZ08rnZj2XaLHGoFMYXz7SkNfCDOOteKBE6SYRfA9WxxI/iBc3ajfDoc6hb/MRAHQ==} peerDependencies: cytoscape: ^3.2.0 - cytoscape@3.29.2: - resolution: {integrity: sha512-2G1ycU28Nh7OHT9rkXRLpCDP30MKH1dXJORZuBhtEhEW7pKwgPi77ImqlCWinouyE1PNepIOGZBOrE84DG7LyQ==} + cytoscape-fcose@2.2.0: + resolution: {integrity: sha512-ki1/VuRIHFCzxWNrsshHYPs6L7TvLu3DL+TyIGEsRcvVERmxokbf5Gdk7mFxZnTdiGtnA4cfSmjZJMviqSuZrQ==} + peerDependencies: + cytoscape: ^3.2.0 + + cytoscape@3.27.0: + resolution: {integrity: sha512-pPZJilfX9BxESwujODz5pydeGi+FBrXq1rcaB1mfhFXXFJ9GjE6CNndAk+8jPzoXGD+16LtSS4xlYEIUiW4Abg==} engines: {node: '>=0.10'} d3-array@2.12.1: @@ -1411,8 +1458,8 @@ packages: resolution: {integrity: sha512-YyUI6AEuY/Wpt8KWLgZHsIU86atmikuoOmCfommt0LYHiQSPjvX2AcFc38PX0CBpr2RCyZhjex+NS/LPOv6YqA==} engines: {node: '>=12'} - d3-geo@3.1.1: - resolution: {integrity: sha512-637ln3gXKXOwhalDzinUgY83KzNWZRKbYubaG+fGVuc/dxO64RRljtCTnf5ecMyE1RIdtqpkVcq0IbtU2S8j2Q==} + d3-geo@3.1.0: + resolution: {integrity: sha512-JEo5HxXDdDYXCaWdwLRt79y7giK8SbhZJbFWXqbRTolCHFI5jRqteLzCsq51NKbUoX0PjBVSohxrx+NoOUujYA==} engines: {node: '>=12'} d3-hierarchy@3.1.2: @@ -1445,8 +1492,8 @@ packages: d3-sankey@0.12.3: resolution: {integrity: sha512-nQhsBRmM19Ax5xEIPLMY9ZmJ/cDvd1BG3UVvt5h3WRxKg5zGRbvnteTyWAbzeSvlh3tW7ZEmq4VwR5mB3tutmQ==} - d3-scale-chromatic@3.1.0: - resolution: {integrity: sha512-A3s5PWiZ9YCXFye1o246KoscMWqf8BsD9eRiJ3He7C9OBaxKhAd5TFCdEx/7VbKtxxTsu//1mMJFrEt572cEyQ==} + d3-scale-chromatic@3.0.0: + resolution: {integrity: sha512-Lx9thtxAKrO2Pq6OO2Ua474opeziKr279P/TKZsMAhYyNDD3EnCffdbgeSYN5O7m2ByQsxtuP2CSDczNUIZ22g==} engines: {node: '>=12'} d3-scale@4.0.2: @@ -1486,15 +1533,15 @@ packages: resolution: {integrity: sha512-b8AmV3kfQaqWAuacbPuNbL6vahnOJflOhexLzMMNLga62+/nh0JzvJ0aO/5a5MVgUFGS7Hu1P9P03o3fJkDCyw==} engines: {node: '>=12'} - d3@7.9.0: - resolution: {integrity: sha512-e1U46jVP+w7Iut8Jt8ri1YsPOvFpg46k+K8TpCb0P+zjCkjkPnV7WzfDJzMHy1LnA+wj5pLT1wjO901gLXeEhA==} + d3@7.8.5: + resolution: {integrity: sha512-JgoahDG51ncUfJu6wX/1vWQEqOflgXyl4MaHqlcSruTez7yhaRKR9i8VjjcQGeS2en/jnFivXuaIMnseMMt0XA==} engines: {node: '>=12'} dagre-d3-es@7.0.10: resolution: {integrity: sha512-qTCQmEhcynucuaZgY5/+ti3X/rnszKZhEQH/ZdWdtP1tA/y3VoHJzcVrO9pjjJCNpigfscAtoUB5ONcd2wNn0A==} - dayjs@1.11.11: - resolution: {integrity: sha512-okzr3f11N6WuqYtZSvm+F776mB41wRZMhKP+hc34YdW+KmtYYK9iqvHSwo2k9FEH3fhGXvOPV6yz2IcSrfRUDg==} + dayjs@1.11.10: + resolution: {integrity: sha512-vjAczensTgRcqDERK0SR2XMwsF/tSvnvlv6VcF2GIhg6Sx4yOIt/irsr1RDJsKiIyBzJDpCoXiWWq28MqH2cnQ==} debug@4.3.4: resolution: {integrity: sha512-PRWFHuSU3eDtQJPvnNY7Jcket1j0t5OuOsFzPPzsekD52Zl8qUfFIPEiswXqIvHWGVHOgX+7G/vCNNhehwxfkQ==} @@ -1519,16 +1566,28 @@ packages: deep-is@0.1.4: resolution: {integrity: sha512-oIPzksmTg4/MriiaYGO+okXDT7ztn/w3Eptv/+gSIdMdKsJo0u4CfYNFJPy+4SKMuCqGw2wxnA+URMg3t8a/bQ==} - define-data-property@1.1.4: - resolution: {integrity: sha512-rBMvIzlpA8v6E+SJZoo++HAYqsLrkg7MSfIinMPFhmkorw7X+dOXVJQs+QT69zGkzMyfDnIMN2Wid1+NbL3T+A==} + default-browser-id@3.0.0: + resolution: {integrity: sha512-OZ1y3y0SqSICtE8DE4S8YOE9UZOJ8wO16fKWVP5J1Qz42kV9jcnMVFrEE/noXb/ss3Q4pZIH79kxofzyNNtUNA==} + engines: {node: '>=12'} + + default-browser@4.0.0: + resolution: {integrity: sha512-wX5pXO1+BrhMkSbROFsyxUm0i/cJEScyNhA4PPxc41ICuv05ZZB/MX28s8aZx6xjmatvebIapF6hLEKEcpneUA==} + engines: {node: '>=14.16'} + + define-data-property@1.1.1: + resolution: {integrity: sha512-E7uGkTzkk1d0ByLeSc6ZsFS79Axg+m1P/VsgYsxHgiuc3tFSj+MjMIwe90FC4lOAZzNBdY7kkO2P2wKdsQ1vgQ==} engines: {node: '>= 0.4'} + define-lazy-prop@3.0.0: + resolution: {integrity: sha512-N+MeXYoqr3pOgn8xfyRPREN7gHakLYjhsHhWGT3fWAiL4IkAt0iDw14QiiEm2bE30c5XX5q0FtAA3CK5f9/BUg==} + engines: {node: '>=12'} + define-properties@1.2.1: resolution: {integrity: sha512-8QmQKqEASLd5nx0U1B1okLElbUuuttJ/AnYmRXbbbGDWh6uS208EjD4Xqq/I9wK7u0v6O08XhTWnt5XtEbR6Dg==} engines: {node: '>= 0.4'} - delaunator@5.0.1: - resolution: {integrity: sha512-8nvh+XBe96aCESrGOqMp/84b13H9cdKbG5P2ejQCh4d4sK9RL4371qou9drQjMhvnPmhWl5hnmqbEE0fXr9Xnw==} + delaunator@5.0.0: + resolution: {integrity: sha512-AyLvtyJdbv/U1GkiS6gUUzclRoAY4Gs75qkMygJJhU75LW4DNuSF2RMzpxs9jw9Oz1BobHjTdkG3zdP55VxAqw==} dequal@2.0.3: resolution: {integrity: sha512-0je+qPKHEMohvfRTCEo3CrPG6cAzAYgmzKyxRiYSSDkS6eGJdyVJm7WaYA5ECaAD9wLB2T4EEeymA5aFVcYXCA==} @@ -1537,8 +1596,8 @@ packages: devlop@1.1.0: resolution: {integrity: sha512-RWmIqhcFf1lRYBvNmr7qTNuyCt/7/ns2jbpp1+PalgE/rDQcBT0fioSMUpJ93irlUhC5hrg4cYqe6U+0ImW0rA==} - diff@5.2.0: - resolution: {integrity: sha512-uIFDxqpRZGZ6ThOk84hEfqWoHx2devRFvpTZcTHur85vImfaxUbTW9Ryh4CpCuDnToOP1CEtXKIgytHBPVff5A==} + diff@5.1.0: + resolution: {integrity: sha512-D+mk+qE8VC/PAUrlAU34N+VfXev0ghe5ywmpqrawphmVZc1bEfn56uo9qpyGp1p4xpzOHkSW4ztBd6L7Xx4ACw==} engines: {node: '>=0.3.1'} dir-glob@3.0.1: @@ -1552,8 +1611,8 @@ packages: dom-accessibility-api@0.5.16: resolution: {integrity: sha512-X7BJ2yElsnOJ30pZF4uIIDfBEVgF4XEBxL9Bxhy6dnrm5hkzqmsWHGTiHqRiITNhMyFLyAiWndIJP7Z1NTteDg==} - dompurify@3.1.1: - resolution: {integrity: sha512-tVP8C/GJwnABOn/7cx/ymx/hXpmBfWIPihC1aOEvS8GbMqy3pgeYtJk1HXN3CO7tu+8bpY18f6isjR5Cymj0TQ==} + dompurify@3.0.6: + resolution: {integrity: sha512-ilkD8YEnnGh1zJ240uJsW7AzE+2qpbOUYjacomn3AvJ6J4JhKGSZ2nh4wUIXPZrEPppaCLx5jFe8T89Rk8tQ7w==} dot-case@3.0.4: resolution: {integrity: sha512-Kv5nKlh6yRrdrGvxeJ2e5y2eRUpkUosIW4A2AS38zwSz27zu7ufDwQPi5Jhs3XAlGNetl3bmnGhQsMtkKJnj3w==} @@ -1565,8 +1624,8 @@ packages: eastasianwidth@0.2.0: resolution: {integrity: sha512-I88TYZWc9XiYHRQ4/3c5rjjfgkjhLyW2luGIheGERbNQ6OY7yTybanSpDXZa8y7VUP9YmDcYa+eyq4ca7iLqWA==} - elkjs@0.9.3: - resolution: {integrity: sha512-f/ZeWvW/BCXbhGEf1Ujp29EASo/lk1FDnETgNKwJrsVvGZhUWCZyg3xLJjAsxfOmt8KjswHmI5EwCQcPMpOYhQ==} + elkjs@0.8.2: + resolution: {integrity: sha512-L6uRgvZTH+4OF5NE/MBbzQx/WYpru1xCBE9respNj6qznEewGUIfhzmm7horWWxbNO2M0WckQypGctR8lH79xQ==} elliptic@6.5.4: resolution: {integrity: sha512-iLhC6ULemrljPZb+QutR5TQGB+pdW6KGD5RSegS+8sorOZT+rdQFbsQFJgvN3eRqNALqJer4oQ16YvJHlU8hzQ==} @@ -1587,14 +1646,6 @@ packages: error-ex@1.3.2: resolution: {integrity: sha512-7dFHNmqeFSEt2ZBsCriorKnn3Z2pj+fd9kmI6QoWw4//DL+icEBfc0U7qJCisqrTsKTjw4fNFy2pW9OqStD84g==} - es-define-property@1.0.0: - resolution: {integrity: sha512-jxayLKShrEqqzJ0eumQbVhTYQM27CfT1T35+gCgDFoL82JLsXqTJ76zv6A0YLOgEnLUMvLzsDsGIrl8NFpT2gQ==} - engines: {node: '>= 0.4'} - - es-errors@1.3.0: - resolution: {integrity: sha512-Zf5H2Kxt2xjTvbJvP2ZWLEICxA6j+hAmMzIlypy4xcBg1vKVnx89Wy0GbS+kf5cwCVFFzdCFh2XSCFNULS6csw==} - engines: {node: '>= 0.4'} - es-get-iterator@1.1.3: resolution: {integrity: sha512-sPZmqHBe6JIiTfN5q2pEi//TwxmAFHwj/XEuYjTuse78i8KxaqMTTzxPoFKuzRpDpTJ+0NAbpfenkmH2rePtuw==} @@ -1610,8 +1661,8 @@ packages: resolution: {integrity: sha512-/veY75JbMK4j1yjvuUxuVsiS/hr/4iHs9FTT6cgTexxdE0Ly/glccBAkloH/DofkjRbZU3bnoj38mOmhkZ0lHw==} engines: {node: '>=12'} - eslint-mdx@2.3.4: - resolution: {integrity: sha512-u4NszEUyoGtR7Q0A4qs0OymsEQdCO6yqWlTzDa9vGWsK7aMotdnW0hqifHTkf6lEtA2vHk2xlkWHTCrhYLyRbw==} + eslint-mdx@2.2.0: + resolution: {integrity: sha512-AriN6lCW6KhWQ9GEiXapR1DokKHefOUqKvCmHxnE9puCWYhWiycU2SNKH8jmrasDBreZ+RtJDLi+RcUNLJatjg==} engines: {node: ^12.20.0 || ^14.18.0 || >=16.0.0} peerDependencies: eslint: '>=8.0.0' @@ -1622,8 +1673,8 @@ packages: peerDependencies: eslint: ^6.0.0 || ^7.0.0 || ^8.0.0 - eslint-plugin-mdx@2.3.4: - resolution: {integrity: sha512-kr6tgaifKL+AVGYMtdYc2VCsIjfYQXuUCKz4rK58d2DpnPFHrmgXIOC7NcMvaEld+VOEpxBSCCnjnsf4IVCQGg==} + eslint-plugin-mdx@2.2.0: + resolution: {integrity: sha512-OseoMXUIr8iy3E0me+wJLVAxuB0kxHP1plxuYAJDynzorzOj2OKv8Fhr+rIOJ32zfl3bnEWsqFnUiCnyznr1JQ==} engines: {node: ^12.20.0 || ^14.18.0 || >=16.0.0} peerDependencies: eslint: '>=8.0.0' @@ -1636,8 +1687,8 @@ packages: resolution: {integrity: sha512-wpc+LXeiyiisxPlEkUzU6svyS1frIO3Mgxj1fdy7Pm8Ygzguax2N3Fa/D/ag1WqbOprdI+uY6wMUl8/a2G+iag==} engines: {node: ^12.22.0 || ^14.17.0 || >=16.0.0} - eslint@8.57.0: - resolution: {integrity: sha512-dZ6+mexnaTIbSBZWgou51U6OmzIhYM2VcNdtiTtI7qPNZm35Akpr0f6vtw3w1Kmn5PYo+tZVfh13WrhpS6oLqQ==} + eslint@8.54.0: + resolution: {integrity: sha512-NY0DfAkM8BIZDVl6PgSa1ttZbx3xHgJzSNJKYcQglem6CppHyMhRIQkBVSSMaSRnLhig3jsDbEzOjwCVt4AmmA==} engines: {node: ^12.22.0 || ^14.17.0 || >=16.0.0} hasBin: true @@ -1688,12 +1739,11 @@ packages: resolution: {integrity: sha512-kVscqXk4OCp68SZ0dkgEKVi6/8ij300KBWTJq32P/dYeWTSwK41WyTxalN1eRmA5Z9UU/LX9D7FWSmV9SAYx6g==} engines: {node: '>=0.10.0'} - ethereum-bloom-filters@1.1.0: - resolution: {integrity: sha512-J1gDRkLpuGNvWYzWslBQR9cDV4nd4kfvVTE/Wy4Kkm4yb3EYRSlyi0eB/inTsSTTVyA0+HyzHgbr95Fn/Z1fSw==} - deprecated: do not use this package use package versions above as this can miss some topics + ethereum-bloom-filters@1.0.10: + resolution: {integrity: sha512-rxJ5OFN3RwjQxDcFP2Z5+Q9ho4eIdEmSc2ht0fCu8Se9nbXjZ7/031uXoUYJ87KHCOdVeiUuwSnoS7hmYAGVHA==} - ethereum-cryptography@2.1.3: - resolution: {integrity: sha512-BlwbIL7/P45W8FGW2r7LGuvoEZ+7PWsniMvQ4p5s2xCyw9tmaDlpfsN9HjAucbF+t/qpVHwZUisgfK24TCW8aA==} + ethereum-cryptography@2.1.2: + resolution: {integrity: sha512-Z5Ba0T0ImZ8fqXrJbpHcbpAvIswRte2wGNR/KePnu8GbbvgJ47lMxT/ZZPG6i9Jaht4azPDop4HaM00J0J59ug==} ethers@5.7.2: resolution: {integrity: sha512-wswUsmWo1aOK8rR7DIKiWSw9DbLWe6x98Jrn8wcTflTVvaXhAMaB5zGAXy0GYQEQp9iO1iSHWVyARQm11zUtyg==} @@ -1706,6 +1756,14 @@ packages: resolution: {integrity: sha512-zDWS+Rb1E8BlqqhALSt9kUhss8Qq4nN3iof3gsOdyINksElaPyNBtKUMTR62qhvgVWR0CqCX7sdnKe4MnUbFEA==} engines: {node: '>=4'} + execa@5.1.1: + resolution: {integrity: sha512-8uSpZZocAZRBAPIEINJj3Lo9HyGitllczc27Eh5YYojjMFMn8yHMDMaUHE2Jqfq05D/wucwI4JGURyXt1vchyg==} + engines: {node: '>=10'} + + execa@7.2.0: + resolution: {integrity: sha512-UduyVP7TLB5IcAQl+OzLyLcS/l32W/GLg+AhHJ+ow40FOk2U3SAllPwR44v4vmdFwIWqpdwxxpQbF1n5ta9seA==} + engines: {node: ^14.18.0 || ^16.14.0 || >=18.0.0} + extend-shallow@2.0.1: resolution: {integrity: sha512-zCnTtlxNoAiDc3gqY2aYAWFx7XWWiasuF2K8Me5WbN8otHKTUKBwjPtNpRs/rbUZm7KxWAaNj7P1a/p52GbVug==} engines: {node: '>=0.10.0'} @@ -1730,8 +1788,8 @@ packages: fast-levenshtein@2.0.6: resolution: {integrity: sha512-DCXu6Ifhqcks7TZKY3Hxp3y6qphY5SJZmrWMDrKcERSOXWQdMhU9Ig/PYrzyw/ul9jOIyh0N4M0tbC5hodg8dw==} - fastq@1.17.1: - resolution: {integrity: sha512-sRVD3lWVIXWg6By68ZN7vho9a1pQcN/WBFaAAsDDFzlJjvoGx0P8z7V1t72grFJfJhu3YPZBuu25f7Kaw2jN1w==} + fastq@1.15.0: + resolution: {integrity: sha512-wBrocU2LCXXa+lWBt8RoIRD89Fi8OdABODa/kEnyeyjS5aZO5/GNvI5sEINADqP/h8M29UHTHUb53sUu5Ihqdw==} fault@2.0.1: resolution: {integrity: sha512-WtySTkS4OKev5JtpHXnib4Gxiurzh5NCGvWrFaZ34m6JehfTUhKZvn9njTfw48t6JumVQOmrKqpmGcdwxnhqBQ==} @@ -1740,12 +1798,12 @@ packages: resolution: {integrity: sha512-7Gps/XWymbLk2QLYK4NzpMOrYjMhdIxXuIvy2QBsLE6ljuodKvdkWs/cpyJJ3CVIVpH0Oi1Hvg1ovbMzLdFBBg==} engines: {node: ^10.12.0 || >=12.0.0} - file-entry-cache@8.0.0: - resolution: {integrity: sha512-XXTUwCvisa5oacNGRP9SfNtYBNAMi+RPwBFmblZEF7N7swHYQS6/Zfk7SRwx4D5j3CH211YNRco1DEMNVfZCnQ==} - engines: {node: '>=16.0.0'} + file-entry-cache@7.0.2: + resolution: {integrity: sha512-TfW7/1iI4Cy7Y8L6iqNdZQVvdXn0f8B4QcIXmkIbtTIe/Okm/nSlHb4IwGzRVOd3WfSieCgvf5cMzEfySAIl0g==} + engines: {node: '>=12.0.0'} - fill-range@7.1.1: - resolution: {integrity: sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==} + fill-range@7.0.1: + resolution: {integrity: sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==} engines: {node: '>=8'} find-up-simple@1.0.0: @@ -1764,15 +1822,11 @@ packages: resolution: {integrity: sha512-CYcENa+FtcUKLmhhqyctpclsq7QF38pKjZHsGNiSQF5r4FtoKDWabFDl3hzaEQMvT1LHEysw5twgLvpYYb4vbw==} engines: {node: ^10.12.0 || >=12.0.0} - flat-cache@4.0.1: - resolution: {integrity: sha512-f7ccFPK3SXFHpx15UIGyRJ/FJQctuKZ0zVuN3frBo4HnK3cay9VEW0R6yPYFHC0AgqhukPzKjq22t5DmAyqGyw==} - engines: {node: '>=16'} - - flatted@3.3.1: - resolution: {integrity: sha512-X8cqMLLie7KsNUDSdzeN8FYK9rEt4Dt67OsG/DNGnYTSDBG4uFAJFBnUeiV+zCVAvwFy56IjM9sH51jVaEhNxw==} + flatted@3.2.9: + resolution: {integrity: sha512-36yxDn5H7OFZQla0/jFJmbIKTdZAQHngCedGxiMmpNfEZM0sdEeT+WczLQrjK6D7o2aiyLYDnkw0R3JK0Qv1RQ==} - flexsearch@0.7.43: - resolution: {integrity: sha512-c5o/+Um8aqCSOXGcZoqZOm+NqtVwNsvVpWv6lfmSclU954O3wvQKxxK8zj74fPaSJbXpSLTs4PRhh+wnoCXnKg==} + flexsearch@0.7.31: + resolution: {integrity: sha512-XGozTsMPYkm+6b5QL3Z9wQcJjNYxp0CYn3U1gO7dwD6PAqU1SVWZxI9CCg3z+ml3YfqdPnrBehaBrnH2AGKbNA==} focus-visible@5.2.0: resolution: {integrity: sha512-Rwix9pBtC1Nuy5wysTmKy+UjbDJpIfg8eHjw0rjZ1mX4GNLz1Bmd16uDpI3Gk1i70Fgcs8Csg2lPm8HULFg9DQ==} @@ -1797,16 +1851,15 @@ packages: functions-have-names@1.2.3: resolution: {integrity: sha512-xckBUXyTIqT97tq2x2AMb+g163b5JFysYk0x4qxNFwbfQkmNZoiRHb6sPzI9/QV33WeuvVYBUIiD4NzNIyqaRQ==} - gensequence@7.0.0: - resolution: {integrity: sha512-47Frx13aZh01afHJTB3zTtKIlFI6vWY+MYCN9Qpew6i52rfKjnhCF/l1YlC8UmEMvvntZZ6z4PiCcmyuedR2aQ==} - engines: {node: '>=18'} + gensequence@6.0.0: + resolution: {integrity: sha512-8WwuywE9pokJRAcg2QFR/plk3cVPebSUqRPzpGQh3WQ0wIiHAw+HyOQj5IuHyUTQBHpBKFoB2JUMu9zT3vJ16Q==} + engines: {node: '>=16'} get-func-name@2.0.2: resolution: {integrity: sha512-8vXOvuE167CtIc3OyItco7N/dpRtBbYOsPsXCz7X/PMnlGjYjSGuZJgM1Y7mmew7BKf9BqvLX2tnOVy1BBUsxQ==} - get-intrinsic@1.2.4: - resolution: {integrity: sha512-5uYhsJH8VJBTv7oslg4BznJYhDoRI6waYCxMmCdnTrcCrHA/fCFKoTFz2JKKE0HdDFUF7/oQuhzumXJK7paBRQ==} - engines: {node: '>= 0.4'} + get-intrinsic@1.2.2: + resolution: {integrity: sha512-0gSo4ml/0j98Y3lngkFEot/zhiCeWsbYIlZ+uZOVgzLyLaUw7wxUL+nCTP0XJvJg1AXulJRI3UJi8GsbDuxdGA==} get-stdin@9.0.0: resolution: {integrity: sha512-dVKBjfWisLAicarI2Sf+JuBE/DghV4UzNAVe9yhEJuzeREd3JhOTE9cUaJTeSa77fsbQUK3pcOpJfM59+VKZaA==} @@ -1816,6 +1869,10 @@ packages: resolution: {integrity: sha512-GlhdIUuVakc8SJ6kK0zAFbiGzRFzNnY4jUuEbV9UROo4Y+0Ny4fjvcZFVTeDA4odpFyOQzaw6hXukJSq/f28sQ==} engines: {node: '>=4'} + get-stream@6.0.1: + resolution: {integrity: sha512-ts6Wi+2j3jQjqi70w5AlN8DFnkSwC+MqmxEzdEALB2qXZYV3X/b1CTfgPLGJNMeAWxdPfU8FO1ms3NUfaHCPYg==} + engines: {node: '>=10'} + git-up@7.0.0: resolution: {integrity: sha512-ONdIrbBCFusq1Oy0sC71F5azx8bVkvtZtMJAsv+a6lz5YAmbNnLD6HAB4gptHZVLPR8S2/kVN6Gab7lryq5+lQ==} @@ -1836,33 +1893,28 @@ packages: resolution: {integrity: sha512-XxwI8EOhVQgWp6iDL+3b0r86f4d6AX6zSU55HfB4ydCEuXLXc5FcYeOu+nnGftS4TEju/11rt4KJPTMgbfmv4A==} engines: {node: '>=10.13.0'} - glob-to-regexp@0.4.1: - resolution: {integrity: sha512-lkX1HJXwyMcprw/5YUZc2s7DrpAiHB21/V+E1rHUrVNokkvB6bqMzT0VfV6/86ZNabt1k14YOIaT7nDvOX3Iiw==} - - glob@10.3.12: - resolution: {integrity: sha512-TCNv8vJ+xz4QiqTpfOJA7HvYv+tNIRHKfUWw/q+v2jdgN4ebz+KY9tGx5J4rHP0o84mNP+ApH66HRX8us3Khqg==} + glob@10.3.10: + resolution: {integrity: sha512-fa46+tv1Ak0UPK1TOy/pZrIybNNt4HCv7SDzwyfiOZkvZLEbjsZkJBPtDHVshZjbecAoAGSC20MjLDG/qr679g==} engines: {node: '>=16 || 14 >=14.17'} hasBin: true glob@7.2.3: resolution: {integrity: sha512-nFR0zLpU2YCaRxwoCJvL6UvCH2JFyFVIvwTLsIf21AuHlMskA1hhTdk+LlYJtOlYt9v6dvszD2BGRqBL+iQK9Q==} - deprecated: Glob versions prior to v9 are no longer supported glob@8.1.0: resolution: {integrity: sha512-r8hpEjiQEYlF2QU0df3dS+nxxSIreXQS1qRhMJM0Q5NDdR386C7jb7Hwwod8Fgiuex+k0GFjgft18yvxm5XoCQ==} engines: {node: '>=12'} - deprecated: Glob versions prior to v9 are no longer supported global-directory@4.0.1: resolution: {integrity: sha512-wHTUcDUoZ1H5/0iVqEudYW4/kAlN5cZ3j/bXn0Dpbizl9iaUVeWSHqiOjsgk6OW2bkLclbBjzewBz6weQ1zA2Q==} engines: {node: '>=18'} - globals@13.24.0: - resolution: {integrity: sha512-AhO5QUcj8llrbG09iWhPU2B204J1xnPeL8kQmVorSsy+Sjj1sk8gIyh6cUocGmH4L0UuhAJy+hJMRA4mgA4mFQ==} + globals@13.23.0: + resolution: {integrity: sha512-XAmF0RjlrjY23MA51q3HltdlGxUpXPvg0GioKiD9X6HD28iMjo2dKC8Vqwm7lne4GNr78+RHTfliktR6ZH09wA==} engines: {node: '>=8'} - globby@11.1.0: - resolution: {integrity: sha512-jhIXaOzy1sb8IyocaruWSn1TjmnBVs8Ayhcy83rmxNJ8q2uWKCAj3CnJY+KpGSXCueAPc0i05kVvVKtP1t9S3g==} + globby@11.0.4: + resolution: {integrity: sha512-9O4MVG9ioZJ08ffbcyVYyLOJLk5JQ688pJ4eMGLpdWLHq/Wr1D9BlriLQyL0E+jbkuePVZXYFj47QM/v093wHg==} engines: {node: '>=10'} gopd@1.0.1: @@ -1897,19 +1949,19 @@ packages: resolution: {integrity: sha512-Pq0h+hvsVm6dDEa8x82GnLSYHOzNDt7f0ddFa3FqcQlgzEiptPqL+XrOJNavjOzSYiYWIrgeVYYgGlLmnxwilQ==} engines: {node: '>=8'} - has-property-descriptors@1.0.2: - resolution: {integrity: sha512-55JNKuIW+vq4Ke1BjOTjM2YctQIvCT7GFzHwmfZPGo5wnrgkid0YQtnAleFSqumZm4az3n2BS+erby5ipJdgrg==} + has-property-descriptors@1.0.1: + resolution: {integrity: sha512-VsX8eaIewvas0xnvinAe9bw4WfIeODpGYikiWYLH+dma0Jw6KHYqWiWfhQlgOVK8D6PvjubK5Uc4P0iIhIcNVg==} - has-proto@1.0.3: - resolution: {integrity: sha512-SJ1amZAJUiZS+PhsVLf5tGydlaVB8EdFpaSO4gmiUKUOxk8qzn5AIy4ZeJUmh22znIdk/uMAUT2pl3FxzVUH+Q==} + has-proto@1.0.1: + resolution: {integrity: sha512-7qE+iP+O+bgF9clE5+UoBFzE65mlBiVj3tKCrlNQ0Ogwm0BjpT/gK4SlLYDMybDh5I3TCTKnPPa0oMG7JDYrhg==} engines: {node: '>= 0.4'} has-symbols@1.0.3: resolution: {integrity: sha512-l3LCuF6MgDNwTDKkdYGEihYjt5pRPbEg46rtlmnSPlUbgmB8LOIrKJbYYFBSbnPaJexMKtiPO8hmeRjRz2Td+A==} engines: {node: '>= 0.4'} - has-tostringtag@1.0.2: - resolution: {integrity: sha512-NqADB8VjPFLM2V0VvHUewwwsw0ZWBaIdgo+ieHtK3hasLz4qeCRjYcqfB6AQrBggRKppKF8L52/VqdVsO47Dlw==} + has-tostringtag@1.0.0: + resolution: {integrity: sha512-kFjcSNhnlGV1kyoGk7OXKSawH5JOb/LzUc5w9B02hOTO0dfFRjbHQKvg1d6cf3HbeUmtU9VbbV3qzZ2Teh97WQ==} engines: {node: '>= 0.4'} hash-obj@4.0.0: @@ -1919,8 +1971,8 @@ packages: hash.js@1.1.7: resolution: {integrity: sha512-taOaskGt4z4SOANNseOviYDvjEJinIkRgmp7LbKP2YTTmVxWBl87s/uzK9r+44BclBSp2X7K1hqeNfz9JbBeXA==} - hasown@2.0.2: - resolution: {integrity: sha512-0hJU9SCPvmMzIBdZFqNPXWa6dqh7WdH0cII9y+CyS8rG3nL48Bclra9HmKhVVUHyPWNH5Y7xDwAB7bfgSjkUMQ==} + hasown@2.0.0: + resolution: {integrity: sha512-vUptKVTpIJhcczKBbgnS+RtcuYMB8+oNzPK2/Hp3hanz8JmpATdmmgLgSaadVREkDm+e2giHwY3ZRkyjSIDDFA==} engines: {node: '>= 0.4'} hast-util-from-dom@5.0.0: @@ -1941,8 +1993,8 @@ packages: hast-util-parse-selector@4.0.0: resolution: {integrity: sha512-wkQCkSYoOGCRKERFWcxMVMOcYE2K1AaNLU8DXS9arxnLOUEWbOXKXiJUNzEpqZ3JOKpnha3jkFrumEjVliDe7A==} - hast-util-raw@9.0.2: - resolution: {integrity: sha512-PldBy71wO9Uq1kyaMch9AHIghtQvIwxBUkv823pKmkTM3oV1JxtsTNYdevMxvUHqcnOAuO65JKU2+0NOxc2ksA==} + hast-util-raw@9.0.1: + resolution: {integrity: sha512-5m1gmba658Q+lO5uqL5YNGQWeh1MYWZbZmWrM5lncdcuiXuo5E2HT/CIOp0rLF8ksfSwiCVJ3twlgVRyTGThGA==} hast-util-to-estree@2.3.3: resolution: {integrity: sha512-ihhPIUPxN0v0w6M5+IiAZZrn0LH2uZomeWwhn7uP7avZC6TE7lIiEh2yBMPr5+zi1aUCXq6VoYRgs2Bw9xmycQ==} @@ -1950,8 +2002,8 @@ packages: hast-util-to-parse5@8.0.0: resolution: {integrity: sha512-3KKrV5ZVI8if87DVSi1vDeByYrkGzg4mEfeu4alwgmmIeARiBLKCZS2uw5Gb6nU9x9Yufyj3iudm6i7nl52PFw==} - hast-util-to-text@4.0.2: - resolution: {integrity: sha512-KK6y/BN8lbaq654j7JgBydev7wuNMcID54lkRav1P0CaE1e47P72AWWPiGKXTJU271ooYzcvTAn/Zt0REnvc7A==} + hast-util-to-text@4.0.0: + resolution: {integrity: sha512-EWiE1FSArNBPUo1cKWtzqgnuRQwEeQbQtnFJRYV1hb1BWDgrAlBU0ExptvZMM/KSA82cDpm2sFGf3Dmc5Mza3w==} hast-util-whitespace@2.0.1: resolution: {integrity: sha512-nAxA0v8+vXSBDt3AnRUNjyRIQ0rD+ntpbAp4LnPkumc5M9yUbSMa4XDU9Q6etY4f1Wp4bNgvc1yjiZtsTTrSng==} @@ -1962,18 +2014,29 @@ packages: header-case@2.0.4: resolution: {integrity: sha512-H/vuk5TEEVZwrR0lp2zed9OCo1uAILMlx0JEMgC26rzyJJ3N1v6XkwHHXJQdR2doSjcGPM6OKPYoJgf0plJ11Q==} + heap@0.2.7: + resolution: {integrity: sha512-2bsegYkkHO+h/9MGbn6KWcE45cHZgPANo5LXF7EvWdT0yT2EguSVO1nDgU5c8+ZOPwp2vMNa7YFsJhVcDR9Sdg==} + hmac-drbg@1.0.1: resolution: {integrity: sha512-Tti3gMqLdZfhOQY1Mzf/AanLiqh1WTiJgEj26ZuYQ9fbkLomzGchCws4FyrSd4VkpBfiNhaE1On+lOz894jvXg==} html-void-elements@3.0.0: resolution: {integrity: sha512-bEqo66MRXsUGxWHV5IP0PUiAWwoEjba4VCzg0LjFJBpchPaTfyfCKTG6bc5F8ucKec3q5y6qOdGyYTSBEvhCrg==} + human-signals@2.1.0: + resolution: {integrity: sha512-B4FFZ6q/T2jhhksgkbEW3HBvWIfDW85snkQgawt07S7J5QXTk6BkNV+0yAeZrM5QpMAdYlocGoljn0sJ/WQkFw==} + engines: {node: '>=10.17.0'} + + human-signals@4.3.1: + resolution: {integrity: sha512-nZXjEF2nbo7lIw3mgYjItAfgQXog3OjJogSbKa2CQIIvSGWcKgeJnQlNXip6NglNzYH45nSRiEVimMvYL8DDqQ==} + engines: {node: '>=14.18.0'} + iconv-lite@0.6.3: resolution: {integrity: sha512-4fCk79wshMdzMp2rH06qWrJE4iolqLhCUH+OiuIgU++RB0+94NlDL81atO7GX55uUKueo0txHNtvEyI6D7WdMw==} engines: {node: '>=0.10.0'} - ignore@5.3.1: - resolution: {integrity: sha512-5Fytz/IraMjqpwfd34ke28PTVMjZjJG2MPn5t7OE4eUCUNf8BAa7b5WUS9/Qvr6mwOQS7Mk6vdsMno5he+T8Xw==} + ignore@5.3.0: + resolution: {integrity: sha512-g7dmpshy+gD7mh88OC9NwSGTKoc3kyLAZQRU1mt53Aw/vnvfXnbC+F/7F7QoYVKbV+KNvJx8wArewKy1vXMtlg==} engines: {node: '>= 4'} import-fresh@3.3.0: @@ -1983,8 +2046,8 @@ packages: import-meta-resolve@2.2.2: resolution: {integrity: sha512-f8KcQ1D80V7RnqVm+/lirO9zkOxjGxhaTC1IPrBGd3MEfNgmNG67tSUO9gTi2F3Blr2Az6g1vocaxzkVnWl9MA==} - import-meta-resolve@4.1.0: - resolution: {integrity: sha512-I6fiaX09Xivtk+THaMfAwnA3MVA5Big1WHF1Dfx9hFuvNIWpXnorlkzhcQf6ehrqQiiZECRt1poOAkPmer3ruw==} + import-meta-resolve@4.0.0: + resolution: {integrity: sha512-okYUR7ZQPH+efeuMJGlq4f8ubUgO50kByRPyt/Cy1Io4PSRsPjxME+YlVaCOx+NIToW7hCsZNFJyTPFFKepRSA==} imurmurhash@0.1.4: resolution: {integrity: sha512-JmXMZ6wuvDmLiHEml9ykzqO6lwFbof0GG4IkcGaENdCRDDmMVnny7s5HsIgHCbaq0w2MyPhDqkhTUgS2LU2PHA==} @@ -1992,7 +2055,6 @@ packages: inflight@1.0.6: resolution: {integrity: sha512-k92I/b08q4wvFscXCLvqfsHCrjrF7yiXsQuIVvVE7N82W3+aqpzuUdBbfhWcy/FZR3/4IgflMgKLOsvPDrGCJA==} - deprecated: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful. inherits@2.0.4: resolution: {integrity: sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==} @@ -2001,15 +2063,11 @@ packages: resolution: {integrity: sha512-QQnnxNyfvmHFIsj7gkPcYymR8Jdw/o7mp5ZFihxn6h8Ci6fh3Dx4E1gPjpQEpIuPo9XVNY/ZUwh4BPMjGyL01g==} engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0} - ini@4.1.2: - resolution: {integrity: sha512-AMB1mvwR1pyBFY/nSevUX6y8nJWS63/SzUKD3JyQn97s4xgIdgQPT75IRouIiBAN4yLQBUShNYVW0+UG25daCw==} - engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0} - inline-style-parser@0.1.1: resolution: {integrity: sha512-7NXolsK4CAS5+xvdj5OMMbI962hU/wvwoxk+LWR9Ek9bVtyuuYScDN6eS0rUm6TxApFpw7CX1o4uJzcd4AyD3Q==} - internal-slot@1.0.7: - resolution: {integrity: sha512-NGnrKwXzSms2qUUih/ILZ5JBqNTSa1+ZmP6flaIp6KmSElgE9qdndzS3cqjrDovwFdmwsGsLdeFgB6suw+1e9g==} + internal-slot@1.0.6: + resolution: {integrity: sha512-Xj6dv+PsbtwyPpEflsejS+oIZxmMlV44zAhG479uYu89MsjcYOhCFnNyKrkJrihbsiasQyY0afoCl/9BLR65bg==} engines: {node: '>= 0.4'} internmap@1.0.1: @@ -2038,9 +2096,8 @@ packages: resolution: {integrity: sha512-8Q7EARjzEnKpt/PCD7e1cgUS0a6X8u5tdSiMqXhojOdoV9TsMsiO+9VLC5vAmO8N7/GmXn7yjR8qnA6bVAEzfA==} engines: {node: '>= 0.4'} - is-array-buffer@3.0.4: - resolution: {integrity: sha512-wcjaerHw0ydZwfhiKbXJWLDY8A7yV7KhjQOpb83hGgGfId/aQa4TOvwyzn2PuswW2gPCYEL/nEAiSVpdOj1lXw==} - engines: {node: '>= 0.4'} + is-array-buffer@3.0.2: + resolution: {integrity: sha512-y+FyyR/w8vfIRq4eQcM1EYgSTnmHXPqaF+IgzgraytCFq5Xh8lllDVmAZolPJiZttZLeFSINPYMaEJ7/vWUa1w==} is-arrayish@0.2.1: resolution: {integrity: sha512-zz06S8t0ozoDXMG+ube26zeCTNXcKIPJZJi8hBrF4idCLms4CG9QtK7qBl1boi5ODzFpjswb5JPmHCbMpjaYzg==} @@ -2070,6 +2127,16 @@ packages: is-decimal@2.0.1: resolution: {integrity: sha512-AAB9hiomQs5DXWcRB1rqsxGUstbRroFOPPVAomNk/3XHR5JyEZChOyTWe2oayKnsSsr/kcGqF+z6yuH6HHpN0A==} + is-docker@2.2.1: + resolution: {integrity: sha512-F+i2BKsFrH66iaUFc0woD8sLy8getkwTwtOBjvs56Cx4CgJDeKQeqfz8wAYiSb8JOprWhHH5p77PbmYCvvUuXQ==} + engines: {node: '>=8'} + hasBin: true + + is-docker@3.0.0: + resolution: {integrity: sha512-eljcgEDlEns/7AXFosB5K/2nCM4P7FQPkGc/DWLy5rmFEWvZayGrik1d9/QIY5nJ4f9YsVvBkA6kJpHn9rISdQ==} + engines: {node: ^12.20.0 || ^14.13.1 || >=16.0.0} + hasBin: true + is-empty@1.2.0: resolution: {integrity: sha512-F2FnH/otLNJv0J6wc73A5Xo7oHLNnqplYqZhUu01tD54DIPvxIRSTSLkrUB/M0nHO4vo1O9PDfN4KoTxCzLh/w==} @@ -2099,9 +2166,13 @@ packages: is-hexadecimal@2.0.1: resolution: {integrity: sha512-DgZQp241c8oO6cA1SbTEWiXeoxV42vlcJxgH+B3hi1AiqqKruZR3ZGF8In3fj4+/y/7rHvlOZLZtgJ/4ttYGZg==} - is-map@2.0.3: - resolution: {integrity: sha512-1Qed0/Hr2m+YqxnM09CjA2d/i6YZNfF6R2oRAOj36eUdS6qIV/huPJNSEpKbupewFs+ZsJlxsjjPbc0/afW6Lw==} - engines: {node: '>= 0.4'} + is-inside-container@1.0.0: + resolution: {integrity: sha512-KIYLCCJghfHZxqjYBE7rEy0OBuTd5xCHS7tHVgvCLkx7StIoaxwNW3hCALgEUjFfeRk+MG/Qxmp/vtETEF3tRA==} + engines: {node: '>=14.16'} + hasBin: true + + is-map@2.0.2: + resolution: {integrity: sha512-cOZFQQozTha1f4MxLFzlgKYPTyj26picdZTx82hbc/Xf4K/tZOOXSCkMvU4pKioRXGDLJRn0GM7Upe7kR721yg==} is-number-object@1.0.7: resolution: {integrity: sha512-k1U0IRzLMo7ZlYIfzRu23Oh6MiIFasgpb9X76eqfFZAqwH44UI4KTBvBYIZ1dSL9ZzChTB9ShHfLkR4pdW5krQ==} @@ -2138,13 +2209,11 @@ packages: resolution: {integrity: sha512-kvRdxDsxZjhzUX07ZnLydzS1TU/TJlTUHHY4YLL87e37oUA49DfkLqgy+VjFocowy29cKvcSiu+kIv728jTTVg==} engines: {node: '>= 0.4'} - is-set@2.0.3: - resolution: {integrity: sha512-iPAjerrse27/ygGLxw+EBR9agv9Y6uLeYVJMu+QNCoouJ1/1ri0mGrcWpfCqFZuzzx3WjtwxG098X+n4OuRkPg==} - engines: {node: '>= 0.4'} + is-set@2.0.2: + resolution: {integrity: sha512-+2cnTEZeY5z/iXGbLhPrOAaK/Mau5k5eXq9j14CpRTftq0pAJu2MwVRSZhyZWBzx3o6X795Lz6Bpb6R0GKf37g==} - is-shared-array-buffer@1.0.3: - resolution: {integrity: sha512-nA2hv5XIhLR3uVzDDfCIknerhx8XUKnstuOERPNNIinXG7v9u+ohXF67vxm4TPTEPU6lm61ZkwP3c9PCB97rhg==} - engines: {node: '>= 0.4'} + is-shared-array-buffer@1.0.2: + resolution: {integrity: sha512-sqN2UDu1/0y6uvXyStCOzyhAjCSlHceFoMKJW8W9EU9cvic/QdsZ0kEU93HEy3IUEFZIiH/3w+AH/UQbPHNdhA==} is-ssh@1.4.0: resolution: {integrity: sha512-x7+VxdxOdlV3CYpjvRLBv5Lo9OJerlYanjwFrPR9fuGPjCiNiCzFgAWpiLAohSbsnH4ZAys3SBh+hq5rJosxUQ==} @@ -2153,6 +2222,14 @@ packages: resolution: {integrity: sha512-uQPm8kcs47jx38atAcWTVxyltQYoPT68y9aWYdV6yWXSyW8mzSat0TL6CiWdZeCdF3KrAvpVtnHbTv4RN+rqdQ==} engines: {node: '>=0.10.0'} + is-stream@2.0.1: + resolution: {integrity: sha512-hFoiJiTl63nn+kstHGBtewWSKnQLpyb155KHheA1l39uvtO9nWIop1p3udqPcUd/xbF1VLMO4n7OI6p7RbngDg==} + engines: {node: '>=8'} + + is-stream@3.0.0: + resolution: {integrity: sha512-LnQR4bZ9IADDRSkvpqMGvt/tEJWclzklNgSw48V5EAaAeDd6qGvN8ei6k5p0tvxSR171VmGyHuTiAOfxAbr8kA==} + engines: {node: ^12.20.0 || ^14.13.1 || >=16.0.0} + is-string@1.0.7: resolution: {integrity: sha512-tE2UXzivje6ofPW7l23cjDOMa09gb7xlAqG6jG5ej6uPV32TlWP3NKPigtaGeHNu9fohccRYvIiZMfOOnOYUtg==} engines: {node: '>= 0.4'} @@ -2161,16 +2238,22 @@ packages: resolution: {integrity: sha512-C/CPBqKWnvdcxqIARxyOh4v1UUEOCHpgDa0WYgpKDFMszcrPcffg5uhwSgPCLD2WWxmq6isisz87tzT01tuGhg==} engines: {node: '>= 0.4'} + is-typed-array@1.1.12: + resolution: {integrity: sha512-Z14TF2JNG8Lss5/HMqt0//T9JeHXttXy5pH/DBU4vi98ozO2btxzq9MwYDZYnKwU8nRsz/+GVFVRDq3DkVuSPg==} + engines: {node: '>= 0.4'} + is-typedarray@1.0.0: resolution: {integrity: sha512-cyA56iCMHAh5CdzjJIa4aohJyeO1YbwLi3Jc35MmRU6poroFjIGZzUzupGiRPOjgHg9TLu43xbpwXk523fMxKA==} - is-weakmap@2.0.2: - resolution: {integrity: sha512-K5pXYOm9wqY1RgjpL3YTkF39tni1XajUIkawTLUo9EZEVUFga5gSQJF8nNS7ZwJQ02y+1YCNYcMh+HIf1ZqE+w==} - engines: {node: '>= 0.4'} + is-weakmap@2.0.1: + resolution: {integrity: sha512-NSBR4kH5oVj1Uwvv970ruUkCV7O1mzgVFO4/rev2cLRda9Tm9HrL70ZPut4rOHgY0FNrUu9BCbXA2sdQ+x0chA==} - is-weakset@2.0.3: - resolution: {integrity: sha512-LvIm3/KWzS9oRFHugab7d+M/GcBXuXX5xZkzPmN+NxihdQlZUQ4dWuSV1xR/sq6upL1TJEDrfBgRepHFdBtSNQ==} - engines: {node: '>= 0.4'} + is-weakset@2.0.2: + resolution: {integrity: sha512-t2yVvttHkQktwnNNmBQ98AhENLdPUTDTE21uPqAQ0ARwQfGeQKRVS0NNurH7bTf7RrvcVn1OOge45CnBeHCSmg==} + + is-wsl@2.2.0: + resolution: {integrity: sha512-fKzAra0rGJUUBwGBgNkHZuToZcn+TtXHpeCgmkMJMMYx1sQDYaCSyjJBSCa2nH1DGm7s3n1oBnohoVTBaN7Lww==} + engines: {node: '>=8'} isarray@2.0.5: resolution: {integrity: sha512-xHjhDr3cNBK0BzdUJSPXZntQUx/mwMS5Rw4A7lPJ90XGAO6ISP/ePDNuo0vhqOZU+UD5JoodwCAAoZQd3FeAKw==} @@ -2183,6 +2266,11 @@ packages: peerDependencies: ws: '*' + isows@1.0.6: + resolution: {integrity: sha512-lPHCayd40oW98/I0uvgaHKWCSvkzY27LjWLbtzOm64yQ+G3Q5npjjbdppU65iZXkK1Zt+kH9pfegli0AYfwYYw==} + peerDependencies: + ws: '*' + jackspeak@2.3.6: resolution: {integrity: sha512-N3yCS/NegsOBokc8GAdM8UcmfsKiSS8cipheD/nivzr700H+nsMOxJjQnvwOcRYVuFkdH0wGUvW2WbXGmrZGbQ==} engines: {node: '>=14'} @@ -2207,8 +2295,8 @@ packages: json-parse-even-better-errors@2.3.1: resolution: {integrity: sha512-xyFwyhro/JEof6Ghe2iz2NcXoj2sloNsWr/XsERDK/oiPCfaNhl5ONfp+jQdAZRQQ0IJWNzH9zIZF7li91kh2w==} - json-parse-even-better-errors@3.0.1: - resolution: {integrity: sha512-aatBvbL26wVUCLmbWdCpeu9iF5wOyWpagiKkInA+kfws3sWdBrTnsvN2CKcyCYyUrc7rebNBlK6+kteg7ksecg==} + json-parse-even-better-errors@3.0.0: + resolution: {integrity: sha512-iZbGHafX/59r39gPwVPRBGw0QQKnA7tte5pSMrhWOW7swGsVvVTjmfyAV9pNqk8YGT7tRCdxRu8uzcgZwoDooA==} engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0} json-schema-traverse@0.4.1: @@ -2220,11 +2308,11 @@ packages: json-stable-stringify-without-jsonify@1.0.1: resolution: {integrity: sha512-Bdboy+l7tA3OGW6FjyFHWkP5LuByj1Tk33Ljyq0axyzdk9//JSi2u3fP1QSmd1KNwq6VOKYGlAu87CisVir6Pw==} - jsonc-parser@3.2.1: - resolution: {integrity: sha512-AilxAyFOAcK5wA1+LeaySVBrHsGQvUFCDWXKpZjzaL0PqW+xfBOttn8GNtWKFWqneyMZj41MWF9Kl6iPWLwgOA==} + jsonc-parser@3.2.0: + resolution: {integrity: sha512-gfFQZrcTc8CnKXp6Y4/CBT3fTc0OVuDofpre4aEeEpSBPV5X5v4+Vmx+8snU7RLPrNHPKSgLxGo9YuQzz20o+w==} - katex@0.16.10: - resolution: {integrity: sha512-ZiqaC04tp2O5utMsl2TEZTXxa6WSC4yo0fv5ML++D3QZv/vx2Mct0mTlRx3O+uUkjfuAgOkzsCmq5MiUEsDDdA==} + katex@0.16.9: + resolution: {integrity: sha512-fsSYjWS0EEOwvy81j3vRA8TEAhQhKiqO+FQaKWp0m39qwOzHVBgAUBIXWj1pB+O2W3fIpNa6Y9KSKCVbfPhyAQ==} hasBin: true keyv@4.5.4: @@ -2244,6 +2332,9 @@ packages: layout-base@1.0.2: resolution: {integrity: sha512-8h2oVEZNktL4BH2JCOI90iD1yXwL6iNW7KcCKT2QZgQJR2vbqDsldCTPRU9NifTCqHZci57XvQQ15YTu+sTYPg==} + layout-base@2.0.1: + resolution: {integrity: sha512-dp3s92+uNI1hWIpPGH3jK2kxE2lMjdXdr+DH8ynZHpd6PUlH6x6cbuXnoMmiNumznqaNO31xu9e79F0uuZ0JFg==} + levn@0.4.1: resolution: {integrity: sha512-+bT2uH4E5LGE7h/n3evcS/sQlJXCpIp6ym8OWJ5eV6+67Dsql/LaaT7qJBAt2rzfoa/5QBGBhxDix1dMt2kQKQ==} engines: {node: '>= 0.8.0'} @@ -2291,8 +2382,8 @@ packages: lower-case@2.0.2: resolution: {integrity: sha512-7fm3l3NAF9WfN6W3JOmf5drwpVqX78JtoGJ3A6W0a6ZnldM41w2fV5D490psKFTpMds8TJse/eHLFFsNHHjHgg==} - lru-cache@10.2.2: - resolution: {integrity: sha512-9hp3Vp2/hFQUiIwKo8XCeFVnrg8Pk3TYNPIR7tJADKi5YfcF7vEaK7avFHTlSy3kOKYaJQaalfEo6YuXdceBOQ==} + lru-cache@10.0.3: + resolution: {integrity: sha512-B7gr+F6MkqB3uzINHXNctGieGsRTMwIBgxkp0yq/5BwcuDzD4A8wQpHQW6vDAm1uKSLQghmRdD9sKqf2vJ1cEg==} engines: {node: 14 || >=16.14} lru-cache@4.1.5: @@ -2313,8 +2404,8 @@ packages: markdown-table@3.0.3: resolution: {integrity: sha512-Z1NL3Tb1M9wH4XESsCDEksWoKTdlUafKc4pt0GRwjUyXaCFZ+dc3g2erqB6zm3szA2IUSi7VnPI+o/9jnxh9hw==} - match-sorter@6.3.4: - resolution: {integrity: sha512-jfZW7cWS5y/1xswZo8VBOdudUiSd9nifYRWphc9M5D/ee4w4AoXLgBEdRbgVaxbMuagBPeUC5y2Hi8DO6o9aDg==} + match-sorter@6.3.1: + resolution: {integrity: sha512-mxybbo3pPNuA+ZuCUhm5bwNkXrJTbsk5VWbR5wiwz/GC6LIiegBGn2w3O08UG/jdbYLinw51fSQ5xNU1U3MgBw==} mdast-comment-marker@2.1.2: resolution: {integrity: sha512-HED3ezseRVkBzZ0uK4q6RJMdufr/2p3VfVZstE3H1N9K8bwtspztWo6Xd7rEatuGNoCXaBna8oEqMwUn0Ve1bw==} @@ -2376,14 +2467,14 @@ packages: mdast-util-phrasing@3.0.1: resolution: {integrity: sha512-WmI1gTXUBJo4/ZmSk79Wcb2HcjPJBzM1nlI/OUWA8yk2X9ik3ffNbBGsU+09BFmXaL1IBb9fiuvq6/KMiNycSg==} - mdast-util-phrasing@4.1.0: - resolution: {integrity: sha512-TqICwyvJJpBwvGAMZjj4J2n0X8QWp21b9l0o7eXyVJ25YNWYbJDVIyD1bZXE6WtV6RmKJVYmQAKWa0zWOABz2w==} + mdast-util-phrasing@4.0.0: + resolution: {integrity: sha512-xadSsJayQIucJ9n053dfQwVu1kuXg7jCTdYsMK8rqzKZh52nLfSH/k0sAxE0u+pj/zKZX+o5wB+ML5mRayOxFA==} mdast-util-to-hast@12.3.0: resolution: {integrity: sha512-pits93r8PhnIoU4Vy9bjW39M2jJ6/tdHyja9rrot9uujkN7UTU9SDnE6WNJz/IGyQk3XHX6yNNtrBH6cQzm8Hw==} - mdast-util-to-hast@13.1.0: - resolution: {integrity: sha512-/e2l/6+OdGp/FB+ctrJ9Avz71AN/GRH3oi/3KAx/kMnoUsD6q0woXlDT8lLEeViVKE7oZxE7RXzvO3T8kF2/sA==} + mdast-util-to-hast@13.0.2: + resolution: {integrity: sha512-U5I+500EOOw9e3ZrclN3Is3fRpw8c19SMyNZlZ2IS+7vLsNzb2Om11VpIVOR+/0137GhZsFEF6YiKD5+0Hr2Og==} mdast-util-to-markdown@1.5.0: resolution: {integrity: sha512-bbv7TPv/WC49thZPg3jXuqzuvI45IL2EVAr/KxF0BSdHsU0ceFHOmwQn6evxAh1GaoK/6GQ1wp4R4oW2+LFL/A==} @@ -2400,6 +2491,9 @@ packages: mdast-util-to-string@4.0.0: resolution: {integrity: sha512-0H44vDimn51F0YwvxSJSm0eCDOJTRlmN0R1yBh4HLj9wiV1Dn0QoXGbvFAWj2hSItVTlCmBF1hqKlIyUBVFLPg==} + merge-stream@2.0.0: + resolution: {integrity: sha512-abv/qOcuPfk3URPfDzmZU1LKmuw8kT+0nIHvKrKgFrwifol/doWcdA4ZqsWQ8ENrFKkd67Mfpo/LovbIUsbt3w==} + merge2@1.4.1: resolution: {integrity: sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg==} engines: {node: '>= 8'} @@ -2408,8 +2502,8 @@ packages: resolution: {integrity: sha512-LJKTl4iVNTndhL+3Uz/tfkjD0klIWsHlUzgtuNnNrsf7bAlXR30m+xYB7lHr5Z/l6e/yAIsr26Dabx6Buo4VGQ==} engines: {node: '>= 7.6.0'} - mermaid@10.9.0: - resolution: {integrity: sha512-swZju0hFox/B/qoLKK0rOxxgh8Cf7rJSfAUc1u8fezVihYMvrJAS45GzAxTVf4Q+xn9uMgitBcmWk7nWGXOs/g==} + mermaid@10.6.1: + resolution: {integrity: sha512-Hky0/RpOw/1il9X8AvzOEChfJtVvmXm+y7JML5C//ePYMy0/9jCEmW1E1g86x9oDfW9+iVEdTV/i+M6KWRNs4A==} micro-ftch@0.3.1: resolution: {integrity: sha512-/0LLxhzP0tfiR5hcQebtudP56gUurs2CLkGarnCiB/OqEyUFQ6U3paQi/tgLv0hBJYt2rnr9MNpxz4fiiugstg==} @@ -2417,8 +2511,8 @@ packages: micromark-core-commonmark@1.1.0: resolution: {integrity: sha512-BgHO1aRbolh2hcrzL2d1La37V0Aoz73ymF8rAcKnohLy93titmv62E0gP8Hrx9PKcKrqCZ1BbLGbP3bEhoXYlw==} - micromark-core-commonmark@2.0.1: - resolution: {integrity: sha512-CUQyKr1e///ZODyD1U3xit6zXwy1a8q2a1S1HKtIlmgvurrEpaw/Y9y6KSIbF8P59cn/NjzHyO+Q2fAyYLQrAA==} + micromark-core-commonmark@2.0.0: + resolution: {integrity: sha512-jThOz/pVmAYUtkroV3D5c1osFXAMv9e0ypGDOIZuCeAe91/sD6BoE2Sjzt30yuXtwOYUmySOhMas/PVyh02itA==} micromark-extension-frontmatter@2.0.0: resolution: {integrity: sha512-C4AkuM3dA58cgZha7zVnuVxBhDsbttIMiytjgsM2XbHAB2faRVaHRle40558FBN+DJcrLNCoqG5mlrpdU4cRtg==} @@ -2498,8 +2592,8 @@ packages: micromark-util-character@1.2.0: resolution: {integrity: sha512-lXraTwcX3yH/vMDaFWCQJP1uIszLVebzUa3ZHdrgxr7KEU/9mL4mVgCpGbyhvNLNlauROiNUq7WN5u7ndbY6xg==} - micromark-util-character@2.1.0: - resolution: {integrity: sha512-KvOVV+X1yLBfs9dCBSopq/+G1PcgT3lAK07mC4BzXi5E7ahzMAF8oIupDDJ6mievI6F+lAATkbQQlQixJfT3aQ==} + micromark-util-character@2.0.1: + resolution: {integrity: sha512-3wgnrmEAJ4T+mGXAUfMvMAbxU9RDG43XmGce4j6CwPtVxB3vfwXSZ6KhFwDzZ3mZHhmPimMAXg71veiBGzeAZw==} micromark-util-chunked@1.1.0: resolution: {integrity: sha512-Ye01HXpkZPNcV6FiyoW2fGZDUw4Yc7vT0E9Sad83+bEDiCJ1uXu0S3mr8WLpsz3HaG3x2q0HM6CTuPdcZcluFQ==} @@ -2567,8 +2661,8 @@ packages: micromark-util-subtokenize@1.1.0: resolution: {integrity: sha512-kUQHyzRoxvZO2PuLzMt2P/dwVsTiivCK8icYTeR+3WgbuPqfHgPPy7nFKbeqRivBvn/3N3GBiNC+JRTMSxEC7A==} - micromark-util-subtokenize@2.0.1: - resolution: {integrity: sha512-jZNtiFl/1aY73yS3UGQkutD0UbhTt68qnRpw2Pifmz5wV9h8gOVsN70v+Lq/f1rKaU/W8pxRe8y8Q9FX1AOe1Q==} + micromark-util-subtokenize@2.0.0: + resolution: {integrity: sha512-vc93L1t+gpR3p8jxeVdaYlbV2jTYteDje19rNSS/H5dlhxUYll5Fy6vJ2cDwP8RnsXi818yGty1ayP55y3W6fg==} micromark-util-symbol@1.1.0: resolution: {integrity: sha512-uEjpEYY6KMs1g7QfJ2eX1SQEV+ZT4rUD3UcF6l57acZvLNK7PBZL+ty82Z1qhK1/yXIY4bdx04FKMgR0g4IAag==} @@ -2595,6 +2689,14 @@ packages: resolution: {integrity: sha512-DMy+ERcEW2q8Z2Po+WNXuw3c5YaUSFjAO5GsJqfEl7UjvtIuFKO6ZrKvcItdy98dwFI2N1tg3zNIdKaQT+aNdA==} engines: {node: '>=8.6'} + mimic-fn@2.1.0: + resolution: {integrity: sha512-OqbOk5oEQeAZ8WXWydlu9HJjz9WVdEIvamMCcXmuqUYjTknH/sqsWvhQ3vgwKFRR1HpjvNBKQ37nbJgYzGqGcg==} + engines: {node: '>=6'} + + mimic-fn@4.0.0: + resolution: {integrity: sha512-vqiC06CuhBTUdZH+RYl8sFrL096vA45Ok5ISO6sE/Mr1jRbGH4Csnhi8f3wKVl7x8mO4Au7Ir9D3Oyv1VYMFJw==} + engines: {node: '>=12'} + min-indent@1.0.1: resolution: {integrity: sha512-I9jwMn07Sy/IwOj3zVkVik2JTvgpaykDZEigL6Rx6N9LbMywwUSMtxET+7lVoDLLd3O3IXwJwvuuns8UB/HeAg==} engines: {node: '>=4'} @@ -2616,10 +2718,6 @@ packages: resolution: {integrity: sha512-RHiac9mvaRw0x3AYRgDC1CxAP7HTcNrrECeA8YYJeWnpo+2Q5CegtZjaotWTWxDG3UeGA1coE05iH1mPjT/2mg==} engines: {node: '>=16 || 14 >=14.17'} - minimatch@9.0.4: - resolution: {integrity: sha512-KqWh+VchfxcMNRAJjj2tnsSJdNbHsVgnkBhTNrW7AjVo6OvLtxw8zfT9oLw1JSohlFzJ8jCoTgaoXvJ+kHt6fw==} - engines: {node: '>=16 || 14 >=14.17'} - minimist@1.2.8: resolution: {integrity: sha512-2yyAR8qBkN3YuheJanUpWC5U3bb5osDywNB8RzDVlDwDHbocAJveqqj1u8+SVD7jkWT4yvsHCpWqqWqAxb0zCA==} @@ -2649,8 +2747,8 @@ packages: react: '>=16.x <=18.x' react-dom: '>=16.x <=18.x' - next-seo@6.5.0: - resolution: {integrity: sha512-MfzUeWTN/x/rsKp/1n0213eojO97lIl0unxqbeCY+6pAucViHDA8GSLRRcXpgjsSmBxfCFdfpu7LXbt4ANQoNQ==} + next-seo@6.4.0: + resolution: {integrity: sha512-XQFxkOL2hw0YE+P100HbI3EAvcludlHPxuzMgaIjKb7kPK0CvjGvLFjd9hszZFEDc5oiQkGFA8+cuWcnip7eYA==} peerDependencies: next: ^8.1.1-canary.54 || >=9.0.0 react: '>=16.0.0' @@ -2670,18 +2768,21 @@ packages: react: '*' react-dom: '*' - next@13.5.1: - resolution: {integrity: sha512-GIudNR7ggGUZoIL79mSZcxbXK9f5pwAIPZxEM8+j2yLqv5RODg4TkmUlaKSYVqE1bPQueamXSqdC3j7axiTSEg==} - engines: {node: '>=16.14.0'} + next@14.2.10: + resolution: {integrity: sha512-sDDExXnh33cY3RkS9JuFEKaS4HmlWmDKP1VJioucCG6z5KuA008DPsDZOzi8UfqEk3Ii+2NCQSJrfbEWtZZfww==} + engines: {node: '>=18.17.0'} hasBin: true peerDependencies: '@opentelemetry/api': ^1.1.0 + '@playwright/test': ^1.41.2 react: ^18.2.0 react-dom: ^18.2.0 sass: ^1.3.0 peerDependenciesMeta: '@opentelemetry/api': optional: true + '@playwright/test': + optional: true sass: optional: true @@ -2729,8 +2830,16 @@ packages: resolution: {integrity: sha512-lJxZYlT4DW/bRUtFh1MQIWqmLwQfAxnqWG4HhEdjMlkrJYnJn0Jrr2u3mgxqaWsdiBc76TYkTG/mhrnYTuzfHw==} engines: {node: '>=4'} - npm-to-yarn@2.2.1: - resolution: {integrity: sha512-O/j/ROyX0KGLG7O6Ieut/seQ0oiTpHF2tXAcFbpdTLQFiaNtkyTXXocM1fwpaa60dg1qpWj0nHlbNhx6qwuENQ==} + npm-run-path@4.0.1: + resolution: {integrity: sha512-S48WzZW777zhNIrn7gxOlISNAqi9ZC/uQFnRdbeIHhZhCA6UqpkOT8T1G7BvfdgP4Er8gF4sUbaS0i7QvIfCWw==} + engines: {node: '>=8'} + + npm-run-path@5.1.0: + resolution: {integrity: sha512-sJOdmRGrY2sjNTRMbSvluQqg+8X7ZK61yvzBEIDhz4f8z1TZFYABsqjjCBd/0PUNE9M6QDgHJXQkGUEm7Q+l9Q==} + engines: {node: ^12.20.0 || ^14.13.1 || >=16.0.0} + + npm-to-yarn@2.1.0: + resolution: {integrity: sha512-2C1IgJLdJngq1bSER7K7CGFszRr9s2rijEwvENPEgI0eK9xlD3tNwDc0UJnRj7FIT2aydWm72jB88uVswAhXHA==} engines: {node: ^12.22.0 || ^14.17.0 || >=16.0.0} number-to-bn@1.7.0: @@ -2740,23 +2849,35 @@ packages: object-inspect@1.13.1: resolution: {integrity: sha512-5qoj1RUiKOMsCCNLV1CBiPYE10sziTsnmNxkAI/rZhiD63CF7IqdFGC/XzjWjpSgLf0LxXX3bDFIh0E18f6UhQ==} - object-is@1.1.6: - resolution: {integrity: sha512-F8cZ+KfGlSGi09lJT7/Nd6KJZ9ygtvYC0/UYYLI9nmQKLMnydpB9yvbv9K1uSkEu7FU9vYPmVwLg328tX+ot3Q==} + object-is@1.1.5: + resolution: {integrity: sha512-3cyDsyHgtmi7I7DfSSI2LDp6SK2lwvtbg0p0R1e0RvTqF5ceGx+K2dfSjm1bKDMVCFEDAQvy+o8c6a7VujOddw==} engines: {node: '>= 0.4'} object-keys@1.1.1: resolution: {integrity: sha512-NuAESUOUMrlIXOfHKzD6bpPu3tYt3xvjNdRIQ+FeT0lNb4K8WR70CaDxhuNguS2XG+GjkyMwOzsN5ZktImfhLA==} engines: {node: '>= 0.4'} - object.assign@4.1.5: - resolution: {integrity: sha512-byy+U7gp+FVwmyzKPYhW2h5l3crpmGsxl7X2s8y43IgxvG4g3QZ6CffDtsNQy1WsmZpQbO+ybo0AlW7TY6DcBQ==} + object.assign@4.1.4: + resolution: {integrity: sha512-1mxKf0e58bvyjSCtKYY4sRe9itRk3PJpquJOjeIkz885CczcI4IvJJDLPS72oowuSh+pBxUFROpX+TU++hxhZQ==} engines: {node: '>= 0.4'} once@1.4.0: resolution: {integrity: sha512-lNaJgI+2Q5URQBkccEKHTQOPaXdUxnZZElQTZY0MFUAuaEqe1E+Nyvgdz/aIyNi6Z9MzO5dv1H8n58/GELp3+w==} - optionator@0.9.4: - resolution: {integrity: sha512-6IpQ7mKUxRcZNLIObR0hz7lxsapSSIYNZJwXPGeF0mTVqGKFIXj1DQcMoT22S3ROcLyY/rz0PWaWZ9ayWmad9g==} + onetime@5.1.2: + resolution: {integrity: sha512-kbpaSSGJTWdAY5KPVeMOKXSrPtr8C8C7wodJbcsd51jRnmD+GZu8Y0VoU6Dm5Z4vWr0Ig/1NKuWRKf7j5aaYSg==} + engines: {node: '>=6'} + + onetime@6.0.0: + resolution: {integrity: sha512-1FlR+gjXK7X+AsAHso35MnyN5KqGwJRi/31ft6x0M194ht7S+rWAvd7PHss9xSKMzE0asv1pyIHaJYq+BbacAQ==} + engines: {node: '>=12'} + + open@9.1.0: + resolution: {integrity: sha512-OS+QTnw1/4vrf+9hh1jc1jnYjzSG4ttTBB8UxOwAnInG3Uo4ssetzC1ihqaIHjLJnA5GGlRl6QlZXOTQhRBUvg==} + engines: {node: '>=14.16'} + + optionator@0.9.3: + resolution: {integrity: sha512-JjCoypp+jKn1ttEFExxhetCKeJt9zhAgAve5FXHixTvFDW/5aEktX9bufBKLRRMdU7bNtpLfcGu94B3cdEJgjg==} engines: {node: '>= 0.8.0'} p-finally@1.0.0: @@ -2838,8 +2959,12 @@ packages: resolution: {integrity: sha512-ojmeN0qd+y0jszEtoY48r0Peq5dwMEkIlCOu6Q5f41lfkswXuKtYrhgoTpLnyIcHm24Uhqx+5Tqm2InSwLhE6Q==} engines: {node: '>=8'} - path-scurry@1.10.2: - resolution: {integrity: sha512-7xTavNy5RQXnsjANvVvMkEjvloOinkAjv/Z6Ildz9v2RinZ4SBKTWFOVRbaF8p0vpHnyjV/UwNDdKuUv6M5qcA==} + path-key@4.0.0: + resolution: {integrity: sha512-haREypq7xkM7ErfgIyA0z+Bj4AGKlMSdlQE2jvJo6huWD1EdkKYV+G/T4nq0YEF2vgTT8kqMFKo1uHn950r4SQ==} + engines: {node: '>=12'} + + path-scurry@1.10.1: + resolution: {integrity: sha512-MkhCqzzBEpPvxxQ71Md0b1Kk51W01lrYvlMzSUaIzNsODdd7mqhiimSZlr+VegAz5Z6Vzt9Xg2ttE//XBhH3EQ==} engines: {node: '>=16 || 14 >=14.17'} path-type@4.0.0: @@ -2863,12 +2988,8 @@ packages: resolution: {integrity: sha512-Nc3IT5yHzflTfbjgqWcCPpo7DaKy4FnpB0l/zCAW0Tc7jxAiuqSxHasntB3D7887LSrA93kDJ9IXovxJYxyLCA==} engines: {node: '>=4'} - possible-typed-array-names@1.0.0: - resolution: {integrity: sha512-d7Uw+eZoloe0EHDIYoe+bQ5WXnGMOpmiZFTuMWCwpjzzkL2nTjcKiAk4hh8TjnGye2TwWOk3UXucZ+3rbmBa8Q==} - engines: {node: '>= 0.4'} - - postcss@8.4.14: - resolution: {integrity: sha512-E398TUmfAYFPBSdzgeieK2Y1+1cpdxJx8yXbK/m57nRhKSmk1GB2tO4lbLBtlkfPQTDKfe4Xqv1ASWPpayPEig==} + postcss@8.4.31: + resolution: {integrity: sha512-PS08Iboia9mts/2ygV3eLpY5ghnUcfLV/EXTOW1E2qYxJKGGBUtNjN76FYHnMs36RmARn41bC0AZmn+rR0OVpQ==} engines: {node: ^10 || ^12 || >=14} prelude-ls@1.2.1: @@ -2883,8 +3004,8 @@ packages: resolution: {integrity: sha512-++Vn7NS4Xf9NacaU9Xq3URUuqZETPsf8L4j5/ckhaRYsfPeRyzGw+iDjFhV/Jr3uNmTvvddEJFWh5R1gRgUH8A==} engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0} - property-information@6.5.0: - resolution: {integrity: sha512-PgTgs/BlvHxOu8QuEN7wi5A0OmXaBcHpmCSTehcs6Uuu9IkDIEo13Hy7n898RHfrQ49vKCoGeWZSaAK01nwVig==} + property-information@6.4.0: + resolution: {integrity: sha512-9t5qARVofg2xQqKtytzt+lZ4d1Qvj8t5B8fEwXK6qOfgRLgH/b13QlgEyDh033NOS31nXeFbYv7CLUDG1CeifQ==} protocols@2.0.1: resolution: {integrity: sha512-/XJ368cyBJ7fzLMwLKv1e4vLxOju2MNAIokcr7meSaNcVbWz/CPcW22cP04mwxOErdA5mwjA8Q6w/cdAQxVn7Q==} @@ -2902,16 +3023,16 @@ packages: randombytes@2.1.0: resolution: {integrity: sha512-vYl3iOX+4CKUWuxGi9Ukhie6fsqXqS9FE2Zaic4tNFD2N2QQaXOMFbuKK4QmDHC0JO6B1Zp41J0LpT0oR68amQ==} - react-dom@18.3.1: - resolution: {integrity: sha512-5m4nQKp+rZRb09LNH59GM4BxTh9251/ylbKIbpe7TpGxfJ+9kv6BLkLBXIjjspbgbnIBNqlI23tRnTWT0snUIw==} + react-dom@18.2.0: + resolution: {integrity: sha512-6IMTriUmvsjHUjNtEDudZfuDQUoWXVxKHhlEGSk81n4YFS+r/Kl99wXiwlVXtPBtJenozv2P+hxDsw9eA7Xo6g==} peerDependencies: - react: ^18.3.1 + react: ^18.2.0 react-is@17.0.2: resolution: {integrity: sha512-w2GsyukL62IJnlaff/nRegPQR94C/XXamvMWmSHRJ4y7Ts/4ocGRmTHvOs8PSE6pB3dWOrD/nueuU5sduBsQ4w==} - react@18.3.1: - resolution: {integrity: sha512-wS+hAgJShR0KhEvPJArfuPVN1+Hz1t0Y6n5jLrGQbkb4urgPE/0Rve+1kMB1v/oWgHgm4WIcV+i7F2pTVj+2iQ==} + react@18.2.0: + resolution: {integrity: sha512-/3IjMdb2L9QbBdWiW5e3P2/npwMBaU9mHCSCUzNln0ZCYbcfTsGbTJrU/kGemdH2IWmB2ioZ+zkxtmq6g09fGQ==} engines: {node: '>=0.10.0'} read-package-json-fast@3.0.2: @@ -2925,11 +3046,11 @@ packages: reading-time@1.5.0: resolution: {integrity: sha512-onYyVhBNr4CmAxFsKS7bz+uTLRakypIe4R+5A824vBSkQy/hB3fZepoVEf8OVAxzLvK+H/jm9TzpI3ETSm64Kg==} - regenerator-runtime@0.14.1: - resolution: {integrity: sha512-dYnhHh0nJoMfnkZs6GmmhFknAGRrLznOu5nc9ML+EJxGvrx6H7teuevqVqCuPcPK//3eDrrjQhehXVx9cnkGdw==} + regenerator-runtime@0.14.0: + resolution: {integrity: sha512-srw17NI0TUWHuGa5CFGGmhfNIeja30WMBfbslPNhf6JrqQlLN5gcrvig1oqPxiVaXb0oW0XRKtH6Nngs5lKCIA==} - regexp.prototype.flags@1.5.2: - resolution: {integrity: sha512-NcDiDkTLuPR+++OCKB0nWafEmhg/Da8aUPLPMQbK+bxKKCm1/S5he+AqYa4PlMCVBalb4/yxIRub6qkEx5yJbw==} + regexp.prototype.flags@1.5.1: + resolution: {integrity: sha512-sy6TXMN+hnP/wMy+ISxg3krXx7BAtWVO4UouuCN/ziM9UEne0euamVNafDfvC83bRNr95y0V5iijeDQFUNpvrg==} engines: {node: '>= 0.4'} rehype-katex@7.0.0: @@ -3080,8 +3201,8 @@ packages: remark@15.0.1: resolution: {integrity: sha512-Eht5w30ruCXgFmxVUSlNWQ9iiimq07URKeFS3hNc8cUWy1llX4KDWfyEDZRycMc+znsN9Ux5/tJ/BFdgdOwA3A==} - remove-accents@0.5.0: - resolution: {integrity: sha512-8g3/Otx1eJaVD12e31UbJj1YzdtVvzH85HV7t+9MJYk/u3XmkOUJ5Ys9wQrf9PCPK8+xn4ymzqYCiZl6QWKn+A==} + remove-accents@0.4.2: + resolution: {integrity: sha512-7pXIJqJOq5tFgG1A2Zxti3Ht8jJF337m4sowbuHsW30ZnkQFnDzy9qBNhgzX8ZLW4+UBcXiiR7SwR6pokHsxiA==} repeat-string@1.6.1: resolution: {integrity: sha512-PV0dzCYDNfRi1jCDbJzpW7jNNDRuCOG/jI5ctQcGKt/clZD+YcPS3yIlWuTJMmESC8aevCFmWJy5wjAFgNqN6w==} @@ -3105,7 +3226,6 @@ packages: rimraf@3.0.2: resolution: {integrity: sha512-JZkJMZkAGFFPP2YqXZXPbMlMBgsxzE8ILs4lMIX/2o0L9UBw9O/Y3o6wFw/i9YLapcUJWwqbi3kdxIPdC62TIA==} - deprecated: Rimraf versions prior to v4 are no longer supported hasBin: true rlp@2.2.7: @@ -3115,6 +3235,10 @@ packages: robust-predicates@3.0.2: resolution: {integrity: sha512-IXgzBWvWQwE6PrDI05OvmXUIruQTcoMDzRsOd5CDvHCVLcLHMTSYvOK5Cm46kWqlV3yAbuSpBZdJ5oP5OUoStg==} + run-applescript@5.0.0: + resolution: {integrity: sha512-XcT5rBksx1QdIhlFOCtgZkB99ZEouFZ1E2Kc2LHqNW13U3/74YGdkQRmThTwxy4QIyookibDKYZOPqX//6BlAg==} + engines: {node: '>=12'} + run-parallel@1.2.0: resolution: {integrity: sha512-5l4VyZR86LZ/lDxZTR6jqL8AFE2S0IFLMP26AbjsLVADxHdhB/c0GUsH+y39UfCi3dzz8OlQuPmnaJOMoDHQBA==} @@ -3131,8 +3255,8 @@ packages: safer-buffer@2.1.2: resolution: {integrity: sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==} - scheduler@0.23.2: - resolution: {integrity: sha512-UOShsPwz7NrMUqhR6t0hWjFduvOzbtv7toDH1/hIrfRNIDBnnBWd0CwJTGvTpngVlmwGCdP9/Zl/tVrDqcuYzQ==} + scheduler@0.23.0: + resolution: {integrity: sha512-CtuThmgHNg7zIZWAXi3AsyIzA3n4xx7aNyjwC2VJldO2LMVDhFK+63xGqq6CsJH4rTAt6/M+N4GhZiDYPx9eUw==} scroll-into-view-if-needed@3.1.0: resolution: {integrity: sha512-49oNpRjWRvnU8NyGVmUaYG4jtTkNonFZI86MmGRDqBphEK2EXT9gdEUoQPZhuBM8yWHxCWbobltqYO5M4XrUvQ==} @@ -3147,20 +3271,20 @@ packages: resolution: {integrity: sha512-vfD3pmTzGpufjScBh50YHKzEu2lxBWhVEHsNGoEXmCmn2hKGfeNLYMzCJpe8cD7gqX7TJluOVpBkAequ6dgMmA==} engines: {node: '>=4'} - semver@7.6.0: - resolution: {integrity: sha512-EnwXhrlwXMk9gKu5/flx5sv/an57AkRplG3hTK68W7FRDN+k+OWBj65M7719OkA82XLBxrcX0KSHj+X5COhOVg==} + semver@7.5.4: + resolution: {integrity: sha512-1bCSESV6Pv+i21Hvpxp3Dx+pSD8lIPt8uVjRrxAUt/nbswYc+tK6Y2btiULjd4+fnq15PX+nqQDC7Oft7WkwcA==} engines: {node: '>=10'} hasBin: true sentence-case@3.0.4: resolution: {integrity: sha512-8LS0JInaQMCRoQ7YUytAo/xUu5W2XnQxV2HI/6uM6U7CITS1RqPElr30V6uIqyMKM9lJGRVFy5/4CuzcixNYSg==} - set-function-length@1.2.2: - resolution: {integrity: sha512-pgRc4hJ4/sNjWCSS9AmnS40x3bNMDTknHgL5UaMBTMyJnU90EgWh1Rz+MC9eFu4BuN/UwZjKQuY/1v3rM7HMfg==} + set-function-length@1.1.1: + resolution: {integrity: sha512-VoaqjbBJKiWtg4yRcKBQ7g7wnGnLV3M8oLvVWwOk2PdYY6PEFegR1vezXR0tw6fZGF9csVakIRjrJiy2veSBFQ==} engines: {node: '>= 0.4'} - set-function-name@2.0.2: - resolution: {integrity: sha512-7PGFlmtwsEADb0WYyvCMa1t+yke6daIG4Wirafur5kcf+MhUnPms1UeR0CKQdTZD81yESwMHbtn+TR+dMviakQ==} + set-function-name@2.0.1: + resolution: {integrity: sha512-tMNCiqYVkXIZgc2Hnoy2IvC/f8ezc5koaRFkCjrpWzGpCd3qbZXPzVy9MAZzK1ch/X0jvSkojys3oqJN0qCmdA==} engines: {node: '>= 0.4'} shebang-command@1.2.0: @@ -3179,12 +3303,11 @@ packages: resolution: {integrity: sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A==} engines: {node: '>=8'} - shiki@0.14.7: - resolution: {integrity: sha512-dNPAPrxSc87ua2sKJ3H5dQ/6ZaY8RNnaAqK+t0eG7p0Soi2ydiqbGOTaZCqaYvA/uZYfS1LJnemt3Q+mSfcPCg==} + shiki@0.14.5: + resolution: {integrity: sha512-1gCAYOcmCFONmErGTrS1fjzJLA7MGZmKzrBNX7apqSwhyITJg2O102uFzXUeBxNnEkDA9vHIKLyeKq0V083vIw==} - side-channel@1.0.6: - resolution: {integrity: sha512-fDW/EZ6Q9RiO8eFG8Hj+7u/oW+XrPTIChwCOM2+th2A6OblDtYYIpve9m+KvI9Z4C9qSEXlaGR6bTEYHReuglA==} - engines: {node: '>= 0.4'} + side-channel@1.0.4: + resolution: {integrity: sha512-q5XPytqFEIKHkGdiMIrY10mvLRvnQh42/+GoBlFW3b2LXLE2xxJpZFdm94we0BaoV3RwJyGqg5wS7epxTv0Zvw==} signal-exit@3.0.7: resolution: {integrity: sha512-wnD2ZE+l+SPC/uoS0vXeE9L1+0wuaMqKlfz9AMUo38JsyLSBWSFcHR1Rri62LZc12vLr1gb3jl7iwQhgwpAbGQ==} @@ -3204,8 +3327,8 @@ packages: resolution: {integrity: sha512-Pdz01AvCAottHTPQGzndktFNdbRA75BgOfeT1hH+AMnJFv8lynkPi42rfeEhpx1saTEI3YNMWxfqu0sFD1G8pw==} engines: {node: '>=12'} - source-map-js@1.2.0: - resolution: {integrity: sha512-itJW8lvSA0TXEphiRoawsCksnlf8SyvmFzIhltqAHluXd88pkCd+cXJVHTDwdCr0IzwptSm035IHQktUu1QUMg==} + source-map-js@1.0.2: + resolution: {integrity: sha512-R0XvVJ9WusLiqTCEiGCmICCMplcCkIwwR11mOSD9CR5u+IXYdiseeEuXCVAjS54zqwkLcPNnmU4OeJ6tUrWhDw==} engines: {node: '>=0.10.0'} source-map@0.7.4: @@ -3237,8 +3360,8 @@ packages: string_decoder@1.3.0: resolution: {integrity: sha512-hkRX8U1WjJFd8LsDJ2yQ/wWWxaopEsABU1XfkM8A+j0+85JAGppt16cr1Whg6KIbb4okU6Mql6BOj+uup/wKeA==} - stringify-entities@4.0.4: - resolution: {integrity: sha512-IwfBptatlO+QCJUo19AqvrPNqlVMpW9YEL2LIVY+Rpv2qsjCGxaDLNRgeGsQWJhfItebuJhsGSLjaBbNSQ+ieg==} + stringify-entities@4.0.3: + resolution: {integrity: sha512-BP9nNHMhhfcMbiuQKCqMjhDP5yBCAxsPu4pHFFzJ6Alo9dZgY4VLDPutXqIjpRiMoKdp7Av85Gr73Q5uH9k7+g==} strip-ansi@6.0.1: resolution: {integrity: sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==} @@ -3256,6 +3379,14 @@ packages: resolution: {integrity: sha512-7FCwGGmx8mD5xQd3RPUvnSpUXHM3BWuzjtpD4TXsfcZ9EL4azvVVUscFYwD9nx8Kh+uCBC00XBtAykoMHwTh8Q==} engines: {node: '>=0.10.0'} + strip-final-newline@2.0.0: + resolution: {integrity: sha512-BrpvfNAE3dcvq7ll3xVumzjKjZQ5tI1sEUIKr3Uoks0XUl45St3FlatVqef9prk4jRDzhW6WZg+3bk93y6pLjA==} + engines: {node: '>=6'} + + strip-final-newline@3.0.0: + resolution: {integrity: sha512-dOESqjYr96iWYylGObzd39EuNTa5VJxyvVAEm5Jnh7KGo75V43Hk1odPQkNDyXNmUR6k+gEiDVXnjB8HJ3crXw==} + engines: {node: '>=12'} + strip-hex-prefix@1.0.0: resolution: {integrity: sha512-q8d4ue7JGEiVcypji1bALTos+0pWtyGlivAWyPuTkHzuTCJqrK9sWxYQZUq6Nq3cuyv3bm734IhHvHtGGURU6A==} engines: {node: '>=6.5.0', npm: '>=3'} @@ -3284,8 +3415,8 @@ packages: babel-plugin-macros: optional: true - stylis@4.3.2: - resolution: {integrity: sha512-bhtUjWd/z6ltJiQwg0dUfxEJ+W+jdqQd8TbWLWyeIJHlnsqmGLRFFd8e5mA0AZi/zx90smXRlN66YMTcaSFifg==} + stylis@4.3.0: + resolution: {integrity: sha512-E87pIogpwUsUwXw7dNyU4QDjdgVMy52m+XEOPEKUn161cCzWjjhPSQhByfd1CcNvrOLnXQ6OnnZDwnJrz/Z4YQ==} supports-color@4.5.0: resolution: {integrity: sha512-ycQR/UbvI9xIlEdQT1TQqwoXtEldExbCEAJgRo5YXlmSKjv6ThHnP9/vwGa1gr19Gfw+LkFd7KqYMhzrRC5JYw==} @@ -3303,8 +3434,8 @@ packages: resolution: {integrity: sha512-VL+lNrEoIXww1coLPOmiEmK/0sGigko5COxI09KzHc2VJXJsQ37UaQ+8quuxjDeA7+KnLGTWRyOXSLLR2Wb4jw==} engines: {node: '>=12'} - synckit@0.9.0: - resolution: {integrity: sha512-7RnqIMq572L8PeEzKeBINYEJDDxpcH8JEgLwUqBd3TkofhFRbkq4QLR0u+36avGAhCRbk2nnmjcW9SE531hPDg==} + synckit@0.8.5: + resolution: {integrity: sha512-L1dapNV6vu2s/4Sputv8xGsCdAVlb5nRDMFU/E27D44l5U6cw1g0dGd45uLc+OXjNMmF4ntiMdCimzcjFKQI8Q==} engines: {node: ^14.18.0 || >=16.0.0} tabbable@6.2.0: @@ -3325,6 +3456,10 @@ packages: resolution: {integrity: sha512-TARUb7z1pGvlLxgPk++7wJ6aycXF3GJ0sNSBTAsTuJrQG5QuZlkUQP+zl+nbjAh4gMX9yDw9ZYklMd7vAfJKEw==} engines: {node: '>=0.10.0'} + titleize@3.0.0: + resolution: {integrity: sha512-KxVu8EYHDPBdUYdKZdKtU2aj2XfEx9AfjXxE/Aj0vT06w2icA09Vus1rh6eSu1y01akYg6BjIK/hxyLJINoMLQ==} + engines: {node: '>=12'} + to-gatsby-remark-plugin@0.1.0: resolution: {integrity: sha512-blmhJ/gIrytWnWLgPSRCkhCPeki6UBK2daa3k9mGahN7GjwHu8KrS7F70MvwlsG7IE794JLgwAdCbi4hU4faFQ==} @@ -3348,8 +3483,8 @@ packages: trim-lines@3.0.1: resolution: {integrity: sha512-kRj8B+YHZCc9kQYdWfJB2/oUl9rA99qbowYYBtr4ui4mZyAQ2JpvVBd/6U2YloATfqBhBTSMhTpgBHtU0Mf3Rg==} - trough@2.2.0: - resolution: {integrity: sha512-tmMpK00BjZiUyVyvrBK7knerNgmgvcV/KLVyuma/SC+TQN167GrMRciANTz09+k3zW8L8t60jWO1GpfkZdjTaw==} + trough@2.1.0: + resolution: {integrity: sha512-AqTiAOLcj85xS7vQ8QkAV41hPDIJ71XJB4RCUrzo/1GM2CQwhkJGaf9Hgr7BOugMRpgGUrqRg/DrBDl4H40+8g==} ts-dedent@2.2.0: resolution: {integrity: sha512-q5W7tVM71e2xjHZTlgfTDoPF/SmqKG5hddq9SzR49CH2hayqRKJtQ4mtRlSxKaJlR/+9rEM+mnBHf7I2/BQcpQ==} @@ -3380,8 +3515,8 @@ packages: typedarray@0.0.6: resolution: {integrity: sha512-/aCDEGatGvZ2BIk+HmLf4ifCJFwvKFNb9/JeZPMulfgFracn9QFcAf5GO8B/mweUjSoblS5In0cWhqpfs/5PQA==} - typescript@5.4.5: - resolution: {integrity: sha512-vcI4UpRgg81oIRUFwR0WSIHKt11nJ7SAVlYNIu+QpqeyXP+gpQJy/Z4+F0aGxSE4MqwjyXvW/TzgkLAx2AGHwQ==} + typescript@5.3.2: + resolution: {integrity: sha512-6l+RyNy7oAHDfxC4FzSJcz9vnjTKxrLpDG5M2Vu4SHRVNg6xzqZp6LYSR9zjqQTu8DU/f5xwxUdADOkbrIX2gQ==} engines: {node: '>=14.17'} hasBin: true @@ -3464,6 +3599,10 @@ packages: unist-util-visit@5.0.0: resolution: {integrity: sha512-MR04uvD+07cwl/yhVuVWAtw+3GOR/knlL55Nd/wAdblk27GCVt3lqpTivy/tkJcZoNPzTwS1Y+KMojlLDhoTzg==} + untildify@4.0.0: + resolution: {integrity: sha512-KK8xQ1mkzZeg9inewmFVDNkg3l5LUhoq9kN6iWYB/CC9YMG8HA+c1Q8HwDe6dEX7kErrEVNVBO3fWsVq5iDgtw==} + engines: {node: '>=8'} + upper-case-first@2.0.2: resolution: {integrity: sha512-514ppYHBaKwfJRK/pNC6c/OxfGa0obSnAl106u97Ed0I625Nin96KAjttZF6ZL3e1XLtphxnqrOi9iWgm+u+bg==} @@ -3524,8 +3663,16 @@ packages: vfile@6.0.1: resolution: {integrity: sha512-1bYqc7pt6NIADBJ98UiG0Bn/CHIVOoZ/IyEkqIruLg0mE1BKzkOXY2D6CSqQIcKqgadppE5lrxgWXJmXd7zZJw==} - viem@2.9.28: - resolution: {integrity: sha512-/1iTg8yQlCNJ+7wSmdsBNB/vhjWqFJtTH6XZXHjGXrZnlBxAtHR5ZAr5TvTJc/2nhVIVE4BkCe5JCrIiSuZodg==} + viem@1.19.6: + resolution: {integrity: sha512-WSBHBMurWIWQk2yisOD8hqSA5S56cZu6onty3hzauVjiHMildtVWujF7YT0xjoU40GpFODvJASRR2RFdzgvUUg==} + peerDependencies: + typescript: '>=5.0.4' + peerDependenciesMeta: + typescript: + optional: true + + viem@2.21.37: + resolution: {integrity: sha512-JupwyttT4aJNnP9+kD7E8jorMS5VmgpC3hm3rl5zXsO8WNBTsP3JJqZUSg4AG6s2lTrmmpzS/qpmXMZu5gJw5Q==} peerDependencies: typescript: '>=5.0.4' peerDependenciesMeta: @@ -3547,20 +3694,19 @@ packages: walk-up-path@3.0.1: resolution: {integrity: sha512-9YlCL/ynK3CTlrSRrDxZvUauLzAswPCrsaCgilqFevUYpeEW0/3ScEjaa3kbW/T0ghhkEr7mv+fpjqn1Y1YuTA==} - watchpack@2.4.0: - resolution: {integrity: sha512-Lcvm7MGST/4fup+ifyKi2hjyIAwcdI4HRgtvTpIUxBRhB+RFtUh8XtDOxUfctVCnhVi+QQj49i91OyvzkJl6cg==} - engines: {node: '>=10.13.0'} - web-namespaces@2.0.1: resolution: {integrity: sha512-bKr1DkiNa2krS7qxNtdrtHAmzuYGFQLiQ13TsorsdT6ULTkPLKuu5+GsFpDlg6JFjUTwX2DyhMPG2be8uPrqsQ==} - web-worker@1.3.0: - resolution: {integrity: sha512-BSR9wyRsy/KOValMgd5kMyr3JzpdeoR9KVId8u5GVlTTAtNChlsE4yTxeY7zMdNSyOmoKBv8NH2qeRY9Tg+IaA==} + web-worker@1.2.0: + resolution: {integrity: sha512-PgF341avzqyx60neE9DD+XS26MMNMoUQRz9NOZwW32nPQrF6p77f1htcnjBSEV8BGMKZ16choqUG4hyI0Hx7mA==} - web3-utils@1.10.4: - resolution: {integrity: sha512-tsu8FiKJLk2PzhDl9fXbGUWTkkVXYhtTA+SmEFkKft+9BgwLxfCRpU96sWv7ICC8zixBNd3JURVoiR3dUXgP8A==} + web3-utils@1.10.3: + resolution: {integrity: sha512-OqcUrEE16fDBbGoQtZXWdavsPzbGIDc5v3VrRTZ0XrIpefC/viZ1ZU9bGEemazyS0catk/3rkOOxpzTfY+XsyQ==} engines: {node: '>=8.0.0'} + webauthn-p256@0.0.10: + resolution: {integrity: sha512-EeYD+gmIT80YkSIDb2iWq0lq2zbHo1CxHlQTeJ+KkCILWpVy3zASH3ByD4bopzfk0uCwXxLqKGLqp2W4O28VFA==} + webidl-conversions@3.0.1: resolution: {integrity: sha512-2JAn3z8AR6rjK8Sm8orRC0h/bcl/DqL7tRPdGZ4I1CjdF+EaMLmYxBHyXuKL849eucPFhvBoxMsflfOb8kxaeQ==} @@ -3570,12 +3716,11 @@ packages: which-boxed-primitive@1.0.2: resolution: {integrity: sha512-bwZdv0AKLpplFY2KZRX6TvyuN7ojjr7lwkg6ml0roIy9YeuSr7JS372qlNW18UQYzgYK9ziGcerWqZOmEn9VNg==} - which-collection@1.0.2: - resolution: {integrity: sha512-K4jVyjnBdgvc86Y6BkaLZEN933SwYOuBFkdmBu9ZfkcAbdVbpITnDmjvZ/aQjRXQrv5EPkTnD1s39GiiqbngCw==} - engines: {node: '>= 0.4'} + which-collection@1.0.1: + resolution: {integrity: sha512-W8xeTUwaln8i3K/cY1nGXzdnVZlidBcagyNFtBdD5kxnb4TvGKR7FfSIS3mYpwWS1QUCutfKz8IY8RjftB0+1A==} - which-typed-array@1.1.15: - resolution: {integrity: sha512-oV0jmFtUky6CXfkqehVvBP/LSWJ2sy4vWMioiENyJLePrBO/yKyV9OyJySfAKosh+RYkIl5zJCNZ8/4JncrpdA==} + which-typed-array@1.1.13: + resolution: {integrity: sha512-P5Nra0qjSncduVPEAr7xhoF5guty49ArDTwzJ/yNuPIbZppyRxFQsRCWrocxIY+CnMVG+qfbU2FmDKyvSGClow==} engines: {node: '>= 0.4'} which@1.3.1: @@ -3587,10 +3732,6 @@ packages: engines: {node: '>= 8'} hasBin: true - word-wrap@1.2.5: - resolution: {integrity: sha512-BN22B5eaMMI9UMtjrGd5g5eCYPpCPDUy0FJXbYsaT5zYxjFOckS53SQDE3pWkVoWpHXVb3BrYcEN4Twa55B5cA==} - engines: {node: '>=0.10.0'} - wrap-ansi@7.0.0: resolution: {integrity: sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==} engines: {node: '>=10'} @@ -3629,6 +3770,18 @@ packages: utf-8-validate: optional: true + ws@8.18.0: + resolution: {integrity: sha512-8VbfWfHLbbwu3+N6OKsOMpBdT4kXPDDB9cJk2bJ6mh9ucxdlnNvH1e+roYkKmN9Nxw2yjz7VzeO9oOz2zJ04Pw==} + engines: {node: '>=10.0.0'} + peerDependencies: + bufferutil: ^4.0.1 + utf-8-validate: '>=5.0.2' + peerDependenciesMeta: + bufferutil: + optional: true + utf-8-validate: + optional: true + xdg-basedir@5.1.0: resolution: {integrity: sha512-GCPAHLvrIH13+c0SuacwvRYj2SxJXQ4kaVTT5xgL3kPrz56XxkF21IGhjSE1+W0aw7gpBWRGXLCPnPby6lSpmQ==} engines: {node: '>=12'} @@ -3643,10 +3796,9 @@ packages: resolution: {integrity: sha512-zw0VAJxgeZ6+++/su5AFoqBbZbrEakwu+X0M5HmcwUiBL7AzcuPKjj5we4xfQLp78LkEMpD0cOnUhmgOVy3KdQ==} engines: {node: '>= 14'} - yaml@2.4.2: - resolution: {integrity: sha512-B3VqDZ+JAg1nZpaEmWtTXUlBneoGx6CPM9b0TENK6aoSu5t73dItudwdgmi6tHlIZZId4dZ9skcAQ2UbcyAeVA==} + yaml@2.3.4: + resolution: {integrity: sha512-8aAvwVUSHpfEqTQ4w/KMlf3HcRdt50E5ODIQJBw1fQ5RL34xabzxtUlzTXVqc4rkZsPbvrXKWnABCD7kWSmocA==} engines: {node: '>= 14'} - hasBin: true yocto-queue@0.1.0: resolution: {integrity: sha512-rVksvsnNCdJ/ohGc6xgPwyN8eheCxsiLM8mxuE/t/mOVqJewPuO1miLpTHQiRgTKCLexL4MeAFVagts7HmNZ2Q==} @@ -3656,19 +3808,20 @@ packages: resolution: {integrity: sha512-9bnSc/HEW2uRy67wc+T8UwauLuPJVn28jb+GtJY16iiKWyvmYJRXVT4UamsAEGQfPohgr2q4Tq0sQbQlxTfi1g==} engines: {node: '>=12.20'} - zod@3.21.4: - resolution: {integrity: sha512-m46AKbrzKVzOzs/DZgVnG5H55N1sv1M8qZU3A8RIKbs3mrACDNeIOeilDymVb2HdmP8uwshOCF4uJ8uM9rCqJw==} - - zod@3.23.8: - resolution: {integrity: sha512-XBx9AXhXktjUqnepgTiE5flcKIYWi/rme0Eaj+5Y0lftuGBq+jyRu/md4WnuxqgP1ubdpNCsYEYPxrzVHD8d6g==} + zod@3.22.4: + resolution: {integrity: sha512-iC+8Io04lddc+mVqQ9AZ7OQ2MrUKGN+oIQyq1vemgt46jwCwLfhq7/pwnBnNXXXZb8VTVLKwp9EDkx+ryxIWmg==} zwitch@2.0.4: resolution: {integrity: sha512-bXE4cR/kVZhKZX/RjPEflHaKVhUVl85noU3v6b8apfQEc1x4A+zBxjZ4lN8LqGd6WZ3dl98pY4o717VFmoPp+A==} snapshots: + '@aashutoshrathi/word-wrap@1.2.6': {} + '@adraffy/ens-normalize@1.10.0': {} + '@adraffy/ens-normalize@1.11.0': {} + '@algolia/cache-browser-local-storage@4.23.3': dependencies: '@algolia/cache-common': 4.23.3 @@ -3753,36 +3906,35 @@ snapshots: js-yaml: 4.1.0 lodash.clonedeep: 4.5.0 - '@babel/code-frame@7.24.2': + '@babel/code-frame@7.23.4': dependencies: - '@babel/highlight': 7.24.2 - picocolors: 1.0.0 + '@babel/highlight': 7.23.4 + chalk: 2.4.2 '@babel/helper-validator-identifier@7.22.20': {} - '@babel/highlight@7.24.2': + '@babel/highlight@7.23.4': dependencies: '@babel/helper-validator-identifier': 7.22.20 chalk: 2.4.2 js-tokens: 4.0.0 - picocolors: 1.0.0 - '@babel/runtime@7.24.4': + '@babel/runtime@7.23.2': dependencies: - regenerator-runtime: 0.14.1 + regenerator-runtime: 0.14.0 '@braintree/sanitize-url@6.0.4': {} '@corex/deepmerge@4.0.43': {} - '@cspell/cspell-bundled-dicts@8.7.0': + '@cspell/cspell-bundled-dicts@8.1.3': dependencies: '@cspell/dict-ada': 4.0.2 - '@cspell/dict-aws': 4.0.1 + '@cspell/dict-aws': 4.0.0 '@cspell/dict-bash': 4.1.3 - '@cspell/dict-companies': 3.0.31 - '@cspell/dict-cpp': 5.1.3 - '@cspell/dict-cryptocurrencies': 5.0.0 + '@cspell/dict-companies': 3.0.28 + '@cspell/dict-cpp': 5.0.10 + '@cspell/dict-cryptocurrencies': 4.0.0 '@cspell/dict-csharp': 4.0.2 '@cspell/dict-css': 4.0.12 '@cspell/dict-dart': 2.0.3 @@ -3790,70 +3942,67 @@ snapshots: '@cspell/dict-docker': 1.1.7 '@cspell/dict-dotnet': 5.0.0 '@cspell/dict-elixir': 4.0.3 - '@cspell/dict-en-common-misspellings': 2.0.0 + '@cspell/dict-en-common-misspellings': 1.0.2 '@cspell/dict-en-gb': 1.1.33 - '@cspell/dict-en_us': 4.3.19 + '@cspell/dict-en_us': 4.3.12 '@cspell/dict-filetypes': 3.0.3 '@cspell/dict-fonts': 4.0.0 '@cspell/dict-fsharp': 1.0.1 '@cspell/dict-fullstack': 3.1.5 - '@cspell/dict-gaming-terms': 1.0.5 - '@cspell/dict-git': 3.0.0 + '@cspell/dict-gaming-terms': 1.0.4 + '@cspell/dict-git': 2.0.0 '@cspell/dict-golang': 6.0.5 '@cspell/dict-haskell': 4.0.1 '@cspell/dict-html': 4.0.5 '@cspell/dict-html-symbol-entities': 4.0.0 '@cspell/dict-java': 5.0.6 - '@cspell/dict-julia': 1.0.1 '@cspell/dict-k8s': 1.0.2 '@cspell/dict-latex': 4.0.0 '@cspell/dict-lorem-ipsum': 4.0.0 '@cspell/dict-lua': 4.0.3 '@cspell/dict-makefile': 1.0.0 - '@cspell/dict-monkeyc': 1.0.6 '@cspell/dict-node': 4.0.3 - '@cspell/dict-npm': 5.0.15 - '@cspell/dict-php': 4.0.6 + '@cspell/dict-npm': 5.0.13 + '@cspell/dict-php': 4.0.4 '@cspell/dict-powershell': 5.0.3 - '@cspell/dict-public-licenses': 2.0.6 - '@cspell/dict-python': 4.1.11 + '@cspell/dict-public-licenses': 2.0.5 + '@cspell/dict-python': 4.1.10 '@cspell/dict-r': 2.0.1 - '@cspell/dict-ruby': 5.0.2 - '@cspell/dict-rust': 4.0.2 + '@cspell/dict-ruby': 5.0.1 + '@cspell/dict-rust': 4.0.1 '@cspell/dict-scala': 5.0.0 - '@cspell/dict-software-terms': 3.3.20 - '@cspell/dict-sql': 2.1.3 + '@cspell/dict-software-terms': 3.3.12 + '@cspell/dict-sql': 2.1.2 '@cspell/dict-svelte': 1.0.2 '@cspell/dict-swift': 2.0.1 - '@cspell/dict-terraform': 1.0.0 - '@cspell/dict-typescript': 3.1.4 + '@cspell/dict-typescript': 3.1.2 '@cspell/dict-vue': 3.0.0 - '@cspell/cspell-json-reporter@8.7.0': + '@cspell/cspell-json-reporter@8.1.3': dependencies: - '@cspell/cspell-types': 8.7.0 + '@cspell/cspell-types': 8.1.3 - '@cspell/cspell-pipe@8.7.0': {} + '@cspell/cspell-pipe@8.1.3': {} - '@cspell/cspell-resolver@8.7.0': + '@cspell/cspell-resolver@8.1.3': dependencies: global-directory: 4.0.1 - '@cspell/cspell-service-bus@8.7.0': {} + '@cspell/cspell-service-bus@8.1.3': {} - '@cspell/cspell-types@8.7.0': {} + '@cspell/cspell-types@8.1.3': {} '@cspell/dict-ada@4.0.2': {} - '@cspell/dict-aws@4.0.1': {} + '@cspell/dict-aws@4.0.0': {} '@cspell/dict-bash@4.1.3': {} - '@cspell/dict-companies@3.0.31': {} + '@cspell/dict-companies@3.0.28': {} - '@cspell/dict-cpp@5.1.3': {} + '@cspell/dict-cpp@5.0.10': {} - '@cspell/dict-cryptocurrencies@5.0.0': {} + '@cspell/dict-cryptocurrencies@4.0.0': {} '@cspell/dict-csharp@4.0.2': {} @@ -3871,11 +4020,11 @@ snapshots: '@cspell/dict-elixir@4.0.3': {} - '@cspell/dict-en-common-misspellings@2.0.0': {} + '@cspell/dict-en-common-misspellings@1.0.2': {} '@cspell/dict-en-gb@1.1.33': {} - '@cspell/dict-en_us@4.3.19': {} + '@cspell/dict-en_us@4.3.12': {} '@cspell/dict-filetypes@3.0.3': {} @@ -3885,9 +4034,9 @@ snapshots: '@cspell/dict-fullstack@3.1.5': {} - '@cspell/dict-gaming-terms@1.0.5': {} + '@cspell/dict-gaming-terms@1.0.4': {} - '@cspell/dict-git@3.0.0': {} + '@cspell/dict-git@2.0.0': {} '@cspell/dict-golang@6.0.5': {} @@ -3899,8 +4048,6 @@ snapshots: '@cspell/dict-java@5.0.6': {} - '@cspell/dict-julia@1.0.1': {} - '@cspell/dict-k8s@1.0.2': {} '@cspell/dict-latex@4.0.0': {} @@ -3911,49 +4058,45 @@ snapshots: '@cspell/dict-makefile@1.0.0': {} - '@cspell/dict-monkeyc@1.0.6': {} - '@cspell/dict-node@4.0.3': {} - '@cspell/dict-npm@5.0.15': {} + '@cspell/dict-npm@5.0.13': {} - '@cspell/dict-php@4.0.6': {} + '@cspell/dict-php@4.0.4': {} '@cspell/dict-powershell@5.0.3': {} - '@cspell/dict-public-licenses@2.0.6': {} + '@cspell/dict-public-licenses@2.0.5': {} - '@cspell/dict-python@4.1.11': + '@cspell/dict-python@4.1.10': dependencies: '@cspell/dict-data-science': 1.0.11 '@cspell/dict-r@2.0.1': {} - '@cspell/dict-ruby@5.0.2': {} + '@cspell/dict-ruby@5.0.1': {} - '@cspell/dict-rust@4.0.2': {} + '@cspell/dict-rust@4.0.1': {} '@cspell/dict-scala@5.0.0': {} - '@cspell/dict-software-terms@3.3.20': {} + '@cspell/dict-software-terms@3.3.12': {} - '@cspell/dict-sql@2.1.3': {} + '@cspell/dict-sql@2.1.2': {} '@cspell/dict-svelte@1.0.2': {} '@cspell/dict-swift@2.0.1': {} - '@cspell/dict-terraform@1.0.0': {} - - '@cspell/dict-typescript@3.1.4': {} + '@cspell/dict-typescript@3.1.2': {} '@cspell/dict-vue@3.0.0': {} - '@cspell/dynamic-import@8.7.0': + '@cspell/dynamic-import@8.1.3': dependencies: - import-meta-resolve: 4.1.0 + import-meta-resolve: 4.0.0 - '@cspell/strong-weak-map@8.7.0': {} + '@cspell/strong-weak-map@8.1.3': {} '@double-great/alt-text@3.1.0': dependencies: @@ -3967,20 +4110,20 @@ snapshots: unified-lint-rule: 2.1.2 unist-util-visit-parents: 5.1.3 - '@eslint-community/eslint-utils@4.4.0(eslint@8.57.0)': + '@eslint-community/eslint-utils@4.4.0(eslint@8.54.0)': dependencies: - eslint: 8.57.0 + eslint: 8.54.0 eslint-visitor-keys: 3.4.3 '@eslint-community/regexpp@4.10.0': {} - '@eslint/eslintrc@2.1.4': + '@eslint/eslintrc@2.1.3': dependencies: ajv: 6.12.6 debug: 4.3.4 espree: 9.6.1 - globals: 13.24.0 - ignore: 5.3.1 + globals: 13.23.0 + ignore: 5.3.0 import-fresh: 3.3.0 js-yaml: 4.1.0 minimatch: 3.1.2 @@ -3988,18 +4131,18 @@ snapshots: transitivePeerDependencies: - supports-color - '@eslint/js@8.57.0': {} + '@eslint/js@8.54.0': {} - '@eth-optimism/contracts-bedrock@0.17.2': {} + '@eth-optimism/contracts-bedrock@0.16.2': {} - '@eth-optimism/contracts-ts@0.17.2(typescript@5.4.5)(zod@3.23.8)': + '@eth-optimism/contracts-ts@0.17.0(typescript@5.3.2)(zod@3.22.4)': dependencies: - '@testing-library/react': 14.3.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1) + '@testing-library/react': 14.1.2(react-dom@18.2.0(react@18.2.0))(react@18.2.0) '@types/change-case': 2.3.1 change-case: 4.1.2 - react: 18.3.1 - react-dom: 18.3.1(react@18.3.1) - viem: 2.9.28(typescript@5.4.5)(zod@3.23.8) + react: 18.2.0 + react-dom: 18.2.0(react@18.2.0) + viem: 1.19.6(typescript@5.3.2)(zod@3.22.4) transitivePeerDependencies: - bufferutil - typescript @@ -4033,12 +4176,12 @@ snapshots: '@ethersproject/transactions': 5.7.0 '@ethersproject/web': 5.7.1 bufio: 1.2.1 - chai: 4.4.1 + chai: 4.3.10 transitivePeerDependencies: - bufferutil - utf-8-validate - '@eth-optimism/core-utils@0.13.2': + '@eth-optimism/core-utils@0.13.1': dependencies: '@ethersproject/abi': 5.7.0 '@ethersproject/abstract-provider': 5.7.0 @@ -4051,7 +4194,7 @@ snapshots: '@ethersproject/properties': 5.7.0 '@ethersproject/rlp': 5.7.0 '@ethersproject/web': 5.7.1 - chai: 4.4.1 + chai: 4.3.10 ethers: 5.7.2 node-fetch: 2.7.0 transitivePeerDependencies: @@ -4059,29 +4202,28 @@ snapshots: - encoding - utf-8-validate - '@eth-optimism/sdk@3.3.0(ethers@5.7.2)': + '@eth-optimism/sdk@3.1.6(ethers@5.7.2)': dependencies: '@eth-optimism/contracts': 0.6.0(ethers@5.7.2) - '@eth-optimism/contracts-bedrock': 0.17.2 - '@eth-optimism/core-utils': 0.13.2 + '@eth-optimism/contracts-bedrock': 0.16.2 + '@eth-optimism/core-utils': 0.13.1 ethers: 5.7.2 lodash: 4.17.21 merkletreejs: 0.3.11 rlp: 2.2.7 - semver: 7.6.0 transitivePeerDependencies: - bufferutil - encoding - utf-8-validate - '@eth-optimism/tokenlist@9.0.51': {} + '@eth-optimism/tokenlist@9.0.9': {} '@ethereumjs/rlp@4.0.1': {} '@ethereumjs/util@8.1.0': dependencies: '@ethereumjs/rlp': 4.0.1 - ethereum-cryptography: 2.1.3 + ethereum-cryptography: 2.1.2 micro-ftch: 0.3.1 '@ethersproject/abi@5.7.0': @@ -4341,55 +4483,54 @@ snapshots: '@feelback/js@0.3.4': {} - '@feelback/react@0.3.4(react@18.3.1)': + '@feelback/react@0.3.4(react@18.2.0)': dependencies: '@feelback/js': 0.3.4 - react: 18.3.1 + react: 18.2.0 - '@floating-ui/core@1.6.2': + '@floating-ui/core@1.6.8': dependencies: - '@floating-ui/utils': 0.2.2 + '@floating-ui/utils': 0.2.8 - '@floating-ui/dom@1.6.5': + '@floating-ui/dom@1.6.11': dependencies: - '@floating-ui/core': 1.6.2 - '@floating-ui/utils': 0.2.2 + '@floating-ui/core': 1.6.8 + '@floating-ui/utils': 0.2.8 - '@floating-ui/react-dom@2.1.0(react-dom@18.3.1(react@18.3.1))(react@18.3.1)': + '@floating-ui/react-dom@2.1.2(react-dom@18.2.0(react@18.2.0))(react@18.2.0)': dependencies: - '@floating-ui/dom': 1.6.5 - react: 18.3.1 - react-dom: 18.3.1(react@18.3.1) + '@floating-ui/dom': 1.6.11 + react: 18.2.0 + react-dom: 18.2.0(react@18.2.0) - '@floating-ui/react@0.26.17(react-dom@18.3.1(react@18.3.1))(react@18.3.1)': + '@floating-ui/react@0.26.25(react-dom@18.2.0(react@18.2.0))(react@18.2.0)': dependencies: - '@floating-ui/react-dom': 2.1.0(react-dom@18.3.1(react@18.3.1))(react@18.3.1) - '@floating-ui/utils': 0.2.2 - react: 18.3.1 - react-dom: 18.3.1(react@18.3.1) + '@floating-ui/react-dom': 2.1.2(react-dom@18.2.0(react@18.2.0))(react@18.2.0) + '@floating-ui/utils': 0.2.8 + react: 18.2.0 + react-dom: 18.2.0(react@18.2.0) tabbable: 6.2.0 - '@floating-ui/utils@0.2.2': {} + '@floating-ui/utils@0.2.8': {} - '@headlessui/react@1.7.19(react-dom@18.3.1(react@18.3.1))(react@18.3.1)': + '@headlessui/react@1.7.17(react-dom@18.2.0(react@18.2.0))(react@18.2.0)': dependencies: - '@tanstack/react-virtual': 3.5.0(react-dom@18.3.1(react@18.3.1))(react@18.3.1) client-only: 0.0.1 - react: 18.3.1 - react-dom: 18.3.1(react@18.3.1) + react: 18.2.0 + react-dom: 18.2.0(react@18.2.0) - '@headlessui/react@2.1.0(react-dom@18.3.1(react@18.3.1))(react@18.3.1)': + '@headlessui/react@2.1.8(react-dom@18.2.0(react@18.2.0))(react@18.2.0)': dependencies: - '@floating-ui/react': 0.26.17(react-dom@18.3.1(react@18.3.1))(react@18.3.1) - '@react-aria/focus': 3.17.1(react@18.3.1) - '@react-aria/interactions': 3.21.3(react@18.3.1) - '@tanstack/react-virtual': 3.5.0(react-dom@18.3.1(react@18.3.1))(react@18.3.1) - react: 18.3.1 - react-dom: 18.3.1(react@18.3.1) + '@floating-ui/react': 0.26.25(react-dom@18.2.0(react@18.2.0))(react@18.2.0) + '@react-aria/focus': 3.18.4(react@18.2.0) + '@react-aria/interactions': 3.22.4(react@18.2.0) + '@tanstack/react-virtual': 3.10.8(react-dom@18.2.0(react@18.2.0))(react@18.2.0) + react: 18.2.0 + react-dom: 18.2.0(react@18.2.0) - '@humanwhocodes/config-array@0.11.14': + '@humanwhocodes/config-array@0.11.13': dependencies: - '@humanwhocodes/object-schema': 2.0.3 + '@humanwhocodes/object-schema': 2.0.1 debug: 4.3.4 minimatch: 3.1.2 transitivePeerDependencies: @@ -4397,7 +4538,7 @@ snapshots: '@humanwhocodes/module-importer@1.0.1': {} - '@humanwhocodes/object-schema@2.0.3': {} + '@humanwhocodes/object-schema@2.0.1': {} '@isaacs/cliui@8.0.2': dependencies: @@ -4412,8 +4553,8 @@ snapshots: '@mdx-js/mdx@2.3.0': dependencies: - '@types/estree-jsx': 1.0.5 - '@types/mdx': 2.0.13 + '@types/estree-jsx': 1.0.3 + '@types/mdx': 2.0.9 estree-util-build-jsx: 2.2.2 estree-util-is-identifier-name: 2.1.0 estree-util-to-js: 1.2.0 @@ -4432,103 +4573,107 @@ snapshots: transitivePeerDependencies: - supports-color - '@mdx-js/react@2.3.0(react@18.3.1)': + '@mdx-js/react@2.3.0(react@18.2.0)': dependencies: - '@types/mdx': 2.0.13 - '@types/react': 18.3.1 - react: 18.3.1 + '@types/mdx': 2.0.9 + '@types/react': 18.2.36 + react: 18.2.0 - '@napi-rs/simple-git-android-arm-eabi@0.1.16': + '@napi-rs/simple-git-android-arm-eabi@0.1.9': optional: true - '@napi-rs/simple-git-android-arm64@0.1.16': + '@napi-rs/simple-git-android-arm64@0.1.9': optional: true - '@napi-rs/simple-git-darwin-arm64@0.1.16': + '@napi-rs/simple-git-darwin-arm64@0.1.9': optional: true - '@napi-rs/simple-git-darwin-x64@0.1.16': + '@napi-rs/simple-git-darwin-x64@0.1.9': optional: true - '@napi-rs/simple-git-linux-arm-gnueabihf@0.1.16': + '@napi-rs/simple-git-linux-arm-gnueabihf@0.1.9': optional: true - '@napi-rs/simple-git-linux-arm64-gnu@0.1.16': + '@napi-rs/simple-git-linux-arm64-gnu@0.1.9': optional: true - '@napi-rs/simple-git-linux-arm64-musl@0.1.16': + '@napi-rs/simple-git-linux-arm64-musl@0.1.9': optional: true - '@napi-rs/simple-git-linux-x64-gnu@0.1.16': + '@napi-rs/simple-git-linux-x64-gnu@0.1.9': optional: true - '@napi-rs/simple-git-linux-x64-musl@0.1.16': + '@napi-rs/simple-git-linux-x64-musl@0.1.9': optional: true - '@napi-rs/simple-git-win32-arm64-msvc@0.1.16': + '@napi-rs/simple-git-win32-arm64-msvc@0.1.9': optional: true - '@napi-rs/simple-git-win32-x64-msvc@0.1.16': + '@napi-rs/simple-git-win32-x64-msvc@0.1.9': optional: true - '@napi-rs/simple-git@0.1.16': + '@napi-rs/simple-git@0.1.9': optionalDependencies: - '@napi-rs/simple-git-android-arm-eabi': 0.1.16 - '@napi-rs/simple-git-android-arm64': 0.1.16 - '@napi-rs/simple-git-darwin-arm64': 0.1.16 - '@napi-rs/simple-git-darwin-x64': 0.1.16 - '@napi-rs/simple-git-linux-arm-gnueabihf': 0.1.16 - '@napi-rs/simple-git-linux-arm64-gnu': 0.1.16 - '@napi-rs/simple-git-linux-arm64-musl': 0.1.16 - '@napi-rs/simple-git-linux-x64-gnu': 0.1.16 - '@napi-rs/simple-git-linux-x64-musl': 0.1.16 - '@napi-rs/simple-git-win32-arm64-msvc': 0.1.16 - '@napi-rs/simple-git-win32-x64-msvc': 0.1.16 - - '@next/env@13.5.1': {} + '@napi-rs/simple-git-android-arm-eabi': 0.1.9 + '@napi-rs/simple-git-android-arm64': 0.1.9 + '@napi-rs/simple-git-darwin-arm64': 0.1.9 + '@napi-rs/simple-git-darwin-x64': 0.1.9 + '@napi-rs/simple-git-linux-arm-gnueabihf': 0.1.9 + '@napi-rs/simple-git-linux-arm64-gnu': 0.1.9 + '@napi-rs/simple-git-linux-arm64-musl': 0.1.9 + '@napi-rs/simple-git-linux-x64-gnu': 0.1.9 + '@napi-rs/simple-git-linux-x64-musl': 0.1.9 + '@napi-rs/simple-git-win32-arm64-msvc': 0.1.9 + '@napi-rs/simple-git-win32-x64-msvc': 0.1.9 '@next/env@13.5.6': {} - '@next/swc-darwin-arm64@13.5.1': + '@next/env@14.2.10': {} + + '@next/swc-darwin-arm64@14.2.10': optional: true - '@next/swc-darwin-x64@13.5.1': + '@next/swc-darwin-x64@14.2.10': optional: true - '@next/swc-linux-arm64-gnu@13.5.1': + '@next/swc-linux-arm64-gnu@14.2.10': optional: true - '@next/swc-linux-arm64-musl@13.5.1': + '@next/swc-linux-arm64-musl@14.2.10': optional: true - '@next/swc-linux-x64-gnu@13.5.1': + '@next/swc-linux-x64-gnu@14.2.10': optional: true - '@next/swc-linux-x64-musl@13.5.1': + '@next/swc-linux-x64-musl@14.2.10': optional: true - '@next/swc-win32-arm64-msvc@13.5.1': + '@next/swc-win32-arm64-msvc@14.2.10': optional: true - '@next/swc-win32-ia32-msvc@13.5.1': + '@next/swc-win32-ia32-msvc@14.2.10': optional: true - '@next/swc-win32-x64-msvc@13.5.1': + '@next/swc-win32-x64-msvc@14.2.10': optional: true + '@noble/curves@1.1.0': + dependencies: + '@noble/hashes': 1.3.1 + '@noble/curves@1.2.0': dependencies: '@noble/hashes': 1.3.2 - '@noble/curves@1.3.0': + '@noble/curves@1.6.0': dependencies: - '@noble/hashes': 1.3.3 + '@noble/hashes': 1.5.0 - '@noble/hashes@1.3.2': {} + '@noble/hashes@1.3.1': {} - '@noble/hashes@1.3.3': {} + '@noble/hashes@1.3.2': {} - '@noble/hashes@1.4.0': {} + '@noble/hashes@1.5.0': {} '@nodelib/fs.scandir@2.1.5': dependencies: @@ -4540,24 +4685,24 @@ snapshots: '@nodelib/fs.walk@1.2.8': dependencies: '@nodelib/fs.scandir': 2.1.5 - fastq: 1.17.1 + fastq: 1.15.0 - '@npmcli/config@6.4.1': + '@npmcli/config@6.4.0': dependencies: - '@npmcli/map-workspaces': 3.0.6 - ci-info: 4.0.0 - ini: 4.1.2 + '@npmcli/map-workspaces': 3.0.4 + ci-info: 3.9.0 + ini: 4.1.1 nopt: 7.2.0 proc-log: 3.0.0 read-package-json-fast: 3.0.2 - semver: 7.6.0 + semver: 7.5.4 walk-up-path: 3.0.1 - '@npmcli/map-workspaces@3.0.6': + '@npmcli/map-workspaces@3.0.4': dependencies: '@npmcli/name-from-folder': 2.0.0 - glob: 10.3.12 - minimatch: 9.0.4 + glob: 10.3.10 + minimatch: 9.0.3 read-package-json-fast: 3.0.2 '@npmcli/name-from-folder@2.0.0': {} @@ -4565,90 +4710,112 @@ snapshots: '@pkgjs/parseargs@0.11.0': optional: true - '@pkgr/core@0.1.1': {} + '@pkgr/utils@2.4.2': + dependencies: + cross-spawn: 7.0.3 + fast-glob: 3.3.2 + is-glob: 4.0.3 + open: 9.1.0 + picocolors: 1.0.0 + tslib: 2.6.2 '@popperjs/core@2.11.8': {} - '@react-aria/focus@3.17.1(react@18.3.1)': + '@react-aria/focus@3.18.4(react@18.2.0)': dependencies: - '@react-aria/interactions': 3.21.3(react@18.3.1) - '@react-aria/utils': 3.24.1(react@18.3.1) - '@react-types/shared': 3.23.1(react@18.3.1) + '@react-aria/interactions': 3.22.4(react@18.2.0) + '@react-aria/utils': 3.25.3(react@18.2.0) + '@react-types/shared': 3.25.0(react@18.2.0) '@swc/helpers': 0.5.2 clsx: 2.1.1 - react: 18.3.1 + react: 18.2.0 - '@react-aria/interactions@3.21.3(react@18.3.1)': + '@react-aria/interactions@3.22.4(react@18.2.0)': dependencies: - '@react-aria/ssr': 3.9.4(react@18.3.1) - '@react-aria/utils': 3.24.1(react@18.3.1) - '@react-types/shared': 3.23.1(react@18.3.1) + '@react-aria/ssr': 3.9.6(react@18.2.0) + '@react-aria/utils': 3.25.3(react@18.2.0) + '@react-types/shared': 3.25.0(react@18.2.0) '@swc/helpers': 0.5.2 - react: 18.3.1 + react: 18.2.0 - '@react-aria/ssr@3.9.4(react@18.3.1)': + '@react-aria/ssr@3.9.6(react@18.2.0)': dependencies: '@swc/helpers': 0.5.2 - react: 18.3.1 + react: 18.2.0 - '@react-aria/utils@3.24.1(react@18.3.1)': + '@react-aria/utils@3.25.3(react@18.2.0)': dependencies: - '@react-aria/ssr': 3.9.4(react@18.3.1) - '@react-stately/utils': 3.10.1(react@18.3.1) - '@react-types/shared': 3.23.1(react@18.3.1) + '@react-aria/ssr': 3.9.6(react@18.2.0) + '@react-stately/utils': 3.10.4(react@18.2.0) + '@react-types/shared': 3.25.0(react@18.2.0) '@swc/helpers': 0.5.2 clsx: 2.1.1 - react: 18.3.1 + react: 18.2.0 - '@react-stately/utils@3.10.1(react@18.3.1)': + '@react-stately/utils@3.10.4(react@18.2.0)': dependencies: '@swc/helpers': 0.5.2 - react: 18.3.1 + react: 18.2.0 - '@react-types/shared@3.23.1(react@18.3.1)': + '@react-types/shared@3.25.0(react@18.2.0)': dependencies: - react: 18.3.1 + react: 18.2.0 + + '@scure/base@1.1.3': {} - '@scure/base@1.1.6': {} + '@scure/base@1.1.9': {} + + '@scure/bip32@1.3.1': + dependencies: + '@noble/curves': 1.1.0 + '@noble/hashes': 1.3.2 + '@scure/base': 1.1.3 '@scure/bip32@1.3.2': dependencies: '@noble/curves': 1.2.0 '@noble/hashes': 1.3.2 - '@scure/base': 1.1.6 + '@scure/base': 1.1.3 - '@scure/bip32@1.3.3': + '@scure/bip32@1.5.0': dependencies: - '@noble/curves': 1.3.0 - '@noble/hashes': 1.3.3 - '@scure/base': 1.1.6 + '@noble/curves': 1.6.0 + '@noble/hashes': 1.5.0 + '@scure/base': 1.1.9 '@scure/bip39@1.2.1': dependencies: '@noble/hashes': 1.3.2 - '@scure/base': 1.1.6 + '@scure/base': 1.1.3 - '@scure/bip39@1.2.2': + '@scure/bip39@1.4.0': dependencies: - '@noble/hashes': 1.3.3 - '@scure/base': 1.1.6 + '@noble/hashes': 1.5.0 + '@scure/base': 1.1.9 + + '@swc/counter@0.1.3': {} '@swc/helpers@0.5.2': dependencies: tslib: 2.6.2 - '@tanstack/react-virtual@3.5.0(react-dom@18.3.1(react@18.3.1))(react@18.3.1)': + '@swc/helpers@0.5.5': + dependencies: + '@swc/counter': 0.1.3 + tslib: 2.6.2 + + '@tanstack/react-virtual@3.10.8(react-dom@18.2.0(react@18.2.0))(react@18.2.0)': dependencies: - '@tanstack/virtual-core': 3.5.0 - react: 18.3.1 - react-dom: 18.3.1(react@18.3.1) + '@tanstack/virtual-core': 3.10.8 + react: 18.2.0 + react-dom: 18.2.0(react@18.2.0) - '@tanstack/virtual-core@3.5.0': {} + '@tanstack/virtual-core@3.10.8': {} - '@testing-library/dom@9.3.4': + '@testing-library/dom@9.3.3': dependencies: - '@babel/code-frame': 7.24.2 - '@babel/runtime': 7.24.4 + '@babel/code-frame': 7.23.4 + '@babel/runtime': 7.23.2 '@types/aria-query': 5.0.4 aria-query: 5.1.3 chalk: 4.1.2 @@ -4656,25 +4823,25 @@ snapshots: lz-string: 1.5.0 pretty-format: 27.5.1 - '@testing-library/react@14.3.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1)': + '@testing-library/react@14.1.2(react-dom@18.2.0(react@18.2.0))(react@18.2.0)': dependencies: - '@babel/runtime': 7.24.4 - '@testing-library/dom': 9.3.4 - '@types/react-dom': 18.3.0 - react: 18.3.1 - react-dom: 18.3.1(react@18.3.1) + '@babel/runtime': 7.23.2 + '@testing-library/dom': 9.3.3 + '@types/react-dom': 18.2.16 + react: 18.2.0 + react-dom: 18.2.0(react@18.2.0) - '@theguild/remark-mermaid@0.0.5(react@18.3.1)': + '@theguild/remark-mermaid@0.0.5(react@18.2.0)': dependencies: - mermaid: 10.9.0 - react: 18.3.1 + mermaid: 10.6.1 + react: 18.2.0 unist-util-visit: 5.0.0 transitivePeerDependencies: - supports-color '@theguild/remark-npm2yarn@0.2.1': dependencies: - npm-to-yarn: 2.2.1 + npm-to-yarn: 2.1.0 unist-util-visit: 5.0.0 '@types/acorn@4.0.6': @@ -4691,91 +4858,99 @@ snapshots: dependencies: '@types/node': 18.11.10 - '@types/d3-scale-chromatic@3.0.3': {} + '@types/d3-scale-chromatic@3.0.1': {} - '@types/d3-scale@4.0.8': + '@types/d3-scale@4.0.7': dependencies: - '@types/d3-time': 3.0.3 + '@types/d3-time': 3.0.2 - '@types/d3-time@3.0.3': {} + '@types/d3-time@3.0.2': {} - '@types/debug@4.1.12': + '@types/debug@4.1.11': dependencies: - '@types/ms': 0.7.34 + '@types/ms': 0.7.33 - '@types/estree-jsx@1.0.5': + '@types/estree-jsx@1.0.3': dependencies: '@types/estree': 1.0.5 '@types/estree@1.0.5': {} - '@types/hast@2.3.10': + '@types/hast@2.3.7': dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 - '@types/hast@3.0.4': + '@types/hast@3.0.2': dependencies: - '@types/unist': 3.0.2 + '@types/unist': 3.0.1 '@types/is-empty@1.2.3': {} - '@types/js-yaml@4.0.9': {} + '@types/js-yaml@4.0.8': {} '@types/json-schema@7.0.15': {} - '@types/katex@0.16.7': {} + '@types/katex@0.16.5': {} '@types/lodash.clonedeep@4.5.9': dependencies: - '@types/lodash': 4.17.0 + '@types/lodash': 4.14.202 - '@types/lodash@4.17.0': {} + '@types/lodash@4.14.202': {} - '@types/mdast@3.0.15': + '@types/mdast@3.0.14': dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 - '@types/mdast@4.0.3': + '@types/mdast@4.0.2': dependencies: - '@types/unist': 3.0.2 + '@types/unist': 3.0.1 - '@types/mdx@2.0.13': {} + '@types/mdx@2.0.9': {} - '@types/ms@0.7.34': {} + '@types/ms@0.7.33': {} '@types/node@18.11.10': {} - '@types/prop-types@15.7.12': {} + '@types/prop-types@15.7.9': {} - '@types/react-dom@18.3.0': + '@types/react-dom@18.2.16': dependencies: - '@types/react': 18.3.1 + '@types/react': 18.2.36 - '@types/react@18.3.1': + '@types/react@18.2.36': dependencies: - '@types/prop-types': 15.7.12 - csstype: 3.1.3 + '@types/prop-types': 15.7.9 + '@types/scheduler': 0.16.5 + csstype: 3.1.2 + + '@types/scheduler@0.16.5': {} '@types/supports-color@8.1.3': {} - '@types/unist@2.0.10': {} + '@types/unist@2.0.9': {} - '@types/unist@3.0.2': {} + '@types/unist@3.0.1': {} '@ungap/structured-clone@1.2.0': {} abbrev@2.0.0: {} - abitype@1.0.0(typescript@5.4.5)(zod@3.23.8): + abitype@0.9.8(typescript@5.3.2)(zod@3.22.4): + optionalDependencies: + typescript: 5.3.2 + zod: 3.22.4 + + abitype@1.0.6(typescript@5.3.2)(zod@3.22.4): optionalDependencies: - typescript: 5.4.5 - zod: 3.23.8 + typescript: 5.3.2 + zod: 3.22.4 - acorn-jsx@5.3.2(acorn@8.11.3): + acorn-jsx@5.3.2(acorn@8.11.2): dependencies: - acorn: 8.11.3 + acorn: 8.11.2 - acorn@8.11.3: {} + acorn@8.11.2: {} aes-js@3.0.0: {} @@ -4847,10 +5022,10 @@ snapshots: dependencies: deep-equal: 2.2.3 - array-buffer-byte-length@1.0.1: + array-buffer-byte-length@1.0.0: dependencies: - call-bind: 1.0.7 - is-array-buffer: 3.0.4 + call-bind: 1.0.5 + is-array-buffer: 3.0.2 array-timsort@1.0.3: {} @@ -4860,9 +5035,7 @@ snapshots: astring@1.8.6: {} - available-typed-arrays@1.0.7: - dependencies: - possible-typed-array-names: 1.0.0 + available-typed-arrays@1.0.5: {} bail@2.0.2: {} @@ -4870,6 +5043,8 @@ snapshots: bech32@1.1.4: {} + big-integer@1.6.52: {} + bignumber.js@9.1.2: {} bn.js@4.11.6: {} @@ -4878,6 +5053,10 @@ snapshots: bn.js@5.2.1: {} + bplist-parser@0.2.0: + dependencies: + big-integer: 1.6.52 + brace-expansion@1.1.11: dependencies: balanced-match: 1.0.2 @@ -4887,9 +5066,9 @@ snapshots: dependencies: balanced-match: 1.0.2 - braces@3.0.3: + braces@3.0.2: dependencies: - fill-range: 7.1.1 + fill-range: 7.0.1 brorand@1.1.0: {} @@ -4899,17 +5078,19 @@ snapshots: bufio@1.2.1: {} + bundle-name@3.0.0: + dependencies: + run-applescript: 5.0.0 + busboy@1.6.0: dependencies: streamsearch: 1.1.0 - call-bind@1.0.7: + call-bind@1.0.5: dependencies: - es-define-property: 1.0.0 - es-errors: 1.3.0 function-bind: 1.1.2 - get-intrinsic: 1.2.4 - set-function-length: 1.2.2 + get-intrinsic: 1.2.2 + set-function-length: 1.1.1 callsites@3.1.0: {} @@ -4918,7 +5099,7 @@ snapshots: pascal-case: 3.1.2 tslib: 2.6.2 - caniuse-lite@1.0.30001614: {} + caniuse-lite@1.0.30001669: {} capital-case@1.0.4: dependencies: @@ -4928,7 +5109,7 @@ snapshots: ccount@2.0.1: {} - chai@4.4.1: + chai@4.3.10: dependencies: assertion-error: 1.1.0 check-error: 1.0.3 @@ -4994,7 +5175,7 @@ snapshots: dependencies: get-func-name: 2.0.2 - ci-info@4.0.0: {} + ci-info@3.9.0: {} clear-module@4.1.2: dependencies: @@ -5024,7 +5205,7 @@ snapshots: comma-separated-tokens@2.0.3: {} - commander@12.0.0: {} + commander@11.1.0: {} commander@7.2.0: {} @@ -5069,6 +5250,10 @@ snapshots: dependencies: layout-base: 1.0.2 + cose-base@2.2.0: + dependencies: + layout-base: 2.0.1 + cross-spawn@5.1.0: dependencies: lru-cache: 4.1.5 @@ -5087,97 +5272,105 @@ snapshots: dependencies: type-fest: 1.4.0 - cspell-config-lib@8.7.0: + cspell-config-lib@8.1.3: dependencies: - '@cspell/cspell-types': 8.7.0 + '@cspell/cspell-types': 8.1.3 comment-json: 4.2.3 - yaml: 2.4.2 + yaml: 2.3.4 - cspell-dictionary@8.7.0: + cspell-dictionary@8.1.3: dependencies: - '@cspell/cspell-pipe': 8.7.0 - '@cspell/cspell-types': 8.7.0 - cspell-trie-lib: 8.7.0 + '@cspell/cspell-pipe': 8.1.3 + '@cspell/cspell-types': 8.1.3 + cspell-trie-lib: 8.1.3 fast-equals: 5.0.1 - gensequence: 7.0.0 + gensequence: 6.0.0 - cspell-gitignore@8.7.0: + cspell-gitignore@8.1.3: dependencies: - cspell-glob: 8.7.0 + cspell-glob: 8.1.3 find-up-simple: 1.0.0 - cspell-glob@8.7.0: + cspell-glob@8.1.3: dependencies: micromatch: 4.0.5 - cspell-grammar@8.7.0: + cspell-grammar@8.1.3: dependencies: - '@cspell/cspell-pipe': 8.7.0 - '@cspell/cspell-types': 8.7.0 + '@cspell/cspell-pipe': 8.1.3 + '@cspell/cspell-types': 8.1.3 - cspell-io@8.7.0: + cspell-io@8.1.3: dependencies: - '@cspell/cspell-service-bus': 8.7.0 + '@cspell/cspell-service-bus': 8.1.3 - cspell-lib@8.7.0: + cspell-lib@8.1.3: dependencies: - '@cspell/cspell-bundled-dicts': 8.7.0 - '@cspell/cspell-pipe': 8.7.0 - '@cspell/cspell-resolver': 8.7.0 - '@cspell/cspell-types': 8.7.0 - '@cspell/dynamic-import': 8.7.0 - '@cspell/strong-weak-map': 8.7.0 + '@cspell/cspell-bundled-dicts': 8.1.3 + '@cspell/cspell-pipe': 8.1.3 + '@cspell/cspell-resolver': 8.1.3 + '@cspell/cspell-types': 8.1.3 + '@cspell/dynamic-import': 8.1.3 + '@cspell/strong-weak-map': 8.1.3 clear-module: 4.1.2 comment-json: 4.2.3 configstore: 6.0.0 - cspell-config-lib: 8.7.0 - cspell-dictionary: 8.7.0 - cspell-glob: 8.7.0 - cspell-grammar: 8.7.0 - cspell-io: 8.7.0 - cspell-trie-lib: 8.7.0 + cspell-config-lib: 8.1.3 + cspell-dictionary: 8.1.3 + cspell-glob: 8.1.3 + cspell-grammar: 8.1.3 + cspell-io: 8.1.3 + cspell-trie-lib: 8.1.3 fast-equals: 5.0.1 - gensequence: 7.0.0 + gensequence: 6.0.0 import-fresh: 3.3.0 resolve-from: 5.0.0 vscode-languageserver-textdocument: 1.0.11 vscode-uri: 3.0.8 - cspell-trie-lib@8.7.0: + cspell-trie-lib@8.1.3: dependencies: - '@cspell/cspell-pipe': 8.7.0 - '@cspell/cspell-types': 8.7.0 - gensequence: 7.0.0 + '@cspell/cspell-pipe': 8.1.3 + '@cspell/cspell-types': 8.1.3 + gensequence: 6.0.0 - cspell@8.7.0: + cspell@8.1.3: dependencies: - '@cspell/cspell-json-reporter': 8.7.0 - '@cspell/cspell-pipe': 8.7.0 - '@cspell/cspell-types': 8.7.0 - '@cspell/dynamic-import': 8.7.0 + '@cspell/cspell-json-reporter': 8.1.3 + '@cspell/cspell-pipe': 8.1.3 + '@cspell/cspell-types': 8.1.3 + '@cspell/dynamic-import': 8.1.3 chalk: 5.3.0 chalk-template: 1.1.0 - commander: 12.0.0 - cspell-gitignore: 8.7.0 - cspell-glob: 8.7.0 - cspell-io: 8.7.0 - cspell-lib: 8.7.0 + commander: 11.1.0 + cspell-gitignore: 8.1.3 + cspell-glob: 8.1.3 + cspell-io: 8.1.3 + cspell-lib: 8.1.3 fast-glob: 3.3.2 fast-json-stable-stringify: 2.1.0 - file-entry-cache: 8.0.0 + file-entry-cache: 7.0.2 get-stdin: 9.0.0 - semver: 7.6.0 + semver: 7.5.4 strip-ansi: 7.1.0 vscode-uri: 3.0.8 - csstype@3.1.3: {} + csstype@3.1.2: {} - cytoscape-cose-bilkent@4.1.0(cytoscape@3.29.2): + cytoscape-cose-bilkent@4.1.0(cytoscape@3.27.0): dependencies: cose-base: 1.0.3 - cytoscape: 3.29.2 + cytoscape: 3.27.0 - cytoscape@3.29.2: {} + cytoscape-fcose@2.2.0(cytoscape@3.27.0): + dependencies: + cose-base: 2.2.0 + cytoscape: 3.27.0 + + cytoscape@3.27.0: + dependencies: + heap: 0.2.7 + lodash: 4.17.21 d3-array@2.12.1: dependencies: @@ -5209,7 +5402,7 @@ snapshots: d3-delaunay@6.0.4: dependencies: - delaunator: 5.0.1 + delaunator: 5.0.0 d3-dispatch@3.0.1: {} @@ -5238,7 +5431,7 @@ snapshots: d3-format@3.1.0: {} - d3-geo@3.1.1: + d3-geo@3.1.0: dependencies: d3-array: 3.2.4 @@ -5263,7 +5456,7 @@ snapshots: d3-array: 2.12.1 d3-shape: 1.3.7 - d3-scale-chromatic@3.1.0: + d3-scale-chromatic@3.0.0: dependencies: d3-color: 3.1.0 d3-interpolate: 3.0.1 @@ -5313,7 +5506,7 @@ snapshots: d3-selection: 3.0.0 d3-transition: 3.0.1(d3-selection@3.0.0) - d3@7.9.0: + d3@7.8.5: dependencies: d3-array: 3.2.4 d3-axis: 3.0.0 @@ -5329,7 +5522,7 @@ snapshots: d3-fetch: 3.0.1 d3-force: 3.0.0 d3-format: 3.1.0 - d3-geo: 3.1.1 + d3-geo: 3.1.0 d3-hierarchy: 3.1.2 d3-interpolate: 3.0.1 d3-path: 3.1.0 @@ -5337,7 +5530,7 @@ snapshots: d3-quadtree: 3.0.1 d3-random: 3.0.1 d3-scale: 4.0.2 - d3-scale-chromatic: 3.1.0 + d3-scale-chromatic: 3.0.0 d3-selection: 3.0.0 d3-shape: 3.2.0 d3-time: 3.1.0 @@ -5348,10 +5541,10 @@ snapshots: dagre-d3-es@7.0.10: dependencies: - d3: 7.9.0 + d3: 7.8.5 lodash-es: 4.17.21 - dayjs@1.11.11: {} + dayjs@1.11.10: {} debug@4.3.4: dependencies: @@ -5367,40 +5560,54 @@ snapshots: deep-equal@2.2.3: dependencies: - array-buffer-byte-length: 1.0.1 - call-bind: 1.0.7 + array-buffer-byte-length: 1.0.0 + call-bind: 1.0.5 es-get-iterator: 1.1.3 - get-intrinsic: 1.2.4 + get-intrinsic: 1.2.2 is-arguments: 1.1.1 - is-array-buffer: 3.0.4 + is-array-buffer: 3.0.2 is-date-object: 1.0.5 is-regex: 1.1.4 - is-shared-array-buffer: 1.0.3 + is-shared-array-buffer: 1.0.2 isarray: 2.0.5 - object-is: 1.1.6 + object-is: 1.1.5 object-keys: 1.1.1 - object.assign: 4.1.5 - regexp.prototype.flags: 1.5.2 - side-channel: 1.0.6 + object.assign: 4.1.4 + regexp.prototype.flags: 1.5.1 + side-channel: 1.0.4 which-boxed-primitive: 1.0.2 - which-collection: 1.0.2 - which-typed-array: 1.1.15 + which-collection: 1.0.1 + which-typed-array: 1.1.13 deep-is@0.1.4: {} - define-data-property@1.1.4: + default-browser-id@3.0.0: dependencies: - es-define-property: 1.0.0 - es-errors: 1.3.0 + bplist-parser: 0.2.0 + untildify: 4.0.0 + + default-browser@4.0.0: + dependencies: + bundle-name: 3.0.0 + default-browser-id: 3.0.0 + execa: 7.2.0 + titleize: 3.0.0 + + define-data-property@1.1.1: + dependencies: + get-intrinsic: 1.2.2 gopd: 1.0.1 + has-property-descriptors: 1.0.1 + + define-lazy-prop@3.0.0: {} define-properties@1.2.1: dependencies: - define-data-property: 1.1.4 - has-property-descriptors: 1.0.2 + define-data-property: 1.1.1 + has-property-descriptors: 1.0.1 object-keys: 1.1.1 - delaunator@5.0.1: + delaunator@5.0.0: dependencies: robust-predicates: 3.0.2 @@ -5410,7 +5617,7 @@ snapshots: dependencies: dequal: 2.0.3 - diff@5.2.0: {} + diff@5.1.0: {} dir-glob@3.0.1: dependencies: @@ -5422,7 +5629,7 @@ snapshots: dom-accessibility-api@0.5.16: {} - dompurify@3.1.1: {} + dompurify@3.0.6: {} dot-case@3.0.4: dependencies: @@ -5435,7 +5642,7 @@ snapshots: eastasianwidth@0.2.0: {} - elkjs@0.9.3: {} + elkjs@0.8.2: {} elliptic@6.5.4: dependencies: @@ -5459,20 +5666,14 @@ snapshots: dependencies: is-arrayish: 0.2.1 - es-define-property@1.0.0: - dependencies: - get-intrinsic: 1.2.4 - - es-errors@1.3.0: {} - es-get-iterator@1.1.3: dependencies: - call-bind: 1.0.7 - get-intrinsic: 1.2.4 + call-bind: 1.0.5 + get-intrinsic: 1.2.2 has-symbols: 1.0.3 is-arguments: 1.1.1 - is-map: 2.0.3 - is-set: 2.0.3 + is-map: 2.0.2 + is-set: 2.0.2 is-string: 1.0.7 isarray: 2.0.5 stop-iteration-iterator: 1.0.0 @@ -5483,17 +5684,17 @@ snapshots: escape-string-regexp@5.0.0: {} - eslint-mdx@2.3.4(eslint@8.57.0): + eslint-mdx@2.2.0(eslint@8.54.0): dependencies: - acorn: 8.11.3 - acorn-jsx: 5.3.2(acorn@8.11.3) - eslint: 8.57.0 + acorn: 8.11.2 + acorn-jsx: 5.3.2(acorn@8.11.2) + eslint: 8.54.0 espree: 9.6.1 estree-util-visit: 1.2.1 remark-mdx: 2.3.0 remark-parse: 10.0.2 remark-stringify: 10.0.3 - synckit: 0.9.0 + synckit: 0.8.5 tslib: 2.6.2 unified: 10.1.2 unified-engine: 10.1.0 @@ -5503,18 +5704,18 @@ snapshots: transitivePeerDependencies: - supports-color - eslint-plugin-markdown@3.0.1(eslint@8.57.0): + eslint-plugin-markdown@3.0.1(eslint@8.54.0): dependencies: - eslint: 8.57.0 + eslint: 8.54.0 mdast-util-from-markdown: 0.8.5 transitivePeerDependencies: - supports-color - eslint-plugin-mdx@2.3.4(eslint@8.57.0): + eslint-plugin-mdx@2.2.0(eslint@8.54.0): dependencies: - eslint: 8.57.0 - eslint-mdx: 2.3.4(eslint@8.57.0) - eslint-plugin-markdown: 3.0.1(eslint@8.57.0) + eslint: 8.54.0 + eslint-mdx: 2.2.0(eslint@8.54.0) + eslint-plugin-markdown: 3.0.1(eslint@8.54.0) remark-mdx: 2.3.0 remark-parse: 10.0.2 remark-stringify: 10.0.3 @@ -5531,13 +5732,13 @@ snapshots: eslint-visitor-keys@3.4.3: {} - eslint@8.57.0: + eslint@8.54.0: dependencies: - '@eslint-community/eslint-utils': 4.4.0(eslint@8.57.0) + '@eslint-community/eslint-utils': 4.4.0(eslint@8.54.0) '@eslint-community/regexpp': 4.10.0 - '@eslint/eslintrc': 2.1.4 - '@eslint/js': 8.57.0 - '@humanwhocodes/config-array': 0.11.14 + '@eslint/eslintrc': 2.1.3 + '@eslint/js': 8.54.0 + '@humanwhocodes/config-array': 0.11.13 '@humanwhocodes/module-importer': 1.0.1 '@nodelib/fs.walk': 1.2.8 '@ungap/structured-clone': 1.2.0 @@ -5556,9 +5757,9 @@ snapshots: file-entry-cache: 6.0.1 find-up: 5.0.0 glob-parent: 6.0.2 - globals: 13.24.0 + globals: 13.23.0 graphemer: 1.4.0 - ignore: 5.3.1 + ignore: 5.3.0 imurmurhash: 0.1.4 is-glob: 4.0.3 is-path-inside: 3.0.3 @@ -5568,7 +5769,7 @@ snapshots: lodash.merge: 4.6.2 minimatch: 3.1.2 natural-compare: 1.4.0 - optionator: 0.9.4 + optionator: 0.9.3 strip-ansi: 6.0.1 text-table: 0.2.0 transitivePeerDependencies: @@ -5576,8 +5777,8 @@ snapshots: espree@9.6.1: dependencies: - acorn: 8.11.3 - acorn-jsx: 5.3.2(acorn@8.11.3) + acorn: 8.11.2 + acorn-jsx: 5.3.2(acorn@8.11.2) eslint-visitor-keys: 3.4.3 esprima@4.0.1: {} @@ -5598,7 +5799,7 @@ snapshots: estree-util-build-jsx@2.2.2: dependencies: - '@types/estree-jsx': 1.0.5 + '@types/estree-jsx': 1.0.3 estree-util-is-identifier-name: 2.1.0 estree-walker: 3.0.3 @@ -5606,7 +5807,7 @@ snapshots: estree-util-to-js@1.2.0: dependencies: - '@types/estree-jsx': 1.0.5 + '@types/estree-jsx': 1.0.3 astring: 1.8.6 source-map: 0.7.4 @@ -5616,8 +5817,8 @@ snapshots: estree-util-visit@1.2.1: dependencies: - '@types/estree-jsx': 1.0.5 - '@types/unist': 2.0.10 + '@types/estree-jsx': 1.0.3 + '@types/unist': 2.0.9 estree-walker@3.0.3: dependencies: @@ -5625,16 +5826,16 @@ snapshots: esutils@2.0.3: {} - ethereum-bloom-filters@1.1.0: + ethereum-bloom-filters@1.0.10: dependencies: - '@noble/hashes': 1.4.0 + js-sha3: 0.8.0 - ethereum-cryptography@2.1.3: + ethereum-cryptography@2.1.2: dependencies: - '@noble/curves': 1.3.0 - '@noble/hashes': 1.3.3 - '@scure/bip32': 1.3.3 - '@scure/bip39': 1.2.2 + '@noble/curves': 1.1.0 + '@noble/hashes': 1.3.1 + '@scure/bip32': 1.3.1 + '@scure/bip39': 1.2.1 ethers@5.7.2: dependencies: @@ -5687,6 +5888,30 @@ snapshots: signal-exit: 3.0.7 strip-eof: 1.0.0 + execa@5.1.1: + dependencies: + cross-spawn: 7.0.3 + get-stream: 6.0.1 + human-signals: 2.1.0 + is-stream: 2.0.1 + merge-stream: 2.0.0 + npm-run-path: 4.0.1 + onetime: 5.1.2 + signal-exit: 3.0.7 + strip-final-newline: 2.0.0 + + execa@7.2.0: + dependencies: + cross-spawn: 7.0.3 + get-stream: 6.0.1 + human-signals: 4.3.1 + is-stream: 3.0.0 + merge-stream: 2.0.0 + npm-run-path: 5.1.0 + onetime: 6.0.0 + signal-exit: 3.0.7 + strip-final-newline: 3.0.0 + extend-shallow@2.0.1: dependencies: is-extendable: 0.1.1 @@ -5709,7 +5934,7 @@ snapshots: fast-levenshtein@2.0.6: {} - fastq@1.17.1: + fastq@1.15.0: dependencies: reusify: 1.0.4 @@ -5721,11 +5946,11 @@ snapshots: dependencies: flat-cache: 3.2.0 - file-entry-cache@8.0.0: + file-entry-cache@7.0.2: dependencies: - flat-cache: 4.0.1 + flat-cache: 3.2.0 - fill-range@7.1.1: + fill-range@7.0.1: dependencies: to-regex-range: 5.0.1 @@ -5743,18 +5968,13 @@ snapshots: flat-cache@3.2.0: dependencies: - flatted: 3.3.1 + flatted: 3.2.9 keyv: 4.5.4 rimraf: 3.0.2 - flat-cache@4.0.1: - dependencies: - flatted: 3.3.1 - keyv: 4.5.4 - - flatted@3.3.1: {} + flatted@3.2.9: {} - flexsearch@0.7.43: {} + flexsearch@0.7.31: {} focus-visible@5.2.0: {} @@ -5775,22 +5995,23 @@ snapshots: functions-have-names@1.2.3: {} - gensequence@7.0.0: {} + gensequence@6.0.0: {} get-func-name@2.0.2: {} - get-intrinsic@1.2.4: + get-intrinsic@1.2.2: dependencies: - es-errors: 1.3.0 function-bind: 1.1.2 - has-proto: 1.0.3 + has-proto: 1.0.1 has-symbols: 1.0.3 - hasown: 2.0.2 + hasown: 2.0.0 get-stdin@9.0.0: {} get-stream@3.0.0: {} + get-stream@6.0.1: {} + git-up@7.0.0: dependencies: is-ssh: 1.4.0 @@ -5812,15 +6033,13 @@ snapshots: dependencies: is-glob: 4.0.3 - glob-to-regexp@0.4.1: {} - - glob@10.3.12: + glob@10.3.10: dependencies: foreground-child: 3.1.1 jackspeak: 2.3.6 - minimatch: 9.0.4 + minimatch: 9.0.3 minipass: 7.0.4 - path-scurry: 1.10.2 + path-scurry: 1.10.1 glob@7.2.3: dependencies: @@ -5843,22 +6062,22 @@ snapshots: dependencies: ini: 4.1.1 - globals@13.24.0: + globals@13.23.0: dependencies: type-fest: 0.20.2 - globby@11.1.0: + globby@11.0.4: dependencies: array-union: 2.1.0 dir-glob: 3.0.1 fast-glob: 3.3.2 - ignore: 5.3.1 + ignore: 5.3.0 merge2: 1.4.1 slash: 3.0.0 gopd@1.0.1: dependencies: - get-intrinsic: 1.2.4 + get-intrinsic: 1.2.2 graceful-fs@4.2.11: {} @@ -5881,15 +6100,15 @@ snapshots: has-own-prop@2.0.0: {} - has-property-descriptors@1.0.2: + has-property-descriptors@1.0.1: dependencies: - es-define-property: 1.0.0 + get-intrinsic: 1.2.2 - has-proto@1.0.3: {} + has-proto@1.0.1: {} has-symbols@1.0.3: {} - has-tostringtag@1.0.2: + has-tostringtag@1.0.0: dependencies: has-symbols: 1.0.3 @@ -5904,26 +6123,26 @@ snapshots: inherits: 2.0.4 minimalistic-assert: 1.0.1 - hasown@2.0.2: + hasown@2.0.0: dependencies: function-bind: 1.1.2 hast-util-from-dom@5.0.0: dependencies: - '@types/hast': 3.0.4 + '@types/hast': 3.0.2 hastscript: 8.0.0 web-namespaces: 2.0.1 hast-util-from-html-isomorphic@2.0.0: dependencies: - '@types/hast': 3.0.4 + '@types/hast': 3.0.2 hast-util-from-dom: 5.0.0 hast-util-from-html: 2.0.1 unist-util-remove-position: 5.0.0 hast-util-from-html@2.0.1: dependencies: - '@types/hast': 3.0.4 + '@types/hast': 3.0.2 devlop: 1.1.0 hast-util-from-parse5: 8.0.1 parse5: 7.1.2 @@ -5932,32 +6151,32 @@ snapshots: hast-util-from-parse5@8.0.1: dependencies: - '@types/hast': 3.0.4 - '@types/unist': 3.0.2 + '@types/hast': 3.0.2 + '@types/unist': 3.0.1 devlop: 1.1.0 hastscript: 8.0.0 - property-information: 6.5.0 + property-information: 6.4.0 vfile: 6.0.1 vfile-location: 5.0.2 web-namespaces: 2.0.1 hast-util-is-element@3.0.0: dependencies: - '@types/hast': 3.0.4 + '@types/hast': 3.0.2 hast-util-parse-selector@4.0.0: dependencies: - '@types/hast': 3.0.4 + '@types/hast': 3.0.2 - hast-util-raw@9.0.2: + hast-util-raw@9.0.1: dependencies: - '@types/hast': 3.0.4 - '@types/unist': 3.0.2 + '@types/hast': 3.0.2 + '@types/unist': 3.0.1 '@ungap/structured-clone': 1.2.0 hast-util-from-parse5: 8.0.1 hast-util-to-parse5: 8.0.0 html-void-elements: 3.0.0 - mdast-util-to-hast: 13.1.0 + mdast-util-to-hast: 13.0.2 parse5: 7.1.2 unist-util-position: 5.0.0 unist-util-visit: 5.0.0 @@ -5968,16 +6187,16 @@ snapshots: hast-util-to-estree@2.3.3: dependencies: '@types/estree': 1.0.5 - '@types/estree-jsx': 1.0.5 - '@types/hast': 2.3.10 - '@types/unist': 2.0.10 + '@types/estree-jsx': 1.0.3 + '@types/hast': 2.3.7 + '@types/unist': 2.0.9 comma-separated-tokens: 2.0.3 estree-util-attach-comments: 2.1.1 estree-util-is-identifier-name: 2.1.0 hast-util-whitespace: 2.0.1 mdast-util-mdx-expression: 1.3.2 mdast-util-mdxjs-esm: 1.3.1 - property-information: 6.5.0 + property-information: 6.4.0 space-separated-tokens: 2.0.2 style-to-object: 0.4.4 unist-util-position: 4.0.4 @@ -5987,18 +6206,18 @@ snapshots: hast-util-to-parse5@8.0.0: dependencies: - '@types/hast': 3.0.4 + '@types/hast': 3.0.2 comma-separated-tokens: 2.0.3 devlop: 1.1.0 - property-information: 6.5.0 + property-information: 6.4.0 space-separated-tokens: 2.0.2 web-namespaces: 2.0.1 zwitch: 2.0.4 - hast-util-to-text@4.0.2: + hast-util-to-text@4.0.0: dependencies: - '@types/hast': 3.0.4 - '@types/unist': 3.0.2 + '@types/hast': 3.0.2 + '@types/unist': 3.0.1 hast-util-is-element: 3.0.0 unist-util-find-after: 5.0.0 @@ -6006,10 +6225,10 @@ snapshots: hastscript@8.0.0: dependencies: - '@types/hast': 3.0.4 + '@types/hast': 3.0.2 comma-separated-tokens: 2.0.3 hast-util-parse-selector: 4.0.0 - property-information: 6.5.0 + property-information: 6.4.0 space-separated-tokens: 2.0.2 header-case@2.0.4: @@ -6017,6 +6236,8 @@ snapshots: capital-case: 1.0.4 tslib: 2.6.2 + heap@0.2.7: {} + hmac-drbg@1.0.1: dependencies: hash.js: 1.1.7 @@ -6025,11 +6246,15 @@ snapshots: html-void-elements@3.0.0: {} + human-signals@2.1.0: {} + + human-signals@4.3.1: {} + iconv-lite@0.6.3: dependencies: safer-buffer: 2.1.2 - ignore@5.3.1: {} + ignore@5.3.0: {} import-fresh@3.3.0: dependencies: @@ -6038,7 +6263,7 @@ snapshots: import-meta-resolve@2.2.2: {} - import-meta-resolve@4.1.0: {} + import-meta-resolve@4.0.0: {} imurmurhash@0.1.4: {} @@ -6051,15 +6276,13 @@ snapshots: ini@4.1.1: {} - ini@4.1.2: {} - inline-style-parser@0.1.1: {} - internal-slot@1.0.7: + internal-slot@1.0.6: dependencies: - es-errors: 1.3.0 - hasown: 2.0.2 - side-channel: 1.0.6 + get-intrinsic: 1.2.2 + hasown: 2.0.0 + side-channel: 1.0.4 internmap@1.0.1: {} @@ -6083,13 +6306,14 @@ snapshots: is-arguments@1.1.1: dependencies: - call-bind: 1.0.7 - has-tostringtag: 1.0.2 + call-bind: 1.0.5 + has-tostringtag: 1.0.0 - is-array-buffer@3.0.4: + is-array-buffer@3.0.2: dependencies: - call-bind: 1.0.7 - get-intrinsic: 1.2.4 + call-bind: 1.0.5 + get-intrinsic: 1.2.2 + is-typed-array: 1.1.12 is-arrayish@0.2.1: {} @@ -6099,8 +6323,8 @@ snapshots: is-boolean-object@1.1.2: dependencies: - call-bind: 1.0.7 - has-tostringtag: 1.0.2 + call-bind: 1.0.5 + has-tostringtag: 1.0.0 is-buffer@2.0.5: {} @@ -6108,12 +6332,16 @@ snapshots: is-date-object@1.0.5: dependencies: - has-tostringtag: 1.0.2 + has-tostringtag: 1.0.0 is-decimal@1.0.4: {} is-decimal@2.0.1: {} + is-docker@2.2.1: {} + + is-docker@3.0.0: {} + is-empty@1.2.0: {} is-extendable@0.1.1: {} @@ -6132,11 +6360,15 @@ snapshots: is-hexadecimal@2.0.1: {} - is-map@2.0.3: {} + is-inside-container@1.0.0: + dependencies: + is-docker: 3.0.0 + + is-map@2.0.2: {} is-number-object@1.0.7: dependencies: - has-tostringtag: 1.0.2 + has-tostringtag: 1.0.0 is-number@7.0.0: {} @@ -6156,14 +6388,14 @@ snapshots: is-regex@1.1.4: dependencies: - call-bind: 1.0.7 - has-tostringtag: 1.0.2 + call-bind: 1.0.5 + has-tostringtag: 1.0.0 - is-set@2.0.3: {} + is-set@2.0.2: {} - is-shared-array-buffer@1.0.3: + is-shared-array-buffer@1.0.2: dependencies: - call-bind: 1.0.7 + call-bind: 1.0.5 is-ssh@1.4.0: dependencies: @@ -6171,22 +6403,34 @@ snapshots: is-stream@1.1.0: {} + is-stream@2.0.1: {} + + is-stream@3.0.0: {} + is-string@1.0.7: dependencies: - has-tostringtag: 1.0.2 + has-tostringtag: 1.0.0 is-symbol@1.0.4: dependencies: has-symbols: 1.0.3 + is-typed-array@1.1.12: + dependencies: + which-typed-array: 1.1.13 + is-typedarray@1.0.0: {} - is-weakmap@2.0.2: {} + is-weakmap@2.0.1: {} - is-weakset@2.0.3: + is-weakset@2.0.2: dependencies: - call-bind: 1.0.7 - get-intrinsic: 1.2.4 + call-bind: 1.0.5 + get-intrinsic: 1.2.2 + + is-wsl@2.2.0: + dependencies: + is-docker: 2.2.1 isarray@2.0.5: {} @@ -6196,6 +6440,10 @@ snapshots: dependencies: ws: 8.13.0 + isows@1.0.6(ws@8.18.0): + dependencies: + ws: 8.18.0 + jackspeak@2.3.6: dependencies: '@isaacs/cliui': 8.0.2 @@ -6219,7 +6467,7 @@ snapshots: json-parse-even-better-errors@2.3.1: {} - json-parse-even-better-errors@3.0.1: {} + json-parse-even-better-errors@3.0.0: {} json-schema-traverse@0.4.1: {} @@ -6227,9 +6475,9 @@ snapshots: json-stable-stringify-without-jsonify@1.0.1: {} - jsonc-parser@3.2.1: {} + jsonc-parser@3.2.0: {} - katex@0.16.10: + katex@0.16.9: dependencies: commander: 8.3.0 @@ -6245,6 +6493,8 @@ snapshots: layout-base@1.0.2: {} + layout-base@2.0.1: {} + levn@0.4.1: dependencies: prelude-ls: 1.2.1 @@ -6254,7 +6504,7 @@ snapshots: load-plugin@5.1.0: dependencies: - '@npmcli/config': 6.4.1 + '@npmcli/config': 6.4.0 import-meta-resolve: 2.2.2 locate-path@6.0.0: @@ -6289,7 +6539,7 @@ snapshots: dependencies: tslib: 2.6.2 - lru-cache@10.2.2: {} + lru-cache@10.0.3: {} lru-cache@4.1.5: dependencies: @@ -6306,34 +6556,34 @@ snapshots: markdown-table@3.0.3: {} - match-sorter@6.3.4: + match-sorter@6.3.1: dependencies: - '@babel/runtime': 7.24.4 - remove-accents: 0.5.0 + '@babel/runtime': 7.23.2 + remove-accents: 0.4.2 mdast-comment-marker@2.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-mdx-expression: 1.3.2 transitivePeerDependencies: - supports-color mdast-util-definitions@5.1.2: dependencies: - '@types/mdast': 3.0.15 - '@types/unist': 2.0.10 + '@types/mdast': 3.0.14 + '@types/unist': 2.0.9 unist-util-visit: 4.1.2 mdast-util-find-and-replace@2.2.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 escape-string-regexp: 5.0.0 unist-util-is: 5.2.1 unist-util-visit-parents: 5.1.3 mdast-util-from-markdown@0.8.5: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-to-string: 2.0.0 micromark: 2.11.4 parse-entities: 2.0.0 @@ -6343,8 +6593,8 @@ snapshots: mdast-util-from-markdown@1.3.1: dependencies: - '@types/mdast': 3.0.15 - '@types/unist': 2.0.10 + '@types/mdast': 3.0.14 + '@types/unist': 2.0.9 decode-named-character-reference: 1.0.2 mdast-util-to-string: 3.2.0 micromark: 3.2.0 @@ -6360,8 +6610,8 @@ snapshots: mdast-util-from-markdown@2.0.0: dependencies: - '@types/mdast': 4.0.3 - '@types/unist': 3.0.2 + '@types/mdast': 4.0.2 + '@types/unist': 3.0.1 decode-named-character-reference: 1.0.2 devlop: 1.1.0 mdast-util-to-string: 4.0.0 @@ -6377,7 +6627,7 @@ snapshots: mdast-util-frontmatter@2.0.1: dependencies: - '@types/mdast': 4.0.3 + '@types/mdast': 4.0.2 devlop: 1.1.0 escape-string-regexp: 5.0.0 mdast-util-from-markdown: 2.0.0 @@ -6388,25 +6638,25 @@ snapshots: mdast-util-gfm-autolink-literal@1.0.3: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 ccount: 2.0.1 mdast-util-find-and-replace: 2.2.2 micromark-util-character: 1.2.0 mdast-util-gfm-footnote@1.0.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-to-markdown: 1.5.0 micromark-util-normalize-identifier: 1.1.0 mdast-util-gfm-strikethrough@1.0.3: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-to-markdown: 1.5.0 mdast-util-gfm-table@1.0.7: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 markdown-table: 3.0.3 mdast-util-from-markdown: 1.3.1 mdast-util-to-markdown: 1.5.0 @@ -6415,7 +6665,7 @@ snapshots: mdast-util-gfm-task-list-item@1.0.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-to-markdown: 1.5.0 mdast-util-gfm@2.0.2: @@ -6432,19 +6682,19 @@ snapshots: mdast-util-heading-style@2.0.1: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-math@2.0.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 longest-streak: 3.1.0 mdast-util-to-markdown: 1.5.0 mdast-util-mdx-expression@1.3.2: dependencies: - '@types/estree-jsx': 1.0.5 - '@types/hast': 2.3.10 - '@types/mdast': 3.0.15 + '@types/estree-jsx': 1.0.3 + '@types/hast': 2.3.7 + '@types/mdast': 3.0.14 mdast-util-from-markdown: 1.3.1 mdast-util-to-markdown: 1.5.0 transitivePeerDependencies: @@ -6452,15 +6702,15 @@ snapshots: mdast-util-mdx-jsx@2.1.4: dependencies: - '@types/estree-jsx': 1.0.5 - '@types/hast': 2.3.10 - '@types/mdast': 3.0.15 - '@types/unist': 2.0.10 + '@types/estree-jsx': 1.0.3 + '@types/hast': 2.3.7 + '@types/mdast': 3.0.14 + '@types/unist': 2.0.9 ccount: 2.0.1 mdast-util-from-markdown: 1.3.1 mdast-util-to-markdown: 1.5.0 parse-entities: 4.0.1 - stringify-entities: 4.0.4 + stringify-entities: 4.0.3 unist-util-remove-position: 4.0.2 unist-util-stringify-position: 3.0.3 vfile-message: 3.1.4 @@ -6479,9 +6729,9 @@ snapshots: mdast-util-mdxjs-esm@1.3.1: dependencies: - '@types/estree-jsx': 1.0.5 - '@types/hast': 2.3.10 - '@types/mdast': 3.0.15 + '@types/estree-jsx': 1.0.3 + '@types/hast': 2.3.7 + '@types/mdast': 3.0.14 mdast-util-from-markdown: 1.3.1 mdast-util-to-markdown: 1.5.0 transitivePeerDependencies: @@ -6489,18 +6739,18 @@ snapshots: mdast-util-phrasing@3.0.1: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unist-util-is: 5.2.1 - mdast-util-phrasing@4.1.0: + mdast-util-phrasing@4.0.0: dependencies: - '@types/mdast': 4.0.3 + '@types/mdast': 4.0.2 unist-util-is: 6.0.0 mdast-util-to-hast@12.3.0: dependencies: - '@types/hast': 2.3.10 - '@types/mdast': 3.0.15 + '@types/hast': 2.3.7 + '@types/mdast': 3.0.14 mdast-util-definitions: 5.1.2 micromark-util-sanitize-uri: 1.2.0 trim-lines: 3.0.1 @@ -6508,22 +6758,21 @@ snapshots: unist-util-position: 4.0.4 unist-util-visit: 4.1.2 - mdast-util-to-hast@13.1.0: + mdast-util-to-hast@13.0.2: dependencies: - '@types/hast': 3.0.4 - '@types/mdast': 4.0.3 + '@types/hast': 3.0.2 + '@types/mdast': 4.0.2 '@ungap/structured-clone': 1.2.0 devlop: 1.1.0 micromark-util-sanitize-uri: 2.0.0 trim-lines: 3.0.1 unist-util-position: 5.0.0 unist-util-visit: 5.0.0 - vfile: 6.0.1 mdast-util-to-markdown@1.5.0: dependencies: - '@types/mdast': 3.0.15 - '@types/unist': 2.0.10 + '@types/mdast': 3.0.14 + '@types/unist': 2.0.9 longest-streak: 3.1.0 mdast-util-phrasing: 3.0.1 mdast-util-to-string: 3.2.0 @@ -6533,10 +6782,10 @@ snapshots: mdast-util-to-markdown@2.1.0: dependencies: - '@types/mdast': 4.0.3 - '@types/unist': 3.0.2 + '@types/mdast': 4.0.2 + '@types/unist': 3.0.1 longest-streak: 3.1.0 - mdast-util-phrasing: 4.1.0 + mdast-util-phrasing: 4.0.0 mdast-util-to-string: 4.0.0 micromark-util-decode-string: 2.0.0 unist-util-visit: 5.0.0 @@ -6546,11 +6795,13 @@ snapshots: mdast-util-to-string@3.2.0: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-to-string@4.0.0: dependencies: - '@types/mdast': 4.0.3 + '@types/mdast': 4.0.2 + + merge-stream@2.0.0: {} merge2@1.4.1: {} @@ -6560,30 +6811,30 @@ snapshots: buffer-reverse: 1.0.1 crypto-js: 4.2.0 treeify: 1.1.0 - web3-utils: 1.10.4 + web3-utils: 1.10.3 - mermaid@10.9.0: + mermaid@10.6.1: dependencies: '@braintree/sanitize-url': 6.0.4 - '@types/d3-scale': 4.0.8 - '@types/d3-scale-chromatic': 3.0.3 - cytoscape: 3.29.2 - cytoscape-cose-bilkent: 4.1.0(cytoscape@3.29.2) - d3: 7.9.0 + '@types/d3-scale': 4.0.7 + '@types/d3-scale-chromatic': 3.0.1 + cytoscape: 3.27.0 + cytoscape-cose-bilkent: 4.1.0(cytoscape@3.27.0) + cytoscape-fcose: 2.2.0(cytoscape@3.27.0) + d3: 7.8.5 d3-sankey: 0.12.3 dagre-d3-es: 7.0.10 - dayjs: 1.11.11 - dompurify: 3.1.1 - elkjs: 0.9.3 - katex: 0.16.10 + dayjs: 1.11.10 + dompurify: 3.0.6 + elkjs: 0.8.2 khroma: 2.1.0 lodash-es: 4.17.21 mdast-util-from-markdown: 1.3.1 non-layered-tidy-tree-layout: 2.0.2 - stylis: 4.3.2 + stylis: 4.3.0 ts-dedent: 2.2.0 uuid: 9.0.1 - web-worker: 1.3.0 + web-worker: 1.2.0 transitivePeerDependencies: - supports-color @@ -6608,7 +6859,7 @@ snapshots: micromark-util-types: 1.1.0 uvu: 0.5.6 - micromark-core-commonmark@2.0.1: + micromark-core-commonmark@2.0.0: dependencies: decode-named-character-reference: 1.0.2 devlop: 1.1.0 @@ -6617,20 +6868,20 @@ snapshots: micromark-factory-space: 2.0.0 micromark-factory-title: 2.0.0 micromark-factory-whitespace: 2.0.0 - micromark-util-character: 2.1.0 + micromark-util-character: 2.0.1 micromark-util-chunked: 2.0.0 micromark-util-classify-character: 2.0.0 micromark-util-html-tag-name: 2.0.0 micromark-util-normalize-identifier: 2.0.0 micromark-util-resolve-all: 2.0.0 - micromark-util-subtokenize: 2.0.1 + micromark-util-subtokenize: 2.0.0 micromark-util-symbol: 2.0.0 micromark-util-types: 2.0.0 micromark-extension-frontmatter@2.0.0: dependencies: fault: 2.0.1 - micromark-util-character: 2.1.0 + micromark-util-character: 2.0.1 micromark-util-symbol: 2.0.0 micromark-util-types: 2.0.0 @@ -6694,8 +6945,8 @@ snapshots: micromark-extension-math@2.1.2: dependencies: - '@types/katex': 0.16.7 - katex: 0.16.10 + '@types/katex': 0.16.5 + katex: 0.16.9 micromark-factory-space: 1.1.0 micromark-util-character: 1.2.0 micromark-util-symbol: 1.1.0 @@ -6744,8 +6995,8 @@ snapshots: micromark-extension-mdxjs@1.0.1: dependencies: - acorn: 8.11.3 - acorn-jsx: 5.3.2(acorn@8.11.3) + acorn: 8.11.2 + acorn-jsx: 5.3.2(acorn@8.11.2) micromark-extension-mdx-expression: 1.0.8 micromark-extension-mdx-jsx: 1.0.5 micromark-extension-mdx-md: 1.0.1 @@ -6761,7 +7012,7 @@ snapshots: micromark-factory-destination@2.0.0: dependencies: - micromark-util-character: 2.1.0 + micromark-util-character: 2.0.1 micromark-util-symbol: 2.0.0 micromark-util-types: 2.0.0 @@ -6775,7 +7026,7 @@ snapshots: micromark-factory-label@2.0.0: dependencies: devlop: 1.1.0 - micromark-util-character: 2.1.0 + micromark-util-character: 2.0.1 micromark-util-symbol: 2.0.0 micromark-util-types: 2.0.0 @@ -6797,7 +7048,7 @@ snapshots: micromark-factory-space@2.0.0: dependencies: - micromark-util-character: 2.1.0 + micromark-util-character: 2.0.1 micromark-util-types: 2.0.0 micromark-factory-title@1.1.0: @@ -6810,7 +7061,7 @@ snapshots: micromark-factory-title@2.0.0: dependencies: micromark-factory-space: 2.0.0 - micromark-util-character: 2.1.0 + micromark-util-character: 2.0.1 micromark-util-symbol: 2.0.0 micromark-util-types: 2.0.0 @@ -6824,7 +7075,7 @@ snapshots: micromark-factory-whitespace@2.0.0: dependencies: micromark-factory-space: 2.0.0 - micromark-util-character: 2.1.0 + micromark-util-character: 2.0.1 micromark-util-symbol: 2.0.0 micromark-util-types: 2.0.0 @@ -6833,7 +7084,7 @@ snapshots: micromark-util-symbol: 1.1.0 micromark-util-types: 1.1.0 - micromark-util-character@2.1.0: + micromark-util-character@2.0.1: dependencies: micromark-util-symbol: 2.0.0 micromark-util-types: 2.0.0 @@ -6854,7 +7105,7 @@ snapshots: micromark-util-classify-character@2.0.0: dependencies: - micromark-util-character: 2.1.0 + micromark-util-character: 2.0.1 micromark-util-symbol: 2.0.0 micromark-util-types: 2.0.0 @@ -6886,7 +7137,7 @@ snapshots: micromark-util-decode-string@2.0.0: dependencies: decode-named-character-reference: 1.0.2 - micromark-util-character: 2.1.0 + micromark-util-character: 2.0.1 micromark-util-decode-numeric-character-reference: 2.0.1 micromark-util-symbol: 2.0.0 @@ -6898,7 +7149,7 @@ snapshots: dependencies: '@types/acorn': 4.0.6 '@types/estree': 1.0.5 - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 estree-util-visit: 1.2.1 micromark-util-symbol: 1.1.0 micromark-util-types: 1.1.0 @@ -6933,7 +7184,7 @@ snapshots: micromark-util-sanitize-uri@2.0.0: dependencies: - micromark-util-character: 2.1.0 + micromark-util-character: 2.0.1 micromark-util-encode: 2.0.0 micromark-util-symbol: 2.0.0 @@ -6944,7 +7195,7 @@ snapshots: micromark-util-types: 1.1.0 uvu: 0.5.6 - micromark-util-subtokenize@2.0.1: + micromark-util-subtokenize@2.0.0: dependencies: devlop: 1.1.0 micromark-util-chunked: 2.0.0 @@ -6968,7 +7219,7 @@ snapshots: micromark@3.2.0: dependencies: - '@types/debug': 4.1.12 + '@types/debug': 4.1.11 debug: 4.3.4 decode-named-character-reference: 1.0.2 micromark-core-commonmark: 1.1.0 @@ -6990,13 +7241,13 @@ snapshots: micromark@4.0.0: dependencies: - '@types/debug': 4.1.12 + '@types/debug': 4.1.11 debug: 4.3.4 decode-named-character-reference: 1.0.2 devlop: 1.1.0 - micromark-core-commonmark: 2.0.1 + micromark-core-commonmark: 2.0.0 micromark-factory-space: 2.0.0 - micromark-util-character: 2.1.0 + micromark-util-character: 2.0.1 micromark-util-chunked: 2.0.0 micromark-util-combine-extensions: 2.0.0 micromark-util-decode-numeric-character-reference: 2.0.1 @@ -7004,7 +7255,7 @@ snapshots: micromark-util-normalize-identifier: 2.0.0 micromark-util-resolve-all: 2.0.0 micromark-util-sanitize-uri: 2.0.0 - micromark-util-subtokenize: 2.0.1 + micromark-util-subtokenize: 2.0.0 micromark-util-symbol: 2.0.0 micromark-util-types: 2.0.0 transitivePeerDependencies: @@ -7012,9 +7263,13 @@ snapshots: micromatch@4.0.5: dependencies: - braces: 3.0.3 + braces: 3.0.2 picomatch: 2.3.1 + mimic-fn@2.1.0: {} + + mimic-fn@4.0.0: {} + min-indent@1.0.1: {} minimalistic-assert@1.0.1: {} @@ -7033,10 +7288,6 @@ snapshots: dependencies: brace-expansion: 2.0.1 - minimatch@9.0.4: - dependencies: - brace-expansion: 2.0.1 - minimist@1.2.8: {} minipass@7.0.4: {} @@ -7049,114 +7300,113 @@ snapshots: natural-compare@1.4.0: {} - next-mdx-remote@4.4.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1): + next-mdx-remote@4.4.1(react-dom@18.2.0(react@18.2.0))(react@18.2.0): dependencies: '@mdx-js/mdx': 2.3.0 - '@mdx-js/react': 2.3.0(react@18.3.1) - react: 18.3.1 - react-dom: 18.3.1(react@18.3.1) + '@mdx-js/react': 2.3.0(react@18.2.0) + react: 18.2.0 + react-dom: 18.2.0(react@18.2.0) vfile: 5.3.7 vfile-matter: 3.0.1 transitivePeerDependencies: - supports-color - next-seo@6.5.0(next@13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1))(react-dom@18.3.1(react@18.3.1))(react@18.3.1): + next-seo@6.4.0(next@14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0))(react-dom@18.2.0(react@18.2.0))(react@18.2.0): dependencies: - next: 13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1) - react: 18.3.1 - react-dom: 18.3.1(react@18.3.1) + next: 14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0) + react: 18.2.0 + react-dom: 18.2.0(react@18.2.0) - next-sitemap@4.2.3(next@13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1)): + next-sitemap@4.2.3(next@14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0)): dependencies: '@corex/deepmerge': 4.0.43 '@next/env': 13.5.6 fast-glob: 3.3.2 minimist: 1.2.8 - next: 13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1) + next: 14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0) - next-themes@0.2.1(next@13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1))(react-dom@18.3.1(react@18.3.1))(react@18.3.1): + next-themes@0.2.1(next@14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0))(react-dom@18.2.0(react@18.2.0))(react@18.2.0): dependencies: - next: 13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1) - react: 18.3.1 - react-dom: 18.3.1(react@18.3.1) + next: 14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0) + react: 18.2.0 + react-dom: 18.2.0(react@18.2.0) - next@13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1): + next@14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0): dependencies: - '@next/env': 13.5.1 - '@swc/helpers': 0.5.2 + '@next/env': 14.2.10 + '@swc/helpers': 0.5.5 busboy: 1.6.0 - caniuse-lite: 1.0.30001614 - postcss: 8.4.14 - react: 18.3.1 - react-dom: 18.3.1(react@18.3.1) - styled-jsx: 5.1.1(react@18.3.1) - watchpack: 2.4.0 - zod: 3.21.4 + caniuse-lite: 1.0.30001669 + graceful-fs: 4.2.11 + postcss: 8.4.31 + react: 18.2.0 + react-dom: 18.2.0(react@18.2.0) + styled-jsx: 5.1.1(react@18.2.0) optionalDependencies: - '@next/swc-darwin-arm64': 13.5.1 - '@next/swc-darwin-x64': 13.5.1 - '@next/swc-linux-arm64-gnu': 13.5.1 - '@next/swc-linux-arm64-musl': 13.5.1 - '@next/swc-linux-x64-gnu': 13.5.1 - '@next/swc-linux-x64-musl': 13.5.1 - '@next/swc-win32-arm64-msvc': 13.5.1 - '@next/swc-win32-ia32-msvc': 13.5.1 - '@next/swc-win32-x64-msvc': 13.5.1 + '@next/swc-darwin-arm64': 14.2.10 + '@next/swc-darwin-x64': 14.2.10 + '@next/swc-linux-arm64-gnu': 14.2.10 + '@next/swc-linux-arm64-musl': 14.2.10 + '@next/swc-linux-x64-gnu': 14.2.10 + '@next/swc-linux-x64-musl': 14.2.10 + '@next/swc-win32-arm64-msvc': 14.2.10 + '@next/swc-win32-ia32-msvc': 14.2.10 + '@next/swc-win32-x64-msvc': 14.2.10 transitivePeerDependencies: - '@babel/core' - babel-plugin-macros - nextra-theme-docs@2.13.2(next@13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1))(nextra@2.13.2(patch_hash=a4rp2hgojklggjmthmkiyqaek4)(next@13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1))(react-dom@18.3.1(react@18.3.1))(react@18.3.1))(react-dom@18.3.1(react@18.3.1))(react@18.3.1): + nextra-theme-docs@2.13.2(next@14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0))(nextra@2.13.2(patch_hash=a4rp2hgojklggjmthmkiyqaek4)(next@14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0))(react-dom@18.2.0(react@18.2.0))(react@18.2.0))(react-dom@18.2.0(react@18.2.0))(react@18.2.0): dependencies: - '@headlessui/react': 1.7.19(react-dom@18.3.1(react@18.3.1))(react@18.3.1) + '@headlessui/react': 1.7.17(react-dom@18.2.0(react@18.2.0))(react@18.2.0) '@popperjs/core': 2.11.8 clsx: 2.1.1 escape-string-regexp: 5.0.0 - flexsearch: 0.7.43 + flexsearch: 0.7.31 focus-visible: 5.2.0 git-url-parse: 13.1.1 intersection-observer: 0.12.2 - match-sorter: 6.3.4 - next: 13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1) - next-seo: 6.5.0(next@13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1))(react-dom@18.3.1(react@18.3.1))(react@18.3.1) - next-themes: 0.2.1(next@13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1))(react-dom@18.3.1(react@18.3.1))(react@18.3.1) - nextra: 2.13.2(patch_hash=a4rp2hgojklggjmthmkiyqaek4)(next@13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1))(react-dom@18.3.1(react@18.3.1))(react@18.3.1) - react: 18.3.1 - react-dom: 18.3.1(react@18.3.1) + match-sorter: 6.3.1 + next: 14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0) + next-seo: 6.4.0(next@14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0))(react-dom@18.2.0(react@18.2.0))(react@18.2.0) + next-themes: 0.2.1(next@14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0))(react-dom@18.2.0(react@18.2.0))(react@18.2.0) + nextra: 2.13.2(patch_hash=a4rp2hgojklggjmthmkiyqaek4)(next@14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0))(react-dom@18.2.0(react@18.2.0))(react@18.2.0) + react: 18.2.0 + react-dom: 18.2.0(react@18.2.0) scroll-into-view-if-needed: 3.1.0 - zod: 3.23.8 + zod: 3.22.4 - nextra@2.13.2(patch_hash=a4rp2hgojklggjmthmkiyqaek4)(next@13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1))(react-dom@18.3.1(react@18.3.1))(react@18.3.1): + nextra@2.13.2(patch_hash=a4rp2hgojklggjmthmkiyqaek4)(next@14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0))(react-dom@18.2.0(react@18.2.0))(react@18.2.0): dependencies: - '@headlessui/react': 1.7.19(react-dom@18.3.1(react@18.3.1))(react@18.3.1) + '@headlessui/react': 1.7.17(react-dom@18.2.0(react@18.2.0))(react@18.2.0) '@mdx-js/mdx': 2.3.0 - '@mdx-js/react': 2.3.0(react@18.3.1) - '@napi-rs/simple-git': 0.1.16 - '@theguild/remark-mermaid': 0.0.5(react@18.3.1) + '@mdx-js/react': 2.3.0(react@18.2.0) + '@napi-rs/simple-git': 0.1.9 + '@theguild/remark-mermaid': 0.0.5(react@18.2.0) '@theguild/remark-npm2yarn': 0.2.1 clsx: 2.1.1 github-slugger: 2.0.0 graceful-fs: 4.2.11 gray-matter: 4.0.3 - katex: 0.16.10 + katex: 0.16.9 lodash.get: 4.4.2 - next: 13.5.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1) - next-mdx-remote: 4.4.1(react-dom@18.3.1(react@18.3.1))(react@18.3.1) + next: 14.2.10(react-dom@18.2.0(react@18.2.0))(react@18.2.0) + next-mdx-remote: 4.4.1(react-dom@18.2.0(react@18.2.0))(react@18.2.0) p-limit: 3.1.0 - react: 18.3.1 - react-dom: 18.3.1(react@18.3.1) + react: 18.2.0 + react-dom: 18.2.0(react@18.2.0) rehype-katex: 7.0.0 - rehype-pretty-code: 0.9.11(shiki@0.14.7) + rehype-pretty-code: 0.9.11(shiki@0.14.5) rehype-raw: 7.0.0 remark-gfm: 3.0.1 remark-math: 5.1.1 remark-reading-time: 2.0.1 - shiki: 0.14.7 + shiki: 0.14.5 slash: 3.0.0 title: 3.5.3 unist-util-remove: 4.0.0 unist-util-visit: 5.0.0 - zod: 3.23.8 + zod: 3.22.4 transitivePeerDependencies: - supports-color @@ -7181,7 +7431,15 @@ snapshots: dependencies: path-key: 2.0.1 - npm-to-yarn@2.2.1: {} + npm-run-path@4.0.1: + dependencies: + path-key: 3.1.1 + + npm-run-path@5.1.0: + dependencies: + path-key: 4.0.0 + + npm-to-yarn@2.1.0: {} number-to-bn@1.7.0: dependencies: @@ -7190,16 +7448,16 @@ snapshots: object-inspect@1.13.1: {} - object-is@1.1.6: + object-is@1.1.5: dependencies: - call-bind: 1.0.7 + call-bind: 1.0.5 define-properties: 1.2.1 object-keys@1.1.1: {} - object.assign@4.1.5: + object.assign@4.1.4: dependencies: - call-bind: 1.0.7 + call-bind: 1.0.5 define-properties: 1.2.1 has-symbols: 1.0.3 object-keys: 1.1.1 @@ -7208,14 +7466,29 @@ snapshots: dependencies: wrappy: 1.0.2 - optionator@0.9.4: + onetime@5.1.2: + dependencies: + mimic-fn: 2.1.0 + + onetime@6.0.0: + dependencies: + mimic-fn: 4.0.0 + + open@9.1.0: + dependencies: + default-browser: 4.0.0 + define-lazy-prop: 3.0.0 + is-inside-container: 1.0.0 + is-wsl: 2.2.0 + + optionator@0.9.3: dependencies: + '@aashutoshrathi/word-wrap': 1.2.6 deep-is: 0.1.4 fast-levenshtein: 2.0.6 levn: 0.4.1 prelude-ls: 1.2.1 type-check: 0.4.0 - word-wrap: 1.2.5 p-finally@1.0.0: {} @@ -7259,7 +7532,7 @@ snapshots: parse-entities@4.0.1: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 character-entities: 2.0.2 character-entities-legacy: 3.0.0 character-reference-invalid: 2.0.1 @@ -7270,7 +7543,7 @@ snapshots: parse-json@6.0.2: dependencies: - '@babel/code-frame': 7.24.2 + '@babel/code-frame': 7.23.4 error-ex: 1.3.2 json-parse-even-better-errors: 2.3.1 lines-and-columns: 2.0.4 @@ -7309,9 +7582,11 @@ snapshots: path-key@3.1.1: {} - path-scurry@1.10.2: + path-key@4.0.0: {} + + path-scurry@1.10.1: dependencies: - lru-cache: 10.2.2 + lru-cache: 10.0.3 minipass: 7.0.4 path-type@4.0.0: {} @@ -7330,13 +7605,11 @@ snapshots: pluralize@8.0.0: {} - possible-typed-array-names@1.0.0: {} - - postcss@8.4.14: + postcss@8.4.31: dependencies: nanoid: 3.3.7 picocolors: 1.0.0 - source-map-js: 1.2.0 + source-map-js: 1.0.2 prelude-ls@1.2.1: {} @@ -7348,7 +7621,7 @@ snapshots: proc-log@3.0.0: {} - property-information@6.5.0: {} + property-information@6.4.0: {} protocols@2.0.1: {} @@ -7362,21 +7635,21 @@ snapshots: dependencies: safe-buffer: 5.2.1 - react-dom@18.3.1(react@18.3.1): + react-dom@18.2.0(react@18.2.0): dependencies: loose-envify: 1.4.0 - react: 18.3.1 - scheduler: 0.23.2 + react: 18.2.0 + scheduler: 0.23.0 react-is@17.0.2: {} - react@18.3.1: + react@18.2.0: dependencies: loose-envify: 1.4.0 read-package-json-fast@3.0.2: dependencies: - json-parse-even-better-errors: 3.0.1 + json-parse-even-better-errors: 3.0.0 npm-normalize-package-bin: 3.0.1 readable-stream@3.6.2: @@ -7387,36 +7660,35 @@ snapshots: reading-time@1.5.0: {} - regenerator-runtime@0.14.1: {} + regenerator-runtime@0.14.0: {} - regexp.prototype.flags@1.5.2: + regexp.prototype.flags@1.5.1: dependencies: - call-bind: 1.0.7 + call-bind: 1.0.5 define-properties: 1.2.1 - es-errors: 1.3.0 - set-function-name: 2.0.2 + set-function-name: 2.0.1 rehype-katex@7.0.0: dependencies: - '@types/hast': 3.0.4 - '@types/katex': 0.16.7 + '@types/hast': 3.0.2 + '@types/katex': 0.16.5 hast-util-from-html-isomorphic: 2.0.0 - hast-util-to-text: 4.0.2 - katex: 0.16.10 + hast-util-to-text: 4.0.0 + katex: 0.16.9 unist-util-visit-parents: 6.0.1 vfile: 6.0.1 - rehype-pretty-code@0.9.11(shiki@0.14.7): + rehype-pretty-code@0.9.11(shiki@0.14.5): dependencies: - '@types/hast': 2.3.10 + '@types/hast': 2.3.7 hash-obj: 4.0.0 parse-numeric-range: 1.3.0 - shiki: 0.14.7 + shiki: 0.14.5 rehype-raw@7.0.0: dependencies: - '@types/hast': 3.0.4 - hast-util-raw: 9.0.2 + '@types/hast': 3.0.2 + hast-util-raw: 9.0.1 vfile: 6.0.1 remark-code-import@1.2.0(patch_hash=heylvfasxh3ubj2edns2svea2m): @@ -7427,7 +7699,7 @@ snapshots: remark-frontmatter@5.0.0: dependencies: - '@types/mdast': 4.0.3 + '@types/mdast': 4.0.2 mdast-util-frontmatter: 2.0.1 micromark-extension-frontmatter: 2.0.0 unified: 11.0.4 @@ -7436,7 +7708,7 @@ snapshots: remark-gfm@3.0.1: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-gfm: 2.0.2 micromark-extension-gfm: 2.0.3 unified: 10.1.2 @@ -7445,7 +7717,7 @@ snapshots: remark-lint-blockquote-indentation@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 pluralize: 8.0.0 unified: 10.1.2 unified-lint-rule: 2.1.2 @@ -7455,7 +7727,7 @@ snapshots: remark-lint-checkbox-character-style@4.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-position: 4.0.4 @@ -7463,7 +7735,7 @@ snapshots: remark-lint-code-block-style@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-generated: 2.0.1 @@ -7472,7 +7744,7 @@ snapshots: remark-lint-emphasis-marker@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-position: 4.0.4 @@ -7480,7 +7752,7 @@ snapshots: remark-lint-fenced-code-marker@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-position: 4.0.4 @@ -7488,7 +7760,7 @@ snapshots: remark-lint-final-newline@2.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 @@ -7504,7 +7776,7 @@ snapshots: remark-lint-hard-break-spaces@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-generated: 2.0.1 @@ -7513,7 +7785,7 @@ snapshots: remark-lint-heading-style@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-heading-style: 2.0.1 unified: 10.1.2 unified-lint-rule: 2.1.2 @@ -7522,7 +7794,7 @@ snapshots: remark-lint-link-title-style@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-position: 4.0.4 @@ -7531,7 +7803,7 @@ snapshots: remark-lint-list-item-bullet-indent@4.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 pluralize: 8.0.0 unified: 10.1.2 unified-lint-rule: 2.1.2 @@ -7539,7 +7811,7 @@ snapshots: remark-lint-list-item-content-indent@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 pluralize: 8.0.0 unified: 10.1.2 unified-lint-rule: 2.1.2 @@ -7548,7 +7820,7 @@ snapshots: remark-lint-list-item-indent@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 pluralize: 8.0.0 unified: 10.1.2 unified-lint-rule: 2.1.2 @@ -7558,7 +7830,7 @@ snapshots: remark-lint-no-blockquote-without-marker@5.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-generated: 2.0.1 @@ -7568,7 +7840,7 @@ snapshots: remark-lint-no-duplicate-definitions@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-generated: 2.0.1 @@ -7578,7 +7850,7 @@ snapshots: remark-lint-no-heading-content-indent@4.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-heading-style: 2.0.1 pluralize: 8.0.0 unified: 10.1.2 @@ -7589,7 +7861,7 @@ snapshots: remark-lint-no-inline-padding@4.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-to-string: 3.2.0 unified: 10.1.2 unified-lint-rule: 2.1.2 @@ -7598,7 +7870,7 @@ snapshots: remark-lint-no-literal-urls@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-to-string: 3.2.0 unified: 10.1.2 unified-lint-rule: 2.1.2 @@ -7608,7 +7880,7 @@ snapshots: remark-lint-no-shortcut-reference-image@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-generated: 2.0.1 @@ -7616,7 +7888,7 @@ snapshots: remark-lint-no-shortcut-reference-link@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-generated: 2.0.1 @@ -7624,7 +7896,7 @@ snapshots: remark-lint-no-undefined-references@4.2.1: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 micromark-util-normalize-identifier: 1.1.0 unified: 10.1.2 unified-lint-rule: 2.1.2 @@ -7635,7 +7907,7 @@ snapshots: remark-lint-no-unused-definitions@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-generated: 2.0.1 @@ -7643,7 +7915,7 @@ snapshots: remark-lint-ordered-list-marker-style@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-generated: 2.0.1 @@ -7652,7 +7924,7 @@ snapshots: remark-lint-rule-style@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-position: 4.0.4 @@ -7660,7 +7932,7 @@ snapshots: remark-lint-strong-marker@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-position: 4.0.4 @@ -7668,8 +7940,8 @@ snapshots: remark-lint-table-cell-padding@4.1.3: dependencies: - '@types/mdast': 3.0.15 - '@types/unist': 2.0.10 + '@types/mdast': 3.0.14 + '@types/unist': 2.0.9 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-position: 4.0.4 @@ -7677,7 +7949,7 @@ snapshots: remark-lint-table-pipe-alignment@3.1.3: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-position: 4.0.4 @@ -7685,7 +7957,7 @@ snapshots: remark-lint-table-pipes@4.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-position: 4.0.4 @@ -7693,7 +7965,7 @@ snapshots: remark-lint-unordered-list-marker-style@3.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 unified: 10.1.2 unified-lint-rule: 2.1.2 unist-util-generated: 2.0.1 @@ -7702,7 +7974,7 @@ snapshots: remark-lint@9.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 remark-message-control: 7.1.1 unified: 10.1.2 transitivePeerDependencies: @@ -7710,7 +7982,7 @@ snapshots: remark-math@5.1.1: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-math: 2.0.2 micromark-extension-math: 2.1.2 unified: 10.1.2 @@ -7724,7 +7996,7 @@ snapshots: remark-message-control@7.1.1: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-comment-marker: 2.1.2 unified: 10.1.2 unified-message-control: 4.0.0 @@ -7734,7 +8006,7 @@ snapshots: remark-parse@10.0.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-from-markdown: 1.3.1 unified: 10.1.2 transitivePeerDependencies: @@ -7742,7 +8014,7 @@ snapshots: remark-parse@11.0.0: dependencies: - '@types/mdast': 4.0.3 + '@types/mdast': 4.0.2 mdast-util-from-markdown: 2.0.0 micromark-util-types: 2.0.0 unified: 11.0.4 @@ -7751,7 +8023,7 @@ snapshots: remark-preset-lint-consistent@5.1.2: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 remark-lint: 9.1.2 remark-lint-blockquote-indentation: 3.1.2 remark-lint-checkbox-character-style: 4.1.2 @@ -7771,7 +8043,7 @@ snapshots: remark-preset-lint-recommended@6.1.3: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 remark-lint: 9.1.2 remark-lint-final-newline: 2.1.2 remark-lint-hard-break-spaces: 3.1.2 @@ -7800,33 +8072,33 @@ snapshots: remark-rehype@10.1.0: dependencies: - '@types/hast': 2.3.10 - '@types/mdast': 3.0.15 + '@types/hast': 2.3.7 + '@types/mdast': 3.0.14 mdast-util-to-hast: 12.3.0 unified: 10.1.2 remark-stringify@10.0.3: dependencies: - '@types/mdast': 3.0.15 + '@types/mdast': 3.0.14 mdast-util-to-markdown: 1.5.0 unified: 10.1.2 remark-stringify@11.0.0: dependencies: - '@types/mdast': 4.0.3 + '@types/mdast': 4.0.2 mdast-util-to-markdown: 2.1.0 unified: 11.0.4 remark@15.0.1: dependencies: - '@types/mdast': 4.0.3 + '@types/mdast': 4.0.2 remark-parse: 11.0.0 remark-stringify: 11.0.0 unified: 11.0.4 transitivePeerDependencies: - supports-color - remove-accents@0.5.0: {} + remove-accents@0.4.2: {} repeat-string@1.6.1: {} @@ -7848,6 +8120,10 @@ snapshots: robust-predicates@3.0.2: {} + run-applescript@5.0.0: + dependencies: + execa: 5.1.1 + run-parallel@1.2.0: dependencies: queue-microtask: 1.2.3 @@ -7862,7 +8138,7 @@ snapshots: safer-buffer@2.1.2: {} - scheduler@0.23.2: + scheduler@0.23.0: dependencies: loose-envify: 1.4.0 @@ -7879,7 +8155,7 @@ snapshots: extend-shallow: 2.0.1 kind-of: 6.0.3 - semver@7.6.0: + semver@7.5.4: dependencies: lru-cache: 6.0.0 @@ -7889,21 +8165,18 @@ snapshots: tslib: 2.6.2 upper-case-first: 2.0.2 - set-function-length@1.2.2: + set-function-length@1.1.1: dependencies: - define-data-property: 1.1.4 - es-errors: 1.3.0 - function-bind: 1.1.2 - get-intrinsic: 1.2.4 + define-data-property: 1.1.1 + get-intrinsic: 1.2.2 gopd: 1.0.1 - has-property-descriptors: 1.0.2 + has-property-descriptors: 1.0.1 - set-function-name@2.0.2: + set-function-name@2.0.1: dependencies: - define-data-property: 1.1.4 - es-errors: 1.3.0 + define-data-property: 1.1.1 functions-have-names: 1.2.3 - has-property-descriptors: 1.0.2 + has-property-descriptors: 1.0.1 shebang-command@1.2.0: dependencies: @@ -7917,18 +8190,17 @@ snapshots: shebang-regex@3.0.0: {} - shiki@0.14.7: + shiki@0.14.5: dependencies: ansi-sequence-parser: 1.1.1 - jsonc-parser: 3.2.1 + jsonc-parser: 3.2.0 vscode-oniguruma: 1.7.0 vscode-textmate: 8.0.0 - side-channel@1.0.6: + side-channel@1.0.4: dependencies: - call-bind: 1.0.7 - es-errors: 1.3.0 - get-intrinsic: 1.2.4 + call-bind: 1.0.5 + get-intrinsic: 1.2.2 object-inspect: 1.13.1 signal-exit@3.0.7: {} @@ -7946,7 +8218,7 @@ snapshots: dependencies: is-plain-obj: 4.1.0 - source-map-js@1.2.0: {} + source-map-js@1.0.2: {} source-map@0.7.4: {} @@ -7956,7 +8228,7 @@ snapshots: stop-iteration-iterator@1.0.0: dependencies: - internal-slot: 1.0.7 + internal-slot: 1.0.6 streamsearch@1.1.0: {} @@ -7976,7 +8248,7 @@ snapshots: dependencies: safe-buffer: 5.2.1 - stringify-entities@4.0.4: + stringify-entities@4.0.3: dependencies: character-entities-html4: 2.1.0 character-entities-legacy: 3.0.0 @@ -7993,6 +8265,10 @@ snapshots: strip-eof@1.0.0: {} + strip-final-newline@2.0.0: {} + + strip-final-newline@3.0.0: {} + strip-hex-prefix@1.0.0: dependencies: is-hex-prefixed: 1.0.0 @@ -8007,12 +8283,12 @@ snapshots: dependencies: inline-style-parser: 0.1.1 - styled-jsx@5.1.1(react@18.3.1): + styled-jsx@5.1.1(react@18.2.0): dependencies: client-only: 0.0.1 - react: 18.3.1 + react: 18.2.0 - stylis@4.3.2: {} + stylis@4.3.0: {} supports-color@4.5.0: dependencies: @@ -8028,9 +8304,9 @@ snapshots: supports-color@9.4.0: {} - synckit@0.9.0: + synckit@0.8.5: dependencies: - '@pkgr/core': 0.1.1 + '@pkgr/utils': 2.4.2 tslib: 2.6.2 tabbable@6.2.0: {} @@ -8048,6 +8324,8 @@ snapshots: titleize@1.0.0: {} + titleize@3.0.0: {} + to-gatsby-remark-plugin@0.1.0: dependencies: to-vfile: 6.1.0 @@ -8072,7 +8350,7 @@ snapshots: trim-lines@3.0.1: {} - trough@2.2.0: {} + trough@2.1.0: {} ts-dedent@2.2.0: {} @@ -8094,45 +8372,45 @@ snapshots: typedarray@0.0.6: {} - typescript@5.4.5: {} + typescript@5.3.2: {} unified-engine@10.1.0: dependencies: '@types/concat-stream': 2.0.3 - '@types/debug': 4.1.12 + '@types/debug': 4.1.11 '@types/is-empty': 1.2.3 '@types/node': 18.11.10 - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 concat-stream: 2.0.0 debug: 4.3.4 fault: 2.0.1 glob: 8.1.0 - ignore: 5.3.1 + ignore: 5.3.0 is-buffer: 2.0.5 is-empty: 1.2.0 is-plain-obj: 4.1.0 load-plugin: 5.1.0 parse-json: 6.0.2 to-vfile: 7.2.4 - trough: 2.2.0 + trough: 2.1.0 unist-util-inspect: 7.0.2 vfile-message: 3.1.4 vfile-reporter: 7.0.5 vfile-statistics: 2.0.1 - yaml: 2.4.2 + yaml: 2.3.4 transitivePeerDependencies: - supports-color unified-lint-rule@2.1.2: dependencies: - '@types/unist': 2.0.10 - trough: 2.2.0 + '@types/unist': 2.0.9 + trough: 2.1.0 unified: 10.1.2 vfile: 5.3.7 unified-message-control@4.0.0: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 unist-util-is: 5.2.1 unist-util-visit: 3.1.0 vfile: 5.3.7 @@ -8141,22 +8419,22 @@ snapshots: unified@10.1.2: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 bail: 2.0.2 extend: 3.0.2 is-buffer: 2.0.5 is-plain-obj: 4.1.0 - trough: 2.2.0 + trough: 2.1.0 vfile: 5.3.7 unified@11.0.4: dependencies: - '@types/unist': 3.0.2 + '@types/unist': 3.0.1 bail: 2.0.2 devlop: 1.1.0 extend: 3.0.2 is-plain-obj: 4.1.0 - trough: 2.2.0 + trough: 2.1.0 vfile: 6.0.1 unique-string@3.0.0: @@ -8165,96 +8443,98 @@ snapshots: unist-util-find-after@5.0.0: dependencies: - '@types/unist': 3.0.2 + '@types/unist': 3.0.1 unist-util-is: 6.0.0 unist-util-generated@2.0.1: {} unist-util-inspect@7.0.2: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 unist-util-is@5.2.1: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 unist-util-is@6.0.0: dependencies: - '@types/unist': 3.0.2 + '@types/unist': 3.0.1 unist-util-position-from-estree@1.1.2: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 unist-util-position@4.0.4: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 unist-util-position@5.0.0: dependencies: - '@types/unist': 3.0.2 + '@types/unist': 3.0.1 unist-util-remove-position@4.0.2: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 unist-util-visit: 4.1.2 unist-util-remove-position@5.0.0: dependencies: - '@types/unist': 3.0.2 + '@types/unist': 3.0.1 unist-util-visit: 5.0.0 unist-util-remove@4.0.0: dependencies: - '@types/unist': 3.0.2 + '@types/unist': 3.0.1 unist-util-is: 6.0.0 unist-util-visit-parents: 6.0.1 unist-util-stringify-position@2.0.3: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 unist-util-stringify-position@3.0.3: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 unist-util-stringify-position@4.0.0: dependencies: - '@types/unist': 3.0.2 + '@types/unist': 3.0.1 unist-util-visit-parents@4.1.1: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 unist-util-is: 5.2.1 unist-util-visit-parents@5.1.3: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 unist-util-is: 5.2.1 unist-util-visit-parents@6.0.1: dependencies: - '@types/unist': 3.0.2 + '@types/unist': 3.0.1 unist-util-is: 6.0.0 unist-util-visit@3.1.0: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 unist-util-is: 5.2.1 unist-util-visit-parents: 4.1.1 unist-util-visit@4.1.2: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 unist-util-is: 5.2.1 unist-util-visit-parents: 5.1.3 unist-util-visit@5.0.0: dependencies: - '@types/unist': 3.0.2 + '@types/unist': 3.0.1 unist-util-is: 6.0.0 unist-util-visit-parents: 6.0.1 + untildify@4.0.0: {} + upper-case-first@2.0.2: dependencies: tslib: 2.6.2 @@ -8276,39 +8556,39 @@ snapshots: uvu@0.5.6: dependencies: dequal: 2.0.3 - diff: 5.2.0 + diff: 5.1.0 kleur: 4.1.5 sade: 1.8.1 vfile-location@4.1.0: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 vfile: 5.3.7 vfile-location@5.0.2: dependencies: - '@types/unist': 3.0.2 + '@types/unist': 3.0.1 vfile: 6.0.1 vfile-matter@3.0.1: dependencies: - '@types/js-yaml': 4.0.9 + '@types/js-yaml': 4.0.8 is-buffer: 2.0.5 js-yaml: 4.1.0 vfile-message@2.0.4: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 unist-util-stringify-position: 2.0.3 vfile-message@3.1.4: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 unist-util-stringify-position: 3.0.3 vfile-message@4.0.2: dependencies: - '@types/unist': 3.0.2 + '@types/unist': 3.0.1 unist-util-stringify-position: 4.0.0 vfile-reporter@7.0.5: @@ -8334,36 +8614,54 @@ snapshots: vfile@4.2.1: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 is-buffer: 2.0.5 unist-util-stringify-position: 2.0.3 vfile-message: 2.0.4 vfile@5.3.7: dependencies: - '@types/unist': 2.0.10 + '@types/unist': 2.0.9 is-buffer: 2.0.5 unist-util-stringify-position: 3.0.3 vfile-message: 3.1.4 vfile@6.0.1: dependencies: - '@types/unist': 3.0.2 + '@types/unist': 3.0.1 unist-util-stringify-position: 4.0.0 vfile-message: 4.0.2 - viem@2.9.28(typescript@5.4.5)(zod@3.23.8): + viem@1.19.6(typescript@5.3.2)(zod@3.22.4): dependencies: '@adraffy/ens-normalize': 1.10.0 '@noble/curves': 1.2.0 '@noble/hashes': 1.3.2 '@scure/bip32': 1.3.2 '@scure/bip39': 1.2.1 - abitype: 1.0.0(typescript@5.4.5)(zod@3.23.8) + abitype: 0.9.8(typescript@5.3.2)(zod@3.22.4) isows: 1.0.3(ws@8.13.0) ws: 8.13.0 optionalDependencies: - typescript: 5.4.5 + typescript: 5.3.2 + transitivePeerDependencies: + - bufferutil + - utf-8-validate + - zod + + viem@2.21.37(typescript@5.3.2)(zod@3.22.4): + dependencies: + '@adraffy/ens-normalize': 1.11.0 + '@noble/curves': 1.6.0 + '@noble/hashes': 1.5.0 + '@scure/bip32': 1.5.0 + '@scure/bip39': 1.4.0 + abitype: 1.0.6(typescript@5.3.2)(zod@3.22.4) + isows: 1.0.6(ws@8.18.0) + webauthn-p256: 0.0.10 + ws: 8.18.0 + optionalDependencies: + typescript: 5.3.2 transitivePeerDependencies: - bufferutil - utf-8-validate @@ -8379,26 +8677,26 @@ snapshots: walk-up-path@3.0.1: {} - watchpack@2.4.0: - dependencies: - glob-to-regexp: 0.4.1 - graceful-fs: 4.2.11 - web-namespaces@2.0.1: {} - web-worker@1.3.0: {} + web-worker@1.2.0: {} - web3-utils@1.10.4: + web3-utils@1.10.3: dependencies: '@ethereumjs/util': 8.1.0 bn.js: 5.2.1 - ethereum-bloom-filters: 1.1.0 - ethereum-cryptography: 2.1.3 + ethereum-bloom-filters: 1.0.10 + ethereum-cryptography: 2.1.2 ethjs-unit: 0.1.6 number-to-bn: 1.7.0 randombytes: 2.1.0 utf8: 3.0.0 + webauthn-p256@0.0.10: + dependencies: + '@noble/curves': 1.6.0 + '@noble/hashes': 1.5.0 + webidl-conversions@3.0.1: {} whatwg-url@5.0.0: @@ -8414,20 +8712,20 @@ snapshots: is-string: 1.0.7 is-symbol: 1.0.4 - which-collection@1.0.2: + which-collection@1.0.1: dependencies: - is-map: 2.0.3 - is-set: 2.0.3 - is-weakmap: 2.0.2 - is-weakset: 2.0.3 + is-map: 2.0.2 + is-set: 2.0.2 + is-weakmap: 2.0.1 + is-weakset: 2.0.2 - which-typed-array@1.1.15: + which-typed-array@1.1.13: dependencies: - available-typed-arrays: 1.0.7 - call-bind: 1.0.7 + available-typed-arrays: 1.0.5 + call-bind: 1.0.5 for-each: 0.3.3 gopd: 1.0.1 - has-tostringtag: 1.0.2 + has-tostringtag: 1.0.0 which@1.3.1: dependencies: @@ -8437,8 +8735,6 @@ snapshots: dependencies: isexe: 2.0.0 - word-wrap@1.2.5: {} - wrap-ansi@7.0.0: dependencies: ansi-styles: 4.3.0 @@ -8464,6 +8760,8 @@ snapshots: ws@8.13.0: {} + ws@8.18.0: {} + xdg-basedir@5.1.0: {} yallist@2.1.2: {} @@ -8472,14 +8770,12 @@ snapshots: yaml@2.3.3: {} - yaml@2.4.2: {} + yaml@2.3.4: {} yocto-queue@0.1.0: {} yocto-queue@1.0.0: {} - zod@3.21.4: {} - - zod@3.23.8: {} + zod@3.22.4: {} zwitch@2.0.4: {} diff --git a/public/_redirects b/public/_redirects index 89f0ac83c..a1f267aeb 100644 --- a/public/_redirects +++ b/public/_redirects @@ -62,21 +62,58 @@ /transaction-fees/overview /builders/app-developers/transactions/fees /dapp-developers/contracts/meta-tx /builders/app-developers/contracts/optimization /builders/tools/build/overview /builders/tools/overview -/protocol-specifications/optimistic-rollup/block-production /stack/protocol/rollup/overview#block-production +/protocol-specifications/optimistic-rollup/block-production /stack/rollup/overview#block-production /builders/node-operators/metrics /builders/node-operators/management/metrics /stack /stack/getting-started /chain/sec /chain/security/faq /builders/chain-operators/management/tools/explorer /builders/chain-operators/tools/explorer /builders/node-operators/management/configuration /builders/node-operators/configuration/base-config -/stack/protocol/deposit-flow /stack/protocol/rollup/deposit-flow -/stack/protocol/transaction-flow /stack/protocol/rollup/transaction-flow -/stack/protocol/withdrawal-flow /stack/protocol/rollup/withdrawal-flow -/stack/protocol/smart-contracts /stack/protocol/rollup/smart-contracts -/stack/protocol/overview /stack/protocol/rollup/overview +/stack/protocol/deposit-flow /stack/transactions/deposit-flow +/stack/protocol/transaction-flow /stack/transactions/transaction-flow +/stack/protocol/withdrawal-flow /stack/transactions/withdrawal-flow +/stack/protocol/smart-contracts /stack/smart-contracts +/stack/protocol/overview /stack/rollup/overview /stack/protocol/design-principles /stack/design-principles /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 +/stack/protocol/fault-proofs/overview /stack/fault-proofs/explainer /builders/chain-operators/management/configuration /builders/chain-operators/configuration/overview /builders/chain-operators/management/custom-gas-token /builders/chain-operators/features/custom-gas-token -/stack/protocol/rollup/smart-contracts /stack/smart-contracts \ No newline at end of file +/stack/protocol/rollup/smart-contracts /stack/smart-contracts +/stack/protocol/fault-proofs/challenger /stack/fault-proofs/challenger +/stack/protocol/fault-proofs/fp-security /stack/fault-proofs/fp-security +/stack/protocol/fault-proofs/mips /stack/fault-proofs/mips +/stack/protocol/fault-proofs/fp-components /stack/fault-proofs/fp-components +/stack/protocol/fault-proofs/explainer /stack/fault-proofs/explainer +/stack/protocol/fault-proofs/cannon /stack/fault-proofs/cannon +/stack/protocol/interop/supersim /stack/interop/supersim +/stack/protocol/interop/superchain-erc20 /stack/interop/superchain-erc20 +/stack/protocol/interop/explainer /stack/interop/explainer +/stack/protocol/interop/cross-chain-message /stack/interop/cross-chain-message +/stack/protocol/features/alt-da-mode /stack/beta-features/alt-da-mode +/stack/protocol/features/custom-gas-token /stack/beta-features/custom-gas-token +/stack/protocol/features/send-raw-transaction-conditional /stack/features/send-raw-transaction-conditional +/stack/protocol/derivation-pipeline /stack/rollup/derivation-pipeline +/stack/protocol/rollup/overview /stack/rollup/overview +/stack/protocol/rollup/withdrawal-flow /stack/transactions/withdrawal-flow +/stack/protocol/rollup/forced-transaction /stack/transactions/forced-transaction +/stack/protocol/rollup/transaction-flow /stack/transactions/transaction-flow +/stack/protocol/rollup/deposit-flow /stack/transactions/deposit-flow +/stack/protocol/outages /stack/rollup/outages +/stack/operators/features/op-txproxy /builders/chain-operators/tools/op-txproxy +/stack/operators/features/proxyd /builders/chain-operators/tools/proxyd +/builders/notices/granite-changes https://github.com/ethereum-optimism/docs/blob/ef619668ae44276edecdfd657157254b9809e2d6/pages/builders/notices/granite-changes.mdx +/builders/notices/fp-changes https://github.com/ethereum-optimism/docs/blob/ef619668ae44276edecdfd657157254b9809e2d6/pages/builders/notices/fp-changes.mdx +/chain/differences /stack/differences +/builders/app-developers/contracts/optimization /builders/app-developers/overview +/builders/app-developers/contracts/system-contracts /stack/smart-contracts +/builders/app-developers/contracts/compatibility /stack/differences +/builders/app-developers/tutorials/first-contract /builders/app-developers/overview +/builders/cex-wallet-developers/cex-support /builders/app-developers/overview +/builders/cex-wallet-developers/wallet-support /builders/app-developers/overview +/builders/cex-wallet-developers /builders/app-developers/overview +/stack/interop/superchain-erc20 /stack/interop/assets/superchain-erc20 +/stack/interop/superchain-weth /stack/interop/assets/superchain-weth +/stack/interop/transfer-superchainERC20 /stack/interop/assets/transfer-superchainERC20 +/builders/app-developers/contracts/superchain-erc20 /stack/interop/assets/superchain-erc20 +/builders/chain-operators/tutorials/sdk /builders/app-developers/overview \ No newline at end of file diff --git a/public/img/icons/caret-down.svg b/public/img/icons/caret-down.svg new file mode 100644 index 000000000..ea15ee513 --- /dev/null +++ b/public/img/icons/caret-down.svg @@ -0,0 +1,4 @@ + + + + \ No newline at end of file diff --git a/public/img/op-stack/protocol/block-time-research-figure-1.png b/public/img/op-stack/protocol/block-time-research-figure-1.png new file mode 100644 index 000000000..5bab0c5ef Binary files /dev/null and b/public/img/op-stack/protocol/block-time-research-figure-1.png differ diff --git a/public/img/op-stack/protocol/block-time-research-figure-2.png b/public/img/op-stack/protocol/block-time-research-figure-2.png new file mode 100644 index 000000000..4e88aabc4 Binary files /dev/null and b/public/img/op-stack/protocol/block-time-research-figure-2.png differ diff --git a/public/img/op-stack/protocol/block-time-research-figure-3.png b/public/img/op-stack/protocol/block-time-research-figure-3.png new file mode 100644 index 000000000..74cf842c3 Binary files /dev/null and b/public/img/op-stack/protocol/block-time-research-figure-3.png differ diff --git a/public/img/op-stack/protocol/block-time-research-figure-4.png b/public/img/op-stack/protocol/block-time-research-figure-4.png new file mode 100644 index 000000000..c20e85eac Binary files /dev/null and b/public/img/op-stack/protocol/block-time-research-figure-4.png differ diff --git a/public/img/op-stack/protocol/block-time-research-figure-5.png b/public/img/op-stack/protocol/block-time-research-figure-5.png new file mode 100644 index 000000000..4feaa1671 Binary files /dev/null and b/public/img/op-stack/protocol/block-time-research-figure-5.png differ diff --git a/public/img/op-stack/protocol/block-time-research-figure-6.png b/public/img/op-stack/protocol/block-time-research-figure-6.png new file mode 100644 index 000000000..73b3da9a2 Binary files /dev/null and b/public/img/op-stack/protocol/block-time-research-figure-6.png differ diff --git a/public/img/op-stack/protocol/cross-chain-message.png b/public/img/op-stack/protocol/cross-chain-message.png index 11bf3e472..67f7e2999 100644 Binary files a/public/img/op-stack/protocol/cross-chain-message.png and b/public/img/op-stack/protocol/cross-chain-message.png differ diff --git a/public/img/op-stack/protocol/op-cross-chain-txn.jpeg b/public/img/op-stack/protocol/op-cross-chain-txn.jpeg new file mode 100644 index 000000000..396668654 Binary files /dev/null and b/public/img/op-stack/protocol/op-cross-chain-txn.jpeg differ diff --git a/public/img/op-stack/protocol/tx-finality.png b/public/img/op-stack/protocol/tx-finality.png new file mode 100644 index 000000000..c1d40fb48 Binary files /dev/null and b/public/img/op-stack/protocol/tx-finality.png differ diff --git a/public/tutorials/cross-dom-bridge-eth.js b/public/tutorials/cross-dom-bridge-eth.js index ba612e28b..82abb4d6e 100644 --- a/public/tutorials/cross-dom-bridge-eth.js +++ b/public/tutorials/cross-dom-bridge-eth.js @@ -1,74 +1,115 @@ (async () => { -const optimism = require("@eth-optimism/sdk") -const ethers = require("ethers") +const { createPublicClient, http, createWalletClient, parseEther, formatEther } = require('viem'); +const { sepolia, optimismSepolia } = require('viem/chains'); +const { privateKeyToAccount } = require('viem/accounts'); +const { getL2TransactionHashes, publicActionsL1, publicActionsL2, walletActionsL1, walletActionsL2 } = require('viem/op-stack'); -const privateKey = process.env.TUTORIAL_PRIVATE_KEY -const l1Provider = new ethers.providers.StaticJsonRpcProvider("https://rpc.ankr.com/eth_sepolia") -const l2Provider = new ethers.providers.StaticJsonRpcProvider("https://sepolia.optimism.io") -const l1Wallet = new ethers.Wallet(privateKey, l1Provider) -const l2Wallet = new ethers.Wallet(privateKey, l2Provider) +const PRIVATE_KEY = process.env.TUTORIAL_PRIVATE_KEY; +const account = privateKeyToAccount(PRIVATE_KEY); -console.log('L1 balance:') -console.log((await l1Wallet.getBalance()).toString()) -const messenger = new optimism.CrossChainMessenger({ - l1ChainId: 11155111, // 11155111 for Sepolia, 1 for Ethereum - l2ChainId: 11155420, // 11155420 for OP Sepolia, 10 for OP Mainnet - l1SignerOrProvider: l1Wallet, - l2SignerOrProvider: l2Wallet, -}) +const publicClientL1 = createPublicClient({ + chain: sepolia, + transport: http("https://rpc.ankr.com/eth_sepolia"), +}).extend(publicActionsL1()) -console.log('Depositing ETH...') -tx = await messenger.depositETH(ethers.utils.parseEther('0.006942')) -await tx.wait() -console.log('Waiting for deposit to be relayed...') -await messenger.waitForMessageStatus(tx.hash, optimism.MessageStatus.RELAYED) +const walletClientL1 = createWalletClient({ + account, + chain: sepolia, + transport: http("https://rpc.ankr.com/eth_sepolia"), +}).extend(walletActionsL1()); -console.log('L1 balance:') -console.log((await l1Wallet.getBalance()).toString()) -console.log('L2 balance:') -console.log((await l2Wallet.getBalance()).toString()) +const publicClientL2 = createPublicClient({ + chain: optimismSepolia, + transport: http("https://sepolia.optimism.io"), +}).extend(publicActionsL2()); -console.log('Withdrawing ETH...') -const withdrawal = await messenger.withdrawETH(ethers.utils.parseEther('0.004269')) -await withdrawal.wait() -console.log('L2 balance:') -console.log((await l2Wallet.getBalance()).toString()) +const walletClientL2 = createWalletClient({ + account, + chain: optimismSepolia, + transport: http("https://sepolia.optimism.io"), +}).extend(walletActionsL2()); -console.log('Waiting for withdrawal to be provable...') -await messenger.waitForMessageStatus(withdrawal.hash, optimism.MessageStatus.READY_TO_PROVE) +const l1Balance = await publicClientL1.getBalance({ address: account.address }); +console.log(`L1 Balance: ${formatEther(l1Balance)} ETH`); -console.log('Proving withdrawal...') -await messenger.proveMessage(withdrawal.hash) +async function depositETH() { -console.log('Waiting for withdrawal to be relayable...') -await messenger.waitForMessageStatus(withdrawal.hash, optimism.MessageStatus.READY_FOR_RELAY) -// Wait for the next block to be produced, only necessary for CI because messenger can return -// READY_FOR_RELAY before the RPC we're using is caught up to the latest block. Waiting for an -// additional block ensures that the RPC is caught up and the message can be relayed. Users -// should not need to do this when running the tutorial. -const maxWaitTime = Date.now() + 120000 // 2 minutes in milliseconds -const currentBlock = await l1Provider.getBlockNumber() -while (await l1Provider.getBlockNumber() < currentBlock + 1) { - if (Date.now() > maxWaitTime) { - throw new Error('Timed out waiting for block to be produced') - } - await new Promise(resolve => setTimeout(resolve, 1000)) -} +const depositArgs = await publicClientL2.buildDepositTransaction({ + mint: parseEther("0.0001"), + to: account.address, +}); + +const depositHash = await walletClientL1.depositTransaction(depositArgs); +console.log(`Deposit transaction hash on L1: ${depositHash}`); + +const depositReceipt = await publicClientL1.waitForTransactionReceipt({ depositHash }); +console.log('L1 transaction confirmed:', depositReceipt); + +const [l2Hash] = getL2TransactionHashes(depositReceipt); +console.log(`Corresponding L2 transaction hash: ${l2Hash}`); + +const l2Receipt = await publicClientL2.waitForTransactionReceipt({ + hash: l2Hash, +}); +console.log('L2 transaction confirmed:', l2Receipt); +console.log('Deposit completed successfully!'); +} + + +async function withdrawETH() { + +//Add the same imports used in DepositETH function +const withdrawalArgs = await publicClientL2.buildWithdrawalTransaction({ +value: parseEther('0.0001'), +to: account.address, +}); + +const withdrawalHash = await walletClientL2.initiateWithdrawal(withdrawalArgs); +console.log(`Withdrawal transaction hash on L2: ${withdrawalHash}`); -console.log('Relaying withdrawal...') -await messenger.finalizeMessage(withdrawal.hash) +const withdrawalReceipt = await publicClientL2.waitForTransactionReceipt({ hash: withdrawalHash }); +console.log('L2 transaction confirmed:', withdrawalReceipt); -console.log('Waiting for withdrawal to be relayed...') -await messenger.waitForMessageStatus(withdrawal.hash, optimism.MessageStatus.RELAYED) +const { output, withdrawal } = await publicClientL1.waitToProve({ +withdrawalReceipt, +targetChain: walletClientL2.chain +}); -console.log('L1 balance:') -console.log((await l1Wallet.getBalance()).toString()) +const proveArgs = await publicClientL2.buildProveWithdrawal({ +output, +withdrawal, +}); + +const proveHash = await walletClientL1.proveWithdrawal(proveArgs); + +const proveReceipt = await publicClientL1.waitForTransactionReceipt({ hash: proveHash }); + +const awaitWithdrawal = await publicClientL1.waitToFinalize({ +targetChain: walletClientL2.chain, +withdrawalHash: withdrawal.withdrawalHash, +}); + +const finalizeHash = await walletClientL1.finalizeWithdrawal({ +targetChain: walletClientL2.chain, +withdrawal, +}); + +const finalizeReceipt = await publicClientL1.waitForTransactionReceipt({ +hash: finalizeHash +}); + +const status = await publicClientL1.getWithdrawalStatus({ +receipt, +targetChain: walletClientL2.chain +}) +console.log('Withdrawal completed successfully!'); +} -})() +})() \ No newline at end of file diff --git a/public/tutorials/cross-dom-solidity.js b/public/tutorials/cross-dom-solidity.js index 9ddafb16b..c4368c9e5 100644 --- a/public/tutorials/cross-dom-solidity.js +++ b/public/tutorials/cross-dom-solidity.js @@ -1,37 +1,39 @@ (async () => { -const optimism = require("@eth-optimism/sdk") -const ethers = require("ethers") - -const privateKey = process.env.TUTORIAL_PRIVATE_KEY +const { createPublicClient, http } = require('viem'); +const { optimismSepolia } = require('viem/chains'); +const { publicActionsL1, publicActionsL2} = require('viem/op-stack'); const transactionHash = process.env.TUTORIAL_TRANSACTION_HASH -const l1Provider = new ethers.providers.StaticJsonRpcProvider("https://rpc.ankr.com/eth_sepolia") -const l2Provider = new ethers.providers.StaticJsonRpcProvider("https://sepolia.optimism.io") -const l1Wallet = new ethers.Wallet(privateKey, l1Provider) -const l2Wallet = new ethers.Wallet(privateKey, l2Provider) - -const messenger = new optimism.CrossChainMessenger({ - l1ChainId: 11155111, // 11155111 for Sepolia, 1 for Ethereum - l2ChainId: 11155420, // 11155420 for OP Sepolia, 10 for OP Mainnet - l1SignerOrProvider: l1Wallet, - l2SignerOrProvider: l2Wallet, -}) +const l1Provider = createPublicClient({ chain: sepolia, transport: http("https://rpc.ankr.com/eth_sepolia") }).extend(publicActionsL1()) +const l2Provider = createPublicClient({ chain: optimismSepolia, transport: http("https://sepolia.optimism.io") }).extend(publicActionsL2()); console.log('Waiting for message to be provable...') -await messenger.waitForMessageStatus(transactionHash, optimism.MessageStatus.READY_TO_PROVE) +await l1Provider.getWithdrawalStatus({ + receipt, + targetChain: l2Provider.chain, +}) console.log('Proving message...') -await messenger.proveMessage(transactionHash) +const receipt = await l2Provider.getTransactionReceipt(transactionHash) +const output = await l1Provider.waitToProve({ + receipt, + targetChain: l2Provider.chain, +}) console.log('Waiting for message to be relayable...') -await messenger.waitForMessageStatus(transactionHash, optimism.MessageStatus.READY_FOR_RELAY) +await l1Provider.getWithdrawalStatus({ + receipt, + targetChain: l2Provider.chain, +}) console.log('Relaying message...') -await messenger.finalizeMessage(transactionHash) +const [message] = getWithdrawals(receipt) +await l1Provider.waitToFinalize({ withdrawalHash: message.withdrawalHash, targetChain: l2Provider.chain }) console.log('Waiting for message to be relayed...') -await messenger.waitForMessageStatus(transactionHash, optimism.MessageStatus.RELAYED) +await l1Provider.getWithdrawalStatus({ receipt, targetChain: l2Provider.chain }) + })() diff --git a/public/tutorials/sdk-estimate-costs.js b/public/tutorials/sdk-estimate-costs.js index f223f0026..72507f96f 100644 --- a/public/tutorials/sdk-estimate-costs.js +++ b/public/tutorials/sdk-estimate-costs.js @@ -1,52 +1,49 @@ (async () => { -const optimism = require("@eth-optimism/sdk") -const ethers = require("ethers") +const { createPublicClient, createWalletClient, http, parseEther, parseGwei, formatEther } = require('viem'); +const { privateKeyToAccount } = require('viem/accounts'); +const { optimismSepolia } = require('viem/chains'); +const { publicActionsL2, walletActionsL2 } = require('viem/op-stack'); const privateKey = process.env.TUTORIAL_PRIVATE_KEY +const account = privateKeyToAccount(privateKey) -const provider = optimism.asL2Provider(new ethers.providers.StaticJsonRpcProvider("https://sepolia.optimism.io")) -const wallet = new ethers.Wallet(privateKey, provider) +const publicClient = createPublicClient({ + chain: optimismSepolia, + transport: http("https://sepolia.optimism.io"), +}).extend(publicActionsL2()) -const tx = await wallet.populateTransaction({ +const walletClientL2 = createWalletClient({ + chain: optimismSepolia, + transport: http("https://sepolia.optimism.io"), +}).extend(walletActionsL2()) + + const transaction = { + account, to: '0x1000000000000000000000000000000000000000', - value: ethers.utils.parseEther('0.00069420'), - gasPrice: await provider.getGasPrice(), -}) - -console.log('Estimating L2 cost...') -const gasLimit = tx.gasLimit -const gasPrice = tx.maxFeePerGas -const l2CostEstimate = gasLimit.mul(gasPrice) -console.log(ethers.utils.formatEther(l2CostEstimate)) - -console.log('Estimating L1 cost...') -const l1CostEstimate = await provider.estimateL1GasCost(tx) -console.log(ethers.utils.formatEther(l1CostEstimate)) - -console.log('Summing total cost...') -const totalSum = l2CostEstimate.add(l1CostEstimate) -console.log(ethers.utils.formatEther(totalSum)) - -console.log('Sending transaction...') -const res = await wallet.sendTransaction(tx) -const receipt = await res.wait() -console.log(receipt.transactionHash) - -console.log('Actual L2 cost:') -const l2CostActual = receipt.gasUsed.mul(receipt.effectiveGasPrice) -console.log(ethers.utils.formatEther(l2CostActual)) - -console.log('Actual L1 cost:') -const l1CostActual = receipt.l1Fee -console.log(ethers.utils.formatEther(l1CostActual)) - -console.log('Actual total cost:') -const totalActual = l2CostActual.add(l1CostActual) -console.log(ethers.utils.formatEther(totalActual)) - -console.log('Difference:') -const difference = totalActual.sub(totalSum).abs() -console.log(ethers.utils.formatEther(difference)) - -})() + value: parseEther('0.00069420'), + gasPrice: await publicClient.getGasPrice() + } + + const totalEstimate = await publicClient.estimateTotalFee(transaction) + console.log(`Estimated Total Cost: ${formatEther(totalEstimate)} ETH`) + + const txHash = await walletClientL2.sendTransaction(transaction) + console.log(`Transaction Hash: ${txHash}`) + + const receipt = await publicClient.waitForTransactionReceipt({ hash: txHash }) + console.log('receipt', receipt); + + const l2CostActual = receipt.gasUsed * receipt.effectiveGasPrice + console.log(`Actual Execution Gas Fee: ${formatEther(l2CostActual)} ETH`) + + const l1CostActual = receipt.l1Fee + console.log(`Actual L1 Data Fee: ${formatEther(l1CostActual)} ETH`) + + const totalActual = l2CostActual + l1CostActual + console.log(`Actual Total Cost: ${formatEther(totalActual)} ETH`) + + const difference = totalEstimate >= totalActual ? totalEstimate - totalActual : totalActual - totalEstimate + console.log(`Estimation Difference: ${formatEther(difference)} ETH`) + +})() \ No newline at end of file diff --git a/public/tutorials/send-tx-from-eth.js b/public/tutorials/send-tx-from-eth.js index 9666aeb07..12ea74460 100644 --- a/public/tutorials/send-tx-from-eth.js +++ b/public/tutorials/send-tx-from-eth.js @@ -1,60 +1,81 @@ (async () => { -const contracts = require("@eth-optimism/contracts-ts") -const utils = require("@eth-optimism/core-utils") -const ethers = require("ethers") - -const privateKey = process.env.TUTORIAL_PRIVATE_KEY - -const l1Provider = new ethers.providers.StaticJsonRpcProvider("https://rpc.ankr.com/eth_sepolia") -const l2Provider = new ethers.providers.StaticJsonRpcProvider("https://sepolia.optimism.io") -const l1Wallet = new ethers.Wallet(privateKey, l1Provider) -const l2Wallet = new ethers.Wallet(privateKey, l2Provider) - -console.log('Initial balance:') -const initialBalance = await l2Wallet.getBalance() -console.log(ethers.utils.formatEther(initialBalance)) - -const OptimismPortal = new ethers.Contract( - '0x16Fc5058F25648194471939df75CF27A2fdC48BC', - contracts.optimismPortalABI, - l1Wallet, -) - -console.log('Estimating L1 transaction gas...') -const gas = await OptimismPortal.estimateGas.depositTransaction( - '0x1000000000000000000000000000000000000000', // _to - ethers.utils.parseEther('0.000069420'), // _value - 1e6, // _gasLimit - false, // _isCreation - '0x', // _data -) - -console.log('Sending L1 transaction...') -const tx = await OptimismPortal.depositTransaction( - '0x1000000000000000000000000000000000000000', // _to - ethers.utils.parseEther('0.000069420'), // _value - 1e6, // _gasLimit - false, // _isCreation - '0x', // _data - { - gasLimit: gas.mul(120).div(100) // Add 20% buffer - } -) - -console.log('Waiting for L1 transaction...') -const receipt = await tx.wait() - -console.log('Waiting for L2 transaction to be relayed...') -const deposit = utils.DepositTx.fromL1Receipt(receipt, 0) -await l2Provider.waitForTransaction(deposit.hash()) - -console.log('Final balance:') -const finalBalance = await l2Wallet.getBalance() -console.log(ethers.utils.formatEther(finalBalance)) - -console.log('Difference:') -const difference = initialBalance.sub(finalBalance) -console.log(ethers.utils.formatEther(difference)) + const { createPublicClient, createWalletClient, http, parseEther, formatEther } = require('viem'); + const { optimismSepolia, sepolia } = require('viem/chains'); + const { privateKeyToAccount } = require('viem/accounts'); + const { publicActionsL2, publicActionsL1, walletActionsL2, walletActionsL1, getL2TransactionHashes } = require ('viem/op-stack') + + const privateKey = process.env.TUTORIAL_PRIVATE_KEY; + const account = privateKeyToAccount(privateKey); + + const l1PublicClient = createPublicClient({ chain: sepolia, transport: http("https://rpc.ankr.com/eth_sepolia") }).extend(publicActionsL1()) + const l2PublicClient = createPublicClient({ chain: optimismSepolia, transport: http("https://sepolia.optimism.io") }).extend(publicActionsL2()); + const l1WalletClient = createWalletClient({ chain: sepolia, transport: http("https://rpc.ankr.com/eth_sepolia") }).extend(walletActionsL1()); + const l2WalletClient = createWalletClient({ chain: optimismSepolia, transport: http("https://sepolia.optimism.io") }).extend(walletActionsL2()) + + const address = account.address; + const initialBalance = await l2PublicClient.getBalance({ address }); + console.log(`Initial balance: ${formatEther(initialBalance)} ETH`); + + const optimismPortalAbi = [ + { + inputs: [ + { internalType: 'uint256', name: '_gasLimit', type: 'uint256' }, + { internalType: 'bytes', name: '_data', type: 'bytes' }, + ], + name: 'depositTransaction', + outputs: [], + stateMutability: 'payable', + type: 'function', + }, + ]; + + const optimismPortalAddress = '0x5b47E1A08Ea6d985D6649300584e6722Ec4B1383'; + const gasLimit = 100000n; + const data = '0x'; + const value = parseEther('0.000069420'); + + const gasEstimate = await l1PublicClient.estimateContractGas({ + address: optimismPortalAddress, + abi: optimismPortalAbi, + functionName: 'depositTransaction', + args: [gasLimit, data], + value, + account: account.address, + }); + + console.log(`Gas estimate: ${gasEstimate}`); + + // Step 3: Send the transaction + const { request } = await l1PublicClient.simulateContract({ + account, + address: optimismPortalAddress, + abi: optimismPortalAbi, + functionName: 'depositTransaction', + args: [gasLimit, data], + value, + gas: gasEstimate * 120n / 100n, // 20% buffer + }) + + const l1TxHash = await l1WalletClient.writeContract(request) + console.log(`L1 transaction hash: ${l1TxHash}`) + + // Step 4: Wait for the L1 transaction + const l1Receipt = await l1PublicClient.waitForTransactionReceipt({hash: l1TxHash}) + console.log('L1 transaction confirmed:', l1Receipt) + + const [l2Hash] = getL2TransactionHashes(l1TxHash) + console.log(`Corresponding L2 transaction hash: ${l2Hash}`); + + const l2Receipt = await l2PublicClient.waitForTransactionReceipt({ + hash: l2Hash, + }); + console.log('L2 transaction confirmed:', l2Receipt); + + const finalBalance = await l2Wallet.getBalance() + console.log(`Final balance: ${formatEther(finalBalance)} ETH`); + + const difference = initialBalance - finalBalance + console.log(`Difference in balance: ${formatEther(difference)} ETH`); })() diff --git a/styles/calculator.css b/styles/calculator.css new file mode 100644 index 000000000..bb5af961b --- /dev/null +++ b/styles/calculator.css @@ -0,0 +1,208 @@ +/* Fee Parameter Calculator */ +@import url('colors.css'); + +/**** Chain Inputs Form Styles ****/ + +button.calculator-button { + padding: 17px 17px; + background: var(--op-red-500); + color: var(--op-neutral-0); + border-radius: 10px; + margin-top: 30px; + margin-bottom: 10px; +} + +.calculator-heading_sub { + font-size: 23px; + margin-bottom: 40px; + text-align: center; +} + +.calcularor-label_description { + font-size: 11px; + margin-bottom: 3px; + color: var(--op-neutral-400) +} + +.calculator-label { + display: flex; + margin-bottom: 5px; +} + +.calculator-select { + width: 100%; + padding: 8px 12px; + border: 1px solid #d3d3d3; + border-radius: 10px; + appearance: none; + -webkit-appearance: none; + -moz-appearance: none; + background-image: url('../public/img/icons/caret-down.svg'); + background-repeat: no-repeat; + background-position: right 10px center; + background-size: 20px; +} + +.calculator-select, +.calculator-input { + margin-bottom: 20px; +} + +select.calculator-select :hover, +select.calculator-select :focus { + border-color: #a9a9a9; + outline: none; +} + +.calculator-form { + margin-top: 40px; + margin-bottom: 30px; + border: 1px solid #efefef; + padding: 35px 30px; + border-radius: 10px; +} + +.calculator-input { + border: 1px solid #dedede; + width: 100%; + border-radius: 10px; + padding: 8px 12px; +} + +/**** Construction Info Styles ****/ + +.construction-info { + margin-bottom: 50px; +} + +.construction-info p { + font-weight: 500; + font-size: 14px; + text-align: center; + padding: 0 40px; + color: var(--op-neutral-500) +} + +.construction-info p span { + font-weight: 700; +} + +/**** Results & Table Styles ****/ + +.results-extra-info, .additional-info p:first-of-type { + margin-bottom: 7px; +} + +.results-table-wrap div.calculator-text p { + font-style: italic; + font-weight: 500; + font-size: 12px; + text-align: center; + color: var(--op-neutral-700) +} + +.calculator-results-wrap table { + width: 100%; + border-collapse: collapse; + margin-bottom: 40px; +} + +.calculator-results-wrap th, +.calculator-results-wrap td { + border: 1px solid var(--op-red-200); + padding: 8px; + text-align: left; +} + +.calculator-results-wrap thead .sub-header { + background-color: var(--op-red-600) !important; + color: var(--op-neutral-0); +} + +.calculator-results-wrap tbody tr td, +.calculator-results-wrap thead tr:nth-of-type(2) th { + text-align: center; +} + +.calculator-results-wrap tbody tr td:first-of-type, +.calculator-results-wrap thead tr:nth-of-type(2) th:first-of-type { + text-align: right; +} + +div.calculator-results-wrap .results-container .results-table-wrap tbody { + font-size: 14px; + color: var(--op-red-600); + font-weight: 700; +} + +.calculator-results-wrap thead th[colspan="2"] { + text-align: right; +} + +div.calculator-results-wrap +.results-container +.results-table-wrap { + display: flex; + flex-direction: column; + align-items: center; + } + +div.calculator-results-wrap +.results-container +.results-table-wrap +table.results-table.table { + border: 1px solid #efefef; + padding: 30px; + border-radius: 10px; +} + +div.calculator-results-wrap +.results-container +.results-recommendations +.calculator-info { + padding: 20px 15px; + background: var(--op-blue-200); + color: var(--op-blue-500); + border-radius: 20px; + margin: 30px 0px; +} + +div.calculator-results-wrap +.results-container +.results-recommendations +.calculator-info.calculator-text a { + text-decoration: underline; + font-style: italic; +} + +.results-recommendations { + margin-bottom: 40px; +} + +div.calculator-results-wrap +.results-container +h3.calculator-heading_text { + font-weight: 100; + color: var(--op-neutral-500); +} + +div.calculator-results-wrap +.results-container .calculator-text { + font-size: 14px; + color: var(--op-neutral-500); +} + +div.calculator-results-wrap .results-container{ + border: 1px solid #efefef; + border-radius: 10px; + padding: 40px 30px 50px; +} + +.loader-container { + display: flex; + justify-content: center; + width: 100%; +} +.loader-container svg { + width: 40px; +} \ No newline at end of file diff --git a/styles/global.css b/styles/global.css index 498779c39..4a1dcb2af 100644 --- a/styles/global.css +++ b/styles/global.css @@ -2,11 +2,12 @@ @import url('https://fonts.googleapis.com/css2?family=JetBrains+Mono:wght@400..700&display=swap'); @import url('colors.css'); @import url('theme.css'); +@import url('calculator.css'); /* Override Nextra so content gets more breathing room */ .nextra-content h2 ~ p, .nextra-content h3 ~ p { - margin-top: 1rem; + margin-bottom: 1.25rem; } /* Custom div that can contain Nextra images */ @@ -68,12 +69,6 @@ a.callout-link { text-decoration: underline; } -@media only screen and (max-width: 767px) { - div.custom-callouts { - top: 105px; - } -} - html.dark div.custom-callouts { color: white; background-color: #432c11; @@ -81,3 +76,18 @@ html.dark div.custom-callouts { html.dark a.callout-link { color: #008ae6; } +.callout-close-btn { + position: absolute; + top: -9px; + right: -9px; + width: 25px; + height: 25px; + border-radius: 50%; + background-color: #fefce8; + display: flex; + justify-content: center; + align-items: center; + border: 2px solid #ffdc00; + color: red; + font-size: 14px; +} diff --git a/styles/theme.css b/styles/theme.css index c82741b6f..1f091d7ca 100644 --- a/styles/theme.css +++ b/styles/theme.css @@ -153,11 +153,11 @@ h4 { } .nextra-content h2 ~ p { - margin-top: .3rem + margin-top: .8rem } .nextra-content h3 ~ p { - margin-top: .3rem; + margin-top: .6rem; } diff --git a/theme.config.tsx b/theme.config.tsx index a4b8adcca..1200969a0 100644 --- a/theme.config.tsx +++ b/theme.config.tsx @@ -28,6 +28,14 @@ const config: DocsThemeConfig = { ), darkMode: true, + banner: { + key: 'viem/op-stack', + text: ( + + πŸŽ‰ We are deprecating the Optimism SDK and migrating all tutorials to use viem/op-stack. Read more β†’ + + ) + }, search: { component: Search, }, diff --git a/utils/breadcrumbs.ts b/utils/breadcrumbs.ts new file mode 100644 index 000000000..ff00309d7 --- /dev/null +++ b/utils/breadcrumbs.ts @@ -0,0 +1,154 @@ +import * as fs from 'fs/promises'; +import * as path from 'path'; +import matter from 'gray-matter'; + +const rootDir: string = path.join(__dirname, '..', 'pages'); +const warnings: string[] = []; + +// ANSI color codes +const YELLOW = '\x1b[33m'; +const RESET = '\x1b[0m'; +const BOLD = '\x1b[1m'; + +interface FileInfo { + title: string; + url: string; + description?: string; + content: string; +} + +// Pages to exclude from checks +const excludedPages = [ + '400.mdx', + '500.mdx', + 'index.mdx', + '404.mdx', + 'console', + 'block-explorer', + 'bridge', + 'sdk', + 'faucet', + 'gas', + 'bug-bounty', + 'live-support', + 'governance', + 'changelog', + 'experimental' +]; + +async function getContentFiles(folderPath: string): Promise { + const files = await fs.readdir(folderPath, { withFileTypes: true }); + const fileInfos: FileInfo[] = []; + const folderName = path.basename(folderPath); + + for (const file of files) { + if (file.name.startsWith('_') || + file.name.startsWith('.') || + excludedPages.includes(file.name)) { + continue; + } + + const filePath = path.join(folderPath, file.name); + + if (file.isFile() && (file.name.endsWith('.md') || file.name.endsWith('.mdx'))) { + try { + const content = await fs.readFile(filePath, 'utf-8'); + const { data: frontMatter } = matter(content); + const fileName = path.basename(file.name, path.extname(file.name)); + const fileTitle = frontMatter.title || fileName; + const relativeUrl = `/${path.relative(rootDir, filePath)}`.replace(/\.(md|mdx)$/, ''); + + fileInfos.push({ + title: fileTitle, + url: relativeUrl, + description: frontMatter.description, + content: content + }); + } catch (error) { + console.error(`Error processing file ${file.name}:`, error); + } + } + } + + return fileInfos; +} + +async function getBreadcrumbCards(breadcrumbPath: string): Promise> { + try { + const content = await fs.readFile(breadcrumbPath, 'utf-8'); + const cardMatches = content.match(/]*href="([^"]+)"[^>]*>/g) || []; + return new Set( + cardMatches.map(match => { + const hrefMatch = match.match(/href="([^"]+)"/); + return hrefMatch ? hrefMatch[1] : ''; + }).filter(Boolean) + ); + } catch (error) { + return new Set(); + } +} + +async function checkDirectory(dirPath: string): Promise { + const entries = await fs.readdir(dirPath, { withFileTypes: true }); + + for (const entry of entries) { + if (entry.isDirectory() && !entry.name.startsWith('_') && !entry.name.startsWith('.')) { + const folderPath = path.join(dirPath, entry.name); + const breadcrumbPath = path.join(dirPath, `${entry.name}.mdx`); + + // Get all content files in the folder + const files = await getContentFiles(folderPath); + + // Get existing cards in breadcrumb + const existingCards = await getBreadcrumbCards(breadcrumbPath); + + // Check for missing pages + files.forEach(({ title, url }) => { + if (!existingCards.has(url)) { + warnings.push( + `Page "${title}" at ${url} needs to be added to the breadcrumb file ${entry.name}.mdx` + ); + } + }); + + // Recursively check subdirectories + await checkDirectory(folderPath); + } + } +} + +async function main() { + console.log('Starting breadcrumb check process...'); + console.log('Root directory:', rootDir); + + try { + // Process main sections: builders, chain, connect, stack + const mainSections = ['builders', 'chain', 'connect', 'stack']; + for (const section of mainSections) { + const sectionPath = path.join(rootDir, section); + try { + await fs.access(sectionPath); + await checkDirectory(sectionPath); + console.log(`Completed checking ${section} section`); + } catch (error) { + console.log(`Skipping ${section} - directory not found`); + } + } + + if (warnings.length > 0) { + console.log(`${YELLOW}${BOLD}Missing pages in breadcrumb navigation:${RESET}`); + warnings.forEach(warning => console.log(`${YELLOW}- ${warning}${RESET}`)); + process.exit(1); + } else { + console.log('All pages are properly referenced in breadcrumb files.'); + } + } catch (error) { + console.log(`${YELLOW}${BOLD}Error checking breadcrumbs:${RESET}`, error); + process.exit(1); + } +} + +main().catch(error => { + console.error('Error in main process:', error); + process.exit(1); +}); diff --git a/utils/calculator-helpers.ts b/utils/calculator-helpers.ts new file mode 100644 index 000000000..c2c9fcb26 --- /dev/null +++ b/utils/calculator-helpers.ts @@ -0,0 +1,1083 @@ +import { transactionTypes } from "./transaction-types"; + +const L1GasBaseFee = + "https://raw.githubusercontent.com/ethereum-optimism/op-analytics/refs/heads/main/reference_data/market_data/outputs/suggest_base_fee.txt"; // E76 +const ethToUsdRate = + "https://raw.githubusercontent.com/ethereum-optimism/op-analytics/refs/heads/main/reference_data/market_data/outputs/ethusd.txt"; // E77 +const blobBaseFee = + "https://raw.githubusercontent.com/ethereum-optimism/op-analytics/refs/heads/main/reference_data/market_data/outputs/blob_base_fee.txt"; // E78 + +// transactionsPerDay === E14: number +// comparableTxnType === E15: string +// dataAvailabilityType === E16: string +// isFaultProofsEnabled === E17: boolean +// targetDataMargin === E18: number +// maxChannelDuration === E22: number +// outputRootPostFrequency === E23: number +// isStateEnabled: boolean, === E24: string + +// ModeledExpectedStateCostsOnL1: number === e120 == n40 == e56 +// ModeledDACostsOnL1: number === e119 == e55 +// ModeledDAPlusStateRevenueOnL2: number === e118 + +function calculateBlobTransactionCost( + dataAvailabilityType: string, // E16: string + altDATransactionCost: number, // E98: number + blobDataFee: number, // E64: number + l1CalldataFee: number, // E67: number + l1CalldataCost: number, // E96: number + blobCost: number // E94: number +): number { + return dataAvailabilityType === "AltDA Plasma Mode" + ? altDATransactionCost + : blobDataFee > l1CalldataFee + ? l1CalldataCost + : blobCost; +} // output = E37 + +function calculateAltDAOrL1TransactionCost( + dataAvailabilityType: string, //E16 + altDAPlasmaModeCost: number, // F98 + blobDataFee: number, // E64 + l1CalldataFee: number, // E67 + l1CalldataAltCost: number, // F96 + blobAltCost: number // F94 +): number { + if (dataAvailabilityType === "AltDA Plasma Mode") { + return altDAPlasmaModeCost; + } else { + return blobDataFee > l1CalldataFee ? l1CalldataAltCost : blobAltCost; + } +} // output = E38 + +export function resultsFeeScalarsAssumed( + comparableTxnType: string, // e15 + transactionsPerDay: number, // e14 + dataAvailabilityType: string, // E16 + targetDataMargin: number, // E18 + isStateEnabled: string, // E24 + maxChannelDuration: number // E22 +): string { + const n25: number = calculateBlobLevelImpliedBlobFullness( + comparableTxnType, + transactionsPerDay, + maxChannelDuration + ) // n25 + + const n26: number = calculateImpliedBlobsPerL1Tx( + comparableTxnType, + transactionsPerDay, + maxChannelDuration + ); // n26 + const mode = + dataAvailabilityType === "AltDA Plasma Mode" + ? "AltDA Plasma Mode, " + : `${Math.round(n25 * 100)}% Blob Fullness and ${ + Math.round(n26 * 10) / 10 + } Blobs per L1 Tx (Avg), `; + const state = isStateEnabled === "Yes" ? " & State" : ""; + return `Fee Scalars Assume: ${mode}Target a ${Math.round( + targetDataMargin + )}% Margin on DA${state}, ${ + Math.round(maxChannelDuration * 100000) / 100000 + } hour Max Submission Window.`; +} // output = G41 + +export async function impliedDataGasFee( + dataAvailabilityType: string, // E16 +): Promise { + const blobgasBaseFee: number = await getBlobBaseFee()// E78 + const l1BaseFee: number = await getL1GasBaseFee(); // E76 + const ethToUsdRate: number = await getEthToUsdRate() // E77 + const mode = + dataAvailabilityType === "AltDA Plasma Mode" + ? "AltDA Plasma Mode, " + : `${Math.round(blobgasBaseFee * 100) / 100} gwei Blobgas Base Fee, `; + return `Implied Data Gas Fee Assumes: ${mode}${ + Math.round(l1BaseFee * 10) / 10 + } gwei L1 Base Fee, ${Math.round(ethToUsdRate)} ETH/USD`; +} // output = G42 + +export function convertToMillionUnits(value: number): number { + return value / 1000000; +} + +export async function getEthToUsdRate(): Promise { + try { + const response = await fetch(ethToUsdRate); + if (!response.ok) { + throw new Error(`Network response was not ok: ${response.status} ${response.statusText}`); + } + const rateText = await response.text(); + const rate = parseFloat(rateText); + if (isNaN(rate)) { + throw new Error(`Failed to parse ETH to USD rate: ${rateText}`); + } + return rate; + } catch (error) { + console.error('Error fetching ETH to USD rate:', error); + throw error; + } +} + +export const determineDAInUse = (dataAvailabilityType: string): string => { + return dataAvailabilityType === "AltDA Plasma Mode" + ? "AltDA Plasma Mode" + : dataAvailabilityType === "L1 Calldata" + ? "L1 Calldata" + : "EIP-4844"; +}; + +// =INDEX($A$20:$G$32,MATCH('Chain Estimator'!$E$15,$A$20:$A$32,0),MATCH($B8,$A$20:$G$20,0)) +const getAvgEstimatedSizePerTx = (comparableTxnType: string) => { + if (!transactionTypes[comparableTxnType]) { + throw new Error(`Invalid transaction type: ${comparableTxnType}`); + } + const output = transactionTypes[comparableTxnType].AvgEstimatedSizePerTx; + console.log("c8::", output); + return output; +}; // c8 done + +// =(N22*N5)/(C8*'Chain Estimator'!E14) +const calculateImpliedCTSL1Data = ( + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string +) => { + const n22 = calculateImpliedBlobsPerDay( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const c8 = getAvgEstimatedSizePerTx(comparableTxnType); + const n5 = Total_Blobgas_Per_Blob; + const output = (n22 * n5) / (c8 * transactionsPerDay); ; + console.log("c10::", output); + return output; +}; // c10 done + +// =(C8*'Chain Estimator'!E14*C13 + N11*N27)/(C8*'Chain Estimator'!E14) +const calculateImpliedCTSL1Gas = ( + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string +) => { + const c8 = getAvgEstimatedSizePerTx(comparableTxnType); + const c13 = getEstimatedSizeCalldataGasRatio(comparableTxnType); + const n27 = calculateImpliedL1Txs( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const numerator = + c8 * transactionsPerDay * c13 + Avg_Compressed_Overhead_Gas_Per_Blob * n27; + const denominator = c8 * transactionsPerDay; + const output = numerator / denominator; + console.log("c11::", output); + return output; +}; // c11 done + +// =INDEX($A$20:$G$32,MATCH('Chain Estimator'!$E$15,$A$20:$A$32,0),MATCH($B12,$A$20:$G$20,0)) +const getEstimatedSizeBlobgasRatio = (comparableTxnType: string) => { + const output = transactionTypes[comparableTxnType].EstimatedSizeBlobgasRatio; + console.log("c12::", output); + return output; +}; // c12 done + +const getEstimatedSizeCalldataGasRatio = (comparableTxnType: string) => { + const output = + transactionTypes[comparableTxnType].EstimatedSizeCalldataGasRatio; + console.log("c13::", output); + return output; +}; // c13 done + +// =24/'Chain Estimator'!E22 +const calculateImpliedMinimumBlobsPerDay = ( + maxChannelDuration: number +) => { + const output = 24 / maxChannelDuration; + console.log("n19::", output); + return output; +}; // n19 + +// =(N5-N10-N6)*C12 +const calculateImpliedEstimatedSizePerBlob = ( + comparableTxnType: string +): number => { + const c12 = getEstimatedSizeBlobgasRatio(comparableTxnType); + const output = + (Total_Blobgas_Per_Blob - + Avg_Compressed_Overhead_Bytes_Per_Blob - + Overhead_Blobgas_per_Blob) * + c12; + console.log("n20::", output); + return output; +}; // n20 done + +// =MIN(N20/C8,'Chain Estimator'!E14/(24/'Chain Estimator'!E22)) +const calculateImpliedL2TxsPerBlob = ( + comparableTxnType: string, + transactionsPerDay: number, + maxChannelDuration: number +) => { + const n20 = calculateImpliedEstimatedSizePerBlob(comparableTxnType); + const c8 = getAvgEstimatedSizePerTx(comparableTxnType); + const value1 = n20 / c8; + const value2 = transactionsPerDay / (24 / maxChannelDuration); + const output = Math.min(value1, value2); + console.log("n21::", output); + return output; +}; // n21 done + +// ='Chain Estimator'!E14/N21 +const calculateImpliedBlobsPerDay = ( + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string +) => { + const output = + transactionsPerDay / + calculateImpliedL2TxsPerBlob( + comparableTxnType, + transactionsPerDay, + maxChannelDuration + ); + console.log("n22::", output); + return output; +}; // n22 done + +// =N20*N22*(C11/16)+(N11*N22) +const calculateImpliedCalldataGasUsedIfL1 = ( + comparableTxnType: string, + transactionsPerDay: number, + maxChannelDuration: number +) => { + const n20 = calculateImpliedEstimatedSizePerBlob(comparableTxnType); + const n22 = calculateImpliedBlobsPerDay( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const c11 = calculateImpliedCTSL1Gas( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const output = + n20 * n22 * (c11 / 16) + (Avg_Compressed_Overhead_Gas_Per_Blob * n22); + console.log("n23::", output); + return output; +}; // n23 done + +// =MIN(N9,(C8*'Chain Estimator'!E14)*('Chain Estimator'!E22/24)/N20) +const calculateL1TxLevelImpliedBlobFullness = ( + comparableTxnType: string, + transactionsPerDay: number, + maxChannelDuration: number +) => { + const c8 = getEstimatedSizeCalldataGasRatio(comparableTxnType); + const n20 = calculateImpliedEstimatedSizePerBlob(comparableTxnType); + const result = (c8 * transactionsPerDay * (maxChannelDuration / 24)) / n20; + const output = Math.min(Max_No_Of_Blobs_Per_L1_Transaction, result); + console.log("n24::", output); + return output; +}; // n24 done + +// =(N21*C8)/N20 +const calculateBlobLevelImpliedBlobFullness = ( + comparableTxnType: string, + transactionsPerDay: number, + maxChannelDuration: number +) => { + const n21 = calculateImpliedL2TxsPerBlob( + comparableTxnType, + transactionsPerDay, + maxChannelDuration + ); + const c8 = getAvgEstimatedSizePerTx(comparableTxnType); + const n20 = calculateImpliedEstimatedSizePerBlob(comparableTxnType); + const output = (n21 * c8) / n20; + console.log("n25::", output); + return output; +}; // n25 done + +// =ROUND(MAX(N24/1,1),0) +const calculateImpliedBlobsPerL1Tx = ( + comparableTxnType: string, + transactionsPerDay: number, + maxChannelDuration: number +) => { + const n24 = calculateL1TxLevelImpliedBlobFullness( + comparableTxnType, + transactionsPerDay, + maxChannelDuration + ); + const maxValue = Math.max(n24, 1); + const output = Math.round(maxValue); + console.log("n26::", output); + return output; +}; // n26 done + +// =N22/N26 +const calculateImpliedL1Txs = ( + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string +) => { + const n22 = calculateImpliedBlobsPerDay( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const n26 = calculateImpliedBlobsPerL1Tx( + comparableTxnType, + transactionsPerDay, + maxChannelDuration + ); + const output = n22 / n26; + console.log("n27::", output); + return output; +}; // n27 done + +// =N27*N7 +const calculateTotalBlobCommitmentL1Gas = ( + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string +) => { + const n27 = calculateImpliedL1Txs( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const output = n27 * L1_Gas_per_Blob_Commitment; + console.log("n30::", output); + return output; +}; // n30 done + +// =N22*N8 +const calculateTotalAltDAPlasmaModeCommitmentL1Gas = ( + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string +) => { + const n22 = calculateImpliedBlobsPerDay( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const output = n22 * L1_Gas_Per_AltDA_Plasma_Mode_Commitment; + console.log("n31::", output); + return output; +}; // n31 done + +// N22 * N5 +const calculateTotalBlobgas = ( + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string +) => { + const n22 = calculateImpliedBlobsPerDay( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const output = n22 * Total_Blobgas_Per_Blob; + console.log("n32::", output) + return output; +}; // n32 + +// =IF('Chain Estimator'!E23=0,0,24/'Chain Estimator'!E23) +const calculateImpliedStateProposalsPerDay = ( + outputRootPostFrequency: number +) => { + const output = + outputRootPostFrequency === 0 ? 0 : 24 / outputRootPostFrequency; + console.log("n33::", output); + return output; +}; // n33 done + +// =N33*IF('Chain Estimator'!E17="Yes",N16,N12) +const calculateTotalStateProposalL1Gas = ( + outputRootPostFrequency: number, + isFaultProofsEnabled: boolean +): number => { + const n33 = calculateImpliedStateProposalsPerDay(outputRootPostFrequency); + const output = + n33 * + (isFaultProofsEnabled + ? Avg_Total_Gas_Used_Per_L1_Fault_Proof_State_Proposal + : Avg_Total_Gas_Used_Per_L1_State_Proposal); + console.log("n34::", output); + return output; +}; // n34 done + +// =IF('Chain Estimator'!E24="Yes",1,0)*N34 +const calculateTotalStateProposalL1GasCoveredByUsers = ( + isStateEnabled: boolean, + outputRootPostFrequency: number, + isFaultProofsEnabled: boolean +) => { + const n34 = calculateTotalStateProposalL1Gas( + outputRootPostFrequency, + isFaultProofsEnabled + ); + const output = (isStateEnabled ? 1 : 0) * n34; + console.log("n35::", output); + return output; +}; // n35 done + +// =N30*'Chain Estimator'!E76/1000000000 +const calculateTotalBlobCommitmentCostsInETH = async ( + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string +) => { + const n30 = calculateTotalBlobCommitmentL1Gas( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ) + const e76 = await getL1GasBaseFee(); + const output = (n30 * e76) / 1000000000; + console.log("n36::", output) + return output; +} // n36 + +// =N31*'Chain Estimator'!E76/1000000000 +const calculateTotalAltDAPlasmaModeCommitmentCostsInETH = async ( + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string +) => { + const n31 = calculateTotalAltDAPlasmaModeCommitmentL1Gas( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ) + const e76 = await getL1GasBaseFee(); + const output = n31 * e76 / 1000000000; + console.log("n37::", output) + return output; +} // n37 done + +// =N32*'Chain Estimator'!E78/1000000000 +const calculateTotalBlobgasCostsInETH = async ( + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string +) => { + const n32 = calculateTotalBlobgas( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ) + const e78 = await getBlobBaseFee(); + const output = (n32 * e78) / 1000000000; + console.log("n38::", output); + return output; +} // n38 + +// =N23*'Chain Estimator'!E76/1000000000 +const calculateTotalL1CalldataCostsInETHIfL1 = async ( + comparableTxnType: string, + transactionsPerDay: number, + maxChannelDuration: number +) => { + const n23 = calculateImpliedCalldataGasUsedIfL1( + comparableTxnType, + transactionsPerDay, + maxChannelDuration + ) + const e76 = await getL1GasBaseFee(); + const output = (n23 * e76) / 1000000000; + console.log("n39::", output); + return output; +} // n39 + +const _calculateL1BlobBaseFeeScalar = ( + determinedDAInUse: string, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string, + targetDataMargin: number +) => { + let output = 0; + const c10 = calculateImpliedCTSL1Data( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const n25 = calculateBlobLevelImpliedBlobFullness( + comparableTxnType, + transactionsPerDay, + maxChannelDuration + ); + const e18 = _targetDataMarginInPercentage(targetDataMargin); + if (determinedDAInUse === "EIP-4844") { + output = (c10 / n25 / (1 - e18)) * 1000000; + } + + console.log("_calculateL1BlobBaseFeeScalar:::", output); + return Math.round(output); +}; + +async function getL1GasBaseFee(): Promise { + try { + const response = await fetch(L1GasBaseFee); + if (!response.ok) { + throw new Error(`Network response was not ok: ${response.status} ${response.statusText}`); + } + const baseFeeText = await response.text(); + console.log("L1GasBaseFee_response::", baseFeeText); + const output = parseFloat(baseFeeText); + if (isNaN(output)) { + throw new Error(`Failed to parse L1 Gas Base Fee: ${baseFeeText}`); + } + console.log("e76:::", output); + return output; + } catch (error) { + console.error('Error fetching L1 Gas Base Fee:', error); + throw error; + } +} + +const getBlobBaseFee = async (): Promise => { + try { + const response = await fetch(blobBaseFee); + if (!response.ok) { + throw new Error(`Network response was not ok: ${response.status} ${response.statusText}`); + } + const feeText = await response.text(); + console.log("BlobBaseFee_response::", feeText); + const output = parseFloat(feeText); + if (isNaN(output)) { + throw new Error(`Failed to parse Blob Base Fee: ${feeText}`); + } + console.log("e78:::", output); + return output; + } catch (error) { + console.error('Error fetching Blob Base Fee:', error); + throw error; + } +}; + +// =ROUND((('Advanced Inputs'!C10/'Advanced Inputs'!N25/(1-E18))*1000000),0) +const calculateL1BlobBaseFeeScalarUsingBlob = ( + determinedDAInUse: string, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string, + targetDataMargin: number +) => { + const output = _calculateL1BlobBaseFeeScalar( + determinedDAInUse, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin + ); + console.log("e94:::", output); + return output; +}; // e94 done + +const calculateL1BlobBaseFeeScalarUsingL1Calldata = ( + determinedDAInUse: string, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string, + targetDataMargin: number +) => { + const output = _calculateL1BlobBaseFeeScalar( + determinedDAInUse, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin + ); + console.log("e96::", output); + return output; +}; // e96 done + +const calculateL1BlobBaseFeeScalarUsingPlasmaMode = ( + determinedDAInUse: string, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string, + targetDataMargin: number +) => { + const output = _calculateL1BlobBaseFeeScalar( + determinedDAInUse, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin + ); + console.log("e98::", output); + return output; +}; // e98 done + +const calculateL1BaseFeeScalarUsingBlobs = ( + isStateEnabled: boolean, + isFaultProofsEnabled: boolean, + outputRootPostFrequency: number, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string, + targetDataMargin: number +) => { + const n30 = calculateTotalBlobCommitmentL1Gas( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const n35 = calculateTotalStateProposalL1GasCoveredByUsers( + isStateEnabled, + outputRootPostFrequency, + isFaultProofsEnabled + ); + const c8 = getAvgEstimatedSizePerTx(comparableTxnType); + const e18 = _targetDataMarginInPercentage(targetDataMargin); + const numerator = n30 + n35; + const denominator = transactionsPerDay * (16 * c8); + const result = numerator / denominator / (1 - e18); + return Math.round(result * 1000000); +}; // f94 done + +const calculateL1BaseFeeScalarUsingL1Calldata = ( + targetDataMargin: number, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string +): number => { + const e18 = _targetDataMarginInPercentage(targetDataMargin); + const c11 = calculateImpliedCTSL1Gas( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const value = c11 / 16 / (1 - e18); + const output = Math.round(value * 1000000); + console.log("f96::", output) + return output +}; // f96 done + +const calculateL1BaseFeeScalarUsingPlasmaMode = ( + targetDataMargin: number, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string, + isStateEnabled: boolean, + outputRootPostFrequency: number, + isFaultProofsEnabled: boolean +) => { + const n31 = calculateTotalAltDAPlasmaModeCommitmentL1Gas( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const n35 = calculateTotalStateProposalL1GasCoveredByUsers( + isStateEnabled, + outputRootPostFrequency, + isFaultProofsEnabled + ); + const c8 = getAvgEstimatedSizePerTx(comparableTxnType); + const e18 = _targetDataMarginInPercentage(targetDataMargin); + const value = (n31 + n35) / (transactionsPerDay * (16 * c8)) / (1 - e18); + const output = Math.round(value * 1000000); + console.log("f98::", output); + return output; +}; // f98 done + +const _targetDataMarginInPercentage = (targetDataMargin: number): number => { + return targetDataMargin / 100; +}; + +const _getCalculateImpliedDataGasFeePerTxParams = async ( + isStateEnabled: boolean, + isFaultProofsEnabled: boolean, + outputRootPostFrequency: number, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string, + targetDataMargin: number, + dataAvailabilityType: string +) => { + const c8 = getAvgEstimatedSizePerTx(comparableTxnType); + const f94 = calculateL1BaseFeeScalarUsingBlobs( + isStateEnabled, + isFaultProofsEnabled, + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin + ); + const f96 = calculateL1BaseFeeScalarUsingL1Calldata( + targetDataMargin, + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const e76 = await getL1GasBaseFee(); + const determinedDAInUse = determineDAInUse(dataAvailabilityType); + const e94 = calculateL1BlobBaseFeeScalarUsingBlob( + determinedDAInUse, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin + ); + const e96 = calculateL1BlobBaseFeeScalarUsingL1Calldata( + determinedDAInUse, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin + ); + const e78 = await getBlobBaseFee(); + const e77 = await getEthToUsdRate(); + return { c8, e76, e77, e78, e94, e96, f94, f96 }; +}; + +const _getBaseFeeScalarCalculationParams = async ( + isStateEnabled: boolean, + isFaultProofsEnabled: boolean, + outputRootPostFrequency: number, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string, + targetDataMargin: number, + dataAvailabilityType: string +) => { + const determinedDAInUse = determineDAInUse(dataAvailabilityType); + const e98 = calculateL1BlobBaseFeeScalarUsingPlasmaMode( + determinedDAInUse, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin + ); + const e64 = await calculateImpliedDataGasFeePerTxUsingBlobs( + isStateEnabled, + isFaultProofsEnabled, + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + dataAvailabilityType, + targetDataMargin + ); + const e67 = await calculateImpliedDataGasFeePerTxUsingL1Calldata( + isStateEnabled, + isFaultProofsEnabled, + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + dataAvailabilityType, + targetDataMargin + ); + const e96 = calculateL1BlobBaseFeeScalarUsingL1Calldata( + determinedDAInUse, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin + ); + const e94 = calculateL1BlobBaseFeeScalarUsingBlob( + determinedDAInUse, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin + ); + const f94 = calculateL1BaseFeeScalarUsingBlobs( + isStateEnabled, + isFaultProofsEnabled, + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin + ); + const f96 = calculateL1BaseFeeScalarUsingL1Calldata( + targetDataMargin, + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const f98 = calculateL1BaseFeeScalarUsingPlasmaMode( + targetDataMargin, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + isStateEnabled, + outputRootPostFrequency, + isFaultProofsEnabled + ); + return { e98, e64, e67, e96, e94, f94, f96, f98 }; +}; + +export const calculateImpliedDataGasFeePerTxUsingBlobs = async ( + isStateEnabled: boolean, + isFaultProofsEnabled: boolean, + outputRootPostFrequency: number, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string, + dataAvailabilityType: string, + targetDataMargin: number +) => { + const { c8, f94, e76, e77, e78, e94 } = + await _getCalculateImpliedDataGasFeePerTxParams( + isStateEnabled, + isFaultProofsEnabled, + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin, + dataAvailabilityType + ); + const value = (c8 * (16 * f94 * e76 + e94 * e78)) / 1000000 / 1000000000; + const output = value * e77; + console.log("e64::", output) + return output +}; // e64 done + +// =('Advanced Inputs'!C8*(16*F98*E76+E98*E78)/1000000/1000000000)*E77 +export const calculateImpliedDataGasFeePerTxUsingAltDAPlasmaMode = async ( + isStateEnabled: boolean, + isFaultProofsEnabled: boolean, + outputRootPostFrequency: number, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string, + dataAvailabilityType: string, + targetDataMargin: number +) => { + const { c8, e76, e77, e78} = + await _getCalculateImpliedDataGasFeePerTxParams( + isStateEnabled, + isFaultProofsEnabled, + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin, + dataAvailabilityType + ); + const { f98, e98 } = await _getBaseFeeScalarCalculationParams( + isStateEnabled, + isFaultProofsEnabled, + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin, + dataAvailabilityType + ); + + const part1 = 16 * f98 * e76; + const part2 = e98 * e78; + const sum = part1 + part2; + const result = sum / 1000000 / 1000000000; + const output = c8 * result * e77; + console.log("e66::", output); + return output; +}; // e66 + +export const calculateImpliedDataGasFeePerTxUsingL1Calldata = async ( + isStateEnabled: boolean, + isFaultProofsEnabled: boolean, + outputRootPostFrequency: number, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string, + dataAvailabilityType: string, + targetDataMargin: number +) => { + const { c8, f96, e76, e77, e78, e96 } = + await _getCalculateImpliedDataGasFeePerTxParams( + isStateEnabled, + isFaultProofsEnabled, + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin, + dataAvailabilityType + ); + const value = (c8 * (16 * f96 * e76 + e96 * e78)) / 1000000 / 1000000000; + const output = value * e77; + console.log("e67::", output); + return output; +}; // e67 done + +// =N34*'Chain Estimator'!E76/1000000000 +export const calculateTotalL1StateProposalCostsInETH = async ( + outputRootPostFrequency: number, + isFaultProofsEnabled: boolean +) => { + const n34 = calculateTotalStateProposalL1Gas( + outputRootPostFrequency, + isFaultProofsEnabled + ); + const e76 = await getL1GasBaseFee(); + const output = (n34 * e76) / 1000000000; + console.log("n40::", output) + return output; +}; // n40 done + +export async function displayL1BlobBaseFeeScalar( + isStateEnabled: boolean, + isFaultProofsEnabled: boolean, + outputRootPostFrequency: number, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string, + dataAvailabilityType: string, + targetDataMargin: number +) { + const { e98, e64, e67, e96, e94 } = await _getBaseFeeScalarCalculationParams( + isStateEnabled, + isFaultProofsEnabled, + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin, + dataAvailabilityType + ); + return calculateBlobTransactionCost( + dataAvailabilityType, + e98, + e64, + e67, + e96, + e94 + ); +} // e37 done + +export async function displayL1BaseFeeScalar( + isStateEnabled: boolean, + isFaultProofsEnabled: boolean, + outputRootPostFrequency: number, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string, + targetDataMargin: number, + dataAvailabilityType: string +) { + const { f98, e64, e67, f96, f94 } = await _getBaseFeeScalarCalculationParams( + isStateEnabled, + isFaultProofsEnabled, + outputRootPostFrequency, + transactionsPerDay, + maxChannelDuration, + comparableTxnType, + targetDataMargin, + dataAvailabilityType + ); + return calculateAltDAOrL1TransactionCost(dataAvailabilityType, f98, e64, e67, f96, f94); +} // e38 done + +// =E118-(E56+E55) | OverallL1DataAndStateCostsMargin +export const calculateOverallL1DataAndStateCostsMargin = async ( + transactionsPerDay: number, + comparableTxnType: string, + displayL1BlobBaseFeeScalar: number, + displayL1BaseFeeScalar: number, + dataAvailabilityType: string, + maxChannelDuration: number, + outputRootPostFrequency: number, + isFaultProofsEnabled: boolean +) => { + const e118 = await calculateModeledDAPlusStateRevenueOnL2(transactionsPerDay, comparableTxnType, displayL1BlobBaseFeeScalar, displayL1BaseFeeScalar) + const e55 = await calculateModeledDACostsOnL1( + dataAvailabilityType, + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ) + const e56 = await calculateTotalL1StateProposalCostsInETH( + outputRootPostFrequency, + isFaultProofsEnabled + ) + const output = e118 - (e56 + e55); + console.log("e58::", output); + return output; +} // e58 + +// =(E14*'Advanced Inputs'!C8*(16*G38*E76/1000000000+G37*E78/1000000000)) +export const calculateModeledDAPlusStateRevenueOnL2 = async ( + transactionsPerDay: number, + comparableTxnType: string, + displayL1BlobBaseFeeScalar: number, + displayL1BaseFeeScalar: number +) => { + const c8 = getAvgEstimatedSizePerTx(comparableTxnType); + const g38 = convertToMillionUnits(displayL1BaseFeeScalar); + const g37 = convertToMillionUnits(displayL1BlobBaseFeeScalar); + const e76 = await getL1GasBaseFee(); + const e78 = await getBlobBaseFee(); + const part1 = (16 * g38 * e76) / 1000000000; + const part2 = (g37 * e78) / 1000000000; + const output = transactionsPerDay * c8 * (part1 + part2); + console.log("e118::", output) + return output +} // e118 + +async function calculateModeledDACostsOnL1( + dataAvailabilityType: string, + transactionsPerDay: number, + maxChannelDuration: number, + comparableTxnType: string +): Promise { + let output = 0; + const f35 = determineDAInUse(dataAvailabilityType); + const n36 = await calculateTotalBlobCommitmentCostsInETH( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ); + const n37 = await calculateTotalAltDAPlasmaModeCommitmentCostsInETH( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ) + const n38 = await calculateTotalBlobgasCostsInETH( + transactionsPerDay, + maxChannelDuration, + comparableTxnType + ) + const n39 = await calculateTotalL1CalldataCostsInETHIfL1( + comparableTxnType, + transactionsPerDay, + maxChannelDuration + ) + if (dataAvailabilityType === "AltDA Plasma Mode") { + output = n37; + } else if (f35 === "EIP-4844") { + output = n36 + n38; + } else { + output = n39; + } + console.log("e119::", output) + return output +} // e119 + + +export const Total_Blobgas_Per_Blob = 131072; // N5 +export const Overhead_Blobgas_per_Blob = 1028; // N6 +export const L1_Gas_per_Blob_Commitment = 21000.0; // N7 +export const L1_Gas_Per_AltDA_Plasma_Mode_Commitment = 21532.0; // N8 +export const Max_No_Of_Blobs_Per_L1_Transaction = 5; // N9 +export const Avg_Compressed_Overhead_Bytes_Per_Blob = 406; // N10 +export const Avg_Compressed_Overhead_Gas_Per_Blob = 6385; // N11 +export const Avg_Total_Gas_Used_Per_L1_State_Proposal = 86847.5; // N12 +export const FastLZ_Intercept = -42585600; // N13 +export const FastLZ_Coefficient = 836500; // N14 +export const FatLZ_Min_Transaction_Size = 100; // N15 +export const Avg_Total_Gas_Used_Per_L1_Fault_Proof_State_Proposal = 420926.0; // N16 \ No newline at end of file diff --git a/utils/create-breadcrumbs.ts b/utils/create-breadcrumbs.ts new file mode 100644 index 000000000..370e44bc4 --- /dev/null +++ b/utils/create-breadcrumbs.ts @@ -0,0 +1,259 @@ +import * as fs from 'fs/promises'; +import * as path from 'path'; +import matter from 'gray-matter'; + +const rootDir: string = path.join(__dirname, '..', 'pages'); + +interface FileInfo { + title: string; + url: string; + description?: string; + content: string; +} + +// Pages to exclude +const excludedPages = [ + '400.mdx', + '500.mdx', + 'index.mdx', + '404.mdx', + '_app.tsx', + '_document.tsx', + '_meta.json' +]; + +function toTitleCase(str: string): string { + return str.split('-') + .map(word => word.charAt(0).toUpperCase() + word.slice(1).toLowerCase()) + .join(' '); +} + +function extractFirstParagraph(content: string): string { + // Remove frontmatter + content = content.replace(/^---[\s\S]*?---/, ''); + + // Remove import statements + content = content.replace(/^import[\s\S]*?\n/gm, ''); + + // Remove HTML/MDX tags + content = content.replace(/<[^>]+>/g, ' '); + + // Remove markdown links but keep text + content = content.replace(/\[([^\]]+)\]\([^)]+\)/g, '$1'); + + // Remove headers + content = content.replace(/^#.+$/gm, ''); + + const paragraphs = content.split(/\n\n+/); + const firstParagraph = paragraphs.find(p => { + const cleaned = p.trim(); + return cleaned.length > 30 && // Minimum length + !cleaned.startsWith('import') && + !cleaned.startsWith('export'); + }); + + if (firstParagraph) { + const cleaned = firstParagraph.replace(/\s+/g, ' ').trim(); + return cleaned.length > 150 ? cleaned.slice(0, 147) + '...' : cleaned; + } + + return ''; +} + +async function generateFolderDescription(folderName: string, files: FileInfo[]): Promise { + if (files.length === 0) { + return `Documentation for ${toTitleCase(folderName)} is coming soon.`; + } + + // Try to find overview or introduction file + const overviewFile = files.find(file => + file.url.toLowerCase().includes('overview') || + file.url.toLowerCase().includes('introduction') + ); + + if (overviewFile && overviewFile.content) { + const desc = extractFirstParagraph(overviewFile.content); + if (desc) return desc; + } + + // Generate description from files if no overview is found + const topics = files.map(file => toTitleCase(path.basename(file.url))).join(', '); + return `Documentation covering ${topics} in the ${toTitleCase(folderName)} section of the OP Stack ecosystem.`; +} + +async function getContentFiles(folderPath: string): Promise { + const files = await fs.readdir(folderPath, { withFileTypes: true }); + const fileInfos: FileInfo[] = []; + const folderName = path.basename(folderPath); + + for (const file of files) { + if (file.name.startsWith('_') || + file.name.startsWith('.') || + excludedPages.includes(file.name)) { + continue; + } + + const filePath = path.join(folderPath, file.name); + + if (file.isFile() && (file.name.endsWith('.md') || file.name.endsWith('.mdx'))) { + try { + const content = await fs.readFile(filePath, 'utf-8'); + const { data: frontMatter } = matter(content); + const fileName = path.basename(file.name, path.extname(file.name)); + const fileTitle = frontMatter.title || toTitleCase(fileName); + const relativeUrl = `/${path.relative(rootDir, filePath)}`.replace(/\.(md|mdx)$/, ''); + + fileInfos.push({ + title: fileTitle, + url: relativeUrl, + description: frontMatter.description, + content: content + }); + } catch (error) { + console.error(`Error processing file ${file.name}:`, error); + } + } + } + + return fileInfos; +} + +async function getExistingBreadcrumbContent(breadcrumbPath: string): Promise<{ + existingContent: string; + existingCards: Set; +} | null> { + try { + const content = await fs.readFile(breadcrumbPath, 'utf-8'); + const cardMatches = content.match(/]*href="([^"]+)"[^>]*>/g) || []; + const existingCards = new Set( + cardMatches.map(match => { + const hrefMatch = match.match(/href="([^"]+)"/); + return hrefMatch ? hrefMatch[1] : ''; + }).filter(Boolean) + ); + return { existingContent: content, existingCards }; + } catch (error) { + return null; + } +} + +async function createOrUpdateBreadcrumb(parentPath: string, folderName: string): Promise { + const folderPath = path.join(parentPath, folderName); + const breadcrumbPath = path.join(parentPath, `${folderName}.mdx`); + + // Get current files in the folder + const files = await getContentFiles(folderPath); + + // Check existing breadcrumb + const existing = await getExistingBreadcrumbContent(breadcrumbPath); + + if (existing) { + // If breadcrumb exists, only add new cards + const newCards: string[] = []; + let content = existing.existingContent; + + files.forEach(({ title: fileTitle, url }) => { + if (!existing.existingCards.has(url)) { + newCards.push(` `); + } + }); + + if (newCards.length > 0) { + // Find the closing tag and insert new cards before it + const cardsSectionEnd = content.lastIndexOf(''); + if (cardsSectionEnd !== -1) { + content = content.slice(0, cardsSectionEnd) + + '\n' + newCards.join('\n') + '\n' + + content.slice(cardsSectionEnd); + + await fs.writeFile(breadcrumbPath, content); + console.log(`Added ${newCards.length} new cards to: ${folderName}.mdx`); + } + } else { + console.log(`No new cards needed for: ${folderName}.mdx`); + } + } else { + // If breadcrumb doesn't exist, create new one + const title = toTitleCase(folderName); + const description = await generateFolderDescription(folderName, files); + + let content = `--- +title: ${title} +description: ${description} +lang: en-US +--- + +import { Card, Cards } from 'nextra/components' + +# ${title} + +${description} + +`; + + if (files.length > 0) { + content += '\n'; + files.forEach(({ title: fileTitle, url }) => { + content += ` \n`; + }); + content += ''; + } else { + content += 'Documentation for this section is coming soon.'; + } + + await fs.writeFile(breadcrumbPath, content); + console.log(`Created new breadcrumb file: ${folderName}.mdx`); + } +} + +async function processSubfolders(parentPath: string): Promise { + try { + const entries = await fs.readdir(parentPath, { withFileTypes: true }); + + for (const entry of entries) { + if (!entry.isDirectory() || entry.name.startsWith('_')) { + continue; + } + + const folderName = entry.name; + console.log(`Processing folder: ${folderName}`); + + try { + await createOrUpdateBreadcrumb(parentPath, folderName); + } catch (error) { + console.error(`Error processing breadcrumb for ${folderName}:`, error); + } + } + } catch (error) { + console.error('Error processing folders:', error); + } +} + +const main = async (): Promise => { + console.log('Starting breadcrumb update process...'); + console.log('Root directory:', rootDir); + + try { + // Process main sections: builders, chain, connect, stack + const mainSections = ['builders', 'chain', 'connect', 'stack']; + for (const section of mainSections) { + const sectionPath = path.join(rootDir, section); + try { + await fs.access(sectionPath); + await processSubfolders(sectionPath); + console.log(`Completed processing ${section} section`); + } catch (error) { + console.log(`Skipping ${section} - directory not found`); + } + } + console.log('Finished updating all breadcrumbs.'); + } catch (error) { + console.error('Error in main process:', error); + process.exit(1); + } +}; + +main().catch(error => { + console.error('Error in main process:', error); + process.exit(1); +}); \ No newline at end of file diff --git a/utils/fix-redirects.ts b/utils/fix-redirects.ts new file mode 100644 index 000000000..5d609c20b --- /dev/null +++ b/utils/fix-redirects.ts @@ -0,0 +1,126 @@ +import * as fs from 'fs/promises'; +import * as path from 'path'; + +const rootDir = path.join(process.cwd(), 'pages'); +const redirectsPath = path.join(process.cwd(), 'public', '_redirects'); +const updates: string[] = []; + +// ANSI color codes +const WHITE = '\x1b[37m'; +const GREEN = '\x1b[32m'; +const YELLOW = '\x1b[33m'; +const RESET = '\x1b[0m'; +const BOLD = '\x1b[1m'; + +interface Redirect { + from: string; + to: string; +} + +interface Summary { + total: number; + fixed: number; + skipped: number; +} + +async function getRedirects(): Promise { + const content = await fs.readFile(redirectsPath, 'utf-8'); + return content.split('\n') + .filter(line => line.trim() && !line.startsWith('#')) + .map(line => { + const [from, to] = line.split(/\s+/); + return { from, to }; + }); +} + +async function findMdxFiles(dir: string): Promise { + const files: string[] = []; + const entries = await fs.readdir(dir, { withFileTypes: true }); + + for (const entry of entries) { + const fullPath = path.join(dir, entry.name); + if (entry.isDirectory() && !entry.name.startsWith('_')) { + files.push(...await findMdxFiles(fullPath)); + } else if (entry.isFile() && /\.(md|mdx)$/.test(entry.name)) { + files.push(fullPath); + } + } + return files; +} + +async function fixFile(filePath: string, redirects: Redirect[]): Promise { + let content = await fs.readFile(filePath, 'utf-8'); + let hasChanges = false; + const relativeFilePath = path.relative(rootDir, filePath); + + redirects.forEach(redirect => { + const markdownRegex = new RegExp(`\\[([^\\]]+)\\]\\(${redirect.from}\\)`, 'g'); + const hrefRegex = new RegExp(`href="${redirect.from}"`, 'g'); + + if (content.match(markdownRegex) || content.match(hrefRegex)) { + content = content + .replace(markdownRegex, `[$1](${redirect.to})`) + .replace(hrefRegex, `href="${redirect.to}"`); + + updates.push(`${WHITE}Fixed in "${relativeFilePath}": ${YELLOW}${redirect.from}${WHITE} β†’ ${GREEN}${redirect.to}${RESET}`); + hasChanges = true; + } + }); + + if (hasChanges) { + await fs.writeFile(filePath, content); + } + + return hasChanges; +} + +function printSummary(summary: Summary) { + console.log('\nSummary:'); + console.log(`${WHITE}Total files πŸ” - ${summary.total}`); + console.log(`${GREEN}Files fixed βœ… - ${summary.fixed}`); + console.log(`${WHITE}Files skipped ⏭️ - ${summary.skipped}${RESET}`); +} + +async function main() { + const summary: Summary = { + total: 0, + fixed: 0, + skipped: 0 + }; + + console.log('Starting to fix redirect links...'); + console.log('Root directory:', rootDir); + + try { + const redirects = await getRedirects(); + const files = await findMdxFiles(rootDir); + + summary.total = files.length; + + for (const file of files) { + const wasFixed = await fixFile(file, redirects); + if (wasFixed) { + summary.fixed++; + } else { + summary.skipped++; + } + } + + if (updates.length > 0) { + console.log(`${GREEN}${BOLD}Fixed links:${RESET}`); + updates.forEach(update => console.log(update)); + printSummary(summary); + } else { + console.log(`${GREEN}No broken links found. Everything is up to date.${RESET}`); + printSummary(summary); + } + } catch (error) { + console.error(`${YELLOW}${BOLD}Error fixing redirects:${RESET}`, error); + process.exit(1); + } +} + +main().catch(error => { + console.error(`${YELLOW}${BOLD}Error in main process:${RESET}`, error); + process.exit(1); +}); \ No newline at end of file diff --git a/utils/redirects.ts b/utils/redirects.ts new file mode 100644 index 000000000..bd2cb66b1 --- /dev/null +++ b/utils/redirects.ts @@ -0,0 +1,135 @@ +import * as fs from 'fs/promises'; +import * as path from 'path'; + +const rootDir = path.join(process.cwd(), 'pages'); +const redirectsPath = path.join(process.cwd(), 'public', '_redirects'); +const warnings: string[] = []; + +// ANSI color codes +const WHITE = '\x1b[37m'; +const GREEN = '\x1b[32m'; +const YELLOW = '\x1b[33m'; +const RESET = '\x1b[0m'; +const BOLD = '\x1b[1m'; + +interface Redirect { + from: string; + to: string; +} + +interface Summary { + total: number; + ok: number; + errors: number; +} + +function formatWarning(filePath: string, fromLink: string, toLink: string): string { + return `${WHITE}File "${filePath}" contains outdated link ${YELLOW}"${fromLink}"${WHITE} - should be updated to ${GREEN}"${toLink}"${RESET}`; +} + +async function getRedirects(): Promise { + const content = await fs.readFile(redirectsPath, 'utf-8'); + return content.split('\n') + .filter(line => line.trim() && !line.startsWith('#')) + .map(line => { + const [from, to] = line.split(/\s+/); + return { from, to }; + }); +} + +async function findMdxFiles(dir: string): Promise { + const files: string[] = []; + const entries = await fs.readdir(dir, { withFileTypes: true }); + + for (const entry of entries) { + const fullPath = path.join(dir, entry.name); + if (entry.isDirectory() && !entry.name.startsWith('_')) { + files.push(...await findMdxFiles(fullPath)); + } else if (entry.isFile() && /\.(md|mdx)$/.test(entry.name)) { + files.push(fullPath); + } + } + return files; +} + +function extractLinks(content: string): string[] { + const markdownLinkRegex = /\[([^\]]+)\]\(([^)]+)\)/g; + const hrefRegex = /href="([^"]+)"/g; + const links: string[] = []; + + let match; + while ((match = markdownLinkRegex.exec(content)) !== null) { + if (!match[2].startsWith('http')) { + links.push(match[2]); + } + } + while ((match = hrefRegex.exec(content)) !== null) { + if (!match[1].startsWith('http')) { + links.push(match[1]); + } + } + return links; +} + +async function checkFile(filePath: string, redirects: Redirect[]): Promise { + const content = await fs.readFile(filePath, 'utf-8'); + const links = extractLinks(content); + const relativeFilePath = path.relative(rootDir, filePath); + + links.forEach(link => { + const redirect = redirects.find(r => r.from === link); + if (redirect) { + warnings.push(formatWarning(relativeFilePath, link, redirect.to)); + } + }); +} + +function printSummary(summary: Summary) { + console.log('\nSummary:'); + console.log(`${WHITE}Total pages πŸ” - ${summary.total}`); + console.log(`${YELLOW}Pages broken 🚫 - ${summary.errors}`); + console.log(`${GREEN}Pages OK βœ… - ${summary.ok}${RESET}`); +} + +async function main() { + const summary: Summary = { + total: 0, + ok: 0, + errors: 0 + }; + + console.log('Starting redirect link check...'); + console.log('Root directory:', rootDir); + + try { + const redirects = await getRedirects(); + const files = await findMdxFiles(rootDir); + + summary.total = files.length; + + for (const file of files) { + await checkFile(file, redirects); + } + + summary.errors = warnings.length; + summary.ok = summary.total - summary.errors; + + if (warnings.length > 0) { + console.log(`${YELLOW}${BOLD}Links that need updating:${RESET}`); + warnings.forEach(warning => console.log(warning)); + printSummary(summary); + process.exit(1); + } else { + console.log(`${GREEN}All internal links are up to date.${RESET}`); + printSummary(summary); + } + } catch (error) { + console.error(`${YELLOW}${BOLD}Error checking redirects:${RESET}`, error); + process.exit(1); + } +} + +main().catch(error => { + console.error(`${YELLOW}${BOLD}Error in main process:${RESET}`, error); + process.exit(1); +}); \ No newline at end of file diff --git a/utils/transaction-types.ts b/utils/transaction-types.ts new file mode 100644 index 000000000..70f154ad6 --- /dev/null +++ b/utils/transaction-types.ts @@ -0,0 +1,50 @@ +export const transactionTypes = { + "General OP Mainnet": { + TransactionsPerDay: 489109, + AvgCalldataBytesPerTx: 1007.8, + AvgEstimatedSizePerTx: 474.6, + AvgBlobgasPerL2Tx: 361.6153521, + EstimatedSizeBlobgasRatio: 1.313, + EstimatedSizeCalldataGasRatio: 21.0, + }, + Base: { + TransactionsPerDay: 3227633, + AvgCalldataBytesPerTx: 632.3006064, + AvgEstimatedSizePerTx: 368.6, + AvgBlobgasPerL2Tx: 168.0497343, + EstimatedSizeBlobgasRatio: 2.193, + EstimatedSizeCalldataGasRatio: 35.09, + }, + Mode: { + TransactionsPerDay: 123889, + AvgCalldataBytesPerTx: 131.8318268, + AvgEstimatedSizePerTx: 144.3, + AvgBlobgasPerL2Tx: 102.9448416, + EstimatedSizeBlobgasRatio: 1.402, + EstimatedSizeCalldataGasRatio: 22.43, + }, + Zora: { + TransactionsPerDay: 126719, + AvgCalldataBytesPerTx: 318.8965479, + AvgEstimatedSizePerTx: 174.6, + AvgBlobgasPerL2Tx: 121.6317714, + EstimatedSizeBlobgasRatio: 1.435, + EstimatedSizeCalldataGasRatio: 22.96, + }, + Mint: { + TransactionsPerDay: 6341, + AvgCalldataBytesPerTx: 274.5535557, + AvgEstimatedSizePerTx: 206.9, + AvgBlobgasPerL2Tx: 317.11, + EstimatedSizeBlobgasRatio: 0.65, + EstimatedSizeCalldataGasRatio: 10.44, + }, + Metal: { + TransactionsPerDay: 430, + AvgCalldataBytesPerTx: 296.1833811, + AvgEstimatedSizePerTx: 237.2, + AvgBlobgasPerL2Tx: 947549.16, + EstimatedSizeBlobgasRatio: 0.0, + EstimatedSizeCalldataGasRatio: 0.0, + }, +}; diff --git a/words.txt b/words.txt index 90467007b..98b6c5e71 100644 --- a/words.txt +++ b/words.txt @@ -15,16 +15,18 @@ Arweave authrpc Badgeholder's Badgeholders +badgeholders basefee BGEZ BGTZ Biconomy birthdate BLEZ -BLOBBASEFEE BLOBPOOL blobpool blobspace +Blockdaemon +Blockdaemon's blockhash blocklists BLOCKLOGS @@ -37,7 +39,6 @@ blocktime BLOOMFILTER bloomfilter BLTZ -Bluesweep Bootcamp BOOTNODES Bootnodes @@ -64,17 +65,19 @@ computependingblock confs corsdomain counterfactually +Crosschain +crosschain Crossmint daserver DATACAP datacap DATADIR datadir -Dencun -derviation Devnet devnet +devnets Devnode +devx direnv DISABLETXPOOLGOSSIP disabletxpoolgossip @@ -82,6 +85,8 @@ Discv discv DIVU Drand +dripcheck +Drippie Eigen ENABLEDEPRECATEDPERSONAL enabledeprecatedpersonal @@ -95,15 +100,19 @@ ETHSTATS ethstats EVMTIMEOUT evmtimeout +executability +exfiltrate EXITWHENSYNCED exitwhensynced EXTRADATA extradata Farcaster farcaster +Faultproof FDLIMIT fdlimit featureset +Flashbots forkable forkchoice FPVM @@ -136,6 +145,7 @@ historicalrpctimeout HOLESKY Holesky holesky +IERC IGNOREPRICE ignoreprice implicity @@ -143,7 +153,7 @@ Inator inator INFLUXDBV influxdbv -initcode +interchain IPCDISABLE ipcdisable ipcfile @@ -162,7 +172,6 @@ leveldb lightkdf logfile logfmt -marketshare MAXAGE maxage MAXBACKUPS @@ -173,7 +182,6 @@ MAXPENDPEERS maxpendpeers MAXPRICE maxprice -MCOPY MEMPROFILERATE memprofilerate Merkle @@ -187,6 +195,7 @@ minsuggestedpriorityfee Mintable Mintplex MIPSEVM +Monitorism Moralis Mordor mountpoint @@ -196,6 +205,7 @@ MTHI MTLO MULT multiaddr +multichain multiclient multisigs MULTU @@ -227,9 +237,12 @@ nosyncserve Numba Offchain offchain +OPCM +opcm Openfort oplabs opnode's +opstack Opti pausable pcscdpath @@ -249,6 +262,7 @@ POAPs PPROF pprof preconfigured +Predeploy predeploy Predeployed predeployed @@ -272,6 +286,7 @@ productionize productionized Protip Proxied +Proxyd proxyd pseudorandomly QRNG @@ -279,6 +294,7 @@ Quicknode quicknode quickstarts RANDAO +rebalance Regenesis regenesis REJOURNAL @@ -286,10 +302,10 @@ rejournal REMOTEDB remotedb replayability -reproven +replayor REQUIREDBLOCKS requiredblocks -Rollouts +rollouts Rollups rollups Routescan @@ -300,15 +316,15 @@ rpcs RPGF Rpgf rpgf +Runbooks +runbooks RWAs +safedb Schnorr -secp -SELFDESTRUCT seqnr SEQUENCERHTTP sequencerhttp serv -Shapella signup SLLV SLTI @@ -329,12 +345,17 @@ subcomponents subgame subheaders SUBU +Sunnyside SUPERCHAIN Superchain superchain Superchain's +Superchainerc +superchainerc Superchains Superscan +Supersim +supersim SYNCMODE syncmode SYNCTARGET @@ -345,13 +366,15 @@ Thirdweb threadcreate tility timeseries -Tranfer trustlessly trustrpc txfeecap txmgr +txns TXPOOL txpool +txproxy +txproxyd uncountered Unprotect unsubmitted @@ -362,15 +385,25 @@ VHOSTS vhosts Viem viem +Viem's VMDEBUG vmdebug VMODULE vmodule -wagmi Warpcast +xlarge XORI xtensibility ZKPs ZKVM Zora zora +Sepolia +voxel +SEPOLIA +sepolia +Pyth +Pyth's +Ankr +Mitigations +Immunefi