Uniting Diverse Ecosystems: The Role of W3C DIDs and VCs in Facilitating Ethereum’s Evolutionary Shifts

12 September 2024

Ethereum Open Community Projects L2 Standards Working Group

Vitalik Buterin highlighted three essential shifts for Ethereum: scaling via L2 rollups to minimize fees, upgrading wallet security through smart contract wallets for improved security and user experience, and enhancing privacy with privacy-preserving measures. This article investigates how the incorporation of W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) can tackle some of these issues by enhancing the management of identities, keys, and addresses, utilizing existing decentralized identity frameworks to help Ethereum’s transition towards a more L2-centered environment.

As Vitalik Buterin discussed in a series of 2023 writings, notably his Three Transitions article, Ethereum is evolving from a nascent experimental technology into a mature tech stack capable of providing an open, global, and permissionless experience for everyday users. Nevertheless, he asserts that there are three principal technical transitions that the stack must undergo, approximately at the same time:

• L2 Scaling Transition: This transition involves shifting the ecosystem to rollups to alleviate the high transaction fees on Ethereum, which have soared to $3.75 and even $82.48 during a market surge.
• Wallet Security Transition: The transition to smart contract wallets (account abstraction) is crucial for improving user comfort and security when managing funds and non-financial assets, moving away from centralized exchanges and individual non-custodial wallets.
• Privacy Transition: It is vital to ensure privacy-preserving transactions and develop additional privacy-preserving mechanisms such as social recovery and identity systems to prevent users from reverting to centralized solutions that provide limited or nearly no privacy.

Vitalik stresses that these transitions are vital and challenging due to the significant coordination required for their execution. He particularly examined the effects of these transitions on the relationship between users and their addresses, payment mechanisms, and key management approaches. The interaction between users and their addresses, along with the management/recovery of keys, poses substantial concerns both technically and in terms of usability – user experience determines success or failure, regardless of the robustness of the underlying technology.

In this article, we will explore these latter issues further and analyze how solutions from a different ecosystem, specifically one concentrating on decentralized identity, often termed self-sovereign identity, can substantially assist with the transitions without necessitating the reinvention of too many elements.

The problem statement in the context of Ethereum’s technical transitions can be succinctly outlined as follows based on Vitalik:

• Complex Payments: These transitions complicate straightforward actions such as making payments, necessitating more information than merely an address, as users must decide which funds to utilize, where to send them, and specific payment instructions often involving identity details.
• Smart Contract Wallets: The introduction of smart contract wallets brings technical challenges that need to be resolved, including ensuring wallets accurately track ETH transferred via smart contract code, including tracking across different networks.
• Privacy Challenges: If implemented, privacy-preserving transactions introduce new difficulties, such as the necessity of a “spending public key” and encrypted data for the recipient to locate and retrieve the payment.
• Identity Changes: The understanding of an “address” will shift, potentially requiring a blend of multiple addresses, encryption keys, and other data for user interactions.

Consequently, these points bring forth the question of how we manage identities, addresses, and their keys in a cohesive manner that does not confuse users or jeopardize the security of their assets.

Considering the aforementioned problem statement, the notion of an “address” within the Ethereum ecosystem is transforming, as the conventional idea of an address as a single cryptographic identifier becomes outdated. Instead, “instructions for how to engage with me” would entail a combination of addresses across multiple Layer 2 (L2) platforms, stealth meta-addresses, encryption keys, and additional data. In his article, Vitalik suggests that one conceivable approach could involve using Ethereum Name Service (ENS) records to encompass all identity information. Sending someone an ENS name such as “alice.eth” would grant them access to all the necessary details for interaction, including payment and privacy-preserving methods. However, this approach has limitations, such as overly linking too much to a name and the inability to utilize trustless counterfactual names, which are critical for sending tokens to newcomers without prior blockchain engagement. Additionally, the ENS system operates on a rent-seeking basis. Therefore, in a broader sense, it is not equitable and does not ensure ongoing ownership of one’s identity; such a situation is untenable. An alternative proposition involves keystore contracts that contain all identity information. These contracts can be conducive to counterfactual settings and are not associated with a single name, allowing for greater flexibility and privacy.

This leads us to the discussion of keys governing “addresses.” In particular, key rotation and key recovery in a multi-address Ethereum ecosystem. Key rotation is gaining importance alongside smart contract wallets and account abstraction wherein the controlling address of a smart contract wallet might change due to a key being rotated or recovered which necessitates a new controlling address. Regardless of whether it involves key rotation or recovery, the conventional approach would entail executing on-chain procedures for each address individually. This method is impractical because of gas expenses, counterfactual addresses, and privacy issues. As mentioned previously, Vitalik recommends the use of keystore contracts that exist in a single location while directing to verification logic across multiple addresses. This would facilitate the creation of a proof of the current spending key for transactions. This necessitates a recovery architecture that distinctly separates verification logic from asset holdings, simplifying the recovery process by requiring only a cross-network proof for recovery.

Within this framework, Decentralized Identifiers can harness keystore contracts to facilitate modular verification logic for contract accounts that authenticate zk proofs through a designated validation module and incorporate a system for conformance in on-chain executions.

Incorporating privacy features, such as secured pointers and zero-knowledge proofs, adds complexity. Nevertheless, it brings potential synergies with keystore contracts for persistent addresses, as the persistent address could be rendered “cloaked” within a zero-knowledge proof.

What implications does this hold for smart contract wallets? Historically, wallets were created to safeguard assets by securing the private key connected to on-chain assets. If a key needed to be modified, the previous one could be revealed safely without concern. However, in a realm governed by zero-knowledge principles, wallets must protect information in addition to assets. The case of Zupass, an identity system based on ZK-SNARK, demonstrates that users can maintain data locally and disclose it only when required. Nonetheless, losing the key to decrypt the data results in losing access to all secured information. Hence, managing encryption keys is becoming increasingly vital. Vitalik proposes that utilizing multiple devices or sharing secrets among (key) “guardians” could help reduce the danger of key loss. However, this method is incompatible for asset recovery owing to the risk of collusion among “guardians.” Ultimately, the notion of an address as the user’s identifier on-chain will need to adapt, necessitating wallets to oversee both asset recovery and encryption key recovery to prevent user overwhelm caused by intricate recovery protocols, often known as poor UX. For instance, Sign In With Ethereum relies on the on-chain address along with the user’s private key controlling that key to create the authentication message. However, this method does not incorporate a one-to-many relationship, nor does it consider a smart contract wallet as the primary representative of the user. Therefore, the verifying entity, often referred to as the relying party, cannot evaluate the scope of the user’s authorization(s) necessary during login, which is crucial based on the features the verifying party provides to the user’s address.

The Three Transitions extend beyond mere technical improvements; they signify profound alterations in how users interact with Ethereum-based frameworks, particularly in identity, key management, and addresses. Consequently, this evolution aims to transform the Ethereum ecosystem from its present configuration into a more accessible and user-friendly platform that emphasizes scalability, security, and usability. Hence, one might naturally inquire: Are there existing tools and frameworks that the community can leverage, especially regarding identity, key management, and privacy, to facilitate these transitions? The answer is undoubtedly affirmative. Particularly, the ecosystem surrounding decentralized identity concepts, along with its standards, frameworks, and several reference implementations, has crafted tools that are immediately applicable within the Ethereum stack.

What Constitutes the Decentralized Identity Ecosystem?

The decentralized identity ecosystem is centered on empowering individuals to manage their digital identities independently of centralized authorities. It utilizes blockchain technology and cryptographic foundations to guarantee privacy, security, and user-centric identity governance. Central to this ecosystem are two fundamental concepts: Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs).

Decentralized Identifiers (DIDs):

DIDs represent a novel kind of identifier that facilitates verifiable, self-sovereign digital identities. These are unique, globally resolvable identifiers linked to a subject, such as a person, organization, or device. DIDs are inherently decentralized, indicating that they do not depend on a central registry or authority for their establishment or management. Instead, they are created and governed by the users or entities acting on their behalf. DIDs generally employ public-key cryptography to guarantee secure interactions and enable the subject to demonstrate ownership and control of their identity while executing specific authorized actions including assertions, authentication, authorization, and encryption.

Verifiable Credentials (VCs):

Verifiable Credentials are digital credentials containing assertions about a subject’s identity, attributes, or qualifications, issued by trustworthy entities known as issuers. VCs are tamper-evidenced and cryptographically signed to ensure their integrity and legitimacy. Notably, VCs are portable, allowing the subject to present them to verifiers, such as service providers or relying parties, without needing those verifiers to reach out to the issuer directly. This capability allows for seamless and privacy-preserving identity verification across varied domains and contexts.

Numerous key stakeholders and organizations are aiding the progress and acceptance of decentralized identity technologies:

• Decentralized Identity Foundation (DIF): DIF is a consortium of organizations that collaborates to develop standards and protocols for decentralized identity systems, fostering interoperability and innovation in the industry.
• World Wide Web Consortium (W3C): W3C operates the Credentials Community Group, instigating work on verifiable credentials and related technologies, alongside the Decentralized Identifier and Verifiable Credentials Working Groups, which are refining the respective specifications
• Hyperledger Indy: Hyperledger Indy is an open-source initiative under the Linux Foundation, aimed at providing resources and libraries for constructing decentralized identity systems.
• Sovrin Foundation: The Sovrin Foundation manages the Sovrin Network, a public permissioned blockchain crafted for decentralized identity governance.
• Microsoft, IBM, and various other technology companies: Several significant tech corporations are actively engaged in developing decentralized identity solutions, contributing to standards formulation, and establishing reference implementations.

Standards are pivotal in ensuring interoperability and alignment within the decentralized identity ecosystem. Some principal standards and reference implementations include:

• Decentralized Identifier (DID) Specification: Outlines the syntax and semantics of DIDs, detailing methods for their creation, resolution, and governance.
• Verifiable Credentials Data Model: Defines the structure and format of verifiable credentials, encompassing JSON-LD contexts for representing assertions.
• DIDComm Messaging Protocol: Facilitates secure, private communication between DIDs employing end-to-end encryption and cryptographic validation.
• SSI (Self-Sovereign Identity) Protocols: Various protocols and frameworks, such as DID Auth, Presentation Exchange, and VC API, support secure interactions and transactions within the self-sovereign identity framework.
• Hyperledger Aries: A framework that furnishes a collection of interoperable components for developing decentralized identity solutions, including agents, wallets, and protocols.
• Privado ID formerly Polygon ID: A suite of tools designed for developers to cultivate secure and trusted relationships between users and applications within Web3. It emphasizes decentralized identity, granting users control over their data. The toolkit is built upon the open-sourced iden3 protocol.
• QuarkID: An open-source DID solution currently implemented on ZKsync Era with digital credentials being issued by the City of Buenos Aires.

Below, we elaborate on how a decentralized identity framework can be effectively employed to address cross-network issues related to identity, address, and key management that were previously outlined.

Utilizing Decentralized Identifiers (DIDs)

Issue: Managing identity for a user across various Ethereum networks presents significant complexity.

DID Solution for Identities:

• DIDs furnish globally distinct identifiers that are resolvable (to their DID Document) and cryptographically verifiable on any blockchain network.
• Each DID is linked to a DID Document, which contains details regarding the connection of a DID with a set of cryptographic keys, the roles these keys can perform such as verification, authentication, authorization, assertion, and encryption, alongside service endpoints like API addresses managed by the keys outlined in the DID Document.
• The association between DIDs and their DID Documents or corresponding cryptographic representations can be stored on any blockchain network, assuring tamper-proof and enduring identity records.

DID Documents for Address Management:

Issue: Users maintain multiple addresses across the Ethereum mainnet, testnets, and Layer 2 solutions, including counterfactual addresses.

DID Document solution:

• A DID document possesses a verificationMethod data property that permits a DID owner or controller to define symmetric and asymmetric cryptographic keys for any preferred curve such as secp256k1 used by Ethereum stacks.
• The verificationMethod for a key also enables the user to designate an ID for the verification method. Typically, this is the DID plus a fragment as stipulated by the DID specification. This fragment allows for two significant functions. Firstly, it lets you specify a network identifier, for instance, “1” if the key is an Ethereum key, and different numbers if that key is not associated with an Ethereum network. Moreover, the fragment can be further extended to indicate whether the key corresponds to a counterfactual address or a smart contract wallet. For instance, “did:ion:1234xxxxddd4444-#1-counter” would signify that the public key identified relates to a counterfactual Ethereum address. Furthermore, if there is a need to distinctly identify an address on Polygon PoS versus Arbitrum One, the “1” could be substituted by the chainId of the target network, e.g., 137 for Polygon PoS.
• Finally, a smart contract wallet can possess its own DID and can be governed by the DIDs of the smart contract wallet owners, where each owner identifies one or more controlling keys for the wallet as specified in their DID document. This aspect allows for two significant enhancements for smart contract wallets – key rotation aka key recovery, and an arbitrary number of controlling keys without exposing those controlling keys.

DID Documents for Key Management including Social Recovery:

DID Solution for Identities:

Issue: The processes for key recovery and key rotation concerning Ethereum addresses, particularly for smart contract wallets, are intricate and not user-friendly.

DID Document solution:

• When a public key linked with a DID needs to be rotated for security or recovery reasons, a user can easily update a DID Document and swap the old public key with a new public key in the verificationMethod using a different controlling key. This key can be one that the user directly manages, or if control has been delegated, one controlled by another user listed as a controller.
• Consequently, this can also be accomplished for a Smart Contract wallet. Every controller can independently modify the key in the verificationMethod associated with their DID. This suffices because the user can generate a cryptographic assertion verifying that the update was executed correctly, which can be submitted to and authenticated by the smart contract wallet.

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

• DID Documents can be portrayed as zero-knowledge

proofs by initially merkelizing their JSON-LD document and subsequently validating Merkle Proofs of the relationships between DID-to-key and DID-to-functional-capability (as represented through one or more cryptographic keys).

• Employing zk-SNARKs, particularly, facilitates the effective verification of cryptographic key assertions on Ethereum networks.
• For instance, the zero-knowledge circuit for a legitimate key rotation update of a DID document would accomplish two objectives: a) confirm that the key being updated is present in the DID document and serves as a controlling key by validating a Merkle proof of 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 be the Merkle Root of the newly merkelized DID Document and the root hash of the previous DID document, while the private inputs would encompass the Merkle proof and the digital signature. The smart contract would merely need to verify the proof, ensure that the previous root hash was recorded, and then substitute the old with the new root hash.
• This presents the benefit that no details are disclosed about which addresses manage the smart contract wallet. Each transaction executed by the smart contract could maintain full anonymity if all submissions to the smart contract include a recursive zero-knowledge proof that verifies that a) the public key associated with the submitting address is a controlling key of the DID that owns the smart contract, and b) that a zero-knowledge proof verifies that the transaction was duly signed by the required quorum of signatures from the owners of the smart contract wallet.

Utilizing Verifiable Credentials (VCs)

Challenge: The entity executing a key operation such as a key rotation or a digital signature for a financial transaction must demonstrate that it is a legitimate entity that complies with all relevant regulations in a jurisdiction with compliance oversight.

VC Solution for Regulatory-Compliant Key Operations:

• W3C VCs permit assertions to be made regarding the subject of the credential, such as “Alice is a legitimate business in Brazil”, or, “This business is a legal entity in the US and registered as a Broker-Dealer”, or, “The legal US entity A is a duly registered Broker-Dealer and is authorized to act on behalf of the legal US entity B”.
• Given the standardized structure and public context reference files that outline the VC standard and specific VC types, each VC can be quickly converted into a zk proof utilizing a standardized and publicly accessible zk circuit. This approach reveals only the legal identity of the VC issuer as the root of trust, such as a KYC provider.
• Such zk proofs, particularly ZK-SNARKs, can be submitted with any transaction and validated within a smart contract, such as a smart contract wallet or a DeFi protocol.
• This facilitates compliant transactions on Ethereum stacks without disclosing any sensitive identity or other pertinent compliance information.

Beneficial Implementations for Ethereum Networks

There are numerous distinct implementations of the W3C DID specification. While many DID methods are not scalable enough or do not easily anchor on a blockchain, several DID methods are suitable for the Ethereum ecosystem – permissionless, blockchain-anchored, scalable, and economical. All of these DID methods are founded on the Sidetree Protocol. The Sidetree Protocol serves as a “Layer 2” DID protocol that can be deployed atop any event anchoring system, including Ethereum, and adheres to W3C guidelines. The Sidetree protocol does not necessitate centralized authorities, unique protocol tokens, reliable intermediaries, or secondary consensus mechanisms. Specifically, the Sidetree protocol delineates a core set of DID PKI state change operations, organized as delta-based Conflict-Free Replicated Data Types (i.e., Create, Update, Recover, or Deactivate), that modify a Decentralized Identifier’s DID Document state.

Thus, by utilizing an Ethereum-based implementation of Sidetree, the Ethereum ecosystem can assure that each user possesses a self-sovereign identity, which is both private and compatible across various L2s and applications.

We are convinced that the incorporation of W3C DIDs and VCs into Ethereum’s framework is essential for navigating the forthcoming transitions. They offer the requisite tools for managing identities, keys, and the security of addresses, as well as ensuring privacy, and are aligned with the decentralized ethos of blockchain technology.

Regrettably, the Ethereum ecosystem and the decentralized identity (DID) ecosystem have not significantly converged, although both emphasize decentralization. The Ethereum ecosystem has primarily focused on enhancing and scaling its blockchain technology, while the DID ecosystem has prioritized the establishment of standards and protocols for managing digital identities. Consequently, collaborative opportunities between these two ecosystems have been scarce.

We perceive the Three Transitions as a chance to alter this dynamic and foster closer collaboration between the Decentralized Identity and Ethereum ecosystems.

Acknowledgments

Special thanks to Eugenio Reggianini ([email protected]) for reviewing the manuscript and contributing significant content.