Porting cert-issuer to a different BC provider

Technical
1

I’m interesting in forking cert-issuer to add (basic) support for a different blockchain provider, probably hyperledger fabric.

Looking at the codebase it seems quite coupled with the idea of the blockchain supporting a cryptocurrency rather than business focussed blockchains like fabric.

Has anyone tried to port cert-issuer to a different chain?, any advice or links to projects would be appreciated :slight_smile:

1 Like
2

Some clarifications for porting to different blockchains (I’ll write this up more properly and place it in a prominent location):

Supporting a different blockchain provider should be restricted to the transaction layer. There are 2 places this would impact (e.g. in the python implementation)

  • In cert-issuer, the code that writes to the blockchain
  • In cert-verifier, the code that reads from the blockchain

The single most critical element to Blockcerts is the verification process – see details, which also requires complying with the schema.

In the “verification process” section called “blockchain transaction”, it describes how to identify the blockchain record. This is using a standard that allows different blockchains to be used. So for the Bitcoin blockchain, this is the OP_RETURN field.

That standard I’m referring to – Chainpoint v2 – is in the process of feeding into a W3C recommendation for describing data anchored to a blockchain. (Note that this standard doesn’t include more advanced timestamping schemes, like Open Timestamps or Chainpoint v3 – W3C Credentials CG will address that topic later).

While Chainpoint v2 only explicitly lists 2 blockchains (Bitcoin and Ethereum) explicitly, don’t let that hold you back. You are free to use a placeholder name and add an implementation for reading from/writing to that blockchain. (To add it to the official reference implementation, there’s a bit of additional followup I can help with, described at the end.)

Let’s look at an example. A Bitcoin anchor would be described with type BTCOpReturn and sourceId of the Bitcoin transaction id. This says: “use the Bitcoin blockchain, transaction id x, and field OP_RETURN to find the anchor”

"type": "BTCOpReturn",
"sourceId": "8623beadbc7877a9e20fb7f83eda6c1a1fc350171f0714ff6c6c4054018eb54d"

If you wanted to support Hyperledger Fabric, you would add a new type, e.g. “HyperledgerFabric”, and you could interpret sourceId as whatever makes sense for referring to a specific record/transaction for that blockchain. (And of course you’d need to implement the actual parts of reading from and writing to the blockchain)

So even if that type of blockchain is not mentioned as a current type, we can go ahead and add the implementation to Blockcerts reference implementation, and I can track addition of this new “type” with the W3C Credentials CG. The main impact may be that the type name may change, but everything else would be intact. In Blockcerts, we would handle that with versioning, i.e. to maintain backcompat.

So the good news is that porting Blockcerts across blockchains should be relatively simple and lightweight. And while the standards aspects introduce a slight delay on finalizing the blockchain “type” as part of the anchoring standard, we are free to introduce it in Blockcerts as an alpha version, etc.

I hope to have some examples to introduce soon, which should hopefully make this clearer.

thanks,
Kim

4 Likes
3

Any update if anyone’s put together a repo for this yet? Love the idea and want to play around with it myself. Was originally planning to try and hack together badgr and fabric before stumbling across Blockcerts!