An overview of the Linux Foundation's open source approach to blockchain. LF is involved with lots of projects which aren't all explicitly Linux these days.
I did research Hyperledger Fabric and compared to other "Blockchain platforms". My conclusion was that it made a lot more sense to use Ethereum in most cases due to:
- Ethereum has a bigger community that is more open and inclusive. While Hyperledger is mainly an IBM and friends like project and a lot of decisions and information is kept inside. Goodluck getting things done without involving consultants from these "supporting" companies.
- Consensus algorithm is what makes a Blockchain a blockchain. Hyperledger says something like you can use whatever consensus mechanism you want but in practice there is not a real alternative to proof of work. Relying on a in public production battle tested algorithm will save a lot of effort and headache.
- crypto economic incentive is what makes a Blockchain a blockchain. Without having a coin to motivate participants in a balanced way to act in a specific desired way, there will not be any real advantages to use a blockchain platform and it is in most cases smarter to just use a distributed database. Hyperledger doesn't provide a practical way to create an incentive mechanism.
- The underlying philosophy of hyperledger is around "federated networks" which means that it is trying to create a controlled environment where transactions take place between authorized participants. This leads to centralization by authority which leads to data immutability according to the degree you trust this entity. This defeats mainly the purpose of Blockchain to create a trustless environment of immutable data record.
> Hyperledger says something like you can use whatever consensus mechanism you want but in practice there is not a real alternative to proof of work
With the latest crop of PBFT consensus algorithms (notably Tendermint/Cosmos), proof-of-stake is shaping up to be a real alternative. Though I'm a bit worried about the inherent complexity.
> Consensus algorithm is what makes a Blockchain a blockchain. Hyperledger says something like you can use whatever consensus mechanism you want but in practice there is not a real alternative to proof of work.
For public use maybe but for commercial/private use cases it can often be assumed that all parties are trusted in some manner. I think their approach to different consensus algorithms makes sense when you're solving for use cases beyond financial transfers between untrusted parties.
"While Hyperledger is mainly an IBM and friends like project"
IBM must have a lot of friends then, including direct competitors like Oracle and SAP, and lots of small startups. :) IBM is one of over 250 members in the consortium, but in the developer community (where it really counts), they are a substantial contributor - I have no idea how many FTEs but there are dozens of IBM developer names in the changelogs for Fabric, Composer, and others. But there are hundreds of other developers contributing to the 10 different project at Hyperledger, and even on Fabric, they are less than 50% of the contributor base by individual and by pull requests. The development is all done publicly (I challenge the "lot of decisions and information is kept inside" claim) and who you work for does not matter, so it's really on the other companies in this space (large and small) to increase their contribution levels, not on IBM's shoulders to decrease theirs, if this is an important metric.
"in practice there is not a real alternative to proof of work"
Come back when you've learned something about how blockchains work somewhere other than with cryptocurrencies. There are many other effective consensus mechanisms out there, especially when you're not trying to solve the anonymous participation goal - and much more energy efficient, and with better speed and finality to boot.
"crypto economic incentive is what makes a Blockchain a blockchain"
No. Perhaps this is a semantics game, as lots of people pretend to be authoritative about this, but there are plenty of intrinsic motivations to developing a common system of record amongst a population of rivalrous nodes, even amongst parties who don't trust each other. If ten banks want to maintain a shared DLT to exchange bank wires, they don't need to pay each other a token to record a transaction. They just don't - the costs of running such an infrastructure are de minimus compared to all the other costs in adoption.
"The underlying philosophy of hyperledger is around federated networks"
False. Hyperledger, as a project and as a community, is a place for the collaborative software development around open source blockchain technologies. There are five different frameworks, including Fabric, but including others focused on different approaches. All projects have focused on non-POW consensus mechanisms, and most are an implementation of consortium models, what's sometimes called "permissioned" blockchains - pick your metaphor, but a consortium of entities governed by a lightweight governing mechanism, or be it a referee on a football field, is a much closer conceptual model than a "federated" network, for which there are already plenty of options.
Again, please do research, talk to people, if you have questions or concerns air them with the project, but please don't just spout what you've heard, or made up after you saw the announcement press release in December of 2015 and paid no further attention to.
Was good to work with HLF but the ops background required to run it in production was staggering: Replicated Kafka + ZK backing the consensus algorithm. I put it all in Kubernetes with StatefulSets. Even with my background running those systems it felt unreasonable. I quit that job in Nov so I don’t know if the situation has improved since then. I liked the architecture and the team was responsive and put care into docs. Would use again.
Thank you! Folks are working hard to get deployment and management via Kube (and Helm Charts, etc) to be first-class supported and consistent. It's about where one would expect a 1.x level project to be, which means improvements like you point out are needed. Lots has happened since November. :) Hope you consider coming back and contributing.
we did a long evaluation of HyperLedger Fabric (0.6 - 1.x) for a project at my company.
We really wanted it to work since the chain code model was cool however we ran into stumbling block after stumbling block and in the end ditched it for something else.
List of pain points (no idea if any have been solved since we gave up on it)
1) Distributing chaincode updates to participants was an exercise in coordination that is unscalable
2) Kafka as consensus. At the time you had to use an infinite kafka queue since pruning it would throw fabric nodes into a panic and they'd drop off the network. We thought for sure we were doing something wrong but the need for an infinite queue was verified by someone at IBM
3) Community. The community around HL F was mostly IBM people or folks off doing their own weird thing and adding features or pull requests that were bizarre (a custom fork of postgres to act as state dB??). With that said there were a handful of _very_ helpful people there just never was a good mass of them
4) Performance. We wanted to run a private blockchain but amongst nodes distributed across the globe in whatever datacenter they chose. Running fabic in a truly distributed way just kills performance. There is a lot of cross talk and waiting for the ordering service to get sorted
5) Not really a blockchain. Fabric relied on the centralized ordering service and each node would contain its own state. If the ordering service pruned logs (which I guess is a feature now) then the distributed nodes could have ledgers that have content the central order does not know about. If that node wanted to rebuild it would need to rebuild from other nodes without a way to truly verify the content of the chain. This may have been solved but it was a gaping wound of a question when we raised it
There are others, in the end it was just way to much work and we moved off to a more popular blockchain and brought our proof of concept to feature parity and beyond in just two weeks.
We reached out to IBM for help several times and the answer was mostly "just buy bluemix" or "pay us and we'll implement it for you"
To use HyperLedger Fabric in any sense of scale and operational readiness you must run it all within one data center. If you have external participants in your network they must also be customers of that service or you can just run it all yourself in y our own DC for your own needs.
IF you go that route, it begs the question of "why bother?" You're putting everything in the hands of one entity and then adding in a ton of complexity and slowness. Just use a database or something right?
We had a large presentation from IBM about hyperledger (I work for a healthcare company) and it seemed like something our industry could really leverage.
I was put on a team to research using it on an upcoming project. Once we started digging in and asking questions, it became apparent very quickly IBM wants to control everything from top to bottom. It's on their network, they build it, they maintain it, and there's not a lot of options outside of what they've already built.
We had some very specific functionality we needed and were told by the IBM team it wouldn't be a problem. When we got down to delivery and talking actuals, they started to balk if they could even deliver what we really needed. After trying to nail several things down and not getting anywhere, we pivoted and are currently looking at other blockchain platforms.
After reading your response, it sounds like we may have dodged a bullet and made the right choice.
IF you go that route, it begs the question of "why bother?" You're putting everything in the hands of one entity and then adding in a ton of complexity and slowness. Just use a database or something right?
So what's the justification your company used for a private blockchain in lieu of a database?
I am looking for a library that provides a blockchain, without needing a consensus mechanism. 50% of the the need is to gain experience and 50% is for a couple of light weight projects. I was hoping this was something I could try out but from the comments it looks like not. I use nodejs so extra points for that, but I am open to other alternatives. An example project would be to set up a local swap market, where users can swap appliances for swap-coins, then spend those for other appliances at a later time.
IMHO a "blockchain without a consensus mechanism" is tantamount to a security door without a lock. The whole point of "blockchain" being that all transactions on it are correct and verifiable via a consensus mechanism, i.e. a distributed, non-centralized trust mechanism where you don't have to trust one individual or company to get it right.
If you really want to record transactions without a consensus mechanism, use a database.
The only mildly sophisticated part of the blockchain itself is the Merkle tree. You can find lots of Node libraries for that.
For every new record, add it to the tree. When your tree gets big enough (i.e. hits maximum block size), sign it along with the hash of the last one, and then start a new Merkle tree. Congrats, you have a blockchain.
A blockchain "without a consensus mechanism" is git: every commit has at least one parent. There is no consensus mechanism, as everybody can commit "to the blockchain".
If you want a good ready to use development tool look at https://truffleframework.com/ - it's literally a wrapper around ethereum-js along with some friendly programming tools for smart contracts, etc.
There is a lot of misinformation circulating in the comments here that I'll be addressing as replies to some of these threads, though inevitably won't be able to get to each one. I'd ask each of you to not just repeat misinformation you've heard from others, but do first-hand research by going to the Hyperledger website, wiki, discussion forums, or other places and learn about the tech before taking the snarky way out. Thanks,
Love the format and illustration, though I feel having a high-level comparison between different Hyperledger projects (especially Fabric versus Sawtooth) is probably important here. Happy to contribute/collaborate on this.
Can someone give me a concrete example of a situation in which a private blockchain makes sense for a company or industry instead of a shared, permissioned database?
[+] [-] ajdlinux|7 years ago|reply
[+] [-] claydavisss|7 years ago|reply
The LF is a huge disappointment to me...just selling the linux brand to whoever wants it.
[+] [-] lima|7 years ago|reply
[+] [-] cateye|7 years ago|reply
- Ethereum has a bigger community that is more open and inclusive. While Hyperledger is mainly an IBM and friends like project and a lot of decisions and information is kept inside. Goodluck getting things done without involving consultants from these "supporting" companies.
- Consensus algorithm is what makes a Blockchain a blockchain. Hyperledger says something like you can use whatever consensus mechanism you want but in practice there is not a real alternative to proof of work. Relying on a in public production battle tested algorithm will save a lot of effort and headache.
- crypto economic incentive is what makes a Blockchain a blockchain. Without having a coin to motivate participants in a balanced way to act in a specific desired way, there will not be any real advantages to use a blockchain platform and it is in most cases smarter to just use a distributed database. Hyperledger doesn't provide a practical way to create an incentive mechanism.
- The underlying philosophy of hyperledger is around "federated networks" which means that it is trying to create a controlled environment where transactions take place between authorized participants. This leads to centralization by authority which leads to data immutability according to the degree you trust this entity. This defeats mainly the purpose of Blockchain to create a trustless environment of immutable data record.
[+] [-] lima|7 years ago|reply
With the latest crop of PBFT consensus algorithms (notably Tendermint/Cosmos), proof-of-stake is shaping up to be a real alternative. Though I'm a bit worried about the inherent complexity.
[+] [-] luma|7 years ago|reply
For public use maybe but for commercial/private use cases it can often be assumed that all parties are trusted in some manner. I think their approach to different consensus algorithms makes sense when you're solving for use cases beyond financial transfers between untrusted parties.
[+] [-] brianbehlendorf|7 years ago|reply
IBM must have a lot of friends then, including direct competitors like Oracle and SAP, and lots of small startups. :) IBM is one of over 250 members in the consortium, but in the developer community (where it really counts), they are a substantial contributor - I have no idea how many FTEs but there are dozens of IBM developer names in the changelogs for Fabric, Composer, and others. But there are hundreds of other developers contributing to the 10 different project at Hyperledger, and even on Fabric, they are less than 50% of the contributor base by individual and by pull requests. The development is all done publicly (I challenge the "lot of decisions and information is kept inside" claim) and who you work for does not matter, so it's really on the other companies in this space (large and small) to increase their contribution levels, not on IBM's shoulders to decrease theirs, if this is an important metric.
"in practice there is not a real alternative to proof of work"
Come back when you've learned something about how blockchains work somewhere other than with cryptocurrencies. There are many other effective consensus mechanisms out there, especially when you're not trying to solve the anonymous participation goal - and much more energy efficient, and with better speed and finality to boot.
"crypto economic incentive is what makes a Blockchain a blockchain"
No. Perhaps this is a semantics game, as lots of people pretend to be authoritative about this, but there are plenty of intrinsic motivations to developing a common system of record amongst a population of rivalrous nodes, even amongst parties who don't trust each other. If ten banks want to maintain a shared DLT to exchange bank wires, they don't need to pay each other a token to record a transaction. They just don't - the costs of running such an infrastructure are de minimus compared to all the other costs in adoption.
"The underlying philosophy of hyperledger is around federated networks"
False. Hyperledger, as a project and as a community, is a place for the collaborative software development around open source blockchain technologies. There are five different frameworks, including Fabric, but including others focused on different approaches. All projects have focused on non-POW consensus mechanisms, and most are an implementation of consortium models, what's sometimes called "permissioned" blockchains - pick your metaphor, but a consortium of entities governed by a lightweight governing mechanism, or be it a referee on a football field, is a much closer conceptual model than a "federated" network, for which there are already plenty of options.
Again, please do research, talk to people, if you have questions or concerns air them with the project, but please don't just spout what you've heard, or made up after you saw the announcement press release in December of 2015 and paid no further attention to.
[+] [-] internet_user|7 years ago|reply
[+] [-] harlanji|7 years ago|reply
[+] [-] brianbehlendorf|7 years ago|reply
[+] [-] DIVx0|7 years ago|reply
We really wanted it to work since the chain code model was cool however we ran into stumbling block after stumbling block and in the end ditched it for something else.
List of pain points (no idea if any have been solved since we gave up on it)
1) Distributing chaincode updates to participants was an exercise in coordination that is unscalable
2) Kafka as consensus. At the time you had to use an infinite kafka queue since pruning it would throw fabric nodes into a panic and they'd drop off the network. We thought for sure we were doing something wrong but the need for an infinite queue was verified by someone at IBM
3) Community. The community around HL F was mostly IBM people or folks off doing their own weird thing and adding features or pull requests that were bizarre (a custom fork of postgres to act as state dB??). With that said there were a handful of _very_ helpful people there just never was a good mass of them
4) Performance. We wanted to run a private blockchain but amongst nodes distributed across the globe in whatever datacenter they chose. Running fabic in a truly distributed way just kills performance. There is a lot of cross talk and waiting for the ordering service to get sorted
5) Not really a blockchain. Fabric relied on the centralized ordering service and each node would contain its own state. If the ordering service pruned logs (which I guess is a feature now) then the distributed nodes could have ledgers that have content the central order does not know about. If that node wanted to rebuild it would need to rebuild from other nodes without a way to truly verify the content of the chain. This may have been solved but it was a gaping wound of a question when we raised it
There are others, in the end it was just way to much work and we moved off to a more popular blockchain and brought our proof of concept to feature parity and beyond in just two weeks.
We reached out to IBM for help several times and the answer was mostly "just buy bluemix" or "pay us and we'll implement it for you"
To use HyperLedger Fabric in any sense of scale and operational readiness you must run it all within one data center. If you have external participants in your network they must also be customers of that service or you can just run it all yourself in y our own DC for your own needs.
IF you go that route, it begs the question of "why bother?" You're putting everything in the hands of one entity and then adding in a ton of complexity and slowness. Just use a database or something right?
*edit format
[+] [-] at-fates-hands|7 years ago|reply
I was put on a team to research using it on an upcoming project. Once we started digging in and asking questions, it became apparent very quickly IBM wants to control everything from top to bottom. It's on their network, they build it, they maintain it, and there's not a lot of options outside of what they've already built.
We had some very specific functionality we needed and were told by the IBM team it wouldn't be a problem. When we got down to delivery and talking actuals, they started to balk if they could even deliver what we really needed. After trying to nail several things down and not getting anywhere, we pivoted and are currently looking at other blockchain platforms.
After reading your response, it sounds like we may have dodged a bullet and made the right choice.
[+] [-] Naomarik|7 years ago|reply
So what's the justification your company used for a private blockchain in lieu of a database?
[+] [-] mailbag|7 years ago|reply
[+] [-] internet_user|7 years ago|reply
[+] [-] talkingtab|7 years ago|reply
[+] [-] ConcernedCoder|7 years ago|reply
If you really want to record transactions without a consensus mechanism, use a database.
[+] [-] jnwatson|7 years ago|reply
For every new record, add it to the tree. When your tree gets big enough (i.e. hits maximum block size), sign it along with the hash of the last one, and then start a new Merkle tree. Congrats, you have a blockchain.
[+] [-] y0ghur7_xxx|7 years ago|reply
[+] [-] random3|7 years ago|reply
If you want a good ready to use development tool look at https://truffleframework.com/ - it's literally a wrapper around ethereum-js along with some friendly programming tools for smart contracts, etc.
[+] [-] brianbehlendorf|7 years ago|reply
Brian Behlendorf, Exec Director, Hyperledger
[+] [-] zby|7 years ago|reply
[+] [-] kyloon|7 years ago|reply
[+] [-] tomhoward|7 years ago|reply
Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains
https://news.ycombinator.com/item?id=17586355
[+] [-] Aqueous|7 years ago|reply
[+] [-] deevolution|7 years ago|reply
[+] [-] st1ck|7 years ago|reply