Sie können Operatoren mit Ihrer Suchanfrage kombinieren, um diese noch präziser einzugrenzen. Klicken Sie auf den Suchoperator, um eine Erklärung seiner Funktionsweise anzuzeigen.
Findet Dokumente, in denen beide Begriffe in beliebiger Reihenfolge innerhalb von maximal n Worten zueinander stehen. Empfehlung: Wählen Sie zwischen 15 und 30 als maximale Wortanzahl (z.B. NEAR(hybrid, antrieb, 20)).
Findet Dokumente, in denen der Begriff in Wortvarianten vorkommt, wobei diese VOR, HINTER oder VOR und HINTER dem Suchbegriff anschließen können (z.B., leichtbau*, *leichtbau, *leichtbau*).
Der Artikel diskutiert die zunehmende Einführung neuer Technologien, die zu vernetzten digitalen Ökosystemen führen, wobei die Blockchain-Technologie Geschäftsmodelle transformiert. Es führt SmaC ein, eine textdomänenspezifische Sprache für Solidität, die die Einhaltung eines Entwicklungsmusters fördert und die Qualität intelligenter Verträge verbessert. Der Ansatz wird durch empirische Studien und eine Fallstudie validiert, die die Effektivität von SmaC bei der Bearbeitung bestehender Verträge und der Entwicklung neuer Verträge belegen. Der Artikel vergleicht SmaC außerdem mit bestehenden Arbeiten und hebt seine einzigartigen Beiträge und das Potenzial für weitere Forschung im Bereich modellgetriebener intelligenter Vertragsentwicklung hervor.
KI-Generiert
Diese Zusammenfassung des Fachinhalts wurde mit Hilfe von KI generiert.
Abstract
Despite the increasing interest in blockchain and smart contracts, their inherent complexity has impeded widespread adoption. In order to mitigate this issue, this work introduces SmaC, a model-based framework for the development of smart contracts in Solidity that enables the treatment of contracts as models, opening up new possibilities for their enhancement and maintenance. A key benefit of SmaC is its ability to impose a development pattern, which contributes to improved code quality and reduced vulnerabilities. The framework’s effectiveness is evaluated through several case studies, showing how model-driven engineering can mitigate contracts inherent complexity and promote better collaboration between developers and domain experts. As this work will demonstrate, when smart contracts are treated as models, a vast array of possibilities unfolds.
Communicated by Javier Troya and Alfonso Pierantonio.
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
1 Introduction
During the last years, the increasing adoption of emerging technologies is given rise to interconnected digital ecosystems, comprising new actors, structures, and regulations, thereby fostering the emergence of novel digital business models [1]. Among these technologies, one of the most promising and revolutionary, considering its potential to transform business models, is blockchain technology [2].
We can refer to a blockchain as a distributed peer-to-peer network, in which the different nodes, once verified their validity, register transactions in an immutable database called the ”ledger,” which offers eventual consistency and uses cryptographic techniques to ensure a high level of trust and security for users [3]. Originally conceived as a software solution to address shortcomings in electronic payments [4], blockchain technology is currently finding applications in both financial and nonfinancial domains that encounter challenges such as third-party intermediation for specific actions, distrust within the ecosystem, and associated economic costs and delays [3]. Some of the functionalities that blockchain offers to overcome these challenges include the immutability of recorded transactions [5], identity validation without intermediaries to establish a trusted environment, resulting in savings in both time and resources [6], thereby enabling proposals for an “Internet of Value" [7]. Beyond the competitive advantages offered by blockchain as a technological solution based on its inherent properties, a significant aspect is its capability to host smart contracts tailored for specific purposes.
Anzeige
In essence, smart contracts are computer programs that execute the logic programmed in them automating processes and ensuring adherence to a set of predefined conditions while minimizing costs [8]. Once deployed on blockchain networks, smart contracts are immutable, meaning they cannot be altered. Besides, everyone has access to their code, thus providing a high degree of transparency across the network in which they operate. By enabling businesses to trigger actions automatically based on predefined criteria, smart contracts enhance efficiency by streamlining processes and reducing fraud and compliance costs [9].
However, the integration of this technology into corporate processes poses significant challenges, primarily due to the steep learning curve associated with coding smart contracts [10] and the digital divide between business professionals and developers tasked with implementing the contracts to modernize or enhance internal processes amid digital transformation efforts [11]. One proposed approach to mitigate these challenges involves the adoption of model-driven engineering (MDE) techniques and tools, which hold the potential to elevate the level of abstraction at which developers and domain experts collaborate and conceptualize solutions [12].
In light of these considerations, the primary objective of this study is to give answer to the following research question: Can smart contracts be conceptualized and developed in a simpler and more reliable way using MDE techniques and tools? Toward this goal, this research introduces SmaC, a textual domain-specific language (DSL) for Solidity, along with its companion tooling, which supports the automatic generation of a model representing the coded smart contract. By providing a model-based representation of the contract, various model management tools can be employed to interact with the contract in numerous ways: linking the contract model with models expressed in other notations, validating or simulating the contract, generating diverse types of reports, and more. Additionally, the developed integrated development environment (IDE) offers several conveniences for developers, including code completion, dynamic error detection, and others. Notably, the IDE’s versatility stems from its development using model-based tools, enabling easy extension to cater to the specific requirements of any potential user.
The rest of this paper is organized as follows: Sect. 2 presents the proposed approach to enable the modeling of smart contracts. Section 3 demonstrates the main contributions of the approach through a couple of empirical studies; Sect. 4 compares the proposal with existing works in the field. Finally, Sect. 5 concludes the paper by discussing ongoing and future research directions stemming from this work.
Anzeige
2 Technological solution
In the following, a model-based approach aimed at elevating the level of abstraction in dealing with smart contracts is introduced. The underlying idea is to transition contracts into the modeling realm, thereby facilitating their conceptualization and development. This approach has the potential to substantially reduce the complexity associated with these tasks and consequently alleviate the entry barrier to the adoption of such technology. As an initial stride in this direction, this section outlines the main aspects of our proposal.
2.1 General overview
The basis of the solution developed to answer the research question of this work is a textual DSL for the codification of smart contracts in Solidity. This DSL has been developed using Xtext1 as an Eclipse plug-in christened SmaC, which serves as the namesake for the whole proposal.
While it is true that any smart contract could be developed in Solidity using any existing IDEs, leveraging the tooling provided by SmaC offers several distinct advantages. Firstly, it promotes adherence to a development pattern grounded on a metamodel, thereby enhancing the quality of the resultant contract. Additionally, SmaC encompasses a range of functionalities that streamline contract coding, including auto-completion and automatic error detection and correction. However, the most significant benefit derived from utilizing SmaC is the limitless possibilities afforded by the automatic transformation of contracts into models.
Figure 1 presents an overview of the SmaC proposal. The textual DSL constructed with Xtext enables the coding of Solidity smart contracts, which are subsequently persisted as EMF models. From this point onwards, these models can be manipulated and edited using either their Solidity-based textual representation or the plethora of existing tools designed for working with EMF models, such as the simple yet effective tree-like editor. Moreover, any Solidity compiler can compile the contract, ensuring compatibility and flexibility in deployment. Furthermore, the figure emphasizes that new concrete syntax can be developed to enable graphical development of contracts, or model transformations can be crafted to bridge contract models with other modeling notations or interchange formats. Indeed, treating contracts as models facilitates seamless integration with any existing modeling language or framework.
Notably, this work will demonstrate several applications, such as contract elaboration or visualization through a tree-like a tree-like editor (Fig. 2), contract validation via model checking mechanisms (Fig. 10), or contract development using a block-based visual syntax (Fig. 17).
Moreover, treating smart contract features not merely as plain text files but as classes, attributes, etc., within an EMF model significantly enhances the development of critical validation and error resolution mechanisms. Overall, the approach of modeling Solidity programs as EMF models markedly improves the robustness, maintainability, and scalability of smart contract development.
Figure 2 depicts an excerpt of a smart contract developed using SmaC, along with its corresponding SmaCmodel. The left panel showcases a snippet of Solidity code, while the right panel displays the corresponding model fragment. It is worth noting that the contract depicted is a simplified version extracted from a larger contract for illustrative purposes. For a more comprehensive view of this aspect of the working prototype, readers are encouraged to refer to the GIFT file available in SmaC’s public repository.2
Fig. 2
Extract from an ERC-20 smart contract coded with SmaC
Having briefly introduced a general overview of the SmaC proposal, some of its key features are described in more detail below. To illustrate these features, screenshots of the case study described in Sect. 3.2.1 have been used, in which generally speaking, a smart contract has been developed to manage certificates of participation in student activities, in the context of a university course (academic credit recognition, ACR).
Structural pattern the implementation of a structural pattern on the definition of the grammar promotes the standardization and quality of the development of the contracts. This approach not only facilitates the creation of robust and maintainable contracts but also enhances consistency and understandability in the codebase. Furthermore, integrating a loop gas restriction within this structural pattern enhances the security and efficiency of smart contracts. When a user submits a transaction, it must specify a gas limit associated with the transaction. The gas limit is the maximum amount of gas available for the execution of a transaction. The out-of-gas exception accounts for more than 90% of all exceptions in Ethereum and causes significant financial losses [13]. This measure helps prevent infinite loops, which can pose a significant security risk and potentially compromise the integrity of the network. Figure 3 shows the beginning of the definition of a smart contract using SmaC, where, based on the defined pattern, SmaC first recommends the user to define a version among the options offered by the IDE. Once the compiler version has been defined, it can be seen that the IDE itself no longer suggests it, offering the user to define other elements based on the pattern.
Autocomplete As with Remix, the most widely used IDE for smart contracts development with Solidity [14], SmaC provides an auto-completion mechanism based on predefined templates. For example, Fig. 4 demonstrates this functionality with the auto-completion of the ERC-20 interface elements for defining a fungible token. In contrast to Remix, SmaC supports the automatic generation of getter, setter, and constructor methods for newly added elements to the contract. Moreover, Remix does not control for new elements being named the same as existing elements, potentially leading to errors due to naming conflicts. SmaC , however, effectively manages and prevents these naming conflicts.
Contextual help to facilitate the coding task and enhance the interpretation and understanding of the elements involved, contextual aid is provided. As depicted in Fig. 5, where a Context contract is to be specified that provides information about the current execution context, the assistance on the element provides information about the functionality of the element that has been defined and which elements can be defined in it.
Error detection and solving a series of validation rules are implemented to ensure the correct specification of the smart contract. Additionally, a set of semi-automatic quick fixes has been integrated to simplify the resolution of such errors when they are detected. These mechanisms are based on auto-completion and error detection. In particular, SmaC automatically defines, for example, the expressions required in loops, removing or renaming elements in case of duplication, and initializing variables to the appropriate values based on their defined types if they are not explicitly initialized. In addition, the auto-completion function in function bodies helps developers by suggesting and inserting code constructs that fit the context, ensuring compliance with syntactic and semantic rules. Figure 6 shows an example of this SmaC functionality, where the duplicity of two contracts with the same name is detected, providing two mechanisms for resolving this error.
Syntax highlighting it has been implemented through the creation of a class that implements the IHighlightingConfiguration Eclipse interface. This class is based on the defined grammar rules for syntax highlighting. The IHighlightingConfiguration interface enables the establishment of color, format, or font configurations for reserved words, numbers, quoted text, and other elements defined in the implemented editor. Figure 2 shows an example of this feature, where it is possible to distinguish the different values of the properties of the ERC-20 token that has been defined.
Fig. 3
SmaC autosuggestion complete SmaC elements. ACR case study
SmaC’s grammar is inherently based on the grammar provided by the Solidity language specification. From this fact, any SmaC model is compilable by the Ethereum EVM. Conversely, for a Solidity smart contract to be considered a well-formed SmaC model, it must conform to the development pattern imposed by the SmaC framework, which is depicted in Fig. 9. Due to the substantial number of terminals and rules defined to emulate Solidity, Fig. 7 zooms in on the File element, while Fig. 8 focuses on the Contract element. These figures provide partial views of the Ecore metamodel generated from the Xtext grammar, showcasing the mapping rules between the abstract (metamodel) and concrete syntax (textual terms), as well as the corresponding editors. In the subsequent sections, the main classes of these metamodels are described in detail.
Fig. 7
Extract of the grammar and corresponding SmaC metamodel for the File element
File represents the file where the compiler version, interfaces, libraries with specific functionality, and the smart contracts themselves are located.
Abstract contract it gathers functionality that can be used by the smart contract that inherits from it to define its logic. Tokens adhering to the ERC-20 or ERC-721 standards share both properties and functions under the same names. However, due to the distinct nature of each contract, they are implemented differently. Utilizing an abstract class can enhance the organization and readability of contract content, although it offers less flexibility for customization compared to employing an interface.
Contract this class encapsulates the smart contract and its defined functionality. Within its body, other elements are included that specify its characteristics, such as constructors, properties, modifiers, events, clauses, among others.
Properties this class embodies a collection of simple variables, each defined and utilized to store a single value that facilitates the execution of smart contract logic. The various types defined include: address, int, uint, float, bytes, char, string, and Boolean.
Mapping these are representations of a series of variables that form a key-value data structure. Unlike properties, which can only store a single piece of data according to their declared type, mappings allow for the association of keys with corresponding values, enabling more complex data storage. Mappings serve a purpose akin to dictionaries, hash tables, or maps in other programming languages, making them valuable for storing and organizing data within smart contracts.
Struct is a data type comprising properties of various types or other defined structs. In SmaC, they are categorized into three types: PersonalizedStruct, User, and Company. PersonalizedStruct enables developers to define properties of different data types according to their requirements. User and Company, whose inner structure is shown in Table 1, have been established as built-in data types because the entities most frequently interacting with smart contracts are typically individuals or organizations. These two categories, therefore, cover the vast majority of entities encountered in blockchain application use cases.
Constructor this element represents a special function that is executed only once during the creation and deployment of a smart contract. The constructor is responsible for initializing and configuring the state variables and other properties of the contract.
Modifier this element corresponds to a modifier that establishes conditions that must be satisfied before executing the function with which they are associated. A key component in defining a modifier is the constraints, which can be specified within the smart contract’s constructors or functions and resemble conditional expressions. In the SmaC language, constraints are represented by the RestrictionClause class. This class can be categorized into two types: Restriction and RestrictionGas, depending on whether a specific condition is specified in the smart contract.
Event this class represents an event in Solidity. Events emit notifications about actions performed by executing the logic defined in the smart contract.
Clause this class represents a function in Solidity, in which the logic of the statements defined by the programmer is executed, such as conditions, loops, and expressions.
Table 1
SmaC built-in data types attributes
Built-in data types
Data type
Attribute data type
Attribute correspondence
User
identifier
address
name
string
surname
string
email
string
Company
identifier
address
name
string
VAT
string
city
string
email
string
It is important to highlight that SmaC fully supports the modeling of any conceivable Solidity language expression that might be included within function bodies. While this section features only two partial excerpts from the SmaC metamodel due to spatial constraints, the thorough design of SmaC guarantees its ability to accommodate the full spectrum of actions and expressions required by Solidity. To substantiate this claim, it will be shown that contracts generated by SmaC have undergone rigorous testing through deployment on the test Ethereum blockchain and interactions facilitated by third-party tools such as Remix and MetaMask.
2.4 Development pattern
As identified by various authors [6, 15], common challenges in smart contract development include a lack of standardization that impedes readability and fails to enforce best coding practices, such as early variable declaration and effective gas management—gas being the unit of computational expense for executing instructions within a loop. The development of SmaC aims to address this issue by implementing a structural pattern, called SmaCGP (SmaC Good Practices pattern), based on the grammar defined by Xtext. The SmaCGP pattern requires developers to follow a specific order when coding a contract, ensuring that elements are added in a predefined sequence. Establishing this pattern promotes a standardized code structure that enhances the readability of smart contracts. This step is crucial to prevent the inclusion of superfluous or incorrect elements that could compromise the integrity of the contract. It also minimizes human error and ensures that all generated models adhere to a consistent and correct pattern. Figure 9 provides an overview of the process for defining contracts according to this pattern, with the sequence in which the main elements should be added summarized below:
Following this pattern avoids the introduction of superfluous or incorrect elements that could compromise the integrity of the contract. It ensures that only essential and valid components are included in the model, while maintaining simplicity and clarity. It also guarantees to minimize human error and ensures that all the contracts developed with SmaC present a uniform and common structure. This not only aids new users and developers in quickly understanding and adopting the tool but also serves as a best practice guide for creating smart contracts. By standardizing the process for selecting and adding instances, it fosters the adoption of consistent and well-defined practices in smart contract development, thereby contributing to a more robust and secure ecosystem.
3 Evaluation and discussion
In the field of software engineering, as in numerous other disciplines, empirical methods play a crucial role in validating proposed theories, evaluating delivered functionality, identifying potential limitations, and uncovering areas for improvement [16]. Therefore, following the introduction of the proposal presented in this work, this section outlines the protocol followed to determine whether the proposed solution effectively addresses the main research question. It is important to note that this validation phase was divided into two distinct stages.
The first stage entailed an empirical study wherein a random selection of Solidity smart contracts sourced from various origins was imported into SmaC to evaluate its capacity to identify anti-patterns within the imported contracts.
In contrast, the second stage involved a laboratory case study designed to evaluate the efficacy of SmaC in real-world scenarios by assessing its performance during the development of a smart contract.
3.1 Empirical study
This subsection provides an overview of the first stage of the validation phase: an empirical study where several existing smart contracts were imported into SmaC to evaluate its capability to handle preexisting contracts, generate the corresponding models, and identify anti-patterns that do not fit the pattern defined by SmaC. Essentially, this procedure allows the SmaC grammar to be validated when importing existing contracts. This experiment adhered to the guidelines outlined in [17].
3.1.1 Description
To ascertain the modeling capability of SmaC for various smart contracts, diverse Solidity contracts were obtained from repositories provided by Ethereum, OpenZeppelin, and Solidity documentation. Brief introductions to these repositories are provided below.
Ethereum Foundation (EF) is a nonprofit organization dedicated to supporting Ethereum and related technologies. The consortium maintains a public repository3 containing a collection of contracts intended for educational purposes. These contracts are designed to help the public gain familiarity with the Solidity language.
OpenZeppelin is a corporate entity that offers tools for developing, deploying, and managing decentralized applications. In its repository,4 OpenZeppelin provides a range of contracts enabling users to leverage their functionality for various purposes, such as access control, creating token assets, and more.
Solidity documentation is consolidated in an online repository known as Read the Docs5 to streamline version control management.
3.1.2 Procedure
Figure 10 depicts the process employed to conduct this experiment. Note that the 55 smart contracts utilized in the study were chosen randomly and are available in the public repository of SmaC,6 along with their corresponding SmaC models. This process can be summarized as follows:
1.
Create an empty smart contract model (SmaC model with.sce extension) or change the file extension from.sol to.sce to import it into SmaC. This enables the comprehensive suite of facilities tools offered by SmaC for working with contract models.
2.
Copy and paste the Solidity code of the smart contract from the website into the SmaC textual editor (if a new SmaC textual model was created).
3.
Review and address any anti-pattern detection displayed by the editor.
4.
Resolve the anti-pattern problems identified during the verification process.
5.
Review the EMF model generated to ensure accuracy and completeness.
The preceding process uncovered several anti-pattern detections when the contracts were imported into SmaC. These anti-patterns can be classified into different groups, which are summarized in Table 2 and discussed in more detail in the following paragraphs.
Table 2
Anti-patterns detected during the study
Anti-pattern detected
Anti-pattern group
Solidity term
Pattern problem
#Contracts involved
G1
Contract
Contract lacking
2
G2
Version
Several versions
1
G3
Library
Reference
4
G4
Interface
Reference
5
G5
Variable
Variables named as a reserved word
9
G6
Loops
Restriction gas required
7
G7
Constructor
Localization
3
G8
Constructor
Constructor’s visibility undefined
13
G9
Modifier
Localization
7
G10
Modifier
Require “_;" instruction
3
G11
Event
Localization
10
G12
Function
Function’s visibility undefined
15
G13
Condition (if)
Open/Close key required ( )
8
The identified anti-patterns indicate a deviation from the pattern prescribed by SmaC. Consequently, in the event of the detection of one or more of these anti-patterns, the contract to be imported must be amended in accordance with the rules set. This way, resolving localization-related problems (G7, G9, G11) simply necessitates reordering the elements in accordance with the established pattern.
On the other hand, Solidity permits files with a.sol extension to exclusively contain the specification of an interface or abstract contract. In contrast, SmaC necessitates the inclusion of at least one Contract object G1.
Regarding G2, several files have been identified whose interior contains contracts that each define its own version respectively. In our proposal, only one version needs to be defined for all smart contracts collected in the SmaC model.
Regarding the functionality imported by a smart contract (G3, G4), SmaC mandates that both libraries and interfaces used in the contract must be defined within the same file to allow for referencing them. However, several smart contracts utilized in this study import libraries or interfaces from external files. To address this issue, one simply needs to create either an interface (G3) or a library (G4) element within the smart contract model.
In SmaC’s DSL grammar, Solidity reserved words are designated as terminals. Consequently, variables named after reserved words trigger an error (G5), which can be readily resolved by modifying the variable name.
One of the advantages offered by SmaC is its ability to prevent the occurrence of infinite loops. To achieve this, the DSL grammar specification mandates the inclusion of a gas restriction when creating a loop. This restriction determines the amount of gas required for an actor interacting with the contract to execute the code contained within the loop. By implementing a gas restriction, the number of loop iterations is constrained in the event that the loop condition is inadequately defined. Therefore, to resolve the G6 anti-pattern, a gas restriction should be added to any contract imported into SmaC .
Anti-patterns groups G8 and G12 pertain to the absence of visibility modifiers for certain elements, which are inherently considered public by default. However, SmaC mandates the explicit definition of a visibility modifier for these elements. This design choice is motivated by the intention to avoid oversight of these elements during contract specification.
Finally, anti-pattern group G13 arises due to the potential omission of certain characters ({ and }) depending on whether multiple expressions are present, whereas SmaC mandates their mandatory inclusion in such cases.
In conclusion, this procedure has demonstrated SmaC’s capacity to identify violations of its pattern when importing existing contracts into the tool. Following the importation of 55 distinct contracts, Smac has successfully identified 13 different groups of anti-patterns that required correction within these contracts.
3.1.4 Potential limitations
In addition to the anti-pattern detection outlined in the previous subsection, the execution of this empirical study has revealed that the pattern defined by SmaC could be quite strict in some circumstances, which are discussed below.
One possible challenge is related to the Struct built-in data types User and Company supported by SmaC. There may be contracts defining a data type with the same names. In such cases, SmaC requires that data types include the attributes specified in Table 1.
This error might arise, for instance, if the developer uses a User data type to represent a user’s information. In this case, the editor will notify an error since certain properties are missing for such data type. To resolve this issue, the required properties must be added to the newly defined data type. Figure 11 illustrates this scenario, depicting the addition of two properties to the User data type in order to adhere to the grammar rule.
Another potential future limitation may arise from changes in the Solidity language, such as the addition of new terminology or the obsolescence of certain features. In the former scenario, the grammar of SmaC would require updating to accommodate these new changes. In the latter case, a new functionality would need to be defined in the class responsible for validating the textual model to notify the developer of the disuse of the deprecated instructions.
3.2 Case study
The second stage of the validation process involved a laboratory case study designed to demonstrate the simplified and reliable development of smart contracts using SmaC. This stage highlights SmaC’s capabilities, utility, and the additional functionalities it offers beyond those inherent to Solidity. A real-world problem relevant to a public university context was selected for this purpose. Following this, the contract was deployed on a blockchain network to validate the compatibility of SmaC contracts with other tools. The main details of this case study, which was conducted according to the guidelines proposed by Wohlin et al. [18], are outlined in the subsequent subsections.
3.2.1 Description
With the objective of encouraging students to expand their knowledge beyond the scope of their degree programs, certain public universities have established a specialized course known as academic credit recognition (ACR). This course, totaling six ECTS credits, acknowledges students’ attendance at various seminars, workshops, or activities pertinent to their field of study. To successfully complete this module, students are required to participate in university-offered activities, for which they will receive certificates of attendance in either electronic or physical format. These certificates align the duration of the activity with the corresponding ECTS credits. Moreover, external organizations, in collaboration with the university, may provide additional activities for students, accompanied by certificates of attendance. Upon fulfilling the requisite number of activities, students are eligible to enroll in the course. The university subsequently verifies the certificates and deems the course passed if the student has fulfilled the minimum required hours of participation. Figure 12 illustrates the exchange of value among the various stakeholders involved in this process.
Fig. 12
Value exchanges between parties involved in the RAC course
To enhance the described process, it is proposed that the university integrates blockchain technology and employs smart contracts, which would yield numerous benefits for both students and the institution. For instance, the university could introduce its own ERC-20 token, representing ECTS credits.
These tokens could be directly distributed to students by the university or affiliated organizations, eliminating the need for cumbersome bureaucratic procedures with third parties and resulting in significant time and cost savings. Establishing a transparent ecosystem would enable the university to authenticate students’ participation in various activities, thereby ensuring the validity of the earned credits. This aspect is particularly significant as it could serve as a deterrent against document forgery. Moreover, by simplifying access to tokens for students, they could seamlessly transfer them to the university, consequently streamlining the documentation process.
3.2.2 Procedure
To implement and deploy the smart contract for this case study, the procedure shown in Fig. 13 and described below was followed.
As an initial step, the smart contract for fungible tokens was developed using SmaC. This contract must conform to the widely adopted ERC-20 standard, which can be accomplished by implementing the IERC-20 interface. Subsequently, the contract is compiled into bytecode using the Remix IDE7 to facilitate deployment on the Binance network. Metamask serves as an intermediary between the network and the deploying address, simplifying the deployment process. Following deployment, the tokens can be imported to the deploying address as illustrated in Fig. 14.
Finally, to demonstrate the interaction with the contract, Fig. 15 illustrates the transfer of tokens between different accounts using the ERC-20 transfer function.
The purpose of this case study is to replace ECTS credit certificates with fungible tokens according to the ERC-20 standard. In order to achieve the construction of a “tokenised” environment, the following requirements (ReqX) have been defined. Note that the contract deploying address corresponds to the university.
Req1.
The university, being the entity responsible for issuing credits and overseeing the credit acquisition process, must have the capability to generate an unlimited number of tokens as necessary.
Req2.
It is imperative to establish a mechanism for adjusting the token circulation based on demand. Additionally, provisions should be made to withdraw tokens from students’ addresses in instances of erroneous issuance or under suspicious circumstances.
Req3.
To mitigate the risk of fraud, only the university should possess the authority to transfer tokens between addresses, with a restriction equivalent to the total token supply. External organizations must be authorized by the university to conduct token transfers.
Req4.
To regulate token transfers conducted by authorized delegates, it is necessary to implement a transfer limit that can be adjusted as required. Hence, incorporating a functionality to verify the available transferable token amount from the university’s account would be beneficial.
Req5.
A mechanism is needed to enable students to submit tokens to the contract holder’s address, symbolizing the submission of documentation and successful completion of the ACR subject validation process.
Req6.
It is essential to integrate basic security measures to prevent unauthorized accounts from executing unauthorized actions, such as manipulating token amounts or soliciting information from other users.
3.2.4 Contract development and deployment
SmaC was utilized to code/model the smart contract, a snippet of which is depicted in Fig. 16. This contract adheres to the ERC-20 pattern due to the implementation of the ERC-20 Interface (IERC-20), a standard for Ethereum tokens [19]. The elements not encompassed within the ERC-20 standard, which support the functionality required for the smart contract to fulfill the specified requirements, are delineated below:
Context: provides information about the current execution context, including the sender of the transaction and its data.
Enumerator
State: to represent two opposite states: “Enable” and “Lock.”
Attributes
_control: whose range of values is the set of integer constants “Enable” and “Lock” defined in the enumerator.
_subjectPass: structure to identify through an address which user has sent to the account that deployed the contract the minimum amount of tokens established to pass the subject.
_tokensAmountRequired: minimum amount to pass the subject. By default, the value is 6.
Modifiers
isOwner: check if the current address that is interacting with the contract is who deployed the smart contract.
isEnable: check if the current control value attribute is Enable to execute the function.
Functions
consultSubjectPass(account): from the received address as input parameter, checks the mapping structure to see if that address has passed the subject, which means that the student has delivered at least the required amount to the contract owner’s account. Requires that the control value is “Enabled” and that only the address that deployed the smart contract can execute this action.
consultSubjectPass: checks the mapping structure to see if the address executing the smart contract function has passed the subject, which means that the student has delivered at least the required amount to the contract owner’s account. Requires that the control value is “Enabled.”
refundTokenECTS: transfer the student’s six tokens to university account.
The smart contract uses two functions, “enableState” and “disableState,” to control the contract’s critical functions. The function “enableState” sets the control to “Enable,” enabling the main functions execution, but only works if the control is “Lock” and is limited to the contract’s deployer. The function “disableState” sets the control to “Lock,” also disabling main functions, but requires the control to be “Enable” and is similarly restricted to the contract’s deployer.
Once the smart contract has been developed, the subsequent step involves deploying it on a blockchain network. In the context of this case study, Binance’s BNB testnet is utilized for deployment. To initiate this process, the Metamask extension8 is downloaded to acquire an account for accessing the Web3 environment. Metamask serves as a wallet, enabling users to send and receive crypto assets within their account. Subsequently, the contract is compiled in Remix to convert its logic into bytecode. Following compilation, deployment is carried out by switching the environment to the Web3 environment, wherein Remix selects the address associated with the Metamask account.
3.2.5 Results
In the following, it is discussed how each of the functional requirements set for the case study in Sect. 3.2.3 have been met with the contract developed with SmaC.
Req1.
To facilitate the provision of tokens as required, the mint function has been incorporated, accessible exclusively to the contract owner. Upon deployment of the contract (creation of an instance on the network), this function is promptly executed to mint the designated number of tokens specified as an argument in the smart contract constructor. Furthermore, the mint function can be invoked subsequently, post-deployment of the smart contract, to augment the total token balance in circulation by the specified quantity.
Req2.
To diminish the token supply, a function named burn has been integrated. This function permits the contract owner to burn a specified quantity of tokens from a designated address. Upon execution of this function, the total token balance in circulation is adjusted by deducting the burnt amount.
Req3.
As a safeguard against fraud, only the address of the smart contract owner can transfer tokens from one address to another, with a cap equivalent to the total token supply. Organizations must receive delegation from the owner’s address to conduct token transfers.
Req4.
The ERC-20 standard encompasses the allowance function, facilitating token delegation to a specified address by the contract owner. In expanding the delegation capability, two supplementary functions, increaseAllowance and decreaseAllowance, have been incorporated to respectively augment and diminish the token transfer allowance. Additionally, two other functions have been defined: one to enable the delegated address to verify the available token transfer limit, and another for the contract owner to ascertain the available token transfer limit for a specific address, if granted permission.
Req5.
The refundTokenECTS function enables students to return their token balance to the account that deployed the contract in order to fulfill the requirements for passing the ACR subject. To accomplish this, students must furnish the address of the account that deployed the contract and possess the minimum requisite number of tokens to pass the course (six tokens). Upon meeting these criteria, their address will be assigned the Boolean value true in the created mapping structure (_subjectPass), which maintains a record of addresses that have successfully completed the subject.
Req6.
To fulfill this requirement, the sending address is designated as the contract owner. Consequently, when executing functions such as transfer, approve, and balanceOf, the executing address must correspond to the one stored in the aforementioned variable. To enforce this condition, the isOwner modifier has been established to conduct this verification. Furthermore, as a precautionary measure, if there arises a necessity to change the executing address to another one, this can be achieved by invoking the transferOwnership function. Upon execution of this function, the permission previously granted to the deploying address is revoked from other addresses. Additionally, an enumerated state has been defined with two values (Enable and Locked) to denote two contrasting states. This facilitates the control of smart contract execution by altering its state using the enableState and disableState functions when necessitated by the deploying user.
Finally, regarding the limitations of the smart contract of this case study, it is worth mentioning that it is only an illustrative example of an ERC-20 token that lacks robust security mechanisms. Therefore, in order to successfully implement this proposal, the functionality of other smart contracts should be imported. These smart contracts should be designed to provide security mechanisms or prevent problems related to the logic implemented in the contract. Examples of such smart contracts are OpenZeppelin Ownable,9 SafeMath10 or other standards for fungible tokens.
In addition, SmaC supports the encoding of other standards such as ERC-223 and ERC-777. ERC-223 differs from ERC-20 in that it does not allow the transfer of tokens to contracts that do not allow the withdrawal of virtual currency. On the other hand, ERC-777 allows the prohibition of funds in and out to prevent tokens from being sent to addresses or accounts that do not handle them.
3.3 Discussion
To conclude this section, the main conclusions drawn from each of the two stages composing the validation of SmaC are presented below.
On the one hand, the empirical study of Sect. 3.1 has shown that SmaC enables the development of smart contracts in accordance with a predefined set of guidelines established by the underlying grammar. This promotes readability and fosters the implementation of best practices for smart contract development. Besides, SmaC incorporates a number of facilities to ease the coding of contracts. Minimal adjustments are typically required for existing contracts to be accommodated within SmaC, thereby enabling their representation as models. Furthermore, the facilities provided by SmaC can assist in executing these modifications effectively.
On the other hand, the case study of Sect. 3.2 has served to prove that SmaC allows the creation of smart contracts conforming to the ERC standards. This substantiates the assertion that any SmaC model is itself a Solidity smart contract, fully compatible with third-party tools, as evidenced in the case study.
In conclusion, Sects. 2 and 3 have introduced and elucidated our approach to introducing smart contracts into the realm of models, along with all the advantages and possibilities inherent in this integration. It is therefore possible to address the primary research question set out in this paper by confirming that the use of models for conceptualizing and developing smart contracts through MDE techniques can facilitate the development process, and reduce the susceptibility to errors, thanks to the pattern defined in the tool.
4 Related work
To demonstrate the unique contribution of the approach proposed in this paper relative to the existing state of the art, this section undertakes a comparative analysis with similar works and solutions found in the literature, employing a predefined set of criteria. Table 3 presents a summarized overview of this analysis, illustrating the performance of various model-based proposals against the established criteria, juxtaposed with the capabilities of SmaC.
Approach: this refers to the methodology or strategy adopted by the proposal to facilitate or empower the development of smart contracts.
HL Syntax: this criterion assesses whether the proposal includes any visual or high-level syntax (e.g., BPMN, Yawl, UML) to facilitate the specification of contracts.
LL Syntax: this criterion evaluates whether the proposal encompasses any low-level syntax, shaping a programming language, to support detailed implementation of smart contracts.
Assistance: this criterion indicates whether the approach offers auxiliary mechanisms (such as quick fixes, autocomplete, tooltips) to simplify either the development of the contract or the specification of its logic.
SC code generation: this criterion examines whether the proposal is capable of generating a complete (Solidity) smart contract.
Firstly, several proposals rely on process models such as BPMN [21, 37] or YAWL [22]. These solutions offer a web-based designer for process modeling, coupled with a compilation module to generate incomplete contracts that can be automatically deployed upon completion. Consequently, these proposals necessitate expertise in both process modeling and Solidity coding.
FSolidM [23] provides a visual notation based on state machines for creating secure Solidity smart contracts. Similarly, [24] utilizes a UML state chart to model smart contracts intended for cyber–physical systems. Both tools target developers and support only partial code generation.
Mao et al. [26] leverage a Char-RNN (recurrent neural network) to identify smart contract building patterns in existing repositories focused on the commerce domain. These patterns are translated into blocks that can be used to develop smart contracts using a blockly based visual domain-specific language (DSL). However, pattern extraction without a preliminary operational analysis may result in inheriting flaws or limitations from the analyzed contracts.
LATTE is a template-based approach that employs forms and offers warning mechanisms, guidance on storage usage, and gas optimization for smart contract development [25]. Nevertheless, it lacks support for certain Solidity abstractions, and the templates predominantly address low-level elements.
iContractML [27] introduces a visual syntax for specifying smart contract functionality. From this specification, incomplete contracts for Azure Blockchain, Hyperledger Composer, Solidity, and DAML are generated. Completion is facilitated by a Xatkit chatbot, which inherently limits it based on the chatbot’s knowledge [38].
DasContract provides nonprogrammers with a blockly based visual DSL that combines BPMN, UML, and DEMO elements to specify smart contracts [28]. It also supports partial code generation.
There are also numerous proposals offering high-level textual DSLs to abstract the complexity of smart contract coding. Some of these DSLs were designed for specific domains [29, 31, 33], while others are domain-agnostic [34, 35]. With the exception of ADICO, which employs Scala, most of these solutions have been developed using Xtext. Typically, these DSLs are utilized either to produce requirements elicitation documents that developers can follow during coding or to generate partial versions of the contract at best.
The company behind the Cardano platform, IOHK,11 offers a textual DSL built on Haskell called Marlowe and a blockly based DSL known as Meadow. Both are designed for implementing financial contracts on Cardano [32]. Despite being supported by a large consortium, this is one of the most comprehensive proposals analyzed. However, it is worth noting that it is focused solely on Cardano, whereas Ethereum remains the most popular blockchain network as for smart contracts is concerned [39].
The analysis of the state of the art has revealed various proposals geared toward specific domains, some presenting limitations regarding the level of Solidity constructions supported, others generating incomplete contracts, and still others implying the need to master several languages. Additionally, it is worth noting that in most cases, only a few or simplistic contracts are considered for evaluation purposes.
In contrast, SmaC is designed to address most of these limitations, being domain-agnostic and capable of producing complete contracts. However, the most significant contribution of SmaC is that it enables the conceptualization of contracts as models. Consequently, MDE tools and techniques can be now used to address any existing or future challenge or limitation, thereby elevating the level of abstraction at which the problem is addressed, as will be briefly discussed in the next section.
5 Conclusions and further work
This work can be considered to have a special nature since it is a kind of starting point toward a complete ecosystem of model-based tooling to work with smart contracts. Consequently, apart from the more traditional conclusions, we would like to conclude this paper describing some of the opportunities opened up by treating smart contracts as models.
5.1 Roadmap
Borrowing the terminology introduced by Cabot and Vallecillo [40], we identify ourselves as “modeling developers." As such, we naturally gravitate toward applying modeling techniques to address challenges across diverse domains. Consequently, upon venturing into the realm of smart contracts, we identified an ideal domain to lower the entry barrier by building and creating model-based solutions.
This work marks our initial foray into this direction. Its primary motivation stems from the myriad opportunities arising from managing smart contracts as models, offering several avenues for further exploration. Figure 1 illustrates some of these potential directions, categorized into two groups: (1) exploring alternative concrete syntaxes to simplify the conceptualization and development of smart contracts, and (2) constructing technological bridges to connect SmaC with modeling notations used by professionals and experts in other domains.
To illustrate the possibilities within the first group, we addressed the development of a blockly based web editor for SmaC. A working prototype was briefly introduced recently at a national forum. As shown in Fig. 17, this editor provides a visual syntax similar to Scratch12 for smart contract development, representing a significant advancement, particularly for novices in the field. With a block-based programming interface, users can conceptualize and design smart contracts without delving into the complex technical aspects of contract programming [41]. This approach not only lowers the barrier entry to smart contracts creation but also fosters further experimentation and innovation by making smart contracts accessible to a broader audience. Moreover, the straightforward development of the blockly based web editor on top of the modeling tooling provided by SmaC serves as a proof of concept for the proposal’s potential.
Another possibility, with implications similar to the previous one, is the development of a concrete syntax in the form of questionnaires. This approach would enable modeling smart contracts based on developers’ responses, and it is currently under development. The fact is that the transition of contracts into models enabled by SmaC makes the development of any necessary notation much more feasible.
Within the second group of avenues for further research, one possibility is to bring the development of smart contracts closer to professionals from business areas and domain experts [42]. To this end, we have begun exploring the building of technological bridges with the e\(^3\)value modeling notation, which focuses on representing the value exchanges between the parties involved in a business proposition [43]. Given its main purpose, e\(^3\)value has already been identified as a promising notation as a high-level abstraction analogy for smart contracts [44]. Therefore, the idea is to automate model transformations between a visual DSL for e\(^3\)value and SmaC, hereby simplifying the understanding and definition of smart contracts for non-developers who can leverage e\(^3\)value. However, using e\(^3\)value models as input to produce SmaC models results in incomplete smart contract models, due to the higher level of abstraction of the former, which lacks low-level information necessary for fully specifying the contract. Thus, to enable complete contract generation, we may introduce intermediate modeling steps, either through visual or textual DSLs, to gather additional information. We are indeed testing the first technological bridges between SmaC and e\(^3\)value in different domains with the assistance of domain experts. It is worth noting that this proposal could be extended to other domains or fields, utilizing different source modeling notations such as BPMN, UML, or any other existing DSL.
To conclude the description of the modeling ecosystem for smart contracts that we envision, we would like to share a couple more ongoing works. Firstly, we are working on integrating SmaC with existing proposals based on formal methods to calculate gas consumption. This integration will offer developers continuous information about the efficiency of the contract under development, with the IDE even suggesting optimized alternatives. Additionally, to ease the learning curve, we are developing a Xatkit bot [45] within SmaC. This bot will enable the development of smart contracts using natural language models (LLMs), providing a more intuitive approach to contract creation.
These features collectively contribute to enhancing the efficiency of smart contract development, improving quality, and bridging the gap between developers and domain experts. Ultimately, our goal is to leverage models to promote the adoption of smart contracts and blockchain technologies.
5.2 Concluding remarks
This work has served to introduce SmaC, a framework designed to leverage models for the development and conceptualization of smart contracts. The initial step in the building of such a framework has consisted in the development of an IDE for Solidity. This IDE not only offers various functionalities to facilitate coding tasks but also automatically transforms any coded contract into an EMF model, enabling further processing with model-based tools.
An empirical study has demonstrated the IDE’s effectiveness in handling existing smart contracts, requiring modifications when anti-patterns are detected. Additionally, a case study has showcased SmaC’s capability to develop complete and fully functional Solidity smart contracts, compatible with existing tools.
However, the most significant aspect of this work lies in the multitude of potential applications it enables. Beyond simplifying smart contract coding with Solidity, SmaC opens new avenues for research by integrating smart contracts into the realm of models. Once contracts can be expressed as models, numerous possibilities emerge, many of which involve reducing the learning curve and bridging the gap with non-IT experts [46]. The examples described in Sect. 5.1 are just some of many potential applications of SmaC models.
While the preceding paragraphs have briefly outlined some of the possibilities offered by bridging the modeling world closer to smart contracts, which we are currently exploring, it is evident that the number of these opportunities is virtually infinite, owing to the current maturity of the modeling field.
The invaluable contribution of Antonio Vallecillo to achieving this level of maturity cannot be overstated. This work is, in many ways, a manifestation of the inspiration drawn from Antonio’s profound commitment to harnessing the power of models to tackle real-world challenges across diverse domains. Antonio’s enduring influence serves as a guiding force, reminding us to leverage models effectively to provide solutions to the challenges faced by our colleagues and professionals in any given field.
To exemplify Antonio’s impact on our personal and professional growth, we would like to share a simple yet illustrative anecdote highlighting the significance of his work. Each of the authors of this paper presented their maiden work at the Spanish Workshop on Model-Driven Software Engineering (ISDM), an event established by Antonio Vallecillo over 15 years ago as the primary forum for the Spanish MDE community, which he has steered since its inception. Since the inaugural edition, we have faithfully attended every iteration of the workshop. In many ways, this paper is a reflection of the inspiring messages, experiences, and lessons shared by a highly respected colleague, a dedicated modeling ambassador, and a cherished friend.
Acknowledgements
This work has been partially funded by the Ministry of Science and Innovation through the SerDigital project (PID2020-117244RB-I00), the European Commission through the SIC-SPAIN 4.0 project (Safer Internet Centre Spain 4.0), and the Regional Government of Madrid through the DESAFÍO-CM project (TEC-2024/COM-235).
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Cristian Gómez-Macías
is an Assistant Professor at the Universidad Rey Juan Carlos of Madrid, Spain, where he obtained his Ph.D. in Computer Science in 2023. His research interests are focused on model driven engineering, blockchain technology and software engineering education.
Francisco Javier Pérez-Blanco
is an Assistant Professor at the Universidad Rey Juan Carlos of Madrid, Spain, where he obtained his Ph.D. in Computer Science in 2022. His research interests are mainly focused on model-driven engineering and business and process modeling.
David Granada
is an Associate Professor at the Universidad Rey Juan Carlos of Madrid, Spain, where he obtained his Ph.D. on Computer Science in 2016. His research interests are focused on Model-driven engineering and project management.
Juan Manuel Vara
is Full Professor of Software Engineering at the Universidad Rey Juan Carlos of Madrid. His current research interests are focused on model-driven engineering, service management and engineering and human aspects of software engineering.
El Sawy, O.A., Pereira, F.: Digital business models: review and synthesis. In: Business Modelling in the Dynamic Digital Space, pp. 13–20 (2013)
2.
Parmentola, A., Petrillo, A., Tutore, I., De Felice, F.: Is blockchain able to enhance environmental sustainability? A systematic review and research agenda from the perspective of Sustainable Development Goals (SDGs). Bus. Strateg. Environ. 31(1), 194–217 (2022)CrossRef
3.
Ivaninskiy, I., Ivashkovskaya, I.: Are blockchain-based digital transformation and ecosystem-based business models mutually reinforcing? The principal-agent conflict perspective. Euras. Bus. Rev. 12(4), 643–670 (2022)CrossRef
Bai, C.A., Cordeiro, J., Sarkis, J., et al.: Blockchain technology: business, strategy, the environment, and sustainability. Bus. Strateg. Environ. 29(1), 321–322 (2020)CrossRef
6.
Alharby, M., Moorsel, A.: A systematic mapping study on current research topics in smart contracts. Available at SSRN 3876872 (2017)
7.
Hossain, S.A.: Blockchain computing: Prospects and challenges for digital transformation. In: 2017 6th International Conference on Reliability, Infocom Technologies and Optimization (Trends and Future Directions)(ICRITO), pp. 61–65. IEEE (2017)
8.
Szabo, N.: The idea of smart contracts. Nick Szabo’s Papers and Concise Tutorials (1997)
9.
Zheng, Z., Xie, S., Dai, H.-N., Chen, X., Wang, H.: Blockchain challenges and opportunities: a survey. Int. J. Web Grid Serv. 14(4), 352–375 (2018)CrossRef
10.
Kaushal, R.K., Kumar, N., Panda, S.N., Kukreja, V.: Immutable smart contracts on blockchain technology: its benefits and barriers. In: 2021 9th International Conference on Reliability, Infocom Technologies and Optimization (Trends and Future Directions) (ICRITO), pp. 1–5 (2021). https://doi.org/10.1109/ICRITO51393.2021.9596538
11.
Lu, Q., Binh Tran, A., Weber, I., O’Connor, H., Rimba, P., Xu, X., Staples, M., Zhu, L., Jeffery, R.: Integrated model-driven engineering of blockchain applications for business processes and asset management. Softw. Pract. Exp. 51(5), 1059–1079 (2021)CrossRef
12.
Brambilla, M., Cabot, J., Wimmer, M.: Model-Driven Software Engineering in Practice. Morgan & Claypool Publishers, Williston (2017)CrossRef
13.
Li, C., Nie, S., Cao, Y., Yu, Y., Hu, Z.: Trace-based dynamic gas estimation of loops in smart contracts. IEEE Open J. Comput. Soc. 1, 295–306 (2020)CrossRef
14.
Durieux, T., Ferreira, J.F., Abreu, R., Cruz, P.: Empirical review of automated analysis tools on 47,587 ethereum smart contracts. In: Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering, pp. 530–541 (2020)
15.
Worley, C.R., Skjellum, A.: Opportunities, challenges, and future extensions for smart-contract design patterns. In: Business Information Systems Workshops: BIS 2018 International Workshops, Berlin, Germany, July 18–20, 2018, Revised Papers 21, pp. 264–276. Springer (2019)
16.
Kitchenham, B.A., Dyba, T., Jorgensen, M.: Evidence-based software engineering. In: Proceedings of 26th International Conference on Software Engineering, pp. 273–281. IEEE (2004)
17.
Jedlitschka, A., Pfahl, D.: Reporting guidelines for controlled experiments in software engineering. In: 2005 International Symposium on Empirical Software Engineering, p. 10 (2005). https://doi.org/10.1109/ISESE.2005.1541818
18.
Wohlin, C., Runeson, P., Höst, M., Ohlsson, M.C., Regnell, B., Wesslén, A.: Experimentation in Software Engineering. Springer, Berlin (2012)CrossRef
19.
Dhillon, V., Metcalf, D., Hooper, M.: Ethereum tokens: high-performance computing. In: Blockchain Enabled Applications, pp. 79–109. Springer (2017)
20.
López-Pintado, O., García-Bañuelos, L., Dumas, M., Weber, I., Ponomarev, A.: Caterpillar: a business process execution engine on the ethereum blockchain. Softw. Pract. Exp. 49(7), 1162–1193 (2019)CrossRef
21.
Tran, A.B., Lu, Q., Weber, I.: Lorikeet: a model-driven engineering tool for blockchain-based business process execution and asset management. In: BPM (Dissertation/Demos/Industry), pp. 56–60 (2018)
22.
Ye, X., König, M.: From the graphical representation to the smart contract language: a use case in the construction industry. In: ISARC. Proceedings of the International Symposium on Automation and Robotics in Construction, vol. 38, pp. 272–279. IAARC Publications (2021)
23.
Mavridou, A., Laszka, A.: Designing secure Ethereum smart contracts: a finite state machine based approach. In: Financial Cryptography and Data Security: 22nd International Conference, FC 2018, Nieuwpoort, Curaçao, February 26–March 2, 2018, Revised Selected Papers 22, pp. 523–540. Springer (2018)
24.
Garamvölgyi, P., Kocsis, I., Gehl, B., Klenik, A.: Towards model-driven engineering of smart contracts for cyber-physical systems. In: 2018 48th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops (DSN-W), pp. 134–139 (2018). https://doi.org/10.1109/DSN-W.2018.00052
25.
Tan, S., S Bhowmick, S., Chua, H.E., Xiao, X.: Latte: visual construction of smart contracts. SIGMOD ’20, pp. 2713–2716. Association for Computing Machinery, New York, NY, USA (2020). https://doi.org/10.1145/3318464.3384687
26.
Mao, D., Wang, F., Wang, Y., Hao, Z.: Visual and user-defined smart contract designing system based on automatic coding. IEEE Access 7, 73131–73143 (2019)CrossRef
27.
Hamdaqa, M., Met, L., Qasse, I.: iContractML 2.0: a domain-specific language for modeling and deploying smart contracts onto multiple blockchain platforms. Inf. Softw. Technol. 144, 106762 (2021). https://doi.org/10.1016/j.infsof.2021.106762CrossRef
28.
Skotnica, M., Pergl, R.: DAS contract-a visual domain specific language for modeling blockchain smart contracts. In: Enterprise Engineering Working Conference, pp. 149–166. Springer (2020)
29.
Frantz, C.K., Nowostawski, M.: From institutions to code: towards automated generation of smart contracts. In: 2016 IEEE 1st International Workshops on Foundations and Applications of Self* Systems (FAS* W), pp. 210–215. IEEE (2016)
30.
Wöhrer, M., Zdun, U.: Domain specific language for smart contract development. In: 2020 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), pp. 1–9. IEEE (2020)
31.
Dornelles, E., Parahyba, F., Frantz, R., Roos-Frantz, F., Reina-Quintero, A., Molina-Jiménez, C., Bocanegra, J., Sawicki, S.: Advances in a DSL to specify smart contracts for application integration processes. In: Anais do XXV Congresso Ibero-Americano em Engenharia de Software, pp. 46–60. SBC, Porto Alegre, RS, Brasil (2022). https://doi.org/10.5753/cibse.2022.20962
32.
Lamela Seijas, P., Thompson, S.: Marlowe: Financial contracts on blockchain. In: Leveraging Applications of Formal Methods, Verification and Validation. Industrial Practice: 8th International Symposium, ISoLA 2018, Limassol, Cyprus, November 5–9, 2018, Proceedings, Part IV 8, pp. 356–375. Springer (2018)
33.
Regnath, E., Steinhorst, S.: SmaCoNat: smart contracts in natural language. In: 2018 Forum on Specification & Design Languages (FDL), pp. 5–16. IEEE (2018)
34.
He, X., Qin, B., Zhu, Y., Chen, X., Liu, Y.: Spesc: A specification language for smart contracts. In: 2018 IEEE 42nd Annual Computer Software and Applications Conference (COMPSAC), vol. 1, pp. 132–137. IEEE (2018)
35.
Sharifi, S., Parvizimosaed, A., Amyot, D., Logrippo, L., Mylopoulos, J.: Symboleo: towards a specification language for legal contracts. In: 2020 IEEE 28th International Requirements Engineering Conference (RE), pp. 364–369. IEEE (2020)
36.
Rasti, A., Amyot, D., Parvizimosaed, A., Roveri, M., Logrippo, L., Anda, A.A., Mylopoulos, J.: Symboleo2SC: From Legal Contract Specifications to Smart Contracts. MODELS ’22, pp. 300–310. Association for Computing Machinery, New York, NY, USA (2022). https://doi.org/10.1145/3550355.3552407
37.
López-Pintado, O., García-Bañuelos, L., Dumas, M., Weber, I.: Caterpillar: a blockchain-based business process management system. BPM (Demos) 172, 1–5 (2017)
38.
Qasse, I., Mishra, S., Hamdaqa, M.: iContractBot: a chatbot for smart contracts’ specification and code generation. In: 2021 IEEE/ACM Third International Workshop on Bots in Software Engineering (BotSE), pp. 35–38 (2021). https://doi.org/10.1109/BotSE52550.2021.00015
39.
Ndiaye, M., Konate, K.: Security strengths and weaknesses of blockchain smart contract system: a survey. Int. J. Inf. Commun. Eng. 16(5), 134–143 (2022)
40.
Cabot, J., Vallecillo, A.: Modeling should be an independent scientific discipline. Softw. Syst. Model. 21(6), 2101–2107 (2022)CrossRef
41.
Reitwiessner, C.: Babbage: a mechanical smart contract language (2019)
42.
Dixit, A., Deval, V., Dwivedi, V., Norta, A., Draheim, D.: Towards user-centred and legally relevant smart-contract development: a systematic literature review. J. Ind. Inf. Integr. 26, 100314 (2022)
Gómez, C., Pérez, F.J., Vara, J.M., De Castro, V., Marcos, E.: Design and development of smart contracts for e-government through value and business process modeling. In: 54th Hawaii International Conference on System Sciences, HICSS 2021, Kauai, Hawaii, USA, January 5, 2021, pp. 1–10. ScholarSpace (2021)
45.
Daniel, G., Cabot, J.: Applying model-driven engineering to the domain of chatbots: the Xatkit experience. Sci. Comput. Program. 232, 103032 (2024)CrossRef
46.
Zheng, Z., Xie, S., Dai, H.-N., Chen, W., Chen, X., Weng, J., Imran, M.: An overview on smart contracts: challenges, advances and platforms. Future Gener. Comput. Syst. 105, 475–491 (2020). https://doi.org/10.1016/j.future.2019.12.019CrossRef
