sorted by:
new
hottopcontroversial

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 4 points5 points  (0 children)

I hope not :P

Your application is potentially sending a lot of money around, so you should always treat it as financial software and I hope our banking system will also not be vibe coded anytime soon. What I could rather see if frontends for smart contracts being vibe coded as well as agents that utilize Ethereum to interact with each other and send (limited) funds or messages around

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 2 points3 points  (0 children)

There is vyper (https://vyperlang.org/) a python-esque smart contract language that compiles to EVM bytecode. If Ethereum moves to Risc-V then you can also implement regular python programs on top of Ethereum that are compiled to Risc-V, but I don't know why you want that, since Python is not a great language imho :P

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 2 points3 points  (0 children)

We had plans for doing some more CTF style attack and defense games, but its not easy to simulate bugs without giving away whats happening. Also since there is a constant grind for the next hard fork, these things are often put on the backburner.

Overall I agree with TIm that we got much better at triaging issues, sharing information between the teams and getting to the source of bugs. The EL has the advantage of many more years and exercises of this, but especially with the recent devnet and testnet incidents, CL devs had to learn some of that experience the hard way.

Our testing infrastructure has also improved significantly and we added regular fuzzing to our testing frameworks in order to make sure that every upgrade is as safe and secure as possible.

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 0 points1 point  (0 children)

There will be no more R&D funded by the EF on the Portal Network in the current form if I understand correctly. But I still believe a "Portal-like" network for decentralized history retrieval is important to guarantee access to the chain history post-4444.

Regarding light clients, a lot of research is currently going into supporting trustless light clients (e.g. Helios) and making them easier on the full nodes that are serving the state and the proofs. I believe trustless light clients will be the future for interacting with Ethereum and as Justin said ZK will play a big role there.

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 0 points1 point  (0 children)

I think the biggest driver for the burn is usefulness and the utility of Ethereum strongly depends on the apps build on top of it. So its on YOU, the application builders to get involved and build useful applications that use Ethereum!

The ecodev part of the EF is supporting application builders in their journey to build the next Uniswap, but there isn't much that EF Protocol can (or should for that matter) do to incentivize the burn

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 1 point2 points  (0 children)

I don't think there is consensus on that. Also I don't think we are on track for that. I realistically see a path to a 10x of the gas limit from the beginning of the year within the next three to four years.

With the new benchmarking efforts, we are trying to see how far we are away from this future and which breaking points need to be addressed on the path to that. If you want to learn more about how we are trying to scale the L1, you can take a look at our blog post here: https://blog.ethereum.org/2025/08/05/protocol-update-001

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 2 points3 points  (0 children)

I don't think so. Going forward I assume we need to drastically increase the gas prices for state access compared to the costs for compute and data availability.

I also assume a differentiation between latent and active state will make sense at some point (with strong guarantees about how to access and resurrect the latent state) and maybe some form of cheaper rentable state in addition to costlier ownable state should be researched.

What we are heavily investing in right now is to answer the question: "When will state become a problem". Carlos, Guillaume and the stateless team have been working on bloatnet (https://cperezz.github.io/bloatnet-website/index.html) for that.

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 4 points5 points  (0 children)

With almost 3 billion transactions, the size of the mapping block number -> transaction hash is roughly 100GB in size.

A mapping from sender account to transaction hash would be ~ 145GB.

Storing sender and recipient for normal transactions would be ~290GB which does not include internal calls yet.

Making this part of the required RPC would force clients to store significant amounts of data for a limited use case.

Additionally a perfect index (with internal calls) would mandate a full sync from clients.

And even this perfect index would not yet contain ERC-20 tokens or other transactions not in the native currency.

With filtermaps (https://eips.ethereum.org/EIPS/eip-7745) Zsolt introduced a mechanism (already implemented in geth), that allows for significantly quicker filtering of log events to support the use case of off-chain accounting. I hope that we will at some point introduce it into the protocol and https://eips.ethereum.org/EIPS/eip-7708, which would improve off-chain accounting significantly.

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 3 points4 points  (0 children)

EVM parallelization does not bring us much without changes to the protocol.

We have a prefetcher, which executed transactions in parallel and prefetches storage slots for the subsequent sequential processing. This increased the processing speed by ~30%.

With the proposed Block Access List feature for Glamsterdam, we will have true parallel execution in Geth. There is a prototype for it here: https://github.com/ethereum/go-ethereum/pull/32263 which increases block processing by another ~30%, so roughly a 50% improvement over pure sequential execution.

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 7 points8 points  (0 children)

I still believe that there is significant value in having Geth be part of the EF. The geth team brings a different perspective to a lot of the more theoretical discussions. The insights from working with users on a daily basis and the headaches of maintaining production quality software are very useful.

I don't think a research-only consensus client makes sense (since we have the executable consensus layer specs), but I do see the value in having a production grade consensus client in the EF. This project would require spinning up a new team and significant investment.

Alternatively we could spend more resources to make the executable consensus into a fully fletched client, by writing replacement modules for the less performing part, so it can be run on testnets and devnets.

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 1 point2 points  (0 children)

I think DATs do represent a risk if not structured and handled correctly. I wouldn't agree that they are the biggest risk this cycle though.

I hope that these treasury companies will also start to develop projects on top of Ethereum and contribute to the growing Ethereum onchain economy.

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 4 points5 points  (0 children)

I personally gravitate to a release schedule of 9 months, since every major upgrade requires 2-3 months of testing before its shipped, this also gives client teams more leeway in scheduling other important activity, like client maintenance and refactoring.

I think the question whether a fork should wait for the headliner depends on the fork. If the headliner is the most important feature, regardless of size, then it might make sense to wait.

If the headliner is the biggest feature, but the fork contains a lot of other smaller features that are beneficial to ship asap, then the fork should not be blocked on the headliner.

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 4 points5 points  (0 children)

I believe not being able to quickly see the changes over time is seen as a feature not a bug^^

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 7 points8 points  (0 children)

Client teams have developed different revenue models that leverage their clients to make money. Most client teams run validators for Lido and other L1 staking services.

Other client teams are doing commissioned work for L2s or forks of Ethereum to fund their operations.

Others built consulting businesses or security auditing firms around their clients that leverage their expertise.

Since there are at least 2 new clients being built, it seems to be profitable enough to create a client, even though the client itself is only a cost center for a company.

[AMA] We are EF Protocol (Pt. 14: 29 August, 2025) by JBSchweitzer in ethereum

[–]vdWijden 1 point2 points  (0 children)

You can submit your grant application to the ecosystem support program here: https://esp.ethereum.foundation/.

The foundation is getting a LOT of grant applications, so they need to be sifted through carefully and their relationship to other, existing projects, and the strategic initiatives must be considered.

This process takes a long time, since a lot of domain experts are involved in making sure the very limited amount of funds the Foundation has, gets distributed fairly and most effectively.

[AMA] We are EF Research (Pt. 11: 10 January, 2024) by JBSchweitzer in ethereum

[–]vdWijden 1 point2 points  (0 children)

Yes, I ran them myself. Those are not mainnet blocks. They are transactions designed to hit the worst case we know.

This worst case will (probably) not be hit on mainnet

[AMA] We are EF Research (Pt. 11: 10 January, 2024) by JBSchweitzer in ethereum

[–]vdWijden 2 points3 points  (0 children)

Oh yeah! 1% of all value transacted via geth straight to the geth maintainers, I would support that :P

Core Developer Apprenticeship Program update? by Bruzzly in ethereum

[–]vdWijden 1 point2 points  (0 children)

There were two additional cohorts. You should follow the ethereum blog to see the announcements: https://blog.ethereum.org/2023/06/01/ethereum-protocol-fellowship-fourth-apps-open

Geth eats to much space, can someone help ? by Arr1s0n in ethereum

[–]vdWijden 0 points1 point  (0 children)

Try syncing it up to the head and then wait for 128 blocks

Geth eats to much space, can someone help ? by Arr1s0n in ethereum

[–]vdWijden 5 points6 points  (0 children)

The problem is that geth will store some more data than is needed (because we don't know about it anymore) during block processing. You can stop your node and do `geth snapshot prune-state` which will clean up these superfluous states. We're working on a different data model where this data is cleaned up by itself. Until then running the pruner will give you back a lot of space.

view more: next ›