Two near-term options for reducing worker gas costs

[arjunhassard]

Following discussions with @vzotova. These choices are actually feasible in the near-term but neither is a barrel of laughs.

1) Separating commitToNextPeriod (formerly confirmActivity) and mint.

Advantages:

• Stakers can choose when to mint, thereby enabling proactive gas price tactics (i.e. waiting for low prices). This is constrained by the transaction becoming too large, which may occur as quickly as following a few dozen daily commits, up to hundreds of daily commits (a more narrow range estimate to be provided).
• Stakers can choose a gas price corresponding to a longer execution time, given there is no longer the 24h constraint/risk.
• Minting accounts for approximately 50% of the gas costs associated with staking, so there is scope to significantly bring down overheads.

Disadvantages:

• Once rewards are minted, the least-bad approach to restaking is creating a new sub-stake (it is problematic to add these rewards to existing sub-stakes since that would retroactively change past reward rates, creating a discrepancy between the sum minted and what 'should have been' minted). The upshot is that that gas costs will increase at each successive mint since the sum of rewards is calculated by looping through (growing) number of sub-stakes.
• Flexibility on when to execute mint does not guarantee any savings. Indeed it may end up being more expensive if gas prices steadily rise, given the hard limit on the mint transaction size, which grows with each commitToNextPeriod.

Other:

• Stakers can restake with the same cadence as that chosen for minting (as opposed to on a period-to-period basis), which in almost all cases will reduce the compounding of rewards. This decreases subsidy-based income, especially over the long-term, but it is ultimately up to each staker, for various minting frequencies, to weigh extra gas costs against the extra income from more regular restaking. Overall, a smaller proportion of rewards distributed to restakers may be beneficial to the network as a whole, since it weakens the advantage of larger / earlier-adopting stakers, which impedes token supply consolidation.
• commitToNextPeriod costs remain the same, and depend on the A) place in line the staker's commitment is relative to others each period and B) the number of sub-stakes they've set to wind down, if any.

2) Increase period duration globally (e.g. to 1 week)

Advantages and non-disadvantages:

• The primary model of rationality for Ursula uptime currently leaned upon by the protoocl – i.e. that relatively minuscule savings associated with being offline / ignoring requests are far outweighed by the risks of damage to the service's reliability/reputation, potentially causing depreciation of the native token's value and the bulk of stakers' assets/income early on – is basically orthogonal to the enforced cadence of commitToNextPeriod.
• There isn't a large economic difference between a confirmactivitybot executing once a day or once a week. In other words, the fact a period is 24 hours is not what is compelling Ursulas to provide a reliable service.
• A seven day period would reduce the gas costs of commitToNextPeriod AND mint operations by 7x, rather than just the latter.

Disadvantages:

• Involves increasing the minimum temporal unit of a sharing policy. However, it is probable that the vast majority of use cases will necessitate far longer policy durations. The likely fee per sharing policy per week has to be extremely low to accommodate end-user budgets (see Pricing Protocol & Economics whitepaper#9), so reduced granularity should have minimal impact. Importantly, use cases that require shorter durations (e.g. vehicle-to-vehicle communication) will regardless be unsatisfied by the current minimum policy duration of 24 hours.
• Requires changes the length and breadth of the the nucypher/nucypher codebase, so may break stuff.

Bonus option:
commitToNextPeriod occurs once per week, without changing the period duration.
details and {a,disa}dvantages to be added

[cygnusv]

Are options 2 and 3 (bonus) feasible to implement once StakingEscrow is already running and people are already committing to periods and getting rewards? Because it seems like option 1 is, but I'm not immediately sure about 2 and 3...At first thought, I'd say it could compromise state consistency.

[vzotova]

Bonus option is part of the first option, and it could be done later if first approach will be chosen (even with upgrade)
2 option - I think it's possible to make it after network lunch

[vzotova]

I have idea how to solve problem with re-staking in first approach (split commit/mint):
Use restriction for max periods only for who disabled re-staking and tell everybody to mint periodically, like once a week (especially for who enabled)

[arjunhassard]

1) Separating commitToNextPeriod and mint.

Current contract:

• Can only have maximum 2 periods committed but un-minted. This implies storing 2 objects (current period & next period).
• commitToNextPeriod() function calculates the reward sum and adds restaked tokens to substakes (lockedPerPeriod[nextPeriod] += lockedTokens)

New proposal (splitting):

• Only save and store the periods committed to. Not the that downtime is already accounted for in PolicyManager.
• When mint called, traverse through all committed but unminted periods to calculate reward.
• Extensible with methods to mint more regularly during eras of relatively low gas prices.
• Committing every 24h and minting every 7 days costs ~500k gas
• COMPLICATION: Stakers deciding to mint and restake some portion (e.g. 50%) of their committed periods, then the remaining portion(s) later.
  for loop messed up: if (_reStake) {subStake.lockedValue += uint128(subStakeReward);}
• If you're not restaking then mint frequency doesn't matter. Worth noting however that compounded rewards features in many professional staker strategies and promotional material to delegators. See p10 of subsidy paper for estimated long-term income divergence, assuming daily restaking.
• DOWNSIDE: Variable minting cadence nominally provides all stakers the same tactical flexibility with respect to gas prices. However this favours deeper-pocketed who can afford higher gas prices and, given smaller operators being forced to wait for cheaper eras, supercharge their reward compounding and supply consolidation (since their relative stake size will grow even faster). On the other hand, leaving things as they are may cause a similar or worse dynamic – where smaller operators simply cannot afford to mint at all, ceding not only the ability to restake & compound but the entire reward. The forum requests for a configurable gas limit we've seen show the prospect of voluntary reward relinquishment is very real!
• How does this affect pooling? More complex to collectively decide on minting frequency? Probably not more problematic than agreeing on winding down and other stake configuration.
• Besides contract update complexity, this also implies more work elsewhere such as maintaining CLI entry points.

2) Increase period duration globally (e.g. to 1 week)

• On contract side of things, only requires changes to coefficients in economics class. No fundamental smart contract update required.
• Lengthening of periods applies equally to all staker activity, but unlike in (1), the practical impact favours smaller operators. This is because this solution decreases the cost of staking in absolute terms (e.g. $2660 -> $380 per year), savings which constitute a far greater percentage of a smaller operator's total budget.
• From a user perspective, gas savings (and their magnitude) affect the universal policy fee constraints. There will be extra logistical costs levied on certain users through the temporal increase to the minimum service unit. However these are almost certainly outweighed by the consequent lowering of fee rates at which stakers can realistically break even.
• Will less frequent committing affect honest node behaviour – e.g. waiting longer to fix problems because they have extra days until the next formal interaction with the network?
• For a less dramatic change, we can increase the period length to 2 or 3 days and still bring meaningful savings – probably far more than option 1 can. Alongside the global fee range, this parameter is an ideal candidate for regular governance-driven updates, since it impacts long-term network adoption and requires both community input and accord.

3) Other

• Using gas tokens. Will save 80-90k for commitToNextPeriod (200k -> 110k).
• As noted, 'bonus'/third solution above (committing more infrequently) also requires splitting mint and commit, and associated technical complexity. It also gives stakers the choice of when to mint, and associated centralization downside.

[vzotova]

Small remark
Committing every 24h and minting every 7 days costs ~500k gas - 500k gas only for minting in that case

[mloop1]

As a community member, currently setting up my node, I'm looking forward to see one of this solution implemented.
IMHO even delaying the network launch of a couple of weeks, if necessary, would definitely not be an issue if this means the possibility to reduce the gas costs by 3x or even more.

[oneyesoneno]

As a community member, currently setting up my node, I'm looking forward to see one of this solution implemented.
IMHO even delaying the network launch of a couple of weeks, if necessary, would definitely not be an issue if this means the possibility to reduce the gas costs by 3x or even more.

i agree with you.

[Yorkemartin]

wanted to check in to give a perspective for the team of a participating member

found out today that if you're using an infura endpoint that there is currently no way to use any gas setting lower than instant.

as a non whale / aggregator / just a normal person this makes the whole thing economically unviable for me and am planning on shutting my ursula node down until some kind of solution or amelioration is available. If I had known infura endpoints locked in instant gas prices I would have not participated in worklock.

really hoping some kind of fix is along the way for this. willing to help if I can : (

[KPrasch]

found out today that if you're using an infura endpoint that there is currently no way to use any gas setting lower than instant.

For what it's worth you can control the maximum acceptable gas price using the --max-gas-price setting which works in tandem with gas pricing strategies. If network gas prices remain higher than this amount for an entire period, your node might miss some commitments, but gives some control over operational fees while remaining as a network participant.