Can Applications Communicate Over Blockchains?

The author Benedikt Herudek pushes the frontiers of decentralized systems in describing how Turing Machines can communicate over Blockchains.

We will suggest introducing Turing Blockchain Machines, using Blockchains as a Turing Tape. Turing Machines are a simplified yet powerful Model for Computability and the every-day life programs we design and use. We introduce them as a ‘Gedankenexperiment’ on an abstraction of Blockchains as Turing Tapes with specific features to try to answer the question, if applications could communicate over the Blockchain.

This endeavor is connected to the question, how far we can push Software Decentralization and with them human relations and society organized by them? Decentralization is a promise because the Implications of using Technology in the way Bitcoin does, suggest it is possible to defeat large cartel-like organizations, which sit right and accepted in the middle of society.

Technology does have a liberating power if designed right: kicking out ‘middle-’ or ‘highwaymen’ is one of them.

The question raised here (we are not ready to give an answer) is a connected precursor to the vision to endow Blockchains with a ‘Turing Complete Language’. Such Blockchains, foremostly Ethereum aim to have ‘programmable money’ and want to allow decentralizing any application logic, (not ‘just’ money).

The approach suggested here aims to have any kind of signal (not ‘just’ money) exchanged via Blockchains, such that it is clear ‘what it means’. Both approaches have in common to attempt to generalize Bitcoin‘s Blockchain approach.

Ingredients of decentralization

If you purchase a good or a service from someone, who doesn’t happen to be your neighbor or a family member, you typically need these three ingredients.

1. ‘Money’ and an accepted way to pay, like cash or electronic payment
2. A common nomenclature as a basis for agreeing what you buy and the seller sells
3. A governance framework to ensure you get what you ordered, you pay what you received and can dispute if appropriate

One form of trade trading over the Internet, private-public key cryptography and browsers are practically indispensable but taken as a given here. When you want to decentralize trade in this sense you need

Regarding (1): Bitcoin. Bitcoin solves the double spending problem with a distributed System and a ‘hardened’ Ledger based on the proof of work mechanism

Regarding (2): we can solve this problem if we can prove that Turing Machines can teach each other languages over a Blockchain. This is the focus here.

Regarding (3): Turing Complete Blockchains, e.g. Ethereum. If we can establish

smart contracts which are distributed, verifiable and ‘unstoppable’ we have a good chance to digitalize and decentralize important and relevant parts of governance

Above listed ‘smart contracts’ realm is sometimes referred to as ‘Internet of law’ as opposed to ‘Internet of money’ referring to Bitcoin and other digital currencies. In the digital realm you can easily imagine one get music files delivered, based on cryptocurrency payment was done or certain conditions (amount of clicks on your post) are fulfilled. Where conditions and delivery lap over into the real world (like delivering a book after you successfully ran a marathon) currently it takes a bit more imagination (and IoT, sensors and maybe even Artificial Intelligence) to imagine the general working of such smart contracts.

Note that questions like ‘Can Machines teach languages’ or ‘Can Machines understand each other’ are rather ‘fuzzy’ questions. They can easily lead astray into questions like ‘Can Machines Think?’ With Chomsky and others, it is important to realize that these questions are ultimately questions as to which metaphor one wants to choose. A better way is to reuse Alan Turing’s approach and try to formalize the question such, that it can be answered.

Half way decentralization

Imagine you ‘don’t mind’ a translation layer as described above in (2). You only mind (1) the decentralized payment and (2) a Turing complete language as part of the Blockchain. Then, you set out to build a new kind of marketplace, a ‘decentralized eBay’ on top of it. Your infrastructure and your payment are decentralized, still, you will end up with a ‘large monolithic application’.

Even on decentralized platforms, for applications, some kind of organization has to define the rules, e.g. how to offer and purchase goods, which data formats they need to use and so on.

Everyone will have to abide the rules that ‘decentralizes eBay’ set up. Even if the founders have best intentions to not monopolize the process, centralization will have to happen because of the basic architecture of the System.

A typical answer to this centralization on the Turing complete Blockchain is the so-called ‘Decentralized Autonomous Organization. The idea is essentially the organization defining all rules needed to run the applications, is itself democratic and decentralized.

But however well intended and efficient a Decentralized Autonomous Organization would be, it is still an institution to force parties into agreements on how applications should be set up. The more successful a DAO is the less an individual voice will count, the less autonomy there will be and the more centralized the DAO will look to the individual.

Seeking Decentralization in rich applications on top of a decentralized turing complete platform will lead to centralization on the Blockchain.

The ‘trick’ to avoid this ‘successful DAO dilemma’ is to not place entire Applications on an immutable Blockchain. Rather, only the transactions that concern Communication between two parties should go to the Blockchain and only on those (but not on the entire Application Logic) should parties have to agree. To allow innovation you need to give autonomy to their applications and force them under agreements on the shared Blockchain, only where absolutely necessary. You want to keep your network dumb, allow autonomous edges to run innovation.

With ‘decentralization’ we foremostly target towards certain effects on power and social relations we would like to see in the real world, like e.g. making banks unnecessary for payment traffic and central banks obsolete for monetary (specifically inflationary) policies. Technology is an enabler only and technically, decentralization these days is typically implemented by a Distributed System with a consensus system, to ensure there is just one truth in spite of many copies of the shared database. If you stress values like ‘autonomy’, ‘resilience’ or ‘simplicity’ in your system you could with some right also claim that paradigms like ‘Service Oriented Architecture’ or ‘Micro Architectures’ should be seen as part of the Decentralization Paradigm. Those are architecture patterns, describing how Systems can communicate while being decoupled. They are typically mentioned in an enterprise context and do not have the privilege of carrying the subservice odor of Bitcoin but they certainly are architectures carrying the possibility to not build ‘huge monolith blocks’, which is really just another expression for ‘not Centralizing’. Some describe Microservice as Service Oriented Architecture without the so-called ‘Enterprise Service Bus’. This is the Integration Layer, which tends to take over a lot of logic like routing and translating different nomenclature. How ‘smart’ you want to design your network and how much logic you want to put into it, is a recurring theme in designing Systems and can have surprising effects, what power relations Systems can implicate.

Of course, there are legitimate usages of a turing complete Blockchain, e.g. for the Internet of Things. Nothing stops one (e.g. if one prefers DAO’s over conventional companies and that does hold a lot of promises) to rewrite known applications on a turing complete Blockchain. However, for the context we are looking at it, turing complete Blockchains main usage would be to - one fine day-(semi-) automate governance with smart contracts.

Automating Translation

Here is why you should care about (2), the translation layer: Your main reason, why Amazon or Ebay has a website you go to, is that it allows you get in touch with the creator or owner of something you would like to have. It allows you to pay (1) and when you paid, it gives you a governance framework (3) to ensure the process (like shipping) works for you because there are legal frameworks behind both the platform and the vendors offering their goods. Somewhat hidden is the fact that the platform delivers a significant (2) ‘translation exercise’ for you. That would be obvious if a Spanish person offers a good offered over eBay by a Chinese person and both only speak English. The platform just sets a common standard (English), how these people can interact. But that would be just the UI surface, the platform itself sets all kinds of standards that enable interaction: The vendor has to accept a certain User Interface and with that, a certain data format prescribing, how the article pictures and descriptions are rendered. That Data format to offer goods then works perfectly with the data format prescribed by eBay to purchase goods, which is the format working ‘under the hood’ when you press the order button. Ebay, in fact, acts as your translator, you have to pay for that. This might be more obvious if we think through this situation in a B2B context where companies would offer and order good via message Systems, automated and without a User Interface. The messages to offer goods would need to be matched with the messages wanting to buy goods. Someone needs to translate these messages into each other.

Typically this just happens via the man in the middle setting a standard. This is the common way these days to establish common terminology allowing applications to talk: per definition. In a typical enterprise, if you want two applications to talk to each other, you make a design, where both parties agree with which messages eg in formats like JSON or XML they will communicate. Whoever went through this, knows this can be a painful process and doesn’t make your projects ‘exactly agile’. On a broader scale, you will have entire bodies with the goal to set standards, like eg the World Wide Web Consortium. Many have good intentions, but the necessary effort and time for meetings and achieving agreements is not a healthy environment for fast innovation. Worse, there are ‘information-cartels’, whose business model eventually depend on establishing and dominating standards allowing people to connect. Ebay and amazon would dominate, even if we would all pay with Bitcoin and even if they were rebuilt on ethereum and ran as a DAO. But all they do is make sure technically people get in touch with each other.

Establishing a common nomenclature per definition is not only stifling innovation it also opens up the backdoor for monopolists and decentralization.

A different way of establishing communication could be to use an approach similar to how we translate natural languages with machines like google translate, essentially we just have a look at how so far parties communicated and draw our conclusion for the future. One could easily imagine building a general machine translation ‘google translate for apps’: all kinds of messages connecting different Systems would be fed in, working translations (typically initiated by humans via above described ‘definition’ approach) would be used to bootstrap the engine and then a self-learning ‘google translate for apps’ would be set up to translate message formats into each other. With the size and clumsiness of the Application Integration Business, it is a surprise, enterprises didn’t use Neural Networks to widely automate this part of the Application Integration Business, just as a decade ago cloud computing started automating (in the sense of ‘hiding from the client’) hardware setup.

Even more so because you don’t have to come up with fancy neural networks to predict, how some Systems will communicate. You could just say if two applications are part of the same industry, they probably use standard XYZ, if they are from the same vendor they probably use standard ABC, if similar Systems have used message formats 123 before for similar cases these two fellows might need just the same, maybe you can parse an XML and reassemble it with some other names and the target system will ‘eat it’. Sometimes a ‘nice & long if then statement’ is just about right.

But doing trade predicting future terminology based on the past just isn’t good enough in many circumstances. Sending Bitcoin over the Blockchain and establishing smart contracts on platforms like ethereum is a binding agreement, which absolutely cannot or should not be changeable: immutability leaving no room for disputes is the cornerstone of such use cases. If you inject now a level of uncertainty as to what your terminology was really supposed to mean, you open the backdoor for irrefutable disputes Imagine Application A sends a message, B takes the translation from an Integration layer, reasoning (‘messages XYZ usually mean in other contexts ABC for applications like me’) and delivers an expensive good. Now, A can always claim ‘well, you misunderstood me. The fact that in cases before the message XYZ translates into ABC doesn’t hold here. I want my money back.’

Predicting future translations based on past successful translations isn’t good enough for Blockchains and the level of trust and binding agreements to base smart contracts on them.

Another way of thinking of this is the following thought experiment. Imagine, a Mars-UFO lands in Amsterdam, Central Station. It’s an unmanned ship, but there is a pretty smart Computer inside. We want to communicate with this device. Connect it to the best and super-trained machine Language Integration layer. It will deliver no results, because saying that our ‘earth-machines’ communicate in ways XYZ, doesn’t mean anything for ‘mars-machine’. Even if we think we ‘understand’ the machine (with an assumption as ‘there are only so many ways how digital systems can operate’), we never really know, if we understand the machine correctly.

Now, if ‘setting standards’ stifles innovation, fosters centralization and ‘predicting based on the past’ isn’t a safe enough bet, one way out of the deadlock could be machines teach each other the language, unambiguously and retraceable over an immutable Blockchain, with which they will transact.

Talking Turing Machines

A ‘Blockchain Turing Machine’ is a conventional Turing Machine with the following specifics:

1. The Blockchain is the shared Turing Tape. There is one machine sending, while the receiving machine is attempting to detect the state machine table of the sending machine
2. More general, in a Blockchain Turing Band, we will have several participants talking to each other. For our purposes, we will just consider one pair of sender and receiver
3. Machines can never erase fields, that is for one direction when they move they can only read but not write. This is reflecting the Blockchain immutability feature.

State Machines would be any Applications behind an address, which write transactions onto the Blockchain to communicate with other Applications. There would be no Turing Complete Language, the endpoints, however, could have any Turing Complete Language and any rich features they like. The logical translation and communication layer would be connected to layers for payment and governance, the latter potentially turing complete.

Here is a simple example, Bit Inversion. The Sender holds a State Machine with the Following State Table.

The machine will first read the symbol under the head, write a new symbol accordingly, then move the tape right, before repeating the read-write-move sequence. After every instruction, there is a new machine state. As soon as the machine reads a blank symbol, the machine terminates.

The current symbol under the head is 0.

so we write a 1

and move the tape right by one square.

The symbol being read is now 1, so we write a 0

and move the tape right by one square

Similarly, the symbol read is a 1, so we repeat the same instructions.

Finally, a 'blank' symbol is read, the program tells the machine to stop.

If, in any case, the Receiver can ‘figure out’ the state table of the sending Turing Machine only if the Sender presents ‘all he got’ (operations, symbols) within a fixed time limit. With that in mind, our question is:

Can we describe a Blockchain Turing Receiver Machine, that is capable of noting down any Blockchain Turing Machine Sender state table unambiguously while watching all the Senders operations and symbols on a shared Blockchain Tape?

If this is the correct question, then one way of investigating is going over the numerous theorems proven over Turing Machine to see what they can contribute. Some other interesting questions to investigate could be:

1. Are Blockchain Turing Machines (no erase possible) useful
2. Do we need to restrict the language types (e.g. along the Chomsky hierarchy) sending Machines can use to make translation for the receiver possible
3. Are there languages or certain statements that can in principle not be translated unambiguously?

We will not discuss those but ask, how we could interpret a ‘yes’ to the question we ask. My conjecture: It means ‘quite a bit’. Take a Computer Program that essentially ‘figured out’ what another Application does, of which it ‘just sees’ some messages. It means this program ‘knows’ what these signals mean and can, therefore, initiate appropriate action. Now, it’s a quite a leap from the Turing Machine sparse notation towards a full Web or Enterprise Applications sending JSON or XML message (‘Clients want a uber- ride Berlin Brandenburger Tor to Tiergarten right now’). But that’s the beauty of Turing Machines, they are simple but can simulate essentially ‘anything’ you need in the digital world. Note also that Applications absolutely do not need to know everything about each other, lots of the typical application logic (how the app works to order an Uber ride, what internal states are saved, how the UI works) is entirely irrelevant to the trading partner (the individuals offering the ride application): Only the transactions counts and that is often much simpler than the entire application producing the message.

Having such a Blockchain Turing Machine Translation Mechanism (transforming a Blockchain into a ‘Babel-chain’ if you will), would have considerable advantages over the above-listed Mechanism to connect Application. The Mechanism wouldn’t offer any ‘wiggle - room’ and no room undue transaction fees. Take the approach, where we assume Application ABC ‘probably meant that’ because similar applications ‘meant that’ in ‘similar cases’. You can’t base important transaction on that unless a human checked it. Because whoever ordered, could always argue there was a misunderstanding, and in this case, the machines cannot just conclude from the past to the future. If you involve humans to review Machine translations or simply set standards for communication from the beginning, you will have all the disadvantages that ‘middlemen’ bring along, best studied with the example of Banks: They will want a share of your transaction, even though they add little value other than facilitating a transaction. They tend to inflate their importance beyond their due position.

If you can automate the translation between Machines and run this over a public and immutable Blockchain, you leave no room for misunderstandings no backdoors as to what ‘was meant’. Everyone can check the ‘understanding handshake’ and the language the two machines agreed upon for their transaction. There is no place for humans or organizations taking an undue tax on your producers and consumers transactions.

After the terminology is agreed, the transaction itself goes into an immutable and verifiable Blockchain, payments and governance can be processed.

If we can’t make turing machines teach their language we need to revert to one of the two other ways to make machines talk. Agreements can work, the internet, for example, is widely build on accepted standards like http and smtp - it works, but it is hard to imagine how you could get monopolists agree to standards today. Making a prediction based on past experience can take us far but also only so far as to the binding character we would like to see on Blockchains. A hybrid approach could be another interesting option, where you agree for example on an algorithm to generate translations based on past working translations. And the agreement is that whatever a certain algorithms spits out, will be the agreed message format.

Request for Comment

Decentralization is the task of relieving us of the ‘middle-man’ tax. Gain and fame should be with the producers of goods and much less with cartels dominating trade - just like banks should have a serving, not a dominating role in the economy. Technology allowing true peer2peer transactions with no room for centralisation can play a liberating role. Avoiding centralisation in Networks implies placing the rich application in autonomous endpoints of the network. Doing this requires making ‘Applications talk’ such that there is no human intervention required and certainty over common nomenclature. Asking the question, if Turing Machines can communicate over Blockchains is a way of trying to push the frontiers of Decentralised Systems.