I can't help but plug my take on why enterprise blockchains are almost entirely bullshit: https://medium.com/@qertoip/enterprise-blockchains-are-a-hug...
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
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.
So transaction throughput stays at 5-15 tx/s and does not increase as you add 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.
>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.
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.
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:
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.
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.
> 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.
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!
Ethereum is decidedly non-transactional in certain cases, like nested contract creation for instance. I don't know about this commit though.
> 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).
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.
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
https://r3cev.com/blog/2016/4/4/introducing-r3-corda-a-distr...
Their Corda Distributed Ledger Designed for Financial Services seems the most sensible of all the Business Blockchain approaches: after careful consideration of the fact that the Bitcoin-style blockchain was expressly designed to be the direct opposite of what large paying customers with money want, their “Blockchain Product” does not, in its default configuration ... contain a blockchain.
PREDICTION: Merkle trees are great, and business is about to discover how to use them as a tamper-evident ledger. That's what will be left of this in a year or so. Possibly branded "Blockchain".