hyperledger-labs / fabric-token-sdk Goto Github PK

Call context.OnError only when creating a token transaction.
Add support to context.OnError for ttx package .

• Extend the use of RawOwner to DLog
• Make Fabtoken public parameters extensible

• Rename api to driver
• Move to latest version of Fabric Smart Client

Error messages generated by these components must improve:

• driver/Validator
• ttxcc, ttx, tcc components

Finalize the code for the validation of the fabtoken driver actions.

Hello,

we're using zkatcc as an external chaincode on HLF. As such we're building by ourself the zkat chaincode docker image but I think this project should be the proper location for such build.

For such task, we would need a docker image repository. As Fabric Token SDK is now open source, I suggest to use the official docker hub. Then we should think on the delivery pipeline for such chaincode delivery :

• how do we manage latest image update ?
• how do we manage tagged image publication ?
• ...

Also, on our current zkat chaincode, we embedd the tokengen tool that way we just need the zkat chaincode image to use that tool and we do not need to build it on each of our developpers env. This choice may be discussed and may be we would prefer other way to deliver such tool :

• a dedicated docker image for fts toolings ?
• a binary delivery for any platform (linux, osx ...) ?
• ... ?

Remove the following dependencies:

• view/driver
• view/core
• fabric/driver
• fabric/core

Currently, only the Transfer function takes in input options to further customise the Transfer operation.
The tasks in this git issue are:

• Add support for custom attributes in the Transfer option, for driver specific customisation
• Add support for Issue options with custom attributes.

In case some user would want to implement an enhanced driver which gives additional capabilities to tokens of existing drivers, where only some tokens can be used for the enhanced capabilities, then the system might reach a state where two or more encoding schemes coexist: (a) The fabtoken token encoding and (b) The encoding for the enhanced token.

In such a setting, we need a way to distinguish between the two encoding schemes.

Therefore it may make sense to encode a Type in some field (such as the owner) to mark that the token needs to be parsed in one scheme and not in another.

In token/services/ttxcc/endorse.go, the endorseView's Call() method blindly signs anything but does not validate what it signs

During the execution of a view that prepares a token transaction, the view, at some point, will collect endorsements on the transaction. The endorsement flow contacts the auditor, if required. If another endorsement collection is performed in the same view, the auditor fails to respond because the view is reusing an already existing session to the auditor but in that session the auditor is supposed to respond to only one auditing request.

The solution is to close the auditor session.

Check that the token operations are called with valid arguments.
Examples:

• If an issuer calls issue with value "0" or type "", then token-sdk should return an error.
• If a user calls transfer or redeem with value "0", then token-sdk should return an error.

Make the following customisation possible:

• Add support to new public param generators
• Topology: Change Token SDK
• Deploy a different TCC

The Token Request does only support a single field for the auditor.

This issue asks to change this field to an array of array of bytes that each driver can fill as needed.

The Token Selector asks to Token Vault about available tokens. A query to the token vault is non-blocking. In the case of concurrent selection we could have the following situations: Two threads query the vault and get the same list of available tokens. One thread manages to complete the transaction lifecycles for the token selected. At the same, time the other thread locks a token already used by the other thread that is not locked anymore cause the transaction has been committed. A token that does not exist anymore is then selected.
Now, to avoid to make the queries to the vault blocking, this issue asks to check, after selection, if the tokens exists and report concurrency error in case some of the tokens do not exist anymore. This will give a chance to the application to retry.

Currently, when a new token is stored into the vault, the token is indexed by its ID.
Indexing also by owner id, would allow the token selector to filter fast by wallet.

Currently, if no TMS is available for the passed options, the token-sdk panics.

This issue asks to replace the above behaviour with returning nil.

When using the token-sdk as a dependency in other project, the string github.com/hyperledger-labs/fabric-token-sdk/token/services/tcc/params.go might not be caught cause it can contain mod information inside.
Replacing it with "/token/services/tcc/params.go" fixes the problem.

Complete documentation for

• DVP
• Token Basic

Allows the developer to specify the deserializer to be used for the issue, transfer, and auditors

Here is the list of tasks in this Issue:

• complete transfer verification function (

  fabric-token-sdk/token/core/fabtoken/validator.go

  Line 158 in 8ced88e

  func (v *Validator) VerifyTransfer(inputTokens []*token2.Token, tr driver.TransferAction) error {

  )
• complete issue verification function (

  fabric-token-sdk/token/core/fabtoken/validator.go

  Line 154 in 8ced88e

  func (v *Validator) verifyIssue(issue driver.IssueAction) error {

  )
• introduce deserializer of owner, issuer, and auditor identity
• token and public parameters loader
• customizable public parameters manager
• cleanup code

Currently, the locking mechanism is memory based. This issues asks to persist the locking information directly into the vault.

This may help improve the inter-operability.

This issues asks to add support for application metadata at the token transaction level.
In turn, this translates to support to custom metadata in the TokenRequest.
Recall that TokenRequest's metadata does not appear on the ledger but is shared off-chain with the parties that are supposed to receive it.

Mathlib offers a single unified API to use pairing friendly elliptic curve for cryptography

TO BE DEFINED...

To allow a consumer of the token SDK to implement new types of transaction of its own, we should consider exporting the fields of the Transaction so that the consumer can just call the fabtoken NewTransaction function and then just reference the fields if there is an need for it.

In certain scenario, one might require double issuance resistance to avoid that an asset can be issued multiple times. This problem can occur because Fabric adopts the execute/order/validate model. In this setting, multiple issues can be executed in parallel asking to issue the same asset for given conditions. Only one issue should make to the ledger.

• export fabtoken driver service and its fields to make it extendable
• move to the latest version of the smart client
• SigService: add support for signer registration
• Vault Processor: configurable token ownership checker support

Currently, when auditing is enabled, the identity of the auditor must be passed at token transaction creation:

	tx, err := ttxcc.NewAnonymousTransaction(
		context,
		ttxcc.WithAuditor(fabric.GetIdentityProvider(context).Identity("auditor")),
	)

However, the public parameters supports a single auditor.
Therefore, if the auditor is not explicitly passes at token transaction creation, it should be automatically set from the public parameters. If the identity of the auditor's FSC node cannot be resolved, then an error will be returned.

The Type field can be by driver to understand which kind of identity the Owner contains. This would avoid drivers to introduce they specialisation as currently done by the fabflow driver with RawOwner.

Documentation should about

• concise feature list
• Architecture
• Tutorial: Write your first Token-Based Distributed Application
• Advanced deployment
• Integration Tests

Currently, the nwo token platform deploy directly the token chaincode but other platform might need to access the definition of the token chaincode in the topology.

This Issue asks to let the nwo fabric platform deploy the token chaincode instead.

• c7da5db
• afca9dc
• f57c564

If a token stays locked for too long, it might be that the process that locked it failed to clear the lock.
This issues asks to introduction an eviction mechanism based on the age of the token. If the token has stayed locked for more than a certain threshold then it gets unlocked.

Currently, it is not possible to retrieve a wallet for the a given TMS identified by network, channel, and namespace. The same applies to the request of recipient identities.

This Issue requires to add the possibility to pass an array of token.ServiceOption to select the proper TMS.

This issue brings the following:

• NWO token topology: use Fabric topology's name when adding a new TMS.
• Introduce TMS Identifier
• Vault/Query: multi network support
• TCC/Auditor: multi network support
• Vault/Processor: multi network support and extendable token issued recognition
• TTX and TTXCC: multi network support
• Core/TMS: multi network support

The link is https://raw.githubusercontent.com/hyperledger-labs/fabric-token-sdk/main/docs/imgs/stack.png, which is difficult to read the words on it.
Thanks!

Currently, the idemix signer deserializer does not check that the secret key matches the nym key this can result in a signer that produces only invalid signatures. To resolve this, check that the signer can produce a valid signature. If not, return an error.