You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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}=awaitthis.opts.ledgerApi.apiV1InvokeContract({contractName: this.opts.contractInstance,//Loaded from deployed contract jsons for Besu, works as chaincodeID for current fabric implementation, non required for CordainvocationType: contractInvocationType.SEND,// Optional depending on protocolmethodName: "insertRecord",//Same common, workflow for Corda's caseparams: [bookshelf],//Same commonsigningCredential: this.opts.web3SigningCredential,//As is for Besu, need to define FabricSignignCredentialgas: 1000000,//optional for Besu autoestimated by web3nonce: 1,//optional for Besu recovered by web3channelName: 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.
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:
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:
The text was updated successfully, but these errors were encountered: