Stay up to date on all things crypto and blockchain

This is a quite comprehensive and good review!

Some nitpicks:

At first, ETH2.0 will source its Ether (but not its security) from the main Ethereum chain

Because PoS blocks contain pointers to PoW blocks, if an individual client wants to, it could treat PoS finalizing a block that points to a given PoW block as finalizing that block, so we get the benefits that we were originally going for with Casper as a finality gadget. But this does depend on this PR or something like it getting merged.

The tools and contracts we’ve written for ETH1.X will likely need to be completely redesigned and rewritten for ETH2.0

There's already work being done for Solidity -> WASM compilers, and I believe a similar thing is in the roadmap for Vyper. That said, there are protocol changes, storage maintenance fees being a big one, that would make optimal contract design look different on the 2.0 chain, so big dapps would need to rewrite quite a bit.

The Phase 1 specification is much less precise and does not seem to be under active development yet.

For what it's worth, I think phase 1 is where phase 0 was ~6 months ago.

However, demand for BETH seems questionable. BETH makes a poor investment, as the one-way peg from ETH to BETH gives BETH a price ceiling of 1 ETH. Which is to say BETH can never be worth more than ETH but can be worth less.

Agree. There's no point in hodling BETH unless you're going to use it to be a staking validator.

Astute readers will have noticed FFG’s cousin, Casper CBC, in the “Ethereum 3.0” section of the sharding roadmap 

In my mental roadmap, it's moved from 3.0 to 2.1. See https://github.com/ethereum/eth2.0-specs/issues/433

CBCification of the beacon chain is literally closer to seeing the light of day than phase 2 :)

It involves a multi-phase random number generation process as well as a verifiable delay function to further frustrate attempts to manipulate the committee selection process.

I would emphasize that at least I personally intend for the beacon chain to be secure even under the assumption that the attacker chooses what all the RNG hashes are, and I would argue the current spec satisfies this assumption (how is this possible? Well, each hash only has 256 bits of entropy, and you only have computational time to check maybe 2^50 of them; with a committee size of 256, getting 85 of 128 with 1/4 stake requires 2^85 attempts, and with 1/3 stake 2^46 attempts, so security may drop to ~30% if the attacker literally can keep proposing new seeds unless they succeed, but in practice manipulating the randomness even if successful is much more expensive)

So from a security analysis point of view, the VDF and RANDAO working are not strict dependencies.

For example, while PoW chains support stateless SPV proofs and NiPoPow-summarized tracking of remote state, PoS forbids any low-state communication. Subjectivity prevents state-light attestations.

Not true! PoS light clients are definitely possible. The general approach is to use random sampling (and we can reuse the random samples used in committees) to verify a small portion of the signatures on the chain, and use this in place of verifying everything. See https://notes.ethereum.org/Irbhsn63R0W6o-r0K9mBOA for a draft of how this might work, and https://github.com/ethereum/eth2.0-specs/issues/403 for a discussion on improving security and making it more stateless.

Phase 2 — Smart Contracts

Here's the most updated links on phase 2 from my point of view:

• https://ethresear.ch/t/improving-the-ux-of-rent-with-a-sleeping-waking-mechanism/1480
• https://ethresear.ch/t/a-minimal-state-execution-proposal/4445
• https://ethresear.ch/t/cross-shard-receipt-and-hibernation-waking-anti-double-spending/4748

BTW fun fact: if we implemented these proposals and set rent to infinity, so contracts would disappear and be force-converted into receipts as soon as they are created, then Ethereum 2.0 would turn into a UTXO model :D

And you as an individual are free to use it that way, and unlike today the incentives would probably lean in that direction for at least some apps. It seems like we're taking the python-style multi-paradigm route here...

Another thing worth mentioning is the proposals to use layer 2 mechanisms to accelerate cross-shard transactions:

https://ethresear.ch/t/a-layer-2-computing-model-using-optimistic-state-roots/4481

Also, one thing that was not mentioned in the post that is still not fully fleshed out is account abstraction.

Phase 3 — Off-chain state storage

This section seems to be not very accurate. To be fair, I don't think we've really said much of anything under the "phase 3" label, and what we have said we've changed a bunch of times, so things we ourselves have said about "phase 3" are not super-accurate either. As far as I know, the only post-phase-2 stuff that we have already planned is (i) adding STARKs in a bunch of places for greater efficiency, (ii) CBC Casper if it's not already done in phase 2 or earlier, and (iii) hyper-quadratic sharding (unless quadratic sharding plus layer 2 for fast communication proves fast enough, which is totally plausible and IMO quite likely).

Stateless clients are definitely an idea we've toyed with a lot in the past though, and we definitely do need blocks to at least be statelessly verifiable reasonably efficiently...

[Cross shard transactions] From reading many proposals, it appears that there is a fundamental trade-off between immediate feedback and predictability

Agree! There are definitely many perspectives, though my personal point of view is that I lean toward a fairly simple and dumb layer 1 cross-shard communication mechanism (eg. cross-shard receipts) and then allowing users to choose between layer 2 cross-shard schemes that have better properties. In general, the optimistic state pattern found in https://ethresear.ch/t/a-layer-2-computing-model-using-optimistic-state-roots/4481 can be extended or modified in a bunch of ways.