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.
Problem
- The blockchain space is moving at an incredibly rapid pace. With the constant development of second layers and dApps, the platforms suffer congestion and long transaction delays due to issues with scalability.
- Moreover, efforts that seek to replace PoW with new consensus models like Proof-of-Stake (PoS) or integrate the protocol with off-chain networks and processes (payment channels, side chains) degrade the assurance, censorship resistance, and trustless nature of the original PoW design.
- Therefore the space is currently at a state of uncertainty in terms of where to balance mass volume usage (necessary for mass public adoption) and security.
Solution
- To resolve these current limitations of PoW we present Chainweb, a parallel chain PoW architecture that combines hundreds or thousands of individually mined peer chains into a single network, capable of achieving throughput in excess of 10,000 transactions per second.
- Unlike other platforms proposed form of consensus, Chainweb’s parallel network model maintains security without using side chains or only using specific part of a blockchain to process a large number of transactions. Kadena’s tests found an extremely high level of security with their proposal, which intends to produce roughly 1,000 different chains eventually for public use.
- With multiple parallel chains working simultaneously, if specific chains are congested by a dApp, a different chain can be utilized to conduct an ICO.
- Kadena’s solution gives every chain the primary chain functions, thus not a side-chain approach to solving scalability.
Main Features
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:
- Step 1: Dan, who’s coins are currently on Chain A, would specify which account he is deleting the coins on & the amount of coins to be destroyed.
- Step 2 : Dan would then specify that he is sending his coins to Chain B, and also include the account on Chain B to receive those coins.
- Step 3 : Upon completion of the transaction, Dan would take that Merkle Proof to the “Creation Chain” to prove that he has indeed deleted his coins. (This step is done at the smart contract level)
- Step 4: The smart contract would then run SPV, verify that the actions in step 1 and 2 have occurred, then distributes the coins to the specified account.
- Step 5 : The “Delete Coin transaction ID” is then consumed to prevent being used twice.
Roadmap
- 2018 Q1 — Whitepaper Release, initial Venture round of funding.
- 2018 Q2 — Accredited Investor Private Sale begins, Testnet release mid Q2.
- 2018 Q3 — Testnet hard fork.
- 2018 Q4 — Mainnet release, main ICO is conducted.
Token Economics — Currently N/A
Potential Considerations
- Main ICO is not until Q4 of 2018, accredited investor private sale begin in May.
Team + Advisors
Stuart Popejoy — Founder UC Berkeley
- Former Executive Director of New Products Division at JP Morgan.
- Over 15 years of experience building trading systems and exchange backbones for the financial industry.
Will Martino — Founder Yale University
- Lead Engineer for JP Morgan’s blockchain prototype: Juno
- Held a Tech Lead position for the SEC’s Crypto Working Group
- Was the lead engineer for the SEC’s Forensics analysis toolkit NEAT
Monica Quaintance — Lead Engineer & Adoption Strategist Columbia University
- Quantitative Analytics Programmer for the SEC
- Investment banker at Cushman & Wakefield
- Senior Database Engineer at Rent the Runway
Ben Jessel — Head of Growth University of Reading
- Led fintech and innovation strategy at Capco, a financial service consultancy.
- Has led numerous Distributed Ledger projects for clients in the area of Syndicated Lending and Post Trade Derivatives processing.
- Worked at a variety of Big-4 consultancies including Accenture and Deloitte MCS where he was involved in operational transformation, and technology strategy.
Vivienne Chen — Social Media & Office Administration Princeton University
- Brings experience in journalism, online media, blogging and creative writing, previously working in editorial at Scholastic.
Mark Nichols — Senior Engineer
- Mark brings a wealth of experience with production Haskell development, with extensive experience in financial systems, DSL design, and big data.
Paul Giordano — Advisor, Insurance
- Paul is an industry veteran as General Counsel and Chairman at Ironshore, CEO of Syncora Holdings Ltd. and CEO of Financial Products & Services and General Counsel at XL Capital.
Wayne Martino — Legal Counsel & Business Advisor
- Wayne has decades of legal and business experience with companies and entrepreneurs in emerging growth industries including the early stages of the commercial internet, new media and nanotech and, since 2013, working in cryptocurrency ecosystem.
Partners and Investors
- Asimov Ventures — asimovventures.com
- MetaStable Capital — metastablecapital.com
- CoinFund — coinfund.io
- Kilowatt Capital — kilowattcapital.com
- Multicoin Capital — multicoin.capital
Additional Resources:
- Github — Kadena LLC
- Coindesk article
- Unlock Blockchain article
- Cryptal News article
- BTC EThereum.com article
- Sammantics article
- ChainWeb White Paper
- ChainWeb Protocol Security Calculations
Kadena compiled TG Q&A with Co-Founder Will Martino & other team members.
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.