Testnet launching soon!Join the Community

Guides

The Async VM (AVM)

The Async VM (AVM) is our flagship innovation, and it's designed to power the next generation of smart contracts. It's similar to Ethereum's virtual machine (EVM) in many ways, but it's not a fork of the EVM and it introduces unique concepts that require a slightly different way of thinking when building decentralized applications.

What is the Async VM?

The AVM is a full-featured virtual machine with a rich set of instructions that can execute complex logic in a deterministic and trustless environment. The instructions are designed to be as simple as possible, so they're easy to understand and reason about. In the AVM, like in other popular blockchain VMs, the stack stores data and controls the flow of execution.

Unlike other smart contract platforms, the AVM doesn't use a global stack. Instead, each account has its own execution stack, and each message is executed on its own stack. This means that the network can execute messages asynchronously, and each of those executions can further spawn reactive executions elsewhere in the system. It also allows contracts to schedule code to run at a specific time in the future, which opens the door to a wide range of use cases. It's easy to see how this model adds utility that the synchronous execution engines of other blockchains simply can't offer.

Execution-ception

Contract executions can spawn reactive executions that can spawn more reactive executions, and so on. This is due to the event-driven nature of the system, and it's one of the most powerful features of the AVM. It allows developers to build complex systems that can react to arbitrary events in real-time, and it opens the door to a wide range of use cases.

It's worth pointing out that the number of reactive executions that can be spawned is inherently limited by the heat tolerance available to the downstream listeners. This means that while it's not technically disallowed, it's not economically feasible for a single contract to spawn an infinite number of reactive executions. This is a good thing, because it prevents the system's resources from being monopolized by buggy or malicious contracts.

The Power of Async

The AVM's asynchronous execution engine is based on the actor model. In this model, each account is an actor that can send and receive messages to and from other actors in the system. Each account effectively has its own private state and its own message queue. When an account receives a message, it's placed into the account's queue until a validator executes the code associated with that message. The validator executes the code and then sends a response back to the sender. This response is placed into the sender's queue, and the sender can then process the response however it sees fit.

The AVM's unique architecture allows for an inherently more efficient and scalable network. It also enables smart contract automation through on-chain event listeners and scheduled execution, as well as provably secure on-chain randomness.

Awaiting responses

When a remote contract function call is prepended with the await keyword, the AVM will "suspend" the current context until the requested execution is complete. But because the AVM is asynchronous, your contract remains fully capable of responding to global events, performing scheduled operations, or handling other calls in parallel. This will feel very familiar to developers who have worked with asynchronous code in JavaScript or other languages.

Async-first development made easy

Thinking asynchronously is hard. Pyro leans heavily on popular Web 2.0 programming languages and supports features like an await keyword and event hooks that help developers write robust, asynchronous code that feels a lot like Typescript and is easy to understand.

If you're familiar with the EVM, you might be wondering how the AVM handles the call opcode. The AVM's call opcode is similar to that of the EVM, but it's not a direct replacement. The AVM's call opcode is asynchronous, and it's designed to call remote functions on other contracts. If access to the result of the remote call is necessary, the await keyword can be used to suspend the current execution context until the remote function call is complete. This is similar to the await keyword in JavaScript, which suspends the current execution context until a promise is resolved.

On-chain event listeners

On-chain event listeners are a powerful pattern that allows smart contracts to react to events that occur across the network. For example, a smart contract could listen for a specific event on another smart contract and then perform some action when that event occurs. Event-driven patterns are difficult or impossible to implement on other blockchains because of the synchronous nature of smart contract execution. Thanks to the asynchronous, event-driven design of the AVM, it's easy to listen for events on other contracts. This is a powerful pattern that enables a wide range of use cases, like reactive execution, portfolio automation, real-time arbitrage, and dynamic governance.

Scheduled execution

Smart contracts can schedule code to run at a specific time in the future. For example, a smart contract could delay its response to a transaction for a few blocks, or it could schedule a recurring execution at a specific interval. This opens the door to interesting things like stronger finality guarantees, governance automation, scheduled payments, and time-based state changes.

Provably secure on-chain randomness

The AVM is capable of generating provably secure random numbers on-chain. This is a powerful feature that breaks down one of the most challenging barriers to Web3 adoption. The AVM's on-chain randomness relies on the fact that requests are resolved asynchronously, and that latency guarantees that a sufficiently unpredictable seed can be generated from the system's Verifiable Random Function (VRF) algorithm at the time of execution. This means that Firechain smart contracts can access provably secure random numbers on-demand without relying on an external source of randomness, like a trusted oracle or a centralized random number generator.

Previous
Architecture