Closed guidanoli closed 11 months ago
FYI @gligneul @miltonjonat @tuler @GCdePaula
One comment I have is that it's probably ok not to worry here about more complex or optimized interactions between the node and specific types of Consensus (e.g., asking a Quorum Consensus if enough claims have already been submitted, and not submitting if that's the case). I guess people could always come up with optional specialized nodes, and opt-in to using them if they want to take that extra step. But having a basic interface that works for general Consensus implementations enables a general node that just works (and will certainly be greatly appreciated by the likes of Sunodo)
Superseded by #152
📚 Context
Currently, the node only knows how to submit claims for the only consensus implemented,
Authority
. It uses the Rust binding for theAuthority
contract to format the function call according to the Solidity Contract ABI. Should the validator node support another consensus implementation, it would need to use its contract binding. This can lead to unnecessary complexity to the node, hindering maintainability and simplicity.✔️ Solution
It would be interesting to have a common interface for submitting claims that all consensus contracts implement. I believe a single
submitClaim(bytes)
would be enough. This function could be added either toIConsensus
or to a new interface, likeIClaimReceiver
.If we make
IConsensus
have this function, it would mean that all consensus contracts would have to implement such function, which means that the same contract is used to query and submit claims. The nice thing about this solution is that it avoids the creation of a new interface, and that you can just callgetConsensus
on aCartesiDApp
contract, and that's the contract that will be used to submit claims. Very intuitive.If we create a new interface instead, these things could be potentially decoupled: one contract for querying and another for submitting claims. I am not sure whether this would be necessary, however. For
Authority
andQuorum
, it seems to me that it is not necessary. It does give us another degree of freedom for developing contracts, but discovering the contract used for claim submission is not as straightforward as callinggetClaim
on theCartesiDApp
contract.