text:
\section{Introduction}
Web3, also known as Web 3.0 or decentralized web, hits the cryptocurrency markets and blockchain communities from 2020 to date \cite{web3soul}\cite{csnreport}. It has become the most prevailing term in the recent period of blockchain prosperity. The concept, proposed by Wood \cite{woodweb3}, promises to provide distributed internet services without trusted third parties (TTP), thereby offering users more control over their data. The very primary principle shared by Web3 applications is that users can hold the data with full control, covering identifiers/tokens/ownership/etc., rather than being managed by centralized organizations as in Web1 and Web2 (cf. Appendix A). With the emphasis on \textit{decentralization}, Web3 moves data away from these central authorities and establishes applications and services surrounding blockchain technologies. Ideally, Web3 developers do not need to build applications on top of a single server (processing business logic) or database (storing user data). Instead,  Web3 applications are deployed on decentralized networks such as blockchain platforms or related distributed systems hosted by many peer-to-peer (P2P) servers.

The conversion from central authorities to the blockchain, more than handing over the ownership back to users, brings many non-functional benefits of being (i) \textit{open}: Web3 data is stored in an open network developed by public communities. Also, Web3 applications are executed in a global view towards the public, making data permanently visible to all the participants; (ii) \textit{trustless}: a user can build connections or exchange assets to an unfamiliar user without the reliance of a trusted third party; (iii) \textit{permissionless}: users' identities are no longer tied to any specific platform and users' activities are free, which do not need an authorization from a governing entity; (iv) \textit{anonymous}: users can obtain partial anonymity through using multiple pseudonyms or off-chain storage; and of (v) \textit{high availability}: Web3 provides a high availability architecture, which reduces the probability of the server crash or single point failure;  (vi) \textit{compatibility}: Deployed services and applications are not limited in the Ethereum ecosystem, but applicable to all competitive blockchains \cite{dappradar,mathdapp} like Avalanche \cite{avax}, Solana \cite{solana}, Binance Smart Chain \cite{bsc} or Oasis Network \cite{rose}, indicating that Web3 can integrate both existing public-chain ecosystems and incoming systems.

Web3 also improves user experience in using web stack technologies and thus promotes the development of blockchain technologies. Web3 helps to build a complete user experience that can better serve newcomers. Users, from the current view, only need to \textbf{\textit{connect the wallet}} to their targeted sites. These sites contain the activities that a user would love to spend time on, which can be specified in different types, such as asset swaps (in DEXes \cite{xu2021sok}), games \cite{axieinfinity}, and trades (of NFTs \cite{wang2021non}). Meanwhile, users can obtain a portion of revenues by keeping active in these projects. The contributions are measured in a wide range covering spent time, interactions, deposits, staking, etc. Users can receive fair rewards as well as add more liquidity to the Web3 ecosystem. In this sense, Web3 has greatly extended the boundary of blockchain, incentivizing more users to participate in the games. The evidence is, as in Dec 2021, the total locked value (TLV) of Web3-related smart contact contract has reached a peak with 193.14 billion USD (more details in Sec.\ref{subsec-impact}). Such a high capitalization market further stimulates the prosperity of techniques surrounding blockchain (cf. Tab.\ref{tab-projects}).

However, despite the fact that Web3 has drawn much attention, clear statements of \textit{what is Web3} and \textit{how Web3 is designed} are even absent. Several studies provided their investigation on the consensus level~\cite{liu2021make} but failed to cover a full view of other components and architectural designs that are equally important to Web3. Unclear definitions and non-agreed consensus indicate that Web3 either is just a hyped concept without practical development or, has more than one single direction for the development. In this technical report, we avoid such high-level discussions, narrowing down the scope to the Web3 architecture and its relation with blockchain. We dig into its building process, investigate its usage in existing projects, and deconstruct the protocol into separated components. With this in the arm, we analyze and evaluate \textit{state of the art} Web3 solutions from perspectives of their design patterns and properties. We further extend our scope to the entire Web3 space (still rooted in blockchains) by discussing their impacts, opportunities, and challenges. To our knowledge, this work provides the first in-time study on Web3, reviewing and exploring the wild Web3 solutions.

\begin{itemize}
\item[-] We investigate existing Web3 projects and extract a succinct backbone model with participating roles and operating workflow to demonstrate the major processes. This provides a loose general model for easy adoption, as well as highlights the core steps to establish a Web3 service.

\item[-] We classify a total of twelve architectural designs of Web3 to reflect the operating mechanism of typical Web3-based applications. We decouple a full Web3 service into three-layered components according to the data workflow. Data in each component can be either operated by the ways of \textit{on-chain}, \textit{off-chain} or \textit{hybrid}. The identified design types can well present all potential combinations, covering a wide range of Web3 applications and services.

\item[-] We accordingly evaluate each architecture based on different property metrics that are grabbed from classic blockchain systems. The evaluation analyses the architectures from multi-dimensional properties (cf. Tab.\ref{tab-archievalua}) when adapting to real applications. We also discuss which participating entity can gain the most benefits under different types. The evaluations directly help software architects to evaluate and compare Web3 solutions and further design their architectural frameworks.

\item[-] We extend our scope from architectural design to the entire Web3 space by discussing its impacts, opportunities and challenges to predict the potential future directions. We show several promising fields that may be inspired by Web3-related technologies, and also point out the open challenges needed to be addressed in the long term. Meanwhile, based on our analyses and evaluations, we answer several questions that are frequently asked by the communities as our closing results to conclude this work.

\item[-] Further, we provide much more surrounding knowledge that is related to Web3, covering its basic primitives, referenced token standards, and adopted programming languages. Necessary primitives cover both architectural design in conventional web services and layered components in classic blockchain systems. The knowledge lays the foundation of Web3, presenting the common components in different blockchain-based Web3 projects.

\end{itemize}

The rest of this paper is organized as follows. Section \ref{sec-protocol} presents a typical Web3-based protocol, together with the inducted security model. Section \ref{sec-archi} presents our architecture extraction and design, as well as gives the criterion used to capture the features of Web3 related applications. Section \ref{sec-evaluation} details our evaluation towards architectural designs, providing practical adaption under different scenarios. Section \ref{sec-discussion} discuss current impacts, opportunities and challenges. Finally, Section \ref{sec-closing} gives our closing results and Section \ref{sec-conclu} concludes this work. Notably, we provide more knowledge of Web3: Appendix A gives fundamental primitives surrounding Web3 and an abstract Web3 workflow. Appendix B and C summarize existing token standards and EVM-operated programming languages, respectively. Appendix D shows a small corpus of \textit{in the wild} Web3 projects.

\section{Web3 Protocol}
\label{sec-protocol}

This section extracts the protocol, security model, and a running example of Web3 systems between user clients and the blockchain infrastructure (together with the protocol workflow, referring to Fig.\ref{fig-workflow} in Appendix A.3). Before our investigation, we clarify the entities that participate in Web3 protocols.

\smallskip
\textbf{Involved Entities.} The Web3 protocol mainly consists of three types of roles, namely, the \textit{Web3 user}, \textit{service provider}, and the \textit{blockchain maintainer}. The Web3 user is a data owner who can propose the request by sending a transaction from the client. The service provider offers the user an on-chain interface and the service that can both process the request and interact with blockchain platforms. The blockchain maintainer provides an operating environment for smart contracts that take the task of processing business and data storage.

\smallskip
\textbf{{General Construction.}}
To launch the Web3 service, a Web3 user needs to first establish his distributed identity by creating an address or account on-chain at the client. Then, the user login the applications using his address-based identity. Subsequently, the application will interact with the blockchain for data computation and data storage. Here, we present the detailed protocol.

\noindent\hangindent 1em \textbf{\textit{\,\, Identity Creation} ($\mathsf{\Pi_1}$).} This algorithm takes as input the security parameter $\kappa$, and outputs a blockchain address/account $addr$. The address provides a public and open-source index that can be associated with an existing identifier. Also, this address is used as an identifier for sending or receiving the cryptocurrency. It covers three sub algorithms, \textit{private key generation}, \textit{public key generation} and \textit{address generation}.

\begin{equation*}
\centering
\begin{aligned}
sk \gets \mathsf{KeyGen_{sk}}(1^{\kappa}), \\
pk \gets \mathsf{KeyGen_{pk}}(sk),\\
addr \gets \mathsf{AddressGen}(pk).
\end{aligned}
\end{equation*}

\noindent\hangindent 1em \quad The algorithm is run by a local Web3 client (e.g., client-based wallet, browser extension-based wallet). Note that the sub-algorithms $\mathsf{KeyGen_{sk}}$, $\mathsf{KeyGen_{pk}}$ and, $\mathsf{AddressGen}$ have different manifestations. For example, for $\mathsf{AddressGen}$, Bitcoin addresses use the base-58 encoding\footnote{https://tools.ietf.org/id/draft-msporny-base58-01.html}, while Ethereum addresses adopt the base-16 encoding algorithms.

\noindent\hangindent 1em \textbf{\textit{\,\, Transaction Generation} ($\mathsf{\Pi_2}$).} This algorithm takes as input the user's private key $sk$, the transaction $metadata$, the transaction $payload$, and accordingly outputs an enveloped transaction $Tx$.

\begin{equation*}
\begin{aligned}
sig \gets \mathsf{Sign}(sk, metadata, payload), \\
Tx \gets \mathsf{TranGen}(sig, metadata, payload).
\end{aligned}
\end{equation*}

\noindent\hangindent 1em \quad This algorithm is run by a Web3 client that receives the request from users. $sk$ is used to generate a signature. $metadata$ refers to transaction-related data, such as the transaction receiver and transaction nonce. $payload$ points to the contract method to be involved and the data to be stored.

\noindent\hangindent 1em \textbf{\textit{\,\, Contract Execution} ($\mathsf{\Pi_3}$).} This algorithm takes as input the transaction $Tx$, and current state $\overline{s}$, and smart contract $contract$, and accordingly outputs the transferred state $s$.
\begin{equation*}
s \gets \mathsf{ContractExec}(\overline{s}, Tx, contract).
\end{equation*}
\noindent\hangindent 1em \quad This algorithm is run by the blockchain maintainers in the network. The transited state $s$ includes a reward or payment used to incentive the participating nodes. The contract $contract$ contains the logic of upper-layer applications, which defines how the state changes happening on the blockchain.

\noindent\hangindent 1em \textbf{\textit{\,\, State Consensus} ($\mathsf{\Pi_4}$).} This algorithm takes as input the transaction $Tx$, the smart contract $contract$ and the current state $s$ to be transited, and outputs the confirmed state $s^{\prime}$, and the confirmed transaction $Tx^{\prime}$.

\begin{equation*}
(s^{\prime}, Tx^{\prime}) \gets \mathsf{Consensus}(s, Tx, contract).
\end{equation*}

\noindent\hangindent 1em \quad  This algorithm is run by blockchain maintainers. The term \textit{confirmed} indicates that the proposed block (containing $s$ and $Tx$) has been agreed upon by sufficient maintainers in the network. The  threshold of confirmation depends on specific algorithms (e.g., 51\% in PoW \cite{nakamoto2008bitcoin}, 2/3 in BFT algorithms \cite{castro1999practical}).

\noindent\hangindent 1em \textbf{\textit{\,\, State Retrieval} ($\mathsf{\Pi_5}$).} This algorithm takes as input the user's address $addr$ and outputs the transaction $Tx^{\prime\prime}$ and the related state $s^{\prime\prime}$.

\begin{equation*}
(s^{\prime\prime}, Tx^{\prime\prime}) \gets \mathsf{Retrieval}(addr,  contract).
\end{equation*}

\noindent\hangindent 1em \quad  This algorithm is run by a Web3 client who aims to retrieve the state.

\smallskip
\noindent\textbf{Secure Web3 Protocols}. Based on the extracted general construction, a secure Web3 protocol is informally defined as follows.

\smallskip
\begin{defi}[Secure Web3 Protocol]
A Web3 scheme $\mathsf{S}$ is secure, if for all blockchain address $addr$ and the initial state $\overline{s}$ outputted from Phase $\mathsf{\Pi_1}$ to Phase $\mathsf{\Pi_5}$, it holds that,

\begin{equation*}
\left[
\begin{array}{ll}
\begin{aligned}
     sig \gets \mathsf{Sign}(sk, metadata, payload) \\
Tx \gets \mathsf{TranGen}(sig, metadata, payload) \\
s \gets \mathsf{ContractExec}(\overline{s}, Tx, contract) \\
 (s^{\prime}, Tx^{\prime}) \gets \mathsf{Consensus}(s, Tx, contract) \\
\end{aligned}
\end{array}
\right]  \Rightarrow (s^{\prime}, Tx^{\prime})
\end{equation*}

\begin{equation*}
\left[
\begin{array}{ll}
\begin{aligned}
(s^{\prime\prime}, Tx^{\prime\prime})\gets \mathsf{Retrieval}(addr,  contract) \\
\end{aligned}
\end{array}
\right]  \Rightarrow (s^{\prime\prime}, Tx^{\prime\prime})
\end{equation*}

where the output satisfies:
\begin{align*}
(s^{\prime}, Tx^{\prime}) = (s^{\prime\prime}, Tx^{\prime\prime})
\end{align*}

\end{defi}

The definition states that a Web3 protocol is deemed to be secure if a user can successfully retrieve the correct state and transaction on the blockchain at any time after the block confirmation. Our security model is based on the assumption of a \textit{robust} blockchain \cite{garay2015bitcoin} and the corresponding security is guaranteed by \textit{persistence} and \textit{liveness}~\cite{garay2017bitcoin}. The \textit{persistence} means whether different nodes have the same view at a specific height of blocks, while the \textit{liveness} focuses on whether a block can be eventually buried deep enough (without the possibility of being reversed) in the valid longest chain. We omit other types of chain structure, such as the directed acyclic graph (DAG) \cite{wang2020sok}.

\begin{figure}[!hbt]
    \centering
    \includegraphics[width=0.9\linewidth]{img/instance.png}
   \caption{An Instance of Web3 User Case}
   \label{fig-instance}
\end{figure}

\textbf{A Running Example.}
We provide an instance to describe how a Web3 system works. The case is straightforward: assume that a user wants to sell his self-created NFT painting on-chain (cf. Fig.\ref{fig-instance}). Firstly, he needs to connect his wallet to the related website and send the request to mint an NFT on his targeted blockchain platforms \cite{wang2021non}. The action of \textit{mint} requires invoking APIs that enable interactions with smart contracts. The contract is executed according to its predefined specifications and token standards (ERC721, see details in Appendix B). After processing the logic, the raw picture is stored in an external decentralized storage network, e.g., IPFS \cite{ipfs}, due to its high-resolution format. IPFS separates the raw data into pieces and distributes them into different nodes, labelling each of them with a content identifier (CID). The returned identifiers are recorded on-chain for further queries from users. Once completing the entire logic, the seller can trace the transaction and his NFT on the blockchain. The buyer with willingness can buy the seller's NFT on Opensea \cite{opensea}, and pay the prices as stated. The ownership of this NFT will be automatically transferred to the buyer once completing the payments.

\section{Architectural Design}
\label{sec-archi}

The architecture is the foundation of software systems. It defines the system structure and external-world interface via underlying components and their relationship. This section provides our architectural design for Web3 systems.

\subsection{Design Principle}

We stay aligned with the mainstream recognition of Web3 and accordingly structure our report by progressively presenting the ways to build a Web3 service and the featured properties in different designs. Based on plenty of investigation towards \textit{in the wild} Web3 projects, we classify them into a compact framework (cf. Fig.\ref{fig-model}), which thus allows the audience to explore the conceptual design space and evaluate different design options.

Specifically, we delineate two basic axes, namely, \textit{decoupled component} and \textit{technical route}, to explore the subtle differences in each cross from orthogonal directions. For the former, we abstract three critical components, including  \textit{client}, \textit{compuation} and \textit{storage}, as our characterisation. Our decoupling is based on the data workflow, which contains three corresponding phases (A-C in Fig.\ref{fig-model}), \textit{data access}, \textit{data computation} and  \textit{data storage}, to describe how data transfers under a normal operating logic. For the latter, we extract three technical routes of implementing a blockchain system: \textit{on-chain} processing, \textit{off-chain} processing, and their \textit{combinations} (hybrid).

By interweaving two axes, we can find that each component can be categorized into sub-items according to its on-chain/off-chain processing route. Based on that, we identify a total of twelve types of architectural designs to show different purposes and usages among a large bunch of projects. Moreover, we capture several essential properties that are frequently mentioned in classic blockchain systems to evaluate the proposed design types. This framework captures major architectural characteristics and related properties of each type, helping Web3 users and software architects to choose the proper design for their products. We give the detailed definitions of each item as follows.

\begin{figure}[h!]
    \centering
    \includegraphics[width=1\linewidth]{img/model.png}
   \caption{\textbf{\textit{Framework.}} We have first identified three major components according to the data workflow: access, computation, and storage (cf. \textit{left Square}). Then, we extract three technical routes that reflect the ways of data processing in blockchain systems: on-chain, off-chain, and hybrid (\textit{medium Square}). Based on the two principal dimensions, we summarise a total of $12$ types of potential Web3 architectural designs (\textit{bottom Square}). With this in the arm, we analyze every type in terms of different property metrics (\textit{right Square}) and point out design trade-offs. Notably, we also provide a guide map by using \textit{blue dotted line}. }
   \label{fig-model}
\end{figure}

\subsection{Decoupled Components}
\label{subsec-compo}

We first investigate how data flows from a user to its backend server. In such a procedure, we have totally extracted three major processes to normal system operations: \textit{data access}, \textit{data computation} and \textit{data storage}. Such procedures describe a typical workflow of blockchain systems.

\begin{itemize}
 \item[-] \textbf{\textit{Data Access.}} To start a Web3 service, a user first needs to send his request through a client. Typically, the request is formatted as a transaction, and accordingly, the client is instantiated as a wallet\footnote{We omit the sub-categories of different wallet types, such as whether utilizing SPV or hardware. More details refer to \cite{chatzigiannis2021sok}\cite{karantias2020sok}.}. Users enter the network by connecting their wallets to a specific website.

  \item[-] \textbf{\textit{Data Computation.}} After a successful connection, the requests from users are parsed into different pieces of logic, being transmitted into backend blockchain platforms. Blockchain operates the logic and decoded methods via smart contracts according to their predefined specifications.

 \item[-] \textbf{\textit{Data Storage.}} The executed data, at last, should be permanent storage. In normal cases, small size data can be directly recorded inside transactions, whereas in some cases, large-scale data requires external storage. The key to maintaining the data integrity in off-chain storage is to add a \textit{hook} that connects the on-chain (such as a hash) and off-chain data.

\end{itemize}

Then, based on descriptions of data flow, we abstract three fundamental components in a full-functional Web3 service by decoupling existing solutions. Merging with our different data processing routes, we categorize the decoupled component with \textit{on-chain}, \textit{off-chain} and \textit{hybrid} options (selected by two or all of them). We give their definitions as follows (and more details in Sec.\ref{subsec-component}). To be noted, as Web3 is featured by decentralization, at least one of the components should be operated on-chain, where no gatekeeper can fully control the network.

\smallskip
\textbf{Client.} Clients are used to receiving requests from users. Classic blockchain systems, on a small scale of requests, can use a single browser as the client to connect with the wallet. However, if the request sharply increases within a short time frame, an agent is required to process an instantaneous flow of requests.

\begin{itemize}
 \item[-] \textbf{\textit{Browser-based Wallet.}} A browser-based wallet is an intuitive solution for users to adopt the Web3 service. Users only need to install an extension tool in the browser and import their private key to this embedded wallet. When browsing a Web3-supported website, users can directly put the button of \textit{connect the wallet}, and all the clicked functions in this website will invoke the backend methods through APIs under the user's account.

 \item[-] \textbf{\textit{Agent-based Wallet.}} An agent solution is to enable batch processing when confronting a high-density situation of requests from users. Similar to traditional Web1/Web2, users should first grant a trusted agent with proper permission. The authentication procedure is executed once users have formally started to register with the agents.
\end{itemize}

\smallskip
\textbf{Computation.} Operating a Web3 service built on smart contracts requires great computing power as the running environment. Purely on-chain computation is instant but costly. A hybrid computation that moves partial computational tasks off-chain is another solution.

\begin{itemize}
 \item[-] \textbf{\textit{Contract-based Computation.}} All the computations are performed on-chain through smart contracts. Here, variables in smart contracts are allowed to be revoked and modified based on the predefined contract instructions.

 \item[-] \textbf{\textit{Hybrid Computation.}} A partial proportion of computations are executed on-chain, while the rest of the computations off-chain. Generally, verification mechanisms are required in this method in order to guarantee integrity between on-chain and off-chain data.

\end{itemize}
\smallskip
\textbf{Storage.} Similar to any services applied to Web1/Web2,  applications and services in Web3 also require enough space for storage. Data in small size, such as ordinary transaction payload, can be stored directly on-chain. In contrast, for the large size, or complicatedly formatted data, like streaming video or raw audio, it should be (partially) stored to external deceives or providers. In this sense, we summarize three types of data storage.

\begin{itemize}
 \item[-] \textbf{\textit{On-chain Storage.}} All the data is stored on-chain, as a state of the smart contract. Any changes will be publicly recorded and can be verified by the entire network. Theoretically, this is the best way to prevent malicious nodes from destroying data due to its total transparency and accountability.

 \item[-] \textbf{\textit{Off-chain Storage.}} It refers to storing data in off-chain networks where only the hash roots are recorded online (e.g., IPFS \cite{ipfs} or Swarm \cite{swarm}). The solution requires an additional process for verification, such as proof-of-existence, to prove data integrity.

 \item[-] \textbf{\textit{Hybrid Storage.}} This is a mixed way that combines both on-chain and off-chain storage, which means storing raw data off-chain (like video and audio) and light metadata (such as account history and certificates) on-chain. The proportion of these solutions is adjusted according to specific scenarios.
\end{itemize}

\subsection{Architectural Designs}\label{subsec-design}

We have identified totally twelve types of architectural designs towards Web3 services (cf. Architectural Type $1-12$ in Fig.\ref{fig-model}). Specifically, we denote each design with \textit{Type}, and it is made up by a three-element tuple $(A_a,B_b,C_c)$ where $a,b \in \{1,2\}$, and $c \in \{1,2,3\}$. Here, the elements $A,B,C$ separately specify the components of \textit{client}, \textit{computation} and \textit{storage}, while the subscripts $1,2,3$, respectively, represent \textit{on-chain}, \textit{hybrid} and \textit{off-chain} as defined before. Based on different combinations, we provide the potential architectural designs as follows.

\begin{itemize}
    \item[-] \textit{Type1} $(A_1,B_1,C_1)$, \textit{Type2} $(A_1,B_1,C_2)$, \textit{Type3} $(A_1,B_1,C_3)$, which are shown in the \textit{black line} at the left square in Fig.\ref{fig-model};

    \item[-] \textit{Type4} $(A_1,B_2,C_1)$, \textit{Type5} $(A_1,B_2,C_2)$, \textit{Type6} $(A_1,B_2,C_3)$ (\textit{\textcolor{brown}{brown line}});

    \item[-] \textit{Type7} $(A_2,B_1,C_1)$, \textit{Type8} $(A_2,B_1,C_2)$, \textit{Type9} $(A_2,B_1,C_3)$ (\textit{\textcolor{blue}{blue line}});

    \item[-] \textit{Type10} $(A_2,B_2,C_1)$, \textit{Type11} $(A_2,B_2,C_2)$, \textit{Type12} $(A_2,B_2,C_3)$ (\textit{\textcolor{teal}{teal line}}).
\end{itemize}

In each design type, smart contracts play the most essential role in entire services that are responsible for on-chain calculations. \textit{Type1} is the most simplified architectural design amongst those combinations. A typical instance is known as today's Ethereum platform. To fit for more complicated cases, external resources should be equipped to the system design, such as the agent in \textit{Type7-12} or the off-chain storage in  \textit{Type2/3}. Notably, the running NFT example in Sec.\ref{sec-protocol} is a based on the \textit{Type2} design.

\section{Architecture Evaluation}
\label{sec-evaluation}
In this section, we present the evaluation criteria and evaluate each type of architecture. Our evaluation covers the properties that are summarized from classic blockchain systems and benefits to different participating parties.

\subsection{Evaluation Criteria}
\label{subsec-criteria}

In the past decades, many evaluation frameworks have been proposed. Among them, the \textit{architecture trade-off analysis method} (ATAM) \cite{kazman1998architecture} is a well-known one. We partially adopt ATAM to assess the Web3 architecture, integrating with the blockchain properties and beneficial parties. In particular, we first select a concrete scenario, refine quality attributes into this scenario, and then present potential concerns related to the quality requirement.

\smallskip
\textbf{ATAM Method.} The architecture trade-off analysis method is initially used in software development to recommend the most suitable architecture for a specific system. The method majorly discusses the trade-offs between different design types and their sensitivity points for risk mitigation. A classic ATAM process consists of three critical aspects: \textit{extract quality attributes}, \textit{identify beneficial parties,} and \textit{analyse in specific scenarios}. Quality attributes are non-functional requirements to specify how well software should be done. In the context of Web3, we adopt the properties extracted from classic blockchain systems as quality attributes. Then, we analyse the system entities regarding their potential benefits and losses. Meanwhile, we still use a similar NFT instance (compared to the running example in Sec.\ref{sec-protocol}) as our analysed scenario.

\smallskip
\textbf{Property Metrics.}\label{subsec-property}
We capture several major properties that are used to evaluate classic blockchain systems. These metrics depict the architecture from multiple dimensions, and we summarize them as follows.

\begin{itemize}
    \item[-] \textit{Performance.} Performance is used to show the maximum rate of confirmed transactions during a specified duration. In the context of blockchain, performance is measured by transaction per second (TPS), which is a widely adopted way to describe the throughput of a system.

    \item[-] \textit{Scalability.} Scalability refers to the ability to process transactions along with the increased scale of networks, which is reflected by the increase or decrease in its performance (measured in transaction per second--TPS).

    \item[-] \textit{Cost.} Each transaction in VM-engined blockchain platforms requires certain transaction fees. This is necessary because a total zero friction (free of fees) will result in a loop logic error \cite{kalra2018zeus} in smart contract operations.

    \item[-] \textit{Security.} Security is a broad term. We limit the scope of security to data-level security. The data should be protected for its integrity and prevented from unauthorized access or faking, or compromising.

    \item[-] \textit{Anonymity.} Anonymity refers to hiding the identities of acting persons. In the context of blockchain, anonymity mainly indicates utilizing cryptographic schemes to break the linkage between physical entities with virtual public addresses~\cite{Li2022SoKTC}. An adversary cannot learn useful information about any specific parties related to the on-chain assets.

    \item[-] \textit{Confidentiality.} Confidentiality refers to hiding the sensitive data that is presented on transactions, including their asset values, useful information in payloads, or contract states. Confidentiality focuses on states rather than entities. Notably, privacy covers both anonymity and confidentiality, where an adversary cannot learn any useful knowledge from public transactions.

    \item[-] \textit{Availability.} Availability is used to measure the probability of a system running abnormally with the existence of potential failure. It indicates the stability of a blockchain system.

    \item[-] \textit{Usability.} Usability in the context of Web3 follows the same connotation as the general computer system, which measures the satisfaction of a specific user in a specific context when using a specific product.

\end{itemize}

\smallskip
\textbf{Stakeholders.}
A major task in ATAM evaluation is to analyse a system's capability for satisfying the stakeholder requirements~\cite{bass2003software}. The stakeholders in the context of our Web3-based evaluation indicate the potential beneficial parties in the system, being aligned with \textit{involved entities} stated in Sec.\ref{sec-protocol}, rather than the person holding assets in proof of stake (PoS) protocols \cite{kiayias2017ouroboros}. Three main stakeholders are identified as our evaluation target.

\begin{itemize}

\item[-] \textit{Web3 user.} A Web3 user is an entity that owns the data. Also, the user is an entity to initiate transactions. The user should accordingly obtain a fair proportion of rewards in the forms such as tokens, badger, etc.

\item[-] \textit{Service provider.} An application owner uses blockchain to provide publicly accessible services for users. The service provider may obtain revenues from both sides: user payments and blockchain platform rewards.

\item[-] \textit{Blockchain maintainer.} Blockchain maintainer provides a running environment for executing the smart contract and storing the blockchain data. The main reward for maintainers comes from the cryptocurrency rewards.

\end{itemize}

\subsection{Architecture Evaluation}
\label{subsec-evaluation}
Then, we start to evaluate each architectural design. We give a specific scenario to narrow down the scope of the high-level description and analyze each architecture regarding its properties and stakeholders.

\textbf{Scenario.} Non-Fungible Token \cite{wang2021non} is a blockchain-based cryptocurrency that allows proving the ownership. In our scenario, an NFT designer, Alice, wants to sell her NFT to Bob by paying cryptocurrencies. Even though this application focuses on a specific domain, we argue that the core requirements are likely to stand across different Web3 applications. We apply different architectures to this scenario, discussing both advantages/disadvantages and trade-offs, to help interested readers consider their final decisions on Web3 architectures.

\smallskip
\textbf{\textit{A1: An Ideal Web3 Architecture.}} An ideal Web3 infrastructure should eliminate all the middle man, without centralized databases or computation devices. The blockchain provides a decentralized platform for data computation and storage while bringing a native token-based economy. Under this architecture, Alice uploads the raw NFT data, the price information, and NFT auxiliary information to a blockchain-based smart contract through a wallet. Then, the blockchain nodes reach an agreement on the data. Next, Bob sends a transaction to invoke the contract for buying NFT. Finally, the NFT ownership transfers to Bob, and Alice obtains the payments. The architecture puts all the computation and storage on the blockchain, bringing security and availability for Web3 users. The blockchain operates on a collection of decentralized nodes, which guarantees the availability of on-chain data. Meanwhile, once blockchain nodes reach an agreement for the received transactions, data becomes immutable. The related architectural design in Sec.\ref{sec-archi} is \textit{Type1}.

However, this architecture confronts some drawbacks, which mainly center around being impractical when adapting to today's Web3 infrastructure.  Firstly, uploading and replicating the data to all blockchain nodes in a peer-to-peer network is time-consuming. Website interactions are slower where the back-ended state transitions need confirmation and propagation throughout the network. Meanwhile, scalability is a long-term issue existing in blockchain systems due to intrinsic decentralization. The architecture is closely integrated with underpinned blockchain systems, which, as a result, will face a similar issue. Moreover, the computation and storage in the blockchain are expensive regarding monetary costs. Worse still, the fees increase with the growing size of payload data.

Beyond that, this architecture raises problems about data privacy. On the one hand, the code and state of smart contracts are transparent by default. Any changes in the contracts are immediately visible, not just to the blockchain nodes but also to anyone outside blockchains. The over-publicity issue hinders the development of Web3 applications, making them hard to be adopted for privacy-critical applications. On the other hand, users' identities lack anonymity. Without an explicit approach taken to protect the user's addresses, virtual addresses on blockchains and physical identities are linkable with the help of analytical tools and big data, even if users can use multiple pseudonyms.

\smallskip
\textbf{\textit{A2: Agent-login Architecture.}} The ideal Web3 solutions, singly relying on the original blockchain technology, confront the issues of poor scalability and high cost. These shortcomings force the user to adopt the alternatively centralized computation or storage outside the blockchain. We gradually proceed from layer to layer. Firstly, we address the congestion issue at the \textit{access} layer. The agent-login design provides a scalable approach to handling many transactions by merging multiple executions. A group of users can access the blockchain platform with one agent account. In particular, in our scenario, multiple NFT-selling and buying transactions are bundled into one transaction. An agent anchors this transaction to the blockchain later for the final agreement. Centralized exchanges, such as Coinbase~\cite{coinbase} or Binance~\cite{binance}, act as agents similar to this design. Many Web3 participants rely on custodial wallets for easy access and management. This architecture can concurrently process transactions without waiting for the blockchain's confirmation, which brings high performance, good scalability, and low cost. The related architectural designs include \textcolor{blue}{\textit{Type7-9}}.
The main drawback of this solution is centralization, which may cause unnecessary issues. For example, a malicious agent may hide the user's transactions without sending them to the blockchain. Worse still, such action is hard to trace due to the lack of transparent evidence.

\begin{table}[!hbt]
    \centering
\caption{Web Architecture Evaluation}
\label{tab-archievalua}
\resizebox{\linewidth}{!}{
\begin{tabular}{lccccccccc|cccc@{}}
\toprule
\multicolumn{2}{c}{} & \multicolumn{7}{c@{}}{\textbf{Property}} & \multicolumn{5}{c@{}}{\textbf{Stakeholders}}\\
\cmidrule(l){3-14}
\multicolumn{2}{c}{\textbf{Architecture}}  & \rotatebox[origin=c]{65}{Performance} & \rotatebox[origin=c]{65}{Scalability} & \rotatebox[origin=c]{65}{Gas Cost} & \rotatebox[origin=c]{65}{Security}  &
\rotatebox[origin=c]{65}{Anonymity} &
\rotatebox[origin=c]{65}{Confidentiality} &
\rotatebox[origin=c]{65}{Availability} &
\rotatebox[origin=c]{65}{Usability} &
\rotatebox[origin=c]{65}{} &
\rotatebox[origin=c]{65}{Web3 User} &
\rotatebox[origin=c]{65}{Service Provider} &
\rotatebox[origin=c]{65}{BC Maintainer} \\
\cmidrule(l){1-14}

& \multicolumn{1}{l}{ $A_1$,$B_1$,$C_1$--\textit{Type1} } &
\tikzcircle[black, fill=white]{2pt}
&
\tikzcircle[black, fill=white]{2pt}
&
\tikzcircle[black, fill=white]{2pt}  & \tikzcircle[black, fill=white]{2pt}  & \tikzcircle[black, fill=white]{2pt}  &  \tikzcircle[black, fill=white]{2pt}
& \tikzcircle[black, fill=white]{2pt}
& \tikzcircle[black, fill=white]{2pt}  & & \tikzcircle[black, fill=white]{2pt}  & \tikzcircle[black, fill=white]{2pt}   & \tikzcircle[black, fill=white]{2pt}   \\

&  \multicolumn{1}{l}{ $A_1,B_1,C_{2/3}$--\textit{Type2/3} } &
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
&
 \tikzcircle[black, fill=white]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
& & + & - & - \\

\cmidrule{2-2}
& \multicolumn{1}{l}{$A_1$,$B_2$,$C_1$--\textit{Type4}} &
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}

&
 \tikzcircle[black, fill=white]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
& & + & -& - \\

& \multicolumn{1}{l}{$A_1$,$B_2$,$C_{2/3}$--\textit{Type5/6}} &
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}

&
 \tikzcircle[black, fill=white]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
& & ++ & -\,- &  -\,-  \\

\cmidrule{2-2}
&\multicolumn{1}{l}{ $A_2$,$B_1$,$C_1$--\textit{Type7}} &

\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
&
 \tikzcircle[black, fill=white]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
 \tikzcircle[black, fill=white]{2pt}
&
 \tikzcircle[black, fill=white]{2pt}
 &
\tikzcircle[green, fill=green]{2pt}
 &

& + & - & - \\

& \multicolumn{1}{l}{$A_2$,$B_1$,$C_{2/3}$--\textit{Type8/9}} &

\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}

&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
& ++ & -\,- &  -\,-  \\

\cmidrule{2-2}
& \multicolumn{1}{l}{$A_2$,$B_2$,$C_1$--\textit{Type10}} &

\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}

&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
& ++ & -\,- &  -\,-  \\

& \multicolumn{1}{l}{$A_2$,$B_2$,$C_{2/3}$--\textit{Type11/12}} &

\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&

& +++ & -\,-\,- &  -\,-\,- \\
\bottomrule

\end{tabular}
}
\begin{tablenotes}
 \item \quad \tikzcircle[black, fill=white]{2pt} Baseline, \tikzcircle[green, fill=green]{2pt} Property enhance, \tikzcircle[red, fill=red]{2pt} Property decrease; (Compared to \textit{Type1})

\end{tablenotes}
\end{table}

\smallskip
\textbf{\textit{A3: Hybrid Computation Architecture.}} This architecture shares the same workflow with $A1$ and $A2$. As discussed, on-chain computations are both time-consuming and money-consuming. Hybrid computation architecture solves this issue by bringing TTP with high computation capabilities. These TTPs process the data off-chain, and merely put a few computation tasks on the blockchain. In our example, the on-chain computation tasks may cover the token payment and NFT  the ownership transfer. This design improves user usability because off-chain computations have better performance and scalability.  The related architectural designs include \textcolor{brown}{{\textit{Type4-6}}}. However, it still assumes that the TTP who provides computation power is honest. A TTP in the real world may act maliciously or fail to provide computations due to hidden interests or being compromised. Again, such malicious computations are hard to be detected.

\smallskip
\textbf{\textit{A4: Hybrid Storage Architecture.}} This architecture stores the raw data off-chain while the data pointer is stored on the blockchain system. In our example, only NFT identifiers and payment information are stored on-chain, while the raw NFT data is stored off-chain. Correspondingly, in the real world, most NFT artists rely on centralized platforms like OpenSea \cite{opensea}, or Solanart \cite{solanaart} to store the raw NFT data. In this architecture, the choice of how to store off-chain data and how to reveal the contents of their off-chain data are left to users, which brings certain privacy and over-publicity issues. Meanwhile, the architecture improves the performance and saves the cost. Due to these benefits, the design has been widely adopted by some storage-intensive applications, such as blockchain-based streaming media, such as Theta \cite{theta}, Audius \cite{audius} and Livepeer \cite{livepeer}, which depends on the combination of on-chain storage and off-chain storage. The related architectural designs include \textcolor{teal}{\textit{Type10-12}}.

However, the solution is partially centralized with the risk of single point failures. In particular, the off-chain storage is controlled by a TTP. Any services built on top of this type can only be processed when a TTP is available, making the data access to relevant information becomes a privilege. Fortunately, some storage systems rely on replication to back up files for data integrity. For example, Storj \cite{wilkinson2014storj} utilizes the proof-of-redundancy mechanism, where every file is stored in at least three locations to avoid files being destroyed. The system operates on the Ethereum platform and stores the metadata in Satoshi format. Similarly, Sia~\cite{vorick2014sia} is a distributed storage system that relies on storage proofs. These proofs consist of a list of publicly verifiable root hashes from the submitted file and a fraction of the original file, and users can verify them easily from on-chain data. InterPlanetary File System (IPFS) \cite{filecoin}, with more complicated proof mechanisms, establishes a fully distributed peer-to-peer file system. Leveraging proof of time/space, IPFS ensures data integrity from both time and space.

\smallskip
{\textbf{Statistical Results.}} The investigation tries to answer the question \textit{which architectural design is the most prevailing?} Existing Web3 projects are designed based on different scenarios. Accordingly, their solutions target different components. We expand our research from mature systems (ranked in the market) as well as newly released whitepapers that claim to launch the projects. Based on our investigation (inevitably select examples in a small corpus from the entire project pool),  we find that most of the teams adopt the \textit{Type1} ($A_1,B_1,C_1$) design with a straightforward blockchain-based architecture. These projects either put focuses on merely one functionality, such as setting connections from Web2 to Web3 \cite{web3auth}, building decentralized identities \cite{idx,ceramic}, or implement the very basic infrastructure \cite{truffle,alchemy,ankr} that can better serve existing blockchain ecosystems. Above reasons made us to select \textit{Type1} as the baseline. For other types, we can observe that the options of external techniques are insufficient. For instance, if a project aims to move the storage off-chain, the options are limited to IPFS \cite{ipfs}, which has been implemented for years with comprehensive instructions and user guides. Affected by little attention to external technologies, other design types (even the sum of the rest ones) only occupy a small share of the entire picture.

\smallskip
\textbf{A Concise Summary.} As shown in Tab.\ref{tab-archievalua}, we provide detailed evaluations of each architectural design. Adding auxiliary techniques (agent, off-chain computation, off-chain storage) will impact the properties from different sides. Positively, performance, scalability, gas cost, and usability can get improved at different levels depending on how many layers have been modified. This is because external techniques can support much more volume of data and participating parties. From the view of single users, they can obtain better services due to faster transaction processing time and cheaper gas costs. In contrast, negatively, security, anonymity, and availability have decreased, compared to the baseline (\textit{Type1}), due to the in-transparency of off-chain processing procedures. Here, the singly applied agent at the client component will not affect the anonymity because either personal address or custodian addresses are equivalent towards adversaries. Similarly, confidentiality, security, and availability are majorly vulnerable at the computation and storage components, with little relation to the access component. Finally, for stakeholders, we can observe that Web3 users can obtain benefits that are consistent with previous reasons (better service). In opposite, both service providers and blockchain maintainers are disadvantageous since the managing costs accordingly increase.

\section{Extending to the Web3 Space}
\label{sec-discussion}
In this section, we extend our scope from architectures to the entire Web3 space. We present the Web3 impacts to current markets. Then, we point out the promising research directions as well as potential barriers on the road.

\subsection{Web3 Impacts}
\label{subsec-impact}

We first discuss the impacts of current Web3 projects. We approach it from two sides. The one is to estimate their influenced market value, while the other one is to see the scale of Web3 applications or services. We give details as follows.

\smallskip
\textbf{Value Estimation.} Supported by mainstream blockchain platforms, Web3 has gained an unexpected breakout. Measuring the quantitative impact is impractical due to its generality and vague bounder. No statistical data can be directly used by different institutions. But we still find indirect ways to reflect its influence. The first way is to investigate the usage of smart contract languages. This is because building a Web3 DApp requires defining logic and functions (e.g., ownership/transfer/connect) through these languages due to its close relation with user interfaces. The total value locked (TLV) by smart contract languages reaches up to maximally $193.14$ billion USD (as of Dec, 2021)\footnote{The TLV of $\$251.877$b is made up by $\$193.14$b from Solidy ($76.68\%$), $\$28.19$b from Rust ($11.19\%$), $\$27.56$b from Vyper $10.94\%$, $\$1.57$b from Ride ($0.62\%$), $\$1.07$b from Cairo ($0.42\%$), $\$193.47$m Bitcoin Script, $\$152.45$m from C\#, $\$3.69$m from Python. Among them, Solidity still occupies the largest proportion, indicating that Ethereum and EVM-compatible platforms play the most important role in the Web3 area. [Data source: \url{https://defillama.com/languages}].}. However, these languages only show a partial picture of the entire Web3 ecosystem, while many competitive programming languages are proposed following the same targets (cf. Appendix C). The real impact of Web3 will greatly outpace the stated data singly observed from languages. Another way to reflect the popularity of Web3 applications is based on fundamental index methodology \cite{web3index} that covers different types of underlying valuation figures such as users' paid fees on applications and individual votes for proposals. Fees, in this track, are different from transaction fees paid to miners in Ethereum. Instead, they are used to represent the cost that people are willing to spend on related decentralized services. For instance, users have spent $253,015$ USD (per $30$ days) on Arweave \cite{arweave} which is used to query or store data on the network. It provides an estimator of a network's value and activities by an in-time track from the view of the demand-side, which provides a distinguished way of investigating the status of the Web3 market.

\smallskip
\textbf{Practical Development.} Besides its high values, Web3 DApps have promoted a rapid evolution towards a wide variety of scenarios. A promising paradigm shift is to move the centralized authority from trusted third parties (TTP) to distributed participants, which is also known as the Decentralized Autonomous Organization (DAO). DAO removes the formal management roles (e.g., delegated authorities) and physical entities (company/office)  \cite{fritsch2022analyzing}, by instead a suite of contracts residing on the Ethereum blockchain. DAOs have been adopted with many instances like Aragon \cite{aragon} and MetaCartel \cite{metacartel}. Another significant shift lies in their way of authenticating identities. Unlike asking for sensitive information through methods of \textit{email$+$password} or \textit{OAuth} in traditional networks, identities in Web3 applications are replaced by anonymous addresses, where the web establisher cannot obtain any useful knowledge of their users. The design further stimulates the widespread of decentralized identifiers (DIDs) \cite{w3cdid}. Users can fully control assets and metadata under their DIDs, and optionally release them to service providers by personal preferences. Moreover, Web3 also instimulates the prosperity of development tools and supplementary suites surrounding blockchain technologies. These tools cover APIs, statistic indicators (The Graph \cite{thegraph}), distributed storage (Sia \cite{sia}, Arweave \cite{arweave}), edge computing (Helium \cite{helium}), etc. They fulfill the blank left from previously isolated components, enabling them to seamlessly integrate together and well support each other. We further provide a look into Web3 applications that are stated in Tab.\ref{tab-projects} in Appendix D. Unfortunately, constrained by our bandwidth, we only select a small group of Web3 projects to demonstrate its wide adoption in this report.

\subsection{New Paradigm}
\label{subsec-oppo}
We then discuss the forthcoming wave of Web3 that goes beyond the initial use case like cryptocurrencies. Web3 can promote technical integration across different domains, ranging from establishing decentralized self-governance organizations to facilitating the progress of DeFi and Metaverse.

\textbf{Technical Integration.} Web3 is a novel approach to delivering internet architecture in a decentralized way. As discussed, Web3 covers every layer of the web architecture, from the front-end to the back-end. It indicates that technical integration may occur in multiple areas. For instance, Theta Labs' \cite{theta} decentralized video solution aims to stream video on Web3 via customized APIs. Audius \cite{audius} is a music sharing platform with the target to decrease the dependency on a record label. Radicle \cite{radicle} is an open-source and distributed platform for code collaboration. Arweave \cite{arweave} and Sia \cite{sia}, similar to IPFS \cite{ipfs}, are to establish a decentralized storage network that allows users to store data. Deeper Network \cite{deeper} intends to build a hardware-powered VPN ecosystem. All these attempts to modify, integrate and improve the existing infrastructure from centralized networks are promising, providing educational experiences on both success path and failure cases for the following developers.

\textbf{Distributed Autonomous Organization (DAO).} Web3 will significantly promote the development of current distributed autonomous organizations. Utilizing a suite of smart contracts improves reliability, as no powerful authorities can break the rules. DAOs run on a flattened hierarchy where each participant has the right to vote on specific issues, similar to the way in a conventional executive board. All the processes, including decision-making, token issuing, option selecting and voting, are transparent due to the on-chain settings. This means anyone, either internally or externally, could audit the code, which greatly improves accountability and reliability and avoids misdirecting usage of funds collected from investors and users. To achieve decentralized governance, every project can issue its specified votes (or tokens) that stakeholders can put their preferences on. For instance, Yearn \cite{yearn} allows users to participate in decision-making and voting on proposals. Radicle \cite{radicle}, as a decentralized GitHub alternative, grants stakeholders the right to manage the project. Similarly, many DeFi protocols, including Uniswap \cite{uniswap}, The Graph \cite{thegraph}, SuperRare \cite{superrare}, and Audius \cite{audius}, enable ownership, participation, and governance via their issued tokens. All these votes and tokens require a Web3 DApp to get interacted with different DAO participants. Also, long-existing DAOs, such as MakerDAO \cite{makerdao}, have attracted many developers contributing to crypto-space and Web3 ecosystems. In this sense, DAO has extended the scope of decentralization, which was previously bound to machines, to a broader area that involves human beings. The shift of \textit{how to operate a digital organization} would pose a great impact on the future world, more than they are presented today.

\textbf{Self Governance.} Initially, software companies in Web1/Web2 obey the rule of protecting data, with a simple aim to involve more users for growth. But eventually, they have to start turning profits by selling or manipulating users' data, such as training AI models to make better recommendations. Users have no choice, facing the dilemma between privacy and convenience. In contrast, individuals in the Web3 space can hold as much personal data, which is more than ever before. Together with DiDs, users can freely browse the internet as well as perceive their data without compromising its privacy. Many solutions, like Ceramic \cite{ceramic} and IDX \cite{idx}, replace traditional authentication by allowing users to build self-sovereign identities. The Ethereum foundation makes much more progress by drafting an RFP \cite{rfpeth} for defining a formal specification. By controlling data and assets, an individual can even earn profits through incentive mechanisms. This is practically important for building a sustainable ecosystem that encourages users to continuously contribute to the required infrastructure.

\textbf{DeFi.} This is an intuitive application of Web3 as all the assets held by users are stored in their wallets. Performing financial-related activities, such as swapping different tokens at DEXes, loaning coins from exchanges, buying/selling crypto-assets from fiat to stablecoins, and designing derivatives (e.g., NFT \cite{wang2021non}, contracts, securities \cite{chen2022absnft}, share, etc.), becomes common and easier for single users since they do not need to register to any financial intermediaries. These activities make up the core of today's DeFi market \cite{werner2021sok}, which also attracts tremendous monetary investments involved in this field. Blockchain systems lay the foundation of DeFi protocols, guaranteeing the normal operations of every piece of logic, while Web3 paves the path to practical usage of these protocols, guiding users to participate in the games. Users only need to act as they behave in centralized markets, rather than having hard research to understand the differences between token standards or blockchain platforms.

\textbf{Metaverse.} Unlike DeFi or NFT specifying one specific direction, Metaverse is a general term that involves numerous technologies, with ambiguous targets to describe a virtual digital world for the incoming future. Intuitively, users in Metaverse will first interact with its front-end and then connect with the decentralized network supported by interoperable blockchain platforms. Web3 can cover all touchable applications that a user can reach, such as social networks, search engines (Brave \cite{brave}), galleries (Opensea \cite{opensea}), and marketplaces. A user can fully control their digital assets, identities, and data, browsing any sector of the Metaverse just like shopping at the store. Web3 can help to establish such a front-end environment with a pretty easy one-step connection for the participating users. In practice, many projects start to establish Metaverse from different aspects like IoT \cite{helium}, Games \cite{axieinfinity}, Markets \cite{superrare}\cite{opensea}, etc.

\subsection{Open Challenges}
\label{subsec-chall}

In this subsection, we point out the potential challenges from four folds, separately from the views of user-level (\textit{application}), system-level (\textit{blockchain}), markets (\textit{economy}), and social organizations (\textit{legality}).

\noindent\textbf{Application.} Decentralized applications built on blockchain-empowered systems are the first gate to individuals. Users have intuitive feelings towards these applications. We abstract three aspects that may affect the user experience.

\begin{itemize}
    \item[-] \textbf{Composability.} Web3-based solutions cover a wide range, either from the type of components, or the products for each component. Data transmitting in different products are inevitably isolated. The way to make data reused by different products at the same layer is urgently important. Standardized APIs may address the problem to some extent, where at least many DApps with similar designs can invoke the same APIs. Ceramic \cite{ceramic} tries to build applications with composable Web3 data and enable reusable data for multiple scenarios. However, making most back-end components composable is still a challenge. The barriers are whether composable components are compatible with each other and whether data can flow seamlessly across different components. For such reasons, the data need to be designed in the same structure for the re-usage by these components.

    \item[-] \textbf{Accessibility.} Web2 networks still cover most Internet users' activities, including social media, shopping, meeting, education, and payments. Users are accustomed to and enjoy their services due to their super convenience and easy accessibility. The lack of integration with modern web browsers and mobile applications limits the wide adoption of Web3 to end-users. An individual user will not change from the product that he used for a long to a new one. How to decrease the migration cost is a challenge. Moreover, interacting with Web3 applications also requires additional development, education, and software/hardware. This becomes a huge recognition difficulty for users and thus impedes its wide adoption.

    \item[-] \textbf{Data Recovery.} The private key is the most important secret of users when using blockchain platforms. The entire account of users relies on a credential that is represented in the form of a complex string or a series of secret recovery phrases. If a user loses his private key, he will never enter his account. The account becomes a dead account with all data, including assets, being locked. Methods to recover accounts, or at least the internal data, are an urgent requirement for applications in the Web3 space. Moreover, applications that adopt off-chain storage require more strict verification for data integrity because additional checks on whether the data in external storage matches on-chain hash values are needed. The data recovery in external pages is difficult due to the absence of traceability and accountability.
\end{itemize}

\smallskip
\noindent\textbf{Blockchain.} Blockchain systems are the most fundamental layer in each architectural design type, supporting upper-layer applications as well as connecting underlying storage. Limitations in blockchain systems will significantly constrain the development of the entire Web3 ecosystem.

\begin{itemize}
    \item[-] \textbf{Scalability.} Scalability represents the ability to process transactions along with the increased scale of networks, which is reflected by the increase or decrease in its performance. This is a long-term issue existing in blockchain systems due to intrinsic decentralization. Every major step needs time, such as data update, signature verification, etc. Among them, the consensus process has the most impacts since the more mining nodes joined the network, the more computational tasks were added. Web3 is closely integrated with underpinned blockchain systems, which, as a result, will face the similar issue as well. In most cases, transactions are slow on website interactions as state transitions need confirmation and propagation throughout the network. Underlying blockchain platforms, together with atop Web3 applications, require conquering the challenges of accommodating rapid growth and the demands of not compromising performance. Otherwise, users, with a high probability, may have a poor experience such as extremely slow loading speed of websites.

    \item[-] \textbf{Interoperability.} Web3 applications, in the foreseen future, will be deployed on many blockchain platforms. This requires interoperable blockchain technologies to facilitate smooth state transitions, either homogeneously or heterogeneously. Creating interchangeable communication channels to connect isolated decentralized ledgers is still a challenge for the development. Current interoperability solutions, such as pegged sidechains \cite{deng2018research}, hash-locks \cite{herlihy2018atomic}, and trusted relays \cite{frauenthaler2020testimonium}, partially mitigate the problem: they enable transactions to cross over chains within their specified ecosystems (e.g., Polkadot and their para-chain slots \cite{wood2016polkadot}), but cannot make nature transactions operated across different ecosystems (Polkadot token on Ethereum). A prevailing method is to create the wrapped token that anchors the origin token with equal supplies as an alternative representation, such as the BTC coin existing in Ethereum with the representation of WBTC (an ERC20 format \cite{wbtc}). However, this makes more and more \textit{representative} tokens produced with no actual usage, increasing the waste and complexity.

    \item[-] \textbf{Contract Vulnerability.} The security of smart contracts \cite{atzei2017survey} will directly affect its connected Web3 applications. Smart contracts contain the business logic and operation specifications, which are key to the upper layer applications. Meanwhile, smart contracts can act as autonomous agents \cite{li2022smart}, decreasing the power of centralized service providers in combined protocols and securing on-chain data from users. Vulnerabilities existing in smart contracts, caused by design flaws or implementation errors, may result in thousands of monetary loss. Examples include the integer underflow/overflow attacks \cite{atzei2017survey}, DAO attacks \cite{daoattack}\cite{thedao} and Parity Multi-Sig Wallet attack \cite{parityattack}. Even worse, the scripting nature of contract programming languages (cf. Appendix C) and the non-updateable feature of smart contracts will significantly limit the growth of Web3 applications.
\end{itemize}

\smallskip
\noindent\textbf{Economy.} As one of the major differences compared to Web1/Web2, users in the Web3 space can automatically obtain rewards according to their contributions. Users holding both digital assets and metadata in their wallets can freely trade them to earn profits. But there are still many concerns about disparate incentive mechanisms, operating costs, and technical debts.

\begin{itemize}
    \item[-] \textbf{Incentive.} Users adopt Web3 applications largely due to their considerable potential revenues. They can earn extra profits by conducting activities in Web3 networks: browsing websites (Basic Attention Token \cite{brave}), providing online storage (Arweave \cite{arweave}), playing games (Axie Infinity \cite{axieinfinity}), or selling self-created products (Opensea~\cite{opensea}). Even for the current stage, developers can obtain airdropped tokens from the project teams by testing their demos on the testnet. However, as more and more users participate in the game, the threshold of obtaining rewards becomes extremely high. Thus, designing a positive incentive mechanism that can cover as many users is crucial to attract new players joining the network.

    \item[-] \textbf{Cost.} The high gas fee has already become a major hurdle in using Ethereum. Sending an transaction will cost more than hundreds of dollars (executions on smart contracts cost more). As a result, applications with complicated computations cannot be deployed on-chain. This is the reason why many competitive public blockchains can co-exist in the market. Moreover, blockchain provides very constrained capabilities of storage, where many DApps can only put a small portion of code on-chain. A potential solution is to adopt more off-chain solutions \cite{gudgeon2020sok} that can take over the workload from on-chain to local servers without significantly breaking decentralization.

     \item[-] \textbf{Technical Debt.} Many Web3 applications are designed in a limited way to facilitate the entire software development cycle. This would cause many costs of additional rework in the latter processes, which is denoted as the \textit{technical debt} \cite{techdebt}. A suitable approach that aims for a long-term proposal can save many more costs because a bad design will accumulate \textit{interest} just as it is in monetary debt. Developing more in an inappropriate route can improve the difficulty of making updates. The development of a project falling into technical debt will reach a point where it is no longer possible to implement the protocol improvements that align with its initial vision. Developers should be sufficiently prudent when designing their products, even for the initial proof-of-concept implementations.
\end{itemize}

\smallskip
\noindent\textbf{Legality.} Governments and official organizations have a lot of concerns due to the rapid shift and huge change in the cryptocurrency world. Individual users are eager to have their non-infringeable rights and are afraid of an anarchy state. It is pretty difficult to reach the balance. Here, we stress the two discussed challenges in the view of the social side.

\begin{itemize}
    \item[-] \textbf{Governance.} Since anyone can launch Web3 projects, an increased number of applications will inevitably make the market segmented and unsupervised. Traditional authorities such as official organizations and governments become less influential than it is today. A large proportion of power is distributed to DAOs, which are made up of individuals. However, anyone who uses Web3 can arbitrarily establish DAOs without strict authentication or KYC (know your customer) steps. This causes instability in society \cite{kiayias2022sok}. For instance, (web3) tweets on decentralized social media platforms would be uncensorable without facing the risk of being punished for spreading rumors. Moreover, some illegal trades, such as porn or drugs, might be abused in unsupervised networks as no explicitly compulsive laws can forbid them.

    \item[-] \textbf{Taxable Difficulty.} The intrinsic property of Web3 is to give the incentive back to users. Individuals who contribute more will obtain higher rewards. Their contributions can be in any form, such as deposited stakes (PoS-based chains \cite{kiayias2017ouroboros}), activities (many projects airdrop tokens based on this), attentions (e.g., BAT \cite{brave}, Cirus \cite{cirus}), or followers in traditional social media (Twitter, Discord, Facebook). If most of the current network users move to the Web3 world, collecting taxes from, at least, technology companies and Internet practitioners becomes extremely difficult. Even worse, hiding assets in accounts can help users directly make investments in financial markets and earn profits. The governments can never know what has happened and when this has occurred, nor for associated evidence used for taxes.

\end{itemize}

\section{Closing Results}
\label{sec-closing}

This section collects several popular questions that are frequently mentioned in communities. We accordingly answer them with our investigated results.

\noindent\hangindent 1em \textit{\textbf{What is Web3?}} Web3 is an umbrella term used to describe the next generation of internet services. It incorporates a wide range of components in the computer infrastructure. We have, in this work, investigated \textit{in the wild} solutions and found several common design patterns. We decouple Web3 services into three major components as in Sec.\ref{sec-archi}. With this, an application/service, in the context of our methodology, can be categorized into a Web3 space if \textit{at least one component is decentralized}. Based on the current view, an ideal Web3 application, operates all the services on-chain. However, this design can only support services with lightweight computations and storage. Supplementary services require external techniques.

\noindent\hangindent 1em \textit{\textbf{What is the cornerstone of Web3?}} Following the previous discussion,
a natural question is that: how to implement the decentralization of each component for building Web3. We review the identified twelve architectural designs and find an interesting result: every component centres around continuously operating blockchain platforms. The front-end wallet needs to connect with the on-chain operation, while the external storage also requires on-chain information for item searching and valid proofs. Therefore, the characterization through \textit{access}, \textit{computation} and \textit{storage} highly rely on the service of blockchain: \textit{access} to the blockchain, \textit{computation} in the blockchain, and \textit{storage} surrounding blockchain. These integrated components can establish a Web3 service thanks to the support from the blockchain. In this way, Web3 holds the property of decentralization, obtaining benefits from the blockchain.

\noindent\hangindent 1em \textit{\textbf{Is Web3 sufficiently decentralized?}} Web3 is not as decentralized as it appears to be \cite{werbach2018blockchain}, in which building a Web3 application still highly relies on a small corpus of companies. For instance,  centralized exchanges that can trade cryptocurrencies are majorly controlled by Binance \cite{binance} and Coinbase \cite{coinbase}, while wallets are affected by MetaMask \cite{metamask}, NFT products  \cite{wang2021non} by OpenSea \cite{opensea}, and stablecoins by Tether \cite{tether}. Meanwhile, a similar phenomenon also occurs in DeFi markets: Uniswap \cite{uniswap} has the most Total Value Locked (TVL); Dai \cite{dai} has dominated the decentralized stablecoins; Chainlink \cite{chainlink} has greatly outcompeted others in the price oracle. Moreover, many infrastructure-related blockchain companies that provide programming interfaces and development tools are concentred on a few companies like Alchemy \cite{alchemy}, Infura \cite{infura}, and Ankr \cite{ankr}. The high density of consolidation in the cryptocurrency field will inevitably result in a partial monopoly, where only a small group of oligarchs takes most of the resources.

\noindent\hangindent 1em \textit{\textbf{Is Web3 secure?}}
The answer would be ``No". Web3 services rely on a suite of composable components to seamlessly work together. Problems in any single component may lead to fail. Come back to our NFT example, the raw data of the NFT may be erased due to the offline insecure storage by adversarial attacks or compromised managers. This is merely an example from the storage layer. In the real world, issues happening in other blockchain components will as well result in severe problems, such as transaction congestion due to poor scalability, slow confirmation caused by probabilistic consensus, or logical loopholes in smart contracts. The security of Web3 is closely related to correct operations of the entire system, which should be an all-level stack evaluation.

\noindent\hangindent 1em \textit{\textbf{Has Web3 addressed privacy worries?}} Web3 services cannot protect user privacy as it claimed. We give discussions from the website, which is the entry of a user to Web3 applications and services. Web-side privacy issues cover a set of design pitfalls and malicious attacks launched from the front-end, such as browsers or mobile applications. In many cases, an adversary may act like a normal operator in the system. For instance, the centralized authority can play the role of a tracker with abilities to record Ethereum addresses over a wide range of users, resulting in privacy violations with the help of its script embedding techniques \cite{winter2021s}. Once a user leaves evidence of using an address at a DeFi site, the malicious browser, which also holds your identities, can map to your physical entity. Besides, other traditional web attacks may also threaten the Web3 sites due to the shared engine.

\begin{center}
\tcbset{
        enhanced,
        colback=red!5!white,
        boxrule=0.1pt,
        colframe=red!75!black,
        fonttitle=\bfseries
       }
       \begin{tcolorbox}[
       title=Fact and Fiction - Truth to be Told of Web3,
        arc=5pt,outer arc=5pt,drop large lifted shadow]
       Based on our investigations from both technical and economic perspectives, Web3 cannot fully replace current web services. Instead, Web3 will still highly rely on the existing Internet infrastructure, including programming languages, communication protocols, agents, and storage. Fortunately, Web3 has reshaped conventional finance markets and facilitated individual self-governance. Users at least begin to pay much more attention to their digital assets covering both virtual data and cryptocurrencies.
       \end{tcolorbox}
\end{center}

\section{Conclusion}
\label{sec-conclu}

Web3 is an emerging concept prevailing in the entire crypto-world. Applications and services in the Web3 space, with non-custodial nature, allow users to control their data and obtain rewards. However, no clear definitions of such a \textit{buzzword} have formed. In this tech report, we fill the gap by investigating a large corpus of \textit{in the wild} projects titled with Web3. We dig into this topic by decoupling existing systems supporting blockchain-based Web3 services into separate core components, and accordingly discussing related features and properties for each potential combination. In total, we have identified twelve architectural design types and evaluated them with profound discussions. Based on our study, we present the new paradigms gained by Web3 and point out the design pitfalls. We further provide our answers to several questions from communities. To the best of our knowledge, this is the first research on Web3 from the view of blockchain.
\bibliographystyle{unsrt}

\section{Introduction}
Web3, also known as Web 3.0 or decentralized web, hits the cryptocurrency markets and blockchain communities from 2020 to date \cite{web3soul}\cite{csnreport}. It has become the most prevailing term in the recent period of blockchain prosperity. The concept, proposed by Wood \cite{woodweb3}, promises to provide distributed internet services without trusted third parties (TTP), thereby offering users more control over their data. The very primary principle shared by Web3 applications is that users can hold the data with full control, covering identifiers/tokens/ownership/etc., rather than being managed by centralized organizations as in Web1 and Web2 (cf. Appendix A). With the emphasis on \textit{decentralization}, Web3 moves data away from these central authorities and establishes applications and services surrounding blockchain technologies. Ideally, Web3 developers do not need to build applications on top of a single server (processing business logic) or database (storing user data). Instead,  Web3 applications are deployed on decentralized networks such as blockchain platforms or related distributed systems hosted by many peer-to-peer (P2P) servers.

The conversion from central authorities to the blockchain, more than handing over the ownership back to users, brings many non-functional benefits of being (i) \textit{open}: Web3 data is stored in an open network developed by public communities. Also, Web3 applications are executed in a global view towards the public, making data permanently visible to all the participants; (ii) \textit{trustless}: a user can build connections or exchange assets to an unfamiliar user without the reliance of a trusted third party; (iii) \textit{permissionless}: users' identities are no longer tied to any specific platform and users' activities are free, which do not need an authorization from a governing entity; (iv) \textit{anonymous}: users can obtain partial anonymity through using multiple pseudonyms or off-chain storage; and of (v) \textit{high availability}: Web3 provides a high availability architecture, which reduces the probability of the server crash or single point failure;  (vi) \textit{compatibility}: Deployed services and applications are not limited in the Ethereum ecosystem, but applicable to all competitive blockchains \cite{dappradar,mathdapp} like Avalanche \cite{avax}, Solana \cite{solana}, Binance Smart Chain \cite{bsc} or Oasis Network \cite{rose}, indicating that Web3 can integrate both existing public-chain ecosystems and incoming systems.

Web3 also improves user experience in using web stack technologies and thus promotes the development of blockchain technologies. Web3 helps to build a complete user experience that can better serve newcomers. Users, from the current view, only need to \textbf{\textit{connect the wallet}} to their targeted sites. These sites contain the activities that a user would love to spend time on, which can be specified in different types, such as asset swaps (in DEXes \cite{xu2021sok}), games \cite{axieinfinity}, and trades (of NFTs \cite{wang2021non}). Meanwhile, users can obtain a portion of revenues by keeping active in these projects. The contributions are measured in a wide range covering spent time, interactions, deposits, staking, etc. Users can receive fair rewards as well as add more liquidity to the Web3 ecosystem. In this sense, Web3 has greatly extended the boundary of blockchain, incentivizing more users to participate in the games. The evidence is, as in Dec 2021, the total locked value (TLV) of Web3-related smart contact contract has reached a peak with 193.14 billion USD (more details in Sec.\ref{subsec-impact}). Such a high capitalization market further stimulates the prosperity of techniques surrounding blockchain (cf. Tab.\ref{tab-projects}).

However, despite the fact that Web3 has drawn much attention, clear statements of \textit{what is Web3} and \textit{how Web3 is designed} are even absent. Several studies provided their investigation on the consensus level~\cite{liu2021make} but failed to cover a full view of other components and architectural designs that are equally important to Web3. Unclear definitions and non-agreed consensus indicate that Web3 either is just a hyped concept without practical development or, has more than one single direction for the development. In this technical report, we avoid such high-level discussions, narrowing down the scope to the Web3 architecture and its relation with blockchain. We dig into its building process, investigate its usage in existing projects, and deconstruct the protocol into separated components. With this in the arm, we analyze and evaluate \textit{state of the art} Web3 solutions from perspectives of their design patterns and properties. We further extend our scope to the entire Web3 space (still rooted in blockchains) by discussing their impacts, opportunities, and challenges. To our knowledge, this work provides the first in-time study on Web3, reviewing and exploring the wild Web3 solutions.

\begin{itemize}
\item[-] We investigate existing Web3 projects and extract a succinct backbone model with participating roles and operating workflow to demonstrate the major processes. This provides a loose general model for easy adoption, as well as highlights the core steps to establish a Web3 service.

\item[-] We classify a total of twelve architectural designs of Web3 to reflect the operating mechanism of typical Web3-based applications. We decouple a full Web3 service into three-layered components according to the data workflow. Data in each component can be either operated by the ways of \textit{on-chain}, \textit{off-chain} or \textit{hybrid}. The identified design types can well present all potential combinations, covering a wide range of Web3 applications and services.

\item[-] We accordingly evaluate each architecture based on different property metrics that are grabbed from classic blockchain systems. The evaluation analyses the architectures from multi-dimensional properties (cf. Tab.\ref{tab-archievalua}) when adapting to real applications. We also discuss which participating entity can gain the most benefits under different types. The evaluations directly help software architects to evaluate and compare Web3 solutions and further design their architectural frameworks.

\item[-] We extend our scope from architectural design to the entire Web3 space by discussing its impacts, opportunities and challenges to predict the potential future directions. We show several promising fields that may be inspired by Web3-related technologies, and also point out the open challenges needed to be addressed in the long term. Meanwhile, based on our analyses and evaluations, we answer several questions that are frequently asked by the communities as our closing results to conclude this work.

\item[-] Further, we provide much more surrounding knowledge that is related to Web3, covering its basic primitives, referenced token standards, and adopted programming languages. Necessary primitives cover both architectural design in conventional web services and layered components in classic blockchain systems. The knowledge lays the foundation of Web3, presenting the common components in different blockchain-based Web3 projects.

\end{itemize}

The rest of this paper is organized as follows. Section \ref{sec-protocol} presents a typical Web3-based protocol, together with the inducted security model. Section \ref{sec-archi} presents our architecture extraction and design, as well as gives the criterion used to capture the features of Web3 related applications. Section \ref{sec-evaluation} details our evaluation towards architectural designs, providing practical adaption under different scenarios. Section \ref{sec-discussion} discuss current impacts, opportunities and challenges. Finally, Section \ref{sec-closing} gives our closing results and Section \ref{sec-conclu} concludes this work. Notably, we provide more knowledge of Web3: Appendix A gives fundamental primitives surrounding Web3 and an abstract Web3 workflow. Appendix B and C summarize existing token standards and EVM-operated programming languages, respectively. Appendix D shows a small corpus of \textit{in the wild} Web3 projects.

\section{Web3 Protocol}
\label{sec-protocol}

This section extracts the protocol, security model, and a running example of Web3 systems between user clients and the blockchain infrastructure (together with the protocol workflow, referring to Fig.\ref{fig-workflow} in Appendix A.3). Before our investigation, we clarify the entities that participate in Web3 protocols.

\smallskip
\textbf{Involved Entities.} The Web3 protocol mainly consists of three types of roles, namely, the \textit{Web3 user}, \textit{service provider}, and the \textit{blockchain maintainer}. The Web3 user is a data owner who can propose the request by sending a transaction from the client. The service provider offers the user an on-chain interface and the service that can both process the request and interact with blockchain platforms. The blockchain maintainer provides an operating environment for smart contracts that take the task of processing business and data storage.

\smallskip
\textbf{{General Construction.}}
To launch the Web3 service, a Web3 user needs to first establish his distributed identity by creating an address or account on-chain at the client. Then, the user login the applications using his address-based identity. Subsequently, the application will interact with the blockchain for data computation and data storage. Here, we present the detailed protocol.

\noindent\hangindent 1em \textbf{\textit{\,\, Identity Creation} ($\mathsf{\Pi_1}$).} This algorithm takes as input the security parameter $\kappa$, and outputs a blockchain address/account $addr$. The address provides a public and open-source index that can be associated with an existing identifier. Also, this address is used as an identifier for sending or receiving the cryptocurrency. It covers three sub algorithms, \textit{private key generation}, \textit{public key generation} and \textit{address generation}.

\begin{equation*}
\centering
\begin{aligned}
sk \gets \mathsf{KeyGen_{sk}}(1^{\kappa}), \\
pk \gets \mathsf{KeyGen_{pk}}(sk),\\
addr \gets \mathsf{AddressGen}(pk).
\end{aligned}
\end{equation*}

\noindent\hangindent 1em \quad The algorithm is run by a local Web3 client (e.g., client-based wallet, browser extension-based wallet). Note that the sub-algorithms $\mathsf{KeyGen_{sk}}$, $\mathsf{KeyGen_{pk}}$ and, $\mathsf{AddressGen}$ have different manifestations. For example, for $\mathsf{AddressGen}$, Bitcoin addresses use the base-58 encoding\footnote{https://tools.ietf.org/id/draft-msporny-base58-01.html}, while Ethereum addresses adopt the base-16 encoding algorithms.

\noindent\hangindent 1em \textbf{\textit{\,\, Transaction Generation} ($\mathsf{\Pi_2}$).} This algorithm takes as input the user's private key $sk$, the transaction $metadata$, the transaction $payload$, and accordingly outputs an enveloped transaction $Tx$.

\begin{equation*}
\begin{aligned}
sig \gets \mathsf{Sign}(sk, metadata, payload), \\
Tx \gets \mathsf{TranGen}(sig, metadata, payload).
\end{aligned}
\end{equation*}

\noindent\hangindent 1em \quad This algorithm is run by a Web3 client that receives the request from users. $sk$ is used to generate a signature. $metadata$ refers to transaction-related data, such as the transaction receiver and transaction nonce. $payload$ points to the contract method to be involved and the data to be stored.

\noindent\hangindent 1em \textbf{\textit{\,\, Contract Execution} ($\mathsf{\Pi_3}$).} This algorithm takes as input the transaction $Tx$, and current state $\overline{s}$, and smart contract $contract$, and accordingly outputs the transferred state $s$.
\begin{equation*}
s \gets \mathsf{ContractExec}(\overline{s}, Tx, contract).
\end{equation*}
\noindent\hangindent 1em \quad This algorithm is run by the blockchain maintainers in the network. The transited state $s$ includes a reward or payment used to incentive the participating nodes. The contract $contract$ contains the logic of upper-layer applications, which defines how the state changes happening on the blockchain.

\noindent\hangindent 1em \textbf{\textit{\,\, State Consensus} ($\mathsf{\Pi_4}$).} This algorithm takes as input the transaction $Tx$, the smart contract $contract$ and the current state $s$ to be transited, and outputs the confirmed state $s^{\prime}$, and the confirmed transaction $Tx^{\prime}$.

\begin{equation*}
(s^{\prime}, Tx^{\prime}) \gets \mathsf{Consensus}(s, Tx, contract).
\end{equation*}

\noindent\hangindent 1em \quad  This algorithm is run by blockchain maintainers. The term \textit{confirmed} indicates that the proposed block (containing $s$ and $Tx$) has been agreed upon by sufficient maintainers in the network. The  threshold of confirmation depends on specific algorithms (e.g., 51\% in PoW \cite{nakamoto2008bitcoin}, 2/3 in BFT algorithms \cite{castro1999practical}).

\noindent\hangindent 1em \textbf{\textit{\,\, State Retrieval} ($\mathsf{\Pi_5}$).} This algorithm takes as input the user's address $addr$ and outputs the transaction $Tx^{\prime\prime}$ and the related state $s^{\prime\prime}$.

\begin{equation*}
(s^{\prime\prime}, Tx^{\prime\prime}) \gets \mathsf{Retrieval}(addr,  contract).
\end{equation*}

\noindent\hangindent 1em \quad  This algorithm is run by a Web3 client who aims to retrieve the state.

\smallskip
\noindent\textbf{Secure Web3 Protocols}. Based on the extracted general construction, a secure Web3 protocol is informally defined as follows.

\smallskip
\begin{defi}[Secure Web3 Protocol]
A Web3 scheme $\mathsf{S}$ is secure, if for all blockchain address $addr$ and the initial state $\overline{s}$ outputted from Phase $\mathsf{\Pi_1}$ to Phase $\mathsf{\Pi_5}$, it holds that,

\begin{equation*}
\left[
\begin{array}{ll}
\begin{aligned}
     sig \gets \mathsf{Sign}(sk, metadata, payload) \\
Tx \gets \mathsf{TranGen}(sig, metadata, payload) \\
s \gets \mathsf{ContractExec}(\overline{s}, Tx, contract) \\
 (s^{\prime}, Tx^{\prime}) \gets \mathsf{Consensus}(s, Tx, contract) \\
\end{aligned}
\end{array}
\right]  \Rightarrow (s^{\prime}, Tx^{\prime})
\end{equation*}

\begin{equation*}
\left[
\begin{array}{ll}
\begin{aligned}
(s^{\prime\prime}, Tx^{\prime\prime})\gets \mathsf{Retrieval}(addr,  contract) \\
\end{aligned}
\end{array}
\right]  \Rightarrow (s^{\prime\prime}, Tx^{\prime\prime})
\end{equation*}

where the output satisfies:
\begin{align*}
(s^{\prime}, Tx^{\prime}) = (s^{\prime\prime}, Tx^{\prime\prime})
\end{align*}

\end{defi}

The definition states that a Web3 protocol is deemed to be secure if a user can successfully retrieve the correct state and transaction on the blockchain at any time after the block confirmation. Our security model is based on the assumption of a \textit{robust} blockchain \cite{garay2015bitcoin} and the corresponding security is guaranteed by \textit{persistence} and \textit{liveness}~\cite{garay2017bitcoin}. The \textit{persistence} means whether different nodes have the same view at a specific height of blocks, while the \textit{liveness} focuses on whether a block can be eventually buried deep enough (without the possibility of being reversed) in the valid longest chain. We omit other types of chain structure, such as the directed acyclic graph (DAG) \cite{wang2020sok}.

\begin{figure}[!hbt]
    \centering
    \includegraphics[width=0.9\linewidth]{img/instance.png}
   \caption{An Instance of Web3 User Case}
   \label{fig-instance}
\end{figure}

\textbf{A Running Example.}
We provide an instance to describe how a Web3 system works. The case is straightforward: assume that a user wants to sell his self-created NFT painting on-chain (cf. Fig.\ref{fig-instance}). Firstly, he needs to connect his wallet to the related website and send the request to mint an NFT on his targeted blockchain platforms \cite{wang2021non}. The action of \textit{mint} requires invoking APIs that enable interactions with smart contracts. The contract is executed according to its predefined specifications and token standards (ERC721, see details in Appendix B). After processing the logic, the raw picture is stored in an external decentralized storage network, e.g., IPFS \cite{ipfs}, due to its high-resolution format. IPFS separates the raw data into pieces and distributes them into different nodes, labelling each of them with a content identifier (CID). The returned identifiers are recorded on-chain for further queries from users. Once completing the entire logic, the seller can trace the transaction and his NFT on the blockchain. The buyer with willingness can buy the seller's NFT on Opensea \cite{opensea}, and pay the prices as stated. The ownership of this NFT will be automatically transferred to the buyer once completing the payments.

\section{Architectural Design}
\label{sec-archi}

The architecture is the foundation of software systems. It defines the system structure and external-world interface via underlying components and their relationship. This section provides our architectural design for Web3 systems.

\subsection{Design Principle}

We stay aligned with the mainstream recognition of Web3 and accordingly structure our report by progressively presenting the ways to build a Web3 service and the featured properties in different designs. Based on plenty of investigation towards \textit{in the wild} Web3 projects, we classify them into a compact framework (cf. Fig.\ref{fig-model}), which thus allows the audience to explore the conceptual design space and evaluate different design options.

Specifically, we delineate two basic axes, namely, \textit{decoupled component} and \textit{technical route}, to explore the subtle differences in each cross from orthogonal directions. For the former, we abstract three critical components, including  \textit{client}, \textit{compuation} and \textit{storage}, as our characterisation. Our decoupling is based on the data workflow, which contains three corresponding phases (A-C in Fig.\ref{fig-model}), \textit{data access}, \textit{data computation} and  \textit{data storage}, to describe how data transfers under a normal operating logic. For the latter, we extract three technical routes of implementing a blockchain system: \textit{on-chain} processing, \textit{off-chain} processing, and their \textit{combinations} (hybrid).

By interweaving two axes, we can find that each component can be categorized into sub-items according to its on-chain/off-chain processing route. Based on that, we identify a total of twelve types of architectural designs to show different purposes and usages among a large bunch of projects. Moreover, we capture several essential properties that are frequently mentioned in classic blockchain systems to evaluate the proposed design types. This framework captures major architectural characteristics and related properties of each type, helping Web3 users and software architects to choose the proper design for their products. We give the detailed definitions of each item as follows.

\begin{figure}[h!]
    \centering
    \includegraphics[width=1\linewidth]{img/model.png}
   \caption{\textbf{\textit{Framework.}} We have first identified three major components according to the data workflow: access, computation, and storage (cf. \textit{left Square}). Then, we extract three technical routes that reflect the ways of data processing in blockchain systems: on-chain, off-chain, and hybrid (\textit{medium Square}). Based on the two principal dimensions, we summarise a total of $12$ types of potential Web3 architectural designs (\textit{bottom Square}). With this in the arm, we analyze every type in terms of different property metrics (\textit{right Square}) and point out design trade-offs. Notably, we also provide a guide map by using \textit{blue dotted line}. }
   \label{fig-model}
\end{figure}

\subsection{Decoupled Components}
\label{subsec-compo}

We first investigate how data flows from a user to its backend server. In such a procedure, we have totally extracted three major processes to normal system operations: \textit{data access}, \textit{data computation} and \textit{data storage}. Such procedures describe a typical workflow of blockchain systems.

\begin{itemize}
 \item[-] \textbf{\textit{Data Access.}} To start a Web3 service, a user first needs to send his request through a client. Typically, the request is formatted as a transaction, and accordingly, the client is instantiated as a wallet\footnote{We omit the sub-categories of different wallet types, such as whether utilizing SPV or hardware. More details refer to \cite{chatzigiannis2021sok}\cite{karantias2020sok}.}. Users enter the network by connecting their wallets to a specific website.

  \item[-] \textbf{\textit{Data Computation.}} After a successful connection, the requests from users are parsed into different pieces of logic, being transmitted into backend blockchain platforms. Blockchain operates the logic and decoded methods via smart contracts according to their predefined specifications.

 \item[-] \textbf{\textit{Data Storage.}} The executed data, at last, should be permanent storage. In normal cases, small size data can be directly recorded inside transactions, whereas in some cases, large-scale data requires external storage. The key to maintaining the data integrity in off-chain storage is to add a \textit{hook} that connects the on-chain (such as a hash) and off-chain data.

\end{itemize}

Then, based on descriptions of data flow, we abstract three fundamental components in a full-functional Web3 service by decoupling existing solutions. Merging with our different data processing routes, we categorize the decoupled component with \textit{on-chain}, \textit{off-chain} and \textit{hybrid} options (selected by two or all of them). We give their definitions as follows (and more details in Sec.\ref{subsec-component}). To be noted, as Web3 is featured by decentralization, at least one of the components should be operated on-chain, where no gatekeeper can fully control the network.

\smallskip
\textbf{Client.} Clients are used to receiving requests from users. Classic blockchain systems, on a small scale of requests, can use a single browser as the client to connect with the wallet. However, if the request sharply increases within a short time frame, an agent is required to process an instantaneous flow of requests.

\begin{itemize}
 \item[-] \textbf{\textit{Browser-based Wallet.}} A browser-based wallet is an intuitive solution for users to adopt the Web3 service. Users only need to install an extension tool in the browser and import their private key to this embedded wallet. When browsing a Web3-supported website, users can directly put the button of \textit{connect the wallet}, and all the clicked functions in this website will invoke the backend methods through APIs under the user's account.

 \item[-] \textbf{\textit{Agent-based Wallet.}} An agent solution is to enable batch processing when confronting a high-density situation of requests from users. Similar to traditional Web1/Web2, users should first grant a trusted agent with proper permission. The authentication procedure is executed once users have formally started to register with the agents.
\end{itemize}

\smallskip
\textbf{Computation.} Operating a Web3 service built on smart contracts requires great computing power as the running environment. Purely on-chain computation is instant but costly. A hybrid computation that moves partial computational tasks off-chain is another solution.

\begin{itemize}
 \item[-] \textbf{\textit{Contract-based Computation.}} All the computations are performed on-chain through smart contracts. Here, variables in smart contracts are allowed to be revoked and modified based on the predefined contract instructions.

 \item[-] \textbf{\textit{Hybrid Computation.}} A partial proportion of computations are executed on-chain, while the rest of the computations off-chain. Generally, verification mechanisms are required in this method in order to guarantee integrity between on-chain and off-chain data.

\end{itemize}
\smallskip
\textbf{Storage.} Similar to any services applied to Web1/Web2,  applications and services in Web3 also require enough space for storage. Data in small size, such as ordinary transaction payload, can be stored directly on-chain. In contrast, for the large size, or complicatedly formatted data, like streaming video or raw audio, it should be (partially) stored to external deceives or providers. In this sense, we summarize three types of data storage.

\begin{itemize}
 \item[-] \textbf{\textit{On-chain Storage.}} All the data is stored on-chain, as a state of the smart contract. Any changes will be publicly recorded and can be verified by the entire network. Theoretically, this is the best way to prevent malicious nodes from destroying data due to its total transparency and accountability.

 \item[-] \textbf{\textit{Off-chain Storage.}} It refers to storing data in off-chain networks where only the hash roots are recorded online (e.g., IPFS \cite{ipfs} or Swarm \cite{swarm}). The solution requires an additional process for verification, such as proof-of-existence, to prove data integrity.

 \item[-] \textbf{\textit{Hybrid Storage.}} This is a mixed way that combines both on-chain and off-chain storage, which means storing raw data off-chain (like video and audio) and light metadata (such as account history and certificates) on-chain. The proportion of these solutions is adjusted according to specific scenarios.
\end{itemize}

\subsection{Architectural Designs}\label{subsec-design}

We have identified totally twelve types of architectural designs towards Web3 services (cf. Architectural Type $1-12$ in Fig.\ref{fig-model}). Specifically, we denote each design with \textit{Type}, and it is made up by a three-element tuple $(A_a,B_b,C_c)$ where $a,b \in \{1,2\}$, and $c \in \{1,2,3\}$. Here, the elements $A,B,C$ separately specify the components of \textit{client}, \textit{computation} and \textit{storage}, while the subscripts $1,2,3$, respectively, represent \textit{on-chain}, \textit{hybrid} and \textit{off-chain} as defined before. Based on different combinations, we provide the potential architectural designs as follows.

\begin{itemize}
    \item[-] \textit{Type1} $(A_1,B_1,C_1)$, \textit{Type2} $(A_1,B_1,C_2)$, \textit{Type3} $(A_1,B_1,C_3)$, which are shown in the \textit{black line} at the left square in Fig.\ref{fig-model};

    \item[-] \textit{Type4} $(A_1,B_2,C_1)$, \textit{Type5} $(A_1,B_2,C_2)$, \textit{Type6} $(A_1,B_2,C_3)$ (\textit{\textcolor{brown}{brown line}});

    \item[-] \textit{Type7} $(A_2,B_1,C_1)$, \textit{Type8} $(A_2,B_1,C_2)$, \textit{Type9} $(A_2,B_1,C_3)$ (\textit{\textcolor{blue}{blue line}});

    \item[-] \textit{Type10} $(A_2,B_2,C_1)$, \textit{Type11} $(A_2,B_2,C_2)$, \textit{Type12} $(A_2,B_2,C_3)$ (\textit{\textcolor{teal}{teal line}}).
\end{itemize}

In each design type, smart contracts play the most essential role in entire services that are responsible for on-chain calculations. \textit{Type1} is the most simplified architectural design amongst those combinations. A typical instance is known as today's Ethereum platform. To fit for more complicated cases, external resources should be equipped to the system design, such as the agent in \textit{Type7-12} or the off-chain storage in  \textit{Type2/3}. Notably, the running NFT example in Sec.\ref{sec-protocol} is a based on the \textit{Type2} design.

\section{Architecture Evaluation}
\label{sec-evaluation}
In this section, we present the evaluation criteria and evaluate each type of architecture. Our evaluation covers the properties that are summarized from classic blockchain systems and benefits to different participating parties.

\subsection{Evaluation Criteria}
\label{subsec-criteria}

In the past decades, many evaluation frameworks have been proposed. Among them, the \textit{architecture trade-off analysis method} (ATAM) \cite{kazman1998architecture} is a well-known one. We partially adopt ATAM to assess the Web3 architecture, integrating with the blockchain properties and beneficial parties. In particular, we first select a concrete scenario, refine quality attributes into this scenario, and then present potential concerns related to the quality requirement.

\smallskip
\textbf{ATAM Method.} The architecture trade-off analysis method is initially used in software development to recommend the most suitable architecture for a specific system. The method majorly discusses the trade-offs between different design types and their sensitivity points for risk mitigation. A classic ATAM process consists of three critical aspects: \textit{extract quality attributes}, \textit{identify beneficial parties,} and \textit{analyse in specific scenarios}. Quality attributes are non-functional requirements to specify how well software should be done. In the context of Web3, we adopt the properties extracted from classic blockchain systems as quality attributes. Then, we analyse the system entities regarding their potential benefits and losses. Meanwhile, we still use a similar NFT instance (compared to the running example in Sec.\ref{sec-protocol}) as our analysed scenario.

\smallskip
\textbf{Property Metrics.}\label{subsec-property}
We capture several major properties that are used to evaluate classic blockchain systems. These metrics depict the architecture from multiple dimensions, and we summarize them as follows.

\begin{itemize}
    \item[-] \textit{Performance.} Performance is used to show the maximum rate of confirmed transactions during a specified duration. In the context of blockchain, performance is measured by transaction per second (TPS), which is a widely adopted way to describe the throughput of a system.

    \item[-] \textit{Scalability.} Scalability refers to the ability to process transactions along with the increased scale of networks, which is reflected by the increase or decrease in its performance (measured in transaction per second--TPS).

    \item[-] \textit{Cost.} Each transaction in VM-engined blockchain platforms requires certain transaction fees. This is necessary because a total zero friction (free of fees) will result in a loop logic error \cite{kalra2018zeus} in smart contract operations.

    \item[-] \textit{Security.} Security is a broad term. We limit the scope of security to data-level security. The data should be protected for its integrity and prevented from unauthorized access or faking, or compromising.

    \item[-] \textit{Anonymity.} Anonymity refers to hiding the identities of acting persons. In the context of blockchain, anonymity mainly indicates utilizing cryptographic schemes to break the linkage between physical entities with virtual public addresses~\cite{Li2022SoKTC}. An adversary cannot learn useful information about any specific parties related to the on-chain assets.

    \item[-] \textit{Confidentiality.} Confidentiality refers to hiding the sensitive data that is presented on transactions, including their asset values, useful information in payloads, or contract states. Confidentiality focuses on states rather than entities. Notably, privacy covers both anonymity and confidentiality, where an adversary cannot learn any useful knowledge from public transactions.

    \item[-] \textit{Availability.} Availability is used to measure the probability of a system running abnormally with the existence of potential failure. It indicates the stability of a blockchain system.

    \item[-] \textit{Usability.} Usability in the context of Web3 follows the same connotation as the general computer system, which measures the satisfaction of a specific user in a specific context when using a specific product.

\end{itemize}

\smallskip
\textbf{Stakeholders.}
A major task in ATAM evaluation is to analyse a system's capability for satisfying the stakeholder requirements~\cite{bass2003software}. The stakeholders in the context of our Web3-based evaluation indicate the potential beneficial parties in the system, being aligned with \textit{involved entities} stated in Sec.\ref{sec-protocol}, rather than the person holding assets in proof of stake (PoS) protocols \cite{kiayias2017ouroboros}. Three main stakeholders are identified as our evaluation target.

\begin{itemize}

\item[-] \textit{Web3 user.} A Web3 user is an entity that owns the data. Also, the user is an entity to initiate transactions. The user should accordingly obtain a fair proportion of rewards in the forms such as tokens, badger, etc.

\item[-] \textit{Service provider.} An application owner uses blockchain to provide publicly accessible services for users. The service provider may obtain revenues from both sides: user payments and blockchain platform rewards.

\item[-] \textit{Blockchain maintainer.} Blockchain maintainer provides a running environment for executing the smart contract and storing the blockchain data. The main reward for maintainers comes from the cryptocurrency rewards.

\end{itemize}

\subsection{Architecture Evaluation}
\label{subsec-evaluation}
Then, we start to evaluate each architectural design. We give a specific scenario to narrow down the scope of the high-level description and analyze each architecture regarding its properties and stakeholders.

\textbf{Scenario.} Non-Fungible Token \cite{wang2021non} is a blockchain-based cryptocurrency that allows proving the ownership. In our scenario, an NFT designer, Alice, wants to sell her NFT to Bob by paying cryptocurrencies. Even though this application focuses on a specific domain, we argue that the core requirements are likely to stand across different Web3 applications. We apply different architectures to this scenario, discussing both advantages/disadvantages and trade-offs, to help interested readers consider their final decisions on Web3 architectures.

\smallskip
\textbf{\textit{A1: An Ideal Web3 Architecture.}} An ideal Web3 infrastructure should eliminate all the middle man, without centralized databases or computation devices. The blockchain provides a decentralized platform for data computation and storage while bringing a native token-based economy. Under this architecture, Alice uploads the raw NFT data, the price information, and NFT auxiliary information to a blockchain-based smart contract through a wallet. Then, the blockchain nodes reach an agreement on the data. Next, Bob sends a transaction to invoke the contract for buying NFT. Finally, the NFT ownership transfers to Bob, and Alice obtains the payments. The architecture puts all the computation and storage on the blockchain, bringing security and availability for Web3 users. The blockchain operates on a collection of decentralized nodes, which guarantees the availability of on-chain data. Meanwhile, once blockchain nodes reach an agreement for the received transactions, data becomes immutable. The related architectural design in Sec.\ref{sec-archi} is \textit{Type1}.

However, this architecture confronts some drawbacks, which mainly center around being impractical when adapting to today's Web3 infrastructure.  Firstly, uploading and replicating the data to all blockchain nodes in a peer-to-peer network is time-consuming. Website interactions are slower where the back-ended state transitions need confirmation and propagation throughout the network. Meanwhile, scalability is a long-term issue existing in blockchain systems due to intrinsic decentralization. The architecture is closely integrated with underpinned blockchain systems, which, as a result, will face a similar issue. Moreover, the computation and storage in the blockchain are expensive regarding monetary costs. Worse still, the fees increase with the growing size of payload data.

Beyond that, this architecture raises problems about data privacy. On the one hand, the code and state of smart contracts are transparent by default. Any changes in the contracts are immediately visible, not just to the blockchain nodes but also to anyone outside blockchains. The over-publicity issue hinders the development of Web3 applications, making them hard to be adopted for privacy-critical applications. On the other hand, users' identities lack anonymity. Without an explicit approach taken to protect the user's addresses, virtual addresses on blockchains and physical identities are linkable with the help of analytical tools and big data, even if users can use multiple pseudonyms.

\smallskip
\textbf{\textit{A2: Agent-login Architecture.}} The ideal Web3 solutions, singly relying on the original blockchain technology, confront the issues of poor scalability and high cost. These shortcomings force the user to adopt the alternatively centralized computation or storage outside the blockchain. We gradually proceed from layer to layer. Firstly, we address the congestion issue at the \textit{access} layer. The agent-login design provides a scalable approach to handling many transactions by merging multiple executions. A group of users can access the blockchain platform with one agent account. In particular, in our scenario, multiple NFT-selling and buying transactions are bundled into one transaction. An agent anchors this transaction to the blockchain later for the final agreement. Centralized exchanges, such as Coinbase~\cite{coinbase} or Binance~\cite{binance}, act as agents similar to this design. Many Web3 participants rely on custodial wallets for easy access and management. This architecture can concurrently process transactions without waiting for the blockchain's confirmation, which brings high performance, good scalability, and low cost. The related architectural designs include \textcolor{blue}{\textit{Type7-9}}.
The main drawback of this solution is centralization, which may cause unnecessary issues. For example, a malicious agent may hide the user's transactions without sending them to the blockchain. Worse still, such action is hard to trace due to the lack of transparent evidence.

\begin{table}[!hbt]
    \centering
\caption{Web Architecture Evaluation}
\label{tab-archievalua}
\resizebox{\linewidth}{!}{
\begin{tabular}{lccccccccc|cccc@{}}
\toprule
\multicolumn{2}{c}{} & \multicolumn{7}{c@{}}{\textbf{Property}} & \multicolumn{5}{c@{}}{\textbf{Stakeholders}}\\
\cmidrule(l){3-14}
\multicolumn{2}{c}{\textbf{Architecture}}  & \rotatebox[origin=c]{65}{Performance} & \rotatebox[origin=c]{65}{Scalability} & \rotatebox[origin=c]{65}{Gas Cost} & \rotatebox[origin=c]{65}{Security}  &
\rotatebox[origin=c]{65}{Anonymity} &
\rotatebox[origin=c]{65}{Confidentiality} &
\rotatebox[origin=c]{65}{Availability} &
\rotatebox[origin=c]{65}{Usability} &
\rotatebox[origin=c]{65}{} &
\rotatebox[origin=c]{65}{Web3 User} &
\rotatebox[origin=c]{65}{Service Provider} &
\rotatebox[origin=c]{65}{BC Maintainer} \\
\cmidrule(l){1-14}

& \multicolumn{1}{l}{ $A_1$,$B_1$,$C_1$--\textit{Type1} } &
\tikzcircle[black, fill=white]{2pt}
&
\tikzcircle[black, fill=white]{2pt}
&
\tikzcircle[black, fill=white]{2pt}  & \tikzcircle[black, fill=white]{2pt}  & \tikzcircle[black, fill=white]{2pt}  &  \tikzcircle[black, fill=white]{2pt}
& \tikzcircle[black, fill=white]{2pt}
& \tikzcircle[black, fill=white]{2pt}  & & \tikzcircle[black, fill=white]{2pt}  & \tikzcircle[black, fill=white]{2pt}   & \tikzcircle[black, fill=white]{2pt}   \\

&  \multicolumn{1}{l}{ $A_1,B_1,C_{2/3}$--\textit{Type2/3} } &
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
&
 \tikzcircle[black, fill=white]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
& & + & - & - \\

\cmidrule{2-2}
& \multicolumn{1}{l}{$A_1$,$B_2$,$C_1$--\textit{Type4}} &
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}

&
 \tikzcircle[black, fill=white]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
& & + & -& - \\

& \multicolumn{1}{l}{$A_1$,$B_2$,$C_{2/3}$--\textit{Type5/6}} &
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}

&
 \tikzcircle[black, fill=white]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
& & ++ & -\,- &  -\,-  \\

\cmidrule{2-2}
&\multicolumn{1}{l}{ $A_2$,$B_1$,$C_1$--\textit{Type7}} &

\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
&
 \tikzcircle[black, fill=white]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
 \tikzcircle[black, fill=white]{2pt}
&
 \tikzcircle[black, fill=white]{2pt}
 &
\tikzcircle[green, fill=green]{2pt}
 &

& + & - & - \\

& \multicolumn{1}{l}{$A_2$,$B_1$,$C_{2/3}$--\textit{Type8/9}} &

\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}

&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
& ++ & -\,- &  -\,-  \\

\cmidrule{2-2}
& \multicolumn{1}{l}{$A_2$,$B_2$,$C_1$--\textit{Type10}} &

\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}

&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
& ++ & -\,- &  -\,-  \\

& \multicolumn{1}{l}{$A_2$,$B_2$,$C_{2/3}$--\textit{Type11/12}} &

\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&
\tikzcircle[red, fill=red]{2pt}
\tikzcircle[red, fill=red]{2pt}
&
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
\tikzcircle[green, fill=green]{2pt}
&

& +++ & -\,-\,- &  -\,-\,- \\
\bottomrule

\end{tabular}
}
\begin{tablenotes}
 \item \quad \tikzcircle[black, fill=white]{2pt} Baseline, \tikzcircle[green, fill=green]{2pt} Property enhance, \tikzcircle[red, fill=red]{2pt} Property decrease; (Compared to \textit{Type1})

\end{tablenotes}
\end{table}

\smallskip
\textbf{\textit{A3: Hybrid Computation Architecture.}} This architecture shares the same workflow with $A1$ and $A2$. As discussed, on-chain computations are both time-consuming and money-consuming. Hybrid computation architecture solves this issue by bringing TTP with high computation capabilities. These TTPs process the data off-chain, and merely put a few computation tasks on the blockchain. In our example, the on-chain computation tasks may cover the token payment and NFT  the ownership transfer. This design improves user usability because off-chain computations have better performance and scalability.  The related architectural designs include \textcolor{brown}{{\textit{Type4-6}}}. However, it still assumes that the TTP who provides computation power is honest. A TTP in the real world may act maliciously or fail to provide computations due to hidden interests or being compromised. Again, such malicious computations are hard to be detected.

\smallskip
\textbf{\textit{A4: Hybrid Storage Architecture.}} This architecture stores the raw data off-chain while the data pointer is stored on the blockchain system. In our example, only NFT identifiers and payment information are stored on-chain, while the raw NFT data is stored off-chain. Correspondingly, in the real world, most NFT artists rely on centralized platforms like OpenSea \cite{opensea}, or Solanart \cite{solanaart} to store the raw NFT data. In this architecture, the choice of how to store off-chain data and how to reveal the contents of their off-chain data are left to users, which brings certain privacy and over-publicity issues. Meanwhile, the architecture improves the performance and saves the cost. Due to these benefits, the design has been widely adopted by some storage-intensive applications, such as blockchain-based streaming media, such as Theta \cite{theta}, Audius \cite{audius} and Livepeer \cite{livepeer}, which depends on the combination of on-chain storage and off-chain storage. The related architectural designs include \textcolor{teal}{\textit{Type10-12}}.

However, the solution is partially centralized with the risk of single point failures. In particular, the off-chain storage is controlled by a TTP. Any services built on top of this type can only be processed when a TTP is available, making the data access to relevant information becomes a privilege. Fortunately, some storage systems rely on replication to back up files for data integrity. For example, Storj \cite{wilkinson2014storj} utilizes the proof-of-redundancy mechanism, where every file is stored in at least three locations to avoid files being destroyed. The system operates on the Ethereum platform and stores the metadata in Satoshi format. Similarly, Sia~\cite{vorick2014sia} is a distributed storage system that relies on storage proofs. These proofs consist of a list of publicly verifiable root hashes from the submitted file and a fraction of the original file, and users can verify them easily from on-chain data. InterPlanetary File System (IPFS) \cite{filecoin}, with more complicated proof mechanisms, establishes a fully distributed peer-to-peer file system. Leveraging proof of time/space, IPFS ensures data integrity from both time and space.

\smallskip
{\textbf{Statistical Results.}} The investigation tries to answer the question \textit{which architectural design is the most prevailing?} Existing Web3 projects are designed based on different scenarios. Accordingly, their solutions target different components. We expand our research from mature systems (ranked in the market) as well as newly released whitepapers that claim to launch the projects. Based on our investigation (inevitably select examples in a small corpus from the entire project pool),  we find that most of the teams adopt the \textit{Type1} ($A_1,B_1,C_1$) design with a straightforward blockchain-based architecture. These projects either put focuses on merely one functionality, such as setting connections from Web2 to Web3 \cite{web3auth}, building decentralized identities \cite{idx,ceramic}, or implement the very basic infrastructure \cite{truffle,alchemy,ankr} that can better serve existing blockchain ecosystems. Above reasons made us to select \textit{Type1} as the baseline. For other types, we can observe that the options of external techniques are insufficient. For instance, if a project aims to move the storage off-chain, the options are limited to IPFS \cite{ipfs}, which has been implemented for years with comprehensive instructions and user guides. Affected by little attention to external technologies, other design types (even the sum of the rest ones) only occupy a small share of the entire picture.

\smallskip
\textbf{A Concise Summary.} As shown in Tab.\ref{tab-archievalua}, we provide detailed evaluations of each architectural design. Adding auxiliary techniques (agent, off-chain computation, off-chain storage) will impact the properties from different sides. Positively, performance, scalability, gas cost, and usability can get improved at different levels depending on how many layers have been modified. This is because external techniques can support much more volume of data and participating parties. From the view of single users, they can obtain better services due to faster transaction processing time and cheaper gas costs. In contrast, negatively, security, anonymity, and availability have decreased, compared to the baseline (\textit{Type1}), due to the in-transparency of off-chain processing procedures. Here, the singly applied agent at the client component will not affect the anonymity because either personal address or custodian addresses are equivalent towards adversaries. Similarly, confidentiality, security, and availability are majorly vulnerable at the computation and storage components, with little relation to the access component. Finally, for stakeholders, we can observe that Web3 users can obtain benefits that are consistent with previous reasons (better service). In opposite, both service providers and blockchain maintainers are disadvantageous since the managing costs accordingly increase.

\section{Extending to the Web3 Space}
\label{sec-discussion}
In this section, we extend our scope from architectures to the entire Web3 space. We present the Web3 impacts to current markets. Then, we point out the promising research directions as well as potential barriers on the road.

\subsection{Web3 Impacts}
\label{subsec-impact}

We first discuss the impacts of current Web3 projects. We approach it from two sides. The one is to estimate their influenced market value, while the other one is to see the scale of Web3 applications or services. We give details as follows.

\smallskip
\textbf{Value Estimation.} Supported by mainstream blockchain platforms, Web3 has gained an unexpected breakout. Measuring the quantitative impact is impractical due to its generality and vague bounder. No statistical data can be directly used by different institutions. But we still find indirect ways to reflect its influence. The first way is to investigate the usage of smart contract languages. This is because building a Web3 DApp requires defining logic and functions (e.g., ownership/transfer/connect) through these languages due to its close relation with user interfaces. The total value locked (TLV) by smart contract languages reaches up to maximally $193.14$ billion USD (as of Dec, 2021)\footnote{The TLV of $\$251.877$b is made up by $\$193.14$b from Solidy ($76.68\%$), $\$28.19$b from Rust ($11.19\%$), $\$27.56$b from Vyper $10.94\%$, $\$1.57$b from Ride ($0.62\%$), $\$1.07$b from Cairo ($0.42\%$), $\$193.47$m Bitcoin Script, $\$152.45$m from C\#, $\$3.69$m from Python. Among them, Solidity still occupies the largest proportion, indicating that Ethereum and EVM-compatible platforms play the most important role in the Web3 area. [Data source: \url{https://defillama.com/languages}].}. However, these languages only show a partial picture of the entire Web3 ecosystem, while many competitive programming languages are proposed following the same targets (cf. Appendix C). The real impact of Web3 will greatly outpace the stated data singly observed from languages. Another way to reflect the popularity of Web3 applications is based on fundamental index methodology \cite{web3index} that covers different types of underlying valuation figures such as users' paid fees on applications and individual votes for proposals. Fees, in this track, are different from transaction fees paid to miners in Ethereum. Instead, they are used to represent the cost that people are willing to spend on related decentralized services. For instance, users have spent $253,015$ USD (per $30$ days) on Arweave \cite{arweave} which is used to query or store data on the network. It provides an estimator of a network's value and activities by an in-time track from the view of the demand-side, which provides a distinguished way of investigating the status of the Web3 market.

\smallskip
\textbf{Practical Development.} Besides its high values, Web3 DApps have promoted a rapid evolution towards a wide variety of scenarios. A promising paradigm shift is to move the centralized authority from trusted third parties (TTP) to distributed participants, which is also known as the Decentralized Autonomous Organization (DAO). DAO removes the formal management roles (e.g., delegated authorities) and physical entities (company/office)  \cite{fritsch2022analyzing}, by instead a suite of contracts residing on the Ethereum blockchain. DAOs have been adopted with many instances like Aragon \cite{aragon} and MetaCartel \cite{metacartel}. Another significant shift lies in their way of authenticating identities. Unlike asking for sensitive information through methods of \textit{email$+$password} or \textit{OAuth} in traditional networks, identities in Web3 applications are replaced by anonymous addresses, where the web establisher cannot obtain any useful knowledge of their users. The design further stimulates the widespread of decentralized identifiers (DIDs) \cite{w3cdid}. Users can fully control assets and metadata under their DIDs, and optionally release them to service providers by personal preferences. Moreover, Web3 also instimulates the prosperity of development tools and supplementary suites surrounding blockchain technologies. These tools cover APIs, statistic indicators (The Graph \cite{thegraph}), distributed storage (Sia \cite{sia}, Arweave \cite{arweave}), edge computing (Helium \cite{helium}), etc. They fulfill the blank left from previously isolated components, enabling them to seamlessly integrate together and well support each other. We further provide a look into Web3 applications that are stated in Tab.\ref{tab-projects} in Appendix D. Unfortunately, constrained by our bandwidth, we only select a small group of Web3 projects to demonstrate its wide adoption in this report.

\subsection{New Paradigm}
\label{subsec-oppo}
We then discuss the forthcoming wave of Web3 that goes beyond the initial use case like cryptocurrencies. Web3 can promote technical integration across different domains, ranging from establishing decentralized self-governance organizations to facilitating the progress of DeFi and Metaverse.

\textbf{Technical Integration.} Web3 is a novel approach to delivering internet architecture in a decentralized way. As discussed, Web3 covers every layer of the web architecture, from the front-end to the back-end. It indicates that technical integration may occur in multiple areas. For instance, Theta Labs' \cite{theta} decentralized video solution aims to stream video on Web3 via customized APIs. Audius \cite{audius} is a music sharing platform with the target to decrease the dependency on a record label. Radicle \cite{radicle} is an open-source and distributed platform for code collaboration. Arweave \cite{arweave} and Sia \cite{sia}, similar to IPFS \cite{ipfs}, are to establish a decentralized storage network that allows users to store data. Deeper Network \cite{deeper} intends to build a hardware-powered VPN ecosystem. All these attempts to modify, integrate and improve the existing infrastructure from centralized networks are promising, providing educational experiences on both success path and failure cases for the following developers.

\textbf{Distributed Autonomous Organization (DAO).} Web3 will significantly promote the development of current distributed autonomous organizations. Utilizing a suite of smart contracts improves reliability, as no powerful authorities can break the rules. DAOs run on a flattened hierarchy where each participant has the right to vote on specific issues, similar to the way in a conventional executive board. All the processes, including decision-making, token issuing, option selecting and voting, are transparent due to the on-chain settings. This means anyone, either internally or externally, could audit the code, which greatly improves accountability and reliability and avoids misdirecting usage of funds collected from investors and users. To achieve decentralized governance, every project can issue its specified votes (or tokens) that stakeholders can put their preferences on. For instance, Yearn \cite{yearn} allows users to participate in decision-making and voting on proposals. Radicle \cite{radicle}, as a decentralized GitHub alternative, grants stakeholders the right to manage the project. Similarly, many DeFi protocols, including Uniswap \cite{uniswap}, The Graph \cite{thegraph}, SuperRare \cite{superrare}, and Audius \cite{audius}, enable ownership, participation, and governance via their issued tokens. All these votes and tokens require a Web3 DApp to get interacted with different DAO participants. Also, long-existing DAOs, such as MakerDAO \cite{makerdao}, have attracted many developers contributing to crypto-space and Web3 ecosystems. In this sense, DAO has extended the scope of decentralization, which was previously bound to machines, to a broader area that involves human beings. The shift of \textit{how to operate a digital organization} would pose a great impact on the future world, more than they are presented today.

\textbf{Self Governance.} Initially, software companies in Web1/Web2 obey the rule of protecting data, with a simple aim to involve more users for growth. But eventually, they have to start turning profits by selling or manipulating users' data, such as training AI models to make better recommendations. Users have no choice, facing the dilemma between privacy and convenience. In contrast, individuals in the Web3 space can hold as much personal data, which is more than ever before. Together with DiDs, users can freely browse the internet as well as perceive their data without compromising its privacy. Many solutions, like Ceramic \cite{ceramic} and IDX \cite{idx}, replace traditional authentication by allowing users to build self-sovereign identities. The Ethereum foundation makes much more progress by drafting an RFP \cite{rfpeth} for defining a formal specification. By controlling data and assets, an individual can even earn profits through incentive mechanisms. This is practically important for building a sustainable ecosystem that encourages users to continuously contribute to the required infrastructure.

\textbf{DeFi.} This is an intuitive application of Web3 as all the assets held by users are stored in their wallets. Performing financial-related activities, such as swapping different tokens at DEXes, loaning coins from exchanges, buying/selling crypto-assets from fiat to stablecoins, and designing derivatives (e.g., NFT \cite{wang2021non}, contracts, securities \cite{chen2022absnft}, share, etc.), becomes common and easier for single users since they do not need to register to any financial intermediaries. These activities make up the core of today's DeFi market \cite{werner2021sok}, which also attracts tremendous monetary investments involved in this field. Blockchain systems lay the foundation of DeFi protocols, guaranteeing the normal operations of every piece of logic, while Web3 paves the path to practical usage of these protocols, guiding users to participate in the games. Users only need to act as they behave in centralized markets, rather than having hard research to understand the differences between token standards or blockchain platforms.

\textbf{Metaverse.} Unlike DeFi or NFT specifying one specific direction, Metaverse is a general term that involves numerous technologies, with ambiguous targets to describe a virtual digital world for the incoming future. Intuitively, users in Metaverse will first interact with its front-end and then connect with the decentralized network supported by interoperable blockchain platforms. Web3 can cover all touchable applications that a user can reach, such as social networks, search engines (Brave \cite{brave}), galleries (Opensea \cite{opensea}), and marketplaces. A user can fully control their digital assets, identities, and data, browsing any sector of the Metaverse just like shopping at the store. Web3 can help to establish such a front-end environment with a pretty easy one-step connection for the participating users. In practice, many projects start to establish Metaverse from different aspects like IoT \cite{helium}, Games \cite{axieinfinity}, Markets \cite{superrare}\cite{opensea}, etc.

\subsection{Open Challenges}
\label{subsec-chall}

In this subsection, we point out the potential challenges from four folds, separately from the views of user-level (\textit{application}), system-level (\textit{blockchain}), markets (\textit{economy}), and social organizations (\textit{legality}).

\noindent\textbf{Application.} Decentralized applications built on blockchain-empowered systems are the first gate to individuals. Users have intuitive feelings towards these applications. We abstract three aspects that may affect the user experience.

\begin{itemize}
    \item[-] \textbf{Composability.} Web3-based solutions cover a wide range, either from the type of components, or the products for each component. Data transmitting in different products are inevitably isolated. The way to make data reused by different products at the same layer is urgently important. Standardized APIs may address the problem to some extent, where at least many DApps with similar designs can invoke the same APIs. Ceramic \cite{ceramic} tries to build applications with composable Web3 data and enable reusable data for multiple scenarios. However, making most back-end components composable is still a challenge. The barriers are whether composable components are compatible with each other and whether data can flow seamlessly across different components. For such reasons, the data need to be designed in the same structure for the re-usage by these components.

    \item[-] \textbf{Accessibility.} Web2 networks still cover most Internet users' activities, including social media, shopping, meeting, education, and payments. Users are accustomed to and enjoy their services due to their super convenience and easy accessibility. The lack of integration with modern web browsers and mobile applications limits the wide adoption of Web3 to end-users. An individual user will not change from the product that he used for a long to a new one. How to decrease the migration cost is a challenge. Moreover, interacting with Web3 applications also requires additional development, education, and software/hardware. This becomes a huge recognition difficulty for users and thus impedes its wide adoption.

    \item[-] \textbf{Data Recovery.} The private key is the most important secret of users when using blockchain platforms. The entire account of users relies on a credential that is represented in the form of a complex string or a series of secret recovery phrases. If a user loses his private key, he will never enter his account. The account becomes a dead account with all data, including assets, being locked. Methods to recover accounts, or at least the internal data, are an urgent requirement for applications in the Web3 space. Moreover, applications that adopt off-chain storage require more strict verification for data integrity because additional checks on whether the data in external storage matches on-chain hash values are needed. The data recovery in external pages is difficult due to the absence of traceability and accountability.
\end{itemize}

\smallskip
\noindent\textbf{Blockchain.} Blockchain systems are the most fundamental layer in each architectural design type, supporting upper-layer applications as well as connecting underlying storage. Limitations in blockchain systems will significantly constrain the development of the entire Web3 ecosystem.

\begin{itemize}
    \item[-] \textbf{Scalability.} Scalability represents the ability to process transactions along with the increased scale of networks, which is reflected by the increase or decrease in its performance. This is a long-term issue existing in blockchain systems due to intrinsic decentralization. Every major step needs time, such as data update, signature verification, etc. Among them, the consensus process has the most impacts since the more mining nodes joined the network, the more computational tasks were added. Web3 is closely integrated with underpinned blockchain systems, which, as a result, will face the similar issue as well. In most cases, transactions are slow on website interactions as state transitions need confirmation and propagation throughout the network. Underlying blockchain platforms, together with atop Web3 applications, require conquering the challenges of accommodating rapid growth and the demands of not compromising performance. Otherwise, users, with a high probability, may have a poor experience such as extremely slow loading speed of websites.

    \item[-] \textbf{Interoperability.} Web3 applications, in the foreseen future, will be deployed on many blockchain platforms. This requires interoperable blockchain technologies to facilitate smooth state transitions, either homogeneously or heterogeneously. Creating interchangeable communication channels to connect isolated decentralized ledgers is still a challenge for the development. Current interoperability solutions, such as pegged sidechains \cite{deng2018research}, hash-locks \cite{herlihy2018atomic}, and trusted relays \cite{frauenthaler2020testimonium}, partially mitigate the problem: they enable transactions to cross over chains within their specified ecosystems (e.g., Polkadot and their para-chain slots \cite{wood2016polkadot}), but cannot make nature transactions operated across different ecosystems (Polkadot token on Ethereum). A prevailing method is to create the wrapped token that anchors the origin token with equal supplies as an alternative representation, such as the BTC coin existing in Ethereum with the representation of WBTC (an ERC20 format \cite{wbtc}). However, this makes more and more \textit{representative} tokens produced with no actual usage, increasing the waste and complexity.

    \item[-] \textbf{Contract Vulnerability.} The security of smart contracts \cite{atzei2017survey} will directly affect its connected Web3 applications. Smart contracts contain the business logic and operation specifications, which are key to the upper layer applications. Meanwhile, smart contracts can act as autonomous agents \cite{li2022smart}, decreasing the power of centralized service providers in combined protocols and securing on-chain data from users. Vulnerabilities existing in smart contracts, caused by design flaws or implementation errors, may result in thousands of monetary loss. Examples include the integer underflow/overflow attacks \cite{atzei2017survey}, DAO attacks \cite{daoattack}\cite{thedao} and Parity Multi-Sig Wallet attack \cite{parityattack}. Even worse, the scripting nature of contract programming languages (cf. Appendix C) and the non-updateable feature of smart contracts will significantly limit the growth of Web3 applications.
\end{itemize}

\smallskip
\noindent\textbf{Economy.} As one of the major differences compared to Web1/Web2, users in the Web3 space can automatically obtain rewards according to their contributions. Users holding both digital assets and metadata in their wallets can freely trade them to earn profits. But there are still many concerns about disparate incentive mechanisms, operating costs, and technical debts.

\begin{itemize}
    \item[-] \textbf{Incentive.} Users adopt Web3 applications largely due to their considerable potential revenues. They can earn extra profits by conducting activities in Web3 networks: browsing websites (Basic Attention Token \cite{brave}), providing online storage (Arweave \cite{arweave}), playing games (Axie Infinity \cite{axieinfinity}), or selling self-created products (Opensea~\cite{opensea}). Even for the current stage, developers can obtain airdropped tokens from the project teams by testing their demos on the testnet. However, as more and more users participate in the game, the threshold of obtaining rewards becomes extremely high. Thus, designing a positive incentive mechanism that can cover as many users is crucial to attract new players joining the network.

    \item[-] \textbf{Cost.} The high gas fee has already become a major hurdle in using Ethereum. Sending an transaction will cost more than hundreds of dollars (executions on smart contracts cost more). As a result, applications with complicated computations cannot be deployed on-chain. This is the reason why many competitive public blockchains can co-exist in the market. Moreover, blockchain provides very constrained capabilities of storage, where many DApps can only put a small portion of code on-chain. A potential solution is to adopt more off-chain solutions \cite{gudgeon2020sok} that can take over the workload from on-chain to local servers without significantly breaking decentralization.

     \item[-] \textbf{Technical Debt.} Many Web3 applications are designed in a limited way to facilitate the entire software development cycle. This would cause many costs of additional rework in the latter processes, which is denoted as the \textit{technical debt} \cite{techdebt}. A suitable approach that aims for a long-term proposal can save many more costs because a bad design will accumulate \textit{interest} just as it is in monetary debt. Developing more in an inappropriate route can improve the difficulty of making updates. The development of a project falling into technical debt will reach a point where it is no longer possible to implement the protocol improvements that align with its initial vision. Developers should be sufficiently prudent when designing their products, even for the initial proof-of-concept implementations.
\end{itemize}

\smallskip
\noindent\textbf{Legality.} Governments and official organizations have a lot of concerns due to the rapid shift and huge change in the cryptocurrency world. Individual users are eager to have their non-infringeable rights and are afraid of an anarchy state. It is pretty difficult to reach the balance. Here, we stress the two discussed challenges in the view of the social side.

\begin{itemize}
    \item[-] \textbf{Governance.} Since anyone can launch Web3 projects, an increased number of applications will inevitably make the market segmented and unsupervised. Traditional authorities such as official organizations and governments become less influential than it is today. A large proportion of power is distributed to DAOs, which are made up of individuals. However, anyone who uses Web3 can arbitrarily establish DAOs without strict authentication or KYC (know your customer) steps. This causes instability in society \cite{kiayias2022sok}. For instance, (web3) tweets on decentralized social media platforms would be uncensorable without facing the risk of being punished for spreading rumors. Moreover, some illegal trades, such as porn or drugs, might be abused in unsupervised networks as no explicitly compulsive laws can forbid them.

    \item[-] \textbf{Taxable Difficulty.} The intrinsic property of Web3 is to give the incentive back to users. Individuals who contribute more will obtain higher rewards. Their contributions can be in any form, such as deposited stakes (PoS-based chains \cite{kiayias2017ouroboros}), activities (many projects airdrop tokens based on this), attentions (e.g., BAT \cite{brave}, Cirus \cite{cirus}), or followers in traditional social media (Twitter, Discord, Facebook). If most of the current network users move to the Web3 world, collecting taxes from, at least, technology companies and Internet practitioners becomes extremely difficult. Even worse, hiding assets in accounts can help users directly make investments in financial markets and earn profits. The governments can never know what has happened and when this has occurred, nor for associated evidence used for taxes.

\end{itemize}

\section{Closing Results}
\label{sec-closing}

This section collects several popular questions that are frequently mentioned in communities. We accordingly answer them with our investigated results.

\noindent\hangindent 1em \textit{\textbf{What is Web3?}} Web3 is an umbrella term used to describe the next generation of internet services. It incorporates a wide range of components in the computer infrastructure. We have, in this work, investigated \textit{in the wild} solutions and found several common design patterns. We decouple Web3 services into three major components as in Sec.\ref{sec-archi}. With this, an application/service, in the context of our methodology, can be categorized into a Web3 space if \textit{at least one component is decentralized}. Based on the current view, an ideal Web3 application, operates all the services on-chain. However, this design can only support services with lightweight computations and storage. Supplementary services require external techniques.

\noindent\hangindent 1em \textit{\textbf{What is the cornerstone of Web3?}} Following the previous discussion,
a natural question is that: how to implement the decentralization of each component for building Web3. We review the identified twelve architectural designs and find an interesting result: every component centres around continuously operating blockchain platforms. The front-end wallet needs to connect with the on-chain operation, while the external storage also requires on-chain information for item searching and valid proofs. Therefore, the characterization through \textit{access}, \textit{computation} and \textit{storage} highly rely on the service of blockchain: \textit{access} to the blockchain, \textit{computation} in the blockchain, and \textit{storage} surrounding blockchain. These integrated components can establish a Web3 service thanks to the support from the blockchain. In this way, Web3 holds the property of decentralization, obtaining benefits from the blockchain.

\noindent\hangindent 1em \textit{\textbf{Is Web3 sufficiently decentralized?}} Web3 is not as decentralized as it appears to be \cite{werbach2018blockchain}, in which building a Web3 application still highly relies on a small corpus of companies. For instance,  centralized exchanges that can trade cryptocurrencies are majorly controlled by Binance \cite{binance} and Coinbase \cite{coinbase}, while wallets are affected by MetaMask \cite{metamask}, NFT products  \cite{wang2021non} by OpenSea \cite{opensea}, and stablecoins by Tether \cite{tether}. Meanwhile, a similar phenomenon also occurs in DeFi markets: Uniswap \cite{uniswap} has the most Total Value Locked (TVL); Dai \cite{dai} has dominated the decentralized stablecoins; Chainlink \cite{chainlink} has greatly outcompeted others in the price oracle. Moreover, many infrastructure-related blockchain companies that provide programming interfaces and development tools are concentred on a few companies like Alchemy \cite{alchemy}, Infura \cite{infura}, and Ankr \cite{ankr}. The high density of consolidation in the cryptocurrency field will inevitably result in a partial monopoly, where only a small group of oligarchs takes most of the resources.

\noindent\hangindent 1em \textit{\textbf{Is Web3 secure?}}
The answer would be ``No". Web3 services rely on a suite of composable components to seamlessly work together. Problems in any single component may lead to fail. Come back to our NFT example, the raw data of the NFT may be erased due to the offline insecure storage by adversarial attacks or compromised managers. This is merely an example from the storage layer. In the real world, issues happening in other blockchain components will as well result in severe problems, such as transaction congestion due to poor scalability, slow confirmation caused by probabilistic consensus, or logical loopholes in smart contracts. The security of Web3 is closely related to correct operations of the entire system, which should be an all-level stack evaluation.

\noindent\hangindent 1em \textit{\textbf{Has Web3 addressed privacy worries?}} Web3 services cannot protect user privacy as it claimed. We give discussions from the website, which is the entry of a user to Web3 applications and services. Web-side privacy issues cover a set of design pitfalls and malicious attacks launched from the front-end, such as browsers or mobile applications. In many cases, an adversary may act like a normal operator in the system. For instance, the centralized authority can play the role of a tracker with abilities to record Ethereum addresses over a wide range of users, resulting in privacy violations with the help of its script embedding techniques \cite{winter2021s}. Once a user leaves evidence of using an address at a DeFi site, the malicious browser, which also holds your identities, can map to your physical entity. Besides, other traditional web attacks may also threaten the Web3 sites due to the shared engine.

\begin{center}
\tcbset{
        enhanced,
        colback=red!5!white,
        boxrule=0.1pt,
        colframe=red!75!black,
        fonttitle=\bfseries
       }
       \begin{tcolorbox}[
       title=Fact and Fiction - Truth to be Told of Web3,
        arc=5pt,outer arc=5pt,drop large lifted shadow]
       Based on our investigations from both technical and economic perspectives, Web3 cannot fully replace current web services. Instead, Web3 will still highly rely on the existing Internet infrastructure, including programming languages, communication protocols, agents, and storage. Fortunately, Web3 has reshaped conventional finance markets and facilitated individual self-governance. Users at least begin to pay much more attention to their digital assets covering both virtual data and cryptocurrencies.
       \end{tcolorbox}
\end{center}

\section{Conclusion}
\label{sec-conclu}

Web3 is an emerging concept prevailing in the entire crypto-world. Applications and services in the Web3 space, with non-custodial nature, allow users to control their data and obtain rewards. However, no clear definitions of such a \textit{buzzword} have formed. In this tech report, we fill the gap by investigating a large corpus of \textit{in the wild} projects titled with Web3. We dig into this topic by decoupling existing systems supporting blockchain-based Web3 services into separate core components, and accordingly discussing related features and properties for each potential combination. In total, we have identified twelve architectural design types and evaluated them with profound discussions. Based on our study, we present the new paradigms gained by Web3 and point out the design pitfalls. We further provide our answers to several questions from communities. To the best of our knowledge, this is the first research on Web3 from the view of blockchain.
\bibliographystyle{unsrt}

redpajama_set_name: RedPajamaArXiv