Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(cactus): Standardized common interface functionality transaction across connectors #604

Closed
kikoncuo opened this issue Feb 26, 2021 · 0 comments
Labels
Milestone

Comments

@kikoncuo
Copy link
Contributor

kikoncuo commented Feb 26, 2021

Currently, connectors have different interfaces due to the differences across DLT protocols features-wise.
As a developer, I want to use different protocols just by instantiating different connectors.
Ideally, just by creating a new instance with new parameters, specific to the network protocol, the rest of my code including controllers should work.

A common interface can be defined for Besu, Quorum, Fabric so far, and we will see if we can fit more to the simplified spec example shown here:

const {
        data: { success, callOutput, transactionId }, //Only one value by default bool, secondary values dependent on protocol
      } = await this.opts.ledgerApi.apiV1InvokeContract({
        contractName: this.opts.contractInstance, //Loaded from deployed contract jsons for Besu, works as chaincodeID for current fabric implementation, non required for Corda
        invocationType: contractInvocationType.SEND, // Optional depending on protocol
        methodName: "insertRecord",  //Same common, workflow for Corda's case
        params: [bookshelf], //Same common
        signingCredential: this.opts.web3SigningCredential, //As is for Besu, need to define FabricSignignCredential
        gas: 1000000, //optional for Besu autoestimated by web3
        nonce: 1, //optional for Besu recovered by web3
        channelName: mychannel //required for Fabric 
      });

Specific features like gas management for the EVM or channels for Fabric can be abstracted through default values or automated calculations.

Something critical to note here is that protocol specific features cannot be limited by the common interface, and those can be enabled through optional parameters when interacting with the nodes IE: Nonce/gas calculations, Privacy groups, multiple channels, defining notaries etc. If the common interface is limiting the protocols features it will not be used and reevaluated to see if it can fit the new requirements.

Changes to this spec will be breaking changes, it's critical to keep it as stable as possible.

Children issues are:

Besu/Quorum:

Fabric:

Corda:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant