Allow the Tick operation to be either permissioned or permissionless

[stiiifff]

Allow the Tick operation to be either permissioned or permissionless based on a set of privileged addresses. Removed the dependency to the Valence clock .. still something to be addressed (see below in comments). Cleaned up IBC Forwarder tests related to testing the fallback address (to use a test address instead of reusing clock/next contract).

closes #217

[stiiifff]

@bekauz Open a draft PR so you can already take a look. /cc @uditvira

Some points left to be addressed:

• I removed the dependency to the Valence clock. One problem thus is that the IBC Forwarder does not enqueue itself into the Clock anymore. Several options:
  • Leave it as is: the forwarder can be configured with the privileged_addresses param to allow ticking by the Covenant admin, or to be permissionless (anyone). (well .. except some of the covenant tests are obviously broken ..)
  • Bring back the dependency: just so that the contract can enqueue itself itself to the Clock (problem we don't have a concept of clock anymore in the forwarder .. which I think is best).
  • Modify the Clock contract: allow to pass a list of contract addresses in the Clock instantiate message to pre-initialize the clock Queue with one or more contract(s) (actually we already pass the list of contracts for the whitelist .. so it wouldn't be a big change). This would allow to gradually break the backward dependency between the various contracts and the clock (i.e. favor directly initializing the clock queue with the addresses to be ticked, rather than configuring a whitelist and having the contracts enqueue themselves).

[stiiifff]

Commit 6f8c91c962c35651139eb9d8eeb37a7805d8eea1 adds an initial_queue instantiation param to the Clock which should forego the need of contracts to enqueue themselves into the Clock. (option 3 above)

[stiiifff]

Remaining to do:

• Add tests to verify permissionless ticking, and permissioned ticking with more than one privileged address (e.g. Clock & Covenant admin).

[stiiifff]

looks great! just leaving a couple of (somewhat hypothetical) thoughts here, along with a few code comments.

given that in top level covenants we no longer add the ibc-forwarders to the whitelist, we could run into a situation where a forwarder is instantiated as part of a covenant, does something, and gets dequeued. now, because ibc forwarder was enqueued while bypassing the whitelist, we would not be able to re-queue it easily (e.g. firing enqueue_clock message) without update-migrating the clock's whitelist/initial queue state variables.

some ideas that come to mind:

• continue adding the forwarders to the whitelist while also doing the initial_queue
• automatically whitelist the initial queue contracts on clock instantiation
• skip the initial_queue altogether. "fire and forget" enqueue_clock messages to every privileged address on ibc forwarder instantiation

what do you think?

I think we could just leave the IBC forwarder in the whitelist, that would be the simplest thing to do. About the 3rd option, I was trying to avoid the dependency to the Clock contract .. isn't it required for the Enqueue msg ?

[bekauz]

yeah, as it stands right now - clock dependency would be required for cases where privileged_addresses would be non-empty (to send the enqueue message).

if having a dependency on the clock is a concern here, we could also move that enqueue method to covenant-utils which are used by all contracts. wdyt?

[stiiifff]

I guess that would work. But why should contracts enqueue themselves to another contract .. while the top-level covenant has all the info to act as orchestrator, and setup everything correctly (cfr. whitelist & initial_queue).

[uditvira]

Some thoughts:

• I think each of the contracts should have no notion of the clock. Enqueue logic if any should be handled only by the orchestrator (i.e., top level covenant or a human)
• A nice property here is that this will allow the clock to be instantiated by the top level covenant however we can still set the privileged addresses to be empty. This gives us the benefit of ticking any of the contracts directly or ticking the clock, both should work
• In discussion with @stiiifff, we talked about how the top level contract could expose a configuration option enabling/disabling permissionless ticking (i.e., whether the clock is in the privileged addresses or not)

[stiiifff]

Will add a few more tests before merging, and create separate issues to migrate other contracts to use the same approach (privileged addresses), and to add an option to the top-level covenant to configure permissioned / permissionless ticking.

[stiiifff]

LGTM !