The Aion Virtual Machine (AVM) is a component of the software running on the machines which maintain the Aion public blockchain network. Specifically, it is the part which runs the programs which users can store on the blockchain.
The key distinction of the AVM, as compared to the virtual machines on many other blockchains, is that the AVM can run blockchain programs (“smart contracts”) written in the Java programming language.
For more background, see this article where we introduced using the AVM to run Java code on the blockchain.
Welcome Java Developers
The biggest news here is obviously for the Java community, itself. They can now build smart contracts directly in Java.
Further, the BloxBean Aion4J Maven plugin makes testing/deploying/calling smart contracts easy to integrate into an existing build system.
Additionally, the BloxBean IntelliJ plugin means that a familiar Java IDE can be used to aid in development, testing, deployment, and debugging. Yes, even debugging! The IntelliJ plugin runs the AVM internally, so you can debug Java smart contracts with full debug support (breakpoints, variable introspection, etc), directly in the IDE.
These tools are described in greater detail on the Aion Docs site:
Some of the new capabilities of AVM may also be of interest to existing blockchain developers:
- Java object-oriented programming model, including custom types
- Rich Java ecosystem and tools and patterns
- Fast and inexpensive primitive data types
- Hybrid storage model: both a key-value store and a transparent object graph
- Strict IEEE 754 floating point support
Broader AVM Benefits
This is a big deal in terms of what can be run on a public blockchain, so those interested in the future of such systems should definitely take note of the AVM.
The AVM provides an entirely new avenue for building on-chain software. Of course, this is talking about building smart contracts in standard Java.
This means that the broader ecosystem of development patterns and tools are potentially candidates for use in a blockchain environment, as in the case of the aforementioned Maven and IntelliJ plugins created by BloxBean.
Beyond that, the AVM also opens the door to further performance improvements on the nodes running the chain, which creates the possibility of allowing more complex blocks in the future (think higher total block energy limits). Some of this comes from our ability to capitalize on the performance of the JVM, but some of it also comes from our new hybrid storage model, and a great deal comes from our ability to run transactions concurrently.
Note that we demonstrated this concurrent transaction execution benefit prior to the fork, where we switched to using the AVM for balance transfers, back in Java kernel 0.3.4. By running multiple transactions at the same time, we can hide the time spent waiting for the DB.
The Future of AVM
Now that we have AVM at our disposal, here are some of our future ideas (none of these are carved in stone, just possibilities we are considering):
- Other JVM language support: All we would need is to build blockchain-hardened versions of the runtime libraries these languages require and verify that they have no other hidden assumptions we would need to more directly support/restrict.
- Optimizations: We have already made some changes to improve some worst-case scenarios of internal execution cost and we have some other experiments to try to further hide the cost of going to the DB.
- Client-side tooling: We already compile the ABI, on the client-side, and we are in the midst of expanding this client-side pipeline to further reduce deployment cost.
- Smaller user libraries: In order to keep the surface area of the AVM small, much functionality is delivered as user libraries, which are packaged along with the contract, when deployed. Some of these are more sophisticated than they need to be (they are a hold-over from a different set of assumptions) so smaller ones would suffice and save on deployment cost.
Since these are packaged with the contract, we don’t need to wait for a hard-fork to change these (and users are free to make their own). - Ease of API expansion: New features targeting smart contracts will be easy to expose in the AVM, since it exposes blockchain functionality as normal API calls, as opposed to special-case opcodes at the VM level. This means we can expand functionality without modifying any of the rest of the tooling stack (much like the way the JVM expands its core class library with new classes and functions).
Of course, there are also some more exotic possibilities, when considering what VM can do, but I will have to leave those to your imagination since we aren’t sure what will be required, quite yet. Suffice it to say, we have a lot of ideas, should we get the opportunity to explore them in the future.
The future looks bright!
