Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Beefing up the Coordinator: Restrictions to initiator, ritual duration, fee model, automatic TX reimbursements, etc #86

Merged
merged 22 commits into from
Jun 29, 2023

Conversation

cygnusv
Copy link
Member

@cygnusv cygnusv commented Jun 9, 2023

This is an omnibus PR that addresses several pending functionalities for the Coordinator. From a subjective order of relevance:

  1. Introduces fee models: initially we're just introducing here a basic IFeeModel interface that allows to calculate initiation costs, but that could be later extended to manage other payment inputs. For this PR, I'm instantiating the interface with a simple FlatRateFeeModel, where ritual initiation cost is just dkg_size * duration * rate and the currency is assumed to be an ERC20 token. We also introduce duration as a parameter to initiate rituals.
  2. Introduces an access-controlled role for initiating rituals, as well as a one-off switch to unleash ritual initiation. The proposed model works as follows:
    • Initially, Coordinator contract works in permissioned way (only addresses that have the INITIATOR_ROLE can create rituals)
    • This role can be granted by the Coordinator admin (uses OpenZeppelin access control model, see tests)
    • Admin can switch the Coordinator from permissioned to permissionless ritual initiation; at this point, the initiator role is not relevant anymore. Note that this action can't be undone.
    • Rationale for this model is that it both works for many types of deployments without changing the code:
      • It's the exact model we plan for the beta release (initially, ritual initiation is controlled by Threshold DAO but can be opened in the future)
      • For devnets and testnets, we have maximum flexibility: if we want it permissioned, we just grant initiator roles; if we want permissionless, we just call the switch.
  3. Automatic reimbursement of costs for posting transcripts and aggregations. It uses Keep's ReimbursementPool model, currently in production with tBTCv2
  4. Ensures that provided decryption request static key by nodes is 42 byte (courtesy of @derekpierre 🎸 )

Also replace contract owner for parameter administration role
Initiator is just the entity that calls initiateRitual(), needs to be authorized, and provides initial payment.
Authority is who controls ritual lifecycle going forward.
Fee Models dictate what's the cost for rituals
Also, changes AccessControl base contract for the more specific AccessControlDefaultAdminRules
Also, change isInitiationRegulated to isInitiationPublic
timeout = _timeout;
maxDkgSize = _maxDkgSize;
feeModel = IFeeModel(_feeModel);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we permit the feeModel address to be updated by the proper role?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's possible, but I'd rather handle that in a later PR, when we decide how do we want to manage fee models (see comment in L71). For our immediate needs (devnets), I don't foresee we will want to change the fee model

@cygnusv cygnusv changed the title Initiator, ritual duration, fee model, etc Beefing up the Coordinator: Restrictions to initiator, ritual duration, fee model, automatic TX reimbursements, etc Jun 23, 2023
@cygnusv cygnusv marked this pull request as ready for review June 23, 2023 11:33
Copy link
Contributor

@theref theref left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great

ape-config.yaml Show resolved Hide resolved
Copy link
Member

@arjunhassard arjunhassard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huge step towards v7.0.0 👏

It may be that:
(i) educating stakers on reimbursements
(ii) adding it to staker UX
(iii) maintaining & updating this section of the contracts
may be more trouble than it's worth during genesis given that they will be 'paid back' by duration-based fees within a few days).

Also, allowing permissionless ritual initiation is predicated on those rituals being far cheaper, so it's hard to know ex ante whether the reimbursements will be enough to justify the gas of withdrawal, and also exactly what the reimbursement could be bundled with and on what layer!

uint256 size = providers.length;
require(duration > 0, "Invalid ritual duration");
require(size > 0, "Invalid ritual size");
return feeRatePerSecond * size * duration;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the proposal contains a default duration fixed at 182.5 days for initialization
and then top ups are fixed at 30 days (payable every 30 days) to keep the availability horizon 182.5 days into the future

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this something you would expect to be hardcoded at the smart contract level?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm opening an issue to track top-ups #93

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No not hardcoded, as ofc we may need to change these. Just wanted to note the likely genesis defaults, pending feedback. However there is a small question of trust implications post-v7.0.0 – ideally the Threshold DAO would control sponsorship parameters like these

stakes = IAccessControlApplication(_stakes);
}

function getRitualInitiationCost(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the 'paywall' here appears to be generating a public key for the first time, I'm wondering how a sponsor tops-up the availability horizon without a new ritual, and also if once they are conferred theINITIATOR_ROLE, they can do this unilaterally and whenever they want

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good questions. Let's track these here #93

Copy link
Member

@derekpierre derekpierre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Presumably we'll need respective nucypher changes (CoordinatorAgent etc.) before mergining into main.


// TODO: Include cohort fingerprint in StartRitual event?
emit StartRitual(id, msg.sender, providers);
emit StartRitual(id, ritual.authority, providers);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

StartRitual's 2nd parameter is indexed as "initiator":

  • Should this be ritual.initiator?
  • Should both initiator and authority be in the event?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. I meant authority here. IMO, once we introduce the authority role, the initiator is nothing more than a sponsor so there's in principle not much interest on it. In fact, once the fee is fully processed (so there's no refund), this role is not needed anymore. I would lean towards just including the authority in the event.

ritual.initiator = msg.sender; // TODO: Consider sponsor model
ritual.dkgSize = uint32(length);
ritual.initiator = msg.sender;
ritual.authority = authority;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be authority zero address?

Copy link
Member

@KPrasch KPrasch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need a matching PR into nucypher/nucypher but looks good 👍🏻

ape-config.yaml Show resolved Hide resolved
Copy link
Member

@derekpierre derekpierre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎸

@cygnusv cygnusv changed the base branch from main to development June 29, 2023 15:13
@cygnusv cygnusv merged commit d6f07bd into nucypher:development Jun 29, 2023
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants