portal-network-specs VS annotated-spec

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

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.