Try   HackMD

An Alternative SaaS Design [Draft]

Orignal design at https://drive.google.com/file/d/1h8qqNlTDR_4et-3BZrGxE8r1-1WLgAzb/view
Thanks to Valdorff for providing early feedback on this document.

Modifications

  • The role of the Supernode smart contract is split into three parts: NOA Vault, NOA Node and Node Delegate
  • Multiple NOA Node instances can be used in parallel.
  • NOA Vault can not be upgraded and is responsible for holding value in the system as well as splitting rewards. It is set as the withdrawal address for each NOA Node instance.
  • Each NOA Node instance can be upgraded through the Node Delegate.
  • NOA Governance is responsible for deploying and setting Node Delegate.

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Pro: Balances Upgradeability with Minimal Trust Assumptions

  • This design allows for the necessary flexibility to address future RP core protocol changes that would require new interactions from the node wallet.
  • At the same time it's possible to make key functions of the node wallet non-upgradeable.
  • Value holding and reward splitting parts remain immutable. Note that the same immutability protecting all parties against withdrawal address changes also means that any future “withdrawal address only” functionality can not be implemented.

Pro: RPL liquidity

  • Splitting validators between multiple NOA node instances significantly improves the ability to partially withdraw RPL.
  • See the examples below comparing various scenarios with 1000 minipools with either a single "supernode" or ten NOA Node instances:

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

  • You can make this as fine as you want by creating more nodes, e.g. 100 nodes means RPL unlocks in 1% increments. But too many nodes means it becomes expensive.
  • Small nodes help with liquidity, while large nodes help reduce the total node count (and thus gas expenses), so it might be best practice to mix different NOA sizes. For example 5 x 1%, 2 x 2.5%, 2 x 5%, 8 x 10%. Meaning 5 NOA Nodes that hold 1% of RPL and minipools, 2 NOA Nodes that hold 2.5% of RPL and minipools and so on.

Cons

  • A more complex smart contract architecture means this is more difficult to implement.
  • Higher gas cost, but can be somewhat managed by number of NOA node instances.
  • Splitting RPL across multiple nodes will lead to higher voting power in a quadratic voting scheme. If this is not desired, NOA Governance could choose to only partially delegate their voting power.

References

Last changed by 
 
knoshua.eth
0
285

Read more

RPIP-49 Thoughts

If there is a node operator queue, base validators SHALL be given priority over satellite validators

Apr 3, 2024
Fraud Proof Challenge Period

Fraud Proofs have been suggested as a potential alternative for multiple oDAO duties. This section explores the security of optimistic fraud proofs and how it relates to the challenge period and other variables. The challenge period aims to protect against censorship attacks. The first type of censorship to consider is on the block builder level: An attacker can attempt to get builders to exclude the fraud proof transaction from their blocks. If they succeed for every block in the challenge period the fraud goes unreported. One could imagine an attacker using MEV boost relays for something like this, but then a single validator building a block locally during the challenge window could thwart the attack. The second type of censorship requires collusion with a majority of all validators. These validators would not only exclude the fraud proof, but would also fork out blocks from other validators that include it. This attack would require a high level of coordination since forking requires direct intervention of participants, but would be resilient against individuals building locally. Besides the high level of difficulty of both attacks, Ethereum is inherently censorship resilient: censorship creates a DoS vector that could cost validators priority fees while it lasts. It is also possible to detect forking censorship and the challenge period could increase when it is likely. Nevertheless, I believe it is possible to make censorship attacks crypto-economically not viable. These are the variables to consider in this context: The cost to exclude a transaction scales with the reward a challenger would receive for a successful fraud proof, because it determines the priority fee a challenger can pay for inclusion. The payment for censorship needs to make up for that lost reward. The cost also scales with the length of the challenge period or the number of blocks. Under block level censorship, the attacker needs to pay the reward every block, under forking censorship only for 51% of blocks.

May 25, 2023
MEV Proofs

This section looks at the potential of proving MEV stealing with the help of the beacon block root proposed in EIP4788. A relatively straight-forward approach would be to use merkle proofs against the beacon root to objectively determine when a node operator has stolen MEV according to some rule set and apply a penalty accordingly. However there are some challenges around what data the beacon root gives us access to and some limitations for what rules can be verified. State Proofs The beacon block root would give access to: The proposer_index contained in the BeaconBlock itself validators in BeaconState linking indices to pubkey and withdrawal_credentials fee_recipient, transactions, and state_root contained in the ExecutionPayload in BeaconBlockBody So unfortunately, a pure state proof approach doesn't appear to be possible with the beacon root alone. For example it would be possible to prove that:

May 25, 2023
Fraud Proof Scrubs

Instead of the current challenge period that relies on trusted oracles to scrub, this design allows fraud proofs during a challenge period to prevent the withdrawal credential exploit described in [SCRUB CHECK -WITH CRED] in a trustless manner. Design The general flow is similar to what we have now: The node operator initiates a first deposit of 1 ETH to the beacon chain. During a scrub period, a fraud proof can be submitted. a) If no fraud proof is submitted, the remaining 31 ETH can be deposited. b) If a valid fraud proof is submitted, the minipool is scrubbed: ETH is returned to liquid stakers and RPL is slashed and awarded to the person providing the proof.

May 24, 2023
Read more from knoshua.eth
Published on HackMD