Feb 26 tl;dc (too long, didn’t converse)
Disclaimer: This is a summary of all the topics discussed in the Eth1.x Recurring Inquiry Call and does not reflect any finalized plans or commitments to network upgrades.
The main themes of the call were:
- The rough plan for the 1.x Research Summit In Paris after EthCC
- The Witness format
- The “Data recovery problem”
Logistics
The Summit is an opportunity to discuss and collaborate on Stateless Ethereum. The weekend after EthCC will be a critical time for people to focus on the most important and unresolved issues.
Although the exact timeframe has not been established yet, a rough outline is being created.
Saturday – After having breakfast, we’ll discuss the scope and goals of the summit. For presentations that are organized, there is approximately 4 hours of time for “deep dives” into specific topics. The afternoon/evening meetings will conclude with an hour of informal conversation and free time.
Sunday – Presentations were limited to 2 hours, as opposed to the previous day. To encourage attendees to form groups to work together on research topics and implementations, the number of presenters was limited to two. A final discussion will take place to discuss the next steps as well as the tech tree.
This Summit does not seek general or public commitment. Instead, it is focused on making significant progress in the work ahead. It is not intended to be passive. In fact, it is reasonable to expect that participants will have “done their homework” so that time for discussion is spent efficiently.
Technical Discussion
Token Format
The first topic discussed was the Witness Specification project, which will be used for determining the deployment of all client computers.
The Token Specification is made up of two parts: semantics (or format) and format (or both). Organizations have the unique ability to neatly separate two elements of testimony that could serve different purposes.
The Semantics are more complicated and concentrate on abstract methods of taking a group object and turning it into another object. A simple formal language can describe semantics. It explains how to move from inputs into outputs, but leaves the details of implementation to the reader. Semantics does not concern data parsing or serialization. These details are more important for implementation. The high-level goal of defining token semantics was to provide a clear reference customers can use without much back and forth.
The Token Format is where code fragments are defined. Different implementations will be able to work together with a good token format. It also describes the process of data decoding and encoding. It is not intended for reducing token sizes but to maximize transmission, generation efficiency, and memory efficiency for client implementations. For example, you can quickly compute the current format in real-time while the state tests are being completed. The token can then be broken into smaller pieces and sent.
Expect a first draft to include refactoring. Other researchers are giving feedback. There is a request to add content on design motivations and a high-level explanation for the existing content. It was also suggested that the witness form should be covered on a future conference call “The 1x Files”. This sounds like a great idea. Keep an eye out in the coming weeks for this development.
Transaction Validation Anomaly
interlude
Assessing the Issue: The chat session also discussed the significant issue of transaction validation in a stateless system.
Currently, every transaction seen on the network is double-checked by a node. First, the nonce is checked to make sure it is valid, and then the balance is checked as a way to confirm that there is enough gas in the account. These checks cannot be done in a stateless world, which could lead to an attack. To avoid this, it may be possible to only include the bare minimum information required to validate transactions, although more research is needed.
The challenge of transaction validation is a larger issue that needs to be solved – the “Data Recovery Problem”. Data recovery may be the answer, and the team is working on it.
Data Recovery on Stateless Ethereum
The scope of the challenge can be found on the ethresearch forum. The concept is simple and is based on a few assumptions.
It is possible to create a stateless client using the existing network primitives in the protocol. This is similar to beam sync, which stores state data and then “pads” it so it can become a full node. A stateless client can discard all state data and then access it when needed.
The protocol and network primitives assume a high probability that connected peers are full nodes. However, this is not always the case as a large portion of the network is stateless. The protocol does not define how a new node should determine if a peer needs state data.
Stateless clients have a better user experience than full nodes, as they can sync faster and connect to the network instantly. There is a possibility that the number of stateless nodes will increase, resulting in an unreliable data availability. If a certain threshold is reached, the network could reach a tipping point.
The trick is that if the network allows state data to be accessed upon request (as it does now), then stateless clients can do the same within the same protocol. Additionally, the protocol can be updated to prevent the network from reaching a tipping point. This can be done by optimizing the client.
There are many topics to discuss, and researchers disagree on whether a breakpoint exists. It is necessary to identify the problem and search for a solution during the summit. Furthermore, network simulations require advanced methods.
Let’s Get Started!
Exciting Things Ahead: The in-person investigation will help us get to the bottom of this. Over the next two weeks, we will be documenting and sharing the details in the “1.x Archives”. The summit in Paris is nearly full – if you haven’t RSVP’d yet, please contact Piper to see if there is space.
If you are interested in taking part in this, join the Telegram Group or reach out to @gichiba or @JHancock on Twitter. If you need assistance with your research, contact us at ethersear.ch.
