February 26th tl;dc (too lengthy, did not call)
Note: This is a summary of the subjects deliberated in the ongoing Eth1.x research conference call, and does not reflect finalized intentions or commitments pertaining to network enhancements.
The principal subjects of this call included:
- The tentative agenda for the 1.x research summit in Paris following EthCC
- The Witness Format
- The ‘data retrieval dilemma’
Arrangements
The gathering to deliberate and collaborate on Stateless Ethereum is scheduled for the weekend following EthCC, which will be a crucial time for addressing the most significant and unresolved challenges related to this initiative.
The agenda is not yet finalized, but a preliminary outline is being developed:
Saturday – Following an hour dedicated to breakfast and open discussion, we will convene to establish objectives and scope for the summit. Approximately 4 hours will be allocated for structured presentations and ‘deep dives’ into specific pertinent subjects. Later in the afternoon/evening, there will be over an hour of additional free time and informal conversation.
Sunday – Similar to the previous day, but restricted to only 2 hours of structured presentations, encouraging participants to form groups and work on various research or implementation subjects for the remainder of the Summit. To conclude, there will be a final discussion to outline subsequent steps and update the technology tree.
It is important to note that this research summit is not aimed at public or general participation, prioritizing significant advancement on the impending tasks. This is not intended to be a spectator event, and there is indeed an expectation that participants will have ‘prepared’ so that the limited time for dialogue is utilized effectively.
Technical discourse
Witness Format
The first subject of technical discussion revolved around the recently submitted draft witness specification, which will aid in defining implementation for all client teams.
The witness specification essentially consists of two components: Semantics and Format. This structure has the beneficial effect of distinctly separating two elements of the witness that may have different purposes.
Semantics can be somewhat challenging to grasp, focusing solely on the abstract processes of converting one set of objects into another. The witness semantics are expressed in a simple formal language, detailing how to transition from inputs to outputs, while leaving all implementation specifics abstracted. For instance, inquiries regarding data serialization or parsing are not pertinent to the witness semantics, as they pertain more to implementation specifics. The overarching objective of formally defining the semantics of witnesses is to establish a completely unambiguous reference for client teams to implement without excessive back-and-forth. Although starting with formal semantics and proceeding towards implementation (rather than, for instance, developing a reference implementation first) is experimental, it is anticipated that this approach will conserve effort in the long term and result in more resilient and varied Stateless Ethereum implementations. The Format aspect is far more tangible, specifying actual details that influence interoperability across various implementations.
The witness format will define aspects like the size of code chunks, and an effective witness format will assist different implementations in maintaining interoperability, generally describing the encoding and decoding of data. The format is not specifically aimed at minimizing witness size but rather at ensuring client implementations are memory-efficient while maximizing the efficiency of generation and transmission. For instance, the current format can be computed in real-time while traversing the state trie without needing to buffer or process entire chunks, facilitating the division of witnesses into small segments that can be streamed.
As this is an initial draft, some revisions are expected both before and after Paris as feedback is provided by other researchers, and there have been requests for additional content on design motivations and high-level explanations related to the aforementioned content. It was also proposed during the call that the witness format be elaborated in an upcoming “The 1x Files” post, which appears to be an excellent idea (stay tuned for that in the upcoming weeks).
Transaction validation, an interlude
As the discussion gravitated toward less concrete issues, a fundamental concern arose in the chat that warrants examination: A prospective issue with validating transactions in a stateless model.
Currently, a node executes two checks on every transaction it encounters on the network. Firstly, the transaction nonce is verified to be consistent with all transactions from that account, and discarded if invalid. Secondly, the account balance is scrutinized to confirm that the account possesses sufficient gas funds. In a stateless framework, these checks cannot be conducted by anyone lacking access to the state, which creates a potential vulnerability for attacks. It is entirely plausible that the witness format could be designed to incorporate the minimal required state data to validate transactions solely from witnesses, but this needs further investigation.
The transaction validation dilemma is actually linked to a broader issue that Stateless Ethereum must address, tentatively referred to as “The data retrieval challenge”. The resolution for data retrieval will also address the transaction validation issue, so we will now shift our focus to that.
Data retrieval in Stateless Ethereum
The complete extent of this challenge is delineated in a post on the ethresearch forum, but the concept is relatively simple and based on a few assumptions:
It is feasible to construct a stateless client within the existing eth protocol using current network primitives. This resembles sort of what beam sync achieves, with the crucial distinction that beam sync is designed to maintain state data and ‘backfill’ it to ultimately evolve into a full node. A stateless client, on the other hand, discardsaway condition data and relies solely on witnesses to engage in the network.
The existing protocol and network components presume that there is a significant likelihood that connected peers maintain valid state, meaning that connected peers are complete nodes. This presumption holds today since the majority of nodes are indeed complete nodes with valid state. However, this presumption cannot be depended upon if a significant fraction of the network is devoid of state. The current protocol also does not outline a mechanism for a newly connected node to determine if a connected peer possesses or lacks a necessary piece of state data.
Stateless clients offer a superior user experience compared to full nodes. They will synchronize more rapidly, and facilitate almost instantaneous connections to the network. It is thus reasonable to speculate that over time, an increasing number of nodes will gravitate towards the stateless end of the spectrum. If this holds true, then the assumption regarding data availability will become increasingly questionable with a rising percentage of stateless nodes within the network. There exists a theoretical ‘tipping point’ where stateless nodes vastly outnumber stateful nodes, and a random collection of peers has a considerably low chance of at least one holding the sought-after piece of state. At that (theoretical) moment, the network collapses.
The notable point here is that if the network permits state to be acquired on demand (as it does currently), a stateless client can (and will) be developed utilizing the same protocol. Extending this logic further: Stateless clients are unavoidable, and the data retrieval challenge will accompany them. It follows that substantial modifications to the eth network protocol will need to occur to definitively avert the network from reaching that tipping point, or at the very least delay it through client enhancements.
Numerous open-ended subjects are available for discussion here, and notably, there is a lack of consensus among the 1x researchers about precisely how close the network is to that theoretical breaking point or if the breaking point even exists. This underscores the requirement for more advanced methodologies in network simulation, as well as the necessity to clearly define the problem at the research summit prior to advancing toward a solution.
À tout à l’heure !
Exciting developments will undoubtedly emerge as a result of the in-person research to take place in Paris in the coming fortnight, and the following installments of “The 1.x Files” will be dedicated to documenting and articulating that work clearly.
The summit in Paris is nearly at full capacity, so if you have not completed the RSVP form to attend, please contact Piper to inquire about available space.
As always, if you’re interested in taking part in the Stateless Ethereum research initiative, feel free to join us on ethresear.ch, obtain an invitation to the telegram group, and reach out to @gichiba and/or @JHancock on twitter.
