
Hyperledger – Linux’s open source approach to blockchain building - ilanhz
https://litepaper.com/resources/hyperledger
======
ajdlinux
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.

~~~
lima
Yes, the title needs to be changed. This is not related to Linux in any way.

~~~
brianbehlendorf
It could be changed to "The Linux Foundation's approach", sure, but it's very
much a Linux Foundation project, and is developed and managed using the same
template by which the Foundation manages the kernel project and others. We
have some differences - there is no central kernel, but a family of different
DLT systems within the Hyperledger community, reflecting geniunely different
approaches. But other parts are similar, from technical governance to
everything being under an open source license to legal compliance.

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

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

~~~
cateye
If parties are trusted, don't bother with Blockchain. Huge added complexity
(which brings security issues) without any benefit. Use for example git or a
conventional database.

~~~
jsutton
Ever try to share a conventional database between multiple different companies
or organizations? It's not practical. It seems more complicated than going
with a blockchain solution (or will be as blockchain deployment tools mature).

The adage that 'if parties are trusted, than go with a conventional DB'
doesn't hold water anymore. If you need to share a database with other
companies, it inevitably leads to contracting a third party solution to manage
the data entry between all parties, which means you now have to trust this one
entity and there's a single point of failure.

Hyperledger, blockchain, and the like eliminate the need for third party
management. A few engineers at each party needs to set up the new service, and
now you don't have to worry about central points of failure, you have built in
redundancy, and you save money by not having to use a data management service
that exists to make money off of you.

~~~
nearting
> Ever try to share a conventional database between multiple different
> companies or organizations? It's not practical.

Not practical how? It seems like this criticism can only be applied to
usability, but that's not a technical shortcoming.

> If you need to share a database with other companies, it inevitably leads to
> contracting a third party solution to manage the data entry between all
> parties, which means you now have to trust this one entity and there's a
> single point of failure.

This criticism seems a bit underspecified. While it's true that having a
single entity to handle data entry results in a single point of failure, but
what's the failure model? Do we assume that this single entity might be
malicious? Or are we assuming that the entity handling data entry isn't
familiar with the types of failures they may encounter, and thus hasn't taken
steps to mitigate the effects of those failures? Both of those scenarios,
given the context of sharing data among organizations, seems unrealistic.

> Hyperledger, blockchain, and the like eliminate the need for third party
> management. A few engineers at each party needs to set up the new service,
> and now you don't have to worry about central points of failure, you have
> built in redundancy, and you save money by not having to use a data
> management service that exists to make money off of you.

The claims you make here are correct: (1) the consensus protocol provides a
decent mechanism for writing to the database, (2) redundancy insulates against
loss of data, and (3) the open nature of the protocol means you don't have to
use a for-profit service. However, there are far more efficient ways to
achieve these things without relying on blockchains. If everyone that could
write to the database is known, and what you want is simply to guarantee the
integrity of the database, there are better data structures than a linear
chain of hashed, batched events (which is all that a blockchain is, at its
core).

~~~
wmf
The failure mode that keeps happening is that the trusted central third party
charges high fees to access the database.

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

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

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

*edit format

~~~
at-fates-hands
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.

~~~
brianbehlendorf
IBM is not the only company that can deliver a network built using Hyperledger
Fabric, or any of the other frameworks. Did you take a look at Sawtooth, or
Iroha? Did your devs engage with the actual Hyperledger community, or only
through IBM? There are several healthcare companies (Change Healthcare is one,
managing insurance claims) who have engaged directly and are in production.

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

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

------
brianbehlendorf
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,

Brian Behlendorf, Exec Director, Hyperledger

------
zby
Kind of light on details. My own impression of Hyperledger is that it is like
the ISO OSI network layers - there is everything in it.

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

------
tomhoward
Related, from a few weeks ago:

Hyperledger Fabric: A Distributed Operating System for Permissioned
Blockchains

[https://news.ycombinator.com/item?id=17586355](https://news.ycombinator.com/item?id=17586355)

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

------
deevolution
My intuition tells me hyperledger is a bunch of bs.

------
st1ck
> You need to enable JavaScript to run this app.

