Go to file
Ivan Boldyrev c3cea695c8
air-trace util for measuring AquaVM performance with tracing crate.
`air-trace run` subcommand allows to run AquaVM on any data, it allows to define most AquaVM inputs, providing defaults for most of them, and sets up either human-readable or JSON tracing output, the latter can be later processed by `air-trace stats`.

Anomaly data input is also supported, that is useful for slow data investigation.

Native execution mode can be used for native profiling.  Please note, however, that current version cannot be built natively on Apple Sillicon processor yet, as invariably depends on the `avm-server` because of leaking types that should be refactored or hidden.  The `--repeat` option can repeat the execution several times for the execution to dominate on input data reading and output.

High-level or rare calls have "info" trace level, instructions are "debug", and sub-instruction calls are "tracing".  Over-detailed tracing can induce overhead that spoils timing data.
2022-07-07 18:44:58 +07:00
.cargo set stack limit to 50 MiB (#244) 2022-04-15 18:22:42 +03:00
.github Migrate air workflow to github-actions (#281) 2022-07-01 16:48:39 +03:00
air air-trace util for measuring AquaVM performance with tracing crate. 2022-07-07 18:44:58 +07:00
air-interpreter air-trace util for measuring AquaVM performance with tracing crate. 2022-07-07 18:44:58 +07:00
avm air-trace util for measuring AquaVM performance with tracing crate. 2022-07-07 18:44:58 +07:00
crates air-trace util for measuring AquaVM performance with tracing crate. 2022-07-07 18:44:58 +07:00
docs Document import scheme and doc comment style (#268) 2022-06-29 22:23:33 +03:00
images Update readme (#260) 2022-05-14 17:12:48 +03:00
tools/cli air-trace util for measuring AquaVM performance with tracing crate. 2022-07-07 18:44:58 +07:00
.gitignore Rename Aqua to AIR, move AVM from FCE (#99) 2021-05-10 14:25:34 +03:00
Cargo.lock air-trace util for measuring AquaVM performance with tracing crate. 2022-07-07 18:44:58 +07:00
Cargo.toml air-trace util for measuring AquaVM performance with tracing crate. 2022-07-07 18:44:58 +07:00
CHANGELOG.md Rename subtree to subgraph (#265) 2022-05-17 15:53:33 +03:00
Config.toml Rename Aqua to AIR, move AVM from FCE (#99) 2021-05-10 14:25:34 +03:00
LICENSE Initial commit 2020-09-18 14:05:43 +03:00
next-hardfork-changes.md add a list of changes to the next hardfork (#232) 2022-03-14 15:58:31 +03:00
README.md Update readme (#260) 2022-05-14 17:12:48 +03:00

crates.io version npm version

AquaVM

AquaVM executes compiled Aqua, i.e., Aqua Intermediate Representation (AIR) scripts, and plays an integral part in the implementation of the Fluence peer-to-peer compute protocol. Specifically, AquaVM allows expressing network choreography in scripts and composing distributed, peer-to-peer hosted services. Moreover, AquaVM plays a significant role in facilitating function addressability in the Fluence network. Figure 1.

Figure 1: Stylized AquaVM And AIR Model

AquaVM & AIR model

Since AquaVM compiles to Wasm, it can run in both client, such as browsers and nodejs apps, and server environments.

AquaVM: Interpreter Execution Model

AquaVM's execution model facilitates Fluence protocol's data push model implemented as a particle, i.e., a smart packet comprised of data, AIR, and some metadata. In this context, AquaVM can be viewed as a pure state transition function that facilitates particle updates, which includes state management of particle data by taking previous and current state to produce a new state and an updated list of peers and call requests in the remaining AIR workflow. In addition to local service call execution, AquaVM handles requests from remote peers, e.g. as part of a parallel execution block, to call local services and handle the future response. See Figure 2.

Figure 2: AquaVM Interpreter Execution Model

interpreter execution model

In summary, the AquaVM execution model handles the topological hops for simple and advanced composition patters, such as (async) parallel service execution on one or multiple peers.

Aquamarine Intermediate Representation (AIR): IR For P2P Systems

AIR scripts control the Fluence peer-to-peer network, its peers and, through Marine adapter services, even resources on other (p2p) networks, such as IPFS and Filecoin, e.g., Fluence IPFS library.

What is AIR?

AIR: Instructions

call

(call <peer_id> (<service name> <service function>) [<arguments list>] <output name>)
  • moves execution to the peer_id specified
  • the peer is expected to host Wasm service with the specified service name
  • the service function is expected to contain the specified function
  • the arguments list is given to the function and may be empty
  • the result of the function execution is saved and returned by it's output name

Example:

(call "peer_id" ("dht" "put") [key value] result)

seq

(seq <left_instruction> <right_instruction>)
  • executes instructions sequentially: right_instruction will be executed iff left_instruction finished successfully

par

(par <left_instruction> <right_instruction>)
  • executes instructions in parallel: right_instruction will be executed independently of the completion of left_instruction

ap

(ap <literal> <dst_variable>)
(ap <src_variable>.$.<lambda> <dst_variable>)
  • puts literal into dst_variable
  • or applies lambda to src_variable and saves the result in dst_variable

Example:

(seq
    (call "peer_id" ("user-list" "get_users") [] users)
    (ap users.$.[0].peer_id user_0)
)

match/mismath

(match <variable> <variable> <instruction>)
(mismatch <variable> <variable> <instruction>)
  • executes the instruction iff variables are equal/notequal

Example:

(seq
    (call "peer_id" ("user-list" "get_users") [] users)
    (mismatch users.$.length 0
        (ap users.$.[0].peer_id user_0)
    )
)

fold/next

(fold <iterable> <iterator> <instruction>)
  • is a form of a fixed-point combinator
  • iterates through the iterable, assigning each element to the iterator
  • on each iteration instruction is executed
  • next triggers next iteration

Example:

(fold users user
    (seq
        (call user.$.peer_id ("chat" "display") [msg])
        (next user)
    )
)

xor

(xor <left_instruction> <right_instruction>)
  • right_instruction is executed iff left_instruction failed

new

(new <variable>)
  • creates a new scoped variable with the provided name (it's similar to \mu operator from pi-calculus that creates an anonymous channel)

fail

(fail <variable>)
(fail <error code> <error message>)
  • throws an exception with provided error code and error message or construct it from a provided variable]

Example

(fail 1337 "error message")

null

(null)
  • does nothing, useful for code generation

AIR: values

Scalars

  • scalars are fully consistent - have the same value on each peer during a script execution
  • could be an argument of any instruction
  • JSON-based (fold could iterate only over array-based value)

Streams

  • streams are CRDT-like (locally-consistent) - have deterministic execution wrt one peer
  • versioned
  • could be used only by call and fold instructions (more instructions for streams to come)
  • could be turned to scalar (canonicalized)