Promoting the Sustainability of Blockchain in Web 3.0 and the Metaverse Through Diversified Incentive Mechanism Design

This article explores the role of blockchains in the development of Web 3.0 and the Metaverse. The success of these technologies is dependent on the utilization of decentralized systems like blockchains, which can store and validate data on identities and reputations and facilitate the exchange of virtual assets. Full nodes, which store the entire blockchain state and validate all transactions, are essential for the decentralization and reliability of the network. However, operating a full node is resource-intensive and can be expensive. To tackle this challenge, we propose an incentive mechanism that utilizes contract-theoretic methods to economically motivate users to support the sustainability and growth of the blockchain network. Our contract design addresses the problem of information asymmetry (e.g., users' revenue-generating capabilities and efforts) between users and the blockchain network. Additionally, we recommend providing diverse incentives based on the user's revenue-generating capabilities and efforts to assist the blockchain network in funding incentives. Our experimental results demonstrate that our proposed mechanism increases the blockchain network's utility by $48.48\%-54.52\%$ and reduces the users' cost by $38.46\%-62.5\%$ compared with the state-of-the-art implementations such as Celo, Vipnode, and Pocket Network.

nodes in the cloud, not including electricity or internet use [5].
As the cost of maintaining a complete state of the blockchain increases, many users migrate to light node implementations, which require only minimal resources. However, light node implementations have their limitations, as they depend on full nodes for initial synchronization and blockchain state verification, which raises concerns about centralization. To address this issue, several blockchain node providers, such as Tatum, Chainstack, Infura, Alchemy, and QuickNode, 1 offer proprietary blockchain nodes and hosting as a service, providing instant API connections to full nodes from many leading blockchain networks to improve blockchain implementations. However, using these services comes with a cost averaging around $49 per month, and the lack of incentives for users to participate in full node implementations is a drawback of these platforms. In contrast, recent proposals, such as Mina [6], DeChain [7], and Flyclient [8], improve the efficiency of light client verification but do not incentivize users to support the blockchain network. This lack of incentives could pose a risk to decentralization, which is a critical issue for Ethereum, Bitcoin, and the broader blockchain community, as highlighted by [9].
Celo, Vipnode, IOTA, and Pocket Network 2 incentivize users to run full nodes to improve the decentralization and reliability of blockchain networks. Celo rewards its network users through gateway fees and transaction payments. Vipnode offers users the flexibility of paying what they want for 30 days of access to its platform and reserved peer slots for instant connections to ensure the Ethereum network remains decentralized. IOTA and Pocket Network incentivize users to run full nodes on their platforms by offering in-app privileges. However, these blockchain implementations fail to address the information asymmetry between users and the network. To design an optimal reward system, the blockchain network must be cognizant of the efforts made by users, specifically in terms of resource contributions and the ability to generate revenue through node implementations. This information is crucial in avoiding the moral hazard problem, which arises when the users do not put forth the effort they claim to. Furthermore, knowledge of users' revenue-generating capabilities assists in circumventing the issue of adverse selection, where users falsely present themselves as having low revenue-generating abilities to gain more rewards. Consequently, the existence of significant information asymmetry poses a challenge when designing optimal rewards. Furthermore, incentives or rewards, such as monetary compensation, reduced gas fees, reputation, and voting weights, can be practical tools for encouraging user participation and adoption of a blockchain platform, but funding the incentives also requires considerable resources. Therefore, the network must deliberate on the most appropriate incentives and how to distribute its budget to optimize its utility effectively. If the budget is not managed effectively, it may be depleted rapidly, leading to reduced or discontinued incentives. Therefore, motivated by the preceding discussion, we ask and attempt to answer the following questions in this article: 1) How should users with information asymmetry levels be incentivized to share resources for the long-term sustainability of the blockchain? 2) How can the blockchain network balance the need to incentivize users with the limited resources available for funding incentives?

B. CONTRIBUTIONS
Contract theory is considered to be a practical approach for incentive mechanism design under asymmetric information scenarios [10]. As a result, we employ contract-theoretic methods to develop an incentive mechanism that economically encourages user engagement in the sustainability and expansion of the blockchain network. Firstly, we characterize the user types based on their revenue-generating capabilities and efforts. Secondly, we provide a contract design that considers the various information asymmetry levels between the blockchain network and the users for the long-term sustainability of the blockchain. Specifically, our innovative model addresses both adverse selection and moral hazard problems. We present solutions to the problems under three different scenarios: the general case where both adverse selection and moral hazard are present and the two extreme cases where only one of these issues is present (i.e., only adverse selection and only moral hazard). Next, to balance the need to incentivize users with the limited resources available, we propose to offer diverse incentives for users with different types based on their reward amounts. Our contract design extracts the user types (revenue-generating capabilities and efforts), which are utilized to determine each user's reward amount and type of reward.
To the best of our knowledge, this work is the first attempt to investigate a diversified incentive mechanism design for users on blockchain networks considering different degrees of information asymmetry. Compared to previous recent implementations, our contributions can be summarized as follows: r We propose a novel incentive mechanism addressing "adverse selection" and "moral hazard" problems.
r We propose a diversified reward scheme for funding user incentives.
r We perform numerous experiments to confirm the effectiveness and efficiency of our diversified incentive mechanism. The rest of this article is organized as follows. Section II explains the system model and the preliminary architecture of our incentive mechanism. We show our contract formulations and closed-form solutions in Section III. Section IV presents our diversified incentives scheme. In Section V, we show the experiment results and analysis of our proposed mechanism. Finally, Section VI concludes this article.

II. SYSTEM MODEL A. SYSTEM ARCHITECTURE
The Ethereum network is a multi-layered system, with hardware, software, and application layers all working together to form a cohesive whole [11]. The hardware layer is a vast computer network that executes transactions and maintains an updated shared database. The software layer enables developers to run programs, such as smart contracts (SCs), using Solidity programming language and node clients on the Ethereum network [12]. The third layer comprises applications that provide various services to Ethereum users, from governance to identity management.
This work focuses on the hardware layer of the blockchain network, specifically the entities that establish the Ethereum network (EN). Two types of nodes are considered: lightweight and full nodes. Maintaining these nodes requires substantial resources such as storage space, computational capabilities, and electricity [13]. Users must have desktop or laptop hardware with at least 500 GB of free disk space, 16 GB of memory (RAM), and a broadband internet connection capable of uploading at least 400 kilobits per second 3 . Due to the significant resources required to run full nodes, appropriate incentives are necessary to encourage user participation. To optimize funding incentives, the EN considers users' revenuegenerating capabilities and offers various types of contracts for users to choose from. Once the contracts are signed, the EN obtains information about the users to determine their corresponding rewards earned. Additionally, a reward amount classification system is implemented to determine the types of rewards to be offered and the terms of trade for such rewards. Fig. 1 illustrates our system architecture with the proposed incentive mechanism design. 3 https://ethereum.org/en/developers/docs/nodes-and-clients/.

B. NETWORK MODEL 1) USER RESOURCES
Full nodes can be run in the cloud with an account on either Amazon Web Services (AWS) or Google Cloud or locally on user devices [14]. In this work, we consider the case of running full nodes locally. Let the set I = {1, . . . , I} denote the population of I heterogeneous users on our EN platform. Suppose there are N tasks to be completed using diverse resources at each user node. Expressly, each user with a full or light node consumes E (t ) energy units at a particular time t for tasks, such as data accumulation, transmission, and computation [15]. The electricity E i (t ) consumed by user i ∈ I to keep the nodes running all the time when needed can be calculated as follows: where c e n (t ) ∈ R + is the cost per unit energy and e n (t ) is the amount of energy used by a task n ∈ N. The locations of the full nodes are supposed to be fixed during any data transfer. We employ the time-division medium access (TDMA) technology, in which the uplink and downlink share the same frequency channel [16]. As a result, the feasible network data rate B i (t ) for user's node i can be mathematically quantified as follows: where for task n, c b n (t ) ∈ R + is the cost per unit data transferred and b n (t ) is the amount of data consumed. Furthermore, full nodes store the state of the most recent 128 blocks (or 64 blocks on a fast/snap sync), which is updated as soon as a new block arrives. The used storage space S i (t ) by the user's node i is a function of the total number of blocks stored at a time t on the user device and can be expressed as: where c s n (t ) ∈ R + denotes the cost coefficient for a unit storage space and S n (t ) represents the block storage space used by user i for task n at any given t. Full nodes are required to verify transactions, beginning with the genesis block and retrieving all transactions recorded on blocks from connected peers. Synchronization of a fully certified node is time-consuming and demands significant computational resources. The user's node i computational resource demands P i (t ) for N tasks is denoted by the following notation: where c p n (t ) ∈ R + denotes the cost coefficient for computational resource utilization and p n (t ) represents the number of computational resources used by the user device.

2) USER'S TYPES
Any user may utilize the EN to operate their own "business," which can result in either success (receive revenue γ , such that γ ≥ 0) or failure (receive revenue of γ = 0), i.e., the revenue realizations {0, γ }. Besides mining, blockchain users can generate revenue through cross-border payments, lending platforms, credit scoring, and financial record keeping. Other revenue-generating opportunities include invoicing management, billing solutions, fund investment, government spending, political funding, stock exchange, and initial public offering [17]. As a result, the users' revenue-generating capabilities θ fall into two distinct types, such that θ ∈ {θ H , θ L } with θ L < θ H , implying users with lower and higher revenuegenerating capabilities, respectively. We mention that the user types can also be extended to more than two using the various techniques explained in [10]. Furthermore, while the EN may not know each user type, it may be aware of users' private information statistics based on market research and previous experience [18]. The EN can use this statistical data to create an apriori distribution set, which can speculate whether a user possesses a high or low capability {θ H or θ L } with the respective probabilities {λ, (1 − λ)}, where λ ∈ [0, 1] is the probability that a user belongs to θ H and (1 − λ) is the probability that a user belongs to θ L . In addition to a user's capability, the level of effort ξ exerted on the EN also plays a role in determining the potential for generating significant revenue. Users can increase their chances of earning higher revenue by investing more resources into the platform. Therefore, we denote θξ ∈ (0, 1) as the probability of a user generating significant revenue based on the level of effort exerted on the EN.
Additionally, we assume that the user i's effort ξ i is a convex function of total resources ψ i and skill set. The user's skill sets comprise the capability to coordinate various resources or the competency to implement and manage full nodes for revenue purposes, which is challenging to quantify. Therefore, we correlate this with the revenue-generating capability. That is, θ H has a higher skill set than θ L . m i , which can be expressed as where ψ i = E i (t ) + B i (t ) + S i (t ) + P i (t ) is the total resource cost from the summation of (1), (2), (3), and (4). c m i ∈ R + is the cost coefficient associated with the skill set m i , which is sufficiently large that the user will never pick an m i that results in θξ ≥ 1 and ensures that the probability 0 < θξ < 1 holds.

3) CONTRACT FORMULATION
We assume both the Ethereum network (EN) and its users are risk-neutral, meaning they do not prioritize saving or consuming. Both the EN and users can earn revenue from mining and gas fees. However, investing resources in the development of full nodes primarily benefits the EN, as it aids in its growth and sustainability. As a result, the EN is motivated to compensate users for their efforts with a contract that details the cost and reward. The contract C = {q, r(ξ )} specifies the cost q for using the EN and the reward r(ξ ) provided to the users. Users pay gas fees to use the EN platform, and the reward r(ξ ) compensates users for their efforts with tokens, voting weights, reputation, or discounts. r(ξ ) is a function of effort ξ , and the EN provides a zero-reward item for any user type that does not provide resources. The EN must optimize its contract by balancing user incentives with fees to maximize revenue.

C. UTILITY MODEL 1) EN'S UTILITY
The EN's utility is primarily determined by the platform utilization fee q and the reward r(ξ ) paid to the users. However, since the user utilizes the platform to run their own tasks, the EN needs to account for the profit made by this means to optimize its utility. Additionally, the EN does not know the user types (e.g., {θ H , θ L }), but it knows the probability that a user belongs to, which is represented by λ i , such that We define the EN's utility as where (7) represents the EN utility in terms of user types, e.g., high and low capability users correlated with {θ H , θ L }. The utility of the EN is calculated as the difference between the total payments made by users and the rewards distributed by the EN. To ensure that the entire process is beneficial to the EN, we require that q i + θ i ξ i r(ξ i ) ≥ 0 holds in all circumstances.

2) USERS' PAYOFF
Each Ethereum user's payoff on the platform is expressed fundamentally as the difference between earned income and payments made to the EN. In addition, we integrate the user's effort from (5) to account for operating costs. For any user i, the generated income consists of the user's revenue γ i and earned rewards r(ξ i ). The user pays the EN q i fees for utilizing the EN's platform, and the EN will reimburse the user's efforts with a payout of r(ξ i ). Therefore, we can derive the users' payoff as Given the utility function in (8), the user chooses the strategy that maximizes its payoff.

3) SOCIAL WELFARE
Next, we define social welfare as the weighted sum of the EN and users' utilities. The system's social welfare U SW can be represented as follows:

4) QOS SATISFACTION
Next, we define quality of service (QoS) satisfaction, which is an essential parameter for our system evaluation. The user i's QoS satisfaction β i based on its utility U EU (i) is formulated as the sigmoid function where μ depicts the constant that determines the satisfactory curve's shape [19]. We define QoS satisfaction for each user based on their payoff using the quality of service class identifier (QCI) table. Each user's QoS satisfaction denoted as β is set in the range [0,1], where a value of 0.5 and beyond means that the user is satisfied and that below 0.5 means dissatisfaction [20].

5) BLOCKCHAIN SUSTAINABILITY
We present a cost-benefit analysis (CBA) to evaluate the economic, social, and environmental costs and benefits of different deploying full node implementations. CBA involves quantifying the costs and benefits of different alternatives in monetary terms and comparing them to determine which alternative is the most efficient [21]. Our CBA U CBA can be formulated as follows where r CBA is the total benefits of incentivization, calculated as r CBA = i∈I θ i × i∈I ξ i × i∈I V(β i ), where V(β i ) represents users' satisfaction with the quality of service. Specifically, r CBA is obtained by multiplying the number of new full nodes, the average contribution per full node, and the evaluation of blockchain sustainability in terms of β i . Similarly, q CBA is the total cost of incentivization, calculated as q CBA = i∈I θ i × i∈I r(ξ i ).
Blockchain sustainability can result in lower transaction costs, improved efficiency, and increased trust. The cost of incentivizing full node implementation includes hardware and energy costs. U CBA can determine if the total benefits outweigh the total costs of incentivizing new full nodes for blockchain sustainability.

III. OPTIMAL CONTRACT DESIGN FOR USERS WITH ADVERSE SELECTION AND MORAL HAZARD
In this section, we explore the optimal incentive mechanism design for heterogeneous users in the EN to encourage the growth and sustainability of Web 3.0 and the Metaverse. Specifically, we solve the EN's utility maximization problem by analyzing three possible scenarios: 1) Only moral hazard scenario: This scenario considers the situation where the EN does not know the effort exerted by users in creating revenue. We consider the user effort defined in (5). 2) Only adverse selection scenario: In the event that the user uses the EN platform to create revenue, however, the EN may not be aware of the user's likelihood of generating a profit, resulting in an adverse selection problem.

3) Both adverse selection and moral hazard scenario:
In this instance, we explore a scenario in which both adverse selection and moral hazard are present, which is the general case that describes the current blockchain network. We present the contract feasibility and optimality conditions for each scenario prior to solving for the optimal contract. The contract feasibility and optimality are expressed as follows.

Definition 1. (Contract Feasibility):
A contract is feasible if each user obtains the maximal payoff by choosing the contract item designed for its type.

Definition 2. (Contract Optimality):
A contract is optimal if it maximizes the EN's utility among all feasible contracts.
The rest of this section includes the optimal contract design under adverse selection and moral hazard scenarios. To establish the general case, we first show the EN's utility maximization problem containing both adverse selection and moral hazard, which is followed by the two extreme cases involving only adverse selection or moral hazard.

A. EN'S UTILITY MAXIMIZATION PROBLEM
In this part, we examine the optimal contract for the EN problem when it is unaware of each user's revenue-generating capability and efforts on the platform. This optimal contract allows the EN to monitor and ensure that no user accepts a contract item that is not intended for its type, and vice versa. Consequently, an incentive compatibility (IC) constraint is required. We define the IC constraint as follows.

Definition 3. (Incentive Compatibility):
A contract is incentive compatible if it provides the maximal payoff for each user when it chooses the contract item {q, r(ξ )} designed for its type, which can be formulated as follows: where ξ j is the effort of a user belongs to type θ i when choosing contract {q j , r(ξ j )}. The IC constraint dictates that a user can only maximize its expected return by selecting the contract that corresponds to its type. Furthermore, for the user to accept the necessary contract item, the EN must guarantee that each user receives a positive payment, imposing an individual rationality (IR) constraint. The IR constraint is expressed in the following definition.
Definition 4. (Individual Rationality): A contract is individually rational if it provides a non-negative payoff to each type-i that accepts the contract item {q, r(ξ )} designed for its type, i.e., The IR constraint gives the user the appropriate incentives to sign the contract. In other words, a contract is only feasible if it meets IC and IR constraints.
Additionally, the IR and IC restrictions are the basic conditions required to ensure that a contract is incentive compatible and rational. In addition to the IR and IC constraints, a number of other conditions must be achieved.
According to Lemma 1, if θ i > θ j , then r(ξ i ) > r(ξ j ) must hold. Therefore, a high-type user should receive a greater reward than a low-type user. If two users receive the same reward, they must be of the same type, and vice versa. Consequently, this property can be defined as: The monotonicity of a contract holds for any feasible contract {q, r(ξ )}, the reward r(ξ ) follows 0 ≤ r(ξ 1 ) < · · · < r(ξ i ) < · · · < r(ξ I ).
The monotonicity property states that the value of the contract to one party cannot decrease as the other party's actions improve. In other words, if one party's actions increase in value, the other party's payoffs must also increase. We can derive the following proposition from the property of monotonicity: Proposition 1: As a strictly increasing function of q, the efforts ξ intuitively fulfills the following criterion Proposition 1 demonstrates that an incentive-compatible contract necessitates high performance from users in exchange for a high payoff, and vice versa.
Lemma 2: For any feasible contract {q, r(ξ )}, the payoff of each user type must satisfy Lemma 2 states that higher-type users achieve higher payoffs than lower-type users. The IC constraint and the two lemmas that we establish allow us to simply derive the following. If a high-type user chooses the contract designed for a low-type user, even if less effort was put into the EN, the lower reward received will diminish the user's payoff. Furthermore, if a lower-type user chooses a contract meant for a high-type user, the reward return cannot compensate for the cost of efforts, and therefore the cost outweighs the return. The user will gain the most payoff if and only if the contract best suits its type is chosen. As a result, we can ensure that the contract is self-revealing.
Next, the optimal contract C * = {q * , r * (ξ )} is the solution to the EN's optimization problem, which seeks to maximize its return by determining the quantity of rewards to offer users depending on their capabilities and efforts, which can be formulated as: Problem 1 (EN's utility maximization problem): where both adverse selection and moral hazard are considered.
Taking the first derivative of the user's expected payoff in (8) with respect to effort ξ , we can determine the user's best choice of effort ξ * under the contract (q, r(ξ )) as follows Likewise, we have ξ j = 1 2 θ i (γ j − r(ξ j )). This equation demonstrates that the optimal effort ξ i for users is independent of q i but decreases with r(ξ i ). In other words, users would have fewer incentives to contribute to the network if they must share a more significant portion of the generated revenue γ i , irrespective of the predetermined gas fees paid q i for every transaction on the EN's platform. The reduction in effort ξ * i immediately reduces the probability of obtaining revenue γ i . Therefore, it is critical to strike a balance between providing sufficient incentives to users and demanding reasonable fees from them.
We can then express the EN's problem in the following form by replacing ξ * i and ξ * j into (17) as follows: 0 ≤ r(ξ 1 ) < · · · < r(ξ i ) < · · · < r(ξ I ), However, it is not possible to separate the moral hazard dimension from the adverse selection dimension in this scenario, meaning that the two incentive problems cannot be addressed independently. In the subsequent subsection, we will discuss the distinct functions of moral hazard and adverse selection, as well as the consequences of their simultaneous existence. The optimal contract design for this issue depends on whether only adverse selection, only moral hazard, or both are explicitly taken into account.

B. OPTIMAL CONTRACT WITH MORAL HAZARD SCENARIO ONLY
Assume that the EN can observe the user's revenue-generating capability, which eliminates the adverse selection problem and leaves only the moral hazard incentive problem. The EN problem can then be reduced to the following by treating users with distinct capabilities independently: Problem 2 (Contract Design for Users with Moral Hazard Scenario Only): In this optimization problem, we seek to maximize the EN's utility subject to the IR and monotonicity constraints. Under the optimal contract with a moral hazard scenario only, we can derive the following insights: 1) This EN utility maximization problem has the solution: q * = 1 2 θ 2 i γ 2 i and r * (ξ H ) = r * (ξ L ) = 0. 2) As there is no adverse selection, the EN's main objective is to mitigate the negative effects of moral hazard. 3) To eliminate moral hazard, the EN should only charge users a substantial, e.g., q i + γ i , where ∈ [0, 1] is an extra fee for the users with unknown efforts in generating high revenue. 4) In this moral hazard scenario, the only reason that the EN may keep the payment restricted to q i is if the users are financially constrained.

C. OPTIMAL CONTRACT WITH ADVERSE SELECTION SCENARIO ONLY
Now consider that the user's effort level is preset at level ξ , but the EN is unable to see the user's revenue-generating capability, which leads to an adverse selection scenario. As a result, the EN's problem can be reduced to: Problem 3 (Contract Design for Users with Adverse Selection Scenario Only): In this optimization problem, we aim to maximize the EN's utility subject to the IC, IR, and monotonicity constraints. The optimal contract taking only the adverse selection scenario into account, provides the following insights: 1) The EN utility maximization problem has the solution: q * i = − 1 2 θ i ξ 2 and r * (ξ H ) = r * (ξ H ) = r * (ξ ), which eliminates the monotonicity constraints from (21d).
2) The EN's payment is negative, i.e., the EN must pay 1 2 ξ 2 to the users instead. This is because the EN demands 100% (i.e., = 1) of the return from the users. However, in order for the IR constraint to hold, a payment from the EN to the users is required.

D. OPTIMAL CONTRACT WITH BOTH ADVERSE SELECTION AND MORAL HAZARD SCENARIOS
Due to the extreme assumptions made in the first two scenarios (e.g., there is only a moral hazard or only an adverse selection), their solutions are simple. Nonetheless, neither extreme approach accurately depicts the fundamental problem in practice. For both types of incentive problems, it is essential to describe how the incentive system could be set up. Intuitively, when both types of incentive problems are present, the optimal menu of contracts is a hybrid of the two extreme alternatives. The EN problem can be solved using the method described in [10] for pure adverse selection. First, the analysis demonstrates that only the θ L user's IR and the θ H user's IC constraints will hold. When the θ L user receives positive payoffs, so does the θ H user, who can always imitate the θ L user for higher incentives. Second, the EN can keep the θ H user from getting rewards in a situation with symmetric information 4 , encouraging users to imitate the θ L user. Therefore, the EN's optimization problem can be expressed as:

Problem 4 (Contract Design for Users with Both Adverse Selection and Moral Hazard):
0 ≤ r(ξ 1 ) < · · · < r(ξ i ) < · · · < r(ξ I ), (22d) By utilizing an optimal contract design that considers both adverse selection and moral hazard scenarios, we are able to gain the following insights: 1) Using the two binding constraints to eliminate q H and q L , we can obtain the optimal rewards r * (ξ H ) and r * (ξ L ) as follows:, 2) Substituting r * (ξ H ) and r * (ξ L ) into the IC and IR constraints in (19), we can obtain the optimal payments q * L and q * H as follows: 3) Since θ H user gets higher rewards than θ L user, we can assume that there is no effort distortion for θ H and θ L . 4) The size of the capability differential (θ 2 H − θ 2 L ) and the EN's prior λ significantly affect the θ L user's reward. 5) The higher the EN's confidence that it will meet an θ H user, the higher its stake r(ξ L ) and payment q H .

IV. INCENTIVE DIVERSIFICATION FOR ETHEREUM NETWORK'S UTILITY OPTIMIZATION
This section demonstrates our incentive diversification scheme, which comprises voting weights and monetary rewards as user incentives for contributing efforts towards the EN. We present our diversified incentive mechanism design in Section IV-A.

A. INCENTIVE DIVERSIFICATION SCHEME DESIGN 1) USER REWARD AMOUNT
Our contract design outlines the user's revenue-generating capability and effort toward the EN, which can help the EN make informed decisions about how to compensate each user. We initially divide the execution time t into fixed-duration time slots t ∈ {0, 1, 2, . . . , T }, with each time slot allocated to the proposal and production of a new block and T is the total execution time. The time slot t = 0 represents the generation of the genesis block. We introduce the classification groups of user reward groups, which helps distinguish users who will earn voting weights from monetary incentives. Without loss of generality, user reward amounts are grouped into four main categories based on the user's capability and effort. These categories include very high-tier I 1 , high-tier I 2 , mid-tier I 3 , and low-tier I 4 users. An I 1 user's reward amount has a high capability and a high effort, which is distinguished from an I 2 user's reward amount with a low capability and a high effort. I 3 user's reward amount has a high capability but a low effort, whereas I 4 user's reward amount has a low capability and a low effort. The user's reward amounts can be calculated as follows: where ξ EN is the maximum specified effort level from the EN, which is used to classify the relative levels of users. We offer voting weights v to high-reward users, which can be characterized as I 1 and I 2 users from (27) and (28). We denote the set of users that fall in I 1 and I 2 as I v and compute the voting weight v i of user i ∈ I v as follows: wherev is the total vote weights that can be allocated as rewards on the system by the EN. Then, on any proposed block by user i at a time t, we add the voting weight v i to the user's existing voting score to boost its chances of approval. We can also apply our voting weight concept to increase each user's verifiable random function for higher chances of being selected as leader or block proposer [22]. Now, on the other hand, users in I 3 and I 4 are offered monetary rewards w. We denote the set of users in I 3 and I 4 as I w and compute the voting weight w i of user i ∈ I w as follows: wherew is the total monetary value that can be allocated as rewards on the system by the EN.

2) REWARD DIVERSIFICATION
Next, we study the user's willingness to accept any form of incentive or trade one incentive for another. This study is relevant because the vast majority of economic activities involve voluntary trade between individuals. When users trade in their resources to the EN for incentives, they can decide to give up one thing (e.g., voting weights) in exchange for another (e.g., money), which is presumably of more value or equivalent to that user. Nonetheless, we must mention that at any time, the users cannot trade all of their voting weights for monetary rewards, as the law of diminishing returns holds to ensure a lower payoff if one item is overly exchanged. We employ indifference curves as a graphical tool to efficiently Algorithm 1: The Proposed Diversified Incentive Mechanism Algorithm. Input: User types, blockchain network information, funding incentives Output: Incentive mechanism design Step 1: Characterize user types • Identify user types based on revenue-generating capabilities and efforts.
• Categorize users into groups with similar characteristics.
• Determine each group's impact on the blockchain network and its potential for revenue generation.

Step 2: Provide contract design
• Address information asymmetry between users and the blockchain network.
• Consider both adverse selection and moral hazard problems.
• Develop solutions for different scenarios: general case, only adverse selection, and only moral hazard.

Step 3: Offer diverse incentives
• Assign reward levels to each user group based on their revenue-generating capabilities and efforts.
• Users with higher reward levels receive voting weights that influence the blockchain network's decisions.
• Users with lower reward levels receive monetary rewards for their participation.
investigate this type of voluntary transaction. In Fig. 2, U = {U 1 , U 2 , U 3 } set of curves display all possible combinations of voting weights v and money w for which a user is equally well off. We assume that the remaining arguments of the utility function are kept constant. The user is equally satisfied with accepting, for example, the reward combinations (v 1 , w 1 ) or (v 2 , w 2 ). We refer to this curve that represents all consumption bundles that a user ranks equally as the indifference curve. Definition 6. (Indifference Curve): An indifference curve (or, in several dimensions, an indifference surface) represents a collection of consumption bundles towards which a person is indifferent. In other words, all bundles offer the same amount of benefit.
The indifference curves in Fig. 2 have a negative slope, indicating that if the user is compelled to sacrifice some v, it must be reimbursed by an increased quantity of w to remain indifferent between the two bundles of products. As v grows, the slope of the curves also increases (i.e., the slope starts at negative infinity and increases toward zero). Fig. 2 is a graphical depiction of the hypothesis that as users acquire more v, they become increasingly less inclined to sell away where the notation specifies that the slope should be determined along the indifference curves. We present another concept called the budget line, shown as the red line in Fig. 2. A budget line in economics is the maximum quantity of goods or services that a user can afford to buy given their income and the price of the goods or services they want to purchase. It is a graphical representation of the budget constraint that users face, which is the limit on the combination of goods or services that they can afford. The budget line can be used to illustrate how changes in income or prices affect the choices that a consumer makes. For example, if a user's reward increases, their budget line will shift outward, allowing them to afford greater voting weights or monetary rewards. Similarly, if the price of voting weights or monetary rewards decreases, the budget line will shift inward, allowing the consumer to afford a greater quantity of that good or service. In this work, we set our budget line for voting weights and monetary rewards to [1,100]. This budget line affects the selection of our indifference curve, and it is subject to change depending on the data collected, which makes the curve U 2 the optimal indifference curve for our experiment.
Therefore, taking U 2 as our optimal curve, the slope of U 2 and the MRS indicate the trades that a user will freely make. At a point such as (v 1 , w 1 ), the user has a large quantity of monetary reward w and is prepared to give up a substantial amount in exchange for voting weights v. Consequently, the indifference curve is rather steep at (v 1 , w 1 ) if the user receives a substantial monetary incentive w and a small number of voting weights v. In contrast, the indifference curve is flatter at (v 2 , w 2 ). That is, the user has a small number of voting weights and is ready to forego relatively few monetary incentives. Therefore, the MRS decreases between (v 1 , w 1 ) and (v 2 , w 2 ). The shifting slope of U 2 demonstrates how a certain consumption bundle's availability affects the trades that a user will freely make. Also, we mention that the points (v * , w * ) are the optimal trading reward for any user on our platform.
To create our indifference curve for the marginal rate of substitution (MRS) graph using our two incentives, we adopt the following steps: 1) We determine the two goods to include in the graph, e.g., voting weights and monetary rewards. 2) We determine the quantities of each incentive the user is willing to trade based on the simulations conducted in Section V. 3) We graphically plot the points shown in Fig. 2, with the number of voting weights on the y-axis and the number of tokens(monetary reward) on the y-axis. 4) We repeat step 2 for multiple trade-off ratios between the two rewards. 5) Finally, we connect the plotted points to create the MRS curve.

3) ALGORITHM ANALYSIS
One of the key advantages of our algorithm is its efficient time complexity. This time complexity means that the algorithm can process large amounts of data in a relatively short amount of time, which is crucial for applications where speed is of the essence, such as real-time data analysis or largescale data processing tasks on the blockchain network. The time complexity of reward amount classification algorithm is O(N w + K w ), where N w is the number of elements in the input weights and K w is the range of weights [23]. The time complexity for our optimal contract can be computed as O(N ) [24]. Therefore, the overall time complexity of the system can be evaluated as O(N ) + O(N w + K w ). The acceptable time complexity of our approach allows for effective use of computer resources, which can contribute to cost savings and increased overall performance.

V. EXPERIMENT RESULTS AND ANALYSIS
In this section, we first provide the system configuration for our experiment in Section V-A. Second, in Section V-B, we describe the performance measurements and experiment benchmarks that will serve as the foundation of our analysis. Finally, in Section V-C, we conduct comprehensive experiments to assess the performance benefits of the suggested mechanism and analyze our findings.

A. SYSTEM CONFIGURATION
In this section, we provide the configuration architecture for our proposed scheme's comprehensive experimentation and analysis. All experiments are targeted at the Ethereum blockchain architecture and protocols. However, our implementation is guaranteed to function on any proof-of-stakebased platform. The experiments are carried out on a Core i7 CPU machine with a 3.8 GHz processor and 32 GB of RAM, using the Python 3.8 environment with solidity v0.8.0. To deploy the optimal contract with moral hazard and adverse selection on this system, we run decentralized nodes from the chainlink platform with SCs on Ubuntu 20.04 LTS. For scripting and developing our SCs, we utilize solidity programming languages. The solutions to our optimal contract design are directly encoded into SCs that run in a particular time slot to extract the user types for their corresponding payouts. In this experiment, we set up decentralized oracle nodes to decentralize the execution of our contract and incentive scheme using chainlink technology 5 . However, due to the expense of deploying transactions on-chain, we confine the majority of transaction executions to off-chain to save resources. Furthermore, when applied with chainlink technology, our approach provides legacy compatibility with the existing blockchain and reduces gas costs.

B. PERFORMANCE METRICS AND EXPERIMENT BENCHMARKS
In this part, we present the preliminary elements for Section V-C, such as the selection of experiment results and benchmarks. The selection of experiment results describes how we chose the various outcomes for this discussion, and the benchmarks describe the measurement metrics utilized to obtain these results.

1) SELECTION OF EXPERIMENT RESULTS
In this experiment, we present the following evaluation guidelines to examine our proposed diversified incentive mechanism: contract analysis, EN's utility analysis, users' payoff analysis, user satisfaction level, user participation rate analysis, and security analysis. The contract analysis expands the EN's utility and the user's payoff based on contract design, offering a thorough overview of contracts under our suggested incentive mechanism. In Section V-B2, we give benchmarks for the analysis of our contract design.
Based on the benchmark in Section V-B3, our system performance findings show the EN's utility and user payoff, the user satisfaction level, the user participation rate, and the security analysis. To obtain these results, we simulate and record the effects on the EN's utility and the user's payment, as indicated in Sections V-C2 and V-C3. Second, we compute the satisfaction levels of the various user incentive levels using (10). The user participation rate demonstrates the efficiency with which our proposed method can engage users. Finally, FIGURE 3. Contract analysis: Fig. 3(b)-(c) show the contract analysis considering various contract types. System performance: Fig. 3(d)-(h) represent the EN's utility, users' payoff, QoS satisfaction, user participation rate (reward amounts), and user participation rate (time)), respectively.
Section V-C6 shows the security analysis of our proposed incentive scheme.

2) BENCHMARK 1
This benchmark includes the blockchain network's (EN's) utility, the user's payoff, and social welfare analysis considering the various contract design scenarios. We list the benchmarks as follows, r Both moral hazard and adverse selection: This benchmark comprises the problem formulation and solution from (22).
r Celo: the developers in [25] created Celo, which is a protocol that supports gateway fees. 6 These fees incentivize node operators to run a full node that is not a validator and acts as a "gateway," i.e., answer requests and forward transactions on behalf of light clients. However, Celo does not consider the EN's utility optimization, user capabilities, or efforts.
r Vipnode: Vipnode provides an economic incentive for running Ethereum full nodes but fails to consider the user's revenue-generating capability and EN's utility introduced in our work. 7 6 Celo implementation can be found at: https://docs.celo.org/ 7 Vipnode implementation can be found at: https://vipnode.org/ r Pocket Network: Pocket Network is an independent blockchain designed for specific applications that use an adapted version of the Tendermint consensus engine and incentivize users with a native cryptocurrency. However, to optimize the EN's utility, the pocket network requires more diversified incentives. 8 We also use various metrics to evaluate our system's performance, including the EN's utility, user payoff, user satisfaction levels, user participation rate, and security analysis.

C. RESULTS AND ANALYSIS 1) CONTRACT ANALYSIS
In this experiment, we investigate the various contract designs to validate the best option by examining EN's utility, user's payoff, and overall social welfare, as depicted in Fig. 3(a), (b), and (c), respectively. Fig. 3(a) illustrates that the EN's utility rises as the number of users increases due to the accumulated revenue generated from multiple users over time. Our analysis shows that the contract that only addresses moral hazard results in the highest utility, followed by the contract that addresses both moral hazard and adverse selection, adverse selection only, and no contract in that order. For 100 users, all contract designs show similar and significantly low utilities. However, as the number of users increases to 400, the contract that addresses moral hazard achieves an average EN utility of 15% − 57% higher than the contracts that consider both moral hazard and adverse selection, adverse selection only, and no contract selection. This is expected as the EN has full knowledge of the users' revenue-generating capabilities and efforts in both extreme cases. Notably, the EN's utility decreases under no contract, leading to more leverage for users. From Fig. 3(b), we can see that the users' payoff is high for the contract considering both moral hazard and adverse selection, followed by that for adverse selection only, moral hazard only, and no contract selection. Specifically, with 400 users, the contract for both moral hazard and adverse selection scenario generates 25% more payoff than that for adverse selection only, 85% more payoff than that for moral hazard only, and nearly 100% more average payoff than the case with no contract selection. This observation can be attributed to users putting in extra effort in the case of moral hazard to compensate for the expenses they incur in adverse selection. Offering moral hazard only to users allows the EN to extract as much profit from users as possible. On the contrary, adverse selection only gives users the leverage to demand reasonable charges from the EN by exposing their revenue-generating capabilities. No contract selection yields the worst outcome because the EN is unaware of the users' capabilities or efforts, which does not improve our goal of sustaining blockchain networks through incentives. We mention that the analysis governing the EN's utility and users' payoff trends applies to the social welfare shown in Fig. 3(c).
Hence, we can conclude from the results that the EN will always prefer a contract considering moral hazard only, while users gravitate towards a contract considering both moral hazard and adverse selection. Nonetheless, considering both moral hazard and adverse selection gives the best results when maximizing the EN's utility and the payoff for its users. Fig. 3(d) compares the performance of our proposed mechanism design to that of Celo, Vipnode, and Pocket Network in terms of the EN's utility. The EN's utility is an increasing function of the total execution time, which is intuitive due to the cumulative payments accrued over time. At a simulation time of 6 hours, our proposed scheme achieves approximately 48.48% − 54.52% increase in the EN's utility compared with Celo, Vipnode, and Pocket Network.

2) EN'S UTILITY ANALYSIS
As shown in Fig. 3(d), offering a contract that addresses both moral hazard and adverse selection in addition to the incentive diversification produces a higher EN's utility. The reasons for this trend of the results consist of the following: (i) as shown in our contract analysis, we present the optimal strategies for the EN to maximize its utility, (ii) as we have shown in Section III, our contract design extracts the user revenue-generating capabilities and efforts for appropriate pricing, which improves the EN's utility, (iii) our reward diversification provides the EN with alternatives to reward users without exhausting its revenue transactions. These factors are, however, absent from the incentive mechanisms proposed by Celo, Vipnode, and Pocket Network. As the EN has increased utility, we can infer that our proposed mechanism is a promising approach for enhancing the EN's utility.

3) USERS' PAYOFF ANALYSIS
This part of the experiment compares the users' payoff under our proposed mechanism, Celo, Vipnode, and Pocket Network, as shown in Fig. 3(e). The users' payoff increases as the total execution time increases, with our proposed scheme achieving up to 38.46% − 62.5% cost reduction compared with Celo, Vipnode, and Pocket Network. From Section II-C2, the users' payoff is a function of their revenue-generating capability and efforts. That is, a high revenue-generating capability gives higher revenue to users, and more costly resources are required, which provides users with higher compensation from the EN. This approach offers a more efficient mechanism for users to identify and extract revenues from EN without indiscriminately increasing their costs. The users' payoff is high under our proposed system, followed by Pocket Network, Celo, and Vipnode, indicating that our proposed mechanism performs better.
Similarly, in Fig. 3(e), the improved performance of our proposed mechanism can be attributed to the accurate representation of each user for proper pricing and compensation. Expressly, users are adequately charged based on their ability to generate revenue and compensated for their efforts contributed towards the EN. Unlike the benchmarks in Section V-B3, our proposed scheme provides a lucid incentive optimization scheme that can accurately represent heterogeneous users on the system. Celo, Vipnode, and Pocket Network do not fully incentivize users because these approaches fail to consider the users' capabilities. Since our proposed mechanism offers increased user utility, we can conclude that our proposed scheme enhances users' payoff compared with Celo, Vipnode, and Pocket Network.

4) USER SATISFACTION LEVEL
In Fig. 3(f), we compare the QoS satisfaction of users in our proposed mechanism compared with that in Celo, Vipnode, and Pocket Network. The QoS satisfaction determines how satisfied the users are with their payoff based on the reward amounts presented in (27)-(30). Fig. 3(f) describes the QoS level based on the reward amount using benchmarks from Section V-B3. From Fig. 3(f), our proposed mechanism achieves 72% more QoS satisfaction than Celo, Vipnode, and Pocket Network. This trend results from the various user types characterized by our contracts. On the one hand, our contract designs ensure that every user is well-represented, which makes it more likely that they will get satisfactory rewards. Accepting the contract items designed for each user guarantees that users are reasonably charged and compensated for services. Additionally, offering a variety of incentives provides users with flexibility in their payoff utilization, which can improve the QoS levels of various users. Specifically, users can trade their voting weight rewards for money to subsidize their costs at any time.
On the other hand, Celo, Vipnode, and Pocket Network do not consider user characterizations and incentive diversification in their implementations. Based on these improvements introduced by our proposed mechanism, users are incentivized to contribute significant resources towards the EN. Therefore, our proposed mechanism offers better QoS satisfaction than other implementations.

5) USER PARTICIPATION RATE ANALYSIS
In this experiment, we evaluate the user participation rate based on the duration and the number of users engaged on the platform using our proposed mechanism, Celo, Vipnode, and Pocket Network. Fig. 3(g) and (h) show the user participation rate based on the reward amount and experiment duration. From Fig. 3(g) and (h), the user participation rate for our proposed system increases as the experiment time. Our proposed scheme achieves up to 68% more user participation than Celo, Vipnode, and Pocket Network have recorded over time.
Based on the results shown in Sections V-C3 and V-C4, we can deduce that our proposed mechanism achieves a high user participation rate due to the enhanced users' payoff and the increased user QoS satisfaction levels. The findings also suggest that the IR and IC constraints can give users a non-negative payoff for any contract and a high payoff for selecting a contract designed for its type. Additionally, the diversification of user incentives attracts more heterogeneous users to participate on the platform. As a result, users are more motivated to contribute resources towards the EN than other implementations.

6) SECURITY ANALYSIS
In this part of the experiment evaluation, we present the security analysis of our proposed mechanism to support the results from Sections V-C2 to V-C5. We consider two main concerns: 1) the possibility of storing excess incentives by users on the platform; and 2) incentive centralization and 51% attacks by specific highly skilled users on the platform. First, we use "burning" to keep track of how many incentives (rewards) each user on the system has. Burning is a security measure that economically disincentivizes undesirable behavior. Burning is the process that diminishes the overall supply of incentives from an economic viewpoint. The objective of network sustainability is for the circulating supply to be deflationary or with as minimal deflation as feasible via the following burning mechanisms: 1) User's tokens can be burned through decentralized autonomous organization (DAO) proposals. 2) High-capability users overuse their stake and incentives to increase block approvals. 3) Nodes do not process honest requests from users due to transaction frontrunning and reordering. Secondly, our proposed mechanism reduces the risk of incentive centralization and 51% attacks by running contracts on decentralized nodes. Expressly, no single node or the EN has exclusive access to executing our incentive mechanism and dispatching rewards, which prevents collusion or improper behaviors on the network. By mitigating these security challenges, our improved diversified incentive mechanism obtains a better user satisfaction and participation rate, as shown in Sections V-C4 and V-C5.

VI. CONCLUSION
In this work, we have proposed a solution to economically encourage user engagement in the maintenance and expansion of blockchain networks, which are essential for the success of Web 3.0 and the Metaverse. Full nodes, which store and validate all transactions in a blockchain, are necessary for the decentralization and reliability of the network. However, running a full node can be costly in terms of resources and expenses. To address this issue, we have developed an incentive mechanism using contract-theoretic methods that addresses the information asymmetry (e.g., users' revenue-generating capabilities and efforts) between users and the network. To optimize the blockchain network's utility for funding incentives, we offered diverse incentives to users based on their revenuegenerating capabilities and efforts. The extensive experiments show that our proposed mechanism increases the blockchain network's utility by 48.48% − 54.52% and reduces the users' cost by 38.46% − 62.5% compared with state-of-the-art implementations, such as Celo, Vipnode, and Pocket Network.