<\/p>\n
12 September 2024<\/strong><\/p>\n Ethereum Open Community Projects L2 Standards Working Group<\/span><\/a><\/p>\n 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.<\/span><\/p>\n As pointed out by Vitalik Buterin in a series of 2023 publications, particularly his <\/span>Three Transitions article<\/span><\/a>, 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:<\/span><\/p>\n 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 \u2013 user experience (UX) ultimately dictates success or failure, regardless of the quality of the underlying technology.<\/span><\/p>\n In this article, we will explore these latter concerns and examine how solutions drawn from another ecosystem, specifically one centered on decentralized identity\u2014often termed self-sovereign identity\u2014can greatly assist with the transitions without reinventing the wheel unnecessarily.<\/span><\/p>\n The problem statement regarding Ethereum\u2019s technical transitions can be encapsulated as follows, according to <\/span>Vitalik<\/span><\/a>:<\/span><\/p>\n 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.<\/span><\/p>\n In light of the aforementioned problem statement, the concept of an \u201caddress\u201d within the Ethereum ecosystem is transforming, with the traditional idea of an address as a solitary cryptographic identifier becoming outdated. Instead, \u201cinstructions for how to engage with me\u201d 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 \u201calice.eth\u201d 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.<\/span><\/p>\n This brings us to the topic of keys managing \u201caddresses\u201d. 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.<\/span><\/p>\n 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<\/span> to normalize onchain executions<\/span><\/a>.<\/span><\/p>\n 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 \u201cconcealed\u201d within a zk proof.<\/span><\/p>\n 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 <\/span>Zupass, a ZK-SNARK-driven identity framework<\/span><\/a> 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) \u201cguardians\u201d could alleviate the risk associated with losing encryption keys. Yet, this method is unsuitable for asset retrieval due to the potential for collusion among \u201cguardians.\u201d Ultimately, the notion of an address as a user\u2019s 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, <\/span>Sign In With Ethereum<\/span><\/a> depends on the onchain address and the user\u2019s 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.<\/span><\/p>\n 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.<\/span><\/p>\n 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).<\/span><\/p>\n Decentralized Identifiers (DIDs):<\/b><\/a><\/p>\n 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.<\/span><\/p>\n Verifiable Credentials (VCs):<\/b><\/a><\/p>\n Verifiable Credentials are digital credentials that include assertions about a subject\u2019s 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.<\/span><\/p>\n Several key contributors and organizations are driving the development and acceptance of decentralized identity technologies:<\/span><\/p>\n Standards are vital in ensuring interoperability and compatibility within the decentralized identity ecosystem. Some significant standards and reference implementations include:<\/span><\/p>\n 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.<\/span><\/p>\n Issue<\/b>: Managing a user’s identity across an array of Ethereum networks is intricate.<\/span><\/p>\n DID Solution for Identities<\/b>:<\/span><\/p>\n DID Documents for Address Management<\/b>:<\/span><\/p>\n Issue<\/b>: Users maintain different addresses on the Ethereum mainnet, testnets, and Layer 2 solutions, including counterfactual addresses.<\/span><\/p>\n DID Document solution<\/b>:<\/span><\/p>\n DID Documents for Key Management including Social Recovery<\/b>:<\/span><\/p>\n DID Solution for Identities<\/b>:<\/span><\/p>\n Issue<\/b>: Key recovery and key rotation for Ethereum addresses, particularly smart contract wallets, pose complexities and lack user-friendliness.<\/span><\/p>\n DID Document solution:<\/b><\/p>\n Privacy (Zero-Knowledge) Aspect of DIDs and DID Documents<\/b><\/p>\n Challenge<\/b>: 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.<\/span><\/p>\n VC Approach for Compliant Key Operations:<\/b><\/p>\n There exists a multitude of implementations of the <\/span>W3C DID specification<\/span><\/a>. 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 \u2013 being permissionless, blockchain-anchored, scalable, and low-cost. All these DID methods are founded on <\/span>the Sidetree Protocol<\/span><\/a>. The Sidetree Protocol is a \u201cLayer 2\u201d DID protocol that can be executed atop any event anchoring system, including <\/span>Ethereum<\/span><\/a>, 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\u2019s DID Document state.<\/span><\/p>\n 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.<\/span><\/p>\n We are convinced that integrating W3C DIDs and VCs into Ethereum\u2019s 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.<\/span><\/p>\n 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.<\/span><\/p>\n\n
\n
What is the Decentralized Identity Ecosystem?<\/span><\/h2>\n
\n
\n
\nDecentralized Identifier (DID) Specification<\/b><\/a>:<\/b> Establishes the syntax and semantics of DIDs, outlining techniques for their creation, resolution, and administration.<\/span><\/li>\nUtilizing Decentralized Identifiers (DIDs)<\/span><\/h2>\n
\n
\n
\n
\n
\n“`<\/p>\n\n
Utilizing Verifiable Credentials (VCs)<\/span><\/h2>\n
\n
Beneficial Implementations for Ethereum Networks<\/span><\/h2>\n