Hyperchains VS Hyperledger

Hi-Core devs,

I have a potential client who is willing to try out a POC with my company, As you know we are building Self Sovereign Identity system on HYPERCHAIN.

But the client is suggesting to do it on Hyperledger. Because they can get support from IBM at a later stage when in production.

Can you guys please help me with a comparison chart that I could use to convince him to use Aeternity infrastructure?

@gorbak25 @radrow.chain @erlmachinedev1.chain

Thank You :slight_smile:

4 Likes

Not sure whether this is still relevant, only noticed your post now.

Hyperledger is a project of the Linux Foundation consisting of many different blockchain frameworks. The framework originally contributed by IBM is called Hyperledger Fabric. The SSI technology stack is called Hyperledger Indy. I’m not familiar with Hyperchain SSI.

There are quite some differences between a Fabric network and Aeternity. Fabric is designed to build permissioned consortium style blockchains, meaning a blockchain available to a limited group of parties of which we know exactly who they are and where permissioning can be used to determine who can do what. While Aeternity is a fully public network where users are pseudonymous.

Here is a video I made for aeternity a while ago where I explain about the differences between Fabric and Aeternity: https://studio.youtube.com/video/cHaXpR78Eeg/edit

So the right technology stack mainly depends on your business model. Do you really need your own network? I’m asking, because using Fabric means setting up your own network. Do you really need a consortium style model?

From an SSI perspective it’s even harder, because it depends on your definition of SSI and how your system would work. I can say that Indy is a blockchain based technology for identity. So normally it would run in conjunction with another system for smart contract execution. Indy heavily relies on verifiable credentials and claims can also be ZKPs.

Since Aeternity now also supports ZKPs I can imagine it might be possible to develop some sort of identity system. It’s hard to say whether you need this, because I’m not familiar with what you are building.

3 Likes

First of all you should ask the client about what specific parts of Hyperledger IBM uses when talking about SSI.

“Hyperledger” is an umbrella for every open-source project that is being developed and supported by the Linux Foundation. IBM for example contributed at least Hyperledger Fabric as project.

My personal guess is that when we talk about SSI they mean Hyperledger Indy which is a specific network that originates from the Sovrin Foundation.

The thing is that currently Hyperledger Indy is most widely used and almost every tool and service around it originates from Indy.

BUT they ALL (!!!) know that Hyperledger Indy won’t be the only ledger that will serve as base layer for SSI (specifically credential & revocation registries). This is why they launched Hyperledger Aries (https://www.hyperledger.org/blog/2019/05/14/announcing-hyperledger-aries-infrastructure-supporting-interoperable-identity-solutions) in 2019.

Hyperledger Aries is an agent framework that uses DIDComm and can theoretically work independent from any base layer as long as the tools and services are being developed. It is also in a very early stage IMO and it could be used with aeternity as base layer. There doesn’t speak anything against it.

Hyperledger Fabric should have nothing to do with SSI IMO.

BTW: https://doc.ibmsecurity.verify-creds.com/ this is the website of IBM in that regards.

Additional comments:

  • the argument to get support from IBM later on doesn’t make sense IMO. then they should do it with them from the start on
  • IMO every company building SSI solutions should aim to provide interoperability => this is what DIDComm and specifically Aries are aiming for
    • not sure if Aries is “the right approach” but in my ears it makes sense
    • if you can guarantee interoperability and maybe even contribute libraries to frameworks being used in that area they could easily replace your solution if required (for whatever reason)

The thing is that the blockchain with its verifiable data registries (Layer 1) is the most boring part of that whole stuff that is being worked on:

2 Likes