Smart contracts are pretty good at executing transactions. But what happens when you want dozens of independent programs communicating, remembering things, and coordinating work over time?
That's the question that got me interested in asynchronous smart contract architecture.
For years, much of blockchain development has revolved around the same basic execution model: submit a transaction, execute some code, update state, and finish.
It's a model that works. Ethereum has an enormous ecosystem of applications proving exactly that.
But what if our application doesn't naturally fit into one synchronous transaction?
What if we want programs that can send messages, handle responses later, and coordinate activities without requiring every participant to execute as part of the same call stack?
That's where the actor model enters the conversation.
And where things start getting interesting.
Disclosure: I founded UseVara, an independent publication openly supportive of the Vara Network. This article examines Gear and Vara's technical architecture, including its limitations.
The Smart Contract Model We Know
Ethereum established a remarkably useful model for programmable blockchains.
A user submits a transaction. A contract executes code. State changes. Other contracts might get called along the way.
Eventually, the transaction succeeds or reverts.
In the Ethereum Virtual Machine, contract-to-contract calls are generally synchronous.
When contract A calls contract B, A waits for B to return before continuing.
This provides something particularly valuable for financial applications: transaction-level atomicity.
Imagine swapping assets through several liquidity pools.
You probably don't want two trades to succeed and the third to fail, leaving you holding something you never intended to buy.
Atomic execution helps prevent that outcome.
There's nothing inherently wrong with this architecture. Ethereum has demonstrated its usefulness rather convincingly.
But here's where my curiosity kicks in.
What happens when an application consists of dozens or hundreds of independent components, each with its own responsibilities?
Do we really want every interaction to resemble a synchronous function call?
Not necessarily.
Actors: An Old Idea With Some Interesting New Possibilities
The actor model has been around since the 1970s.
It isn't blockchain magic. It's an established approach to concurrent computation.
An actor is an independent computational entity that can:
- Maintain its own state.
- Receive and process messages.
- Send messages to other actors.
- Change its behavior based on its state.
Think of a restaurant kitchen.
A waiter takes an order and sends it to the kitchen. The kitchen prepares the food. Somebody else handles drinks. Another person manages deliveries.
Everyone has a job, and they communicate through requests and responses.
The waiter doesn't need to stand motionless beside the stove while the chef cooks.
Now imagine trying to run the entire restaurant as one enormous synchronous function call.
You could probably make it work.
I'm not sure anybody would enjoy maintaining it.
The actor model lets us organize software around independent participants communicating through messages.
Variations of this approach have been used in distributed systems for decades, including software built with Erlang and Akka.
The interesting question is what happens when we bring that programming model onto a blockchain.
Putting Asynchronous Messages on a Blockchain
A blockchain still has to reach agreement about what happened.
That requirement doesn't disappear because programs communicate asynchronously.
The network still executes code, validates state transitions, and applies consensus rules.
What changes is how application components interact.
Instead of primarily coordinating work through nested synchronous calls, programs exchange messages.
One program receives a message, processes it, updates its state, and sends messages to other programs.
Those programs process their messages according to the execution environment's scheduling rules.
This is the architecture behind Gear Protocol, which provides smart contract execution for the Vara Network.
Gear uses WebAssembly programs and Rust-based tooling, with asynchronous messaging as a central part of its programming model.
The distinction isn't simply that messages exist.
Ethereum has events. Other blockchain environments support forms of asynchronous communication.
What's interesting is that message-driven interaction is fundamental to how Gear programs communicate.
And we can look at a small piece of actual code to see what that means.
Show Me the Code
Here's a minimal example using Gear's gstd library.
It receives a message and sends a new message back to the sender.
#![no_std]
use gstd::msg;
#[unsafe(no_mangle)]
extern "C" fn handle() {
let destination = msg::source();
msg::send(destination, "PING", 0)
.expect("Failed to send message");
}
That's it.
The program identifies the actor that sent the incoming message using msg::source().
It then calls msg::send() with three arguments:
- The destination actor.
- The message payload,
PING. - The amount of value to transfer, which is zero in this example.
The code uses the message-sending API documented in the Gear standard library guide.
There's an important distinction here.
Sending a message is not the same as synchronously executing another program and receiving its result.
When the destination is another program, the message participates in Gear's message-processing system and is handled according to the runtime's execution rules.
In this particular example, the destination is whoever sent the original message. If that sender is a user account, the outgoing message is delivered through the user-message mechanism rather than executing another smart contract.
For actual program-to-program communication, the destination would be another deployed program's actor ID.
And this snippet is deliberately minimal. It doesn't implement a complete request-response workflow, handle retries, or demonstrate asynchronous waiting.
For those capabilities, Gear provides additional mechanisms, including asynchronous handlers and reply futures.
The code is small, but the architectural idea is substantial.
A program can initiate an interaction by sending a message without requiring the destination program to execute as a nested synchronous call.
Now let's give that idea something interesting to do.
Let's Build a Spaceport
Suppose we're making a game where players fly cargo ships between space stations.
Nothing too exotic.
Ships, fuel, cargo, markets, insurance, and the occasional unfortunate docking maneuver.
A player arrives at a station carrying a hold full of minerals.
Before selling the cargo, several things need to happen.
The station needs to approve docking.
A cargo system needs to inspect the manifest.
A market needs to calculate the purchase price.
An insurance system might need to update the ship's coverage.
And eventually, somebody needs to get paid.
We could attempt to coordinate all of that within a synchronous transaction.
But what if we designed each component as an independent program?
The docking system receives a request and sends a message to the cargo system.
The cargo system checks the manifest and replies.
The market processes a pricing request.
The trade coordinator tracks the operation as responses arrive.
Each program has a defined responsibility.
Other unrelated work can continue through the network's message-processing system while this workflow progresses.
That's a useful way to organize a complicated application.
It also sounds suspiciously like how people have been building distributed software for decades.
Which is rather the point.
Now for the Part the Marketing Brochures Skip
Asynchronous programming isn't free magic.
It introduces some wonderfully annoying problems.
What happens if a message fails?
What if a response arrives later than expected?
What if the cargo gets reserved but the payment fails?
What if the player submits the same request twice?
What if the market price changes while the trade is being processed?
These aren't minor implementation details.
They're fundamental questions about application correctness.
In a synchronous Ethereum transaction, multiple contract calls can participate in one atomic operation.
An asynchronous workflow may involve several separately executed messages.
If an early operation succeeds and a later operation fails, the earlier state transition isn't necessarily undone.
Our fictional spaceport might need to reserve cargo before attempting settlement, track pending requests, prevent duplicate processing, and implement explicit cancellation rules.
Distributed systems engineers have names for techniques that help manage these situations: state machines, idempotency, compensating actions, and timeouts.
You don't have to love the terminology.
You do have to solve the problems.
The actor model doesn't eliminate complexity. It gives you a different way to organize it.
For some applications, that's a very worthwhile trade.
For others, it may be entirely unnecessary.
Programs That Remember What They're Doing
Another interesting property of Gear programs is that they can maintain state between message executions.
To be clear, persistent state isn't unique to Gear. Ethereum contracts have persistent storage too.
The distinction is how that state participates in a message-driven application.
Imagine an autonomous trading station.
It maintains inventory, tracks pending orders, remembers outstanding requests, and processes messages from ships and other programs.
It doesn't need to run continuously like a conventional server process.
Its state persists on-chain, and incoming messages trigger additional computation.
A ship sends a request.
The station checks its records.
It sends a response or initiates another interaction.
Then it waits for whatever happens next.
Suddenly, the application starts looking less like a collection of contract functions and more like a little society of independent software participants.
I'm not suggesting we should anthropomorphize every smart contract until the blockchain resembles a particularly expensive ant farm.
But the mental model is useful.
When you're building complicated software, the way you divide responsibilities matters.
Sometimes the right abstraction makes an enormous difference.
What If a Program Needs to Do Something Tomorrow?
Here's where Gear gets particularly interesting.
Asynchronous communication doesn't have to mean sending a message immediately.
Gear also supports delayed messages.
A program can schedule a message to be processed after a specified number of blocks.
The relevant API is msg::send_delayed(), documented in Gear's delayed-messages guide.
Imagine an auction.
A participant starts the auction, and the auction program records the relevant state.
Instead of relying entirely on an external service to remember when the auction should close, the program can arrange for a delayed message to trigger settlement.
That message might be sent to another program or back to the auction program itself.
Now combine delayed messaging with another Gear capability: gas reservations.
Gear programs can reserve gas for future message processing.
The gas-reservation documentation describes how reserved gas can support delayed execution without requiring a separate external transaction to initiate every scheduled action.
That's a particularly interesting architectural capability.
It doesn't mean programs receive unlimited free computation.
Gas still has to be funded, reservations have rules, and the network still has to execute the scheduled work.
But it does mean certain future actions can be arranged as part of the on-chain program's own workflow.
Consider an insurance policy that expires after a defined period.
Or an auction that settles after its bidding window closes.
Or a game world in which a scheduled event changes the state of an installation.
These are situations where delayed messages and reserved execution resources may provide a useful alternative to relying exclusively on external scheduling infrastructure.
And that opens up another category of design questions worth investigating.
Is Asynchronous Execution Better?
Better for what?
If you're building a straightforward token contract, an asynchronous actor architecture might offer little practical advantage.
If you're executing a financial transaction that absolutely must settle atomically, synchronous execution has attractive properties.
But if you're building a system with many independent, stateful components that coordinate over time, asynchronous messaging deserves a serious look.
The advantages aren't automatic.
You still have to consider execution costs, message scheduling, gas management, failure handling, developer tooling, and network performance.
And it's entirely possible to build a terrible application using an elegant architecture.
We've all seen that movie.
The interesting thing is having another option.
For a long time, Ethereum's execution model has shaped much of the industry's understanding of what smart contracts should look like.
That's understandable.
But there's no particular reason to assume one execution model should be ideal for every application forever.
Software engineering has never been that tidy.
What I'd Test Before Getting Too Excited
I like interesting architecture.
I like working software considerably more.
So before committing to an asynchronous smart contract platform, I'd want answers to some practical questions.
Message guarantees: How are messages queued, scheduled, and processed? What guarantees actually exist around execution and delivery?
Failure handling: What happens when execution runs out of gas, a destination cannot process a message, or a reply never arrives?
Security: How do programs authenticate message senders and prevent unauthorized interactions?
Observability: How do I trace a complicated chain of messages when something breaks?
Cost: What does a complete multi-message workflow cost, rather than one isolated operation?
Developer experience: How easy is it to test failures, debug state transitions, and deploy updates safely?
And perhaps most importantly:
Does the architecture make my application easier to build?
That's the question I'd keep coming back to.
A programming model doesn't become valuable simply because it's clever.
It becomes valuable when it helps people build useful software.
So What Happens When Smart Contracts Talk Asynchronously?
They don't become intelligent.
They don't magically become faster.
And they certainly don't stop requiring careful engineering.
What changes is how developers can organize their applications.
Instead of designing every interaction around synchronous execution, we can build collections of stateful programs that communicate through messages, maintain their own state, and arrange certain actions for future execution.
For some applications, that's unnecessary complexity.
For others, it might be exactly the abstraction they've been missing.
I don't know which application will ultimately make the strongest case for asynchronous smart contracts.
And frankly, I'd be suspicious of anyone who claims they already know.
What interests me is that the tools exist, the architecture is different enough to warrant investigation, and developers can experiment with it right now.
That's considerably more exciting than another slide deck promising to revolutionize everything.
Build something. Send some messages. Break a few things. Figure out what works.
That's where the interesting discoveries usually happen.
Disclosure: I founded UseVara.org, an independent publication openly supportive of the Vara Network. This article reflects that editorial perspective and is not sponsored by Gear or Vara. The Rust example illustrates the documented messaging API and is not a complete, independently compiled application. I personally hold VARA but cannot use the HODL emoji because VARA is not listed among HackerNoon's supported assets.☺️