This post is part of a three part series on the fundamental pillars of Blockchains: start here to read the introduction.
Blockchains typically provide some facility for computation by participant nodes. This is a critical feature to be considered and well specified during the planning process. In fact, this is probably the most important part of a blockchain specification project.
In Bitcoin for instance, the specification is designed mostly to allow the movement of coins between addresses. Every node that reads through the blockchain processes the money movements and individually validates
- That the money movements are initiated by the proper account holders.
- That the accounts are properly funded to initiate the money movements.
Why is this done in a distributed way, requiring each node to perform the action? It's a form of discipline embedded in the system that protects from bad actors. If the chain allows arbitrary participants (and even so-called 'permissioned chains' often do), how do you determine if an action is allowed? The solution in blockchain-land is two fold:
- Require all participants to run the same code in a 'transaction' without error
- Require results of the code to be the same for all participants
If the code distributed follows the rules laid down in the system, it will be executed, and then embedded into the chain. If it does not follow the rules, it won't go in. If the code does something funny, and works differently for different nodes, then the nodes will be unable to agree on the results of the code, and they will do something else (based on the rules the blockchain itself has set up.)
In a way, this just sort of pushes the problem of bad actors around on paper a bit. It doesn't mean bad actors can't try and act. But it does mean you get to take the possible actions they could take and confine them to a set of rules.
Bitcoin took a very conservative approach to this, and made its list of possible operations any actor could request very limited. (In technical terms, the Bitcoin specification's language is not Turing Complete, a measure of computer language expressivity.) Later blockchains have been chipping away at this limit.
Ethereum, for example allows Turing-complete code to be run, forcing actors to pay a certain amount of currency in order to essentially provide a bond that their code won't run horribly amok. Once the code has run long enough, or taken enough memory, it is forcibly halted, keeping participants safe.
I would generally recommend a very limited, discrete set of computational actions to be specified. To the extent that these are simple and easily enforceable, the security of the chain is greatly enhanced.
At the same time, there is some art to choosing the computational actions. Pick a good architect, and if you don't have a good in-house blockchain person, make sure to get one in to review the plan before embarking on a lengthy development process.