cartesi / rollups-contracts

Smart Contracts for Cartesi Rollups
https://cartesi.github.io/rollups-contracts/
Apache License 2.0
21 stars 39 forks source link

Define interface for submitting claims #143

Closed guidanoli closed 11 months ago

guidanoli commented 11 months ago

📚 Context

Currently, the node only knows how to submit claims for the only consensus implemented, Authority. It uses the Rust binding for the Authority 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 to IConsensus or to a new interface, like IClaimReceiver.

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 call getConsensus on a CartesiDApp 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 and Quorum, 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 calling getClaim on the CartesiDApp contract.

guidanoli commented 11 months ago

FYI @gligneul @miltonjonat @tuler @GCdePaula

miltonjonat commented 11 months ago

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)

guidanoli commented 11 months ago

Superseded by #152