1/ How do you scale a Proof of Work blockchain? Well, let's start with the classic Computer Science parallelization and work from there.

2/ If one Bitcoin blockchain can do 5 transactions per second (using round number approximations for simplicity), two Bitcoin blockchains can do 10 transactions per second, ten blockchains can do 50 tps, etc.

3/ But this approach has two major problems:

1. Each of these completely standalone blockchains has a completely different currency. Ten separate currencies...not so great.

2. A 51% attack becomes a 5.1% attack...not good.

4/ @kadena_io's #chainweb protocol solves both of these problems by braiding the chains together. For 2 chains, in addition to making each block include the hash of the previous block on the same chain, you also have it include the hash of the previous block on the other chain.

5/ This means each #chainweb block in a 2-chain network contains one additional hash--i.e. 256 additional bits of information...not bad! But what benefits do we get in exchange?

6/ Well, if you wait one block after your transaction, it will require the full hash power of both chains to do a 51% attack on that block. And the hash braiding gives us the merkle tree structure needed to do cross-chain SPV proofs, yielding a single currency across both chains

7/ So now we've solved the two major problems described in post #3 of this series, and the cost is only 256 bits (32 bytes) of additional storage per block. But if we scale this up to, say 10 chains, that starts to add up...

8/ If each block in a 10-chain web contains the hashes of the previous block on all other 9 chains, that's an additional 288 bytes of overhead per block or 2880 bytes per block height--it gets out of hand fast. But there's hope!

9/ It turns out there's a brilliant result from an obscure branch of math that can save us and solve the Proof of Work scalability problem! More on this tomorrow...

@kadena_io #chainweb #scalableblockchain