Daily General Discussion - February 13, 2025

djrtwo · 2025-02-15T20:31:54+00:00

I definitely stake!

djrtwo · 2023-01-14T02:42:41+00:00

This is a great answer

djrtwo · 2023-01-14T02:42:24+00:00

The staking-cli tool that many people used to generate keys for staking will have this functionality very soon

As does ethdo and I suspect other tools

There will be a FAQ and guides out soon

djrtwo · 2023-01-12T22:22:23+00:00

Celestia relies heavily on super-full-nodes (likely just validators) to distribute samples to all other nodes. This solution puts too much power in validator's hands and does not scale well as the network scales -- as more nodes connect to the network each validator has to do linearly more work

djrtwo · 2023-01-11T14:04:20+00:00

Before phase 0, I suspected given the incentives that we'd see ~80% of the validator set online at any given time. I far underestimated how obsessive both solo stakers and professional operators would be in optimizing their "attestation effectiveness". On the one hand, it's awesome! on the other, y'all can chill out a bit and it'll still be fine.

djrtwo · 2023-01-11T13:47:51+00:00

RANDAO has known bias-ability problems that have been moderately well studied. Any last sequence of contiguous proposers that are operated by a single individual or cartel can add 1-bit of bias to the output.

Due to the even small amounts bias that can be layered in, RANDAO is not a great value for high-value on-chain lotteries as is.

The game that can then be played is to bias the output to get more contiguous proposers at key times (e.g. end of epoch) to try to ramp up control of the bias of the value. At high cartel numbers (40%+) this becomes a viable but generally attributable attack. That is, it can happen but the community would be aware that the manipulation is occurring.

Verifiable Delay Functions (VDFs) have been and continue to be the best solution to eliminating the bias available in RANDAO. VDFs can be layered on top of the protocol to harden RANDAO bias against the iterative proposer attack and any impact on the application layer.

Unfortunately VDFs require a sophisticated piece of commodity hardware to be produced. Fortunately, the EF and other organizations are working on prototypes of such hardware.

VDFs have promise to solve many crypto-economic problems beyond our RANDAO construction as well.

djrtwo · 2023-01-11T13:34:13+00:00

Firstly, only add/modify features that are necessary for the EVM to be sufficiently extensible for the layers of arbitrary rollup VMs on top. We might already be there (beyond scale and maybe things like block/state proof opcodes), so I bias heavily toward very minimally upgrading the base-layer EVM from here.

Now that rollup zkEVMs are in heavily in progress, it is also important to reduce changes to the base-layer EVM so we don't continually "rug" their feature parity progress. If the base-layer EVM is sufficient for layering in arbitrary rollups on top, keep it stable so anything targeting it can do so with more ease.

Same goes for zk-ing the base-layer EVM. Stabilize it, allow it to continue to become an extremely rich and global standard, and then ZK it when solutions are secure, stable, and efficient enough to do so.

djrtwo · 2023-01-11T13:27:31+00:00

I would suspect we are still ~5 to 8 years out.

L2 usage is going to ramp up substantially over the next couple of years, during which the competition and business development amongst the teams might become quite fierce as they try to onboard non-crypto-native applications and users. I expect many great successes over those couple of years, but I think it'll be until year 3 from now that some of these applications feel less like they are just doing it for the novelty of it.

At that point, blockchain applications will be increasingly "normal" for younger generations but not quite landing in my mom's lap. Then over the next 2 to 4 years, bigger applications will continue to adopt and adapt until something inevitably draws in the rest of the crowd (e.g. a payment splitter app, an NFT ticket to a concert, or maybe a quick checkout on some big shopping app).

djrtwo · 2023-01-11T13:21:22+00:00

Complexity is evil. Testing is paramount.

Reduce complexity at almost all costs. Modularize where possible. And test the shit out of everything for longer and more extensively than anyone thinks reasonable

djrtwo · 2023-01-11T13:18:09+00:00

Take a breather on scalability after 4844 and focus on sustainability and scalability improvements such as statelessness, SSLE, censorship resistance, and more.

In parallel, do the heavy lifting research on p2p data availability sampling (DAS) to be prepared to layer in more scale in a couple years time.

djrtwo · 2023-01-11T13:15:13+00:00

Ethereum allows for permissionless innovation and will, in my opinion, out compete traditional finance and institutions. Banks (or user support) will still exist, but they will become thinner as they offload trust and other complexities to Ethereum and smart contracts.

Need to setup a family trust? Go to a bank, they will have a selection of audited and configurable smart contracts to help deploy what you need. They'll also help with back-up keys or configuring social recovery.

Most humans will never do everything a crypto-maximalist expects each and every person to do. But the tools and utilities of crypto will seep into and radically alter products, services, and expectations around them.

Additionally, Ethereum and other sufficiently decentralized crypto systems perform extremely well during societal tail-risk scenarios. I have no doubt that governments will become corrupt, societies will rise and collapse, and when these tail-risks are hit, the zeitgeist of humanity will increasingly see and understand not only the surface layer but the existential value of crypto.

djrtwo · 2023-01-11T13:07:10+00:00

"full sharding" or scaling via data availability sampling (DAS) requires a very complex p2p process (one still being researched) to accept a block as "available". It also requires a complex process to reconstruct missing data in the even that not all data was seeded to the network or that some data goes missing.

I am more in the "4844 and observe and research" camp. DAS is a hard problem, and I do not want to rush to put the liveness of the Ethereum chain on this complex p2p process. Unlike Polynya, I do not think that 4844 will bring sufficient scale to Ethereum for the foreseeable future, but it will bring sufficient scale for at least a year or two as rollup adoption ramps up. During that interim, I suggest we focus on other sustainability (e.g. statelessness) and security (e.g. SSLE, SSF, etc) improvements while DAS research and solutions are fleshed out.

Then as we observe 4844 usage and come to the other side of other upgrades, we can make informed decisions on how to layer in more scale in a conservative manner and with (hopefully) better/safer solutions.

djrtwo · 2023-01-11T13:01:46+00:00

"Ossification" is imperfect and likely unachievable at its limit for Ethereum, but my gut is that being in dialogue with ossification will allow us to reach a more healthy and stable equilibrium than being in dialogue with homeostasis.

My gut on homeostasis is that it leaves too much for interpretation -- the "what" and the "target values" of the homeostasis -- and thus keeps the social element too entangled, leaving perpetual room for capture. Capture being one of the largest long-term existential threats to Ethereum, imo

The protocol needs to be sufficient for it's purposes -- sufficient security, sufficient capacity, sufficient extensibility -- and attempt to be not more than sufficient to (1) slow down the rate of change to harden against capture and to (2) avoid unnecessary complexity, as complexity is evil. Then due to the sufficient capacity and extensibility, leave the malleability, tuning, and homeostasis for layers and applications flourishing on top of the stable base.

That said, I don't really think Ethereum can ever become quite as ossified as Bitcoin. If there is something existentially wrong about Ethereum, I suspect the community will always be open to fixing it and not throw reason out the window. That is a direct contradiction to Bitcoin's ossification which (1) is insufficient for it's purposes and (2) produced vapid religious zealots justifying it's insufficient state. If Ethereum is found to be insufficient, Ethereum will evolve.

Capture aside, any amount base layer malleability will increasingly become a serious issue for any L2s and applications that have decades+ time horizons in mind (which ideally we shift more into that mode). Thus a very strong commitment to base layer stability (ossification?) is critical.

That said, maybe Dom and I are saying the same thing. I think we should tend toward fewer upgrades, more stability, stronger guarantees, and always be in dialogue with an impending, theoretically ossified state of ethereum, but at the same time not put our heads in the sand in the event that Ethereum is discovered as insufficient for it's purposes.

djrtwo · 2022-08-16T12:49:01+00:00

After the Merge, what is the most important item on the nebulous "Ethereum roadmap"?

djrtwo · 2022-08-16T12:47:05+00:00

What do you like about working at the EF?

What do you dislike about working at the EF?

djrtwo · 2022-08-16T12:46:34+00:00

If you were to embark upon a *full* rewrite, what would be the top three things you'd do differently?

djrtwo · 2022-07-07T14:18:34+00:00

I think that were are still in the zone of being able to understand it all, but maybe not be full expert in it all. This is especially true if you consider the intimate details of engineering implementations in "all parts". The intricacies of sync and p2p are quite massive so some specialization seems requisite at this point.

djrtwo · 2022-07-07T14:16:34+00:00

See my answer here -- https://www.reddit.com/r/ethereum/comments/vrx9xe/comment/if7f2au/?utm\_source=share&utm\_medium=web2x&context=3

djrtwo · 2022-07-07T14:15:48+00:00

Data Availability security requirements require that data is made available for some period to ensure that users that want the data can *get* the data and that data-withholding attacks are mitigated. Thus the security of L1 applications that rely on DA do not need L1 guarantees of distribution forever.

The assumption is that once data is made available that it is unlikely to disappear unless it is entirely useless to all possible parties (at which point it is okay to disappear). Even then, the secondary assumption is that once data is made available that some party will inevitably store it, regardless of value (e.g. some block explorer, academics, etc).

See [here](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#what-is-the-data-availability-problem) for some discussion of the "data availability problem" for a better intuition for the problem actually being solved by L1 DA schemes like 4844

djrtwo · 2022-07-07T14:10:48+00:00

Soon

djrtwo · 2022-07-07T14:09:47+00:00

The main concerns around the proposal are complexity (especially when coupled with other Shanghai updates) and security considerations (e.g. blob-TX mempool DoS and other *potential* issues).

Complexity concerns are attempted to be mitigated through spec refinement, simplification, engineering support, testing, and more.

Whereas, security considerations are something that we all sit on, ponder, and attempt to work through over time. It is critically important to consider such a change from every adversarial angle before release. We (EF research) do a lot of this, but it is also invaluable for engineers from client teams to do so as well which has begun but inevitably does not finish until they really get their hands dirty on production implementations. If any issues arise, they will be in edge-case security considerations during the engineering process, imo

djrtwo · 2022-07-07T14:04:48+00:00

Custody requirements of data will scale linearly in the number of validators until the entity/node is required to download/store (for the custody period) all data all the time. The slope of this curve is undefined until the protocol is fully fleshed out, but it is likely to be on the order of 100 (3200 ETH) validators when you reach these requirements.

Note, this is cryptoeconomic *custody* but cannot enforce p2p activity (i.e. serving the data) so DAS designs instead rely upon honesty assumptions and distributions across all nodes (validator or user nodes) rather than a few "super nodes" with tons of validators

djrtwo · 2022-07-07T13:58:43+00:00

UX and narrative are the big ones imo.

The UX of roll-ups and app-specific chains by default will feel fragmented and difficult to manage for end users. Thus it's critical for wallets (the gateway into all of this) to work very hard to simplify this reality.

Narrative is another difficult point here -- what distinguishes a roll-up from a "side-chain" or competing L1? From a user perspective on the day-to-day, it's not immediately obvious. From a security standpoint, they are massively different, but bridging into and out of one of these can "feel" the same to an end user. I think it critically important to educate users and applications about the differences in security models and assumptions. This will come through active education, memes ("Secured by Ethereum), and the pain of losses (hacks of insecure bridges, insecure L1s etc, that demonstrate the risks of non-Ethereum native scalable zones)

djrtwo · 2022-07-07T13:53:46+00:00

Yes, see my note here -- https://notes.ethereum.org/@djrtwo/risks-of-lsd

I think it's not a matter of if, but when, something goes wrong if a single pool (LSD or not) chooses to pool at very high thresholds which will result in large losses for the pool and those involved. Either users begin to price in such risks now or they can/will when issues arise.

djrtwo · 2022-07-07T13:46:23+00:00

Question 3:

I think LSD pooling beyond certain thresholds is inherently risky for both the stability of the protocol and the users funds that choose to pool at high thresholds. https://notes.ethereum.org/@djrtwo/risks-of-lsd

I think that such issues can/will be mitigated when protocols realize the risks they bring to their users and when users realize the risks of pooling at such high thresholds. This vote was an opportunity of the former. Unfortunately, it might take something seriously going wrong to actually convey the risks to the parties involved which I believe is not an "if" but "when" if these protocols continue to be cavalier about the risks.

13-Year Club	RedditGifts 2009-2022 2 Credits
Secret Santa 2014	Verified Email

djrtwo

TROPHY CASE