EF-Supported Teams: Research & Development Roundup

Friends,

As the year of the Merge ends, we wanted to share updates from many of the Ethereum gardeners and EF-supported teams that achieved long sought accomplishments, both big and small, alongside the rest of the ecosystem in 2022. We all have a lot to be thankful for, from the new communities we’ve come to know, to having each other through it all!

As always, this roundup series focuses on EF-supported teams whose members are working to grow and improve Ethereum as a whole. Included in this edition are updates from many teams highlighted in the previous report, and other new and rotating groups.

Enjoy!

Consensus R&D (aka EF Research Team)

Authored by Danny Ryan and Hsiao-Wei Wang

This was an extraordinary year. With the magic of client teams, DevOps wizards, testers, stakers, and the community at large, we successfully merged ✌️🐼!

THANK YOU ALL for contributing to The Merge, massively reducing energy consumption, and making Ethereum a more secure and sustainable protocol. Switching Ethereum mainnet consensus mechanism to Proof-of-Stake (PoS) was a significant milestone the Consensus R&D team has been working on for many years — but this is not the full story!

Additionally, the Consensus R&D team has been tackling emergent problems in the MEV domain (e.g. proposer builder separation (PBS), MEV smoothing/burning), pondering security improvements to the beacon chain (e.g. single slot finality (SSF), single secret leader election (SSLE)), and a whole host of other consensus research – multi-dimensional EIP-1559, better aggregation techniques, optimized applied cryptography, and more.

Next year, our team will continue working on, but not limited to, the following:

• Scheduled and tentative protocol upgrades
  
  1. Withdrawals functionality: this feature will enable stakers to withdraw their balances from the beacon chain to their execution layer accounts. The consensus-layer core specs are nearing completion, and client teams are actively implementing and testing the functionality.
  2. EIP-4844 aka proto-danksharding:

  
  

• Other post-merge research topics, e.g., proposer/builder separation (PBS), Verkle trie/statelessness, single slot finality (SSF), data availability sampling (DAS), fee market refinement, single secret leader election (SSLE), and more.

Cryptography Research

Authored by Dankrad Feist

The cryptography team has taken an initiative to make Ethereum secure against quantum computers. Our team members have contributed to a post-quantum signature scheme that is to be standardized by NIST (National Institute of Standards and Technology). We continue to work in this direction and build a signature scheme that scales better via aggregations. Further down the road, we may improve the scalability via better aggregation techniques, or via different hardness assumptions.

Fe-lang

Authored by Grant Wuerker

The Fe team aims to provide the Ethereum community with a safe and effective smart contract programming language. The team is responsible for the design of Fe-lang and the development of its core components, including the compiler, standard library, and tooling.

Over the past year, the team has been focused on adding language features and preparing for our first beta release. Below are the highlights from 2022:

Notable language features:

• Low-level intrinsic functions (0.12.0).
• Nested structs in memory (0.13.0).
• Std library with evm and context modules (0.14.0).
• Nested structs in storage (0.14.0).
• const folding (0.14.0).
• Function argument labels (0.15.0).
• Nested structs can be returned and passed into functions (0.19.1).
• Braces! (0.19.1).
• Traits and generic function parameters (0.19.1).
• Enums and match statements (0.20.0).
• mut keyword (0.20.0).

Please see the releases page for a complete list of changes.

Tooling:

• @zjhmale developed a Hardhat plugin.
• A couple contributors developed VS Code plugins:
  
  

Other:

• Yoshi has been working on a compiler backend specialized for smart contracts named Sonatina.
• A few simple contracts were verified using K.

Our top priorities moving into 2023 are: first beta release (see: Fe’s path to production), better generic support, better constant support, and improvements to the standard library. We are especially excited about future Bountiful challenges.

Formal Verification

Authored by FV team

hevm

We’ve spent most of this year rewriting the symbolic execution engine in hevm. This rewrite decompiles EVM into a custom intermediate representation and then issues SMT queries based on the structure of the terms in this IR. This architecture gives us significantly more control over the details of the SMT encoding and makes the implementation of custom simplification and static analysis stages much easier.

SMTChecker

In the past months we focused on bug fixing and UX improvements. One important new feature that was added is the possibility to use the Horn solver Eldarica when using the CLI or JSON interface from solc.

Yools

A few months ago we started Yools as a proof of concept, testing the idea that verifying Yul instead of both Solidity and EVM bytecode has a lot of advantages. The preliminary results are quite promising, and we’re excited to continue working on it in 2023.

PolySolver, a solver for generalized polynomials

We started this research branch with the goal of verifying properties of polynomials from ZK apps/circuits. We recently started applying it to R1CS circuits in collaboration with 0xPARC and other organizations.

Geth

Authored by Péter Szilágyi

2022 was a tad slower year when it came to shipping Geth features, but that is primarily due to the Ethereum Merge, which took up most of the team’s time for testing, tweaking and generally making sure everything ticks. That said, we do have a number of interesting things we’ve been working on in between.

Path-based trie storage

Perhaps the highlight upcoming feature – at least for us as maintainers – is Gary’s path-based trie storage. We figured out (a few years back) how to do state pruning, but needed to get rid of one blocker: fast sync. That meant shipping a new sync protocol (snap) not only for Geth, but also helping other clients get it out the door. With fast sync murdered, we can finally change the state-trie storage model in Geth from hash keys to path keys. Whilst this is an insanely invasive change in Geth, it will finally allow us to do full, real-time historical state pruning during block processing. The cherry on top is that full sync actually gets faster. 🙂

TL;DR A small teaser from a while back.

Light clients

One victim of The Merge was light clients. Previously, they only needed to follow the chain of headers, check the PoW, and download Merkle proofs to access the Ethereum state. In a post-merge world, however, PoW is gone, and thus light clients cannot rely on execution layer headers alone to follow the chain. The only viable solution is to follow the beacon chain headers, at least some parts of it. Zsolt has been working full-time on reproducing the bare minimum beacon data structures in Geth and exposing them in the LES protocol to make light clients workable again. This also requires collaborating with consensus client teams to have access to the needed data in the first place, so it takes a while. The upside is, however, that this work might not only fix light clients, but also enable full (but non-block-producing) nodes to follow the chain without a consensus client attached! Wouldn’t that be amazing, to only babysit one program again!

Shanghai

We’re barely past the merge, but protocol dev never stops. The Shanghai hard fork is already semi-scheduled (exact contents still a bit debated), and Matt has been working tirelessly on the two main features: withdrawals and Ethereum Object Format. The former is already being deployed on cross client testnets. Withdrawals will finally complete The Merge, enabling staked ether and accumulated rewards to be collected, while the EOF work will enable a cleaner internal organization of smart contracts, simplifying compiler work and also enabling a few more advanced features to be implemented. After the year’s #TestingTheMerge, Marius is currently helping in a similar role getting Shanghai ready and out faster and better.

Blob transactions

Possibly delayed until the Cancun hard fork, but already in full development is the support for blob transactions (aka 4844), which would allow the Ethereum network to create huge transactions (128KB a pop) that only have an ephemeral lifespan (2-4 weeks). The purpose of these transactions would be to allow layer 2 solutions to commit to and prove large batches of data very cheaply, without incurring an indefinite storage cost on all full nodes. This should make L2s significantly cheaper and thus allow Ethereum to – hopefully – onboard the next stream of users. This work has been pioneered by Coinbase’s Jessie and team and is currently being picked up by Peter to integrate where possible and reimplement where Geth’s DoS requirements require a different approach from the original PoC work.

Verkle trees

Looking even further out, Guillaume has been working on replacing Ethereum’s Merkle trees with Verkle trees. This could end up being the most invasive change ever done to the Ethereum execution layer, with implications across pretty much every aspect of the network. The advantage of Verkle trees would be greatly simplified state proofs, which might just enable stateless clients. This year, he put together a functional PoC, originally running in a PoW testnet and currently a PoS testnet. For now, performance-wise, there’s still work to be done as it’s about 2.5x slower than Merkle trees, but we’ll get there. A lot of research and development is being done trying to figure out how to do the transition from Merkle to Verkle without pausing the entire network (converting the data structures takes over a week currently).

Go-leveldb

Over the years we’ve had our ups and downs with using go-leveldb as our storage engine. We’re forever grateful to Suryandaru Triandana for creating it and helping us out now and again! However, the project being unmaintained for many years now left us without a viable upgrade path: we couldn’t get our optimizations in and some upstream changes even introduced DoS vectors, unfixed to this very day. We’ve tried out many alternative databases (RocksDB, BoltDB, Badger, Postgres) and converged on Pebble, a relatively new – but actively maintained – port of RocksDB in Go. Jared is currently pioneering the integration works – which primarily consists of getting that one or two missing features that we rely on accepted in the upstream Pebble projects. Switching out LevelDB to Pebble, we don’t expect performance to change, just for us to sleep better at night :P.

Built-in transaction tracers

Perhaps not the most visible feature, but we’ve worked a lot on tweaking and extending Geth’s built-in transaction tracers – which, if you missed the memo – now all run natively in Go and are quite speedy. Sina’s been the primary contributor on this front, also making some of the tracers configurable. A large feature we’ve been planning and are currently working on is live-tracing, which would allow Geth to be started with some tracers explicitly requested on startup, which would run along with normal block processing, storing the tracing results on disk. This should allow users relying on traces to not have to have the brittle 128 block window to quickly trace something before the state is pruned.

Docs & Website

Perhaps as surprising to you as to us ( 😀 ), this year we’ve started putting some effort into getting our online docs in a somewhat better shape. Shoutout to Joseph for going through our hot mess of pages and trying to make heads or tails of them. Within the same effort – with full thanks to the ethereum.org team – we’ve also been working on a new website for Geth. Don’t expect all of a sudden to have more – or different kinds of – information published, so our new website will mostly follow the old architecture, but should be a welcome refresher compared to the stock bootstrap template we threw together ages ago just to have a downloads page. Contributions are welcome!

Aaand, that’s a wrap 🙂

Javascript Team

Authored by Holger Drewes

The EthereumJS libraries date back to as early as 2014 and represent a continued effort to both modernize and keep an uncluttered code base. In 2022, we did a big round of breaking releases:

• Introducing native JavaScript BigInt support
• Making larger structural changes such as extracting a “pure” EVM from the historically grown VM package code, and also…
• Preparing the libraries for the Merge.

For 2023, there is a lot around the corner. We are actively working on an implementation of sharding (to be precise: EIP-4844 “Shard Blob Transactions”), we’ve merged EIP-4895 “Beacon Chain Withdrawals” code, and plan to complete the 5 Ethereum Object Format (EOF) EIPs that are being considered for mainnet by building on top of the initial EIP-3540 implementation, enabling us to join an early EOF-focused testnet (likely in January 2023).

Our EthereumJS (execution) client continues to mature. We recommend listening to the PEEPanEIP podcast episode in which our team member Gajinder talks about how our client went through the Merge and a potential future light client.

The client is now able to serve a full Ethereum testnet along with a Lodestar consensus client instance. These efforts have culminated in the launch of an early Pre-Shanghai testnet called Shandong later in the year, which activated various EIPs being considered for Shanghai and was well perceived by the community and other client teams.

We will build upon these experiences and launch a continued series of dedicated “Community Testnets” throughout 2023 which will be HF-independent and iterate quickly with early EIP integrations and a strong focus on (dev) community needs. Stay tuned for an announcement here!

On Ultralight, our Portal Network implementation has significantly improved throughout 2022, and we have now started working on PoCs that use an Ethers provider, swapping out the classic 3rd party RPC provider (e.g. Infura) and already successfully serving (parts of) the JSON RPC calls in a purely decentralized fashion by using a distributed Portal Network (!!). Continued results are promising, but we still need to collect more data on “soft” factors such as performance, scalability, and network resilience. There also are networking questions being addressed regarding a pure browser usage of the developed solution.

And, regarding Ethers: Ethers v6 is just around the corner. Stay tuned for an announcement in the coming weeks! 🤩 You can catch up on what will be included by watching this YouTube Devcon talk from Richard.

Ipsilon (Execution Environment research)

Authored by Alex Beregszaszi

Last year we finally launched our “website”, where most of our work can be observed. This year we were also active on Twitter.

EIPs

This has been the “Year of EIPs” for Ipsilon. We have worked on and published a large number of them. In order of maturity:

PUSH0 and Initcode metering

EIP-3855: PUSH0 (providing a nice gas improvement) and EIP-3860: Initcode metering (reducing DoS risks) are accepted for the Shanghai upgrade.

EOF

The group of EIPs called EVM Object Format (EOF). This includes EIP-3540, EIP-3670, EIP-4200, EIP-4750 and EIP-5450. The work on EOF started early 2021 and the steps were split, because initially we did not anticipate to launch them together. Today this group, colloquially called “big EOF”, is considered for inclusion in Shanghai (or Cancun).

Twitter had a number of good threads (1 2 3) about EOF, its features and benefits to the ecosystem. To name a few:

• Large gas savings with the reworked control flow system (static jumps provided by RJUMP and RJUMPI).
• Useful new instructions, such as RJUMPV to efficiently handle switch/jump-tables.
• Structured contracts (separation of various code sections and data) makes analysis (both automated and manual) easier, and thus can reduce security risks.
• This structure also allows for validation of contracts at deployment time, which reduces runtime overhead and risks.
• The format is extensible and allows introduction of features, which were not possible until now (an example is EIP-663 and evmmax).

The current work can be followed on the EOF1 Checklist page.

Unlimited SWAP/DUP

Connected to EOF is EIP-663 introducing long awaited swaps and dups accessing greater stack depth — this could remove those feared “Stack too deep” errors Solidity is outputting. This change is proposed for Cancun.

Others

Besides these we worked on a number of other proposals:

• EIP-5000 (in collaboration with Solidity) introduces a MULDIV instruction, which would significantly reduce the cost of fixed point math, a cornerstone of many (DeFi) applications.
• EIP-5656 (in collaboration with Vyper) introduces a MCOPY instruction, which can provide cheap memory copying at a 2-5x reduction in cost compared to today. This also “deprecates” the identity precompile.
• EIP-6046 is our (not very well developed) attempt to solve the “SELFDESTRUCT-problem”.
• evmmax (in collaboration with geth), the continuation of the evm384 project, introduces a small number of instructions, which can be used as building blocks to replace several current and future proposed “precompiles”.

These are not yet proposed for any upgrade, but perhaps some could make it into Cancun.

evmone and fizzy

On the software front, EVMC 10.0.0 and evmone 0.9.0 were released, which support Paris (Merge) and among other changes rearchitect gas accounting of refunds. These releases are used by Silkworm and by Solidity’s testing infrastructure. Accompanying, a number of releases of intx were made, mostly to improve speed of arithmetic operations in evmone.

We have also made a long delayed release of Fizzy v0.8.0, which contains the majority of planned features. This includes built-in runtime metering. The work is paused on Fizzy, for now.

Portal

Authored by Piper Merriam

The Portal Network is a multi team project being led by Piper Merriam that aims to deliver lightweight protocol access for the Ethereum network. Portal Network is a new set of distributed peer-to-peer storage networks that are designed for verifiable storage and retrieval of all of the data that makes up the execution chain and which is required for interacting with the Ethereum network.

The Portal team has been working all year on trin our client for the Portal Network. The Portal Network project as a whole has been quietly working towards building out this entirely new special purpose storage network and is on track to deliver the first version of this new protocol to the Ethereum community during 2023. We are currently focused on delivering the “History” protocol which will provide access to all of the block headers and bodies from the history of the Ethereum execution chain. All of the three independent client implementations have matured this year to fully implement the base functionality needed to launch healthy live networks.

In the last month, we deployed our first version of “Portal Hive”, a “black box” testing tool that verifies the different client implementations are all compliant with the protocol specifications. We also deployed the first iteration of “glados”, our network health monitoring tool which actively audits the network to check the availability of content. These are big milestones for the project, marking the point where we transition into having live networks with real data.

The next few months will see the history network coming online with more and more of the historical data becoming available for retrieval. Our next focus will be on implementing the Beacon chain light protocol and serving the corresponding data. Following that will be the Ethereum State data, the canonical transaction index, and the transaction gossip network.

Privacy & Scaling Explorations

Authored by PSE Team

The PSE team has been hard at work on an ever-expanding list of projects this year. Below is a sample of what PSE team members have been working on – you can find a more complete list of ongoing projects at appliedzkp.org.

We’ve been fascinated with the possibilities of privacy-preserving social applications enabled by a decentralized ecosystem of composable infrastructure. We’ve built and experimented with tools such as:

• Semaphore for creating anonymous identities to interact within customized groups.
• Unirep for private non-repudiable reputation.
• Interep, ZK-Chat for private communication, RLN for anonymous spam protection.
• Crypt-Keeper for ZK identity management and proof generation.
  Proof of concept applications like Zkitter and UniRep Social have let us bring these experiments to life and see how people interact in environments that feel familiar, but operate in fundamentally different ways.

On the scaling front, we’re exploring how succinct proofs can offer improved efficiency in a variety of areas, from gas costs to throughput and even validating Ethereum itself:

• BLSWallet provides components for an L2 smart contract wallet with BLS signatures and aggregated transactions for reduced gas costs.
• Zkopru combines using zk-SNARKs and optimistic rollups for low-cost private transactions on L2.
• The zkEVM Community Edition is one of many zkEVM efforts putting zk-SNARKs to work to make verifying L1 transactions easier and cheaper.

We’ve also broken new ground in anonymous voting and Public Goods funding. We supported several teams adopting MACI (Minimal Anti-Collusion Infrastructure) for customized quadratic voting and quadratic funding rounds. Thanks to help from teams from ESP, Devcon, EcoDev, and more, we’ve supported local leaders in the Ethereum community adopting [zk]Quadratic Funding around the world; each iteration was an opportunity to improve the tools and process, with the goal being more grassroots, privacy-first, quadratic funding operators that create value for their community.

Many team members showcased their work at Devcon VI in Bogotá. Over a dozen PSE projects presented, as well as an all-team effort to organize the Temporary Anonymous Zone community hub, with an accompanying demo app where attendees interact anonymously as part of a Devcon VI Semaphore group.

PSE is a growing community and we invite contributors and experimenters of all kinds! You can follow us on Twitter and Mirror, or join our Discord to get involved.

Protocol Support

Authored by Tim Beiko

The Merge was, by far, the most important thing for Protocol Support to get right in 2022. The team helped with coordination, community awareness and a long list of miscellaneous tasks, from launching bordel.wtf to publishing the Merge Manual. On September 15th, we celebrated Ethereum’s successful transition to proof-of-stake! A few weeks later, we highlighted the work of merge contributors by signing them a song at Devcon.

Since then, we’ve been working on both Shanghai/Capella, which is focused on Beacon Chain withdrawals, as well as the next upgrade, centered around EIP-4844, a.k.a. protodanksharding. This should keep us busy for at least the first half of 2023. The two first things you can expect are devnets (and tutorials!) for Beacon Chain withdrawals, and the launch of the KZG Ceremony, for which we just announced a grants round! For more on these protocol upgrades, see the latest AllCoreDevs update.

Beyond upgrades, the team focused on two other major initiatives in 2022. The first was launching Protocol Guild. The guild, whose design was birthed in a tweet, is a collective of over 120 Ethereum L1 maintainers to which DAOs and individuals can donate as a way of supporting the protocol. Unlike typical grants, focused on organizations, funds sent to PG are routed to individual contributors directly. To test the idea, a one year pilot was launched in May. Six months in, PG has published a mid-pilot update, as well as its plans for 2023. Expect a new, governance-minimized version of PG, deployed to both L1 & L2s, with a much longer vesting period.

The second big initiative PS undertook was (re)launching the Ethereum Protocol Fellowship (f.k.a. Core Dev Apprenticeship Program, or CDAP). EPF provides participants with stipends and mentorship to allow them to dive deep in the “core dev” rabbit hole with the goal of onboarding proficient contributors to client and research teams. This third cohort has over 20 participants, including a handful that participate permissionless-ly, working on various projects including MEV, light clients, account abstraction and sharding. Once it wraps up, around ETHDenver, we’ll take time to reflect on how it went and how it can be improved. We expect to run another cohort that will begin over the summer.

Last but not least, contributors to the Ethereum Execution Layer Specification, a.k.a. EELS, have recently joined the PS team. The work on EELS will provide Ethereum’s EL with a more accessible spec, from which it’s easy to generate test vectors. It’s also a significant step in aligning how changes are specified across the execution and consensus layer, given the latter already has a similar spec. If you were thinking of writing an EIP, it’s worth giving EELS a look as well — it might be easier to use a Python diff than reimplementing a large chunk of Ethereum in markdown pseudocode!

Remix

Authored by Rob Stupay and Yann Levreau

IDE Updates:

We began the year at v0.21.0 and have just released v0.29.0. For all the details about what has been updated on the IDE please check our end of year article.

Process

The Remix team has been integrating User Centered Design methodologies into our workflow. We’ve sought user feedback through our “Ask Remix Anything” calls, individual user interviews, from our support channels and through social media outreach. We’ve also incorporated beta testers into our release process. These new channels of feedback have been very helpful.

Dogfooding

We dogfooded the IDE on a few projects. At ETHDenver we hacked a token-curated, upgradable playlist and song minting dApp for Rocky Mountain Public Media. Then we developed Remix Rewards, an ongoing program to reward Remix contributors, beta testers, and UX research participants with NFT badges. Finally, we created Remix Challenges, quizzes that use ZK proofs. We then began using the Remix Challenge quizzes in our workshops; they make an excellent demo project for introducing Remix’s capabilities. Through using Remix in all of these demo projects, we were able to find some areas where we could improve the tool and then… we did.

Workshops & Talks

Throughout 2022, Remix team members gave workshops and talks at: ETHDenver, Devconnect, Solidity Summit, Kuala Lumpur Ethereum Meetup, EthCC, SmartCon, EThSafari, Devcon (one of which was in Spanish), ETHVietnam, and ETHIndia.

A preview of 2023

Here are some highlights from our 2023 Roadmap:

• Improving Remix’s performance with a slow internet connection
• Improving Remix’s overall performance
• Remix for “low code” use cases
• Adding new features and building requested features
• Giving more workshops

Robust Incentives Group

Authored by Barnabé Monnot

This year, our team participated in multiple conversations on the economics of Ethereum with industry partners as well as academic grantees and collaborators. We organized ETHconomics in April during Devconnect, a gathering of industry researchers and academics who discussed all facets of protocol economics for the Ethereum base layer and rollups. In December, we co-organized the first Columbia Cryptoeconomics Workshop. We also recently released RIG Open Problems, an initiative to decentralize our research process.

Among other works and talks listed on our homepage, here are other topics that kept us busy this year:

Snake Charmers [Python Ecosystem]

Authored by Keri Clowes

In 2022, we made many exciting changes across our libraries. We released our first beta versions of web3.py v6, which opened the door for many long-awaited breaking changes throughout our stack. Those breaking changes included:

• Streamlining the eth-abi API
• Dropping support for deprecated Python versions (3.5 and 3.6)
• Deprecating camelCase syntax in favor of snake_case (and lots more)

Of particular note, robust asynchronous support is now available via the AsyncHTTPProvider. A full list of changes to web3.py can be found on the release notes page of the documentation.

The middle of the year brought us The Merge and so eth-tester, web3.py, and py-EVM all got updates to support the Paris hard fork. Additionally, we shipped some new features to our ENS module, including support for ENSIP-10 and the Cross-Chain Interoperability Protocol.

We’ve also been focused on making web3.py as extensible as possible, so we added APIs for custom modules and methods. This enables users to easily handle non-standard JSON-RPC methods, or even add a full L2 API. We’ve also spent time modernizing our libraries this year, including adding support for Python 3.10 and 3.11, and modernizing our release processes.

We put an emphasis on developer relations this year, as Marc continues to prioritize educational content mainly focused on web3.py patterns and internals, geared at a wide range of developer abilities. These blog posts at snakecharmers.ethereum.org.

He also spoke at Devcon VI and at the inaugural Pychain conference.

We launched a developer survey to gain insight into the types of users that we have, and the ways in which they use web3.py and our supporting libraries. Participate in the survey here.

In 2023, our team plans to:

• Refine the asynchronous providers in web3.py, and release a stable web3.py v6.
• Implement changes to our stack of libraries to support the Shanghai and other network upgrades that follow in 2023, including changes to clients and smart contract languages.
• Integrate the user feedback gained from the survey and other feedback channels into our roadmap.
• Continue to prioritize users by producing educational blog posts, and presenting at various events.

Security [Security / Consensus Tests]

Authored by Fredrik Svantes

We started this year with the clear objective to make The Merge a success from a security perspective, so in the first half of the year and up until The Merge, our efforts were primarily aimed towards testing and improving security wherever possible in the protocol and clients. At The Merge, no major issues were spotted and everything appeared to go very smoothly.

During this year we have worked on many things leading up to and beyond The Merge. Some of our work started with a merge threat assessment, and has been related to fuzzing using tools such as Antithesis, Nosy Neighbor, Beacon Fuzz, Engine API Fuzzer, EL fuzzers and other fuzzers.

We have also manually audited clients, libp2p, L2s, Bridges, validator appliances, mev, worked with external auditing companies for some audits, researched ways to reduce DDoS risks of validators, and more.
One of the perhaps more publicly seen improvements was our significantly increased bounties (4x), but we have also released tools such as Nosy Neighbor and Secure Drop.

The security team also closely worked with the protocol support team and the client teams in a weekly merge testing call and has been running its own validators for the testnets.

Lastly, the team has given several talks and published several posts about security, such as

Continue keeping an eye out for our “Secured” blog posts if you want to learn more about what we’re up to.

In 2023, the team will focus on:

• Internal security audits of Capella/Shanghai
• Further improving our testing capabilities
• Coordinating an external security audit of Account Abstraction
• Coordinating and communicating vulnerability reports through the Bounty program
• Internal manual spec and client audits
• Running and improving fuzzing infrastructure
• Internal security audits of Layer 2/Bridges
• Holding client security calls to further collaborate on security
• Coordinating external security audits

Solidity

Authored by Franziska Heintel

Throughout 2022, we published 6 Solidity releases with the following highlights:

Besides the ongoing work on the compiler and language, we also engaged with the ecosystem:

• We organized the Underhanded Solidity Contest 2022, which was a great success. The goal of the ontest is to write seemingly innocent and straightforward-looking Solidity code that actually contains malicious behavior or backdoors. Check out the Board of Fame for all winning submissions!
• In April, we hosted the Solidity Summit, a one-day conference, as part of Devconnect in Amsterdam. The Solidity Summit is a collaborative event focusing on the future of Solidity. Find a recap of the event with full agenda and links to all talk recordings here.

If you want to get up to speed with recent Solidity developments, here is a selection of talks the Solidity core team members gave in 2022:

In December, we shared “Solidity Core Team Updates” on the Solidity blog, summarizing the most important events in the core team.

Last but not least: The Solidity Developer Survey 2022 launched on December 7! If you are a Solidity developer, please support us by providing your insights and take 10 minutes to take part in the survey here. The survey closes on January 7, 2023.

ZoKrates

Authored by Thibaut Schaeffer

2022 was a good year for ZoKrates:

• It started with the implementation of a Solidity verifier for the Marlin proving scheme by Nirvan Tyagi, a great first contribution to the project.
• A lot of new functionality was added to the language throughout the year, such as shadowing of variables, a wider range of complex types, as well as easier conversion tools between numeric types.
• In the summer, ZoKrates was upgraded to a more modern syntax. No more endif and other vintage language constructs.
• The rest of the year was spent focusing on the introduction of assembly blocks to ZoKrates. Historically known for being higher level, ZoKrates will very soon give developers the power (and responsibility) to write low-level constraints by hand.
• Finally, Georg Wiese wrote an integration of ZoKrates with a variant of the Plonk proof system, which is also being finalized.

The ZoKrates team is looking forward to welcoming more developers in the ZK world in 2023!