Add Indy-Besu PoC

[akarabashov]

This is not an official Indy Ledger code yet, but an experimental proof of concept (PoC). The goal is to prove a possibility to use Indy Besu as a foundation for Indy Ledger and show how it can be done.
The code and PoC may be moved to a separate Indy repository later for further development.

Plan for making this code official

Proposed by @TelegramSam in #1826

• Work is created in new repositories
  • I understand a previous conversation decided to put the work in indy-node. I think this decision should be changed.
  • This will help the work move faster with less community bottlenecks.
• Related work should be clearly labeled as experimental or research
  • This includes a did method definition, for example
• Advance the project so that we are able to test the properties of the project, including speed, scale, bandwidth, processor load, and energy use.
• Delay commitment to the new approach until we reach sufficient confirmation of approach validity.

Goals and ideas

• Prove a possibility of a replacement for Hyperledger Indy ecosystem that provides support for verifiable credentials:
  • Components to replace:
    • Distributed ledger: Indy Node and Indy Plenum
    • Client library: Indy SDK
  • Capability to migrate the data from the original Indy Ledger
• Distributed ledger requirements:
  • Public Permissioned Blockchain
    • Control the validator nodes
    • Control the user permissions
  • EVM compatible Blockchain
    • Capability to deploy on different networks
  • Based on existing open-source blockchain framework with a good performance, sufficient adoption, and wide community
  • Capability to work without tokens and fees
  • Stable consensus protocol
• Functional requirements:
  • Interoperability:
    • Capability to use existing DID's and identifiers:
      • Support indy DID method
      • Support sov DID method
      • Identifiers previously stored on the client side should be resolvable on the new Ledger
    • Capability to use the ledger as an AnonCreds Registry
    • Compatibility with the latest AnonCreds Specification
  • Extensibility:
    • Capability to integrate new pieces of functionality easily
    • Capability to use ETHR DID method
      • Integration with the AnonCreds Registry
      • Integration with Permissioned modules
  • Data validity:
    • Neglect gas efficiency in favour general validation of the stored data
      • Basic DID Documents validation
      • Basic AnonCreds entities validation
      • Basic state consistency validation

Design documentation

See design document covering the main ledger aspects.

Contact list

Feel free to ask any questions here or in person. All team developers will be happy to answer.
Especially Renata
(GH: @Toktar ,
LinkedIn: https://www.linkedin.com/in/renata-toktar-999b7a15b/
discord: Renata Toktar#5546
email: [email protected])

[Patrik-Stas]

@Toktar @Artemkaaas Apologies for taking this long time getting back to this. I have partially completed another pass over the comments and feedback, left some replies. I'll be continuing tomorrow.

Great discussion and please to see that you have already addressed some of the concerns 👍

[ashcherbakov]

PoC proved a possibility of using Besu for permissioned Indy ledger.
No concerns to push into experimental branch to not lose the work.
There is ongoing discussion if the PoC should stay in the branch or be moved into a separate rep.

[Patrik-Stas]

Approving from the perspective of:

• proving capability to store anoncreds on chain
• proving capability to permission validators for private deployments
• proving capability to permission network writes for private deployments
• proving credential issaunce and verification e2e against the novel anoncreds method.

That being said, learnings should be taken from this POC and IMO further development should be done. I have expressed my position (and raised some questions) quite extensively here #1826 (comment)

My proposal for the next steps is:

• Use https://github.com/gmulhearn/anoncreds-on-ethereum as basis did&anoncreds method
  • DID method: well known did:ethr
  • Anoncreds method: new, support rev registries, built on top of did:ethr
  • Simple contracts
• Use this POC as basis for network permissioning of
  • validators
  • write transactions
• Lastly decide on the way of organizing, I am in favor of new repo.

Apart from proving various aspect of permissioned anoncreds infra on Besu, I find this PR also valuable from perspective of 2nd order effects in kicked off - it triggered fusing mental energy into the researching alternative approach (the repo linked above). I think we are in good position where we can compare 2 streams of work and cherry pick the desirable attributes/components of both.

[Patrik-Stas]

Re-approving, please note my comment #1821 (review)

[WadeBarnes]

@TelegramSam, @reflectivedevelopment, Could you also weigh in here. Do we have agreement on the conditions of acceptance as @Patrik-Stas has stated? Anything further to add?

[ashcherbakov]

Re-approving, see #1821 (review)

[jovfer]

LGTM as soon as @TelegramSam 's comments are included at the top of the new code README.md

[WadeBarnes]

LGTM as soon as @TelegramSam 's comments are included at the top of the new code README.md

I saw that, I'd just like the comments on the PR for completeness.