1 Introduction

The Web3 vision takes blockchain disintermediation to a next level by making it ubiquitous, encompassing not only payments and financial services but also digital identities, data and business models. Where the vision of a ubiquitous integration of emerging technology has become widely known as Internet of Things (IoT), the Web3 narrative can be characterized as the Web of Everything, and even more, the Web of Everything and Everybody, since the idea of being “owned and operated by its users” [1] is the key ingredient of Web3. Although Web3 is still in its infancy, it has gained massive attention by major analysts such as Gartner [2], Forrester [3] and Forbes Technology Council [4] as well as the Harvard Business Review [1, 5, 6], and the expectations are high towards Web3 being “our chance to make a better internet” [1]. In Table 1, we have summarized a series of Web3 characteristics that we find most significant for the current Web3 narrativeFootnote 1 by comparing them to corresponding Web 2.0 characteristics.

Fig. 1.
figure 1

Web3 fundamental components: tree, ledger and cloud.

Full size image

Albeit the current enthusiasm about Web3, we are lost in a state of confusion. The Forbes technology article titles “Why Web3 Is So Confusing”. The Forrester article is titled “Web3 Isn’t Going To Fix The Shortcomings Of Today’s Web”. And when both the Gartner article [2] and the Harvard Business review article [5] are titled “What Is Web3?”, they rather aim at giving an overview of the current Web3 narrative than answering the question. And, actually, since the Web3 does not yet exist, the question of ‘what is Web3’, can only be about overviewing its current narrative. Therefore, for an engineering research endeavor, the question to be asked has to be ‘what will be Web3’?

In this paper, we discuss a potential foundation of Web3 in terms of fundamental components, architectural principles and a Web3 design space. We postulate that any implementation of Web3 can be explained in terms of three fundamental components, i.e., tree, ledger and cloud (Fig. 1) that adhere to a series of Web3 architectural principles and thus form the basis to elaborate the full Web3 design space.

In [9], we have contributed the architecture of the Alphabill platform – a platform for universal asset tokenization, transfer and exchange as a global medium of exchange. In this paper, we discuss Alphabill as an enabler for Web3 – in terms of the suggested Web3 foundation.

Table 1. Most significant Web3 characteristics – compared to Web 2.0.
Full size table

We proceed as follows. In Sect. 2, we provide an outline of the suggested Web3 foundation. In Sect. 3, we briefly sketch the Web3 design space. In Sect. 4, we discuss the Alphabill platform. We finish with a conclusion in Sect. 5.

2 A Web3 Foundation

We postulate that any implementation of Web3 can be explained on the basis of three fundamental components, i.e., tree, ledger and cloud (abbreviated as \(\tau + \lambda + \gamma \)), see Fig. 1, that adhere to a series of Web3 architectural principles and thus form the basis to elaborate the full Web3 design space, compare with Table 2. We say that the Web3 fundamental components together with the Web3 architectural principles and the elaborated Web3 design space form the foundation of Web3.

Table 2. A Web3 foundation.
Full size table

2.1 The Web3 Information Tree

The fundamental component \(\tau \) represents the latest Web3 information as a treeFootnote 2. The tree structure is extended to a graph structure by nodes that contain node addresses and are interpreted as references – as we are used to from hyperlinks [27] and transclusions [27, 28]. Conceptually, the Web3 information is actually a graph. We stay in the tradition of modeling web information as a tree. We do not do so for the sake of tradition in its own right. It is the language-oriented stance of the tree approach that is beneficial for us, when we conceptualize an essential ingredient of Web3: each partition of Web3 defines its own domain-specific language. Furthermore, the tree approach allows for a convenient ad-hoc addressing scheme: paths in the treeFootnote 3.

  • The tree \(\tau \) is a child-ordered, node-colored tree.

Edges, child-ordering and node colors of \(\tau \) are used to express information. We call the color of a node its node information. Depending on the context, we call the color a node also the label of the node (i.e., we use node color, node information and node label as interchangeable). We use the label l of a node v also to identify the sub tree \(\sigma \) that has v as a root, and call l also the label of sub tree \(\sigma \). We understand \(\tau \) as an abstract syntax tree that adheres to a context-free grammar that we call the grammar of \(\tau \)Footnote 4,Footnote 5. We call the language that \(\tau \) belongs to the Web3 base language, denoted by W (the grammar of \(\tau \) is the grammar of W, and \(\tau \in W\)).

The Web3 tree \(\tau \) is partitioned. A partition is a sub tree of \(\tau \). The purpose of a partition is to hold the information of a specific asset or a specific domain. The list of example partitions is sheer endless. Basically, all of the cryptocurrency-based platform visions seen during ICOs (initial coin offerings) in the last decade can be realized as partitions in Web3. Examples of partitions could be: a cryptocurrency, a real-estate tokenization platform [31] (ideally connected to the official cadastre; or even being the official cadastre), an e-procurement system for the public sector [32, 33], a nation-wide healthcare information system [34], a business-to-business vending platform, a particular relational database of a certain company etc. Each partition owns a partition-specific language (that is used describe the content of the partition) and is governed by partition-specific rules.

Figure 2 illustrates an example Web3 tree \(\tau \). The topmost part of \(\tau \) (in Fig. 2, consisting of labels of the form \(\tau x\)) realizes the addresses of the Web3 partitions. Figure 2 depicts three partitions having the addresses \(\tau 1 / \textit{partition}\), \(\tau 4 / \textit{partition}\), and \(\tau 1 / \tau 1.3 / \tau 1.3.2 / \textit{partition}\). Actually, addresses of partitions are not special, each node in the Web3 tree can be addressed, see the address of the node labeled \(\textit{l}_{3}\) in Fig. 2 as an example.

Fig. 2.
figure 2

The Web3 information tree \(\tau \).

Full size image

The Web3 base language W contains a language for describing context-free grammars as a sub-language. Each partition has three child nodes: content, grammar, and rules (see Fig. 2). The grammar node contains a the grammar of the partition. All sub trees of the content node has to adhere to this grammar. Furthermore, W contains a programming language as sub language that allows for establishing rules for sub trees of \(\tau \). This programming language has the same intentions as Bitcoin’s programming language Script and the smart contract [35] languages [36, 37] of other blockchain technologies such as Ethereum’s SolidityFootnote 6. We call this sub language of W simply the Web3 programming language.

The rules node of a partition contains rules that are written in the Web3 programming language. A rule evaluates to true or false and can have side-effects upon its execution. The rules are triggered whenever the content of the partition is about to be changed by a Web3 protocol. Whenever a rule is violated (evaluates to false), the change is rejected. The rules of a partition are used to complete the partition’s context-free grammar, i.e., they are used enforce needed context-sensitive properties of the partition. But the Web3 programming language allows for much more. It allows to access the full protocol history that is reflected in the Web3 ledger \(\lambda \) and, therefore, to access the full version history of \(\tau \) – either directly via \(\lambda \) or indirectly via \(\lambda \) (via hash identifiers provided by \(\lambda \)) by accessing data stored in the cloud \(\gamma \) (\(\gamma \) and \(\lambda \) and options to distribute data over \(\gamma \) and \(\lambda \) will be described in Sect. 2.2).

Actually, the rule-based control of Web3 is much more fine-grained. Rules cannot be only added to partitions, but to any sub tree of \(\tau \), see sub tree \(l_7\) in Fig. 2 for an example. The rules apply to all sub trees of the corresponding (sibling) content node.

Pervasive Digital Rights. In the Web3, digital rights are a pervasive concept. They are so essential for the Web3 vision that the Web3 can be even characterized in terms of them, i.e., as the integration of digital rights exchange into the (application layer) internet protocols. Digital rights express trusted, certified ownership of digital assets. Digital rights manifest in digital signatures of digital assets stored in the Web3 tree \(\tau \). Complex digital rights scenarios can be expressed with the Web3 programming language. The enforcement of digital rights is on a different page. Basic digital rights that are merely about consuming (accessing) digital assets might be enforced (ensured) technologically. However, in general, when digital rights are about re-use of digital assets, they need to be collateralized by appropriate regulations. With the Web3, the notion of digital rights itself seems to become generalized. They are not merely about the utilization of digital assets anymore, instead, they express rights in real-world assets (legal assets or physical assets). Again, such notion of digital rights need to collateralized by regulations. In this strand of Web3, regulations and institutions [38, 39] need to co-evolve [40, 41] with the emerging Web3. The Web3 need to anticipate (conceptually and technologically) such developments.

Access rights represent a basic form of digital rights. Similar to digital rights, access rights are an essential, integral part of the tree. Access right owners are identified via public cryptographic keys. We consider the access rights as part of the rules. Access rights can be established with the Web3 programming language, allowing for arbitrarily complex, dynamic access right management. Practically, we can assume that the Web3 defines an access rights language (that can itself be considered part of the Web3 programming language).

Eric Schmidt and Jared Cohen have explained the “future of identity” [42] in the “new digital age” [43] as follows: “The shift from having one’s identity shaped off-line and projected online to an identity that is fashioned online and experienced off-line will have implications for citizens, states and companies as they navigate the new digital world.” [42] We postulate that the Web3 principle of pervasive digital rights is of utmost significance for changing the concepts of online identities and identities.

2.2 The Ledger and the Cloud

The Web3 tree \(\tau \) is a purely conceptual model. It explains the informational structure of the Web3 and, most importantly, introduces the notion of Web3 partition. The Web3 cloud \(\gamma \) and the Web3 ledger \(\lambda \) together provide the concrete realization of the Web3. The cloud \(\gamma \) stores the full version history of the Web3 tree \(\gamma \). The Web3 ledger \(\lambda \) provides certificates for Web3 information. It is the fully certified complete protocol Web3 log. Occasionally, we therefore call the ledger \(\lambda \) also the Web3 certification ledger

The Web3 cloud and ledger can be implemented as overlay network to any internet protocol stack such as, of course, the TCP/IP protocol stack of today’s Internet. The Web3 tree \(\tau \) manifests merely through application-layer protocols that are kept free from any lower-layer concepts and, therefore, is independent of any changes to lower protocol layers. Today’s dominating Web protocol http relies on IP addresses and is therefore intertwingled with the current Internet protocol stack at the Internet layer. DNS (Domain Name Service) is designed as an aftermath to http. The functioning of today’s Web tree is anchored in trust into the centralized mechanism of IP address allocation – provided by the Internet organizations ICANN (Internet Corporation for Assigned Names and Numbers) and IANA (Internet Assigned Numbers Authority). Trust in today’s Web tree is rooted in trust into ICANN and IANA. The Web3 tree \(\tau \) can gain trust from the Web3 ledger \(\lambda \) in its role as the certification backbone of the Web3. Again, the ledger can be kept free from any lower-layer concepts. It is Web3 cloud component \(\gamma \) that needs to be related to a concrete internet protocol stack when it is realized.

Data Abstraction and Livestreaming. The concept of the Web3 ledger \(\lambda \) can be explained best through two architectural principles that go hand-in-hand with each other: the Web3 data abstraction principle and Web3 livestreaming. Data abstraction is a core software engineering principle [44]. In the context of the Web3 it means, that the Web3 tree \(\gamma \) is manipulated and only manipulated through a set of well-defined Web3 protocols. This is not so in the Web. From the beginning [45], the http protocol had a post method, which allows for adding new data to a Web server. Soon after [46], the http protocol was enriched by a put method that allows for updating a specific web resource. The point is that the post and the put method are rather seldomly used in practice. Instead, Web resources are manipulated by all kinds of means, i.e., direct writes to the file system, mitigated by a web content management system etc. This means that the complete log of Web protocol activities would not reflect at all the actual Web version history.

In our Web3 foundation, it is an architectural principle that all Web3 protocol activities are recorded in the Web3 ledger \(\lambda \) and we call this principle Web3 livestreaming. Of course, this principle makes only sense if the Web3 is always only manipulated through defined Web3 protocols – which is the essence of the Web3 data abstraction principle. We postulate, that the Web3 ledger \(\lambda \) is the only authoritative reference for Web3 content. As such is certified, becoming: the fully certified complete Web3 log.

Following the current state of the art, a natural candidate to implement the Web3 ledger \(\lambda \) is with today’s blockchain technology [18, 47,48,49]. The reason for this is the efficiency of the blockchain data structure. We can assume that verifying a signature is thousand times more costly than computing a hash [9], which leads to the concept of organizing the data in blocks, computing a Merkle tree per block and signing this tree (via its root hash). This efficiency argument holds independent of the concrete consensus mechanism of a blockchain or the question whether the blockchain is permissionless or permissioned etc.

There are two fundamental options to distribute Web3 data over the Web3 tree \(\tau \) and the Web3 ledger \(\lambda \):

  • Pure certification ledger. No data is stored in the ledger \(\lambda \). All Web3 data is stored (only) in cloud \(\gamma \). A chunk of Web3 data \(\delta \) that is exchanged via a Web3 protocols is represented in the ledger by a hash value \(h_\delta \). The hash value \(h_\delta \) serves as identifier of \(\delta \), i.e., to retrieve \(\delta \) from \(\gamma \).

  • Certification/data ledger. Some of the data that is exchanged via Web3 protocols are stored directly in the ledger \(\lambda \).

Maximizing Data Protection. A reason for not storing data directly in the ledger is efficiency. This reason is independent of whether the ledger is public or not. If the ledger is public, a natural pattern (to maximize data protection) is to formulate Web3 (partition) rules only in terms of data stored in the ledger \(\lambda \) – the Web3 rules can now be called ledger rules. Then, assuming that the data in the cloud \(\gamma \) is not public (and effectively protected), only such data would be stored in the ledger that is needed in formulating Web3 (partition) rules. Storing clear data in the ledger does not automatically break anonymity.

Ultra Scalability. Ledger transaction performance is the sine-qua-non pre-condition for the Web3 to be turned into reality. We discuss ultra scalability as part of the Alphabill scenario discussion in Sect. 4.

3 On the Web3 Design Space

The Web3 is said to be “our chance to make a better internet” [1]. A “better Web” has been envisioned long before the Web. Already in 1960, Ted Nelson founded project XanaduFootnote 7 [50, 51] – the original hypertext [27] project. Today, more than 50 years later, the requirements that have been formulated for Xanadu (Table 3) read like a wish list for the “better internet” including: a document type system, transclusions [28], secure user identification, access rights management, data replication etc. Last but not least, a royalty mechanism and payment system for the consumption of digital assets was in the Xanadu list.

Table 3. The original 17 rules of Ted Nelson’s Xanadu.
Full size table

Analysing today’s enterprise application landscape [52, 53] leads to similar requirements in regard to crosscutting concerns. The fact that today’s enterprise applications are implemented as web-based applications gives us an idea of another huge opportunity for Web3 that has been overlooked so far: the systematic amalgamation of intranet and internet (where we think of the intranet as a potential enterprise application backbone [52, 53]. In the same vein, the Web3 can become a massive Devops backbone. The SUM (Single Underlying Model) of the orthographic modeling approach [54] can be integrated as partition into Web3 – enabling both CASE 2.0 as described in [55, 56] and the model-driven organization as described in [57].

As the Web of everything the Web3 encompasses the Internet of Things (IoT). And as such, it becomes a Web of manufacturing and logistics [58,59,60,61]. The integration of SDN (software-defined networking), IoT and blockchain technology [62,63,64] will become a strand of research contributing to Web3.

As a Web of everybody, massive disintermediation is the standard narrative of the Web3. Disintermediation leads to re-shaped institutions [38, 39, 65] as well as entirely new institutions. As the societies’ institutional architecture [40], governance needs to be re-thought and re-designed.

Collective intelligence (CI) [66] systems form an extremely important class of web-based applications with Wikipedia and Reddit being just two examples [21]. CI systems are natural candidates for Web3 partitions. CI systems will stay with us in the future and their importance will even steadily increase. For example, enterprises have started to understand the potential of CI for their endeavors [53] – take Blackrock’s AladdinFootnote 8 system and Genpact’s Cora systemFootnote 9 as (particularly important) examples.

Fig. 3.
figure 3

The Alphabill platform.

Full size image

4 The Alphabill Scenario

Recently [9], we have described the Alphabill platform and its architecture, see Fig. 3. Alphabill is a platform for universal asset tokenization, transfer and exchange as a global medium of exchange. Users of the Alphabill platform can launch arbitrarily many partitions on the platform. Alphabill is a partitioned, replicated, sharded blockchain. Each partition implements an individual token and corresponding transaction system. Alphabill partitions correspond to the notion of Web3 partitions in our Web3 foundation. The Alphabill platform provides the necessary protocols, languages, libraries and toolkits to implement partitions in such a way that they show robustness and unlimited scalability. Robustness is achieved through replication, i.e., highly redundant partitions. The ultra scalability is enabled by a novel electronic money scheme, the bill scheme [67, 68]. Each Alphabill partition is sharded. Through its decomposability, the bill money scheme eliminates coordination efforts between shards. Coordination between partitions is achieved efficiently through a dedicated atomicity partition and a novel, three-phase commit protocol.

As a proof-of-concept, we have successfully delivered the bill-based blockchain technology KSI Cash [9, 68,69,70,71]. The performance of the technology has been tested exhaustively, together with the European Central Bank, in order to assess the technological feasibility of a digital euro [9]. The tests achieved: (i) 15 thousand transactions per second, under simulation of realistic usage, with 100 million wallets, and (ii) up to 2 million payment orders per second, i.e., an equivalent of more than 300,000 transactions per second, in a laboratory setting with the central components of KSI Cash.

5 Conclusion

Too often, we think and talk about Web3 in terms of individual Web3 solutions (individual Web3 products, individual Web3 assets, individual Web3 business models etc.) – although Web3 is clearly a vision of a digital ecosystem, and, actually, a vision of the most encompassing digital ecosystem. In our opinion, it is unlikely that Web3 emerges – out of nothing – as a series of Web3 solutions (independent of how much venture capital might be pumped into such individual efforts). What we need in first place, is to shape and to provide excellent (ultra-useful, ultra-easy, ultra-robust, ultra-scalableFootnote 10) infrastructure and tools to enable Web3 solutions. And, we are convinced, now is the time to do so. From an engineering perspective, Web3 is the integration of digital rights exchange into the (application layer) internet protocols. From a design perspective, we need to care more for the completeness of vision of Web3. With the Web3 foundation suggested in this paper, we hope to help with the completeness of vision of Web3.