A Reuse-Oriented Visual Smart Contract Code Generator for Efficient Development of Complex Multi-Party Interaction Scenarios

Abstract

Multi-party interaction scenarios usually involve interaction and collaboration between multiple participants, such as business negotiation, teamwork, etc. In multi-party interaction scenarios, trust mechanisms are needed to ensure the use of rights and the fulfillment of obligations. The use of blockchain and smart contracts to establish a decentralized trust mechanism is a solution. The development process of smart contracts may require experts in different fields to design them together, and it is difficult for non-experts to understand smart contract code. The traditional method of smart contract development is for the developer to manually write the smart contract code, which may lead to low development efficiency and the inability of the scene participants to understand the smart contract code. To address this challenge, we propose a reuse-oriented visual smart contract generator to efficiently develop complex multi-party interaction scenarios. This paper proposes a model based on BPMN that uses smart contracts to express the process of multi-party interaction so that the parties in various domains understand the business requirements. Then, a multi-layer reusable library is proposed and used to generate a visual solidity code. We also integrate code compilation, security checking, and deployment into the target blockchain environment for testing. The function of the tool is verified in the case of flight delay insurance, which shows that it can aid the automated development of smart contracts for multi-party interaction scenarios. At the same time, the feasibility of the tool is verified by five cases selected from the literature, which shows that it can aid the development of smart contracts to achieve a high degree of reusability.

1. Introduction

In the present digital era, numerous economic and social activities involve multi-party interactions, such as online marketplaces, supply chain management, and the Internet of Things. In these multi-party interaction scenarios, the lack of trust between participants (such as buyers, sellers, suppliers, consumers, etc.) is aggravated because they may experience problems such as information asymmetry, fraud, false evaluation, etc. These problems can affect the security and efficiency of transactions and reduce the confidence and enthusiasm of participants. Since different participants may not be directly connected to each other, specific mechanisms are needed to establish and maintain trust relationships to ensure the safety and effectiveness of the interaction process. It is challenging to guarantee trust in multi-party interaction scenarios, and one of the main reasons is the lack of an effective supervision mechanism. There is usually no authoritative third-party organization to supervise and manage participants, which makes it difficult to establish an effective trust mechanism between participants.

With the emergence of blockchain and smart contract (SC) technologies, people have begun to explore the use of these technologies to solve the trust problem in multi-party interaction scenarios. Blockchain is a decentralized, distributed ledger technology that can record various types of transaction information [1]. An SC is an automatically executed computer program that can define and enforce rules and terms between two or more parties [2]. Blockchain and SC technologies have the advantages of non-tampering, transparency, decentralization, and autonomy, so they are considered powerful tools to build reliable trust mechanisms. Therefore, SCs can be used to solve trust problems in different domains involving multi-party interaction scenarios, such as financial transactions, supply chains, and legal contracts. At present, SC is being increasingly widely used as the key technology in blockchain to solve the problem of the lack of trust. Various types of platforms support the development of SCs, such as Ethereum and Hyperledger Fabric [3].

The insurance industry faces trust problems, and the emergence of blockchain and SC technology provides a solution to this. The process of purchasing flight delay insurance and obtaining compensation is illustrated in Figure 1. In a real-life scenario, users may purchase airline tickets from airlines and potentially purchase flight delay insurance from insurance companies. The Civil Aviation Authority (CAA) is responsible for formulating flight departure plans and recording the actual takeoff and landing times of flights. If users encounter flight delays or cancellations after purchasing flight delay insurance, they can file a claim with the insurance company. Users need to provide relevant supporting documents, such as tickets, flight delay notifications, and actual departure and landing times. The insurance company will assess the legitimacy of the claim based on the terms of the contract and the claim requirements. The claim will undergo a manual review, and, if it meets the criteria, the insurance company will provide compensation. During this process, the insurance company’s review time may be lengthy, and there is a possibility that they will deceive the user. If the insurance company denies the claim, the user may need to file a lawsuit against the insurance company in court, to ensure that their rights are protected. This process can be time-consuming and requires a significant amount of effort.

The emergence of blockchain technology can address the trust issues in the aforementioned context. The compensation ratios of insurance policies formulated by insurance companies are reflected in the form of SC code. The takeoff and landing times of flights are also recorded on the blockchain through a unified system managed by the Civil Aviation Authority. Following the actual landing of a flight, an automated SC is executed to compensate orders that exceed the stipulated delay time. By utilizing SCs for automated compensation, the cumbersome processes of manual submission, verification, and approval are eliminated. Consequently, insurance companies are unable to deceive consumers, thereby safeguarding the trust between insurance companies and users. Fizzy [4] is an insurance service that covers flight delays and aims to provide a decentralized insurance solution settled on the Ethereum blockchain via open-source SCs. This study extracts the key multi-party interaction scenarios in purchasing flight delay insurance and obtaining compensation. This case will be used in this paper to illustrate the method proposed to generate SCs automatically.

Since SCs are interdisciplinary in nature, different practitioners, such as lawyers, computer engineers, business and finance experts, and others from different fields, can collaborate to design, propose, and implement SCs [5]. At present, the mainstream method used to write SCs is technology-related. The current, most popular SC languages (such as Solidity [6] and Vyper [7]) are mainly intended for technical personnel and are not easy to understand, which makes them difficult for non-IT professionals to use. According to the CoinGeco survey [8], only 40% of users of decentralized finance can read and understand the source code of smart contracts. Therefore, it is difficult for these people to participate in the development process of SCs. Professional developers of SCs may also fail to understand the requirements of the domain, resulting in the development of SCs with requirement errors. In addition, the manual development method will also lead to problems such as low development efficiency. To address these issues, we devise three research questions.

• RQ1: How can we model the requirement scenarios and interaction relationships of SCs so that they can be easily understood and used by both business personnel and developers?
• RQ2: How can we automatically generate SC codes based on the process and interaction models in a reusable way?
• RQ3: How can reusable libraries be maintained in an efficient, low-barrier way to support RQ2’s automatic code generation?

The main contributions of this paper are summarized as follows.

1.1. The Model Based on BPMN Integrated SC Interaction

To solve RQ1, we propose an interaction model based on Business Process Modeling Notation (BPMN). In Chapter 3 we describe an example, which clearly illustrates the multi-party interaction scenarios when using SCs. Other domain experts who are not developers can understand the logic of SCs with our model and thus integrate their domain knowledge to co-design SCs.

1.2. Multi-Layer Reusable Library and Mapping Rules

To solve RQ2, we propose a multi-layer reusable library, in which two layers can be reused. We define the mapping rules from model to code so that a complete SC code can be generated from the model. The composite function layer is divided by domain to support the specific needs of different domains. Through the combination of different layers, new composite functions are formed to support the changing business logic.

1.3. Visual Maintenance of Multi-Layer Reusable Library

For RQ3, to improve the programming speed and efficiency, we use Google Blockly (https://developers.google.cn/blockly, accessed on 1 December 2022), a JavaScript library for visual programming editors, to implement the visual customization of Solidity’s standard logical structure to generate functions, and to automatically generate SC codes by visual configuration. The use of drag and drop to write Solidity code to populate the reusable library lowers the developer level barrier. We develop a tool that supports security checking, code compilation, and deployment in the target blockchain environment.

The remainder of this paper is organized as follows. In Section 2, we introduce the related work. In Section 3, we describe the system design in detail. In Section 4, we present the details of the experimental settings and the results, as well as the comparison with up-to-date tools. In the final section, we present the conclusions and future work.

2. Related Work

We summarize related studies from two aspects: business modeling based on BPMN for SC and methods of automatic SC generation. We compare these methods in Section 4.

2.1. Business Modeling Based on BPMN for SC

BPMN models devise business process diagrams to describe operations in a business. BPMN models can be encoded and parsed, so we can obtain various types of information about multi-party interaction scenarios, such as rules, execution processes, participants, etc. However, the BPMN model only considers the process behavior of the system, without considering the implementation mode, and, in practical applications, the system may be subject to external disturbances, so it cannot guarantee that all stakeholders trust the process. A lack of trust will hinder the collaborative process and affect its success [9]. Therefore, combining BPMN with blockchain is a suitable approach.

Weber et al. [10] propose an approach that integrates blockchain into the orchestration of BPMN models so that no central authority is needed to maintain trust. Our approach is similar to this in the sense that we also use models based on BPMN to express business processes. However, Weber et al. focus on monitoring the process in the model, while we focus on generating the task expression of the complete code. The BPMN model has also been used as a mediator to generate SC code [11]. However, the authors of the paper note that SCs generated in this way have some limitations, such as the fact that user tasks still need to be written manually.

2.2. Automatic Code Generation of SC

One possible means to enable people from multiple domains, not merely IT, to co-create SCs is to adopt existing modeling languages, express business requirements as specific models, and translate the models into SC code through rule mapping. Skotnica et al. [11] present an approach to creating model-driven blockchain SCs. Their proposed approach consists of building a metamodel of SCs and an algorithm to automatically generate SCs using this model. They obtained a metamodel for SCs using an extended subset of BPMN 2.0 level 3. Compared with our work, the main limitation is that they do not express the interaction relationship in the business, and the verification logic of script tasks and user tasks still needs to be completed manually. Qin et al. [12] define a common representation of complex natural language contracts for people from diverse backgrounds, uniformly translating human-readable sentences and disambiguating language. They propose a contract model called the Intelligible Description Language Contract (IDLC), which makes the SC readable by computers and understandable by humans, eliminating the ambiguity of SCs. Similar to us, they mention the need to coordinate interactions between independent entities in contracts, which is reflected in our work. Differing from our work, their focus is on the construction of the model, i.e., to establish a unified contract model so that the participants can reach a consensus, but the code generation based on the model is lacking.

Many researchers are also studying the use of domain-specific language methods to describe business requirements and transform domain-specific language into SCs. Wohrer et al. [13] designed a domain-specific language called the Contract Modeling Language (CML) to describe the components of SCs and generate SCs according to the CML. The CML is close to natural language, with syntax that incorporates coding abstractions, as well as the automatic integration of design patterns that are common in the code generation process. This language makes the representation of SCs more understandable both conceptually and syntactically. Compared to our work, this method may not be intuitive for the expression of business requirements, and it has certain requirements for the person who writes the CML code, making it less appealing to those who are not familiar with CML syntax. Tateishi et al. [14] proposed a method based on document templates and Domain-Specific Language for SC (DSL4SC) templates to realize the automatic generation of SCs. This is an approach that combines domain-specific languages and templates, and the parameter mapping between the document template and the DSL4SC template constitutes the SC template. Compared with our method, although this template-integrated method is more intuitive than the method using domain-specific language directly, it lacks flexibility.

In addition, the tool used to build visualizations also allows us to automatically generate SCs, enabling users to generate SCs through configuration options in a user-friendly user interface (UI). Google Blockly is a commonly used tool that provides a drag-and-drop, composable programming environment that enables users to build programs by dragging and connecting graphical blocks of code [15]. This visual means of programming makes it more intuitive and easy to understand. Guida et al. [16] present a prototype SC registry for the searching and discovery of SCs, and they develop a visual programming environment based on Google Blockly, equipped with basic Solidity instructions. The construction of more complex aggregation instructions is supported. Mao et al. [17] use a clustering algorithm to extract features from the dataset captured by the SC program. Char-RNN (improved by LSTM) is used to automatically generate unified basic function codes based on domain features. At the same time, in response to the above results, a visual programming platform based on Google Blockly is proposed for users, so that they can interact with the platform through a visual interface and design SCs. The benefit of the visual programming environment is that IT can improve the development efficiency, but it still requires the designer of the SC to possess certain technical knowledge. Moreover, compared with our work, the use of only a visual programming environment is limited; it cannot reflect the business requirements. In our work, the visual programming environment is part of the content and is combined with business modeling to jointly generate SC codes.

To summarize, the existing automated SC generation methods have the following limitations: (1) they cannot present the business processes of SCs to users while reflecting reusability; (2) the interactions among stakeholders, between SCs, and between stakeholders and SCs are not depicted; (3) many approaches fail to generate fully deployable SCs; (4) few methods integrate the essential security checking functions of SCs.

3. Method

3.1. Model Based on BPMN-Integrated SC Interaction

The focus of SC modeling is on the description of the interactions between stakeholders and SCs. BPMN is a widely adopted language to model business processes. However, it is not fully suitable for SC-oriented business process modeling, so we use a limited set of BPMN elements, namely Activity, SwimLane, and Connecting Object of BPMN 2.0, and we customize the meaning of the elements. It connects business people and developers, specifically designed to describe multi-party interactions. The abstract representation of the model based on BPMN as shown in Figure 2.

• Activity There are three types of activities:

  -

  UserTask: This represents the users’ actions in external systems, which do not occur on the blockchain, and some of these tasks will invoke the current SC.

  -

  ScriptTask: This action is performed by the current SC, and it corresponds to a composite function.

  -

  ServiceTask: This action needs to invoke behaviors in other SCs, and it can be regarded as an interaction within the blockchain.

• Swimlane
  We design three types of swimlanes, i.e., Participant, Current SC, and External SC. As shown in Figure 2, at the top of the swimlane is the behavior of the Participant. User tasks are modeled in the Participant swimlane; because this type of task is run in an external system, it will not be resolved. Service tasks are modeled in the external SC swimlane, which represents the external SC behavior that the current SC needs to call. The middle part is the current SC swimlane, which is the core of the BPMN model, storing all script tasks of the current SC.
• Connecting Objects

  -

  Message Flow: There are two types of message flow. The first type is the interaction between the user task and script task, which describes the interaction between the user and the SC. The second type is the information interaction between the script task and service task, which represents the invocation of external SCs, as shown in the message flow on the left side of Figure 3.

  -

  Sequence Flow: There are two types of sequence flow. The first type is used to specify the order in which activities are executed. The second type is the interaction between two script tasks in the same swimlane, representing the call relationship. It should be noted that when two script tasks interact, the number on the task flow indicates the execution order of the invocation relationship, and the small number indicates the initiator of the invocation behavior, as shown in the sequence flow on the right side of Figure 3.

Figure 3. BPMN connecting objects.

Figure 3. BPMN connecting objects.

We developed a UI modeling tool based on BPMN-JS (https://bpmn.io/toolkit/bpmn-js/, accessed on 1 October 2022) and extended the properties panel to support binding tasks and composite functions. Figure 4 is an example showing how our proposed modeling rules can be used to model the flight delay insurance scenario described in Figure 1.

To achieve the scenario of automatic compensation for flight delays, we use three proposed models. The first model is relatively simple, and we do not present it here. It represents the insurance company’s process of maintaining insurance. It includes functions such as adding new insurance, discarding insurance, checking insurance validity, obtaining the percentage of compensation, and verifying the cancellation time.

The second model based on BPMN, shown in Figure 5, depicts the process of the insurance company registering with the CAA. Firstly, the insurance company needs to submit a registration application to the CAA and provide the necessary supporting documents. Once the application is approved, the CAA will initialize the insurance company through an SC. Additionally, the insurance company transfers a deposit to the SC to support future compensation.

The third model based on BPMN, as shown in Figure 4, consists of two SCs: the current SC, which is responsible for automated compensation execution, and the external SC, which maintains the insurance. The process begins with the user purchasing insurance for their flight; the CAA provides the relevant flight information, and the current SC verifies the validity of the insurance by calling the external SC. If the check passes, the current SC records the purchased insurance for the user. Within a specified timeframe, the user has the option to cancel the insurance. In such cases, the current SC checks if the user has purchased insurance and calls the external SC to verify whether the cancellation falls within the allowed time limit. If the requirements are met, the current SC cancels the insurance. The CAA is responsible for recording and maintaining the takeoff and landing times of flights. After a flight lands, the CAA inputs the landing time, and the current SC uses the actual landing time to determine whether compensation is required. If compensation is necessary, the current SC calls the external SC to query the percentage of the compensation. Subsequently, the SC automatically transfers the compensation amount to the user.

3.2. Multi-Layer Reusable Library and Mapping Rules

To solve RQ2, we propose a multi-layer reusable library and define the composition between the different layers, as shown in Figure 6. We model real-world scenarios with SC interactions as models based on BPMN in a manual manner, following our modeling rules. An SC may consist of one or more interaction models based on BPMN. Script tasks in the models based on BPMN bind composite functions to support code generation. The composite function layer and the function layer are two reusable layers; the function layer is continuously combined to form new composite functions to support continuous changes in business logic.

To support the process, developers must firstly complete the BPMN modeling of the multi-party interaction business scenario described in Section 3.1. Secondly, they should ensure that each task of the process of code generation has corresponding composite functions in the reusable library. Otherwise, we must add new composite functions to the reusable code library to support code generation. Composite functions can be composed of multiple functions, and new functions must be added to the library when the functions in the reusable library do not meet the requirements.

The methods of adding functions include the following: they can be manually added by developers, or they can be added through our low-code visualization method, described in Section 3.3.

The most important step in generating the code is parsing the models based on BPMN. The essence of analyzing the models is to analyze different tasks in the models, and the interaction relationships in the models are reflected in the application that calls the SC. There are four types of tasks in the models based on BPMN, and, in automatic code generation, different tasks are performed with different generation methods. Therefore, when modeling a business process, the developers must determine the type of each task. The four types of tasks and their corresponding code generation methods are as follows.

• script-common: This task is the current SC task and does not invoke any other task—for example, the Cancel the insurance task in Figure 4. When parsing such tasks, the developers only need to form a mapping to the composite functions in the reusable code library.
• script-extra-replaced: This task is a task of the current SC and it invokes a task of an external SC—for example, the Check validity and cancellation conditions of the insurance task in Figure 4. In addition to forming a mapping of the task to the composite functions in the reusable code library, its parsing process also requires the introduction of the function name and address of the external SC being invoked.
• script-intern-replaced: This task belongs to the current SC, and it invokes another task of the current SC. When parsing such tasks, in addition to forming a mapping to the composite functions in the reusable code library, the developers also need to introduce the name of the called function. This type of task is not commonly used because functions with call relationships are usually written in a task.
• service: This task is an external contract task invoked by the current SC task—for example, the Determine whether the cancellation time limit is exceeded task in Figure 4. Since this type of task is an external task, we do not need to form a mapping to the composite functions in the reusable code library; we only need to obtain the function name and contract name.

The flowchart for the parsing of tasks in the model based on BPMN to generate code is shown in Figure 7.

3.3. Visual Maintenance of Multi-Layer Reusable Library

In order to solve RQ3 and maintain the multi-layer reusable library in an efficient, low-barrier manner, the different layers in the multi-layer reusable library are combined in a low-code and visual manner. The way in which the layers are combined with each other is shown on the right of Figure 6, where we try to keep each layer low-code and visual.

3.3.1. Solidity Logical Structure Based on Google Blockly to Generate Functions

The Solidity Logical Structure Blockly component (https://github.com/XinzheShen182/blockly-solidity-function, accessed on 1 February 2023) can help developers to quickly and accurately generate a new function by dragging and dropping. The component integrates reuse function code and reliable Solidity syntax structures to help developers to develop SC functions faster. It uses the Google Blockly visual framework, a graphical programming approach that provides a simple code editor that reduces the coding complexity, improves the programming efficiency, and lowers the developer level barrier.

This component uses Blockly Developer Tools (https://developers.google.com/blockly/guides/create-custom-blocks/blockly-developer-tools, accessed on 1 January 2023) to customize partial blocks of code, as shown in Figure 8a, while integrating the original syntax structure of Blockly, as shown in Figure 8b, so that the generated functions support the Solidity syntax rules.

A composite function can be constructed from custom blocks and the original grammatical blocks of Solidity Logical Structure Blockly. A custom block includes the following categories: function type, function modifier, basic reuse function code, other function code, and field. There are four function types, i.e., ordinary function, constructor, event, and fallback. There are two function modifiers, i.e., function visibility and attributes. The basic reuse function contains some simple, reusable functions commonly used in SCs, such as transfer and contract destruction. These commonly available functions in SCs are derived from [12] and refined using a machine learning clustering algorithm. Other function code represents other generic statements, such as assignment statements. Field is used to build the required state variables, including atomic and nested state variables, i.e., map types and array types.

3.3.2. Code Configurator Based on Web Form to Generate New Composite Functions

The Code Configurator component is responsible for managing and maintaining the reusable code library. It provides a visual configuration maintenance interface. In addition, it can manage the composite functions in the library, as well as their associated functions and state variables according to the domain, whose actions include adding, deleting, modifying, and querying. The composite function is the basic unit of generated code that corresponds to the script tasks in the model based on BPMN.

3.3.3. Code Generator Based on Google Blockly to Generate SC Code

We design a component called the Code Generator, based on Google Blockly, to realize automatic code generation. It adopts the Blockly visualization method to construct the SC framework to be generated, including the basic information of the SC and the models based on BPMN to be associated with it, as shown in Figure 9. A BPMN model represents a multi-party interactive process, and an SC can be associated with one or more BPMN models. This component then adds the version of the compiler to the SC. The deployment environment determines the process and is transparency to the user.

When building an SC framework using Google Blockly, we provide two frameworks: Contract and Interface. Contract can generate a complete SC, and Interface can generate an interface, but it requires other contracts to inherit and implement and cannot be deployed directly. Developers need to select one of the two types and set the basic information, including the contract name, the contract description, the inheritance relationship with the external library contract, and the link to the BPMN models.

3.4. The Overall Architecture of the SC Code Generator

We have developed a tool that supports modeling, reuse library maintenance, code generation, security checking, SC code compilation and deployment, and more. The overall framework of the generator is shown in Figure 10, which consists of four modules.

3.4.1. Business Process Modeling

In this module, multi-party interactions are modeled using BPMN Modeler following the proposed custom and extended BPMN2.0 specification. The BPMN model and associated functions are then stored in the library by BPMN Translator, which will be processed by Code Generator Blockly.

3.4.2. Reusable Function Management

This module is used to maintain reusable units. The Code Configurator is used to manage the compound functions. In addition, Solidity Logic Structure Blockly provides a visual programming method based on Google Blockly, which can generate basic functions through custom block editing. The reusable code library maintained by this module has a mapping relationship with the BPMN model in the previous step, and it is called by Code Generator Blockly together.

3.4.3. Code Generation

This module is responsible for combining one or more BPMN models, contract information, and inherited external libraries to generate a complete SC code with Code Generator Blockly. This module inputs the BPMN model and outputs the SC code by calling the reusable code library.

3.4.4. Security Checking and Deployment

SCs are executed on the blockchain, and their security is crucial. Due to the immutable feature of blockchain, once an SC is deployed, its code cannot be manually modified, and the consequences of security vulnerabilities are extremely serious. For example, the DAO event [18] on Ethereum, which was a crowdfunding project, was subject to a re-entry attack due to a coding problem. Hackers used these two vulnerabilities to make more than 200 attacks, stealing a total of 3.6 million Ethereum, more than a third of the total amount of Ethereum raised by the project. The security vulnerabilities of SCs mainly include code reentry, integer overflow, and predictable random processing. Security checking is implemented to protect participant assets, ensure the proper execution of SCs, maintain data integrity and trustworthiness, and meet compliance requirements. Security checking can improve the ability of SCs to resist attacks; prevent fund theft, data tampering, and malicious operations; and ensure the reliability of the SC and the security of participants’ rights and interests. Thus, our generator integrates security checking tools. Furthermore, to enhance its integrity, users can compile and deploy the generated code into their private chain, which they can customize for testing.

Security checker is mainly responsible for performing security checks on the generated SCs to avoid security vulnerabilities. To achieve this goal, the SC security checking tool Slither [19] is integrated into our tool. Slither is a Solidity static analysis framework written in Python 3. Slither enables developers to discover vulnerabilities and enhance code comprehension. Slither’s error detection exceeds that of other static analysis tools in terms of speed, robustness, and the balance of detection and false positives to find problems in SCs. The developers of Slither show that it outperforms other static analysis tools in detecting the most dangerous and common reentry vulnerabilities [19].

Blockchain Trigger is mainly responsible for the interaction with the blockchain. We mainly use the Truffle [20] framework to integrate, compile, and deploy SCs in the system. The code can be compiled and deployed directly after being generated by the generator, greatly enhancing the system’s ease of use.

For the case of flight delay insurance mentioned in Section 1, we use the tool to generate the SC code, and part of the code is shown in Figure 11.

4. Experiment and Comparison

4.1. Use Cases for Evaluation

To verify whether the proposed BPMN model applies to multiple scenarios of SCs and check the effectiveness of the reuse mechanism in improving the development efficiency in practical applications, we extracted five representative contracts from the literature for evaluation. These contracts have certain complexity, involve multiple stakeholders, and are widely used as use cases in related research. However, the most important aspect is that the selected contracts permit reuse in multiple fields, which proves that our tools embody the idea of reuse.

-

Voting and Election Contract [21]: This case is one of the earliest applications of SCs and reflects the idea of decentralization. Therefore, this application is taken as one of our cases. The sponsor of a poll can register both the voters and the candidates, and, within a specific time, the voters can choose a candidate to vote for. After the polls close, everyone can view the results.

-

Voting Result Notification Contract [22]: The contract involves the originator, voter, and candidate who is registered. When the number of votes reaches a specified number, messages are sent to other contracts.

-

Crowdfunding Contract [23]: The contract covers the crowdfunding originator and shareholders. The user becomes a crowdfunding shareholder when money is transferred from a user’s account to a crowdfunding project. A crowdfunding project is established if it is successfully raised within the specified time, and the shareholders in the project have the right to vote on all proposals. All money will be refunded unless the fund is raised successfully.

-

Supply Chain Contract [24]: The contract involves buyers, manufacturers, intermediaries, carriers, and suppliers. The buyer places an order with the manufacturer, who sets delivery dates and compensation for overdue payments. Manufacturers contact intermediaries, who identify suppliers and carriers. After receiving the raw materials from the supplier, the manufacturer produces goods. After the manufacturer has delivered the goods to the buyer, the compensation clause will be enforced if the delivery time is exceeded.

-

Buying and Selling Contract [25]: The contract involves buyers and sellers. Sellers can register goods for buyers to view and purchase. After the buyer buys the goods, the seller will determine the delivery time and overdue compensation. The indemnity clause will be applied if the delivery time exceeds the agreed time.

4.2. Evaluation

The reusability of the tool is evaluated against the five contracts described in Section 4.1. First, we construct and store some reuse units for voting and transaction business in the reuse library. Second, a developer with experience in SC development is invited to develop the five SCs in a manual line-by-line manner, and the number of lines of code, the state variables, and the functions of each SC are determined. Then, the developer develops the five SCs with the proposed visualized reuse-supporting tool, using reusable units to generate code automatically. Finally, we also calculate the number of lines of code, state variables, and functions reused.

Next, we use the ratio of the number of code lines reused to the total number of code lines manually developed by the developers as the reuse rate, as shown in

Table 1. Reusability evaluation on the five contracts.

Contract	Total Code Lines	Reused Code Lines	Number of State Variables	Number of Reused Fields	Number of Functions	Number of Reused Function	Reused Code Rate
Crowdfunding	130	55	15	6	11	4	40.74%
Voting Result Notification	80	39	9	6	8	4	48.75%
Election	58	58	7	7	5	5	100%
Supply Chain	150	65	19	8	11	6	43.30%
Buying and Selling	87	65	11	8	7	6	74.71%

. It can be seen from the experimental results that our tools can effectively support code reuse, thus improving the development efficiency and code correctness. As the number of reusable units gradually accumulates, the effectiveness of this reusable mechanism will become more obvious.

4.3. Comparison

We compare the proposed SC generation tool with other state-of-the-art related tools. First, the models and methodologies used in each tool are summarized. The expression of business interaction processes allows for the alignment of SCs with a broader spectrum of business processes, thereby providing enhanced functionality, so we use Business Processes as a comparative feature. The articulation of the interactive relationship with SCs facilitates the understanding and communication of complex contract logic and interaction processes. This contributes to collaboration and consensus building among the involved parties. Therefore, we use Interactive Relationship as a comparative feature. Code-reusing libraries can reduce the development costs and support developers in rapidly building new SCs, thereby fostering collaboration and sharing within the blockchain development community. In light of these benefits, the comparative feature Code Reusing has been established. Security Checking refers to whether attention is given to conducting security checks on the generated SCs. SCs with vulnerabilities can potentially cause significant losses. Complete Smart Contract refers to whether a fully functional SC code has been generated, which can be directly compiled and deployed. Some methods may generate a template that developers need to fill in with their specific details.

Next, we compare the tools in terms of some main functional features, as shown in

Table 2. Comparison between SC generation methods.

Method	Model	Business Processes	Interactive Relationship	Code Reuse	Visual Interface	Security Checking	Complete Smart Contract
Proposed Method	BPMN + Blockly	YES	YES	YES	YES	YES	YES
Skotnica [11]	BPMN	YES	NO	NO	YES	NO	NO
Qin [12]	IDLC	NO	NO	NO	NO	NO	NO
Guida [16]	SC Descriptor Model	NO	NO	YES	YES	NO	YES
Wöhrer [13]	CML	NO	NO	NO	NO	NO	YES
Mao [17]	Char-RNN + Blockly	NO	NO	YES	YES	NO	YES
Ingo [10]	BPMN	YES	NO	YES	YES	NO	NO

. The comparison shows that the proposed tool has more functional support for SC generation, especially the automatic code generation and reuse techniques, improving the development efficiency.

5. Conclusions

In order to address the problem whereby non-IT personnel are not familiar with the code when experts from multiple fields jointly develop SCs, this paper proposes a reuse-oriented visual SC generator to support efficient SC development, especially suitable for complex multi-party interaction scenarios. This allows people from different fields to be involved in the SC development process, not merely programmers. Our approach enables SC designers to construct business models from business requirements, automatically generate code from business models, and provide security checks and deployment tests. We propose a model based on BPMN to model complex interactions in multi-party SCs. At the same time, the transformation rules from the BPMN model to the reusable code base are defined and maintained to support the automatic generation of SC codes. In addition, we propose multi-layer reusable libraries and implement the maintenance of reusable libraries and the visual development of the Solidity language using a visual web tool based on Google Blockly. The visualization method based on Google Blockly has also been used for the automatic generation of SC codes. The experimental results of five cases show that the proposed method and generator help to improve the reusability of SC development. The qualitative comparison with other advanced methods and tools shows that the proposed automatic SC generation method has certain advantages.

One of our ongoing works aims to gradually explore the requirements of different domains and continuously add new reuse units to the reuse library. Another work seeks to realize the functions of monitoring the execution of SCs in the blockchain and carrying out correctness verification.