1.x file: February meeting summary

February 26 tl;dc (I didn’t call because it was too long)

disclaimer: This is a summary of topics discussed in recurring Eth1.x research meetings and does not represent final plans or commitments to network upgrades.

The main topics of this call are:

• Rough plans for the 1.x Research Summit in Paris following EthCC
• witness format
• ‘Data retrieval issues’

logistics center

A summit to discuss and collaborate on stateless Ethereum is scheduled for the weekend after EthCC, which will be an integral time to address the most important and unresolved issues in this effort.

The schedule hasn’t been confirmed yet, but here’s a rough outline:

Saturday – After an hour of breakfast and free discussion, we will come together to discuss the goals and scope of the summit. Approximately four hours are then reserved for structured presentations and ‘deep dives’ on specific topics of importance. There will be an hour or more of free time and informal discussion in the late afternoon/evening.

sunday – Same as before, but with just two hours of structured presentations, encouraging attendees to break into groups and work on different research or implementation topics for the remainder of the summit. Finally, there will be a final discussion to plan next steps and revise the skill tree.

It should be stated that this research summit will not focus on public or general engagement to make meaningful progress in future work. This is not an event for spectators, and indeed there is an expectation that attendees will complete their ‘homework’ and make the short discussion time efficient.

technical discussion

witness format

The first topic of technical discussion centered around recently submitted papers. Draft Witness SpecificationThis helps define the implementation for all client teams.

The watch specification actually consists of two parts: semantics and format. This organization has the desirable characteristic of clearly separating the two sides of the witness, which may have different goals.

Semantics is a little more difficult to understand and only concerns abstract ways of taking one group of objects and transforming them into another. Witness semantics are a simple formal language that describes how to move from input to output, with all implementation details abstracted away. For example, questions about serializing or parsing data are not related to witness semantics because they are closer to implementation details. The high-level goal of defining the meaning of a witness in a formal way is to have a completely clear reference that the client team can implement without a lot of back and forth. Of course, starting with formal semantics and working towards implementation (instead of coding a reference implementation) is experimental, but it is expected to save effort in the long run and lead to a much more robust and versatile Stateless Ethereum implementation. The format is much more specific and specifies actual details that affect interoperability between various implementations.

The watch format is where things like the size of code chunks are defined. A good watch format helps different implementations maintain interoperability and generally accounts for the encoding and decoding of data. This format is not specifically geared towards reducing watch size, but rather keeping client implementations memory efficient and maximizing creation and transfer efficiency. For example, a watch can be split into small chunks and streamed, as the current format can be computed in real time while traversing the state tree without having to buffer or process the entire chunk.

As a draft, I expect there will be some refactoring before and after Paris with feedback from other researchers, and there are already requests for more details on design motivation and high-level explanations related to the above. There was also a suggestion on the call to fill out a witness form for an upcoming “The 1x Files” post, which seems like a good idea (stay tuned for this in the coming weeks).

Transaction Verification, Interlude

Moving on to less specific topics of discussion, one fundamental issue was raised in the chat that required discussion. This is a problem that can occur when verifying transactions in the stateless paradigm.

Currently, nodes perform two checks on every transaction they see on the network. First, the transaction nonce is checked to see if it matches all transactions in that account, and if invalid, is discarded. Second, check your account balance to make sure you have enough gas funds in your account. In a stateless paradigm, a stateless person cannot perform these checks, creating a potential attack vector. A witness form could be created to include the minimum state data required to verify the witness’ transaction, but this would require further investigation.

The transaction validation problem is actually related to a more general problem that stateless Ethereum must solve, tentatively called the “data retrieval problem.” Data retrieval solutions also solve the problem of transaction validation, so let’s look at that now.

Stateless Ethereum Data Retrieval

The full scope of this challenge is described. From an ethresearch forum post:However, the idea is relatively simple and built on a few assumptions.

It is possible, within the present to Use protocols to build stateless clients using existing network primitives. this is sort of What is beam synchronization? The important difference is that Beam Synchronization maintains state data and ‘backfills’ it to eventually become a full node. In contrast, stateless clients discard state data and rely entirely on witnesses to participate in the network.

Current protocols and network primitives assume that connected peers have a high probability of maintaining a valid state. This means that the connected peer is likely to be a full node. This assumption currently holds true because most nodes are actually full nodes with valid state. However, if a high percentage of the network is stateless, this assumption may not be reliable. The current protocol also ~ no Specifies a method for a new connected node to determine whether the connected peer has the required state data.

Stateless clients have a better UX than full nodes. Sync speeds are faster and you can connect to the network almost instantly. Therefore, it is reasonable to assume that over time more and more nodes will move towards the stateless end of the spectrum. In this case, as the proportion of stateless nodes in the network increases, the assumption of data availability becomes increasingly valid. There is a theoretical ‘tipping point’ where stateless nodes greatly outnumber stateful nodes, and the probability that at least one randomly selected peer holds the desired state is low enough. At that (theoretical) point the network will crash.

The key point here is this. If the network allows state to be obtained on demand (as it does now), stateless clients can (and will) be built on the same protocol.. Extending this reasoning even more dramatically, stateless clients are inevitable and bring with them data retrieval problems. This brings about the following important changes: to Network protocols need to be created to absolutely prevent the network from reaching that tipping point, or at least push it further through client optimization.

There are many open topics to discuss here, and importantly, there is disagreement among 1x researchers about how far the network is from its theoretical threshold, or whether a threshold exists. This highlights the need for more sophisticated approaches to network simulation and the need to clearly define the problem in research conferences before finding solutions.

See you later !

Exciting things will undoubtedly unfold as a result of the direct research to be conducted in Paris over the next two weeks, and the next few installments of “1.x Files” will be devoted to documenting and clearly laying out that work.

The Paris Summit is almost at capacity, so if you haven’t completed the RSVP form, please contact Piper to see if there is space available.

As always, if you are interested in participating in Stateless Ethereum research activities, join us at ethresear.ch, get invited to our Telegram group, and connect with @gichiba and/or @JHancock on Twitter.