Experimenting with Chaos Engineering and Blockchain

1. How to create and verify a blockchain transaction
2. How experiments in CTK can be incredibly powerful tools for both testing and automation

git clone //github.com/yolannel/CTKBlockchain

pip install -U -r requirements.txt

Experiment 1: Understanding Rollbacks, Immutability and Stable States

• Node - user or computer within the blockchain architecture (each has an independent copy of the whole blockchain ledger)
• Transaction - the smallest building block of a blockchain system (records, information, etc.) that serves as the purpose of blockchain
• Block - a data structure used for keeping a set of transactions which is distributed to all nodes in the network
• Chain - a sequence of blocks in a specific order
• Miners - specific nodes which perform the block verification process before adding anything to the blockchain structure
• Consensus (consensus protocol) - a set of rules and arrangements to carry out blockchain operations

Often described as 'spreadsheets in the sky' - these present a really unique way to use Chaos Toolkit. The goal of this experiment is to check that a chain exists and can be called after a simple transaction. No rollbacks should be supported since a blockchain should be immutable. To test this here's our first experiment:

{
    "version": "1.0.0",
    "title": "Can we make a new transaction?",
    "description": "The system should respond to a transaction request.",
    "tags": ["tx"],
    ...

    "steady-state-hypothesis": {
        "title": "Chain exists",
        "probes": [
            {
                "type": "probe",
                "name": "chain-exists",
                "tolerance": 200,
                "provider": {
                    "type": "http",
                    "timeout": 5,
                    "url": "//127.0.0.1:5000/chain"
                }
            }
        ]
    },

Actions vs Probes

Probes can help you to check the system state, but actions introduce new information or a change to the system being tested. For example, checking that the chain exists is a probe but creating a new transaction is an action.

"method": [
        {
            "type": "action",
            "name": "make-new-transaction",
            "provider": {
                "type": "http",
                "timeout": 1,
                "url": "//127.0.0.1:5000/transactions/new",
                "method": "POST",
                "headers": {
                    "Content-Type": "application/json"
                },
                "arguments": {
                    "sender": "me",
                    "recipient": "new-other-address",
                    "amount": 20
                }
            }
        },
        {
            "type": "probe",
            "name": "check-chain",
            "provider": {
                "type": "http",
                "url": "//127.0.0.1:5000/mine"
            }
        },
        {
            "type": "action",
            "name": "mine-block",
            "provider": {
                "type": "http",
                "timeout": 3,
                "url": "//127.0.0.1:5000/mine"
            }
        },
        {
            "type": "probe",
            "name": "check-chain",
            "provider": {
                "type": "http",
                "url": "//127.0.0.1:5000/mine"
            }
        }
    ],

Finally, we reach the rollbacks! When designing an experiment, you should be aware of the capabilities of your system and also what it should be able to do.

For example, I could include code in my blockchain.py file that allows a user to delete a transaction which hasn’t been mined yet; however, this would violate the operation of a blockchain because blockchains derive trust from immutability.

A software production rollback is simply the returning of a codebase to an earlier, more stable version. If you are curious about the execution workflow that would typically result in a rollback, you can understand those conditions from the . Then the snippet that usually handles rollbacks is simply:

"rollbacks": [
    ]}

Running the Transaction Experiment:

$ python blockchain.py

$ chaos run testTransaction.json

Understanding Decentralized and Distributed Consensus

Centralized, decentralized and distributed network models by Paul Baran (1964), part of a RAND Institute study to create a robust and nonlinear military communication network . 

1. We should ensure that the chain exists on two separate nodes.
2. Simulate activity.
3. Check the chains exist still.
4. Resolve the chains to identify the global truth.

{
    "type": "action",
    "name": "simulate activity",
    "provider": {
        "type": "python",
        "module": "os",
            "func": "system",
            "arguments": {
                "command": "python -c \"import activity; activity.run(100)\""
            }
    }
}

Running the Consensus Experiment

$ python blockchain.py --port 5000

$ python blockchain.py --port 5001

$ chaos run testConsensus.json

Some Key Takeaways

1. The Chaos Toolkit tests what states are actually possible for your system, so that is context specific - walking through this tutorial, you have seen how the experiments should be tailored to how the system should work (in this case, no rollback options).

2. On an even more abstracted level, the CTK is an automation tool - note how the consensus test essentially automates a lot of usage and then checks. This actually makes it incredibly powerful even if you aren’t specifically running a chaos experiment because there is a set process that you create which is replicable. Think of experiments as blueprints for what you want to try!

Diving into blockchain with experimentation is a great way to flex your mind around immutability and stable states. If you have any questions or would like some insights into similar topics, find us at Reliably on Hackernoon.

This Chaos Engineering with Blockchain tutorial was developed by . The blockchain tutorial linked in the beginning was developed by Daniel van Flymen.