ABCDE — Agile Block Chain DApp Engineering
This post is part of Overtheblock’s Tech Series whose aim is to contribute to a fruitful and efficient usage of exponential technologies in reshaping the way business is conducted, and society is governed. More specifically, this contribution proposes a method for the improvement of blockchain software development processes.
The post is an excerpt from the homonymous scientific article by the same authors published in Blockchain: Research and Applications, vol. 1, 2020.
Blockchain software development is becoming more and more important for any modern software developer and IT startup, and software repositories are experiencing an explosion of blockchain projects developed by small, medium and large teams.
Nonetheless, blockchain software production still lacks a disciplined, organized and mature development process, as demonstrated by the many (in)famous failures and frauds that occurred in recent years.
To address this issue, we developed ABCDE, a complete method addressing blockchain software development. In its present version, ABCDE covers Ethereum Solidity development, though it can be extended to other DLT systems and languages [1].
The method considers the software integration among the blockchain components — smart contracts, libraries, data structures — and the off-chain components, such as web or mobile applications, which altogether constitute a complete DApp system.
We believe that agile practices are very suited to DApp development, because they target systems whose requirements are not completely understood since the beginning, or tend to change, as it is the case of most blockchain-based applications. ABCDE is based on Scrum [2]. The main difference with Scrum is the separation of development activities into two flows — one for smart contracts and the other for off-chain software interacting with the blockchain.
ABCDE makes explicit the activities that must be performed to design, develop, test and integrate smart contracts and off-chain software, and documents the smart contracts using formal UML diagrams to help development, security assessment, and maintenance.
The proposed method also has specific activities for security assessment and gas optimization, through the systematic use of patterns and checklists.
DApp Architecture
The so-called “decentralized applications”, or “DApps”, are a trending area of software development.
DApps typically run on a blockchain, the technology originally introduced to manage the Bitcoin digital currency, which runs in a network of peer-to-peer nodes, so it is naturally decentralized, redundant and transparent.
A blockchain can also be the ideal environment for a decentralized computer, and this led to the introduction of the Ethereum blockchain, whose nodes are able to run Turing-complete programs called “smart contracts” (SCs). The original idea behind SCs is that they can be used for the automated enforcement of contractual obligations, without having to trust a central authority, and without space and time constraints.
Ethereum blockchain, and many other kinds of similar initiatives to develop Distributed Ledger Technology (DLT) to run SCs, can be also used by networks of nodes selected by invitation, and not necessarily aimed at managing digital currencies, which are called “permissioned” blockchains.
All the initiatives behind blockchain technology — new digital currencies with their own blockchain, exchanges and other web-based ventures using digital money, ICO startups, and applications running on permissioned DLT — are based on developing software inside this new paradigm.
Figure 1 shows the typical architecture of a DApp. Here the blockchain, with its nodes and related SCs is shown on the left. On the right, we show what we call “App System”, the software system which enables easy interaction with the DLT. The App System is in turn divided into modules facilitating the user interaction (shown at the bottom of the figure), and modules running business logic and storing off-chain data, on the Cloud or in dedicated servers, shown at the top.
For instance, the App System of a wallet able to directly access a public blockchain is composed only of the UI part. The App System of an Exchange is composed of complex server modules enabling the management of the accounts, clearing books used for trading, many services offered to its customers, and modules enabling the user interactions — which run the Exchange responsive Web site, and which might also be specific apps to download and run on mobile terminals.
We note that SCs running on all the nodes hosting a blockchain have the strong constraint that all outputs and state changes resulting from their execution must be the same in all nodes. Consequently, a SC is strictly forbidden to access the external world — it can answer to external messages belonging to its public interface and can send messages to other SCs running on the same blockchain; no other kind of direct interaction with the external world is allowed.
This fact implies that any DApp is intrinsically divided into two subsystems — the SCs running on a blockchain, and the App System allowing users and devices to interact with the SCs. These systems are very different, and their development must use different techniques. The App System is very similar to existing Web applications, though often with above-average security constraints. SC development, on the other hand, needs new concepts, among which the concepts of “address”, signing with the private key behind the address, “gas” consumption, SC immutability once deployed, cryptocurrency transfer and “oracle”.
This specificity led us to conclude that a new methodology of software development is needed for DApp development. In fact, ABCDE is not entirely new, but it is a significant extension of Scrum, a classical agile method.
An Iterative, Agile workflow
Nowadays, the developments of DApps worldwide share some common characteristics. Several teams involved are typically working on DeFi (Decentralized Finance) projects, which gathered money through venture capital and/or token minting. Other projects are promoted by startups trying to take advantage of the novelty of DApps to develop disruptive solutions, or to get a niche where to thrive.
In both cases, they are typically small, self-organizing co-located teams, where experts of system requirements are highly available. Another characteristic of DApp development is that DApps typically are not life-critical applications, though several among them can be mission-critical. The time-to-market and the ability to get early feedback from the users and the stakeholders are essential, because often the requirements of the DApp initially are only vaguely defined and are subject to change.
All these features make DApp development an ideal candidate for the use of Agile Methods (AMs), which are suited for small, self-organizing teams, possibly co-located, working on projects whose requirements can change [3]. AMs are able to deliver quickly and often, as needed by DApp projects. The most used AM is presently Scrum [2], and from Scrum we kept the requirement gathering with user stories, the iterative-incremental approach, the key roles, and the events.
In short, Scrum, as most other AMs, typically performs requirement elicitation through user stories (USs), which are short descriptions of how the system answers to inputs from users, or external devices. USs are mostly gathered at the beginning of the development but can be modified and augmented at any time. The project advances iteratively implementing a subset of the USs at each iteration. Each iteration is called Sprint. The person accountable for defining the Sprint Goal and explaining the USs to the Developers is called Product Owner. Developers select the subset of USs needed to reach the Sprint Goal.
The steps of the proposed ABCDE design method are shown in Fig. 2. Note that most steps are in fact performed many times, because the approach is iterative and incremental. In the figure, the pink circles represent Sprint Planning Meetings (SPM) held at the beginning of each sprint with the aim of defining a Sprint Goal and a plan to deliver it, and Sprint Review Meetings (SRM) held at the end of sprints with the aim of inspecting the Sprint results and determining future adjustments. Daily Scrums (stand-up meeting held each day, whose goal is to inspect progress towards the Sprint Goal and adapt the work if necessary) and Sprint Retrospective (event held at the end of each sprint whose goal is to inspect the Sprint results and determine future adjustments) are not reported.
After an initial stage where the vision of the project and the initial USs are gathered, the process proceeds in two iteration cycles, one aimed at developing SCs, and the other at developing the App System. After 2–3 iterations, the two subsystems are integrated and tested, and the iterations proceed.
For a detailed description of the steps, we refer to the original paper which is publicly available.
Besides Scrum, other agile practices are well suited to DApp development, and which may be leveraged in the ABCDE process. The most important are:
1. Test Driven Development (TDD), which is writing the tests even before the code, using an automated test suite.
2. Continuous Integration: merging all developers’ working copies to a shared mainline, even several times a day. This practice is strictly linked to TDD, because when new code is integrated into an existing one, it is necessary to run all tests to verify the absence of unwanted side effects.
3. Collective code ownership: every developer is allowed to intervene on whatever code s/he considers appropriate to modify. Team members modifying SC code, however, should be very careful not to infringe security and gas optimization rules.
4. Information Radiators (Cards, Boards, Burndown charts): making visible the status of a project using boards that can be observed by everyone and updated in real-time can obviously greatly benefit DApp development.
5. Coding Standards: the project manager (or the Scrum Master) must ensure that this practice is strictly followed, facilitating code understanding, and easing subsequent maintenance activities.
6. Pair Programming (PP): we suggest using PP in the case the software to be developed is critical, is not yet well understood, or there are new team members to train on the job.
Security and Gas Optimization
Assessing SC and, in general, DApp security is a difficult task, due to the complex and new architecture of DApps. A sound method for DApp development, however, cannot overlook security. Since DApp security assessment covers a large number of concepts and guidelines, we wrote a specific paper on the subject written by our research group, which can be read on Arxiv [4]. Here we briefly recall the key advice of this paper.
Following a secure software development lifecycle approach, ABCDE does not limit security assessment to testing, or to a specific phase performed after development, but it introduces security assurance practices in all three phases of design, coding and testing. Moreover, ABCDE stresses that the first and foremost concept in security management is to have a security mindset. The development team(s), and the whole organization, must be fully aware of the importance of security and protection from attacks.
Since ABCDE is an agile process, it is based on principles and practices such as: maximising communication, short iterations, refactoring, continuous testing, simplicity, intention-revealing code, and use of simple tools. All these practices surely help security. However, Agile also means incremental development, where USs are continuously implemented, added to the current working system and tested. This greatly helps productivity, but might be at the expense of security, because there is the risk that these continuous additions may introduce unwanted side effects and even security breaches.
Our approach includes some security checklists, to be performed during and after the design, coding and testing phases. The aim is to verify that all security patterns and practices concerning known problems are applied. We also include a checklist for gas optimization, which is crucial not only for saving money, but also for sparing DOS attacks and avoiding unwanted SC execution abort for running out of gas.
ABCDE approach is iterative and incremental. When developing DApps which manage real value, like digital money or tokens, it’s important that all stakeholders (or blockchain governance bodies) agree on the smart contract logic and implementation. This means that all stakeholders should be involved in each iteration, or at least in the iterations leading to the integration of SC and App systems. In the case this is not possible, one has to anticipate the detailed design and coding of the key contracts at a given set of iterations — involving all stakeholders — and then give the Product Owner the responsibility of checking and taking note of all the changes. In all phases, depending on the size of the project and the number of SCs, the checklist can be unique for the system, or you may use a separate checklist for each SC subsystem. A spreadsheet file with the checklists is available at the following link: http://tiny.cc/security_checklist.
Besides security, another important factor of smart contracts that must be carefully designed from the beginning is their cost. Creating SCs and writing permanent data in a public blockchain can be very costly, so it is important to keep them to a minimum and to limit the transactions that write or modify these data. Also, the messages exchanged among the App System and the SCs, and among SCs, must be properly designed and well documented. The specific patterns that can be used to save gas are presented and discussed in Ref. [5].
Note that in Ethereum the maximum size of the bytecode of a SC is restricted to 24576 Bytes by the standard EIP 170. For serious SCs, that size limit can be hit easily, so many of the gas-saving patterns are useful also to make a SC viable.
UML Extensions
When designing and documenting SCs, diagrams can be very useful to highlight the connections and the exchange of messages. For this purpose, we advocate the use of a subset of UML diagrams, being UML the universal standard for software design diagrams [6] . Note that some specific concepts must be introduced to account for peculiar SC features.
Luckily, UML has an extensibility mechanism called stereotype, which can be used to introduce new concepts, through tagging. The UML diagrams we considered to model SCs are Class diagrams and Sequence diagrams. Also, UML Statecharts can be used to graphically represent the various states of a SC, or of an App System module and its transitions. Statecharts, however, do not need any specific stereotype.
Class diagrams help to effectively model the data structure of smart contracts, whereas the exchange of messages between the entities of the system is modelled using a modified UML sequence diagram.
In Fig. 3 we show a class diagram documenting the SCs of a supply chain certification system. The entities looking like classes, are in fact SCs, when tagged with the “<<contract>>” stereotype. You can also see “<<abstract contract>>” and “<<library>>” stereotypes, according to the corresponding constructs of Solidity language. A SC can have attributes, which are part of its storage variables, and operations (functions), which can be part of its ABI (Application Binary Interface). Special functions called “modifier” are tagged with the homonymous stereotype. The records that can be defined and used by SCs are tagged as “<<struct>> and cannot hold operations.
The diagram also shows tags of kind “<<mapping>>”, to denote how a collection is stored in the SC.
Fig. 4 shows a sequence diagram documenting how messages are exchanged among participants in a Decentralized Exchange (DEX). Here you can see SCs (“<<contract>>” and “<<external contract>>”), wallets and a standard application (Relayer), with no stereotype.
The messages exchanged between these participants, can be transactions sent to the blockchain by an external address (“<<trans-msg>>”), calls of public functions of a SC made by another SC (“<<internal-msg>>”), token or cryptocurrency transfers (denoted by a dashed arrow). For a complete list of the stereotypes introduced to document SC design, please refer to the original paper [1].
The proposed ABCDE method has been tested on some real DApp development projects, and is continuously upgraded to stay up to date with the new versions of Solidity.
[1] L. Marchesi, M. Marchesi, R. Tonelli (2020). “ABCDE — Agile Block Chain DApp Engineering”. Blockchain: Research and Applications, vol. 1, Elsevier.
[2] K. Schwaber, M. Beedle (2001). “Agile Software Development with Scrum”, Pearson.
[3] K. Beck, et al. (2001). “Manifesto for agile software development”.
[4] L. Marchesi, M. Marchesi, L. Pompianu, R. Tonelli (2020). “Security checklists for ethereum smart contract development: patterns and best practices”, arXiv preprint arXiv:2008.04761.
[5] L. Marchesi, M. Marchesi, G. Destefanis, G. Barabino, D. Tigano (2020). “Design patterns for gas optimization in ethereum”, in: International Workshop on Blockchain Oriented Software Engineering (IWBOSE), IEEE, pp. 9–15.
[6] M. Fowler (2018). “UML Distilled: A Brief Guide to the Standard Object Modeling Language — 3rd Edition”. Addison-Wesley Professional.
Please cite as:
Marchesi L., Marchesi M., Tonelli R. (2022) ABCDE — Agile Block Chain DApp Engineering, Overtheblock Innovation Observatory, retrievable at [link].
OverTheBlock is a LINKS Foundation’s initiative carried out by a multidisciplinary team of innovation researchers under the directorship of Enrico Ferro. The aim is to promote a wider awareness of the opportunities offered by the advent of exponential technologies in reshaping the way business is conducted, and society is governed.
We are chain agnostic, value-oriented and open for discussion.
