First off, when did "blockchain" become an uncountable noun? "blockchains" or "blockchain technology" sounds much more natural.
Anyways, I wish more people in the media would differentiate between the Merkel tree, providing the immutable ledger part, and the proof-of-work distributed consensus algorithm, which provides some degree of trust through burning an ever-increasing amount of power. Most of the benefits the author lists would be true of just the Merkel tree without needing the wasteful proof-of-work consensus system, if it's used between trusted parties. Also, even if there's not complete trust, it would still provide an audit trail so that appropriate actions could be taken against bad actors.
When the author later talks about governance boards, that just underscores the incongruity even more. While I'm sure governance boards could be shoehorned into some DAO-like system over distributed consensus, it seems a lot easier to just get rid of the whole distributed consensus altogether and give some digital signatures to the governance board that can sign/bless the Merkel tree.
>First off, when did "blockchain" become an uncountable noun?
When the businessmen/marketers/cryptocurrency-illiterate got their hands on it and tried to distance themselves from the only useful blockchain in existence: the Bitcoin blockchain.
LoL, as I sit here trading $10s of thousands online with no permission from any government or depending on a private company I need to trust. Your pound, dollar and yuan dropping like rocks, yeh, lol is right!
Most of the benefits the author lists would be true of just the Merkel tree without needing the wasteful proof-of-work consensus system, if it's used between trusted parties.
The parties don't have to be trusted. It's the opposite. A good blockchain needs mutually mistrustful parties who are not anonymous. If somebody tries to tamper with the ledger, all the other parties can easily tell who did it. It takes collusion of all parties to change history invisibly. Thus, you want parties who are not entirely cooperative.
Actually, zwenger was right. Without a proof of work, they do.
What's a blockchain? It's a data structure with a cryptographically strong CRC mechanism. But there's nothing stopping me from writing a new set of data into a new chain and passing it off as the original.
Sure, you may notice, but you can't prove my new chain is forged. I'll say the backup chain you're using as proof is the forgery...
It takes a proof of work to make the chain effectively uneditable. (Uneditable without paying for the work, which has been selected to be too expensive to be practical.)
> Sure, you may notice, but you can't prove my new chain is forged. I'll say the backup chain you're using as proof is the forgery...
If the items in the chain have digital signatures, you can prove that the people they're signed by contradicted themselves (or lost control of their signing keys). In Bitcoin people have felt that this wasn't good enough by itself, perhaps because there's not necessarily recourse against a counterparty who double-spends money, but you can still show that the double-spend attempt happened and who (in the sense of a signing key/address) was responsible for it.
"A good blockchain needs mutually mistrustful parties who are not anonymous" - in opposite, blockchain is a good solution for open system with anonymous participants. For other settings, there are more efficient solutions(e.g. PBFTs)
You may want to revise your view on who invented the data structure. It wasn't
Merkel (Angela?), it was Ralph Merkle. You use incorrect name too consistently
for it to be just a typo.
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.
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.
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:
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.
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.
> 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.
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.
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.
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
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.
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.
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".
That's not particularly surprising. If you're smart enough to implement and seed a distributed Merkle tree ledger you're smart enough to extrapolate the implications of indiscriminately offering yourself as an indefinitely persisted data feed.
That's a nice rationalization of the situation, but history shows that being smart enough to do one thing has almost no correlation with being smart enough to do any other specific thing that wasn't already necessary to do the first. I doubt the ability to implement blockchains has anything to do with such socio-political analysis, and so should you.
Expertise yes, but not necessarily desire to keep your information private. There are many expert cryptographers who are much more public than Satoshi.
That's a good way of putting it. Many other people in a similar position may have chosen to be public. Many other people would have chosen to remain private but failed at. It takes skill to chose to remain private about something like this in a way the remains (at least so far) resistant to at least som concerted skilled effort to find you.
"80% of banks are working on blockchain projects" - this means they've told someone to "investigate", which doesn't in any way mean a product is in the offing.
And so on with all the other claimed examples.
The product here is the Hyperledger initiative, run by IBM. The “IBM Blockchain – What is Blockchain?” page is a good example of content-free Blockchain hype:
Almost every “is” on that page is a “might” or “could” – no blockchain does all the things it describes in present-day terms, and particularly not any of the code dumps at Hyperledger.org.
Hyperledger.org is a corporate open source Potemkin village of the sort IBM has long favoured: the illusion of an open project, with no “there” there. I spent half an hour dredging the site and could not find one clear statement of what this software is actually intended to do, let alone differences from and similarities to existing blockchains. Even Bitcoin blog CoinDesk noted: “Among the doubts facing Hyperledger is a perceived lack of clarity on what might be ultimately produced by the initiative.”
If you click long enough, you'll find a page where the participating companies have dumped their unfinished blockchain experiments. The main code contributor is Digital Asset Holdings, who dumped Hyperledger Fabric there; their joining announcement (on their own site, not hyperledger.org) gives as technical details only that Hyperledger is an append-only ledger and has an actual Bitcoin-style blockchain in it.
(This makes it more "blockchain" than others. e.g., R3 Corda is a "Blockchain Product" that doesn't include a blockchain in its default configuration. The key factor to "Business Blockchain" is that any examples that work, aren't actually a blockchain. You get Merkle trees just shoving your transactions into a git repo.)
As Hyperledger found out, all manner of businesses – financial institutions, beef industry, shoe brands, confectioners – don’t want to share data even with all participants in their blockchain, but only with the people the specific deal is actually with, funnily enough:
The lack of clarity is kind of a feature, as Hyperledger is intended to be a modular, completely general framework for building any possible blockchain you can imagine.
Also, airy promises are not only cheap - it's a dessert wax and a floor topping! - but highly available and widely distributed in the Business Blockchain environment!
The other main code dump on hyperledger.org is Intel's. Their "Sawtooth Lake" replaces the blitheringly stupid and wasteful Proof of Work with something equally stupid but less wasteful, Proof of Elapsed Time, which might as well be called Proof of Buying An Intel CPU. Rather than have miners compete to produce the next block, a timer running in an environment secured by a DRM mechanism built into your Intel CPU picks if you get to do the next block. The white paper is an extended advertisement for Intel® Software Guard Extensions™ (SGX™). Also, they only have a simulated Proof of Buying An Intel CPU mechanism as yet.
This doesn’t provide any security against malicious participants; the excuse is that private blockchains need speed over security. You might think that at that point you don’t need a blockchain at all, but you’re hardly going to sell any consultant hours with that sort of thinking.
There's a link on my site to go on the alerts mailing list :-) It's literally not finished yet. (21,284 words of body text at this moment and I have maybe 5k-10k to add. I was targeting 15k for a quickly dashed-off Kindle short, and I appear to have turned the project into a miniature Sistine chapel.) I have excerpts from the draft up at the site. Which I just moved to http://davidgerard.co.uk/blockchain/ .
The article didn't mention tokenization of shares and token-based fund-raising. Presently, that is a far more disruptive and interesting use case for blockchains.
Trusted deployments of SaaS like software on your own infrastructure, for one thing. Using the merkle tree plus some currency's consensus gives us a path to trusted software deployment models, done on trusted infrastructure.
The article is behind a paywall so here is the article text -
How Blockchain Will Change Your Life
The technology’s potential goes way beyond finance.
By GINNI ROMETTY
Nov. 7, 2016 7:25 p.m. ET
Until the mid-1990s, the internet was little more than an arcane set of technical standards used by academics. Few predicted the profound effect it would have on society. Today, blockchain—the technology behind the digital currency bitcoin—might seem like a trinket for computer geeks. But once widely adopted, it will transform the world.
Blockchain offers a way to track items or transactions using a shared digital “ledger.” Blocks of new transactions are added at the end of the chain, and encryption ensures that it remains unbroken—tamper-proof and error-free. This is significantly more efficient than the current methods for logging and sharing such information.
Consider the process of buying a house, a complex transaction involving banks, attorneys, title companies, insurers, regulators, tax agencies and inspectors. They all maintain separate records, and it’s costly to verify and record each step. That’s why the average closing takes roughly 50 days. Blockchain offers a solution: a trusted, immutable digital ledger, visible to all participants, that shows every element of the transaction.
Financial institutions are becoming early adopters: The World Economic Forum estimates that 80% of banks are working on blockchain projects. CLS, the world’s largest multicurrency cash-settlement system, is implementing blockchain in the foreign-exchange market. The Bank of Tokyo-Mitsubishi UFJ has developed a smart-contract prototype for multiparty business transactions. China UnionPay is using blockchain for loyalty programs that operate across multiple banks.
But the potential goes beyond finance. We at IBM estimate that applying blockchain to global supply chains could generate more than $100 billion in annual efficiencies. Toyota and the U.S. Postal Service are exploring this already.
Visa and DocuSign are working on a blockchain system that enables a car buyer to sit in the driver’s seat, configure the aspects of a lease on the dashboard, and drive away immediately. La’Zooz, an Israel startup, has a blockchain ride-sharing app that allows drivers to connect directly with customers, without needing a middleman like Uber or Lyft.
All of this is promising. But for blockchain to go beyond pilots, the technology needs a system of transparent governance. Remember what guided the development of the internet: not-for-profit groups like the Internet Engineering Task Force and the World Wide Web Consortium. Their involvement gave businesses confidence that the internet would be stable and based on open standards.
The same must be true for blockchain. More than 80 leading finance and technology organizations, including IBM, have joined the Linux Foundation Hyperledger, a project aimed at creating an enterprise-grade blockchain framework. More than 600 additional firms have already applied to join the consortium.
There’s one more lesson to draw from the early days of the internet. If you had understood in 1995 the opportunities and threats it would ultimately present to your company or industry, what would you have done differently—to become the disrupter rather than the disrupted? That is where we are with blockchain today.
Ms. Rometty is the chairman, president and CEO of IBM.
It is consistently true that any writeup that says "Blockchain" (capital B, no article) will be somewhere between wrong and not-even-wrong.
I commend to you “Ignoring Blockchain Is Corporate Suicide: Why Blockchain is the biggest single threat to all CEOs for destroying corporate value” by Nick Ayton, in analyst newsletter Innovation Enterprise (7 July 2016). In the several years I’ve been following Bitcoin and blockchains, this is the single worst, stupidest and most incoherent piece of “Blockchain” hype I’ve seen; you definitely need to read it, to inoculate yourself against the worst excesses of this foolishness.
There's a very small niche problem that blockchain is actively solving and that is the enrichment of ICO founders.
Ethereum, Zcash, Ripple, Siacoin, Monero are all essentially the penny stock pump & dump scams of the early days of the internet.
Right now we got a lot of big movers courting blockchain companies but so far we see that it's a horrible ecosystem for building mission critical and scalable apps that is already being solved by AWS, GCE, Azure etc.
Ethereum especially is the biggest blunder out of the blockchain party. Can't scale (capped at low double digit transactions per second) due to it's overly distributed and trustless mechanisms with a huge security vulnerability surface thanks to a turing complete piece-of-crap language called Solidity.
I strongly suspect that we will see the demise of ICOs and blockchain bubble popping when regulators move in as they have previously done with fantasy sports betting startups.
To the adventurous and greedy individual thinking of launching blockchain ICOs: don't count on your coin != fiat because that won't matter when a bunch of people feel victimized enough and start courting the SEC.
disclaimer: I actually hold above cryptocoins but overall extremely pessimistic and feel pretty stupid buying into it.
Anyways, I wish more people in the media would differentiate between the Merkel tree, providing the immutable ledger part, and the proof-of-work distributed consensus algorithm, which provides some degree of trust through burning an ever-increasing amount of power. Most of the benefits the author lists would be true of just the Merkel tree without needing the wasteful proof-of-work consensus system, if it's used between trusted parties. Also, even if there's not complete trust, it would still provide an audit trail so that appropriate actions could be taken against bad actors.
When the author later talks about governance boards, that just underscores the incongruity even more. While I'm sure governance boards could be shoehorned into some DAO-like system over distributed consensus, it seems a lot easier to just get rid of the whole distributed consensus altogether and give some digital signatures to the governance board that can sign/bless the Merkel tree.