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: renata.toktar@dsr-corporation.com)

[Toktar]

Thanks @Patrik-Stas for your amazing overview! We are incredibly pleased to see such a high interest in our solution and Indy project in general. Let us provide a summary of our response now, we are going to add more details soon:

1. Two designs are not concurrent options. Our plan is that both approaches can be available and co-exist in deployments of Indy 2.0 (both did:indy2 and did:ethr contracts can be deployed).
   • Our current approach would be better for existing migrations (especially from the Holder side). On the other hand, the new applications can use did:ethr.
   • We've been updating the README and adding a Roadmap to make it more clear
   • Contracts for permissioned use case (upgrade, roles, etc.) are decoupled from did:indy2, so they can work with did:ethr as well.
   • Our CL AnonCreds implementation can also work with did:ethr.
2. One of the main goals of did:indy2 is to be compatible with existing did:indy and did:sov as much as possible to simplify the migration, especially on the Holder side for existing VCs. Although on the ledger side the data structures are new (indy2) to suppoer recent standards and new features, we are going to support compatibility on the VDR/client side. It's not there yet, but in our roadmap.

This fact was probably not very clear in existing code and documentation, so we've been updating the README and adding a Roadmap.

[Toktar]

Hello @Patrik-Stas! In continuation of the previous messsage, let me give a response to your comments:

DID resolvers for Besu will have to be either way made.

Depends on the implementation of the VDR/SDK. We would like to make this transition as smooth as possible for Indy users. Although for Issuers the difference is not that visible, the main difference is for migration on the Holder side. Indy2 approach allows keeping existing VCs for all Holders (no need to re-issue them).

Issuer will either way have to ...

do additional steps for migration

Yes, but we plan to hide all the actions in one script in order to localize the migration to the click of a single button. Moving Issuer's data completely without their approval would be ethically incorrect.

Current design

1. Speaking about the disadvantages of checking an identifier, a regular expression is a way to check an identifier to restrict a valid syntax. The cost of this operation is not important, since we use a permissioned network with zero gas costs.

2. Regarding trust guarantees, we had an intention to check legacy Indy(Sov) DID identifiers, against an appropriate verification key (needs signature verification), but ed25519 signature is not as trivial for Solidity as EcDSA. Due to this, we have postponed its implementation to the next phases.

Comparison of designs

I consider the did:ethr method to be one of the best, but there is a question of business goals. Indy2 approach allows keeping the same identifier. Thus, already issued VCs will continue to be valid without reissuing.

Indy2 keeps original Indy permissioned transactions to manage a network.

Migration plan includes transferring a full DID Document from original Indy with adding a new EcDSA Verification method with Ethereum account issuer signature.

did:ethr compatibility

By Indy2 design, it will be possible to combine different Indy specific DID method and did:ethr method smart contracts on one network, giving customers the option of not having to switch between networks. At the same time, permission smart contracts are currently not tied to Indy and are scalable to all smart contracts For CL Anoncreds it is possible to update current smartcontracts for using different DID methods. In addition, the PoC https://github.com/gmulhearn/anoncreds-on-ethereum contains the same approach for storing entities in the state and can be combined with the current PoC.

---

We have added project goals to README. And added a file with a roadmap, since this is a PoC implementation and there is still a lot of work ahead.

[Patrik-Stas]

Hi @Toktar sorry just getting back to this now, got somewhat occupied with other things past week. I see you left feedback on my review, I'll go through it, thank you!

[dbluhm]

We really appreciate the in-depth review that @Patrik-Stas left! We haven't had a chance to look at this as much as we'd like to yet but it's on Indicio's radar to review and raise any concerns.

[TelegramSam]

I have thoughts that I put in an issue: #1826

[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 👍

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

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