Lifecycle Optimization of Smart Contract for Different Scenarios in 6G Network

In the rapidly evolving landscape of the sixth generation (6G) network, smart contracts emerge as a pivotal technology for enforcing trustful rules. However, the conventional lifecycle model of smart contracts—encompassing stages from initiation to the termination of a contract instance—suffers from rigidity and lack of customization, leading to notable operational challenges. These challenges primarily manifest as heightened resource demands, including longer waiting periods and escalated transaction costs, which hinder the adaptability of smart contracts in the varied and dynamic contexts of 6G-connected environments. Driven by these issues, this article conducts a comprehensive analysis of the smart contract lifecycle. We introduce an innovative lifecycle model that offers customizable flexibility, allowing for the merging or separation of different stages in the smart contract process. Meanwhile, we propose a unique transaction data structure designed to integrate parameters of combined stages, each marked with distinct identifiers for differentiation. Further, we introduce an innovative address scheme for smart contract instances, which provides an identifier to simplify instance access while also maintaining a mechanism for traditional access methods. The verification results show that the model can save 52.72% of processing fee and 68.09% of completion time compared with the conventional method.


I. INTRODUCTION
T HE SIXTH generation of mobile networks (6G) is antic- ipated to bring forth advanced capabilities, including significantly higher speeds, reaching up to 1 Tbps through the use of terahertz waves, and reduced latency [1], [2].As 6G networks evolve, smart contracts emerge as pivotal tools, functioning as self-executing contracts with predefined rules and conditions on the blockchain [3], [4].Smart contracts are deployed and executed within the blockchain Hong Su and Chuanfeng Zhang are with the School of Computer Science, Chengdu University of Information Technology, Chengdu 610225, China (e-mail: suguest@126.com;3063074975@qq.com).
Digital Object Identifier 10.1109/JIOT.2024.3384239network.They uphold principles of transparency, immutability, and security [5], [6], playing a crucial role in establishing and enforcing trusted rules across various aspects of network operations.For instance, their applications within 6G networks extend to facilitating secure roaming between network providers, ensuring automatic verification and enforcement of agreed-upon rules for interconnection and data transfer [7].However, the existing smart contract model may not align with the varied requirements of different 6G devices.These devices have diverse requirements for smart contracts.Some devices require rapid data processing [8], while others with low-value density necessitate a focus on minimizing processing costs [9].Additionally, for short-lived devices, there is no need for their handlers to persist in memory for extended periods.On the other hand, before utilizing a smart contract, a distinct predeployment step [10] is involved, where the smart contract code is inserted into the blockchain and initialized.The predeployment step comes with additional transactions and introduces two drawbacks.First, to include these transactions on the blockchain, the sender must provide rewards to the miner, leading to increased costs.Second, users are required to wait for a sufficient number of blocks to ensure the confirmation of the deployment transaction on the blockchain.Consequently, the predeployment phase of smart contracts presents challenges in meeting the diverse requirements of devices connected to 6G networks.
Contemporary research in smart contract lifecycle optimization has been predominantly focused on enhancing individual stages rather than adopting a systematic, holistic approach.For example, the study presented in [11] proposes an integrated method to embed smart contracts within a single blockchain transaction, thereby conserving steps; however, this integration is limited to merging only the execution and deployment phases.Similarly, the research in [12] delves into conditional transactions to streamline cross-chain exchanges, effectively simplifying specific lifecycle stages (deployment and invocation), yet it falls short of providing an all-encompassing lifecycle solution.In another instance, Su et al. [13] introduced a dynamic approach by deferring the instantiation of smart contracts until it's deemed necessary, a strategy particularly tailored to Internet of Things (IoT) environments for cost-saving purposes.Nevertheless, this approach primarily focuses on optimizing the instantiation phase of the smart contract lifecycle, without addressing the entire lifecycle spectrum comprehensively.Despite these advancements, there remains a need for a unified model that fully addresses the lifecycle, particularly in the evolving context of 6G networks, a research gap this article aims to fill.
Therefore, establishing a flexible lifecycle model for smart contracts is essential for 6G-connected devices.The lifecycle of a smart contract encompasses stages from initiation to the termination of a contract instance.For devices prioritizing prompt data processing, predeploying their smart contracts is advantageous, as it facilitates faster subsequent invocations.Conversely, for devices where cost efficiency is paramount, merging the deployment and invocation stages of smart contracts can lead to savings by reducing the need for separate steps.Additionally, integrating the termination phase of the contract with its initialization and invocation processes can yield further reductions in both time and cost.
In this article, we propose to optimize the lifecycle of a smart contract, with the goal of enhancing its adaptability to diverse requirements in 6G scenarios.Our model delineates the smart contract lifecycle into four stages: 1) uploading code to blockchain; 2) instantiation; 3) invocation; and 4) termination.This model allows users to flexibly combine or separate these stages based on their specific scenarios.For example, users can integrate code placement and instantiation into a single step, followed by invocation in a separate step.Alternatively, all of these actions can be executed simultaneously, further streamlining the process.
The primary contributions of this article are outlined as follows.
1) This article introduces a lifecycle optimization model for smart contracts, marking a departure from current methods that focus only on specific and fixed lifecycle stages.This approach allows for the division of the smart contract lifecycle into various stages, providing users with the flexibility to customize execution based on different scenarios.This could include running all stages concurrently, executing them sequentially, or employing other combinations or separations of lifecycle stages.It helps to enhance the adaptability of smart contracts in diverse 6G connected device environments.To the best of our knowledge, this is the first time to propose a lifecycle optimization model for smart contracts from a systematic perspective, rather than focusing on specific and fixed stages.2) We introduce an innovative address scheme designed to facilitate the invocation of smart contracts in the context of 6G scenarios.This scheme utilizes a unique identifier, allowing for the invocation of a smart contract instance without needing its address, a departure from current methods where the contract's address must be generated first.With this scheme, once a contract is deployed, its identifier is mapped to the corresponding address, enabling immediate invocation post-deployment.This approach streamlines the deployment and invocation process, enhancing efficiency.3) We introduce a novel transaction data structure for smart contracts in 6G scenarios.This structure allows users to specify parameters for various lifecycle stages of a smart contract, such as deployment and invocation, through the incorporation of specialized fields and the implementation of multiuser encryption techniques.Unlike current methods where transactions can only trigger one stage, our structure enables the inclusion of parameters for multiple stages in a single transaction.Meanwhile, users can choose to provide parameters for specific stages rather than all stages, enhancing the customization and adaptability of smart contracts in varied 6G scenarios.This design helps to improve the efficiency and flexibility of smart contracts.The subsequent sections of this article are organized as follows.In Section II, we provide an overview of related work.Section III outlines the lifecycle optimization model, allowing to combine or separate various steps in the smart contract lifecycle.Section IV provides a quantitative analysis of the main characteristics of the proposed model.Finally, Section V presents the results of the verification process.

II. RELATED WORK
The optimization of smart contracts is gaining increased attention due to the widespread application of smart contracts in various sectors.This optimization encompasses various aspects, such as lifecycle management, security enhancement [14], and gas fee reduction [15].In the context of 6G scenarios, lifecycle optimization emerges as particularly crucial due to the diverse requirements of 6G devices, which may range from low-gas consumption to rapid response times.Effective optimization of smart contracts can yield substantial benefits, especially considering the vast number of devices in 6G networks.
Current research efforts in the realm of smart contract optimization have predominantly centered on enhancing individual stages of the smart contract lifecycle.These studies contribute valuable insights for improving specific lifecycle elements, although they frequently lack a holistic perspective, tending to focus on isolated stages rather than considering the lifecycle in its entirety, as shown in Table I.
In [11], researchers introduced an innovative method, termed the embedded smart contract way, which effectively integrates both the smart contract and its data into a single blockchain transaction.This method uniquely merges the contract execution and deployment phases, thereby eliminating the separate predeployment phase.This consolidation leads to a reduction in waiting times and associated costs, presenting a streamlined approach.However, it primarily focuses on optimizing the deployment and invocation stages, without addressing other lifecycle stages of a smart contract.Consequently, while beneficial, its applicability may be limited to specific scenarios in 6G environments.
Further expanding on this concept, Zhang et al. [16] explored the use of smart contracts in cross-chain environments, utilizing the embedded smart contract model.This approach not only streamlines the deployment and invocation phases but also introduces the concept of keyword-based embedded contracts.This innovation enhances the ease of interaction and cooperation across different blockchain platforms, boosting flexibility in multichain contexts.Nonetheless, this method also centers around the embedded smart contract Work [12] presents an innovative approach for cross-chain exchanges utilizing conditional transactions.In the blockchain context, conditional transactions are those executed based on specific, predefined conditions.This approach simplifies the integration of the predeployment and invocation stages of smart contracts, and even termination stage if its conditions match immediately.It achieves this simplicity by encapsulating the logic within a single field of a transaction, the "conditional field," rather than using a separate smart contract file.This method focuses on using conditional transactions to streamline asset transfers across various blockchains, thereby facilitating a more efficient exchange process in multiblockchain environments.Although this model improves efficiency by minimizing the steps required in cross-chain transactions, it primarily focuses on merging only certain stages of the smart contract lifecycle.
The study in [13] presents a dynamic strategy for the instantiation of smart contracts.This model advocates for the delayed instantiation of a smart contract, activating it only when there is a genuine need, and terminating it upon achieving its intended purpose.This strategy is particularly relevant given that many smart contracts often remain idle [17], thereby emphasizing efficient and purposeful usage.The instantiation and invocation processes are deferred until user demand necessitates activation.This method is especially beneficial in IoT environments, where computational resources are typically limited.By prioritizing resource optimization and enhancing execution efficiency, this strategy marks a notable advancement in smart contract technology.However, while this approach enables dynamic execution of the instantiation phase of a smart contract, it does not extend its optimization to other phases of the smart contract lifecycle.As a result, users do not have the flexibility to dynamically execute or optimize other critical stages of the smart contract process.
Collectively, these studies mark a considerable advancement in the field of smart contract lifecycle optimization.They introduce various solutions that ease the usage and implementation of smart contracts, reflecting progress in this technology.However, these approaches tend to implicitly optimize only certain aspects of the lifecycle.This collection of research serves as a foundational platform for future exploration, aiming to further enhance the optimization of the entire smart contract lifecycle.Such advancements are crucial for adapting smart contracts to the evolving requirements of IoT in the context of the emerging 6G network era and beyond.

III. OPTIMIZATION MODEL
This section describes the lifecycle optimization model, with a specific focus on enhancing the flexibility of smart contracts to accommodate the varied requirements of IoT devices.The term "flexibility" in the context of smart contract lifecycle refers to the ability to adapt and adjust the various stages and processes involved in the lifecycle of the contract.
The smart contract lifecycle encompasses the entire process, commencing with the deployment of code on the blockchain and concluding with the termination of the contract.This lifecycle is categorized into four distinct steps: 1) code uploading; 2) instantiation; 3) invocation; and 4) termination.In the first step, referred to as code uploading ("C"), users initiate a transaction, transmitting the smart contract code to the blockchain.Following the confirmation of the transaction, miners store this code in their nodes.The second step, referred to as instantiation ("I"), occurs after the code has been uploaded.Miners load the smart contract code into memory, providing relevant parameters, such as an address or handle, for external invocation.The third step, referred to as invocation ("V"), allows users to interact with the smart contract.Users transmit parameters through transactions to invoke the appropriate interface of the smart contract, enabling them to execute specific functions or operations.The fourth step, denoted as termination ("T") is the final phase in the lifecycle of a smart contract.Miners are responsible for terminating the corresponding instance of the smart contract, freeing up resources and concluding its execution.For simplicity, we will not cover the termination step initially and will address it in a separate Section III-F.
Currently, to invoke the interface of a smart contract, it must undergo preinstantiation (C and I) since the smart contract address is a prerequisite for invoking its interface, and this address is acquired during the deployment step.The deployment step instantiates the smart contract, but there is a waiting time between this step and the subsequent invocation process.Combining these steps enables the immediate invocation after Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.deployment, and eliminates the need for an external address during the deployment step.The address mechanism corresponding to this new combination method is discussed in Section III-C.It is important to note that the predeployment of the contract is not mandatory for the blockchain mining process.Instead, it is implemented to ensure the sequential execution of lifecycle steps due to their time dependency.For example, it is essential that the invocation does not precede the instantiation.Further details about this mechanism are provided in Section III-D.
The lifecycle steps of a smart contract can be executed either in a combined or separate manner.The process of uploading the contract codes to the blockchain can be combined with the creation of an instance.Similarly, the steps of creating an instance and interacting with the instance can also be combined.In the combined approach, these steps are performed together, with the deployment and invocation parameters included in a single transaction.This allows the invocation of the contract interface immediately after instantiation.Adopting the combined method reduces the waiting time for an invocation transaction to be confirmed and included in the main chain, along with the corresponding transaction fees.
Building upon the aforementioned analysis, we introduce a novel model known as the lifecycle optimization model, which provides the flexibility to consolidate multiple lifecycle steps into a single user action.In this model, users can upload code, instantiate, and invoke the interface of a smart contract in one step.Furthermore, users can selectively execute specific steps through a single invocation.The lifecycle optimization model is designed to streamline the process and improve user convenience.Fig. 1 visually represents this model, illustrating its key components and interactions.
To facilitate the lifecycle optimization model, we have implemented the following features.
1) Introduction of a new transaction type.We have created a novel transaction type specifically designed to support various lifecycle steps of smart contracts.This transaction type is characterized by fields that can hold parameters for distinct lifecycle stages, such as code uploading and invocation, thus providing a comprehensive framework for managing the lifecycle of smart contracts.2) Parameter identification.To distinguish between different parameters within the transaction, each parameter receives a unique identifier.These identifiers enable users or codes to access specific parameters during execution.3) Modified instance addressing scheme.The instance address scheme for the smart contract undergoes the following modifications.a) For invocations combined with deployment, the instance is accessed using the instance identifier.
In this scenario, the instance identifier functions as the address for accessing the instance.b) For regular invocations that are not part of the combined deployment and invocation, the instance is accessed by the address of the code-uploading transaction along with the instance identifier.

Definition 1: (Inside Invocation and External Invocation):
An inside invocation refers to a smart contract invocation that occurs within the deployment transaction itself.Conversely, when an invocation is carried out in a separate transaction, it is referred to as an external invocation.

Definition 2 (Lifecycle Optimization Model):
The lifecycle optimization model is designed to offer users the flexibility to combine or separate distinct lifecycle steps.It introduces a novel transaction type capable of encapsulating parameters for various steps within the lifecycle, employing unique identifiers to differentiate these parameters.Additionally, the model incorporates a modified address scheme to accommodate both internal and external invocations.
In the following, we will discuss several issues that are relevant to the lifecycle optimization model.These issues include potential combinations of lifecycle steps, the handling of parameters, the introduction of new address schemes, the underlying mechanisms, and the facets of code reuse.

A. Lifecycle Combination
With the introduction of lifecycle optimization model, users gain the flexibility to create multiple combinations for the lifecycle of a smart contract.The following outlines possible scenarios that a user can complete in a single step.
1) Individual Steps: The sender can choose to perform each step separately.For each step, the sender issues a corresponding transaction to trigger its execution.2) Partial Combined Steps: The sender can combine steps C (code uploading) and I (instantiation), or steps I and V (interface invocation) into one step.In the former case, both code uploading and instantiation occur simultaneously in one transaction.In the latter case, the sender can instantiate the code and invoke its interface in a single step.However, it is crucial to note that for the latter scenario, the code must have been uploaded to the blockchain beforehand; otherwise, the instantiation process will fail.

3) Complete Combined Steps:
The sender has the option to combine all three steps (C, I, and V) into a single transaction, executing them together.This approach allows for the code to be deployed to the blockchain, followed by its instantiation and subsequent interface invocation, all within one transaction.For a clear comparison of different combinations, we have included them in Table II.
Note that if a user chooses to combine steps C (code uploading) and I (instantiation) into one step, and executes step V (interface invocation) separately, it follows the traditional model where the smart contract is deployed first, and then the interface is invoked.

B. Parameter
To support the proposed model, it is essential to introduce additional fields within the transaction data structure.These fields consist of three segments, each corresponding to a specific step in the lifecycle of a smart contract.The second segment is the instantiation segment, containing parameters needed for instantiating a smart contract.If this field is present, a smart contract instance will be created according to these parameters.In cases where multiple instances are required, the sender can include all the instance parameters sequentially within this segment.
The third segment is the invocation segment, encompassing parameters needed to invoke the interface of the instantiated smart contract.If this field is present, the corresponding interface will be invoked.
1) Transaction Involving Multiple Participants: In certain cases, actions for a smart contract may involve multiple participants, and these actions can be combined using the proposed model.Therefore, the model supports parameters from various participants, aiming to combine actions from different participants.To distinguish between different participants, the address of each participant is included at the beginning of their respective parameters.To indicate the approval of the transaction by each participant, the transaction content is signed by all participants, known as the parameter signature.The parameter signature is stored within the "sender signature" field.The data structure of the new transaction is depicted in Fig. 2.
There are three main steps for the signature process for this kind of transaction.
1) The hash function HS(x) is used to generate a hash of the main body of the transaction, which refers to the content of the transaction excluding the signature part.This is represented as HS(main body).
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
2) Each participant involved in the transaction signs the main body using their private key.The signing process is performed with the function Signature(HS(main body), pk i ), where pk i represents the private key of participant i.The resulting signatures are then included in the "parameter signature" part of the transaction.3) Next, the sender of the transaction signs both the main body and the parameter signature of all participants combined.This can be expressed as Signature(HS(main body, parameter signature), pk sender ).The resulting signature is included in the sender signature part of the transaction.By following this process, the transaction ensures that the main body is signed by each participant individually, and then the sender further signs the combined main body and parameter signature.This approach provides a mechanism to verify the authenticity and integrity of the transaction data.The following is a brief proof.
1) Hash Function: The use of a hash function, denoted as HS(x), provides a one-way transformation that generates a unique hash value for the given input.Deriving the original input from the hash value alone is computationally infeasible, ensuring the integrity of the main body and preventing tampering with the transaction content.2) Private Key Signature: Each participant signs the main body of the transaction using their private key.The Signature(HS(main body), pk i ) function guarantees that the signature is generated with the corresponding private key of the participant.This ensures the authenticity and integrity of the main body, validated by the participants' private keys.3) Parameter Signature: The parameter signature section collects individual signatures from all participants, ensuring that the actions and intentions of each participant are recorded and included in the transaction.This allows for verification and auditing of the participants' involvement in the transaction.4) Sender Signature: The sender of the transaction signs both the main body and the parameter signature combined using their private key.The Signature(HS(main body, parameter signature), pk sender ) function guarantees that the sender's signature is linked to the entire transaction content, including the combined main body and parameter signature.This provides a layer of security and confirms the overall authenticity and integrity of the transaction.By combining these elements, the signature process ensures that the transaction content remains unaltered and verifies the involvement and approval of each participant.This enhances the security of the transaction and mitigates the risk of unauthorized modifications or malicious activities.

C. Address
Given that different parameters may exist in one transaction, it is necessary to introduce distinct names or identifiers to differentiate them.Consequently, the address of a smart Algorithm 1 Pseudocode for Invocation Among Different Transactions (tx1 and tx2 Are Two Different Transactions) 1: tx1: code 2: . . .The address of a smart contract functions as a unique identifier to locate the resources associated with a specific instance of the smart contract.It's crucial to clarify that this address does not refer to a memory address but rather represents a means of accessing the instance's resources.These resources include information about the process (such as process ID or PID), data related to input passing (such as invocation parameters), and methods for obtaining output (e.g., through pipes or files).To efficiently locate resources, we utilize a map called the address mapping table, which uses the address as the key to locate the corresponding resources.
With the introduction of the new address mechanism, two methods are available to specify a smart contract instance.
1) Invocation in Different Transactions: This method is used when the invocation of a smart contract function occurs in a different transaction than its deployment.In Algorithm 1, we start with two separate transactions, tx1 and tx2, each containing smart contract code.
Step 1: tx1 includes the code and identifier (id_m, line 3) for the first smart contract.
Step 2: Within tx1, we define a function "fun1" for this smart contract (lines from 5 to 7).Step 3: tx2 then invokes the function fun1 of the smart contract in tx1.This is achieved by specifying both the identifier id_m and the address of tx1 (line 13).This setup allows tx2 to interact with the smart contract deployed in tx1, using the unique identifier and address for precise targeting and execution.2) Invocation in the Same Transaction: This approach simplifies the invocation process by requiring only the identifier when the deployment and invocation occur within the same transaction.Algorithm 2 describes a scenario where both the smart contract and its invocation exist within a single transaction, tx.
Step 1: We define the smart contract with its identifier (id_m, line 3) and include the fun1 function (lines from 5 to 7) within the same transaction.
Step 2: The invocation of fun1 is then performed within the same transaction (line 11).Here, only the identifier id_m is needed to call the function.The method of invocation inside the same transaction streamlines the invocation process, making it more efficient by eliminating the need for transaction address references within a single transaction context.
The code field can also accommodate multiple smart contracts, each requiring a distinct identifier to differentiate them.Similarly, the instance field may contain multiple instantiation configurations, where each configuration represents a separate instance and possesses its own unique identifier.
In scenarios where only a single invocation is needed, the CIV method proves to be highly efficient, as it eliminates the need for a separate instance address.This method facilitates the invocation within the same transaction as the deployment, thereby removing the necessity an additional transaction address.This streamlined approach simplifies the user experience by removing the need for instance addresses.This is a notable departure from the conventional smart contract model, where typically an instance address is first obtained, and all subsequent invocations are conducted through this address.

D. Processing Procedure for Lifecycle Step Combinations
A transaction that includes a lifecycle operation is referred to as a lifecycle-containing transaction.When such a transaction is confirmed, miners take corresponding actions based on the lifecycle steps involved.
The process of handling a lifecycle-containing transaction can be divided into three steps: 1) parameter parsing; 2) correctness checking; and 3) action execution.Initially, miners search for the lifecycle operation flag within the transaction.They then analyze the lifecycle steps and their combinations.
In the second step, miners perform validity checks on these steps.This involves verifying the following.
1) The correct sequence of lifecycle steps.For example, a contract invocation should not occur before the instantiation step.
2) The completion of preceding steps.For instance, an invocation step should only be executed after the deployment step.If the validation fails, processing for the corresponding transaction is halted.The final step involves taking the appropriate actions based on the lifecycle steps.
1) If the step includes a C (code uploading) action, miners store the code in the blockchain nodes' code storage.2) If the step includes an I (initialization) action, miners load the code into memory and execute the initialization function to create an instance.Subsequently, miners create an address-handle mapping table for this instance.Additionally, to enable internal invocations using only the instance identifier, miners maintain a cache holding handles for invoking the newly created instance.3) If the step includes a V (invocation) action, miners retrieve instance handles from the cache or the addresshandle mapping table.If a matching instance is found, the invocation request and its parameters are sent to the corresponding instance.

E. Code Reuse
While all lifecycle actions are performed within the CIV method, the code itself can still be reused.Other smart contracts have the ability to utilize the code of a specific smart contract by referencing its address.As it has an address (as discussed in Section III-C) and as long as the instance is not terminated, it can be invoked with parameters if provided.
Moreover, CIV smart contracts possess the ability to invoke functions from other smart contracts.These types of smart contracts are typically designed for specific scenarios that involve frequent changes and require the invocation of code from other smart contracts.In essence, they function similarly to a scripting language that combines and executes various operating system commands.
In cases where a smart contract encompasses both reusable and changeable logic, it can be divided into two parts, each assigned a unique identifier.One part represents the reusable common logic, which can be utilized by other smart contracts, while the other part comprises the changeable logic.These two parts can still be executed together as a single step.

F. Termination Optimization
The previous discussion did not include the termination step, which we will address separately here.When there are corresponding parameters for termination, miners will execute the termination actions of smart contracts.The termination step can be combined with other steps, and the possible combinations include CIVT, CIV-T, CI-VT, CI-V-T, C-IVT, C-IV-T, C-I-VT, and C-I-V-T.
When the termination step is combined with other steps, an additional transaction can be eliminated.Particularly, if a smart contract is intended for a single-use scenario, all lifecycle steps (C, I, V, and T) can be combined into one step (CIVT).This type of smart contract is referred to as a disposable smart contract.Using the CIVT approach saves two transactionsone for deployment and the other for termination-compared to the current method of CI-V-T.

IV. ANALYSIS
In this section, we will analyze the main characteristics of the proposed model, focusing on two key aspects: 1) higher transaction utilization rate and 2) enhanced robustness.

A. Transaction Utilization Rate
Transactions associated with a smart contract can be categorized into two distinct types.The first type includes functional transactions, which are specifically utilized to invoke the functions of a smart contract, typically in step V.These transactions are integral for interacting with and leveraging the functionalities of the smart contract.Conversely, the second type encompasses nonfunctional transactions, which are related to other lifecycle steps like C (code uploading) and I (instantiation).These transactions are essential for the foundational setup and maintenance of the smart contract rather than its direct functional use.
It is helpful if we know the proportion of functional transactions.This measurement is known as the transaction utilization rate (tur), which is defined in (1).A higher transaction utilization rate (tur) indicates a larger proportion of transactions being used to trigger functions of the corresponding smart contract where n fun represents the number of transactions used to trigger functions of a smart contract (also called functional transactions), and n a denotes the total number of transactions used for the smart contract.The total number of transactions (n a ) is the sum of n fun (the number of functional transactions) and n nonf (the number of nonfunctional transactions, such as transactions used for deployment), as shown in Utilizing tur, we can compare the transaction utilization ratio across different lifecycle methods.Let's first consider the scenario with only one invocation for the smart contract.The transaction utilization ratios (tur) for the CIV, CI-V, and C-I-V methods are expressed in In the CIV method, the transaction utilization rate (tur) reaches 100%, as it requires no additional transactions beyond the initial one, which simultaneously addresses the C (code uploading), I (instantiation), and V (invocation) stages.This singular transaction for all three steps signifies a highly efficient use of resources.Conversely, in the CI-V and C-I-V methods, the tur values drop to 50% and approximately 33%, respectively.The CI-V method necessitates two transactionsone for CI and another for V, while the C-I-V method requires three separate transactions.This indicates a comparatively higher level of inefficiency from the user's perspective, with more transactions not directly contributing to the smart contract's functionality.Hence, particularly in scenarios where a smart contract's functions are invoked infrequently, the CIV method offers a more transaction-efficient alternative compared to the CI-V and C-I-V methods.
When considering the termination step, the difference becomes more pronounced If the number of functional invocations is large enough (e.g., approaching infinity), the tur of CI-V methods also tends to be close to 100%, as demonstrated in (5).While there may not be a substantial difference in this scenario, the CIV method still offers advantages.It saves time for the first invocation by eliminating the need to wait for the completion of deployment.Additionally, it saves the cost of one transaction, which can be meaningful for nonprofit projects (5)

B. Robustness Analysis
We now analyze the robustness of the proposed method in the case of a missing transaction.A missing transaction refers to a transaction that has been initially included in the main chain but later ends up in a branch due to blockchain fork, resulting in the transaction being considered as missing.
The probability of encountering a missing transaction escalates with an increase in the number of transactions involved in a smart contract's lifecycle.This is due to each transaction being sealed and processed independently in the blockchain.Suppose we consider a lifecycle comprising n transactions.Under these circumstances, we can calculate the probability of experiencing at least one missing transaction throughout the entire lifecycle.This probability, denoted as p lfc missing , represents the chance of encountering a missing transaction at any point during the lifecycle process.The calculation of p lfc missing is formulated using the equation shown in where p tr missing is the probability that a transaction is missing.A missing transaction can result in an error case where a transaction (ith transaction) depends on another transaction (jth transaction) that should have occurred at a specific time but is missing due to a blockchain fork.In this scenario, the ith transaction is considered an error transaction.Error transactions can be used as a measure of the robustness for a blockchain.
The number of error transactions is related to the number of transactions in the lifecycle.For simplicity, let's assume that transactions in the lifecycle of a smart contract depend on their preceding transactions, and we arrange these transactions in a dependence order.Consider a scenario where the first missing transaction occurs at position i, and it is followed by n subsequent transactions that are dependent on it.In this case, the total number of possible error transactions (e n i ) is n, as all these (n) transactions depend on transaction i, as illustrated in As an example, let us consider the C-I-V method, where transactions V and I depend on transaction C.If transaction C is missing, there will be two error transactions: 1) transaction V and 2) transaction I.On the other hand, if transaction I is missing, there will be one error transaction, which is transaction V.
To calculate the total number of possible error transaction cases (en), we need to consider all transactions in the lifecycle.
Since each transaction has the potential to be the first missing transaction, we sum up the possibilities.Assuming there are N transactions used in the lifecycle, the total number of possible error transactions, en, can be expressed as shown in Equation ( 8) provides a means to analyze the robustness of different lifecycle methods.Let us first discuss the case when there is only one functional invocation (n fun = 1).In the C-I-V method, with N = 3, there are three possible error transactions (en = 3).However, in the CIV method, with N = 1, there are no error transactions (en = 0).Now let's consider two cases when the number of functional invocations is more than 1.
1) There is a relatively small number of functional invocations (n fun = 6).The C-I-V method entails 8 transactions in total (with two additional lifecycle transactions), leading to 28 potential error transactions (en = 28).In contrast, the CIV method, under the same conditions, results in a lower count of 15 error transactions (en = 15).2) There is a relatively large number of functional invocations (n fun = 100).The C-I-V method, which incorporates 102 transactions (including two additional lifecycle steps), could lead to as many as 5151 error transactions (en = 5151).Meanwhile, the CIV method, even with a high number of invocations, maintains a relatively lower error count at en = 4950.Since the value of en is high in the C-I-V method, it is crucial to ensure an adequate waiting time before invoking functions to ensure the correct deployment of the smart contract.

A. Test Environment
The verification process is conducted on our customdeveloped blockchain platform, UscIoV,1 specifically tailored to facilitate the lifecycle optimization model for smart contracts.This platform is designed to handle the four key lifecycle stages of a smart contract: 1) code uploading (C); 2) instantiation (I); 3) function invocation (V); and 4) termination (T).

1) Blockchain Configuration:
The following outlines the configuration for the blockchain used in verification.
1) Consensus Algorithm: The blockchain operates on a Proof of Work (PoW) consensus mechanism.We have configured the mining difficulty to require the block hash to commence with six zeros.This configuration typically results in a block mining time of several seconds within our testing environment.2) Smart Contract Runtime Environment: Embedded smart contracts in our system are developed using Java, allowing them to leverage the existing java runtime environment (JRE) of the blockchain.To guarantee the determinism and immutability that are essential for smart contracts, we impose strict limitations on their functionality.Specifically, any access to external systems, such as network connectivity, as well as nondeterministic functions like random number generation or clock access, are strictly prohibited.Instead, only a set of predetermined, secure functions are allowed.To enforce this, we employ a prescreening module that rigorously checks and verifies that each smart contract only utilizes these approved functions, ensuring compliance with our deterministic and immutable design requirements.3) Gas Fee Unit: For transactional purposes, we utilize a smaller unit of internal coins, termed as lu.This is similar to Ethereum's approach, where wei is used alongside the primary unit Ether.The conversion rate is set at 1 internal coin = 10 6 lu.2) Hardware and Software Setup: The following details the hardware and software configuration of the blockchain.
1) Node Configuration: Our blockchain network is composed of 64 nodes (virtual machines).These virtual machines are hosted on four distinct workstations.The configuration of these workstations is as follows: a) One HP workstation (Model: Z2G4 TWR Desktop Graphics Workstation), equipped with an Intel Core I9-9900 CPU and 64 GB of memory, providing robust processing power.b) Two Dell workstations (Model: PowerEdge T130), each powered by Intel Xeon CPUs E3-1220 v5 @3.00 GHz and bolstered with 32 GB of memory, ensuring efficient and reliable performance.c) One Lenovo workstation (Model: ZHENGJIUZHE JIMAX-34ASU), featuring an AMD Ryzen 7 1800X Eight-Core Processor @3.60 GHz and 16 GB of memory, adding to the diversity and strength of the network's computational resources.2) Operating System: The nodes operate on Ubuntu 18.04 LTS, which provides a stable and reliable environment.
To support UscIoV, which is developed in Java, each node is equipped with JRE version 1.7.This ensures compatibility and efficient functioning of the blockchain system.3) Computational Resources: The following outlines the computational resources.a) Memory Resources: The virtual machines are equipped with varied memory capacities, ranging from 1 GB to 8 GB.b) CPU Resources: Each machine is powered by 1, 2, or 4 virtual CPUs, operating at a speed of 3.00 GHz.c) Network Architecture: Our blockchain network is structured as a peer-to-peer (P2P) system, operating within an internal network.This setup guarantees stable network conditions and consistent performance.To simplify the network architecture, we employ a fixed topology approach.This means that the addresses of the peer nodes are predetermined and preconfigured in a specific file, eliminating the need for dynamic discovery of peer nodes.

3) Implementation of Smart Contract Lifecycle:
The following details the implementation of the Smart Contract lifecycle.
1) Transaction Structure: In our verification process, we utilize the data field of blockchain transaction for storing lifecycle parameters.These parameters are identified with the prefix "lfo."To accurately represent different lifecycle stages, we employ specific keywords: C indicates code uploading, I signifies instantiation, V is used for invocation, and T represents termination.Each lifecycle stage parameter is formatted as key-value pairs, demarcated by a colon (":").To further refine the handling of these parameters, particularly for those that vary in length, we introduce a length indicator marked as "<length>."Consequently, the format for lifecycle parameters is established as "<key><length>:<value>."For example, a lifecycle structure could be as follows.

B. Comparison of Different Lifecycle Methods
In this section, we compare different lifecycle methods, considering their processing time and costs, which reflect the various steps involved in the lifecycle.
The verification smart contract is a simple Java class, consisting of 244 characters encoded in Base64.During the code uploading stage, the smart contract is restored by decoding the Base64 representation.In the instantiation stage, the blockchain platform creates an instance of the intended smart contract.In the invocation stage, we invoke the interface named "Interf1" within the smart contract, containing a function that records the number of triggers received, acting as a counter that increments by one with each invocation.
Five lifecycle methodologies are examined in our study: CIVT, CIV-T, CI-V-T, C-IV-T, and C-I-V-T.Specifically, the CIV-T, CI-V-T, and C-IV-T methods align with the lifecycle approaches presented in work [11], the standard practice currently employed in Ethereum, 2 and the strategy introduced in work [13], respectively.For clarity in our comparative analysis, these methods are also named as Compare1, Compare2, and Compare3.Meanwhile, since the Compare2 (CI-V-T) method is utilized within Ethereum, we refer to it as the conventional method.The other two methodologies, Compare1 and Compare3, are explored as research alternatives aimed at enhancing this conventional approach.
We executed 128 testing rounds.In each testing round, we carried out the lifecycle stages C (Code uploading), I (Instantiation), V (Invocation), and T (Termination).Depending on the approach used (CIVT, C-IV-T, CI-V-T, or C-I-V-T), the lifecycle may require one transaction (as in the CIVT approach), two transactions (CIV-T), three transactions (as in C-IV-T or CI-V-T approaches), or four transactions (as in the C-I-V-T approach).We employed a script to determine and send the next transaction, aiming to eliminate unnecessary waiting intervals between steps.
1) Processing Time: In this section, we aim to compare the processing time across different lifecycle methods.The processing time (T processing ) is measured from the moment the first transaction is sent until the invocation process is completed.This processing time can be divided into two components: 1) the time required for mining the transaction(T mining ) and 2) the time consumed by the lifecycle actions (T action ), as illustrated in During our verification process, we noted that T mining significantly influences the overall processing time (T processing ).In our verification environment, it typically takes several seconds to include a transaction in the blockchain (T mining ).Conversely, the processing time (T action ) for actions, such as C, I, V, or T, is considerably shorter, usually less than 100 ms, on the verification blockchain nodes.This is due to the fact that the invoked smart contract function primarily involves recording logs, which is a relatively quick operation.
Fig. 3 illustrates that the CIVT method exhibits the lowest processing time among the five methods, with its curve consistently at the bottom.The processing time for the CIVT method ranges from 10 s (in the 12st round) to 52 s (in the 16th round).In contrast, the compared method, CIV-T(Compare1), C-IV-T(Compare2) and CI-V-T(Compare3), fall in the middle in terms of their respective curves.However, the C-I-V-T method demonstrates the highest waiting time values, characterized by significant peaks and substantial fluctuations.The processing time ranges from 59 s to 152 s in the C-I-V-T method.Fig. 3 indicates that the C-I-V-T method is the most time-consuming among the five methods.Conversely, the CIVT method stands out as the most time-saving approach.
The comparison of average completion times also illustrates the efficiency trend among the methods.The C-I-V-T method records an average completion time of 97.06 s, which is substantially longer than the 76.38 s average for the CI-V-T method.The C-IV-T method shows a slightly shorter average time of 74.63 s.In comparison, the CIV-T method averages at 50.39 s.Notably, the CIVT method outperforms all others with the shortest average completion time of just 24.38 s, underscoring its superior efficiency in processing.Consequently, the ranking in terms of processing speed is as follows: C-I-V-T > CI-V-T ≈ C-IV-T > CIV-T > CIVT.Quantitatively, the CIVT method achieves a 74.89% improvement in processing time over the C-I-V-T method.When compared to the C-IV-T method (referred to as Compare3), the CIVT method shows a gain of 67.33%.Additionally, it outperforms the CI-V-T method (Compare2, the conventional method) with a 68.09% improvement and surpasses the CIV-T method (Compare1) with a 51.63% gain.
The variation in processing time reflects the difference in the number of transactions involved in the lifecycle.In the CIVT method, only one transaction is involved, resulting in the shortest processing time.Conversely, the C-I-V-T method requires four transactions, leading to the longest processing time.The other three methods involve two or three transactions, resulting in a moderate processing time.
To further elucidate the differences observed in processing time, Dunn's test was employed as a post-hoc analysis following the Kruskal-Wallis H test.This nonparametric approach is particularly suitable for comparing the median values of groups without the assumption of normal data distribution.After identifying significant differences among the five methods (C-I-V-T, C-IV-T, CI-V-T, CIV-T, and CIVT) with the Kruskal-Wallis H test (p-value = 2.37e-25), Dunn's test was utilized for detailed pairwise comparisons.The results, as detailed in Table III, reveal differences between certain lifecycle method pairs.The CIVT method outperforms C-I-V-T (p = 5.28 × 10  efficiency gains of the CIV-T and CIVT methods over the C-I-V-T, C-IV-T, and CI-V-T methods. 2) Processing Fee: In this section, we analyze and compare the processing fees associated with different lifecycle methods.As suggested in [18] and [19], reducing the number of transactions used can lead to cost savings in terms of transaction fees.
The processing fee, denoted as Fee process , is composed of two main components: 1) the transaction fee (Fee transaction ) and 2) the smart contract fee (Fee smartContract ), as outlined in (10).In the following, we will describes Fee transaction and Fee smartContract : Fee process = Fee transaction + Fee smartContract . ( The Fee transaction represents the reward given to the miner for processing the transactions involved in the lifecycle of a smart contract.It is the sum of each individual transaction, as defined in Fee transaction = n i=1 Fee tr i (11) where n is the total number of transactions used in a lifecycle method, tr i denotes the ith transaction, and Fee tr i is the fee associated with transaction tr i .The Fee smartContract represents the cost associated with executing a smart contract, as defined in (12).In theory, it should be directly proportional to the computational resources utilized by the smart contract.However, for simplicity, we calculate this fee based on the file size, making it proportional to the number of lines in the source code file, denoted as fileSize.Additionally, Fee smartContract is influenced by gasPrice, representing the user-selected price paid for each line of the smart contract.The verification script dynamically adjusts gasPrice in response to the workload of the sending node.Specifically, when the CPU usage of the sending node is high, gasPrice increases to regulate the transaction sending speed Fee smartContract = gasPrice * fileSize (12) where gasPrice represents the expense associated with processing a single line of the source file and fileSize denotes the total number of lines in the source file.
It is crucial to acknowledge that the adjustment of gas prices based on the workload of the sending node assumes an effective and fair mechanism for determining gas prices.In practical scenarios, gas prices can be influenced by various factors, including market dynamics and miner behavior.However, for the specific focus of our study on the impact Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply. of different lifecycle methods, we deliberately disregard these external factors that do not directly reflect the influence of the lifecycle method.This simplification allows us to maintain a targeted analysis of the impact of different lifecycle methods on processing fees.
The processing fee results are presented in Fig. 4. From Fig. 4, it can be observed that the CIVT method exhibits the lowest fee, while the C-I-V-T method has the highest fee.The other three methods, CI-V-T, C-IV-T and CIV-T, have moderate fee.The order of the processing fees is as follows: Quantitatively, the average processing fees are 1774.19lu, 2755.21lu, 3753.40 lu, 3689.56 lu, and 4730.15lu for CIVT, CIV-T(Compare1), CI-V-T(Compare2), C-IV-T(Compare3), and C-I-V-T, respectively.The CIVT method shows a performance decrease when compared to the other methods: it exhibits a 62.50% decrease in gas fees over C-I-V-T, a 51.92% decrease compared to C-IV-T, a 52.72% decrease relative to CI-V-T (the conventional method), and a 35.63% decrease relative to CIV-T.
Furthermore, we conducted a statistical analysis.Upon identifying significant differences among the five methods (C-I-V-T, C-IV-T, CI-V-T, CIV-T and CIVT) using the Kruskal-Wallis H test (p-value = 2.13e-30), we still employed Dunn's test for more detailed pairwise comparisons.The results, presented in Table IV.From the table, we can see that the CIVT method demonstrates an obvious processing fee saving over the C-I-V-T (p = 2.17 × 10 −27 ), C-IV-T (p = 2.55 × 10 −10 ), and CI-V-T (p = 9.15 × 10 −12 ) methods, and a slightly processing fee saving over CIV-T (0.0573).This indicates that the CIVT approach reduces processing fee compared to these methods.
This difference in cost can be attributed to the varying number of transactions used (n in (11)).In the C-I-V-T method, there are four transactions (n = 4), resulting in four Fee transaction charges.As a result, the processing fee exceeds 4000 lu (processing fee for one transaction is at least 1000 lu in our verification blockchain).The minimum recorded  value is 4308 lu during the 6th round of testing.In contrast, the CIVT method involves only one transaction (n = 1), resulting in a relatively lower cost.The highest processing fee observed for this method is 1885 lu during the 18th round of testing, which is lower than that of the C-I-V-T method.
Despite the noticeable difference in the overall cost, there is not much variation in the fee required to process the smart contract (Fee smartContract ).This is because the processing of smart contract files and the required actions, such as decoding and storing the smart contract code, are similar across the different methods.To verify this, we subtract the Fee transaction from the aforementioned data.The resulting Fee smartContract values are depicted in Fig. 5.
The average gas fees required to process the smart contract for the different methods range from just over 700 lu to slightly below 771 lu.Specifically, the average fees stand at 743.15 lu for C-I-V-T, 702.56 lu for C-IV-T, 766.40 lu for CI-V-T, 768.21 lu for CIV-T, and 770.78 lu for CIVT.The maximum variation in average processing fees is limited to 68 lu.This fluctuation is largely attributed to the changes in resource demand, where higher gas prices are applied during periods of increased resource usage, and conversely, lower gas prices are set when the resource burden is reduced.
Based on the aforementioned results, we can conclude that the CIVT method provides the most cost savings by minimizing the number of additional transactions.In comparison, the CIV-T CI-V-T and C-IV-T methods incur higher processing fees due to the inclusion of an extra transaction.The C-I-V-T method, while not reducing any fixed processing fees, has the highest overall fee.
The above analysis covers the total cost from deployment to invocation.However, in practical scenarios, it is advisable to adopt different strategies based on the frequency of invocations.For smart contracts where termination, invocation, deployment can be executed simultaneously, employing the CIVT method allows for the combination of deployment, invocation and termination, resulting in savings of two transaction fee.In cases where it is uncertain whether a smart contract will be invoked (as seen in approximately 67.5% of smart contracts that have never been invoked in Ethereum [17]), adopting the C-IV-T or C-I-V-T method can save costs by running the deployment actions only when there is no invocation.If invocations occur later, the first user invocation triggers both the instantiation and the subsequent invocations, ensuring cost efficiency without wasting resources.

VI. CONCLUSION
This article addresses the intricate demands of diverse scenarios within 6G networks, where devices exhibit varying processing needs.The traditional smart contract model, which includes a predeployment phase, struggles to adapt to the dynamic requirements of 6G.Our proposed method provides a flexible solution, allowing the combination or separation of different lifecycle stages based on specific scenario needs.For instance, in scenarios involving devices with short lifespans, our approach enables the seamless integration of code deployment, instantiation, invocation, and termination into a single operation, thereby eliminating the requirement for long-term persistence of smart contracts.
Our method is suitable for environments requiring reduced processing time, lower costs, or the immediate use of smart contracts without the need for predeployment.This includes smart home systems, industrial IoT in manufacturing, agricultural monitoring, retail inventory management, and urban infrastructure management.By selectively employing various lifecycle optimization methods, our approach can effectively reduce processing fees, time, or both, depending on the specific requirements.
One limitation of the current smart contract technology, especially in the evolving context of 6G networks, is the simplistic approach toward lifecycle optimization, which primarily focuses on processing time and fees.This approach does not sufficiently account for the complex interplay of network dynamics, user behavior, and environmental conditions that are critical in 6G environments.To address this, future research should aim to develop more sophisticated optimization strategies for smart contract lifecycles.These strategies should extend beyond basic metrics to encompass a broader spectrum of factors, thereby enhancing both efficiency and adaptability in the fast-evolving 6G landscape.Additionally, the integration of smart contracts across diverse blockchain platforms presents a notable challenge due to the anticipated variety of blockchain systems in 6G scenarios.This lack of interoperability and lifecycle management optimization hampers efficiency.Future work should, therefore, explore the integration of crosschain technologies with lifecycle optimization.By focusing on interoperability and optimizing lifecycle management across different blockchain systems, advancements can be achieved, improving the overall efficiency and resilience of smart contracts in 6G networks.

Manuscript received 30
November 2023; revised 30 January 2024 and 6 March 2024; accepted 28 March 2024.Date of publication 2 April 2024; date of current version 26 June 2024.This work was supported in part by the National Natural Science Foundation of China under Grant 61772352; in part by the National Key Research and Development Project under Grant 2020YFB1711800 and Grant 2020YFB1707900; in part by the Science and Technology Project of Sichuan Province under Grant 2019YFG0400, Grant 2020YFG0479, and Grant 2020YFG0322; and in part by the Research and Development Project of Chengdu under Grant 2019-YF05-01790-GX.(Corresponding author: Hong Su.)

Fig. 1 .
Fig. 1.Lifecycle optimization model.Users can select to run "C," "I," and "V" separately or in a combined way.

Fig. 2 .
Fig. 2. Transaction data structure designed to accommodate parameters from multiple participants.The main body section holds the parameters contributed by the different participants.Function "HS(x)" represents a hash function used to generate a hash of x.On the other hand, the function Signature(m, pk n ) is used to sign the content of m with the private key of participant n .
"lfo<length>:C<length>: <code>, I<length>: <instance name>, V<length>: <invocation parameter>, T<length>: <instance name>."2) Lifecycle Parameter Validation: During the processing of transactions that contain lifecycle parameters, these parameters undergo a validation process: Miners extract key-value pairs from the transaction data field to identify lifecycle steps and parameters.If lifecycle steps and parameters are found, miners validate the combination of lifecycle steps.Valid combinations are C, CI, CIV, and CIVT if the smart contract code has not been stored in the blockchain.Similarly, valid combinations are I, IV, and IVT if the code has already been stored.Only V and VT are considered valid if the instance has been created.Incorrect sequences, such as IC, VC, or VI, are rejected.

Fig. 3 .
Fig. 3. Comparison of completion time across different lifecycle methods.

TABLE I COMPARISON
OF SMART CONTRACT LIFECYCLE OPTIMIZATION METHODS concept, sharing similar limitations in terms of lifecycle stage optimization and thus inheriting the associated drawbacks.

TABLE II COMBINATIONS
OF DIFFERENT SMART CONTRACT LIFECYCLE STEPS

TABLE III DUNN
'S TEST RESULTS FOR PAIRWISE COMPARISONS OF PROCESSING TIME

TABLE IV DUNN
'S TEST RESULTS FOR PAIRWISE COMPARISONS OF PROCESSING FEE