Please enable JavaScript.

Coggle requires JavaScript to display documents.

Ethereum Tech Decisions (Collaborating on this diagram (Use dark grey…

- - - - (2014) Slasher
        
        use penalties to solve the nothing at stake problem
        
        (mid-2014) #Vlad requiring validators to put down deposits, much larger in size than rewards, that could be taken away for misbehavior.
        
        small, only canceling out signing rewards.
    - - clients log on at least once every four months (and deposits take four months to withdraw), and clients simply refuse to revert further than that.
    - - Economic Finality
        
        once a block was “finalized”, no conflicting block could be finalized without a large portion of validators having to sign messages that conflict with their earlier messages in a way that the blockchain could detect, and hence penalize.
        
        Vlad started heavily researching mechanism design, particularly with an eye to making Casper more robust against oligopolies, and we also started looking at consensus algorithms inspired by traditional byzantine fault tolerance theory, such as Tendermint.
        
        Traditional BFT
        
        Vlad decided that traditional BFT was lame (he particularly disliked hard thresholds, like the 2/3 in PBFT and Tendermint). :red_cross:
        
        Subjective Finality: CBC
        
        validators sign messages, and if they sign a message that conflicts with their earlier message, they have to submit a “justification” proving that, in the relevant sense, the new thing they are voting for “has more support” than the old thing they were voting for, and so they have a right to switch to it.
        
        Vitalik: Research PBFT
        
        Plausible liveness
        
        Accountable safety
        
        4 slashing conditions
        
        simplified to 2 slashing conditions
        
        (Jan, 2017) Parametering Casper: Time to finality/ Decentralization / Overhead Trade off
        
        Aim for high decentralization and low overhead
        
        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
        
        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
        
        make validating less accessible. Work on improving decentralized stake pooling software as a second-best to base-layer decentralization.
        
        From validator count to minimum staking ETH
        
        3 more items...
        
        consensus by bet
  - - - CBC
        
        latest message-driven GHOST (adaptation of GHOST to proof of stake)
    - - FFG
        
        start off with hybrid PoS, using proof of work as the base fork choice rule
  - - - Penalize both sides hard (Vlad’s preference)
        
        Discouragement attack: attackers could credibly threaten to make a 51% attack that causes everyone to lose money, thereby driving everyone else to drop out, thus dominating the chain at near-zero cost
      - Split the chain into two, penalize one side on each chain, and let the market decide which chain is more valuable (Vitalik preference). triangle of harm
      - Penalize both sides a little
    - - (Dec, 2017) suspicion scores
      - (Aug, 2018) 99% Fault Tolerant Consensus
  - - - Block Proposer
        
        Proof of Work
        
        (2017~ Jun 2018) Hybrid Casper contract version
        
        Unfortunately, development of FFG then slowed down. The decision to implement FFG as a contract made some things easier, but it made other things harder, and it also meant that the eventual switch from EVM to EWASM, and single-chain Casper to sharded Casper, would be harder.
        
        The premise of being able to parallelize vote txs with normal txs is flawed. To achieve this, the contract would need to be heavily doctored to hide certain state from outside reads (while allowing reads from clients) and to change some of the logic to happen during the epoch initialization rather than throughout the epoch. We would also need to divide the epoch into a "administrative" phase (registration, logout, slashing) and a "voting" phase (last 37 blocks of epoch) in which no admin activities can occur.
        
        Random Beacon
        
        (2018) Full Proof of Stake
        
        See Shasper section :checkered_flag:
- - - - take advantage of all of these extra signatures to make the chain much more “stable”, getting “100 confirmations” worth of security within a few seconds.
        
        Attestation 2
        
        Attestation 1
      - BLS signature aggregation makes this practical in terms of computational overhead
    - - Require strong on-chain randomness
        
        on-chain randomness is hard
        
        RANDAO exploitability analysis
      - Verifiable Delay Function #Justin
      - Immediate message driven GHOST (originally "recursive proximity to justification" or "RPJ")
        
        This reduce the dependence on proposers, allowing the chain to grow uninterrupted even if >90% of proposers are malicious, as long as >50% of attesters are friendly.
        
        Has stability, yay!
- - - - in-protocol decentralized exchange
        
        one can construct "pathological tokens" that have rules that are designed to treat any in-protocol penalties as a no-op.
        
        So doing this securely would possibly depend on some form of "on-chain governance", which is obviously a huge attack vector ( https://vitalik.ca/general/2018/03/28/plutocracy.html ). :red_cross:
        
        would need to be subsidized to be secure :red_cross: