While everyone gazes in wonder on December 1st, 12pm UTC expecting the Eth 2.0 Beaconchain genesis, the JavaScript team has been diligently crafting our own small genesis release in the background. Although we are still well-versed with the good old Eth 1.0 chain, we are equally thrilled about this. 😀
Some contextual information: the EthereumJS ecosystem surrounding the VM comprises a highly modular selection of libraries (vm, blockchain, merkle-patricia-tree, tx,…), with each hosting its specific functionality. While this is beneficial for the user, it has proven less than ideal for development as it often becomes necessary to implement modifications across multiple libraries simultaneously, which can be difficult and time-consuming to manage while maintaining consistency when the libraries are stored in separate repositories. Therefore, earlier this year we resolved to overhaul our setup and merge the VM-related libraries into a single monorepo. This single repository allows for targeting changes across various libraries within a single pull request and enables execution of all different library test suites concurrently to guarantee consistency. Simultaneously, the advantages of having multiple packages released individually are preserved.
Since transitioning to the monorepo, our development output has surged. 😋 We uncovered numerous enhancements we wished to implement, leading to an unceasing flow of improvements, particularly as one change frequently triggered another, all of which now seemed “so evident to execute”. 😜
So we innovated. And innovated. And innovated. Essentially throughout the entire year. This is the primary reason you’ve heard relatively little from us during the previous months; we were immensely occupied with all these tasks.
Even though we sometimes questioned if we would ever manage to pull everything together again (consult our extensive release notes to grasp what I imply), today I am genuinely proud to finally proclaim: we accomplished it. 😋 A huge thank you to an incredible team for all the wonderful and committed efforts on this. 🎉
This signifies not one but six significant releases on our core libraries with our virtual machine taking center stage:
In this article, we won’t delve deeply into the technical specifics and will instead provide a high-level overview. For a more exhaustive picture, refer to the release notes linked above; we genuinely prioritized making these concise and comprehensible while providing a solid overview of all pertinent (breaking) changes.
Perhaps just one crucial note: we adopted a new naming convention throughout these releases, and you must utilize the new names to access the latest versions. The previous ethereumjs-vm package, for instance, now installs as follows:
npm install @ethereumjs/vm
Ok. What is actually included? Let’s take a brief glance.
All Hardforks
EthereumJS VM v5 now accommodates all hardforks dating back to genesis. This marks a significant chapter in the history of JavaScript Ethereum, and we anticipate that this will facilitate numerous potentially thrilling new applications. We have our own, and more on this shortly.
A VM on a designated HF can be initiated using:
import VM from '@ethereumjs/vm'; import Common from '@ethereumjs/common'; const common = new Common({ chain: 'mainnet', hardfork```html : 'spuriousDragon' }); const vm = new VM({ common });
A VM Focused on EIPs
Although hardforks are excellent for grouping a series of consensus alterations, a hardfork-centric VM has proven to lack sufficient adaptability for a forward-thinking progression where it remains undecided for an extended period which EIPs will be incorporated into a forthcoming hardfork (the Berlin hardfork currently stands as the most significant illustration of this).
With the latest VM update, the internal structural modularization layer has undergone significant revisions. This enables EIPs to be established as native entities within the VM. A VM tailored with a specific collection of EIPs can be initialized as demonstrated below:
import Common from '@ethereumjs/common'; import VM from '@ethereumjs/vm'; const common = new Common({ chain: 'mainnet', eips: [2537] }); const vm = new VM({ common });
Initially, we are endorsing the following new EIPs (primarily associated with the Berlin hardfork) as part of the VM v5 launch:
TypeScript
In this EthereumJS release cycle, we can assertively confirm that we have comprehensively advanced our libraries to a contemporary technology framework. A significant component of this: with the recent updates, we are nearing the completion of our long-anticipated TypeScript transition, with all our primary libraries and internal dependencies now developed in TypeScript.
Just a glimpse at what renders TypeScript so exceptional and contributes to the enhancement of our libraries’ durability and security: TypeScript functions as a superset of JavaScript and informs developers about the data types for every variable and object utilized in the code. Is the variable named address a string or a binary Buffer object? Although JavaScript provides no explicit indications regarding this – greatly escalating the chances of subsequent developer errors – TypeScript guarantees clarity in this respect.
Moreover, it becomes significantly more enjoyable to collaborate on our libraries directly or utilize them within third-party projects since, as a developer, you can effortlessly obtain insights like this in the IDE throughout the entire codebase:
Your development environment, equipped with appropriate TypeScript typing, now understands that a blockchain variable is an @ethereumjs/blockchain object (please hold back your comments, Go and Rust developers 😅 ) and not just “something”.
“`So our custom code enhances the readability of your (TypeScript) code tremendously by utilizing the new library versions.
Promises
If you are not particularly familiar with JavaScript, you may bypass this section; however, if you are a JavaScript developer, you will probably breathe a sigh of relief upon hearing this news, so we will at least give it a brief mention:
Another transition completed, with all library APIs now operating with JavaScript Promises. Thus, there will be no more callbacks throughout our entire stack.
Usage of the library shifts from:
blockchain.getBlock(blockId, block => { console.log(block); );
Example of the new API:
const block = await blockchain.getBlock(blockId); console.log(block);
The slight indentation in the initial example may not seem significant at first glance. However, with multiple old-style nested calls, the code can become increasingly convoluted and unreadable. Just search “callback hell” if you are curious about how that can manifest. 🙂 Promises facilitate writing code that is substantially more comprehensible.
Library Refactorings
It can sometimes be challenging to grasp the necessity of an engine overhaul while the vehicle is still functional, yet it ultimately becomes essential if you aim to safely navigate the next 10,000 miles. Similarly, refactoring in software often mirrors this scenario. 😀 In this series of releases, we have revamped the core of several of our most essential libraries, and our block, our tx, and partially our blockchain library has undergone a significant rewrite.
It should now be considerably easier to interact with these libraries, which should be well-equipped to lay down a firm and secure foundation within the Ethereum JavaScript ecosystem for the upcoming years.
Outlook
We hope you appreciate our latest releases. This article merely offers a glimpse of the most critical updates, with comprehensive details available in the release notes linked at the beginning of this post. We welcome your feedback on our Discord server or our new @EFJavaScript Twitter account.
For us, these releases create sturdy ground for shifting towards a more future-oriented development cycle, and we are enthusiastically anticipating this coming to fruition. With the VM fully equipped with all hard forks, it now becomes feasible to integrate the VM into our revamped EthereumJS Client project. We won’t be joining the mainnet with this client anytime soon. However, we will nonetheless be able to contribute toward enhancing client diversity. The new client, in its initial stages, will enable us to participate in development testnets such as Yolo v2 (and beyond) and actively aid in detecting and safeguarding against consensus bugs across clients. We will also be able to engage more actively in future protocol research and potentially participate in upcoming research implementations. More information will follow once we have a functional version of our client ready (targeting full sync on Yolo v2), which we anticipate will be early next year.
For now, we wish everyone a reflective conclusion to the year, paired with an exhilarating beacon chain launch day (week)! 🚀
The EF JavaScript Team
