12 September 2024

Ethereum Open Community Projects L2 Standards Working Group

Vitalik Buterin has highlighted three significant transitions for Ethereum: enhancing scalability through L2 rollups to minimize costs, upgrading wallet security with smart contract wallets for improved security and user experience, and advancing privacy through mechanisms that uphold user privacy. This article discusses how the integration of W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) can help tackle these challenges by streamlining the management of identities, keys, and addresses. This approach builds on existing decentralized identity solutions to facilitate Ethereum’s transition to a more L2-focused ecosystem.

As noted by Vitalik Buterin in a series of articles from 2023, most notably in his Three Transitions piece, Ethereum is evolving from a nascent experimental technology to a robust tech stack that aims to deliver an open, global, and permissionless experience for average users. He argues that the technology stack must navigate three major technical transitions, which need to occur roughly in unison:

L2 Scaling Transition: This entails migrating the ecosystem to rollups in order to tackle the excessive transaction fees on Ethereum, which have soared to $3.75 or even $82.48 amidst bullish market conditions.
Wallet Security Transition: Transitioning to smart contract wallets (account abstraction) is essential for improving user comfort and enhancing security when managing funds and non-financial assets, as it shifts reliance away from centralized exchanges and isolated non-custodial wallets.
Privacy Transition: It’s vital to ensure that funds are transferred in a privacy-preserving manner while also developing additional privacy mechanisms such as social recovery and identity systems to prevent users from reverting to centralized solutions that provide limited or negligible privacy.

Vitalik underscores that these transitions are pivotal yet daunting due to the significant coordination required for their implementation. He specifically addresses the effects of these transitions on the dynamics between users and addresses, payment systems, and key management methodologies. The connection between users and their addresses, along with key rotation and recovery, is a major concern from both a technical and usability standpoint; user experience is crucial for determining success regardless of the technology’s sophistication.

This article will explore these issues further and examine how solutions from another ecosystem—particularly the one centered on decentralized identity, often called self-sovereign identity—can significantly facilitate these transitions without having to reinvent the wheel.

The problem statement related to Ethereum’s technical transitions can be encapsulated as follows, according to Vitalik:

Complex Payments: The transitions complicate simple actions like making payments; users need to provide more than just an address—such as specifying which funds to use, where they are being sent, and particular payment instructions, often involving identity details.
Smart Contract Wallets: Smart contract wallets introduce technical challenges, including tracking ETH sent by smart contract code and ensuring functionality across various networks.
Privacy Challenges: Implementing privacy-preserving transactions introduces new complications, such as the necessity of a “spending public key” and encrypted information to facilitate recipient payment identification.
Identity Changes: The definition of an “address” will transform, potentially necessitating a combination of multiple addresses, encryption keys, and additional data for user interaction.

These points pose a critical question: how do we effectively manage identity, addresses, and their corresponding keys in a way that does not confuse users or compromise the security of their assets?

Considering the aforementioned problem statement, the conception of an “address” in the Ethereum ecosystem is progressing, as the traditional notion of a single cryptographic identifier is becoming outdated. Instead, “instructions on how to interact with me” will require a combination of addresses across various Layer 2 (L2) platforms, stealth meta-addresses, encryption keys, and other data. Vitalik discusses a potential method using Ethereum Name Service (ENS) records to consolidate all identity information. Sending someone an ENS name like “alice.eth” would grant access to all necessary interaction details, including payment methods and privacy-preserving processes. However, this strategy has its drawbacks, such as being overly tied to one’s name and lacking trustless counterfactual names—crucial for facilitating token transfers to new users without prior blockchain interaction. Furthermore, the ENS system operates as a rent-seeking entity, raising equity concerns and failing to ensure continued ownership of one’s identity, which is unsustainable. An alternative solution presents itself through keystore contracts that retain all identity information. These contracts can be counterfactual-friendly and not bound to any specific name, thus allowing for greater flexibility and privacy.

This leads us to discuss keys that govern “addresses,” specifically the aspects of key rotation and key recovery within a multi-address Ethereum ecosystem. Key rotation is emerging as a vital feature in the context of smart contract wallets and account abstraction, where the controlling address of a smart contract wallet might change due to a key rotation or recovery. Under the traditional approach, the process would involve executing on-chain procedures for each address separately, which is impractical due to gas costs, counterfactual addresses, and privacy concerns. As mentioned earlier, Vitalik suggests employing keystore contracts that reside in a single location while pointing to verification logic at various addresses. This arrangement would permit the generation of proof of the current spending key for transactions, requiring a recovery architecture that separates verification logic from asset holdings, thereby simplifying recovery protocols to necessitate merely a cross-network proof for restoration.

In this context, Decentralized Identifiers can leverage keystore contracts to support a modular verification framework for contract accounts that validates zk proofs through dedicated verification modules and embeds a system to standardize on-chain implementations. Introducing privacy measures, such as encrypted pointers and zk proofs, raises complexity but offers potential synergies with keystore contracts for persistent addresses since the address could be “cloaked” in a zk proof.

What implications do these developments hold for smart contract wallets? Traditionally, wallets were architected to safeguard assets by shielding the private key tied to on-chain assets. If the key were to change, the old one could be disclosed safely without incurring any risks. However, in a zero-knowledge context, wallets must also protect additional data beyond just assets. The illustration of Zupass, a ZK-SNARK-based identity system, showcases that users can maintain data locally, disclosing it only when required. Nevertheless, losing the data’s encryption key equates to forfeiting access to all encrypted data, which is making key management increasingly critical. Vitalik proposes utilizing multiple devices or implementing secret sharing among (key) “guardians” as a strategy to reduce the risk of losing encryption keys. Nonetheless, this method isn’t ideal for asset recovery due to potential collusion risks among “guardians.” Ultimately, the notion of an address as a user’s on-chain identifier will need to evolve, and wallets must incorporate both asset recovery and encryption key recovery to prevent overwhelming users with convoluted recovery processes, resulting in poor UX. For instance, Sign In With Ethereum relies on the on-chain address and the user’s private key governing that key to generate the authentication message. However, this approach lacks a one-to-many relationship and does not acknowledge a smart contract wallet as the primary representative of the user. This limitation means the verifying party, or relying party, cannot assess the range of authorization(s) needed from the user during login, which is crucial depending on the functionalities offered by the verifying entity to the user address.

The Three Transitions represent more than mere technical enhancements; they signify transformative shifts in user engagement with Ethereum-based stacks, particularly concerning identity, key management, and addresses. This evolution aims to reshape the Ethereum ecosystem from its current form into a more user-centric and accessible platform that emphasizes scalability, security, and usability. Consequently, a pertinent question arises: Are there tools and frameworks currently available that could assist the community—particularly in terms of identity, key management, and privacy—to facilitate these transitions? The answer is a resounding yes. Specifically, the ecosystem surrounding the concept of decentralized identity—with its standards, frameworks, and numerous reference implementations—has produced tools that are immediately applicable within the Ethereum stack.

What is the Decentralized Identity Ecosystem?

The decentralized identity ecosystem is designed to empower individuals with control over their digital identities without dependency on centralized authorities. It utilizes blockchain technology alongside cryptographic principles to guarantee privacy, security, and user-focused identity management. Central to this ecosystem are two fundamental concepts: Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs).

Decentralized Identifiers (DIDs):

DIDs represent a novel form of identifier that facilitates verifiable, self-sovereign digital identities. They are unique, globally resolvable identifiers linked to a subject, such as an individual, organization, or device. By design, DIDs are decentralized, operating without reliance on a central registry or authority for their creation or management. Users or entities acting on their behalf create and control DIDs. Typically, DIDs employ public-key cryptography to secure interactions, allowing the subject to assert ownership and control over their identity and execute specific authorized actions including assertions, authentication, authorization, and encryption.

Verifiable Credentials (VCs):

Verifiable Credentials are digital credentials encompassing claims about a subject’s identity, attributes, or qualifications, which are issued by trusted entities known as issuers. VCs are tamper-evident and cryptographically signed to ensure their integrity and authenticity. Notably, VCs are portable, enabling the subject to present them to verifiers, such as service providers or relying parties, without requiring direct interaction with the issuer. This features seamless and privacy-respecting identity verification across different domains and contexts.

Numerous key players and organizations are contributing to the development and adoption of decentralized identity technologies:

Decentralized Identity Foundation (DIF): A consortium of organizations working together to establish standards and protocols for decentralized identity systems, promoting innovation and compatibility.
World Wide Web Consortium (W3C): Hosts the Credentials Community Group, which nurtures work on verifiable credentials and related technologies, along with the Decentralized Identifier and Verifiable Credentials Working Groups that are refining relevant specifications.
Hyperledger Indy: An open-source initiative under the Linux Foundation, focused on providing tools and libraries for building decentralized identity systems.
Sovrin Foundation: Operates the Sovrin Network, a public permissioned blockchain dedicated to decentralized identity management.
Major Tech Companies: Firms like Microsoft and IBM are actively engaged in developing decentralized identity solutions and contributing to standards advancement, while also creating reference implementations.

Standards are vital for ensuring interoperability and compatibility within the decentralized identity ecosystem. Key standards and reference implementations include:

Decentralized Identifier (DID) Specification: Outlines the syntax and semantics of DIDs, detailing methods for their creation, resolution, and management.
Verifiable Credentials Data Model: Specifies the structure and format of verifiable credentials, including JSON-LD contexts for representing claims.
DIDComm Messaging Protocol: Facilitates secure, private communication between DIDs utilizing end-to-end encryption and cryptographic authentication.
SSI (Self-Sovereign Identity) Protocols: A variety of protocols and frameworks such as DID Auth, Presentation Exchange, and VC API that support secure interactions and transactions within the self-sovereign identity framework.
Hyperledger Aries: A framework providing interoperable components for building decentralized identity solutions, including agents, wallets, and protocols.
Privado ID (formerly Polygon ID): A developer toolkit to establish secure and trustworthy relationships between users and applications in Web3, centered on decentralized identity and empowering users over their data. The toolkit is based on the open-source iden3 protocol.
QuarkID: An open-source DID solution currently implemented on ZKsync Era, with digital credentials issued by the City of Buenos Aires.

Below, we elucidate how a decentralized identity framework can be effectively leveraged to address the cross-network challenges concerning identity, address, and key management previously discussed.

Utilizing Decentralized Identifiers (DIDs)

Problem: Managing an individual’s identity across diverse Ethereum networks is complex.

DID Solution for Identities:

DIDs offer globally unique identifiers that are resolvable (to their DID Document) and cryptographically verifiable across any blockchain network. Each DID is linked to a DID Document containing information about its relationship with a set of cryptographic keys, detailing functions these keys can perform—verification, authentication, authorization, assertion, and encryption—and service endpoints including API addresses governed by the keys noted in the DID Document. The relationship between DIDs and their respective documents or cryptographic representations can be stored on any blockchain network, ensuring a tamper-proof and persistent identity record.

DID Documents for Address Management:

Problem: Users possess different addresses across the Ethereum mainnet, testnets, and Layer 2 platforms, inclusive of counterfactual addresses.

DID Document Solution:

A DID document incorporates a verificationMethod data property that permits a DID owner or controller to specify symmetric and asymmetric cryptographic keys for any desired curve, such as secp256k1 employed by Ethereum stacks. The verificationMethod for a key also enables the user to identify a verification method ID, typically comprising the DID plus a fragment according to the DID specification. This fragment serves two significant purposes: it allows specification of a network identifier (e.g., “1” for an Ethereum key and different identifiers for alternate networks) and can extend to signify if the key is associated with a counterfactual address or smart contract wallet. For instance, “did:ion:1234xxxxddd4444-#1-counter” could indicate that the public key in question belongs to a counterfactual Ethereum address. Additionally, if required for specific distinctions between networks like Polygon PoS and Arbitrum One, the “1” could be replaced with the chainId of the target network, e.g., 137 for Polygon PoS.

Furthermore, a smart contract wallet can be designated its own DID, controlled by the DIDs of the smart contract wallet owners—where each owner designates one or more controlling keys for the wallet as articulated in their DID document. This key management arrangement enhances two major aspects of smart contract wallets: key rotation (a.k.a. key recovery) and allowing an arbitrary number of controlling keys without revealing them openly.

DID Documents for Key Management, Including Social Recovery:

Problem: Key recovery and rotation for Ethereum addresses, especially smart contract wallets, are complex and lack user-friendliness.

DID Document Solution:

When it becomes necessary to rotate a public key tied to a DID for security or recovery reasons, a user can simply amend the DID Document, replacing the previous public key with a new one in the verificationMethod using an alternative controlling key. This can either be a key directly managed by the user or one delegated by another user controlling a DID listed as a controller. Consequently, this can also be implemented for a Smart Contract wallet, whereby each controller independently updates the key in the verificationMethod related to their DID. This is sufficient, as the user can generate a cryptographic commitment affirming that the update was executed accurately, which can be submitted for verification by the smart contract wallet.

Privacy (Zero-Knowledge) Aspects of DIDs and DID Documents

DID Documents can be represented through zero-knowledge proofs by first creating a Merkle tree from their JSON-LD document and subsequently verifying Merkle Proofs of relationships between DID-to-key and DID-to-functional-capability (as delineated through one or more cryptographic keys). Utilizing zk-SNARKs enables efficient verification of cryptographic key assertions across Ethereum networks. For instance, the zero-knowledge circuit for validating a key rotation update of a DID document would achieve two objectives: a) Verify that the updating key is present in the DID document, establishing it as a controlling key through validation of a Merkle proof of inclusion, and b) Verify the digital signature of the controlling key over the root hash of the older DID document. The public inputs fed into the proof would consist of the Merkle Root of the newly merkelized DID Document and the root hash of the prior DID document, while the private inputs would involve the Merkle proof and the digital signature. The smart contract would merely need to validate the proof, confirm that the earlier root hash was registered, and then replace the old hash with the new one.

This arrangement allows for anonymity concerning which addresses govern the smart contract wallet. Each transaction within a smart contract wallet could potentially be entirely anonymous, provided that all transactions submitted to the smart contract include a recursive zero-knowledge proof asserting that a) the public key linked with the submitting address is a controlling key of the DID that owns the smart contract, and b) that a zero-knowledge proof demonstrating that the transaction was correctly signed by the requisite signatures of the smart contract wallet owners is verified within the circuit itself.

Utilizing Verifiable Credentials (VCs)

Problem: Entities executing key operations—such as key rotations or digital signatures for financial transactions—must validate their status as a legitimate entity fulfilling all applicable compliance regulations in jurisdictions with compliance oversight.

VC Solution for Compliant Key Operations:

W3C VCs allow claims to be asserted regarding the subject of the credential, for instance, “Alice is a legal enterprise in Brazil,” or, “This enterprise is legally registered in the US and recognized as a Broker-Dealer,” or, “The legally registered US entity A is authorized to act on behalf of the legally registered US entity B.” Given the standardized structure and public context reference files that specify VC standards and particular VC types, each VC can seamlessly be converted into a zk proof through a standardized, publicly available zk circuit, revealing only the legal identity of the VC issuer that serves as the root of trust, such as a KYC provider.

Such zk proofs, specifically ZK-SNARKs, can be submitted alongside any transaction and verified within a smart contract setting, such as a smart contract wallet or within DeFi protocols. This facilitates compliant transactions across Ethereum stacks without disclosing any sensitive identity or other relevant compliance data.

Useful Implementations for Ethereum Networks

There are various implementations of the W3C DID specification available. While many DID methods may lack the required scalability or ease of blockchain anchoring, several methods align well with the Ethereum ecosystem—being permissionless, blockchain-based, scalable, and cost-effective. All of these methods are grounded in the Sidetree Protocol. The Sidetree Protocol is a “Layer 2” DID protocol applicable to any event anchoring system, including Ethereum, and conforms to W3C guidelines. The Sidetree protocol does not necessitate centralized authorities, unique protocol tokens, trustworthy intermediaries, or supplementary consensus mechanisms. It delineates a foundational set of DID PKI state change operations, structured as delta-based Conflict-Free Replicated Data Types (such as Create, Update, Recover, or Deactivate), that modify a Decentralized Identifier’s DID Document state.

Thus, by utilizing an Ethereum-based Sidetree implementation, the Ethereum ecosystem can guarantee that each user possesses a self-sovereign identity that is both private and interoperable across different L2s and applications.

We believe that integrating W3C DIDs and VCs into Ethereum’s infrastructure is pivotal for navigating the upcoming transitions. They furnish essential tools for managing identities, keys, addresses, security, and privacy, which align with the decentralized principles of blockchain technology. Unfortunately, the Ethereum ecosystem and the decentralized identity (DID) ecosystem have not substantially intersected thus far, despite sharing a commitment to decentralization. The Ethereum ecosystem has largely focused on advancing and scaling its blockchain technology, while the DID ecosystem has been dedicated to developing standards and protocols for regulating digital identities. Consequently, opportunities for synergy between these two ecosystems have remained scarce.

We view the Three Transitions as a unique opportunity to foster better collaboration between the Decentralized Identity and Ethereum ecosystems.

Acknowledgments

Gratitude is extended to Eugenio Reggianini ([email protected]) for proofreading the manuscript and contributing valuable content.