Skip to main content

7 posts tagged with "blockchain"

View All Tags

· 4 min read

In Part 1 of this post, I discussed a particular example - that of decentralised Uber to decipher if a decentralised Uber makes sense, or in general is decentralistion always better?

In this post, we will explore some the theoretical basis of the argument.

Braess's Paradox

Braess's paradox (often cited as Braess' paradox) is a proposed explanation for the situation where an alteration to a road network to improve traffic flow actually has the reverse effect and impedes traffic through it.


You can find the complete explaination of this example here. I will just suffice to say that the total commute time from Start to End is lower if there is no link from A to B vs when there is. It would be better if a rule is laid down that only a certain number of people are allowed in the road A to B. Keeping it open to independent choices of everyone produces an outcome which is sub-optimal to everyone

Decentralisation is not a value in itself

I recently came across a very interesting tweet by Simona Pop of Bounties Network.


There is no inherent value in decentralization. What decentralisation enables is of value for some people or in some contexts. Does it make people more efficient? Can theynow do things which government or regulators didn't want them to? Does it give them more control of their lives? These are the questions which actually matter.

Democracy vs Dictatorship

In context of nations, the tradeoff between democracy and dictatorship is very similar to that between decentralization and centralization.

Though nations have much broader and varied goal, compared to organizations. For example, companies have a clear metric of creating more shareholder value.

What are the metrics on which decentralised organizations should be judged? Is it the value accrued to network participants?

How much value can be assigned to network participants not getting censoured - which is one the key benefits of decentralised orgs.

Countries' metric can be GDP, GINI coefficient or the happiness level ( Bhutan actually uses this metric)

Historically, Decentralisation always emerged as a response to restrictions in centralised systems

Here's a great post which talks about the rise of decentralization in context of mp3 file sharing. The author points that decentralization always arises in response to the law when a certain use of centralized technology is denied.

A quote from the above post which sums this beautifully

Ask yourself, what can some people not do on centralized systems which they should be able to do? If you look closely, you might be able to spot informal strategies people are using today to get around the rules, and these could help inform what to formalize into a protocol.

What do people really want?

I think the key question is - What do people really want? Are they OK with sacrificing some privacy and freedom for better user experience and less effort.

If we try to reason with organization of states, most states have high level of centralization. US, China, Russia are some examples which come to mind. Direct democracies in comparison have been few and has only worked for fewer states.

Other advantage of centralization is that it concentrates power on the top layers. These people want to increase their power - leading to more alliances, subjugation or attacks - ultimately leading for the organizations to be more powerful.

Similar dynamics can be seen in corporate orgnizations. The profit motive actually helps them become bigger and concentrate more power. This drive is lacking in decentralised organizations.

Urusula Le Guinn in her book The Dispossesed portrays this beautifully. The book talks about a society born out of anarchism, an extreme form of decentralization. These people establish a society from ground up in a new planet. What was interesting was that even in this anarchist society points of centralization emerged. For example, people were given names by a centralised computer systems. Important people controlled means of production and media. The book is a great portrayal of the dichotomy between centralization and decentralization.

The emergence of miner centralization, high level of control by developers, etc. point to this phenomenon in current crypto ecosytem. It emerges primarily for better coordination and efficiency.

This begs the question:

Isn't the inherent tendency for people to strive for power a deterrent against decentralization? And what has fundamentally changed in the last few years which would tilt the balance towards decentralization?

· 6 min read

Many people come to me ask about how they should proceed to become a developer in the blockchain space. I thought it would be a good idea to put down my thoughts in a post so that I can easily refer people to this.

As many of you may be aware, blockchain and cryptocurrencies are the craze these days and everybody wants to understand what they are all about. IMO, the current interest is overhyped. Blockchain is not the solution to every problem we are facing today. But to discard them as just another hype would be a mistake. At the least, it warrants a careful examination of how they can change the world.

To me, blockchain represents a fundamental way in which we think about cooperation and trust in society and are a foundational technology. Maybe it will not have any significant impact in the short term (1-2 yrs), but it will significantly alter the tech landscape in medium to long-term (5-10 yrs).

So, if you are really interested in this space, think for the long-term

Now let's get to the question of how can one start to learn about this space and become a "blockchain developer". I am assuming that you already are a developer/ have capability to code but in some other domain. Maybe you are an Android dev or a react dev or work on any of the other myriad technologies out there.

The beauty about this space is that most of the exciting development in blockchain space happens in open source. If you want today, you can look into the source code of bitcoin and figure out how it exactly works. Of course, you need to be able to understand the source code written by other people, which is not trivial.

Github repos for popular projects

Bitcoin Ethereum HyperLedger

Also, the blockchain and crypto community is very open and most of the discussions happen over Github issues, telegram groups, Reddit or mailing lists.

To get started, you have to get a broad understanding of what is blockchain, how its different from traditional technology, what is consensus, etc. You need not understand all this in great detail, but you should have a hang of it. In my opinion, starting with Bitcoin and Ethereum are the best way to learn about all this. For the first 15-20 days, just leave everything else and try to understand how does bitcoin and Ethereum work and what are the various concepts involved. Don't get into coding yet, as that is the simpler part and would be easier once you have the basic concepts sorted.

The best resource for learning these concepts is

It has lots of explanatory videos and articles. It is more focused on bitcoin but does a good job of explaining the basics.

Once you are done with this, head on to Ethereum Github and digest its white paper

This repo also has a lot of good resources on blockchain aggregated in a single place.

Now, to become a developer you need to understand that there are primarily 2 types of blockchain networks.

**1. Permissioned networks

  1. Permissionless networks**

In permissionless networks, anybody can go ahead and start a node and start mining blocks and participate in the network. Good examples of such networks are Ethereum and Bitcoin

In permissioned networks, only those people who are authorised can run a node which contributes to the network. Such networks are more suited for business use cases, where a business or different parties involved in a business run nodes for the network.

The important thing to note here is that the identities of these nodes are known and everybody in the network knows who is running a particular node. This makes the job of achieving a consensus much easier. If you want to run permissioned networks, HyperLedger is a good project to follow.

From a developer perspective, there are few opportunities in this space:

  1. Build permissioned networks for businesses

Many businesses are trying to understand how they can use blockchain in their use cases. For example, a car manufacturing company may want to use blockchain for their supply chain. Such business use cases, mostly need a permissioned network as the nodes who will operate in the network are mostly known.

Hyperledger Fabric is a good protocol to develop permissioned networks. To get started, go through its documentation. Its decently well explained and should give you a good foundation to start with.

  1. Build decentralised protocols

A lot of research goes into the different type of protocols which are used by the blockchain. Things like which consensus mechanism should be used, what should be the tradeoffs between scalability and trustlessness and how the incentives for different players should be aligned.

These are the sort of things which core developers of Bitcoin and Ethereum worry about. For getting involved in such work, you need to have strong CS and Math chops. You can start getting involved with building protocols by contributing to the Bitcoin or Ethereum project and build your way from there.

  1. Build dApps on existing protocol

The third kind of thing which you can do is to focus on building dApps and smart contracts. dApps are Decentralised Applications which run on existing protocol. Ethereum is the easiest way to get started on this. Ethereum uses a language called Solidity which is similar to Javascript and any frontend developer can easily try to start dabbling in it. Solidity also has a great documentation which can help you get started.

This is also the domain of ICOs. Most Ethereum based ICOs need a smart contract which encodes the logic of their platform. So developers can get projects developing smart contracts for clients who want to do ICOs.

Apart from Ethereum, there are many new protocols which have come up like Stellar, EOS, etc. Each protocol has made its own set of trade-offs which makes it suitable for particular projects. But I would suggest if you are just starting in this field, start with Ethereum - as it has the highest number of devs working on it and most simple queries you may have can easily be solved by searching on Google or StackOverflow.

Dedicated StackExchange for Ethereum Dedicated StackExchange for Bitcoin

While trying to learn about blockchain, keep in mind that development for decentralised web (blockchains, etc.) is very different from the standard centralised development which most developers are used to. So, in the early days, you may have to break your head trying to get an intuition for how it works. But don't get disappointed and lose hope.

Blockchain community is very open and helpful and if you are stuck in some place, just ask. Post it on relevant forums on Reddit, telegram, StackOverflow etc. and I am sure somebody will help you.

All the best in your learning journey! Give a shout out to me on twitter if you need any help.

· 7 min read

The consensus problem in distributes system is an age old problem. A strong form of consensus problem can be defined as follows:

Given a set of processors, each with an initial value:

  • All non-faulty processes eventually decide on a value
  • All processes that decide do so on the same value
  • The value that has been decided must have proposed by some process

These three properties are referred to as termination, agreement and validity. Any algorithm that has these three properties can be said to solve the consensus problem.

Now these faulty processors can have 2 types of faults.

  1. Crash faults - Where faulty processes just stop. They don't act any further.
  2. Byzantine faults - In this case, we don't assume any thing about the faulty processes. These processes can behave aribitrarily. They can send wrong message, correct message to some and false message to some, lying, deceiving, anything is fair game.

If the processes only have crash faults, then achieving consensus is relatively easy. We can be sure that all messages we get are from correct processes as the processes which are faulty don't send any messages. Systems which only tolerate crash faults can operate via simple majority rule, and therefore typically tolerate simultaneous failure of up to half of the system. If the number of failures the system can tolerate is f, such systems must have at least 2f + 1 processes [1].

While if the processes can be Byzantine, they can send incorrect messages or correct messages to some and incorrect messages to others.Byzantine nodes are special in the sense that they can do any arbitrary thing (lie, deceive, etc). This lack of any assumptions about the nodes is very powerful and this is the reason why this problem is so interesting.

For solving for consensus in presence of crash faults, simpler algorithms like Raft and Paxos work. But these algorithms don't work in presence of Byzantine faults.

The problem of consensus with Byzantine Faults is discussed in Leslie Lamport's paper on Byzantine General's Problem. A solution for this was also proposed by Lamport, a good discussion about which can be seen here.

The problem with this algorithm is that it's a very costly algorithm. Leslie Lamport's solution to Byzantine General Problem requires O(nm+1) message transmissions where n is the total number of nodes and m is the number of byzantine nodes such that n>3m.

Practical Byznatine Fault Tolerance

Practical BFT is a consensus algorithm proposed by Castro and Liskov which solves Byzantine General's Problem in a more efficient way. Practical BFT requires O(n2) messages to achieve consensus in presence of Byzantine processes.

pBFT involves 3 stages in normal case operation

  1. Pre-prepare
  2. Prepare
  3. Commit

Screen-Shot-2018-07-21-at-7.03.46-PM Fig 2. Normal case operation of pBFT

pBFT algorithm (as described in the original paper) solves for consensus in case of classic distributed systems. Though this has been adapted for blockchain based systems like in case of Hyperledger Fabric and Tendermint.

One important thing to keep in mind is that pBFT based consensus works only in case of permissioned networks - where the identity of nodes is known. Anyone can't just join these network. The operation of the algorithm is based on the identity of nodes being known.

Blockchain helps in achieveing consensus in distributed systems as it groups transactions in blocks in order to amortize the high commit latency (on the order of ten minutes) over many transactions. Also, linking blocks via cryptographic hashes into an immutable chain, makes it easy to verify the historical record (via Merkle proofs).

More in section 3.3 of this thesis.

In next section we will talk about Tendermint in more detail.


Tendermint was one of the first consensus algorithms to adapt pBFT for blockchains. Tedermint consensus algorithm is used by Cosmos Network.

Screen-Shot-2018-07-21-at-4.56.53-PM Fig 1. Basic description of Tendermint protocol

Tendermint involves 3 stages

  1. Propose
  2. Prevote
  3. Pre-commit

Once the above steps are done then the network moves to commit stage.

Why does pBFT need 3 steps?

Similar reasons as need for 3 stage for Tendermint explained below

Why is a commit stage needed in pBFT? StackExchange Thread

Why a 3 step protocol is needed in Tindermint?

A single stage of voting allows validators to tell each other what they know about the proposal. But to tolerate Byzantine faults (which amounts, essentially to lies, fraud, deceit, etc.), they must also tell each other what they know about what other validators have professed to know about the proposal. In other words, a second stage ensures that enough validators witnessed the result of the first stage.

As the primary can be byzantine, it may not send the request m to some of the honest nodes and the nodes in that case will not reply. But in that case, 2f+1 votes will not be obtained? - Or f faulty nodes and f+1 honest nodes vote for the message.

Why is a primary needed in pBFT?

Primary comes in handy to arbitrate the order of requests (Miguel Castro's talk - link in reference)

Leaderless Consensus Systems

Paxos proposes a consensus system without a leader, but it is more complex than a leader based system. So, key reason for having a leader based consensus system is the relative simplicity of design and reasoning about the consensus system.

Tendermint vs pBFT Reddit Discussion

  1. Tendermint executes one consensus instance at a time (in PBFT there are several parallel instances), as this is more appropriate in the context of blockchain systems.
  2. Tendermint (similar to Raft) has simplicity as one of key design decisions. There is no difference between normal case and view change phase.
  3. Tendermint is optimised for gossip based communication and is designed for high number of nodes (hundreds). Messages in Tendermint are of constant size and does not depend on system size, contrary to PBFT View-Change message that contains 2f+1 signed Prepare messages and that depends on system size.

Tendermint vs Casper Reddit Discussion

Tendermint was a bonded proof-of-stake specification before Casper.

One major reason why Ethereum didn't adopt Tendermint as its PoS was because Tendermint would halt when >= 1/3 of the voting power disappears. Tendermint favored consistency while Casper was designed to favor availability in case of network partition (CAP theorem) and that was the original point of philosophical departure.

Designing Fault Tolerant systems

When designing fault tolerant systems, 3 key properties should be kept in mind (Stackexchange Thread)

1. Crash or byzantine failures

Should the system be designed to withstand nodes just stopping to do anything (i.e. no messages at all) or should it also consider nodes which exhibit arbitrary behaviour?

2. Eventual or strong consistency

Should the system provide certainty, that some state is final and not revertible or are we okay with irreversibility with high probability?

3. Open or closed membership

Is it known in advance (and to all nodes) who is participating in the protocol? E.g. a reliable database used by google has a defined number of nodes, which are known to all other nodes. In Bitcoin it is unclear even how many miners are participating in the consensus algorithm.

For the most well known consensus algorithms, the properties are:

Bitcoin / Ethereum: Byzantine failures, eventual consistency, open membership RAFT / Paxos: Crash failures, strong consistency, closed membership PBFT / Zyzzyva: Byzantine failures, strong consistency, closed membership

Now there are two basic results in distributed systems which determine the trade-offs for a consensus system. These are CAP theorem and FLP Impossibility.

CAP Theorem

Otherwise called ‘Brewer’s Theorem,’ CAP theorem states the impossibility of simultaneously satisfying more than 2 out of 3 guarantees in a distributed system: consistency, availability, and partition tolerance.

Facing DDoS, Tendermint stops

FLP Impossibility

The FLP result shows that in an asynchronous setting, where only one processor might crash, there is no distributed algorithm that solves the consensus problem.


  1. Miguel Castro explaining pBFT

a. Practical consensus (without Byzantine nodes)

b. pBFT (with Byzantine nodes)

· 4 min read

I recently did a tweetstorm on applicability of blockchains in supply chain. Here's an unrolled version:

1/ Nowadays, blockchains are peddled as a solution to many problems. But quite simply they are nothing more than distributed databases - with one important difference. There is no central party which operates/controls these databases.

2/ Blockchains can only be useful in cases where there are multiple parties and there is a problem of trust. i.e. neither they trust each other nor there is a central third party which everyone trusts. If any of these conditions are not true, blockchain is not needed.

3/ One particular case which many people tout as a good use case of blockchains are Supply chains. Somehow its intuitive to people that blockchain should help here. Coz’


a. Supply chains are complex and involve multiple parties

b. There are almost always problems of trust. You can’t expect disparate suppliers to trust each other, can you?

Isn’t it obvious that blockchains should help in supply chain?


5/ Well, it’s not that simple. Blockchains do not “know” anything about the physical “wet” world. So, somebody/something needs to push that data about the “real” world on the blockchain. And this is where the problem starts.

6/ How do we know that the data being pushed on the blockchain is accurate?

In a supply chain, generally, data about containers are pushed on the blockchain by IoT sensors. Data in the blockchain is as good as the reliability of the sensors.

7/ What if a sensor on a container has been tampered with? Or the sensor is removed from the container and attached to some other container? Blockchain can’t do anything about this. There need to be other methods to control this. Anti-tampering solutions.

8/ Though what blockchain can help in is that - the data stored in the blockchain can’t be censored. If there are multiple parties operating the blockchain network, any rogue operation will be visible to all the parties running the nodes.


9/ This is a big improvement over centralised databases like SQL where the admin of the database or the admin of the server can make changes in the database without anybody knowing. Or the admin can can prevent specific entities from writing to the database (because there's only one copy and he is the incharge of it). This is censorship and this is what blockchain prevents.

10/ The key problem is that there is no unique way to identify a container digitally apart from the sensors/tags/codes attached to them - and these tags can easily be replaced/removed/tampered with.

11/ Unless… Unless the item itself has a unique digital fingerprint. In that case, tracking the item on blockchain makes sense. Diamonds, for example, are said to have a unique laser reflection fingerprint.


12/ Or you have a physical lock on the object which can be digitally controlled. In this case, you must ensure that the gain for any attacker in breaking the lock is lower than effort in breaking the lock. uses such smart locks for renting things like cycles, etc.


13/ To conclude: Blockchains can’t provide product provenance in a supply chain. It is still the domain of sensors and how reliable they are. What blockchains can do though is that, if some data is stored in the blockchain - it can’t be altered.

14/ If somebody tries to alter it (basically attacks the blockchain), every other node in the supply chain will know about it and hence appropriate steps can be taken. Nothing more. Nothing less.

15/ So, next time somebody comes and tells you that blockchain can solve the issues in supply chain - please ask them how would they ensure that the data pushed on blockchain is not getting tampered. And then grab a beer :)

Thanks Nilesh for providing initial feedback on the post.

· 9 min read

Recently I have been attending a few conferences and meetups focusing on blockchain and its application. While its good that this technology is getting attention in India, I really believe that we need to do a better job at understanding this technology. Many times I come across propositions which intend to apply blockchain to something which doesn't really need blockchain. While part of this may be fuelled by the recent ICO craze, but mostly its lack of effort on our part to get into the depth and really understand what this technology entails.

Blockchain on the face of it is needed to prevent the problem of double spending in a trustless environment. Only when there are multiple parties involved and there is a problem of trust between them, does applying blockchain based solutions help.

Some points to keep in mind before applying blockchain to any system:

1. Blockchain is not needed for "immutability"

The use of blockchain as an immutable ledger is so well advertised that people think that just the use case of creating an immutable database is enough to justify using a blockchain.

But "immutability" is a nuanced concept which we will see below.

Designing atabases which are immutable by design is an age old concept. More commonly known as append-only databases, there have been many attempts to create such databases. Google's Big Query, RethinkDB and CouchDB created databases which were append only by design but they had to allow for garbage collection/updation as such databases blowup in size quickly. Datomic is an existing database which is append only by design. This allows for auditing how and where changes were made.

Here is a good discussion on immutable databases and a discussion on where such databases can be used.

The thing to keep in mind is that these append-only databases are not immutable if the admin can be an attack vector. As these databases are at the end of the day stored in hard drive of a central server, it can always be edited.

Content addressable datastores like IPFS can be used securely store data as in that case a file is addressed by a unique hash. If the data stored in the file is changed in any way, then it will no longer have the same hash. The only issue is that these hashes need to be stored in a secure way in a database and this introduces a vulnerability.

If you use blockchain, it gives you protection from the admin being an attack vector, as there is no single copy of the database which can be edited. The database is present in distributed nodes and the truth is determined by the consensus mechanism like Proof-of-Work, Proof-of-Stake, etc. and not based on what is written in a single node.

Thus, "immutability" is not a singleton concept but a spectrum. Depending upon what your attack models are and the level of data protection and trustlessness you need, there can be different solutions which serve the purpose, and are more efficient.

2. Its very hard to make blockchain work with the "Wet World"

Wet world here is referring to the physical/offline world. Things which are not digital are tough to be represented on blockchain in a non-repudiable manner. Blockchain operates in the world of bits, while the physical world is made of atoms.

Blockchain doesn't know about what is happening in the world. For example, there is no information on the blockchain if a particular team won a game or not. For this information to be available to the blockchain, there needs to be a service which pushes this data on the blockchain. Such services are called Oracles. Having trustworthy Oracles which pushes correct data on the blockchain is a non-trivial problem. According to Nick Szabo, trusted third parties are security loopholes.

Tracking items in supply chain on blockchain also faces this bottleneck. Since, the items which are transported in a suppychain are physical/"wet" accurately identifying them on blockchain is challenging. Generally such items are tagged with digital ID like RFID, barcode, etc. But it is easy to tamper with such digital IDs externally applied on an object. Unless the object itself has a digital signature (like diamond fingerprint, explained in more detail below), any external ID which is applied on an object can be tampered with or copied.

In a use case which we recently built, we wanted to track a crate of mangoes across different part of supply chain. We can do this by attaching a bar code to each crate, and tracking that barcode in blockchain. The problem is that, this barcode can easily be copied and attached to another crate. If there are no other checks and balances, this system will fail given that participants have enough incentive to fool the system.

There are some projects like which use locks on physical objects e.g bicycle to make them operable using smart contracts. Though how secure these locks are which can be operated digitally is an area of examination. If there is enough incentive, can't that lock itself be removed? Then there will be no way to track these assets on blockchain.

On the other hand, in cases where the object itself has a digital fingerprint, this problem doesn't exist. For example, in case of diamond, shining a laser light on it in a particular way produces a diffraction pattern which is unique signature of a diamond. This unique pattern can be hashed and tracked on blockchain.

Diamond Refraction Pattern Diamond Refraction Pattern

3.You don't need blockchain for tokenization

Recently I met a gentleman who was suggesting how blockchain will change the face of small businesses in India. Now, a Pizza shop can issue a Pizza Token(PT) and ask to be paid in them. His regular customers can buy the tokens and pay him in PT whenever they order pizza from him.

On the face of it, it sounds like a genuine use case. But when we dig deeper, it soon becomes clear that there is no need of a blockchain here. Even today Ola issues Ola money which is nothing but a token which can be used only in Ola platform. The company running the service (Ola) can issue tokens for fiat, which can be redeemed by token holders in the platform. In the process, some discount is given to users for using Ola Money.

Since, we are trusting the service provider, there is no need of blockchain here. This of course leads to issues where the service provider can arbitrarily change the number of tokens needed for a service, or there being no external market for Ola money tokens (at least no formal markets)

Of course, one advantage of tokens is that you can realise your revenue before actually providing the service - but since there is no external market for such tokens, there is no speculation and trading activity which happens in case of crypto tokens.

4. In many cases, centralised services work just fine

You don't need decentralization for everything. If you trust a service provider, there is no need for decentralization. Only when there are multiple parties involved, who don't trust each other, there can be a case of decentralised applications.

Decentralised networks also have their own problems. Decentralised networks are more resilient as they don't have a single point of failure. But they suffer from effects like Braess's Paradox Braess's paradox demonstrates how adding a new high-speed road in a road network can lead to more congestion, than without the new road. So, in some cases a central planning, which has view of the complete system, may make more sense than decentralised systems which don't have any global optimization function.

Scientists have also shown how decentralised power grids can also suffer from similar problems.

5. Centralised services will always have better speed and efficiency

If speed and efficiency are your main concern, blockchain based solutions may not be the ideal choice.

Visa averages around 2,000 tps, with a peak capacity of perhaps 50,000 tps Google currently processes 65,000 queries per second. By design, it is very difficult to achieve such rates for distributed networks

On the other hand, Bitcoin is limited to 3-7 transactions per second and Ethereum to 7-15 tx per second.

Here's a graph of transactions taking place in the Ethereum network

Ethereum transaction

So, around 700K transation are made on Ethereum everyday, which comes down to 8.1 transactions per second. At its peak, Ethereum network had processed ~1.3 mn tx per day, which is around 15 tx per second

Although there are efforts to scale these system for processing more number of transactions, they will never achieve the speed of centralised systems.

Ethereum is focussing on sharding to achieve high TPS while Lightning Network is bitcoins bet to scale the number of transactions processed by creating off chain channels.

Proof of stake protocols can achieve higher number of transactions per second as they don't involve miners but only validators. Ethereum's POS protocol Casper for example will have an expected time of 4s per block in starting.

If we assume that number of tx per block is same as current, which is 150 tx/block, then the throughput with casper would be 37.5 tx per second. This is much better than current state, but still leaves much to be desired.

Since, by design any blockchain based system would involve coordination cost between different nodes, which need to be sure that only authentic transactions are being processed by the network, they would be slower than a single server processing all the transactions. The benefit such network though provides is that of trust between nodes, which is absent in a centralised system.

Only in those systems where the benefits due to increase in trust outweighs the loss in speed and efficiency, do blockchain makes sense.

Thanks Nilesh for reviewing the initial draft of this post.

· 3 min read

Crypto world is booming and at the core of this is the consensus mechanism introduced by Satoshi Nakamoto called Proof-of-Work. Bitcoin is based on proof-of-work consensus mechanism.

The basic idea of proof-of-work is that the miners who mine Bitcoins and validate transactions can't just do this without any cost. They have to prove that they have solved some difficult crypto problems (finding SHA-256 hashes with specified number of leading zeros). Since the miners have to expend computing power in solving these crypto problems, they can't just add arbitrary transactions in the blocks they mine. The bitcoin consensus mechanism is designed in such a way that it is in miners' best interest to follow the longest chain and only validate correct transactions.

While the above description may sound like a lot of jargon, the underlying idea is pretty neat. It says that one can't be trusted for what one says, it has to be backed up by some work one has done to achieve it. In the case of bitcoin mining, it is the cost of electricity consumed in solving the crypto puzzles which lends credence to the miner. In developer parlance

Talk is cheap, show me the code.

What is the one thing which is dear in our lives? No, it is not money. Money can be earned by different mechanisms, but what can't be earned back once spent is Time

So, how can we trust what someone is saying? Ask them to show proof of what they have done about it. Have they spent any time of their life doing/working towards what they are saying. This can act as good way to filter a lot of noise.

A practical application can be found in the area of hiring. Many candidates claim that they are very interested in a company or a particular field, say marketing. The best way to test it is to come up with practical ways for them to work on it. If a company is looking for product managers, ask the candidates to do a small project for them working on an open problem which the company is facing. This would act as a good proof-of-work test. If the candidate actually spends time on it, then he is really interested in the job, otherwise not.

This approach is followed in many open source projects. Open source projects don't need you to pass an interview to start contributing in the project. You can just start contributing, and if your contribution is found valuable - then your code pull request is merged in the main branch - otherwise not. Your work is the best signal of your interest, not how eloquently you say so.

Nick Szabo has a great article on how social scalability can be achieved in a trustless environment using proof-of-work. Devising unique ways to eke out true incentives and alignments might as well be one of the biggest contribution of blockchain technology.

· 4 min read

Recent hype in blockchain aside, the fact that Blockchain is a completely different approach to doing tech can't be denied. Some key differences which make it non-intuitive to understand are:

  1. It's a completely distributed system and not just in terms of distribution as a way to ensure redundancy or load-balancing. The way blockchain works assumes distributed architecture, with each node capable of working independently. This is very different from the traditional way of designing server-client based architectures.

  2. The protocol doesn't assume that people will play nicely. In fact, the core assumption is that if something can be broken, it will be broken. What is interesting is the way in which incentives are designed in such a way that the best strategy for each player is to act according to the protocol. The game-theoretic insights built into the protocol incentivise players to act in a way that makes the system work.e.g. Byzantine Fault Tolerance is one of the core concept around which the protocol is based.

  3. The protocol developers have taken a very long view of how societies will evolve and have not constrained themselves to current social and economic systems. Bitcoin, which is one of the most popular applications of blockchain, fundamentally challenges the idea of money. We assume money to be something which is issued and regulated by govt. and derive its value from the guarantee of the Central bank. But this is a recent trend in history, and till 1933 US dollar was backed by gold (Gold Standard)

  4. Blockchain technology was developed by geeks and visionaries who imagined an alternate reality in which society can function. It was completely missed by the VC ecosystem except a few exceptional VCs like Fred Wilson at USV. Part of the reason may be because traditional venture funds work on a 7-10 yr time horizon, and blockchain was something which needed time horizon much bigger than that.

  5. Tokenization is a core mechanism by which these new protocols are funded, and is a very different way of thinking about business model and equity. Tokens at the same time work as the basic unit of value in the protocol (or an alternative for money) and also provide user a share in the value appreciation of that protocol. So, you are an investor and user at the same time just by virtue of holding the tokens and using them. Of course, there needs to be certain conditions met for this to occur, and not all business models can be tokenized - this is a fresh way of thinking about funding projects.

Most succinctly, this has been captured by this HBR article which argues that blockchain is not a disruptive but a foundational technology.


If we agree that Blockchain is a technology whose repercussions will be felt in the coming 5-10 years, I think the best way to benefit from it is to really build your foundations in the technology and understand the core ideas and not get swayed down in the hype. Blockchain is at a point where World Wide Web (www) was in 1980s, and the FBs and Googles are yet to be built. Or who knows, may be there won't be tech giants created by this tech wave and the societal impact will be very different from that of World Wide Web.


  1. Bitcoin Whitepaper
  2. Ethereum Whitepaper
  3. Filecoin Whitepaper
  4. Bitcoin Lightning Network paper
  1. Nick Szabo's Blog
Tech Basics
  1. The Byzantine's General Problem
  2. Merkel Tree
  3. Blockchain Visualisation
Twitter Handles to follow
  1. Naval Ravikant
  2. Nick Szabo
Slack Channels/Gitter
  1. Coinfund slack
  2. Bitcoin slack
  3. Ethereum gitter