Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Establishing Trust in a Blockchain Ecosystem

DZone's Guide to

Establishing Trust in a Blockchain Ecosystem

Learn about areas of trust in a blockchain ecosystem, and how to establish trust so that stakeholders will be willing to join and use it.

· DevOps Zone
Free Resource

The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.

Areas of Trust in a Blockchain Ecosystem

A blockchain architecture gives participants the ability to share a ledger that is updated, through peer-to-peer replication every time a transaction occurs. Peer-to-peer replication means that each participant in the network can act as both a publisher and a subscriber. Each node can receive or send transactions to other nodes, and the data is synchronized across the network as it is transferred.

Image title

A blockchain network is economical and efficient because it eliminates duplication of effort and reduces the need for intermediaries. It is also less vulnerable because it uses consensus models to validate information. Transactions are secure, authenticated, and verifiable. As such, a blockchain can be thought of as a software platform for recording and storing transactions and tracking the movement of any asset across a supply chain.

Testing Approaches for Establishing Trust

A supply chain using a blockchain can only be successful if stakeholders are willing to join and use the blockchain ecosystem.  This means they need to trust the blockchain fabric, they also need to trust that smart contracts will operate correctly, and they need to trust how other stakeholders develop and deliver applications that may interact with the common blockchain fabric.

Software quality is essential and there are several testing approaches for establishing trust within a blockchain network:

By consensus - In a business network where participants are known and trusted, transactions can be verified and committed to the ledger through various means of consensus or agreement, including the following:

  • Proof of stake: To validate transactions, validators must hold a certain percentage of the network’s total value.  Proof-of-stake would provide increased protection from a malicious attack on the network by reducing incentives for attack and making it very expensive to execute attacks.
  • Multi-signature: A majority of validators must agree that a transaction is valid.
  • Practical Byzantine Fault Tolerance (PBFT): An algorithm designed to settle disputes among network participants when one participant in a set generates different output from the others in the set.

Whatever the method of consensus, data is appended to a ledger, and for a tester, this means establishing the validity across multiple stakeholders. It also means testing against the existence of third parties and the impact of new parties joining the blockchain ecosystem - both in terms of data flow and performance.

Service virtualization can be used to switch the API interaction of components both off and on to simulate the impact on a blockchain ecosystem. Scenario tests can be run with these parties in different states to understand the impact. When a party is added back into the ecosystem then a large short term data update may be required to bring that node in synch with the rest of the blockchain ecosystem.  This could impact the performance of the blockchain. The speed of consensus (and maybe the completion of consensus) may also be impacted by nodes not interacting with the blockchain as well as any applications interacting with the blockchain.

By APIs - A blockchain can emit events, a blockchain might call out to an external system or events from external systems might trigger a blockchain activity. For example, a transaction is submitted to an API. The transaction is validated against specific rules, an update order is agreed upon and a blockchain is updated and distributed. Lastly, a confirmation is received via an API that the blockchain has been updated. Projects need to test the interaction of applications into and from the blockchain ecosystem at each step. Most blockchains use REST based APIs.

By functionality - Smart contracts are code that is executed with every transaction.  It assesses the transaction against rules before allowing it to be entered for consensus.

So the blockchain consortium (which could be a regulatory body) need to test the execution of the behavior of the contract.  This can be done against a dummy blockchain because it is only the behavior that needs to be tested and not the pervasive data.  Smart contracts code the rules that are assessed for each transaction before the consensus algorithm decides where the data from the transaction should be appended to the data chain.  The smart contract requires functional testing.

The stakeholders and users of a blockchain may be humans interacting via a user interface or a system interacting via an API. For client applications the fact that it is interacting with a blockchain is irrelevant and typical UI/UX functionality testing applies. What will be different is the test environment which may be a dummy blockchain or a virtualized service representing data going in or coming out from a blockchain.

By performance - Performance testing needs to be considered from the perspective of an end user of the client app, the system interfaces and the response from a smart contract if applicable. It should also be performed against the execution service provided by the blockchain fabric, in order to assess the impact of multiple failures of, or completions of, data consensus and updates across nodes. These scenarios are influenced by data, location, and latency. Automated performance testing is required to assess the scalability of the blockchain ecosystem for all these scenarios. End-to-end scenarios need to combine all aspects across the blockchain ecosystem and should include compound testing with multiple endpoints.

By security - One of the key differences between a blockchain ecosystem and a messaging exchange is that all stakeholders on the blockchain are contributing to the integral security of the same data and "network." That is the nature of consensus. Beyond the security of the blockchain, private cloud stakeholders need to assess the security of their individual applications interacting with the blockchain.  For regulators or consensus bodies, the execution of smart contracts that will be embedded into the execution of every transaction on the blockchain, are a potential route for issues and need validation. The challenge to ensure the integrity of an ecosystem with multiple applications and end points can only be addressed with automated security testing.

Software Testing Considerations for Establishing Trust

In line with thinking about blockchain as a software platform, blockchain has carved out certain roles of expertise that mimic traditional development roles. Blockchain developers are responsible for writing smart contracts and client-side applications to invoke smart contracts. Blockchain testers have the experience with traditional processing platforms and data sources and create new tests as these systems integrate with blockchain events. Blockchain operators manage member permissions and security. Blockchain architects are concerned with resolving business concerns and making design tradeoffs. Establishing trust in a blockchain, aka guaranteeing quality, is the responsibility of all these roles across the blockchain team.

With the advent of DevOps, the role of the tester is changing. Traditionally, testers create and execute tests trying to find defects in the code. With the DevOps approach every role has responsibility for quality. Running tests becomes simply the continuous testing step in the automated continuous delivery pipeline. The tester's role on the DevOps team becomes one of a mentor – the person that selects the testing infrastructure, maps out the test strategy, and is an advocate for looking at the overall quality picture from both the business and user/customer point of view.  This change in focus requires a change in culture.  Today the QA professional not only requires some testing specialties but also requires a knowledge of software development and the business domain.  A culture of quality requires emphasis on the performance of the continuous delivery pipeline creating the feedback loops that inform the team of quality and security issues in a timely manner and be willing to experiment, take risks and learn from failures.  The best strategy for continuous testing means testing as early as possible using production-like environments (shift-left), include testing as part of every deployment process (shift-right) and execute continuously during the life of the project (automation).

Summary

Blockchain is a shared, immutable ledger for recording the history of transactions.  Trust in consensus is fundamental for the overall integrity and consistency of all blockchain network transactions.  Blockchain stakeholders are independent, yet need to develop for, and trust, the blockchain ecosystem.  Continuous testing is essential for establishing trust – testing APIs, and performing functional, performance, and security testing.  With DevOps, the role of testing and quality is changing to become the responsibility of the whole team.

Further Reading

Continuous Testing for Dummies - learn how to automate the right set of tests and simulate what’s missing to reduce costs and speed delivery of high-quality software.

Blockchain for Dummies – understand the fundamentals of Blockchain in this short guide.

The DevOps Zone is brought to you in partnership with Sonatype Nexus.  See how the Nexus platform infuses precise open source component intelligence into the DevOps pipeline early, everywhere, and at scale. Read how in this ebook

Topics:
blockchain ,devops ,software testing ,continuous testing

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}