Innovative Insights: A Progress Report on EF-Backed Research & Development Teams

Comrades,

Since the previous EF-Supported Teams update, advancements have been observed throughout. From enhanced network conditions to the upcoming Istanbul launch and the development of Eth1.x and Eth2, all critical areas fundamental to the functionality and longevity of Ethereum are progressing.

This edition emphasizes teams and initiatives from the Foundation and the broader Ethereum ecosystem that are striving to expand and enhance Ethereum as a whole. In this issue, we will discuss updates from several teams featured in the prior report, fully endorsed projects that are integral components of the Ethereum ecosystem such as Eth2.0 Research, Geth, and Solidity, along with additional ecosystem initiatives.

Have fun!

Aleth / C++ Ethereum

Written by Andrei Maiboroda

The Aleth group was among those client teams developing the Istanbul upgrade for the Eth1.x chain, and Aleth 1.7.2 has been released with complete support for Istanbul.

EVM & other consensus

Key achievements for the evmone project:

Following the initial launch of this experimental rapid EVM implementation, we concentrated on extracting even greater performance from it. The 0.2.0 version is approximately 66% quicker than its predecessor. Subsequently, the 0.3.0 release extended evmone’s compatibility with the Istanbul specifications. For those intrigued by the concepts that evmone explores and for further details on optimizing EVM, please refer to the slides from the Optimization techniques for EVM implementations presentation at Devcon5, as well as the Efficient gas calculation algorithm for EVM article.

The EVMC project (the cross-language API for EVM implementations) has undergone necessary updates incorporating support for Istanbul. All of this is included in the EVMC 7.0.0 release.

Several improvements have been made in the aleth-interpreter to eliminate unnecessary state access in the execution of certain opcodes. These deficiencies were identified thanks to the excellent EVM test suite provided by evmone project.

The aleth-interpreter has also transitioned from utilizing boost::multiprecision to the intx library. This signifies a movement towards delivering the aleth-interpreter without a boost dependency, and it has also permitted us to conduct intriguing benchmarks to assess how inadequate the boost implementation of 256-bit integers was for our objectives.

Post-Istanbul, we chose to incorporate several proposed EIPs for the forthcoming hard fork (Berlin): EIP-1380 Reduced gas expenses for self-calls and EIP-2046 Reduced gas expenses for static calls made to pre-compiles. These implementations can now be activated in the testeth tool, details below.

Networking

We have integrated an optimization that has long been utilized by other mainnet clients: immediately disseminating new blocks to peers following the PoW check rather than awaiting full validation and execution. Furthermore, we established a maximum limit on the number of previously discarded transactions retained by the transaction pool (now set to 1024).

The client version reported during devp2p handshake was rectified, thus enabling Aleth’s version to be accurately displayed on ethernodes.

RPC

A series of corrections have been implemented to better align with the input/output formats utilized in the RPC interfaces of other clients. Numerous methods have experienced a substantial performance enhancement due to a fix that removed unnecessary transaction re-executions. This may be evident in scenarios involving frequent RPC requests, such as when utilizing retesteth with aleth.

Database

Reconstructing the indices from the existing blocks database has been corrected and optimized, allowing for improved optimization and modification of the index database structure in the future.

Testeth tool

The structure of the consensus tests folder has been reorganized by the testing team, and testeth now accommodates it – all tests addressing fork rules prior to Istanbul are categorized in the LegacyTests suite.

State tests can now be generated and executed using a string format like “ForkName+EIP_number” instead of a traditional fork name in the expect section. This facilitates anyone intending to prototype new EIPs in aleth to create tests for them before the EIP is validated for the fork – this is the fundamental concept behind the EIP-centric forking process, which is currently being embraced by the All Core Devs community. As an illustration of this mechanism, the two new EIPs mentioned earlier (EIP-2046 and EIP-1380) can be activated in testeth, and we’ve produced a few state tests to demonstrate this functionality.

We have also rectified and optimized the functionality of testeth to execute any custom test file (beyond the established consensus test structure) and enhanced its output to be more aligned with the EVM tool of go-ethereum. This enabled us to incorporate testeth into goevmlab project, where aleth’s EVM implementation is now partaking in a cross-fuzzing initiative alongside three other prominent clients’ EVMs.

Among other advancements:

Ecosystem Support Program

Written by the ESP Team

Taiwan-Specific Grants

We have recently bestowed a series of five grants ranging from $2,000-$5,000 at Crosslink Taipei. This represents the latest in a series of locality-focused waves aimed at highlighting the contributions of communities globally.

Increasing Non-Financial Support

We are persistently broadening our understanding of “support” for initiatives where a traditional grant may not be suitable. Some of the non-financial support we’ve offered includes rounds of feedback with expert advisors, linking teams working on similar projects, AWS credits, invitations to events, and other forms of assistance.

Enhancements to the Website

Our newly revamped website https://Ecosystem.Support/ is evolving! We began modestly with a FAQ section and modifications to the homepage – we plan to follow this up with a grants showcase and a dedicated blog for regular updates.

We aim to ensure valuable skills are utilized, hence we’ve overhauled our inquiry forms to be somewhat more open-ended, featuring a designated pathway for individuals keen on contributing to the ecosystem but uncertain about their role. Feel free to explore and apply!

Ewasm

Authored by Alex Beregszaszi and Paul Dworzanski

Since the previous update, the focus of the Ewasm team has transitioned towards research on Eth 2.0, collaborating closely with other teams.

As the launch of Eth 2.0 phase 0 approaches, the development of the phase 2 execution layer is actively ongoing, concurrently with the progression of phases 0 and 1. Multiple proposals have emerged concerning the architecture of phase 2. The Ewasm team has been working on refining designs through prototypes and benchmarks, building upon a minimal base in Scout.

Scout

The Scout specification serves as a minimal interface for EEs (Execution Environments). This simplified interface is sufficient to prototype stateless EEs, which are necessary for validating the stateless model and informing the design of Ewasm and phase 2.

Scout comprises three implementations:

• scout in Rust, crafted for rapid prototyping and collaboration (it employs a Wasm interpreter with profiling capabilities),

• scout.ts in Typescript for swift prototyping and browser compatibility,

• and ScoutOne in C++, optimized for performance and production use, to be embeddable by Eth 2.0 clients.

Execution Environments

In contrast to the Eth 1 stateful model that suffers from known scaling challenges, Eth 2 is suggested to be stateless, where state is preserved off-chain, with only a hash representing the state remaining on-chain, alongside witnesses being included in transactions.

The stateless model brings forth new challenges. Prototypes and assessments are essential to confirm its feasibility.

The Ewasm team has devoted significant effort to prototyping and measuring stateless EEs, which we categorize as follows:

1. An EE that must align with Eth 1 data structures and execution.

   • SMPT (Stateless Merkle Patricia Trie) utilizing RLP to serialize the witness and transaction data, employing the Eth1 signature scheme.

   • An EVM implementation in Assemblyscript.

   • biturbo (formerly known as TurboToken), using Multiproof to more effectively encode witness data and also endorsing EVM execution.

2. Architectures that do not require backward compatibility.

   • KMM (Katajainen Makinen Merkle) Token EE that is enhanced for witness size and execution duration.

   • Groth16 verifier implementation to facilitate zk-SNARKs within Eth 2.

   • STARK verifier implementation.

Significantly, the ongoing investigation into the relationship between Eth 1 and Eth 2 chains is noteworthy. To assist in the evaluation of the “switchover” proposal, which involves integrating Eth 1 into an EE on Eth 2, the Eth 1 EEs previously mentioned were prototyped. The team is also actively analyzing proposals that link the two networks and their consequences on EE architecture.

Our primary objective is to ensure a positive developer experience for both current and prospective DApps.

This EE initiative has been influencing the design of Scout and Eth 2.

Rapid Cryptography

For Ewasm to thrive, we need to perform expensive cryptographic operations on-chain. Fortunately, crypto frequently encounters runtime bottlenecks through bigint arithmetic. Initially, we benchmarked various implementations of cryptographic primitives to pinpoint bottlenecks. Subsequently, we created a rapid native bigint API to mitigate these issues. Finally, we enhanced the highly optimized websnark library, in collaboration with its developers, to utilize this bigint API.

The outcomes are promising: with the bigint API integrated in interpreters, we are nearing native speeds for elliptic curve operations (!), which serve as fundamental components for various cryptographic tasks. We can now perform pairings at speeds close to native efficiency. This represents the most significant recent achievement of Ewasm.

This effort has enabled the EE prototypes mentioned earlier to function within the performance limits of Eth 2.

Velocity, Metering, Size

Ewasm encompasses numerous other endeavors concerning speed, metering (reducing metering runtime overhead and accurately approximating runtime), and bytecode size. From optimizing the Wasm engine to conducting metering analysis and bytecode transformations, the Ewasm team is diligently crafting the ideal execution system.

Tools

We are consistently developing tooling for Ewasm.

Bindings for Eth 2 and bigint APIs are available for Assemblyscript and Rust.

In cases where Wasm bytecode needs enhancements, a versatile tool called chisel has been developed to facilitate various transformations (such as reducing bytecode size and modifying imports/exports) necessary for both Ewasm and non-Ewasm applications.

Formal Validation

Written by Leo Alt

The newly established Formal Verification team is engaged in creating tools, assisting other Foundation teams with formal models and proofs, and collaborating with members of the Ethereum FV community.

Recently, efforts have primarily concentrated on:

• Solidity’s SMTChecker, an unbounded model checking tool for Solidity smart contracts.

• KYul, Yul semantics represented in K. KYul further aids the Solidity compiler by generating bisimulation proofs for both optimized and non-optimized Yul code.

• Spearheading the development of a smart contract specification language with support from various FV community members. This specification language is aimed at delineating contract properties and aspires to be straightforward and compatible with multiple FV tools.

• Assisting the Eth2 research team and Runtime Verification in the verification efforts for the Beacon Chain.

• Managing HEVM (together with Dapphub), a fully compliant Haskell EVM implementation.

• Supporting the Testing team in expanding the coverage of Ethereum tests by addressing the gaps identified in various EVM implementations.

Geth

Written by Péter Szilágyi

With the release of v1.9.0 in July, the Geth team has primarily focused on refining the existing code base; addressing any issues uncovered; and preparing the client for the Istanbul hard fork. In addition to these maintenance modifications – amounting to 8 releases – the team has also been laying the foundation for new developments to come.

We have amassed a significant collection of 5 EIPs concerning ENRs (Ethereum Node Records) designed for networking and peer discovery. Utilizing these, Geth nodes have gradually been upgraded to broadcast considerably more information about themselves than prior protocols permitted (e.g., IPv4 and IPv6 addresses, Ethereum network affiliation, configured and applied forks, light server capabilities, etc.). The fork ID work has already been implemented atop the eth protocol, enabling Geth nodes to neatly partition the network between incompatible devices. These records are also indexed by a new discovery service accessible over DNS (not yet finalized), complicating eclipse attacks substantially and facilitating Ethereum functioning in environments where UDP is restricted (DNS over HTTPS).

In terms of performance, we are advancing on multiple fronts. On one hand, we strive to lessen the burden on the network by enabling smarter propagation of transactions (and quite possibly blocks); meanwhile, we are developing a state snapshotter that can follow…the active chain serves as an acceleration framework for EVM execution as well as state synchronization. In the interim, we are developing various configuration avenues for Geth that will enable users to eliminate unnecessary portions of the database (without affecting network wellness), thereby conserving valuable SSD space. All these seem like encouraging trajectories, and we will disclose some metrics shortly.

A considerable effort has been dedicated to the light client infrastructure, allowing server operators to assign and oversee client priorities and resource allocations through the RPC API. Although long-term, light client incentivization is intended to function through the peer-to-peer protocol, the existing feature set already enables an operator to gather payments independently from Geth and align them with Geth’s internal bookkeeping. This should instantly empower anyone to establish a paid light server service (though it’s important to note that this is still in the prototype stage). Efforts are ongoing toward the complete P2P payment layer.

Javascript Team

Contributors: Samuel Furter, Holger Drewes, Marc Garreau, Everton Fraga, Richard Moore

You may have already been informed, as it was no secret, but we will take this opportunity of the EF Dev Report to formally declare: the EF has assembled a formidable new JavaScript team which consolidates the following well-known projects under one umbrella:

Members from these varied teams have commenced collaborating across project lines and to address interoperability challenges and we anticipate robust synergies to develop in the medium-term future. This initial quarter has been utilized for the new team to cultivate unity, foster trust, and establish essential organizational frameworks. Prepare to learn more in 2020 when we will unveil and implement a cohesive strategy and vision to amplify our influence supporting the Ethereum JavaScript/TypeScript developer ecosystem (you are sincerely invited to engage in the discussion). This endeavor will extend beyond the scope of the previous individual projects.

However, the current initiatives will not be overlooked. We are very much cognizant of the need to nurture and advance tools that are widely utilized within the community. Thus, here are the respective updates to illuminate what has transpired within these projects during the last quarter.

Web3.js

We have rolled out several patches for Web3.js since the previous EF blog announcement and transitioned to semantic versioning. These adjustments included TypeScript support, enhanced transaction signing features, added transaction confirmation workflow properties, introduced the long-awaited JSON-RPC method getChainId, incorporated the connected event into the subscriptions, expanded the provider interface with the method supportsSubscription and additional utility functions to utilize bloom filters.

More specifics about the new features and enhancements can be found in our release notifications on GitHub.

At present, we are concentrating on minimizing the bundle size, enhancing performance, introducing reconnection for the WebsocketProvider, and refining the TypeScript developer experience.

In addition to all of these exciting enhancements, we’ve been fortunate to welcome Chris to the EF-JS Team. Chris is currently supporting Web3.js development but will also be engaged in all other EF-JS packages.

Ethers.js

We have been preparing v5 for public use, and adoption has been consistently increasing. Many thanks to everyone experimenting with it and reporting issues.

The emphasis on v5 has been on enhancing extensibility and refining the API for framework developers, including a new framework, ethers-app, specifically aimed at dapp developers.

With the decrease in new issues, we are anticipating the launch of v5 for production shortly, with only a few minor modifications in the pipeline and a couple of nodes remaining in the completely overhauled documentation.

EthereumJS

Noteworthy developments on the EthereumJS front include the releases of various components aimed at Istanbul support: the VM has received a significant v4.1.0 update in September and we are currently resolving the final bugs to ensure the VM’s full compliance with the official testing suite. Other relevant updates in the context of Istanbul include releases of the transaction, block, and common (hardfork and network logic) libraries.

Grid

Since the last EF blog update, numerous significant enhancements have been introduced to Ethereum Grid. The application now resides in your operating system’s taskbar, providing an intuitive interface to download, configure, and execute Ethereum clients and tools. The plugin system continues to undergo refinements with each new integration,but similarly thrilling are Grid Applications. Applications have been developed to test RPC functions, retrieve block information through Geth’s GraphQL implementation, authorize transactions with Clef, and much more. The team has been engaged in creating guides about the capabilities offered by Grid, which can be accessed on the Medium publication.

Python Ecosystem [PyEVM/Trinity/Web3.py/Vyper]

Written by Piper Merriam

Web3.py

Recent efforts have been directed towards enhancing stability and updating documentation. The primary goal currently is to introduce asynchronous support for the library.

Trinity

The Trinity client is progressing toward a beta launch that will feature the newly created “Beam Sync” (https://medium.com/@jason.carver/intro-to-beam-sync-a0fd168be14a). We are also concentrating on teamwork with the larger community of client developers to address significant challenges such as state bloat and determining a transition strategy for Eth 1.x into the 2.0 ecosystem.

EthPM

Our ongoing efforts are concentrated on ecosystem tools. The ethpm-cli continues to enhance, facilitating the installation of packages from diverse sources along with package creation and distribution.

Remix

Contributed by Yann Levreau

With regards to Remix, we have numerous updates to present. In recent months, our group has been engaged in:

• Enhancing the Remix Plugin and collaborating with communities in various capacities – @GrandSchtroumpf.

• Developing a WebSocket Plugin for Edi Sinovcic’s GitHub integration.

• Assisting Quorum in the integration of their Remix plugins.

• Collaborating with Waffle (Ethworks) on their plugins.

• Working with the VSCode Ethereum group to incorporate the plugin engine as a VSCode extension.

• Transitioning to fully decentralized loading of plugin resources (currently using IPFS).

• Remix libraries: @Aniket has recently joined the team to enhance, maintain, and advocate for the remix libraries repository https://github.com/ethereum/remix. This involves critical contributions to remix-debug (transaction debugging), remix-tests, remix-solidity, remix-analyzer (new module added: warning for ether transfers in loops)

• Remix libraries: completing remix-simulator and increasing tests on remix-debug @iurimatias

• Enhancing the IDE’s file explorer to support folders and conventional features. Collaborating with Ethworks on new themes. Employing the Monaco editor. Adjusting compiler version according to the Solidity pragma – @Lianahus @ryestew @Aniket @GrandSchtroumpf

• We announced Remix desktop here https://medium.com/remix-ide/remix-desktop-8c1e9e946ee1, and we are currently finalizing it. Stay tuned for a release very soon! – @yann300 @lianahus

• Remix Workshop is a plugin operating within the Remix plugin API.

It enables the creation of tutorials, registration of tutorials, and provides an avenue for students and learners to actively engage with tutorials. The range of tutorials being developed is extensive (Solidity, Vyper, general Ethereum concepts, etc…). It really depends on the creators of the tutorials! The initial proof of concept was successful and we are progressing towards launching a first version with input and feedback from various teams in the community. –  @GrandSchtroumpf @ryestew

• Workshops and outreach beyond the community: one part of our mission is also to contribute to educational initiatives in various manners. We anticipate this will gain more significance in 2020. – @ryestew @Aniket @GrandSchtroumpf @team

• Organizing workshops / meetups (ESCE, Consensys, Devcon, Dappcon).

• Engaging with organizations and individuals from beyond the community. Not necessarily to onboard them in a technical sense, but more to provide an initial understanding of blockchain, Ethereum, and beyond.

• Practically developing a tool for that (see Remix workshop)

Research [CBC]

Contributed by Aditya Asgaonkar

For the Casper CBC project team, our recent focus has been on:

1. Defining the minimal CBC Casper protocol along with validator strategies for liveness within a consolidated framework (termed Valid Labeled State transition & Message production system, VLSM). A public document is currently in progress and will be shared shortly.

2. Formal verification of VLSM

3. Utilizing CBC Casper components to enhance the Eth2.0 design, such as https://ethresear.ch/t/cross-shard-messaging-system/6201

4. Community engagement initiatives like this AMA: https://www.reddit.com/r/ethereum/comments/dsiz9j/ama_we_are_the_cbc_casper_research_team/

Keep an eye out for more updates shortly!

Research [Plasma]

Written by Plasma Group

Since May, we have been diligently engaged in advancing scaling technology. Four distinct teams within the ecosystem are developing the Generalized Plasma specification for various blockchains, including OmiseGO, Matic, Cryptoeconomics Lab, and Plasm. While many of our colleagues are focused on production payments, we have started exploring somewhat less examined domains for scaling, such as application development and overall composability. Progress in this area includes the Optimistic Virtual Machine – a universal dispute language for layer 2 constructions, along with our demonstration with Uniswap for Devcon5 – a scalable payments and exchange game available at Unipig Exchange. This game is built on an optimistic rollup chain – a concept that originated from discussions with Barry Whitehat & Vitalik during the Scaling Ethereum conference in early June.

As we conclude the year, we are gearing up to release a paper for the OVM, along with preparing more comprehensive documentation for Optimistic Rollup. Currently, those interested in learning about it can find a description on our blog detailing how to construct it for arbitrary smart contracts, accompanied by some preliminary documentation illustrating the transition from plasma to optimistic rollup at:

Our Forum: https://plasma.build/t/rollup-plasma-for-mass-exits-complex-disputes/90/1

On Github: https://gist.github.com/karlfloersch/1bf6ab7871f41e3a5a921c0a007ad5c6

Plasma Call: https://youtu.be/5RpYoU6xD_M?t=1136

Research [Serenity / Eth2]

Written by EF Team

After Devcon5, Danny and the Eth2 research team initiated a weekly series of quick Eth2 updates, and recently a series centered around validating in Eth2. For the latest information and developments as we approach the commencement of Phase 0, refer to the links below, and remain tuned to the EF Blog!

Overall, advancements are ongoing towards the Phase 0 testnets and mainnet launch. Phase 1 specifications and prototypes are progressing simultaneously, while Phase 2 continues active and productive R&D efforts.

Validated: Staking on Eth2 #0 – 2019-11-27

Eth2 Quick Update #4 – 2019-11-21

Eth2 Quick Update #3 – 2019-11-08

Eth2 Quick Update #2 – 2019-10-31

Eth2 Quick Update #1 – 2019-10-23

Security [Security / Consensus Tests]

Written by Martin Holst Swende

In terms of security, there has been considerable activity concerning the Istanbul hard-fork. The previous python-based fuzzer (Evmlab) has been recreated in Go, and has been utilized to produce EIP-targeted fuzzers. These fuzzers have been employed to create test cases (exposing implementation errors in both Besu and Nethermind) and have been utilized to execute millions of test scenarios contrasting Geth and Parity – and as of late November, we also had Aleth and Nethermind VMs operating on the same fuzzer framework. Thus, we are currently conducting differential fuzzing with four EVMs!

In addition, we are also executing libfuzzer-based fuzzers on Geth and Parity, a task spearheaded by @cryptomental.

Some time ago, it was revealed on the Bounty page that $15K USD was allocated towards security audits of EIPs. Out of this, we have awarded “`html$5K each to Neville Gretch contract-library.com and Hubert Ritzdorf (Chainsecurity) for their contribution in assessing the security ramifications of EIP-1884.

Numerous additional bounties have been given, the majority of which will be disclosed publicly shortly.

Solidity

Written by Christian Reitwiessner

The Solidity programming language and compiler persist in stabilizing and incorporating features requested by the community. These encompass capabilities to produce Solidity code for utilization in various adaptable formats, along with stability and security enhancements. The team is focused on a forthcoming 0.6.0 release, along with updates to the 0.5.x branch.

Webassembly

Solidity offers experimental preview output of webassembly code via the –ewasm switch. We have broadened most of the Yul optimizer stages to accommodate eWasm code, are developing the glue code that translates EVM-style Yul to eWasm-style Yul, and possess a functional prototype for eWasm binary code generation necessary to deploy contracts.

Solidity 0.6.0

We are nearing completion with the implementation of breaking changes and aspire to release Solidity 0.6.0 later this year. Several of the new modifications consist of:

• Explicit “virtual” and “override” keywords are required for overriding functions.

• ABIEncoderV2 is no longer classified as experimental.

• A fallback function has been divided into a “receive ether” function and an actual “fallback” function.

• Abstract contracts must (and can be) designated as “abstract”.

• Structs and enums can now be defined at the file level.

• Setting the length of a storage array arbitrarily is disallowed.

• The push() function is supported to add new default-initialized elements to a dynamic storage array.

• An “leave” statement has been introduced to Yul / Inline Assembly to exit from the current function.

• Support for multiple return values in NatSpec has been added.

• Improved formatting for error messages in the command line.

• Metadata hash defaults to IPFS, with the option to switch to Swarm or remove it.

• Removal of “revert reason strings” from the binary is now permitted.

SMT Checker

The SMTChecker has acquired a new model-checking engine that accommodates loops and enables the verification of assertions considering an unbounded number of transactions. For further details about the modifications, click here: https://medium.com/@leonardoalt/smtchecker-toward-completeness-1a99c02e0133.

We are presently engaged in facilitating function calls within the new engine, which
“`will facilitate multi-contract evaluation even when the invoked code remains undisclosed.

Yul Optimizer

The Yul optimizer is now capable of considering the side-effect-free nature of user-defined functions, thus allowing optimization across such function invocations. It can eliminate unnecessary sload and mload calls and take into account conditional local values of variables.

Compiler Interface:

• If standard-json is utilized, the compiler generates bytecode exclusively for the chosen contract or halts after parsing and analysis if bytecode is not requested.

• The –error-recovery option can be employed to recuperate from most parser issues, enabling the creation of an AST even for invalid input.

In addition to the modifications mentioned earlier, we have integrated numerous minor bug fixes and features.

State Channel Research

Composed by Liam Horne

In recent months, the Ethereum state channels research and development community has made significant strides.

Most thrillingly, state channels are operational on the mainnet. Connext, a micropayment platform leveraging our work, has been active in production since September 2019. The scalability and user experience improvements offered by state channels are now practical benefits for users. Go try it out!

Behind the scenes, research and development have been industrious over the past six months. This summer, the two main state channel research teams – Counterfactual and Magmo – merged their efforts into a single project and protocol called “StateChannels”. This collaboration has hastened our pace and simplified the experience for Ethereum’s application developers, who no longer need to consider which channel standards they intend to endorse.

More specifically, in recent months we have:

What’s next for state channels?

• We are developing two demonstration applications, entirely built on the Client API, running in the browser through our reference hub.

• Onboarding new initiatives, attracting more contributors, and ensuring state channels remain exceptionally developer-friendly.

ZoKrates

Written by Jacob Eberhardt

We are pleased to announce a major update regarding progress towards transforming ZoKrates into a robust yet intuitive toolkit for zkSNARKs on Ethereum.

Great news for ZoKrates developers: In-browser development of ZoKrates code is now available in Remix. You can locate the ZoKrates plugin through the plugin manager in the left tab.

A long-awaited feature has been a more sophisticated type system, and with our recent release, we delivered just that: ZoKrates now accommodates complex user-defined types in the form of structs and multi-dimensional arrays. To ensure seamless interaction with ZoKrates programs utilizing these new types externally, we have introduced a JSON-ABI, facilitating easy programmatic access.

To enhance the readability of ZoKrates, we restructured our module system and modified the file extensions of ZoKrates source code files to .zok. Additionally, the internal parser re-implementation based on a formal DSL grammar —previously mentioned in our last update— has been successfully completed.

Finally, further optimizations have been introduced in compiled programs to decrease both execution and proof generation duration. We presented these findings along with applications using ZoKrates at Devcon V in Osaka to educate the community!