A Vision of a System Registry for The World Computer

Ethereum wanted to be The World Computer. At least, this is what we first saw when discovering https://www.ethereum.org/ in 2016. Since its inception in 2013 until today, we are however treated to a bare-boned database where the only available “tables” are: addresses (accounts and contracts), blocks, transactions, and events. An Operating System, however, necessitates thousands of types of data in order to function.

Ethereum’s killer use case right now is payments. But it could be even more.

The Trouble of Having a Small Number of Standardized Data Types

Take the classical web that has just a handful of data types: the web page, the hyperlink, the keyword. A web page does not dissect into the meaning of its contents further than a set of keywords (that are only treated as strings).

What follows is the arbitrary adoption of interfaces of meaning by each page creator.

What does this mean for the human user? A lot of effort to browse, search and trying to understand each interface of each resource one is directed to. The current “solution” is to simply use the “state of the art” websites of a handful of companies, that have enough money to create pleasant interfaces. This in itself reduces competition and makes it harder for newcomer web sites to be found and used.

What happens when you need to interact with the interfaces of government, education or legal resources? It may take you a lot of time to find out what you are looking for and how to use their services.

What does this mean for the machine user? The inability for automated systems to navigate the web, other than by trial and error. You can have web crawlers, but not smart and exact navigators.

The Semantic Web was well-positioned to become the System Registry for the Classical Web, but it suffered from non-adoption because it meant a little more work from the side of content creators. It provided thousands of new types and also many types of relations between types. Since the creation of the web in the 90ties, the World Computer that the Web could have delivered uses today only a handful of types.

A New Beginning

Ethereum also promises a World Computer and started to deliver this remarkably well with a Touring-complete environment (at least in terms of expressivity). But years after inception it does not have a type registry and even less something in the way of a System Registry.

We would like to see some Type Registry as a seed from where a System Registry can emerge.

This is why we started an EIP proposal for a Decentralized Type System for EVM (dType): http://eips.ethereum.org/EIPS/eip-1900.

UPDATE: Also see dType Storage Extension, dType Alias, Language Extension, Functions Extension.

A type registry comes with the benefit of reusability of types. Instead of individual projects creating multiple versions of the same type, based on personal needs — and therefore making the chain heavy with redundant bytecode, projects can reuse already deployed types.

By knowing the expected type of an interface, we can display data in rich formats. Imagine a block explorer showing you an array of values stored on the blockchain as a pointer on a geographical map, because it sees that the array has a geopoint type. Or displaying a nice time-series graph, because it knows how to treat this data type:

type Event {
    uint256 timestamp;
    uint256 value;
    string event_name;
}
type EventSeries {
    Event[] events;
    string series_name;
}

The same time series can be displayed as a normal table or spreadsheet, which can be the default UI for any two-dimensional array.

Side note: we should have access to thestruct’s name in the solc compiled ABI. It will make the ABI more specific and easier to find the types used for the inputs and outputs.

We can now have different HTML widgets for different kinds of data and display these widgets programmatically. The user can even choose what display format he wants, based on the existing options. He is not constrained anymore.

This can very well lead to stronger collaboration on UI/UX components that everyone can use. Components that save the user time, because he knows what to expect, instead of forcing him to reason about how a new interface works or agonize whether something is a bug or a feature.

Having a unified type system can also pave the way for machine learning & AI tools to better understand data.

We can go one step further and build our web2 tools to use the types from the registry and unify the centralized and decentralized services step by step.

Type Registry Requirements

The type registry should be a collection of agreed-upon data formats, that everyone can use. It is important to keep it a common good, therefore non-custodial and censorship-resistant. We are creating the backbone of interoperable building blocks, we do not want that backbone corruptible.

A general format for creating types should be agreed upon and provided as a template. Along with recommendations and rules for naming the types (no name squatting or names that don’t define the actual data).

Types can be created and proposed by anyone. Adding new types into the registry should happen as a result of a community consensus, similar in concept as the current Ethereum EIP process. Here is where decentralized governance tools, combined with versioning systems will become more and more needed and we hope to soon see something like this used for dType itself. Open source projects, such as DAOstack, Aragon are making good progress with building governance tools.

The data stored for each type should be enough to ensure:

• anyone can use that type in one’s own contract (e.g. type name, library/contract address, subtypes, and labels)
• anyone can get the source code of a type’s libraries and contracts
• anyone can cache the entire registry data off-chain and build tools based on it (blockchain gives us this for free now)

CRUD operations:

• allow inserting new types if a consensus is reached
• updating types is tricky and can break backward compatibility; we suggest creating a new and better type
• removing types can be done, but only if they are no longer used and only after consensus is reached

A Critical Look

We have seen some of the benefits: eliminating on-chain type definition redundancy, unifying interfaces, UI/UX smart composition, incentivizing automation, better data analysis, interoperability (including web2 — web3).

What are the drawbacks and are they bigger than the advantages?

Like anything that needs consensus and standardization, it comes with the overhead of collaboration and debate. But the entire point of Ethereum is that we need collaboration and debate if we want a fair and better system.

When building something, you will have to see if there are types you can reuse. Or propose a new type. So, it comes at the cost of research — which, by building proper development tools, should be reduced at the cost of a search.

The biggest overhead that one might complain about is the storage cost for the registry itself. Considering the reuse of type libraries, as mentioned above, the cost for the actual type registration transaction is less than adding bytecode to deployed contracts through reinventing the wheel.

Side note: If we are discussing state fees, we might want to make a distinction between data that is of general use (system data) and personal data that anyone can add on the blockchain and only benefits a small subset of people.

If there are more disadvantages that we have not spotted, please comment. This article is meant as an incentive to discuss and think.

In Other Words

We are complaining about bad UI and UX for individual projects, but we need to see that the web itself has a bad UI and UX. Not only that, but it lacks the standardization needed for automation.

If a human user has enough intelligence, patience and time, he can still navigate the web. But an algorithm fails to have the same success. And instead of putting in the effort of collaborating and finding consensus on standards, developers are trying to teach algorithms to have human creativity, based on how humans use the web now. This approach cannot be optimized, because the foundation is flawed.

This is why any successful AI will emerge from companies that have created data representation standards internally, such as Google, Amazon, Facebook. While their effort might make the life of their users easier, it may come at the cost of their freedom. Their tools are black boxes. They can change the rules of the game while the game is in play, without any user consent.

The new web3 will become a reality. The only choice that we have is: do we let it be controlled by black boxed companies with an incentive to control their users’ behavior or do we collaborate and build standards for a fair and transparent system? The long term battle is on our freedom of choice.