Friends,
From our team to you and yours, we hope everyone and their families are well and keeping safe during these complicated weeks. To help pass some time while we’re all stuck in doors, it’s time again to update the community on progress made by some of the EF-supported projects not covered in last week’s ESP Allocation Update. While the last Winter edition in this series was posted only a few months ago, we’ve all come a long way since the launch of the Istanbul network upgrade, and many teams have news to share.
As always, these updates focus on EF-supported teams and efforts 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 news.
Enjoy!
Aleth / C++ Ethereum
Authored by Paweł Bylica
In December 2019, the 1.8.0 version of Aleth was released. It contains a number of fixes and improvements related to a variety of aspects of how this C++ Ethereum node functions. In particular, we made improvements to the RPC interface, blockchain sync and network protocol, and testing tools (testeth, aleth-vm). See CHANGELOG for more details.
This release also contains substantial work related to the consensus mechanism:
- Muir Glacier network upgrade support.
- EIP-1380 « Reduced gas cost for call to self » implementation.
- EIP-2046 « Reduced gas cost for static calls made to precompiles » implementation.
- Support for individual EIP activation to facilitate EIP-centric network upgrade process.
Aleth 1.8.0 is the last planned version. From now on, we are only committed to basic maintenance of the code, Pull Request review and fulfilling the remaining needs of testing and EIP reviews. At this point I’d like to thank all Aleth contributors, especially Nils-Erik Frantzell who put a lot of effort in the project in the past year.
It is also worth mentioning maintenance releases of sibling projects:
Last but not least, we have published an article on Efficient gas calculation algorithm for EVM, later included in Devcon 5 presentation Optimization techniques for EVM implementations.
Applied ZKP
Authored by Koh Wei Jie and Kobi Gurkan
The Applied ZKP team works to bridge the gap between cutting-edge research in zero-knowledge proofs, and application development on Ethereum.
Perpetual Powers of Tau
In September 2019, we launched the Perpetual Powers of Tau ceremony (PPOT). PPOT aims to benefit the zero-knowledge ecosystem, particularly zk-SNARK projects built on Ethereum, by partially easing the burden of trusted setup ceremonies. Every zk-SNARK project requires two phases of parameter generation, and PPOT replaces the first phase, which can be shared by all circuits. Individual teams can choose any contribution from the ceremony to branch out and perform their own phase 2 setup.
This ceremony supports circuits up to 2 ^ 28 constraints, which means that each contribution requires a 97G download, a 1-day computation, and a 49G upload. At the time of writing, we collected 29 contributions from 28 unique individuals, and all contribution files can be downloaded and independently verified against a public ceremony transcript.
Semaphore
Semaphore is Applied ZKP’s flagship project, initiated in mid-2019. It is a generic privacy gadget which enables use cases such as mixers, anonymous login, and anonymous voting. One use case of Semaphore, developed by Chih-Cheng Liang, is Semaphore Authentication, which enables anonymous logins with protection against Sybil attacks. We encourage readers to check out this explanatory blog post to understand what Semaphore is and how it works.
Security audit and code release
We engaged ABDK Consulting to perform a security audit of Semaphore’s zk-SNARK circuit code and Solidity contracts. We fixed the issues they uncovered, and released the final source code. We have included in the audit many components from the circom standard library, thus providing a greater set of tools to be used by the wider community of SNARK developers that use circom.
Phase 2 ceremony
At the time of writing, we are performing a circuit-specific multi-party trusted setup ceremony. The process we are following is documented here. We collaborated with Supranational, a member of the VDF Alliance, to run a verifiable delay function (VDF) on a pre-announced Ethereum block hash, and applied the output of said VDF onto challenge file #25 from the Perpetual Powers of Tau ceremony (see below), and kicked off the circuit-specific ceremony on the 6th of April 2020.
Thanks to excellent work by Brian Gu, we were able to repurpose Aztec Protocol’s Ignition ceremony software for our ceremony. Please check out more details about this ceremony by reading its participant guide.
Feel free to discuss in the Semaphore Society Telegram chat group.
Semaphore RLN
Semaphore RLN provides a way to perform rate-limiting in a P2P setting – instead of relying on an on-chain nullifier map to prevent double-signaling, we use Shamir Secret Sharing to expose shares of the broadcaster’s private key. Multiple published shares from the same broadcaster can be used to reconstruct the private key, opening up the possibility for the original holder of the private key to be slashed.
MACI
Originally proposed by Vitalik Buterin in an ethresear.ch post, systems built with MACI make collusion among participants difficult, while retaining the censorship resistance and correct-execution benefits of smart contracts. Although MACI can provide collusion resistance only if the coordinator is honest, a dishonest coordinator can neither censor nor tamper with its execution.
In late 2019, we started work on a technical specification and implementation and we are nearing completion of a minimal viable product.
Future work: adding anonymization to MACI
MACI uses a coordinator for processing, where the coordinator uses SNARKs to prove integrity, such that a malicious coordinator can only hurt collusion-resistance properties. One downside of the current approach is that the coordinator is able to link each user’s original key to their final key, as they see all the key changes.
We seek to further improve privacy towards the coordinator by allowing anonymous key changes by users. Please read more on this ethresear.ch post.
MiMC Bounty
MiMC has become a popular cryptographic hash function in SNARKs due to its great performance. While it is the oldest of the bunch in the “hash functions with low multiplicative complexity” family of functions, we felt it should receive more critical attention. We initiated a bounty for collision finding in MiMC, which we also plan to extend to Poseidon.
Optimistic Rollup Hub + ZK Optimistic rollups
Optimistic Rollup allows greater layer 2 scalability with the use of on-chain data availability and fraud proofs. The Hub chain further allows for easy mass migrations between different rollups. The hub allows for easy mass migrations.
ZK Optimistic Rollup builds upon the same idea but for anonymous transfers. Instead of having all the transaction metadata in the clear, each transaction in the rollup is a 2-to-2 anonymous transfer.
PeekABook
PeekABook allows two users to privately match orders, such that no user can discover more information about an order made by another user unless they have an order that would fulfill it.
Experimental directions
Up until now we’ve described projects that we’ve released — either as mature code, specs or concrete plans. We are continuously investigating new experimental areas which we hope will mature to fully-fledged projects.
Some of these include:
- Verifying a STARK in SNARK – allowing for some form of layer 1 recursion
- Blind Find – an MPC-based construction proving a path exists between users in a p2p network, without revealing the path itself.
- Fractal on Ethereum
- RSA-based rollup
And more 🙂
Ecosystem Support Program
On April 1 we posted the ESP Allocation Update, where we shared some of the work we’ve been doing to improve our processes as well as a list of the projects that received financial support in 2019. Watch the blog for more updates, and follow us on Twitter (@EF_ESP) to keep up with the latest on the projects we support!
Ewasm
Authored by Alex Beregszaszi
Since the last update in December, the team has continued to work on Eth 2.0 Phase 2 and started to take a more active part in Eth 1x research as well.
Our intuition is that certain parts of research are needed by both and can be shared between the two efforts.
Eth 1.x / Stateless Ethereum
In a stateless model, it is not expected that everyone keeps a copy of the entire state of the blockchain. Instead, each block comes with a proof (the so-called witness) of the part of the state affected. The optimal creation, distribution and verification of witnesses becomes a crucial component of this new stateless system. The challenge of creation and verification is what interests our team most.
There exist various ideas for reducing block witness size, some of which Paul has collected in a survey. Given our background in instruction sets, the first problem we had a look at is reducing code size. This is important, because code also needs to be included in the witness. Two approaches come to mind: compression and merklization. An early phase experiment suggests we can cut down the amount of code transferred as part of the block witness by 40-60%.
We further plan to explore options to
- reduce the storage part of the witness,
- to accurately charge for the witness size (« witness metering »),
- and to partake in creating a witness specification.
Eth 2.0
It must be noted, since the execution model of Eth 2.0 is also stateless, the work done as part of Eth 1x becomes applicable here too.
Cross-shard design
Without the ability to efficiently transfer Ether (and potentially other tokens), payment for execution and transactions becomes a complicated matter. Last year a variety of models emerged, including receipts with accumulators, queues and balance maps. Casey has proposed an alternative called EthTransfer objects.
In addition to Ether transfer, contracts may want to be able to communicate with other contracts on different shards, and potentially perform atomic operations. All of this leads to a vast design space for Phase 2, which we’ve been exploring so far.
As an experiment, starting a few weeks ago, we have been working on Eth1x64. This reduces the design space and should allow for quick iterations of different designs.
Under Eth1x64 each shard is homogenous and is running an instance of Eth 1.x, with shard 0 being the current Eth 1.0 mainnet. We are working on multiple small proposals, all of which focus on various ways to accomplish cross-shard communication.
This work will give an idea of the complexity of introducing sharding into Eth1, allowing us to gather wider feedback from Dapp developers, and we can take the results into refining the WebAssembly-based Phase 2 designs.
Speed
Zero-knowledge protocols are becoming increasingly important. It must be ensured they can be efficiently supported on Eth 2.0. An optimized implementation in AssemblyScript of the SNARK-friendly MiMC hash function and a zkSNARKs-based token example have been developed. This example works well as an Execution Environment. Benchmarks show that both can achieve comparable performance to compiler engines and EVM-based (precompile aided) implementations. See Jared’s summary for numbers.
This work also guided further reviews of the big integer API, which is an important element of a powerful and safe, WebAssembly-based execution.
WebAssembly
The last few months have been a fruitful time for WebAssembly with the release of the stable 1.0 version of the specification. A number of new promising interpreter projects have been announced and/or released. We are keeping a close eye on these and intend to include them in our benchmarking report.
In January we began working on Fizzy, a new Webassembly engine. Features such as integer-only support (no floating point operations) and interpreter-only execution make it well-suited for blockchain use cases. In addition, a clean codebase written in modern C++17 and the goal of easy embeddability aim to make Fizzy a viable, modular component for Eth 2.0 client implementations. By the time of this update, Fizzy is able to pass almost all official test cases (with the exception of Wasm validation, which is not yet implemented) and compares very well on speed benchmarks.
Formal Verification
Authored by Leo Alt and Martin Lundfall
Act
Act is a simple and effective specification language to write formal specifications. It is being developed with input from several groups, and we hope that in the future it will be common to use Act to specify smart contracts.
By allowing properties to be expressed on different levels, the main goal for Act as a tool is to enable modular verification. The specification can be verified as a standalone document, where contract invariants can be checked from the specified function’s pre/post conditions, and the post conditions can be checked from a function’s storage updates. Ideally this modular verification will make it much easier for other tools to verify that the source code/bytecode are correct.
We are currently working on three proof backends for the intermediate proofs:
- Coq definitions
- K specs
- SMT theorems
Each one of the backends has its own pros and cons, and we hope to achieve good performance and coverage by developing all fronts at the same time.
We hope to release a prototype of each proof backend and study how to express loop invariants until June 2020.
We will soon release a detailed technical post about Act. Contributions to the repository are always welcome!
SMTChecker
The SMTChecker is a model checking based static analysis module in the Solidity compiler that tries to verify source code assertions in compile-time. Last year a new engine based on Constrained Horn Clauses was added. This engine’s main feature is that it can automatically find inductive invariants that are used to prove assertions, enabling support for loops and state properties.
We recently added internal function calls to the engine and keep improving support for the Solidity language. In the next 3 months we will keep working on increasing language support, counterexample generation/presentation and external function calls, which will hopefully start to transition the SMTChecker from experimental into a useful and powerful tool.
In the future we also want to:
- Combine the SMTChecker and Act, and study amazing stuff like synthesis of missing code to match the specs / synthesis of adversarial code.
- Create a Remix plugin for the SMTChecker which would improve usability greatly.
Verified ABI encoding/decoding
We are collaborating with ConsenSys R&D who are working on a verified ABI encoder/decoder using Yul-Isabelle. The idea and discussions started at Devcon V, and since then, good progress was made and we are close to a prototype.
Initially we intend to use it together with the Solidity Fuzzer to find bugs related to optimization and ABI encoding/decoding. Our final and slightly ambitious dream is to use the verified ABI encoder/decoder as part of the Solidity compilation process. This would imply that a substantial part of code generation is verified!
Eth2
We have continuously supported Runtime Verification in maintaining the KEVM formal semantics and verifying the deposit contract and beacon chain specs. The deposit contract is also one of our main benchmarks when developing Act. We would like to provide an alternate specification for the deposit contract and proof for the incremental Merkle tree properties via Act by July, when we also intend to study Eth2 Phase 1 and Phase 2 properties that must be proved.
Hevm
Hevm, a haskell EVM evaluator and debugger can now be used for property-based testing.
Users of the dapp development tool can now write Solidity tests whose arguments are randomly generated and that are run multiple times against a correctness criteria. This provides a way for smart contract developers to massively increase test coverage in a relatively straightforward manner.
Going forward we will be exploring extending hevm with symbolic execution capabilities. This would make it possible to use hevm to formally verify EVM bytecode.
Geth
Authored by Péter Szilágyi
Over the past quarter the Geth team has been busy with network plumbing and laying the groundwork for future releases. This post will only enumerate a few of the major features; for a detailed bullet point view please consult our release notes.
DNS discovery
A feature we’ve specced out about 2 years ago and shipped last quarter is DNS-based peer discovery. Going forward, Geth v1.9.11+ nodes have two independent mechanisms to find peers. The DNS lists serve as a fallback mechanism when peers cannot be found through the DHT. They might also end up being the starting point for a Tor integration.
DNS-based discovery is a centralized mechanism, but we have tried to make the operation of this mechanism as transparent and permissionless as possible. The public lists used by default are generated by crawling the discovery DHT. Nodes running any Ethereum client which implements EIP-868 and EIP-2124 will appear in the public lists automatically. If you want to create a DNS-based node list for your private or public network, please check out our DNS Discovery Setup guide.
At this time, there are ~1150 publicly-routed Ethereum mainnet nodes in the default list; and our public lists also serve the Ropsten, Goerli and Rinkeby test networks. Currently the network generates 8 million DNS queries per day to this discovery mechanism.
Transaction propagation
For a couple years now, most of the network bandwidth used by Ethereum nodes was shuffling transactions around. Unfortunately, this mechanism was never optimized since its inception, so it was very wasteful. Over the last quarter, we’ve spec’d out an update to the eth protocol (EIP 2464) which enables transactions to be announced between nodes and only transferred upon request.
This new protocol was released in Geth v1.9.11, is already implemented by Nethermind and in progress for Open Ethereum too. Since only about 30% of the network supports it, the amount of bandwidth saved globally is still a question, but running an eth/64 vs. eth/65 bootnode experiment with 250 peers has promising results.
Based on last week’s traffic, eth/65 is capable of reducing transaction propagation bandwidth by about 75%. For a bootnode of ours with 250 full node peers, that’s 750KB/s saved, or roughly 1.8TB of bandwidth per month. We are certain there is still room for improvement, but let’s take it one step at a time.
Apart from eth/65, Geth shipped support for larger than 32KB transactions back in January (courtesy of StarkWare), with a soft limit originally at 64KB and soon raised to 128KB (higher limits heavily rely on how eth/65 performs globally).
Dynamic snapshots
A large bottleneck in running the EVM and doing an initial sync revolve around the state representation in Ethereum: the Merkle Patricia trie. Since all the state data is laid out in a tree format, accessing any account takes about 6-8 random disk lookups currently on mainnet. During fast sync, the same random intermediate trie nodes need to be downloaded one by one to get to the actual data.
A feature we’ve been working on actively for half a year now is dynamic state snapshots: in short, creating a flat acceleration structure on disk which allows any account or storage slot to be loaded with 1 disk lookup. This is similar to Open Ethereum’s fatdb layout, except this one is dynamic: the snapshot mechanism in Geth is capable of keeping the acceleration structure updated live as the chain progresses (including the mini forks).
One benefit of the dynamic snapshots are O(1) EVM state reads. Although this might sound like a holy grail, it is not. Most contract executions don’t go crazy with disk reads, so the benefit is limited, and most contracts also do lots of writes, which still need to be pushed into the Merkle trie. The dynamic snapshots, however, do allow eth_call operations to be blazing fast and they do make DoS transactions significantly harder to pull off.
A much more interesting feature enabled by the dynamic snapshots is a new synchronization protocol, which we’ve been trying to pin down for 2 years now (originally called leaf sync). The protocol is still a work in progress, but if our hunches are correct, it should allow syncing the Ethereum state significantly faster.
Discovery v5
The initial version of the next-gen discovery protocol was implemented in Geth, albeit it is not yet enabled. Whilst the spec and implementation is still fluid, syncing with the Eth 2.0 requirements, it is a huge milestone to have a working version in the live codebase.
Javascript Team
Authored by: Holger Drewes, Philipp Langhans
Last quarter was exciting for the team. For the first time we came together in person early March during EthCC in Paris, deepened relationships and discussed team cooperation, possible collaborations and future plans. Expect to hear more on that once things start to bear fruits.
Ethers.js
Ethers v5 is going through the last beta releases before final launch. A lot of fixes and usability improvements (like more-fitting names for API calls) discussed with the community have been applied preparing for a stable and robust final release. Noteworthy new features added lately are the new WebSocketProvider and experimental EIP-1193 (Ethereum Provider JavaScript API) support.
Web3.js
After being the main maintainer for the Web3.js library for more than a year, Samuel has decided that it is now time to go on with new adventures (thank you Samuel for all your great work! ♥️). We enjoyed a last being-together in the days around EthCC. Library development will now be taken over by other team members on a shared basis.
For the moment we have a strong focus on ensuring a steady release process and we are working on familiarizing ourselves with the tech stack and procedures since Samuel was the No. 1 expert here. Please bear with us that we are therefore very selective on adding new features in the near term. For the moment – and for the same reasoning – we also won’t do development on the 2.x branch (currently released as an alpha version of the library.
EthereumJS
We moved the EthereumJS VM to a monorepo, combining structurally related libraries (tx, block, blockchain, HF configuration (common)) under one roof. This will significantly ease VM development in the future and allow for integrated PRs. There is a v5 release of the VM based upon this new structural basis planned to be released soon which will introduce several breaking changes. Feel free to drop in and join (and shape) the discussion.
Thanks to the great work of dryajov we now also have a working TypeScript implementation of the devp2p stack. A release on this is imminent.
Grid
Ethereum Grid was split into two parts: the desktop application and a core module that can provide binary management outside of the Electron context e.g. on CLI or in other tools like test runners or IDE’s (Remix, VSCode). The goal of the core is to provide an engine that itself is very small but can be extended via plugins. The necessary mechanisms that allow a secure and stable extension without having to modify Grid in the future have been implemented. This was the main goal of the refactoring and a transition towards a finalized product.
Grid can be extended with small scripts, called workflows, that interact with binaries. A variety of them have been created and demoed at EthCC: Grid Workflows
Python Ecosystem [PyEVM / Trinity / Web3.py / Vyper]
Authored by Piper Merriam
Web3.py
The Web3.py library has continued work on incremental improvements and stability. Thanks to some third party contributions, we expect to have preliminary support for mnemonic phrase and HD accounts released in the near term future. We also continue to work towards full async support, though there is still a decent bit of foundational work to be done on this front.
Trinity
The Trinity client continues work across both the 1.x and 2.0 fronts. Work continues on the Trinity Eth2 client as we get closer to having stable, longer lived public testnets. On the Eth1.x side we continue to work towards a functional mainnet client. One of the biggest things to come out of our work over the last two years is the “Stateless Ethereum” effort which is shaping up to transform the Ethereum mainnet over the next 18-24 months.
EthPM
The EthPM team is working with the Solidity team to incorporate the packaging standard such that the compiler is able to compile the resources in a package, produce packages of the compiled resources, and use the EthPM spec for metadata/contract source verification.
Remix
Feel free to check out our medium posts for more detailed content.
Our public website has just been released 😉
Remix IDE – Live && Desktop app
- Full support for Solidity 0.6.0 breaking changes and features has been added to the Solidity Plugin.
- Low level interaction are now possible (Solidity receive and fallback)
- Light and Dark themes have been added. We redesigned UI’s of the Solidity Plugin and Deploy&Run Plugin.
- The latest Remix Plugin Engine(v0.2.0) has been successfully integrated into Remix IDE, as well as remix-simulator (Ethereum dev node in the browser).
- From now on, the desktop version is following Remix live releases.
Remix plugin
- The latest version comes with the ability to have websocket plugins and we will add more types (Secure Ecmascript, IPC) soon.
- Integration with VScode is currently in the process and hopefully available soon.
- Here’s the documentation for developing plugins.
External Plugins
- We support external teams to build their plugins and add them to Remix IDE.
- We have a Gitter channel dedicated to Remix plugins. You can propose a plugin to the community by creating a PR in the remix-plugins-directory repository
- If you require financial help to build your plugin, we can probably do something!
Here’s what you need to do: – Please create a Github issue (in the repository where your plugin is located) for describing what you intend to do. – Send us a mail – [email protected] – containing a document describing the project, a link to the Github issue and an invoice proposal. – We’ll do our best to contact you and plan for next steps.
Remix Simulator
- Integration with Remix IDE is mostly completed.
Remix static analyzer
- Remix Analyzer moved to typescript and now uses the latest AST (Abstract syntax tree).
Remix tests
- We published new features recently and reached out to the Remix community for feedback, and received a good outcome. Here are the medium posts: part 1 – part 2.
Blog posts & reachout communities
We’ve started to push some new content, which will be our focus during the coming months.
We are also putting efforts in workshop content, realizing and promoting it.
E2E Testing
David aka @ioedeveloper joined the team recently and is working on E2E testing and the Remix IDE, aiming to consolidate our release process.
Research [Eth1.X (Stateless Ethereum)]
Authored by Griffin Hotchkiss
The set of upgrades to the existing Ethereum protocol dubbed “Eth1.X” have coalesced into a more unified effort by researchers to implement and transition to “Stateless Ethereum”. The upgrades and topics of inquiry are not just relevant to improving scalability and resilience of the current chain, but are also relevant and in many ways complementary to engineering and design challenges being tackled by Eth2 research teams.
Following EthCC in Paris, there was a Stateless Ethereum research Summit, regarded by attendees as seminal and wildly successful by all accounts.
Updates about the Stateless Ethereum initiative have been chronicled by Griffin Ichiba Hotchkiss in an ongoing series called “The 1.X Files”, which in addition to summarizing and digesting monthly calls, dives deep into the core concepts being researched and the road ahead.
Research [Serenity / Eth2]
Authored by EF Team
Danny Ryan, Carl Beekhuizen and the Eth2 research team have continued regular series like ‘Eth2 Quick Update’ and ‘Validated: Staking on Eth2’ here on the EF Blog. For the latest news and progress as we draw nearer to the launch of Phase 0, check out the latest posts below!
Eth2 quick update
Validated, staking on eth2
Security [Security / Consensus Tests]
Authored by Martin Holst Swende
The health of the Ethereum Mainnet is the top priority, and we have investigated and published an EIP proposing penalties for state trie misses.
Towards the end of 2019, we paid out several bounties. ChainSecurity earned another 8500 points, for three separate reports: 1000 points for a slow execution on Geth, due to an unnecessary copying of data when CALL variants were made with large calldata; 5000 points out of the ‘pot’ of money allocated towards EIP reviews, with their help in assessing the security of EIP-1884 (which also earned Neville Gretch (contract-library.com) 5000 points).;and submitted a DoS vector for Geth/Parity, together with Daniel Perez (split 50/50), which earned them 2500 points each.
In early 2020, the prolific bughunter Sam Sun was awarded another 10K bounty points for the ENS vulnerability which necessitated migrating all records to a new registrar.
The Go-Evmlab repository has been updated to better integrate with Geth and help out during analysis of chain operations, as well as creating custom evm-fuzzers.
We have also had two external audits done on the upcoming Discovery version 5 protocol. One was performed by Least Authority, and another by Cure53. They are both accessible here. The protocol is implemented (but not activated) in Geth already — see below.
Consensus tests:
Blockchain test generation code was reworked and migrated to retesteth.
VMTests are now generated in Blockchain test format.
Stats web server set up at http://retesteth.ethdevops.io/
Solidity
Authored by Franziska Heintel, Daniel Kirchner and Christian Reitwiessner
Since the last update, the Solidity team has released version 0.6.0. Apart from the abundance of features already announced in our previous post, this also includes “try/catch” as high-level syntax to handle failure conditions for external calls. In the meantime, the 0.6 series has stabilized in multiple minor releases and early planning for the next major release 0.7 has started (a future blog post will announce the features to be expected).
A notable new language feature within the 0.6 series is support for immutable variables. Starting from version 0.6.5 of Solidity state variables can be declared “immutable”. Immutable variables can be assigned once during contract creation and be cheaply read from runtime code. The constructor code will directly insert the values specified for the immutables during construction into the runtime code, so that the runtime cost of an access is merely that of a single PUSH.
Other language features that recently emerged are interface inheritance (which will be supplemented by ERC165 interface IDs in the near future), optional reason strings for internal reverts and the ability to assign storage pointers via inline assembly. The latter enables constructs useful for writing updateable contracts.
Furthermore we introduced syntax for CREATE2 via new C{salt:
The main focus of the Solidity team is on extending the new code generation via Yul as intermediate representation. A variety of language constructs is now supported: recent notable additions include external function calls, try/catch, increased array support, tuples and more.
On the backend side the translation of Yul code to Ewasm is now complete pending some tweaks with regards to types, meaning that finalizing code generation via Yul IR will yield a Solidity to Ewasm compiler.
The Yul optimizer continues to be improved; most notably we are introducing the Yul Phaser. The phaser is a tool that employs a genetic algorithm to find the best sequence of optimizer steps – in the future it could also be possible to use it on individual contracts if you want to spend more time compiling and get a cheaper contract.
Further improvements:
solc-js is now built to WebAssembly instead of asm.js, which should make compilation much faster and increase browser compatibility.
The JSON AST export is now complemented by an AST import that can be used e.g. for mutation testing and other experiments.
There is continued effort towards source verification (at https://github.com/ethereum/source-verify), the effort to build a collection of authenticated ABI and source codes of deployed smart contracts through the metadata hashes in the bytecode and to provide a trustless way to retrieve authoritative ABI information from ipfs or other sources.
The Solidity grammar is now defined via antlr and the antlr-based grammar will be kept up-to-date by the team.
SMT Checker
The SMTChecker module continues to increase its support to Solidity, as well as improving its verification techniques. The new CHC engine now also supports internal function calls and multi-transaction counterexamples (unreleased), showing exactly how each transaction must be called in order to break an assertion. We are currently working on support to external functions and as usual, supporting more features of the Solidity language.
Solidity Summit!
Finally, we are looking forward to the Solidity Summit, which will take place online on April 29-30. The Solidity Summit is an interactive forum with discussions and short talks about Solidity, Yul, language design and tooling. We aim to have useful discussions that result in improvement proposals and pave the way for actual implementations. Furthermore, we want to foster communication between teams working on similar topics and identify needs for the smart contract ecosystem for Ethereum. For information about registration, agenda and the livestream please visit the Solidity Summit website.
Follow us online
For regular updates, you can follow the Solidity team on Twitter or check out more Solidity-related content like feature deep dives, release announcements and bug reports on the recently launched Solidity blog!
ZoKrates
Authored by Jacob Eberhardt
Since the last update, the ZoKrates team designed and released the first version of zokrates.js, a library to compile, execute and prove ZoKrates programs from JavaScript. It uses WASM under the hood and is already being used to power our Remix plugin!
As part of this effort – and to better support programmatic interaction with ZoKrates – a new version of the ZoKrates ABI was developed. It is now capable of exposing complex data types in the same style Solidity does through ABI specifications.
To increase efficiency, we added further optimization techniques to the ZoKrates compiler: memoization of function calls, detection of unconstrained variables, and more. These optimizations are under review and subject to testing and we hope to bring them to you in the next release.
Native verification – a feature commonly requested by our users – is implemented as a prototype and currently undergoing testing.
Finally, the introduction of unsigned integers in ZoKrates which benefit from automatic optimizations is progressing. This is particularly useful when using widespread hash functions such as SHA256 and implementing algorithms that inherently use binary representations.
—
🦄