DECADENT:
DECentralized Application
DEvelopmeNt Toolkit
Layout: typeset by the author using LATEX.
DECADENT:
DECentralized Application
DEvelopmeNt Toolkit
An Interactive User Environment for Developing and
Deploying DApp Smart Contracts
Jonathan M. van Westendorp 11325747
Bachelor thesis Credits: 18 EC
Bachelor Kunstmatige Intelligentie
University of Amsterdam Faculty of Science
Science Park 904 1098 XH Amsterdam
Supervisor
Z. Shi MSc & Dr. Z. Zhao Informatics Institute Faculty of Science University of Amsterdam Science Park 904 1098 XH Amsterdam June 26th, 2020
Abstract
The emergence of blockchain technology recently facilitated the construction of innovative solutions for problems in fields such as supply chains, healthcare and social networking. Due to their decentralized and independent nature, decentral-ized applications have in many cases proven to enhance security and performance while reducing cost. It is expected that decentralized applications will grow in importance for industrial and private enterprises. Decentralized application de-velopment can be very challenging for those without a thorough understanding of the needed concepts. Even for the more experienced smart contract developer, the complexity of decentralized applications can significantly delay the develop-ment process. The DECentralized Application DEvelopmeNt Toolkit provides an urgently needed DApp development and testing framework. DECADENT bridges the gap between standard business process models and smart contract-based de-centralized applications by allowing developers to design, deploy and simulate the behavior of decentralized applications on actual permissioned or permissionless blockchain systems. The prototype described in this thesis contains all the re-quired functionality. In the future, the analysis framework can be improved to provide a more accessible and extensive way of decentralized application develop-ment, exploration and refinement.
Contents
1 Introduction 3
2 Related Work 5
2.1 State of the Art . . . 5
2.1.1 Blockchain Technologies . . . 5 2.1.2 Smart Contracts . . . 6 2.2 Development Tools . . . 7 2.2.1 Modeling . . . 8 2.2.2 Testing . . . 9 2.2.3 Monitoring . . . 10 2.2.4 Simulation . . . 10 2.3 Gaps . . . 11 3 DECADENT 14 3.1 Requirements . . . 14 3.2 Architecture Design . . . 16 3.3 Implementation Details . . . 17 3.3.1 Function Testing . . . 18 3.3.2 Simulation . . . 21 3.3.3 Visualization . . . 26 4 Crowd Journalism 28 4.1 DECADENT Usability . . . 29 4.1.1 DApp Modeling . . . 29 4.1.2 DApp Analytics . . . 30 4.2 Results . . . 31 5 Discussion 33 5.1 Contributions . . . 33 5.2 Weaknesses . . . 34 5.3 Future Studies . . . 35
6 Conclusions 36
References 38
Chapter 1
Introduction
With the growing scale of industrial applications, e.g., global distribution and social networks, trustworthiness has become an important non-functional design requirement. Decentralized applications (DApps) [1], especially those based on blockchain, provide promising solutions to this problem. Due to their use of con-sensus algorithms and decentralization, little to no gaps are left for single points of failure or transparency flaws. Examples of applied blockchain frameworks can be found in various fields such as supply chains [2], healthcare and pharmaceutics [3] and social networking [4].
Blockchain can store interaction information among distributed members of the network as transactions [5]. The transactions are stored in so-called blocks which are on their turn chained to form a ledger. An important feature of blockchain is decentralization. Each contributor in the network has an identical copy of the entire blockchain on their local system, making it impossible to corrupt the chain by entering faulty information. Furthermore, all blocks hold hashes formed using data from the block itself and its predecessor. Altering a single block would thus be impossible without making modifications to the whole chain, requiring the consensus of the majority of participants in the decentralized system.
Consensus is achieved using algorithms such as Proof of Work (PoW) [6], which requires highly specialized computing technology and consumes an exten-sive amount of energy. This is undesirable as adopting a blockchain solution in an industrial environment would merely increase equipment expenses. Permissioned blockchain provides a solution to this problem. In a permissioned blockchain net-work every participant is known and authenticated. Assuming the obvious trust-worthiness within an enterprise, computationally expensive consensus algorithms become obsolete. Algorithms such as Proof of Elapsed Time (PoET) can instead be used, dramatically reducing the cost of applying and maintaining a blockchain network [7].
It is seldom straightforward to develop a DApp, increasing safety and auton-omy, for industrial applications. Although predictions can be made for DApp performance in certain situations, anomalies can always occur. There is no way to predict the performance of a decentralized application in every special case. As DApps grow in complexity, it becomes unimaginable how may things can result in faulty performance. Consequently, the urgency of automating the testing process becomes evident. Studies have already explored the applicability of blockchain solutions in different industrial environments [8]. The possibility of automating permissioned blockchain performance profiling has also been examined [9]. There is, however, no information yet on how DApp performance could be profiled and tested automatically in existing industrial environments. As previous studies only tested the blockchains basic functionality, a method for analyzing how real DApps perform within different environments and with different configurations is still ab-sent.
This thesis aims to investigate the possibility of automating the testing and simulation process of decentralized applications. The key research question of this thesis will be: How to accelerate and simplify DApp development? To tackle this question, it is broken down into three sub-questions.
1. How to bridge the gap between business logic and decentralized applications?
2. How to enable developers to customize testing of a deployed decentralized application, preferably in an automated way?
3. How to visualize the testing results comprehensibly?
Business processes taken from real-world examples are implemented and tested in blockchain environments. A tool is developed that aims to facilitate DApp development and testing. The next chapter will go into related work and review where the field of study is lacking. The chapter is concluded by giving the proposed solution for the research questions.
Chapter 2
Related Work
As blockchain is a relatively new field of study, the absence of similar research is ex-pected. However, over the past years, blockchain technology has established itself as an inevitable improvement on information systems. This provides a reasonable cause for extensive research.
2.1
State of the Art
2.1.1
Blockchain Technologies
Most commonly known blockchain technologies such as Bitcoin or Ethereum merely serve the purpose of digital currency for a majority of people. Although that is ex-actly what Bitcoin’s purpose is [10], Ethereum and blockchain frameworks based on Ethereum were built not to be restricted to one purpose only. The aim of Ethereum is to serve as a base for decentralized applications [11]. Ethereum sup-ports the deployment of smart contracts, which are in essence predefined processes that are translated to computer code, enabling automation of processes that cur-rently require human interaction. DApps make use of smart contracts to guarantee safety and autonomy in their process logic [12].
Still, Ethereum is not a complete solution for every application. In practice, most applications require quick transactions and trust between contributors in the network. As Bitcoin and Ethereum-based blockchain protocols choose complete decentralization over privacy and performance, private information can fall into the wrong hands [13]. Furthermore, as mentioned earlier, consensus algorithms used in permissionless blockchain protocols are computationally expensive, signif-icantly slowing down the creation of blocks. Permissioned blockchains like Fabric and Sawtooth from the Hyperledger community provide solutions to these prob-lems. The closed blockchain network assumes trust between parties, enabling the
use of less heavy consensus algorithms. Also, privacy issues concerning sensitive information are assumed nonexistent as information stored on the permissioned blockchain is not accessible to outsiders [14].
2.1.2
Smart Contracts
Transferring a business infrastructure to (permissioned) blockchain starts with de-signing the needed smart contracts. Business logic is translated to a smart contract language that is supported by the blockchain, Solidity being the most popular. A smart contract can be designed to be as complicated as needed. However, good care should be taken to avoid mistakes. Once a contract is deployed, the per-manent nature of blockchain ensures that the code cannot be changed, therefore, faults cannot be solved anymore.
A simple example of a DApp can be a blind auction [15], where participants in the network can bid an amount of money on an item of interest, just like in a normal auction. However, in this example, participants do not have a way of knowing the bids of the other participants. Solidity’s built-in cryptography is used to encode the respective bids. The bidding amount has to be sent with the bid to ensure that the participants abide by their bid. A time period is specified during which the participants can make bids. When the period comes to an end, the participants have to send their bid again, but now the values are not encrypted. The contract then checks whether both hashes match. If they do, the bid is considered valid. The benefits of a similar auction operated on blockchain over a traditional auction are that there is no stress on the process towards the end of the auction, as all values are hashed and therefore bids are invisible to other participants. Other advantages are the speed by which transactions are made, the security of transactions and the absence of human error.
More complicated and realistic examples are the smart social media usecases from the ARTICONF project [4]. One of these usecases describes a local energy social network that enables energy trading between peers. The transition from fossil fuels to renewable energy sources like solar energy has sped up in the last decades as the urgency to reduce climate change has grown. More and more people are investing in solar panels to reduce household energy costs and contribute to the transition to green energy. However, local energy grids often lack sufficient infrastructure to handle the surplus emerging as a result of more privately gener-ated energy. Consequently, people are often stuck with their energy with no way of benefiting. The ARTICONF usecase proposes a social media platform based on permissioned blockchain where one can register oneself on the network with one’s phone number as a personal identifier. The advantage of registering on the network is that tokens can be earned for specific actions. For example, a user is rewarded with tokens when the energy usage and generation data is shared. Furthermore,
Figure 2.1: Smart Energy
tokens can be earned by trading energy with other households and utilities, re-lieving the energy grid while simultaneously contributing to a more sustainable community. Users can then compensate their energy bills with the earned tokens. Figure 2.1 should clarify the decentralized application workflow.
The aforementioned process is entirely automated with the use of smart con-tracts. Every part of the mechanism is developed as its own smart contract. Sensitive user data can reliably be controlled because of properties like security and tamper-freedom that are inherent to blockchain.
DApps such as the one described above require long periods of development and testing. In fact, testing the performance of the smart contract infrastructure can take considerable time itself, as the entire structure needs to be deployed repeatedly for each test. Furthermore, the heavily encoded core of blockchain ensures safety but can also make application performance hard to decipher. A means of deploying a decentralized application in a controlled testing environment and a way to issue automated tests could reduce the time needed to test the DApp significantly. In the following section, a collection of tools that are already available are reviewed. It is described in detail how these tools prove helpful for this research and where they could be improved for more usefulness in DApp testing and simulation.
2.2
Development Tools
Multiple tools have already been developed that enable developers to test and un-derstand DApp behavior in blockchain environments. Furthermore, tools that can model processes that are translatable to smart contracts also exist. These tools range from interfaces for Business Process Modeling Notation (BPMN) to tools
that support translation from BPMN into a smart contract language, Caterpillar1
being the most robust implementation of this concept. Tools that enable moni-toring of the blockchain itself are also available. The most popular example being Hyperledger Explorer2, which is a monitoring tool exclusively made for
permis-sioned blockchains from the Hyperledger community. However, undoubtedly the most powerful tool currently in existence is Truffle3. Truffle provides some very
useful features, including, but not limited to, smart contract life cycle manage-ment and automated contract testing. The relevant details of these tools will be described in the following sections. Similar tools will also be reviewed.
2.2.1
Modeling
An important part of developing DApps is ensuring the correct business logic. A popular way of visualizing a business process is BPMN, a language based on XML that can be visualized easily. All tasks that are executed in a process can be modeled using BPMN. Functionality in the form of scripts can be bound to a task so that the script is executed when the process arrives at a certain task. BPMN also enables user input, looping over tasks and decision making, which are all indispensable in most smart contract workflows. Multiple tools exist for process modeling with BPMN. The most used tool is Camunda4. Camunda has
a demo in the form of a web application that allows a user to define the basic structure of a process model. However, adding scripts to the model can best be done using the downloadable application. During modeling, the XML code behind the model can be viewed, and changes can be made according to specific development requirements. After finishing a basic process model, the model can be tested using a browser application provided by Camunda. The process can be executed from start to finish, keeping track of changing global variables that are part of the process.
BPMN provides a way for people who do not have any knowledge about smart contracts to explore process structures, which is useful to gain a conceptual un-derstanding of the process. However, as relatively few people are proficient in writing Solidity, and an even smaller number of people have the knowledge to cor-rectly translate a process model written in BPMN to a working smart contract, a bridge between the two languages is necessary. Caterpillar provides this bridge [16]. Caterpillar contains three essential parts, the first being an execution panel where a process model can be developed. Caterpillar supports the necessary parts of BPMN to define an executable BPMN entity. Upon saving the process model, it
1Original repository: https://github.com/orlenyslp/Caterpillar 2More info: https://www.hyperledger.org/use/explorer
3Main web page: https://www.trufflesuite.com 4Main web page: https://camunda.com
is translated to Solidity using a translation system defined in Caterpillar and com-piled using a Solidity compiler. The workflow of a process model is preserved using function numbering in Solidity. Each task is translated to a function in Solidity. The scripts that are bound to a task have to be written in Solidity beforehand for the translation to execute correctly. Tasks that require the deployment of a smart contract on its own have to be defined as service tasks in BPMN. The contracts that are connected to a service task should be deployed before the main contract is deployed. The reason for this is that the addresses of the dependencies should be specified in the service tasks before deployment. The service tasks themselves are handled by the second part of Caterpillar: the services manager. The services manager deploys all needed service contracts on startup of Caterpillar. It outputs the addresses of the deployed contracts in the terminal so that transferring them to the main process model becomes an easy task. When saving and compiling the model is completed, the model appears in the execution panel. From here, an instance can be created. Analogous to Camunda, Caterpillar implements function-ality for executing the process model. This is done by the final and most important part of Caterpillar, the core, which enables users to execute the newly generated and deployed smart contract on an Ethereum testing network. This simulation is discussed more thoroughly in the final paragraph of this subsection.
2.2.2
Testing
As Ethereum was the first blockchain framework to support the implementation of smart contracts, most tools for testing smart contracts are based on Ethereum. The most common and low-level tool for developing smart contracts is the Remix IDE5. Remix provides smart contracts with a Solidity editor and compilers that
translate smart contracts from Solidity to bytecode, deployable in blockchains that support smart contracts written in Solidity. Remix also supports the deployment of the developed contracts in an Ethereum framework. After deployment, contract functionality can be tested. The functions that are defined in a smart contract can be run to see if they are defined correctly. Remix also decodes the output so that it can be analyzed without the problem of it being too cryptic to read.
A tool that helps to understand the dependencies between contracts is PIET6.
PIET is a Solidity smart contract viewer that supports development, auditing and use of smart contracts written in Solidity. In addition to what the Remix IDE already contains, PIET provides the user with an interface of how dependencies are structured in smart contracts. Dependencies are visualized as arrows between contracts and functions, which is very useful when developing multiple contracts
5https://remix.ethereum.org 6https://piet.slock.it
that all have dependencies on each other, forming a complicated DApp structure. Although the aforementioned tools are very helpful for gaining basic insights, Truffle is of superior use for the DApp development process on Ethereum. The Truffle suite contains tools that enable developers to create, deploy and test the smart contracts that form a DApp. Automated testing scripts can be written using JavaScript or Solidity. Truffle will execute them automatically and provides the option to show stack-traces when an error occurs. Furthermore, Truffle contains a powerful command-line interface to interact with a deployed DApp that lets the developer debug Solidity code to see where faulty behavior comes from.
2.2.3
Monitoring
Hyperledger Explorer is a useful tool for monitoring activity within a blockchain framework. Explorer provides a web application with a dashboard on which all relevant metrics are shown. The most useful functionality of the tool is the query-ing of data stored in blocks and transactions. Furthermore, the number of peers in the network can be viewed and active transaction families can be queried.
A more generic tool for monitoring blockchain activity is Grafana7. Similarly
to Hyperledger Explorer, Grafana can also be used to display relevant blockchain information. A connection has to be made between a blockchain framework and Grafana that enables transferring data between instances. Grafana then provides tools to display this data in graphs on a dashboard. This is very useful for a clear overview of e.g. transaction throughput, i.e. the number of transactions per unit of time, and node activity.
Another established framework for monitoring that can also be used for analysis is Kibana. Kibana is part of the Elasticsearch, Logbase, Kibana (ELK) stack8
which is a combination of three tools that enable the analysis and monitoring of any kind of time-series data. Kibana provides dashboards in a similar fashion as the two tools described previously. The dashboards can be customized based on any required view and panels can be designed to display metrics with a wide range of available visualization methods.
2.2.4
Simulation
Automated simulation of smart contracts is not in the least an easy task. Remix IDE provides a way to execute functions defined in smart contracts by hand and see their output. Truffle has an automated testing feature that can automatically find faults and provide feedback to the user. Caterpillar improves this concept
7Main web page: https://grafana.com
by letting the user follow the designed process model in a user-friendly way. The functionality behind this is structured as follows. When an instance of the process model is created, it is deployed on the blockchain network. The viewer that is present in the execution panel can then show the state of the instance, annotating the current task that is executed by Caterpillar in real-time. Tasks that need user input are colored dark green. The process execution waits for the user to input the required values and then moves on through the process. When the process is finished, the execution is concluded and the instance is removed from the list of instances. After finishing, an instance cannot be queried again.
2.3
Gaps
The aforementioned tools all provide useful functionality for gaining a better un-derstanding of DApps in the development stage. However, for business owners and system operators exploring the possibilities of developing a DApp for their enterprise, this collection of tools falls short, the most important gaps being:
• An essential part of DApp development is modeling the desired structure. BPMN can prove very useful for this and, although Camunda does not allow translation from BPMN to any smart contract language, it has provided a good starting point for Caterpillar. Caterpillar closely resembles a tool for automated simulation and analysis. However, Caterpillar itself contains gaps in functionality that should be closed as well to be useful and provide a decent bridge between business process models and DApps.
– Caterpillar deploys translated process models on Ethereum. Even though Ethereum is useful for testing purposes and applications where execu-tion speed and user data protecexecu-tion are not important, permissioned blockchain and future permissioned blockchain derivatives will be the infrastructure of choice for most DApps. Thus, support for these types of blockchain is necessary.
– Repeated instance creation can only be done manually, which should be avoided as it drastically slows the profiling process.
– User input is needed for the execution of user tasks. This is undesirable as it obstructs automated simulation. Ultimately, the output from the contract execution is only briefly shown in the terminal. To be of use for business owners and system operators, this output data should be stored in such a way that it can be used for focused analysis.
• The tools for testing smart contracts can be useful for the initial stage of de-velopment. Furthermore, the testing tools can be used for exploring the faults
of an already deployed contract. Consequently, Remix, PIET and especially Truffle can prove very useful for exploring Solidity behavior and exposing unexpected dependencies. A tool for automated testing and analysis should contain this functionality. However, on their own, they are insufficient for profiling a DApp.
– Systematic simulation is impossible. Testing a complicated smart con-tract structure function by function would take too long and doesn’t provide any insights into the underlying smart contract dynamics. – developing decentralized blockchain applications is not a
straightfor-ward process. It can be hard to understand correctly what is happening under the hood. A graphical user interface (GUI) is present in Remix and PIET, but Truffle only allows interaction through the command-line interface, excluding the developers and business owners that do not have much experience with Solidity, blockchain or general computer technology.
– Remix, PIET and Truffle are only useful for development on Ethereum, obstructing DApp development for permissioned blockchain.
• Hyperledger Explorer is sufficient for monitoring Hyperledger Sawtooth, Fab-ric and Iroha only. It cannot be used for monitoring other blockchains like Ethereum, which is still preferred for some DApps. Furthermore, none of the monitoring tools can be used to interact with blockchain, which is an essen-tial part of development. System operators require control over parameters in the system, so that system performance can be profiled constructively.
• It is undesirable to rely on these many tools for designing, testing and sim-ulating DApps. Using all tools separately would require a developer to have multiple instances of the same blockchain with the same deployed DApp running. As DApp deployment if often time-consuming, this is not a good solution.
Solving all problems stated above and combining the essence of all aforementioned tools would yield a multifunctional automated decentralized application testing tool. First of all, the tool should be able to deploy smart contracts written in Solidity, onto any blockchain that supports Solidity. It should then be able to call functions and show output. This is necessary to make sure specific functions can be tested. Secondly, the tool should provide a GUI for designing DApp workflows that can thereafter be deployed on a blockchain network directly. Caterpillar can be used for this as the most basic functionality is already in place. Thirdly, a means of automatically simulating the deployed contract workflow should be implemented.
Parameters that require user input should allow varying to uncover smart contract behavior in certain situations. Using this part of the tool, one should be able to generate enough data for the performance analysis. Finally, the tool should provide a way to process and visualize the generated data, so that conclusions can be drawn about the behavior of the DApp. These conclusions could lead to optimization of the smart contract structure or provide useful feedback for when the DApp is deployed in live situations. The next chapter will discuss the proposed solution and implementation in more detail.
Chapter 3
DECADENT
During this research project, a solution is constructed in the form of a DECentral-ized Application DEvelopmeNt Toolkit, or DECADENT. For DECADENT to be of significant usefulness to DApp developers, the required components should be selected carefully. DECADENT should be able to provide insight into basic smart contract functionality. Furthermore, the possibility to study DApp performance in a simulated environment will help gain a better understanding of how the DApp would perform in real situations. Moreover, generating random user input based on certain probabilistic distributions will enable the developers to predict smart contract behavior in situations that are not expected before deployment. A GUI will bind these components in an approachable tool while also providing a base for visualization of testing results.
3.1
Requirements
The functionality requirements for DECADENT are defined as follows.
1. DECADENT should contain the ability to compile smart contracts and de-ploy them on a blockchain framework. Once dede-ployed, all externally available functions should be listed so that they can be used to invoke the deployed smart contract. If successful, output is shown in an integrated terminal. This part is not the most essential, but DECADENT should contain this func-tionality to provide usefulness for users that are not seeking more extensive analysis.
2. DECADENT should allow users to model their business processes in a straight-forward and comprehensible way. Caterpillar implements the basis for this functionality that will be of most use for DApp development. DApp develop-ers will benefit from simplified ways of building the DApp structure. BPMN
is simply more readable than plain Solidity. Furthermore, the ability to de-ploy a process model directly on blockchain with the click of a button will make handling cryptic blockchain commands obsolete. As Caterpillar is an open-source application, it can be easily adopted and improved in DECA-DENT.
3. The biggest requirement for DECADENT is a means of automated busi-ness process model simulation. Once a DApp in development is deployed on blockchain, a way is needed to simulate its behavior. The most beneficial and quick way to make repeated simulation possible is to create instances sequentially in a loop. The users should on their part be able to specify the number of simulations needed. During the simulation, all required in-put parameters should automatically be inserted in the workflow so that the process can continue. Varying the input parameter should be made possible so that real usecase contract input can be imitated. In conclusion, repeated workflow execution should be added to DECADENT to work on top of Cater-pillar. Furthermore, forms should be added to define all input parameters that would be used for simulation. For the parameters that should be varied, an option should be implemented to let the user vary parameter input based on probabilistic distributions.
4. Finally, DECADENT should show all relevant simulation output in a sim-plified manner, so that the user can visualize the important aspects in a comprehensible way. Monitoring tools such as Grafana or the ELK stack can be used for visualization. Alternatively, as time is limited, simple plot-ting tools could be provided to make basic visualization possible. The output should then be processed enough to be readable by itself.
For each of the functionality requirements stated above, a programmatic way of implementation is needed. As DECADENT will be entirely web-based and inter-active, JavaScript will be the obvious choice. Front-end JavaScript in combination with HTML for template management and CSS for styling will be used to build the entire front end of DECADENT.
For the back-end, Node.js is most suitable as it provides all back-end function-ality needed. Furthermore, designing an application programming interface (API) for DECADENT with Node.js is the most straightforward as most available API interfaces are based on Node.js, the most popular being Express.
The data storage is handled by MongoDB. This choice is based on the fact that it can be easily connected to Node.js and handles data in JSON format in the most intuitive way.
Designing an intuitive web-application can prove challenging without the right skills. Frameworks like Vue.js, Angular.js and React.js can be extremely helpful
as they make building interactivity into an application much easier. Moreover, the component-based workflow often results in a clear application structure, making styling easier as well.
Even though the Caterpillar front-end is built with the Angular.js framework, Vue.js is the best choice for this application. The reasons being that Vue.js is the most flexible, lightweight and best performing of all frameworks. Also, it is the newest of all frameworks and judging by the popularity it has gained in a short amount of time, it will grow to be the most used framework in the future.
The blockchain implementation is not considered to be a part of DECADENT. Consequently, it will not be part of the functionality requirements. However, to test DECADENT’s usability, a blockchain framework should be present. As the blockchain needs to support Solidity, there is a finite selection of blockchain frameworks that can be used. Fortunately, the blockchain frameworks that do support Solidity smart contracts are the frameworks that have the most potential to be used for actual DApps. The focus will lie on permissioned blockchains such as Hyperledger Sawtooth and Fabric. Although they are still in development, the functionality they already contain is sufficient for testing purposes. Meanwhile, Caterpillar already has a working connection with Ethereum. For the simulation tool, there is no need to modify Caterpillar to work with Hyperledger Sawtooth or Fabric, as this compatibility can easily be added in the future.
The architecture of DECADENT should be designed with equal care because poor architecture can result in bottlenecks and unwanted dependencies. The ar-chitectural choices will be presented in the next chapter.
3.2
Architecture Design
The architecture can best be shown graphically. However, globally, the architecture is structured as follows. DECADENT contains three functional parts.
1. The first part is the simple smart contract functionality analysis part, which can deploy a smart contract and test its functions.
2. The second part is built on Caterpillar. Caterpillar is expanded with a component that can simulate a DApp with varied input values.
3. The third part handles the data that is being generated by simulation and deployment, which is split into two separate parts, one for the first analysis part and one for the second.
From an application perspective, however, more is needed for the tool to be useful and efficient.
• A front-end will be built to allow users to interact with all parts mentioned above. Deployed contracts are visualized interactively. All output is clearly shown so that there is no room for ambiguity
• The back-end of DECADENT will contain all functional parts. Users can communicate with the simple smart contract functionality analysis part through an API. Caterpillar already contains an API. The simulation operator makes uses of this API while simulating DApps. All of these components interact with an RPC within a certain blockchain framework.
• All output from the blockchain framework is stored in a database for later use. The visualization part requests specific data from the database to be shown.
• The visualization part, containing both the simple visualization and the ex-tensive visualization, is used to display all data in an accessible way on the front-end.
Figure 3.1 contains a flow chart that should clarify the structure of DECADENT.
Figure 3.1: DECADENT Architecture
3.3
Implementation Details
As each component originates from a different discipline in software development, the respective implementations proved challenging in different ways. In this
sec-tion, the details considering each component will be laid out. Although challenges in the development process are not desirable for steady progress, they did form the current prototype and helped make it more robust.
3.3.1
Function Testing
For the most basic functionality of the prototype, a way to deploy smart contracts and invoke them had to be implemented. As the group using DECADENT will consist mostly of parties testing permissioned blockchain applications, a suitable permissioned blockchain platform for testing had to be found. Still, to accom-modate parties interested in testing on a permissionless blockchain system, the ability to connect to both was preferable. Fortunately, because the permissioned blockchain systems that are considered best for this use, namely those developed by the Hyperledger community, support Solidity smart contracts by integrating the Ethereum framework, the way of connecting with the systems is very similar to an actual Ethereum implementation. Ethereum contains a lightweight remote procedure call protocol (RPC). It uses JSON format to receive and respond to administrative calls. With this method, smart contracts can be deployed and in-voked. Hyperledger Sawtooth and Fabric support this method as well, hence the preference towards them. Figure 3.2 demonstrates the framework for Sawtooth, which uses a specialized component for the implementation of Ethereum, named SETH.
Figure 3.2: Sawtooth Seth [17]
It is shown in the figure that web3.js, a node.js package, is the direct way of communicating with the RPC. The RPC can on its turn send requests to the trans-action validator and control the configuration of the network. Web3.js can be used as a bridge between human-readable JavaScript or JSON code and bytecode. It
is also used in the prototype as translating to bytecode manually is not desirable. For the blockchain implementation, the starting point was Sawtooth combined with SETH. A three-node network was set up with SETH in a virtual machine provided by Google Cloud. Docker images were used to accommodate all needed components, as this was advised by the Sawtooth documentation. This way, de-centralization could be simulated without needing multiple virtual machines. After minimal exploratory testing of the installation procedure, every part of the sys-tem appeared to be functioning properly. Simple numerical transactions could be sent over the network and registered in blocks. However, the activation of the SETH-RPC proved considerably more difficult. The framework of the SETH-RPC is built with Rust, a language inspired by C that focuses on safety. After extensive debugging, it was concluded that the structure of SETH combined with Sawtooth is undesirably complicated. Further debugging seemed merely counterproductive, as it would take too much time and insufficient documentation about the subject could be found online. Moreover, as Sawtooth and the other Hyperledger projects are a long way from being finished, it is expected that the systems contain defects that do not have a way of fixing yet.
Hyperledger Fabric was the obvious next option. Although Sawtooth SETH is more popular in the blockchain community, Fabric, with Fab3 as its Ethereum implementation, has existed for longer and has thus had more time to develop. Fig-ure 3.3 appears quite different from the Sawtooth flowchart. In essence, however, there are hardly any differences except terminology. Fab3 is the portal through which there can be communication with the Ethereum Virtual Machine (EVM) running on Fabric. In this case, another Hyperledger project is used to implement the EVM: Hyperledger Burrow. It is installed on every peer that is part of the Fabric network. Burrow allows the deployment of smart contracts in Chaincode, which is the inner framework of Fabric where smart contracts are executed.
The installation of Fabric with Fab3 had problems as had the installation Saw-tooth. The problems mostly resulted from conflicting dependency requirements between the Fabric Chaincode EVM and Fabric itself. Solving this required ex-ploring which versions did work, eventually leading to the functional combination. The Fab3-RPC allowed for implementation and invocation of smart contracts satis-fying all necessities for developing a prototype for DECADENT. The development was structured as follows. First, the front-end for this part of DECADENT was de-veloped. A basic Vue.js template was used as a basis1. One specialized component then appeared sufficient for containing all functionality. To make DECADENT ap-plicable to all situations where EVM-based blockchain systems are deployed, an input box was added where the user can input the port connected to the RPC. On input, the component tells the user if the port is valid. Figures 3.4 and 3.5 show
Figure 3.3: Fabric Fab3[12]
the possible outcomes.
Figure 3.4: RPC not available
Smart contracts deployed after entering the port will be deployed on the blockchain containing this RPC. The contract in the entered Solidity file is sent to the back-end using a RESTful API, where it gets compiled using a Solidity compiler. The compilation result contains the bytecode for the smart contract and the Appli-cation Binary Interface (ABI), which is a useful overview of the smart contract functions and parameters in JSON format. The bytecode is sent to the RPC using web3.js, which handles the encoding of the RPC request. The ABI is sent back to the server front-end, where it is used to build an input form, as shown in figure 3.6.
Figure 3.5: RPC available
The form contains all public smart contract functions that can be called. A function call is again sent to the back-end where it gets encoded and sent to the smart contract through the RPC. The response, i.e. all transaction information, is stored in MongoDB and visualized in another tab on the front-end. Figure 3.7 shows several of those bars with one expanded. All information present in the transaction is shown here and can be used for debugging and informational purposes.
This part of DECADENT is especially useful for comparing different blockchain implementations. If the blockchain contains an RPC with an EVM-like environ-ment connected to it, transaction timings can be compared. Moreover, the different ways blockchain handles transactions can be reviewed, eventually leading to a more substantiated choice of blockchain environment for a DApp. Consequently, this functionality improves on existing smart contract IDE’s.
3.3.2
Simulation
The second part of the prototype should be able to improve the understanding of DApp workflows. Caterpillar provides a way to build, visualize and deploy a DApp workflow on a blockchain system. Figure 3.8 shows the Caterpillar front-end editor, where a basic smart contract for loan applications is presented in BPMN. Adding this open-source application to DECADENT would be of great use to developers and business owners. Although Caterpillar is structured in a way very similar to the function testing part of DECADENT, the fact that it was written with Angular.js, made a translation to Vue.js too complicated and time-consuming. Another way had to be found to add its functionality to the prototype. Luckily, iFrames provide the most basic solution that preserves all functionality.
However, installing the Caterpillar source code next to DECADENT appeared not to be an option. Caterpillar requires other packages to function and would not
Figure 3.6: The input form based on the contract
work with the packages needed by DECADENT. Furthermore, Caterpillar contains its own blockchain testing environment based on Ethereum. This environment conflicts with the existing Fabric environment an thus could not exist with it in harmony. Docker provided the solution to these problems. Caterpillar running in a separate container has its own Node.js packages installed and cannot conflict with the blockchain environment on the host system. Binding ports from the host system to the Caterpillar container provided a way of communicating with the Caterpillar system. Figure 3.9 shows the resulting editor in DECADENT’s prototype. Figure 3.10 shows two example contracts deployed on the Ethereum test network.
The Caterpillar architecture can be modeled as shown in Figure 3.11. Cater-pillar contains two highly useful parts. The first being a translation module for converting BPMN to Solidity. The work item manager translates each task in BPMN to a work item in Solidity. The resulting contracts are deployed using the Solidity compiler and registered for later use. The second part is the execution engine which allows users to create running smart contract instances that users can interact with. The process executes each task automatically and stops when user input is needed. In between each task execution, the current state of the process is requested with a GET request. The response contains the item that is executed next. As the Caterpillar core works with requests, the whole process could be executed remotely, which makes remotely interacting with, or simulating, the process possible.
Figure 3.7: An overview of transactions with one expanded
What Caterpillar does not contain, as mentioned before, is a way of repeat-edly creating processes, running them automatically and varying the parameters. Although such simulation is not difficult, adding it to a sophisticated existing ap-plication required extensive investigation of the system. This primarily resulted in the certitude that a simulation panel inside the Caterpillar container would lead to confusion. Another panel in DECADENT’s front-end was the best choice. HTTP requests can then be used to create a DApp instance and interact with it.
The analytics panel allows a user to select any model deployed in Caterpillar. After the selection, the model BPMN is requested from Caterpillar. The response contains the BPMN but does not contain the compilation details. The BPMN is used to represent the model at the top of the page. The tasks that require user input are then extracted BPMN as well. Combined with the needed parameters, this data is used to create an input form for each user task, which requires initial input values for simulation. These user task parameters are automatically inserted in the respective user tasks when needed. However, for effective simulation, pa-rameters have to be varied. To implement this feature, a checkbox was added that opens an additional form when checked. In this form, depending on the
Figure 3.9: Caterpillar in a specialized Vue.js container
Figure 3.10: Two deployed process models
eter type, a distribution can be specified and customized to fit the needs of the user. Simulation of actual DApp behavior requires ways to simulate real-world situations. Luckily, a wide range of probabilistic models is available to imitate real-world probabilities. For instance, A Gaussian distribution can be customized to have a range that fits every possible simulation requirement of a developer.
f (x) = 1 σ√2πe −1 2( x−µ σ ) 2
Thus, the option to sample random values from a Gaussian distribution is given. JavaScript does not provide a package for this so the standard random number generator from the math package has to be transformed. This is done following the approach described by Azzalini & Dalla Valle [18, 19]. Gaussian parameters such as mean, variance and skewness can be customized to imitate a real-world probabilistic situation. For Boolean input values, a Bernoulli distribution with variable mean can be used to generate any combination of Boolean values needed.
f (k; p) = pk(1 − p)1−k for k ∈ {0, 1}
When every parameter has been filled in, the simulation can be started. Figure 3.12 should clarify how the analytics panel can look in a real situation.
Figure 3.12: Simulation dashboard with an example model selected
The simulation functionality is reasonably complicated. However, it can easily be explained using the diagram in figure 3.13. This fundamentally shows a loop that checks the current process status, runs a task with the current parameters if needed and stores task output in a database. This data can then be easily used for analysis and visualization.
Figure 3.13: Simulation operator
Figure 3.14: Results overview
3.3.3
Visualization
After a simulation is completed, the simulations are stored in a local database. Each simulation run contains multiple single process simulations. Which in turn contain all user tasks executed and the transaction receipts generated. Such a structure enables DECADENT to easily retrieve all information needed. The results tab of the front-end of DECADENT will show each simulation that is completed successfully as seen in figure 3.14. Clicking on this simulation will then take the user to a specialized component that contains all the configured plots and graphs. The visualizations were built using Jscharting, a chart builder that over the past two decades has proved to be a robust solution for making charts. Jscharting also contains a Vue.js extension which makes it the most preferable tool for simple visualization purposes.
The data structure resulting from the simulation also serves another purpose. In DECADENT, the short development time only allowed for a simple
demon-stration of what the simulation data can be used for. However, because the data structure follows a clean JSON structure, JSON based visualization tool-kits like Elasticsearch can easily be connected through an API, which will give users the ability to shape the visualizations entirely to their will.
Chapter 4
Crowd Journalism
To demonstrate the functionality the prototype already contains, a real-world use-case was chosen. For the functionality of DECADENT to be properly demon-strated, the usecase has to cover all parts of the tool. The usecase best suited for this demonstration purpose was drawn from the ARTICONF project as well. The usecase describes crowd journalism, referring to the cooperation between ordinary citizens and professional journalists to produce media content with higher added value [4]. The system allows ordinary citizens in places where journalistically rel-evant events are happening to record the events and upload them to the system. A smart contract processes the metadata of the video and validates if the location of the video corresponds to the location of the uploader. Either the video gets rejected or it gets passed on to the second smart contract. This smart contract is responsible for video classification. Even though the locations can be correct, the recordings can still be irrelevant or fake. The video has to be classified by peers, other nodes in the blockchain network. When enough peers have classified the video, and it is accepted, the video is stored in a database. Journalists can then use these videos for journalistic publications or more private purposes. Uploaders and peers get rewarded for correct classification in the form of tokens. These tokens can be used to buy available videos and use them. Although the blockchain frame-work for this usecase is clearly structured, see figure 4.1, the usecase developers could benefit from insight into specific DApp details. For instance, it is assumed that most classifiers are trustable. However, it is uncertain what would happen to the number of valid recordings and the rewarding system if a reasonable percentage of classifiers give wrong classifications. With the right parameters, DECADENT could show the consequences of such problems. Furthermore, if there are varying execution times for each function, an event may have already gone by without the chance of a video being uploaded. In the next paragraph, it is explained how DECADENT was used to gain insight in the DApp structure and performance.
Figure 4.1: Crowd journalism
4.1
DECADENT Usability
4.1.1
DApp Modeling
First, the system process had to be modeled using BPMN. The BPMN modeler em-bedded in the Caterpillar component was most useful for this. The aforementioned problem description specifies that two smart contracts are needed in this usecase. However, time constraints resulted in a slightly simplified model. This model con-tains all necessary components that are needed for a complete demonstration of the prototype. Furthermore, the prototype does provide the needed functional-ity for supporting the complete model. This would take more time, however, as two smart contracts result in a more complicated structure. The model used for demonstration purposes is shown in figure 4.2.
Figure 4.2: Crowd journalism simplified and modeled with BPMN
The top left of the model shows the starting event, e.g. a terrorist attack or political demonstration. The model needs a starting event to activate the process.
The first user task, indicated by the emblem of a person, is a task added for development purposes. This allows avoidance of a second smart contract. The required input parameter is the minimum amount of classifiers for a video. In the next user task, video metadata can be added, which is validated in the next task containing a script. If the video location is invalid, the video gets rejected. If the location is valid, the video passes to the classification space where peers can classify the video to receive tokens. In this model, the number of classifiers that accepted the video is entered. This is to avoid a loop in the smart contract. It is possible to implement this loop but getting Caterpillar to translate it correctly can be somewhat complicated. The next script task calculates the acceptance percentage using the minimum amount of classifiers and the number of classifiers that accepted the video. If the acceptance percentage is higher than 75%, the video is stored in a database and the uploader and classifiers are rewarded with an arbitrary amount of tokens. If the percentage is lower than 75%, the video is rejected.
4.1.2
DApp Analytics
Once the model is successfully translated and compiled, the Solidity smart con-tracts are returned. These can be used for simple function testing, which is use-ful as the scripts present in some tasks persist through translation. If there is an issue with those scripts, this can be found using the function testing part of DECADENT. Where the Remix IDE can do this on an Ethereum environment, DECADENT’s prototype can execute functions on any permissioned or permis-sionless blockchain with an RPC and the Ethereum Virtual Machine. Although this can be very useful, the biggest use of DECADENT is the ability to test the DApp behavior. This can be done on the simulation part of the DECADENT. As shown in figure 4.3, when the deployed model is selected, the simulation operator creates forms for each of the tasks that require user input. Appropriately naming the tasks in the model would allow for a more readable result.
After entering constant or varying values for each of the user tasks, simulation can be started by specifying the number of trials and clicking the simulate button. During the simulation, the model viewer located at the top of the page marks what task is currently executed. A progress bar shows the simulation progress. Finally, when the simulation is finished, results can be accessed from the results tab on the left of the page. In the next paragraph, these results are discussed more extensively.
Figure 4.3: Simulation dashboard of the crowd journalism usecase
4.2
Results
Because all execution data from the simulation is present in the database, every thinkable visualization can be made using Jscharting. For demonstration purposes, the execution times of each user task are shown in a graph in figure 4.41. Varying
the input parameters should not have a drastic effect on execution times. However, it is possible that when numbers start to grow, the execution times also rise, which is something to take into account as the DApp will be used by a big number of people all around the world so loading times should be as low as possible, as this could affect what videos are uploaded.
Besides the execution timings, all events and parameters are present as well. In this example, more extensive analysis can be done by exploring in what manner the input parameters affect the emitted events. For example, at the end of DApp execution, either a video is accepted and stored in the database or it gets rejected. Both events can be found in the data and connected to the input parameters to see what effect the parameters have on the classification outcome. To extend this even more, classifiers can be grouped into two categories, the trustworthy classifiers and those that cannot be trusted. Simulation can show the effect of the ratio between the two classifier types on the number of videos accepted wrongly. Further analysis
1It should be noted that Caterpillar has a significant effect on execution timings. As all commands are executed through an API connection, there is much room for external influences. In this result, it is therefore unclear where the varying execution times come from. Either the variation is caused by Ethereum itself, or Caterpillar has a significant influence. Still, the result is useful. For example, it could be checked if the execution times change when the workflow is altered.
Figure 4.4: User task execution timings
can then predict the effect of e.g. a false classification fine or a bigger reward for correct classification on the number of false classifications.
In this thesis, the possibilities of DApp exploration with the Crowd Journal-ism usecase were shown. However, DECADENT provides the possibility to build and deploy any business process model on blockchain. Different DApps contain different abstract problems that should be visualized with different techniques. DECADENT provides the basis for deployment and performance analysis of any DApp. More extensive analysis is DApp-specific and the user is encouraged to make small adjustments to the visualization part to fit their specific needs.
Chapter 5
Discussion
During this research project, the possibility and approach of building a DApp anal-ysis tool have been explored. The projected growth of the number of blockchain-based applications creates the necessity of such a tool. The smart contract analysis tool drastically reduces the time needed for testing the DApp in the stage of de-velopment. Moreover, it provides insight into smart contract behavior which can influence choices in structure and functionality in a positive way.
Following from the usability demonstration and results, it is shown that DECA-DENT can effectively analyze smart contract behavior. A clearly structured soft-ware framework was set up to provide multiple ways to analyze a DApp in de-velopment. DECADENT has multiple advantages to the analytics services that already exist. However, there are also several weaknesses to this tool. Both the contributions and DECADENT’s weaknesses will be discussed in the following paragraphs.
5.1
Contributions
As the field of blockchain studies is relatively new, there is a lot left to explore when it comes to the field of automated performance testing. Applications that are as smart as the one developed during this research project simply are not available yet. The biggest strength of DECADENT thus lies in the fact that it is very innovative. Even though the tool is merely a prototype, it still is a big contribution to the (permissioned) blockchain community. Other advantages will be laid out below.
• A big issue with most available modeling, testing, monitoring and simulation tools is the fact that they are built for specific blockchains. Hyperledger Explorer, for instance, is only useful for monitoring Sawtooth, Fabric and
Iroha. The Remix IDE can only test smart contracts deployed on Ethereum. Furthermore, open-source tools such as Caterpillar were built to work with Ethereum only. The advantage of DECADENT is that it is built to be used generically. The function testing part of DECADENT can work with any blockchain that uses an RPC and the Ethereum Virtual machine. The docker image for Caterpillar has an Ethereum testing network built-in. However, simply removing the testing network and starting the docker image with the option "network=host" will make Caterpillar bind to any RPC available, running on port 8545.
• DECADENT combines and improves concepts from different available test-ing and analytics frameworks. As a result, users do not need multiple tools for analyzing their smart contracts. Furthermore, the use of Vue.js results in DECADENT’s clear structure and user-friendly functionality.
• Being able to simulate DApp behavior with generated random numbers from different distributions, DECADENT is the only tool that can give important insights into DApp performance. These insights range from simple ones, such as the effect of parameters on execution timings, to more complicated insights, specific to a DApp.
• The unique way of visualizing the simulation output, inherent to DECA-DENT, is very versatile. While implementing simple visualizations such as an overview of execution times, space is given to users to fill in themselves. Combined with customized testing, this is unique and can be helpful to the community.
• A simple install script and docker image are combined to make DECADENT very easy to install. With a short installation manual, even users without a technical background will be able to install and deploy DECADENT.
5.2
Weaknesses
Although the list of weaknesses is short, they still should be named because they provide a basis for future research.
• DECADENT contains a large API structure with multiple endpoints. This means that there is a large amount of endpoint specifications that point to localhost. Consequently, when DECADENT is deployed in a cloud envi-ronment, a way to interact with DECADENT from this cloud environment has to be found. Luckily, Chrome Remote Desktop provides a solution. This
software can be installed to be able to open a desktop on the virtual machine that also contains a browser.
• A weakness that is mostly the result of time constraints is that DECADENT contains some bugs. For example, sometimes DECADENT fails to start simulation due to an underlying cause. This can be fixed but it would require a large amount of testing hours that are not available for this project.
• The part containing analytics and visualization is slightly underdeveloped. A basis for analytics and visualization is present, but this is not nearly enough to accommodate all possible usecases. However, as the data is present, users are free to add analytics and visualization frameworks to DECADENT for their own use. Given that Vue.js is easy to customize, manually adding a component should not a complicated task.
These weaknesses do not cause huge problems for the research project itself. How-ever, it would be desirable to remove them from DECADENT. This can be part of future studies.
5.3
Future Studies
Considering the fact that DECADENT developed during this research project is a prototype, much can be done to improve the functionality. For instance, DECA-DENT currently supports all blockchain systems with an RPC and an EVM. For a future project, it could be researched whether it is possible to make DECA-DENT even more generic so that other permissioned or permissionless blockchain frameworks can be tested. Furthermore, although Solidity is the main program-ming language for smart contract development, smart contracts written with e.g. WASM cannot be tested yet with DECADENT. Future studies could be done to determine the feasibility of implementing such support. Finally, as the part con-taining analytics and visualization currently can provide basic insight, more can be done to extend the functionality. For instance, it can be researched to which extent monitoring and visualization frameworks such as the ELK stack or Grafana can be added to DECADENT. This would result in a user-friendly environment for visualizing and analyzing the output data from the completely customizable simulation.
Chapter 6
Conclusions
Reviewing the tool that was developed during this study, evidently, the prototype enables answering the research questions in detail. To accelerate and simplify DApp development, first, the gap between business process models and decentral-ized applications had to be bridged. Caterpillar provided the best starting point, as it contains translation rules for translating from BPMN to Solidity. Automated and customized testing is not a part of Caterpillar so this had to be implemented. Using the single simulation functionality that was partly available, a simulation operator was built based on back-end API logic. The results of the simulation were stored in a clear JSON structure to make analysis and visualization possible. All data is available in DECADENT. JavaScript charting libraries are used for creating visualizations. JSON-based analysis frameworks can be used to gain a deeper understanding.
To bundle all components in a usable tool, a viable web-based application ar-chitecture had to be chosen. Although Vue.js was chosen for this application, An-gular.js or React.js can also be used. Back-end functionality can best be developed using JavaScript. Specifically, Node.js fits best for DECADENT as it supports all the required packages. Next, the front-end and back-end should be built in such a way that they do not form bottlenecks. A blockchain framework should be chosen for testing that has undergone enough development. Underdeveloped blockchain frameworks have a big chance to contain unsolvable problems. Finally, the com-munication with the blockchain had to be built into the front-end and back-end of the tool, ensuring that there are no faults in the system by making all system output clearly visible. As blockchain implementations generally are light-weight, the logging is minimal. Consequently, it can sometimes be a challenge to have a clear view of underlying behavior.
With this prototype, it is proven that automatically simulating DApp behavior on permissionless or permissioned blockchain frameworks is possible. Although this
tool is hardly more than a proof of concept, future versions of DECADENT will be of huge impact on DApp development worldwide. Considering the rapidly growing popularity of blockchain applications for industrial use, the tool developed during this research project will become an indispensable part of DApp development.
References
[1] W. Cai et al. “Decentralized Applications: The Blockchain-Empowered Soft-ware System”. In: IEEE Access 6 (2018), pp. 53019–53033.
[2] F. Tian. “An agri-food supply chain traceability system for China based on RFID blockchain technology”. In: 2016 13th International Conference on Service Systems and Service Management (ICSSSM). 2016, pp. 1–6.
[3] Q. Xia et al. “MeDShare: Trust-Less Medical Data Sharing Among Cloud Service Providers via Blockchain”. In: IEEE Access 5 (2017), pp. 14757– 14767.
[4] R. Prodan et al. “ARTICONF: Towards a Smart Social Media Ecosystem in a Blockchain Federated Environment”. In: Zenodo, Aug. 2019. doi: 10.5281/ zenodo.3580716. url: https://doi.org/10.5281/zenodo.3580716. [5] D. Parkins. “Blockchains: The Great Chain of Being Sure About Things”.
In: The Economist 31.10 (2015).
[6] C. Dwork and M. Naor. “Pricing via Processing or Combatting Junk Mail”. In: Advances in Cryptology — CRYPTO’ 92. Ed. by Ernest F. Brickell. Berlin, Heidelberg: Springer Berlin Heidelberg, 1993, pp. 139–147. isbn: 978-3-540-48071-6. doi: 10.1007/3-540-48071-4_10.
[7] A. Corso. “Performance Analysis of Proof-of-Elapsed-Time (PoET) Consen-sus in the Sawtooth Blockchain Framework”. In: (2019).
[8] H. Zhou, C. de Laat, and Z. Zhao. “Trustworthy Cloud Service Level Agree-ment EnforceAgree-ment with Blockchain Based Smart Contract”. In: 2018 IEEE International Conference on Cloud Computing Technology and Science (Cloud-Com). 2018, pp. 255–260.
[9] Z. Shi et al. “Operating Permissioned Blockchain in Clouds: A Performance Study of Hyperledger Sawtooth”. In: 2019 18th International Symposium on Parallel and Distributed Computing (ISPDC). 2019, pp. 50–57.
[10] S. Nakamoto. “Bitcoin: A Peer-to-Peer Electronic Cash System”. In: Cryp-tography Mailing list at https://metzdowd.com (Mar. 2009).
[11] G. Wood. “Ethereum: A Secure Decentralised Generalised Transaction Ledger”. In: Ethereum project yellow paper 151 (2014), pp. 1–32.
[12] S. Raval. Decentralized Applications: Harnessing Bitcoin’s Blockchain Tech-nology. O’Reilly, 2016.
[13] R. Henry, A. Herzberg, and A. Kate. “Blockchain Access Privacy: Challenges and Directions”. In: IEEE Security Privacy 16.4 (2018), pp. 38–45.
[14] K. Gai et al. “Permissioned Blockchain and Edge Computing Empowered Privacy-Preserving Smart Grid Networks”. In: IEEE Internet of Things Jour-nal 6.5 (2019), pp. 7992–8004.
[15] Solidity by Example. Accessed: 2020-6-19. url: https://solidity.readthedocs. io/en/v0.6.4/solidity-by-example.html.
[16] O. Pintado. “Caterpillar: A Blockchain-Based Business Process Management System”. In: Sept. 2017.
[17] Seth-RPC. Accessed: 2020-6-19. url: https : / / sawtooth . hyperledger . org/docs/core/releases/0.8.10/solidity_developers_guide/seth_ rpc.html.
[18] A. Azzalini. “A Class of Distributions Which Includes the Normal Ones”. In: Scandinavian Journal of Statistics 12.2 (1985), pp. 171–178. issn: 03036898, 14679469. url: http://www.jstor.org/stable/4615982.
[19] A. Azzalini and A. Dalla Valle. “The multivariate skew-normal distribution”. In: Biometrika 83.4 (Dec. 1996), pp. 715–726. issn: 0006-3444. doi: 10 . 1093 / biomet / 83 . 4 . 715. eprint: https : / / academic . oup . com / biomet / article-pdf/83/4/715/702865/83-4-715.pdf. url: https://doi.org/ 10.1093/biomet/83.4.715.
Appendix
All code used for the development of DECADENT is publicly available on GitHub1. In this repository, a README.md is available that contains installation instruc-tions and further notes.
