January – Earlybirds Invest

January 14th tl;dc (too long, didn’t call)

Disclaimer: This is a digest of the topics discussed in the recurring Eth1.x research call, and doesn’t represent finalized plans or commitments to network upgrades.

The main topics of this call were

Rough data quantifying advantages of switching to a binary trie structure
Transition strategies and potential challenges for a switch to binary tries
“Merklizing” contract code for witnesses, and implications for gas scheduling/metering
Chain pruning and historical chain/state data — network implications and approaches to distribution.

Logistics

The weekend following EthCC (March 7-8), there will be a small 1.x research summit, with the intent of having a few days of solid discussion and work on the topics at hand. The session will be capped (by venue constraints) at 40 attendees, which should be more than enough for the participants expected.

There will also likely be some informal, ad-hoc gathering around Stanford Blockchain week and ETHDenver, but nothing explicitly planned.

The next call is tentatively scheduled for the first or second week in February — half-way between now and the summit in Paris.

Technical discussion

EIP #2465

Although not directly related to stateless ethereum, this EIP improves the network protocol for transaction propagation, and is thus a pretty straightforward improvement that moves things in the right direction for what research is working on. Support!

Binary Trie size savings

Transitioning to a binary trie structure (instead of the current hexary trie structure) should in theory reduce the size of witnesses by something like 3.75x, but in practice that reduction might only be about half, depending on how you look at it..

Witnesses are about 30% code and 70% hashes. Hashes within the trie are reduced by 3x, but code is not improved with a binary trie, since it always needs to be included in the witness. So switching to a binary trie format will bring witness sizes to ~300-1400kB, down from ~800-3,400kB in the hexary trie.

Making the switch

Enacting the actual transition to a binary trie is another matter, with a few questions that need to be fleshed out. There are essentially two different possible strategies that could be followed:

progressive transition — This is a ‘ship of Theseus’ model of transition whereby the entire state trie is migrated to a binary format account-by-account and storageSlot-by-storageSlot, as each part of state is touched by EVM execution. This implies that, forevermore, Ethereum’s state would be a hexary/binary hybrid, and accounts would need to be “poked” in order to be updated to the new trie format (maybe with a POKE opcode ;). The advantages are that this does not interrupt the normal functioning of the chain, and does not require large-scale coordination for upgrading. The disadvantage is complexity: both hexary and binary trie formats need to be accounted for in clients, and the process would never actually “finish”, because some parts of the state cannot be accessed externally, and would need to be explicitly poked by their owners which probably wont happen for the entire state. The progressive strategy would also require clients to modify their database to be a kind of ‘virtualized’ binary trie inside of a hexary database layout, to avoid a sudden dramatic increase in storage requirements for all clients (note: this database improvement can happen independent of the full ‘progressive’ transition, and would still be beneficial alone).

compute and clean-cut — This would be an ‘at once’ transition accomplished over one or more hard-forks, whereby a date in the future would be chosen for the switch, and then all participants in the network would need to recompute the state as a binary trie, and then switch to the new format together. This strategy would be in some sense ‘simpler’ to implement because it’s straightforward on the engineering side. But it’s more complex from a coordination perspective: The new binary trie state needs to be pre-computed before the fork which could take an hour (or thereabouts) — during that window, its not clear how transactions and new blocks would be handled (because they would need to be included in the yet-un-computed binary state trie, and/or the legacy trie). This process would be made harder by the fact that many miners and exchanges prefer to upgrade clients at the last moment. Alternatively we could imagine halting the entire chain for a short time to re-compute the new state — a process which might be even trickier, and potentially controversial, to coordinate.

Both options are still ‘on the table’, and require further consideration and discussion before any decisions are made with regards to next steps. In particular weighing the trade-offs between implementation complexity on one hand and coordination challenges on the other.

Code “chunking”

Addressing the code portion of witnesses, there has been some prototyping work done on code ‘merklization’, which essentially allows contract code to be split up into chunks before being put into a witness. The basic idea being that, if a method in a smart contract is called, the witness should only need to include the parts of the contract code that were actually called, rather than the entire contract. This is still very early research, but it suggests an additional ~50% reduction in the code portion of a witness. More ambitiously, the practice of code chunking could be extended to create a single global ‘code trie’, but this is not a well developed idea and likely has challenges of its own that warrant further investigation.

There are different methods by which code can be broken up into chunks, and then be used to generate witnesses. The first is ‘dynamic’, in that it relies on finding JUMPDEST instructions, and cleaving near those points, which results in variable chunk sizes depending on the code being broken up. The second is ‘static’, which would break up code into fixed sizes, and add some necessary metadata specifying where correct jump destinations are within the chunk. It seems like either of these two approaches would be valid, and both might be compatible and could be left up to users to decide which to employ. Either way, chunking enables a further shrinking of witness sizes.

(un)gas

One open question is what changes would be necessary or desirable in gas scheduling with the introduction of block witnesses. Witness generation needs to be paid for in gas. If the code is chunked, within a block there would be some overlap where multiple transactions cover the same code, and thus parts of a block witness would be paid for more than once by all the included transactions in the block. It seems like a safe idea (and one that would be good for miners) would be to leave it to the poster of a transaction to pay the full cost of their own transaction’s witness, and then let the miner keep the overpayment. This minimizes the need for changes in gas costs and incentivizes miners to produce witnesses, but unfortunately breaks the current security model of only trusting sub-calls (in a transaction) with a portion of the total committed gas. How that change to the security model is handled is something that needs to be considered fully and thoroughly. At the end of the day, the goal is to charge each transaction the cost of producing its own witness, proportional to the code it touches.

Wei Tang’s UNGAS proposal might make any changes to the EVM easier to accomplish. It’s not strictly necessary for stateless Ethereum, but it is an idea for how to make future breaking changes to gas schedules easier. The question to ask is “What do the changes look like both without and with UNGAS — and those things considered, does UNGAS actually make this stuff significantly easier to implement?”. To answer this, we need experiments that run things with merklized code and new gas rules appled, and then see what should change with regard to cost and execution in the EVM.

Pruning and data delivery

In a stateless model, nodes that do not have some or all of the state need a way to signal to the rest of the network what data they have and what data they lack. This has implications for network topology — stateless clients that lack data need to be able to reliably and quickly find the data they need somewhere on the network, as well as broadcast up-front what data they don’t have (and might need). Adding such a feature to one of the chain-pruning EIPs is a networking (but not consensus) protocol change, and its something that also can be done now.

The second side of this problem is where to store the historical data, and the best solution so far proposed is an Eth-specific distributed storage network, that can serve requested data. This could come in many flavors; the complete state might be amenable to ‘chunking’, similar to contract code; partial-state nodes could watch over (randomly assigned) chunks of state, and serve them by request on the edges of the network; clients might employ additional data routing mechanism so that a stateless node can still get missing data through an intermediary (which doesn’t have the data it needs, but is connected to another node that does). However it’s implemented, the general goal is that clients should be able to join the network and be able to get all the data they need, reliably, and without jockying for position connecting to a full-state node, which is effectively what happens with LES nodes now. Work surrounding these ideas is still in early stages, but the geth team has some promising results experimenting with ‘state tiling’ (chunking), and turbo-geth is working on data routing for gossiping parts of state.

As always, if you have questions about Eth1x efforts, requests for topics, or want to contribute, attend an event, come introduce yourself on ethresear.ch or reach out to @gichiba and/or @JHancock on twitter.

In today’s roundup, we’re excited to feature four recipients from a recent Local Grants wave in Japan! We see Ethereum as an ever-growing, creative and inclusive playground, and it is our responsibility to let everyone keep playing.

It’s not easy to commit to public goods or novel use cases without a quick financial return, and it’s important to support the dedicated teams working to solve interesting problems, improve public infrastructure and build creative blockchain use cases. In this Local Grants round, the Ethereum Foundation is happy to shine a spotlight on a local community proactively working to demonstrate the potential of decentralized technology.

zkCREAM: Zero-knowledge Confidential Reliable Ethereum Anonymous Mixer

zkCREAM:Confidential Reliable Ethereum Anonymous Mixer is a set of protocols and dapps which enables more robust, accessible, secure, anonymous, and verifiable voting for public elections in Japan. zkCREAM is developed as a pilot program. It consists of a set of smart contracts and user-friendly interface app that allows the average general public to vote in a completely anonymous fashion while maintaining the integrity and verifiability of the final vote tallies. It also supports MACI making it more collusion resistant, reliable, and anonymous.

The team’s next focus of the development is to build both mobile and desktop voting application that are easy to use. It will showcase and leverage the use of zkCREAM in the Ethereum community. In addition, the team will develop additional voting logic layers to support other common scenarios, such as quadratic voting, instant runoff voting, and ranked-choice voting.

Ryodan System AG: Building Layer 2 with zkRollups and zkCloud

The Ryodan team works on problems of scalability, privacy, and code complexity. They take a multi-faceted approach that incorporates both protocol R&D, and building tools to make zero knowledge proofs more accessible to developers.

The zkCloud service aims to help developers use zero-knowledge proofs to write smart contracts and programs more easily. zkCloud currently supports Groth16 and PLONK proofs, with STARKs coming soon. The team is also developing an optimized zkSTARK Rust library, along with other tools to enable a no-code approach to zero knowledge-based applications.

The team is also developing a new zk-rollup, based on a design proposed by CEO Leona Hioki. The approach offers potential privacy and efficiency improvements by not requiring transaction history data for contract execution.

Startrail: Records Infrastructure for Physical and Digital Artwork

Startrail is an Ethereum-based infrastructure for recording the provenance and exhibition history of both physical and digital artwork. In addition to using ERC721 to represent an artwork or its certificate, NFC chips can be attached to physical artworks and associated with the certificate on the blockchain.

CEO Taihei himself is a contemporary artist who was inspired to use blockchain technology to solve pain points he experienced in the art industry. Since 2016, he has built a team of people from both art and technical backgrounds who are inspired by the possibilities of distributed ledger technology to solve problems of provenance and compliance in art ownership. They work with people from the art industry, such as artists, gallerists, curators and web-based marketplaces, to make sure that they meet their practical needs in operation.

The team’s next goals include open sourcing their smart contracts and expanding their infrastructure to the global market. Advocating for the rights of all people in the art industry, including artists and collectors, they hope to bring all kinds of art industry participants into the Ethereum ecosystem.

w3a.io: Smart Lock Authentication for Physical Devices

W3a.io uses Ethereum to verify usage rights for physical devices. The team first explored the concept in 2020 in a joint experiment with Nara Institute of Science and Technology (NAIST) in which they trialed a blockchain-based system for automated car sharing on the NAIST campus. A “virtual key” allowed an authorized user to lock and unlock a car with their smartphone, and users were incentivized to return cars to locations where they would be in the highest demand.

W3a.io builds on the concept and learnings from the NAIST pilot, using digital signatures to authenticate authorized operators of physical devices even while offline. The team hopes it can be applied to many use cases to make it easier to bring Ethereum into the real world!

Famiee: Partnership Certificates on Ethereum

Famiee is a non-profit dedicated to helping all types of families access the benefits available to legally married couples through a platform for issuing partnership certificates on Ethereum. A network of participating corporations provide services for couples who hold Famiee certificates, giving them access to benefits that would otherwise only be available to legally married couples such as employee family benefits, joint mortgage applications, family discounts, public assistance or life insurance.

Famiee began issuing certificates for same-sex partners in February 2021, and plans to extend the service to include other types of families and partnerships that are not legally recognized in certain places, such as marriages where women choose to keep their original names or single mothers living together to support each other. They are currently working on a mobile app to issue certificates that meet a high standard for privacy protection, security and KYC.

Countless local Ethereum communities around the world are a big part of why Ethereum feels simultaneously global and personal for so many people. Accordingly, we are continuously experimenting with ways to support local communities around the world.

Again, thank you to all of the contributors who are promoting Ethereum adoption in the real world, and if you think you’re the next one, please head to our grants page to learn more about what we look for in the projects we fund.