Closed guidanoli closed 1 year ago
I couldn't find any mention of ConsensusCreated in the node code. So I believe we don't use it.
I couldn't find any mention of ConsensusCreated in the node code. So I believe we don't use it.
Great news, then! :-)
I've one concern about removing it. How can dApp will known which Consensus exists? I thought that with this event we can manage to know when a Consensus is created. What are the options for a dApp to subscribe or change consensus? it should've some way to know the existing ones.
How can dApp will known which Consensus exists?
Through a factory.
How can dApp will known which Consensus exists?
Through a factory.
Seems to be a good approach. We have to define this new feature and the set of contracts before removing all the information related with the creation of a new consenus, right? Or just have something decided to cover this.
Seems to be a good approach. We have to define this new feature and the set of contracts before removing all the information related with the creation of a new consenus, right? Or just have something decided to cover this.
This feature is defined by cartesi/rollups-contracts#25 and implemented by cartesi/rollups#64. As explained here, by removing this event, we don't lose any information, even if the contract is deployed by an EOA.
📚 Context
As soon as one deploys an
Authority
contract, it emits an event calledConsensusCreated
which contains the following parameters:owner
: the address that has ownership over the authority contractinputBox
: the address of theIInputBox
that the authority will listen toInputAdded
eventsWe argue that the
ConsensusCreated
event can be extinguished by showing that each parameter can already be retrieved in another way, or doesn't capture well how the Authority works in practice.owner
: this information is already emitted throughOwnershipTransferred
events (see OpenZeppelin'sOwnable
contract)inputBox
: this assumes that the authority will listen to exactly one input box forever. This does not take multiple input boxes into consideration. This will be the case whenever (and if) a new version of the input box contract is released and deployed. Furthermore, it makes more sense for this parameter to be application-specific, and not consensus-specific. For example, an input box could allow bigger inputs because the off-chain machine running the DApp back-end allows.✔️ Solution
We may remove the
ConsensusCreated
event from theAuthority
contract. We need to make sure this is not a breaking change for the off-chain.As a result, the
IInputBox
argument passed to the constructor of theAuthority
contract can be removed. This change will have cascading effects in cartesi/rollups#64, cartesi/rollups#99, and cartesi/rollups#85.📈 Subtasks