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
sourceId of the Bitcoin transaction id. This says: “use the Bitcoin blockchain, transaction id x, and field OP_RETURN to find the anchor”
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.