From 71c6ce64cc4b3ba5f1df6d48e9d6e69cfd0b7347 Mon Sep 17 00:00:00 2001 From: krofax Date: Fri, 10 Jan 2025 16:22:58 +0100 Subject: [PATCH 01/10] updating EAS contracts --- pages/stack/smart-contracts.mdx | 123 ++++++++++++++++++++------------ public/_redirects | 3 +- 2 files changed, 80 insertions(+), 46 deletions(-) diff --git a/pages/stack/smart-contracts.mdx b/pages/stack/smart-contracts.mdx index 07b18dd2b..cb1f30f2b 100644 --- a/pages/stack/smart-contracts.mdx +++ b/pages/stack/smart-contracts.mdx @@ -66,7 +66,6 @@ The upgrade was coupled with the [Granite network upgrade](/builders/node-operat * 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 @@ -74,18 +73,18 @@ The upgrade was coupled with the [Granite network upgrade](/builders/node-operat The Safe Extensions protocol upgrade is intended to increase the security and decentralization of the Superchain by: -1. Increasing the Security Council Safe's signing threshold, from 4 to 10, out -of 13 owners. This meets the 75% threshold requirement for a Stage 1 rollup -outlined in [L2Beat's Stages framework](https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52) -2. Reassigning the role of Guardian from the Foundation to a new Guardian Safe -with the Security Council Safe as its sole owner. This moves the Superchain -closer to satisfying the 1 week exit window 5 requirement for Stage 1. - * Additionally the Foundation is appointed to the new DeputyGuardian role - which is able to act as Guardian through the Guardian Safe. This +1. Increasing the Security Council Safe's signing threshold, from 4 to 10, out + of 13 owners. This meets the 75% threshold requirement for a Stage 1 rollup + outlined in [L2Beat's Stages framework](https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52) +2. Reassigning the role of Guardian from the Foundation to a new Guardian Safe + with the Security Council Safe as its sole owner. This moves the Superchain + closer to satisfying the 1 week exit window 5 requirement for Stage 1. + * Additionally the Foundation is appointed to the new DeputyGuardian role + which is able to act as Guardian through the Guardian Safe. This appointment can be revoked by the Security Council Safe at any time. -3. Reassigning the owner of the L2ProxyAdmin contract from the Foundation to -the Security Council. This ensures the Security Council Safe has a blocking -vote for L2 predeploy upgrades and is a requirement for Stage 1. +3. Reassigning the owner of the L2ProxyAdmin contract from the Foundation to + the Security Council. This ensures the Security Council Safe has a blocking + vote for L2 predeploy upgrades and is a requirement for Stage 1. * [Official - Safe Extensions Release](https://github.com/ethereum-optimism/optimism/releases/tag/op-contracts%2Fv1.5.0) * [Governance Post](https://gov.optimism.io/t/final-protocol-upgrade-8-guardian-security-council-threshold-and-l2-proxyadmin-ownership-changes-for-stage-1-decentralization/8157) @@ -116,7 +115,6 @@ vote for L2 predeploy upgrades and is a requirement for Stage 1. * PreimageOracle: [1.0.0](https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.4.0/packages/contracts-bedrock/src/cannon/PreimageOracle.sol#L33) * 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.4.0 - Fault proofs @@ -303,16 +301,16 @@ and most importantly making the stack modular. ### L1 Contract Details -#### AddressManager +#### AddressManager -`AddressManager` is a legacy contract that was used in the old version of the +`AddressManager` is a legacy contract that was used in the old version of the Optimism system to manage a registry of string names to addresses. We now use a more standard proxy system for most contracts, but this contract is still used for the L1CrossDomainMessenger, via ResolvedDelegateProxy #### SuperchainConfig -The `SuperchainConfig` contract is used to manage configuration of global +The `SuperchainConfig` contract is used to manage configuration of global superchain values. It has the ability to pause and unpause all withdrawals in the Superchain. @@ -338,7 +336,7 @@ contract acts as an escrow for ERC721 tokens deposited into L2. The `L1StandardBridge` is responsible for transferring ETH and ERC20 tokens between L1 and L2. In the case that an ERC20 token is native to L1, it will be escrowed within this -contract. If the ERC20 token is native to L2, it will be burnt. +contract. If the ERC20 token is native to L2, it will be burnt. #### OptimismPortal @@ -348,53 +346,53 @@ Users are encouraged to use the `L1CrossDomainMessenger` for a higher-level inte #### ProtocolVersions -The `ProtocolVersions` contract is used to manage Superchain protocol version +The `ProtocolVersions` contract is used to manage Superchain protocol version information. It exposes a recommended and required version for node operators. -The recommended/required versions are changed with each hard fork. Nodes can +The recommended/required versions are changed with each hard fork. Nodes can optionally halt if using the wrong version. #### SystemConfig -The `SystemConfig` contract is helps manage configuration of an OP Stack -network. Much of the network's configuration is stored on L1 and picked up by -L2 as part of the derivation of the L2 chain. The contract also contains +The `SystemConfig` contract is helps manage configuration of an OP Stack +network. Much of the network's configuration is stored on L1 and picked up by +L2 as part of the derivation of the L2 chain. The contract also contains references to all other contract addresses for the chain. #### DisputeGameFactory -The `DisputeGameFactory` contract generates `FaultDisputeGame` contract +The `DisputeGameFactory` contract generates `FaultDisputeGame` contract instances. -#### FaultDisputeGame +#### FaultDisputeGame -The `FaultDisputeGame` contract is deployed by the `DisputeGameFactory`. Each -deployed instance of the contract acts as a host to a proposal about the state +The `FaultDisputeGame` contract is deployed by the `DisputeGameFactory`. Each +deployed instance of the contract acts as a host to a proposal about the state of the OP Stack chain at a given block number. #### PermissionedDisputeGame -The `Guardian` can also choose to revert to a `PermissionedDisputeGame` +The `Guardian` can also choose to revert to a `PermissionedDisputeGame` contract that only allows specific roles to submit and challenge proposals. #### AnchorStateRegistry -The `AnchorStateRegistry` is a contract that stores the latest "anchor" state -for each available `FaultDisputeGame` type. The anchor state is the latest -state that has been proposed on L1 and was not challenged within the challenge +The `AnchorStateRegistry` is a contract that stores the latest "anchor" state +for each available `FaultDisputeGame` type. The anchor state is the latest +state that has been proposed on L1 and was not challenged within the challenge period. By using stored anchor states, new `FaultDisputeGame` instances can -be initialized with a more recent starting state which reduces the amount of +be initialized with a more recent starting state which reduces the amount of required offchain computation. #### DelayedWETH -The `DelayedWETH` contract has been set up to hold the bonds and only allow -payouts after a delay, so that bonds can be redirected towards the correct +The `DelayedWETH` contract 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. -#### MIPS +#### MIPS -The `MIPS` smart contract is an onchain implementation of a virtual machine -(VM) that encompasses the 32-bit, Big-Endian, MIPS III Instruction Set +The `MIPS` smart contract is an onchain implementation of a virtual machine +(VM) that encompasses the 32-bit, Big-Endian, MIPS III Instruction Set Architecture (ISA). #### PreimageOracle @@ -484,10 +482,10 @@ user is depositing from L1 to L2 or withdrawing from L2 to L1. ### GasPriceOracle The `GasPriceOracle` is no longer a permissioned contract like in the legacy -system. It only exists to preserve the API for offchain gas estimation. The -function `getL1Fee(bytes)` accepts an unsigned RLP transaction and will return -the L1 portion of the fee. This fee pays for using L1 as a data availability -layer and should be added to the L2 portion of the fee, which pays for +system. It only exists to preserve the API for offchain gas estimation. The +function `getL1Fee(bytes)` accepts an unsigned RLP transaction and will return +the L1 portion of the fee. This fee pays for using L1 as a data availability +layer and should be added to the L2 portion of the fee, which pays for execution, to compute the total transaction fee. Following the Ecotone upgrade, the values used for L1 fee computation are: @@ -606,15 +604,18 @@ withdrawn to an immutable address on L1. ### SchemaRegistry -The `SchemaRegistry` predeploy implements the global attestation schemas for -the Ethereum Attestation Service protocol. +The `SchemaRegistry` predeploy implements the global attestation schemas for the Ethereum Attestation Service protocol. * **Address:** `0x4200000000000000000000000000000000000020` * **Introduced:** Bedrock * **Deprecated:** no * **Proxied:** yes -### EAS +The SchemaRegistry works alongside the Ethereum Attestation Service (EAS) to enable attestations. See [Build Decentralized Identity Apps with Attestations](about-attestations) for more details on schemas and usage. + +### EAS (Ethereum Attestation Service) + +The [Ethereum Attestation Service (EAS)](https://attest.sh/) is an open-source public good included as a predeploy in the OP Stack. It allows developers to issue and manage attestations on-chain, supporting use cases such as decentralized identity and other data integrity scenarios. The `EAS` predeploy implements the Ethereum Attestation Service protocol. @@ -623,6 +624,39 @@ The `EAS` predeploy implements the Ethereum Attestation Service protocol. * **Deprecated:** no * **Proxied:** yes +### Contract addresses + +EAS contracts are deployed on these networks: + +| Network | Attestation Contract | Schema Registry Contract | +| ---------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | +| 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 use EAS + +You can interact with the Ethereum Attestation Service in several ways: + +1. **Using the EAS Scan UI:** + * [EAS Scan for OP Mainnet](https://optimism.easscan.org/) + * [EAS Scan for OP Sepolia](https://optimism-sepolia.easscan.org/) + +2. **Using the JavaScript SDK:** + * [EAS SDK Documentation](https://docs.attest.sh/docs/developer-tools/eas-sdk) + +3. **Access Directly Onchain:** + * See the [EAS Smart Contract Implementation](https://github.com/ethereum-attestation-service/eas-contracts/blob/master/contracts/EAS.sol). + +### Indexing Attestations + +Attestations made via EAS can be indexed through the following tools: + +* [GraphQL Endpoint](https://docs.attest.sh/docs/developer-tools/api) +* [Ponder Graph](https://github.com/ethereum-attestation-service/eas-ponder-graph) +* [Open Source Indexer](https://github.com/ethereum-attestation-service/eas-indexing-service) + +For more information on working with attestations, see [Build Decentralized Identity Apps with Attestations](about-attestations). + ### BeaconBlockRoot The `BeaconBlockRoot` predeploy provides access to the L1 beacon block roots. @@ -634,8 +668,7 @@ This was added during the Ecotone network upgrade and is specified in * **Deprecated:** no * **Proxied:** no -### DEPRECATED Contracts - +### DEPRECATED Contracts #### DEPRECATED - LegacyMessagePasser diff --git a/public/_redirects b/public/_redirects index 753e33de4..eb5db867a 100644 --- a/public/_redirects +++ b/public/_redirects @@ -117,4 +117,5 @@ /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 -/stack/explainer /superchain/superchain-explainer \ No newline at end of file +/stack/explainer /superchain/superchain-explainer +/chain/identity/contracts-eas /stack/smart-contracts#eas-ethereum-attestation-service \ No newline at end of file From b18cf994a3f4ac074b936443167cab9c2ac05cc1 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 15 Jan 2025 16:24:47 +0100 Subject: [PATCH 02/10] Add redirections for redirects --- public/_redirects | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/public/_redirects b/public/_redirects index eb5db867a..1062ad0ed 100644 --- a/public/_redirects +++ b/public/_redirects @@ -118,4 +118,12 @@ /builders/app-developers/contracts/superchain-erc20 /stack/interop/assets/superchain-erc20 /builders/chain-operators/tutorials/sdk /builders/app-developers/overview /stack/explainer /superchain/superchain-explainer -/chain/identity/contracts-eas /stack/smart-contracts#eas-ethereum-attestation-service \ No newline at end of file +/chain/identity/contracts-eas /stack/smart-contracts#eas-ethereum-attestation-service +/chain/identity/about-attestations https://community.optimism.io/identity/about-attestations +/chain/identity/applications https://community.optimism.io/identity/applications +/chain/identity/contracts-eas https://community.optimism.io/identity/contracts-eas +/chain/identity/individuals https://community.optimism.io/identity/individuals +/chain/identity/organizations https://community.optimism.io/identity/organizations +/chain/identity/overview https://community.optimism.io/identity/overview +/chain/identity/projects https://community.optimism.io/identity/projects +/chain/identity/schemas https://community.optimism.io/identity/schemas From 2cc8f9c533a0351780f121b17d569d2d5b907b3e Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 15 Jan 2025 16:34:48 +0100 Subject: [PATCH 03/10] Remove identity files --- pages/chain/identity.mdx | 29 --- pages/chain/identity/_meta.json | 9 - pages/chain/identity/about-attestations.mdx | 63 ------ pages/chain/identity/applications.mdx | 23 -- pages/chain/identity/contracts-eas.mdx | 40 ---- pages/chain/identity/individuals.mdx | 30 --- pages/chain/identity/organizations.mdx | 15 -- pages/chain/identity/overview.mdx | 47 ---- pages/chain/identity/projects.mdx | 25 --- pages/chain/identity/schemas.mdx | 236 -------------------- 10 files changed, 517 deletions(-) delete mode 100644 pages/chain/identity.mdx delete mode 100644 pages/chain/identity/_meta.json delete mode 100644 pages/chain/identity/about-attestations.mdx delete mode 100644 pages/chain/identity/applications.mdx delete mode 100644 pages/chain/identity/contracts-eas.mdx delete mode 100644 pages/chain/identity/individuals.mdx delete mode 100644 pages/chain/identity/organizations.mdx delete mode 100644 pages/chain/identity/overview.mdx delete mode 100644 pages/chain/identity/projects.mdx delete mode 100644 pages/chain/identity/schemas.mdx diff --git a/pages/chain/identity.mdx b/pages/chain/identity.mdx deleted file mode 100644 index 87c4b79e5..000000000 --- a/pages/chain/identity.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -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 deleted file mode 100644 index 8fb1817c3..000000000 --- a/pages/chain/identity/_meta.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "overview": "Overview", - "about-attestations": "About attestations", - "contracts-eas": "Contracts (EAS)", - "schemas": "Schemas", - "applications": "Apps", - "organizations": "Organization", - "projects": "Projects" -} \ No newline at end of file diff --git a/pages/chain/identity/about-attestations.mdx b/pages/chain/identity/about-attestations.mdx deleted file mode 100644 index 4c2bdfbba..000000000 --- a/pages/chain/identity/about-attestations.mdx +++ /dev/null @@ -1,63 +0,0 @@ ---- -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 - -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 - -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. - -Our journey towards decentralized identity begins with the [Ethereum Attestation Service](https://optimism.easscan.org), a set of smart contracts for creating, verifying, and revoking on/off-chain attestations. -You can think of Ethereum Attestation Service as a multiplayer database for streamlining the attestation process and enabling a robust web of trust on any OP Chain in the Superchain. - -![attestation logo.](/img/op-mainnet/identity/atst-logo.png) - -## Benefits of using Ethereum attestation service - -EAS makes it easy to sign any piece of data. In addition, here are a few key benefits: - -* **Permissionless**: The AttestationStation is a public contract, which means that it is not owned or controlled by any one person or organization. Anyone can use the contract to verify and attest anything. -* **Tooling:** Indexing, various access-management integrations, and more are already available for the AttestationStation. - -## Privacy - -Attestations create log entries that become part of the permanent record of the blockchain. -Here are some best practices to avoid violating users' privacy: - -* Obtain explicit consent from users for [personal information](https://csrc.nist.gov/glossary/term/PII), which includes a user's legal name and birthdate. - Clearly [inform users](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/personal-information-what-is-it/what-is-personal-information-a-guide/) what data is being collected, why it is being collected, and how it will be used. -* Sensitive data should not be stored onchain, in any way. - If you need a smart contract to verify it in the future, you can use the hash of the sensitive data rather than the data itself. -* Even when storing sensitive data offchain, you need to ensure it is stored securely using encryption, proper authentication and authorization, etc. - - - You are encouraged to consult a lawyer or other professional advisors if you are uncertain about your obligations. - 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 - -**Q: Are attestations replacements for verifiable credentials?** - -**A:** Attestations should not be viewed as a replacement for verifiable credentials or decentralized identifiers. Rather developers can use attestations to create [decentralized identifiers](https://www.w3.org/TR/did-core/), credentials, claims, and more. - -**Q: Are attestations replacements for proof of personhood?** - -**A:** Attestations and the associated web of trust are complementary with proof of personhood like [WorldID](https://worldcoin.org/blog/announcements/worldcoin-commits-optimism-superchain-vision-ahead-mainnet-launch) and similar solutions. Without proof of personhood, agents could sybil-attack the web of trust to build their reputation. On the other hand, web of trust extends proof of personhood to confer more information about the person you're interacting with which is critical in governance and other use-cases that require knowledge of the person's reputation. - -**Q: Why attestations instead of soulbound / non-transferable tokens?** - -**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 - -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 deleted file mode 100644 index 7375f3a4b..000000000 --- a/pages/chain/identity/applications.mdx +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Attestation Apps -lang: en-US -description: Learn some of the applications that use attestations. ---- - -# Attestation apps - -This guide lists some of the applications that use attestations. - -## Ethereum attestation service - -These are some of the applications that use the attestations: - -* [EAS Scan](https://optimism.easscan.org/): This no-code interface lets you build schemas, query, and submit attestations. -* [Citizen Attestations](https://citizen-attestations.xyz/): An attestation explorer for Optimism focusing on attestations that are relevant for the OP Citizens eligibility process. -* [Attest Fest](https://attest-fest.party/): Create multiple EAS attestations using the power of CSV and Safe multisig wallets. It's an attest fest, yay! -* [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 - -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 deleted file mode 100644 index 9c6498d4d..000000000 --- a/pages/chain/identity/contracts-eas.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Contracts (EAS) -lang: en-US -description: Learn the basics of contracts for EAS, EAS contract addresses, and how to read and write attestations. ---- - -# 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 - -The [Ethereum Attestation Service](https://docs.attest.sh/docs/welcome) is deployed on these addresses: - -| Network | Attestation Contract | Schema Registry Contract | -| ---------- | -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -| 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 - -You can read and write attestations in several ways: - -* [EAS scan user interface (OP Mainnet)](https://optimism.easscan.org/) -* [EAS scan user interface (OP Sepolia)](https://optimism-sepolia.easscan.org/) -* [JavaScript SDK](https://docs.attest.sh/docs/developer-tools/eas-sdk) -* [Access directly onchain](https://github.com/ethereum-attestation-service/eas-contracts/blob/master/contracts/EAS.sol) (if you need to attest from a smart contract) - -## Indexing - -Indexing is available via: - -* [GraphQL endpoint](https://docs.attest.sh/docs/developer-tools/api) -* [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 - -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 deleted file mode 100644 index b7b234e86..000000000 --- a/pages/chain/identity/individuals.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Individual identity -lang: en-US -description: Learn about how individual identity is represented in the Optimism Collective. ---- - -## 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 - -To obtain a unique identifier: - -1. Use the **[Farcaster Id Gateway](https://docs.farcaster.xyz/reference/contracts/reference/id-gateway)** -2. Use the Warpcast app, which: - -* Creates a new custody address -* Acts as a wallet - -### Making attestations - -When you make attestations about individuals: - -* Leave the recipient address blank -* Enter the users id into the attestation metadata - -### Further reading - -For more details on individual identity in the Optimism Collective, refer to **[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/organizations.mdx b/pages/chain/identity/organizations.mdx deleted file mode 100644 index 558e73de0..000000000 --- a/pages/chain/identity/organizations.mdx +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Organizations -lang: en-US -description: Learn about the organization entity within the Optimism Collective's identity stack. ---- - -## Organizations - -Within the Optimism Collective, the organization entity is used to represent teams, squads, DAOs and other organizations that may work on multiple projects. Organizations can apply to Retroactive Public Goods Funding (Retro Funding) with specific [projects](https://docs.optimism.io/chain/identity/projects), never with just the organization. This is because projects represent contributions that created impact in the Collective, and Retro Rounds award OP to past impact. - -The organization entity is represented onchain by an attestation. The attestation UID is the organization's unique identifier for its lifecycle in the Collective. To create a new organization, an attestation is issued using [this schema](https://optimism.easscan.org/schema/view/0xff0b916851c1c5507406cfcaa60e5d549c91b7f642eb74e33b88143cae4b47d0). The only metadata included in the schema is the Farcaster Id of the person who created the organization, and the entity type (in this case "organization"). - -All other organization metadata is stored or referenced in the [Organization Metadata Attestation](https://optimism.easscan.org/schema/view/0xc2b376d1a140287b1fa1519747baae1317cf37e0d27289b86f85aa7cebfd649f). The Organization Metadata Attestation is re-issued anytime there is a change in metadata. Apps displaying organization metadata should look to the most recent attestation for the up-to-date metadata. - -See the [attestation schemas page](https://docs.optimism.io/chain/identity/schemas) for more details on the schemas and their metadata. diff --git a/pages/chain/identity/overview.mdx b/pages/chain/identity/overview.mdx deleted file mode 100644 index efa96fd28..000000000 --- a/pages/chain/identity/overview.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Identity overview -lang: en-US -description: Learn about the basics of decentralized identity solutions. ---- - -import { Callout } from 'nextra/components' - -# Introduction - -This guide explains the role of decentralized identity in the Optimism Collective and its key components. - - -## Identity in the Optimism Collective - -Decentralized identity solutions empower individuals to customize their identity according to their preferences, move it seamlessly across services, and regain control of their personal information from centralized platforms. These solutions are designed to enable users to prove specific attributes about themselves in a trustworthy and verifiable way, without compromising their privacy or security. - -The Optimism Collective is [building a better economic engine that fuels positive-sum games](https://www.optimism.io/vision). Decentralized identity is central to that mission. For example, the two-house governance system of the Optimism Collective consists of: - -1. Token holders, who vote by delegating their OP tokens to delegates. -2. Community members who participate in a one-person-one-vote system based on reputation and community contributions. - -Decentralized identity expands the design space for innovation. It aims to give individuals greater control over their finances and easier participation in the global economy on their own terms. - -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 - -There are three important components to identity within the Optimism Collective: - -1. [Individuals](https://community.optimism.io/docs/identity/project-and-individual-identity-in-the-collective/#people-and-projects) -2. [Projects](https://community.optimism.io/docs/identity/project-and-individual-identity-in-the-collective/#people) -3. [Attestations](https://community.optimism.io/docs/identity/attestations-best-practices/) - -Individuals and projects are the relevant entities in the Optimism Collective about which statements might be made. Attestations are the way in which these statements are made. - - - Decentralized identity not only supports democratic governance but also enhances innovation and individual financial control within the Optimism Collective ecosystem. - - -## Next steps - -To learn more about identity in the Optimism Collective: - -* Explore the [governance docs on project and individual identity](https://community.optimism.io/docs/identity/project-and-individual-identity-in-the-collective/) -* Read about [attestation best practices](https://community.optimism.io/docs/identity/attestations-best-practices/) -* Understand how [identity contributes to the Optimism vision](https://www.optimism.io/vision) diff --git a/pages/chain/identity/projects.mdx b/pages/chain/identity/projects.mdx deleted file mode 100644 index 98ae2a849..000000000 --- a/pages/chain/identity/projects.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Projects -lang: en-US -description: Learn about the project entity within the Optimism Collective's identity stack. ---- - -## Projects - -Within the Optimism Collective, [the project entity](https://community.optimism.io/docs/identity/project-and-individual-identity-in-the-collective/#people) represents contributions to the Optimism Collective and can be used to apply for Retroactive Public Goods Funding (Retro Funding). -## Project Representation - -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 - -All other project metadata is stored or referenced in the [Project Metadata Attestation](https://optimism.easscan.org/schema/view/0xe035e3fe27a64c8d7291ae54c6e85676addcbc2d179224fe7fc1f7f05a8c6eac). - -### 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 - -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 deleted file mode 100644 index 4e5d2ea8c..000000000 --- a/pages/chain/identity/schemas.mdx +++ /dev/null @@ -1,236 +0,0 @@ ---- -title: Schemas -lang: en-US -description: Learn about schema structures and the type of data that can be included in attestations. ---- - -# Schemas - -Schemas define the structure and type of data that can be included in an attestation. - -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 - -* **[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) - -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. - -| Schema UID | `0xff0b916851c1c5507406cfcaa60e5d549c91b7f642eb74e33b88143cae4b47d0` | -| ----------- | --------------------------------------------------------------------------------------------------------------- | -| Issuer | Attestations issued as part of Retro Funding sign up are issued by `0xF6872D315CC2E1AfF6abae5dd814fd54755fE97C` | -| 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) - -Used to associate metadata to an organization. Re-issued each time there is a change to metadata - -| Schema UID | `0xc2b376d1a140287b1fa1519747baae1317cf37e0d27289b86f85aa7cebfd649f` | -| ------------ | --------------------------------------------------------------------------------------------------------------- | -| Issuer | Attestations issued as part of Retro Funding sign up are issued by `0xF6872D315CC2E1AfF6abae5dd814fd54755fE97C` | -| Recipient | Null | -| RefUID | The attestation UID of the organization this metadata relates to | -| farcasterID | The Farcaster id of the individual who published the organization metadata | -| name | The name of the organization | -| projects | The array of projects that belong to this organization | -| parentOrgUID | The attestation UID of this organization's parent, in case it has one | -| 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) - -Used to associate metadata to a project. Re-issued each time there is a change to metadata. - -| Schema UID | `0xe035e3fe27a64c8d7291ae54c6e85676addcbc2d179224fe7fc1f7f05a8c6eac` | -| -------------------- | --------------------------------------------------------------------------------------------------------------- | -| Issuer | Attestations issued as part of Retro Funding sign up are issued by `0xF6872D315CC2E1AfF6abae5dd814fd54755fE97C` | -| Recipient | Null | -| projectRefUID | The attestation UID of the project this metadata relates to | -| farcasterID | The Farcaster id of the individual who published the project metadata | -| name | The name of the project | -| category | The category of the project | -| parentProject RefUID | The attestation UID of this project's parent project, in case it has a parent | -| 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/0x2169b74bfcb5d10a6616bbc8931dc1c56f8d1c305319a9eeca77623a991d4b80) - -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 | `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 | -| 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) - -Used to identify which Retro Funding applications have been approved or rejected. - -| Schema UID | `0x683b1b399d47aabed79c9aa8f2674729021174b6e5cce1e20675eab404fc82d6` | -| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Issuer | Currently, the Optimism Foundation issues these from the following address: `0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F` | -| Recipient | Null | -| projectApplicationUID | The unique identifier of the projects Retro Funding application. | -| 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) - -Used to identify the reward amount each approved project received in a Retro Funding round - -| Schema UID | `0x670ad6e6ffb842d37e050ea6d3a5ab308195c6f584cf2121076067e0d8adde18` | -| ------------- | ---------------------------------------------------------------------------------------------------------------------------- | -| Issuer | Currently, the Optimism Foundation issues these from one the following address: `0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F` | -| Recipient | Null | -| refUID | The UID of the Retro Funding application | -| projectRefUID | The unique identifier of the project | -| round | The retro round for which the project was rewarded | -| OPamount | The amount of OP awarded to the project | - -## Schemas related to token house grants - -### [Token house grant approved](https://optimism.easscan.org/schema/view/0x8aef6b9adab6252367588ad337f304da1c060cc3190f01d7b72c7e512b9bfb38) - -Issued by the Grants Council when a project is approved for a grant. Does not indicate that the grant has been completed. - -| Schema UID | `0x8aef6b9adab6252367588ad337f304da1c060cc3190f01d7b72c7e512b9bfb38` | -| ---------------- | --------------------------------------------------------------------------------- | -| Issuer | Currently issued by the Grants Council lead. | -| Recipient | The address where the tokens will be delivered once the grant has been completed. | -| refUID | Currently null | -| projectRefUID | The unique identifier of the project that was approved for the grant. | -| UserIncentivesOP | The OP amount approved for user incentives. | -| BuildersOP | The OP amount approved for the builder. | -| Season | The season (number) in which the grant was approved | -| Intent | The intent (number) to which the mission belongs | -| Mission | The name of the mission (in words) under which this grant was made. | -| Approval date | The date the grant was approved, in the following format MM/DD/YYYY | -| MetadataUrl | Currently null | - -## Schemas related to roles and contributions - -### [Citizens](https://optimism.easscan.org/schema/view/0xc35634c4ca8a54dce0a2af61a9a9a5a3067398cb3916b133238c4f6ba721bc8a) - -Citizen attestations were first issued in Season 6 and are used to represent Citizenship separately from the ability to vote in a specific Retro Round. The resolver contract checks that the issuer is the Foundation with following address `0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F` - -| Schema UID | `0xc35634c4ca8a54dce0a2af61a9a9a5a3067398cb3916b133238c4f6ba721bc8a` | -| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 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) - -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. - -| Schema UID | `0x41513aa7b99bfea09d389c74aacedaeb13c28fb748569e9e2400109cbe284ee5` | -| --------------- | -------------------------------------------------------------------------- | -| FarcasterID | The voter's unique identifier | -| Round | The round number for which this voting Badge was valid | -| voterType | Guest or Citizen | -| votingGroup | Used to assign voters to subcategories in case the Round has subcategories | -| selectionMethod | The method in which this voter was selected | - -### [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`. | -| 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 | - -### [Governance contribution](https://optimism.easscan.org/schema/view/0xef874554718a2afc254b064e5ce9c58c9082fb9f770250499bf406fc112bd315) - -Issued to those who held governance roles in the Collective, such as Grants Council members. - -| Schema UID | `0xef874554718a2afc254b064e5ce9c58c9082fb9f770250499bf406fc112bd315` | -| ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 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 | -| govSeason | The season the individual held the role | -| govRole | The role held by the individual | - -## Archived schemas - -These schemas are no longer being actively issued, but capture valuable historical data. - -### [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. - -| Schema UID | `0xfdcfdad2dbe7489e0ce56b260348b7f14e8365a8a325aef9834818c00d46b31b` | -| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Issuer | Currently, the Optimism Foundation issues these from one of the following addresses: `0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9` or `0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F` | -| Recipient | The Badgeholder's address | -| rpgfRound | The round number for which this voting Badge was valid | -| 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) - -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). - -| Schema UID | `0x7ae9f4adabd9214049df72f58eceffc48c4a69e920882f5b06a6c69a3157e5bd` | -| ----------- | --------------------------------------------------------------------------------------------------------------- | -| Issuer | Attestations issued as part of Retro Funding sign up are issued by `0xF6872D315CC2E1AfF6abae5dd814fd54755fE97C` | -| Recipient | Null | -| farcasterID | The Farcaster id of the individual who created the project | - -* **[RetroPGF 3 Approved Application schema UID](https://optimism.easscan.org/schema/view/0xebbf697d5d3ca4b53579917ffc3597fb8d1a85b8c6ca10ec10039709903b9277):**`0xebbf697d5d3ca4b53579917ffc3597fb8d1a85b8c6ca10ec10039709903b9277`. Important: Remember to verify the attester address is `0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9` -* **[RetroPGF 3 Application schema UID](https://optimism.easscan.org/schema/view/0x76e98cce95f3ba992c2ee25cef25f756495147608a3da3aa2e5ca43109fe77cc):** `0x76e98cce95f3ba992c2ee25cef25f756495147608a3da3aa2e5ca43109fe77cc` -* **[RetroPGF 3 Lists schema UID](https://optimism.easscan.org/schema/view/0x3e3e2172aebb902cf7aa6e1820809c5b469af139e7a4265442b1c22b97c6b2a5):** `0x3e3e2172aebb902cf7aa6e1820809c5b469af139e7a4265442b1c22b97c6b2a5` -* **[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 - -* 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). From f50e27c3e45ce5a21d7ac4dca8dc34bcb126d314 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 15 Jan 2025 18:36:44 +0100 Subject: [PATCH 04/10] fix breadcrumbs --- pages/stack/interop.mdx | 5 +++ pages/stack/interop/explainer.mdx | 69 ++++++++++++++----------------- pages/stack/interop/predeploy.mdx | 20 ++++----- pages/stack/interop/security.mdx | 50 ++++++++++------------ words.txt | 15 ++----- 5 files changed, 73 insertions(+), 86 deletions(-) diff --git a/pages/stack/interop.mdx b/pages/stack/interop.mdx index c601fdb88..f867c5124 100644 --- a/pages/stack/interop.mdx +++ b/pages/stack/interop.mdx @@ -27,4 +27,9 @@ Documentation covering Cross Chain Message, Explainer, Message Passing, Op Super + + + + + diff --git a/pages/stack/interop/explainer.mdx b/pages/stack/interop/explainer.mdx index 4de32d7fd..2b9685b90 100644 --- a/pages/stack/interop/explainer.mdx +++ b/pages/stack/interop/explainer.mdx @@ -11,11 +11,11 @@ import { InteropCallout } from '@/components/WipCallout' -# Interoperability explainer +# Interoperability explainer ## Why do we need interoperability? -It is easy for a blockchain to be certain about information it generates itself. +It is easy for a blockchain to be certain about information it generates itself. Information that comes from other sources is harder to provide in a safe, decentralized, and uncensorable manner (this is called [The Oracle Problem](https://chain.link/education-hub/oracle-problem)). The next major scalability improvement to the OP Stack is to enable a network of chains to feel like a single blockchain. This goal requires low-latency, seamless message passing and asset bridging. @@ -23,15 +23,15 @@ This goal requires low-latency, seamless message passing and asset bridging. *Interoperability* is a set of protocols and services that lets OP Stack blockchains read each others' state. Interoperability provides the following benefits: -- 1-block latency asset movement, removing the problem of capital fragmentation leading to better capital efficiency. -- Improved experience for both users and developers. -- Secure transfer of assets, such as ETH and ERC-20 tokens, across L2s. -- Horizontal scalability for applications that need it. +* 1-block latency asset movement, removing the problem of capital fragmentation leading to better capital efficiency. +* Improved experience for both users and developers. +* Secure transfer of assets, such as ETH and ERC-20 tokens, across L2s. +* Horizontal scalability for applications that need it. ## Interoperability architecture A pre-interop OP Stack node consists of two pieces of software: a consensus client (e.g. op-node) and an execution client, which is responsible for processing user transactions and constructing blocks (e.g. op-geth). -Interoperability among OP Stack chains is enabled via a new service called [*OP Supervisor*](/stack/interop/op-supervisor). +Interoperability among OP Stack chains is enabled via a new service called [*OP Supervisor*](/stack/interop/op-supervisor). Every node operator is expected to run this service in addition to the [rollup node](/builders/node-operators/architecture#rollup-node) and [execution client](/builders/node-operators/architecture#execution-client). ```mermaid @@ -145,28 +145,26 @@ Interop expands the scope of trust for unsafe blocks (blocks that are shared thr If a sequencer chooses to accept unsafe messages, the sequencer must trust the sequencer that produces the inbound message as well as any referenced unsafe messages produced from sequencers in the transitive dependency set.
- -What is the transitive dependency set? - -The transitive dependency set of a blockchain is all the chains on which it depends, and all the chains that depend on them, and so on. -For example, in the illustration above, the dependency set of chain A is just chain B. -However, the *transitive* dependency set includes chain B, the chains that depend on it (C and D) and the chains that depend on them (E). -If there was a chain that depended on E, that chain would be part of the transitive dependency set too. - -```mermaid - -flowchart LR - A[Chain A] <--> B[Chain B] - B <--> C[Chain C] - B <--> D[Chain D] - D <--> E[Chain E] - F[Chain F] <--> G[Chain G] -``` - -For example, there could be a block in chain D that depends on an initiating message in chain E> -If the block with that initiating message is still unsafe (not written to L1), then the block in chain D is also usafe, even if it has been written to L1. -As a result, a block in chain B that depends on the chain D block can also be unsafe, as can a block in chain A that depends on the block in chain B. - + What is the transitive dependency set? + + The transitive dependency set of a blockchain is all the chains on which it depends, and all the chains that depend on them, and so on. + For example, in the illustration above, the dependency set of chain A is just chain B. + However, the *transitive* dependency set includes chain B, the chains that depend on it (C and D) and the chains that depend on them (E). + If there was a chain that depended on E, that chain would be part of the transitive dependency set too. + + ```mermaid + + flowchart LR + A[Chain A] <--> B[Chain B] + B <--> C[Chain C] + B <--> D[Chain D] + D <--> E[Chain E] + F[Chain F] <--> G[Chain G] + ``` + + For example, there could be a block in chain D that depends on an initiating message in chain E> + If the block with that initiating message is still unsafe (not written to L1), then the block in chain D is also usafe, even if it has been written to L1. + As a result, a block in chain B that depends on the chain D block can also be unsafe, as can a block in chain A that depends on the block in chain B.
Notably this trust assumption is only for *unsafe* blocks, and *only* if the sequencer allows messages from unsafe blocks to be processed. @@ -202,8 +200,8 @@ To move an asset from chain E to chain B, it is necessary to move the asset from ### 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. +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. This model provides the highest level of interoperability, as any blockchain can transact directly with any other. ```mermaid @@ -213,10 +211,8 @@ flowchart LR A <--> C <--> E <--> B <--> D <--> A ``` - Each blockchain in the Superchain interop cluster shares the same security model to mitigate the weakest-link scenario. As outlined in the [Standard Rollup Charter](https://gov.optimism.io/t/season-6-standard-rollup-charter-ratification/8135#p-36758-governing-policies-11), these chains share the same L1 `ProxyAdmin` Owner. Any changes to the Superchain interop cluster must follow the standard Protocol Upgrade vote procedure—the established governance process for Superchain modifications. - {/* ## Interop assets @@ -229,8 +225,7 @@ This means ETH and ERC-20s can seamlessly and securely move across L2s, and inte */} ## 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](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). - +* 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](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). diff --git a/pages/stack/interop/predeploy.mdx b/pages/stack/interop/predeploy.mdx index d89f3b4ee..672938171 100644 --- a/pages/stack/interop/predeploy.mdx +++ b/pages/stack/interop/predeploy.mdx @@ -13,7 +13,7 @@ import { InteropCallout } from '@/components/WipCallout' # Interoperability predeploys -The following predeploys have been added to enable interoperability. +The following predeploys have been added to enable interoperability. *Predeployed smart contracts* exist at predetermined addresses, coming from the genesis state. They're similar to [precompiles](https://www.evm.codes/precompiled) but run directly in the EVM instead of running as native code. @@ -22,9 +22,9 @@ They're similar to [precompiles](https://www.evm.codes/precompiled) but run dire 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) -- **Source code:** [`CrossL2Inbox`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol) +* **Address:** `0x4200000000000000000000000000000000000022` +* **Specs:** [`CrossL2Inbox`](https://specs.optimism.io/interop/predeploys.html#crossl2inbox) +* **Source code:** [`CrossL2Inbox`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol) ## L2ToL2CrossDomainMessenger @@ -32,9 +32,9 @@ The `L2ToL2CrossDomainMessenger` is a higher level abstraction on top of the `Cr It's utilized for secure ERC20 token transfers between L2 chains. Messages sent through the `L2ToL2CrossDomainMessenger` on the source chain receive both replay protection and domain binding (the executing transaction can only be valid on a single chain). -- **Address:** `0x4200000000000000000000000000000000000023` -- **Specs:** [`L2ToL2CrossDomainMessenger`](https://specs.optimism.io/interop/predeploys.html#l2tol2crossdomainmessenger) -- **Source code:** [`L2ToL2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/L2ToL2CrossDomainMessenger.sol) +* **Address:** `0x4200000000000000000000000000000000000023` +* **Specs:** [`L2ToL2CrossDomainMessenger`](https://specs.optimism.io/interop/predeploys.html#l2tol2crossdomainmessenger) +* **Source code:** [`L2ToL2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/L2ToL2CrossDomainMessenger.sol) {/* ## OptimismSuperchainERC20Factory @@ -60,6 +60,6 @@ This contract is the `Beacon` part, which provides the implementation address fo The `SuperchainTokenBridge` is an abstraction on top of the `L2toL2CrossDomainMessenger` that facilitates token bridging using interop. It has mint and burn rights over `OptimismSuperchainERC20` tokens, as described in the [token bridging spec](https://specs.optimism.io/interop/token-bridging.html). -- **Address:** `0x4200000000000000000000000000000000000028` -- **Specs:** [`SuperchainTokenBridge`](https://specs.optimism.io/interop/predeploys.html#superchainerc20bridge) -- **Source code:** [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) +* **Address:** `0x4200000000000000000000000000000000000028` +* **Specs:** [`SuperchainTokenBridge`](https://specs.optimism.io/interop/predeploys.html#superchainerc20bridge) +* **Source code:** [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) diff --git a/pages/stack/interop/security.mdx b/pages/stack/interop/security.mdx index 7dec4e67a..a0b488677 100644 --- a/pages/stack/interop/security.mdx +++ b/pages/stack/interop/security.mdx @@ -18,37 +18,34 @@ import { InteropCallout } from '@/components/WipCallout' This interop vulnerability arises when an initiating message seems to exist, prompting the processing of the executing message. However, the initiating message ends up not actually appear in the canonical chain. Excluding L1 reorgs, this can happen in two ways: -- *Equivocation*. A sequencer publishes a block using the gossip protocol that is different from the one that eventually gets written to L1. - The problem happens when the gossip protocol block includes a log entry that is used as an initiating message, but the real block (the one written to L1) doesn't. - The way this is handled is that a block that depends on an unsafe block is, itself, unsafe. - It does not get treated as safe until all the blocks on which it depends (directly or indirectly) are also written to L1. +* *Equivocation*. A sequencer publishes a block using the gossip protocol that is different from the one that eventually gets written to L1. + The problem happens when the gossip protocol block includes a log entry that is used as an initiating message, but the real block (the one written to L1) doesn't. + The way this is handled is that a block that depends on an unsafe block is, itself, unsafe. + It does not get treated as safe until all the blocks on which it depends (directly or indirectly) are also written to L1. -- *Faulty information*. The sequencer operator can run a verifier node for every chain in the dependency set, in which case it can deduce the initiating messages from the safe transactions of every chain. - To save on resources, the sequencer can choose to query existing nodes of the source blockchain. - In that case, if the information provided to sequencer is incorrect, of course the blocks posted by the sequencer will be also incorrect. +* *Faulty information*. The sequencer operator can run a verifier node for every chain in the dependency set, in which case it can deduce the initiating messages from the safe transactions of every chain. + To save on resources, the sequencer can choose to query existing nodes of the source blockchain. + In that case, if the information provided to sequencer is incorrect, of course the blocks posted by the sequencer will be also incorrect. - In this case, invalid blocks will be replaced with deposit only blocks by other verifiers. + In this case, invalid blocks will be replaced with deposit only blocks by other verifiers.
+ What are deposit only blocks? - What are deposit only blocks? + Normally the blocks that make it to the canonical blockchain are those posted to L1 by the sequencer. + However, when those blocks are missing or invalid (for example because they rely on an initiating message that is missing), they're replaced by *deposit only blocks*, blocks whose content can be calculated from L1 without relying on the sequencer. - Normally the blocks that make it to the canonical blockchain are those posted to L1 by the sequencer. - However, when those blocks are missing or invalid (for example because they rely on an initiating message that is missing), they're replaced by *deposit only blocks*, blocks whose content can be calculated from L1 without relying on the sequencer. + The way this works is that there are two types of user transactions in an OP Stack block: - The way this works is that there are two types of user transactions in an OP Stack block: + * Sequencer transactions, which go through the sequencer. + These transactions are extremely cheap, but in theory a sequencer could censor them. + * Deposit transactions, which users submit through L1. + These transactions have the cost of an L1 transaction, which is a lot higher, but they cannot be censored by the sequencer. - - Sequencer transactions, which go through the sequencer. - These transactions are extremely cheap, but in theory a sequencer could censor them. - - Deposit transactions, which users submit through L1. - These transactions have the cost of an L1 transaction, which is a lot higher, but they cannot be censored by the sequencer. - - A deposit only block only contains the deposit transactions and some internal transactions, not the sequencer transactions. - - For more information about this process, [see the technical specifications](https://specs.optimism.io/protocol/derivation.html#deriving-the-transaction-list). + A deposit only block only contains the deposit transactions and some internal transactions, not the sequencer transactions. + For more information about this process, [see the technical specifications](https://specs.optimism.io/protocol/derivation.html#deriving-the-transaction-list).
- ## The latency/security tradeoff @@ -62,7 +59,7 @@ There are three different possibilities, at different levels of latency and secu ### Unsafe initiating messages L2 blocks start as unsafe, meaning that there's no L1 evidence for them, and the sequencer for that blockchain can send out incorrect information. -Sending out incorrect information, for example that a certain transaction is included in a block when it isn't, is called *equivocation*. +Sending out incorrect information, for example that a certain transaction is included in a block when it isn't, is called *equivocation*. A sequencer that builds blocks with interop can choose to accept messages from unsafe blocks (received through the gossip protocol), for minimal latency. However, because of equivocation risk, a block that is written to L1 (*local safe*) can only be considered truly safe (the techincal term is *cross safe*), for itself and the previous blocks in its blockchain are also written to L1. @@ -92,7 +89,7 @@ sequenceDiagram Alternatively, a sequencer can be configured to only accept executing messages once the initiating message is in a cross safe block. A cross safe block is one that is written to L1, and whose dependecies (direct or indirect, including dependencies of previous blocks in the same chain) are all written to L1. -When a block is cross safe, the source sequencer cannot equivocate, and the state will only need to be recalculated if there's an [L1 reorg](https://www.alchemy.com/overviews/what-is-a-reorg#what-happens-to-reorgs-after-the-merge). +When a block is cross safe, the source sequencer cannot equivocate, and the state will only need to be recalculated if there's an [L1 reorg](https://www.alchemy.com/overviews/what-is-a-reorg#what-happens-to-reorgs-after-the-merge). The cost of this enhanced security that it would take longer for a message to pass from one blockchain to the other. Higher throughput OP Stack chains like Base and OP Mainnet submit a batch about every 5 minutes, so on average it takes about 2.5 minutes for an initiating message to become safe. @@ -131,12 +128,9 @@ Currently, this adds [about 15 minutes](https://ethereum.org/en/roadmap/single-s Safe and Unsafe Security Diagram - -Even if a sequencer accepts unsafe initiating messages, the blocks it constructs that rely on them are considered unsafe until the blocks with those initiating messages are written to L1 and become safe. - + Even if a sequencer accepts unsafe initiating messages, the blocks it constructs that rely on them are considered unsafe until the blocks with those initiating messages are written to L1 and become safe. - {/* ## 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. @@ -146,4 +140,4 @@ There is nothing stopping a sequencer from censoring a transaction when it is se ## What is stopping a shared sequencer from including just the executing message and not the initiating message? The protocol enforces the fact that all executing messages are valid. It does this by reorganizing out executing messages that have invalid initiating messages. Running software that does not enforce this would be non-standard behavior and would leave yourself at risk of accepting an invalid executing message and therefore running on a forked chain. -*/} \ No newline at end of file +*/} diff --git a/words.txt b/words.txt index 92f79e7e6..a76e42839 100644 --- a/words.txt +++ b/words.txt @@ -14,14 +14,10 @@ Ankr Apeworx Arweave authrpc -Badgeholder's -Badgeholders -badgeholders basefee BGEZ BGTZ Biconomy -birthdate BLEZ BLOBPOOL blobpool @@ -78,6 +74,7 @@ DATACAP datacap DATADIR datadir +dependecies Devnet devnet devnets @@ -111,7 +108,6 @@ exitwhensynced EXTRADATA extradata Farcaster -farcaster Faultproof FDLIMIT fdlimit @@ -158,6 +154,7 @@ Inator inator INFLUXDBV influxdbv +inteoperates interchain IPCDISABLE ipcdisable @@ -165,7 +162,6 @@ ipcfile IPCPATH ipcpath IPFS -ipfs JALR JOURNALREMOTES journalremotes @@ -264,7 +260,6 @@ Permissionless permissionless permissionlessly Perps -personhood Pimlico POAP POAPs @@ -328,8 +323,6 @@ RPCPREFIX rpcprefix rpcs RPGF -Rpgf -rpgf Runbooks runbooks RWAs @@ -352,7 +345,6 @@ snapshotlog Snapsync snapsync Soneium -soulbound soyboy spacebar Spearbit @@ -395,6 +387,7 @@ TXPOOL txpool txproxy txproxyd +uncensorable uncountered undercollateralize Unichain @@ -402,6 +395,7 @@ unmetered Unprotect unsubmitted UPNP +usafe VERKLE verkle VHOSTS @@ -414,7 +408,6 @@ vmdebug VMODULE vmodule voxel -Warpcast xlarge XORI xtensibility From 67302d9dcbb289f3fd1d78c3b3506afafed6c945 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 16 Jan 2025 11:33:36 +0100 Subject: [PATCH 05/10] Update words.txt Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- words.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/words.txt b/words.txt index a76e42839..6ea2c3d0a 100644 --- a/words.txt +++ b/words.txt @@ -395,7 +395,7 @@ unmetered Unprotect unsubmitted UPNP -usafe +unsafe VERKLE verkle VHOSTS From 252b4c924cae8ca2387a7c789c7229797f3e535e Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 16 Jan 2025 11:33:53 +0100 Subject: [PATCH 06/10] Update words.txt Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- words.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/words.txt b/words.txt index 6ea2c3d0a..ef9144cc5 100644 --- a/words.txt +++ b/words.txt @@ -74,7 +74,7 @@ DATACAP datacap DATADIR datadir -dependecies +dependencies Devnet devnet devnets From 24a28f2e1186137effc84295f0103f59c62cf4aa Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 16 Jan 2025 14:44:36 +0100 Subject: [PATCH 07/10] Update words.txt Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- words.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/words.txt b/words.txt index ef9144cc5..2079624f2 100644 --- a/words.txt +++ b/words.txt @@ -154,7 +154,7 @@ Inator inator INFLUXDBV influxdbv -inteoperates +interoperates interchain IPCDISABLE ipcdisable From 2840df413b9292b8821bfffc07a36ef8bc7df983 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 16 Jan 2025 14:45:16 +0100 Subject: [PATCH 08/10] updated word --- pages/stack/interop/explainer.mdx | 2 +- pages/stack/interop/security.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/pages/stack/interop/explainer.mdx b/pages/stack/interop/explainer.mdx index 2b9685b90..ead383e48 100644 --- a/pages/stack/interop/explainer.mdx +++ b/pages/stack/interop/explainer.mdx @@ -96,7 +96,7 @@ The second transaction creates an *executing message* on the destination chain. This executing message could result in a contract function being executed on the destination chain. The initiating message is simply a log event. -Any log event on any chain that inteoperates with the destination can initiate a cross-domain message. +Any log event on any chain that interoperates with the destination can initiate a cross-domain message. The transaction that receives the message on the destination chain calls a contract called [`CrossL2Inbox`](https://specs.optimism.io/interop/predeploys.html#crossl2inbox). This call can be at the top level, directly from the externally owned account, or come through a smart contract. diff --git a/pages/stack/interop/security.mdx b/pages/stack/interop/security.mdx index a0b488677..b6c7f819d 100644 --- a/pages/stack/interop/security.mdx +++ b/pages/stack/interop/security.mdx @@ -87,7 +87,7 @@ sequenceDiagram ### Safe initiating messages Alternatively, a sequencer can be configured to only accept executing messages once the initiating message is in a cross safe block. -A cross safe block is one that is written to L1, and whose dependecies (direct or indirect, including dependencies of previous blocks in the same chain) are all written to L1. +A cross safe block is one that is written to L1, and whose (direct or indirect, including dependencies of previous blocks in the same chain) are all written to L1. When a block is cross safe, the source sequencer cannot equivocate, and the state will only need to be recalculated if there's an [L1 reorg](https://www.alchemy.com/overviews/what-is-a-reorg#what-happens-to-reorgs-after-the-merge). The cost of this enhanced security that it would take longer for a message to pass from one blockchain to the other. From ca581a3711e3894447091a565944aabd7e10c2ff Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 16 Jan 2025 19:30:03 +0100 Subject: [PATCH 09/10] remove identity nav link --- pages/chain/_meta.json | 1 - 1 file changed, 1 deletion(-) diff --git a/pages/chain/_meta.json b/pages/chain/_meta.json index 6c45f77d2..cf2e338d0 100644 --- a/pages/chain/_meta.json +++ b/pages/chain/_meta.json @@ -3,7 +3,6 @@ "networks": "Networks and RPC Endpoints", "addresses": "Contract addresses", "tokenlist": "Bridged token addresses", - "identity": "Identity", "testing": "Testing", "security": "Security" } \ No newline at end of file From f3a14bdf16e7175098ad61ea0aee74a8b232020f Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 16 Jan 2025 19:34:53 +0100 Subject: [PATCH 10/10] fix lint issue --- pages/stack/interop/op-supervisor.mdx | 6 +++--- words.txt | 5 +---- 2 files changed, 4 insertions(+), 7 deletions(-) diff --git a/pages/stack/interop/op-supervisor.mdx b/pages/stack/interop/op-supervisor.mdx index 3382811fe..b130e13ed 100644 --- a/pages/stack/interop/op-supervisor.mdx +++ b/pages/stack/interop/op-supervisor.mdx @@ -46,11 +46,11 @@ OP Supervisor provides an interface for `op-node` to query cross-chain safety in Key API methods include: -| Method(s) | Description | +| Method(s) | Description | | ----------------------------------------- | ------------------------------------------------------------------------------------- | -| `UnsafeView` and `SafeView` | Return the Local and Cross heads for their respective levels | +| `UnsafeView` and `SafeView` | Return 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` | Tell the Supervisor when the Node's heads change | +| `UpdateLocalSafe` and `UpdateLocalUnsafe` | Tell 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 | diff --git a/words.txt b/words.txt index 38dfbe8a5..23795ef2b 100644 --- a/words.txt +++ b/words.txt @@ -74,7 +74,6 @@ DATACAP datacap DATADIR datadir -dependencies Devnet devnet devnets @@ -154,7 +153,6 @@ Inator inator INFLUXDBV influxdbv -inteoperates interchain IPCDISABLE ipcdisable @@ -282,6 +280,7 @@ preinstalls Prestate prestate prestates +PREVRENDAO PRICEBUMP pricebump PRICELIMIT @@ -292,14 +291,12 @@ Protip Proxied Proxyd proxyd -pseudorandomly Pyth Pyth's QRNG Quicknode quicknode quickstarts -RANDAO rebalance Regenesis regenesis