Process Digitalization using Blockchain: EU Parliament Elections

Case Study

Marek Skotnica

1 a

, Marta Apar

ıcio

2 b

, Robert Pergl

1 c

and S

ergio Guerreiro

2 d

Faculty of Information Technology, Czech Technical University, Prague, Czech Republic

Department of Computer Science, Instituto Superior T

ecnico, Lisbon, Portugal

Keywords:

Blockchain, Smart Contracts, Digitalization, Elections.

Abstract:

Blockchain aims to be a disruptive technology in many aspects of our lives. It attempts to disrupt the aspect of

our lives that were hard to digitize, such as democratic elections or were digitized in a centralized way, such as

the ﬁnancial system or social media. Despite the initial success of blockchain platforms, many hacks, design

errors, and a lack of standards was encountered. This paper aims to provide a methodical approach to the

design of the blockchain-based systems and help to eliminate these issues. The approach is then demonstrated

in an EU parliament elections case study.

1 INTRODUCTION

The Blockchain smart contracts promise a way to dig-

itize processes where value and trust are involved.

This applies to processes in many industries, such as

supply chain management, ﬁnance, government pro-

cess automation, voting, and many others. However,

there are many challenges to overcome before es-

sential processes can be deployed to the Blockchain.

For example, after deploying a smart contract to the

Blockchain, the smart contract cannot be updated, and

possible errors cannot be ﬁxed. The errors may result

in signiﬁcant monetary or security damage. There-

fore, a methodical approach to design, validate, im-

plement, and simulate is needed to address the prob-

lem.

This paper describes a method to digitize pro-

cesses using Blockchain technology based on the

Business Process Management (BPM) method and

the Model-Driven Engineering (MDE) approach. It is

expected that by applying this method, the program-

ming errors will be reduced.

To demonstrate the functionality of the proposed

approach, a EU parliament elections case study was

created. A model of a EU parliament elections vot-

ing process running in Blockchain was modeled, a

https://orcid.org/0000-0002-8811-3389

https://orcid.org/0000-0002-1857-0381

https://orcid.org/0000-0003-2980-4400

https://orcid.org/0000-0002-8627-3338

Blockchain smart contract was generated, and ﬁnally,

a simulation of the functionality was performed.

The paper is organized as follows: In Section 2,

the research method and the research question are for-

mulated. A related research is covered in Section 3.

In Section 4, the underlying scientiﬁc foundations are

brieﬂy discussed. An approach to digitize processes

using the Blockchain technology is introduced in Sec-

tion 5. The proposed approach is demonstrated on a

EU parliament elections case study in Section 6. In

Section 7, the current results are summarized, and fur-

ther research is proposed.

2 RESEARCH QUESTION AND

METODOLOGY

The research question is: How to digitize processes

using blockchain smart contracts in a methodi-

cal way and eliminate programming errors while

avoiding a dependency on a particular blockchain

implementation?

The design science research approach is applied

in this paper as described in (Hevner et al., 2004;

Hevner, 2007), which is shown in Figure 1. In the

ﬁrst cycle, a relevance of the problem is discussed in

Section 1. The environment in which this research is

applied is model driven engineering. The challenge

is the application of the MDE to the blockchain tech-

nology. The environment in which this research is

Skotnica, M., Aparício, M., Pergl, R. and Guerreiro, S.

Process Digitalization using Blockchain: EU Parliament Elections Case Study.

DOI: 10.5220/0010229000650075

In Proceedings of the 9th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2021), pages 65-75

ISBN: 978-989-758-487-9

Figure 1: Design Science Research Cycles (Hevner, 2007).

applied is electronic voting.

The second cycle is described in Section 6 and

Section 7. A complex case from the domain is mod-

elled and simulated as a blockchain smart contract.

And, ﬁnally, the relevant grounding into the ex-

isting knowledge base is in Section 5, Section 6.

The Section 3 provides an overview of existing ap-

proaches, and the Section 5 shows how to apply the

MDE approach to the blockchain technology.

3 RELATED RESEARCH

There have been attempts at raising the level of ab-

straction from Code-Centric to Model-Centric Smart

Contracts development. The different approaches

tried so far can be divided into three: the Agent-

Based Approach, the State Machine Approach, and

the Process-Based Approach (Apar

ıcio. et al., 2020).

For this research and going further into state of the art

already mentioned in (Skotnica and Pergl, 2020), di-

rectly related to this paper, the main focus will be the

Process-Based Approach.

In (Weber et al., 2016) was proposed a tool

to support inter-organizational processes through

Blockchain technology. To ensure that the joint pro-

cess is correctly executed, the control ﬂow and busi-

ness logic of inter-organizational business processes

are compiled from the processes models into Smart

Contracts. Weber et al. developed a technique to

integrate Blockchain into the choreography of pro-

cesses to maintain trust, employing triggers and web

services. By storing the status of process execution

across all involved participants, as well as to coordi-

nate the collaborative business process execution in

the Blockchain. The validation was made against the

ability to distinguish between conforming and non-

conforming traces. (Garc

ıa-Ba

nuelos et al., 2017) pre-

sented an optimization in regards to the already pre-

sented paper (Weber et al., 2016). To compile BPMN

models into a Smart Contract in Solidity Language,

the BPMN model is ﬁrst translated into a reduced

Petri Net. Only after this ﬁrst step, the reduced Petri

is compiled into a Solidity Smart Contract. Com-

pared to (Weber et al., 2016), (Garc

ıa-Ba

nuelos et al.,

2017) managed to decrease the amount of paid re-

sources and achieve higher throughput. Caterpillar,

ﬁrst presented in (Pintado, 2017) and further dis-

cussed in (L

opez-Pintado et al., 2018), is an open-

source Business Process Management System that

runs on top of the Ethereum Blockchain. Like any

BPMS, Caterpillar supports the creation of instances

of a process model (captured in BPMN) and allows

users to track the state of process instances and to ex-

ecute tasks thereof. The speciﬁcity of Caterpillar is

that the state of each process instance is maintained on

the Ethereum Blockchain, and the workﬂow routing is

performed by Smart Contracts generated by a BPMN-

to-Solidity compiler. Given a BPMN model (in stan-

dard XML format), it generates a Smart Contract (in

Solidity), which encapsulates the workﬂow routing

logic of the process model. Speciﬁcally, the Smart

Contract contains variables to encode the state of a

process instance, and scripts to update this state when-

ever a task completes or an event occurs. (Tran et al.,

2018) presented a tool that automatically creates a

well-tested Smart Contract code from speciﬁcations

that are encoded in the business process and data reg-

istry models based on the implemented model trans-

formations. The BPMN translator can automatically

generate Smart Contracts in Solidity from BPMN

models while the registry generator creates Solidity

Smart Contract based on the registry models. The

BPMN translator takes an existing BPMN business

process model as input and outputs a Smart Contract.

This output includes the information to call registry

functions and to instantiate and execute the process

model. The registry generator takes data structure in-

formation and registry type as ﬁelds, and basic and

advanced operations as methods, from which it gen-

erates the registry Smart Contract. This work builds

upon already seen works, such as (Garc

ıa-Ba

nuelos

et al., 2017; Weber et al., 2016), for the BPMN trans-

lation algorithms.

Going into further detail over the case study do-

main, highly used as a case study in research (Horcas

et al., 2014), voting is a fundamental part of demo-

cratic systems. The current voting system raises con-

cerns for those who depend on it to elect their rep-

resentative, particularly concerning integrity; secu-

rity; transparency; and accessibility, which translates

into low turnout. E-voting by itself doesn’t address

all these concerns due to requiring supervision by a

central authority. However, combining the E-voting

solution with the Blockchain technology could be a

solution, since the latter is decentralized, and dis-

tributed (Curran, 2018).

In (Dagher et al., 2018) was proposed a

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

blockchain-based voting system, named BroncoVote,

that preserves voter privacy and increases accessibil-

ity, while keeping the voting system transparent, se-

cure, and cost-effective. BroncoVote used the smart

contracts in Ethereum blockchain to keep a record

of every user in the system as well as all the bal-

lots and the information regarding them. The smart

contracts were also used to achieve access control.

Besides, integrating Paillier homomorphic encryption

into the system to preserve voter privacy. By resorting

to Ethereum’s blockchain and smart contracts, they

enabled voters administration and auditable voting

records. However, it is important to keep in mind that,

in Ethereum any computation requested has to be paid

according to a preset deterministic unit called gas,

which has a variable real-world cost. Thus reducing

the computation performed on the blockchain is im-

perative to reduce the cost of a service running off the

blockchain (Azzopardi et al., 2020). As in (Dagher

et al., 2018), (Khoury et al., 2018) also suggests the

usage of blockchain technology to solve trust issues.

It suggests a new business model for voting service

providers, where the voting service provider enables

the voting event organizers to deploy an event voting

smart contract. The event management server deploys

in the Ethereum network the voting contracts conﬁg-

ured according to the voting event customer. (Zhang

et al., 2019) presents an Ethereum based electronic

voting protocol, Ques-Chain, that may surpass the

voting domain to other ﬁelds with similar needs. This

protocol responds to problems of three entities, for

the e-voting systems tackles the threat of malicious

manipulation by hackers, for the service providers

helps to prevent and eliminate scams, given the high

costs to perform data cleaning, at last, for the voters

tackles the doubts that may arise about the integrity

of the voting procedure and anonymity failure. The

protocol presented can be divided roughly into four

stages: Setup Stage, where the organizer initialize

the e-voting; Sign Stage, where the voter will get a

signed-blinded-ballot from the organizer; Vote Stage,

where the voters vote; Count Stage, where the voters

will count legal ballots and publish the results. There

are some similarities between the last work mentioned

and (Al-Rawy and Elc¸i, 2018). However, the latter

divides the voting process into six phases. Both re-

sort to blockchain technology and public-private key

systems. At last, in (Bellini et al., 2018), a process-

centric blockchain-based architecture, called Hyper-

Vote, is discussed. The advantage of HyperVote over

the other papers here presented is that the ﬁrst fol-

lows the business trend of cloud computing, virtually

turning it into an online service (XaaS). Meaning in a

more practical manner that HyperVote is able to sup-

port dynamic selection, deployment, and execution of

an e-voting process whose requirements are tailored

to the user needs. It is a pay-per-use conﬁgurable ap-

proach bringing on costs during the limited timeframe

of an election. This allows to optimize the allocation

of resources as the same infrastructure can serve dif-

ferent customers in different time frames. The Hy-

perVote is an XML based data structure containing

all the information required by the execution environ-

ment to deploy, execute, account, and monitor the ser-

vice. The HyperVote binds a Workﬂow Model with

the concrete Atomic Services (chaincode) and Hyper-

ledger Network structure and Cloud Infrastructures

that will be invoked and selected by the workﬂow, re-

spectively, when executed.

4 METHODOLOGIES USED

4.1 BPM

A process is a collection of events, activities, and de-

cisions that collectively lead to an outcome that brings

value to an organization’s customers. Understand-

ing and managing these processes to ensure that they

consistently produce value is critical for the effective-

ness and competitiveness of an organization. Busi-

ness Process Management is a body of principles,

methods, and tools to discover, analyze, redesign, im-

plement, and monitor business processes. Process

models and performance measures are foundational

pillars for managing processes. Since these pillars

help to achieve business goals efﬁciently and effec-

tively while complying with boundary requirements

for governance, risk, and compliance.

There are many languages for modeling business

processes diagrammatically, perhaps one of the old-

est are ﬂowcharts. Nowadays, there is a widely-used

standard for process modeling, namely the Business

Process Model and Notation (BPMN). BPMN is an

industry-standard for workﬂow procedures, supported

by the Object Management Group (OMG).

4.2 MDE

One of the promising methods that can facilitate

the development of Smart Contracts is Model-Driven

Engineering. Through Model-Driven Engineering,

executable code can be generated for Smart Con-

tracts from a set of models that specify the pro-

cesses to be supported. For instance, (Horcas et al.,

2014) and (Mavridou and Laszka, 2018) are tool-

supported methods that allow the generation of So-

lidity (Ethereum Foundation, 2020) Smart Contracts

Process Digitalization using Blockchain: EU Parliament Elections Case Study

from BPMN diagrams and ﬁnite state machines, re-

spectively.

Using Model-Driven Engineering requires a set

of models to be used as input for code generation.

In particular, rather than focusing on algorithms and

the elaboration of code, it focuses on the creation of

models as representations of the software to be built.

These models are then used to be transformed into

other models or code. Key aspects of this transfor-

mational approach are that it speeds up the creation

of software, that it enhances software quality, and

that it facilitates the portability and interoperability

of software. In ”Towards a shared ledger business

collaboration language based on data-aware pro-

cesses” (Hull et al., 2016) called for the development

of a shared ledger business collaboration language,

which should be a language that business people can

understand and use in cross-organizational business

processes supported by blockchain technology.

4.3 Blockchain

(Nakamoto, 2009) described the Blockchain as an ar-

chitecture that enables participants to perform elec-

tronic transactions without relying on trust. This

makes it possible that each block contains some data,

the hash of that block, and the hash of the previous

block. The data stored in a block corresponds to mul-

tiple transactions, and each transaction has an identi-

ﬁcation for the sender, receiver, and asset. The block

also has a hash, which identiﬁes its content and is

always unique. If something is changed within the

block, it will cause the hash value to change. This is

why hashes are useful for detecting changes in blocks.

The hash value of the previous block effectively cre-

ates a Blockchain, and it is this technology that makes

the Blockchain so secure. However, the hashing tech-

nology is far from enough, as the high computing

power that exists today, among which the computer

can calculate thousands of hashes per second. To mit-

igate this problem, the Blockchain has a consensus

mechanism called Proof-of-Work. This mechanism

slows down the creation of new blocks since if a block

is tempered, the Proof-of-Work of all the previous

blocks has to be recalculated. Therefore, the security

of Blockchain comes from its creative use of hashing

and a Proof-of-Work mechanism. Of course, its dis-

tributed nature also adds a certain degree of security

because the Blockchain does not use a central entity

to manage the chain, but uses a peer-to-peer network

that anyone can join.

As a new technology, Blockchain raises questions

regarding its viability. As (Garther, 2019) claims,

Blockchain technology is still very immature to sup-

port most of the potential use cases and is still a

tremendous amount of research, implementation, and

adoption to be done. Further, building systems on

Blockchain is non-trivial due to the steep learning

curve of the Blockchain technology. According to

a survey by (Gartner, 2018), “23 percent of [rele-

vant surveyed] CIOs said that blockchain requires the

newest skills to implement any technology area, while

18 percent said that blockchain skills are the most dif-

ﬁcult to ﬁnd.”.

4.4 Smart Contracts

Blockchain is run by machines that essentially per-

form three things: networking, consensus, and state

management. These machines must run application-

layer software responsible for updating the state. For

Blockchains like Ethereum (Vitalik Buterin, 2013),

a Turing-complete virtual machine is the application

layer. The software programs that developers deploy

to the Blockchain virtual machine are usually called

Smart Contracts. The Ethereum Blockchain was

speciﬁcally created and designed to support Smart

Contracts. Solidity is a high-level programming lan-

guage to implement Smart Contracts specially design

for the Ethereum Virtual Machine (EVM). the smart

contracts are deployed onto the blockchain in the form

of a specialized bytecode. This bytecode then runs on

each Ethereum node in EVM. Since creating smart

contracts directly in the bytecode would be too im-

practical, multiple specialized high-level languages

have been created, together with the compilers needed

to convert them into EVM bytecode.

The smart contract itself is written in any sim-

ple language, depending on which Blockchain will be

deployed, and is usually very short. Although they

are relatively short, they are extremely powerful as

they leverage the huge power of cryptography and

blockchains since they operate across organizations

and between individuals. Smart contracts can store

records of who owns what, as well as promises with-

out the need for intermediaries or exposing people to

fraud. These contracts can automatically execute in-

structions given in the past. For pure digital assets,

there is no setback, because the value to be trans-

ferred can be locked in the contract when the con-

tract is created, and automatically released when the

conditions and terms are met. In this case, fraud is

impossible because the program can truly control the

assets involved without the need for a trusted inter-

mediary. Like all algorithms, Smart Contracts may

require input values and only act if certain prede-

ﬁned conditions are met. When a particular value is

reached, the Smart Contract changes its state and ex-

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

ecutes the functions, that are programmatically pre-

deﬁned algorithms, automatically triggering an event

on the Blockchain. If false data is entered into the

system, then false results will be outputted.

4.5 Tokens

From what has been written throughout this paper,

the use of Blockchain technology seems the future

to manage digital assets, due to its security and im-

mutability features. In (Voshmgir, 2019) tokens are

described as ways to represent ”programmable assets

or access rights, managed by a smart contract and

an underlying distributed ledger. They are accessible

only by the person who has the private key for that ad-

dress and can only be signed using this private key.”

However, without the use of fungible tokens, this

would be impossible to do since no unique informa-

tion can be written into the token. To represent to-

kens that have to be unique and hold information in-

stead of values, non-fungible tokens are preferred. On

one hand, the fungible tokens can be exchanged to

any other token of the same type. Non-fungible to-

kens, on the other hand, cannot be replaced by other

non-fungible tokens of the same type. For these rea-

sons, the fungible tokens are uniform, meaning they

are identical to one another, where the non-fungible

tokens are unique. Fungible tokens are divisible into

smaller units, while the non-fungible tokens cannot

be divided. In this paper, the non-fungible tokens are

used to represent voter’s ballots.

Due to the need to standardize the general struc-

ture of Ethereum Blockchain tokens, Ethereum Im-

provement Proposals (Ethereum, 2020) was created.

These standards allowed for Smart Contracts running

on Ethereum to interact with tokens deﬁned by other

Smart Contracts. One of these standards is the ERC-

20, providing a typical list of rules on how the fun-

gible tokens should be structured. That makes them

easy to trade, as there is no need to differentiate the to-

kens. To represent unique assets, however, the tokens

must be non-fungible, even if they are of the same

type. In order to facilitate these types of tokens, the

ERC-721 standard was created (Voshmgir, 2019).

4.6 Das Contract

The Das Contract (Skotnica and Pergl, 2020) is a

DSL designed to be an implementation-independent

language for specifying blockchain smart contracts.

The Das Contract speciﬁcation is based on a sub-

set of BPMN 2.0 (OMG, 2011), UML class dia-

gram (OMG, 2015) and extended with concepts spe-

ciﬁc to the blockchain execution environment. The

Legal Text

Formal

Models

A Person

A Company

A Legal

Authority

A Smart

Contract

Code

Generation

A Blockchain

A Contract

Human Understanding Technical Implementation Digital Interaction

Figure 2: A proposed concept architecture of DasCon-

tract (Skotnica and Pergl, 2020).

extension allows to specify off-chain forms to interact

with the smart contract, smart contract logic, and abil-

ity to work with payments or tokens. The language is

still under development, and it will be enhanced with

the support of decentralized identity and data oracles.

According to the (Skotnica and Pergl, 2020) and

shown in Figure 2, DasContract’s approch consists of

three parts:

Human Understanding: part deﬁnes a contract be-

tween multiple parties that they need to agree on.

Such a contract is a combination of legal text

and formal ontological models. The legal text in

some form speciﬁes the legal validity of the for-

mal model.

Technical Implementation: part speciﬁes how for-

mal models from the contract are transformed into

a software executable code and uploaded into a

blockchain as a smart contract.

Digital Interaction: is a part where people, compa-

nies and legal authorities can interact with the

agreed upon contracts. Since the contract is in

a blockchain, the interaction is fully digital, and

thanks to cryptography can also be legally bind-

ing. Blockchain by design also provides an audit

trail of all actions performed by the parties and

ensures that the agreed upon contract is executed

correctly.

5 OUR APPROACH

Our approach was designed to answer the research

question from section 2. It adopts the BPM method-

ology to provide a methodical way of designing a

blockchain smart contract. A Model-driven engineer-

ing approach is used to generate a smart contract

source code for a particular blockchain. In this pa-

per an Ethereum smart contract platform is used, but

the approach can be generalized. An application of

our approach is shown in section 6 on a process of

EU parliament elections.

Process Digitalization using Blockchain: EU Parliament Elections Case Study

The BPM life-cycle in context of digitizing a process

to be used in blockchain technology is following:

1. Design - A process is designed in a DasContract

language with blockchain limitations in mind.

The major limitation compared to a traditional

software system is it’s immutability and a require-

ment that all performed actions are deterministic.

2. Modeling - A simulation of the DasContract may

be performed to ensure the correct behaviour of

the process. This may be critical because the con-

tract can’t be changed after being deployed and

it may be handling signiﬁcant monetary or legal

value.

3. Execution - A smart contract source code is gener-

ated and uploaded to the blockchain. Because the

metamodel is implementation independent, any

supported blockchain platform can be chosen.

4. Monitoring - Due to the inherent blockchain ca-

pability to record all transaction history, auditing

and analysis of process execution history can be

done.

5. Optimization - The optimization is not relevant in

blockchain because once the smart contract is up-

loaded it is not possible to change it.

6. Re-engineering - Similar to the optimization, the

re-engineering is not available. A new process can

be designed and uploaded to the blockchain but

the old one will be still running.

5.1 Das Contract to Smart Contract

Transformation

The DasContract consists of three interconnected

models: process model, data model, and forms model.

The metamodel of the data and forms models is

shown on Figure 3. The highlighted parts in blue are

the recent additions to support the representation of

fungible and non-fungible tokens and enums. The to-

kens inherit from the entity, and therefore they can

have data properties to represent token metadata.

Process Model: speciﬁes the contract’s process ac-

tivities, their execution order, property mappings, and

user roles. The model is based on an extended subset

of the BPMN 2.0 level 3 notation. The main addition

is support for blockchain tokens (described in Sec-

tion 4.5) that allows to issue and receive both fungi-

ble and non-fungible tokens. During the transforma-

tion, the process sequence is transformed into a smart

contract programming language statements such as if-

else, functions, etc. This process may vary for differ-

ent blockchain implementations.

Data Model: is a domain model of the process is

based on the UML class diagram. It allows speci-

fying entities, properties, and relationships between

them. The properties may contain primitive types

such as int, bool, and string, but arrays and enumer-

ations are supported as well. Address and Address-

Payable types are added to support the storage of a

blockchain actor’s addresses and consequent token or

cryptocurrency transfers. A blockchain token is rep-

resented as a special type of entity and supports deﬁn-

ing both fungible and non-fungible tokens with cus-

tom properties. A transformation of the models to the

smart contract source code is straightforward because

the blockchain programming languages support such

concepts in the form of classes, structures, enums, and

properties. The support of tokens is native on some

platforms. On other platforms such as Ethereum is

added as a third-party library.

Forms Model: speciﬁes an interface for the user

activity input. The forms model is generated into

two parts during the generation – off-chain model

and on-chain code that is similar to a web application

client-side and server-side code. The off-chain model

is interpreted by a blockchain wallet that allows the

user to interact with the smart contract. Most of the

blockchain implementations currently have no sup-

port for off-chain code inside a smart contract. The

on-chain code handles validations, user rights, and

property bindings.

6 CASE STUDY: EU ELECTION

Since 1979, occurred to date, nine Elections of the

European Parliament, once every ﬁve years according

to the universal adult suffrage. From 2020, 704 Mem-

bers of the European Parliament will be elected by

more than 400 million eligible voters from 27 mem-

ber states, for this reason it is considered the sec-

ond largest democratic elections in the world (Hare,

2015). Each member state has its own voting sys-

tem, either being by Preferential voting, Closed lists

or Single Transferable Vote, all can be combined

with Multiple Constituents. Further, each member

state has its own voting methods for citizens resi-

dent abroad and if whether or not voting is compul-

sory. Each member state has different rules determin-

ing who can vote for and run as a Member of the Eu-

ropean Parliament. Although this is not a very stan-

dardized process, the European Parliament is the only

institution in the European Union, directly elected by

the citizens. So, it is extremely important that this

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

1 0..*

0..*

<<Enumeration>>

PropertyDataType

Int

Uint

Bool

String

DateTime

Address

AddressPayable

Data

Byte

Reference

0..*

CandidateRoles

0..*

CandidateUsers

Asignee

1 0..*

<<Enumeration>>

FormFieldType

Property

ComboBox

Custom

0..*

StartForm

<<Enumeration>>

PropertyType

Single

Collection

Dictionary

0..*

Contract

+ Id: string

+ ProcessDiagram: string

Process

ProcessUser

+ Id: string

+ Name: string

+ Description: string

UserTask

ProcessRole

+ Id: string

+ Name: string

+ Description: string

UserForm

+ Id: string

FormField

+ Id: string

+ Order: int

+ Type: FormFieldType

+ DisplayName: string

+ IsReadOnly: boolean

+ PropertyExpression: string

+ CustomConﬁguration: string

StartEvent

0..*

ReferencedDataType

Token

+ Symbol: string

+ IsFungible: bool

+ IsIssued: bool

DataType

+ Id: string

+ Name: string

Enum

+ Values: string[]

Property

+ Id: string

+ Name: string

+ IsMandatory: boolean

+ PropertyDataType: PropertyDataType

+ Type: PropertyType

+ KeyType: PropertyDataType

Entity

Figure 3: A DasContract Data and Forms Metamodel.

is a transparent, meddle-proof, usable, authenticated,

accurate and veriﬁable process (Patil et al., 2013).

The development and implementation of constitu-

tional and legal provisions have been one of the en-

gineering concerns. Since for instance, the Elections

of the European Parliament have the estimated cost of

e 700 million. Blockchain has been the most promis-

ing technology when it comes to the electoral domain,

seeing that per each vote, a new transaction, if valid, is

added to the end of the blockchain and remains there

forever (Curran, 2018). For this solution, no central-

ized authority is needed to approve the votes, and ev-

eryone agrees on the ﬁnal tally as they can count the

votes themselves, as anyone can verify that no votes

were tampered with and no illegitimate votes were in-

serted.

This case study shows how to digitize the EU elec-

tion process by following a method proposed in Sec-

tion 5. A simpliﬁed version of the process was de-

signed and tested on the Ethereum blockchain.

6.1 Process Design

The EU election process is very complex. The EU

issues general guidelines on how country elections

should look like, and each country then implements

its legislation to describe how the elections are done

in a particular country. This means that each of the 27

EU countries does this process differently. To avoid

this complexity, it was assumed that there is a uniﬁed

Process Digitalization using Blockchain: EU Parliament Elections Case Study

European Parliament Elections

Start Country

Elections

[Political Party]

Party

[Candidate]

candidate

[Political

Party] Approve

and Order

Candidates

Country

Ellections

Initiate

Ellections

Country Elections

Assign

Privilegues to

the Elected

Candidates

Distribute SeatsCount Votes

Send ballots to

the elegible EU

Citizens

[EU Citizen]

Vote

Figure 4: A DasContract Process Model of the EU Elections.

voting process and each country votes according to

one of the three voting systems – preferential voting,

closed lists, and single transferable vote.

The modeled process is shown on Figure 4. It

starts with an initiation of the elections where all the

countries and their voting systems are initiated in the

contract. After the initiation, political parties are able

to register until a set deadline is expired. Later, candi-

dates are able to register, and in the next step, the po-

litical parties approve the candidates. In some coun-

tries, candidates without countries are allowed. Af-

ter a deadline for the approval is reached, the country

elections for each of the initiated countries are started

in parallel as a subprocess.

PoliticalParty

id: Address

name: string

code: string

website: string

voteCount: int

allocatedSeats: int

Candidate

id: Address

name: string

website: string

voteCount: int

hasSeat: bool

1..*

Elections

startDate: Date

partyRegistrationEnd: Date

candidateRegistrationEnd: Date

candidateApprovalEnd: Date

0..*

1..*

CountryElections

countryName: string

votingSystem: VotingSystem

electionDates: Date[1..2]

availableSeats: int

electoralTreshold: byte

minimumAge: byte

<<Enumeration>>

VotingSystem

OpenList

ClosedList

SingleTransferable

<<Token>>

VotingToken

isFungible: false

symbol: 'VOTE'

isIssuedByContract: true

voterId: address

Figure 5: A DasContract Data Model of the EU Elections.

The country elections subprocess starts by creat-

ing sending non-fungible tokens to eligible EU vot-

ers. The non-fungible tokens represent voting ballots

to assure that a double vote is prevented. In the next

step, the EU citizens are able to vote by sending their

tokens to the election smart contract during the elec-

tion days. After the voting is over, votes are counted,

and seats are distributed according to the country’s

voting system. In the end, privileges are assigned to

the selected candidates.

The process model also contains a validation and

script task that is currently entered in form of a solid-

ity programming language. In the future, a domain-

speciﬁc language is expected to be designed and used.

The data model is shown on Figure 4. It only con-

tains the essential information about the elections be-

cause the storage costs are high on public blockchain

because of a need for replication on all nodes and

keeping all the history. A new concept added in this

paper is a possibility to specify tokens and enumera-

tions in the data model. The voting token representing

a ballot is speciﬁed as a non-fungible token and to as-

sure it’s uniqueness, it is associated with an individual

voter identiﬁer. The voter identiﬁer represents a cit-

izen’s identity public key, however, the identiﬁcation

of the citizen is outside of the scope of this paper and

is a subject of further research.

The forms model rendering for the process step

Vote is shown on Figure 6. The DasContract currently

generates only an on-chain validation code because

the off-chain code is not supported on Ethereum plat-

form.

6.2 Execution

During the execution step, the designed model was

used to generate a Solidity smart contract accord-

ing to the MDE principles. The generation algo-

rithm is available on GitHub under an open-source

license (Skotnica, 2020).

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

Vote

Czech Pirate Party [CPP] pirati.cz

Party:

Country:

Czech Republic

Conﬁrm

Figure 6: A User Interface of the Closed List Vote in a

Blockchain Wallet.

An interesting example of the generated code

shows an implementation of the vote function that

accepts a non-fungible voting token and a voting

choices cast by the citizen:

function vote(address[] memory votingChoices)

public {

require(votingTokensContract

.isEligibleToVote(msg.sender),

"Voter not eligible to vote");

require(isVotingOpen(),

"Voting is currently not allowed");

require(votingChoices.length > 0,

"At least one cadidate must be chosen");

if(votingSystem == VotingSystem.ClosedList){

require(

politicalPartiesMap[votingChoices[0]]

.exists,

"Party address is invalid");

politicalPartiesMap[votingChoices[0]]

.voteCount++;

}

else if(votingSystem ==

VotingSystem.OpenList){

...

}

else if(votingSystem ==

VotingSystem.SingleTransferable){

...

}

votingTokensContract

.transferVoteToken(msg.sender);

}

//The generated code was adjusted to improve

//it’s readability.

The name of the function is taken from the task name

in a process model. The parameters of the vote func-

tions are from the forms model that is associated with

a user task. The address of a voting citizen and his

voting ballot are not the parameters to prevent people

from acting as someone else. The citizen’s id is taken

from the msg object that contains a veriﬁed public key

by the original sender. Inside the function, the ﬁrst

step is to validate the person’s eligibility to vote in the

current election (E.g. he can be a minor and have no

Figure 7: A Screenshot from Remix Simulation.

voting rights.). The second validation assures that the

correct process step is selected. Finally, the votes are

validated so the citizen does not lose his ballot with-

out voting for a valid candidate.

After the validations, a vote is counted according

to the country voting system and the citizen’s vote

is transferred back to the smart contract to prevent

a double vote. Note that the casting vote is counted

but not forgotten due to blockchains’ inherent his-

tory keeping. The blockchain also guarantees that

the function is processed one at a time so the vote-

Count++ is safe to be used even when it is called from

multiple sources in parallel.

In the end, the generated source code was simu-

lated in the Ethereum Remix simulation environment.

A screenshot from the simulation showing the vote

function is show in Figure 7.

6.3 State of the Art

Currently, the election process can be designed, sim-

ulated, and executed in blockchain technology. How-

ever, the public blockchain implementation Ethereum

capacity only allows to process up to ﬁfteen trans-

actions per seconds (Blockchair, 2020) for all of it’s

users and an average transaction price as of Septem-

ber 16th 2020 is 4.301 USD (YChart, 2020). The two

reasons alone would make it impossible to run the real

EU parliament elections on Ethereum blockchain. It

is expected that in the future the transaction prices

will go lower and the transactions per second will in-

crease due to implementation of the proof of stake

consensus algorithm and second layer scaling solu-

tions. These scaling limitations do not apply to private

blockchain solutions such as Hyperledger Fabric (The

Hyperledger White Paper Working Group, 2018) and

therefore it would be possible to execute the EU elec-

tion process there. However, the private blockchains

may not guarantee the same security properties as the

public blockchains because the network is run by a

handful of selected operators.

Process Digitalization using Blockchain: EU Parliament Elections Case Study

6.4 Summary

Following the proposed method allowed us to model

the EU elections case in a visual editor using a stan-

dardized BPMN language. The DasContract subset

of the BPMN language only allowed for concepts that

are valid in Blockchain. Furthermore, the data model

was expressed, and a custom non-fungible token was

designed. It was possible to test the process model’s

behavior during the design using standardized BPMN

simulation tools.

During the Execution phase, a Solidity smart con-

tract was generated using an open-source algorithm.

The generated code contains 365 lines, and it was ex-

ecuted in the Remix environment. Due to Ethereum

transaction fees, it would not make economic sense to

run it on millions of users.

Overall, the proposed approach seems to make the

digitalization of processes in the blockchain environ-

ment easier as it is based on a standardized process

modeling notation. The generation of smart contract

code reduces programming errors. However, only

Ethereum smart contracts can be generated, but the

DasContract model seems to be transferable to other

blockchain implementations.

7 CONCLUSIONS AND FURTHER

RESEARCH

This paper introduced a method to digitize processes

using blockchain smart contracts based on the MDE

approach. The method followed the BPM steps and

was demonstrated in the EU parliament elections case

study. It was shown that using the DasContract vi-

sual domain-speciﬁc language it is possible to design,

model, execute and monitor the process. By following

the method, a possibility to introduce a programming

error in code was reduced because the code was gen-

erated. Finally, the generated code was simulated on

the Ethereum blockchain.

The limitation of this approach was also men-

tioned, mainly that there is currently no public

blockchain capable of supporting millions of trans-

actions in a cost and time-efﬁcient way. Accord-

ing to the Gartner (Gartner, 2019), production-ready

blockchain technology will be available by 2030. By

then, the transaction fees should be lower, so signiﬁ-

cant cost savings can be realized.

7.1 Further Research

• Extend the example and DasContract language

with a Decentralized Identity (DiD) (W3C, 2020)

and Blockchain oracles such as ChainLink (Steve

Ellis, et a., 2017).

• Compare possibilities of executing the processes

in public vs private blockchains.

• Case studies and usability studies to improve the

proposed method.

• Compare different blockchain implementations

such as Cardano (IOHK, 2017), Tron (Tron Foun-

dation, 2018), EOS (Daniel Larimer, et al., 2017),

and Hyperledger Fabric (The Hyperledger White

Paper Working Group, 2018) and their ability to

execute DasContract models.

• Transformation of the models can be formalized

using the transformation speciﬁcation languages

like QVT (OMG, 2016) and ATL (OMG, 2002).

ACKNOWLEDGEMENTS

This research has been supported by CTU SGS grant

No. SGS20/209/OHK3/3T/18.

REFERENCES

Al-Rawy, M. and Elc¸i, A. (2018). A design for blockchain-

based digital voting system.

Apar

ıcio., M., Guerreiro., S., and Sousa., P. (2020). To-

wards an automated demo action model implementa-

tion using blockchain smart contracts. In Proceedings

of the 22nd International Conference on Enterprise

Information Systems - Volume 2: ICEIS,, pages 762–

769. INSTICC, SciTePress.

Azzopardi, S., Colombo, C., and Pace, G. J. (2020). A

technique for automata-based veriﬁcation with resid-

ual reasoning. In MODELSWARD, pages 237–248.

Bellini, E., Ceravolo, P., Bellini, A., and Damiani, E.

(2018). Designing process-centric blockchain-based

architectures: A case study in e-voting as a service. In

Data-Driven Process Discovery and Analysis, pages

1–23. Springer.

Blockchair (2020). Ethereum transactions per second.

Curran, K. (2018). E-voting on the blockchain. The Journal

of the British Blockchain Association, 1(2):4451.

Dagher, G. G., Marella, P. B., Milojkovic, M., and Mohler,

J. (2018). Broncovote: Secure voting system using

ethereum’s blockchain.

Daniel Larimer, et al. (2017). EOS.IO Technical White Pa-

per v2.

Ethereum (2020). Ethereum Improvement Proposals

(EIPs).

Ethereum Foundation (2020). The Solidity Contract-

Oriented Programming Language.

Garc

ıa-Ba

nuelos, L., Ponomarev, A., Dumas, M., and We-

ber, I. (2017). Optimized execution of business pro-

cesses on blockchain.

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

Garther (2019). The Reality of Blockchain.

Gartner (2018). Gartner survey reveals the

scarcity of current blockchain deployments.

https://www.gartner.com/en/newsroom/press-

releases/2018-05-03-gartner-survey-reveals-the-

scarcity-of-current-blockchain. Accessed: 2020-08-

10.

Gartner (2019). The reality of blockchain.

Hare, P. W. (2015). Making diplomacy work: intelligent

innovation for the modern world. CQ Press.

Hevner, A. (2007). A Three Cycle View of Design Science

Research. Scandinavian Journal of Information Sys-

tems, 19(2).

Hevner, A. R., March, S. T., Park, J., and Ram, S. (2004).

Design Science in Information Systems Research.

MIS Q., 28(1):75–105.

Horcas, J., Pinto, M., and Fuentes, L. (2014). An aspect-

oriented model transformation to weave security us-

ing cvl. In 2014 2nd International Conference on

Model-Driven Engineering and Software Develop-

ment (MODELSWARD), pages 138–150.

Hull, R., Batra, V. S., Chen, Y.-M., Deutsch, A., Heath III,

F. F. T., and Vianu, V. (2016). Towards a shared ledger

business collaboration language based on data-aware

processes. In International Conference on Service-

Oriented Computing, pages 18–36. Springer.

IOHK (2017). Cardano Blockchain.

Khoury, D., Kfoury, E., Kassem, A., and Harb, H. (2018).

Decentralized Voting Platform Based on Ethereum

Blockchain.

opez-Pintado, O., Garc

ıa-Ba

nuelos, L., Dumas, M.,

Weber, I., and Ponomarev, A. (2018). CATER-

PILLAR: A Business Process Execution Engine on

the Ethereum Blockchain. CoRR, abs/1808.03517.

eprint: 1808.03517.

Mavridou, A. and Laszka, A. (2018). Designing secure

ethereum smart contracts: A ﬁnite state machine

based approach. In International Conference on Fi-

nancial Cryptography and Data Security, pages 523–

540. Springer.

Nakamoto, S. (2009). Bitcoin: A peer-to-peer elec-

tronic cash system. Cryptography Mailing list at

https://metzdowd.com.

OMG (2002). ATLAS - Authorization Token Layer Acqui-

sition Service, version 1.0.

OMG (2011). Business Process Model and Notation

(BPMN), Version 2.0.

OMG (2015). Uniﬁed Modeling Language, version 2.5.

OMG (2016). QVT - MOF Query/View/Transformation,

version 1.3.

Patil, M., Pimplodkar, V., Zade, A. R., Vibhute, V., and

Ghadge, R. (2013). A survey on voting system

techniques. International Journal of Advanced Re-

search in Computer Science and Software Engineer-

ing, 3(1):114–117.

Pintado, O. (2017). Caterpillar: A Blockchain-Based Busi-

ness Process Management System.

Skotnica, M., e. a. (2020). Dascontract 2.0 github reposi-

tory.

Skotnica, M. and Pergl, R. (2020). Das Contract - A Visual

Domain Speciﬁc Language for Modeling Blockchain

Smart Contracts. In Aveiro, D., Guizzardi, G., and

Borbinha, J., editors, Advances in Enterprise Engi-

neering XIII, pages 149–166, Cham. Springer Inter-

national Publishing.

Steve Ellis, et a. (2017). ChainLink - A Decentralized Ora-

cle Network.

The Hyperledger White Paper Working Group (2018). An

Introduction to Hyperledger.

Tran, A. B., Lu, Q., and Weber, I. (2018). Lorikeet: A

model-driven engineering tool for blockchain-based

business process execution and asset management. In

BPM.

Tron Foundation (2018). Tron - Advanced Decentralized

Blockchain Platform.

Vitalik Buterin (2013). Ethereum Whitepaper.

Voshmgir, S. (2019). Token economy how blockchains

and smart contracts revolutionize the economy.

Blockchain HUB, Berlin.

W3C (2020). Decentralized Identiﬁers (DIDs) v1.0.

Weber, I., Xu, X., Riveret, R., Governatori, G., Ponomarev,

A., and Mendling, J. (2016). Untrusted business pro-

cess monitoring and execution using blockchain. In

La Rosa, M., Loos, P., and Pastor, O., editors, Busi-

ness Process Management, pages 329–347, Cham.

Springer International Publishing.

YChart (2020). Ethereum average transaction fee.

Zhang, Q., Xu, B., Jing, H., and Zheng, Z. (2019). Ques-

chain: an ethereum based e-voting system. arXiv

preprint arXiv:1905.05041.

Process Digitalization using Blockchain: EU Parliament Elections Case Study