One of the unique, but not well discussed design distinctions of the Aion Virtual Machine (when compared to most other blockchain VMs) is its storage model. Whenever I say “hybrid storage model”, all of the eyes in the room quickly glaze over with either confusion or disinterest.
Here, I want to explain what this means and why it will be game-changing for how smart contracts are developed.Virtualizing what?
Let’s take a step back and first talk about what puts the “virtual” into “virtual machine”. While there are lots of answers to this for different VMs (usually around virtualizing a different architecture, full machine without one, or ideal machine), we want to focus on blockchain VMs.
In this environment, what we really want to virtualize is: A program starts and then runs forever. After all, it “starts” when it is deployed, and then can respond to events as though it was always running, until it is deleted. The space between that start-stop could last for years and the program would act as though it never stopped.
But it clearly does stop. All machines the program is running on probably stopped several times. So how do we provide this virtual behaviour, the un-provable lie that the program never actually stopped? Storage.
Confused? Well, consider the program thinking “I am going to store some information into this variable and come get it later… oh wait.” This means that the program needs to store this data somewhere persistent. One of the key differences between blockchain environments is how that persistent storage is exposed.Storage in Blockchains Key-value Store
In Ethereum’s EVM, the storage abstraction is a key-value store. However, Solidity does a good job of making this seem transparent. It does this by being designed around this limitation. If the language can only describe what can be mapped to a key-value store, problem solved!Key-value store with language assistance