A lot of industries are experimenting with the technology Let’s look at some of the benefits that blockchain can bring to specific types of business:
What SpectraMind Would do in Blockchain Test?
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/Availabilityalso 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 SpectraMind 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.
What Types of Tests and Techniques Can SpectraMind Perform on Applications Built on Blockchain?
There are many different types of tests that can be performed at the various stages of developing software projects. Below are a few types of tests that can be utilized to ensure a high level of test coverage and quality for blockchain applications.
Unit Tests
Unit tests help developers ensure their code is performing correctly at the lowest levels and smallest parts of functionality. This should always be the first line of defense to ensure an application catches the majority of bugs early during development.
Integration Tests
Integration tests help developers and test engineers ensure the communication of their code between different components, and possibly between internal and external systems like databases.
User Interface
User interface (UI) testing uncovers how the application works from the end user’s perspective. It’s important to ensure that you carry out UI testing to make sure their experience is positive or that they at least get the correct feedback from the application when it doesn’t perform well.
Application Programming Interface
Application programming interface (API) testing gives you confidence that you’ve validated the responses that your application receives from external APIs and makes sure the formats of your API requests are correct and being handled correctly.
With blockchain applications, there is also a similar type of technology to APIs that allows you to adopt the same testing practices for APIs. These are called smart contracts.
Blockchain Testing Tools we Work with @ SpectraMind
There are some pretty good tools and frameworks being developed that can help with both development and testing.
We also Offer
For more information on our Blockchain test solutions : pls email : info@spectramindsolutions.com