AKC core redesign

[squamosa89]

The first phase of Loyalstar, AKC core (1.0) design is "completed". In the current design, we use basic Hyperledger Fabric Chaincode design to implement loyalty point exchange. Unfortunately, the current design, while it is working, is not suitable for a bigger picture of AKC, that is building a Blockchain as a service system.

In order to rebuild AKC (1.1), I am writing several proposals that will complete change the current system behavior. The main problem is that the previous design mostly based on general knowledge on mainstream blockchain system (ETH, BTC) without taking into account many features and architecture of Fabric.

In order to speed up the system design process, there are several topics that I would require the team to study and participate in the design process. These topics are fairly new on Fabric 1.3, thus, I believe there are not many people who already have experience with those. Here are 4 topics that I would like the team to study further.

1. Cross channel communication (CCC):
   CCC is an important part in designing bridge protocol between MainChain and an arbitrary PrivateChain. The general assumption is that there should be a way for a Chaincode function to invoke other Chaincode function using: https://godoc.org/github.com/hyperledger/fabric/core/chaincode/shim#ChaincodeStub.InvokeChaincode From the documentation of this function, it seems we can only perform read-only call to other Chaincode. Further study on this topic is required to see in detail how we can use this into designing a Token on Mainchain that can be used in PrivateChain as transaction fee.

2. System Chaincode Plugin (SCP): https://hyperledger-fabric.readthedocs.io/en/release-1.3/systemchaincode.html SCP is a special Chaincode that runs inside a peer node process, rather than in an isolated docker container like user Chaincode that we are currently using. While the basic syntax is similar to user Chaincode, SCP is much more powerful and allows us to call other system low level functionalities that the basic Shim interface does not provide. I think SCP is a great way to implement Mainchain that is required for all peers. We must study how to implement SCP, what other system functions that we can invoke from a SCP and how to enable CCC between SCP and a normal user Chaincode.

3. Key level endorsing policy (KEP): KEP is a new feature in Fabric 1.3 (https://hyperledger-fabric.readthedocs.io/en/release-1.3/endorsement-policies.html#key-level-endorsement). KEP allows us to customize endorsement policy for each transactions, rather than the static endorsing policy that we must specify when deploy Chaincode. While this is not a pressing concern, it is very nice for us to understand how to write such feature to enable other use case later. A simple one could be: a normal transaction would only require endorsement from AKC and 1 more organization, while an important transaction (transfer a large amount of money) must require all node endorsement.

4. Delta based transaction (DBT) In order to improve system throughput, Fabric provides several example on how to build high throughput Fabric network using delta based transaction (DBT). Those examples can be found here: https://github.com/hyperledger/fabric-samples/tree/release-1.3/high-throughput This is an extremely important overhaul to the Chaincode structure to adapt with the growing customer base of AKC.

I would like to discuss those 4 features in detail over the next few weeks.

[GiangtranFPT]

@longnv1a + Hai SCP and KEP @squamosa89 + @GiangtranFPT DBT + CCC

[0x369142857]

Chaincode cannot invoke to change ledger data in other channels but We can get data by calling function InvokeChaincode(chaincodeName string, args [][]byte, channel string) Refer to internal repos: akc-research for more detail