Parametrizing Casper: the decentralization/finality time/overhead tradeoff

  • Time to finality: how many seconds after H is proposed does H get finalized?
  • Decentralization - defined here as the size of the validator pool, eg. a blockchain might have space for 1000 active validators). Note that this corresponds directly to accessibility - the minimum amount of ETH needed to become a validator, but more on this later.
  • Overhead: how many messages per second do full nodes (including validators) need to verify?
  • Aim for high decentralization and low overhead, and let finality time be very long. Exchanges are used to finality times of over one hour, so tell them it’s still going to be that way.
  • Aim for high decentralization and low finality time, but require nodes to process high overhead. Tell full node operators to suck it up and accept this, and work on improving light client protocols.
  • Aim for low overhead and low finality time, and make validating less accessible. Work on improving decentralized stake pooling software as a second-best to base-layer decentralization.
  • Abandon the goal of economic finality.

Deterministic threshold signatures for Stake Pools

Note that our work on elliptic curve pairing precompiles is important because, along with zk-SNARKs, the primitive can be used to implement deterministic threshold signatures. Hence, we could have a system where we have perhaps only 100 validators at the base level, but expect that many of these “validators” will be pools. The validation code of these validators will be a verifier for a threshold signature (which can be computed in constant time), and the threshold signature proves that at least 2/3 of the participants in the pool approved the given hash. Each pool may itself have tens or even hundreds of participants.

  • Fully open: there exists a contract through which anyone can join.
  • Closed: the pool is made between a group of friends who know each other.

From validator count to minimum staking ETH

Given a validator count (eg. d = 1000), the next question is: how does that translate into another variable that matters a lot for users personally - how much ETH do they need to become a (base-level) validator? There are a few formulas for this:

  • Set some minimum deposit size (eg. 500 ETH), and let the amount of staking ETH, as well as the total number of validators (and hence either the finality time or the overhead) float
  • Set a maximum number of validators, and increase the minimum deposit size toward infinity as the number of currently active validators approaches the maximum
  • Some intermediate policy between the two, eg. one might consider setting the minimum deposit size to equal the number of currently staking validators
  • 2412 validators
  • The largest validator has size 1206000 ETH

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store