12 September 2024
Ethereum Open Community Projects L2 Standards Working Group
Vitalik Buterin identified three crucial transitions for Ethereum: scaling through L2 rollups to reduce costs, enhancing wallet security via smart contract wallets for better security and user experience, and advancing privacy through privacy-preserving mechanisms. This article explores how integrating W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) can address some of these challenges by improving the management of identities, keys, and addresses, leveraging existing decentralized identity solutions to aid Ethereum’s transitions efficiently to move to a more L2-based world.
As Vitalik Buterin pointed out in a series of 2023 articles, particularly his Three Transitions article, Ethereum is transitioning from a young experimental technology into a mature tech stack that could bring an open, global, and permissionless experience to average users. However, he believes that there are three major technical transitions that the stack needs to undergo, roughly simultaneously:
- L2 Scaling Transition: This involves moving the ecosystem to rollups to address the high transaction costs on Ethereum, which have reached $3.75 or even $82.48 during a bull run
- Wallet Security Transition: The shift to smart contract wallets (account abstraction) is necessary for enhanced user comfort and security in storing funds and non-financial assets, moving away from centralized exchanges and single non-custodial wallets.
- Privacy Transition: Ensuring privacy-preserving funds transfers and developing other privacy-preserving mechanisms such as social recovery and identity systems is essential to prevent users from resorting to centralized solutions that offer only some or virtually no privacy.
Vitalik emphasizes that these transitions are crucial and challenging due to the intense coordination required to implement them. In particular, he discussed the implications of these transitions on the relationship between users and addresses, payment systems, and key management processes. The relationship between users and their addresses, and key rotation/recovery are a major concern both technically and from a usability point of view – UX determines success or failure no matter how good the underlying technology is.
In this article, we will delve into these latter issues and discuss how solutions from another ecosystem, namely the one focused on decentralized identity, also often referred to as self-sovereign identity, can significantly aid with the transitions without having to reinvent too many wheels.
The problem statement in the context of Ethereum’s technical transitions can be summarized as follows according to Vitalik:
- Complex Payments: The transitions make simple actions like paying someone more complex, requiring more information than just an address because the user needs to determine which funds to use, where to send it to, and specific payment instructions often involving identity information.
- Smart Contract Wallets: Smart Contract wallets add technical issues that need to be addressed, such as ensuring wallets track ETH sent by smart contract code including tracking across networks.
- Privacy Challenges: Privacy-preserving transactions, if implemented, introduce new challenges, such as needing a “spending public key” and encrypted information for the recipient to find the payment and how to pick it up.
- Identity Changes: The concept of an “address” will change, potentially requiring a combination of multiple addresses, encryption keys, and other data to interact with a user.
These points, therefore, raise the question of how we manage identity, addresses, and their keys together, and in a way that does not confuse the user, and compromise the security of their assets.
Given the above problem statement, the concept of an “address” in the Ethereum ecosystem, is evolving, with the traditional idea of an address as a single cryptographic identifier becoming obsolete. Instead, “instructions for how to interact with me” will involve a combination of addresses on multiple Layer 2 (L2) platforms, stealth meta-addresses, encryption keys, and other data. In his article, Vitalik points out that one possible approach would be using the Ethereum Name Service (ENS) records to contain all identity information. Sending someone an ENS name like “alice.eth” would allow them to access all the necessary details for interaction, including payment and privacy-preserving methods. However, this method has drawbacks, such as tying too much to one’s name and the inability to have trustless counterfactual names, which are essential for sending tokens to new users without a prior blockchain interaction. In addition, the ENS system is a rent-seeking system. Therefore, more broadly, it is not equitable and does not guarantee continued ownership of one’s identity; that is not a tenable situation. An alternative solution involves keystore contracts that hold all identity information. These contracts can be counterfactual-friendly and are not tied to a specific name, allowing for more flexibility and privacy.
This brings us to the topic of keys controlling “addresses”. Specifically, key rotation and key recovery in a multi-address Ethereum Ecosystem. Key rotation is just becoming an important feature with smart contract wallets and account abstraction where the controlling address of a smart contract wallet might change because a key is rotated or recovered which necessitates a new controlling address. Irrespective of key rotation or key recovery, the traditional method would be to run onchain-procedures on each address separately. This is impractical due to gas costs, counterfactual addresses, and privacy concerns. As mentioned before, Vitalik proposes the usage of keystore contracts that exist in one location and point to verification logic at different addresses. This would allow the creation of a proof of the current spending key for transactions. This requires a recovery architecture that separates verification logic and asset holdings, simplifying the recovery process by requiring only a cross-network proof for recovery.
In this context, Decentralized Identifiers can leverage keystore contracts to empower a modular verification logic for contract accounts that verifies zk proofs through a specific validation module and embeds a system to standardize onchain executions.
Adding privacy measures, such as encrypted pointers and zk proofs, increases complexity. However, it offers potential synergies with keystore contracts for persistent addresses since the persistent address could be “cloaked” in a zk proof.
What does this all mean for smart contract wallets? Traditionally, wallets were designed to secure assets by protecting the private key associated with on-chain assets. If the key was to be changed, the old one could be safely disclosed without any risk. However, in a zero-knowledge world wallets need to protect data besides assets. The example of Zupass, a ZK-SNARK-based identity system, illustrates that users can hold data locally and only reveal it when necessary. However, losing the data’s encryption key means losing access to all encrypted data. Therefore, the management of encryption keys is also becoming increasingly important. Vitalik suggests that multiple devices or secret sharing among (key) “guardians” could be used to mitigate the risk of losing encryption keys. However, this approach is not suitable for asset recovery due to the potential risk of collusion among “guardians”. Finally, the concept of an address as a user’s on-chain identifier will have to change, and, therefore, wallets must manage both asset recovery and encryption key recovery to avoid overwhelming users with complex recovery processes aka poor UX. For example, Sign In With Ethereum relies on the onchain address and the user’s private key controlling that key to generate the authentication message. However, there is no notion of a one-to-many relationship in this approach, and no notion of a smart contract wallet as the primary delegate of the user. The verifying party, also called the relying party, therefore, cannot assess the scope of the authorization(s) required for the user when logging in which is crucial depending on the functionality the verifying party makes available to the user address.
The Three Transitions are more than just technical enhancements; they represent radical shifts in how users engage with Ethereum-based stacks, especially in the areas of identity, key management, and addresses, thereby, evolving the Ethereum ecosystem from its current state into a more user-friendly and accessible platform that prioritizes scalability, security, and usability. Therefore, one would naturally ask the following question: Are there tools and frameworks already available that could be utilized by the community, especially regarding identity, key management, and privacy to ease the transitions? The answer to that is a definite yes. In particular, the ecosystem that has evolved around the concept of decentralized identity and its standards, frameworks, and numerous reference implementations has produced tooling that is readily usable within the Ethereum stack.
What is the Decentralized Identity Ecosystem?
The decentralized identity ecosystem is focused on giving individuals control over their digital identities without relying on centralized authorities. It leverages blockchain technology and cryptographic principles to ensure privacy, security, and user-centric identity management. At the core of this ecosystem are two key concepts: Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs).
Decentralized Identifiers (DIDs):
DIDs are a new type of identifier that enables verifiable, self-sovereign digital identities. They are unique, globally resolvable identifiers associated with a subject, such as an individual, organization, or device. DIDs are decentralized by design, meaning they do not rely on a central registry or authority for their creation or management. Instead, they are created and controlled by the users or entities acting on their behalf. DIDs typically utilize public-key cryptography to ensure secure interactions and allow the subject to prove ownership and control of their identity and perform specific authorized actions such as assertions, authentication, authorization, and encryption.
Verifiable Credentials (VCs):
Verifiable Credentials are digital credentials that contain claims about a subject’s identity, attributes, or qualifications, issued by trusted entities known as issuers. VCs are tamper-evident and cryptographically signed to ensure their integrity and authenticity. Importantly, VCs are portable and can be presented by the subject to verifiers, such as service providers or relying parties, without the need for those verifiers to contact the issuer directly. This enables seamless and privacy-preserving identity verification across different domains and contexts.
Several key players and organizations are contributing to the development and adoption of decentralized identity technologies:
- Decentralized Identity Foundation (DIF): DIF is a consortium of organizations collaborating to develop standards and protocols for decentralized identity systems. It promotes interoperability and innovation in the space.
- World Wide Web Consortium (W3C): W3C hosts the Credentials Community Group, which incubates work on verifiable credentials and related technologies, and the Decentralized Identifier and Verifiable Credentials Working Groups, which are developing updates to the respective specifications
- Hyperledger Indy: Hyperledger Indy is an open-source project under the Linux Foundation. It is focused on providing tools and libraries for building decentralized identity systems.
- Sovrin Foundation: Sovrin Foundation operates the Sovrin Network, a public permissioned blockchain designed for decentralized identity management.
- Microsoft, IBM, and other tech companies: Several major tech companies are actively involved in developing decentralized identity solutions, contributing to standards development, and building reference implementations.
Standards play a crucial role in ensuring interoperability and compatibility within the decentralized identity ecosystem. Some key standards and reference implementations include:
- Decentralized Identifier (DID) Specification: Defines the syntax and semantics of DIDs, including 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: Enables secure, private communication between DIDs using end-to-end encryption and cryptographic authentication.
- SSI (Self-Sovereign Identity) Protocols: Various protocols and frameworks, such as DID Auth, Presentation Exchange, and VC API, facilitate secure interactions and transactions within the self-sovereign identity paradigm.
- Hyperledger Aries: A framework that provides a set of interoperable components for building decentralized identity solutions, including agents, wallets, and protocols.
- Privado ID former Polygon ID: A set of tools built for developers to create secure and trusted relationships between users and applications in the Web3. It focuses on decentralized identity, giving users control over their data. The toolkit is based on the open-sourced iden3 protocol.
- QuarkID: An open-source DID solution currently deployed on ZKsync Era with digital credentials being issued by the City of Buenos Aires.
Below, we detail how a decentralized identity framework can be successfully applied to the cross-network challenges for identity, address, and key management previously discussed.
Using Decentralized Identifiers (DIDs)
Problem: Managing identity for a user across various Ethereum networks is complex.
DID Solution for Identities:
- DIDs provide globally unique identifiers that are resolvable (to their DID Document) and cryptographically verifiable across any blockchain network.
- Each DID is associated with a DID Document which contains information about the relationship of a DID with a set of cryptographic keys, the functions these keys can perform such as verification, authentication, authorization, assertion, and encryption, as well as service endpoints such as API endpoints to addresses controlled by the keys listed in the DID Document.
- The relationship of DID to their DID Documents or respective cryptographic representations can be stored on any blockchain network, ensuring tamper-proof and persistent identity records.
DID Documents for Address Management:
Problem: Users have different addresses on the Ethereum mainnet, testnets, and Layer 2 solutions, including counterfactual addresses.
DID Document solution:
- A DID document has a verificationMethod data property allowing a DID owner or controller to specify symmetric and asymmetric cryptographic keys for any desired curve such as secp256k1 utilized by Ethereum stacks.
- The verificationMethod for a key also allows the user to specify an ID for the verification method. This is typically the DID plus a fragment as per the DID specification. This fragment allows two very important things. First, it allows you to specify a network identifier, for example, “1” if the key is an Ethereum key, and other numbers if that key is not on an Ethereum network. In addition, the fragment can be extended to indicate if the key belongs to a counterfactual address or a smart contract wallet. For example, “did:ion:1234xxxxddd4444-#1-counter” would indicate that the public key identified belongs to a counterfactual Ethereum address. In addition, if required for certain reasons to separately identify an address on Polygon PoS vs Arbitrum One the “1” could be replaced by the chainId of the target network, e.g. 137 for Polygon PoS.
- Lastly, a smart contract wallet can be given its own DID and controlled 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 last point allows for two major improvements for smart contract wallets – key rotation aka key recovery, and an arbitrary number of controlling keys without revealing those controlling keys
DID Documents for Key Management including Social Recovery:
DID Solution for Identities:
Problem: Key recovery and key rotation for Ethereum addresses, particularly smart contract wallets, are complex and are not user-friendly.
DID Document solution:
- When a public key associated with a DID must be rotated for security or recovery purposes, a user can simply update a DID Document and replace the old public key with a new public key in the verificationMethod using another controlling key. This can be a key the user directly controls, or if control has been delegated, by another user controlling a DID listed as controller.
- Therefore, this can also be achieved for a Smart Contract wallet. Each controller can independently update the key in the verificationMethod associated with their DID. This is enough because the user can produce a cryptographic commitment that the update was done correctly that can be submitted to and verified by the smart contract wallet.
Privacy (Zero-Knowledge) Aspect of DIDs and DID Documents
- DID Documents can be represented as zero-knowledge proofs by first merkelizing their JSON-LD document, and then verifying Merkle Proofs of relationships of DID-to-key and DID-to-functional-capability (as represented through one or more cryptographic keys).
- Using zk-SNARKs, in particular, enables efficient verification of cryptographic key claims on Ethereum networks.
- For example, the zero-knowledge circuit for a valid key rotation update of a DID document would do two things: a) verify that the updating key is in the DID document and is a controlling key by verifying a Merkle proof of inclusion in the DID document and b) verify the digital signature of the controlling key over the root hash of the old DID document. The public inputs to the proof would be the Merkle Root of the new merkelized DID Document and the root hash of the old DID document, and the private inputs would be the Merkle proof and the digital signature. The smart contract would only have to verify the proof, check that the old root hash was registered, and then update the old with the new root hash.
- This has the advantage that no information is leaked about which addresses control the smart contract wallet. Every smart contract wallet transaction could be fully anonymous if all transactions submitted to the smart contract have a recursive zero-knowledge proof that verifies that a) the public key belonging to the address submitting the transaction is a controlling key of the DID that is a smart contract owner and b) that a zero-knowledge proof that the transaction was signed by the correct quorum of signatures of the smart contract wallet owners was properly verified by a verifier in the circuit itself.
Using Verifiable Credentials (VCs)
Problem: The entity performing a key operation such as a key rotation or a digital signature for a financial transaction must prove that it is a legal entity that meets all applicable compliance rules for a jurisdiction that has compliance oversight.
VC Solution for Compliant Key Operations:
- W3C VCs allow assertions to be made about the subject of the credential such as “Alice is a legal enterprise in Brazil”, or, “This enterprise is a legal entity in the US and a registered Broker-Dealer”, or, “The legal US entity A is a legally registered Broker-Dealer and is legally authorized to act on behalf of the legal US entity B”.
- Given the standardized structure and public context reference files that specify the VC standard and specific VC types, each VC can be readily turned into a zk proof given a standardized, and publicly available zk circuit. Revealing only the legal identity of the VC issuer as the root of trust, such as a KYC provider.
- Such zk proofs, in particular, ZK-SNARKs can be submitted with any transaction and verified in a smart contract such as a smart contract wallet or a DeFi protocol.
- This allows for compliant transactions on Ethereum stacks without revealing any sensitive identity or other relevant compliance data.
Useful Implementations for Ethereum Networks
There are dozens of different implementations of the W3C DID specification. While many DID methods are not as scalable as necessary, or not easily anchored on a blockchain, several DID methods fit the bill for the Ethereum ecosystem – permissionless, blockchain-anchored, scalable, and cheap. All of these DID methods are based on the Sidetree Protocol. The Sidetree Protocol is a “Layer 2” DID protocol that can be implemented on top of any event anchoring system, including Ethereum, and is compliant with W3C guidelines. The Sidetree protocol does not require centralized authorities, unique protocol tokens, trustworthy intermediaries, or secondary consensus mechanisms. Specifically, the Sidetree protocol defines a core set of DID PKI state change operations, structured as delta-based Conflict-Free Replicated Data Types (i.e. Create, Update, Recover, or Deactivate), that mutate a Decentralized Identifier’s DID Document state.
Therefore, by leveraging an Ethereum-based implementation of Sidetree, the Ethereum ecosystem can ensure that each user has a self-sovereign identity, that is both private and interoperable across different L2s and applications.
We believe that the integration of W3C DIDs and VCs into Ethereum’s infrastructure is crucial for navigating the upcoming transitions. They provide the necessary tools for managing identities, keys, and address security, and privacy, and are aligned with the decentralized nature of blockchain technology.
Unfortunately, the Ethereum ecosystem and the decentralized identity (DID) ecosystem have not intersected much, though both share a focus on decentralization. The Ethereum ecosystem has primarily concentrated on advancing and scaling its blockchain technology, whereas the DID ecosystem has prioritized developing standards and protocols for governing digital identities. As a result, opportunities for collaboration between these two ecosystems have been limited.
We see the Three Transitions as an opportunity to change this and start a closer collaboration between the Decentralized Identity and Ethereum ecosystems.
Acknowledgments
Special thanks go to Eugenio Reggianini ([email protected]) for proofreading the manuscript and adding important content.
from Ethereum – My Blog https://ift.tt/vfY4SOn
via IFTTT