Companions,
Throughout the previous year, programmers and analysts backed by the Ethereum Foundation have diligently focused on their tasks and maintained an impressive output.
Their concentration has persisted on their endeavors, and collectively we are all contributing to a more comprehensive Ethereum. Today, our routine all-team update series is reinitiating in a transformed and continually expanding ecosystem. Ethereum boasts larger decentralized application, developer, and user communities than ever, the network has persistently enhanced, and consistent advancement has been realized on projects both significant and minor.
Although many squads release their own thorough updates, we deemed it fitting to present the community with the most recent news from various teams (some of whom are more reserved) supported by the Foundation. Enjoy!
Aleth / C++ Ethereum
In anticipation of the Constantinople / Petersburg upgrade, Aleth has had several releases – commencing from version 1.5.x series and culminating with the latest 1.6.0. Aleth has obtained a plethora of peer-to-peer network enhancements, including a standalone devp2p discovery client named aleth-bootnode, and is aligned with the most recent Ethereum revision.
Changelog: https://github.com/ethereum/aleth/blob/master/CHANGELOG.md
The EVMC initiative continues to progress by gaining new language bindings and various enhancements while maintaining ABI compatibility with version 6.
Changelog: https://github.com/ethereum/evmc/blob/master/CHANGELOG.md
Lastly, the ethash library (https://github.com/chfast/ethash) has incorporated ProgPoW support along with several integration fixes and upgrades.
Changelog: https://github.com/chfast/ethash/blob/master/CHANGELOG.md
DevOps
There are five primary domains where DevOps resources are utilized: Websites, Bootnodes, Geth, Swarm, and Testing. DevOps is continually enhancing our methodologies for deploying infrastructure, primarily utilizing Ansible and Terraform, but also employing Kubernetes. Furthermore, we are working to augment documentation and tracking of how infrastructure is utilized by all the engineering teams.
One recent mini-project that has reached completion involves collating recent code forks of EthStats and establishing a release and new repository which we refer to as “EthStats Classic” (https://github.com/ethereum/eth-netstats). Alethio EthStats is the version 2.0 and will be upheld by the Alethio group (https://github.com/Alethio/ethstats-network-dashboard).
From within the Swarm team: We are developing tools using Kubernetes that enable us to swiftly provision various Swarm deployments comprising up to 1000 Swarm nodes, pre-configured with tracing, monitoring, and data visualization tools, which facilitate our development and testing initiatives. These tools allow us to conduct multiple end-to-end tests as well as simulate various network scenarios. Additionally, we regularly conduct integration tests on larger deployments in conjunction with our go-test test suite before every release, ensuring that we do not introduce regressions or performance decline in Swarm.
DevP2P Design
In early 2019, DevP2P Design finalized several significant tasks:
-
EIP-778 (Ethereum Node Records) was sanctioned during the allcoredevs conference call.
-
Protocol specifications for eth/63 and les/2 have been transferred from GitHub wiki pages to the https://github.com/ethereum/devp2p repository.
-
Initial drafts of the Node Discovery v5 specification have been released.
In the meantime, we are diligently focused on finalizing the Node Discovery v5 specification. The “par”, “pip,” and “shh” protocol specifications are being modified for publication in the devp2p repository and the implementation of EIP-868 and Node Discovery v5 in Geth. We are also engaged in developing an EIP for RLPx v6, which aims to remedy certain cryptographic issues and to integrate EIP-778 node records into the handshake process.
ENR extensions and auxiliary development tools have been added to Geth, both as an enhancement to v4 and as a component of v5. The Discovery v5 protocol and its Geth implementation are nearing completion as final adjustments are being made, with external auditors now integrated into the protocol for a security examination. Discovery v5 is garnering significant attention from the Eth 2.0 implementers community, and Felix has participated in discussions with them to provide clarity on how the protocols harmonize.
The devp2p repository continues to establish itself as a crucial hub for Ethereum communication protocols, with several intriguing proposals currently under evaluation, and documentation like LES and PIP having been finalized. Significant behind-the-scenes discussions and activities have been underway concerning LES and its prospective direction. Numerous enhancements to LES code structure and durability are in the Geth pull-request queue (a special acknowledgment goes to Gary Rong) addressing immediate challenges, while research on the long-term vision is being conducted. In the upcoming weeks, the Geth team will convene to unify ideas and reach a verdict regarding the direction of LES and its implementation.
EF Grants
During the first quarter of 2019, we publicly shared Wave 5 and unveiled additional recipients at Ethereal. It has been an exceptionally thrilling period for the program as we have quietly broadened our scope to include a variety of project types and examined further means in which we can assist the community.
While we proceedto welcome new submissions, we are additionally proactively identifying high affinity applications from core developers and researchers. Furthermore, we will (in the upcoming months) release a Grantee Retrospective showcasing the effects of prior grants and the exceptional teams behind these initiatives.
The purpose of the program is not merely to offer financial assistance, but to deliver more tailored support for high-potential teams, encompassing research aid, networking, communications, and beyond. By enhancing the support framework and inviting diverse perspectives, we adhere to our mission of decentralizing the decision-making process while genuinely striving to advance the ecosystem. Stay tuned for more updates!
EthereumJS
Our emphasis within the EthereumJS team is to cater to the community with top-notch and resilient JavaScript/TypeScript implementations of base-layer Eth 1.0 and progressively Eth 1.x technologies and protocols. Please visit our organizational documentation at ethereumjs.readthedocs.io for an overview of our activities and key entry points to our work.
TypeScript
The primary focus earlier this year was migrating our codebase to TypeScript, and we are close to finalizing our most utilized libraries. We have introduced TypeScript versions of essential building blocks such as our blockchain and transaction libraries (the latter now featuring complete hard fork and EIP-155 replay protection support); here is an open PR containing a thorough rewrite of the devp2p library in TypeScript awaiting merging (kudos to Dmitriy Ryajov from MetaMask/Mustekala); and – perhaps the most thrilling aspect – the transformation of our VM implementation to TypeScript has now been finalized and is already incorporated into the master branch. Keep an eye out for a beta release shortly!
VM
We recognize the significance of a well-organized, modular, and extensible JavaScript VM for enabling powerful analysis and debugging capabilities within development tools like Remix, Truffle, and others. In this light, a major current focus over the last few months has been to make substantial progress toward these objectives and undertake significant refactoring on the VM. Primarily executed by our new team member Sina Mahmoodi, the upcoming v4 VM release will feature more explicit and comprehensible memory and stack management, modernization of code through the introduction of ES6 classes and async/await usage, in addition to a comprehensive refactoring and modularization of the EVM-specific code architecture. The latter – alongside some newly introduced EEI-like environment interfaces for accessing blockchain data – is gearing up for a forthcoming eWASM integration within the VM.
Other Research
We are also committed to sustaining and maintaining our existing codebase to ensure our libraries remain secure, reliable, and efficient. The latest experiments pursuing these objectives involve leveraging WASM modules for cryptographic primitives, the use of BigInt in JavaScript/TypeScript alongside fixed-width number management, as well as enhanced handling and conversion of hexadecimal and buffer values with reduced error potential. We will update you once we achieve concrete results on these various fronts.
Ewasm
The recent months have been particularly active and productive. To ensure that Ewasm is effectively designed as an execution layer, the design process is guided by prototypes, analysis, and benchmarking. In Q1, we initiated comprehensive benchmarking studies for both WebAssembly and EVM engines. In Q2, we launched Scout, a prototype execution engine for Ethereum 2.0. Our emphasis in Q3 will be on ongoing iterations of prototypes, informed by our analyses and benchmarking.
Ewasm during Q1 2019
Benchmarking
As benchmarking advanced, new inquiries emerged that necessitated more detailed benchmarks and at times the development of new infrastructure. Benchmarking aims to address ongoing questions, including those concerning:
* various WebAssembly engines (including interpreters and different compiler types)
* different implementations of Ethereum precompiles
* implementing the same contracts in both WebAssembly and EVM
* diverse metering strategies
Benchmarked WebAssembly (Wasm) engines comprise a substantial array of standalone engines, alongside the Wasm engines integrated into Ewasm clients (using Hera).
For the precompiles comparison, we utilized go-ethereum, natively-compiled Rust implementations, and Wasm-compiled Rust versions. The Rust implementation for each Constantinople precompile is accessible at ewasm-precompiles. We also employed various manually optimized C versions.
For the EVM comparison, we selected optimized EVM implementations of contracts and created corresponding versions in WebAssembly. The EVM bytecodes were assessed using go-ethereum, parity-ethereum, and evmone. These comparisons have been particularly productive, uncovering new objectives and requirements for our design.
The architecture of WebAssembly lends itself well to metering optimizations. Several metering prototypes were developed and analyzed, focusing on common contract classes and various types of WebAssembly engines.
Results regarding EVM were disclosed in Q2 (see below). Reporting on subsequent results, including an in-depth analysis of WebAssembly engines, is ongoing and will be provided in future publications.
Precompiles
The implementation of all Constantinople precompiles along with four newly suggested precompiles (blake2, ed25519, bls12-381, sha1) has been completed and is available in the ewasm-precompiles repository.
We accomplished syncing the complete Rinkeby chain utilizing these implementations in go-ethereum.
Eth 1.x
Certain team members took part in the Eth1.x / Istanbul meetups located in San Francisco and Berlin. We provided updates regarding our advancements and showcased several EIP proposals for Istanbul, which hold importance for Ewasm. Three significant areas of alteration include enhanced protocol limits, segregation of initialization and operational code, and account versioning.
Eth 2.0
The Ewasm team has consistently engaged in discussions with the Eth 2.0 research team about Phase 2. We shared unresolved queries, design elements, and concepts. The Ewasm team took part — primarily remotely — in the Eth 2.0 research meeting leading up to EDCON in April. The intention was to converse about execution engine prerequisites for Eth 2.0.
Our proposals are documented in our design repository (https://github.com/ewasm/design/issues).
Testnet
The testnet is continuously managed at ewasm.ethereum.org. Contracts can be crafted in Rust utilizing Rust tools (ewasm-rust-api and chisel), which have seen enhancements. Contracts can also be composed in C, which features a less mature toolchain.
Ewasm during Q2 2019
Eth 1.x
We have made public a section of the benchmarking report: EVM benchmarks. The outcomes illustrate the potential for significantly lowering the gas cost of computational opcodes within the EVM, prompting us to propose EIP-2045: Particle gas costs for EVM opcodes.
The EVM benchmarks emphasize new speed records established by the optimized EVM implementation: evmone. Developed through a collaborative effort of the Ewasm and Aleth/C++ teams, evmone is intended to be imported as an execution module by any Ethereum client. Further evaluation of the speed improvement achieved by evmone and potential gas cost reductions in the EVM is currently ongoing.
Eth 2.0
We introduced Scout, a prototyping tool for Wasm execution scripts on Ethereum 2.0. The release of Scout was announced on ethresearch here and was showcased at the Scaling Ethereum conference in Toronto (video here).
Scout represents a prototype of a novel method for execution on Ethereum 2.0 based on “execution environments”. Additional experimentation and evaluation are necessary to ascertain if execution environments can fulfill the requirements of Ethereum 2.0, and Scout is structured for conducting such experiments. Numerous researchers and developers are enthusiastic about this new methodology (see the update on Serenity from the Research team, below).
Wasm on the Blockchain
The Ewasm team delivered four presentations in Berlin at the inaugural Wasm on the Blockchain workshop. Videos from the gathering have yet to be uploaded, but slides are accessible:
Several members of the Ewasm team also took part in the June assembly of WebAssembly’s Community Group. This engagement has enabled us to comprehend and discuss forthcoming proposals for WebAssembly, many of which are pertinent to Ewasm. Notes from the Community Group assembly can be found in the WebAssembly/meetings repository.
Geth
The Geth team has been focusing on the upcoming major release, v1.9.0, which has been under development for nearly four months now. Some hints that we’ve shared throughout this period revolve around substantial performance enhancements for archive nodes and considerable storage reductions for full nodes. These appear to be corroborated by external sources as well, and we are genuinely pleased about them. Additionally, we have been working on a new database format that allows relocating a significant portion (estimated at ⅔, based on a recent benchmark) of the data of a full node (not an archive) onto a HDD, making it more convenient and cost-effective to operate Ethereum nodes.
Lower level networking: the team has concentrated on the new discovery specifications (ENR and associated), aiming to replace both the older v4 (used by full nodes) as well as the makeshift v5 (used by Geth light clients). This will be the first substantial upgrade of this infrastructure in the last four years, therefore we have many lessons to incorporate. The ambition is to construct a far more robust system capable of supporting the coexistence of higher-level protocols (les) and multiple Ethereum networks (mainnet, testnets, etc).
Higher level networking: the light client protocol features transaction lookups by hash and new RPC APIs to provide priority service to paying customers. The team has reviewed directions for both the LES and PIP protocols and has agreed to initiate the establishment of common directions between Geth and Parity. The first cross-team meeting is scheduled for May.
We have also concentrated on dividing
We have extracted account management from Geth into a distinct signer application named Clef. The initial release will only be command-line interface (CLI), but we have been developing various proof-of-concept user interfaces to ensure we and others can build upon the foundational elements that Clef offers. Clef aims to offer a secure method for managing your Ethereum accounts capable of handling both keys and hardware wallets; but most significantly, one that can be utilized by all decentralized applications on your system without necessitating that each DApp develops its own account management!
Other minor features we have been focusing on encompass a GraphQL-based API for querying blockchain data, integrated support for smart card wallets, updated Ledger compatibility, Prometheus monitoring support (in addition to InfluxDB, which we have already deployed), BlockScout integration into Puppeth, and more.
As we approach the 1.9.0 release, we have shortened this section and will provide a detailed blog post in the upcoming weeks!
Grid
The Mist Browser has been phased out, but Ethereum Grid was introduced. Grid is a desktop application that empowers users to securely download, set up, and utilize various clients and tools within the Ethereum ecosystem. Among its possible advantages, Grid can:
-
enable a less tech-savvy audience to interact safely with technical tools
-
assist projects in the ecosystem to reach broader audiences
-
offer a platform to expedite development in the Ethereum space.
The Grid team is eager for your feedback on the alpha software and welcomes communication from projects interested in creating a plugin for the platform!
Moon
Our latest achievements are documented on our roadmap as an early year written update! Check it out on GitHub: https://github.com/moonad/roadmap.
Play
Introducing Play: Tools for decentralized education
Play launched our inaugural tool a month ago – an embeddable Solidity editor. You can paste Solidity code and receive a live preview which allows you to publish the contract and interact with it on-chain. Play can be embedded in any site or application – to demonstrate your smart contract, educate, you name it! Try it out at https://play.ethereum.org/editor-solidity/
We have just released our second tool, a static workshop/tutorial generator.
Stay tuned and engage with the Play team https://twitter.com/play_ethereum
Python Ecosystem [PyEVM/Trinity/Web3.py/Vyper]
Web3.py
Web3.py has been progressing toward a v5 beta release. Version 5 includes efforts to standardize the supported RPC APIs following EIP-1474, a new API for reading from deployed contracts, implementation of signing standards like EIP-712 and EIP-191, as well as numerous bug resolutions. Web3.py v5 also features a new experimental package manager API. Review the release notes for more details.
Vyper
Vyper has benefited from several internal cleanup initiatives. Examples of this include comprehensive lint checks, the inclusion of type annotations in certain code modules, automation for these annotations, enhancements to Vyper’s testing setup and continuous integration workflow, and various code refactors. All of this has been part of an ongoing, project-wide initiative aiming for better maintainability and readability. The long-term objective of this initiative is to facilitate an easier onboarding process for new contributors to the project.
Vyper is also actively adding anticipated features. For further information, check out Vyper’s GitHub issues and pull requests pages.
Trinity
Trinity has continued to enhance with numerous bug fixes, performance upgrades, and Constantinople support. We’ve also focused on making the codebase more modular to boost maintainability and code reuse across both Ethereum 1.0 and 2.0 sections of the code repository. Trinity is further enhancing its event-driven architecture and extensibility capabilities.
In addition, Trinity has undergone numerous updates aimed at establishing an initial Ethereum 2.0 testnet. We remain in collaboration with the research team to integrate Eth2 into Trinity.
In Eth1.0 developments: we are currently experimenting with a new feature dubbed Beam Sync. Picture starting a Trinity node and having it begin processing the latest blocks and responding to RPC requests within minutes. Beam Sync will validate blocks as they are mined by prioritizing the synchronization of the state used in the newest blocks.
Finally, on the Eth1.x front, we have been advancing the Firehose Sync protocol, a novel state synchronization protocol designed to significantly reduce the time required to initiate a node and download all necessary data to become an integral node within the Ethereum network. Firehose and Beam Sync complement each other. While Beam Sync is currently feasible with the existing network, its performance will be significantly enhanced by the Firehose Sync protocol.
eWASM
We have also been establishing some foundations for eWASM over the past few months. The py-wasm library now features a fully operational implementation of the WebAssembly interpreter, and we’ve initiated preliminary efforts to incorporate this into Py-EVM to create an EWASM-based execution environment for smart contracts.
EthPM
EthPM is now completely integrated into Web3.py v5. ERC 1319 has been revised to include several useful events and functions. A registry explorer was developed to provide a user interface for interacting with various EthPM Registries. A CLI tool is being developed for downloading EthPM packages to local storage.
Remix
We have finally launched Remix 0.8, which features a comprehensive UX redesign along with the incorporation of a more stable version of the remix plugin API. The documentation has seen enhancements and will continue to be refined with future updates. Explore the 0.8.0 release on Github, updated app, and our Medium article.
We are consistently updating https://remix-alpha.ethereum.org with the latest developments!
We have also observed the integration of remix-tests and remix-debug in Embark and EtherAtom, commenced the migration of the remix codebase to TypeScript, and introduced the long-awaited support for the new AST 😉 .
Beginning with the 0.8 release, we will dedicate more resources to creating and promoting educational content, initially for the Remix stack and subsequently for the broader Ethereum ecosystem.
We intend to launch patch versions of Remix more frequently now and to initiate a Remix website shortly.
The desktop version (operable offline) is anticipated to arrive soon (some progress has already been made with Grid integration, and we need to explore how we can combine efforts here).
We will persist in refining the remix-plugin API and enhancing the developer UX in the coming weeks. Now that the foundational layer is complete, we need to utilize decentralized storage for hosting plugins. This may take several months.
Besides this, we aim to continue producing tutorials, workshops, and undertake the necessary actions for onboarding newcomers.
Research [CBC]
Goals for 2019:
1. Generate liveness proofs for a range of synchrony assumptions, and for both probabilistic and deterministic liveness requirements.
2. Develop a sharding specification by Devcon 5, complete with a cross-shard messaging fork choice rule and (potentially) a load balancer.
Work Accomplished in January-June 2019:
1. Finality Inspector – Stanford Research Workshop, February 2019
- The Finality Inspector is an algorithm that determines the finality score of a specific block (the weight of validators that must equivocate for the given block to be reverted) by searching for a finality criterion within the message DAG. The algorithm is quite efficient — it operates in polynomial time relative to the total number of validators.
2. Documentation for Finality Inspector – ETHParis, March 2019
- We prepared an informative blog post that outlines the Finality Inspector and demonstrates an execution of the protocol (for binary consensus) and the level of finality on proposed values.
3. Liveness Strategies – May 2019
- To date, we have devised three liveness strategies for the CBC Casper family of protocols.
4. LMD GHOST fork choice algorithms – IC3 Boot Camp, June 2019
- We presented an efficient method for maintaining the prevailing LMD GHOST tip of the blockchain. Upon encountering a new block, it updates the LMD GHOST tip in O(V^2) time (without any additional data retained within blocks), or O(V*log(V)) time (if blocks keep a skip list of their ancestor blocks). This algorithm can also be utilized for executing the LMD GHOST portion of the Eth 2.0 fork choice.
Community Engagement from January-June 2019:
1. Vlad @ Stanford Blockchain Conference, February 2019
2. Vlad, Aditya @ ETHCC, March 2019
3. Vitalik, Aditya @ EDCON, April 2019
4. Vlad @ CryptoChicks, June 2019
Research [Plasma]
Delivering a complete implementation of Plasma offered valuable perspective that was crucial in developing generalized plasma. This realization stemmed from the understanding that our testnet was overly specialized & an acknowledgment that we needed upgrade capabilities. We wouldn’t have reached this conclusion if we hadn’t faced the hard truth that transitioning our current implementation to production would be heavily constrained. Instead, a relatively minor time investment in a redesign contributed to our future-proof design.
Announcements from the first half of the year include:
Current efforts prioritize Production Payments Plasma. In the coming months, we will be launching Generalized Plasma into production with a fully audited & scalable payments network. Next steps will involve addressing:
Plapp Plapp.
Research [Serenity]
tldr; it’s happening
Phase 0
The beacon chain has undergone several iterations and is generally stable as client groups implement it. Significant work is focused on testing and review as we approach the end of June’s Phase 0 specification freeze. A wide range of consensus test vectors are now being completed by client teams, and a fuzzing initiative is currently in progress, targeting the python spec and the go spec with plans to fuzz clients shortly. Runtime Verification has also initiated formal specifications of the beacon chain in K, along with the formal verification of the Vyper deposit contract.
There exist a handful of single-client testnets open for public involvement. In the upcoming months, we anticipate the emergence of both short-lived and then long-lasting multi-client public testnets.
Much of the effort for Phase 0 is now in the hands of the client teams to bring the beacon chain to production. The client to-do list encompasses: consensus evaluations, enhancements, effective aggregation, reliable p2p networks, state synchronization, validator UI/UX, security assessments, and visualization tools… Next time you get the opportunity, thank (or fund!) your local client team. They are the unsung champions in this process and merit far more support and recognition.
Phase 1
The Phase 1 specification on shard data chains is chiefly established and has experienced many simplifications over the last few months. Most of these simplifications are evident in the “custody game“, which lowers the complexity of computations and the difficulty of challenge games in instances of unavailable data. The custody game is now more amenable to multi-party computations to encourage decentralized staking collectives.
Recently, Phase 1 became executable and has been incorporated into the spec testing suite. This specification is set to be iterated upon, simplified, and prototyped in the approaching months.
Phase 2
Phase 2 is witnessing some intriguing research developments. There has been considerable effort in simplifying and abstracting the execution consensus layer through a new term known as “execution environments“. Execution environments present numerous possibilities regarding how Eth 2.0’s highly scalable data layer could be utilized. Notably, it could enable us to integrate Eth1 into Eth2, facilitating a more seamless transition for the community. Much of the research and discussions regarding Phase 2 are taking place at http://ethresear.ch/, so be sure to check it out!
Light clients
A light client specification based on Phase 1 is established and will be worked on iteratively in the forthcoming quarter. We hope to see several light client implementations being developed in Q3 or Q4 after the core beacon chain implementations stabilize.
Security [Security / Consensus Tests]
We have conducted extensive metering of the execution of opcodes within Geth, to provide foundational background and analysis for https://eips.ethereum.org/EIPS/eip-1884, which seeks to rebalance opcodes that might otherwise result in significant degradation of the Ethereum network.
The hive framework has been updated, and is once again operational on https://hivetests.ethstats.net/, and we have also re-launched a libfuzzer-based geth/parity differential fuzzer in a production setting. We plan to publicly unveil this fuzzer in the mid-term future.
Retesteth stability has been reinstated. We have also resolved bugs encountered while running StateTests and BlockchainTests via test* RPC interface on aleth. Retesteth can now be constructed on docker and run against any client that supports the test* RPC interface. Geth + retesteth support has now been enabled.
Special Projects
-
Collaborations with Microsoft to create a superior Integrated Development Environment, such as the Azure Blockchain Workbench.
-
Ether’s Shariah Compliance has been finalized. Details of the fatwa from Amanie Advisors are to be revealed. This initiative is expected to attract additional users and applications from the Islamic community. Cheers to enhancing financial inclusion and new markets.
-
Inaugurating the Ethereum OASIS Open Project to fortify and bring further structure to our standards procedure.
-
Initiated a new wiki: eth.wiki (still under development).
-
Collaborating with Santa Fe Institute to establish a cryptoeconomics research initiative. Recently, we sent Consensys’s Shruti Appiah to Santa Fe to speak on token economics.
-
Exploring avenues to enhance Ethereum’s presence in the enterprise sector. Therefore, we have been engaging more with the Ethereum Enterprise Alliance and Hyperledger. Thus far, the Ethereum Foundation has joined both associations and we are determining viable subsequent actions.
-
Continuing collaborative inquiries with:
-
A plethora of new merchandise on the Ethereum merchandise shop!
Solidity
The present focal points for Solidity advancement are outlined as follows:
-
refining the ABIEncoderV2 for a stable release,
-
expanding the coverage of the SMT checker module,
-
developing the Yul Optimizer and code generator transitioning from Solidity to Yul (basic contracts like an ERC20 token are currently operational)
-
code generation from Yul to eWASM under the assumption that all types are 64 bits wide
-
syntactic and semantic fuzz testing of diverse components
-
strategizing modifications for the imminent breaking release 0.6.0
In recent weeks, we have enabled access to the Yul compiler and optimizer via standard-json. Additionally, it is possible to reach the Solidity to Yul code generator using the –ir switch. For security purposes, you must compile the Yul code to bytecode manually once again. Please experiment with this, but be aware that both components are still experimental! Moreover, we are introducing further checks to the decoder section of the ABIEncoderV2 component to prevent invalid data from passing through the decoding phase.
Swarm
Swarm has experienced considerable stability enhancements, particularly fortifying network connectivity code and the integration of the new LocalStore with dependable garbage collection. Our devops framework and cluster provisioning have graduated, allowing testing of intricate network behaviors in a cluster of up to 1000 nodes.
Advancements in debugging, tracing, metrics, and network simulation testing are now complemented by comprehensive smoke tests. Such tests are conducted regularly on deployments and facilitate continuous performance monitoring. Since they closely reflect actual usage, they simulate user perception and will be utilized to validate implementation changes or identify regressions.
Release v0.4 recently introduced a much more reliable testnet. The 0.4 release now officially brings ACT (Swarm’s access control module) that allows users to regulate access to shared content or developers to provide authenticated protected areas/functions of dapps. It will also feature enhanced Swarm Feeds.
We are continuously restructuring our working methods, pursuing more principled engineering, and adhering to clean code principles.
Swarm has now established a product sub-team and consolidated our roadmap by adopting a more user-centric MVP approach to milestones.
Other recent updates can be found here: https://github.com/ethersphere/swarm/blob/master/CHANGELOG.md Finally, we held the Swarm Orange Summit in Madrid and it was extraordinarily successful and well received!
Web3.JS
The newly introduced framework (1.0.0-beta.38) of Web3.js is actively evolving and improves day by day. We have integrated the capability to pass a custom transaction signer, to configure the workflow for transaction confirmation, new modules (Admin, TxPool, Miner, Debug), and some new methods for the Eth module (getChainId, requestAccounts, getPendingTransactions). To ensure the success of the new architecture, we are permitting breaking changes by transitioning this endeavor to a 2.0-alpha version of Web3.js. Since version 1.0.0-beta.37 is broadly employed and to allow bug fixes for it, we have chosen to designate beta.37 as 1.0 stable. This offers us the opportunity to enable bug resolutions for the old framework of Web3.js while peacefully coexisting with the fresh and stimulating 2.0-alpha architecture.
By the Numbers:
📝 1486 commits
🔧 244 resolved issues
🏆 ~135000 lines of code contributed and ~165000 removed
The forthcoming steps for the Web3.js initiative will be detailed in the next announcement.
Whisper
We are enhancing compatibility with Parity’s variant of Whisper. Our objective is to create a fully compatible WASM version of this, to facilitate the application of Whisper in Dapps.
A few inconsistencies between the implementation and the specification were identified by Status and have been rectified.
The documentation endeavor is progressing well and is accessible in the geth pages repository. The protocol specifics are set to be transferred to the Devp2p spec repository.
ZKSnarks Research
We are advancing with zkrollup implementations and growing more confident in utilizing zkp (zero knowledge proofs) to scale arbitrary dapps for millions of users. Our aim is to present zkrollup as a proof of concept and subsequently begin to explore scaling various kinds of dapps through this method.
High-level languages are beginning to mature that allow developers to construct scalable dapps utilizing snarks with reduced ramp-up time. We are enthusiastic about these advancements and eager to see developer adoption.
In terms of privacy, we have developed a generic zcash-style circuit for use in coin mixing, voting, anonymous DAOs, anonymous social media, and other compelling privacy-focused areas. Our next deliverable in this direction will involve a mixer for ERC20 tokens. This opens the door for more exciting privacy initiatives such as anonymous journalism and voting.
ZoKrates
Throughout the past months, we focused on achieving three primary objectives: to enhance ZoKrates’ efficiency, augment its capabilities, and simplify its usage even further.
We introduced support for Elliptic Curve Cryptography within ZoKrates programs and provided primitives leveraging EC cryptography, such as EdDSA verification, to developers. Alongside other beneficial building blocks, these are now included as part of the ZoKrates standard library. This is complemented by a new Python library known as pycrypto, which incorporates application code that simplifies interaction with provable ZoKrates programs.
To fully leverage these building blocks, we have enhanced optimizations for the ZoKrates compiler and initiated the refactoring of the module system to better facilitate composition.
We have also formally specified the ZoKrates DSL grammar and are actively working on a more efficient parser implementation based on that specification.
As a step toward our goal of a Rust-only codebase, we have included support for Bellman which enabled native builds for Mac OS X along with efficiency improvements.
Lastly, we have expanded our documentation (e.g., tutorial on how to prove pre-images of hashes) and released a blog post discussing the challenges of employing zkSNARKs in dApps. For developer training, we conducted a workshop at the 2nd ZKProof Workshop held in Berkeley. Additional workshops are scheduled to take place in London and Split in June.
