Comment by buckie | Hacker News Reader

Comment by buckie | Hacker News Reader

Parent Full thread

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

>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.

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.

If the block size is 1, is it still a chain?

Of course. If Bitcoin dropped the number of transactions per block to 1 tomorrow would it stop being a blockchain?

I must have misinterpreted the statement. It felt like block count rather than size in the context of the sentence.

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/

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

Btw, small bone to pick with the Pact whitepaper[1]:

> EVM and Solidity have no support for atomic execution. Ethereum contracts simply abort on error, leaving developers with the impossible task of undoing previous writes and contract creates after any possible error condition.

EVM transactions are atomic; all state changes are reverted on aborts (out-of-gas errors and throws). Ethereum state changes are committed only after successful transaction execution, so developers never have to worry about writes from half-executed transactions.

1. http://kadena.io/docs/Kadena-PactWhitepaper-Oct2016.pdf

Is this commit from Oct 4 what you're referring to? https://github.com/ethereum/go-ethereum/commit/46a527d014851...

Ethereum is decidedly non-transactional in certain cases, like nested contract creation for instance. I don't know about this commit though.

The spec [http://gavwood.com/Paper.pdf] has been to revert on errors since day 1:

> Just as with contract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack underflow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. σ).

The Oct 4 commit just optimizes the way that reverts are implemented in go-ethereum (use a journal rather than deep copies).

For the case(s) you've mentioned, you are correct: the state that is built up disappears on error.

However, when last I checked, there are several operations that fall outside of this guarantee, e.g. new account creation, that are not rolled back on error. This would be as easy fix but to my knowledge is still unaddressed. Hopefully, they've changed this and if they have please let me know.

Edit: I stand corrected, thanks!

Last time I looked, you guys were developing Hopper, a contract language with a dependent type system. Why the pivot to Pact?

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.

... and you avoid problems like the Solidity compiler bug, where you could have written perfect, provably correct contract code, and the thing you're running it on could still open an exploit. The exploit could still have happened with interpreted code, but at least then it would be fixable.

Will do!

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.

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

When's the ICO?

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.

> 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?

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.

Reply on news.ycombinator.com