Atlas Discussion

Hi all,

To be honest, we’re late to this party, but better late than never.
Let’s talk about Atlas - what would we like it to be.

I put up a branch with 3 relevant RPIPS:

From RPIP-12:

Atlas will implement the following high-level features:

  • LEB8s
  • Use queue ETH
  • Include queue capacity in maximum deposit size
  • Scale assignments with deposit size
  • SaaS
  • Minor cleanup
  • Removal of total effective RPL stake

Contention

I will post polls for each significant point of contention I have seen in discussion.
Please vote in the polls so we can see how split opinion is.

At this time, I can think of 2 points of contention.

How should we use queue ETH

As currently written in RPIP-12, we are using queue ETH and the “excess” rewards are going to rETH holders. By “excess” I mean the rewards coming from validators that are running using queue ETH (after the NO takes their share).

  • We shouldn’t use queue ETH - it should stay idle
  • Use queue ETH; the “excess” rewards should go to rETH holders
  • Use queue ETH; the “excess” rewards should go to the pDAO
  • Use queue ETH; the “excess” rewards should go to the NOs in the queue
  • No preference
  • I have asked for more information below, which I need to decide

0 voters

SaaS

As currently written in RPIP-13, the supernode delegate is upgradable by RP (via the oDAO). It is not upgradable by the SaaS provider. If it were upgradable by the SaaS provider (not the oDAO), this would mean the end user needs to trust the SaaS provider not to, eg, steal funds. As written, instead the end user and SaaS provider need to trust the oDAO. Note that even if it’s written as an RP contract, a SaaS provider can choose to copy it so they retain control of upgrades (see the comment from @Wander making the case that they would).

  • It’s good as written; it should be upgradable by the oDAO
  • It’s good as written, but should not be an RP-controlled contract; it should upgradable by SaaS providers
  • RP shouldn’t provide a SaaS layer
  • No preference
  • I have asked for more information below, which I need to decide

0 voters

Thanks Val for making the forum thread! There’s already been some great discussion of this topic here: Discord

I won’t repost my thoughts since I’ve written a lot in that link above, but I will summarize.

Re: the first point of contention, I believe the difference between the options is small enough to not be of much consequence, so I chose the option I believe has the best UX: Use queue ETH; the “excess” rewards should go to the NOs in the queue

Re: the second point, SaaS contracts are a great addition to the RP ecosystem, but I am strongly opposed to enshrining a specific SaaS architecture in the core RP protocol, as I believe this is both unnecessary and potentially harmful in the long run. I believe the current proposal would not be used by SaaS providers anyway due to the added oDAO trust dependency.

I do support safe changes to the core protocol as needed to support a SaaS layer which strictly lives on top, however. I think we should all be very grateful to the RP team for working on a reference implementation, since this will really accelerate the SaaS ecosystem on RP.

Based on this, I voted above for It’s good as written, but should not be an RP-controlled contract; it should upgradable by SaaS providers

3 Likes

Me as a community member now…

Queue eth contention:

  • I would probably vote against if it went in as excess rewards going to queue. I think that encourages more NOs in the case where we have enough (or too many NOs).
  • I’ll be voting for the rETH version. I like idle almost as much. These are my two favorites.
  • The protocol variant is a little complex, but I could live with it.

SaaS contention:

  • I’m not sure I get the point of this contract.
  • I had thought it was for large non-crypto institutions (eg a bank or a college endowment) to have a way into getting the higher apr of commissions. I don’t see minimum deposits etc that would make this so.
  • Currently it primarily seems like a way to get around limitations we’ve purposely put into the protocol. You need to pair RPL and ETH so you have alignment. You need to stake your RPL in a minipool so pure speculators are taxed by inflation.
  • If we want to help allow ETH-only (and RPL-only), we should do so natively, permissionlessly, and trustlessly. This design doesn’t make it there imo.
    • Unless I’m misreading the code, whoever can upgrade this can do pretty much whatever including routing all rewards and any exited ETH however they wish. This means either complete trust in the SaaS provider (if they’re the upgrader) or the oDAO (if it’s a network contract)
  • Right now my vote is that RP shouldn’t provide a SaaS layer.
  • I’m looking to be convinced here. I feel a lot of people think this is valuable and I’m missing something.
Best SaaS use I can think of

A large cryptocurious-but-not-so adventurous tradfi institution could be the supernode operator. They could take in RPL from others (since they’re not adventurous enough to want this exposure) and farm out running the minipools (since they’re not cryptonative). The current contract would support this without additional trust if they kept upgrade power. [I guess this use case would lean me to having the contract, but not run by RP]

That said, they’d need to be crypto-savvy enough to upgrade the contract when needed, or at least to confirm a contractor is providing an appropriate upgrade. Non-trivial.

2 Likes

Congratz on the huge effort to write the RPIPs and also this thread Val.

Small suggestions to RPIP-12:

  • Cleanup should also remove the MinipoolDeposity.Empty type.
  • The " Scale assignments with deposit size" is not clear to me. Should start explaining the new rule (how does it scale?) and then the limit numbers. What’s the difference between scaling assignments and socialized assignments?
  • “The number of scaling assignments SHALL be the minimum of:” I believe it’s meant to be maximum. I would also suggest bringing that maximum number down from 90 as it approaches a full block. Someone paying for 50 or 60 assignments with one deposit seems more than enough.

Empty is a good call.

Clearly need to write the scaling section better since it wasn’t clear to you. Will work on it at some point, or I’ve added you to the repo, so you can contribute.

The idea for the scaling component is you assign as many as possible with your deposit, unless it would exceed 90 (this number can be tweaked a little if need be - iirc 93 filled a block, so went with 90 to hit 92 including socialized)

The socialized component is a fixed number (2).

The overall implementation: min( 2+min(as_many_as_possible_with_deposit_ETH, 90), as_many_as_possible_with_deposit_plus_dp_eth, as_many_as_waiting)

1 Like

I’m generally soured on the idea that we should implement things with known workarounds, such as sqrt/2 voting power and a saas contract that can simply be copy pasted.

Trustlessness is a core principle of ethereum and rocket pool. My vote is that the saas contract be in the domain of the saas company.

2 Likes

Hmmm… While the contract can be copy pasted, the (somewhat savvy) end customer can see if the RP-upgradable one is used or not.

That’s true. Perhaps documenting which SaaS providers have and have not done so is sufficient

Edit: voting for the odao controlled path now. This will facilitate development and Val is right as usual

Any reason you are using a constant value of 2 instead of the existing network parameter “deposit.assign.maximum” (which is currently set to 2)?

I was just explaining it. Iirc, in the PR I use the existing two parameters, one for max scaling one for socialized. Should probably edit the rpip to say they’re parameters and have those starting values.

1 Like

I’d like to propose we also include the delegate system change I devised which reduces minipool deployment gas usage by around 35%.

Most of the work is already done. The changes are minor but the result is a significant reduction in gas which means lower break even time for Node Operators.

I can’t think of any reason why we wouldn’t want to include this in Atlas.

5 Likes

I want to add some color to my previous comment based on a recent conversation in relation to the SaaS contract problem.

@kane suggested a middle ground between the upgradeability by the oDAO and a complete separation from the protocol. Namely, he suggested we use the same process that is used right now for minipools where NOs can choose to upgrade to the new “official” version or remain on the previous version if desired.

I like this idea a lot since it removes the concern of trust in the oDAO from the SaaS perspective. Given that withdrawals are on the horizon and we know an upgrade to the supernode delegate is necessary for this, it may be worthwhile to publish an “official” upgradeable version of the supernode delegate which is opt-in as Kane suggested.

In the long run, it still doesn’t allow for full customization that a SaaS provider may want, though. This means that, especially as the ecosystem matures, we’ll likely see more providers opt to deploy their own version, and the official version will still be a part of the protocol that requires maintenance.

Therefore, my view now is that we should aim to use an opt-in upgradeable structure for the supernode delegate but also commit to deprecating this in the future at some point. In my opinion, RP the protocol shouldn’t have this responsibility in the long run.

1 Like

Awesome conversation y’all, love coming here to catch up on things.
I would be most in favor of what @Wander just outlined with the supernode contract being opt-in upgradeable with an “official” version being published by the team. I would strongly oppose an oDAO controlled supernode.

2 Likes

I was wondering about a referral system for rETH we talked about before (Ledger). With Redstone we removed the lock, which should make this significantly easier. Is this something we would want to develop or is this up to the ecosystem? Is this something we want to get audited? Can we still get this into Atlas?

2 Likes

Touched base briefly with the team and then made edits to RPIP-12 and RPIP-13. The relevant changes are:

RPIP-12:

  • Added the gas saving feature @kane mentioned
  • Added the Commission Contract @knoshua suggested
  • Added removing the “Empty” deposit type to miscellaneous (@kane feel free to overrule if there’s a reason since I didn’t run this by you)
  • Tried new wording around scaling assignments (please have a look @fornax)
  • No change to “Use queue ETH” section, based on poll results

RPIP-13:

  • Added the high level idea of the upgrade split for the supernode delegate (oDAO upgradable latest version; SaaS providers decide whether to use the latest version or stay on their current one).
    • This differs from the poll result, as it provided a new option. The new option made this a lot less contentious imo (and a couple of folks commented as much).

I do not like the layout of RPIP-12. It is too large for a single yes/no pDAO vote. We do not need LEB8s or SaaS to use the queue ETH. RPIP-12 should be tossed and each individual Atlas upgrade should be voted on instead.

Example

Note that a vote on RPIP-12 (this RPIP) includes RPIP-8

This seems like a sneaky way to bundle a bunch of RPIPs together.

Even if the upgrades would be performed best together, these are each huge decisions and should be separated.

(Please correct me if I’m wrong about anything)

1 Like

As an example, queue ETH and LEB8 code are intermingled, because they both touch the workings of the queue. It is possible to separate them, but inefficient. It’s important NOT to get in the way of dev by micromanaging. My initial preference would be that things that are contentious should either get their own vote or, better yet, simply not get included in the first place. Waiting for community consensus and a vote is a HUGE hit to dev.

If we vote far in advance of dev (months, ideally) then I think we can break it up into as many votes as we want, but that’s not where we currently are.

1 Like

I understand the sentiment. But I think it is also dangerous to think about the protocol DAO as a burden on the dev team. In my opinion, whether the dev team has put time into an idea should not be considered in determining the future of the protocol. The dev team should be following the decisions of the pDAO and not the other way around. Otherwise, the pDAO will just become a yes man to the dev team, and Rocket Pool loses its claim to decentralized protocol governance.

I am not trying to advocate for separate upgrades - yes, that would be very burdensome for any dev team - and definitely not micromanagement. Instead, I think the major pieces should be voted on separately as described in RPIP-4. So I think RPIP-12 would be breaking RPIP-4.

Maybe it would help if someone could link me to how the dev team structure + payments or incentives work so I can understand it better.

These are very big changes, and there is non negligible risk associated with integrating them. For example the added complexity can make it harder to analyze the protocol’s security and decentralization and lead to implementation bugs, like the one we saw with v1.6.1. I think separating major changes into their own proposal votes is important.

2 Likes

Regarding SaaS, if we allow the contract to be upgradable by the provider, how do we make sure that RP doesn’t suffer if the provider’s contract gets hacked or is upgraded poorly ? Are there requirements that the upgraded contracts are audited before release in our ecosystem?

It would be a PR nightmare if something bad happens with an upgrade and the fingerpointing and blame reflects back on RP and it damages the reputation of our protocol.

How do we control, monitor (or approve) the risks from any SaaS provider who decides to upgrade the supenode delegate contract ? I assume there is a core code that can’t be changed without our approval and the upgrades are adding some bells and whistles that a provider desires ?

The last I’d heard (and this is loose) was:

  • some portion not upgradable
  • some portion upgradeable by oDAO
  • SaaS provider opts in to updates

If a SaaS provider doesn’t opt into an update, in a way that hurts their clients, they’re a bad provider. When you trust someone to run your infra, you’re trusting them to do that well. The setup is trust-minimized (their incentives are aligned and they can’t just take your money), not trustless (you retain full control).

Finally, if a SaaS provider copies the contracts (with or without modification) and deploys that… Then it is 100% out of RP’s control. Anything the SaaS provider does is to their credit or blame - up to and including stealing their clients’ money via upgrade based exploits.

The best we can do is maintain a very easy to look up contract address for people to be able to crosscheck. We can also maintain a list of SaaS providers and whether they point to the canonical contract or a modified non-oDAO gated version. But that can change in a heartbeat, so the contract address is a stronger check.

(Missed this earlier: like the rest of RP’s contracts, the canonical contract would be audited, yes)