accordproject / hyperledger-fabric-tools Goto Github PK

We need to investigate how data privacy features in Hyperledger Fabric apply to, and can be applied to, Accord Project legal smart contracts. Transient data can be used to secure data passed as input to transactions, and private data collections can be used to secure data stored in the world state. However, I do not have a good answer for securing data returned in the response from a transaction, or emitted as a chaincode event.

Side note; channels are the most extreme form of data privacy available in Hyperledger Fabric, and depending on the number of contract instances could lead to excessive operational overhead.

Linked to #5, but separate topic.

How do we allow only certain participants in a Hyperledger Fabric network to submit transactions to a contract instance? Hyperledger Fabric has various access control technologies including access control rules defined on a channel (ACLs), organization based access control (checking the MSP ID in the smart contract), and attribute based access control (checking certificate attributes in the smart contract).

We should determine which access control mechanisms are suitable for Accord Project legal smart contracts, and figure out how users could apply these access controls.

Once the deployment model in #1 is agreed upon, we need to decide on what packaging tools are required to generate and build Fabric smart contract packages (.cds) files that can be deployed using the Fabric CLI or SDKs.

Is there a need for Fabric chaincode developers to extend the Fabric chaincode with other code, and not just the generic code that links from Fabric into Cicero? Need to figure out what the use cases are (if any), and how a user would go about doing this extension work.

We need to come up with the deployment model for an Accord Project legal smart contract in terms of Hyperledger Fabric smart contract(s) (chaincode).

Today, there are two samples demonstrating how to do this.

The first one demonstrates how to use a single Fabric chaincode x to host multiple contract templates and contract instances:
https://github.com/accordproject/fabric-samples/blob/release-1.1/chaincode/cicero/node/cicero.js

One drawback of this approach is the lack of explicit approvals (signatures) from all interested parties. Transactions submitted to create new contract instances, update the contract data, or execute the contract are only subject to the endorsement policy of chaincode x. Endorsement is not approval - endorsement happens silently by the act of a party in the network executing chaincode at the request of an authorised client application.

Another drawback of this approach is that because there is only a single Fabric chaincode, it can only have one endorsement policy and one private data collection configuration. This doesn't really map to the legal smart contracts - each contract instance will have its own set of counterparties, and these counterparties should be the ones endorsing transactions.

The second one, built by me, demonstrates how to package a contract template and a contract instance document into a Fabric chaincode package:
https://github.com/sstone1/helloworld-cicero-hlfv14/blob/master/lib/cicero-contract.js

During deployment of a Fabric chaincode in v1.4, all organizations must explicitly install the chaincode onto their peer node(s). At this point, they are also explicitly agreeing to run this chaincode on their peer node(s). In the first sample, they are only explicitly agreeing to run the generic Accord Project code. In this second sample, they are explicitly agreeing to run the contract template and the contract instance document on their peer node(s).

However, the drawback of this approach is that there is too much overhead to creating new contract instances. Each Fabric chaincode gets built into a Docker container, so if you wanted 10,000 contract instances, you would have to have 10,000 Docker containers - this will likely cause operational problems.

Instead, based on the discussion on Slack and on the technology working group call, I think we favour something inbetween these two samples. This approach would be:

• An Accord Project contract template (.cta) file can be easily packaged into a Fabric chaincode package (.cds) file
• The Fabric chaincode package can be installed onto each organizations peer node(s), at which point they are explicitly agreeing to run the contract template (which contains the Ergo logic)
• The Fabric chaincode package can be instantiated on a channel
• Contract instances (instances of the contract template) can be created by submitting transactions to the chaincode; in order to provide explicit approval, this should be a multi stage process (for example - propose contract, approve contract, commit contract)

This approach solves some of the problems with the above samples - contract templates and contract instances are always explicitly approved, and the overhead of running multiple contract instances is low - however it does not solve the endorsement policy and private data collection configuration problem; there would only be one template per contract template per channel.

However, Fabric v2.0 will be introducing a new chaincode lifecycle, that allows a single chaincode package to be instantiated multiple times on a channel with different names, different endorsement policies, and different private data collection configuration problems - all without spinning up a Docker container per instantiation. This would IMO be the ideal approach, as each instantiated version could be a contract instance, with its own endorsement policy and private data collection configuration suitable for the parties in that contract instance.

I know Fabric v2.0 is not released yet, but given it's early days with this integration work, I think we'd be okay with a less optimal approach in Fabric v1.4 for now - with the aim to move this to Fabric v2.0 as soon as it's available?

We should look to build a sample and tutorial that demonstrates how to use an Accord Project legal smart contract on top of Hyperledger Fabric, along with an application. Hopefully this is a case of using an existing Accord Project sample and just switching where the contract gets executed.

Following on from #1, once a legal smart contract is deployed to Hyperledger Fabric - what happens if and when:

• The contract template needs to be updated?
• The contract data needs to be updated?
• The set of counter parties in the contract change?
• The contract "completes"?

These events may not even be possible, but it would be good to clarify.

Hyperledger Fabric supports a set of programming languages:

• JavaScript, TypeScript, Java, and Go for smart contracts
• JavaScript, TypeScript, and Java for applications (Go is there, but it's difficult to use)

Currently the Accord samples are all written in JavaScript, using the JavaScript version of the Cicero engine. Do we need to consider any of the other programming languages? Can users write applications that interact with a legal smart contract using any supported programming language?

We need to decide on how Hyperledger Fabric endorsement policies fit in best for Accord Project legal smart contracts - from what I've seen, sometimes these may be comprised of an explicit set of counter-parties from the contract instance, or this might be a %age of a network when the Fabric network is being run by other parties.

This is probably a documentation task, but you could imagine some form of tooling for generating suitable endorsement policies from a contract instance.