Blockchain Architecture Design Guidelines – Architecting Blockchain-Based Applications (3/3)

Although (or because) blockchain is a hype topic, careful analysis is necessary to check whether blockchain is an adequate solution for an envisioned application. Designing the architecture of blockchain-based applications is challenging and requires a significant amount of aligned architecture decisions. We support architects with guidelines for the decision whether blockchain could be an adequate solution and guide decision making for blockchain-based applications by outlining the architecture design space with numerous relevant questions.

①Needs | ①Foundations | ②Blockchain Terminology | ③Blockchain Drivers | ③Architecting Guidance | ③Get Started

In our first article of our article series on architecting blockchain-based applications, we motivated our work and the key contributions that resulted from our internal workshop in that topic. Our first key observation was that in literature on the blockchain concept and its applications, terms are often confused and used in a not clearly delineated way. In the previous article, we described a terminology precisely delineating key terms around blockchain, addressing our first key observation. Our second key observation was that blockchain-based applications are not easy to be designed, and guidance is needed in asking the right questions to make well-informed decisions on the central architectural questions. In this article, we want to provide relevant and helpful architecting guidance. Our guidance covers three parts:

• Dealing with architecture drivers and checking whether they point towards using blockchain technologies.
• Exploring the design space of an architecture for a blockchain-based application and guiding architects to touch the relevant questions and build a comprehensive understanding of the architecture they design.
• Deepening the understanding of the impact of blockchain-based applications on their users and the user experience.

Below, we use Ethereum as an example technology for better understandability. However, this choice is arbitrary and our arguments work with any given technology.

Architecture Drivers that Might Benefit from Blockchain

When designing the architecture of an application and considering to use blockchain technology as a basis, it is important to make an informed decision about whether using this paradigm and technology is an adequate solution or not. A helpful approach to get a foundation for this decision is to look at existing real-world applications with their requirements and design decisions. However, the available number and documentation is limited.

To provide support for architects, the approach we followed was to identify the key features a blockchain provides and reason about situations where these key features are helpful. As a result, we identified the following properties for a quick check to judge whether blockchain could be an adequate paradigm and technology, because otherwise, other (simpler – and simpler often means better) technologies could be applied to solve the problem. Then, we provide a more elaborate version of architecture drivers that are in favor of using blockchain technology to build applications. The following figure summarizes our quick check questions and refined drivers.

Blockchain Adequacy – Quick Check

In order to quickly check the adequacy of blockchain technology for an application that is developed, an architect should check the following properties:

1. A group of several participants wants to keep track of certain transactions between them, to the public, or a certain subgroup of the participants. In principle, any kind of transaction concept can be possible here, such as transferring money in some currency system, distributing files in a file system, making legal contracts, etc.
2. The handled transactions are important for the participants in some sense, e.g., in a legal sense, with respect to monetary value, in a sense of secrets of some company which have a high value, etc. Furthermore, the participants do not trust each other
3. Using a central, trustworthy authority that validates transactions and keeps track of them is not a preferable option.

If the properties 1.-3. are fulfilled, using blockchain as a technology might be an adequate solution idea, and further analysis and design considerations are needed. Otherwise, different solutions approaches and technologies should be considered.

Blockchain Adequacy – Refining the Architecture Drivers

After answering the questions of the quick check and having a first indication of „Am I in a situation where blockchain technology could be an adequate technology choice?“, of course one has to dig deeper to make an informed decision in the concrete situation. With the following questions, we guide the further analysis and discussion of architecture drivers and the adequacy of blockchain for an application.

Data Integrity

• Is data integrity especially important? This means, logged transactions must be safe from later manipulation. If you are in a situation where one has a growing amount of data over time related to some real world value, i.e., one has to be able to append new data, and once data has been added, it must not be lost, blockchain might provide an adequate technology for storage.
• The situation should be that data integrity is more important than performance (number of validated transactions per time unit), since blockchain technology will not perform as well as standard databases.
• Is probabilistic data integrity, unalterability etc. acceptable? In our first article, we mentioned that concepts such as unalterability of data in the ledger do not hold for sure but only in a „probabilistic“ or „risk-based“ manner, which is in some sense a consequence of the used consensus algorithm protocols to eliminate the need for a central authority. Here, the used mechanisms make it computationally hard but not impossible to alter the data in the ledger retroactively. Notice the subtle difference between the first bullet point above and the probabilistic data integrity mentioned here: Even though we might explicitly choose blockchain technology because of its provided data integrity, we do not get guarantees on that! We thus should ask ourselves whether we need some guarantee on data integrity in a strict sense. In some application domains, the requirements for such a guarantee, which might, e.g., be present due to special legal restrictions in the given problem domain, might prohibit the use of blockchain technology. This might be the case for applications where human safety aspects play a strong role.
• Is it acceptable that written data cannot be changed any more? Data written to a blockchain cannot be altered later on. It is an integral part of the ledger and will stay. If this property of data is not acceptable, blockchain technology might be not adequate.

Scalability

• Does the system have to be scalable in the sense of number of users or peer nodes? Blockchain technology is built to easily add peer nodes without investing in central infrastructure in advance.
• Does the system have to scale in the sense of increasing amounts of data and number of transactions? Blockchain technology has limitations in terms of throughput and size of data stored. This has to be considered.

Data Transparency

• Does the needed or acceptable level of transparency match blockchain properties? By default, blockchain technologies lead to a visibility of all data written to the blockchain ledger for all participants for all times. However, we note that participants, transactions and data do not have to be fully transparent, since e.g. in Bitcoin, participants are anonymous due to the fact that they are only identified by their public key. Hence, one has degrees of freedom in adjusting transparency of the data stored in the blockchain, e.g., by using corresponding detailed (potentially cryptographic) concepts for data modeling, by using anonymization or pseudonymization, and so on. However, this does not come by itself, but, after informed decisions on the desired level of transparency have been taken, it has to be implemented explicitly.
• If opting for non-transparency of a certain concept (identity, transferred data, …), one has to be sure that it will not be a problem in the future if the corresponding data, e.g., the identity of some participant, is revealed. This might e.g. result from using data which is external to the blockchain. For example, if one is able to match a certain public key of a participant in Bitcoin to some real-world person, since one knows that a certain transaction was used to pay for some good delivered to the person, all transactions the person has ever made in Bitcoin using the same public key can be matched to that person. Another corresponding situation might be that due to increased processing power, a few years after some encrypted data was stored in the blockchain, it might be possible to decrypt it and reveal the information. Even if personal data can be pseudonymised or anonymised for privacy reasons, transactions are usually visible to everyone. Thus, the question must be answered, which level of visibility of transactions is desired. This has also implications on the use of a public, private, or no blockchain at all.
• Another important thing to consider here are legal requirements as the European General Data Protection Regulation (GDPR, in German called DSGVO), which entitles users to demand deletion of their personal data. Since by default, data written to a blockchain persists for all times, care has to be taken that this aspect is handled correctly by the devised blockchain-based application.

Reliability and Availability

• What level of reliability/availability do we need? Is it important that the ledger/data storage is available almost all of the time, e.g., 99.9 % of the year? Also, is it important, that it is publicly available to everyone participating in the particular ecosystem? Due to the concept that the data in the blockchain is replicated many times among the participants‘ peer machines, the system will have high availability since it is not a problem if some machine fails. Furthermore, we should ask ourselves whether we want to achieve this without investing too much in advance for infrastructure, since otherwise, other approaches which provide high availability and reliability might also be possible.
• For a public blockchain, we have to consider what happens with the blockchain in the longer run. For example, it is possible that nobody will run Bitcoin nodes in a few years, since Bitcoin is replaced by a different cryptocurrency. Then, applications building on the respective blockchain might become unavailable and data stored in the blockchain will be lost unless it is backed up in some way.
• We also have to think about what happens in the beginning. For many applications, a „critical mass“ of users is necessary to make more users want to participate. Some strategies might have to be devised here to get the application running, e.g., somehow the new application might have to be presented to the public at certain occasions, or certain special benefits might be necessary for early adopters to motivate people to participate. If too few participants or nodes exist, it might be too easy to perform a 51 % attack for people to trust the application, and also the application might not have sufficient reliability since in case only a few nodes fail, the application might fail in total.

Blockchain Architecture Design Space Guidelines

Designing the architecture of blockchain-based applications comes with a large number of degrees of freedom. There is no standard architecture and depending on the concrete requirements and the blockchain technology chosen, an architect has to come up with many individual decisions. Thus, we chose to give the architecting guidance in the form of questions to be answered and decided on by the architects and developers of blockchain-based applications.

To put some structure on our design space guidelines, we use the Fraunhofer ADF (Architecture Decomposition Framework, see the figure below). It is a framework for architectural views that aims at supporting architects to decompose and document the overall architecture of a software system into clearly separated views with guiding names. ADF helps in structuring architecture work by providing guidance for asking the right architectural questions about the software to be developed. Hence, the ADF views are ideal to attach the guiding questions for the design space exploration towards blockchain-based applications. To come up with the guiding questions, we analyzed what the specific properties of the blockchain technology (distribution of the application, immutability of the data in the ledger, …) mean with respect to an application’s architecture and the central decisions. The desired properties of applications that are developed using blockchain technology (e.g., trustworthy handling of important data) provide guidance here. One can observe that our resulting, below-mentioned design space guidelines span across all aspects of the ADF, which emphasizes that the architectural impact of using blockchain technologies for building applications can be immense.

The following figure depicts the central concepts that make up ADF’s architecture views: One separates runtime aspects, i.e., how the running system is structured and behaves, from development time (devtime) aspects, i.e., how the application’s code is organized. Furthermore, one considers how data is structured, which functions the application provides, how deployment is done, and which activities are performed by developers and operators of the software. Furthermore, technologies are considered.

In the following, we present key questions for the exploration of the design space when architecting blockchain-based applications by traversing the ADF. Architects and developers can use these questions to systematically explore decisions to be made. Depending on the technologies selected, some design decisions might be already determined or at least restricted. Thus, our questions might suggest decisions that are implicitly already taken with your choice of technology. Nevertheless, the questions significantly add to the understanding of blockchain technologies and their usage in applications.

Explore the design space of data aspects @ runtime:

• What kind of data is stored in the blockchain?
  • Is the data itself stored in the blockchain (on-chain) or is only a reference stored in the blockchain (and the real data is off-chain)?
  • Is the data stored in the blockchain encrypted?
• Where is the data stored?
  • On which nodes is the data stored?
  • When and how and by whom is determined, where the data is stored (during runtime, during development)?
  • Where is data persisted and where is it only kept in memory?
• How large are the data elements stored in the blockchain?
• How large is the distributed database / ledger of the blockchain technology on the individual nodes?
  • When and how is the ledger initially downloaded to the nodes?
  • How is the expected growth of the ledger over time?
• Is the distributed database/ledger of the blockchain technology covering only data of the application under design or is it a general-purpose ledger storing also data of other applications (developed by someone else)

Explore the design space of functions aspects @ runtime:

• Which logic to place on the blockchain ledger (with Smart Contracts) and which to place in an application layer?
  • Which logic does benefit from the execution as Smart Contracts?
  • Which logic does only rely on storing results on the blockchain ledger?
• What is the interface between the application and the blockchain layer?
  • Which errors/anomalies can occur, on which to react on application level?
  • Which UX concepts are needed? Which potential errors have to propagate up to the user(s)?
  • What is the impact on the real world? How long does it take to get assured transactions? What can be rolled back and what not?
  • What is the behavior of the blockchain technology? When are things volatile? When are they confirmed? How to handle that on application level?
• Which UIs will give the end users access to the blockchain?
• Is it necessary to do mining in the blockchain? Is this valid for all nodes?

Explore the design space of deployment aspects @ runtime:

• Is the application functionality executed on-chain or off-chain, i.e., deployed on the blockchain ledger as smart contracts or to some other execution node as a separate application layer?
  • Smart contracts: The key application logic of the blockchain-based application is stored on the blockchain ledger as a smart contract. Application data (or excerpts of it) is also stored on the blockchain ledger.
    In case the smart contract should be executed, it is loaded in the runtime environment provided by the used blockchain technology and executed, storing new states of data again in the blockchain ledger. Additional application logic and the user interface can still run on a separate application layer or even node.
  • Separate application layer: All logic and the user interface of the blockchain-based application is running on a separate application layer, only the application data (or excerpts of it) is stored on the blockchain ledger.
• In case of a blockchain-based application which does not only consist of smart contracts: Where is the blockchain-based application deployed?
  • On a separate application node, which communicates with the blockchain node?
    As the blockchain nodes often use highly optimized hardware for blockchain mining, deploying the application logic on a separate application node might be considered.
  • On the blockchain node itself?

• Do users of the blockchain-based application have dedicated blockchain nodes or do they share blockchain nodes? This means, does a single node handle the storage of data in the ledger for several users, or is this done by an individual node for each user?
  • Are there dedicated blockchain nodes of the individual user (part “a” of the following figure), that only serve the application node of the user? This also means that the user has its own “copy” of the blockchain ledger.
  • Do users of the blockchain-based application share the same blockchain node? This also means that they share a “copy” of the blockchain ledger. A further architectural decision is then, how many and which users share a blockchain node.

• Do users have their individual application node running the blockchain-based application or do they share application nodes?
  • Is there a dedicated application node for each user of the blockchain-based application (this is depicted in “a” in the following figure)?
  • Do users share centrally operated application nodes, which are only accessed via light-weight user interfaces, e.g. a web client? (“b” in the following figure)

• If a user works several blockchain applications based on the same blockchain technology: Do these blockchain applications work with the same blockchain ledger or are they using different ones?
• What are hardware requirements to use a certain blockchain technology and the corresponding costs?
  • Is it possible to participate without mining?
  • What hardware is needed to participate without mining?
  • What hardware is needed to participate with mining?
• What are infrastructure / software / network requirements to use a certain blockchain technology?

Explore the design space of activities aspects @ runtime:

• Which operation model do we choose for the blockchain?
  • Build on an existing public/central blockchain instantiation?
  • Create and operate an own public instantiation (permissioned or permissionless)?
  • Create and operate an own private instantiation?
• What can be consumed from cloud providers (blockchain as a service)?
  • Partial set of nodes for a private or public blockchain (without mining)
  • Partial set of nodes for a private or public blockchain (with mining)
• What type of operation activities is needed by the application developer?
  • Updates? Configuration?
• What type of operation activities is needed by the blockchain operator?
• What type of operation activities is needed by the end user?
  • Installation? Configuration?

Explore the design space of technology aspects @ runtime + devtime:

• Which blockchain technology to choose with which characteristics?
  • Ledger Type: Permissionless vs. permissioned?
  • Which consensus algorithms are available?
  • Governance: Who controls the lifecycle/evolution of the blockchain technology? (Community, Consortium, Company, …) Which goals do they pursue?
  • Under which license is the blockchain technology available?
  • What is the maturity and popularity of the blockchain technology?
  • Does the technology come with a crypto currency or not?
  • How much cost is needed to conduct transactions? (real-world cost)
  • How long does it take until a block gets written? How long does it take until a transaction can be assumed to be accepted by all nodes?
  • What is the maximum throughput of the technology (in transactions per second)?
  • How does the network behave when more nodes are added?
  • Tool ecosystem: Are there developing, debugging and testing tools available?
• How to configure the blockchain technology? (Mining, transaction costs, …)
  • Which proof to use?
  • Which node types to create and how many of them? (impact e.g. on validation times and throughput)
  • Which block size to use?
  • Should the blockchain technology be used with centralized or decentralized validation?

Explore the design space of data aspects @ devtime:

• How to design the data structures to be stored on the blockchain ledger?
• How to connect data structures on the blockchain ledger with off-chain data structures?

Explore the design space of functions aspects @ devtime:

• How to decompose the blockchain-based application into modules?
• How do the APIs of the blockchain technology look like towards applications/clients and for which programming languages does direct support exist (e.g. in the form of libraries)?

Explore the design space of deployment aspects @ devtime:

• What are the deployment units of applications and how are they built and packaged?
• How are the deployment units of applications distributed to nodes for installation?
• How are the deployment units of applications installed on the nodes?
• What are the deployment units for smart contracts and how are they installed on the nodes?

Explore the design space of activities aspects @ devtime:

• How is the blockchain-based application tested?
  • Which nodes are needed?
  • How to bring the ledger in a clear starting state to have reproducible behavior in tests?
• Which tools are available for development around the blockchain technology?

For architects not knowing the ADF in detail, we sketch how one can do architecture work based on it, which works roughly as follows. The following order of architecting work is recommended (although in the end, all aspects have to be iterated and aligned):

• Start with describing aspects of your system when it is executed (Runtime). Then proceed to describe how your system is organized during development (Devtime). Besides the blockchain-specific questions given in the next sections, runtime aspects typically include general questions like which different services/components/domains can be identified and how the system can be deployed. On the other hand, devtime considerations cover aspects like package structure, source code management, build pipeline etc.
• Start with Data and Functions, then care about Deployment and Activities, and in parallel touch again and again Technologies

Impact on Users and User Experience

Designing and developing applications that are based on blockchain technologies is not only complex by the topic itself, it also has major implications in terms of usability and user experience. Possible challenges mainly arise from the fact that the whole technology stack is very complex and involves a massively distributed network.

When designing blockchain-based applications, available UX guidelines are of course still valid. However, the technical properties of blockchain lead to implications that might more or less shine through to the interaction concept and need careful tackling in the UX concept. Thus, the following questions can give guidance in the process of intertwined architecting and user experience design with a specific focus on blockchain:

1. Timing aspects
   • How to handle delay in processing a transaction?
   • How to deal with situations where (after some time has passed) immediate feedback of the user is required?
   • What happens when a user’s transaction is being unprocessed for a longer time? E.g., in Bitcoin, transaction fees are paid to the miner that creates a new block containing the transaction. Since this mining process requests immense computing resources, transactions with higher fees are favored and transactions with comparatively low fees are disregarded.
2. Correct transactions
   • How does one prevent the app from creating invalid/corrupt transactions that will be rejected by other clients or nodes?
   • What happens when the same user commits multiple transactions from different devices?
     For instance, consider a voting app, where certain people (e.g. citizens of a country) are provided with a token which they can use to vote for a president. The vote is registered and counted via a smart contract that also publishes the result after a certain timespan.
     Now a citizen votes for president A from the smart phone, then votes again from the computer for president B. Both voting transactions go to different mining nodes. While, technically, it is guaranteed that eventually only one transaction becomes part of the longest chain and, thus, the valid vote, how does the app communicate this to the user? In which state are both apps?
3. Network aspects
   • How does the app deal with network problems (no internet for several minutes)
4. Blockchain state
   • Is the app able to detect temporary forks of the blockchain?
   • Which is the current application state (versus the current blockchain state)? How is it synchronized?
5. User perception
   • How can the user trust the app? In case of the wallet application, it might send money to somebody else (developer of the app).
   • How can the app be designed both understandable and easily usable by a regular person that does not know anything about complicated cryptography and blockchain processes?

We conclude with some architectural patterns/solution concepts that might be useful when tackling the questions and challenges we have outlined:

1. Asynchronous communication patterns
2. Event based UI design
3. Elaborated error handling (compensation logic on failed transaction)
4. Central synchronization server for different devices
5. Error detection as early as possible (first client-side verification, then server-side verification, finally blockchain-side verification)
6. Use an abstraction layer: Present a business-case-related view to the user that abstracts from the actual technical concepts on the blockchain (transactions, cryptography, …).
   Bitcoin wallets, for example, display the current Bitcoin balance to the user. However, technically, this value is nowhere stored on the blockchain, but is calculated from the total value of incoming transactions minus the total value of outgoing transactions.
7. Solid, trust-worthy UI-design

However, much more guidance is desirable and imaginable, but it requires learning from many new and innovative blockchain-based applications across the whole software-industry. Beyond architecting, there are more topics that need further guidance to come up with the desired blockchain-based applications:

• Coming up with innovative and creative ideas for new blockchain-based applications
• Designing the overall business model around blockchain-based applications
• Designing the legal framework around blockchain-based applications
• Designing the overall user experience around blockchain-based applications
• Creating and managing trust among the involved parties and stakeholders
• Handling quality assurance of blockchain-based applications

Further Sources of Information

The following resources are recommended further readings regarding the blockchain topic, besides the numerous links mentioned during the articles.

Xu, Weber, Staples: Architecture for Blockchain Applications

Fraunhofer Position Paper on Blockchain and Smart Contracts

Wesenberg, SATURN 2018: Blockchain Is the Answer. What Was the Question Again?