1 Introduction

With significant advances in artificial intelligence, machine learning, modern computing, information and communication technology, it is expected that people’s daily lives will change significantly by 2030 [1]. People will rely on technology that is faster, more reliable, data-driven, intelligent, immersive, decentralized, and autonomous in their business and personal lives. According to [1], 6 G technology is expected to play a significant role in supporting higher communication speeds, reliability, and coverage for future human–machine centric emerging applications (e.g., metaverse, DAO, robotic communication, and brain-computer interaction-based applications). According to a recent report, 6 G networks are expected to provide 100% more energy efficiency than 5 G networks for various application executions [1]. Furthermore, with the rise of generative AI, chat-GPT, web 3.0, metaverse, blockchain, cryptocurrency, and smart devices, user device-generated traffic could exceed 5 zettabytes per month by 2030. The 6 G network will play a significant role in handling massive amounts of data by providing large bandwidth, high security, energy efficiency, adopting advanced antenna, AI and machine learning technology, blockchain, IoT, and edge computing, terahertz communication, and decentralized architectures (e.g., DAO applications), among others [1]. To address the challenges of the coming decade, the research in [2] identified some key technologies for 6 G networks, including terahertz communications (THz), super massive MIMO-based antenna systems, reflecting intelligent surfaces (RIS), holographic beamforming, immersive communication, edge computing, visible-light communications (VLC), blockchain-based work coordination and resource sharing, and quantum communications. The study also identified several requirements for 6 G use case scenarios such as a minimum 1 Tb/s peak data rate, 1 Gb/s user required data rate, E2E latency of 0.01–0.1 ms, high mobility (greater than 1000 km/h), high connection density (10 times more than 5 G), and higher energy efficiency (10–100 times higher than 5 G).

6 G wireless networks aim to automate smart society work by seamlessly integrating wireless networks spanning the ground, air, space, and underwater regions [3]. The 6 G network is expected to improve existing internet services by delivering not only virtualized and software-defined services, but also immersive, blockchain, and edge cloud-enabled internet of everything (IoE) solutions. With the transition to 6 G, several new industry 5.0-based cyber-physical-social-biological systems (CPSBS)-based applications may emerge by connecting physical devices to cyber, social, and biological space of communication, respectively. According to [4], 6 G networks will utilize all available spectrum resources, including millimeter, micro-wave, terahertz, and other light waves. 6 G networks will combine terrestrial, microwave, non-terrestrial, and satellite Internet to create a network that is energy, latency, and reliability efficient, has a higher connection density, is flexible, intelligent, and secure.

Recently, the FCC (Federal Communications Commission) emphasized that blockchain technology, when combined with 6 G, can deliver a more secure and distributed network than the previous 5 G-based network [5]. To that end, blockchain technology has gained popularity as a reliable technology for distributed applications in the internet of everything (IoE) and 6 G network domains, attracting significant attention from both researchers and industry professionals. Initially, BitCoin’s success prompted users and industry professionals to focus on blockchain-based digital asset exchange activities. However, initially, the audience for cryptocurrency usage was limited due to limited capacity and high latency costs during digital asset exchange. To address this issue, researchers have focused on blockchain-based smart contracts (such as Ethereum). Using the ethereum virtual machine, or EVM, Ethereum provides a suitable platform for users who rely on smart contract-based decentralized application execution. Blockchain-based smart contracts are best suited for DAO applications due to their self-organization and self-management capabilities. The smart contract can offer access control facilities, service coordination, resource sharing facilities, fairness, and finding the access history of DAO users [6].

In the blockchain based peer-to-peer network, cryptography techniques and hash functions are used to create the data block [7]. The data blocks can be verified decentralizedly using consensus algorithms (e.g., PoW, PoS). Blockchain applications are expanding beyond payments and financial data storage to include healthcare, manufacturing, and education, among others [8]. Blockchain technology is scalable, decentralized, and distributed, allowing for permanent data recording and transaction validation without the use of central authorities. Blockchain technology offers numerous benefits, including security, privacy, decentralization, resiliency, smart contract-based transactions, data integrity, and trust. It is expected to improve the efficiency of 6 G network-based applications such as extended reality (XR), brain-computer interaction, metaverse, gaming, and fungible or non-fungible token based applications [6]. Blockchain-based services can benefit from 6 G technology in a variety of ways. Blokchain-based services may experience significant latency as a result of ledger consistency, ledger update, and transaction validation processes performed by miners. The 6 G network can improve the latency and reliability of several blockchain-based services (e.g., caching, computing, resource management, resource sharing) by providing decentralization, trusted parties reduction, massive ultra-realibility with low latency (URLLC), ERLLC (extremely reliable and low latency), LDHMC (long-distance and high-mobility communication), FeMBB (further enhanced mobile broadband), ELPC (extremely low-power communication), and umMTC (ultra-massive machine type) communication features [6].

The paper will then go over some blockchain-related applications, such as electronic government services and DAOs. Due to several reasons (centralization and human intervention), the electronic governance services (e-services) suffer from several inefficiencies in terms of security and transparency. Because of centralized decision-making or IT infrastructure, e-services are vulnerable to external attacks. Furthermore, an electronic system that requires human intervention or control may be prone to significant error and corruption. External attacks and human interventions have the potential to compromise data integrity and privacy. To address these issues, the work in [9] focuses on the implementation of decentralized blockchain-based smart contract policies. Blockchain, along with smart contract technologies, can improve efficiency and deliver automated services for different organizations, like decentralized autonomous organizations (DAOs). The DAO can use smart-contract programs (i.e., rules are written as smart-contract programs) to execute business rules when specified. The members of the organization (e.g., developers or users who can buy membership via crytocurrency) control any DAO regulations or rules using blockchain technology [9, 10]. Collaboration among organizations wholeheartedly relies on effective information sharing. In different business platforms, like the supply chain, multiple parties collaborate (e.g., manufacturing, marketing, and delivery parties), requiring extensive information exchange to integrate different processes. Blockchain technology uses smart contracts to execute inter-organization-based cooperative business processes and supports decentralized autonomous organizations (DAO) [10].

Currently, to validate transactions in the blockchain network, different consensus mechanisms are used in the literature, such as PoW, or proof-of-work, and PoS, or proof-of-stake [9]. In the PoW-based consensus mechanism, the miner or validator node can be selected based on high computational power (i.e., that solves the puzzle). Whereas, in the PoS-based mechanism, the validators are selected based on their stake (i.e., participants that can invest cryptocurrency or ether as collateral). The authors in [9] also mentioned that due to its decentralized nature and validator-based block validation capability, the blockchain with smart contract-based policy execution can be a perfect match for many DAO applications. Unlike traditional organizations, the DAO can be governed without the need for a centralized system. In a centralized autonomous organizations (CAO), the central authority or board members can decide the rules, goals, and actions associated with the organization, and other members or employees need to act upon the central authority’s decision (e.g., a traditional bank). In contrast, in decentralized organizations based on DAO, all members have voting rights (i.e., users must purchase some cryptocurrency for membership tokens) on any decisions or rules governing the organization. Unlike CAO, the decentralized autonomous organization can provide blockchain-based, scalable, and democratized decision-making features [11]. The smart contract running on the Ethereum blockchain network can provide automated agreement, governance policy setup, and rule-checking facilities for various DAO-based services (e.g., crowdfunding, project voting, NFT trading) without the need for human intervention [12]. One of the primary characteristics of DAO-based services is autonomy. DAOs rely on automated programs (e.g., smart contracts) to carry out decisions that do not require human intervention or manual processes [11]. When a smart contract (in the blockchain) triggers certain events, the decentralized system executes them automatically. For example, when the transaction is supported via the sufficient votes provided by the DAO members, the funds associated with the transaction will be dispatched to the recipient account by the contractor nodes in the Ethereum blockchain. DAOs enable partnerships between different entities or members without the need for any physical communication. This is because the smart contract that runs in the network nodes automatically eliminates the need for human interventions. By adopting the 6 G and blockchain-based smart contract governance system, the DAO can not only efficiently address the security concerns suffered by centralized systems (e.g., DoS attacks) but also lower the cost associated with the complex IT system for a centralized solution. By storing the DAO rules and transactions in the blockchain, the blockchain technology can increase security and transparency among involved parties (e.g., DAO members). The integration of 6 G with blockchain networks can offer low-latency decentralized, and secure services for DAO applications via smart contracts [13,14,15].

To increase organizational efficiency and value circulation, the DAO-based decentralized autonomous work execution approach not only integrates monetary capital with human capital but also other assets or capital as a component of the system. By doing so, DAOs can effectively manage not only uncertainty and diversity issues but also complexity in the working environments, making them a promising new decentralized organization work management model [16]. To deliver digitalized, intellectual, democratized, and collaborative management or governance (i.e., both on and off-chain), DAO can leverage not only blockchain technology but also utilize the features and benefits of various other technologies (e.g., AI, big data, and IoT) [16]. The article in [17] created a decentralized crowdfunding application (DAO) using Ethereum as a blockchain platform. Users can use this decentralized application to donate money to causes that are important to them. The authors used blockchain to not only verify transactions, but also to protect sensitive application data. Contributors can use the blockchain-based, secure crowdfunding platform to support exciting startups or ventures at low risk. This platform enables individuals, small start-ups, and various teams to raise funds for their projects by offering tokens to potential contributors or members. Currently, the literature contains several blockchain-based DAO projects, including coin swapping DAO, voting DAO, crytoloan DAO, social club DAO, and NFT trading DAO, among others.

Now we’ll talk about some DAO-related works. According to [18], decentralized autonomous organizations (DAOs) can revolutionize resource allocation, asset exchange, production processes, and organizational operation structures by combining blockchain and Web 3.0 technologies. It should be noted that Web 3.0 is the latest version of the internet that includes decentralization, blockchain, and token-based economics. DAOs can use token economics and other value creation schemes to bring together communities with similar goals or values for Web 3.0 (e.g., autonomy, self-operation, or evolution via smart contracts). DAOs promote fairness, value maximization, and justice among Web 3.0 participants. DAOs can protect their members’ privacy and security. DAOs are critical to achieving Web 3.0’s goal of building a prosperous and open Internet with unique value. The works in [19, 20] indicated that DAO-based applications have gained interest not only in finance-related applications, but also in other areas that require decentralized autonomy, such as autonomous self-driving cars or vehicular applications [21, 22], and social club operation activities. According to articles [19, 23], DAO operations include not only blockchain smart contracts with on-chain and off-chain transaction processing, but also cyber-physical-social system components and various cryptocurrency token types.

In [24], the authors stated that Web 3.0, with the help of both blockchain and DAO, can break the previous oligarchy structure and create a new scientific field known as decentralized science (DeSci). Web 3.0 can realize the distributed network vision and enable services such as network ownership and autonomy through the use of DAO, blockchain, and various cryptocurrency exchange technologies. The articles in [24] stated that the DAO can be governed by both humans and machines without a centralized hierarchy. Previous research on DAOs [23,24,25] concentrated on the challenges and modeling of DAOs rather than coordinating and slicing resources for multiple DAOs on a blockchain platform. The task allocation strategy based on user choice, DAO, and non-DAO-based application execution over the 6 G network is still being considered.

Previous research has focused on 6 G, blockchain, and DAO application execution separately, despite their extensive overlap. According to the authors’ knowledge, previous research has not compared the performance of DAO and traditional centralized non-DAO applications in a 6 G-based blockchain network. Furthermore, there is a lack of multi-platform coordination and a low-latency resource choreography scheme for both DAO and non-DAO application execution that considers both blockchain and MEC activities. The previous work did not select heterogenous resources (local and non-local DAO work execution server, virtual worker, blockchain work processing device, bandwidth, and cloud resources) at the same time for multiple DAO applications by taking not only the lowest possible workload processing delay but also both the lowest communication delay and the lowest resource access waiting delay. The existing literary works did not provide an appropriate low-latency multi-application scheduling scheme for both DAO and non-DAO applications. Importantly, the existing blockchain and MEC-enabled 6 G network did not test the performance of various DAO applications, including crowdfunding DAO, decentralized voting DAO, cryto-loan DAO, social club DAO, NFT-sale DAO, rent NFT DAO, and coin swapping DAO. Along with various DAO applications, the MEC and blockchain-based 6 G network-based work did not investigate different non-DAO application execution performance, such as remote monitoring applications and traditional centralized banking-based loan applications.

Previous literary works did not provide an answer to how to coordinate various tasks such as network setup, blockchain regulation, DAO setup, real-time user DAO/non-DAO application requests and resource information, application-specific best resource mapping, timeslot allocation, and application execution all at the same time. The literature lacks an adaptive network model for DAO and non-DAO-based application execution that considers blockchain, mobile-edge cloud computing, different application types and their characteristics (workload and data size), DAO servers, different user devices, worker types, and 6 G network technologies. Previous works’ application work completion and result supply delays did not account for various phases of delay, such as network setup, blockchain regulation, DAO setup, real-time user DAO/non-DAO application request and resource information, application-specific best resource mapping, and DAO/non-DAO application execution phase delay. Previous works lack a suitable numerical model that takes performance metrics such as application work completion delay, economic charges, throughput, service deployer and supplier surplus, demand realization ratio, energy overhead, acquired benefit ratio, and so on.

To address the gaps, this article gives a street smart multi-platform coordination and low-latency-aware resource choreography scheme for decentralized autonomous organizations (DAO) and non-DAO-based application execution over blockchain and MEC-enabled 6 G networks.

The significant contributions associated with this article are mentioned below:

  • This work provides a resource choreography scheme that selects the best physical device resources, digital worker device resources (DAO server, MEC cloud server, blockchain device, third party server), and communication resource for each DAO and non-DAO application execution with minimum application work completion latency by checking local and non-local resource node status and application requirements.

  • This work gives a low-latency application first-based application timeslot scheduling scheme by taking multiple resource coordination, application deadline requirements, and different DAO and non-DAO applications. This work provides a blockchain and MEC-enabled 6 G network model to investigate the performance of different DAO applications (e.g., crowdfunding DAO, decentralized voting DAO, cryto-loan DAO, social club DAO, NFT saling DAO, rent NFT DAO, and coin swapping DAO applications). Along with different DAO applications, this work also investigates the performance of different non-DAO applications.

  • To assess the DAO and non-DAO application performance over MEC and blockchain-powered 6 G networks, this article includes a suitable numerical model that consists of application work completion and result supply delay, economic charges for users, total acquired throughput, service deployer and supplier surplus value, demand realization ratio, user total energy overhead, acquired benefit ratio, average prevailing power, and prevailing user percentage. The application work completion and result supply delay computation include not only computation work processing delay and waiting delay but also communication delay associated with heterogenous DAO and non-DAO-based application execution.

  • This paper gives the simulation results associated with the proposed kaizen scheme that offers low-latency requirement application first serve basis (LLRF) scheduling, multi-platform (blockchain, web server, third party wallet service) coordination (MPC), and predicted low application work completion delay based resource selection with minimum workload processing delay (MPD), minimum waiting delay (MWD), and communication delay (MCD). The simulation results of the proposed kaizen scheme are compared to two existing schemes.

The literary works are discussed in the related works section 2. The proposed Kaizen scheme-based resource choreography scheme along with the network model is delivered in Sect. 3. The mathematical model is hinted at in Sect. 4. The simulation results associated with the proposed kaizen scheme and the compared scheme are delivered in Sect. 5. The findings of the paper are discussed in Sect. 6.

Fig. 1
figure 1

Proposed network model for DAO and non-DAO-based application execution

Full size image

2 Related Works

This section will discuss literary works about decentralized autonomous organizations that use blockchain and 6 G technology. The authors of [26, 27] investigated the research issues and preliminary steps involved in the execution of blockchain-based DAO applications. The work in [28] discussed the importance of DAO-based interaction among digital, robotic, and human workers in the execution of manufacturing tasks. The authors of [29] emphasize the importance of artificial intelligence technology, parallel systems, and DAOs in developing next-generation smart city-based applications. The article in [30] discusses the organizational structure, requirements, supporting technologies, governance mechanisms, and applications for DAO. According to [31], the DAO can provide digital governance and management of digital assets, data, and identities through the implementation of smart contracts on the blockchain. The article in [32] discussed the role of NFTs in the DAO. They stated that NFTs could be used in the DAO to represent digital ownership of assets (such as real estate or art). The authors of [33, 34] discussed the core elements: governance, beliefs, transaction fees, voting power, membership, rules and regulations, use cases, technologies, the role of AI, and open issues related to DAO-based application. The works in [35] discussed the various autonomy levels associated with DAOs. The works in [36, 37] emphasize the importance of DAO-based parallel maintenance and collaborative governance for various vehicular application implementations. The article in [38] looked into various research challenges associated with Web 3.0 and DAO, including scaling issues, accountability management, the quality of user request execution, and collaboration among technologies and agents, among others. The work in [39] created a social DAO platform for crowdfunding applications that combines the Ethereum blockchain, smart contracts, and token exchange interfaces. The authors of [40] discussed how a DAO can use a blockchain-based platform to perform voting tasks, task management, strategic decision-making, and token exchange activities.

The authors of [41] proposed integrating DAO technologies with V2X technologies to enable the deployment of safe and secure vehicular services. The article in [42] discussed the importance of blockchain, IoT, and cloud technologies for various data-centric DAO application executions. The work in [43] considers the role of human intelligence, AI-generated content, and society 5.0 technologies in making fair and accountable decisions in DAOs. The work in [44] proposed a new management framework for CPSS (cyber-physical-social systems)-based work execution that takes parallel management, AI, and DAO into account. The authors of [45] discussed various design considerations for different web 3.0 and DAO-based decentralized application (dAPP) development, such as low latency, high security, high throughput, low energy overhead, and low service costs. The article in [46] looked into the challenges of using a DAO-based operational model, privacy-preserving collaboration between technologies and platforms, and data transfer activities for safe and secure ITS (intelligent transportation system) services. The work in [47] discussed DAO working procedures, as well as how DAO can be created and used for a variety of applications such as charities, freelance businesses, and investments. The article in [48] looked at the differences between a decentralized DAO and a traditional centralized organization. They stated that in a DAO, there is no centralized authority. In contrast, traditional centralized systems lack transparency due to centralized control. They stated that a centralized control-based system can be biased and result in significant delays in service delivery. They also provided some popular DAO use cases, including crowdfunding DAO, NFT exchange DAO, investment DAO, governance DAO, and social DAO. The work in [49] demonstrated that DAOs can be governed by smart contracts, which are a key component of blockchain technology. A smart contract (i.e., computer code) can be written by programmers to provide the logic, agreements, and terms between parties and users regarding transaction execution. The authors of [50] suggested that a DAO could run on the blockchain using a series of smart contracts for various transaction processing tasks (e.g., voting) or NFT transfer-based metaverse applications. Unlike the previously mentioned and existing research articles, this paper investigates the performance of a street smart and low-latency-aware resource assignment scheme for DAO and non-DAO-based application execution over a 6 G network.

Fig. 2
figure 2

Workflow and timestamp arrangement for DAO and non-DAO-based application execution

Full size image
Algorithm 1
figure a

Proposed Kaizen algorithm

Full size image

3 Proposed Kaizen-Based Resource Choreography for DAO and Non-DAO Application Execution

3.1 Network Model and Specific Considerations

The proposed network infrastructure for the DAO and non-DAO-based applications is highlighted in Fig. 1. The proposed network infrastructure incorporates four parts. The access network is the first component of the network model, in which DAO and non-DAO application subscribers connect to the internet or the remaining network via their cellular base station or WLAN access point-based connectivity (IEEE 802.11b-based bandwidth up to 6–8 GHz, distance limit: 1.01 km). The access network’s subscribers and worker nodes (which are within cellular BS coverage) include software developer devices, various types of manager devices (branch manager/senior manager/store owner/general manager), video camera sensors, mobile phones, computers, robots, doctors’ devices, chief financial officer/head of business devices, and human worker devices, among others. The access network can provide users and subscribers with a variety of wireless connections, including the IEEE 802.11b-based microwave link (bandwidth range 3–7 GHz, distance up to 1–500 m), the IEEE 802.11ad-based milimeter wave link (30–300 GHz bandwidth range and distance up to 1–40 m), and the IEEE 802.15.3.d-based terahertz link (bandwidth range 3–10 THz, distance limit 1–15 m). The second part is the edge network. In the edge network, the edge cloud server is connected to a cellular base station via an IEEE 802.3ca-based next-generation fiber link (communication distance of 20 to 40 km, up to 50 GB/s). Different types of edge worker devices and instances are also connected to the edge server via a fiber link and reside near the edge cloud server, such as blockchain devices (local etherium clients, miners, peer blockchain devices), web servers, local DAO servers, and third-party servers (for various wallet services). The third part is the core network, which allows different routers to transport traffic to and from the remote cloud or edge network. The edge network devices (cellular base station, edge cloud server) communicate with the core network via an IEEE 802.3cd dedicated fiber link. The final part of the network model is the remote cloud network. It should be noted that the remote cloud network devices connect to the core network via an IEEE 802.3 CD fiber link. A fiber link connects various types of devices in the remote cloud network. The remote cloud network’s devices include the remote cloud server, remote blockchain server, web server, remote DAO server (for maintenance, DAO member conflict, recovery, membership, and voting issue resolution), and remote third party server (for various wallet services).

The maximum work execution or CPU speed for the edge-cloud worker device (MEC cloud server, blockchain device, web server, local DAO server, and third-party server) is 4200 MHz, with a storage capacity of 128 GB. The maximum work execution or CPU speed for the remote-cloud worker device (remote cloud server, blockchain device, web server, local DAO server, and third-party server) is 5000 MHz, with a storage capacity of 256 GB. The local worker or user device has a processing speed of 1800 MHz and a storage capacity of 512 MB. In this paper, the resource choreographer node at the cellular base station provides resource assignment, timeslot design orchestration, and worker selection for various DAO and non-DAO-based application executions over blockchain and the MEC-enabled 6 G network. Figure 2 delineates the proposed kaizen scheme-based workflows and timestamp arrangement for DAO and non-DAO-based application execution.

3.2 Kaizen-Based Resource Choreography and Application Scheduling Process

The operation ordering process associated with the proposed Kaizen-based resource choreography and application scheduling process for DAO and non-DAO-based applications is shown in Fig. 2. Algorithm 1 describes the working procedure and logical steps involved in the proposed scheme. As illustrated in Fig. 2, the entire time cycle associated with DAO and non-DAO application execution is divided into five phases. The introductory phase begins with the resource choreographer node at the edge (cellular base station) sending beacon messages (IB) to its surrounding devices and receiving user connectivity request messages (RU) from users and subscribers (e.g., mobile devices, video cameras, medical devices, and various manager devices). The users or subscriber devices also send or receive service register requests (SR) or response messages (OR) to and from the resource choreographer node. Following that, the second phase, or blockchain operation regulation phase, will begin. The second phase involves the users or subscribers sending a blockchain service registration request message (BR) and receiving a blockchain service registration response message. They also took part in user verification, key exchange, and consensus mechanism setup operations during the initial blockchain operation setup process (KE). The following phase is the DAO setup and initiation phase. During this phase, the developers first create a DAO, then create a smart contract for the DAO, and finally deploy and test the DAO for the specified time duration (DC). Next, users can purchase tokens for DAO membership using the investing operation duration (MP). Following that, DAO members can change or establish a new DAO government by voting during the designated DAO government setup period (vo). The fourth phase, known as the user request send and resource choreography phase, will now begin. During the fourth phase, subscribers/users send resource status update requests to workers (RR messages) and then receive responses from workers (RE messages). The slot schedule for application request dispatch is then delivered by the resource choreographer device to users (via PS message). Next, the users and subscribers can send their DAO and non-DAO application execution request messages to the resource choreographer device (during the RT slot). The host resource choreographer device then requests that other nearby choreographer devices send their resource schedule information (via ORR message) and receives their response (via OS message).

Following that, the host resource coordinator checks each DAO and non-DAO application request and schedules the most suitable most resources/physical-digital worker (blockchain device, web server, cloud server, third party server, DAO server) with communication resources for each DAO and non-DAO application request (during the SS slot) with the minimum predicted application work completion and result supply delay \(g_{acdl}^{j}\) (see Sect. 4 for calculation). In this work, physical, digital worker, and communication link resources for each DAO and non-DAO application are chosen based on their predicted computation workload processing delay, communication delay, and waiting delay. It should be noted that the predicted application work completion and result supply delay calculations account for communication delay, workload (for application execution), processing delay, and waiting delay. Following the timeslot and resource scheduling for multiple subscriber application requests (DAO and non-DAO applications), the resource choregrapher device sends schedule information to users and subscribers (BS message). Finally, the fifth phase will be operational. During this phase, both the DAO and non-DAO applications will be executed at their designated timeslots. In this work, the DAO/non-DAO app timeslot means the time duration in which the operation associated with the DAO/non-DAO application will be executed by using the selected physical and digital device resources along with communication resources. In this work, a low-latency requirement-based DAO/non-DAO application will be executed prior to the non-low-latency DAO/non-DAO application request. During the DAO application timeslots, all DAO applications are executed (e.g., crowdfunding DAO, decentralized voting DAO, cryptoloan DAO, social DAO, NFT art selling DAO, coin swapping DAO, rent NFT DAO application). During non-DAO application timeslots, all non-DAO applications are executed (e.g., remote monitoring, traditional loan application in a bank, retail chaining application, doctor prescription application). Section 4.1 discusses all of the steps involved in executing DAO and non-DAO applications.

4 Mathematical Model

This section briefly highlights the mathematical calculation model necessary for examining different performance metrics. First, we will deliver the model associated with application work completion and result supply delay.

4.1 Average Application Work Completion and Result Supply Delay (AAWCD)

The total DAO and non-DAO-based application work completion and result supply delay (\(g_{acdl}^{j}\)) comprises all delays associated with the introductory setup phase (\(g_{ip}^{j}\)), blockchain registration phase (\(g_{brp}^{j}\)), DAO setup phase (\(g_{dsp}^{j}\)), user app request send and resource choreography phase (\(g_{urc}^{j}\)), and DAO and non-DAO application execution phase completion (\(g_{dnoa}^{j}=g_{da}^{j}+g_{nda}^{j}\)).

The average application work completion and result supply delay \(G_{aad}^{j}\) is denoted by taking the ratio of total work completion delay and total application (DAO and non-DAO) number (\(G_{aad}^{j}=\frac{\sum _{j=1}^{y}g_{acdl}^{j}}{j}\)). \(G_{aad}^{j}\) is analyzed by:

$$\begin{aligned} G_{aad}^{j}= & {} \frac{\sum _{j=1}^{y}g_{acdl}^{j}}{j}\nonumber \\= & {} \frac{\sum _{j=1}^{y}g_{ip}^{j}+g_{brp}^{j}+g_{dsp}^{j}+g_{urc}^{j}+g_{dnoa}^{j}}{j}, \end{aligned}$$
(1)

where j is the total DAO and non-DAO application execution request number.

The introductory network and connection setup phase delay \(g_{ip}^{j}\) is quantified by:

$$\begin{aligned} g_{ip}^{j}= & {} \frac{h_{ib}^{j}+h_{ru}^{j}+h_{sr}^{j}+h_{or}^{j}}{n_{fk}}*\alpha _{fk}\nonumber \\{} & {} +\frac{h_{ib}^{j}+h_{ru}^{j}+h_{sr}^{j}+h_{or}^{j}}{n_{wk}}*\alpha _{wk}+ \frac{L_{io}^{j}}{\mu _{ro}^{j}}\nonumber \\{} & {} + \frac{L_{iu}^{j}}{\mu _{su}^{j}}+g_{po}^{j}+g_{wo}^{j} \end{aligned}$$
(2)

\(h_{ib}^{j}\), \(h_{ru}^{j}\), \(h_{sr}^{j}\), and \(h_{or}^{j}\) are the introductory Beacon message size, user network connect request message size, user DAO and non-DAO application service registration request size, and service registration response message size, respectively. \(g_{po}^{j}\) and \(g_{wo}^{j}\) are the incurred propagation latency and waiting delay latency, respectively. In this work, we have used the M/D/1 queuing model for waiting delay calculation during resource usage and application execution [51]. \(\mu _{ro}^{j}\) and \(\mu _{su}^{j}\) are the work processing speed for resource choreographer and user device, respectively. \(L_{io}^{j}\) and \(L_{iu}^{j}\) are the workload amounts for the resource orchestrator and user device during the introductory phase, respectively. \(n_{fk}\), \(n_{wk}\), \(\alpha _{fk}\), and \(\alpha _{wk}\) are data transfer rates for fiber links, data transfer links for wireless links, associated hop count numbers during fiber links, and wireless link-based data dispatch, respectively.

The blockchain registration phase delay \(g_{brp}^{j}\) is enumerated by:

$$\begin{aligned} g_{brp}^{j}= & {} \frac{h_{br}^{j}+h_{ke}^{j}+h_{sr}^{j}}{n_{fk}}*\alpha _{fk}\nonumber \\{} & {} +\frac{h_{br}^{j}+h_{ke}^{j}+h_{sr}^{j}}{n_{wk}}*\alpha _{wk}+ \frac{L_{brb}^{j}}{\mu _{bcw}^{j}}+ \frac{L_{bru}^{j}}{\mu _{su}^{j}}+g_{po}^{j}+g_{wo}^{j} \end{aligned}$$
(3)

\(h_{br}^{j}\), \(h_{ke}^{j}\), and \(h_{sr}^{j}\) are the user blockchain registration request message size, key exchange and consensus/agreement message data size, and blockchain service registration completion message, respectively. \(\mu _{bcw}^{j}\) and \(\mu _{su}^{j}\) are the work processing or CPU speed for the blockchain and the user device, respectively. \(L_{brb}^{j}\) and \(L_{bru}^{j}\) are the workload counts for blockchain devices and user devices during the blockchain registration phase, respectively.

The DAO setup phase delay \(g_{dsp}^{j}\) is enumerated by:

$$\begin{aligned} g_{dsp}^{j}= & {} \frac{h_{dc}^{j}+h_{mp}^{j}+h_{vo}^{j}}{n_{fk}}*\alpha _{fk}+ \frac{L_{dcd}^{j}}{\mu _{dw}^{j}}+ \frac{L_{dcb}^{j}}{\mu _{bcw}^{j}} \frac{L_{dcu}^{j}}{\mu _{su}^{j}}\nonumber \\{} & {} +\frac{h_{dc}^{j}+h_{mp}^{j}+h_{vo}^{j}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j} \end{aligned}$$
(4)

\(h_{dc}^{j}\), \(h_{mp}^{j}\), and \(h_{vo}^{j}\) are the message sizes associated with DAO creation, smart-contract deployment operation, and DAO governance setup operation, respectively.

\(L_{dcd}^{j}\), \(L_{dcb}^{j}\), and \(L_{dcu}^{j}\) are the workload counts for the DAO server, web server, third-party server, blockchain device, and user device/developer device during the DAO setup phase, respectively. \(\mu _{dw}^{j}\) is the work processing or CPU speed for the digital worker device (DAO server, web server, or third-party server).

The user app request send and resource choreography phase delay \(g_{urc}^{j}\) is figured by:

$$\begin{aligned} g_{urc}^{j}= & {} \frac{h_{rr}^{j}+h_{re}^{j}+h_{ps}^{j}+h_{rt}^{j}+h_{orr}^{j}+h_{os}^{j}+h_{bs}^{j}}{n_{fk}}*\alpha _{fk}+\nonumber \\{} & {} \times \frac{L_{urhc}^{j}}{\mu _{ro}^{j}}+ \frac{L_{uroc}^{j}}{\mu _{ro}^{j}}+\frac{L_{urdw}^{j}}{\mu _{dw}^{j}}+\frac{L_{uru}^{j}}{\mu _{su}^{j}}+g_{po}^{j}+g_{wo}^{j}\nonumber \\{} & {} +\frac{h_{rr}^{j}+h_{re}^{j}+h_{ps}^{j}+h_{rt}^{j}+h_{orr}^{j}+h_{os}^{j}+h_{bs}^{j}}{n_{wk}}*\alpha _{wk} \end{aligned}$$
(5)

\(h_{rr}^{j}\), \(h_{re}^{j}\), \(h_{ps}^{j}\), \(h_{rt}^{j}\), \(h_{orr}^{j}\), \(h_{os}^{j}\), and \(h_{bs}^{j}\) are the message size associated with worker resource status request, resource status response by worker, slot schedule message for users app request dispatch, app request transfer by users, host choreographer to other nearby choreographer app schedule information request, nearby choreographer to host choreographer app schedule response, and broadcasted resource schedule message, respectively. \(L_{urhc}^{j}\), \(L_{uroc}^{j}\), \(L_{urdw}^{j}\) and \(L_{uru}^{j}\) are the workload counts for the host choreographer device, other choreographer device, different worker, and user device/developer device during the user app request send and resource choreography phases, respectively.

The DAO and non-DAO application execution phase delay \(g_{dnoa}^{j}\) is figured by taking both DAO and non-DAO type application execution (\(g_{dnoa}^{j}=g_{da}^{j}+g_{nda}^{j}\)). \(g_{dnoa}^{j}\) is quantified by:

$$\begin{aligned} g_{dnoa}^{j}= & {} \sum _{j=1}^{y}(g_{cfd}^{j}+g_{dvd}^{j}+g_{cld}^{j}+g_{sod}^{j}+g_{snad}^{j}\nonumber \\{} & {} +g_{rnd}^{j}+g_{csd}^{j}+g_{ndrm}^{j}+g_{ndtb}^{j}+g_{ndrc}^{j}+g_{nddp}^{j}) \end{aligned}$$
(6)

\(g_{cfd}^{j}\), \(g_{dvd}^{j}\), \(g_{cld}^{j}\), \(g_{sod}^{j}\), \(g_{snad}^{j}\), \(g_{rnd}^{j}\), and \(g_{csd}^{j}\) are the DAO application work finalization delays regarding crowdfunding DAO, decentralized voting DAO, crypto-loan DAO, social DAO, selling art DAO, renting NFT DAO, and coin-swap DAO application, respectively.

\(g_{ndrm}^{j}\), \(g_{ndtb}^{j}\), \(g_{ndrc}^{j}\), and \(g_{nddp}^{j}\) are the non-DAO application work finalization delays regarding the remote monitoring app, traditional banking app, retail chain app, and doctor prescription application, respectively.

First, this article will deliver the work finalization delay (\(g_{cfd}^{j}\)) associated with the crowdfunding DAO application.

If a user wishes to participate in the crowdfunding DAO-based application, he or she can go to the crowdfunding DAO web application page. The web page javascript handles the donation contribution event from the start, using the donation input from users. During this phase, participants can connect their Ethereum wallet to the crowdfunding DAO web app interface. The web app UI offers users a variety of options, including the ability to create a crowdfunding project or contribute to an existing crowdfunding project. Before contributing to any crowdfunding project, the user must first add ether tokens to their wallet (such as a metamask). The user then contributes to a crowdfunding project by selecting the project and amount. The user concludes the contribution process by confirming the token contribution approval in the wallet. The web app then sends the transaction to the local Ethereum node. The web page calls the contribute ether() function of a crowdfunding smart contract on a local node of the Ethereum blockchain network, resulting in a donation transaction.

The local Ethereum node then validates the crowdfunding contribution transaction. Once validated, the transaction is sent to the blockchain network’s peer nodes. Peers validate the donation transaction, which is then sent to the miner node. The miner node then validates the donation transaction, executes the logic associated with the contribution function, modifies the crowdfunding smart contract state, places the transaction on a new block (with hashing), and appends the block to the blockchain. Following that, the block is sent to the peer blockchain nodes by the miners for validation. Following validation, the peer blockchain device sends the block to the local Ethereum node. Following the execution of the ether contribution or donation transaction during block validation, the local ether client’s smart contract executes the donation completion operation. The donation funds will be transferred from the donor’s wallet to the crowdfunding project wallet (via BLKC processing by a local Ethereum client). Finally, once the smart contract running on the local Ethereum node has completed block processing, the successful or contribution confirmation event is published on the users’ web application page or web UI. The app work finalization delay (\(g_{cfd}^{j}\)) associated with the crowdfunding DAO application is calculated as follows:

$$\begin{aligned} g_{cfd}^{j}= & {} \sum _{j=1}^{y}(\delta _{utw}^{j}+\delta _{upw}^{j}+\delta _{wspf}^{j}+\delta _{tpp}^{j} +\delta _{tptws}^{j}+\delta _{wstlb}^{j}\nonumber \\{} & {} +\delta _{lbcw}^{j}+\delta _{lbtp}^{j}+\delta _{ppw}^{j} +\delta _{ptm}^{j}+\delta _{mfw}^{j}+\delta _{mtp}^{j}+\delta _{psw}^{j}\nonumber \\{} & {} +\delta _{ptlbc}^{j}+\delta _{lbcws}^{j}+\delta _{lbctws}^{j}+\delta _{wsps}^{j}) \end{aligned}$$
(7)

\(\delta _{utw}^{j}\) is the user device to web server preliminary app request data transfer delay regarding crowdfunding DAO application execution.

\(\delta _{utw}^{j}\) is enumerated by:

$$\begin{aligned} \delta _{utw}^{j}=\frac{h_{uwsc}^{j}}{n_{fk}}*\alpha _{fk}+ \frac{L_{swc}^{j}}{\mu _{wsw}^{j}}+ \frac{L_{uwc}^{j}}{\mu _{su}^{j}} +\frac{h_{uwsc}^{j}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j} \end{aligned}$$
(8)

where \(h_{uwsc}^{j}\) is the dispatched data amount between user device and web server during users connectivity with the web app. \(L_{swc}^{j}\) and \(L_{uwc}^{j}\) are the workload amounts for the web server and user device during user connectivity with the web server, respectively. \(\mu _{wsw}^{j}\) and \(\mu _{su}^{j}\) are the computation work processing speeds for the web server and user device, respectively.

\(\delta _{upw}^{j}\) is the user device workload amount processing delay during donation/ether contribution to a crowdfunding project.

\(\delta _{upw}^{j}\) is examined by: \(\delta _{upw}^{j}= \frac{L_{upw}^{j}}{\mu _{su}^{j}}\).

\(L_{upw}^{j}\) is the workload for the user device regarding crowdfunding project selection and donation work processing.

\(\delta _{wspf}^{j}\) is the crowdfunding DAO web server workload processing delay regarding user donation input taking, connecting third-party servers regarding wallet-related activities, and transaction creation after user donation message signing via wallet. \(\delta _{wspf}^{j}\) is hinted by: \(\delta _{wspf}^{j}= \frac{L_{wspf}^{j}}{\mu _{wsw}^{j}}\). \(L_{wspf}^{j}\) is the workload for the web server regarding donation input processing and transaction processing.

\(\delta _{tpp}^{j}\) is the third party server workload processing delay during crowdfunding donation event processing (e.g., add ether to wallet, wallet connectivity with web app, ether swapping with other coin during exchange, transfer ether from user wallet to crowdfunding DAO wallet). \(\delta _{tpp}^{j}= \frac{L_{tpp}^{j}}{\mu _{tpw}^{j}}\). \(L_{tpp}^{j}\) is the workload for third-party servers regarding ether donation, swapping, and transfer ether-related activities for the crowdfunding DAO application. \(\mu _{tpw}^{j}\) is the work processing or CPU speed for a third-party server. \(\delta _{tptws}^{j}\) is the data transfer delay to or from the web server from or to a third-party server during donation activities and web server connectivity with a third-party server. \(\delta _{tptws}^{j}=\frac{h_{tptws}^{j}}{n_{fk}}*\alpha _{fk}+ \frac{h_{tptws}^{j}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\). \(h_{tptws}^{j}\) is the exchanged data amount between the web server and third-party server for crowdfunding DAO application execution. \(\delta _{wstlb}^{j}\) is the donation transaction data dispatch delay from the web server to the local Ethereum node on the Ethereum blockchain. \(\delta _{wstlb}^{j}=\frac{h_{wstlb}^{j}}{n_{fk}}*\alpha _{fk}+ \frac{h_{wstlb}^{j}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\). \(h_{wstlb}^{j}\) is the exchanged donation transaction data amount size that flows from the web server to the local Ethereum node on the Ethereum blockchain. \(\delta _{lbcw}^{j}\) is the dispatched donation/crowdfunding transaction validation work processing delay at the Ethereum client node. \(\delta _{lbcw}^{j}= \frac{L_{lbcw}^{j}}{\mu _{bcw}^{j}}\). \(L_{lbcw}^{j}\) is the workload for the Ethereum client node regarding signed transaction primary validation work processing. \(\mu _{bcw}^{j}\) is the CPU speed for blockchain worker devices (e.g., miner, ethereum client nodes, peer blockchain devices). \(\delta _{lbtp}^{j}\) is the validated transaction data transfer delay from the local blockchain Ethereum client node to the peer blockchain device for transferred donation or crowdfunding transaction validation. \(\delta _{lbtp}^{j}=\frac{h_{lbtp}^{j}}{n_{fk}}*\alpha _{fk}+ \frac{h_{lbtp}^{j}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\). \(h_{lbtp}^{j}\) is the validated transaction data size that exchanges from the local ethereum clint node to the peer blockchain device. \(\delta _{ppw}^{j}\) is the dispatched transaction validation work processing delay at the peer blockchain node. \(\delta _{ppw}^{j}= \frac{L_{ppw}^{j}}{\mu _{bcw}^{j}}\). \(L_{ppw}^{j}\) is the workload for the peer blockchain node. \(\delta _{ptm}^{j}\) is the validated transaction data transfer delay from peer device to miners for block creation and appending to blockchain. \(\delta _{ptm}^{j}=\frac{h_{ptm}^{j}}{n_{fk}}*\alpha _{fk}+ \frac{h_{ptm}^{j}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\). \(h_{ptm}^{j}\) is the peer node validated transaction data size that exchanges from the peer blockchain device to the miner device.

\(\delta _{mfw}^{j}\) is the miner node work processing delay that includes the donation transaction validation and logic execution related to the donation/contribution function, crowdfunding smart contract state change work, placement of the validated transaction on a new block, and addition of the block to the blockchain. \(\delta _{mfw}^{j}= \frac{L_{mfw}^{j}}{\mu _{bcw}^{j}}\). \(L_{mfw}^{j}\) is the workload for the miner node that includes donation transaction validation, smart contract state-changing work, new block generation, and the addition of a new valid block to the blockchain. \(\delta _{mtp}^{j}\) is the block data transfer delay from the miner to peer devices. \(\delta _{mtp}^{j}=\frac{h_{mtp}^{j}}{n_{fk}}*\alpha _{fk}+ \frac{h_{mtp}^{j}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\). \(h_{mtp}^{j}\) is the valid block data size that is exchanged from the miner to the peer blockchain device.

\(\delta _{psw}^{j}\) is the peer node secondary blockchain work processing delay that includes block validation and execution. \(\delta _{psw}^{j}= \frac{L_{psw}^{j}}{\mu _{bcw}^{j}}\). \(L_{psw}^{j}\) is the workload amount for peer device-based block data validation work. \(\delta _{ptlbc}^{j}\) is the validated block data transfer delay from the peer device to the local Ethereum client device at the blockchain network. \(\delta _{ptlbc}^{j}=\frac{h_{ptlbc}^{j}}{n_{fk}}*\alpha _{fk}+ \frac{h_{ptlbc}^{j}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\). \(h_{ptlbc}^{j}\) is the peer node validated block data size that exchanges from the peer blockchain device to the local Ethereum client device. \(\delta _{lbcws}^{j}\) is the local Ethereum client device-based final crowdfunding work completion delay that includes publication of transaction success confirmation, transfer fund confirmation from the user wallet to the crowdfunding DAO wallet address, and smart contract-based donation work processing. \(\delta _{lbcws}^{j}= \frac{L_{lbcws}^{j}}{\mu _{bcw}^{j}}\). \(L_{lbcws}^{j}\) is the secondary workload for the local Ethereum client device regarding new block syncronization, execution of transactions in the block, and transaction confirmation work. \(\delta _{lbctws}^{j}\) is the final donation-based crowdfunding application transaction success/confirmation message transfer delay from the local Ethereum client node to the web app server. \(\delta _{lbctws}^{j}=\frac{h_{lbctws}^{j}}{n_{fk}}*\alpha _{fk}+ \frac{h_{lbctws}^{j}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\). \(h_{lbctws}^{j}\) is the data size that consists of the transaction confirmation message. \(\delta _{wsps}^{j}\) is the web server-based final crowdfunding transaction completion or confirmation message visualization work processing delay. \(\delta _{wsps}^{j}= \frac{L_{wsps}^{j}}{\mu _{wsw}^{j}}\). \(L_{wsps}^{j}\) is the secondary workload for the web server regarding final crowdfunding transaction completion or donation delivery confirmation message visualization work.

Next, we will present the working delay associated with the decentralized voting application for DAO members. The app work finalization delay (\(g_{dvd}^{j}\)) for the decentralized voting DAO application is measured by:

$$\begin{aligned} g_{dvd}^{j}= & {} \sum _{j=1}^{y}(\delta _{utw}^{dvd}+\delta _{upw}^{dvd}+\delta _{wspf}^{dvd} +\delta _{tpp}^{dvd}+\delta _{tptws}^{dvd}+\delta _{wstlb}^{dvd}\nonumber \\{} & {} +\delta _{lbcw}^{dvd}+\delta _{lbtm}^{dvd}+\delta _{mfw}^{dvd}+\delta _{mtlb}^{dvd}+\delta _{lbcws}^{dvd} +\delta _{lbctws}^{dvd}+\delta _{wsps}^{dvd}) \end{aligned}$$
(9)

\(\delta _{utw}^{dvd}\) is the user device to web server preliminary voting app request data transfer delay.

\(\delta _{utw}^{dvd}\) calculation method is similar to \(\delta _{utw}^{j}\) (please see previous crowdfunding application work finalization delay). \(\delta _{upw}^{dvd}\) is the user device self workload processing delay during voting web app execution (\(\delta _{upw}^{dvd}= \frac{L_{upw}^{dvd}}{\mu _{su}^{j}}\)). \(\delta _{wspf}^{dvd}\) is the decentralized voting web server workload processing delay (\(\delta _{wspf}^{dvd}= \frac{L_{wspf}^{dvd}}{\mu _{wsw}^{j}}\)). \(\delta _{tpp}^{dvd}\) is the third party server workload processing delay during voting transaction processing (\(\delta _{tpp}^{dvd}= \frac{L_{tpp}^{dvd}}{\mu _{tpw}^{j}}\)). \(\delta _{tptws}^{dvd}\) is the data transfer delay to/from the web server from/to a third-party server during voting app processing (\(\delta _{tptws}^{dvd}=\frac{h_{tptws}^{dvd}}{n_{fk}}*\alpha _{fk}+ \frac{h_{tptws}^{dvd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{wstlb}^{dvd}\) is the voting transaction data transfer delay from the web server to the local Ethereum node (\(\delta _{wstlb}^{dvd}=\frac{h_{wstlb}^{dvd}}{n_{fk}}*\alpha _{fk}+ \frac{h_{wstlb}^{dvd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{lbcw}^{dvd}\) is the voting transaction validation work processing delay at the local ethereum node (\(\delta _{lbcw}^{dvd}= \frac{L_{lbcw}^{dvd}}{\mu _{bcw}^{j}}\)). \(\delta _{lbtm}^{dvd}\) is the validated transaction data transfer delay from Ethereum client node to the miner device (\(\delta _{lbtp}^{dvd}=\frac{h_{lbtp}^{dvd}}{n_{fk}}*\alpha _{fk}+ \frac{h_{lbtp}^{dvd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{mfw}^{dvd}\) is the miner node work processing delay (\(\delta _{mfw}^{dvd}= \frac{L_{mfw}^{dvd}}{\mu _{bcw}^{j}}\)). \(\delta _{mtlb}^{dvd}\) is the block data transfer delay from miner to the local Ethereum client device for validation work processing (\(\delta _{mtlb}^{dvd}=\frac{h_{mtlb}^{dvd}}{n_{fk}}*\alpha _{fk}+ \frac{h_{mtlb}^{dvd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{lbcws}^{dvd}\) is the local Ethereum client device-based final voting success checking work completion delay (\(\delta _{lbcws}^{dvd}= \frac{L_{lbcws}^{dvd}}{\mu _{bcw}^{j}}\)). \(\delta _{lbctws}^{dvd}\) is the final voting application transaction success/confirmation message transfer delay from Ethereum client node to the web app server (\(\delta _{lbctws}^{dvd}=\frac{h_{lbctws}^{dvd}}{n_{fk}}*\alpha _{fk}+ \frac{h_{lbctws}^{dvd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{wsps}^{dvd}\) is the web server-based voting transaction completion or confirmation message visualization work processing delay (\(\delta _{wsps}^{dvd}= \frac{L_{wsps}^{dvd}}{\mu _{wsw}^{j}}\)).

Next, we’ll talk about the work finalization delay for the cryto-loan DAO application execution. The app work finalization delay (\(g_{cld}^{j}\)) for cryto-loan DAO application is measured by:

$$\begin{aligned} g_{cld}^{j}= & {} \sum _{j=1}^{y}(\delta _{utw}^{cld}+\delta _{upw}^{cld}+\delta _{wspf}^{cld} +\delta _{tpp}^{cld}+\delta _{tptws}^{cld}+\delta _{wstlb}^{cld}\nonumber \\{} & {} +\delta _{lbcw}^{cld}+\delta _{lbtm}^{cld}+\delta _{mfw}^{cld}+\delta _{mtlb}^{cld}+\delta _{lbcws}^{cld}\nonumber \\{} & {} +\delta _{lbctws}^{cld}+\delta _{wsps}^{cld}) \end{aligned}$$
(10)

\(\delta _{utw}^{cld}\) is the user device to decentralized web server connectivity request transfer delay (i.e., calculation similar to \(\delta _{utw}^{dvd}\)). \(\delta _{upw}^{cld}\) is the user device initial workload processing delay during crytoloan app execution (\(\delta _{upw}^{cld}= \frac{L_{upw}^{cld}}{\mu _{su}^{j}}\)). \(\delta _{wspf}^{cld}\) is the crytoloan web server workload processing delay (\(\delta _{wspf}^{cld}= \frac{L_{wspf}^{cld}}{\mu _{wsw}^{j}}\)). \(\delta _{tpp}^{cld}\) is the third party server workload processing delay during crytoloan transaction processing (\(\delta _{tpp}^{cld}= \frac{L_{tpp}^{cld}}{\mu _{tpw}^{j}}\)). \(\delta _{tptws}^{cld}\) is the data transfer delay to/from the web server from/to a third-party server during crytoloan app processing (\(\delta _{tptws}^{cld}=\frac{h_{tptws}^{cld}}{n_{fk}}*\alpha _{fk}+ \frac{h_{tptws}^{cld}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{wstlb}^{cld}\) is the crytoloan transaction data dispatch delay from web app server to local Ethereum node (\(\delta _{wstlb}^{cld}=\frac{h_{wstlb}^{cld}}{n_{fk}}*\alpha _{fk}+ \frac{h_{wstlb}^{cld}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{lbcw}^{cld}\) is the crytoloan transaction validation work processing delay at the local ethereum node (\(\delta _{lbcw}^{cld}= \frac{L_{lbcw}^{cld}}{\mu _{bcw}^{j}}\)). \(\delta _{lbtm}^{cld}\) is the validated crytoloan transaction data transfer delay from local Ethereum client node to the miner device (\(\delta _{lbtp}^{cld}=\frac{h_{lbtp}^{cld}}{n_{fk}}*\alpha _{fk}+ \frac{h_{lbtp}^{cld}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{mfw}^{cld}\) is the miner node workload processing delay for crytoloan application (\(\delta _{mfw}^{cld}= \frac{L_{mfw}^{cld}}{\mu _{bcw}^{j}}\)). \(\delta _{mtlb}^{cld}\) is the block data transfer delay from miner to local Ethereum client device during crytoloan application execution (\(\delta _{mtlb}^{cld}=\frac{h_{mtlb}^{cld}}{n_{fk}}*\alpha _{fk}+ \frac{h_{mtlb}^{cld}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{lbcws}^{cld}\) is the local Ethereum client device-based block validation and transaction success checking/confirmation work completion delay (\(\delta _{lbcws}^{cld}= \frac{L_{lbcws}^{cld}}{\mu _{bcw}^{j}}\)).\(\delta _{lbctws}^{cld}\) is the final crytoloan transaction success/confirmation message transfer delay from the local Ethereum client to the web app server (\(\delta _{lbctws}^{cld}=\frac{h_{lbctws}^{cld}}{n_{fk}}*\alpha _{fk}+ \frac{h_{lbctws}^{cld}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{wsps}^{cld}\) is the web server-based crytoloan transaction completion visualization work processing delay (\(\delta _{wsps}^{cld}= \frac{L_{wsps}^{cld}}{\mu _{wsw}^{j}}\)).

Our next application is a social DAO-powered application execution. By purchasing tokens, the user can obtain social club membership and various benefits. The app work finalization delay (\(g_{sod}^{j}\)) for social DAO application is given by:

$$\begin{aligned} g_{sod}^{j}= & {} \sum _{j=1}^{y}(\delta _{utw}^{sod}+\delta _{upw}^{sod}+\delta _{wspf}^{sod} +\delta _{tpp}^{sod}+\delta _{tptws}^{sod}+\delta _{wstlb}^{sod}\nonumber \\{} & {} +\delta _{lbcw}^{sod}+\delta _{lbtm}^{sod}+\delta _{mfw}^{sod}+\delta _{mtlb}^{sod} +\delta _{lbcws}^{sod}+\delta _{lbctws}^{sod}+\delta _{wsps}^{sod}) \end{aligned}$$
(11)

\(\delta _{utw}^{sod}\) is the user device to social DAO web server conectivity request transfer delay (i.e., calculation process is similar to \(\delta _{utw}^{dvd}\)). \(\delta _{upw}^{sod}\) is the user device-based initial workload processing delay during social DAO app execution (\(\delta _{upw}^{sod}= \frac{L_{upw}^{sod}}{\mu _{su}^{j}}\)). \(\delta _{wspf}^{sod}\) is the social DAO web server workload processing delay (\(\delta _{wspf}^{sod}= \frac{L_{wspf}^{sod}}{\mu _{wsw}^{j}}\)). \(\delta _{tpp}^{sod}\) is the third party server workload processing delay during social club event access transaction processing (\(\delta _{tpp}^{sod}= \frac{L_{tpp}^{sod}}{\mu _{tpw}^{j}}\)). \(\delta _{tptws}^{sod}\) is the data exchange delay to/from the web server from/to a third-party server during social DAO application processing (\(\delta _{tptws}^{sod}=\frac{h_{tptws}^{sod}}{n_{fk}}*\alpha _{fk}+ \frac{h_{tptws}^{sod}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{wstlb}^{sod}\) is the social club event access transaction data dispatch delay from the web app server to local Ethereum node (\(\delta _{wstlb}^{sod}=\frac{h_{wstlb}^{sod}}{n_{fk}}*\alpha _{fk}+ \frac{h_{wstlb}^{sod}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{lbcw}^{sod}\) is the social event access transaction validation work processing delay at the local ethereum node (\(\delta _{lbcw}^{sod}= \frac{L_{lbcw}^{sod}}{\mu _{bcw}^{j}}\)). \(\delta _{lbtm}^{sod}\) is the validated social event access transaction data transfer delays from local Ethereum client to miner device (\(\delta _{lbtp}^{sod}=\frac{h_{lbtp}^{sod}}{n_{fk}}*\alpha _{fk}+ \frac{h_{lbtp}^{sod}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{mfw}^{sod}\) is the miner node workload processing delay for social DAO application transaction validation (\(\delta _{mfw}^{sod}= \frac{L_{mfw}^{sod}}{\mu _{bcw}^{j}}\)). \(\delta _{mtlb}^{sod}\) is the block data transfer delay from the miner to the local Ethereum client device during social DAO app execution (\(\delta _{mtlb}^{sod}=\frac{h_{mtlb}^{sod}}{n_{fk}}*\alpha _{fk}+ \frac{h_{mtlb}^{sod}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{lbcws}^{sod}\) is the local Ethereum client device-based block validation and transaction confirmation work completion delay. (\(\delta _{lbcws}^{sod}= \frac{L_{lbcws}^{sod}}{\mu _{bcw}^{j}}\)). \(\delta _{lbctws}^{sod}\) is the social club event access transaction success/confirmation message transfer delay from local Ethereum client to the social DAO web app server (\(\delta _{lbctws}^{sod}=\frac{h_{lbctws}^{sod}}{n_{fk}}*\alpha _{fk}+ \frac{h_{lbctws}^{sod}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{wsps}^{sod}\) is the social DAO web server-based social club event access transaction completion message visualization work processing delay (\(\delta _{wsps}^{sod}= \frac{L_{wsps}^{sod}}{\mu _{wsw}^{j}}\)).

The following section of this paper will discuss the work finalization delay associated with selling NFT art DAO application execution. The app work finalization delay (\(g_{sod}^{snad}\)) for selling NFT art DAO applications is given by:

$$\begin{aligned} g_{snad}^{j}= & {} \sum _{j=1}^{y}(\delta _{utw}^{snad}+\delta _{upw}^{snad}+\delta _{wspf}^{snad} +\delta _{tpp}^{snad}+\delta _{tptws}^{snad}\nonumber \\{} & {} +\delta _{wstlb}^{snad}+\delta _{lbcw}^{snad}+\delta _{lbtm}^{snad}+\delta _{mfw}^{snad} +\delta _{mtlb}^{snad}\nonumber \\{} & {} +\delta _{lbcws}^{snad}+\delta _{lbctws}^{snad}+\delta _{wsps}^{snad}) \end{aligned}$$
(12)

\(\delta _{utw}^{snad}\) is the user device for selling NFT art DAO web server conectivity request transfer delay (calculation similar to \(\delta _{utw}^{dvd}\)). \(\delta _{upw}^{snad}\) is the user device-based initial workload processing delay during selling NFT art DAO app execution (\(\delta _{upw}^{snad}= \frac{L_{upw}^{snad}}{\mu _{su}^{j}}\)). \(\delta _{wspf}^{snad}\) is the selling NFT art web server workload processing delay (\(\delta _{wspf}^{snad}= \frac{L_{wspf}^{snad}}{\mu _{wsw}^{j}}\)). \(\delta _{tpp}^{snad}\) is the third-party server workload processing delay during NFT after selling transaction processing (\(\delta _{tpp}^{snad}= \frac{L_{tpp}^{snad}}{\mu _{tpw}^{j}}\)). \(\delta _{tptws}^{snad}\) is the data exchange delay to/from the web server from/to a third-party server during NFT art selling application processing (\(\delta _{tptws}^{snad}=\frac{h_{tptws}^{snad}}{n_{fk}}*\alpha _{fk}+ \frac{h_{tptws}^{snad}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{wstlb}^{snad}\) is the NFT art selling transaction data dispatch delay from the web app server to the local Ethereum node on the Ethereum blockchain (\(\delta _{wstlb}^{snad}=\frac{h_{wstlb}^{snad}}{n_{fk}}*\alpha _{fk}+ \frac{h_{wstlb}^{snad}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{lbcw}^{snad}\) is the NFT art selling transaction transaction validation work processing delay at the local ethereum node (\(\delta _{lbcw}^{snad}= \frac{L_{lbcw}^{snad}}{\mu _{bcw}^{j}}\)). \(\delta _{lbtm}^{snad}\) is the validated NFT art selling transaction data transfer delays from the local Ethereum client to the miner device (\(\delta _{lbtp}^{snad}=\frac{h_{lbtp}^{snad}}{n_{fk}}*\alpha _{fk}+ \frac{h_{lbtp}^{snad}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{mfw}^{snad}\) is the miner node workload processing delay for NFT art selling transaction validation (\(\delta _{mfw}^{snad}= \frac{L_{mfw}^{snad}}{\mu _{bcw}^{j}}\)). \(\delta _{mtlb}^{snad}\) is the block data transfer delay from miner to the local Ethereum client device during NFT art selling transaction execution (\(\delta _{mtlb}^{snad}=\frac{h_{mtlb}^{sod}}{n_{fk}}*\alpha _{fk}+ \frac{h_{mtlb}^{snad}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{lbcws}^{snad}\) is the local Ethereum client device-based block validation and NFT art-selling transaction confirmation work completion delay (\(\delta _{lbcws}^{snad}= \frac{L_{lbcws}^{snad}}{\mu _{bcw}^{j}}\)). \(\delta _{lbctws}^{snad}\) is the publication of selling NFT art in the market place transaction success message transfer delay from local Ethereum client to the NFT art selling web server (\(\delta _{lbctws}^{snad}=\frac{h_{lbctws}^{sod}}{n_{fk}}*\alpha _{fk}+ \frac{h_{lbctws}^{snad}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{wsps}^{snad}\) is the NFT art selling web server-based selling work confirmation messages work processing delay (\(\delta _{wsps}^{snad}= \frac{L_{wsps}^{snad}}{\mu _{wsw}^{j}}\)).

The following section of this paper will discuss the work finalization delay associated with the execution of the renting NFT DAO application. In this renting NFT DAO, users can rent NFTs by providing ether or other cryptocurrencies as collateral. The app work finalization delay (\(g_{rnd}^{j}\)) for renting the NFT DAO application is delivered by:

$$\begin{aligned} g_{rnd}^{j}= & {} \sum _{j=1}^{y}(\delta _{utw}^{rnd}+\delta _{upw}^{rnd}+\delta _{wspf}^{rnd} +\delta _{tpp}^{rnd}+\delta _{tptws}^{rnd}+\delta _{wstlb}^{rnd}\nonumber \\{} & {} +\delta _{lbcw}^{rnd}+\delta _{lbtm}^{rnd}+\delta _{mfw}^{rnd}+\delta _{mtlb}^{rnd} +\delta _{lbcws}^{rnd}+\delta _{lbctws}^{rnd}+\delta _{wsps}^{rnd}) \end{aligned}$$
(13)

\(\delta _{utw}^{rnd}\) is the user device to rent NFT web server conectivity request transfer delay (similar as \(\delta _{utw}^{dvd}\)). \(\delta _{upw}^{rnd}\) is the user device initial workload processing delay during renting NFT app execution (\(\delta _{upw}^{rnd}= \frac{L_{upw}^{rnd}}{\mu _{su}^{j}}\)). \(\delta _{wspf}^{rnd}\) is the renting NFT web server workload processing delay (\(\delta _{wspf}^{rnd}= \frac{L_{wspf}^{rnd}}{\mu _{wsw}^{j}}\)). \(\delta _{tpp}^{rnd}\) is the third party server workload processing delay during renting NFT transaction processing (\(\delta _{tpp}^{rnd}= \frac{L_{tpp}^{rnd}}{\mu _{tpw}^{j}}\)). \(\delta _{tptws}^{rnd}\) is the data transfer delay to/from the web server from/to a third-party server during renting NFT app processing (\(\delta _{tptws}^{rnd}=\frac{h_{tptws}^{rnd}}{n_{fk}}*\alpha _{fk}+ \frac{h_{tptws}^{rnd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{wstlb}^{rnd}\) is the renting NFT transaction data dispatch delay from the web app server to the local Ethereum node (\(\delta _{wstlb}^{rnd}=\frac{h_{wstlb}^{rnd}}{n_{fk}}*\alpha _{fk}+ \frac{h_{wstlb}^{rnd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{lbcw}^{rnd}\) is the renting NFT transaction validation work processing delay at the local ethereum node. (\(\delta _{lbcw}^{rnd}= \frac{L_{lbcw}^{rnd}}{\mu _{bcw}^{j}}\)). \(\delta _{lbtm}^{rnd}\) is the validated renting NFT transaction data transfer delays from local Ethereum client node to the miner (\(\delta _{lbtp}^{rnd}=\frac{h_{lbtp}^{cld}}{n_{fk}}*\alpha _{fk}+ \frac{h_{lbtp}^{rnd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{mfw}^{rnd}\) is the miner node workload processing delay for renting NFT DAO application (\(\delta _{mfw}^{rnd}= \frac{L_{mfw}^{rnd}}{\mu _{bcw}^{j}}\)). \(\delta _{mtlb}^{rnd}\) is the block data transfer delay from the miner to local Ethereum client device during renting NFT DAO applications (\(\delta _{mtlb}^{rnd}=\frac{h_{mtlb}^{rnd}}{n_{fk}}*\alpha _{fk}+ \frac{h_{mtlb}^{rnd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{lbcws}^{rnd}\) is the local Ethereum client device-based NFT block validation and transaction success confirmation work completion delay (\(\delta _{lbcws}^{rnd}= \frac{L_{lbcws}^{rnd}}{\mu _{bcw}^{j}}\)). \(\delta _{lbctws}^{rnd}\) is the final renting NFT transaction confirmation message transfer delay from the local Ethereum client to the web app server (\(\delta _{lbctws}^{rnd}=\frac{h_{lbctws}^{rnd}}{n_{fk}}*\alpha _{fk}+ \frac{h_{lbctws}^{rnd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{wsps}^{rnd}\) is the web server-based renting NFT transaction completion message visualization work processing delay (\(\delta _{wsps}^{rnd}= \frac{L_{wsps}^{rnd}}{\mu _{wsw}^{j}}\)).

Our next application is the token exchange or coin swapping DAO application execution. In this application, users can exchange their own token (e.g., ether) for another coin (e.g., USDC). The app work finalization delay (\(g_{csd}^{j}\)) for coin swap DAO application is measured by:

$$\begin{aligned} g_{csd}^{j}= & {} \sum _{j=1}^{y}(\delta _{utw}^{csd}+\delta _{upw}^{csd}+\delta _{wspf}^{csd} +\delta _{tpp}^{csd}+\delta _{tptws}^{csd}+\delta _{wstlb}^{csd}\nonumber \\{} & {} +\delta _{lbcw}^{csd}+\delta _{lbtm}^{csd}+\delta _{mfw}^{csd}+\delta _{mtlb}^{csd} +\delta _{lbcws}^{csd}\nonumber \\{} & {} +\delta _{lbctws}^{csd}+\delta _{wsps}^{csd}) \end{aligned}$$
(14)

\(\delta _{utw}^{csd}\) is the user device to coin swap DAO web server conectivity request transfer delay (similar as \(\delta _{utw}^{dvd}\)). \(\delta _{upw}^{csd}\) is the user device-based initial workload processing delay during coin swap DAO app execution (\(\delta _{upw}^{csd}= \frac{L_{upw}^{csd}}{\mu _{su}^{j}}\)). \(\delta _{wspf}^{csd}\) is the coin swap web server workload processing delay (\(\delta _{wspf}^{csd}= \frac{L_{wspf}^{csd}}{\mu _{wsw}^{j}}\)). \(\delta _{tpp}^{csd}\) is the third-party server workload processing delay during coin swap transaction processing (\(\delta _{tpp}^{csd}= \frac{L_{tpp}^{csd}}{\mu _{tpw}^{j}}\)). \(\delta _{tptws}^{csd}\) is the data exchange delay to/from the web server from/to a third-party server during coin swap application processing (\(\delta _{tptws}^{csd}=\frac{h_{tptws}^{csd}}{n_{fk}}*\alpha _{fk}+ \frac{h_{tptws}^{csd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{wstlb}^{csd}\) is the coin swap transaction data dispatch delay from the web app server to local Ethereum node (\(\delta _{wstlb}^{csd}=\frac{h_{wstlb}^{sod}}{n_{fk}}*\alpha _{fk}+ \frac{h_{wstlb}^{csd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{lbcw}^{csd}\) is the coin swapping transaction validation work processing delay at the local ethereum node (\(\delta _{lbcw}^{csd}= \frac{L_{lbcw}^{csd}}{\mu _{bcw}^{j}}\)). \(\delta _{lbtm}^{csd}\) is the validated coin swap transaction data transfer delay from local Ethereum client node to miner device (\(\delta _{lbtp}^{csd}=\frac{h_{lbtp}^{csd}}{n_{fk}}*\alpha _{fk}+ \frac{h_{lbtp}^{csd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{mfw}^{csd}\) represents the miner node workload processing delay for coin swap transaction validation (\(\delta _{mfw}^{csd}= \frac{L_{mfw}^{csd}}{\mu _{bcw}^{j}}\)). \(\delta _{mtlb}^{csd}\) is the block data transfer delay from the miner to the local Ethereum client device during coin swap application execution (\(\delta _{mtlb}^{csd}=\frac{h_{mtlb}^{csd}}{n_{fk}}*\alpha _{fk}+ \frac{h_{mtlb}^{csd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{lbcws}^{csd}\) is the local Ethereum client device-based block validation and coin swap transaction confirmation work completion delay (\(\delta _{lbcws}^{csd}= \frac{L_{lbcws}^{csd}}{\mu _{bcw}^{j}}\)). \(\delta _{lbctws}^{csd}\) is the coin swap transaction confirmation message transfer delay from the local Ethereum client to the coin-swap web server (\(\delta _{lbctws}^{csd}=\frac{h_{lbctws}^{csd}}{n_{fk}}*\alpha _{fk}+ \frac{h_{lbctws}^{csd}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{wsps}^{csd}\) is the coin swap web server-based transaction completion message visualization work processing delay (\(\delta _{wsps}^{csd}= \frac{L_{wsps}^{csd}}{\mu _{wsw}^{j}}\)).

Our next application is non-DAO retain chain operation execution, which relies on centralized decision-making. Different retail chain-based decision-making operations, such as product price setup, can be performed in this application by soliciting feedback from the central decision-maker. The app work finalization delay (\(g_{ndrc}^{j}\)) for retail chaining-based non-DAO applications is evaluated by:

$$\begin{aligned} g_{ndrc}^{j}= & {} \sum _{j=1}^{y}(\delta _{smc}^{ndrc}+\delta _{smfp}^{ndrc}+\delta _{smtm}^{ndrc} +\delta _{mp}^{ndrc}+\delta _{mtsm}^{ndrc}\nonumber \\{} & {} +\delta _{csmp}^{ndrc}+\delta _{smtbm}^{ndrc}+\delta _{bmp}^{ndrc} +\delta _{bmtsm}^{ndrc}+\delta _{smsp}^{ndrc}) \end{aligned}$$
(15)

\(\delta _{smc}^{ndrc}\) is the store manager delay regarding internet connectivity and edge cloud server connectivity delay (similar to \(\delta _{utw}^{dvd}\)). \(\delta _{smfp}^{ndrc}\) is the store manager-based initial workload processing delay that includes the sales report generation and capturing delay (\(\delta _{smfp}^{ndrc}= \frac{L_{smfp}^{ndrc}}{\mu _{su}^{j}}\)). \(\delta _{smtm}^{ndrc}\) is the store manager’s captured data offload delay to the local MEC server. (\(\delta _{smtm}^{ndrc}=\frac{h_{smtm}^{ndrc}}{n_{fk}}*\alpha _{fk}+ \frac{h_{smtm}^{ndrc}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{mp}^{ndrc}\) is the MEC server-based offloaded data processing delay (\(\delta _{mp}^{ndrc}= \frac{L_{mp}^{ndrc}}{\mu _{dw}^{j}}\)). \(\delta _{mtsm}^{ndrc}\) is the MEC processed resultant data transfer delay to the senior manager device at central office (\(\delta _{mtsm}^{ndrc}=\frac{h_{mtsm}^{ndrc}}{n_{fk}}*\alpha _{fk}+ \frac{h_{mtsm}^{ndrc}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{csmp}^{ndrc}\) is the senior manager device-based workload processing delay regarding price decision (\(\delta _{csmp}^{ndrc}= \frac{L_{csmp}^{ndrc}}{\mu _{su}^{j}}\)). \(\delta _{smtbm}^{ndrc}\) is the senior manager device processed resultant data transfer delay to branch manager device (\(\delta _{smtbm}^{ndrc}=\frac{h_{smtbm}^{ndrc}}{n_{fk}}*\alpha _{fk}+ \frac{h_{smtbm}^{ndrc}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{bmp}^{ndrc}\) is the branch manager device-based workload processing delay (\(\delta _{bmp}^{ndrc}= \frac{L_{bmp}^{ndrc}}{\mu _{su}^{j}}\)). \(\delta _{bmtsm}^{ndrc}\) is the branch manager device processed resultant data transfer delay to the store manager device (\(\delta _{bmtsm}^{ndrc}=\frac{h_{bmtsm}^{ndrc}}{n_{fk}}*\alpha _{fk}+ \frac{h_{bmtsm}^{ndrc}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{smsp}^{ndrc}\) is the store manager device-based workload processing delay regarding the execution of senior and branch manager decisions regarding product price (\(\delta _{smsp}^{ndrc}= \frac{L_{smsp}^{ndrc}}{\mu _{su}^{j}}\)).

Next, we’ll talk about the app work finalization delay for non-DAO-based traditional banking applications. In this application, the user first uploads loan-related documents to a local MEC server. The MEC server processes the loan application’s success and eligibility results. The loan eligibility result will then be sent to the senior bank manager at the central office for approval. The app work finalization delay (\(g_{ndtb}^{j}\)) for non-DAO-based traditional banking applications is given by:

$$\begin{aligned} g_{ndtb}^{j}= & {} \sum _{j=1}^{y}(\delta _{udc}^{ndtb}+\delta _{udp}^{ndtb} +\delta _{udtm}^{ndtb}+\delta _{mp}^{ndtb}+\delta _{mtsm}^{ndtb}\nonumber \\{} & {} +\delta _{smp}^{ndtb}+\delta _{smtbm}^{ndtb}+\delta _{bmp}^{ndtb}+\delta _{bmtu}^{ndtb}+\delta _{udsp}^{ndtb}) \end{aligned}$$
(16)

\(\delta _{udc}^{ndtb}\) is the applicant user device connectivity delay regarding internet connectivity delay (similar as \(\delta _{utw}^{dvd}\)). \(\delta _{udp}^{ndtb}\) is the user device-based initial loan application data capture workload processing delay (\(\delta _{udp}^{ndtb}= \frac{L_{udp}^{ndtb}}{\mu _{su}^{j}}\)). \(\delta _{udtm}^{ndtb}\) is the applicant user device captured data offload delay to the local MEC server (\(\delta _{udtm}^{ndtb}=\frac{h_{udtm}^{ndtb}}{n_{fk}}*\alpha _{fk}+ \frac{h_{udtm}^{ndtb}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{mp}^{ndtb}\) is the MEC server-based offloaded bank loan application data processing delay (\(\delta _{mp}^{ndtb}= \frac{L_{mp}^{ndtb}}{\mu _{dw}^{j}}\)). \(\delta _{mtsm}^{ndtb}\) is the MEC processed banking application resultant data transfer delay to the senior manager device at head office (\(\delta _{mtsm}^{ndtb}=\frac{h_{mtsm}^{ndtb}}{n_{fk}}*\alpha _{fk}+ \frac{h_{mtsm}^{ndtb}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{smp}^{ndtb}\) is the bank senior manager device-based workload processing delay regarding final loan approval decision generation (\(\delta _{smp}^{ndtb}= \frac{L_{smp}^{ndtb}}{\mu _{su}^{j}}\)). \(\delta _{smtbm}^{ndtb}\) is the senior manager device processed bank loan application resultant data transfer delay to the branch manager (\(\delta _{smtbm}^{ndtb}=\frac{h_{smtbm}^{ndtb}}{n_{fk}}*\alpha _{fk}+ \frac{h_{smtbm}^{ndtb}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{bmp}^{ndtb}\) is the branch manager device-based workload processing delay (\(\delta _{bmp}^{ndtb}= \frac{L_{bmp}^{ndtb}}{\mu _{su}^{j}}\)). \(\delta _{bmtu}^{ndtb}\) is the branch manager device processed resultant bank loan application status data transfer delay to the user applicant device (\(\delta _{bmtu}^{ndtb}=\frac{h_{bmtu}^{ndtb}}{n_{fk}}*\alpha _{fk}+ \frac{h_{bmtu}^{ndtb}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{udsp}^{ndtb}\) is the user device-based workload processing delay regarding visualization of bank loan application result. (\(\delta _{udsp}^{ndtb}= \frac{L_{udsp}^{ndtb}}{\mu _{su}^{j}}\)).

Next, this article will calculate the app work finalization delay for non-DAO-based remote surveillance application. In this application, a video camera device at the task location sends task data to the MEC server. The MEC-processed result will be sent to the human worker device. A human worker device verifies the remote surveillance results from the MEC-dispatched data. Finally, the task result will be sent to the host user device. The app work finalization delay (\(g_{ndrm}^{j}\)) for non-DAO-based traditional remote surveillance applications is delivered by:

$$\begin{aligned} g_{ndrm}^{j}= & {} \sum _{j=1}^{y}(\delta _{udc}^{ndrm}+\delta _{udp}^{ndrm} +\delta _{udtm}^{ndrm}+\delta _{mp}^{ndrm}\nonumber \\{} & {} +\delta _{mthw}^{ndrm}+\delta _{hwp}^{ndrm}+\delta _{hwtu}^{ndrm}+\delta _{udsp}^{ndrm}) \end{aligned}$$
(17)

\(\delta _{udc}^{ndrm}\) is the user device internet connectivity (similar to \(\delta _{utw}^{dvd}\)). \(\delta _{udp}^{ndrm}\) is the video camera-based initial workload processing delay regarding image capturing work (\(\delta _{udp}^{ndrm}= \frac{L_{udp}^{ndrm}}{\mu _{su}^{j}}\)). \(\delta _{udtm}^{ndrm}\) is the video camera device captured data offload delay to the local MEC server (\(\delta _{udtm}^{ndrm}=\frac{h_{udtm}^{ndrm}}{n_{fk}}*\alpha _{fk}+ \frac{h_{udtm}^{ndrm}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{mp}^{ndrm}\) is the MEC server-based offloaded video camera captured data processing delay (\(\delta _{mp}^{ndrm}= \frac{L_{mp}^{ndrm}}{\mu _{dw}^{j}}\)). \(\delta _{mthw}^{ndrm}\) is the MEC-processed remote surveillance resultant data transfer delay to the human worker device (\(\delta _{mthw}^{ndrm}=\frac{h_{mthw}^{ndrm}}{n_{fk}}*\alpha _{fk}+ \frac{h_{mthw}^{ndrm}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{hwp}^{ndrm}\) is the human worker device-based workload processing delay regarding remote surveillance final decision generation (\(\delta _{hwp}^{ndrm}= \frac{L_{hwp}^{ndrm}}{\mu _{su}^{j}}\)). \(\delta _{hwtu}^{ndrm}\) is the resultant data transfer delay to the host applicant’s user device (\(\delta _{hwtu}^{ndrm}=\frac{h_{hwtu}^{ndrm}}{n_{fk}}*\alpha _{fk}+ \frac{h_{hwtu}^{ndrm}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{udsp}^{ndrm}\) is the host-user device-based workload processing delay regarding visualization of application result (\(\delta _{udsp}^{ndrm}= \frac{L_{udsp}^{ndrm}}{\mu _{su}^{j}}\)).

Finally, this paper will calculate the app work completion delay for non-DAO-based doctor prescription generation applications. In this application, the user’s device sends health-related data to the MEC server. The MEC-processed result will then be sent to the specialized doctor’s device. The specialized doctor device validates the MEC-processed results. Finally, the doctor’s prescription results will be transmitted from the doctor’s device to the host user’s device. The app work finalization delay (\(g_{nddp}^{j}\)) for non-DAO-based doctor prescriptions with healthcare applications is devised by:

$$\begin{aligned} g_{nddp}^{j}= & {} \sum _{j=1}^{y}(\delta _{udc}^{nddp}+\delta _{udp}^{nddp} +\delta _{udtm}^{nddp}+\delta _{mp}^{nddp}\nonumber \\{} & {} +\delta _{mtdd}^{nddp}+\delta _{ddp}^{nddp}+\delta _{ddtu}^{nddp}+\delta _{udsp}^{nddp}) \end{aligned}$$
(18)

\(\delta _{udc}^{nddp}\) is the user device internet connectivity delay. (similar to \(\delta _{utw}^{dvd}\)). \(\delta _{udp}^{nddp}\) is the user device-based initial workload processing delay regarding healthcare data collection (\(\delta _{udp}^{nddp}= \frac{L_{udp}^{nddp}}{\mu _{su}^{j}}\)). \(\delta _{udtm}^{nddp}\) is the user device captured health-related data offload delay to the local MEC server (\(\delta _{udtm}^{nddp}=\frac{h_{udtm}^{nddp}}{n_{fk}}*\alpha _{fk}+ \frac{h_{udtm}^{nddp}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{mp}^{nddp}\) is the MEC server-based health-related data processing delay (\(\delta _{mp}^{nddp}= \frac{L_{mp}^{nddp}}{\mu _{dw}^{j}}\)). \(\delta _{mtdd}^{nddp}\) is the MEC processed resultant data transfer delay to the specialized doctor (\(\delta _{mtdd}^{nddp}=\frac{h_{mtdd}^{nddp}}{n_{fk}}*\alpha _{fk}+ \frac{h_{mtdd}^{nddp}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{ddp}^{nddp}\) is the doctor device-based workload processing delay regarding final healthcare and prescription decision generation (\(\delta _{ddp}^{nddp}= \frac{L_{ddp}^{nddp}}{\mu _{su}^{j}}\)). \(\delta _{ddtu}^{nddp}\) is the doctor device processed healthcare prescription application resultant data transfer delay to the host user device (\(\delta _{ddtu}^{nddp}=\frac{h_{ddtu}^{nddp}}{n_{fk}}*\alpha _{fk}+ \frac{h_{ddtu}^{nddp}}{n_{wk}}*\alpha _{wk}+g_{po}^{j}+g_{wo}^{j}\)). \(\delta _{udsp}^{nddp}\) is the host user device-based workload processing delay regarding visualization of application results. (\(\delta _{udsp}^{nddp}= \frac{L_{udsp}^{nddp}}{\mu _{su}^{j}}\)). The parameters used in the evaluation process in indicated in Tables 1.

4.2 Economic Charges for Users

The economic charges for users during DAO and non-DAO-based application execution (\(K_{ufc}^{j}\)) include bandwidth resource usage cost, digital device resource usage cost (cloud server, web server, blockchain server, third party server), physical or personal device resource usage cost, and finance cost during waiting latency for application execution.

\(K_{ufc}^{j}\) is delineated by:

$$\begin{aligned} K_{ufc}^{j}= & {} \sum _{j=1}^{y_{do}}u_{pdr}^{j}*\delta _{pd}^{j}+\sum _{j=1}^{y_{do}}u_{br}^{j} *(\delta _{at}^{j}+\delta _{ar}^{j})\nonumber \\{} & {} +\sum _{j=1}^{y_{do}}u_{ddr}^{j}*(\delta _{ws}^{j}+\delta _{cs}^{j}+\delta _{bcw}^{j} +\delta _{tps}^{j})+\sum _{j=1}^{y_{do}}u_{wl}^{j}*\delta _{wr}^{j}\nonumber \\{} & {} +\sum _{j=1}^{y_{nd}}u_{pdr}^{j}*\delta _{pd}^{j}+\sum _{j=1}^{y_{nd}}u_{br}^{j} *(\delta _{at}^{j}+\delta _{ar}^{j})\nonumber \\{} & {} +\sum _{j=1}^{y_{nd}}u_{ddr}^{j}*(\delta _{ws}^{j}+\delta _{cs}^{j}+\delta _{bcw}^{j} +\delta _{tps}^{j})+\sum _{j=1}^{y_{nd}}u_{wl}^{j}*\delta _{wr}^{j} \end{aligned}$$
(19)

where \(y_{do}\) is the total DAO application execution request count. \(y_{nd}\) is the total non-DAO application request count. The total DAO and non-DAO application count is y=\(y_{do}\)+\(y_{nd}\). \(u_{pdr}^{j}\), \(u_{br}^{j}\), \(u_{ddr}^{j}\), and \(u_{wl}^{j}\) are average/per millisecond economic expense costs for physical/user device-based resource usage for application execution (e.g., user device, manager device, doctor device, video sensor device), bandwidth resource usage for data transfer/receive work, digital device-based resource usage for application execution (e.g., cloud server, web server, blockchain server, third party server), and resource/app execution waiting overhead, respectively. \(\delta _{pd}^{j}\), \(\delta _{at}^{j}/\delta _{ar}^{j}\), \(\delta _{ws}^{j}, \delta _{cs}^{j}, \delta _{bcw}^{j}, \delta _{tps}^{j}\), and \(\delta _{wr}^{j}\) are the associated time delays regarding physical device-based app work execution, communication delay that includes transmission/receive operation, digital worker time delay for (web server, cloud server, blockchain device, third party server) DAO and non-DAO application work processing, and waiting latency overhead during DAO and non-DAO-based application execution, respectively.

4.3 Total Acquired Throughput

The acquired throughput value can be devised by taking the ratio value of the exchanged data amount (for both DAO and non-DAO-based application execution) and the last application execution time value (i.e., makespan time delay).

\(B_{att}^{j}\) is acquired by: \(B_{att}^{j}=\frac{\sum _{j=1}^{y_{do}}(h_{id}^{j}+h_{rd}^{j})+\sum _{j=1}^{y_{nd}}(h_{rd}^{j}+h_{id}^{j})}{\sum _{j=1}^{y}g_{lacd}^{j}}\).Where \(g_{lacd}^{j}\) is the last application execution time value (i.e., makespan delay).

\(g_{lacd}^{j}\)=max{\(g_{acdl}^{1}, g_{acdl}^{2},..g_{acdl}^{y}\)}, \(j\) \(\in 1,2,..y\). y is the total DAO and non-DAO application count value. \(g_{acdl}^{j}\) is the application work completion and result supply delay for different DAO and non-DAO applications. \(h_{id}^{j}\), \(h_{rd}^{j}\), \(y_{do}\), and \(y_{nd}\) are the exchanged applications input data size, resultant data size, total DAO application,and non-DAO application value, respectively.

4.4 Service Deployer and Supplier Surplus Value

The service deployer and supplier surplus (\(K_{ssv}^{j}\)=\(K_{ufc}^{j}\)-\(K_{ssc}^{j}\)) can be delineated by taking the difference between the service supplier’s own service deployment cost (\(K_{ssc}^{j}\)) and collected revenue from the DAO and non-DAO application service takers (\(K_{ufc}^{j}\)). The revenue value computation process is delivered in 4.2. The service deployment cost (\(K_{ssc}^{j}\)) for service suppliers and providers (that includes the resource purchase cost, service deployment cost, and service maintenance cost) for multiple DAO and non-DAO-based application executions is assessed by:

$$\begin{aligned} K_{ssc}^{j}= & {} \sum _{j=1}^{y_{do}}v_{ddr}^{j}*(\delta _{ws}^{j}+\delta _{cs}^{j} +\delta _{bcw}^{j}+\delta _{tps}^{j})\nonumber \\{} & {} +\sum _{j=1}^{y_{do}}v_{wl}^{j}*\delta _{wr}^{j}+\sum _{j=1}^{y_{do}}v_{pdr}^{j}*\delta _{pd}^{j} +\sum _{j=1}^{y_{do}}v_{br}^{j}*(\delta _{at}^{j}+\delta _{ar}^{j})\nonumber \\{} & {} +\sum _{j=1}^{y_{nd}}v_{pdr}^{j}*\delta _{pd}^{j}+\sum _{j=1}^{y_{nd}}v_{br}^{j} *(\delta _{at}^{j}+\delta _{ar}^{j})\nonumber \\{} & {} +\sum _{j=1}^{y_{nd}}v_{ddr}^{j}*(\delta _{ws}^{j}+\delta _{cs}^{j}+\delta _{bcw}^{j} +\delta _{tps}^{j})+\sum _{j=1}^{y_{nd}}v_{wl}^{j}*\delta _{wr}^{j} \end{aligned}$$
(20)

where \(y_{do}\) is the total DAO application execution request. \(y_{nd}\) is the total non-DAO application request. \(v_{pdr}^{j}\), \(v_{br}^{j}\), \(v_{ddr}^{j}\), and \(v_{wl}^{j}\) are service deployers/suppliers average (per milisecond) financial cost for physical/user device-based resource usage (e.g., user device, manager device, doctor device, video sensor device), bandwidth resource usage, digital device-based resource usage (e.g., cloud server, web server, blockchain server, third party server), and resource/application execution waiting overhead, respectively. \(\delta _{pd}^{j}\), \(\delta _{at}^{j}/\delta _{ar}^{j}\), \(\delta _{ws}^{j}, \delta _{cs}^{j}, \delta _{bcw}^{j}, \delta _{tps}^{j}\), and \(\delta _{wr}^{j}\) are the time delays regarding physical device-based app work processing, data transmission/receive operation-based communication delay, digital worker time delay for (web server, cloud server, blockchain device, third party server) DAO and non-DAO application work processing, and waiting latency overhead during DAO and non-DAO-based application execution, respectively.

4.5 Demand Realization Ratio for Users

The DAO and non-DAO application execution demand realization ratio is captured by obtaining the ratio results between the total (DAO and non-DAO) successful application that realizes the application time budget limit and the total user application count that arrives for execution. The demand realization ratio for user application execution \(Z_{udrr}^{j}\) is examined by: \(Z_{udrr}^{j}=\frac{\sum _{j=1}^{y_{do}} \gamma _{tsa}^{j}+\sum _{j=1}^{y_{nd}} \gamma _{tsa}^{j}}{\sum _{j=1}^{y}n_{ta}^{j}}\). Where \(\gamma _{tsa}^{j}\) is the successful DAO/non-DAO application value that realizes the application time budget limit. \(n_{ta}^{j}\) is the total DAO and non-DAO application number (\(n_{ta}^{j}=y_{do}+y_{nd}\)).

4.6 Users Total Energy Overhead

The energy overhead for host user devices regarding both DAO and non-DAO application execution (\(Q_{eo}^{j}\)) can be investigated by taking the users energy overhead during both DAO and non-DAO application data transfer/reception activities, physical or personal device-based application work processing delay (by different user devices/manager devices/doctors/robots/video sensor devices), digital device-based application work processing delay (by cloud server/web server/blockchain device/third party server), and waiting latency associated with application work completion/resource access operation. \(Q_{eo}^{j}\) is investigated by:

$$\begin{aligned} Q_{eo}^{j}= & {} \sum _{j=1}^{y_{do}}f_{pd}^{j}*\delta _{pd}^{j}+\sum _{j=1}^{y_{do}}f_{at}^{j}*\delta _{at}^{j} +f_{ar}^{j}*\delta _{ar}^{j}\nonumber \\{} & {} +\sum _{j=1}^{y_{do}}f_{dd}^{j}*(\delta _{ws}^{j}+\delta _{cs}^{j}+\delta _{bcw}^{j}+\delta _{tps}^{j}) +\sum _{j=1}^{y_{do}}f_{wr}^{j}*\delta _{wr}^{j}\nonumber \\{} & {} +\sum _{j=1}^{y_{nd}}f_{pd}^{j}*\delta _{pd}^{j}+\sum _{j=1}^{y_{nd}}f_{at}^{j}*\delta _{at}^{j} +f_{ar}^{j}*\delta _{ar}^{j}\nonumber \\{} & {} +\sum _{j=1}^{y_{nd}}f_{dd}^{j}*(\delta _{ws}^{j}+\delta _{cs}^{j}+\delta _{bcw}^{j}+\delta _{tps}^{j}) +\sum _{j=1}^{y_{nd}}f_{wr}^{j}*\delta _{wr}^{j} \end{aligned}$$
(21)

The total DAO and non-DAO application count is y=\(y_{do}\)+\(y_{nd}\). \(f_{pd}^{j}\), \(f_{at}^{j}\), \(f_{ar}^{j}\), \(f_{dd}^{j}\), and \(f_{wr}^{j}\) are average/per milisecond energy overhead costs for physical/user device-based application work processing, application data transfer/receive work, digital device-based work processing, and waiting latency overhead delay, respectively. \(\delta _{pd}^{j}\), \(\delta _{at}^{j}/\delta _{ar}^{j}\), \(\delta _{ws}^{j}, \delta _{cs}^{j}, \delta _{bcw}^{j}, \delta _{tps}^{j}\), and \(\delta _{wr}^{j}\) are the associated time delays for physical device-based app work execution, communication delays that include transmission and receive operations, digital worker time delays for web servers, cloud servers, blockchain devices, third-party server-based DAO and non-DAO application work processing, and waiting latency overhead during DAO and non-DAO-based application execution.

4.7 Acquired Benefit Ratio

The acquired total benefit ratio for users (\(\sigma _{br}^{j}\)) is measured by summing up the application work completion delay gain, economic gain, and energy overhead gain. \(\sigma _{br}^{j}\) is captured by:

$$\begin{aligned} \sigma _{br}^{j}= & {} \sum _{j=1}^{y_{do}+y_{nd}} \sigma _{dg}^{j}+\sigma _{egg}^{j}+\sigma _{eog}^{j}= \frac{\sum _{j=1}^{y_{do}+y_{nd}}g_{tbd}^{j}-g_{lacd}^{j}}{\sum _{j=1}^{y_{do}+y_{nd}}g_{tbd}^{j}}\nonumber \\{} & {} +\frac{\sum _{j=1}^{y_{do}+y_{nd}}K_{tfb}^{j}-K_{ufc}^{j}}{\sum _{j=1}^{y_{do}+y_{nd}}K_{tfb}^{j}}+ \frac{\sum _{j=1}^{y_{do}+y_{nd}}Q_{teb}^{j}-Q_{eo}^{j}}{\sum _{j=1}^{y_{do}+y_{nd}}Q_{teb}^{j}} \end{aligned}$$
(22)

where \(g_{lacd}^{j}\), \(K_{ufc}^{j}\), and \(Q_{eo}^{j}\) are the required delay values for las- arrived DAO and non-DAO application execution, the, required economic charges for users, and the, required energy overhead for users regarding DAO and non-DAO application execution in the proposed kaizen scheme, respectively.

\(g_{tbd}^{j}\), \(K_{tfb}^{j}\), and \(Q_{teb}^{j}\) are the time budget limit for users, the economic budget limit for users, and the energy budget limit for users regarding DAO and non-DAO application execution in the proposed kaizen scheme, respectively.

4.8 Average Prevailing Power Value for Users

The average prevailing power value for users \(\gamma _{pv}^{r}\) is computed by dividing the total prevailing power of users by the total user device. The total prevailing power of users can be determined by measuring the difference between the total energy summation value of all user devices at the initiation of the simulation and the total energy used by users after the completion of the application in different simulation rounds.

\(\gamma _{pv}^{r}\) is investigated by:

\(\gamma _{pv}^{r}= \frac{\sum _{r=1}^{s_{t}}\sum _{j=1}^{y} Q_{pve}^{j}-Q_{ueu}^{j}}{\sum _{r=1}^{s_{t}} z_{tu}}\). \(Q_{pve}^{j}\) is the summation of initial power values for all users (\(Q_{pve}^{j}=z_{tu}*P_{te}\)). Where \(z_{tu}\) and \(P_{te}\) are the total user participants in the network and the total initial battery power for each user device, respectively. \(s_{t}\) is the total simulation instance count. \(Q_{ueu}^{j}\) is the used power values for different DAO and non-DAO application execution after the completion of different numbers of simulation rounds (\(Q_{ueu}^{j}=r*j*Q_{eou}^{j}\)), where r is the simulation instance/round total, j is the total executed DAO and non-DAO application count in a simulation instance, and \(Q_{eou}^{j}\) is the average energy spent per user in a round for different application execution.

4.9 Network Existence Time Value

The network existence time value \(\lambda _{netv}^{i}\) can be deduced by dividing the total available energy value of users by the total required energy value for a simulation instance involving different DAO and non-DAO application executions.

\(\lambda _{netv}^{i}\) is delivered by:

\(\lambda _{netv}^{i}= \frac{\sum _{i=1}^{z_{tu}}Q_{pve}^{i}}{\sum _{i=1}^{z_{tu}}\sum _{j=1}^{y} Q_{ueu}^{j}}\). where \(Q_{pve}^{i}\) is the summation of total power for all user devices in the network. \(z_{tu}\) is the total user device in the network. \(Q_{ueu}^{j}\) is the energy overhead cost for users due to DAO and non-DAO application execution in a round/simulation instance.

4.10 Prevailing User Percentage

The prevailing user percentage value (\(\chi _{pur}^{r}\)) is calculated by dividing the total active user device by the total participant user device in the network.

\(\chi _{pur}^{r}\) is measured by:

\(\chi _{pur}^{r}= \frac{\sum _{r=1}^{s_{t}}z_{tu}-z_{nau}^{r}}{\sum _{r=1}^{s_{t}} z_{tu}}\). where r is the simulation instance value. \(z_{tu}\) and \(z_{nau}^{r}\) are the total participant user devices in the network (after network formation) and non-active users (who do not have any sufficient energy to operate or die) after the end of any application execution round.

Table 1 Necessary parameters for simulation
Full size table

5 Simulation Results and Analysis

In the fifth section, we compared the proposed Kaizen scheme (LLRF+MPC+MPD+MWD+MCD) to two existing schemes. The proposed kaizen scheme is based on a low-latency application first-serve-based scheduling scheme (LLRF) as well as multiple platform coordination or MPC (blockchain, DAO, MEC, third-party server) and predicted low application work completion delay (includes minimum processing delay or MPD, waiting delay or MWD, communication delay or MCD) based resource/worker allocation per application. The compared schemes are existing scheme one (NSF+MCL) and existing scheme two (HPSF+NIBS). The compared scheme one (NSF+MCL) includes not only nearest resource node, worker, or server (NSF) selection with minimum communication latency (MCL) for DAO and non-DAO application execution, but also an early arrival-based scheduling order (e.g., [18, 53, 56, 57]). The existing compared scheme two (HPSF+NIBS) employs both the highest processing power (HPSF)-based worker selection and the non-intentional/random basis scheduling order (NIBS) for multiple DAO/non-DAO application scheduling (e.g., [21, 25, 52, 54, 55]).

This paper analyzes the performance of the following DAO applications: crowdfunding DAO, decentralized voting DAO, cryto-loan DAO, social club DAO, NFT saling DAO, rent NFT DAO, and coin swapping DAO. Furthermore, the non-DAO applications under consideration include remote monitoring, traditional centralized banking-based loan applications, retail chaining-based applications, and doctor-prescription-based application execution. We used MATLAB and Python software for simulation. The number of DAO and non-DAO applications is chosen at random from the range of 11 to 88. In this paper, the numbers of local DAO-enhanced MEC servers, local blockchain devices, local web servers, local third-party servers, and remote cloud servers are 3, 3, 3, and 4, respectively. The input and output data amounts for DAO and non-DAO applications are verified within 4 KB and 10 MB, respectively. The workload (CPU cycles/bit) for each physical device (user device, robot, video camera, mobile phone, manager, and doctor device) and virtual or digital device/worker (blockchain, MEC server) is verified within a 5–1000 CPU range. The time budget or deadline limit for DAO and non-DAO application execution is verified in 780 ms and 28,800 ms, respectively. Table 1 provide specific simulation parameters and values for various DAO and non-DAO applications.

Fig. 3
figure 3

Avg. app work completion delay and economic charges for users

Full size image
Fig. 4
figure 4

Total energy overhead and service supplier surplus

Full size image
Fig. 5
figure 5

User demand realization ratio and acquired throughput

Full size image
Fig. 6
figure 6

Prevailing power and network existence time

Full size image
Fig. 7
figure 7

Prevailing user ratio and acquired benefit ratio

Full size image

Figure 3a visualizes the impact of the total amount of DAO and non-DAO application request execution on the average application work completion and result dispatch delay (AAWCD). In the simulation, the total number of apps ranged from 11 to 88. From Fig. 3a, it is shown that as the total executed amount of DAO and non-DAO applications grows, the average app work completion delay (AAWCD) also rises. Another observation from Fig. 3a is that the average app work completion delay (AAWCD) is lower in the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD) compared to the compared scheme first (NSF+MCL) and compared scheme second (HPSF+NIBS). The reason for this is that the resource choreographer node in the proposed Kaizen scheme schedules multiple DAO and non-DAO applications based on the low-latency requirement application first serve basis (LLRF). The proposed Kaizen scheme also provides multi-platform (blockchain, web server, and third-party wallet service) coordination (MPC) and computes associated delays before resource scheduling for applications. The proposed Kaizen scheme selects the finest resource (server, worker, bandwidth, or cloud resource) that provides the minimum workload processing delay (MPD), minimum waiting delay (MWD), and communication delay (MCD) for each DAO- and non-DAO-based application. Another observation is that the compared schemes first (NSF+MCL) and second (HPSF+NIBS) have the second lowest and highest average app work completion delays (AAWCD), respectively. The primary reason for this reasoning is that the compared scheme first (NSF+MCL) attempts to select the nearest resource node, worker, or server (NSF) for DAO and non-DAO application execution with the lowest communication latency (MCL). As a result, the compared scheme first (NSF+MCL) uses a chronological or early arrival-based scheduling order. As a result, the second scheme (HPSF+NIBS) attempts to select resource nodes/workers/servers for DAO and non-DAO application execution based on their maximum work processing power (HPSF). Furthermore, the second compared scheme (HPSF+NIBS) uses non-intentional or random basis order (NIBS) to schedule multiple applications. Thus, the compared schemes first (NSF+MCL) and second (HPSF+NIBS) have longer waiting and work processing times than the proposed Kaizen scheme. Figure 3a shows that when the number of DAO and non-DAO apps is 66, the average app work completion delay (AAWCD) for the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD), compared scheme first (NSF+MCL), and compared scheme second (HPSF+NIBS) is 6646 ms, 7740 ms, and 8585 ms, respectively.

Figure 3b depicts how the total number of apps affects users’ economic charges. Users in this work must pay economic charges due to differences in DAO and non-DAO application execution and resource usage. Figure 3b shows that the economic charges for different application executions rise in all three compared schemes as the number of DAO and non-DAO application executions grows. Figure 3b shows that the proposed kaizen scheme has lower economic charges than both schemes one and two. The primary reason is that the proposed Kaizen scheme has a low resource utilization time due to a short application work completion delay. The compared scheme (NSF+MCL) has the second lowest economic charges due to the second shortest resource utilization time (i.e., application work completion delay). The compared scheme second (HPSF+NIBS) incurs the highest economic costs due to the longest application work completion delay and resource utilization time. From Fig. 3b, it can be highlighted that, when the DAO and non-DAO app numbers are 88, the users economic charges for the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD), compared scheme first (NSF+MCL), and compared scheme second (HPSF+NIBS) are 7766 USD, 8275 USD, and 8542 USD, respectively. From the results, it can be seen that the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD) achieves 6.55% and 10% users economic charge gain than the compared scheme first (NSF+MCL) and compared scheme second (HPSF+NIBS), respectively. The economic charge gain is calculated by dividing the economic charge difference value (between the compared scheme and the proposed scheme) by the economic charge value of our proposed scheme.

Figure 4a shows the total user energy overhead results for various schemes as a function of application number. Figure 4a shows that the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD) outperforms the compared schemes first (NSF+MCL) and second (HPSF+NIBS) in terms of lower energy overhead or expense for various DAO and non-DAO application executions. Figure 4a shows that the large number of DAO and non-DAO applications results in a significant energy overhead in all compared schemes, despite their low application amounts. The proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD) reduces energy overhead by shortening the application work completion time. The compared scheme (NSF+MCL) has the second lowest energy overhead for various application work completion tasks (e.g., data transfer, receive, idle listening, local user device-based work processing). The compared scheme second (HPSF+NIBS) has the highest energy overhead during various application work completion tasks (e.g., data transfer, receive, idle listening, local user device-based work processing). Figure 4a shows that, with 88 DAO and non-DAO application numbers, the total user energy overhead for the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD), compared scheme first (NSF+MCL), and compared scheme second (HPSF+NIBS) are 8073 mJ, 8655 mJ, and 8965 mJ, respectively. Thus, the results indicated that the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD) achieves 7.20% and 11.04% more users energy overhead gain than the compared scheme first (NSF+MCL) and compared scheme second (HPSF+NIBS), respectively.

Figure 4b illustrates the experimental results for service deployer and supplier surplus (i.e., service provider profit) as a function of total DAO and non-DAO app numbers. The service deployer/supplier surplus (service provider profit) is calculated as the difference between the service deployer/supplier revenue from users and the service deployer/supplier cost (for resource purchases and service maintenance). Figure 4b shows that the proposed Kaizen scheme (LLRF+MPC+MPD+MWD+MCD) has the highest surplus among service deployers/suppliers. In terms of service deployer/supplier surplus amount, the compared scheme first (NSF+MCL) and second (HPSF+NIBS) ranked second and third, respectively. This is obvious because the proposed Kaizen scheme has the lowest additional waiting latency (service deployer/supplier-associated additional resource service delivery cost) when compared to the NSF+MCL scheme (compared first) and the HPSF+NIBS scheme (compared second). From Fig. 4b, it is seen that, when the DAO and non-DAO app number is 88, the service deployer/supplier surplus (profit) for the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD), compared scheme first (NSF+MCL), and compared scheme second (HPSF+NIBS) are 2150 USD, 1777 USD, and 1589 USD, respectively. From the results, it can be seen that the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD) offers 21% and 35.30% service deployer/supplier surplus gain (or service provider profit gain) than the compared scheme first (NSF+MCL) and compared scheme second (HPSF+NIBS), respectively.

Figure 5a depicts the results of the user demand realization ratio versus the time budget limit (for different compared schemes). The user demand realization ratio is calculated by dividing the number of application executions that meet the given time budget criteria by the total number of applications that need to be executed. Figure 5(a) shows that the proposed Kaizen scheme (LLRF+MPC+MPD+MWD+MCD) achieves a higher user demand realization ratio than others. The proposed Kaizen scheme (LLRF+MPC+MPD+MWD+MCD) achieves the shortest application work completion delay. As a result of their second-lowest application work completion delay, the user demand realization ratio is the second lowest in the compared scheme (NSF+MCL). The user demand realization ratio is lowest in the compared scheme second (HPSF+NIBS) due to the longest application work completion delay. From Fig. 5a, it is hinted that, when the app execution time budget or limit is 17,000 ms, the user demand realization ratios for the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD), compared scheme first (NSF+MCL), and compared scheme second (HPSF+NIBS) are 74%, 65%, and 60%, respectively.

Figure 5b presents the acquired throughput results as a function of the exchanged data amount or application data quantity. The acquired throughput result is calculated by dividing the makespan delay associated with the application execution by the total data exchange amount or application data quantity. A larger amount of delivered application data increases throughput in any scheme compared to smaller counterparts. The proposed kaizen scheme has the highest acquired throughput value because it has a lower makespan delay. In contrast, the makespan delay is second largest in the compared scheme first (NSF+MCL), and highest in the compared scheme second (HPSF+NIBS). Thus, the acquired throughput value is the second largest in the compared scheme (NSF+MCL) and the smallest in the second scheme (HPSF+NIBS). Figure 5b notifies that when the app data quantity is 43.2 MB, the acquired throughput values for the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD), compared scheme first (NSF+MCL), and compared scheme second (HPSF+NIBS) are 4.85 Mbps, 4.65 Mbps, and 4.4 Mbps, respectively.

The performance comparison results outcome regarding users average prevailing power versus application processing simulation cycle is depicted in Fig. 6a. User prevailing power is calculated as the difference between total user power at the start of a round and total consumed power. The average user’s prevailing power is calculated by dividing the total remaining power of all users by the total number of users. Figure 6a shows that the prevailing power of users decreases in all compared schemes as the finished application execution simulation cycle value increases. This is obvious, because a longer simulation cycle results in a greater number of DAO and non-DAO application executions, as well as higher energy costs for users. As a result, the proposed Kaizen scheme shows the greatest amount of user prevailing power when compared to the first (NSF+MCL) and the second (HPSF+NIBS). The outcome is clear, as the user’s energy overhead for various DAO and non-DAO applications is lowest in the proposed Kaizen scheme, second lowest in the compared scheme first (NSF+MCL), and third lowest in the compared scheme second (HPSF+NIBS). Figure 6a hints that, when the finished simulation cycle or round is 1200 and the total finished app per cycle is 22, the users’ average prevailing power for the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD), compared scheme first (NSF+MCL), and compared scheme second (HPSF+NIBS) are 355 mJ, 241 mJ, and 145 mJ, respectively.

Figure 6b delivers the results of network existence time values for various schemes versus total application execution per cycle. The network existence time value indicates how many simulation rounds the network will exist (users with sufficient energy value for app execution) given the various number of application executions in a round. The figure shows that as the number of application executions per simulation cycle increases, the network existence time (round) decreases. It is clear that, due to the lower cost of energy for application execution, the network existence round value (with users having enough energy value for varying amounts of application execution) is the most important in the proposed kaizen scheme. As a result, the network existence round value (with users having enough energy for various amounts of application execution) is the second lowest in the compared scheme (NSF+MCL) due to the second highest energy overhead for various application executions. The compared scheme second (HPSF+NIBS) has the lowest network existence value (round) due to poor energy overhead performance for multiple DAO and non-DAO application executions. Figure 6b shows that, when the total number of DAO and non-DAO applications completed in a round is 88 and the total number of user devices is 400, the network existence time value (number of simulation rounds) for the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD), compared scheme first (NSF+MCL), and compared scheme second (HPSF+NIBS) are 123, 115, and 111, respectively.

Figure 7a compares the performance results for the current user ratio by varying the total application execution per simulation cycle. The figure shows that the prevailing user ratio decreases in all schemes as the total number of applications executed per round increases. The prevailing user ratio is calculated as the ratio of total fit user devices with sufficient energy remaining for app execution to the total number of user devices at the start of the simulation cycle (including both fit and dead user devices). The proposed kaizen scheme has fewer dead user devices because the energy cost burden for each round-based application execution is lowest. Thus, the proposed kaizen scheme achieves the highest prevailing user ratio when compared to the first compared scheme (NSF+MCL) and the second compared scheme (HPSF+NIBS). The figure shows that the number of non-fit or dead user devices for each round-based application execution is second-lowest in the first scheme (NSF+MCL) and highest in the second scheme (HPSF+NIBS). As a result, the first compared scheme (NSF+MCL) has a second-best prevailing user ratio, while the second compared scheme (HPSF+NIBS) has the lowest. Figure 7a visualizes that when the total app execution cycle or round is 1000 and the total executed app count is 22, the prevailing user ratios for the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD), the compared scheme first (NSF+MCL), and the compared scheme second (HPSF+NIBS) are 30%, 25%, and 20%, respectively.

Figure 7b renders the acquired benefit ratio results for the users versus total DAO and non-DAO application execution quantities. The acquired benefit ratio for users under different schemes is delivered by including application work completion delay gain ratio, user energy overhead gain ratio, and user economic charges gain ratio. Figure 7b deduces that the acquired benefit ratio grows with the raising values of total completed DAO and non-DAO application quantity. As the delay gain, energy overhead gain, and economic charges gain are top-most in the proposed scheme, the proposed Kaizen scheme delivers the highest total acquired benefit ratio of all the compared schemes. The work completion delay gain, energy overhead gain, and economic charge gain are the second lowest in the compared scheme first (NSF+MCL), resulting in the second highest acquired total benefit ratio. The compared scheme second (HPSF+NIBS) has the lowest work completion delay gain, energy overhead gain, and economic charges gain, resulting in the lowest acquired total benefit ratio among the other schemes. Figure 7b deduces that, when the total number of executed apps is 66, the acquired benefit ratios for the proposed kaizen scheme (LLRF+MPC+MPD+MWD+MCD), the compared scheme first (NSF+MCL), and the compared scheme second (HPSF+NIBS) are 1.07, 0.72, and 0.48, respectively.

6 Conclusion

In this work, a street smart multi-platform coordination and low-latency-aware resource choreography scheme is presented for multiple decentralized autonomous organization (DAO) and non-DAO-based application execution over blockchain and the MEC-enabled 6 G network by investigating heterogeneous resources, heterogenous DAO and non-DAO application types, data sizes, workloads, and application requirements. In this article, different types of physical device resources (e.g., user device), communication resources, and digital worker resources (cloud server, DAO server, third party server, and block chain device) are selected for different DAO and non-DAO application execution by evaluating the minimum predicted application work completion and result supply delay among all available resources. For the first time, this paper examines the work completion delay, user energy, and economic charge performance of various DAO applications and non-DAO application execution. This article also presented a suitable application resource scheduling scheme and a proper 6 G network model for multiple DAO and non-DAO application executions, taking into account various user device types, physical and virtual resource types, multiple platforms, and user priority. This paper presents a mathematical model for computing the performance of the proposed Kaizen scheme. The simulation results show that for the total executed DAO and non-DAO applications of 88, the proposed Kaizen scheme experiences 11.26% app work completion delay gain, 7.20% users energy overhead gain, 6.55% users economic charges gain, and 20.99% service deployer/provider surplus gain than the compared scheme (NSF+MCL). The simulation results revealed that for the total executed DAO and non-DAO applications of 88, the proposed kaizen scheme experiences 21.14% app work completion delay gain, 11.04% users energy overhead gain, 10.0% users economic charges gain, and 35.30% service deployer/provider surplus gain than the compared scheme (HPSF+NIBS). However, there are still some challenges that need to be addressed in the future, such as the prediction of DAO and non-DAO application arrivals using machine learning, deep learning-based congestion control, age of information (AoI), virtualization, and semantic communication-aware packet and resource scheduling schemes, more advanced privacy enhancement techniques using quantum cryptography.