feat: fabtoken HTLC

Is your feature request related to a problem? Please describe.

If someone wants to perform an atomic swap with a Fabric ledger being involved, right now they are left to their own devices to develop the specific contract that could perform the swap. It would be great, if we as a framework would provide some useful primitives for this such as a contract (chaincode) that demonstrates this.

Describe the solution you’d like

Ideally It would be a contract that is generic enough in the sense that it can be deployed to any Fabric network (including networks running Fabric 1.x) and work with any tokens that may be defined on that network. This is probably not possible because there’s no standardized way because there’s no built-in concept of balances in Fabric, so the next best way (may be) is to assume that the token being swapped is as per the FabToken specs and just hardcode this in the HTLCs own logic.

The assumption on top of the assumption in the above paragraph is that the FabToken specs are prescriptive enough to have the basic operations defined in them similar to how ERC-20 does a good enough job for this.

Part of this feature implementation is to validate these assumptions above and then refine the design in a collaborative manner.

Describe alternatives you’ve considered

N/A

Additional context

FabToken: https://fabric-documentations.readthedocs.io/en/latest/token/FabToken.html

Parent: feat(core-api): atomic swaps with HTLCs #510

[petermetz]

@RafaelAPB I think Jordi is busy with the HTLC coordinator right now so this one is on hold at the moment.

[petermetz]

I believe the FabToken is not supported - only arbitrary representation of digital assets. However, we can work with abstractions such as the State, and StateList: https://github.com/hyperledger-labs/university-course/blob/master/support/Lab05/chaincode/ledger-api/state.js

@RafaelAPB Oops, thank you for checking on this, I didn’t make it all the way to the end of the FabToken documentation, where (based on what you said above) I discovered these statements:

Future releases will provide users a greater ability to integrate tokens into business logic by supporting non-fungible tokens and chaincode interoperability,

Chaincode interoperability allows tokens to be issued, transferred, and redeemed by chaincode. This would allow the channel to issue and define tokens using business logic agreed to by members of the channel. For example, you can use chaincode to set the attributes of a chaincode, and associate certain attributes with different transactions.

From which I take it that for now the only way to deal with the tokens is via that CLI tool that the tutorial 1 is showing as well.

Defining a digital asset without any ontology is not the best, but facilitates things. An alternative is to follow a standard that defines the representation of a digital asset (will open an issue), and use that on the HLTC.

Okay, let’s continue the discussion there and try to evolve the design into something useful. I guess for the optimal solution, we are kind of stuck waiting for Fabric to have this feature available as an SDK+ChainCode compatible feature of theirs.