7 ms·

Before I founded a company[1] in this space I investigated blockchain applications for JPM and I agree with your take on bitcoin-style blockchains being mostly

by buckie 10y ago

Before I founded a company[1] in this space I investigated blockchain applications for JPM and I agree with your take on bitcoin-style blockchains being mostly BS for industry. I'd take it a step further to note that mining is incompatible with private blockchains of any form because the new coins+fees incentive structure doesn't exist. Permissioned/Private Blockchains don't need to look like Bitcoin, they just need to offer many of the same features plus a few more. What we're really talking about is a database that competitors can share, which is largely inspired by Bitcoin's system. Some things it needs to actually work: - Vastly increased performance: 5-15 transactions per second is useless for industrial use. - Smart Contract languages designed for safety over generality: more of an empowered SQL than a C/Go. Tokenization doesn't provide enough of a benefit over traditional approaches and generalized computation is too dangerous. - Deterministic BFT Consensus: this is to replace mining + remove anonymous participation, it needs to be fast and scale. - Confidential transaction support: the trickiest of the lot, as we cannot currently hit performance + double-spend protection at once. In case you're curious what our approach is: BFT Raft-like for consensus (8k-12k trans/sec), soon to be open sourced smart contract language, signal protocol over the chain for confidential stuff. [1]: http://kadena.io http://kadena.io

cloudjacker 10y ago
When's the ICO?
- buckie 10y ago
  We're focused on private deployments currently but are playing with the idea of a public chain. The issue is that it would look so different from what people are used to that we're having a hard time with the monetization strategy/figuring out what people would use it for. For one, there's no Mining so what's the meaning of the initial coins? Also, it'd be much closer to an AWS Lambda + Stripe/Ripple than anything else which makes fee structures tricky. The big reason is that we would run all of the nodes ourselves because our core IP is ScalableBFT and we think that's the most valuable bit. It's the first/only deterministic BFT Consensus that can scale into the 1000's of nodes + maintain constant performance as it scales. Being a bit of a breakthrough, we are keeping the protocol and its implementation proprietary.
  - cdetrio 10y ago
    > can scale into the 1000's of nodes + maintain constant performance as it scales. So transaction throughput stays at 5-15 tx/s and does not increase as you add nodes?
    - buckie 10y ago
      The blockchains we're discussing here are about uniform replication & inter-node agreement, so constant performance is as the system scales is the goal. Our implementation of ScalableBFT runs at 8k-12k transactions per second, not 5-15 tps, and it maintains this performance as cluster size increases (up to some limit, we haven't managed to test it past the limit yet and think it's around 5k-15k nodes). The other deterministic BFT systems like PBFT and SmartBFT are a little bit faster for small cluster sizes but slow down for every added node, encountering full system locks before 256 nodes. It's worth noting that these systems generally do not do pubkey sig verification on every command, instead relying on consensus and direct replication via TLS for authorship guarantees. The drawback, of course, is that an attacker is one server (the client's TLS server) away from inputting fake commands that the system deems real + smart contract authority is handled logically and not cryptographically... we see the CEO and the Mail Clerk having different keys to be a huge benefit from a Bitcoin-like approach. This makes the bottleneck for us crypto-verification. Verifying 8k-12k signatures per seconds is pretty tricky if you don't skimp out on the crypto, which a lot of vendors are doing in the name of speed.
trhway 10y ago
>What we're really talking about is a database that competitors can share >BFT Raft-like for consensus exactly. Blockchain right now is just the most "simple" and open format of sharable append-only-log-structured database and consensus protocol for it.
- spopejoy 10y ago
  It's still a blockchain though. Bitcoin is also a database-backed BFT consensus, with a fixed transaction batch size, a fixed data schema, and a probabilistic consensus/BFT algorithm. Deterministic BFT consensus systems that maintain linear, incrementally-hashed logs are blockchains with a block size of 1. Since they are so much faster, the block concept is unnecessary.
  - cgio 10y ago
    If the block size is 1, is it still a chain?
    - buckie 10y ago
      Of course. If Bitcoin dropped the number of transactions per block to 1 tomorrow would it stop being a blockchain?
      - cgio 10y ago
        I must have misinterpreted the statement. It felt like block count rather than size in the context of the sentence.
bgibson 10y ago
Hi buckie, first I've seen of Kadena but like your approach. Deterministic BFT, built in Haskell, what looks like a Lisp for contract language prioritizing safety. Good work. I'm helping organize a conference at Stanford in January on blockchain protocol design and security, would you guys have any interest in presenting about your approach and/or things you've learned so far: https://cyber.stanford.edu/blockchainconf/ https://cyber.stanford.edu/blockchainconf/
- buckie 10y ago
  Yeah, sounds interesting. Ping us at info@kadena.io so we can chat more/keep in touch. Pact should be O/S Sunday or Monday, we're putting the finishing touches on the web editor now and the Atom plugin is already out there[1] though without a binary to run alongside it there's not much to see. [1]: https://atom.io/packages/language-pact https://atom.io/packages/language-pact
  - cdetrio 10y ago
    Last time I looked, you guys were developing Hopper, a contract language with a dependent type system. Why the pivot to Pact?
    - spopejoy 10y ago
      Pact is fundamentally different from Hopper, reflecting our goal to create the right database metaphor for blockchain systems. You can see Bitcoin as a single-purpose versioned key-value database with support for authorization with public keys. Pact generalizes the versioned key-value database to be key-row, maintains a full history, and the rest of the language allows you to enforce whatever invariants you want, with whatever key-based authorization scheme you need. As such, Pact is really a very simple language, which is really important for business adoption. If people are going to be entrusting code to execute contracts, you have to be able to read that code with some hope of understanding what it means. This is also why Pact is interpreted, not compiled: that way you can easily see what code is stored in the ledger.
sandGorgon 10y ago
this is very cool! quick question - why did you decide to build your own rather than use an infrastructure like Ethereum. We were thinking of leveraging Ethereum (with a consensus protocol) to build a database that can be shared between a few competitors that are in our ecosystem. Would love to hear your thoughts. P.S. I'm not a blockchain expert.
- buckie 10y ago
  Well, it depends what you really want out of the system. I'd argue that generalized computation is inappropriate for a permissioned blockchain. For a public blockchain, sure, though I'd still not go with Ethereum for a bunch of reasons (e.g. it's compiled so when you find a compiler bug you need to upgrade all of the contracts vs upgrade the interpreter, because it's a pita to develop in, etc...) EVM was a great first step, but like all first steps it is in need of iteration. Also, I would note that "with a consensus protocol" is very, very tricky... well if you want BFT anyways. Rolling your own consensus is on the order of difficulty of rolling your own crytpo -- this is experts only, don't do it. It's not quite as difficult as crypto but you still need to formally prove it which is very hard. We didn't make our own consensus, instead we used Raft for consensus and figured out how to make it BFT which is hard but nowhere near as hard as making consensus from scratch. Here's my off-the-cuff guide to figuring out if you want a blockchain and what properties it needs: Do you want a distributed DB? * No -> postgres. * Yes -> you need consensus of some fashion. Will some nodes for the DB be hosted by competitors in your space? * No -> You don't need BFT, use hashicorp's stuff. * Yes -> You need BFT, welcome to "I need a blockchain" territory Will competitors be able to directly write logic that will run on the system? * No -> regular language is fine * Yes -> you need a smart contract language to write in What type of scaling and performance do you need? * 3-100 nodes + high performance -> PBFT/SmartBFT for consensus is fine, but keep in mind that if you ever need to scale beyond this you're screwed (maybe you can get to 200 but I doubt it). * 100-10k nodes + high performance -> email us at info@kadena.io, we're literally the only ones able to do this currently * +100 nodes + low performance -> Mining based consensus could work, but you need to lock it down and centralize pending transactions a bit to avoid incentivization issues. * >10k nodes + high performance -> wait 5 years, maybe someone will figure it out. What do you need to do with the chain? * track allocation of things/conserve mass -> no need for a smart contract language, adapt a bitcoin approach * conserve mass + run logic -> you need some type of language, though maybe not a smart contract class one Assuming you need to run logic... * and don't need BFT -> glue python/whatever onto consul, be careful to only write deterministic code * need BFT, and want to be able to fold proteins -> use EVM (though I'd recommend rethinking your approach... why should you replicate massive computations like this?) * need BFT, and want the system to work a lot like a very paranoid DB -> email us

by buckie 10y ago

cloudjacker 10y ago

When's the ICO?

buckie 10y ago
We're focused on private deployments currently but are playing with the idea of a public chain. The issue is that it would look so different from what people are used to that we're having a hard time with the monetization strategy/figuring out what people would use it for. For one, there's no Mining so what's the meaning of the initial coins? Also, it'd be much closer to an AWS Lambda + Stripe/Ripple than anything else which makes fee structures tricky. The big reason is that we would run all of the nodes ourselves because our core IP is ScalableBFT and we think that's the most valuable bit. It's the first/only deterministic BFT Consensus that can scale into the 1000's of nodes + maintain constant performance as it scales. Being a bit of a breakthrough, we are keeping the protocol and its implementation proprietary.
- cdetrio 10y ago
  > can scale into the 1000's of nodes + maintain constant performance as it scales. So transaction throughput stays at 5-15 tx/s and does not increase as you add nodes?
  - buckie 10y ago
    The blockchains we're discussing here are about uniform replication & inter-node agreement, so constant performance is as the system scales is the goal. Our implementation of ScalableBFT runs at 8k-12k transactions per second, not 5-15 tps, and it maintains this performance as cluster size increases (up to some limit, we haven't managed to test it past the limit yet and think it's around 5k-15k nodes). The other deterministic BFT systems like PBFT and SmartBFT are a little bit faster for small cluster sizes but slow down for every added node, encountering full system locks before 256 nodes. It's worth noting that these systems generally do not do pubkey sig verification on every command, instead relying on consensus and direct replication via TLS for authorship guarantees. The drawback, of course, is that an attacker is one server (the client's TLS server) away from inputting fake commands that the system deems real + smart contract authority is handled logically and not cryptographically... we see the CEO and the Mail Clerk having different keys to be a huge benefit from a Bitcoin-like approach. This makes the bottleneck for us crypto-verification. Verifying 8k-12k signatures per seconds is pretty tricky if you don't skimp out on the crypto, which a lot of vendors are doing in the name of speed.

trhway 10y ago

>What we're really talking about is a database that competitors can share >BFT Raft-like for consensus exactly. Blockchain right now is just the most "simple" and open format of sharable append-only-log-structured database and consensus protocol for it.

spopejoy 10y ago
It's still a blockchain though. Bitcoin is also a database-backed BFT consensus, with a fixed transaction batch size, a fixed data schema, and a probabilistic consensus/BFT algorithm. Deterministic BFT consensus systems that maintain linear, incrementally-hashed logs are blockchains with a block size of 1. Since they are so much faster, the block concept is unnecessary.
- cgio 10y ago
  If the block size is 1, is it still a chain?
  - buckie 10y ago
    Of course. If Bitcoin dropped the number of transactions per block to 1 tomorrow would it stop being a blockchain?
    - cgio 10y ago
      I must have misinterpreted the statement. It felt like block count rather than size in the context of the sentence.

bgibson 10y ago

Hi buckie, first I've seen of Kadena but like your approach. Deterministic BFT, built in Haskell, what looks like a Lisp for contract language prioritizing safety. Good work. I'm helping organize a conference at Stanford in January on blockchain protocol design and security, would you guys have any interest in presenting about your approach and/or things you've learned so far: https://cyber.stanford.edu/blockchainconf/ https://cyber.stanford.edu/blockchainconf/

buckie 10y ago
Yeah, sounds interesting. Ping us at info@kadena.io so we can chat more/keep in touch. Pact should be O/S Sunday or Monday, we're putting the finishing touches on the web editor now and the Atom plugin is already out there[1] though without a binary to run alongside it there's not much to see. [1]: https://atom.io/packages/language-pact https://atom.io/packages/language-pact
- cdetrio 10y ago
  Last time I looked, you guys were developing Hopper, a contract language with a dependent type system. Why the pivot to Pact?
  - spopejoy 10y ago
    Pact is fundamentally different from Hopper, reflecting our goal to create the right database metaphor for blockchain systems. You can see Bitcoin as a single-purpose versioned key-value database with support for authorization with public keys. Pact generalizes the versioned key-value database to be key-row, maintains a full history, and the rest of the language allows you to enforce whatever invariants you want, with whatever key-based authorization scheme you need. As such, Pact is really a very simple language, which is really important for business adoption. If people are going to be entrusting code to execute contracts, you have to be able to read that code with some hope of understanding what it means. This is also why Pact is interpreted, not compiled: that way you can easily see what code is stored in the ledger.

sandGorgon 10y ago

this is very cool! quick question - why did you decide to build your own rather than use an infrastructure like Ethereum. We were thinking of leveraging Ethereum (with a consensus protocol) to build a database that can be shared between a few competitors that are in our ecosystem. Would love to hear your thoughts. P.S. I'm not a blockchain expert.

buckie 10y ago
Well, it depends what you really want out of the system. I'd argue that generalized computation is inappropriate for a permissioned blockchain. For a public blockchain, sure, though I'd still not go with Ethereum for a bunch of reasons (e.g. it's compiled so when you find a compiler bug you need to upgrade all of the contracts vs upgrade the interpreter, because it's a pita to develop in, etc...) EVM was a great first step, but like all first steps it is in need of iteration. Also, I would note that "with a consensus protocol" is very, very tricky... well if you want BFT anyways. Rolling your own consensus is on the order of difficulty of rolling your own crytpo -- this is experts only, don't do it. It's not quite as difficult as crypto but you still need to formally prove it which is very hard. We didn't make our own consensus, instead we used Raft for consensus and figured out how to make it BFT which is hard but nowhere near as hard as making consensus from scratch. Here's my off-the-cuff guide to figuring out if you want a blockchain and what properties it needs: Do you want a distributed DB? * No -> postgres. * Yes -> you need consensus of some fashion. Will some nodes for the DB be hosted by competitors in your space? * No -> You don't need BFT, use hashicorp's stuff. * Yes -> You need BFT, welcome to "I need a blockchain" territory Will competitors be able to directly write logic that will run on the system? * No -> regular language is fine * Yes -> you need a smart contract language to write in What type of scaling and performance do you need? * 3-100 nodes + high performance -> PBFT/SmartBFT for consensus is fine, but keep in mind that if you ever need to scale beyond this you're screwed (maybe you can get to 200 but I doubt it). * 100-10k nodes + high performance -> email us at info@kadena.io, we're literally the only ones able to do this currently * +100 nodes + low performance -> Mining based consensus could work, but you need to lock it down and centralize pending transactions a bit to avoid incentivization issues. * >10k nodes + high performance -> wait 5 years, maybe someone will figure it out. What do you need to do with the chain? * track allocation of things/conserve mass -> no need for a smart contract language, adapt a bitcoin approach * conserve mass + run logic -> you need some type of language, though maybe not a smart contract class one Assuming you need to run logic... * and don't need BFT -> glue python/whatever onto consul, be careful to only write deterministic code * need BFT, and want to be able to fold proteins -> use EVM (though I'd recommend rethinking your approach... why should you replicate massive computations like this?) * need BFT, and want the system to work a lot like a very paranoid DB -> email us