blog.ethereum.org
Open in
urlscan Pro
2a05:d014:275:cb01::c8
Public Scan
URL:
https://blog.ethereum.org/2022/12/29/supported-teams-roundup-22
Submission: On March 31 via api from FI — Scanned from FI
Submission: On March 31 via api from FI — Scanned from FI
Form analysis 1 forms found in the DOM
<form>
<div class="css-k008qs">
<div role="group" class="chakra-form-control css-1kxonj9"><input type="email" placeholder="Enter your e-mail" name="email" id="updates-email" class="chakra-input css-1s5eut1"></div>
<div class="css-0"><button disabled="" type="submit" class="chakra-button css-1thzom3">Sign up<!-- --></button></div>
</div>
</form>Text Content
EF Blog
Skip to content
Categories
R&D
Research & Development
Devcon
Devcon
Org
Organizational
ESP
Ecosystem Support Program
ETH.org
Ethereum.org
Sec
Security
NxBn
Next Billion
Protocol
Protocol Announcements
Search
Languages
EF-SUPPORTED TEAMS: RESEARCH & DEVELOPMENT ROUNDUP
POSTED BY ETHEREUM FOUNDATION TEAM ON DECEMBER 29, 2022
Organizational
TABLE OF CONTENTS
* Consensus R&D (aka EF Research Team)
* Cryptography Research
* Fe-lang
* Notable language features
* Tooling
* Community
* Other
* Formal Verification
* hevm
* SMTChecker
* Yools
* PolySolver, a solver for generalized polynomials
* Geth
* Path-based trie storage
* Light clients
* Shanghai
* Blob transactions
* Verkle trees
* Go-leveldb
* Built-in transaction tracers
* Docs & Website
* Javascript Team
* Ipsilon (Execution Environment research)
* EIPs
* PUSH0 and Initcode metering
* EOF
* Unlimited SWAP/DUP
* Others
* evmone and fizzy
* Portal
* Privacy & Scaling Explorations
* Protocol Support
* Remix
* IDE Updates
* Process
* Dogfooding
* Workshops & Talks
* A preview of 2023
* Robust Incentives Group
* Snake Charmers [Python Ecosystem]
* Security [Security / Consensus Tests]
* Solidity
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:
* Continued refinement of the EIP-4844 consensus-layer specs. At the same
time, we are collaborating with developer teams on the CL+EL clients
interop and devnets.
* To use KZG polynomial commitments in EIP-4844, we need to generate the
"trusted setups" via KZG Ceremony with public participants. You can find
more progress updates in the recent KZG Ceremony Grant Round RfP blog post.
* 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:
* @vuvoth's
* @zjhmale's
COMMUNITY:
* Hosted Fe Day, presented at Solidity Summit, and sat in on a languages panel
at Secureum TrustX in Amsterdam for Devconnect 2022.
* Participated in the Language Tug of War panel in Bogotá for Devcon 2022.
* Launched Bountiful and got hacked by @plotchy.
* Received contributions from a total of 12 contributors.
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 ( :D ), 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:
* L1 consensus and economics: Conversations continued around the Three attacks
on Ethereum Proof-of-Stake paper and consensus changes. See also the talk at
Devcon on Time in Ethereum, by Caspar.
* Proposer-Builder Separation: See a state-of-research post and talk at Devcon,
by Barnabé.
* Macroeconomics: Ongoing research into discouragement attacks, issuance policy
and circulating supply, see talk at Devconnect by Anders.
* Rollup economics: See a first-principles post and a talk at EthCC, by
Barnabé. Find also more about blockspace derivatives, by Julian.
* Dispute protocols: See a post on a type-theoretic approach to disputes, by
Sebastien.
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
* Talk: Securing the Beacon chain
* Panel: Bug Bounties & Whitehats
* Talk: Nosy Neighbor - Automated Fuzz Harness Generation for Golang Projects
* Talk: Ethereum Foundation's Bug Bounty Program
* Secured #2: Public Vulnerability Disclosures
* Secured #3: Security Teams
* Secured #4: Bug Bounty Rewards now up to $250,000 USD
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:
* Solidity 0.8.12 improved the JavaScript/Wasm binary and fixed several bugs.
* Solidity 0.8.13 fixed an important bug related to abi.encodeCall, extended
the using for directive and implemented “go to definition” for the language
server. Furthermore, it’s the release that marked compiling via the new Yul
IR pipeline production ready. ℹ️ Using via-IRcan help avoid stack too deep
errors! Read more about that here.
* Solidity 0.8.14 fixed two important bugs, namely a Size Check Bug in Nested
Calldata Array ABI-Reencoding and a Bug Concerning Data Location during
Inheritance.
* Solidity 0.8.15 fixed another two important bugs, improved inlining
heuristics and added a .selector member for errors and events. You can read
more about the bugs here:
* Optimizer Bug Regarding Memory Side Effects of Inline Assembly
* Bug when Copying Dirty Bytes Arrays to Storage
* Solidity 0.8.16 fixed a Head Overflow Bug in Calldata Tuple ABI-Reencoding
and included several improvements like more gas-efficient overflow checks for
addition and subtraction.
* Solidity 0.8.17 fixed a Storage Write Removal Bug On Conditional Early
Termination, made overflow checks on multiplication more efficient, and added
an LSP feature to always analyze all files in a project. Version 0.8.17 marks
the 100th Solidity release!
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:
* Daniel on “Generating EVM Bytecode from Yul in the new via IR Pipeline”
* Chris outlining “Recent and Planned Futures”
* Franzi giving an “Introduction to Solidity in 2022”
* Hari on “Topics in Solidity”
* Chris with “Modern Solidity”
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!
Previous post
Next post
SUBSCRIBE TO PROTOCOL ANNOUNCEMENTS
Sign up to receive email notifications for protocol-related announcements, such
as network upgrades, FAQs or security issues. You can opt-out of these at any
time.
Sign up
--------------------------------------------------------------------------------
*
*
*
*
* Ethereum Foundation
•
* Ethereum.org
•
* ESP
•
* Bug Bounty Program
•
* Do-not-Track
•
* Archive
CATEGORIES
* Research & Development
•
* Devcon
•
* Organizational
•
* Ecosystem Support Program
•
* Ethereum.org
•
* Security
•
* Next Billion
•
* Protocol Announcements