Currently, the node only knows how to control Authority contracts, but not any contract that implements the IConsensus interface.
Furthermore, the node calls the getClaim function to check if a claim has been submitted yet. This method, however, is unstable, because the error message depends on the Ethereum node implementation.
Finally, the consensus contract does not emit any event when a claim is submitted successfully. This, again, makes it harder for the node to keep track of which claims have been submitted already.
We should, therefore, improve the IConsensus interface with node developers in mind.
✔️ Solution
After discussing with @gligneul, @pedroargento and @torives, we agreed that the IConsensus interface should:
Have a function to submit claims (to be used by validator nodes)
Have a function to retrieve claims (to be used on-chain by ICartesiDApp contracts)
Emit an event signalling when a claim is submitted (to be used by validator nodes, so the validator doesn't try to submit a claim again)
Emit an event signalling when a claim is accepted (to be used by reader and validators nodes to list all claims that can be retrieved on-chain, and therefore don't need to be submitted)
As a result, we may remove the following contracts:
IHistory
History
IHistoryFactory
HistoryFactory
IAuthorityHistoryPairFactory
IAuthorityHistoryPairFactory
We can define a contract that deals with claim storage and make Authority (and Quorum in the future) inherit it. We can name it ClaimStorage. Other names are welcome!
📚 Context
Currently, the node only knows how to control
Authoritycontracts, but not any contract that implements theIConsensusinterface.Furthermore, the node calls the
getClaimfunction to check if a claim has been submitted yet. This method, however, is unstable, because the error message depends on the Ethereum node implementation.Finally, the consensus contract does not emit any event when a claim is submitted successfully. This, again, makes it harder for the node to keep track of which claims have been submitted already.
We should, therefore, improve the
IConsensusinterface with node developers in mind.✔️ Solution
After discussing with @gligneul, @pedroargento and @torives, we agreed that the
IConsensusinterface should:ICartesiDAppcontracts)As a result, we may remove the following contracts:
IHistoryHistoryIHistoryFactoryHistoryFactoryIAuthorityHistoryPairFactoryIAuthorityHistoryPairFactoryWe can define a contract that deals with claim storage and make
Authority(andQuorumin the future) inherit it. We can name itClaimStorage. Other names are welcome!