eth-protocol-fellows / cohort-zero Goto Github PK

Github Discussions

Discussions is the space for communities to have conversations, ask questions and post answers without opening issues
If you are an admin or a maintainer of a repository, you can enable Discussions under “Features” in the repository settings

If you would like to receive 1:1 feedback on your participation in the program, please do the following by October 21st.

Send me an email to [email protected] with the following information. Try to be somewhat concise.

1. The Plan: A description of the project(s) you chose to work on and why.
2. The Facts: Summary of what you have done thus far during the program.
3. The Wins: What did you do well? Anything you feel you now understand particularly well? Did you accomplish anything?
4. The Hard Stuff: Are there any places where you feel you fell short? Anything you are aware of that you could have done better?
5. Summarize: Overall, how do you feel about the time you've spent thus far.
6. What do you want to come next: When the program concludes, what is your desired outcome? Do you feel you are on your way towards that?
7. How would you improve things: How would you change the program to be more effective. What could we have done differently to better set you up for success

I will get you a response with my feedback and impressions of your work over the last months.

May someone kindly pleass merge my PR. PR#172 and PR#173, one for the showcase and the other for showcase Readme.md Updates. It's has been created 7 days now and no one merged it. Is there anything wrong with it? I have noticed it isn't mine alone.

One sub-component of "State Expiry" and the underlying changes to the storage layout within the trie are that code will now be chunked and stored within the trie itself.

https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Code

One thing that we want to verify is that tracking code chunk access will indeed be relatively trivial. Write a quick POC in a client that tracks code chunk access using something like the bitfield approach suggested by Vitalik on the call. (see call recording about 20-30 minutes into the call). Is it indeed trivial to implement? Are there any hidden complexities?

Suggested methodology for this would probably be to run a modified client, though it is possible the necessary information is available through the transaction tracing APIs as well.

Using this issue to temporarily house some meta-information about what I mean when I say "Development Update".

One of the core goals of this program is to improve your technical writing and communication skills. One of the ways to do this is to get comfortable telling people about what you are working on. So one of the expectations for program participants is a regularly cadenced development update. For the duration of the program, all participants should publish a development update at least once every two weeks.

A good development update can take many forms. Every individual will probably need to find their own style. Here are some suggestions.

• You don't need to explain everything, but sometimes it is good to try and explain things to see if you know how.
• A bulleted list of factual statements about what you worked on is a great place to start.
• Links are great. Forum posts. Pull requests. HackMD documents.

A great example are Danny Ryan's "finalized" series of development updates. Here's a recent one: https://blog.ethereum.org/2021/04/02/finalized-no-25/

You should:

• post your first update within the first week of starting into the program.
• post your update somewhere public. This can be your own blog. A forum post. A markdown document in the cohort-zero repository.
• you should provide a URL referencing your development update in your ./notes/<your-name>.md document within the cohort-zero repository.

Verkle tries are coming...

https://notes.ethereum.org/@vbuterin/verkle_tree_eip

Every client is going to need this functionality. The Nethermind client is ripe for someone to jump in and create a workable proof-of-concept implementation of the verkle trie in preparation for the upcoming protocol changes.

State expiry is going to modify the gas schedule such that some things become more expensive and some things become cheaper.

https://notes.ethereum.org/@vbuterin/witness_gas_cost_2

It would be good to analyze how this will effect popular contracts. (see state expiry call recording). The exact methodology for how to do this analysis would need to be figured out, but it would likely involve running modified client code to export this data. It might be possible to use the transaction tracing APIs to get the necessary data from block execution to do this without client modifications.

As we all step into stage one (which will occur over the next 1-2 weeks), we should start to look at how we can pull all of the work together into a single resource. I see this fitting into two categories.

1. Aggregating reading resources into something structured. This was already partially begun in the "Suggested Reading" section. The simplest approach would be to expand this section out further and continue to try and refine how it is organized. Quality over quantity. We don't want to just blindly pull in every link anyone listed in their notes documents. Lets focus on getting the good stuff in.
2. Aggregating project ideas. This can be done in a new section of the stage-1-project-discovery.md document, or in a new standalone document if that seems more appropriate. The end goal is to fully merge everyone's work into a common list of projects. If multiple people have investigated the same project, work together to merge what you've written into a common description of the project.

Towards the end of this cohort, we'll be looking to do something to showcase the work that's been done as part of the program. This issue is just going to sit here as a placeholder representing the intent to do this. Details will get fleshed out as we get closer.

I think there's a document I'll try to produce this week which I'll title something like "how to actually be helpful".

The desire to help is easy. Actually being helpful is often much harder.

The blanket offer of help is often not actually helpful. "Hi, how can I help?". It may appear on the surface that you are being helpful, but actually taking advantage of this type of offer is profoundly difficult. We don't know what you are good at. We don't know what you know. And we're often already busy with other things so taking the time to tease this information out and guide you towards an appropriate task is often significant.

The best help comes from those that take responsibility of doing the discovery work themselves. Take time to look through open github issues for ones that appear within your ability.

Another type of "non-help" I've run into is over-planning. Someone might find an issue, and then spend a lot of time laying out a very well thought through plan for how they plan to execute on it. Then they ask me for feedback on their plan. The feedback I have is almost always the same: "Lets see what the implementation actually looks like".

The best type of help is the type that still asks questions when necessary, but also puts forth an effort to figure things out for themselves. Have you actually read the contributing documentation? Have you actually looked through other pull requests to see how things are typically done? Have you actually spent any real effort trying to answer the question yourself before asking? The best help is the type that takes initiative.

Hi, is the discord only open to the cohort-zero participants?

It seems to be invalid. I'd love to be a part of the discussions if this is open to others.

Do you have something that "needs to be figured out"? Or maybe an interesting idea that you just don't have time to execute on? Maybe an upcoming EIP that needs a proof-of-concept implementation? A valuable data-set that needs to be extracted from the chain data? Some analysis of deployed smart contract bytecode? If so, you can feel free to drop it into this repository as an issue.

We'll use the "help wanted" label to flag these if/as they show up.

Set me back on track since I am new to eth dev, yet I have a thought that may prevent many front-running attacks. Searching for contemplations or reasons why this wouldn't work (or in the event that I simply need sufficient comprehension of eth):

Fundamentally, the consensus is changed to implement that transactions inside a block are executed in a particular yet non-predictable order. for instance: The miner chooses the transaction they need to include for the block, these are sorted by gwei and account nonce, the PoW nonce is then used to seed a Mersenne Twister (or other appropriate PRNG) which is utilized to play out a Fisher–Yates shuffle on the sorted transactions, they are then executed in this new order. Utilizing the PoW nonce implies that the transaction execution order can't be anticipated by observing the mempool alone, preventing sandwich and some other front-running attacks from working. The block can be approved/validated by watching that its PoW nonce was utilized to effectively sort the transactions. I don't know PoS all around ok to propose an equivalent, yet certainly there should be something. am I missing something?

Ethereum network crawler is software, which uses its p2p protocol to discover peers in the network and collect info about them. Crawler like this is part of Tuweni tool stack - https://github.com/apache/incubator-tuweni.
More info about backend design can be found in this video - https://www.youtube.com/watch?v=-BDarYVhS1s.

Crawler serves output at configured REST endpoint. Public instance can be found at https://crawler.tmio.io/ with crawled data here: peers https://crawler.tmio.io/rest/peers?limit=1000 and clients https://crawler.tmio.io/rest/clients

Goal is to create user interface which would crunch collected metrics and display similarly to ethernodes.org. Specifically, numbers with charts for:

• Number of nodes over time
• Different client software
• Client software version (% of compatibility with given network upgrade)
• eth protocol version support

This UI can be based on existing basic frontend of the crawler. Feel free to open issues, PRs in Tuweni repo, everything is FOSS and looking forward to contributions. It would be best to have it ready during next few weeks to track London upgrade readiness. If you have any questions contact me and for technical details author - http://github.com/atoulme at Tuweni discord https://discord.gg/zHHPRpT

The Quilt team has begun initial work on writing an executable python specification. The project is in the early stages here:

https://github.com/quilt/eth1.0-specs

The project is in early stages. Expect to spend your own effort finding where you can contribute and how, as the project isn't necessarily at a stage where it is easy to bring on new contributors. Consider things like looking for parts of the protocol which have not yet been implemented as well as expanding the number of consensus tests that are being executed.

I have a cool project (1 or 2 days) for someone with experience in web development + web3
So for the testnets we usually deploy a forkmon e.g. https://forkmon.ethdevops.io/
Which shows the state of the network/ which node is on which fork etc.
I just implemented a new RPC call debug_burned which shows the amount of ether burned by EIP-1559 which is scheduled for the upcoming London fork and I would love to have a site similar to the forkmon which just shows this for the last 10 blocks individually and for the overall.
This would be really cool for the testnet forks (and maybe later for mainnet)
So if you're interested in working on that, ping me. I'll try to assist as much as possible, but I am not good in webdev

you can ping me on discord -> MariusVanDerWijden

After going through the program meta, I have been struggling about what would be considered a good project. Because I came across Eth hole where there's great practice developer project ideas but most of the projects already exists.

My question is what constitutes a good project, should the ideas be based on existing projects with an intention to make our own better the currently existing ones or It should be ideas that has never been done before?

We want, and maybe need to fully deprecate the legacy transaction types. This is motivated, or potentially required under state expiry. One common objection to this is that there may be transactions that were signed by cold wallets and then put into cold storage to be broadcast at some later time. Similarly, there are hardware wallets that support the current transaction type which may not be updated.

One route to deprecating these legacy transaction types at the consensus protocol level while still retaining support for them would be a precompile. Suppose you have some legacy transaction L. The idea would be that you would wrap it up in one of the new supported transaction types, and then within the EVM send it to the precompile which would handle dispatching the transaction at the EVM level.

This needs to be investigated to see whether it is viable, determine roughly how it would work, and understand any trade-offs that it might have.

If you would like an invite to the R&D discord, please leave an email address in a comment on this issue and we'll get one sent your way.

I'm writing a review of the existing litterature on state expiry, statelessness & related topics such as light clients.
It's here: https://www.notion.so/norswap/State-Expiry-Statelessness-in-Review-8d531abcc2984babb9bf76a44459e611

It's still a work in progress, though it's getting close to being finished. Posting it now so that I can show it in the first call tonight.

I'd appredicate any kind of comments on what I currently have, answer to questions, or even contributions to the text.

Feel free to comment on Notion, or to post your high-level thoughts in this issue.