Diegorb1329/eth_magicians_forum huggingface dataset:
Title: Deployment_to_mainnet_pending__How_can_I_deploy_my
Category: Magicians

Author: devcraft1
Date: 2022-04-11T06:12:51.681Z

pending2361×369 46.9 KB
Pending deployment on mainnet. How can I resolve this?

Author: abcoathup
Date: 2022-04-12T07:09:16.888Z

I assume that you resolved by increasing the gas price.
https://etherscan.io/address/0xa4bd0bd50f12e43796ec8c50d66eef484900a7b4
Title: Coronavirus_used_to_promote_govt_bank_run_digital_
Category: Magicians

Author: AltcoinXP-Anthony
Date: 2020-03-19T05:03:15.257Z

Let’s say the governments decide to use the coronavirus to convince the populace that a government/bank run digital currency is a good thing. They can promote this as “cash is bad, it spreads germs. so we need to move to a digital cash ASAP” Then point the population to a digital currency they’ve designed… maybe even having banks mining on it to provide the illusion of safety and decentralization.
This post is to discuss possible ways to combat this.
Title: Explore_721_Standards_Process_Discussion
Category: Magicians

Author: fulldecent
Date: 2018-03-26T06:12:24.988Z

Here are the slides from our EIP presentation at Explore 721, an event in Dallas this past weekend.


docs.google.com



Standards Process
Standards Process And forking
Title: Large_Number_of_Validators_for_DVT_Testing
Category: Magicians

Author: AndyGPN
Date: 2024-04-14T18:24:52.421Z

Hi everyone,
We’ve been looking into the new distributed verification solutions, SSV and Obol, specifically. We have build a decent size cluster of nodes to experiment on, but are having trouble getting enough validators or even holETH. Our goal is to eventually move this setup to the mainnet, but we need to thoroughly test everything first.
We’d like to have at least a few hundred Holesky validators running on our machines.
Is there a way to easily obtain at least a couple thousand holETH to create the necessary validators, or better yet, are there any validators already running that we could take over? Given the current queue times, that’d be even better.
We’re happy to “return” them after a few months. I’m also happy to verify that I’m human and that this is not for a nefarious purpose. 
Thanks,
Andy
Title: Professional_Magician_Who_Loves_Ethereum
Category: Magicians

Author: integritymatters
Date: 2018-12-08T06:20:26.031Z

Found my way here via Reddit, and it really caught my eye as I’ve been an honest to goodness professional Mentalist for 22 years, and I absolutely love the potential that blockchain in general, and Ethereum specifically can offer people in terms of freedom, liberty, and radical self ownership.
Not sure how useful I can be on the coding side of things, but I’ve spent my life learning how & why people think the way that they do, and how to leverage applied psychology to influence behavior. Looking forward to lurking around here and contributing if/when it’s useful.

Author: jpitts
Date: 2018-12-08T18:33:18.343Z

Thanks for introducing yourself!
I can see an interesting application of your skills in the community: researching how certain transactions are understood to users, particularly if they are accomplished with interacting with physical objects or haptics on mobile devices. This kind of user interaction is not unlike how an audience of a magic act perceives information on cards, objects, or even concepts that are put into motion by the mentalist.
Magicians and mentalists are experts in the UX realm!
One recent example is using QR codes to transfer value such as in Austin Griffith’s “Burner Wallet” proof of concept.
https://medium.com/gitcoin/ethereum-in-emerging-economies-b235f8dac2f2
Other examples:

the use of stamps as a way to associate a digital signature with a physical object
using cards to represent Ethereum smart contract actions (perhaps through Status.im hardwallet / card https://hardwallet.status.im)

Author: integritymatters
Date: 2018-12-09T18:17:37.515Z

That’s what I’ve said for a long time! My educational background is in fine art & design, and I’ve always seen a huge parallel in how magicians go about designing their effects and how designers create websites, apps, posters, or anything else that requires interaction with the user. It’s a connection that very few recognize or appreciate, so it’s awesome to see you recognize it.
The only place a magical effect exists is in the minds of the audience. It’s not real, you can’t point to it, but I still get paid good money to make it happen. It’s a meta-product of sorts, and it’s designed from the beginning to the end. Every gesture, word, and interaction is carefully choreographed.
I see Ethereum as a the magical substrate that makes a lot of meta-experiences possible, and I’m super stoked about it.
Title: ETHReport_2018_Released
Category: Magicians

Author: andytudhope
Date: 2018-07-23T14:48:58.243Z

Hey good people,
We have just made https://ethreport.info live - it contains the data from over 100 interviews conducted with some of the best known developers working in and around Ethereum currently.
There are tonnes of cool ideas/issues/frustrations/opportunities in there for you to dig into, and it should be pretty easy to do that with the functionality on the site. You can read more about future plans here: https://medium.com/@cryptowanderer/the-ethprize-report-2018-831de9a9280f
Title: Inflation__stakers_profits__the_real_reasons_behin
Category: Magicians

Author: jnavy
Date: 2021-02-03T20:36:23.906Z

EIP-1559 sole purpose is to make stakers more money, while creating a fake deflationary system (burning fees) to cover the stakers inflation of ETH (~8%).
The only reason they are so against the miners is because miners are taking the profit away from stakers, stakers don’t want to wait for ETH2, they want more profits now.
I also feel its very hypocritical to talk about miners and inflation, while they have no concern whatsoever by giving stakers 8%, this will severely inflate the system, burning fees is just a gimmick to cover the fact of this inflation.
EIP-1559 is solely designed for stakers and their profits, nothing more, nothing less.
Looks like big money has officially taken over Ethereum, every future push will be to strictly benefit stakers and their returns.

Author: esaulpaugh
Date: 2021-02-04T19:14:11.680Z

If 10% of ETH is staked at a return of 8%, inflation experienced by ETH is on the order of 0.8%.

Author: stoniestfool
Date: 2021-03-17T09:45:00.753Z

I couldn’t agree more. Many holder state miners profits should not increase with the price but at the same time just enjoyed a 5x on their holding. The hypocrisy makes me sick. I actual read someone arguing miners could just switch and mine btc.
Vatalick tweeted the acd are not manipulating the price but refused to respond to the fact only 77% of eth that would have been issued according to the yellow paper timetable has.
Title: Forming_a_new_Ring__ETH2_0_Networking_Ring
Category: Magicians

Author: mikerah
Date: 2019-03-26T11:41:05.011Z

Hey,
We are finally announcing an ETH2.0 Networking Ring. We will be working on standards and requirements around the needs of ETH2.0. With the transition to Proof of Stake and the addition of sharding, we expect a new set of networking challenges. The focus of this Ring is to help with that and make ETH2.0 a reality.
You can read more here: ETH2.0 Networking Ring · ethereum-magicians/scrolls Wiki · GitHub .
cc’ing @atoulme @zscole

Author: zscole
Date: 2019-03-26T14:34:38.423Z

Sweet! Definitely interested in helping push the ball forward on these initiatives. As you know, we’re currently working on implementing Hobbits in Artemis and Lodestar, but what should be our next steps?

Author: mikerah
Date: 2019-03-27T00:15:18.152Z

Here’s a rough sketch of what we need to do in the long-term:

Finalize Wire Protocol. We are currently using hobbits for testing and Matt Slipper has a PR with a more complete wire protocol for those with complete libp2p implementations.
Start modifying the beacon chain wire protocol in order to take into account shards in Phase 1.
Figure out networking for light clients. We can look to how current light clients in PoS networks like Cosmos handle this.
Figure out networking privacy. I am currently working on this with another researcher and have been onboarding him to our efforts. He should be able to contribute soon.

Author: atoulme
Date: 2019-04-12T15:49:06.693Z

Happy to participate. I will be at the core dev meeting in Berlin next week. I will present hobbits there.
Title: Solidity_Mathematical_Expression_Interpreter_Libra
Category: Magicians

Author: YoungDeveloper78
Date: 2023-09-28T08:31:06.556Z

Title: Solidity Mathematical Expression Interpreter Library
Description:
Hello Ethereum Magicians community,
I’m excited to introduce a Solidity Mathematical Expression Interpreter Library. This library is designed to enable mathematical expression interpretation within the Ethereum ecosystem while providing support for integers.
Features:

Mathematical Expression Parsing: Our library can parse and evaluate mathematical expressions that include operators such as +, -, *, /, %, and ^, as well as parentheses for defining the order of operations.
Solidity Compatibility: The library is written in Solidity, making it easy to integrate with smart contracts on the Ethereum blockchain.
Safe and Secure: While this library provides powerful mathematical capabilities, it’s crucial to exercise caution when processing untrusted input strings.

Use Cases:

Smart Contracts: You can use this library in your Solidity smart contracts to perform complex mathematical calculations within the Ethereum network.
DeFi Applications: DeFi projects often require mathematical operations. Our library simplifies these calculations within DeFi protocols.
Custom Calculations: If your project involves custom mathematical operations, this library provides a flexible solution.

Please Note:
This library is provided “as is,” and I make no guarantees about its correctness or suitability for any specific purpose. It’s important to thoroughly test and validate its functionality before deploying it in a production environment.
GitHub Repository: Math Interpreter Solidity GitHub
I’m eager to hear your thoughts and feedback on this library. Let’s discuss its potential applications and any improvements that can be made.
Feel free to ask questions, share your insights, and explore how this library can benefit the Ethereum community.
Thank you for your time, and I look forward to our discussions!
Best regards, Parsa Rahbaran

Author: YoungDeveloper78
Date: 2024-10-20T11:47:43.835Z

ParsaRahabarn/Math-interpreter-solidity
Title: Proposed_private_funding_model___3_Years_To_Open_
Category: Magicians

Author: jpitts
Date: 2019-02-22T00:48:06.622Z

I wonder if fast-moving private units could form around projects such as the EVM, Ethereum 1x, usability, privacy, etc. with investors and experienced startup leads.
These units would be structured in the same manner to reduce confusion. The work, kept proprietary, with a legal agreement that regular releases are made to public under an open source license in 3 years.
Hence, “3 Years To Open”, or 3YTO.
Ethereum ecosystem teams e.g. EF-funded projects, ConsenSys projects, etc. could get preferred access to the work, but have to pay far more than if they had granted full funding early-on.
3YTO units would be free to sell access to the work to anyone, including Ethereum competitors, but the 3 year open source release rule would have to be maintained.

Author: boris
Date: 2019-02-22T06:40:46.728Z

There is so much turmoil around open source licenses right now that (eg Redis and Mongo altered licenses to try and block cloud providers) that I don’t know if tinkering with that aspect makes sense.
Aragon’s multiple teams approach seems healthy — although they still all operate with what is essentially “startup investment”, so long term sustainability is up to each team.

Author: owocki
Date: 2019-02-28T15:09:44.630Z

Hi from the EThmagicians Business Models ring. Someone sent us a link to this thread.
Whats a ‘fast moving private unit’?  Is that just a token that moves fast?

Author: jpitts
Date: 2019-02-28T22:36:02.592Z

LOL, no, I should have explained better. I was thinking of a small development team with a product manager and project manager. Still, some fast-moving tokens might be involved, to facilitate funding and compensation for participants.
Title: Improving_Network_Resilience_Despite_a_Supermajori
Category: Magicians

Author: matt
Date: 2020-06-26T19:33:08.407Z

TLDR: If Geth had multiple implementations of consensus critical code paths (e.g. EVM, state root calculation, etc) that were chosen randomly for use during each block, we could force diversity into an environment that wants to run a single client.
–
There was a great discussion in ACD 90 regarding the burnout client developers face due to the unending protocol upgrades and maintenance tasks. It was noted that client diversity helps reduce this to a degree, because in a world with many clients, one failing would not lead to a catastrophic failure where the majority of the network follows an invalid fork.
Geth currently accounts for 76% of all mainnet clients. There are numerous different ways to understand why that is the case and how to best address it. I’ll leave that for another discussion. My assumption is that this is the world we live in now and we will likely continue to live in a world with a single supermajority client for some time – so how can we build a more resilient network?
A supermajority client implies the need for 100% correctness of its consensus critical code paths. In other words, the supermajority client must be fault tolerant to maintain correctness and availability. Traditionally, non-byzantine fault tolerance is achieved via replication, redundancy, and/or diversity. In terms of achieving fault tolerance in software, only the latter is really applicable because i) code is deterministic, so running identical implementations will lead to identical results and ii) redundancy is already addressed in the consensus protocol.
Fault tolerant software is not a new concept and has been explored in many industries where high-availability is paramount. I think there is a lot of potential for integrating some of their paradigms into our client development. For example, suppose Geth dynamically loaded three different EVM implementations (via EVMC) and randomly chose a new implementation each time an interpreter was constructed. Given the distribution of Geth clients, now for a catastrophic failure to occur 2/3 of the implementations would need to incur a fault for the same input.
I’m curious to hear others’ thoughts on this, especially regarding feasibility. Not only would it be an enormous undertaking, it would slow down development by a factor of 2-3x, and require a significant growth in headcount on the Geth team. The positive aspect is that we can improve the diversity of the network ourselves without needing to convince hobbyist and companies to choose less popular implementations.
Title: How_could_this_huge_transaction_be_executed_withou
Category: Magicians

Author: hagen
Date: 2021-05-23T11:11:35.814Z

Hi  Since I have seen this transaction (which was part of a $-25-Mio-Issue on a DeFi project called xToken) I am thinking about it: 0x7cc7d935d895980cdd905b2a134597fb91004b5d551d6db0fb265e3d9840da22
It contains a bunch of expensive transactions through the wide field of DeFi space, but costed itself not a single Wei of Gas. How could that be?
I have seen on Ethercan, that it is called a “private transaction”, which was “bypassing the mempool”.
What are the requirements to submit such an transaction and even to get it into the chain accepted by other miners? It seems to me that the folks behind this transaction were their own miners, but how could they get it broadcasted into the network without the power of a bigger pool? Or was this a coordinated effort by multiple participants across several mining pools?
Thank you in advance for any thoughts that may help me here in order to understand.

Author: esaulpaugh
Date: 2021-05-25T06:08:40.174Z

All you have to do is set the gas price to zero and then mine the transaction or have it mined on your behalf.
Title: On_decoding_raw_calldata__without_the_ABI_or_signa
Category: Magicians

Author: Jon-Becker
Date: 2023-12-20T19:07:40.769Z

This will serve as discussion for my article: “On Decoding Raw EVM Calldata”
Feedback is appreciated, and helps me improve!
Note: It’s probable that this method is not 100% accurate, and can be iterated on and improved. If you notice any edge cases or bugs that I’m missing, please let me know by opening an issue or PR.

Author: wjmelements
Date: 2023-12-21T00:08:43.392Z

I think you still need signature resolution. Otherwise you don’t know the types and the decoding would be ambiguous. There are also collisions in the 4byte prefix so you really need the ABI json.

Author: Jon-Becker
Date: 2023-12-21T00:24:02.997Z

@wjmelements
Decoding various types is ambiguous, such as bool and uint<N>. However, this is not a blocker for decoding readable types from
the raw calldata, and this article outlines how we can remove some of the ambiguity when decoding raw calldata.
For my purposes, i’ve found that this method of calldata decoding is extremely accurate, and can handle decoding dynamic types (and even nested dynamic types) with ease.
Heimdall does support decoding with signature resolution, but falls back to this method if no signature is found.
So you are partially correct, yes there is some ambiguity but no, you don’t need signature resolution or ABI to obtain a decoded view of the calldata

Author: wjmelements
Date: 2023-12-21T00:41:41.805Z

Ok here is a concrete example for the ambiguous types. Suppose the 4byte calldata parameter-array is [3, 0x40, 1, 0]. Is this (3, [0]) or is it (3, 64, 1, 0)?

Author: Jon-Becker
Date: 2023-12-21T01:53:19.650Z

You are correct, this is an example of an ambiguous type. This method, and heimdall, will assume it is (3, [0]).
This does not prevent us from decoding the calldata, however. This paper does not present this method as a perfect solution — this is the closest we can get without the ABI / signature.

Author: wjmelements
Date: 2023-12-21T19:33:52.823Z

This is the right decision and should be correct almost all of the time. I suspect your code will be useful for block explorers when the contract is unverified. I will recommend it to Etherscan.
Title: SRI_style_Integrity_Digests_for_Tokens
Category: Magicians

Author: tim-cotten
Date: 2022-12-13T01:26:07.118Z

In the games industry I have a lot of discussions with traditional Web 2.0 devs about Web3 & NFTs. When we debate utility of tokens often we call back to the “degraded blockchain” problem that Lars Doucet talks about coupled with Moxie Marlinspike’s take on ERC-721 & ERC-1155 lacking any form of integrity digest for the JSON metadata that NFTs might point to. (Moxie Marlinspike >> Blog >> My first impressions of web3)
Has there been any work on this?
I implemented a simple scheme as an example in this contract: https://etherscan.io/address/0x0e20655885c38b1b5cedfff5b15289b76f3cdefc#code
The minting function requires at the time of minting that the contract owner attest a SHA-256 hash representing the contents of the JSON metadata that the tokenId points to. (There’s some additional logic in there to allow minting and burning singular instances of the token, and when burned the contract owner can re-mint with new metadata/new digest. Only if the current owner voluntarily burns their token though: it’s sort of a mutual-consent upgrade path).
It’s implemented using a getIntegrity(tokenId) method that returns a string of form {algo}-{digest} where {algo} is baked into the method itself (to save space, rather than store a uint256 pair for algo/digest) and relies on another mapping called _integrities.
This causes each mint to take an additional ~20k gas, but allows off-chain validation of the pointed to metadata in the same way SRI does it for Web 2.0.
The relevant lines in the single file compilation are 2223 - 2321.
Reinventing the wheel? Is this already a standard somewhere and I just missed it?

Author: tim-cotten
Date: 2022-12-13T01:31:35.326Z

BTW, the W3C’s spec is here: Subresource Integrity
An example implementation in HTML5 looks like:
<script
  src="https://example.com/example-framework.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>
Title: Strategies_for_capping_validator_set_size
Category: Magicians

Author: vbuterin
Date: 2022-07-01T06:45:03.943Z

Thread to talk about validator size capping strategies, including this doc:



HackMD



HackMD - Collaborative Markdown Knowledge Base
This document is incorporated into https://notes.ethereum.org/@vbuterin/single_slot_finality





And any other ideas.

Author: kladkogex
Date: 2022-07-01T12:53:19.982Z

An interesting idea is to require validators to maintain replacement price (if a new validator wants to join she would pay this price to the old validator)
Then validators would be taxed on the replacement price.

Author: vshvsh
Date: 2022-07-03T18:23:33.728Z

I think that the number of entities participating in Ethereum consensus is much, much lower than 400k (and much lower than 26 thousands, implied by the estimate of 15 validators/staker), and will be much lower for the foreseeable future. I would be very surprised if the actual number of entities operating consensus nodes of the beacon chain is over 2 or 3 thousand. The consensus algorithm, with some changes, can accommodate everyone who actually operates nodes hundreds of times over.
Thus, option 1 is entirely unnecessary. Making subcommittees from this amount isn’t needed. Option 2, in any shape, will lead to shifting out hobbyist validators, either through direct economic mechanisms or via indirect ones (e.g. just being better at timing validator entries/exists, or circumventing the native mechanism entirely to create a validator medallion market). If that’s not the desired effect, it should not be considered. I think that in general any change to a consensus protocol that makes operators’ time harder will result in professional operators dealing with it easily and unprofessional ones just finding a simpler hobby and moving on with their lives.
Option 3 is not defined very well (e.g. it’s not clear if consensus “power” and rewards are scaled with validator balance), but if there’s any solution here, it lies in scaling consensus participation power + rewards linearly with the stake of a validator. If the rewards are not scaled, small stakers will end up outpriced. If the power is not scaled, the change will result in lower security.

Author: kladkogex
Date: 2022-07-06T16:02:33.331Z

vshvsh:

I think that the number of entities participating in Ethereum consensus is much, much lower than 400k (and much lower than 26 thousands, implied by the estimate of 15 validators/staker), and will be much lower for the foreseeable future.


More than 50% is now controlled by three enities Coinbase, Binance and Lido

Author: vshvsh
Date: 2022-07-07T14:27:23.359Z

Lido is not one staking entity. There’s 28 node operators that validate chain under Lido’s umbrella.
Title: Categorizing_DeFi_lending_protocols_by_software_ri
Category: Magicians

Author: dcota
Date: 2023-02-03T02:23:16.015Z

Hi Ethereum Community,
I’d like to start by introducing myself and the project I am working on, then move on to the topic of this discussion.
I am Daigaro and I am one of the co-founders of a project called Fuji Finance. At Fuji, we built the first borrowing money market aggregator and deployed it on Ethereum in May 2021. During our journey to find product-market-fit, we learned several lessons and now we are expanding the same concept but with money market aggregation across L2s/chains.
Aggregation of money markets consists of two general concepts:


Routing users to the lending market with the best interest rate, either the highest lending APY or the lowest APR for borrowers.

Rebalancing or refinancing the assets of pooled users from a current money market to one with better lending-borrowing interest rates, meaning moving the user/users’ positions or assets to another market when interest rates are better.

While these two concepts are a technical challenge on their own, we have addressed most of them. An interesting Twitter conversation covered many of the other challenges of money market aggregation, with key players identifying challenges we have faced.
An important point to note is that money markets are not equal, meaning their risk levels are not the same. When aggregating a series of money markets, your risk exposure is that of the “weakest link” and users should be aware of this.
This problem led us to begin discussions with several groups on how this risk should be categorized. Being no experts in the matter, we bring the discussion here for the community and experts to discuss.
With the help of RiskDAO, we have synthesized the risk categories into three general fields, with ideas on how to measure them quantitatively or qualitatively:


Trust in the DAO/organization behind the money market:
1.a. Minimum economic power required to pass a vote and change the protocol parameters.
1.b. Number of entities required with enough economic power to pass a vote (looking into governance token distribution).


Trust in the code of the money market:
2.a. Amount of bug bounties relative to TVL.
2.b. Number of completed security audits.
2.c. Time elapsed since last version release.


Protocol economic risk exposure:
3.a. Exposure to volatile assets.
3.b. Exposure to low cap assets.
3.c. Exposure to “funny” stable coins and assets.
3.d. Type and reliability of price oracles used.


With that said, we open the discussion to find insights or, hopefully, reach consensus on what a proper risk rating system for money markets should be.
Title: EIP_7892__Blob_Parameter_Only_Hardforks
Category: EIPs

Author: ethDreamer
Date: 2025-02-28T17:01:28.522Z

Discussion topic for EIP-7892
Update Log

2025-02-28: Add EIP: Blob Parameter Only Hardforks

External Reviews
None as of 2025-02-28
Outstanding Issues
None as of 2025-02-28
Title: SHADOW__A_Scheme_Handler_Discovery_Option_for_Wall
Category: EIPs

Author: SamWilsn
Date: 2023-05-17T16:04:25.455Z

This proposal (affectionately known as SHADOW) is an alternative to EIP-1193 for wallet discovery in web browsers that requires no special permissions. Web pages intending to open a connection to a wallet inject an iframe tag pointing at a well-known scheme. Communication between the page and the wallet uses the postMessage API.

Author: SamWilsn
Date: 2023-05-17T16:14:19.622Z

The proposal pull request: Add EIP: Scheme-Handler Discovery Option for Wallets by SamWilsn · Pull Request #7039 · ethereum/EIPs · GitHub

Author: SamWilsn
Date: 2023-05-17T16:33:09.494Z

Some WebExtensions to show a proof of concept: GitHub - SamWilsn/wallet-demo
These show an extension replying to a postMessage using an iframe and protocol handler in both Chrome and Firefox.

Author: SamWilsn
Date: 2025-03-03T20:46:00.560Z

Could be useful for future standards: Local Peer-to-Peer API

Author: sbacha
Date: 2025-03-08T08:19:02.042Z

Was there any issues in your PoC regarding connectivity?

Author: SamWilsn
Date: 2025-03-18T20:20:18.547Z

This proposal (SHADOW) doesn’t rely on any networking, but still requires the wallet to register a scheme handler. That’s annoying for mobile/hardware wallets.
With WebRTC (or possibly this local peer-to-peer API), you get better options.
Title: EIP_7862__Delayed_Execution_Layer_State_Root
Category: EIPs

Author: Nerolation
Date: 2025-01-16T19:48:54.035Z

EIP-7862 proposes delaying the ExecutionPayload’s state_root by one block. Instead of referencing the post-state of the current block, the state_root in block n would point to the post-state of block n-1.
Find additional context here:


Ethereum Research – 25 Sep 24




Proposal: Delay stateRoot Reference to Increase Throughput and Reduce Latency

Proposal: Delay stateRoot Reference to Increase Throughput and Reduce Latency By: Charlie Noyes, Max Resnick  Introduction Right now, each block header includes a stateRoot that represents the state after executing all transactions within that...

Reading time: 5 mins 🕑
Likes: 39 ❤

Author: sbacha
Date: 2025-03-28T04:08:30.698Z

There any work or updates on this? Would like to see if relays can adopt this too

Author: Nerolation
Date: 2025-04-23T07:06:15.745Z

Yeah, currently exploring the design space.
Since yesterday, there’s also a discord channel to discuss it further:
Title: History_Expiry_Meta_EIP
Category: EIPs

Author: pipermerriam
Date: 2025-04-02T17:19:42.131Z

This topic is to discuss the History Expiry Meta EIP


github.com/ethereum/EIPs








Add EIP: History Expiry Meta


master ← pipermerriam:piper/add-history-expiry-meta-EIP



          opened 05:35PM - 31 Mar 25 UTC




            pipermerriam
          



+117
-0






This is a work in-progress of the Meta-EIP for history expiry.  I'm still active…ly working on it.

Author: sinamahmoodi
Date: 2025-04-24T15:55:59.968Z

Update from geth. The latest release includes the ability to a) offline-prune an existing datadir up to the merge block via prune-history command, b) snap sync without fetching the premerge block bodies and receipts. In both cases you will need to pass the --history.chain postmege flag to indicate a pruned history.
These are not advertised lest users get the idea to try it on mainnet before Pectra which we’d like to avoid. We have partial integration of era files with more coming in this direction.
Title: EIP_7937__64_bit_mode_EVM_opcodes__EVM64_
Category: EIPs

Author: sorpaas
Date: 2025-04-23T19:57:50.477Z

Discussion topic for EIP-7937: 64-bit mode EVM opcodes (EVM64)
Update Log

2025-04-23: initial draft
2025-04-24: EIP number is (re-)assigned to 7937
2025-04-25: Added missing SHR, SHL, SAR 64-bit mode. Updated “Rationale” section.
2025-04-25: Removed DUP* and SWAP* 64-bit mode.

External Reviews
None as of 2025-04-23.
Outstanding Issues
None as of 2025-04-23.
Title: EIP_7880__EOF___EXTCODEADDRESS_instruction
Category: EIPs

Author: shemnon
Date: 2025-02-12T22:32:36.036Z

Discussion topic for EIP-7880: EOF - EXTCODEADDRESS instruction
Update Log

2025-02-12: initial draft

External Reviews
None as of 2025-02-12
Outstanding Issues
None as of 2025-02-12

Author: wjmelements
Date: 2025-02-12T23:59:52.944Z

as the contract may be updated to non EOF code and EXTDELEGATECALL will no longer be able to call the contract

Where is this specified? It would be a severe limitation on the eof methods if they can’t call non-eof code.

Author: shemnon
Date: 2025-02-13T00:24:28.104Z

EOF1 contracts can only EXTDELEGATECALL EOF1 contracts - EIP-3540: EOF - EVM Object Format v1
This has been a restriction because of SELFDESTRUCT, we don’t want EOF code disappearing for any reason, even in neo-SELFDESTRUCT form.
EOF can freely EXTCALL and EXTSTATICCALL legacy code.
Title: Pectra_upgrade_client_releases_for_Holešky___Sepol
Category: EIPs

Author: abcoathup
Date: 2025-02-13T23:36:43.147Z

Pectra upgrade client releases for Holešky & Sepolia testnets
Pectra upgrade schedule:

Holešky: slot 3710976, Monday, February 24, 21:55:12 UTC
Sepolia: slot 7118848, Wednesday, March 5, 7:29:36 UTC





Layer
Client
Version





Consensus Layer
Grandine
1.0.0



Consensus Layer
Lighthouse
v7.0.0-beta.2



Consensus Layer
Lodestar
v1.27.1



Consensus Layer
Nimbus
v25.3.0



Consensus Layer
Prysm
v5.3.0



Consensus Layer
Teku
25.2.0



Execution Layer
Besu
25.2.2



Execution Layer
Erigon
v2.61.3



Execution Layer
Geth
v1.15.5



Execution Layer
Nethermind
1.31.4



Execution Layer
Reth
v1.2.2
Title: EIP_7703__Increase_Calldata_Cost
Category: EIPs

Author: wjmelements
Date: 2024-05-08T01:57:36.899Z

https://github.com/ethereum/EIPs/pull/8529
replaces eip-7623 which is insecure

Author: OlegJakushkin
Date: 2024-05-15T22:46:31.616Z

Dear @wjmelements:
Is there any practical analysis data of the past numbers? what this would bring to the ledger in practical terms? (e. g. you had it 4 times before now its 3 just because of assigned EIP number)

How many TXs would have been affected in the last time range by such a change from all TXs in gas terms?
How much would they increase in size?
If it “allows a higher block gas limit” at the same time calldata price goes up and fills that gap - so what is expected to change?

Author: wjmelements
Date: 2024-05-15T22:53:38.893Z

OlegJakushkin:

Is there any practical analysis data of the past numbers?


No. But anecdotally, builders are discriminating against large calldata transactions because they bring more delay-risk than the gas pays for.



 OlegJakushkin:

How many TXs would have been affected in the last time range by such a change from all TXs in gas terms?


all of the ones with calldata



 OlegJakushkin:

How much would they increase in size?


I don’t understand your question.



 OlegJakushkin:

If it “allows a higher block gas limit” at the same time calldata price goes up and fills that gap - so what is expected to change?


Higher gas limit, lower gas prices, cheaper execution gas.

Author: OlegJakushkin
Date: 2024-05-15T23:16:07.256Z

all of the ones with call-data
(1) but how may are there in say a week with call data? (in occupied bock gas proportion to TXs without call-data)


I don’t understand your question.
say gas is space in a block - you increase call-data cost, then TXs with call data take more space in a block. Yet imagine people can not stop using that exact same TXs and call-data still is used in exactly in same volume. So how much that propotion in (1) would change?

Author: wjmelements
Date: 2024-05-15T23:35:18.486Z

OlegJakushkin:

say gas is space in a block - you increase call-data cost, then TXs with call data take more space in a block. Yet imagine people can not stop using that exact same TXs and call-data still is used in exactly in same volume. So how much that propotion in (1) would change?


The proportion of gas used for calldata would increase if there is no change in behavior.

Author: sbacha
Date: 2025-03-13T03:19:11.809Z

How is this different than, oh i dont know EIP-7623: Increase Calldata Cost - #32 by wjmelements ?
SELL ME THIS EIP

Author: wjmelements
Date: 2025-03-20T09:59:01.569Z

EIP-7623 only charges additional gas for calldata conditionally. The EIP-7623 condition can be exploited for gas sheltering as I explain in that post.
Title: EIP_XXXX__CALL_GAS_SPLIT_opcode
Category: EIPs

Author: rakita
Date: 2025-04-01T11:57:37.267Z

Discussion topic for EIP-XXXX: CALL_GAS_SPLIT opcode
Update Log

2025-03-27: Initial Commit

External Reviews
TBD
Outstanding Issues
TBD
Title: EIP_7778__Prevent_Block_Gas_Smuggling
Category: EIPs

Author: benaadams
Date: 2024-10-01T15:47:22.921Z

Exclude Discounts & Refunds for Block GasLimit Enforcement
Complementary to to



EIP-7623: Increase Calldata Cost EIPs core


    By increasing the calldata cost for users that do not spend more than a certain threshold on EVM computation we can achieve the following: 

Reduce maximum possible blocksize from ~1.7 MB to 0.55 MB without effects on current throughput.
Reduce block size variance
Reduce inefficienty from big gap between avg. block size and max. possible block size.
Make room for raising gas limit and/or blob count
Differentiate between users that need calldata inside the EMV vs pure DA.

This is achieved by inc…
  

Prevent the circumvention of the block gas limit by excluding certain gas discounts and refunds from block gas accounting, except for those reflecting actual reductions in computational work.
This proposal aims to align the block gas usage with the Ethereum Virtual Machine’s (EVM) real workload, preventing “block gas smuggling.” It complements EIP-7623 by further reducing the maximum block size and its variance, enhancing network stability and efficiency.
Link:

github.com/ethereum/EIPs








Add EIP: Prevent Block Gas Smuggling


master ← benaadams:eip7773



          opened 03:28PM - 01 Oct 24 UTC




            benaadams
          



+193
-0






Prevent the circumvention of the block gas limit by excluding certain gas discou…nts and refunds from block gas accounting, except for those reflecting actual reductions in computational work. 

This proposal aims to align the block gas usage with the Ethereum Virtual Machine's (EVM) real workload, preventing "block gas smuggling." It complements [EIP-7623](./eip-7623) by further reducing the maximum block size and its variance, enhancing network stability and efficiency.

Author: jochem-brouwer
Date: 2024-10-06T20:44:18.429Z

Regarding receipt encoding, what should be encoded in the receipt of the tx? We have a cumulative gas used field there. I think the encoded cumulative gas used here should reflect what gas was used in the block, i.e. evm_gas_used?

Author: benaadams
Date: 2024-10-10T15:53:42.750Z

It should be the gas used without refunds (i.e. the value used for the block gaslimit/target check); so would be higher than the sum of the gas charged per tx
Title: EIP_7916__SSZ_ProgressiveByteList
Category: EIPs

Author: zsfelfoldi
Date: 2025-03-25T10:11:02.221Z

github.com/ethereum/EIPs








Add EIP: SSZ ProgressiveByteList


ethereum:master ← etan-status:sz-progressivebytelist



          opened 03:47PM - 24 Mar 25 UTC




            etan-status
          



+72
-32






Move SSZ ProgressiveByteList to its own EIP so that it can be worked on independ…ently of the eth_getLogs filter usage.

Plans are to work with @wemeetagain to generalize it beyond byte lists, and to simplify the parameters with `CAPACITY = unbounded` as well as `COMMON_RATIO = 4`. That way, in EIPs such as EIP-6404 and EIP-6466 it is no longer necessary to define arbitrary bounds to byte lists, and in consensus we can use such an `UnboundedList[T]` construct to replace proposer / attester slashing lists (with a shared maximum allowed len), and could use it for attestations list that keeps changing across forks.

First step is to move this out to its own EIP with Zsolt as author, then do the followup work with me and @wemeetagain in separate PRs.






This EIP introduces a new Simple Serialize (SSZ) type to make List[T, N] with large capacities N more efficient in cases where the list is much shorter than the capacity.
Title: EIP_7808__Reserve_Tx_Type_Range_for_RIPs
Category: EIPs

Author: CarlBeek
Date: 2024-11-05T00:17:16.126Z

This post is for discussion of EIP 78xx  wherein the transaction-type range from 0x40 to 0x7f are reserved for use by the RIP process similar to how EIP-7587 did for precompile addresses.

Author: protolambda
Date: 2024-12-19T15:06:51.604Z

OP-Stack uses 0x7E for deposit txs from L1 into L2.
See specs/specs/protocol/deposits.md at main · ethereum-optimism/specs · GitHub
This type falls into this range.
Will there be a registry of L2 tx type usage?
Also, I believe other L2 stacks use custom tx types already as well. Arbitrum has 7 if I remember correctly.

Author: prasincs
Date: 2025-04-04T22:52:05.794Z

Where is this defined? I followed the specs but when I looked at ethereum-optimism/op-geth/blob/optimism/core/types/transaction.go#L47-L52 it’s same as go-ethereum.
whereas Arbitrum defines it here OffchainLabs/go-ethereum/blob/084f63827520569955a905596878d90d42b734a7/core/types/transaction.go#L46-L60
(sorry new account can’t link)
we can probably go through all major go-ethereum forks for the file and find if the range has any overlaps?

Author: shemnon
Date: 2025-04-05T00:18:09.148Z

EIP editors are not going to like this suggestion, but I think we should keep an open “living” RIP/RRC to enumerate chain specific TX Types, precompile addresses, etc.  This should be somewhere and it it was a RIP/RRC there is some weight of “this is the official registry.”
TX types may become the most conflicted.
Also, we should preserve some for multi-byte TX types.

Author: prasincs
Date: 2025-04-28T01:51:45.669Z

I like this idea, it’s very hard to build a scalable indexer across the ecosystem if we have to make custom rules. Having an official registry would help to ensure that we at least have the diffs recorded.
Title: EIP_______GitChain
Category: EIPs

Author: etan-status
Date: 2025-04-01T10:01:47.752Z

Discussion topic for GitChain EIP:

Add EIP: GitChain by etan-status · Pull Request #9579 · ethereum/EIPs · GitHub
EthPandaOps support

Author: etan-status
Date: 2025-04-01T13:20:23.651Z

github.com/ethereum/EIPs








        Review by
        

          wjmelements
         - Add EIP: GitChain


master ← etan-status:gc-init




This solves MEV!






Yes, ordering transactions by issue number ensures that transactions cannot be frontrun.

Author: etan-status
Date: 2025-04-01T13:21:41.569Z

This also removes all security issues and operational challenges involved with validator key management, including support infrastructure such as the generic validator request bus, and the entire engine API interaction. There is no concept of INVALID payloads.

Author: etan-status
Date: 2025-04-01T13:26:24.583Z

Wallets also no longer need to use a16z/helios to verify JSON-RPC responses. They can simply check the GitHub TLS signature and immediately know that the response is correct, immediately! No more 12s delay to wait for the sync committee signature, or 24s with ePBS, or 36s if state root computation is delayed… It’s all obsolete!

Author: etan-status
Date: 2025-04-01T13:56:00.585Z

4444 is also included:

For history, simply checkout the repository with a max --depth
For state, use Git sparse checkout to only checkout the accounts that are of interest.

The response can be validated by checking the GitHub TLS signature. No Merkle proofs etc are needed, every subpage can be verified using TLS.
It is up to GitHub to switch to PQ signature schemes for TLS in time. Notably, it does not add complexity to the blockchain, it just continues to work as is.

Author: etan-status
Date: 2025-04-01T16:05:44.451Z

github.com/ethereum/EIPs








        Comment by
        

          rkapka
         - Add EIP: GitChain


master ← etan-status:gc-init




This is a fantastic alternative to the Beam Chain! I like it much more






Yes, this proposal does not require experimental zk crypto or crazy protocols. It is straight-forward to audit, based on established tooling.

Author: bbusa
Date: 2025-04-01T18:47:57.509Z

EthPandaOps supports this EIP

Author: etan-status
Date: 2025-04-02T00:55:00.940Z

github.com/ethereum/EIPs








        Review by
        

          ensi321
         - Add EIP: GitChain


master ← etan-status:gc-init




This ensures we are censorship resistant legally 👍






It’s a good point. GitHub is available globally, including regions that have more restrictive Internet access. GitChain is also auditable, the sequential indexing makes it obvious if a transaction suddenly disappears, as it leaves a gap in the issue numbering.

Author: etan-status
Date: 2025-04-02T00:56:10.837Z

With the proposed timeline, do we have to propose it for inclusion in Fusaka? @timbeiko
Title: EIP_7903__Remove_Initcode_Size_Limit
Category: EIPs

Author: charles-cooper
Date: 2025-03-05T10:37:28.787Z

discussion topic for Add EIP: Remove Initcode Size Limit by charles-cooper · Pull Request #9452 · ethereum/EIPs · GitHub

Author: sbacha
Date: 2025-03-08T08:15:58.142Z

Is Pectra off the table for this?

Author: charles-cooper
Date: 2025-03-14T16:50:46.943Z

benchmarks (tl;dr: jumpdest analysis shows a strong linear correlation to initcodesize, at sizes ranging from 128 bytes to 15MB):



github.com


eip-3860-benchmarks/benchmark_results at master ·...
jumpdest analysis benchmarks. Contribute to charles-cooper/eip-3860-benchmarks development by creating an account on GitHub.

Author: chfast
Date: 2025-04-26T07:57:46.492Z

It is not explicitly mentioned in the benchmark summary what implementation is measured, but I’m guessing this is the C++ code in the same repo. I believe this would be more meaningful if existing implementations (e.g. geth, revm, nethermind). Also the benchmarks don’t necessarily target the worst cases. Depending on the implementation, the worst cases is some combination of PUSH1, PUSH2 and JUMPDEST.

Author: chfast
Date: 2025-04-26T08:06:38.808Z

This must be coordinated with EIP-7825 (discussed in Eip 7825: Transaction Gas Limit Cap) which is going to put its own limits on the both initcode and deploy code sizes.

Author: charles-cooper
Date: 2025-04-27T11:47:50.748Z

Can you specify what the worst case is? Happy to accept a pull request if some important case has been missed.
Title: EIP_7691__Blob_throughput_increase
Category: EIPs

Author: parithosh
Date: 2024-04-17T21:27:30.857Z

Discussion for Add EIP: Blob throughput increase by parithosh · Pull Request #8452 · ethereum/EIPs · GitHub

Author: parithosh
Date: 2024-04-25T10:40:45.414Z

When brought up at ACD, There was a point raised by Ansgar to include blob gas logic from his EIP into this one: Add EIP: Stepwise Blob Throughput Increase by adietrichs · Pull Request #8343 · ethereum/EIPs · GitHub

Author: poojaranjan
Date: 2025-03-03T11:55:20.260Z

EIP-7691 Blob throughput increase with @parithosh  @Nerolation and Sam Calder-Mason
Title: EIP_7919__Pureth_Meta
Category: EIPs

Author: etan-status
Date: 2025-03-26T13:12:14.909Z

https://eips.ethereum.org/EIPS/eip-7919

https://purified-web3.box
https://eth-light.xyz (viewer to see Mainnet transactions/receipts after SSZ conversion)
Title: EIP__Ethereum_LTS
Category: EIPs

Author: wjmelements
Date: 2025-03-31T17:39:03.202Z

Given the recent testnet complications, I present a solution clarifying the stability of Ethereum networks by classifying them as Long-Term Support (LTS) or Bleading-Edge (BE). Developers should not have the ground torn up from beneath them. LTS nets will work forever and never change, while BE nets will have the latest features.
History

Add Draft EIP
Title: EIP_7732__Enshrined_Proposer_Builder_Separation__e
Category: EIPs

Author: potuz
Date: 2024-04-12T18:29:34.357Z

Creating a topic for discussions EIP-7732


Ethereum Improvement Proposals


EIP-7732: Enshrined Proposer-Builder Separation
Separates the ethereum block in consensus and execution parts, adds a mechanism for the consensus proposer to choose the execution proposer.





Full design notes are included  in this document:



HackMD



ePBS specification notes - HackMD
Fully detailed specification notes for a minimal implementation of ePBS





The Python full specification is included in
https://github.com/ethereum/consensus-specs/pull/3828

Author: gorondan
Date: 2024-04-13T11:03:17.750Z

Great to see ePBS kick off👏, we’re following the topic with great interest, over at the EPFsg.
some questions on design:

was the urge to “fix the bug” the reason you’re proposing block auction ePBS? Because there are debates on the fact that we’re just going to move MEVboost market structure (that is considered the bug, right?), in-protocol.
is your envisioned pipeline something like ePBS->slot auctions->ET?

Thank you

Author: potuz
Date: 2024-04-13T12:22:05.719Z

The current bug is the existence of a forced trusted player in an otherwise trustless blockchain. As the document states, we aim to solve this issue in a minimal viable way. Other designs like slot auctions and/or execution ticket may be better, but I at least do not know how to actually implement them. As you delve into the minutiae of actually writing the python spec you’ll see that there are many edge cases that need to be considered. The current spec still has many of those. It seems to me that both slot auctions and execution tickets can be an iteration from ePBS and actually are simpler to specify once ePBS is in place, so given the urgency prompted by the problems we are seeing right now on mainnet is that I want to deploy a bug fix and focus on theoretical design in parallel/future.

Author: u59149403
Date: 2025-04-24T19:06:57.080Z

So this EIP makes life of MEV extractors simpler? So people performing sandwich attacks will have easier life? Now they don’t need to trust middleman and so can steal money from honest users even simpler? And this EIP democratizes MEV extraction, so now even home stackers can extract MEV, perform sandwich attacks and steal money from Ethereum users? In trustless way? Cool! I like this proposal! Thank you for thinking about these poor sandwich attackers. (This is sarcasm.)