Why does Web3.0 need blockchain?
As the core carrier for the evolution of organizations and the distribution of benefits in Web3.0 applications, blockchain technology is an indispensable component of Web3.0 applications. Web3.0 needs blockchain.This article is sourced from Web3 Explorer, authored by Mike and Lester.
Introduction
This article is the second in the "Web3.0 Explorer" series, the first being: "Sorting Out the Concept of Web3.0" (Rhythm Blockbeats has reprinted the full text, see link). This article will continue to explore the ideas from the previous one. Due to the author's limited expertise and the fact that the industry is still in its developmental infancy, many parts of this article will only be briefly mentioned and not deeply explored.
Let’s briefly review the core ideas from the previous article:
● Web3.0 is a set of open protocol clusters. Based on open protocols, it can stimulate strong innovation capabilities from all parties.
● The core issue that Web3.0 addresses is the distribution of benefits among platforms. It breaks the monopoly of large intermediary platforms caused by Web2.0, allowing value to be smoothly distributed to every value creator within the platform. Web3.0 will still have (large) platforms, but these platforms will be collectively owned by the community.
Web2.0 platforms are owned by companies, while Web3.0 platforms are owned by communities.
The refinement of this concept is illustrated as follows:
Web2.0 Platform Illustration
Web3.0 Platform Illustration
Compared to Web2.0 platforms, the core components of Web3.0 platforms include the following participants:
● Community Validators/Nodes: Maintainers of the platform network, operators of underlying blockchain nodes, and validators. They provide service security.
● Community Contributors: Including community developers, promoters, etc. They contribute directly to the project.
● All other value contributors: Including but not limited to platform content contributors. Value contributors also include end consumers.
In other words, for Web3.0 platforms, they are no longer owned by a single company; there is an evolution in the organizational form.
Evolution of Organizational Forms
For platforms, the evolution of organizational forms is comprehensive: it includes both internal organizational evolution and external relational evolution. The terms we mention below: project, platform, application, Web3.0 App, unless otherwise specified, all express the same meaning.
Let’s first discuss the internal organizational evolution of projects.
Projects will maintain a streamlined team size, containing only the most necessary components:
● Core management team
● Core R&D personnel
● Core developer community operation personnel
● Core marketing personnel
● Core design personnel
● Necessary other staff
Apart from the core personnel mentioned above, all positions can be open to the community. This means the community can participate in the advancement of the project together. For example:
● As it is open-source code, community developers can contribute code, fix bugs, etc. There can be appropriate bounty support for these developers.
● Community developers can apply for and implement entire functionalities. The project team can issue tasks in the form of issues and grant them to community developers for development.
● Some community KOLs can be established around the core team to help operate the entire community. There can be some incentive measures as appropriate.
● All participating validator nodes can voluntarily help promote the project. Validators themselves have incentives and do not need additional incentives.
Adopting this collaborative form with the community can change the traditional enterprise R&D and marketing strategies. In other words, the corporate structure may be impacted.
We have conducted some analysis on project costs:
● Retaining only the core team can significantly reduce human resource costs.
● There may not even be a need for a centralized office, or only a very small office is required, which can also save costs.
● Early community participation can gather more people's needs, leading to better product design and reduced design costs.
● Strong collaboration with the community can greatly save marketing expenses and early public testing costs.
● Strong collaboration with the community and good interaction can enhance the efficiency of bug fixes and feature upgrades, reducing R&D costs.
● As long as the product meets or approaches expected goals, strong community engagement will lead every user to voluntarily spread the word, easily forming positive network effects and reducing marketing costs.
These saved costs can be allocated to the true value creators on the platform.
Next, let’s discuss the changes in the relationship between projects and users.
● In Web3.0 platforms, users contribute content or data on the platform, creating value for the platform. The exact amount of this value can be quantitatively assessed (though not completely accurately), and this assessment is generally not real-time or pre-set. The benefits generated from this value will ultimately be distributed to users in some form.
● This quantitative metric and the accompanying calculation methods will be recorded in a completely open manner, clearly and accurately, and executed in a reliable and trustworthy manner.
● The platform and users truly merge into one, with users willing to create value for the platform, and the platform clearly and reliably rewarding users.
Now let’s discuss the changes in the relationship between projects and capital providers.
● Traditional angel rounds, seed rounds, and the ABCDE IPO route will no longer be effective in Web3.0 platforms. Generally speaking, new project forms will be sufficient up to the B round.
● The proportion of investors in the project will not be too large. Specific values will vary by project.
● The proportion of core team shares in the project will not be too large. Specific values will vary by project.
● The distribution ratio of project benefits will be allocated as much as possible to the value creators within the platform.
In other words, once the platform reaches a stable and mature stage, the primary service target of the platform itself will be the value creators of the platform, rather than the major shareholders of investors in Web2.0. Ultimately, only impact investments will remain, as referenced in "Thin Heads and Fat Tails: Understanding the Crypto Reinvention of Capitalism."
It is important to note that when we say the community owns the platform, we do not mean to completely dismantle the team and fully utilize the community for decentralized project operations. The founding team's shareholding does not need to be too large, but its role remains very important. The comprehensive capabilities of the founding team are still the primary factor in whether a Web3.0 project can succeed.
Throughout the development of the project, the founding team plays a core role in promotion and decision-making. Completely decentralized on-chain governance is not advisable, as it is extremely inefficient. We cannot jump from one extreme to another. If human society could solve all problems through voting, then human society would not be so complex.
We can even refer to this organizational governance form as weakly decentralized governance.
Earlier, we mentioned that the organizational form of Web3.0 projects (compared to Web2.0 projects) will undergo some changes. The distribution of benefits is closely related to the organizational form. Is there any tool that can support this new organizational structure? New models call for new solutions.
The Emergence of Blockchain
Blockchain actually provides two core capabilities:
● A more equitable and open way to participate, which is the openness of organizational forms.
● Assets are settled by contracts and circulate reliably and without barriers.
These two capabilities are built on various fundamental characteristics of blockchain, and since we are discussing a higher-level concept, we will not elaborate on the basic characteristics here.
In other words, using blockchain as an underlying benefit distribution system, on top of the blockchain, can:
Support the openness of organizational forms.
Allow all participants to unconditionally trust the distribution method and reach a consensus on it.
Ensure the reliable execution of benefit distribution.
Let’s discuss these three points separately.
- Support the openness of organizational forms.
Blockchain itself has openness.
● Whether it is the PoW consensus protocol or PoS and other consensus protocols, their underlying designs are open, not proprietary.
● The open-source software development model allows everyone in the community to participate in project contributions at a low cost.
● The open-source software development model allows project content/algorithms to be openly audited and verified by various institutions.
● The open-source software development model allows project decisions to be publicly scrutinized and participated in by everyone.
Therefore, Web3.0 systems based on blockchain infrastructure inherently embrace openness. On top of blockchain systems, effective new types of open organizational forms suitable for Web3.0 characteristics can be established.
- Allow all participants to unconditionally trust the distribution method and reach a consensus on it.
Due to the openness of the protocol (code), the protocol content can be unconditionally verified by all parties. The distribution method is part of the overall protocol and is therefore also unconditionally trusted by all parties. The content of the protocol can change through governance, and each change will be openly and clearly presented in the protocol. The distribution method will maintain stability for a certain period, and changes will not be particularly frequent. As all parties trust the protocol, consensus is reached.
3. Ensure the reliable execution of benefit distribution.
Once the distribution rules are clearly defined, they will be implemented in on-chain code. The basic characteristics of blockchain ensure that on-chain code is executed securely and reliably across all nodes. If there are changes to the distribution rules, they will also be updated on-chain, and all nodes will upgrade the protocol, with the consensus protocol among nodes ensuring that the new upgrades are executed securely and reliably.
In summary, blockchain is crucial for Web3.0 and is an essential infrastructure for Web3.0 applications.
It should be noted that blockchain technology itself may have other uses in other fields, but these are not the subject of this discussion.
The Token System of Web3.0
As previously discussed, blockchain is the infrastructure for the organizational form and benefit distribution of Web3.0 applications, which implicitly includes two basic elements:
● Account system
● Token system
Accounts are used to distinguish participating entities, and Web3.0 App Tokens correspond to traditional options/stocks. As a means to encourage community participation, each Web3.0 App blockchain can have its own Token. Especially for validator node participants, obtaining the Native Token of a Web3.0 App is almost a necessary incentive.
Under open protocols, to attract other nodes to validate and provide security services, there are costs involved for these node participants. There must be some mechanism to incentivize them and ensure a certain profit to keep this open system running smoothly. From this perspective, local Tokens are essential for Web3.0 Apps.
Similar to traditional sovereign currencies having exchange rates, different Web3 App Tokens also have exchange rates. Generally, they can be converted based on stable dollars.
Similar to the salary plus options model of traditional Web2.0 companies, the local Token of Web3.0 corresponds to options, and there should also be a Stable Coin for the project's daily operational income and expenses. This Stable Coin should be commonly used stablecoins like USDT, USDC, etc., rather than a Native Stable Coin issued by the project itself; the project should not issue a non-universal Stable Coin.
The acquisition of Stable Coins in Web3.0 App projects can only occur through one of the following forms:
● Investment from investors
● Donations from donors
● Loans
● Income from the project's external economic activities
The expenditures of Stable Coins in the project include but are not limited to the following forms:
● Project R&D expenses
● Project promotion expenses
● Project operational expenses
● Project raw material supplier expenses
● Community project support expenses
● …
Each Web3.0 App should design its own economic system (this statement is somewhat redundant, as each Web2.0 App also needs to design its own economic system, commonly known as a business model. Relying on love for power is ultimately unsustainable). In other words, the economic system is part of the underlying mechanism of a project. Web3.0 Apps based on blockchain infrastructure can design their economic systems more flexibly, stimulating more innovation in this field.
However, blockchain is not a panacea.
Limitations of Blockchain
From its inception, blockchain has had another name—distributed ledger. A ledger is a book that records transaction (economic activity) information. So, can we state that blockchain should only handle matters related to economic activities?
Looking at the history of blockchain development (starting from 2008), you will find that almost all effective innovations belong to the economic and financial fields. There have been many attempts to extend blockchain to other fields, but the results have been meager. It is worth considering whether there is an underlying logical principle at work.
Applying blockchain to other fields will encounter some principled limitations.
Limitation 1: Low efficiency (energy consumption ratio) of multi-node redundant calculations, and extremely high redundancy in multi-node storage.
Assuming our blockchain has 100 nodes, compared to traditional centralized services, each logical calculation needs to be computed 100 times, consuming 100 times (or more) the energy of centralized services. If there are more nodes, the energy consumption will increase further. Storage is similar; for traditional centralized databases, with disaster recovery backup services, it counts as 5 copies.
In contrast, blockchain storage means 100 nodes equate to 100 copies, which is 20 times more than traditional centralized database storage. If more nodes participate, this multiple increases.
Limitation 2: Low storage space efficiency.
Due to encryption and proof requirements, blockchain state storage uses structures like MPT, which occupy a relatively large amount of storage space, leading to low economic efficiency.
Limitation 3: Low query efficiency, even very weak.
Transactions are stored in blocks in a chain, and states are stored in MPT structure KV databases. Unlike traditional SQL databases, the storage method of blockchain has weak query capabilities and low efficiency.
Traditional SQL databases have done extensive work to optimize storage and query for structured data, and decades of development have reached a very mature stage. New advancements are also innovating in areas like distributed scaling, ensuring seamless scaling while maintaining simplicity, consistency, and efficiency in queries. The RPC interface generally provided by blockchain can only implement the simplest query functions.
Due to the above limitations, it is unrealistic to intend to use blockchain as a universally applicable distributed database.
From another perspective, the information in this world, aside from economic affairs, includes various layers of information. For example, a cup. Its shape, size, color, weight, whether it is transparent, whether it has a lid, the ratio of the lid to the cup body, the cup's capacity, the material of the cup, whether it is glass, stainless steel, or plastic.
Can it withstand high temperatures? If it is stainless steel, is it 304? How many impurities are there? What is the production date of the cup? Where was it shipped from? Which courier company delivered it? When was it received? What is the printing process on the cup? What words are printed on it? What color is the pattern? Who is the designer? What material is the rubber pad between the cup body and lid? What is its expiration date? Is it used at home, in the office, or in the car? Is it mainly used for drinking water, coffee, or tea?
Is the cup easy to clean? Does tea easily accumulate in the cup? How is the thermal conductivity of the cup? Does it have an insulating pad? Is it one of a set of cups? If so, do its sibling cups differ from it? If one is broken, is there a replacement policy? After adding hot water, what is the expansion rate of the cup? Not to mention the molecular kinematics data in the cup wall after adding hot water. And so on, and so forth. Expanding from one object, information at various levels is endless.
This information is the inherent property of the object, or its intrinsic property. It is unrelated to economic affairs; it is the information of the object itself. Economics is an external property, or social property. Economics is a product of society.
The limitations of blockchain prevent it from storing these endless inherent property data of objects, and it should only be used to store data related to economic affairs. This also echoes the initial name of distributed ledger.
Web3.0 App System Architecture
If complete information cannot be stored on the blockchain, then where should it be stored? The industry has explored this area extensively. For example, the IPFS project aims for distributed storage; the Arweave project aims for permanent storage. They can work in conjunction with blockchain by storing a hash value of an external data blob in the blockchain's account and transaction data-related objects, achieving data association and relationship binding.
This model has already been adopted by many projects. We will refer to this type of infrastructure used for storing large amounts of data as distributed storage or Distributed Storage (DS).
However, this model still faces many detailed issues:
● It must be stable and durable. Since it is associated via Hash, the Hash value must remain fixed and always valid. This places high demands on these DS projects, requiring data to be permanently valid, Hash values to remain unchanged, and no conflicting Hashes.
● Access efficiency must be high. These DS projects should support data storage and access efficiency well, with low latency.
● Access costs cannot be too high. The costs of data storage and access must not be too high; otherwise, it cannot truly be popularized.
● Access must be convenient. Easy access will allow various projects to quickly integrate and establish a DS service ecosystem.
Many projects in the industry are exploring these aspects, and this seems to be a reasonable direction.
This separation of data will bring changes to software architecture. The storage and on-chain logic processing of blockchain should only be responsible for economic affairs-related business; other data and business should be processed off-chain. The reasons are as follows:
● Depositing and retrieving data from DS are network operations and asynchronous requests. The return time of such requests has a considerable degree of uncertainty, potentially differing by 2 or 3 orders of magnitude compared to local requests. Therefore, such operations are not suitable for on-chain processing and should be handled off-chain.
● The computation and processing of a large amount of non-economic data may take a significant amount of time, and this processing should be executed off-chain.
If the results of off-chain processing are related to economic affairs, they should be submitted to the chain for subsequent processing. If they are unrelated to economic affairs, they should be directly stored and accessed from DS.
Thus, there are now two logical processing engines: one on-chain and one off-chain. How these two engines can perfectly collaborate, maintain, and upgrade versions is a significant issue. We see that the industry is beginning to have corresponding solutions. For example, the Off-Chain Worker (OCW) in Substrate aims to solve the integration and maintenance issues.
In the entire system, to improve execution efficiency and stability, load balancing, caching layers, and other components may also be needed.
Next, we will illustrate the system architecture of Web2.0 Apps and Web3.0 Apps through comparison to help readers understand more clearly.
The architecture of Web2.0 Apps centers around databases. The operational flow is as follows:
● Users access the service address. DNS or IP locates to the gateway;
● The request passes through the gateway and enters the service logic;
● The service logic interacts with the database to store, retrieve, or update data;
● The service logic returns the processing result to the gateway;
● The gateway returns the result to the user;
● Additionally, based on the raw data from the DB, there can be another branch process for big data analysis, mining, AI training, etc.
The system architecture of Web3.0 Apps centers around Blockchain and Distributed Storage. The operational flow is as follows:
● Users access the service address. Distributed DNS (e.g., IPFS's IPNS, Arweave's DNS Gateway, etc.) locates to the gateway;
● The request passes through the gateway and enters the service logic (Off-Chain Worker and indexing service);
● The service logic interacts with DS to store, retrieve, or update data. When necessary, it interacts with the blockchain to send transactions, update states, and obtain results;
● The service logic returns the processing result to the gateway;
● The gateway returns the result to the user;
● Additionally, based on the raw data from distributed storage, there can be another branch process for big data analysis, mining, AI training, etc. In the Web3.0 scenario, this analysis can be conducted by third-party big data AI services for more professional processing and analysis.
Here, we clearly present a system architecture for Web3.0 Apps, which shows a certain degree of similarity to the system architecture of Web2.0 Apps. It does not exclude the possibility that Web3.0 Apps can have other architectural models and computational paradigms (such as the Turing tape computational paradigm proposed by Arweave, see: "Blockchain Storage ARWEAVE: Turing Machine's Tape, A New Paradigm of Trusted Computing" and "The Evolution of Consensus: A Journey of Blockchain Application Paradigm Evolution").
Competition Between Web3.0 and Web2.0
As an emerging entity, Web3.0 will inevitably compete with the existing robust Web2.0 ecosystem. The speed of development will vary across different industries. Here, we will briefly analyze how Web3.0 can compete with Web2.0.
The competition between Web3.0 and Web2.0 must first maintain consistency or similarity in user experience, which is the starting point of competition.
Simply relying on slogans like distributed, decentralized, more secure, privacy protection, and openness is insufficient to impress the majority of consumers. When it comes to trade-offs between security, privacy, and user experience, the vast majority of users will prioritize user experience (for convenience).
Therefore, Web3.0 applications should also focus on user experience, striving to maintain consistency with the user habits of Web2.0 applications to facilitate a smooth transition to a new and better comprehensive experience. However, it is also essential not to sacrifice the fundamental requirements of Web3.0—security—for the sake of user experience. Overall, the requirements for application development have become higher.
Once a similar competitive starting point is reached, Web3.0 has the following competitive advantages over Web2.0 platforms:
● Traditional business models of Web2.0, such as advertising, memberships, games, etc., can also be used in Web3.0, with some evolutionary changes in form. In these areas, Web3.0 will not lag behind Web2.0.
● Value contributors in Web3.0 platforms can receive clear returns, encouraging users to prefer the new platform over the old one.
● User behavior on the new platform is safer, with better privacy protection, promoting users to use the new platform with more confidence.
● More users mean more data accumulation, ultimately forming an ultimate unfair competitive advantage in data. The article "Thin Heads and Fat Tails: Understanding the Crypto Reinvention of Capitalism" argues that the ultimate unfair competitive advantage arises from the accumulation of data on open platforms and the big data mining and AI training conducted on it, making it impossible for traditional closed Web2.0 companies to compete.
● Web3.0 features both privacy protection and open access at the data level. As a raw data open platform, it can stimulate endless innovations: data processing, big data analysis, AI training, etc. Some of the benefits brought by these innovations can be fed back to the data providers—users. Ultimately, this will form a vast, richly layered, and stable open data ecosystem in Web3.0.
However, in the early stages, there will also be some issues that need to be studied, such as:
● Open data being used by closed proprietary companies without being opened back. This could lead to a period where the product quality of large enterprises still leads over Web3.0 Apps.
● Closed camps will not sit idly by; will the open product form prompt closed proprietary companies to allocate some resources to join the open camp? What do these mean for both the open and closed camps?
● In which areas will Web3.0 first challenge Web2.0 platforms?
● Ultimately, which areas will Web3.0 cover, and which areas are unsuitable for the survival of Web3.0?
The Rent-Seeking Problem of Web3.0 Platforms
If Web3.0 platforms are indeed as competitive as we have analyzed, they may ultimately develop into monopolistic platforms (in a certain field). Theoretically, organizations in a monopolistic position will have the motivation for rent-seeking. So, can Web3.0 platforms cope with this inherent challenge?
The forking and legitimacy requirements of blockchain help address this issue. For detailed discussions on this aspect, see: "The Essence of Cryptographic Protocols is No Longer 'Decentralization', but the Forkability of Blockchain," and "Vitalik: Legitimacy is the Most Scarce Resource in the Crypto Ecosystem." This article will not elaborate further.
Earlier, we provided the system architecture of Web3.0 Apps. Now, in conjunction with the forking nature of blockchain, we actually have an additional requirement: the openness of the DS component.
This means that the data storage component should not be bound to a single blockchain but should allow all forks of this blockchain to have 100% functional access capabilities. This requirement should be established as a preset strategy in the design of the Web3.0 system from the outset. This strategy itself serves as a deterrent to limit the malicious motives of the governance bodies of the Web3.0 system.
Explorations in this area should yield some very interesting results.
Conclusion
This article discusses blockchain as the core carrier for the organizational evolution and benefit distribution of Web3.0 applications, which is an indispensable part of Web3.0; Web3.0 needs blockchain.
This article also briefly explores the system architecture of Web3.0 Apps, the competitive advantages of Web3.0, and the rent-seeking problem of Web3.0 platforms.
References:
"Thin Heads and Fat Tails: Understanding the Crypto Reinvention of Capitalism"
"Blockchain Storage ARWEAVE: Turing Machine's Tape, A New Paradigm of Trusted Computing"
"The Evolution of Consensus: A Journey of Blockchain Application Paradigm Evolution"
"Vitalik: Legitimacy is the Most Scarce Resource in the Crypto Ecosystem"
