Diegorb1329/eth_magicians_forum huggingface dataset:
Title: Un_link_coins__split
Category: Working_Groups

Author: jeff
Date: 2023-03-20T08:41:17.592Z

take the security ring and remove it from the chain…

Author: bawtman
Date: 2023-03-20T19:07:12.259Z

Hi @jeff, Welcome to the community. Could you give us some background on your topic? I am guessing your are referring to ring signatures here. Also could you explain why you feel this would be useful or what risks this addresses please? Is this about privacy protection? Thanks for any updates.
Title: Is_there_interest_in_another_data_ring_meeting_in_
Category: Working_Groups

Author: tjayrush
Date: 2019-06-28T19:54:08.746Z

Over the past year or so we’ve had a few interesting data ring meetings (Berlin, Paris, DevCon4). Are people interested in putting something together in Berlin this August?
I’ve always promoted the idea of fully decentralizing access to the Ethereum data, and have been making excellent progress lately. I’d love to share my work, discuss it’s implications, expand on how to proceed, etc.
I’m happy to try to put together an agenda, collect interested parties, but I’m also totally open to supporting someone else if they wish to organize. I posted a suggestion to the Ring Formation online form, so it should show up on the agenda. Please feel free to suggest topics, discussion points, presentation topics, whatever.
The more I watch the Ethereum space develope, the more I fear we are marching blindly into a situation where a few large companies are the only ones who will be able to extract and deliver historical data from the chain. This, to me, is a threat to the long-term viability of any blockchain.

Author: anett
Date: 2019-07-01T07:32:12.577Z

Hey @tjayrush
If you need any help with organising this Meeting - getting a space for it or anything else (mostly regarding to organisation) let me know 
If you want to help us with organising this Council, join us on Telegram

Author: nsexer
Date: 2019-07-04T14:47:30.927Z

tjayrush:

I’ve always promoted the idea of fully decentralizing access to the Ethereum data, and have been making excellent progress lately. I’d love to share my work, discuss it’s implications, expand on how to proceed, etc.
I’m happy to try to put together an agenda, collect interested parties, but I’m also totally open to supporting someone else if they wish to organize. I posted a suggestion to the Ring Formation online form, so it should show up on the agenda. Please feel free to suggest topics, discussion points, presentati


“https://www.blockchainweek.berlin/” is something already. Data rings could fit nicely into that…

Author: tjayrush
Date: 2019-07-06T13:18:17.328Z

Hi @nsexer. I just re-read my post. I guess I forgot to say that I meant to do this under the ‘data ring’ at the upcoming Magician’s meeting in Berlin in August. Would you like to help organize? @annett has offered to help as well. Suggestions for topics, etc. are very welcome.

Author: jpitts
Date: 2019-07-07T01:27:42.636Z

You can count me in too  I may be busy helping @anett but will try to make this one.
One key thing is to find out what venue is best, considering which event we’ll be going to. The main Council is slated for Web3 Summit, but we’re hoping each Ring can happen where it is most convenient for its participants.
Title: _2_ETHProduct_Community_Call__notes___video_
Category: Working_Groups

Author: pet3rpan
Date: 2018-12-08T09:05:29.141Z

Agenda (how to participate, and time/date): https://hackmd.io/GY0b9TdaSEuvjbVqDoXKKA?both
We are having the second ETHProduct call soon next week on the 11th. You will find all details you need in there.

Author: pet3rpan
Date: 2018-12-12T23:52:42.811Z

Recording of the community call https://youtube.com/watch?v=omQ4qsCNx1Q

Author: tvanepps
Date: 2018-12-13T02:04:46.724Z

Hey there! Looking to update that Google sheet I created recently - is there a single, consistent thread where calls will be announced or is it just on this forum somewhere?
Same question for call recurrence. thanks


docs.google.com



ETHEREUM PUBLIC CALLS
ETH PUBLIC CALLS

 Hello all: This is my attempt to collect general info for all public calls in the Ethereum ecosystem into one place. If you see
 something that' s incorrect or incomplete please add a comment and I will update the info.( tweeting@...

Author: pet3rpan
Date: 2018-12-16T08:37:23.790Z

tvanepps:

Hey there! Looking to update that Google sheet I created recently - is there a single, consistent thread where calls will be announced or is it just on this forum somewhere?


I try to announce it in the magicians forum within the product management category: Product Management Ring - Fellowship of Ethereum Magicians
Call recurrence is roughly about every 2 weeks ~ but forum thread with agenda and incoming community call notice goes up as soon as a call is organised.
Lmk if you have any other questions
Title: Paginated_getLogs
Category: Working_Groups

Author: sakulstra
Date: 2025-05-04T20:29:27.846Z

Motivation
When I first entered this space >4 years ago, the first thing i built was an indexer for the aave protocol. Now 4years later, looking at this app not much has improved and I would probably do it the same way again.
Indexing events should be easy, but it is not.
Perhaps i might be able to do a few calls less, or I might be able to use alchemy* on L2s, but the core pain of eth_getLogs persists.

there is no cursor
there is no handling of reorgs
constant block-range limits on increasingly faster chains are pain

Running an archive node myself, might be possible, but it’s a huge barrier of entry for “getting started”.
While the bigger providers, started to offer custom built solutions for the problem (pipelines by alchemy, and streams by quicknode), these solutions require a vendor lock in, so there should be a feasible node level alternative imo.
Spec
My knowledge on the topic is at best, limited. Therefore I will not suggest any specific spec.
That said, I assume a new method would need to be introduced to not break existing eth_getLogs usage.
My naive assumptions is that:

fromBlock should also accept a blockHash. This way *getLogs could return removed: true events, if the fromBlock was reorged.
if the search range exceeds some sort of limit on the archive node, the node should just return (not error) and the return should contain the last visited blockHash, so on the next query one can continue from there.

Perhaps it could make sense to have a more complex cursor including e.g. a txIndex. I assume with ever growing blocks one might end up in a situation where one block might exceed the node limits (iirc. there was some issue with infura in the past).
Prior work
There seem to be two related prs that i could find:

Proposal: Paginated Filter Queries ethereum/go-ethereum#17487 i think the first time this issue was raised, but eventually the topic has gotten stale
JSONRPC responses with cursor/paging · Issue #617 · ethereum/execution-apis · GitHub a somewhat newer thread on the topic, with what i think are bot responses
predictable block ranges when using eth_getLog · Issue #10606 · paradigmxyz/reth · GitHub slightly unrelated, but seems like ppl have pushed to get at least alchemy level feature parity accross clients

*In contrast to other node providers, alchemy does not implement a strict maximum blockRange, but allows for a dynamic range / suggest a dynamic range if the range contained to many matches Based on your parameters, this block range should work: [0x0, 0x270f]
Title: OG_Council__NFT_protocols_and_usecases
Category: Working_Groups

Author: Captainjames
Date: 2022-04-30T02:28:30.935Z

Hey everyone, here is a summary of what we did in the workshop at the OG Council. I consider this a part 1 and hope to do a part 2 answering some of these questions or providing more detail on these topics at a future event. Here are the compiled notes on questions, use cases and protocols we discussed. Feel free to add more.
Questions

How can we ensure new use cases of NFTs remain truly decentralized
How can we use Defi integration for NFT governence tokens
How can insurance contracts be tradable (similar to oracle based payouts)
Where are my NFTs stored?
Copyrights - What are the laws around music, film, books and storylines?
How can we market and promote NFTs in Web3

Use cases

Composable remixable NFTs
CUPPA.CC decentralized onbourding USAIC POAP chains
TCR
Harberger Tax
Medical Data (MRI, DTI, ASL)
Linlock
Identity and personal information (eg. Medical use)
Real estate
Membership
Certificates and education
Licences
Game items
Certificates of authenticity
Intellectual Properties (IPs)
Ticketing
Art trading
Bills of lauding
Voting
Vouchers (NFT burn mechanic)
Film, book and music rights (nfts)

Protocols

Near Protocol
NFT X
Climate kitties
POAP
Royalty Register DAO
Lens Protocol
Hedgey
Wolf Game (NFT game)
Crypto Raiders (NFT Game)
Aaveagotchi (NFT game)
Soulbound NFTs (non tradable tokens)

Author: Yorikobeal
Date: 2022-05-03T05:20:05.268Z

Thank you for posting the summary!
Title: Standardizing_output_from_RPC_s_across_nodes
Category: Working_Groups

Author: ankitchiplunkar
Date: 2019-01-11T09:27:48.406Z

Hi all,
I am Ankit Chiplunkar I currently work at https://www.tokenanalyst.io/ and earlier developed GitHub - analyseether/ether_sql: A python library to push ethereum blockchain data into an sql database.. Posting here on the suggestion of @tjayrush .
We collect, clean and format all types of data gathered from Ethereum clients, and regularly fall into problems where different nodes return different types. We have written a few blogs and opened several PR’s on the issue, but I think this ring can be a good place to standardize the data returned from Ethereum clients.
What do you guys think?
References:
Blogs:
https://medium.com/tokenanalyst/weird-quirks-we-found-in-ethereum-nodes-d5dcbad0c86
https://medium.com/tokenanalyst/towards-production-grade-open-source-ethereum-nodes-6ef2e9458fb4
PR’s

GitHub · Where software is built
GitHub · Where software is built

Author: tjayrush
Date: 2019-01-13T18:16:42.389Z

Hey Ankit. Thanks for posting this.
Summary of findings from the above article [with my comments]:

Use an SSD. [Confirmed]

Parity RPC responds even while syncing, Geth does not. [Not confirmed]

There is no standard error reporting from the nodes. Different nodes report errors in different ways. [Confirmed]
‘r’, ‘s’, and ‘v’ fields differ between clients. [Not confirmed]

Parity syncs faster than Geth. [Believed to be true]

JSON-RPC interface is not type-safe. [Is any JSON type safe?]

Tracing and state diff appear only in Parity (not Geth) and then with some inconsistancies. [Not confirmed]

RPC and Web socket interfaces handle block re-orgs. There’s a question if they are correctly handled. [Not confirmed]

Small differences between Geth and Parity: [Not confirmed]

Uncle size is null in Parity, but does exist in Geth.
Filter IDs on Geth and Parity are different.
Geth assigns random IDs, and Parity uses an incremental counter.


The consensus rules among clients have to match in order to make Ethereum work, but everything else, e.g. the exposed API, or RPC interface can be totally different. [Should be the same but are possibly different]

Take each client with a grain of salt. [Confirmed]

Author: jpzk
Date: 2019-01-14T16:11:47.276Z

Hey tjayrush,
Thanks for checking on the findings, when you write “Not confirmed” do you mean a) you are going to evaluate it or b) you evaluated it and you did confirm that this issue exists.
Best,
Jendrik

Author: tjayrush
Date: 2019-02-08T16:08:58.032Z

@jpzk When I say ‘not confirmed’ above I meant that I did not independently test the claim made by Ankit. In other words, I don’t know if it right or wrong.
Title: _BlockCypher_s_Ethereum_API_was_knocked_out_after_
Category: Working_Groups

Author: jpitts
Date: 2019-03-12T16:27:18.149Z

cc “Education Ring” 
Ok, so we have this Twitter discussion and some misconceptions:
https://twitter.com/Catheryne_N/status/1105218247736012800
She experienced sync problems after the HF, and seems to have avoided normal channels for support, and reached out directly to @vbuterin.
https://blog.blockcypher.com/ethereum-woes-d9b2af62da67

After examining every which way we could think of to add the Trie state to our Ethereum state, we asked Vitalik for assistance. His first comment to us was “oh you’re one of the few running one of those big, scary nodes.” We asked him if he knew of anyone else running a “big, scary node” to see if we could possibly sync with them. He knew of no one, not even the Ethereum Foundation keeps a full archival copy of the Ethereum chain.

It highlights an education-related issue that I see. We need entry points for users of various kinds so that they know where to start, where to bring problems up. This person does not even seem to be aware of the Data Ring.

Author: tjayrush
Date: 2019-03-13T15:47:25.869Z

There’s a fair amount of misinformation as well. Running an archive node is not that hard. I run two of them IN MY HOUSE (plus two Parity tracing nodes – one on a laptop). It’s not that hard or that scary.

Author: boris
Date: 2019-03-14T06:30:54.399Z

There were sync problems before the HF. Various Twitter responses from knowledgeable devops folks points out they don’t seem to know what they are doing. And, of course, the interaction with VB sounds like a fabrication.
But back to your point – this is a commercial company. I think messaging / education / entry points for commercial companies could be VERY interesting. We want to welcome them and onboard them as open source contributors – or make it clear who they can pay for help.
For example, I wonder if they are running Geth or Parity.
For the Geth team, might they list trusted consultants who do paid work? Who would pay an affiliate fee?
For Parity, they should add a paid support option right in their repo.
Title: Joint_session_on_interoperability_with_Ring13
Category: Working_Groups

Author: Ethernian
Date: 2018-10-28T10:42:38.285Z

@boris,
Unfortunately, the Architects Ring (15) and the Ring 13 for EIPs & Interoperability are scheduled in the same time slot. The interoperability topic is a central for architects too, so I would propose to make a joint session at least on this topic, Further Ring specific topics could be discussed separately if needed.
@apitkevich, agree?

Author: boris
Date: 2018-10-28T11:14:04.714Z

Hey @Ethernian — as I said in person I think there is enough to cover in the EIPs session to not merge. EIPs is not a ring, rather process oriented.
You’re welcome to bounce between sessions and there is lots to do post event to continue the discussion.
And if you could write more about your thoughts on interoperability that would be great.

Author: Ethernian
Date: 2018-10-28T12:43:15.897Z

boris:

And if you could write more about your thoughts on interoperability that would be great.


here they are:
Thoughts on EIPs and interoperability
Title: Payments_Use_Case_Working_Group
Category: Working_Groups

Author: Jsg
Date: 2024-11-25T16:14:44.260Z

Problem
No blockchain ecosystem has yet nailed the customer-to-merchant payments use case. Mainstream users still do not pay with crypto, and they are not close to doing so.
Opportunity
Ethereum is the perfect ecosystem to redesign this use case and grow to Visa and Mastercard levels of adoption.
Goal
In other words, the KPI is that most of our friends use Ethereum-powered methods in their everyday lives. Customer-to-merchant payments will bring the first billion users to Ethereum.
More Info
Payments is a complex social and technical problem. It requires specific coordination among the players on the ecosystem to unlock network effects.
Read this article to know more: L1 and L2 Chain Fragmentation Problem: A Crypto Payments-Centric View
Specification: PreAuth-ERC20
Call to Action
Comment here and join forces.

Author: Deep
Date: 2024-11-29T06:30:00.581Z

Yes, would love to join!

Author: Jsg
Date: 2024-11-29T16:15:53.108Z

Looking forward to it.

Author: Jsg
Date: 2024-12-15T21:26:45.472Z

Added the Spec on the post: PreAuth-ERC20
Title: SCSVS___Smart_Contract_Security_Verification_Stand
Category: Working_Groups

Author: jpitts
Date: 2019-10-22T22:38:49.930Z

This was posted by  Damian Rusinek on ethresear.ch.


Together with my colleague Paweł Kuryłowicz we have created the Smart Contract Security Verification Standard which we published on the 1st of October.
#SCSVS - Smart Contract Security Verification Standard is a FREE 13-part checklist created to standardize the security of smart contracts for developers, architects, security reviewers and vendors. This list helps to avoid the majority of known security problems and vulnerabilities by providing guidance at every stage of the development cycle of the smart contracts (from designing to implementation).
In my opinion, this is great material for people interested in smart contracts and decentralized application.
From the most important information:

SCSVS is available for everyone for FREE here: https://securing.github.io/SCSVS/ 
Authors: Damian Rusinek and Paweł Kuryłowicz (we are both from SecuRing company - we are very grateful to them because they let us do it partly during work)
It was released 01.10.2019r.
It was shown for the first time during the OWASP Global AppSec Amsterdam 2019 during my presentation.

Cheers,
Damian
Title: Simulation_working_group_proposal_for_Eth_1_x
Category: Working_Groups

Author: lrettig
Date: 2018-11-29T20:44:53.505Z

Along with state rent and Ewasm, this proposal forms the output of the third and final Eth 1.x working group going into tomorrow’s call. Kudos to Shahan Khatchadourian & co. for putting this together.

Author: jpitts
Date: 2018-11-30T19:19:51.473Z

Adding more details for clarity:
Ethereum Eth1.x WG3: Simulation
by Shahan Khatchadourian & other contributors

This document is to capture the infrastructure, platform, and requirements for simulation towards an Eth1.x feature list for inclusion in an upcoming hard fork. The simulation platform is intended to resolve questions that the community has about where we are at, where we are headed, and what we need to know and do to get there.

Author: zscole
Date: 2018-12-04T20:32:24.957Z

Putting together a call for this Thursday to expand on these points and identify requirements for test net.
https://github.com/ethereum/eth2.0-specs/issues/233

Author: shahankhatch
Date: 2018-12-07T15:33:18.614Z

Will have call today at 8AM PST.


Zoom Video


Join our Cloud HD Video Meeting
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference...

Author: zscole
Date: 2018-12-07T22:43:18.167Z

Notes and recording from this morning’s call.
Title: Any_interest_in_bringing_back_the_Product_Manageme
Category: Working_Groups

Author: yungzyad
Date: 2023-03-21T00:18:27.473Z

I’m a Web3 Product Manager who just stumbled upon this community. Doesn’t seem like there has been much action here since January 2019, which is crazy considering how much the Ethereum ecosystem has grown since then. Would love to kickstart this group again if anyone else is interested
Title: ETHSecurity_Report_Responses
Category: Working_Groups

Author: captnseagraves
Date: 2018-09-14T20:47:54.665Z

This thread is meant to house responses to the ETHSecurity report. If there was something missed or misrepresented please contribute to the conversation here. If you would like to contribute resources to the security wiki, please make a PR here: https://github.com/ethsecurity/berlin-workshop
Title: Data_Ring_Topic__Real_World_Data___Oracles
Category: Working_Groups

Author: tjayrush
Date: 2019-02-19T22:07:21.485Z

There was a discussion about how certain ‘real-world’ data enters the system, that is Oracles.

Is there a way to express ‘trust relationships’?
What types of real-world data would be nice to have on chain? (price feeds, ABIs, token information)
Should we separate oracle-related topics into a different ring?

Action Item: @Alex will post links to materials which explain Oracles in the eth magicians discussion.

Author: tjayrush
Date: 2019-02-19T22:08:49.675Z

My take:
I think it might be a good idea to separate out the discussion of ‘data in’ to the chain from ‘data out.’ I think these two issues might have separate audiences, so separating might be beneficial. I haven’t thought about it a lot, but it feels like the issues/solutions for ‘data in’ vs. ‘data out’ may be quite different as well.
Thoughts?

Author: jpitts
Date: 2019-02-21T01:37:15.760Z

Oracles and data from external sources should be a separate side Ring IMO.
Still, I would imagine that certain Oracle data is on-chain and needs to be verified, processed, and queried by dapps. In this regard, Oracle devs have the same concerns as any other dapp dev.

Author: tjayrush
Date: 2019-02-21T04:02:03.093Z

I did notice that there was an Oracles Ring in the HackMD document, so anyone interested in Oracles can attend that ring. Perhaps the issue is already sorted.
Title: Forming_a_Ring__VM_Ring
Category: Working_Groups

Author: ltfschoen
Date: 2019-03-04T13:22:52.223Z

Purpose: Discuss EVM and eWASM design, improvements, and compatibility. New opcode definition. Keeping Jello / Yellow paper specifications up to date.
Closes https://github.com/ethereum-magicians/scrolls/issues/62
cc @gcolvin @expede @boris
Title: Sepolia_deposit_smart_contract_source_code
Category: Working_Groups

Author: shoenseiwaso
Date: 2023-06-14T08:18:54.157Z

Does someone have the source code for the Sepolia deposit smart contract? It’s not verified on Etherscan, and a few attempts at a web search and search of likely places in Github didn’t turn up anything. Thanks!

Author: gregdhill
Date: 2023-12-01T06:29:21.491Z

According to @parithosh_j it is a variant of this repo: GitHub - protolambda/testnet-dep-contract: Testnet deposit contract for Eth2 - permissioned, tokens, drain, admin funcs. DO NOT USE ON MAINNET.

Author: shoenseiwaso
Date: 2024-07-14T07:05:04.568Z

A very belated thank you for this!
Title: An_idea_to_decentralize_the_non_organization_short
Category: Working_Groups

Author: tjayrush
Date: 2018-11-04T16:29:03.856Z

I sort of volunteered to do a regional magicians meeting, but short of that, I had an idea. It’s sort of a combination of an online and an in-person meeting.
The idea is to get four ring makers to work together to coordinate introducing their ring to a larger audience. It would be video-based but in a setting in each city where small groups of real humans are physically together. The intention is introduce the rings to the humans in the room.
Here’s the rules of engagement:


Four ring makers come together to agree to hold a co-coordinated online video / in-person meetup event. A date and time is selected.


The ring makers seek out a volunteer from within their ring to be the ring’s spokesperson. (The ring maker should not be the spokesperson if at all possible).


At the start of the ‘meeting’ (which can be scheduled to last an hour) all four spokespeople can have a short introductory discussion about the magicians in general (What are the magicians? What are the magician’s not? What are rings? etc.). This first part could last for ten minutes.


For each of the next four fifteen minute periods, a spokesperson would speak exclusively to the in-person audience in each location. There could be a few minutes of question and answer. This would require the coordination of separate screen share sessions between each ring in a ring-buffer-like modulo arithmaticy kind of assignment (spokesperson 1 speaks to group 2, spokesperson 2 to group 3, 3 to group 4, 4 to group 5 % 4). During the second ten-minute section each spokesperson speaks to the next group modulo 4.


Each ‘presentation’ and ‘question and answer’ could last ten minutes and start 15 minutes apart, that would allow for switching Google screen shares and would take up about an hour (4 *15).


At the end of the hour, there could be a ten-fifteen minute ‘wrap up’ call with all four rings.


Yes – I totally understand that this may be more difficult than simply putting on a regional magician’s session, but we have to learn how to dis-intermediate ourselves (thus rule 2). If anyone is interested (I need three additional rings), let me know. I host my city’s Ethereum meetup, so I can be pretty flexible on timing. I’d prefer an evening meetup for my group, but I can accommodate. I’m the ring maker for the Data Ring, if you want to volunteer to be the spokesperson, let me know.
If this does not sound like a good idea, please let me know that as well (I have a thick skin).
If you’d like to volunteer to do a North East of US regional event (for which I can find space in Philadelphia, PA), let me know that as well.
Final note: this is a do-ocrocy. Let’s do.
Title: Data_standardization_with_a_rough_consensus
Category: Working_Groups

Author: vlad-kahoun
Date: 2018-11-05T15:36:44.981Z

I suppose we agree that dApps and platforms need to cooperate with each other. It’s not possible now, because they use different formats of messages. I think that we need an abstraction layer – middleware - that can translate various data/message standards between each other. As a result everyone’s idea can become a standard, protocol or feature understandable to other parts of the system.
I’m working on that kind of middleware (please see my introduction: https://ethereum-magicians.org/t/the-big-introduce-yourself-thread/75/66?u=vlad-kahoun) and I’m happy to create a working group to discuss and cooperate with others interested in the topic and various ways to solve standardization. Please let me know here in discussion or message me if you’re interested to discuss further, so we can set up our communication.
There are at least 3 ways to establish standards


Directive – when a strong organization introduces and pushes a new standard.


Consensual – when a diverse group of people/organizations agree on the best standard for a particular purpose (e.g. the standard for bounties).


The 3th way is based on a rough consensus. It means that the best standard is not decided in advance. Instead, anyone can introduce his own standard and the successful ones are the standards used by the most clients and platforms.


I propose the 3th way as a solution for standardization because it enables anyone to create better standard/language while being still understood by all other parts of the system. This approach will be possible once we have the abstraction middleware that can translate one standard to another, even in a multi-hop manner.
The translation middleware is useful mainly for off-chain data, meta-data in transactions and all messages exchanged between various clients and platforms.
There is a description of an example client backed by the middleware: https://github.com/unfwk/jekyll

Author: jpitts
Date: 2019-03-02T00:24:52.862Z

@vlad-kahoun my apologies for not replying earlier. We definitely do believe in “rough consensus and running code”, and hope that all Rings use it. More so, that Rings find rough consensus in person with a final decision only happening here on the Forum, so that all can participate.
Principles of the Fellowship: https://github.com/ethereum-magicians/scrolls/wiki/Principles-of-the-Fellowship
Title: Red_Queen_s__New_Sync_Proposal
Category: Working_Groups

Author: yperbasis
Date: 2019-04-23T12:21:27.710Z

As part of Ethereum 1x efforts, we want to tackle the issue of the growing blockchain state. Large state size leads to long sync times. On top of that, geth’s fast sync is not that fast and takes a few hours. Parity’s warp sync is faster, but is not supported in geth. We propose a new sync protocol and an algorithm, which we believe can perform snapshot sync in less than an hour. The idea is somewhat similar to Warp Sync and especially to Leaf Sync (under development in geth). Moreover, the new protocol caters for clients with a different storage structure than the canonical Patricia trie (e.g. turbo-geth).
The new protocol and algorithm are described in a paper. See also my presentation at Ethereum Core Devs Eth1x/Istanbul Planning Meeting in Berlin.
This is the first version; comments, suggestions, critique are most welcome.

Author: yperbasis
Date: 2019-04-23T13:59:06.038Z

The new protocol is related to Forming a Ring: ETH v64 Wire Protocol Ring.

Author: yperbasis
Date: 2019-04-25T09:59:08.840Z

See also a gitter discussion about new sync protocols.

Author: yperbasis
Date: 2019-06-10T18:50:17.513Z

An update: we’re going to use “Red Queen” for a sync algorithm (one out of a few possible) and “Firehose” for the new sync protocol. A new version 0.3 of Firehose is available at https://github.com/ledgerwatch/turbo-geth/blob/red-queen/docs/firehose.MD.
Title: Address_Space_Extension_with_bridge_contracts
Category: Working_Groups

Author: axic
Date: 2021-07-15T09:34:23.064Z

This is an alternative proposal building on top of the Address Space Extension with Translation Map idea. See this for open questions.
One of the major issues identified is the inability to distinguish short (legacy) addresses from compressed addresses, and the resulting complexity of automatic translation.
In order to avoid this problem, we introduce a special contract type, called bridge contract, which announces itself being capable of interacting with the new address space, but is actually placed in the legacy address space (and has a short address).  Other contracts in the legacy space can not interact with the new address space.
For the complete text see ASE with bridge-contracts - HackMD

Author: dogeprotocol
Date: 2023-12-02T01:12:14.068Z

Hi, FunctionTypes in Ethereum currently use 20+4 bytes where 4 bytes is for function identifier in an external contract (for example). So it is only possible to use 28 bytes instead of 32 bytes for the address, otherwise FunctionTypes will break.
Any solution around this?
Title: RIP_7712__Multi_dimensional_256_bit_nonce_for_RIP_
Category: RIPs

Author: alex-forshtat-tbk
Date: 2024-05-23T22:36:25.240Z

The original RIP-7560 previously required a creation of a NonceManager contract and an introduction of a 256-bit wide two-dimensional nonce parameter. This closely reflects the implementation of “nonce” replay protection in ERC-4337.
However, this requirement seemed to complicate an already complex design while not being strictly necessary to achieve most of the goals set forward by RIP-7560, so this feature has been extracted into a separate document here:
https://github.com/ethereum/RIPs/pull/23
Title: About_the_RIPs_category
Category: RIPs

Author: matt
Date: 2024-04-25T19:11:49.587Z

This category is for Rollup Improvement Proposals.
The goal of the RIP project is to standardize and provide high-quality documentation for Rollups in Ethereum ecosystem. This repository tracks past and ongoing improvements to Ethereum’s Rollup ecosystem in the form of Rollup Improvement Proposals (RIPs).
All RIPs are optional. RIPs are and will always remain optional standards for Rollups and participants in the larger EVM ecosystem. RIPs and RollCall are not a governance process.
More information can be found at GitHub - ethereum/RIPs: The Ethereum Rollup Improvement Proposal repository
Title: RRC_7740__Add_pre_installs_for_deployment_factorie
Category: RIPs

Author: rmeissner
Date: 2025-01-15T19:11:33.846Z

Discussion thread for RRC-7740
Open questions:

Should other non-factory contracts be added too (i.e. multicall3, ERC-1820 registry)?
What other factories should be added (i.e. ERC-2740)

Author: rmeissner
Date: 2025-01-15T19:14:37.076Z

rmeissner:

Should other non-factory contracts be added too


I would only support this for existing contracts that are well established (as the ones referenced). As new contract should utilize one of the singleton factories to deploy instances that are consistent across networks.

Author: wminshew
Date: 2025-01-15T20:17:00.073Z

multicall3 would be a great addition imo

Author: Arvolear
Date: 2025-01-22T19:51:10.449Z

Can we think of some deterministic singleton WETH contract that may be preinstalled as well?
Title: RIP_7711__An_RIP_7560_compatible_transactions_bund
Category: RIPs

Author: alex-forshtat-tbk
Date: 2024-05-23T22:30:37.876Z

The original RIP-7560 previously required a separation of a Native Account Abstraction transaction flow into non-atomic validation frame and execution frame.
We now believe that this separation may not be necessary for some L2 implementations, so this separation of transactions into non-atomic parts has been extracted into a separate document here:
https://github.com/ethereum/RIPs/pull/22

Author: colinlyguo
Date: 2025-05-07T06:39:06.688Z

Hey, I have a question related to the motivation for this RIP. It mentions:

On “single sequencer” Layer 2 chains that do not have a “transaction mempool” in a traditional sense, this proposal provides no benefit compared to the original RIP-7560.

This claim seems to have an assumption that the sequencer will serve transactions in a first-come first-served order, so it won’t be bothered by state conflicts among native aa transactions.
However, if the sequencer picks transactions from a public mempool based on factors like effective gas tip, this RIP could still help mitigate state conflicts among native AA transactions. Am I understanding this correctly?

Author: alex-forshtat-tbk
Date: 2025-05-09T23:20:44.112Z

colinlyguo:

However, if the sequencer picks transactions from a public mempool based on factors like effective gas tip, this RIP could still help mitigate state conflicts among native AA transactions. Am I understanding this correctly?


Yes, you are correct, as long as there exists an open mempool of AA transactions and the sequencer, or a block builder, mostly relies on transactions from this mempool, we need a mechanism to isolate the transactions or else the block builder may “choke” on a huge number of invalid AA transactions.
In this moment in time it does not matter if this is a centralised sequencer or a PoS validator, they both will have the same problem.
Our proposed solution to this problem is a combination of RIP-7711 and ERC-7562.
Title: RIP_7876__Canonical_ERC_7802_token_bridge_address
Category: RIPs

Author: yoavw
Date: 2025-02-11T18:39:11.739Z

RIP-7876 sets a standard address for the ERC-7802 token bridge address trusted by ERC-20 tokens that support ERC-7802 Crosschain minting/burning.
ERC-7802 proposed a minimal interface for crosschain minting/burning of ERC-20 tokens. The token is requires to trust a bridge address and allow it to call crosschainMint/crosschainBurn. The bridge address would typically be immutable and affect the token’s address as determined by CREATE2.
EIP-7587 reserved a range for standardized precompiles/predeploys used by rollups. The proposal makes use of this range to reserve the token bridge address.
By standardizing the bridge address we gain two advantages:

Tokens can be deployed in a future-proof manner on every chain. If/when a rollup adds native ERC-7802 capability to their canonical bridge, existing immutable tokens can benefit from the improved interoperability even though they were deployed earlier.
Tokens can deploy to the same CREATE2 address if they wish. Having the same bridge address means they don’t need to pass a different argument during deployment.

We propose that rollups that implement a native ERC-7802 bridge will use this standard address to help token devs with interop and avoid fragmentation.
Title: RIP_7789__Cross_Rollup_Contingent_Transactions
Category: RIPs

Author: shakeshack
Date: 2024-10-18T01:52:06.067Z

This proposal introduces a method to make cross-rollup transactions contingent on the shared Layer 1 (L1) history of communicating Layer 2 (L2) rollups.
Specifically, a contingency DAG is created across rollups for cross rollup transactions that is utilized to enforce a number of safety invariants.

Future to past communication is not allowed.
Communicating across L1 histories is not allowed.
A reorg of the originating chain from which a contingency link is created must also mean a reorg of the contingent chain.
A message originating from a source chain prior to reorg must not be replayable on the dependent destination chain after both chains reorg.

L2s are recommended to both track and align their L1 origins to enable faster cross L2 communication.
See the PR below for more information.


github.com/ethereum/RIPs








RIP-7789: Cross Rollup Contingent Transactions


master ← polymerdao:bo/cross-contigency



          opened 03:26AM - 17 Oct 24 UTC




            notbdu
          



+265
-0






This proposal introduces a method to make cross-rollup transactions contingent o…n the shared Layer 1 (L1) history of communicating Layer 2 (L2) rollups. 

This means a requirement on L2s to track their L1 origins.

Safety invariants are also defined around this L1 contingency across communicating L2s.

See [here](https://github.com/polymerdao/RIPs/blob/bo/cross-contigency/RIPS/rip-7777.md) for a version with working image links.






An alternative link is provided to the markdown file w/ working image links as well.


github.com/polymerdao/RIPs


cross-contigency/RIPS/rip-7789.md

bo

---
rip: 7789
title: Cross Rollup Contingent Transactions
description: Proposal to make cross-rollup transactions contingent on the shared L1 history across rollups. 
author: Bo Du (@notbdu), Devain Pal Bansal (@dpbpolymer), Ian Norden (@i-norden)
discussions-to: https://ethereum-magicians.org/t/rip-7789-cross-rollup-contingent-transactions/21402
status: Draft
type: Standards Track
category: Core
created: 2024-10-16
---

## Abstract

This specification proposes a method to make cross-rollup transactions contingent on the shared Layer 1 (L1) history of communicating Layer 2 (L2) rollups. 

The aim is to highlight the importance of L2’s tracking their L1 origins and the role it plays in the finality of a rollup. By introducing L1 origin tracking as a requirement, we define how it is utilized to establish ordering guarantees between rollups before they reach their safe or finalized stages. This enhances the reliability of cross-rollup interactions by accounting for the shared L1 context between rollups pre-finality.

## Motivation





  This file has been truncated. show original
Title: RIP_7759__Layer_2_Transaction_Fee_Specification
Category: RIPs

Author: highlander
Date: 2024-08-22T19:54:43.998Z

1 Introduction
The L2 WG is an open-source initiative with a scope to


Identify and document the most relevant use cases and business requirements for Layer 2 and other Blockchain Scalability solutions for EVM-compatible public blockchains


Define a technical standard with identification and differentiation of classes of scalability solutions as required that meet both ecosystem and enterprise requirements, with a particular focus on interoperability between Layer 2 solutions for EVM-compatible public blockchains


For EVM-compatible public blockchains, identify, document, and devise solution approaches for Layer 2 Blockchain scalability solution-specific challenges such as MEV, block (gas) limits, TVL concentration, etc.


Identify and document characteristics of Layer 2 Blockchain environments for EVM-compatible public blockchains that will be key in addressing mainstream and enterprise adoption.


The work is an Ethereum Community Project, which is managed by OASIS.
1.1 Overview
Layer 2 (L2) Transaction Fees are a crucial element of financing the operations of L2 platforms apart from rewards given to participants for providing economic security guarantees such as validators in consensus protocols. Yet how these transaction fees are derived, to whom they are paid, how and where they are displayed to any of the participants in L2 platforms varies greatly between L2 platforms.
Given the above, the need for transparency in an open ecosystem to build trust, and the evolving legal and regulatory landscape around fee transparency and what type of fees can be charged, this document sets out to define the different types of L2 transaction fees and then define requirements around transaction fee transparency for L2 platforms.
Note, that fees associated with asset and data bridges between L2 platforms as well as between L2 platforms and centralized exchanges are beyond the scope of this document.
The standard is an Ethereum Open Community Project specification draft (PSD)
Please, review and comment on the RIP once published as a draft!

Author: poojaranjan
Date: 2025-02-18T04:14:59.295Z

PEEPanEIP 138: RIP-7759 Layer 2 Transaction Fee Specification with @highlander
Title: wallet_addSubAccount
Category: Uncategorized

Author: wilsoncusack
Date: 2025-02-27T19:47:24.381Z

This ERC introduces a new wallet RPC, wallet_addSubAccount, which allows an app to request a wallet to track a smart account that the wallet owns. It also allows apps to request the wallet to provision a new account, owned by the universal wallet with a signer provided by the caller.
Embedded app accounts (onchain accounts specific to a single app) have led to a proliferation of user addresses, which can be difficult for users to keep track of. Many embedded app account users also have a universal wallet, which can be used across apps. With hierarchical ownership–where one smart account can own another–if the embedded app account is a smart account, it could be owned by the user’s universal wallet. This would allow users to be able to control an app account via their universal wallet. However, though hierarchical ownership is already possible today, there is no way for apps to tell universal wallets about embedded app accounts a user may have. The proposed RPC provides a path for this.


github.com/ethereum/ERCs








Add ERC: API for hierarchical accounts


ethereum:master ← jakeFeldman:hierarchical-accounts-api



          opened 07:38PM - 27 Feb 25 UTC




            jakeFeldman
          



+236
-0






This ERC introduces a new wallet RPC, wallet_addSubAccount, which allows an app …to request a wallet to track a smart account that the wallet owns. It also allows apps to request the wallet to provision a new account, owned by the universal wallet with a signer provided by the caller.
Title: ERC_7887__Cancelation_for_ERC_7540_Tokenized_Vault
Category: Uncategorized

Author: jeroen
Date: 2025-02-19T08:52:02.060Z

Shares or assets locked for Requests can be stuck in the Pending state. For some use cases, such as redeeming from a pool of long-dated real-world assets, this can take a considerable amount of time.
This standard expands the scope Asynchronous ERC-7540 Vaults by adding cancelation support.


github.com/ethereum/ERCs








Add ERC: Cancelation for ERC-7540 Tokenized Vaults


ethereum:master ← ERC4626-Alliance:master



          opened 01:33PM - 18 Feb 25 UTC




            hieronx
          



+360
-0






When opening a pull request to submit a new EIP, please use the suggested templa…te: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

 - The PR edits only existing draft PRs.
 - The build passes.
 - Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
 - If matching on email address, the email address is the one publicly listed on your GitHub profile.
Title: AI_Assistant_for_Ethereum
Category: Uncategorized

Author: GraphicalDot
Date: 2025-05-07T08:09:14.184Z

Apologies in advance for the sales pitch.
From discovery to first project, new blockchain developers face fragmented resources, steep learning curves, complex setups, and sparse mentorship
(source: ethereum-magicians.org ). These pain points contribute to high dropout rates and highlight the need for better onboarding support.
We’ve built Bytebell , an AI-powered DevRel Copilot purpose-built for crypto ecosystems. It ingests your GitHub repos, docs, whitepapers, and even forum threads or diagrams—then returns precise, context-aware answers to developer queries via chat.
Bytebell is already cutting support load and onboarding time by up to 80% in projects working with stacks like Solidity, Move, and ZK tech.
You can try it live:
• sui.bytebell.ai
• caldera.bytebell.ai
We’re now planning to build the same for Ethereum. We’d love your feedback—especially on what sources beyond EIPs, the Ethereum GitHub, and EVM docs we should ingest.

Author: aryaethn
Date: 2025-05-07T14:01:08.835Z

Hello, @GraphicalDot
I haven’t seen your product, but as a feedback on sources, I can recommend ingesting on rollups docs and GitHubs, like Arbitrum, Optimism, zkSync, Scroll, Linea, etc., since they are a very important part of the ecosystem. Also, many of them overlap with your pre-existing support on ZK tech.
Title: EIP_7924__Ethereum_Intent_URI__EI_URI___A_Universa
Category: Uncategorized

Author: frani
Date: 2025-04-15T13:32:09.271Z

Discussion thread for Add EIP: Ethereum Intent URI (EIURI) by frani · Pull Request #9644 · ethereum/EIPs · GitHub
Title: Security_concerns_when_deploying_contracts_with_th
Category: Uncategorized

Author: elmariachi
Date: 2024-09-08T20:34:50.007Z

using the plain old CREATE opcode, when I’m deploying contracts, the contract addresses depend on the account’s current nonce.
When I’m using the same account / EOA to deploy contracts on different chains, there might exist completely unrelated contracts on different chains.
Regardless of the UX implications (multichain explorers, eg tenderly would display unrelated transactions across chains), might that lead to security related issues? Could eg someone find  a transaction casted for one contract on the L1 and replay that on an L2 (since the contract addresses are the same?)

Author: ryley-o
Date: 2024-09-16T17:55:03.099Z

In general, EIP-155 prevents replay attacks on different chains.
Of course, for the few transactions that sign in a pre-EIP-155 format, yes, there will always be some amount of cross-chain replay attack vulnerability. Those transactions are typically very intentional, however, and are not part of the typical UX.
Title: Mixer_for_etherum
Category: Uncategorized

Author: John_Trant_112
Date: 2023-09-14T12:21:13.274Z

Hi everybody! Just curious, is there any kind of mixer for etherum such as https://tumbler.io for bitcoin? If you know some please let me know. Thahnks!

Author: Mani-T
Date: 2023-09-15T06:24:33.672Z

Tornado Cash, maybe you can try this one.

Author: danielrdo
Date: 2024-04-19T19:03:18.246Z

You can try UniJoin too

Author: HoangTranMap
Date: 2024-06-04T18:20:13.289Z

yes bro ok ok ok ok ok
Title: Ethereum_R1__The_Neutral_Rollup_for_Ethereum
Category: Uncategorized

Author: zengjiajun
Date: 2025-05-01T11:25:37.179Z

“General purpose L2 should be commodity — simple, replaceable, and free from risky governance or centralized dependencies.”

Ethereum R1 is a new rollup project rooted in the core values of Ethereum: open global participation, decentralization, credible neutrality, and censorship resistance.
We believe it’s time to build a rollup that doesn’t revolve around private token allocations or opaque governance. One that doesn’t require trust in a foundation, a multisig, or a VC round. One that can outlive us all.
Why now?
Many L2s have become the new L1s — controlled by a small group of insiders, guided by private incentives. We believe the Ethereum community deserves a public, neutral alternative.
Ethereum community has called for us to act. We’re responding with a plan to build and launch Ethereum R1 — and we want you to help shape it.
What is Ethereum R1?


Fully donation-funded — no token, no private sales. Just ETH contributions from the public.


Stage 2 from day one — permissionless proving, long upgrade delay period with a huge set of multisig with broad representation across the Ethereum ecosystem.


Ethereum public good — Proportion of base fees go to R&D and app dev until 2030 — then they’re burned.


Replaceable by design — no proprietary governance, no branding lock-in, no cult of personality.


This is a rollup that belongs to Ethereum, not to a foundation, not to insiders, not to us.
Join the movement
This is an open call to:


Developers who want to contribute to a truly public rollup


App builders looking for a censorship-resistant home


ETH holders who want to fund Ethereum public goods, not extraction schemes.


A draft roadmap is live Ethereum R1 Roadmap, and discussions are starting in our Telegram channels.
If you believe rollups should be a commodity, not a cartel — join us.
Website / GitHub / Twitter / Telegram
Let’s build Ethereum’s rollup. Together.
— Jiajun, Ahmad, Kassandra, Jünger and friends