Doug Beardsley Show Notes Kadena

  • Kadena in a Nutshell: Complete Layer 1 blockchain solution that is based on proof of work and also scaleable. It has three components that are major product focuses.
  • One is our smart contract language called Pact.  We realised smart contract languages are not very good, have crazy bugs and loss of money; we felt redesigning a smart contract language from the ground up for smart contract development was a really great thing. We could build safety and security in from the get-go and then we wouldn’t have rely on DApp developers getting things right. Pact forms the foundation of our company and our product hierarchy.  Then we have 2 blockchains - a private blockchain and public blockchain project. Both of those are built on top of Pact and run the smart contracts through this language. As an aside, Pact is not just a Kadena thing anymore; we are doing a projects with Tendermint called Kadenamint to run Pact on their platform. We are putting Pact forth as a standard language for smart contract development.
  • Where did the idea for Pact come from? The syntax is most like List. The co-founder who did the most work on Pact has a deep background in Finance. Pact is a formally verified language, which means at the end, you can verify if the language is written correctly. This is the most exciting part of Pact, the formal verification framework.  Most languages are NOT formally verified.  If you are writing a smart contract which will exist outside in the wild once you release it, you should be able to verify it to make sure it is secure across all attack vectors.  The more power you have the more care you need to take.
  • The thing about blockchain is that once you put the smart contract on the blockchain, unlike other programming, it is there forever and so our thesis with Pact is that we want to be much more confident about what we are putting out there because it is immutable.  You need confidence upfront.  From a commercial standpoint, is this turning incomplete verifiable language appealing to clients?  It’s pretty good, once they get past the syntax of it.
  • The language should have first-class support for multi-sig operations. We have this idea of a keyset which gives you multi-sig basically. People find it very intuitive. This can be done with any smart contract; it can have this multi-sig keyset governance built into it.  Guards allow you to do programmable contract governance. Once the smart contract has been out for a while and audited, it cannot be changed or upgraded, which can be a good or bad thing depending on how the contract has been written.
  • Contract governance determines whether or not the smart contract is upgradeable.  With Pact and our blockchain, we put the code for the smart contract on the blockchain, and it is human-readable, so you can see this contract does not allow it to be upgraded.  There is another approach called managed capabilities which notifies users to give you permission as part of the signing contract language.
  • Can you summarise ChainWeb – your braided blockchain approach? This is attacking the scalability issue. We believe proof of work is the best proven and tried consensus mechanism that we know of.  This is basically the parallelisation process extended to the blockchain.  ChainWeb solves this problem by linking the chains together.
  • To understand how it works, let’s start with two chains. There are two blocks on the chains, and each block has a hash of the previous block, which makes it a blockchain. In a ChainWeb, each block on the two chains would not only have the hash of the previous block but also the hash of the block on the other chain as well. Chain 1 has a pointer to the previous block but also a pointer to the previous on Chain 2. Chain 2 also has a pointer to the previous block but also a pointer to the previous on Chain 1. This means in order to carry out a 51% attack; you have to have 51% of the entire network.
  • ChainWeb distributes the hash power among many chains rather than just one. As soon as you get one block ahead, you have to have the hash power that went to both of those chains.  We want to scale out arbitrarily.  Degree diameter theory (from graph theory) makes all chains connectable.  How much space does it take up in each block? You are only storing the hash in each block of about 256 bits.  Because of the interconnectedness of chains, you only need three neighbour chain block’s hash stored in each block.
  • The chain graph is static. Everyone can see it. In order to move from 10 chains to 50, that would be a fork which would need to be voted on by everyone. You can run a node on a subset of chains, not on every chain. This would reduce the replication data requirements.
  • The interconnectedness of chains should encourage miners to try out different strategies across chains and mine across chains.
  • Proof of stake miners are violating money transmission laws in US and Europe.  Just because you have a new technology doesn’t mean that it gets a pass.  There is another argument that Proof of Stake is really rule by the wealthy in the network.  If you can’t figure out how to scale proof of work, then, of course, you could go down the proof of stake path.  But right now we would rather work on scaling proof of work.  All blocks earn rewards and payout coins.  When you add more chains, the reward is split between all chains’ blocks.  Rewards are based on block height.   There is pre-planned coin reward curve.
  • What is expected at the end? The transactions will pay for all the mining.  We followed the Bitcoin playbook.  One of the things that coin base issuance does it allows miners to plan around future revenues. Without it, at the end, you now have an unknown unknown.  I think eventually, Ethereum will move to a 1% increase in the supply indefinitely. Eventually, there should be enough demand for transactions, to cover the Bitcoin miners’.  Network dynamics should over time address these issues.
  • More chains reduce the vector of attack. ChainWeb, due to the interconnected nature of the chain, it is not about the blocks but about the hash power.  As the chains are connected so quickly and spreads out, you need the hash power of the whole network to be able to attack any single chain.  You need 51% of the whole hash power of the network to be able to attack any chain.
  • Kadena is a great company to work for. The culture is defined from the top by our founders.  Both Will and Stuart are from a technical background which was very important to me.
  • Who is Kadena built for? Who will the product users be? We are building with the concerns of Dapp developers in mind and people who actually want to use blockchain technology for real things.  Our private blockchain was what Kadena was built around at the beginning.  We are very interested in exploring the interplay between these public and private blockchains. We have a private blockchain and a recently released public blockchain.  We think there is huge potential in this hybrid blockchain area for applications in many different industries.
  • Private blockchains are basically a new form of middleware; so it is a new form of middleware that companies are using to distribute, segregate and organise data. A public blockchain would be the place of settlement for whatever value needs to take place as a permanent record. Is there anything special in the interaction between your private and public blockchain?
  • There are other hybrid concepts are out there.   The public blockchain validate and allows value transfer between private chains.  The other one was using ZKsnarks.
Subscribe to our podcast on iTunes