by Benedikt Herudek
Machines can’t (hardly) communicate
One classical form of Machine to Machine Communication can be found in Enterprise Integration. Consider the case of a CRM and Billing System in a Telecommunications enterprise. Client orders are taken in with the CRM System. After the Order is fulfilled, the Billing System will be responsible to generate a bill. Both Systems (in fact there are many more) know the concept of a Client and of Products, but they have different ways of talking about them and their internal Data Models differ.
Communication between Applications is often done with the help of Middleware and so called Enterprise Service Bus. These Applications render infrastructure with the necessary features around security, performance and stability. An important part of such centralized message brokers is that they handle the translation between the Applications. Often, they use a central translation layer, a generic language for concepts that both Applications know (the ‘customer’) and over which they have to exchange information. ‘
With the rise of the Internet of Things, the problem sometimes takes often the form, that devices have different message Formats but need to be able to communicate, e.g. the iPhone needs to be able to take over from remote controls and talk to all TV’s. The scenario is sometimes referred to as the ‘Baskets of Remotes Problem’ describing the situation we find in many households, where there will be one remote for any device like Television or sound machine, but none of those remotes is able to speak to any other device than the one it was initially designed for. There are at least two reasons, why the question of machine communication will be even more prominent in the Internet of Things.
For one, there will be much more devices and hardware in the Internet, potentially with many different standards. In many cases, we might also have long living devices, which work with standards that current vendors don’t support any more. Second, many devices are directly exposed to the end user. End users neither have the skills nor the tolerance to tweak devices into common standards or set up intermediary translation layers like enterprise middleware often offers them.
It is interesting to see, how Bitcoin approaches what in traditional terms we might call Integration of Endpoints. If you like you could see wallets and miners as endpoints in a large network. Bitcoin is able to integrate such endpoints like wallets and miners in a large distributed network seamlessly without any integration effort.
If you ever opened a wallet on your smartphone and see a a wallet as some kind of application and if you ever worked on a project connecting for example an Enterprise Application into a network, you might find it surprising that you are able to make your application talk to a large distributed network within minutes. Bitcoin achieves this by flipping around the notion of Transactions and Applications. For Bitcoin, the Transactions (Blockchain) are permanent, while the endpoint, the wallets is derived.
A Bitcoin wallet is not an account holding a permanent value, rather it deducts the Bitcoins the owner of the private / public masters from the transactions in the Blockchains.
The ‘broken’ Standard Solution
In spite of flipping this notion around, Bitcoin does something very conventional. It simply mandates the use of certain data formats, only if you read and write ‘Bitcoin Blockchainish’ can you participate in the network. That is the right approach for a limited (even though very important) set of use-cases like financial transactions. Existing Integration patterns often follow the same pattern in dictating a message exchange format, often relying upon industry or vendor standards.
A ‘Bitcoin & Blockchain’ minded spirit might want to see here something similar to a (broken) trusted middleman solution. Instead of trying handling the issue directly, peer2peer one reverts to a 3rd party, so to say a trusted middle man that can oversee both sides and mediates and settles between the two. There are some well known problems with reverting to such standards. First of all, there might be none, then there might be too many, then who ever sets the standard, especially a large vendor, might try to dominate an area.
We can see these problems in any ‘incarnation’ of the problem of machine Communication, be it in Enterprise Integration or in the Internet of Things. An important point to realize is, that what seems to start as a technicality (how to translate message formats into each other) in fact opens the door to centralization, data monopolists and closed networks. That is because, if a community like a social network or an online app store is large and offers end users and companies, that they can seamlessly communicate to anyone within this closed networks, then this closed network delivers a major value to joiners and will attract even more joiners, who don’t want to be left out.
There is little use in 1-2 person social networks, the larger it is and the more entities are reachable via it, the higher the value is, the more users will be attracted and the more they will be willing to pay. Data exchange formats and more generally speaking Machine Communication lies hence at the core of many information monopolies we can see these days. Standards are not only a ‘clumsy way’ to solve the issue, they also offer leverage to monopolists.
A Decentralized Approach
Blockchains are essentially transactional Systems, which allow with the help of cryptography and peer 2 peer networks to have transactions immutable. In many respects they are different than an existing transactional Middleware, however also for them there is a question how they approach data message exchange formats.
Not only will there be different applications communicating to Blockchains, also will there be many different Blockchains, which communicate to each other. The suggestion we want to make is that Blockchains – instead of following the ‘look for standards’ solutions – should allow senders and receivers to interact peer 2 peer and incentivize network members to deliver the service they need to have to communicate. Those specialized network members would not only deliver the virtual infrastructure for communication (like for Bitcoin), they would also play a major role in translating different message formats on the application layer into each other an enable communication without standards.
Instead of using Miners to create Blockchain features we want specialized network members (referred to as ‘Translators’ in an overall System referred to as ‘Babelchain’) to translate message formats and enable Communication, while also producing a version of immutability in the resulting Transaction log.
Roughly, we want to try to pursue the following analogy in the rest of the paper.
The effect of a resulting System would be that we eliminate the the needs for standards and hence also those parties that (ab-) use this to create monopolistic structures. What Bitcoins tries to do to Banks, this Technology tries to do to closed networks.
Proof of Work – Consensus on Transactions
The so – called ‘Proof of Work’ algorithm is at the heart of Bitcoin’s Security Model. Security for Bitcoin is foremost the fact that the transaction log can for all practical purposes after a short time not be changed again and that is an indispensable feature for a finance transaction System, where we want to avoid that someone could spent the same Bitcoin twice. The ‘clou’ – if you will – is that Bitcoin achieves this without restricting any access to its payment system.
Anyone can open a wallet and participate in the network and no matter how malicious a participant wants to be, he will not be able to overcome the System. The typical approach of nearly any System dealing with sensitive transaction would be tp restrict access, introduce Identity Management and monitor, audit and if necessary exclude players from the System. Bitcoin doesn’t do any of this and still comes up with a remarkable stable Algorithm.
The ‘proof of work’ algorithm achieving this relies on hash algorithms. A hash algorithm takes an arbitrary-length data input and produces a fixed-length deterministic result. One metaphor to visualize this is the notion that a hash algorithm takes a unique fingerprint of a dataset, a fingerprint that for any practical reasons only this specific dataset can have and a fingerprint which is so interlinked with the dataset it reflects that any, even tiny change of one bit in the dataset will cause the fingerprint to look entirely different.
Bitcoin uses what is called a ‘nonce’ as this but that can arbitrarily changed by miners to try to impact the resulting fingerprint. The fingerprint allows no reverse-conclusions as to how the input dataset might have looked like. It looks truly random – but its not. For any specific dataset, the fingerprint computed will always be the same. Another important feature is that that the fingerprint can be easily and undoubtedly verified to result from of a specific dataset.
All one will have to do is processing the dataset through the hash algorithm in question and check the resulting fingerprint. For any hash function for any practical purposes we can make the assumption that it is impossible to find two different inputs that produce the same fingerprint.
This has an important implication: It is also virtually impossible to select an input in such a way as to produce a desired fingerprint. Hence, the only way to achieve this would be to try random inputs until one generates the desired fingerprint. Bitcoin’s ‘Proof of Work’ draws heavily on this feature by demanding that certain fingerprints must meet certain standards, for example to be smaller that a certain target see. This makes it difficult to ‘get the job done’ and that is exactly what Bitcoin wants to be the case, because this is its way to create an immutable Blockchain.
Bitcoin wraps this in a process called ‘Mining’. Mining is essentially the way you get someone to execute this task, the way to incent him. Because if someone achieves the goal set by Bitcoin, he will have a good chance to receive the mining reward, which corresponds to a number of Bitcoin representing a certain value. Technically, Mining is the process of hashing the block header repeatedly, changing one parameter (‘nonce’) , until the resulting hash matches a specific target.
The hash function’s result cannot be determined in advance, nor can a pattern be created that will produce a specific hash value. Hence, the only way to produce a hash result matching a specific target is to randomly modifying the input until the desired hash result appears by chance.
Bitcoin requires hashing the block header because the block header describes a set of transactions, that the Miners gathered in the distributed network. Hence, if you secure the block header in the sense that you cannot easily revert it, you achieve your goal of having transactions immutable.
Now, not only does Bitcoin make Mining artificially difficult with introducing a difficulty target, it introduces an additional ‘trick’ that would make it very difficult to revert transactions after a couples of blocks were added. That, as we remember, was the whole point of the exercise, to make the Blockchain immutable after it was recorded.
The “previous block hash” field is inside the block header and thereby affects the current block’s hash.
The child’s own identity changes if the parent’s identity changes. When the parent is modified in any way, the parent’s hash changes. The parent’s changed hash necessitates a change in the “previous block hash” pointer of the child.
This in turn causes the child’s hash to change, which requires a change in the pointer of the grandchild, which in turn changes the grandchild, and so on. This cascade effect ensures that once a block has many generations following it, it cannot be changed without forcing a recalculation of all subsequent blocks. Because such a recalculation would require enormous computation, the existence of a long chain of blocks makes the Blockchain’s deep history immutable, which is a key feature of Bitcoin’s security.
Now, miners or the companies they run them know all these difficulties when they would try to cheat. Hence, their reasoning will be and actually is: its best to play fair and just try to with this hash computing so we can add a transaction to the Block that will send some Bitcoin to us.
That is the whole point, the algorithm is set up such that playing by the rules will be more advantageous than trying to cheat the network. The consensus on the state of transactions is achieved implicitly by miners choosing the longest chain, where most computing power is already lined up. One can use metaphors to approach and understand this mechanism. One common way to think about the Blockchain is for example to think of it as layers in a geological formation.
The surface layers might be changeable, if you wish, but once you go a few inches deep, geological layers become more and more stable. There would be more to say e.g. about so – called 51% attacks where one miner controls the majority of the network and could adjust transactions.
We won’t dive into this but summarize what matters for our discussion Important to realize is that the work Bitcoin demands is useful only for creating security, there is no other intrinsic value attached to hashing used here other than making the Blockchain immutable. The difficulty of the work is artificially created by (1) hashing against a difficulty target and (2) linking fingerprints such that change of one parent will create a cascade effect and demand redoing younger hashes.
More…..
To delve deeper into the paper, please see the rest of the report ‘Babelchain Machine Communication Proof of Understanding’ here (PDF) – which is part of the Blockchain News Library – where some 164 papers and reports are located (and free to read and download).
