I've been thinking about a few aspects of smart contracts and blockchain tech - especially public blockchain tech - and I have some lingering doubts that I'd like to capture here for any of you to attack.

(With contributions from Sita Krishnakumar, Vishwas Bhushan and Manoj Kumar)

Some time back, I attended an event at Forrester@Bangalore where one of their senior analysts said something like "blockchain as a technology is different from cryptocurrency and you shouldn't confuse the two" - i.e.  he was trying to say that you can use and benefit from blockchain tech without participating in cryptocurrency markets. At least that was my interpretation of it. That's where I begin.

Below I offer a couple of theses to consider in this context. When reading this post, please remember that we have the freedom to be wrong in the labs team at Imaginea :)

Thesis 1: Blockchain as a tech cannot be decoupled from cryptocurrencies

At least in the context of public blockchains, I now think blockchain as a tech cannot be decoupled from cryptocurrencies. A public blockchain relies on untrusted parties participating in maintaining the integrity of the distributed ledger. Irrespective of the scheme they use to maintain their copy of the ledger and to interact with their peers, what is supposed to be their incentive?

Here are some possible reasons why such a party might participate in the network -

  1. Money - direct incentives. This means cryptocurrency and the markets
    around them.
  2. Vested interest in applications built on the blockchain. If a party
    has a number of applications built, then they may feel compelled to
    participate in the network just to have a say in what is important
    to them.
  3. Possibly malicious intentions to control a ledger's contents. In
    this case, running a node would be an investment towards controlling
    a network of interest.
  4. Other (this must always be factored in)

If we're looking at money, the thesis is already held. We know that in order to control a network, you need to dedicate considerable finances if you have malicious intentions. With some ingenuity thrown in, the cost could be manageable, but is still not particularly low for some of the major networks. If we're looking at vested interests as the dominant mode, then it seems to gravitate towards a "private blockchain" where a consortium of entities control the blockchain and the happenings on the network.

Bottomline seems to be that a node runner needs some incentive to participate in ledger maintenance - even the malicious ones must stand to gain something financially at the end of the day, while the ones with vested interests are trying to not lose financially.

So in all three cases, it is looking like a financial incentive underpins the motivations of the participants. This seems to require the incentive flow to be manifested as a currency in order for the participants to gauge their operations.

I'm extrapolating this to the "other" case by saying financial incentives MUST underpin those as well. If you accept that, then the thesis may be taken to stand - i.e. you CANNOT run public blockchains WITHOUT an attached cryptocurrency ... i.e. contrary to the analysts's statement, blockchain as a tech and cryptocurrencies are deeply coupled.

Thesis 2: Blockchain applications using smart contracts will degenerate into token networks

It's an all or nothing story. So all blockchain applications will degenerate into a token network with all business logic residing off chain. That means general smart contracts are (or will be) useless in the real world.

It has so far proven incredibly hard to get real world data on to the blockchain for most of the promised real world applications. As I've noted earlier in Blockchain Applications Must Be Closed Systems, the immutable and timeless nature of the data on the chain means all the data stored on the chain must circle back to the chain itself for validation. This is really really hard and something like Oraclize isn't a catch all solution - and it relies on centralized certificate authorities.

To see why it is hard, think of how to implement an insurance policy on the chain. It needs to be done in such a way that a policy holder cannot provide false claim information and that needs to be guaranteed by the blockchain. So how do you know that someone claiming a hospitalization amount was really hospitalized? You now need to roll in the hospital systems operations on to the chain as well. And then identity systems, medical equipment and so on, to such an extent that human intervention in the process is near zero. The validity of a claim shouldn't rely on the word of a desk clerk noting down your details on the computer system. If any of this is expected to not happen due to threat of legal action, then the whole premise of the blockchain tech serving to regulate without an authority falls apart, so you can't fall back to legal action.

Again, every system participating in the network must have already been "enrolled" on the blockchain somehow and must be secured on a continuous basis independent of the chain. For example, if requests and data are expected to come with a validating signature, the cost of bribing to get that signature must be prohibitively high - comparable to attacking the blockchain network - otherwise the system crumbles.

One degenerate solution to this problem of actually storing irrefutable data on the blockchain is to not store such external world data at all. This means the chain and the contracts on it only deals with the exchange of tokens, with all the real world action taking place outside.  In such a case, the chain serves as an irrefutable ledger of transactions without making any claims about their legitimacy or authority. Party A might have sent some tokens to Party B, but why would not be the concern of the network. It would just record that that happened. So a chain that only provides for tokens to be created and exchanged without any notion of "Turing complete" smart contracts would totally serve this purpose.

Interval: The next installment will be about permissioned blockchains.  Need to think a bit more about them as the concepts are more nuanced.


Sita - I think if you look at B2B examples, there are verticals where this can be implemented and would not require the entire sector involvement to begin with. Few players will pave the way for an industry standard to be achieved. Logistics, cargo shipping, original art management, music copyrights are few of the areas that come to my mind immediately.

  • Reply - That's the promise of smart contracts. So far, the promise hasn't been proven out is what I'd stated as part of the arguments to thesis 2. True that there are tons of folks working on these aspects, but I'd like to see one case marked
    "solved" and take it up for further analysis. Also, the mechanisms by which the trust problems can be solved for each of these domains is, I think, idiosyncratic. If you look at the trust problem as split - a) establishing trust and b)
    maintaining it - blockchain tech can take on (b), but (a) requires domain specific tech. Given that, it is also worth questioning whether blockchain is the only tech that can solve (b). The import of both the "theses" put together, for me, is
    that in all these areas, we'll see blockchains that work with token systems exclusively without embodying real world data on the networks - i.e. "blockchain as a secure database" is moot.

Vishwas - I do agree on the fact about public blockchain that, 'It can not be decoupled with token or crypto'. As there is no one in control of the network, the token economic will play a role to engage the user and maintain the network. And which is why applications like SteemIt - public
blockchain(steem) based content distribution platform, Blockchain cuties - ethereum based , Akasha Project - Ethereum based social networking
platform, Decent - another content distribution platform based on blockchain and few others(not coming into my mind right now), leverages the use of token economics to run the application.

Coming to the fact that, none of the companies are ready to bring real world data on blockchain because of current limitations that we have, but we should also look into the upcoming blockcahin developments/innovation. like for example, Ethereum is going to implement PoS (Proof of Stake) with its CASPER release and claims that it will solve the current scalability issue that it has, EOS has already implemented DPoS (Delegated Proof of Stake) and released which is also considerably fast and they all are public blockchains. And with implementation of these consensus the problem of high resource utilisation (for mining) will also gets solved. All these data tell us at least one thing, that innovation in blockchain is going on and will definitely evolve in future.

Current market trends : As far as my understanding is, most of the clients are willing to invest on permission-ed and consortium blockchains rather than going for public ones(because of all those complexities which you pointed). As Sita mentioned, use cases like, supply chain, original art management, music copyrights and even finance/payments will fit either into permission-ed or consortium.

Reply - My theses are not about the viability of blockchain from an implementation perspective. My argument is independent of, for example, how the consensus is established or how fast it is established. It is a statement about the purely deterministic aspect of smart contract validation.

I haven't thought through the permissioned blockchain use yet, as stated at the beginning.

Manoj - We hear lot of discussions about how Block-chain technology is trying to solve some of the security issues. In the process of trying to answer the questions you put forward, came across Sovrin-Network which claims for providing
decentralized public utility for Self-Sovereign identity.

  • Reply - Yes, web standards are also coming to capture such claims. Also ZKP based systems seem to be interesting in this context, though they increase the overall complexity of the systems they touch. These are one more level of abstraction that lay users cannot verify for themselves.