research VS annotated-spec

Vitalik teases twitter that "Sharding is coming" with the release of research code, and provides more info here

Casper Version 1 Implementation Guide sees the light.

I would definitely love for there to be more work on ZK programming languages. Exposing the internals more to help people do this was one of my motivations for attempting the task of making my own PLONK implementation. We need more tools to help people write circuits, and verify circuits; we should get to the point where verifying a verification key can be done eg. on etherscan as easily as verifying solidity code can be today.

> they have zero power to do anything related to consensus.

Suggest reading what Vitalik has to say if you're going to offer this kind of objection:

https://github.com/ethereum/research/blob/master/papers/disc...

Infura collects upwards of 80 percent of the fees that flow into Ethereum and is in a position to control exactly who participates profitably. If your solution is "minority will fork" the obvious question is surely "with what scalable infrastructure?"

The main difference between all recent Ethereum sharding proposals since ~2020 (both Danksharding and pre-Danksharding) and most non-Ethereum sharding proposals is Ethereum’s rollup-centric roadmap (see also: [1] [2] [3]): instead of providing more space for transactions, Ethereum sharding provides more space for blobs of data, which the Ethereum protocol itself does not attempt to interpret. Verifying a blob simply requires checking that the blob is available - that it can be downloaded from the network. The data space in these blobs is expected to be used by layer-2 rollup protocols that support high-throughput transactions.

Vitalik Buterin gives a (not so sneak) peek at the current version of the Casper contract.

Quite surprised at this comment. The reason I got into blockchain was _because_ of the incredibly difficult technical challenges it poses. Among the few I get to work on:

- How to implement robust p2p networking algorithms for sharding in a distributed system such as Ethereum (a very deep rabbit hole), as Ethereum is migrating to a "sharded" architecture

- How to solve the "data availability problem" https://github.com/ethereum/research/wiki/A-note-on-data-ava.... The current solution uses advanced cryptography known as KZG commitments https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-...

- How to solve the problem of "transaction frontrunning", in which miners have an asymmetric advantage in ordering transactions they put in blocks for their benefit, which can adversely affect users creating those transactions. This is a problem known as MEV (Miner Extractable Value) https://research.paradigm.xyz/MEV and there is some incredibly sophisticated work going into this problem. It is a deep engineering problem as well

I could go on and probably give you 20 other incredibly technical, challenging problems that are on the bleeding-edge of this technology. If you're interested, would be happy to chat more!

Verkle trees (very important concept): slides, doc, code

All ethereum research is open source https://github.com/ethereum/research including the cryptography they plan to use for eth2. If you want an overview of what eth2 could look like take a look at the roadmap https://twitter.com/VitalikButerin/status/1333922620857745408 or the eth2 specs https://github.com/ethereum/eth2.0-specs

My current understanding: The Sync Committee selects 512 validators to continually sign off on block header. Any block headers that get >2/3 are "valid"1, such that Light Clients using this header for verification can trust it.

https://github.com/ethereum/annotated-spec/blob/master/phase...

Here we have slashing fields in the block body where you insert your proofs of slashable offense. There are functions with a “slash” in the name that describes precise state transition.

The hard part of slashing is finding these proofs because you have to do more work than necessary to detect slashing and produce proofs - that’s what this software does. It’s more expensive to run a slasher but you need only one and it does not matter who runs it, anyone can run it. The link that you sent says that this slasher broadcasts proofs by default - that way anyone can include it.

According to Eth docs:

> One validator is randomly selected to be a block proposer in every slot. This validator is responsible for creating a new block and sending it out to other nodes on the network. Also in every slot, a committee of validators is randomly chosen, whose votes are used to determine the validity of the block being proposed.

The annotated code for this can be found in [2].

[1] https://github.com/ethereum/annotated-spec/blob/master/phase...

[2] https://notes.ethereum.org/@vbuterin/Sys3GLJbD#Misc

Here's some more info on Sync committees if you are interested. https://github.com/ethereum/annotated-spec/blob/master/altair/sync-protocol.md

The crux of the article is that the front-ends are all routing calls through centralized APIs to get their message included on the blockchain. Infura and Alchemy don't do much. They just pass a JSON-RPC message to an Ethereum node running on their servers. There is some additional indexing services they provide, but there are many open, decentralized alternatives for that such as TheGraph Protocol. And it's not unfeasible for an application to run its own Postgres instance to index data from the ETH blockchain.

As for full-fat clients on normal mobile devices, the main issue is the data requirements. Running a full node can take hundreds of gigabytes. It is possible on light hardware. People are running Beacon chain nodes on Raspberry Pis. But you do need the storage and that tends to be scarce on mobile.

Meanwhile, the Ethereum core devs are aware of this issue and are actively working towards it. They shipped the Altair hard fork this year that has adds sync committees which make it possible to do without needing the whole chain history (using merkle trees): https://github.com/ethereum/annotated-spec/blob/master/altai...

The light client to follow from those improvements is forthcoming:

It's not about validators going offline, it's about the validator set changing. To quote the annotated specs

Even a relatively light reading of the Annotated Spec[1] for Eth2 and/or the Eth Org's Proof of Stake FAQs[2] suggests the designers (and independent implementer-teams who gave feedback to designers... lather, rinse, repeat) understand it's important to consider the overall system "outside of the comfort zone".

[1] https://github.com/ethereum/annotated-spec/blob/master/phase...

[2] https://eth.wiki/en/concepts/proof-of-stake-faqs

Alpha leak: I am currently finishing up a full revision of my annotated specification for Altair, and plan to get it published in a couple of weeks. Meanwhile Vitalik's annotated spec has some info on how base rewards work under Altair.