A Fully Decentralized Web Application Framework with Dynamic Multi-Point Publishing and Shortest Access Path

Abstract

Decentralized applications (DApps) have found extensive use across various industries. However, they still face several issues that need to be resolved. Currently, DApps are in a semi-decentralized stage, as only partial decentralization has been achieved. This paper presents FDW, a fully decentralized web application framework, which mainly includes the DWeb market, developer client, publisher client, and visitor client. The DWeb (Decentralized Web) market is established to manage all DWebs. In the DWeb market, developers can register, upload, and maintain DWebs; publishers can download, validate, and deploy DWebs; and visitors can browse DWebs and provide content. To guarantee the reliable operation of DWebs, multiple publisher nodes deploy a DWeb through dynamic multi-point publishing. By adopting the shortest access path, client nodes can efficiently access any DWeb from the closest publishing node. Additionally, the incentive and governance mechanisms encourage collaboration among all participants, ensuring the security of FDW. A prototype system of FDW has been developed, which consists of a DWeb container and an example DWeb. An analysis and evaluation of the decentralization, scalability, and security of FDW are provided. Compared with other related schemes, FDW shows certain advantages in these aspects.

1. Introduction

With the continuous popularization and maturity of blockchain [1,2] and smart contract [3,4] technology, the use of decentralized applications (DApps) is becoming more and more widespread. It has penetrated all walks of life, including finance [5], government affairs [6], the supply chain [7], medical care and health [8], and other fields [9,10]. DApps have the characteristics of openness and transparency, user control, and high security [11]. They solve some of the major problems commonly encountered in traditional centralized applications: applications and content are controlled by large technology companies; Internet entrances can block specific websites or content; and there are security risks, such as physical attacks, infrastructure shutdowns, and single points of failure.

Although DApp is widely used, there are still problems, such as concurrent access performance, oracle security, and scalability. Decentralized web applications (DWebs) [12], as an implementation method of DApps, have some key issues in the implementation and application process: (1) Partial decentralization. Most of the existing DWebs achieve the decentralization of data storage and main business logic through smart contracts. The front-end pages of DWebs still use traditional centralized deployment, which reduces the concurrent access performance of DWebs. In addition, some non-subject business logic, such as registration, login, and permission control, have not undergone a decentralized transformation, which will also become a bottleneck in the performance of DWebs. (2) The centralization problem of access entrance. Most of the existing DWebs access portals are still through domain names, which are subject to some limitations of DNS (domain name system) resolution.

Combining the above issues, this paper aims to design and implement a fully decentralized web application framework. There are the following challenges: (1) DWebs should permanently exist in the network, including front-end pages, business logic, content data, etc., and the centralization of any one of them may become performance bottlenecks and security weaknesses. (2) Compliance with the principle of “net neutrality” [13], providing a DWeb visiting method with user-centered search, access, and other functions to improve the convenience of users visiting DWebs. (3) Implementation and verification of a DWeb prototype system that is fully decentralized.

In order to solve the above challenges, we propose a fully decentralized web application framework, FDW, which employs the DWeb market to contain all DWebs. The DWebs are published to multiple blockchain web publisher nodes by dynamic multi-point publishing, and their metadata are stored and displayed on the DWeb market. A special DWeb can be searched and visited by the shortest access path from the DWeb market. The prototype system of FDW is further implemented and its core processes are described in detail. The decentralization, scalability, and security of FDW are analyzed and evaluated. Compared with other related decentralized schemes, it has certain advantages in the above aspects.

The main contributions of this paper are summarized as follows: (1) Fully decentralized web application framework: a fully decentralized web application framework named FDW is proposed, which provides a DWeb ecosystem for users with different roles, such as developers, publishers, and visitors, through the DWeb market. (2) Dynamic multi-point publishing: The developer submits the DWeb metadata to the blockchain, and the DWeb is dynamically published by multiple web publisher nodes. (3) Shortest access path: A DWeb hash table is designed to allow visitors to quickly connect to the closest web publisher. It enhances the user experience for visitors and loads balances for web access. This paper’s novelty lies in its creation of a fully decentralized web application framework. It employs dynamic multi-point publishing and the shortest access path, ensuring reliable DWeb operation and efficient access. The incentive and governance mechanisms also foster collaboration among different roles, enhancing the system’s security.

The rest of this paper is organized as follows: Section 2 describes the rationale, key technologies, and work related to DWeb. Section 3 proposes the system architecture of FDW with dynamic multi-point publishing and the shortest access path. Section 4 and Section 5 respectively explore the FDW workflow and prototype system design. Section 6 analyses and evaluates the results of FDW through experiments. The supervision, access by domain name, and content search are discussed in Section 7 after comparing with other related schemes. Finally, Section 8 concludes this study.

2. Background

2.1. Decentralized Web Application

DWeb is a web application built based on decentralized technology, aiming to improve transparency, security, and user control, and reduce dependence on centralized service providers. DWeb applications are fundamentally different from traditional centralized applications in terms of deployment methods, data storage, operation logic, user control rights, and governance methods. A detailed comparison is shown in Figure 1.

The development of DApps has experienced three main stages: (1) In-chain decentralization stage. That is, peer-to-peer interactive operations are realized within the blockchain, including token transactions, data transmission, block requests, and so on. It mainly achieves some functions of the infrastructure layer, data storage layer, and business service layer in Figure 1. (2) Semi-decentralized stage. The emergence and large-scale use of smart contracts applies decentralization to a wider field and achieves a limited, pseudo-decentralized ability to interact with the off-chain real world through blockchain oracle [14], which is also the stage we are currently in. (3) Fully decentralized stage. Real decentralization and trust minimization are achieving adopting DWeb-related technologies. That is, the integration and implementation of all functions in the four-layer structure, as in Figure 1.

2.2. Key Technologies

The key technologies related to DWeb mainly include blockchain, Web3 [15], API3 (Application Programming Interface 3), DAPI (decentralized application programming interface) [16], DApp (decentralized application), DID (decentralized identity) [17], DAO (decentralized autonomous organization) [18], DeFi (decentralized finance) [19], etc., and their interrelationships are shown in Figure 2.

Blockchain is the infrastructure for DWeb publishing and operation, and its architecture contains a storage layer, network layer, consensus layer, incentive layer, contract layer, and application layer [20]. The storage layer uses distributed ledger technology to store all blockchain data in each full node. The network layer generally builds a P2P network to realize the transmission of data. The block data are agreed upon in the consensus layer by using different consensus algorithms. The contract layer distributes the business logic in the form of code to be executed in the blockchain. The incentive layer introduces economic incentives to promote the stable operation of the blockchain. The application layer introduces and uses blockchain technology to empower traditional industries in various fields. Blockchain technology empowers traditional industries. DID, DAO, DeFi, etc. are the basic decentralized applications, and are also the standardized components that decentralized applications in other industries generally have to integrate.

API (application programming interface) is a set of rules and protocols that allows different software applications to communicate and interact with each other. DAPI refers to the API service for interaction with decentralized applications. On the one hand, it provides an access interface service to data and functions in blockchain or decentralized applications, which is convenient for other applications to call functions and services in a decentralized network. On the other hand, it provides access service to data and functions in the off-chain real world in a distributed way, which is convenient for decentralized applications, such as smart contracts, to interact with the off-chain real world. API3 directly connects data providers and data consumers to improve the credibility and transparency of data, and at the same time, ensures decentralization and security in the process of data interaction. API3 contains blockchain, basic DApps, DAPIs, etc. It provides technical frameworks, governance structures, and economic incentives to facilitate the development and maintenance of DAPIs.

DApp is a collective term for all decentralized applications, including basic DApps, DAPIs, DWebs, mobile decentralized apps, PC decentralized C/S applications, and so on.

Web3 generally refers to the decentralized internet, which contains blockchain-related infrastructure and technical framework, basic DApps, and various DApp industry applications created based on decentralized infrastructure and basic DApps. Web3 builds a decentralized, fair, and secure digital world and ecosystem, where all services and applications are decentralized and run on a decentralized network, and users have full control over the data.

2.3. Related Work

With the release of Ethereum, there is a large number of DApps based on smart contracts, e.g., CryptoKitties [21], Decentraland [22], etc. However, some of the DApps are still partially implemented in a centralized mode [14,15]: centralized management of part of the data (statistical data, cached data, etc.); centralized deployment of the presentation layer; centralized domain name access method, etc. Currently, there are relatively few actual projects and studies that are fully decentralized.

Different from the HTTP protocol used by traditional centralized web access, IPFS [23] proposes a P2P protocol based on content, rather than address. It avoids single points of failure, enhances the scalability and flexibility of the network, and has high performance. However, its cost of operation and maintenance is high, and it has not yet been applied on a large scale. Also, it is temporarily unable to provide rendered web pages with dynamic content.

Permaweb [24] is the service architecture for all websites and applications in the Arweave [25] network. It provides tamper-proof, permanent storage capabilities in a decentralized network, and provides content creators with low-cost, zero-maintenance, and permanently hosted web services. However, there are scalability issues, such as low throughput and high latency, as the number of transactions increases. Privacy and security challenges may arise due to the openness and transparency of Arweave. Computing and energy consumption issues are brought about by the consensus algorithm. Decentralization may lead to legal and supervisory issues.

Tim, the father of the World Wide Web, launched the Solid project at the end of 2017 [26]. Solid is a decentralized social platform that “re-decentralizes the Internet”. Solid designed the “Linked Data” specification to allow data to flow freely on the Internet. This breaks down the data silos between large technology companies and makes data owned by content creators.

The API3 project [27] provides DApps with interactive services with off-chain real-world data and services by DAPIs. It allows smart contracts to access off-chain real-world data without the need for oracles. The blockchain system can access API data and services through Airnode. API3 solves the problem of incompatibility between APIs and DApps in the centralized ecosystem. It enables existing APIs to interact with decentralized Web3.

The search function of traditional centralized web applications generally mainly relies on centralized indexed search engines of large technology companies. Meanwhile, the ESPRESSO [28] framework provides large-scale search Solid pods [29] for individuals or applications. ESPRESSO considers access rights and caching requirements while promoting distributed query performance. It provides a solution for enhancing search utility in the decentralized web.

In terms of access to DWeb, Decentralized Domain Name Service (DDNS) [30] is a relatively popular solution. The ownership, registration rights, usage rights, etc., of DDNS are not controlled by a centralized third party. DDNS is decentralized and runs on the blockchain. In 2011, Namecoin [31] was created based on the Bitcoin code. It can manage and register .bit domain names in a decentralized manner, but it requires a special DNS to be accessed. The ENS (Ethereum Name Service) [32] provides similar functions and has a large number of users. It is a distributed, open, and extensible naming system based on Ethereum that can be mapped to Ethereum addresses, other cryptocurrency addresses, content hashes, metadata, etc. Handshake [33] employs a distributed, permissionless DNS-compatible naming protocol in which each peer verifies and manages the root zone to replace existing certificate authorities.

Singh et al. [34] proposed a framework for a decentralized web. It makes use of a mesh network to connect community-based routers. This DWeb design is also capable of operating during network partitions and can quickly re-synchronize with the larger network once connectivity has been restored.

Despite progress in decentralized web technologies, several significant challenges remain. Many DApps, despite being based on smart contracts, still rely on partial centralization. IPFS, although innovative, has high operation and maintenance costs, and lacks support for dynamic web pages, limiting its large-scale adoption. Permaweb in the Arweave network struggles with scalability issues, including low throughput and high latency during increased transactions, and faces privacy, security, computational, and regulatory challenges. Decentralized domain name services like Namecoin require special DNS for access, adding complexity. These limitations collectively indicate that there is still much work to be done to achieve a fully functional, efficient, and secure decentralized web ecosystem.

3. Modelling

3.1. System Architecture

Based on the research and analysis of DWeb-related technologies, and inspired by previous work, we designed a fully decentralized web application architecture: FDW. It generally includes basic components, DWeb market, developer client, publisher client, and visitor client. The FDW architecture is shown in Figure 3.

The blockchain that supports smart contract functions provides infrastructure for FDW, mainly including distributed storage, P2P network, consensus mechanism, incentive mechanism, etc. FDW directly uses the existing mature blockchain infrastructure. On this basis, some common basic components are provided, including DAO, DID, DeFi, smart contract virtual machine (VM), etc. FDW needs to integrate related basic DApps to better empower FDW.

The DWeb market is presented to manage and maintain all DWebs, which is composed of DWeb DAO, fund pool, DWeb container, DWeb content, etc. The DWeb DAO and fund pool are mainly used for DWeb governance and incentives, which are described in detail in Section 3.4. The DWeb container displays all published DWebs and their metadata, and it is the access entrance of DWebs. The DWeb content is submitted by the content providers and is stored on the blockchain.

The main roles of FDW are developers, publishers, and visitors. The developers register, upload them to the blockchain, and maintain them after the DWebs are developed. Then, the publishers download and deploy the DWebs when they have been successfully validated. The visitors are divided into DWeb viewers and content providers. The viewers only browse DWebs, and the content providers submit content data through the DWeb. The details are provided in Section 4.

3.2. Dynamic Multi-Point Publishing

Before publishing a DWeb, developers need to develop it, including the implementation of front-end pages and smart contracts, which are detailed in Section 4.2. After the development of a DWeb is completed, its metadata are stored on the blockchain through smart contracts. The DWeb’s metadata provide the basic information of a DWeb, whose data structure is defined in Table 2. The DWeb’s business logic is deployed to the blockchain in the form of smart contracts. The front-end page of the DWeb is published by multiple web publisher nodes that are closer to the DWeb ID, which is the unique identity value of a DWeb. We use the subtraction of two ID values to represent the logical distance, where the smaller the logical distance, the closer the two IDs are. When a DWeb publishing node goes offline or fails, it will be deployed and published by other closer nodes to achieve dynamic multi-point publishing. The DWeb dynamic multi-point publishing model is shown in Figure 4.

The minimum and maximum values of node ID for publishing DWeb are:

$${NodeID}_{min}=WebID-{\displaystyle \frac{2^n\times N_{webPub}}{2{\times N}_{publisher}}}$$

(1)

$${NodeID}_{max}=WebID+{\displaystyle \frac{2^n\times N_{webPub}}{2\times N_{publisher}}}$$

(2)

in which $WebID$ is the ID value of the DWeb being published. $n$ is the bit length of node ID and DWeb ID. The publisher number providing DWeb publishing services is $N_{publisher}$, and the number of DWeb that needs to be published is $N_{webPub}$. The node ID value calculated according to Formulas (1) and (2) may exceed the range of node ID (0, 2ⁿ), so the true value of node ID needs to be further calculated.

$$NodeID=\left\{\begin{array}{l}NodeID+2^n, NodeID<0\\ \hspace{1em}\hspace{1em}NodeID, 0\le NodeID<2^n\\ NodeID-2^n, NodeID\ge 2^n\end{array}\right.$$

(3)

From Figure 4, we assume that $n$ is 10, and 8 nodes (orange) have been registered as DWeb publisher nodes. When there is a DWeb w200 that needs to be published on 4 nodes (set by the developer, not less than 3), according to Formula (1), (2) and (3), the DWeb w200 should be deployed and published by the publisher node within the node ID range (968, 456], that is nodes n252, n147, n1020, and n381.

Each node has a DWeb DHT (distributed hash table) [35] to store the DWeb publisher key–value pair. The key records the DWeb published, and the value contains the DWeb publishing node ID. When a large number of DWebs are published, DWeb DHT will occupy a very large storage space of each node. Learning from the DHT of storing neighbor nodes in Ethereum, the DWeb DHT only stores the j DWebs closer to the current node, and only stores the k publisher node IDs closer to the current node for each DWeb. In Figure 4, when j and k are both 2,

Table 1. DWeb DHT of node n10.

DWeb (Distance)	Publisher Node	Distance	Stored
w900 (134)	n1020	14	Y
	n898	136	Y
	n147	137	N
	n645	389	N
w200 (190)	n1020	14	Y
	n147	137	Y
	n252	242	N
	n381	371	N
w700 (334)	n898; n766; n645; n520	136; 268; 389; 510	N
w400 (390)	n252; n381; n645; n520	242; 371; 389; 510	N

shows the DWeb DHT of node n10.

From Table 1, the DWeb DHT of node n10 only needs to store two DWebs (w900 and w200) and their two publisher nodes, which are closer to the current node n10.

Each publisher node needs to deploy multiple DWebs that match itself. The theoretical average number of DWebs that should be deployed per publisher node is:

$$N_{webPerPublisher}={\displaystyle \frac{N_{web}\times N_{webPub}}{N_{publisher}}}$$

(4)

in which $N_{web}$ is the total number of DWebs published in the FDW market. In Figure 4, $N_{webPerPublisher}$ is $4\times 4/8=2$. That is, four DWebs need to be deployed on eight publisher nodes, and each DWeb needs to be published on four different nodes. In theory, each publisher node needs to deploy an average of two DWebs.

3.3. Shortest Access Path

Each DWeb is published by multiple publisher nodes, so any client can visit a DWeb from different publisher nodes. From Table 1, only a part of the DWeb that is close to the client node is recorded in the DWeb DHT of the client node, so the client node cannot obtain all DWeb publisher nodes. For a DWeb that has been recorded in the local DWeb DHT of the client node, the client node can obtain the publisher node of the DWeb and directly visit the DWeb deployed on the publisher node. However, the client node cannot visit a DWeb if this DWeb has not been recorded in the local DWeb DHT of the current client node. The shortest access path is planned to visit DWebs not recorded in the local DWeb DHT of the client node. Figure 5 shows the model of the DWeb’s shortest access path.

The neighbor nodes’ DHT for each node record the m nodes closer to the current node. With the help of the neighbor nodes DHT, a closer publisher node can be found from the DWeb publisher nodes through multiple hops. The shortest access path is defined as the path that each hop passes farthest from the client node and is closest to the DWeb to be visited. For example, in Figure 5, client node n10 visits DWeb w400; due to the DWeb DHT of node n10 not storing DWeb w400, the shortest access path to visit the DWeb w400 requires multiple hops. In the first hop, client node n10 requests the DWeb w400 publisher to node n252, which is farthest from node n10 and closest to DWeb w400. Since the DWeb DHT of node n252 stores the publisher of DWeb w400, in the second hop, node n252 returns the DWeb w400 publisher of node n381 in its DWeb DHT to client node n10. Node n10 can visit the DWeb w400 through the publishing address of node n381.

The number of hops to find a DWeb publisher node that is closer to the client node is:

$$N_{hop}={\displaystyle \frac{|WebID-NodeID|-\frac{2^n\times N_{webPub}}{2\times N_{publisher}}}{\frac{2^n\times N_{neighbor}}{2\times N_{node}}}}+1$$

(5)

in which $N_{node}$ is the number of all nodes in the blockchain p2p network and $N_{neighbor}$ is the maximum number of each node storing neighbor nodes. ${\displaystyle \frac{2^n\times N_{neighbor}}{2\times N_{node}}}$ represents the maximum logical distance of each hop through the neighbor nodes. The logical distance between the DWeb to be visited and the current client node is expressed as $|WebID-NodeID|$, which may exceed the range of ID (0, 2n), and also is further calculated by Formula (3).

In Ethereum, n is 256, and the maximum value of $|WebID-NodeID|$ is $2^{256}/2$. The number of all nodes is assumed to be 10,000 and the $N_{neighbor}$ is $16\times 256/15$. The number of all publisher nodes is assumed to be 1000 and $N_{webPub}$ is 16. Then, the maximum number of hops to find a DWeb publisher node for a client node is:

$$N_{maxHop}={\displaystyle \frac{\frac{2^{256}}{2}-\frac{2^{256}\times 16}{2\times 1000}}{\frac{2^{256}\times 16\times 256}{2\times \mathrm{10,000}\times 15}}}+1\approx 36$$

(6)

In other words, in a real blockchain network similar to Ethereum, the maximum number of hops for a client node needs to go through to visit a DWeb is 36.

3.4. Incentive and Governance

FDW is a collaborative to develop, deploy, publish, and visit DWebs at scale. There are multiple roles in FDW: developer, publisher, and visitor (viewer and content provider). DWeb governance is achieved through the incentives of the participants in a fully decentralized way. The method of FDW incentive and governance is shown in Figure 6.

In FDW, any honest DWeb viewer can challenge the faulty behavior of a developer, content provider, or publisher. There are many faulty behaviors for different roles, such as a developer uploading a harmful DWeb to the blockchain, illegal content being submitted by a content provider, a publisher failing to provide DWeb publishing services as agreed, etc. If a challenge is proven, part of the stakes of misbehaving nodes will be taken away by automatically executing a smart contract.

DWeb developers need to stake some tokens into the fund pool when a DWeb is uploaded to the blockchain. If no verified challenge is received within a certain staking period, the developer’s stakes will be returned and a certain reward will be obtained.

It is similar for content providers. Some stake is deposited to the fund pool when new content is submitted. Within a shorter staking period, the deposit can be returned and a certain reward can be obtained if no proven challenge is received.

DWeb publishers are required to provide ongoing DWeb publishing services as agreed. The service fees of DWeb publishers are paid periodically. If continuous DWeb publishing services are not provided, the deposit will be forfeited.

DWeb viewers need to pay a certain fee to visit a DWeb on the DWeb market and have voting rights at the DWeb governance. The incentive mechanism of FDW creates a positive feedback loop that will continually improve its governance.

4. Workflow Design

4.1. Overall Workflow

The workflow of FDW consists of three phases: DWeb development, DWeb publishing, and DWeb visiting. The workflow of FDW is shown in Figure 7.

During the DWeb development phase, a DWeb application first needs to be developed, including web front-end pages for user interaction, smart contracts that implement business logic functions, etc. Then, the developer registers this DWeb application in the FDW market, deploys smart contracts, and uploads web front-end pages to the blockchain. After that, the DWeb applications need to be maintained and managed, such as through version upgrades, etc.

The publishers provide deployment and publishing services for the DWeb front-end. Any node with web publishing capabilities can register as a web publisher. When a corresponding type of DWeb is registered on the FDW market, these DWeb front-end pages are downloaded and validated; then, they are deployed locally to the publisher node. The DWeb service address is broadcasted to the entire blockchain P2P network, and this newly deployed DWeb can be accessed by all visitors.

Visitors can search for a DWeb based on custom requirements to access it. On the one hand, visitors can browse DWeb content data provided by other content providers. On the other hand, visitors can submit content data through the DWeb front-end pages, becoming a content provider. Visitors vote on the DWebs and content data to regulate and govern DWebs.

4.2. Developer

The main responsibilities of the developer are DWeb development, uploading DWeb to the blockchain, and maintaining DWeb. The development process of FDW is shown in Figure 8.

A fully decentralized DWeb is developed first, including front-end pages and smart contracts. The business logic functions of DWeb are implemented through smart contracts and can run in the virtual machine of each node in a decentralized manner. Visitors use all DWeb functions through front-end pages, which are dynamically deployed by multiple publisher nodes.

The developed DWeb will eventually be uploaded to the blockchain. The basic information of DWeb is first registered in the FDW market so that visitors can easily search for this DWeb. The basic information of DWeb includes the title, type, description, developer, project start time, etc.

Then, the developer registers this DWeb application on the FDW market, deploys smart contracts, and uploads web front-end pages to the blockchain. Then, the smart contract that implements the DWeb business logic code is deployed to the blockchain. The DWeb front-end pages are also uploaded to distributed file servers (such as IPFS) for DWeb publishers to download and deploy. The DWeb’s smart contract address, front-end pages’ download addresses, hash value, etc. are written to the blockchain during the DWeb initialization process. The detailed algorithm of the DWeb register and uploading to the blockchain process is shown in Algorithm 1.

Algorithm 1: The process of DWeb registering and uploading to the blockchain

Input: DataItemDWeb: the basic information of this DWeb application Codecontract: the smart contract solidity code of this DWeb application PagefrontEnd: the front-end pages of this DWeb application Output: ResultDWeb: the process results of this DWeb application 1: web3 ← new Web3(web3URL) 2: contractFDW ← new web3.Contract(ContractFDW.ABI, ContractFDW.Address) 3: error ← contractFDW.methods.registerDWeb(DataItemDWeb).send({ from: myAccount }) 4: if error != null then 5:  return error 6: contractItem ← compile(Codecontract, 1) 7: contractnew ← new web3.Contract(contractItem.ABI) 8: addrnewContract ← contractnew.deploy({data: contractItem.byteCode}).send({ from: myAccount } 9: hashpages, urlpages ← Upload(PagefrontEnd) 10: error ← contractFDW.methods.InitDWeb(addrnewContract, hashpages, urlpages).send({ from: myAccount } 11: if error != null then 12:  return error 13: return true

In order to attract more visitors, DWeb developers may continue to operate and maintain DWeb. Developers can update DWeb registration information, upgrade DWeb front-end pages, actively interact with visitors in the community, and answer questions raised by visitors.

4.3. Publisher

On the blockchain, publisher nodes are a special type of node that can provide DWeb deployment and publishing services. According to the dynamic multi-point publishing model in Section 3.2, a DWeb will be dynamically deployed to multiple publisher nodes and maintain the set number that needs to be published.

Before deploying a DWeb, nodes with DWeb deployment capabilities provide service information, including service type, service period, etc., and register as a DWeb publisher on the FDW market. DWeb publishers screen out DWebs that meet their deployment conditions. For each DWeb, publishers download the front-end pages and verify them. The DWeb that passes verification is deployed locally to the publisher node. Its publishing address is broadcast to each node of the blockchain by calling the smart contract transaction of the FDW market. The detailed algorithm of the DWeb publishing process is shown in Algorithm 2.

Algorithm 2: The process of DWeb publishing

Input:  ServiceItem: the web service provided by this DWeb publisher 1: error ← contractFDW.methods.registerPublisher(ServiceItem).send({ from: myAccount }) 2: if error != null then 3:  return error 4: dwebs ← contractFDW.methods.queryDWeb(ServiceItem).call() 5: for I = 0; I < Count(dwebs); i++ 6:  if isCloser(dwebs[i]) then 7:   pages ← download(dwebs[i].hashpages, dwebs[i].urlpages) 8:   if isValid(pages) then 9:    dwebURL ← deployDWeb(pages) 10:    error ← contractFDW.methods.provideService(dwebURL).send({ from: myAccount }) 11:    if error != null then 12:     continue 13: end for 14: return true

After the DWeb publisher successfully deploys and publishes a DWeb, any node in the blockchain network can visit this DWeb through the DWeb publisher.

4.4. Visitor

Visitors can search for a specific DWeb on the DWeb Market, browse its content, and submit related content to the DWeb. Visitors have the right to vote on a DWeb and its content. The visiting process of FDW is shown in Figure 9.

In the DWeb market, visitors can view the basic information of all published DWebs when a client node is running. Some specific DWebs can be searched based on visitors’ customization requirements.

As a DWeb viewer, some fees are paid to browse DWeb pages and their content data. However, as a DWeb content provider, some rewards can be earned if visitors submit content for a DWeb that is legal and not challenged by other visitors.

Meanwhile, any visitor can vote on the browsed DWeb pages and their contents to implement DWeb governance, which is described in detail in Section 3.4.

5. Prototype System

5.1. Overall Design

According to the design of the FDW framework with dynamic multi-point publishing and the shortest access path, we develop a prototype system. The Ethereum node client Geth [36] is modified to implement a dynamic multi-point path and shortest access path. Each client node has a DWeb container to display all DWebs. A DWeb as an example to validate FDW. The design of the FDW prototype system is shown in Figure 10.

From Figure 10, DWeb visitors can view the DWeb container locally through a browser, since each modified client node deploys a DWeb container. The detailed design of the DWeb container and an example of DWeb are given in Section 5.2 and Section 5.3.

5.2. DWeb Container

DWeb container is the visiting entrance to all DWebs. It is deployed in each modified node and can be visited by each client node. The main functions of the DWeb container include DWeb registration and update, DWeb initialization, DWeb search, DWeb publishing list update, etc.

Table 2. The data structure of a DWeb’s basic information.

Data Item	Size (Bytes)	Remark
DWeb Id	8	The unique identifier of a DWeb in the DWeb market
Deploy Type	4	DWeb type that publisher nodes can deploy
Title	32	The unique title of the current DWeb
Category	4	The category of the current DWeb
Description	128	Detailed description of the current DWeb functions, features, etc.
Developer	32	The developer of the current DWeb
Upload Time	8	The time that the current DWeb is first uploaded to the blockchain
Contract Address	32	The address of the smart contract that implements the current DWeb business logic code
Pages Hash	32	Hash value of all DWeb front-end pages
Pages download URL	32	The front-end pages’ download addresses of the current DWeb
Publishing URL List	32 × n	The list of all publishing URL addresses
Version	8	The version of the current DWeb

shows the data structure of a DWeb’s basic information.

The function implementation of the DWeb container is realized through smart contract code. The DWeb container front-end pages and smart contract code are implemented for detail.

5.3. Example DWeb

In order to better demonstrate the relationship between a DWeb and a DWeb container, we implemented a DWeb instance as an example. The example DWeb mainly implements article management, including article lists and search, adding new articles, modifying article content, article comments, etc.

Table 3. The data structure of an article management DWeb.

Data Item	Size (Bytes)	Remark
DWeb ID	8	The unique identifier of a DWeb in the DWeb market
Title	32	The unique title of the current DWeb
Description	128	Detailed description of the current DWeb functions, features, etc.
Developer	32	The developer of the current DWeb
Create Time	8	The time that the current DWeb is first uploaded to the blockchain
Version	8	The version of the current DWeb
Comments List	32 × n	The list of all publishing URL addresses

shows the data structure of article management DWeb.

The front-end pages and smart contract code of this example DWeb are designed. The smart contract code is uploaded on the blockchain by the developer in the form of deploying smart contract transactions, and the front-end pages are deployed and published by multiple publisher nodes.

6. Analysis and Evaluation

6.1. Experimental Setup

We analyze and evaluate FDW adopting the prototype system implemented in Section 5. 100 modified Ethereum nodes build a blockchain network, and the PoA (proof-of-authority) [37] consensus engine is used. These nodes run in 4 virtual machines, each of which has 16 cores, 32 GB DRAM, 20 Mbps bandwidth, and 50 ms latency, running Ubuntu 20.04 LTS. 20 nodes are registered as publisher nodes, and the number of the example DWeb needs to be published is 4. The values of the FDW prototype system running parameters are shown in

Table 4. The values of the FDW prototype system running parameters.

Parameter	Value	Remark
$n$	256	The bit length of node ID and DWeb ID
$N_{node}$	100	The number of all nodes in the blockchain p2p network
$N_{neighbor}$	$16\times 256/15$	The maximum number of each node storing neighbor nodes
$N_{publisher}$	20	The number of publisher nodes
$N_{webPub}$	4	The number of the example DWeb needs to be published

.

In order to publish more DWebs, we simply copied multiple article management DWebs (described in detail in Section 5.3), but each DWeb has a different Web ID, which is evenly distributed.

6.2. Decentralization

In FDW, a publisher node can deploy multiple DWebs and a DWeb can be deployed by multiple publisher nodes. In experiment (a), we measure the average number of DWebs deployed by publisher nodes of FDW, theoretical value, and centralized deployment with the varying total number of DWebs. The experimental results are shown in Figure 11a. The total numbers of DWebs were set to 5, 10, 15, 20, 25, 30, 35, 40, 45, and 50. The theoretical average number of DWebs deployed by publisher nodes was calculated according to Formula (4). In experiment (b), the total number of DWebs remained at a fixed value of 50, and the number of DWebs deployed by each publisher node is shown in Figure 11b.

According to Figure 11a, the average number of DWebs deployed by publisher nodes and the total number of DWebs are almost directly proportional. When the number of DWebs is greater, the number of DWebs deployed by publisher nodes is greater. The average number of DWebs deployed by publisher nodes is basically consistent with the theoretical number. In addition, when the same number of DWebs need to be published, the number of DWebs deployed by publisher nodes in FDW is lower than the number of webs deployed by centralized servers. In Figure 11b, the number of DWebs deployed by each publisher node is basically the same as that when the publisher node ID and DWebs ID are evenly distributed. These show that FDW is highly decentralized.

Further, we evaluate the decentralization of DWeb access by measuring the number of access times to each publisher node while continuously increasing the number of access times to a certain DWeb. Figure 12 shows the number of access times for publisher nodes with the total number of access times.

In Figure 12, the number of access times to the four publisher nodes is basically the same. When visitor client node IDs are unevenly distributed, their access times will be slightly different. Additionally, with the same total number of access times to a certain DWeb, the number of access times to each publisher node in FDW is less than the number of access times to centralized servers.

The decentralization of FDW is mainly reflected in three aspects: (1) Decentralization of DWeb operation. Different from the traditional centralized web, the content data of DWeb is stored on the blockchain through smart contracts, and each full node stores the content data of DWeb. The business logic of DWeb is also achieved through smart contracts. In addition, by adopting dynamic multi-point publishing, FDW realizes the decentralization of Web front-end pages. (2) Decentralization of DWeb access. In FDW, different viewers may access different publisher nodes when they browse a special DWeb, and the same viewer browsing a special DWeb may access different publisher nodes at different times. (3) Decentralization of DWeb governance. Administrators generally have the greatest authority to manage the centralized web. While in FDW, any DWeb viewer can challenge the fault behavior of different roles. The incentive mechanism effectively promotes viewers to actively improve DWeb governance.

From the above, as the number of DWebs that need to be published and the number of publisher nodes increase, DWebs can be deployed to more publisher nodes, and access to DWeb becomes more dispersed. Therefore, the larger the number of DWeb that needs to be published and the number of publisher nodes, the higher the degree of decentralization.

6.3. Scalability

For the scalability of FDW, we compare the FDW and traditional centralized web from storage overhead and network load of a publisher node. In this experiment, we published 50 DWebs, whose Web ID was evenly distributed and size was about 0.3 MB per DWeb. Firstly, we continuously increased the number of publisher nodes from 4 to 40 in steps of 4 and recorded the size of the average storage overhead of publisher nodes. The average storage overhead of publisher nodes with the number of publisher nodes is shown in Figure 13a. Then, client nodes initiate requests for content data of 50 DWebs. We evaluate the network load of a publisher node with a varying number of publisher nodes. The network load per publisher node with the number of publisher nodes is shown in Figure 13b.

Compared with storing all web data on a publisher node for the traditional centralized web, each publisher node only stores the front-end-page data of DWebs deployed on this node. The storage overhead per publisher node is greatly reduced in FDW. When the number of all DWebs and the number of DWebs that need to be published remain unchanged, the storage overhead of each publisher node decreases as the number of publisher nodes increases.

According to Figure 13b, as the number of publisher nodes continues to increase, the network load of both FDW and traditional centralized web increases, but the network load of FDW increases significantly slower than that of the traditional centralized web. That is because content data requests from client nodes are distributed to various publisher nodes.

According to the above two experiments, the number of publisher nodes and the number of DWebs that need to be published are two important factors affecting the scalability of FDW. If the number of DWebs that need to be published is too small, the security of FDW will be reduced (described in detail in Section 6.4). Therefore, the greater the number of publisher nodes, the higher the scalability of FDW.

6.4. Security

In FDW, the security of content data storage and business logic implementation mainly relies on the blockchain system. However, some publisher nodes may be abnormally offline or launch attacks such as denial of web service (named Byzantine nodes). The probability that a visitor fails to access a DWeb is:

$$R_{accessFailed}={\displaystyle \frac{\left(\genfrac{}{}{0pt}{}{N_{allFaultPub}}{N_{faultWebPub}}\right) \left(\genfrac{}{}{0pt}{}{N_{publisher}-N_{allFaultPub}}{N_{webPub}-N_{faultWebPub}}\right)}{\left(\genfrac{}{}{0pt}{}{N_{publisher}}{N_{webPub}}\right)}}$$

(7)

in which $N_{allFaultPub}$ is the number of all Byzantine nodes in publisher nodes, and it is less than one-third of the total number of publisher nodes $N_{publisher}$ in the blockchain network. If $N_{allFaultPub}$ is larger than one-third of $N_{publisher}$, the FDW system is considered unsafe. $N_{faultWebPub}$ is the number of all Byzantine nodes in publisher nodes of a DWeb.

In Formula (7), DWeb is inaccessible when $N_{faultwebPub}$ and $N_{webPub}$ are equal. That is, a DWeb cannot be accessed when all publisher nodes of this DWeb are Byzantine nodes. In this case, Formula (7) can be simplified to:

$$R_{accessFailed}\le {\displaystyle \frac{\left(\genfrac{}{}{0pt}{}{\lfloor \frac{1}{3}\times N_{publisher}\rfloor }{N_{webPub}}\right) }{\left(\genfrac{}{}{0pt}{}{N_{publisher}}{N_{webPub}}\right)}}$$

(8)

According to Formula (8), we first kept $N_{publisher}$ unchanged at 30 and increased $N_{webPub}$ to measure the relationship between $R_{accessFailed}$ and $N_{webPub}$. Their relationship is shown in Figure 14a. Then, $N_{webPub}$ was kept unchanged at 4, and $N_{publisher}$ was increased to measure the relationship between $R_{accessFailed}$ and $N_{publisher}$. Figure 14b shows their relationship.

According to Figure 14, when the total number of publisher nodes remains unchanged, the greater the number of DWebs that need to be published, the lower the probability of failure to access a DWeb. The probability is close to 0 when the value of $N_{webPub}$ is greater than 7. On the other hand, if the number of DWebs that need to be published remains unchanged, the greater the total number of publisher nodes, the higher the probability of failure to access a DWeb. But the growth is relatively slow, and the probability of failure to access a DWeb is 1.23% when the total number of publisher nodes is 3000. The probability that a DWeb cannot be accessed is very low in Figure 14, and it shows that FDW is highly secure.

7. Discussion

7.1. Comparison

We compared FDW with other existing related decentralized schemes in decentralization, scalability, security, etc. is the results are shown in

Table 5. Comparison between FDW and existing decentralized schemes.

Schemes	Example	Decentralization	Scalability	Security
Traditional centralized web	github.com	Low	Poor	Low
Distributed file storage system [23]	IPFS [23]	Medium	Excellent	High
API3 [27]	api3.org [27]	Medium	Medium	Medium
DApp [10]	cryptokitties.co [21]	Business logic (✓) Front-pages (✕)	Poor	High
DWeb [12]	PermaWeb [24]	High	Poor	High
FDW (ours)	FDW	Full	Excellent	High

.

FDW is a fully decentralized web application framework in which DWeb front-end pages are deployed by multiple publisher nodes and business logic functions run in the virtual machine of each node through smart contracts. The dynamic multi-point publishing and shortest access path model is proposed to improve the scalability of FDW. Each DWeb is deployed by multiple closer publisher nodes, which not only addresses the single point of failure problem of traditional centralized web servers, but also avoids the waste deployed by all nodes in the blockchain. Meanwhile, each publisher node dynamically deploys multiple closer DWebs; that is, when some publisher nodes are offline or faulty and cannot be visited, other closer nodes will deploy the DWeb to keep the number of DWeb published consistent with the number that needs to be published. It ensures the reliability and security of DWeb.

IPFS is a distributed file storage protocol, which implements the decentralized management of files, such as text files, pictures, etc., but does not implement functions such as decentralized publishing and display of web applications. Projects related to API3 provide services interactive with the off-chain real world. They cannot provide complete web application functions, and their services are provided by specific nodes with off-chain data. Currently, some DApps have achieved decentralization in terms of storage and business logic, but front-end pages and some non-core business logic still adopt a traditional centralized approach. PermaWeb can permanently store various static files or network applications and allow users to create a decentralized HTML5 APP online. However, developers cannot create a web application with complex functions. Its real application scenarios are relatively narrow and inconvenient for developers to use.

7.2. DWeb Supervision

It is very necessary to supervise DWebs and their content in order to prevent some illegal data from being submitted [38]. There are three supervision methods in FDW. Before submitting, both DWeb developers and content providers need to deposit a certain stake. If malicious behavior is detected, the deposit will be forfeited. During submission, all submitted content will be compared with the preset black word library. If there are illegal words, they cannot be submitted. Meanwhile, the publishers verify each DWeb before deploying it. If it does not pass the verification, it will not be deployed. Within a period after submission, every visitor can challenge a DWeb and its content. If this challenge is proven, part of the stakes of misbehaving nodes will be taken away.

In addition, some more reasonable and effective supervision measures can be introduced, but this is not the focus of this paper.

7.3. Access DWeb by Domain Name

Almost everyone accesses a website through a domain name. In fact, the URL (uniform resource locator) of the website in the form of an IP (internet protocol) address and port is firstly obtained from the domain name server and then the website is accessed.

In FDW, the DWeb container is deployed by each modified client node. It is the visiting entrance to all DWebs, and there is no need for visitors to remember DWeb’s domain name. Additionally, each DWeb is dynamically deployed by multiple publisher nodes, which means that the binding relationship between the domain name and the web server often changes. Moreover, the domain name server will become an obstacle to decentralization, which is contrary to the fully decentralized web application framework of FDW.

7.4. Content Search

FDW provides a simple search function to search by title, category, description, etc. As the DWeb continues to grow, more complex search capabilities based on more conditions are necessary. Some decentralized search engine solutions have been proposed, such as ESPRESSO, which provides large-scale search Solid pods for enhancing search utility in the decentralized web.

Since each blockchain full node stores all ledger data, the storage pressure on full nodes will be high. Therefore, similar to each DWeb deployed by multiple closer publisher nodes, storing part of DWeb content data is a solution to address the high storage pressure of blockchain full nodes, such as sharding [39,40,41], separate of storage [42], etc.

8. Conclusions

Currently, the development of DApps is in a semi-decentralized phase, with only partial decentralization achieved. In this paper, FDW, a fully decentralized web application framework, is proposed. Leveraging blockchain systems that support smart contracts, the DWeb market is developed to manage all DWebs. Here, developers are responsible for registering, uploading, and maintaining DWebs; publishers download, verify, and deploy them; and visitors browse DWebs and supply content.

Specifically, each DWeb is deployed by multiple publisher nodes through dynamic multi-point publishing. This approach ensures the reliable operation of DWebs. Meanwhile, by using the shortest access path, client nodes can efficiently access any DWeb from the closest publishing node. Moreover, the incentive and governance mechanisms promote cooperation among developers, publishers, and visitors, safeguarding the security of FDW.

A prototype system of FDW has been developed, incorporating a DWeb container and an example DWeb. Through analysis and evaluation, FDW demonstrates certain advantages over other related decentralized schemes in terms of decentralization, scalability, and security.

Looking ahead, further research will be conducted on the supervision of DWebs and their content. Additionally, the exploration of decentralized web search engines remains an important area for future study.