February 26 at tl;dc (too long, I didn’t call)
Disclaimer: This is a summary of topics covered in the recurring Eth1.x research call and does not represent finalized plans or commitments regarding network upgrades.
The main themes of this call were:
- The rough plan for the 1.x research summit in Paris following EthCC
- The format of the witness
- The “data recovery problem”
Logistics
The summit to discuss and collaborate on Stateless Ethereum is planned for the weekend following EthCC, which will be a much-needed time to work on the most important and unresolved issues in this effort.
The schedule is not yet fixed, but an outline is emerging:
SATURDAY – After an hour of breakfast and free discussion, we will meet to agree on the objectives and scope of the summit. Then, approximately 4 hours are set aside for curated presentations and “deep dives” on particular topics of importance. In the late afternoon/evening there will be another hour of free time and informal discussion.
Sunday – As before, but with only 2 hours of structured presentations, to encourage participants to divide into groups and work on the different research or implementation topics for the rest of the Summit. Finally, there will be a final discussion to define next steps and revise the tech tree.
It should be clarified that this research summit is not focused on public or general engagement in favor of significant progress in future work. This is not a spectator event, and indeed participants are expected to have “done their homework” so that the limited time allocated for discussions is used effectively.
Technical discussion
Cookie format
The first technical discussion topic focused on the recently submitted project draft witness specificationwhich will help define the implementation for all client teams.
The cookie specification is actually made up of two parts: semantics and format. This organization has the desirable property of clearly separating two aspects of the witness which could have different objectives.
Semantics is a little harder to master and is simply about the abstract methods of taking a group of objects and transforming them into other objects. The semantics of cookies are written in a simple formal language describing how to pass from inputs to outputs, leaving out all the implementation details. For example, questions about serialization or data parsing are not relevant to cookie semantics, as they are more of an implementation detail. The main goal of formally defining cookie semantics is to have a completely unambiguous reference that customer teams can implement without much back-and-forth. Certainly, starting with formal semantics and working towards the implementation (rather than coding a reference implementation) is experimental, but it is hoped that this will save effort in the long run and lead to much more Stateless Ethereum implementations. robust and diverse. The format is much more concrete and specifies real details that affect interoperability between different implementations.
The witness format is where things like the size of pieces of code will be defined, and a good witness format will help different implementations remain interoperable and, in general terms, describes the encoding and decoding of data. The format is not specifically intended to reduce cookie size, but rather to maintain the memory efficiency of client implementations and maximize generation and transmission efficiency. For example, the current format can be calculated in real time while running through the status test without having to buffer or process entire chunks, allowing the cookie to be broken into smaller chunks and streamed .
As a first draft, there should be some refactoring before and after Paris as other researchers give feedback, and there is already a demand for a bit more content on design motivations and high-level explanations regarding the content above. It was also suggested on the call that the witness format be written into an upcoming “The 1x Files” article, which sounds like a great idea (stay tuned for that in the coming weeks).
Validation of transactions, an interlude
Moving on to less concrete discussion topics, a fundamental question was raised in the chat that merits discussion: a potential problem with validating transactions in a stateless paradigm.
Currently, a node performs two checks on all transactions it sees on the network. First, the transaction nonce is checked to be consistent with all transactions in that account, and rejected if it is not valid. Second, the account balance is checked to ensure that the account has enough money for gas. In a stateless paradigm, these controls cannot be carried out by anyone who does not own the state, which opens up a potential vector of attack. It is entirely possible that the cookie format could include the minimum amount of state data required to validate transactions from cookies only, but this needs to be examined in more detail.
The transaction validation problem is actually related to a more general problem that Stateless Ethereum needs to solve, which is tentatively called “the data recovery problem.” The data recovery solution will also solve the transaction validation issue, so we will come back to that now.
Data Recovery in Stateless Ethereum
The full scope of this challenge is described in an ethresearch forum postbut the idea is relatively simple and built from a few hypotheses:
It is possible, in the current context eth protocol, create a stateless client using existing network primitives. It is sort of what beam sync is, with the important distinction that beam sync is intended to hold state data and “fill” it to eventually become a complete node. In contrast, a stateless client throws away state data and relies entirely on witnesses to participate in the network.
Current protocol and network primitives assume that there is a high probability that connected peers maintain valid state, i.e., connected peers are full nodes. This assumption is valid now because most nodes are indeed full nodes with valid state. But this assumption is not reliable if a high proportion of the network is stateless. The current protocol also makes not specify a way for a new connected node to see whether or not a connected peer has necessary state data.
Stateless clients have better UX than full nodes. They will synchronize more quickly and allow an almost instantaneous connection to the network. It is therefore reasonable to assume that over time more and more nodes will move towards the stateless end of the spectrum. If this is the case, the data availability assumption will become increasingly weak with a higher proportion of stateless nodes in the network. There is a theoretical “tipping point” where stateless nodes far outnumber stateful nodes, and a random assortment of peers has a sufficiently low probability that at least one of them holds element d ‘Desired state. At this (theoretical) point, the network breaks.
The thing here is that if the network allows state to be obtained on demand (as is currently the case), a stateless client can (and will) be created on the same protocol. Expanding this reasoning to make it more dramatic: stateless clients are inevitable, and the problem of data recovery will accompany them. It therefore follows that significant changes in eth A network protocol will need to be developed to categorically prevent the network from reaching this tipping point, or at least push it further away through client optimizations.
There are many open topics to discuss here, and most importantly, there is disagreement among 1x researchers about exactly how far the network is from this theoretical breaking point, or whether the breaking point exists at all. This highlights the need for more sophisticated approaches to network simulation, as well as the need to clearly define the problem at the top of the research before pursuing a solution.
See you later !
Exciting things will undoubtedly unfold as a result of the in-person research that will be carried out in Paris over the next fortnight, and future episodes of “The 1.x Files” will be dedicated to documenting and clearly presenting this work.
The Paris Summit is almost sold out, so if you have not completed the RSVP form to attend, please contact Piper to see if there is space.
As always, if you would like to participate in the Stateless Ethereum research effort, join us at ethresear.ch, be a guest in the Telegram group, and contact @gichiba and/or @JHancock on Twitter.
