Ethereum Vision: A System Registry for the World Computer

Editor's Note: This article comes fromEthereum enthusiasts (ID: Ethfans)Editor's Note: This article comes from

Ethereum enthusiasts (ID: Ethfans)

, Author: Loredana Cirstea, translation & proofreading: Wuwei & A Jian, reproduced by Odaily with authorization.

The goal of Ethereum is the global computer, this is the conclusion of our first visit to https://www.ethereum.org/ in 2016. But from its conception in 2013 to today, we still only use it as a bare-metal database with a few usable "tables": addresses (accounts and contracts), blocks, transactions and events. To use it as an operating system would require thousands of data types.

Right now, ethereum's killer app is payments, but it can do so much more.

secondary title

The problem with the small number of standard data types

Take the classic World Wide Web (web) as an example, it has only a few data types: web pages, hyperlinks, keywords. Apart from treating some keywords as strings, web pages know nothing about the text content.

Here's what the interface means for each page creator as seen.

What about when you need to use government, educational sector interfaces, or legal resources? It can wear you down trying to find and use relevant services.

What about machine users? It causes errors in automated systems while browsing the web. So you can only make a web crawler, but you can't browse the web intelligently and accurately.

The Semantic Web is well suited to be the System Registry of the Classical Web. But it would bring extra work on the side of the content producer, so it is not acceptable. It provides a large number of new types as well as types that represent type relationships. Since the World Wide Web was created in the 90's, only a small number of data types can be used with a World Wide Web-based computer.

secondary title

New beginning

Ethereum promises to be the world's computer and provides a Turing-complete environment from the start, which is a great place to start (at least in terms of the expressiveness of the system). Yet years after its creation, Ethereum still does not support type registration, nor does it even have a system registry. We hope to see the data type registry in Ethereum, and then the embryonic form of the system registry will emerge.

As such, we have submitted an EIP, Implementing a Distributed Type System (dType) on the EVM: http://eips.ethereum.org/EIPS/eip-190.

Update: See also dType storage extensions, dType aliases, language extensions, function extensions.

The benefit of the type registry is type reuse. Rather than each project individually creating (different versions of) the same type based on its own needs (making the bytecode on-chain bloated), they can reuse types that have already been deployed to the type registry.

When the interface type is accurately understood, we can present data in a richer form. Imagine a blockchain browser that understands an array of values ​​on-chain as a coordinate type, and is able to render it as a point on a map. Or when it understands the data type, it can render a nice time series graph:

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

This will allow everyone to use well-coordinated UI/UX components. Components save the user time because he will know exactly what the expected result is, instead of being forced to understand how a new interface works or suffering from not being able to tell whether it is a bug or a feature.

A unified type system also prepares machine learning and AI tools for better understanding of data.

We can go a step further and build web2 tools to consume types from registries and gradually unify centralized and decentralized services.

secondary title

Requirements for Type Registry

The data in the type registry should be in a common data format that everyone can use. It is important for a registry to maintain its public-good nature, so it must be non-custodial and censorship-resistant.

• The general way to create a type is to obtain consensus and provide it in the form of a template. At the same time, suggestions and rules for type naming should be issued (to avoid naming conflicts or names that do not match actual data).

• Anyone can create and submit types. Adding new types to the registry needs to be the result of community consensus, similar to the current Ethereum EIP process. As a result, we will increasingly urgently need decentralized management tools and their corresponding version management systems. Hope to see these tools used by dType soon. Open source projects like DAOstack and Aragon have made good progress building management tools.

• Each data type should store enough data in the registry to ensure:

Anyone can apply types to their own contracts (eg: type name, library/contract address, subtypes and tags)

• Anyone can get the source code of the type library and contract

• Anyone can cache full registry data off-chain and develop tools based on it (current blockchains already give us this property)

• Allow new types to be added when consensus is reached

Updating types is tricky and may break backwards compatibility, we recommend only adding new, more complete types

Types can be removed, provided they are no longer used and a consensus has been reached

secondary title

dialectical perspective

We have seen some benefits: reduced redundancy of on-chain type definitions, unified interface, smarter UI/UX organization, automatic incentives, better data analysis, better interactivity (including web2 - web3).

So, what are the disadvantages? Will it outweigh the advantages?

As with anything that requires consensus and standardization, these come with an overhead of collaboration and debate. But in the case of Ethereum, we have to collaborate and argue to make a fair and beautiful system.

Sidenote: In case of state fees, we would like to be able to distinguish between general data (system data) and personal data (which can be added to the blockchain by everyone and benefit a small number of people).

other

If there are other deficiencies not pointed out in this article, please add comments. This article is a throwaway.

secondary title

other

When we complain about poor UI and UX experience in different projects, we need to understand that the UI and UX of the World Wide Web itself are not good enough. Not only that, but it lacks the standardization needed for automation.