research VS portal-network-specs

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

Other blockchain networks struggle because it's not trivial for wallets to have embedded nodes. It's not even really easy to do on Ethereum since light clients are hard to use, but this is improving with better infrastructure. The other hurdle for the Ethereum ecosystem is the reliance on the web stack, which trains users that the default way to interact with these networks is through a web browser, which is another limiting factor for being able to run your own node. And so yeah, obviously people will rely on Infura. But it doesn't have to be like that, this is a just result of the technology being limited (irrationally self-imposed, with the reliance on web browsers) rather than users' true desires.

The solution is to build a different structure that eliminates the antagonistic relationships between the parties, where there's no economic advantage to scale. There's this project directly backed by EF doing that but that doesn't have VC backing and there's no token so obviously there's no hype machine pushing it along.

Or better, eventually, do in a distributed way with something like the portal network: https://github.com/ethereum/portal-network-specs

From the post:

> People don’t want to run their own servers, and never will...

Fair enough, but there are active efforts to develop ultra-light clients for Ethereum together with the concept of "portal network":

https://github.com/ethereum/portal-network-specs/

https://our.status.im/nimbus-fluffly/

> there’s not even a word for an actual untrusted client/server interface that will have to exist somewhere, and no acknowledgement that if successful there will ultimately be billions (!) more clients than servers.

I would not say there's "no acknowledgement" of this; depending on how deep you are in the space, it's pretty obvious that the goal is to have layered networks and mission specific networks (storage vs. messaging vs. consensus), all economically incentivized, that are p2p through and through, from the resource constrained devices of end consumers to the staking nodes that secure the networks. That's the hope, the goal, and the focus of ongoing efforts.

The opposite of the missing word is "a node in a p2p network".

The points made about the difficulty in evolving protocols quickly are not lost on me, but I guess I'm more optimistic than the author that it will happen relatively quickly in coming years, including this one. In the process, there will be opportunities seized where the protocols fall short and half-measures or worse (with respect to decentralization) will generate excitement for a time. That seems like "growing pains" to me.

Older blocks, transactions and receipts/logs would still be accessible through dedicated sub-protocols (eg. the Portal Network) or externally developed protocols (eg. TheGraph), in addition to a much smaller but still sufficient number of volunteer nodes and block explorers. Note that many dapps are already moving their historical data queries to TheGraph and similar protocols for efficiency.

Does this help? https://github.com/ethereum/stateless-ethereum-specs/wiki/Glossary

Reorganize the p2p network to make providing proofs simpler and cheaper; see Piper Merriam's work on this.

Piper Merriam's work on distributed state storage and state and witness availability: https://ethresear.ch/t/scalable-transaction-gossip/8660 and https://github.com/ethereum/stateless-ethereum-specs/pull/54