Kadena is creating a public blockchain using a new consensus mechanism called Chainweb which offers a scaling solution for a Proof of Work consensus based chain system.
Chainweb — Kadena’s “massively-parallelized public blockchain platform” will utilize the Chainweb Protocol as its consensus mechanism.
Chainweb is a Proof-of-Work Parallel-Chain Architecture for Massive Throughput.
Multiple chains integrate their Merkle roots (the Merkle root is the hash of all the hashes of all the transactions in the block) with each other, ensuring that while each individual chain acts as a unique blockchain, it can still share information and reach consensus with other chains.
Every single chain will produce Kadena’s tokens, and Chainweb’s protocol will ensure that the same coin cannot exist on two chains at the same time.
Chainweb will use a Simple Payment Verification (SPV) to delete coins that are sent to another chain before being created on the receiving chain.
This process is a trustless destructive cross-chain coin transfer through SPV which occurs at the smart contract level.
Step by Step guide on the trustless destructive cross-chain transfer process:
If Dan wants to move his coins from Chain A to Chain B, he would take the following steps:
Q: How do the miners guarantee the safety of each chain with so many parallel block chains?
A: Same as Bitcoin or Ethereum, just on a larger scale. A majority of the network mines the entire thing and doesn’t build off bad blocks. By construction every block that gets included must be published
Q: Are users assigned a chain to be on, or do they select their own chain providers? Will there be any reason that particular chains might compete for users on their own chain?
A: Select their own. Every chain is just as open, ownerless, and trustless as bitcoin or ethereum… there’s just more than one chain to transact on.
Q: What is to prevent, for example, everyone from choosing the same chain?
A: Congestion, if everyone uses the same one then it gets congested and the fees creep up.
Q: When are all the parallel chains created?
A: At genesis, and when a hard fork happens at the forking block. All the chains in the network need to be aware of what other ones exist + who their peers are.
Q: So all the thousands of parallel chains are created at the genesis? And then to add capacity there is a hard fork which adds new chains?
A: Yes, though we’ll see if we launch at 1k+ chains (I’d like to but may be overkill initially) so we could launch at, say, 500 chains, and fork up to 1000 if the network starts to get congested.
Q: Is Kadena similar to ICON?
A: ICON’s much closer to Dfinity/Cosmos, all of which are closer to IBM’s fabric, than any are to Kadena. Regarding consensus — ICON uses deterministic BFT (PoS) for consensus and scales using interop networks (basically sharding). There’s a bunch of technical limitations and niggles with this approach, it’s a longer convo, but the tl;dr is that this approach works well for private chains but has a borked security model (trust in identity instead of physics) + liquidity issues when used for public chains. re:smart contracts — ICON doesn’t have them, they have python with (it appears) a storage API. As for kadena, for public consensus we have chainweb (take PoW, add a dash of graph theory, shake gently and voila… crazy high throughput, crazy high security, keep your trust in physics). As for smart contracts, we have Pact (super safe, super readable, designed for non-programmers to understand, formally verifiable, crazy fast to rapidly develop in) which is going to be the next SQL.
Q: Can only PoW consensus mechanism join the braid?
A: No, any fully probabilistic consensus primitive can be used. We had a line in the paper about proof of space but it got pulled. Chainweb is really a low-level way of using “probabilistic effort”, for lack of a better term, more efficiently. However, things like PoS won’t work — I mean I’m sure someone will try to adapt PoS for it but the security model is just borked. You can _transport_ the assurance that a mined root represents in a way that you can’t for PoS (or any deterministic BFT) — they just don’t pin assurance to physics in the same way.
Q: Can coins that already do PoW join the braid?
A: No, the braid’s configuration is decided at launch and can’t change unless a hard fork was involved. It’s not a sidechain thing. Instead of there being one “everything gets settled ultimately on me” chain there are N chains that can equally perform settlement in a braid. NB: if you want to get SUPER philosophical then the answer maybe but how you’d do it has more asterixis for why it’s a bad idea/won’t work than this message has characters.
Q: Does Kadena see it self as an interoperable solution?
A: Yep. I’ve never understood why interop was big deal BTW — if you’re a private blockchain, you use an oracle for it and write an API (we’ve been doing this for 30 years and are _really_ good at this). If you’re a public blockchain w/ smart contracts, just add merkle proof validation (so you can do on-chain SPV) and voila! You can now transfer (thus communicate) between wholly separate chains by allowing users to bring trustless proofs. There’s a little more to it (like this works _really_ well for bitcoin proofs because the hashrate is just stupid high so the difficulty of the toplevel hashes is insane) but that’s the gist. SPV isn’t useful to consumers (just use an oracle/run a full node) but it’s super useful to blockchain interop.
Anyway, Kadena Public will have this ability — more or less arbitrary SPV (can’t guarantee it’ll work for all 1k altcoins… thats a lot of alt coins). Moreover, we on-chain SPV based interop to make chainweb work. Solving bitcoin<->kadena interop was actually how discovered chainweb (solve interop for bitcoin -> what about dogecoin -> what about all coins that aren’t kadena -> well what about pact -> let’s have two-chains to make the question make sense -> oh crap, this works for N chains if we use graph theory).
Q: Is this a scalable solution for PoW?
A: Yes… what if I told you that the solution to scalability was PoW?
It’s actually kinda crazy, the higher the throughput you set for chainweb, the _more_ secure it gets (and thus the lower the latency). There are bounds for this, of course, but for the useful configurations it’s true.
Q: Is the scalability of ChainWeb theoretically infinite?
A: Technically it’s unbounded as you can keep making the diameter larger… but we’ll run out of fiber _way_ before you need to start discovering/making new graphs with diameters > 20.
Q: How is PoW not about economic power?
A: PoS and dpos is the same, economic power rules.
Moving to PoS or dPoS is to gain scalability at the cost of a trustless system. At least with PoW, you maintain a trustless system.
Economic power will always find a way to maximise their incentives on a network, that is inevitable. Moreover, I’ve always seen PoS as having the potential to devolve into oligopoly — if 20 people own a majority of the token and don’t want to lose control of the network then no price you offer them will ever be enough… and you’re kinda outta luck. At least in PoW, anyone can became a major player if they spend enough money on resources (open system).
Q: What is the vesting schedule for Team and Advisors token?
A: Initial grants come out of the investor share of the genesis block, which doesn’t have vesting restrictions unlike the platform share which has a _long_ vest. Generally these initial team and advisor tokens have between a 1mo-1yr vest and are relatively small when compared to the entire economy. Subsequent grants for the team and advisors will come from the platform share and will vest accordingly — T+0 to T+1yr after launch there is no vest at all, T+2yr to T+5yr after launch the platform share vests linearly on a monthly basis.
Q: Is vesting for Team and Advisors coded in the smart contract?
A: We need to ask our lawyers and accountants what the best way to do this is — I’d like it to be baked into a smart contract but we may do it another way for reasons.
Q: Was your smart contract audited by an independent cybersecurity company?
A: We’re not there yet, but we’re aiming to open source the v1 of pact’s formal verification system in April so, really, we’re going to get the FV system audited and then use the FV system on the contract itself.
Q: Has the code for your product been published, and has is it been audited by an independent cybersecurity company?
A: This is basically the previous question but broader — it’ll all be open source but yeah we’ll be getting an audit prior to launch… probably over the summer.
Q: Is achieving 100k tps actually feasible?
A: Yes, I think a 100k tps Chainweb config (so 10k chains) is feasible though we’d need a lot of utilization first to justify a hard fork to that capacity but we could do it (e.g. we are running a 50k tps config that is, on average, using 10k tps with peaks that are between 40k and 50k tps). The amount of mining energy needed would be the same (the difficulty per chain is just cut in half but there are 2x as many chains).
Q: Regarding connection between your public blockchain and private blockchains. Is there any connection? Do they use the same token? Let’s say there is 100M tokens in circulation available for people to buy. If some company wants to setup a private blockchain with you, do they use a set of these 100M tokens or something totally different?
A: Both our public and private protocol use the same smart contract language (Pact) but they are (intentionally) nothing alike re: consensus mechanism. Our private chain is a scalable byzantine fault tolerance (BFT) protocol and doesn’t involve tokens; our public protocol is called chainweb that uses PoW with some graph theory braiding (you can read about it in our white paper), that’s where the tokens are involved.
Q: Why isn’t Pact turing complete?
A: Pact isn’t turing complete because we don’t want to have recursion, infinite loops, etc in smart contracts.
Q: Do you think lightning network makes what Chainweb is obsolete?
A: Lightning network is a level two scaling solution whereas chainweb is a level one. All level two solutions work with (almost) all level one’s, so they don’t really compete. You could plug lightning into chainweb without much effort.
Q: Which is better, lightning network or Chainweb?
A: Both is better. Lightning isn’t a great fit for a general scalability solution due to liquidity/centralization/reg issues plus the general solution should be at the base layer of the stack, BUT it has specific cases where it could make a lot of sense.
Q: How is Kadena better than Credits? Credits claims it does above 230k Transactions per second.
A: For one, it uses a proven consensus protocol (POW) — I think people forget that it’s incredible that POW actually works. Back when the paper came out, this was a big unknown and I feel like people think that just anything will work. Another point: it scales like this, I think, because it’s peer-to-peer where you have connected consensus domains (I have a hard time believe that any sequential exec env can do 230k `hello world`s let along something useful); the problem is that if the ledger is centrally held in a single consensus env I can corrupt one of the connected sub consensus envs and move that corruption to another sub consensus env.
Q: Could the Chainweb protocol scale beyond that level (230k transactions per second)?
A: Yes. Would I recommend it? Probably not/would need a damn good reason too. 230k tps is just overkill for a level 1 system. Visa, globally, peaks at 40k tps but averages 10k tps. It’d be hard to imagine a scenario where we’d fork above 100k tps. Level 2 scaling solutions should be attempted before that.