But first, let‘s ask what the potential upside is to implementing these auditable blockchains to various industries. Supply chain is one obvious area. Supply chain often suffers from different endpoints having different systems involved with tracking; imagine if an item can move cleanly from system A to system B without fear of transaction flaws that could place it in both or neither system due to time lags or breakdowns between systems. Imagine money transfers that can be instantaneous without “waiting to clear”. Imagine a service outage by a bank or retailer where the customer still has access to account balances, transaction receipts, and shipping status through the independent ledger. Perhaps the applications for purchase/transactions could be independent from the company, so their system being offline would not impact business. Or election voting records that are tamper-proof despite being electronic.
SAP, the marketshare leader in ERP solutions, is integrating blockchain capabilities into their products. SAP is developing Project Leonardo (which specializes in IoT) to use blockchain. Citing that the World Forum predicts that 10% of global GDP will be stored in blockchain by 2027, they define blockchain as a reliable, difficult-to-hack record of transactions – and of who owns what, based on DLT, which securely records data across a peer-to-peer network. SAP Ariba, which focuses on supply chain, is also getting into the blockchain game.
A lot of industries are experimenting with the technology, and one city (Dubai) is pushing to becoming the world’s first blockchain-powered government to utilize the technology for all documents and transactions by 2020. Let’s look at some of the benefits that blockchain can bring to specific types of business:
But how does one go about testing this new technology, and what are the limitations we have to deal with? This is not a comprehensive list from an actual project – this is me thinking out loud about some considerations I would certainly want to include. If you’re a tester, this will seem familiar, otherwise, it is a good introduction to the testing mindset. Keep in mind that blockchain has a much broader scope than Bitcoin, so Bitcoin factoids may be more constrained than blockchain factoids. Let’s take a walk through my thoughts about various concerns:
Block size: Less than 100 bytes of a block is spent non-payload. For Bitcoin, there is currently a fixed maximum limit of 1MB per block. For its first 18 months, the average block size averaged under 30KB. Now, in the beginning of December 2017, the average size hovers around 1MB. What happens if the amount of new data going into a block exceeds the maximum block size – how is it handled? Keep in mind that multiple transactions can be buried inside a single block. In August of 2017, the Bitcoin Blockchain had a ‘hard fork’ to address 2 different approaches to start tackling the scalability problem. One side (mostly miners) wanted bigger blocks and now has an 8MB max instead of 1MB, while the other (mostly users and developers) wanted a better compression algorithm (Segwit) while keeping the 1MB max. However, the cash on each side of the fork is different — Bitcoin (BTC) vs. Bitcoin Cash (BCH) – and attempts to transfer between different sides of the fork will destroy the funds, but pre-fork history belongs to both sides. But there still seems to be a trade-off in these two – Bitcoin is more secure, but Bitcoin Cash transactions take less time. It has yet to be determined how having block sizes beyond 1MB and/or using better compression algorithms will pan out, but it demonstrates that the original Bitcoin constraints on blockchain blocks do not limit blockchain in general.
Chain size: There should not be a limit here, so it may be fun to test block creation functionally and performance-wise as the chain lengthens. https://blockexplorer.com/api/status?q=getBlockCount can tell you the current count (almost 500,000 as I write this). It is possible for the chain to get temporarily broken, if 2 miners unknowingly simultaneously arrive at two different valid solutions for the same block. After a short period of time, the peer-to-peer network will resolve these splits so that just one branch of the chain will survive.
Load: Bitcoin’s blockchain currently has a maximum throughput of 3-4 transactions per second (with a theoretical max of 7 under perfect conditions), with new blocks to hold transactions create about every 10 minutes. Compare this to the transaction/second loads needed to handle Ethereum (20), PayPal (193), Visa (2,000 average but has gone as high as around 50,000), McDonald’s POS via AWS (8,600), and Alibaba on Singles Day, 2017 (256,000 average). The problem with blockchain is that speed drops when load increases, making scalability problematic. There is a DLT alternative to blockchain called Tangle, which is blockless, scalable and lightweight, helped by using trees instead of chains. It also requires no data miners to pay for processing. However, Tangle technology is pretty new, and the cryptography hashing was altered as recently as July of 2017 to fix a vulnerability that had allowed unauthorized forking.
Performance: How long does a query take if it must look at every block in the chain to research something like every time a specific account was touched? Is it like SQL queries, where phrasing things differently affects duration? This may involve integration testing which emphasizes the outer querying app more than the blockchain itself.
Consistency/Availability: According to the CAP theorem, there are only 2 possibly responses that a partitioned system can give: the most recent accessible piece of a chain, or the choice between the most recent piece of the chain or an error. Or in other words, if the most recent end of the chain is unaccessible (which is always a possibility in a partitioned system), do you throw and error or provide details from an earlier chunk? Let’s assume that waiting for the end of the chain to become accessible fails, and the system must choose between these two options: fail or reveal an earlier block. By the way, in a non-partitioned system, either the system is up or it isn’t – nothing piecemeal.
Collisions: We covered this up in Chain Size, where it should be possible to duplicate through automation to get the timing right, so you can ensure that the proper behavior occurs for 2 blocks that want to simultaneously get added. Consistency/Availability also presents another way to attack this “well, I seem to have this information for a block that I’m not sure where to put”, when the chain’s end is not available, again so you can ensure that the proper behavior occurs. Some limbo location until it can be processed? A split in the chain? A juggling act where the new one gets added to the last accessible block and the orphaned inaccessible block gets added back in later?
Security: Blockchain seems to appear in the news to either publicize the increased value of bitcoin, or the theft of bitcoin, raising the obvious question: is bitcoin safe? Multiple layers of security are built into determining identity. Unfortunately, once the identity layers have been hacked, the instantaneous transactions cannot be stopped. The multiplicity of keys may complicate theft, but ultimately, anything that can be entered can also be stolen, by weaknesses such as lackluster caching or tools such as sniffers. In terms of Bitcoin/Bitcoin Cash, there’s been a trade-off of security vs. transaction time. The tamper-resistant quality of security is built-in to blockchain (except for one company’s blockchain editing tool). I’ve also mentioned above about Tangle’s recent update to fix a security issued that allowed blocks to be altered without breaking the chain. Why hack a block? It could be a steal data (theft, which may include authorizing an unauthorized transaction), or it could be to edit data (fraud).
Data corruption: We talked about collisions that can interfere with testing earlier, so here is a specific cause of a Consistency/Availability root cause. What happens to the data in a block if a block gets corrupted? Is there a way to repair the block? Can the chain past the damaged block be reached?
How do you fix transaction typos: Correcting a block should not (but is) possible, with the existences of tools contradicting the immuteable qualities that make blockchain valuable. Otherwise, a newer blockchain entry must be added that voids or corrects the earlier mistake in the chain. Alternatively, a new transaction to adjust it back could be added.
CRUD testing query logic: In the case of supply chain or product recall or user activity, many records need to be properly parsed spanning multiple chains or multiple records inside a block or both. In the case of smart contracts, you may want to track all drafts of the contract, or pull the versions that were in force over a specific period of time. Testing should include both functional and performance.
Database handling: How is your tracking set to deal with unusual cases in supply chain management? What if something is damaged or goes missing? What if an item becomes 2 items (like a diamond that gets split)? What about 2 items becoming one (two 2-packs get damaged and the undamaged halves get combined into a new 2-pack)?
This is just the beginning of a list of potential testing for blockchain systems. Testing should go beyond just the blockchain portion and include integration testing that maps to the whole business process. I hope this exercise gives you helpful ideas on testing this new technology.
Research for this white paper included information from the following sources:
https://www.multichain.com/blog/2016/05/four-genuine-blockchain-use-cases/
https://en.bitcoin.it/wiki/Block
https://www.sap.com/products/leonardo/blockchain.html
https://www.ariba.com/about/news-and-press/sap-ariba-gets-in-blockchain-game
https://www.wsj.com/articles/dubai-aims-to-be-a-city-built-on-blockchain-1493086080 https://bitinfocharts.com/comparison/size-btc.html
https://en.wikipedia.org/wiki/IOTA_(technology)
https://www.huffingtonpost.com/ameer-rosic-/goodbye-corrupt-charities_b_13207806.html
