Actor Model

How It Works

The BigFile's programming model is based on memory-isolated cubes that communicate through asynchronous message passing, using binary data to encode Candid values. Each cube processes its messages one at a time, preventing race conditions. When issuing inter-cube messages, a cube uses callbacks to handle the results.

Cubes as actors

The actor model is a mathematical framework for concurrent computation, where an actor, in response to a message, can modify its state, send messages, and create additional actors.

In many ways, a cube functions similarly to an actor. For instance, an actor has:

• a private state that can only be modified by the cube itself
• a single thread of execution, so it does not need lock-based synchronization
• the ability to communicate with other cubes through asynchronous messages
• the ability to create new cubes

A key distinction between traditional actors and cubes on the BigFile is that cubes support bidirectional message passing. Messages are categorized into requests and responses, with requests allowing for replies, and the BigFile tracking callbacks for the responses.

In actor terminology, every actor has a mailing address for receiving messages. Similarly, a cube on the BigFile has its own mailing address, which resembles an IPv6 address.

Although a cube's update throughput is limited by blockchain consensus and its single thread of execution, it can handle hundreds of queries concurrently, achieving throughput of thousands of queries per second with latency measured in milliseconds.

To complete the picture, it's important to note that end users also act as participants in this model. This means that browsers and mobile apps can directly perform update and query operations on cubes.

See examples of dapps 100% on-chain