Core Contracts Release 3

Governance
#1

Hi Everyone,

The cLabs team is happy to announce the Contracts Release 3!

The upcoming governance proposal has the release notes found here.

The specifications will include the following changes:

  • Update Reserve.sol with support for multiple exchanges to pull assets to prepare for CIP-33.
  • Add ExchangeEUR.sol and StableTokenEUR.sol to core contracts to prepare for CIP-33.
  • Permit registered exchange to expand/contract supply on StableToken.sol #6780
  • Update BlockchainParameters.sol with CIP-21
  • Update Validators.sol with CIP-29 Implementation

Relevant links:

Anticipated governance proposal timeline:

  • Baklava
    • Date: March 2nd, 2021
    • Proposal ID: 13
  • Alfajores: March 9th, 2021
  • Mainnet: March 16th, 2021

If you have any comments or questions we suggest replying here on this forum post so as to keep the conversation asynchronous and inclusive.

We look forward to hearing your thoughts,

The cLabs team

2 Likes
Governance at a Glance
#2

It is unfortunate that something like CIP-29 is just part of this batch. All other stuff is just additions, however CIP-29 makes significant changes to incentive system.

In ideal world, CIP-29 would have instead parametrized the “grace period” variable and a separate Governance proposal would be requried to actually change the period from 12 blocks to 120 blocks.

There are legitimate reasons to oppose extending the downtime period. While from network general availability perspective it doesn’t matter if 1 node is down for 10 minutes, if nodes are flaky too often, it can lead to block times increasing from 5 seconds to 10 seconds at a higher frequency, that can have some meaningful consequences for use cases that depend on timing. (i.e. use cases like trading and arbitrage, and certain UX/UI use cases too).

But now that CIP-29 is just part of this one big batch, we have no option to actually discuss the change in isolation.

#3

CIP-29 was part of the All-Core Dev Call 3 agenda and a video is on that website of the entire call.

In the call, the community was asked about moving CIP-29 to last call and there was rough consensus to do that. Then, the was a 2 week period for everyone to review the proposal and raise any objections before it went to Accepted state.

I disagree that you have no option to discuss the change, Core Contracts Release 3 is part of the Governance Call happening this Thursday were folks can openly discuss items like CIP-29.

If the issue is implementation of the spec as part of Core Contracts Release 3 vs submitting it as a separate CGP on-chain for voting, I think that’s a valid point worth discussing. If the issue is in the specifications behind CIP-29 itself and its potential impact on the network, then I’m very curious why those concerns weren’t raised before? If it has a serious impact on the network, I welcome you to discuss it in the Governance call.

There is a precedent in the CIP Process to move a specification back to Draft Status from Accepted Status as outlined here if there is a serious flaw and core devs agree that it can be corrected and stuff. So, if you feel the consequence has an impact on the network, we can also schedule a future All-Core Dev Call to dive deep into the ramifications of such a change.

1 Like
#4

Discussion is different from official voting though. The point i am raising is that, there is difference between adding functionality to the blockchain/smart contracts, vs changing parameters of the network.

Imo, core contracts upgrades should be about code changes and functionality, and not about parameter changes.

An example would be if ExchangeEUR/StableTokenEUR contract additions also came with changes to the exchange spread. That would batch two different types of change (i.e. code/functionality change and a parameter change) and wouldn’t be ideal from either discussion or voting perspective.

#5

Thank you for engaging in this core contracts release process @thezviad! Love seeing folks involved. I’d like to address both parts of your feedback.

  1. There wasn’t enough time / opportunity to opine on this proposal

@Yaz already responded, but I would also like to point out that CIP-29 was published on December 3rd and has already been submitted for an audit after going through the entire CIP process.

  1. Network performance may suffer if the grace window is extended

I believe this was thoroughly addressed in the proposal and would love to hear which parts of our reasoning you disagree with. One bit that I will call out here though (excerpted)

“Our proposal to slightly extend this window to 10 minutes will strengthen Celo while still incentivizing the most stringent uptime requirements among layer 1 protocols.”

Other layer 1 protocols are not suffering from validator downtime despite being several orders of magnitude more lenient. Why do you think Celo performance will degrade?

  1. Parameter changes should happen through governance

As our proposal outlines, we are not changing a network parameter, we are adding a new one. I suppose it is possible for all parameters to be added first and then voted on to set them, but that would very quickly cause voter fatigue as it would be a colossal amount of voting. It is standard practice to set a parameter value when adding a new parameter, which can then be changed via governance.

2 Likes
#6

I am not sure I agree on voter fatigue in this case. What I am suggesting is that, in ideal case, this change could have been done in two parts:
#1: Add a new GracePeriod parameter with a default value of 0 and a setter function and use it in calculateEpochScore (instead of hard coded value as is right now: celo-monorepo/Validators.sol at master · celo-org/celo-monorepo · GitHub)

#2: submit a governance proposal to set GracePeriod to 0.625% after contracts upgrade.

Step #1 would be just a code change. So it would just have to go through code review, code audit and just get deployed as part of standard contract upgrade process. It would just add functionality without changing anything.

Step #2 would be something that actually requires voting and would be voted on independently.

The way it was done, it will require code change once again if we ever want to change this parameter, and it will once again have to be changed without any explicit voting for choosing the threshold.

As for its effect, I did misread this originally and I thought it was extending lookback window from 1 minute to 10 minutes which could be more problematic. But now i understand that it just changes the scoring to have a grace period of total of 10 minutes in an epoch overall, which is certainly less of an issue.

1 Like
#7

I tend to agree with this separation of concerns. In fact, I left similar comments on the feature PR.

We just received the audit report for release 3 back from OpenZeppelin and they flagged the same low severity issue. Unfortunately the report is currently private, but below is the relevant excerpt:

The grace_period variable of the calculateEpochScore function in the Validators contract is hardcoded and it’s not possible to set it again to another value once the contract is deployed.
To improve flexibility and efficiency of the code base, consider implementing it in such a way that the governance can change its value without re-deploying the contract again.

I recommend we use the audit response as an opportunity to make this parameter governable.

3 Likes
Governance Proposals for March 2021