While everyone is watching in amazement on December 1st at 12:00 UTC waiting for the genesis of Eth 2.0 Beaconchain, we on the JavaScript team have been quietly preparing our own little genesis version in the shadows. Being very close to the good old Eth 1.0 chain, we are nevertheless very excited about this as well. 😀
A background story: the EthereumJS ecosystem around Virtual machine consists of a very modular set of libraries (vm, blockchain, merkle-patricia-tree, tx,…), each encapsulating its own dedicated set of features. While this is great for the user, it is not great for development, as it often becomes necessary to make changes to multiple libraries at once, which is difficult and time-consuming to act in a way that preserve the consistency of libraries. in different repositories. Earlier this year we decided to update our setup and combine the VM related libraries into a single monorepo. This is a single repository where it is possible to target changes to multiple libraries within a single pull request and run all the different library test suites together to ensure consistency. At the same time, the benefits of having multiple packages released individually remain.
Since switching to monorepo our development activity has literally exploded. 😋 We discovered so many things we wanted to improve that we just couldn’t stop, especially since one change often triggered another that was now “so obvious to do.” 😜
So we developed. And developed. And developed. Basically, all year round. This is the main reason why you have heard relatively little from us over the past few months, we have been so busy with all this.
While at the end of the process we sometimes wondered if we’d ever put things back together (see our detailed release notes to get an idea of what I mean), I’m really proud today of finally be able to announce: we I did it. 😋 Thanks to an incredible team for all the wonderful and dedicated work on this. 🎉
This is not one but six major releases on our main libraries with our virtual machine in mind:
In this article, we won’t go into much technical detail and will instead give a high-level overview. For a more complete picture, check out the release notes linked above, we’ve really taken care to make them understandable and readable and give a good overview of all relevant (breaking) changes.
Perhaps just one important note: we moved to a new naming scheme with these versions and you must use the new names to get the new versions. The old ethereumjs-vm The package, for example, now installs as follows:
npm install @ethereumjs/vm
All right. What’s really in there? Let’s take a quick look.
All hardforks
EthereumJS virtual machine v5 now supports all hardforks since genesis. This is an introduction to the history of Ethereum JavaScript and we hope it will pave the way for various new and potentially exciting use cases. We have ours, more on that below.
A VM on a specific HF can be started with:
import VM from '@ethereumjs/vm'; import Common from '@ethereumjs/common'; const common = new Common({ chain: 'mainnet', hardfork: 'spuriousDragon' }); const vm = new VM({ common });
A VM centered on EIP
While hardforks are great for bringing together a set of agreed-upon changes, a hardfork-centric VM has proven not to be flexible enough to allow for future-oriented development where it isn’t finalized for some time. EIP will make it a new hardfork. (THE Berlin hardfork seems to be the best example so far).
With the new version of the VM, the internal functional modularization layer has been reworked. This allows EIPs to now become native citizens within the VM. A VM with a special set of EIPs can be instantiated as follows:
import Common from '@ethereumjs/common'; import VM from '@ethereumjs/vm'; const common = new Common({ chain: 'mainnet', eips: (2537) }); const vm = new VM({ common });
To begin with, we support the following new EIPs (mainly aimed at the sector Berlin hardfork) with the VM v5release:
Manuscript
During this EthereumJS release cycle, we can confidently say that we have comprehensively brought our libraries to a modern technology stack. A big part of this: With the new releases, we are moving closer to our long-planned and executed TypeScript transition and all of our major libraries as well as internal dependencies are now written in TypeScript.
Just a quick overview of what makes TypeScript so great and helps make our libraries more robust and secure: TypeScript is a superset of JavaScript and allows developers to know the data types for every variable and object used in the code. Is the variable called address a string or binary Buffer object? Although you won’t get any explicit indication of this in JavaScript – which greatly increases the risk of later developer errors – in TypeScript you will be sure of it.
It’s also a lot more fun to work directly on our libraries or use the libraries in a third-party project, because as a developer you can now get hints like this in the IDE throughout the codebase:
Your development environment with proper TypeScript input now simply knows that a blockchain the variable is a @ethereumjs/blockchain object (wait for your comments, Go and Rust developers 😅) and not just “something”. So our own code respectively gets your code (TypeScript) which will become much more readable using new versions of the library.
Promises
If you’re not that keen on JavaScript, you can skip this section, but if you’re a JavaScript developer, you’ll probably sigh with relief following this news, so we’ll at least briefly cover it:
Another finalized transition, all library APIs now work with JavaScript Promises. So no more callbacks all over our stack.
Library usage changes from:
blockchain.getBlock(blockId, block => { console.log(block); });
New API example:
const block = await blockchain.getBlock(blockId); console.log(block);
The small indentation on this first example doesn’t seem to mean much at first glance. Over several of these old style calls nested together you get deeper and deeper and at some point the code becomes unreadable. Just Google “recall hell” if you want to know what it might look like. 🙂 Promises allow you to write much more readable code.
Library refactorings
It is sometimes a little difficult to imagine the need for an engine change if the car is still running, nevertheless at some point it becomes a necessity if one is to safely cover the next 10,000 miles. With software refactoring, it’s often a bit similar. 😀 With this release series, we’ve reworked the fundamentals of some of our most core libraries and our blockOUR tax and partly our blockchain the library received a significant rewrite.
These libraries should now be much easier to work with and should be well prepared to provide a solid and secure foundation to build on within the Ethereum JavaScript ecosystem for years to come.
Outlook
We hope you enjoy our new features. This article can only provide an overview of the most important changes and things are covered in much more detail in the release notes linked at the start of this article. We are happy to hear your comments about our Discord server or our new @EFJavaScript Twitter account.
For us, these releases provide a solid foundation for moving into a more future-oriented development cycle and we look forward to seeing this come into play. With the VM having all hardforks implemented, it is now possible to integrate the VM in our redesigned version. EthereumJS client project. We will not be joining the mainnet with this client anytime soon. But we will nevertheless be able to contribute to improving the diversity of our customers. The new client in its early stages will allow us to join development test networks like Yolo v2 (and following) and actively help discover and protect against cross-client consensus bugs. We will also be able to contribute more actively to future protocol research and potentially participate in subsequent research implementations. You’ll hear more about this once we have a first usable version of our client ready (targeting full sync on Yolo v2), it will be early next year.
For now, we wish everyone a contemplative end of the year complemented by an exciting beaconchain launch day (week)! 🚀
The EF JavaScript Team
