12 September 2024
Ethereum Open Community Projects L2 Standards Working Group
Vitalik Buterin outlined three essential transitions for Ethereum: scaling via L2 rollups to minimize expenses, improving wallet security through smart contract wallets for enhanced safety and user experience, and progressing privacy with privacy-conserving mechanisms. This article examines how the integration of W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) can tackle some of these issues by refining the handling of identities, keys, and addresses, utilizing existing decentralized identity systems to facilitate Ethereum’s transitions effectively towards a more L2-oriented landscape.
As pointed out by Vitalik Buterin in a series of 2023 publications, particularly his Three Transitions article, Ethereum is evolving from a nascent experimental technology into a robust tech stack that could deliver an open, global, and permissionless experience to everyday users. Nonetheless, he asserts that there are three primary technical transitions that the stack must achieve, largely concurrently:
- L2 Scaling Transition: This entails shifting the ecosystem to rollups in order to mitigate the exorbitant transaction fees on Ethereum, which have soared to $3.75 or even $82.48 during market surges.
- Wallet Security Transition: Adapting to smart contract wallets (account abstraction) is crucial for better user ease and security when managing funds and non-financial assets, moving away from centralized exchanges and standalone non-custodial wallets.
- Privacy Transition: Guaranteeing privacy-preserving fund transfers and developing additional privacy-preserving mechanisms such as social recovery and identity systems is vital to prevent users from turning to centralized solutions that provide little or no privacy.
Vitalik underscores that these transitions are important and arduous due to the substantial coordination needed to execute them. In particular, he addressed the ramifications of these transitions on the relationship between users and addresses, payment systems, and key management strategies. The connection between users and their addresses, as well as key rotation/recovery, represent a significant concern both technically and from a user experience standpoint – user experience (UX) ultimately dictates success or failure, regardless of the quality of the underlying technology.
In this article, we will explore these latter concerns and examine how solutions drawn from another ecosystem, specifically one centered on decentralized identity—often termed self-sovereign identity—can greatly assist with the transitions without reinventing the wheel unnecessarily.
The problem statement regarding Ethereum’s technical transitions can be encapsulated as follows, according to Vitalik:
- Complex Payments: The transitions complicate straightforward actions like making payments, requiring more information than merely an address because the user must assess which funds to utilize, where to send them, and specific payment instructions often necessitating identity information.
- Smart Contract Wallets: Smart Contract wallets introduce technical challenges that must be resolved, such as ensuring wallets can monitor ETH sent by smart contract code, including tracking across various networks.
- Privacy Challenges: Privacy-preserving transactions, when introduced, create new hurdles, requiring a “spending public key” and encrypted details for the recipient to receive the payment and determine how to retrieve it.
- Identity Changes: The notion of an “address” will evolve, potentially necessitating a mix of multiple addresses, encryption keys, and additional data for user interaction.
Thus, these points provoke the inquiry of how best to manage identity, addresses, and their keys collectively, ensuring that the user is not confused and their asset security is maintained.
In light of the aforementioned problem statement, the concept of an “address” within the Ethereum ecosystem is transforming, with the traditional idea of an address as a solitary cryptographic identifier becoming outdated. Instead, “instructions for how to engage with me” will necessitate a combination of addresses across multiple Layer 2 (L2) platforms, stealth meta-addresses, encryption keys, and other relevant data. In his article, Vitalik suggests that one possible method would involve utilizing Ethereum Name Service (ENS) records to encompass all identity details. Sending an ENS name such as “alice.eth” would permit the recipient access to all required interaction specifics, inclusive of payment and privacy-preserving techniques. Nevertheless, this method has its limitations, such as over-attaching identity to a single name and the inability to have trustless counterfactual names, which are crucial for sending tokens to new users without any past blockchain interaction. Moreover, the ENS system operates as a rent-seeking construct. Consequently, it is inherently inequitable and fails to secure ongoing ownership of one’s identity, which is an untenable scenario. An alternate solution involves keystore contracts that retain all identity information. These contracts can accommodate counterfactual scenarios and are detached from a specific name, offering greater flexibility and privacy.
This brings us to the topic of keys managing “addresses”. In particular, key rotation and key recovery in a multi-address Ethereum ecosystem. Key rotation has become an essential feature with smart contract wallets and account abstraction, as the governing address of a smart contract wallet might shift due to key rotation or recovery, necessitating a new governing address. Regardless of key rotation or recovery, the conventional approach would require executing on-chain procedures on each address independently. This is impractical due to gas expenses, counterfactual addresses, and privacy issues. As previously noted, Vitalik advocates for the use of keystore contracts that exist in a singular location and refer to verification logic across different addresses. This would facilitate the creation of proof for the current spending key concerning transactions. This demands a recovery architecture that distinguishes verification logic from asset holdings, streamlining the recovery procedure by requiring merely a cross-network proof for recovery.
In this context, Decentralized Identifiers can utilize keystore contracts to enable modular verification logic for contract accounts, which validates zk proofs via a specific validation module and incorporates a system to normalize onchain executions.
Incorporating privacy enhancements, such as encrypted references and zk proofs, adds to the intricacy. Nevertheless, it presents potential alignments with keystore contracts for persistent addresses, as the permanent address could be “concealed” within a zk proof.
What implications does this have for smart contract wallets? Historically, wallets were crafted to safeguard assets by securing the private key linked with on-chain assets. If a change of key was necessary, the previous one could be safely disclosed without any danger. However, in a zero-knowledge environment, wallets need to safeguard data in addition to assets. The instance of Zupass, a ZK-SNARK-driven identity framework exemplifies that users can retain data locally and disclose it only when required. Nonetheless, the loss of the encryption key for the data leads to forfeiting access to all encrypted information. Thus, managing encryption keys is becoming progressively vital. Vitalik recommends that employing multiple devices or secret sharing among (key) “guardians” could alleviate the risk associated with losing encryption keys. Yet, this method is unsuitable for asset retrieval due to the potential for collusion among “guardians.” Ultimately, the notion of an address as a user’s on-chain identifier must evolve, thus necessitating wallets to manage both asset recovery and encryption key recovery, preventing users from being overwhelmed with convoluted recovery methods, which translates to inadequate UX. For instance, Sign In With Ethereum depends on the onchain address and the user’s private key overseeing that key to create the authentication message. However, there is no concept of a one-to-many relationship in this approach, and no recognition of a smart contract wallet serving as the primary delegate of the user. Consequently, the verifying entity, also referred to as the relying party, cannot evaluate the extent of the required authorization(s) for the user when logging in, which is essential depending on the functionalities that the verifying entity offers to the user address.
The Three Transitions are not merely technical upgrades; they signify profound transformations in how users interact with Ethereum-based stacks, particularly concerning identity, key management, and addresses, thus evolving the Ethereum ecosystem from its present state into a more user-friendly and accessible platform that emphasizes scalability, security, and usability. Hence, it is natural to inquire: Are there tools and frameworks currently accessible that could be leveraged by the community, particularly regarding identity, key management, and privacy to facilitate the transitions? The answer is a resounding yes. Specifically, the ecosystem that has developed around the concept of decentralized identity and its associated standards, frameworks, and numerous reference implementations has generated tools that are readily usable within the Ethereum stack.
What is the Decentralized Identity Ecosystem?
The decentralized identity ecosystem concentrates on empowering individuals with control over their digital identities without dependence on centralized authorities. It utilizes blockchain technology and cryptographic principles to guarantee privacy, security, and user-focused identity management. At the center of this ecosystem are two fundamental concepts: Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs).
Decentralized Identifiers (DIDs):
DIDs are an innovative category 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. DIDs are inherently decentralized, meaning they do not depend on a central registry or authority for their creation or administration. Rather, they are generated and managed by the users or entities acting on their behalf. Typically, DIDs incorporate public-key cryptography to ensure secure interactions and enable the subject to demonstrate ownership and control of their identity while performing specific authorized actions such as assertions, authentication, authorization, and encryption.
Verifiable Credentials are digital credentials that include assertions about a subject’s identity, attributes, or qualifications, issued by trusted entities known as issuers. VCs are tamper-evident and cryptographically signed to guarantee their integrity and authenticity. Significantly, VCs are portable and can be presented by the subject to verifiers, such as service providers or relying parties, without requiring those verifiers to contact the issuer directly. This allows for seamless and privacy-preserving identity verification across various domains and contexts.
Several key contributors and organizations are driving the development and acceptance of decentralized identity technologies:
- Decentralized Identity Foundation (DIF): DIF is a consortium of organizations working together to establish standards and protocols for decentralized identity systems. It promotes interoperability and innovation in the field.
- World Wide Web Consortium (W3C): W3C hosts the Credentials Community Group, which nurtures work on verifiable credentials and related technologies, alongside the Decentralized Identifier and Verifiable Credentials Working Groups, which are refining updates to the respective specifications.
- Hyperledger Indy: Hyperledger Indy is an open-source initiative under the Linux Foundation. Its focus is on providing tools and libraries for constructing decentralized identity systems.
- Sovrin Foundation: The Sovrin Foundation manages the Sovrin Network, a public permissioned blockchain engineered for decentralized identity governance.
- Microsoft, IBM, and other technology firms: Numerous major technology firms are actively participating in the development of decentralized identity solutions, contributing to standardization efforts, and creating reference implementations.
Standards are vital in ensuring interoperability and compatibility within the decentralized identity ecosystem. Some significant standards and reference implementations include:
- “`html
Decentralized Identifier (DID) Specification: Establishes the syntax and semantics of DIDs, outlining techniques for their creation, resolution, and administration. - Verifiable Credentials Data Model: Defines the structure and format of verifiable credentials, which includes JSON-LD contexts for representing assertions.
- 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, including DID Auth, Presentation Exchange, and VC API, enable secure interactions and transactions within the self-sovereign identity framework.
- Hyperledger Aries: A framework that offers a suite of interoperable components for constructing decentralized identity solutions, encompassing agents, wallets, and protocols.
- Privado ID previously Polygon ID: A suite of tools designed for developers to forge secure and trustworthy relationships between users and applications in Web3. It emphasizes decentralized identity, granting users control over their data. The toolkit is founded on the open-source iden3 protocol.
- QuarkID: An open-source DID solution currently deployed on ZKsync Era with digital credentials issued by the City of Buenos Aires.
Below, we outline how a decentralized identity structure can be effectively utilized to address the cross-network challenges regarding identity, address, and key management previously outlined.
Utilizing Decentralized Identifiers (DIDs)
Issue: Managing a user’s identity across an array of Ethereum networks is intricate.
DID Solution for Identities:
- DIDs offer globally unique identifiers that can be resolved (to their DID Document) and verifiable through cryptographic means across any blockchain network.
- Each DID is linked to a DID Document that encompasses details about the relationship of a DID to a collection of cryptographic keys, the actions these keys can perform such as verification, authentication, authorization, assertion, and encryption, as well as service endpoints like API endpoints to addresses managed by the keys outlined in the DID Document.
- The association of DIDs with their respective DID Documents or cryptographic representations can be recorded on any blockchain network, guaranteeing tamper-proof and enduring identity records.
DID Documents for Address Management:
Issue: Users maintain different addresses on the Ethereum mainnet, testnets, and Layer 2 solutions, including counterfactual addresses.
DID Document solution:
- A DID document includes a verificationMethod data property allowing a DID owner or controller to define symmetric and asymmetric cryptographic keys for any preferred curve like secp256k1 used by Ethereum stacks.
- The verificationMethod for a key additionally allows the user to define an ID for the verification method. Typically, this is the DID with a fragment as prescribed by the DID specification. This fragment facilitates two crucial aspects: firstly, it allows the specification of a network identifier, for example, “1” if the key pertains to an Ethereum key, and other numbers if that key is not part of an Ethereum network. Moreover, the fragment can be expanded to indicate if the key is associated with a counterfactual address or a smart contract wallet. For instance, “did:ion:1234xxxxddd4444-#1-counter” signifies that the public key pertains to a counterfactual Ethereum address. Additionally, if there is a need to distinctly identify an address on Polygon PoS vs Arbitrum One, the “1” could be substituted with the chainId of the intended network, e.g., 137 for Polygon PoS.
- Lastly, a smart contract wallet may have its own DID and be managed by the DIDs of the wallet’s owners, where each owner indicates one or more controlling keys for the wallet as described in their DID document. This point enables two significant enhancements for smart contract wallets – key rotation, also known as key recovery, and an unlimited number of controlling keys without the need to disclose those controlling keys.
DID Documents for Key Management including Social Recovery:
DID Solution for Identities:
Issue: Key recovery and key rotation for Ethereum addresses, particularly smart contract wallets, pose complexities and lack user-friendliness.
DID Document solution:
- When a public key linked to a DID needs to be rotated for security or recovery reasons, a user can easily modify a DID Document and replace the outdated public key with a new one in the verificationMethod using another controlling key. This can be a key that the user directly manages, or if control has been delegated, by another user managing a DID designated as controller.
- Consequently, this can also be realized for a Smart Contract wallet. Each controller can independently update the key in the verificationMethod related to their DID. This suffices as the user can generate a cryptographic commitment confirming that the update was executed correctly, which can be presented to and validated by the smart contract wallet.
Privacy (Zero-Knowledge) Aspect of DIDs and DID Documents
- DID Documents can be represented as zero-knowledge
“`- Proofs achieved by initially merkelizing their JSON-LD document, followed by authenticating Merkle Proofs of associations between DID-to-key and DID-to-functional-capability (illustrated through one or several cryptographic keys).
- Utilizing zk-SNARKs, specifically, allows for swift verification of cryptographic key assertions on Ethereum networks.
- For instance, the zero-knowledge circuit for a legitimate key rotation modification of a DID document would execute two tasks: a) confirm that the updating key exists within the DID document and serves as a controlling key by validating a Merkle proof of its inclusion in the DID document and b) authenticate the digital signature of the controlling key over the root hash of the previous DID document. The public inputs to the proof would consist of the Merkle Root of the newly merkelized DID Document and the root hash of the previous DID document, while the private inputs would include the Merkle proof and the digital signature. The smart contract would solely need to validate the proof, ascertain that the old root hash was recorded, and subsequently replace the old root hash with the new one.
- This presents the benefit that no details are disclosed about which addresses oversee the smart contract wallet. Each smart contract wallet transaction could maintain complete anonymity if all transactions presented to the smart contract include a recursive zero-knowledge proof validating that a) the public key associated with the address executing the transaction is a controlling key of the DID that owns the smart contract and b) that a zero-knowledge proof confirming that the transaction was validated by the appropriate quorum of signatures from the smart contract wallet proprietors was successfully verified by a verifier in the circuit.
Utilizing Verifiable Credentials (VCs)
Challenge: The entity conducting a key operation such as key rotation or providing a digital signature for a financial transaction needs to demonstrate that it is a legitimate entity compliant with all relevant regulations for a jurisdiction under compliance supervision.
VC Approach for Compliant Key Operations:
- W3C VCs allow for declarations to be made about the subject of the credential such as “Alice is a legal business in Brazil”, or, “This business is a recognized entity in the US and a registered Broker-Dealer”, or, “The legally recognized US entity A is a registered Broker-Dealer and is duly authorized to act on behalf of the legally recognized US entity B”.
- Due to the standardized format and publicly available reference files that specify the VC standard and distinct VC types, each VC can easily be converted into a zk proof given a standard, publicly accessible zk circuit. Disclosing only the lawful identity of the VC issuer as the trust anchor, such as a KYC provider.
- These zk proofs, specifically ZK-SNARKs, can accompany any transaction and be validated in a smart contract such as a smart contract wallet or a DeFi protocol.
- This facilitates compliant transactions within Ethereum stacks without exposing any sensitive identity or pertinent compliance information.
Beneficial Implementations for Ethereum Networks
There exists a multitude of implementations of the W3C DID specification. While numerous DID methods may not possess the necessary scalability or the ability to be easily anchored on a blockchain, several DID methods align well with the Ethereum ecosystem – being permissionless, blockchain-anchored, scalable, and low-cost. All these DID methods are founded on the Sidetree Protocol. The Sidetree Protocol is a “Layer 2” DID protocol that can be executed atop any event anchoring system, including Ethereum, and adheres to W3C guidelines. The Sidetree protocol does not necessitate centralized entities, unique protocol tokens, trustworthy intermediaries, or secondary consensus processes. In particular, the Sidetree protocol delineates a fundamental set of DID PKI state change operations, organized as delta-based Conflict-Free Replicated Data Types (i.e. Create, Update, Recover, or Deactivate), that alter a Decentralized Identifier’s DID Document state.
Thus, by utilizing an Ethereum-based application of Sidetree, the Ethereum ecosystem can guarantee that each user possesses a self-sovereign identity that is both private and interoperable across various L2s and applications.
We are convinced that integrating W3C DIDs and VCs into Ethereum’s architecture is vital for navigating the forthcoming transitions. They equip the essential instruments for managing identities, keys, and address security and privacy, and are congruent with the decentralized essence of blockchain technology.
Regrettably, the Ethereum ecosystem and the decentralized identity (DID) ecosystem have not significantly intersected, despite both sharing a commitment to decentralization. The Ethereum ecosystem has predominantly focused on enhancing and scaling its blockchain technology, while the DID ecosystem has prioritized establishing standards and protocols for managing digital identities. Consequently, opportunities for synergy between these two realms have been scarce.
We perceive the Three Transitions as a chance to transform this situation and initiate closer collaboration between the Decentralized Identity and Ethereum ecosystems.
Appreciations
Heartfelt thanks to Eugenio Reggianini ([email protected]) for reviewing the manuscript and contributing significant content.
