Extinguish `ConsensusCreated` emitted by `Authority`

guidanoli commented 1 year ago

📚 Context

As soon as one deploys an Authority contract, it emits an event called ConsensusCreated which contains the following parameters:

owner: the address that has ownership over the authority contract
inputBox: the address of the IInputBox that the authority will listen to InputAdded events

We 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 through OwnershipTransferred events (see OpenZeppelin's Ownable 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 the Authority 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 the Authority contract can be removed. This change will have cascading effects in cartesi/rollups#64, cartesi/rollups#99, and cartesi/rollups#85.

📈 Subtasks

[ ] Remove the event
[ ] Update the on-chain tests
[ ] Verify that the off-chain runs fine

gligneul commented 1 year ago

I couldn't find any mention of ConsensusCreated in the node code. So I believe we don't use it.

guidanoli commented 1 year ago

I couldn't find any mention of ConsensusCreated in the node code. So I believe we don't use it.

Great news, then! :-)

xdaniortega commented 1 year ago

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.

tuler commented 1 year ago

How can dApp will known which Consensus exists?

Through a factory.

xdaniortega commented 1 year ago

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.

guidanoli commented 1 year ago

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.

cartesi / rollups