Why Blockchain Accounts Matter 2/3: From EOA to UP
In the first part of this series, I wrote about how current account systems are leveraged and how decentralized approaches for sharing data work out. Now it’s time to get into blockchain accounts and how they could become proper houses for such data.
Regular User Accounts on the EVM
As stated before, in the Web3 data scheme, encryption is used as a private key to seal and verify the information. A basic framework is needed so they can become accounts that may develop into digital identities. On the world’s most extensive programmable blockchain protocol, Ethereum’s EVM, a minimal user account, is called an Externally Owned Account (EOA). Compared to the previously described public and private keys, an EOA also derives an address from the public part of the key, under which the user can be reached. The address then serves as an identifier. Creating an EOA happens offline, free of charge, and can be repeated as often as needed to create new accounts. They do not consume any storage space in the network and are only referenced with data during the initial action.
Every action in the network must be signed via such an EOA before it can be executed. Critically, however, there is only one EOA for each private key, which is mandatory for participation in the network. As blockchain technology has become prevalent in the financial market, the term “wallet” has quickly become common for applications that manage these EOAs. The initial setup involves creating a list of words, called the seed phrase, which then serves as a backup for the private key. If this is lost, the assets held cannot be recovered, and further participation under that user account is precluded. The dilemma makes the current user connection very complicated and not very future-proof. Securing one’s complete identity with only one static password (the seed phrase) would be grossly negligent. Another letdown: They don’t come with glandular permission. All private keys have direct admin rights. Users often split data sets across multiple EOAs to lower risks.
Alternative methods already provide relief when storing high assets and reduce the importance of keys. Multiple EOAs are needed to act on multi-sig applications, such as Safe. However, these are targeted at a group of individuals. Accepting everyday things regarding a single, separate identity with different personalities sounds strange in this context. But there is a second, much more serious problem: It is impossible to natively connect user-based information to the public address of the EOA, as we are used to doing on social media these days. Accordingly, user-friendly interaction based on the protocol layer is only sporadically possible without further concepts.
Current Problems of Blockchain Adaptation
Mass-scale identity management requires multiple options for recovery, rights assignment, and linking to public user information. However, aside from problems with scaling and user accounts, other issues hinder widespread connectivity.
Immediately after setting up a wallet, users must connect to a crypto exchange, as no actions can be taken on the network without depositing value. However, verification on these exchange sites can take days, among other things. Once one is allowed to interact, there are no safeguards for incorrect data entry. Mistakes are irrevocable if one has transferred values or given the wrong receiving address during data transfer. A far more significant concern is the lack of consensus on spam protection. Especially when digital goods or certificates are account-bound, i.e., cannot be transferred, the counterpart should be able to react to it.
But where the protocol is a good foundation, further layers of abstraction can be added. Modern blockchains have a programmable application layer-so does EVM. These programs are usually called smart contracts and are deployed and executed on the blockchain computer when the EOA, as initiator, starts a particular transaction process. Smart Contracts have addresses, just like EOAs themselves, but come at a network cost because they require storage and computing power. Compared to centralized Web2 structures that keep the data undercover, the public backend of such programmable smart contracts is decoupled from the front end. It’s a great enabler for development as everyone can build their implementation. However, like the chain in the network, smart contracts are final in their functionality once implemented. Only individual values of parameters can change subsequently. Ideally, however, accounts should be extensible and dynamic, requiring new clever methods of storage.
To better understand why this, in particular, is a challenge to develop blockchain accounts for the masses, we can look at the Ethereum Name Service (ENS) based on smart contracts. The idea of ENS stems from the web we use today. Instead of typing in the address of a website’s server, we use domains that resolve it into human-readable text. As long as the user has purchased the domain, it can reference any address. ENS provides the same functionality for blockchain addresses. The domain can add information like social media links, email addresses, or a profile picture. They are handy for quickly remembering addresses but also have several drawbacks for account management. The implementation cannot restore domains, and only a statically limited and predefined amount of information can be appended. Additionally, the payment to keep the name is a hurdle severely affecting identities. When the subscription expires, all historical actions on the network no longer carry the original name, and users lose any reputation that was associated with it. Worst of all, others can repurchase the name and adopt the historically associated identity.
Insights into Universal Profiles
As concepts and problems were seen early on, using smart contracts as the center for accounts was introduced in 2017 within the Ethereum community called ERC-725. In this, LUKSO founder Fabian Vogelsteller published the proposal to use EOAs merely as intenders of a higher-level, abstracted account for any form of entity. This way, one can use and exchange a variety of EOAs on different devices but outwardly speak as one identity. Some examples could be storing the controllers within a Ledger device as a backup or only having a controller valid for a certain time. This could be a good idea for onboarding, where the user takes over control afterward. The standard is divided into two parts: One for executing program code or creating new smart contracts, and the other defines a storage list with keys and values. This list exists only as a parameter and can be filled with any data elements (including VCs), making the handling extremely flexible. With the vast potential in mind for a drastically new economy, the LUKSO project evolved and tackled adoption problems at the application level. It’s an ecosystem based on public generic and modular smart contracts that can be used for all Ethereum networks and various use cases.
Building on Standardization
Standardization plays a significant role in blockchain networks for several reasons: more transparency, collaboration on code, efficiency in development, and much better implementation of new features and improvements, as many people assure code quality. As I explained earlier, open source fosters collaboration among developers and organizations working on blockchain networks, leading to the rapid development of new ideas and innovative solutions to address evolving needs. They can ensure that different blockchain ecosystem components can interact seamlessly and modularly while building network effects and trust simultaneously.
In its standard ecosystem, ERC725 translated to the LPS0, including the enrichment with different modular standards to improve user interactions. Using the Universal Receiver standard, accounts can receive notifications about incoming and outgoing actions. To these, developers can attach custom flows and behaviors. An example would be rejecting or approving certain digital goods or currency transactions. Redirects or blocklists to reduce spam are also conceivable. If the recipient does not accept certain payments, they could be sent back to the original address. However, should the transaction occur, digital goods are also written directly to the profile as a reference until the user has spent that currency or no longer owns the object. This feature is a milestone for the infrastructure of economies of data in blockchain networks. Collective viewing of currencies was previously only possible for centralized services that scan the blockchain and display transactions in a readable format. Now, blockchain programs can act completely decentralized by directly querying the addresses of accounts with a simple call.
Another critical point is the Key Manager, via which it is possible to give the EOAs different roles and rights. Until now, these simple accounts could only cover full access and offered little security for managing content. By default, the Key Manager has nine permissions but can adapt any behavior through its interface and even be attached to other smart contracts, such as tokens with governance.
Standards for specifying the memory register are also included. Storage space is only helpful to some if it is known how to access and interpret this data. A generic scheme for reading and writing guarantees that the data is readable in an automated way. Since the storage space of the blockchain is very scarce, the information here is decoded according to a predefined pattern. The suitably developed ERC-725 library for developers makes it child’s play for people to deal with those standards. Another criticism of current goods on a blockchain is that their connections can be verified, but often not the attached data itself. To this end, this type of smart contract has a standardized hash key that indicates whether the original information is still unaltered.
The presented storage concept is also used for entity metadata. An ERC725 account can be enriched with user information. This enhancement is called Universal Profile and combines publicly viewable information, and the account people are used to from current social media. However, the same feature was designed for exchangeable and unique goods on the blockchain to allow rich, goods-related metadata. Here, multiple sources of information and media, names or descriptions can be attached, and even profiles of numerous artists can be handled. These profiles could enter the value chain of the digital good in the long run by utilizing royalties. If there is a link with the Key Manager, rights assignments for subsequent content modification can also be implemented here. All standardizations for digital assets were adapted to the level of user-friendliness to do justice to the newly created account functionalities. Among other things, these include notifications, the collected transfer of goods, but also new security aspects.
The approach of the Universal Profile can be cited as „public first, private second, “ as the account can already have general information as in regular social media apps. Later, services will utilize the convenient structure underneath to dock private claims onto them or even stay fully anonymized. As David Silverman said in his talk: “If you build a project for private purposes first, it’s locked in, and going public would not be an option. So being public and flexible is better for placing directions and power into developers’ hands, not making decisions for them.”
Whether it’s decentralized organizations, applications, or the metaverse: There is also a lot of hype around social applications. It can be assumed that many future data transfers will occur via decentralized user accounts, making navigating difficult. Universal Profiles can create multiple linked instances, so-called vaults, to organize data and assets. These behave like subfolders of a profile. Not only can they be used to sort a person’s possessions or provide additional security, but they also allow trusted applications to be written to specific profile subfolders. Users can enjoy digital software without worrying about additional account handling. This concept can be bundled with a separate standardization for relay services. In these, transactions are not sent directly from the account to the blockchain but are passed to an external service that executes them on behalf of the user. The actions remain protected by cryptographic signatures, but the user no longer has to pay for transactions directly. A new market will likely develop to allow users to participate in the network entirely without their crypto assets. The concepts may resemble mobile phone providers’ monthly usable data volume. In return, users can use advertising, free-to-play concepts, or subscription models. Frequent users can still manage their currency, of course. All these functions of the LUKSO ecosystem can be operated via an extension in the browser or the mobile apps already under development.
New Primary Networks for the Economy
The project starts on its blockchain, similar to the current Ethereum network or Gnosis blockchain. At LUKSO, the entry into the network works via the abstracted LSP0 account instead of an EOA to use the complete set of functionality among each other. If users also interacted with EOAs, the counterpart would need more features within their relationships, hindering the network effect of convenience around them. By having separate standalone networks for different economies in the blockchain field, general scalability for mainstream adoption can be securely raised. Additionally, early users can easily be subsidized through lower network participation. Subsidization and entry point convenience could not work out on a settled network.
Despite the low costs and speed of subnetworks for Ethereum itself, the project decided against it from early on as they have certain sacrifices. Docked L2s are governed by multi-sigs and use a centralized way of building blocks. Therefore they are mutable and digital asset states at risk. Another downside of subnetworks is that they are data silos for users, which might get stuck with their assets if transfer costs exceed the asset they wanted to bridge back or if too many users wish to move outside the subnetwork at the same time, resulting in bottlenecking. On that note, only some applications or datasets can be bridged as datasets are too large or cumbersome to wrap up.
Subnetworks are significant for bringing scalability to apps and protocols for temporary interaction durations. However, they do not fit for having generic core accounts imagined as the center of your decentralized identity across Web3. Standalone networks can score with maximum security and interoperability while enabling a landscape for valuable data fields. These could soon be connected across primary networks using Interoperable Ethereum Protocols like the concept of Hashi or read verifiable data from external instances using CCIP. For LSPs, a separate realm and fresh start fit well into the goal of onboarding new users through a blockchain account ecosystem and economy that was impossible before.
Now that I cleared up how regular user accounts work, which problems are related to handling identity, and how LUKSO built out an entire account ecosystem based on enriching the user experience, let’s continue how other networks tackle account abstraction and how this is a substantial pillar for decentralized social networks to grow.
