Blockchain-Structured Programming

Whenever a new programming paradigm is hailed it is more often of a blend of existing paradigms than being genuinely novel. For example, what do you get when cross reactive programming (Rx) with functional programming? Functional reactive programming (FRP), which is essentially a prescription without side effects.

Or acclaimed new paradigms are simply existing paradigms with a twist. For example, what do you get when you take procedural programming and eliminate side effects? Functional programming.

Sometimes such a twist may be a cynical corruption. For example, what do you get when take a pragmatic approach to functional programming, such as allowing some side effects? Pragmatic functional programming (a.k.a. procedural programming).

And so it is that cynicism and corruption bring us to the new kid on the block. What do you get when you cross the elegant and reasoned hierarchies of block-structured programming with the clarity, fairness and accountability of unregulated capitalism? Blockchain-structured programming.

In one sense, this blended paradigm represents a new mix, yet in another it can claim a long history. For example, pyramid schemes date back to ancient Egyptian times. The privateering (a.k.a. piracy, theft, government-backed enterprise) that kicked off Europe’s imperial age popularised pieces of eight as a currency. In modern computing terms, the division of a byte into pieces of eight results in bits, hence Bitcoin. Another crypto-currency, Ether, is named for the insubstantial and fictitious medium that, in the 19th century, was believed to propagate light.

Naming offers many insights: Litecoin is named for its lack of financial weight; PotCoin is dope; and Namecoin has yet to be named – as developers know, naming is hard. As for blockchain itself, although the term clearly describes a list structure, it also seems to double up as the seed word in a word association game, to which the most obvious response would be flushplunger .

In traditional computer science, algorithms and data structures are described in terms of performance costs. Insertion into a conventional linked list has a cost of O(1), for instance. A similar theme underpins blockchains, but the measures are more generous. Insert a record into a list using a cryptographic hash and you can be talking a cost of 1 MWh. Indeed, the costs are so severe that instead of using IDEs (Integrated Development Environments), blockchain-structured programmers favour DIED (Doing Insertions with Environmental Destruction).

The energy consumption of Bitcoin, for example, is on a par with that of a nation like Switzerland. But unlike Switzerland, which uses its utilities to support a well-regulated banking system, CERN and chocolate, Bitcoin has so far eluded utility. Often touted as a currency, it behaves more like a speculative asset – mostly, people speculating as to whether or not it’s actually an asset. The specific mechanism in Bitcoin that has proven so costly is its proof-of-work algorithm (POW, see also Prisoner of War ). Proving that Bitcoin works has taken more time and energy than expected – unlike rigorous, reasoned and environmentally neutral high-energy physics experiments, it’s not going well.

Data structures in the blockchain world have many superficial similarities to more conventional data structures. For example, instead of lists having a head , they have a blockhead . The same word substitution can also apply to those who head blockchain companies. Classic singly linked lists, such as found in Lisp, are often created using cons . This is the same in blockchain-structured programming.

There appear to be many operators in blockchain-structured programming, but many seem to have dubious reputations – cryptocurrencies have proven surprisingly popular in the kinds of international trade frowned upon by less entrepreneurial individuals hindered by decency and morals.

Perhaps one of the most popular operators is the exchange operator. Where exchange and swap are similar in conventional programming, in blockchain-structured programming an exchange involves gambling with speculative assets cryptographically, whereas the swaps market involves gambling with speculative assets without the assistance of cryptography. Exchange operators are therefore defined on Bitcoin-set as opposed to bit-set structures. These are often password-protected by a charismatic founder (or head , see above) who may drop dead at any moment – cryptonite that adds a certain frisson to chaining one’s finances to blocks. In such cases the underlying architecture of a distributed, tolerant and anonymous ledger model is considered ironic.

As with any programming paradigm in the 21st century, blockchain-structured programming addresses distribution and concurrency. Blockchains are inherently distributed and their transactions make much more sense if you drop ACID. Concurrency is typically addressed through smart contracts. As with most other things labelled smart , they’re not, and still accommodate many classes of error that programmers have come to expect – even demand! – from their concurrency models, such as race conditions and re-entrancy problems. Being able to have a race fits well with the competitive ethos of blockchain-structured programming.

We can conclude that underpinning many cryptocurrencies is a simple design pattern: the Blockchain of Irresponsibility. Blockchain-structured programmers are quick to counter that the inefficiencies and lack of accountability inherent in many cryptocurrencies and blockchain models should not be used to judge all blockchain applications. They contend that blockchain is a good solution, albeit one in need of a good problem.