Dear friends,
From our personnel to you and your loved ones, we wish for the well-being and safety of everyone and their families during these challenging weeks. To help pass the time while we are all indoors, it’s time again to inform the community on advancements made by some of the EF-supported initiatives not addressed in last week’s ESP Allocation Update. Although the last Winter edition in this series was shared merely a few months ago, we’ve all progressed significantly since the deployment of the Istanbul network upgrade, and many groups have updates to provide.
As always, these updates concentrate on EF-supported squads and endeavors whose participants are striving to enhance and develop Ethereum as a whole. This edition encompasses updates from multiple teams featured in the prior report, along with additional fresh and rotating news.
Enjoy!
Aleth / C++ Ethereum
Written by Paweł Bylica
In December 2019, the 1.8.0 edition of Aleth was made available. It encompasses a variety of corrections and enhancements related to several aspects of how this C++ Ethereum node operates. Specifically, we optimized the RPC interface, blockchain synchronization, network protocol, and testing tools (testeth, aleth-vm). Refer to CHANGELOG for further details.
This release also includes significant contributions related to the consensus protocol:
- 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 promote EIP-centric network upgrade methodology.
Aleth 1.8.0 is the final planned iteration. From this point forward, we are solely committed to fundamental maintenance of the code, reviewing Pull Requests, and addressing the remaining requirements for testing and EIP evaluations. At this juncture, I would like to express my gratitude to all Aleth contributors, particularly Nils-Erik Frantzell, who dedicated considerable effort to the project over the past year.
It is also important to mention maintenance updates of sibling projects:
Finally, we have released an article on Efficient gas calculation algorithm for EVM, which was later incorporated into a Devcon 5 presentation Optimization techniques for EVM implementations.
Applied ZKP
Written by Koh Wei Jie and Kobi Gurkan
The Applied ZKP team endeavors to connect the gap between pioneering research in zero-knowledge proofs and practical application development on Ethereum.
Perpetual Powers of Tau
In September 2019, we inaugurated the Perpetual Powers of Tau ceremony (PPOT). PPOT’s goal is to support the zero-knowledge ecosystem, particularly zk-SNARK projects developed on Ethereum, by alleviating part of the burden associated with trusted setup ceremonies. Every zk-SNARK project necessitates two stages of parameter generation, and PPOT substitutes the first stage, which can be utilized by all circuits. Individual teams can select any contribution from the ceremony to proceed with their own phase 2 setup.
This ceremony accommodates circuits with up to 2 ^ 28 constraints, implying that each contribution entails a 97G download, a 1-day computation, and a 49G upload. At the time of writing, we gathered 29 contributions from 28 distinct individuals, and all contribution files can be downloaded and independently validated against a public ceremony transcript.
Semaphore
Semaphore stands as Applied ZKP’s premier project, launched in mid-2019. It is a general privacy tool enabling use cases like mixers, anonymous login, and confidential voting. One application of Semaphore, formulated by Chih-Cheng Liang, is unveiled the final source code. We have incorporated various elements from the circom standard library into the audit, thereby offering an enhanced array of instruments for the broader community of SNARK developers utilizing circom.
Phase 2 ceremony
As of the current writing, we are conducting a circuit-specific multi-party trusted setup ceremony. The methodology we are adhering to is detailed here. We partnered with Supranational, a participant of the VDF Alliance, to execute a verifiable delay function (VDF) on a pre-announced Ethereum block hash, and incorporated the result of said VDF into challenge file #25 from the Perpetual Powers of Tau ceremony (see below), marking the inception of the circuit-specific ceremony on April 6, 2020.
Due to the outstanding efforts by Brian Gu, we managed to adapt Aztec Protocol’s Ignition ceremony software for our event. For further details regarding this ceremony, please refer to its participant guide.
Feel free to engage in conversation in the Semaphore Society Telegram chat group.
Semaphore RLN
Semaphore RLN offers a mechanism for implementing rate-limiting in a P2P environment – rather than depending on an on-chain nullifier map to avert double-signaling, we utilize Shamir Secret Sharing to distribute shares of the broadcaster’s private key. Multiple disclosed shares from the same broadcaster can be leveraged to reconstitute the private key, which raises the risk of the original holder of the private key facing a slashing event.
MACI
Initially suggested by Vitalik Buterin in an ethresear.ch article, frameworks developed with MACI make collusion among participants challenging, while preserving the censorship resistance and accurate execution advantages of smart contracts. Although MACI may offer collusion resistance if the coordinator acts honestly, an unprincipled coordinator is incapable of censoring or manipulating its execution.
In late 2019, we commenced work on a technical specification and implementation and we are close to finalizing a minimal viable product.
Future endeavors: incorporating anonymization into MACI
MACI employs a coordinator for processing, whereby the coordinator utilizes SNARKs to validate integrity, ensuring that a malicious coordinator can only undermine collusion-resistance attributes. A current drawback of this approach is that the coordinator can connect each user’s initial key to their final key, being privy to all key modifications.
We aim to enhance privacy concerning the coordinator by enabling users to undertake anonymous key changes. For additional insights, please refer to this ethresear.ch article.
MiMC Bounty
MiMC has emerged as a favored cryptographic hash function in SNARKs due to its superior performance. Despite being the earliest of the group in the “hash functions with low multiplicative complexity” category, we believed it warranted increased scrutiny. We launched a bounty for collision detection in MiMC, which we also intend to extend to Poseidon.
Optimistic Rollup Hub + ZK Optimistic rollups
Optimistic Rollup enhances layer 2 scalability by utilizing on-chain data availability and fraud proofs. The Hub chain additionally facilitates straightforward mass migrations between various rollups. The hub offers seamless mass migrations.
ZK Optimistic Rollup builds on the same principle but for anonymous transactions. Instead of having all the transaction metadata exposed, each transaction within the rollup represents a 2-to-2 anonymous transfer.
PeekABook
PeekABook enables two users to privately match orders, ensuring that no user can ascertain additional information regarding an order placed by another user unless they possess an order that would fulfill it.
Experimental paths
Until now, we have detailed projects that we have launched — either as mature code, specifications, or definitive plans. We are continually exploring new experimental domains that we aspire will evolve into fully developed initiatives.
Some of these encompass:
- Verifying a STARK within a SNARK – facilitating some form of layer 1 recursion
- Blind Find – an MPC-based framework demonstrating a pathway exists between users in a p2p network, without disclosing the path itself.
- Fractal on Ethereum
- RSA-basedrollup
And more 🙂
Ecosystem Support Program
On April 1 we published the ESP Allocation Update, where we disclosed some of the efforts we’ve been undertaking to enhance our procedures, along with a list of the initiatives that obtained financial backing in 2019. Keep an eye on the blog for additional updates and follow us on Twitter (@EF_ESP) to stay updated on the latest regarding the projects we support!
Ewasm
Written by Alex Beregszaszi
Since our previous update in December, the team has persisted in advancing Eth 2.0 Phase 2 and has begun to engage more actively in Eth 1x research as well.
Our belief is that certain aspects of research are essential for both efforts and can be exchanged between the two projects.
Eth 1.x / Stateless Ethereum
In a stateless model, it is not anticipated that everyone retains a complete copy of the entire state of the blockchain. Rather, each block includes a proof (the so-called witness) of the state segment affected. The efficient creation, distribution, and verification of witnesses becomes a key element of this new stateless architecture. The challenge of creation and verification is what captivates our team the most.
There are numerous concepts for minimizing block witness size, some of which Paul has compiled in a survey. Given our expertise in instruction sets, the initial problem we examined was the reduction of code size. This is vital, as code also needs to be included in the witness. Two strategies come to mind: compression and merklization. An initial phase experiment indicates we can decrease the amount of code passed as part of the block witness by 40-60%.
We also plan to investigate options to
- minimize the storage component of the witness,
- to accurately account for the witness size (“witness metering”),
- and to take part in formulating a witness specification.
Eth 2.0
It should be noted that since the execution model of Eth 2.0 is also stateless, the work conducted as part of Eth 1x becomes relevant here as well.
Cross-shard design
Without the capability to efficiently transfer Ether (and possibly other tokens), compensating for execution and transactions becomes a complicated issue. Last year, various models surfaced, including receipts with accumulators, queues, and balance maps. Casey has suggested an alternative known as EthTransfer objects.
Alongside Ether transfer, contracts might wish to communicate with other contracts on different shards and potentially perform atomic operations. All of this creates a substantial design space for Phase 2, which we’ve been investigating thus far.
As an experiment, starting a few weeks ago, we have been developing Eth1x64. This narrows the design space and should facilitate quick iterations of various designs.
Under Eth1x64, each shard is uniform and runs an instance of Eth 1.x, with shard 0 being the current Eth 1.0 mainnet. We are undertaking multiple small proposals, all aimed at different means to achieve cross-shard communication.
This endeavor will provide insights into the intricacy of integrating sharding into Eth1, enabling us to gather broader feedback from Dapp developers, which we can then use to hone the WebAssembly-based Phase 2 designs.
Speed
Zero-knowledge protocols are becoming progressively crucial. It is essential to ensure 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 crafted. This example performs well as an Execution Environment. Benchmarks reveal that both can attain comparable performance to compiler engines and EVM-based (precompile supported) implementations. Refer to Jared’s summary for specifics.
This work has also directed further reviews of the big integer API, which is a critical aspect of a robust and secure WebAssembly-based execution.
WebAssembly
The past few months have been enriching for WebAssembly with the release of the stable 1.0 version of the specification. Several new promising interpreter projects have been announced and/or released. We are closely monitoring these and plan to incorporate them into our benchmarking report.
In January, we commenced work on Fizzy, a new WebAssembly engine. Features like integer-only support (no floating point operations) and interpreter-only execution render it well-suited for blockchain applications. Additionally, a clean codebase written in modern C++17 along with the objective of easy embeddability aim to make Fizzy a practical, modular component for Eth 2.0 client implementations. By the time of this update, Fizzy can pass nearly all official test cases (with the exception of Wasm validation, which is yet to be implemented) and compares excellently on speed benchmarks.
Formal Verification
Act
Act is an intuitive and efficient specification language for crafting formal specifications. It is under development with contributions from various groups, and we aspire that in the future, utilizing Act to delineate smart contracts will become standard practice.
By permitting attributes to be articulated on varied levels, the primary objective of Act as a tool is to facilitate modular verification. The specification can be validated as an independent document, where contract invariants may be assessed from the delineated function’s pre/post conditions, and the post conditions can be evaluated from a function’s storage updates. Ideally, this modular validation will simplify the process for other tools to verify the accuracy of the source code/bytecode.
At present, we are developing three proof backends for the intermediate proofs:
- Coq definitions
- K specs
- SMT theorems
Each backend presents its unique advantages and drawbacks, and we aim to ensure good performance and coverage by advancing all fronts concurrently.
We anticipate launching a prototype for each proof backend and investigating how to articulate loop invariants by June 2020.
We will soon post a comprehensive technical article regarding Act. Contributions to the repository are perpetually welcomed!
SMTChecker
The SMTChecker is a static analysis module based on model checking found in the Solidity compiler, aiming to verify source code assertions during compile-time. Last year, a new engine centered around Constrained Horn Clauses was introduced. This engine’s key attribute is that it can autonomously discover inductive invariants used to validate assertions, thus enabling support for loops and state characteristics.
Recently, we integrated internal function calls into the engine and continue to enhance support for the Solidity language. Over the next three months, we shall focus on expanding language support, counterexample generation/presentation, and external function calls, with hopes of evolving the SMTChecker from an experimental stage into a practical and robust tool.
In the future, we also aspire to:
- Merge the SMTChecker and Act, investigating intriguing concepts like the synthesis of absent code to conform to the specifications / synthesis of adversarial code.
- Develop a Remix plugin for the SMTChecker which would greatly enhance usability.
Verified ABI encoding/decoding
We are partnering with ConsenSys R&D, who are engaged in crafting a verified ABI encoder/decoder utilizing Yul-Isabelle. The idea and discussions initiated at Devcon V, and since then, considerable progress has been achieved, bringing us close to a prototype.
Initially, we plan to utilize it with the Solidity Fuzzer to uncover bugs related to optimization and ABI encoding/decoding. Our ultimate and somewhat ambitious vision is to incorporate the verified ABI encoder/decoder into the Solidity compilation process. This would signify that a significant portion of code generation is verified!
Eth2
We have consistently supported Runtime Verification in upholding the KEVM formal semantics and validating the deposit contract and beacon chain specifications. The deposit contract is also one of our primary benchmarks during the Act development process. We aim to present an alternative specification for the deposit contract and prove the incremental Merkle tree properties through Act by July, when we also plan to explore Eth2 Phase 1 and Phase 2 attributes that need to be substantiated.
Hevm
Hevm, a Haskell EVM evaluator and debugger can now be utilized for property-based testing.
Users of the dapp development tool can now formulate Solidity tests whose inputs are randomly generated and executed multiple times against a correctness benchmark. This offers smart contract developers a way to substantially enhance test coverage in a fairly straightforward manner.
Moving forward, we will investigate extending hevm with symbolic execution functionalities. This would enable hevm to formally validate EVM bytecode.
Geth
Written by Péter Szilágyi
In the preceding quarter, the Geth team has been engaged with network infrastructure and establishing the foundation for future updates. This article will merely highlight a few of the significant features; for a comprehensive bullet point overview, please refer to our release notes.
DNS discovery
A feature we drafted about two years ago and launched last quarter is DNS-based peer discovery. Moving forward, Geth v1.9.11+ nodes are equipped with two separate systems to identify peers. The DNS lists act as a fallback strategy when peers cannot be identified through the DHT. They could also serve as the initial point for a Tor integration.
While DNS-based discovery is a centralized approach, but
“`we have endeavored to render the functionality of this system as open and unregulated as feasible. The public lists, which are utilized by default, are created by scanning the discovery DHT. Nodes operating any Ethereum client that adheres to EIP-868 and EIP-2124 will automatically be included in the public lists. If you wish to establish a DNS-based node list for your private or public network, please refer to our DNS Discovery Setup guide.
Currently, there are approximately 1150 publicly routable Ethereum mainnet nodes in the default list; additionally, our public lists also cater to the Ropsten, Goerli, and Rinkeby test networks. At present, the network generates around 8 million DNS queries daily directed towards this discovery system.
Transaction dissemination
For a couple of years, much of the network bandwidth utilized by Ethereum nodes has been involved in transmitting transactions. Regrettably, this system was never fine-tuned since its launch, leading to excessive waste. Over the past quarter, we have outlined an update to the eth protocol (EIP 2464) that permits transactions to be announced among nodes and only transmitted upon solicitation.
This updated protocol was introduced in Geth v1.9.11, is already in place in Nethermind, and is also being developed for Open Ethereum. As only around 30% of the network currently supports it, the overall reduction in bandwidth remains uncertain; however, preliminary tests with an eth/64 versus eth/65 bootnode experiment with 250 peers reveal promising outcomes.
Based on last week’s activity, eth/65 has the potential to lower transaction propagation bandwidth by about 75%. For one of our bootnodes with 250 full node peers, this equates to a savings of 750KB/s, or roughly 1.8TB of bandwidth each month. We are confident that there’s still room for enhancement, but we will proceed gradually.
In addition to eth/65, Geth added support for transactions exceeding 32KB back in January (thanks to StarkWare), initially setting a soft limit at 64KB that has now been increased to 128KB (higher limits greatly depend on how eth/65 performs on a global scale).
Dynamic snapshots
A significant bottleneck in executing the EVM and conducting an initial sync revolves around the state representation utilized in Ethereum: the Merkle Patricia trie. As all state data is structured in a tree format, retrieving any account currently requires about 6-8 random disk lookups on the mainnet. During quick sync, the necessary intermediate trie nodes must be downloaded sequentially to access the actual data.
A feature we have been actively developing for the past six months is dynamic state snapshots: in essence, creating a flat acceleration structure on disk that allows any account or storage slot to be retrieved with just one disk lookup. This concept is similar to Open Ethereum’s fatdb layout; however, this one is dynamic: the snapshot mechanism in Geth is able to maintain the acceleration structure in real time as the chain evolves (including the mini forks).
One advantage of the dynamic snapshots is O(1) EVM state reads. While it might seem like a breakthrough, it’s not entirely so. Most contract executions do not excessively demand disk reads, making the advantage somewhat limited, and many contracts also perform numerous writes, which still need to be added into the Merkle trie. However, dynamic snapshots do allow eth_call operations to be remarkably quick, and they significantly complicate the execution of DoS transactions.
An even more intriguing functionality enabled by the dynamic snapshots is a novel synchronization protocol, which we have been striving to finalize for the past two years (initially referred to as leaf sync). The protocol is still a work in progress, but if our assumptions hold true, it should enable syncing the Ethereum state at a much faster pace.
Discovery v5
The initial iteration of the next-generation discovery protocol has been incorporated into Geth, although it has not yet been activated. While the specifications and implementation remain adaptable, aligning with the Eth 2.0 requirements, it is indeed a significant milestone to have a functional version present in the live codebase.
Javascript Team
Authored by: Holger Drewes, Philipp Langhans
The last quarter was thrilling for the team. For the first time, we gathered in person in early March during EthCC in Paris, strengthened our connections, and deliberated team collaboration, potential partnerships, and future initiatives. Anticipate further updates once we start seeing outcomes.
Ethers.js
Ethers v5 is currently undergoing its final beta releases before the official launch. Numerous fixes and enhancements for usability (such as more appropriate names for API calls) discussed within the community have been incorporated in preparation for a robust and stable final release. Notable new features added recently are the new “`html
WebSocketProvider and provisional EIP-1193 (Ethereum Provider JavaScript API) assistance.
Web3.js
After holding the primary maintenance role for the Web3.js library for over a year, Samuel has determined it is the appropriate moment to embark on new ventures (many thanks Samuel for all your outstanding efforts! ♥️). We savored a final gathering in the days surrounding EthCC. The library’s development will now be managed by other team members collectively.
Currently, we maintain a strong emphasis on establishing a reliable release process and are working to familiarize ourselves with the technology stack and protocols since Samuel was the leading authority in this area. Kindly bear with us as we are thus very selective about incorporating new functionalities in the immediate future. For now – and for the same reasoning – we will also refrain from development on the 2.x branch (presently published as an alpha version of the library.
EthereumJS
We have transitioned the EthereumJS VM to a monorepo, merging structurally related libraries (tx, block, blockchain, HF configuration (common)) under a single entity. This will greatly simplify VM development moving forward and enable integrated PRs. A v5 release of the VM based on this new structural foundation is slated for release soon, which will introduce several breaking modifications. Feel free to drop in and participate (and influence) the conversation.
Thanks to the excellent contributions of dryajov, we now have a functioning TypeScript implementation of the devp2p stack. A release of this is on the horizon.
Grid
Ethereum Grid has been divided into two components: the desktop application and a core module that can manage binaries outside of the Electron environment e.g. on CLI or in various tools like test runners or IDEs (Remix, VSCode). The objective of the core is to offer a compact engine that can be extended through plugins. The essential mechanisms that facilitate secure and stable extensions without having to alter Grid in the future have been established. This was the primary aim of the refactoring and a move towards a finalized product.
Grid can be augmented with small scripts, referred to as workflows, that interact with binaries. Numerous such scripts have been developed and demonstrated at EthCC: Grid Workflows
Python Ecosystem [PyEVM / Trinity / Web3.py / Vyper]
Authored by Piper Merriam
Web3.py
The Web3.py library has continued making progress on gradual enhancements and stability. Thanks to various third-party contributions, we anticipate releasing preliminary support for mnemonic phrases and HD accounts in the foreseeable future. We are also striving to achieve full async support, although a considerable amount of foundational work still remains to be accomplished in this area.
Trinity
The Trinity client is actively advancing on both the 1.x and 2.0 projects. Work on the Trinity Eth2 client continues as we approach the establishment of stable, long-term public testnets. On the Eth1.x front, we are persistently working toward a functional mainnet client. One of the most significant outcomes from our efforts over the past two years is the “Stateless Ethereum” initiative, which is set to transform the Ethereum mainnet over the next 18-24 months.
EthPM
The EthPM group is collaborating with the Solidity team to integrate the packaging standard so that the compiler can compile the resources in a package, generate packages of the compiled resources, and utilize the EthPM specifications for metadata/contract source validation.
Remix
Feel free to explore our medium articles for more comprehensive information.
Our public website has just launched 😉
Remix IDE – Live && Desktop Application
- Comprehensive support for Solidity 0.6.0 breaking changes and features has been incorporated into the Solidity Plugin.
- Low-level interactions are now feasible (Solidity receive and fallback)
- Light and Dark themes have been included. We have redesigned the UIs of the Solidity Plugin and Deploy&Run Plugin.
- The latest Remix Plugin Engine(v0.2.0) has been effectively integrated into the Remix IDE, along with the remix-simulator (Ethereum dev node in the browser).
- Moving forward, the desktop edition will align with Remix live releases.
Remix Plugin
- The latest iteration comes with the capability to support websocket plugins, and we will soon add more types (Secure Ecmascript, IPC).
- Integration with VScode is currently in the
“`process and are anticipated to be accessible soon. - Here’s the guide for creating plugins.
External Plugins
- We encourage external groups to construct their plugins and incorporate them into Remix IDE.
- There is a Gitter channel specifically for Remix plugins. You can suggest a plugin to the community by initiating a PR in the remix-plugins-directory repository
- If you need financial assistance to develop your plugin, we may be able to help!
Here’s what you should do: – Kindly create a Github issue (in the repository where your plugin resides) detailing your intentions. – Contact us via email – remix@ethereum.org – including a document explaining the project, a link to the Github issue, and a proposal for an invoice. – We will strive to reach out to you and outline the next steps.
Remix Simulator
- The integration with Remix IDE is largely finalized.
Remix static analyzer
- Remix Analyzer has transitioned to TypeScript and now employs the latest AST (Abstract Syntax Tree).
Remix tests
- We have introduced new features recently and reached out to the Remix community for their input, which resulted in positive feedback. Here are the Medium articles: part 1 – part 2.
Blog posts & outreach communities
We have begun to share some fresh content, which will be our emphasis in the coming months.
Additionally, we are dedicating resources to workshop content, both creating and promoting it.
E2E Testing
David, known as @ioedeveloper, has recently joined the team and is focusing on E2E testing and the Remix IDE, aspiring to streamline our release procedure.
Research [Eth1.X (Stateless Ethereum)]
Written by Griffin Hotchkiss
The array of enhancements to the current Ethereum protocol referred to as “Eth1.X” have combined into a more cohesive initiative by researchers to implement and transition toward “Stateless Ethereum”. The improvements and areas of exploration are not only significant for boosting the scalability and robustness of the existing chain but are also pertinent and often complement the engineering and design challenges being addressed by Eth2 research teams.
Following EthCC in Paris, a Stateless Ethereum research summit was held, which participants regarded as groundbreaking and overwhelmingly successful.
Updates on the Stateless Ethereum initiative have been documented by Griffin Ichiba Hotchkiss in an ongoing series titled “The 1.X Files”, which, in addition to summarizing and digesting monthly discussions, delves deeply into the fundamental concepts under investigation and the path forward.
Research [Serenity / Eth2]
Written by EF Team
Danny Ryan, Carl Beekhuizen and the Eth2 research team have continued their regular series titled ‘Eth2 Quick Update’ and ‘Validated: Staking on Eth2’ on the EF Blog. For the most recent updates and advancements as we approach the launch of Phase 0, please check out the latest articles below!
Eth2 quick update
Validated, staking on eth2
Security [Security / Consensus Tests]
Written by Martin Holst Swende
The well-being of the Ethereum Mainnet is of utmost importance, and we have examined and published an EIP proposing penalties for state trie misses.
Towards the end of 2019, we awarded several bounties. ChainSecurity acquired an additional 8500 points for three separate reports: 1000 points for a slow execution on Geth caused by an unnecessary duplication of data when CALL variants were made with large calldata; 5000 points from the fund allocated for EIP reviews, for their assistance in evaluating the security of EIP-1884 (which also earned Neville Gretch (contract-library.com) 5000 points); and they submitted a DoS vector for Geth/Parity, along with Daniel Perez (split 50/50), which earned each of them 2500 points.
In early 2020, the prolific bug bounty hunter Sam Sun was granted another 10K bounty points for the ENS vulnerability that required migrating all records to a new registrar.
The Go-Evmlab repository has been enhanced to better work with Geth and assist during analysis of chain operations, as well as to create custom evm-fuzzers.
We have also conducted two external audits on the forthcoming Discovery version 5 protocol. One audit was carried out by Least Authority, and another by Cure53. They areboth reachable here. The system is executed (though not yet activated) in Geth already — examine below.
Consensus examinations:
Blockchain testing generation code has been restructured and transferred to retesteth.
VMTests are presently produced in Blockchain test format.
Stats web server established at http://retesteth.ethdevops.io/
Solidity
Composed by Franziska Heintel, Daniel Kirchner, and Christian Reitwiessner
Since the previous update, the Solidity team has rolled out version 0.6.0. In addition to the plethora of features already disclosed in our last update, this also integrates “try/catch” as a high-level syntax to manage failure cases for external calls. Meanwhile, the 0.6 series has achieved stability with various minor versions, and early preparations for the next major release 0.7 have commenced (a forthcoming blog entry will announce the expected features).
A remarkable new language capability within the 0.6 series is the support for immutable variables. Commencing with version 0.6.5 of Solidity, state variables can be designated as “immutable”. Immutable variables may be assigned a single time during contract establishment and can be efficiently read from runtime code. The constructor code will directly embed the values designated for the immutables during setup into the runtime code, allowing the runtime cost of an access to only be that of a single PUSH.
Additional language capabilities that have surfaced recently include interface inheritance (which will be complemented by ERC165 interface IDs in the near future), optional reason strings for internal reverts, and the capability to assign storage pointers via inline assembly. The latter facilitates the creation of constructs useful for drafting updatable contracts.
Moreover, we have introduced syntax for CREATE2 via new C{salt:
The primary focus of the Solidity team is to extend the new code generation utilizing Yul as an intermediate representation. A variety of language constructs is now endorsed: recent significant additions involve external function calls, try/catch, enhanced array support, tuples, and more.
On the backend, the translation of Yul code to Ewasm is now finished, pending some adjustments regarding types, which indicates that completing code generation via Yul IR will yield a Solidity to Ewasm compiler.
The Yul optimizer continues to see improvements; notably, we are introducing the Yul Phaser. The phaser is a utility that harnesses a genetic algorithm to determine the optimal sequence of optimizer steps – in the future, it may also be possible to apply it to individual contracts if you wish to spend more time on compilation for a less expensive contract.
Further advancements:
solc-js is now constructed for WebAssembly as opposed to asm.js, which should enhance compilation speed and boost browser compatibility.
The JSON AST export is now augmented by an AST import that can be utilized for mutation testing and other trials.
There is ongoing effort towards source verification (at https://github.com/ethereum/source-verify), striving to compile a collection of validated ABI and source codes of deployed smart contracts through the metadata hashes within the bytecode and to offer a trustless method to retrieve authentic ABI data from IPFS or other resources.
The Solidity grammar is now defined through antlr, and the antlr-based grammar will be consistently updated by the team.
SMT Checker
The SMTChecker module persists in expanding its support for Solidity, in addition to enhancing its verification methodologies. The new CHC engine now also accommodates internal function calls and multi-transaction counterexamples (unreleased), demonstrating precisely how each transaction must be invoked to breach an assertion. We are currently developing support for external functions and, as usual, advancing support for additional features of the Solidity language.
Solidity Summit!
Ultimately, we are eagerly anticipating the Solidity Summit, which will occur online on April 29-30. The Solidity Summit is an interactive platform featuring discussions and brief presentations concerning Solidity, Yul, language design, and tooling. We aspire to have productive discussions that yield improvement proposals and pave the route for tangible implementations. Additionally, we wish to cultivate communication among teams tackling similar subjects and pinpoint requirements for the Ethereum smart contract ecosystem. For details on registration, agenda, and the livestream, please visit the Solidity Summit website.
Follow us online
For regular updates, you can track the Solidity team on Twitter or explore more Solidity-related materials such as feature deep dives, release notifications, and bug reports on the newly launched Solidity blog!
ZoKrates
Composed by Jacob Eberhardt
Since the last update, the ZoKrates team has created and launched the inaugural version of zokrates.js, a biblioteca for compiling, executing, and proving ZoKrates programs from JavaScript. It operates using WASM at its core and is already powering our Remix plugin!
As a component of this initiative – and to enhance programmatic interaction with ZoKrates – a fresh version of the ZoKrates ABI was engineered. It is now proficient in exposing intricate data types following the same style Solidity employs through ABI specifications.
To bolster efficiency, we have incorporated additional optimization strategies into the ZoKrates compiler: function call memoization, identification of unconstrained variables, and more. These enhancements are currently under review and subject to testing, and we anticipate introducing them in the next release.
Native verification – a feature frequently requested by our users – is established as a prototype and is presently undergoing testing.
Lastly, the roll-out of unsigned integers in ZoKrates, benefiting from automatic optimizations, is making progress. This is especially advantageous when utilizing well-known hash functions such as SHA256 and implementing algorithms that inherently incorporate binary representations.
—
🦄
