Public blockchains are increasingly important in industries such as nance, supply-chain management, and governance. In the last two years, there has been increased usage of blockchain for decentralized nance (DeFi). The usage of DeFi mainly consists of cryptocurrency lending and providing liquidity for decentralized exchanges. However, the considerable volume of reports shows large nancial losses during network congestion, increasing transaction prices, programming errors, and hacker attacks. One survey suggested that only 40% of people working with DeFi smart contracts understand their source code. To address the issues, this paper proposes a model-driven approach to create blockchain smart contracts based on a visual domain-speci c language called DasContract. An improved design of the DasContract language is presented, and a code generation process into a blockchain smart contract is described. The proposed approach is demonstrated on a proofof-concept model of a decentralized mortgage process where the contract is designed, generated, and simulated in a blockchain environment.
The blockchain smart contracts promise a revolution in many industries that
so far resisted the digital revolution. They may play a signi cant role in
nance, supply chain management, voting, and many other industries. However,
the promises of the blockchain technology were not yet materialized. According
to the Gartner, mainstream adoption is expected in 2030 [
The public blockchains' primary use is currently the decentralized nance
(DeFi) that is used for decentralized exchanges and crypto loans. However, there
are many problems DeFi is currently facing. The rst one is network congestion,
which increases the transaction processing time and price (that reaches up to
12 USD per transaction [
To address these challenges, a visual language for modeling smart contracts,
DasContract, has been proposed in [
Therefore, this paper aims to bridge the gap and build on top of the
preliminary research. First, the DSL initially provided by the DasContract
paper [
The paper is organized as follows: In Section 2, the research method and the research question are formulated. In Section 3, the underlying scienti c foundations are brie y discussed. An approach to generate blockchain smart contracts from a DasContract language is introduced in Section 4. The proposed approach is demonstrated on a Mortrage case study in Section 5. The related research is discussed in Section 6. Finally, in Section 7, the current results are summarized, and further research is proposed.
This research applies the design science (DS) approach of Hevner [
First conceptualized in 2008 [
A smart contract is a computer protocol that allows creating digital contracts
between multiple parties without a need for a trusted third-party intermediary.
Once deployed, the smart contract will automatically evaluate the commitments
that may occur to the parties over time, based on the agreed terms [
Ethereum [
As further described in [
As described by Voshmgir [
On the Ethereum platform, Ethereum Improvement Proposals (EIPs) [
One of these standards is the ERC-20, providing a typical list of rules on how
the tokens should be structured. These tokens are fungible, meaning that tokens
of the same type are interchangeable. That makes them easy to trade, as there
is no need to di erentiate the tokens. To represent unique assets, however, the
tokens must be non-fungible { every token is unique and non-interchangeable,
even if they are of the same type. In order to facilitate these types of tokens, the
ERC-721 standard was created. [
Uni ed Modeling Language (UML) [
The DasContract was rst introduced in [
The main goal of the DasContract is to provide a way to conclude digital contracts for people, companies, and governments without the need for an intermediary. The contract conditions are agreed on upfront and inserted into a blockchain smart contract that ensures the contract's immutability and execution according to the agreed conditions.
The proposed concept architecture of the DasContract is shown on Figure 2. First, a contract between parties is formalized using the DasContract language and a legal text, then a smart contract is generated, and nally, the people, companies, and legal authorities interact according to the smart contract logic.
However, the original paper does not provide a straightforward method for translating the DEMO model to the executable BPMN and does not provide
code generation algorithms. This leaves a gap that this paper aims to ll by
introducing a new DSL language (shown in Figure 3) and describes how the
smart contract code should be generated.
4 Towards Generating Smart Contracts from DasContract
Language
This section introduces a way to generate blockchain smart contracts using a
Model-Driven Engineering approach (MDE) [
The new DasContract DSL metamodel is shown on g. 3. The original
DasContract metamodel was based on DEMO models. Although the execution of
DEMO models is described in [
As a basis for the execution behavior, an extended subset of BPMN 2.0 level 3 is used. However, compared to the BPM systems that interpret the model, an approach that generates code with the model behavior is used. This approach is used due to blockchain performance and storage limitations. Each line of code executed in the blockchain costs money, and the storage costs are also at a premium.
The algorithm described in this paper is implemented in C# programming
language and published on Github under an MIT license [
ProcessRole + Id: string + Name: string + Description: string 0..* 0..*
0..*
ProcessUser + Id: string + Name: string + Description: string 0..* 1 0..* 1
Contract + Id: string + ProcessDiagram: string 1 1
Process + Id: string 1 0..*
ProcessElement + Id: string + Name: string 1 1 1 1 StartEvent
EndEvent
ParallelGateway
ExclusiveGateway 0..* 0..* Source Target
Entity + Id: string + Name: string
SequenceFlow + Id: string + Name: string + Condition: string 0..* 0..*
1 low1 F e c n e u q e S lt u a f e
D 0..* Gateway
Property 0..* + Id: string + Name: string + IsMandatory: boolean + IsCollection: boolean + Type: PropertyType <<Enumeration>>
PropertyType Int Uint Bool String DateTime Address AddressPayable Data
Entity
ScriptTask + Script: string
BusinessRuleTask + BusinessRuleDefinitionXml: string <<Enumeration>>
FormFieldType Property Custom s e l o R e t a d i d n a C s r e s U e t a d i d n a C e e n g i s
A 0..* 0..* UserTask
0..* + Id: string + Name: string + Id: string 1 1 UserForm 1
StartForm 1
Event 0..*
Task
ServiceTask + ImplementationType: string + Configuration: string
FormField + Id: string + Order: int 0..* + Type: FormFieldType + DisplayName: string + IsReadOnly: boolean + PropertyExpression: string + CustomConfiguration: string
The DasContract DSL consists of the following models: Data Model Speci es data structures used inside of the smart contract. These structures can be referenced inside of the process model. Process Model Speci es a contract's business process as an extended subset of the BPMN 2.0 language. Forms Model Speci es a user form required to ll by the user in a process user task. The forms provide a way to interact with smart contracts.
The data model's implementation is straightforward because the blockchain smart contract languages provide generous native support to specify data structures. The supported concepts are entities, properties, entity properties, and arrays. Each property can also be marked as mandatory. The data types of properties are Int, UInt, Bool, String, DateTime, Address, AddressPayable, Data, Entity. The types Address and AddressPayable are blockchain speci c and support cryptocurrency or token payments.
Example Let's have an entity Payment with four properties { two addresses identifying the sender and receiver, a numeric de ning the amount sent and a boolean indicating whether the payment was on schedule. The generated code is shown in Listing 1. struct Payment { uint256 amount; bool onSchedule; address sender; address receiver;
The process model uses an extended subset of the BPMN 2.0 level 3 notation.
The formal speci cation of a BPMN execution is already well researched, and
there are many di erent formalizations such as [
The blockchain smart contracts are more similar to a programmable database rather than a desktop, web, or console application. Due to this fact, not all of the BPMN concepts can be implemented or make sense. Therefore only a limited subset is implemented: user task, script task, XOR gateway, parallel gateway, start event, and end event. The blockchain-speci c activities were added: payment task. The payment task is a task attribute that can be added to both user and script task to add support to work with cryptocurrency or tokens. Process Flow Exclusive gateways are converted into a sequence of if-else statements, advancing the execution based on the statement's result. Parallel gateways are more complex, as they can not only create multiple execution branches but are also used for synchronizing multiple ows (branches) into a single ow. If a gateway has multiple incoming ows, then a counter is de ned, keeping track of the number of ows that have reached the gateway. The outgoing ows are triggered once the counter matches the number of incoming ows. An example can be seen in Listing 2, that contains the logic of parallel gateways generated based on Figure 4. Activities Functions are also used to encapsulate the logic of activities. Unlike the internal gateway functions, these functions are publicly visible. User activities allow accepting parameters and store them inside of the contract using property binding logic. The generator also allows restricting access to function execution based on the executor's address. This is done using roles de ned using square brackets inside the name of the activity (see Figure 4). The addresses to each role are assigned at runtime, meaning that anyone can execute an activity with an unassigned role. The rst execution assigns the role, reserving the remaining activities of the given role to that address. modifier isEscrowPropertyRightsState{ require(isStateActive("EscrowPropertyRights")==true); _; function EscrowPropertyRights(bool Agree) isEscrowPropertyRightsState isEscrowPropertyRightsAuthorized public {
ActiveStates["EscrowPropertyRights"] = false; escrowagreement.agreeToEscrow = Agree; ActiveStates["EscrowProperty"] = true;
EscrowProperty(); Listing 3. User task logic generated based on the model snippet in Figure 4.
An example of a converted user activity can be seen in Listing 3, generated based on the Escrow Property Rights activity in Figure 4. The generated function contains two modi ers, checking whether the contract is in the valid state and whether the executor (Property Owner role) is authorized. The function has one input parameter that has been de ned using the editor. This parameter is then stored inside the contract according to the de ned property binding logic. An address of the property owner is read from the msg.sender property that provides a sender's public address veri ed by his private key while sending the transaction to the blockchain.
Token Activities Described in Section 3.3, tokens play a signi cant role in the smart contract ecosystem by allowing to express ownership of an asset. By complying with the token standards, these tokens can also interact with other smart contracts. An activity that would allow us to create/send/receive tokens would signi cantly improve the generated smart contracts' capabilities. For example, it would allow sending voting ballots (in the form of a token) to the voters.
The forms model de nes a form that is shown to a user and allows interaction with a contract. Such logic is implemented in two places called on-chain and o -chain. On-chain code is run inside the blockchain. Our algorithm is represented as parameters that are passed into a function generated from a user task. An example is shown on Listing 3 - the method EscrowPropertyRights contains a parameter Agree that will be provided by the user while calling the method. O -chain code is run inside a cryptocurrency wallet to provide the user with comfortable user experience while interacting with a smart contract. However, the Ethereum Solidity does not support o -chain code, and therefore we leave this aspect for further research.
For the modeling of the new DasContract models, a new visual modeling
environment was created. The visual modeling reduces the modeler's errors and
reduces the time required to produce a model. The modeling environment is
available on Github under an MIT license [
Compilation to the Solidity code assumes a valid DasContract model created in the modeling environment and does not check for other errors. The last check is done during the Solidity code compilation (usually in the Remix environment) and allows the modeler to x issues in custom script tasks and user task validation logic.
There are the following limitations to this approach, and they should be
addressed in future research. First, the script tasks and a validation logic of
user tasks still need to be expressed in Solidity language. An
implementationindependent DSL for such expressions should be added to the design of the
language. Second, the language only contains support for receiving tokens.
Support to issue both fungible and non-fungible tokens would be required. Third,
it is not clear how would people authenticate themselves and prove their roles
outside of the standard smart contract wallet. A way to support decentralized
identity standards such as W3C DID should be explored. Finally, according to
Gartner [
This section provides a case study to demonstrate the capabilities of the
approach proposed in the previous section. A case of a decentralized mortgage
that supports non-fungible tokens (ERC-721) to represent the property
ownership was created. This case study designs the process in a decentralized way
that means that the property token is held in the smart contract as collateral.
A scenario where the lenders can request a default of the loan is modeled. The
complete DasContract model and the generated source code are published on
Github under an MIT license [
[Borrower] Cancel Application [Lender] Escrow Money
[Property Owner] Escrow Property Rights [Insurer] Accept
Insurance [Borrower] Apply For a Mortgage
Validate
Contract [Insurer] Pay for the Borrower Invalid
Valid [Borrower] Pay Mortgage Fee
Check Payment
Schedule Payment to the Insurer and Lender Payment On
Schedule [Lender] Request Default
Validate Terms
Violation
Terms Violated Terms Not Violated Release Escrows
Invalid
Valid Pay Owner Payment
Contract
Canceled Transfer the Property to the
Borrower Loan Completed Transfer the Property to the
Lender
Loan Defaulted [Insurer] Check Indemnity Terms
Behind Payment
Payments
Finished [Lender] Transfer Proportion Money to the
Borrower
The following steps were taken while conducting this case study: 1) A
DasContract model was created in a visual editor. 2) An Ethereum Solidity smart
contract code was created by an algorithm described in Section 4. 3) A
simulation of the generated smart contract was performed in the Remix [
The process model of the proposed process can be seen in Figure 5. The process begins with a borrower applying for a mortgage. Three other parties { insurer, property owner, lender { must then con rm their involvement by carrying out their speci c action. If any of them declines, or the borrower changes their mind, then the contract is deemed invalid, and any escrows that have been already transferred will be released back to their previous holders.
When all parties agree and the contract is successfully validated, then the full payment to the owner is automatically released, also ending their involvement in the contract. In the next phase of the contract, the borrower is tasked to carry out to periodically pay the mortgage fees. Those fees are then automatically distributed to the insurer and lender. The payment schedule is checked afterward, resulting in three possible scenarios. First, the payment is on schedule; the contracts state will return to \waiting" for another payment. Second, The payments are behind schedule; in this case, the insurer checks the indemnity terms, paying for the borrower if they are met. Third, the payments are nished, in which case the property is automatically transferred to the borrower, ending the contract.
Before the payments are fully nished, the lender is also at any time allowed to request for borrower's default to check whether the borrower has not violated terms. If the terms have indeed been violated, then the lender will pay proportion money de ned in the terms to the borrower. The property will then be transferred to the lender, ending the contract.
The described process was simulated using the Remix IDE. The test environment allows to perform transactions from various addresses, enabling to simulate people interacting with the smart contract. The transaction was successfully run by the borrower (left sidebar), returning status information about the transaction (right window).
The limitations of the case study are the following. First, the mortgage is
paid in a cryptocurrency, which is a very volatile asset. This can be addressed
using a stablecoins [
A very similar research is done by the Caterpillar project [
Other approaches provide a graphic environment to visually compose smart
contract code based on Blockly [
The paper introduced an approach to creating a model-driven blockchain smart contracts. The potential bene ts are: 1) An increase readability of the blockchain smart contracts by providing a visual DSL that allows contract simulation. 2)The simulation also contributes to eliminating smart contract errors as the behavior can be examined before publishing the contract. 3)The expressivity was improved by a complete redesign of the DasContract DSL and providing the capability to support non-fungible tokens. To demonstrate the proposed approach's functionality, a decentralized mortgage case study was presented in Section 5. The mortgage case was modeled; a Solidity code was generated and simulated in the Remix environment.
The major limitation of this approach remains the immaturity of available
blockchain implementations. According to the Gartner [
Further research is following: 1) Support for generation of smart contracts
on di erent platforms. 2) Case studies and usability studies to improve the
proposed language design. 3) Explore a possible extension with more BPMN
symbols and concepts. 4) Explore a possible extension of the proposed model by
DMN [
Acknowledgement This research has been supported by CTU SGS grant No. SGS20/209/OHK3/3T/18