Skip to main content

Glossary

General terms​

Fluence Network​

Fluence network is an open, permissionless network of Fluence protocol-compliant Peers. You can use it to make Deployments, execute and choreograph Cloudless Functions to perform your computations.

  • kras is the main Fluence Network
  • dar is the non-incentivized test network that is expected to follow exactly the same protocol as kras

Fluence Protocol​

Fluence Protocol is an open, off-chain protocol that matches resource providers and consumers to enable secure, verifiable decentralized serverless compute. The protocol is defined by a set of behaviors of Peers, on top of Libp2p and Aquamarine, that enables emergent abilities of the Fluence network: to resolve, serve, execute and verify Cloudless Functions.

Fluence Blockchain​

Fluence Blockchain is a L2/L3 application-specific EVM-compatible blockchain dedicated to the Compute Marketplace, which includes both Deployments and Capacity Commitments. As of now, Fluence Blockchain is bridged with Filecoin and Ethereum Mainnets.

Fluence CLI​

Fluence CLI is the main entry point into a Fluence App lifecycle:

Fluence App​

Fluence App is the actual end-user application that includes Cloudless Deployment but may be paired with a Gateway to call Cloudless Functions from HTTP endpoints and enable HTTP event listeners, browser application and other integration.

Fluence JS Client​

A JS library that enables full-fledged, bi-directional interactions between JS applications (both node.js and browser-based, Electron.js is also an option) and Fluence Network.

Fluence JS Client is embedded into Fluence CLI.

Cloudless Function​

Cloudless Function is a piece of useful compute work defined by developer. It contains one or more Compute Functions and an Aqua script to orchestrate them by connecting outputs and inputs, denoting parallelism and defining success and failure.

With the help of Aqua, a developer can implement redundancy and fault-tolerance policies for their Cloudless Functions, facilitate parallelism across different machines, pass data from peer to peer, and much more.

Cloudless Deployment​

Cloudless Deployment is a Compute Function and/or Cloudless Scheduler configured, deployed and ready for use. It is an instantiated Cloudless Distributive, managed by a Deal, and running on Workers.

Cloudless Distributive​

Prototype for a Cloudless Deployment. Includes:

Cloudless Distributive is structured with IPLD resulting in a unique CID and uploaded to network storage for future content-addressable retrieval.

Cloudless Scheduler​

Cloudless Scheduler triggers a Cloudless Function without client interaction, based on events. Implemented as a part of Cloudless Deployment. See Spells for low level details.

Trigger types a Scheduler is capable to handle:

  • time-based, such as cronjobs
  • event-based, such as chain events

Proofs​

Fluence Protocol enables a set of Proofs that drives its cryptonomic model.

Proof of Capacity​

Proof that a compute peer (Host) has certain capacity allocated and available for Cloudless Deployments. Every Host must provide Proofs of Capacity in order to participate in Deployments.

Proofs generation is managed by the Capacity Commitment Prover (CCP).

Proof of Processing​

Proof that a Cloudless Function was executed as described – in a distributed manner.

Conducted and checked by AquaVM during execution on every step.

See Golden Particles to learn more about the use of Proof of Processing to facilitate verifiable deal settlement, i.e. payment for Cloudless Function executions.

Proof of Execution​

Proof of Compute Function: an attestation that a computation of a single function, running on a Peer, was done correctly.

PoE is pluggable, so that different workloads can benefit from the decentralization of compute. The options might include:

  • zero knowledge proofs (ZKP)
  • Trusted Execution Environments (TEE)
  • Verification of cryptographic function execution for MPC
  • Repeated execution of pure code
  • Consensus for external effects, Managed Effects
  • and more

Distributed​

AIR​

Aqua Intermediate Representation (AIR) results from compiling your Aqua scripts. AIR is used by the AquaVMs deployed on Fluence Peers to execute the workflows and Compute Function compositions specified in your Aqua scripts. AIR contains a very limited set of instructions, like (seq A B) or (par A B) for control flow, and (call peerId (serviceId functionName) [...args] exportVariable) to execute compute operations using Marine services or Peer API.

Aqua​

Aqua is Fluence’s language, designed especially to program choreography of distributed Cloudless Functions and orchestration of local functions. Aqua describes distributed control flow in developer-friendly terms, and delegates computations to Compute Functions on particular Peers. Aqua follows the structural typing paradigm to simplify composition and reuse of different libraries and Cloudless Functions. Read more in the Aqua Book.

AquaVM​

Interprets Aqua IR to orchestrate local function calls or choreograph Cloudless Functions. Checks and provides all the Cloudless Function proofs.

AquaVM is a State Machine that takes a Particle received by a particular Peer, interprets an AIR script of this Particle along with the Particle Data, and gives the Peer a set of commands: what Compute Functions to call locally (if any), to what Peers to send this Particle to (if any), and how the Particle Data should be updated (if should).

AquaVM enables Proof of Processing by also running on-chain to verify Particles, identify the Deals involved, and distribute the rewards.

Aquamarine​

Aquamarine is a technology stack that enables the off-chain Fluence Protocol: Aqua with AIR and AquaVM, and Marine. In other words, Aquamarine is Fluence without incentives and system services.

Particle​

A Particle is a network package that forms a single-use software-defined network (SDN) for a single request of a single AIR script.

Every Particle contains an immutable header and a mutable body. The immutable header includes an AIR script and some metadata including the initiator's signature; the mutable body contains the results of compute function calls triggered by the script execution along with the signatures of involved Peers.

Particle Data​

Particle data is an audit log of the distributed execution flow of a Particle; the mutable part of the Particle that contains Compute Function responses and Peer signatures.

Particle data has a CRDT-like format capable to handle fork-join behavior resulting in response data converging in a (eventually) deterministic way. Fork-join behavior in Aqua arises when the same Particle is executed in parallel on one or more peers.

Pi-calculus​

Pi-calculus, aka π-calculus, is a process calculus that is an extension of lambda calculus that describes the parallel execution of processes for dynamic network configurations.

The AIR and AquaVM execution model is built on fundamental principles of pi-calculus.

Spell​

A Spell is a single-peer representation of Cloudless Deployment used by the Cloudless Scheduler. It consists of a special Marine Service and an AIR script.

A Spell script is executed periodically or based on an event to run a predefined Cloudless Functions.

TODO: See Spell docs here.

Topology​

Here: exact way the execution of Cloudless Function flows from Peer to Peer, including sequential transitions, fork/join convergent executions, and more.

Topology is expressed and handled with the help of Aqua.

Compute​

Nox​

Nox is the reference implementation of a fully Fluence Protocol-compliant Peer capable to serve Cloudless Deployments. Nox serves as a Host for many Workers, where each Worker is devoted to a distinct Deployment.

System Services​

Marine Services that are required for a Fluence Peer to operate according to the Fluence Protocol, e.g. resolve Subnets, make Deployments, maintain Workers.

Part of Nox.

Builtin Services​

Low-level Compute Functions implemented in a peer’s native language, ie. Rust for Nox. Builtins allow the protocol-compliant execution of Aqua, such a math and string operators. See more in aqua-lib repo.

Marine​

Marine is a general purpose Wasm runtime, intended to execute Compute Functionss in form of linked Wasm Modules (aka Services) on a Peer.

It is the main way to express computations in the Fluence Protocol.

Developers have three ways to define computations:

With Marine, computations are portable and safe for the Provider.

Marine Service​

Service is a virtual construct combining one or more linked Marine modules, one of them being a Facade Module, and exposing one or more Compute Functions via Webassembly IT.

Service:

Service is identified by a Service ID that's bound to the Peer ID that provides this service.

Service exposes one or more Compute Functions and a developer needs to provide peer id, service id, and function name to invoke the function.

AIR instructions is the only legitimate way in the Fluence protocol to call a service function. For a developer, it entails using Aqua language and Fluence CLI.

Marine SDK​

Marine SDK is a set of tools that help developers write and compile Rust code as Marine modules and Services.

Marine JS​

Implementation of Marine running on JS. This includes support for Marine SDK and Module Linking. Only Pure module can run in JS Marine.

Marine Module​

Marine Module is a single .wasm file compiled with Wasm IT support, e.g., using Rust language with the Marine SDK.

Module Linking​

Modules can use each other using the shared nothing linking scheme.

Pure Module​

Module with no external effects (including WASI) that takes only inputs and maybe an internal sandboxed state, and produces new state and outputs. May have (foreign function) interface declarations for other modules via Module Linking.

Wasi Module​

A Marine Module that uses basic WASI effects such as access to time and file system.

Facade Module​

A Module, that is the only module accessible from the outside – it constitutes the API of a Service exposing a set of Compute Function declarations.

For modules that are intended to be shared as an API, developers often need to write a Facade module to protect internal APIs from unauthorized access, enforce business-invariants, etc.

Webassembly (Wasm)​

Webassembly is a binary instruction format for a stack-based virtual machine. Wasm is intended to provide a memory-safe, sandboxed execution environment with a flexible set of settings, such as memory size and allowed imports. Multiple languages, such as Rust, C/C++ or tinyGo, support the Wasm compile target.

Fluence provides a Rust SDK but supports any compiled Wasm module following the Module ABI conventions.

Webassembly IT​

Webassembly Interface Types (Wasm IT, WIT) is a part of the Component model proposal that allows using complex types, like strings, structs, enums and arrays, in a Wasm module's API.

WASI​

WASI stands for WebAssembly System Interface. It's an API that provides access to several OS-like features defining a standardized set of POSIX-like imports to access the OS. It has integrated capability-based security, extending WebAssembly's characteristic sandboxing to include I/O.

Managed Effects​

Managed Effects is an architectural approach that addresses the following contradiction:

  • Compute without effects is useless
  • Compute with effects might be dangerous

With Managed Effects, every effect is accessed only with an Effector Module. Effector Module is audited by the community to check that its API is useful for developers, and its effects are safe for Compute Providers.

Compute Providers whitelist only the known Effector Modules and forbid effects in any other module. If some Effector Module requires Provider to have certain capabilities, like locally deployed service or installed binary, it is the Provider's responsibility to ensure the capabilities are available.

Developer can access this effect safely using Module Linking.

Effector Module​

A Marine Module that implements Managed Effects providing access to an Effect in a safe and useful way. An Effector is what a developer can use via Module Linking.

Effector modules have a special section in their config that describes binary imports, socket imports, or similar things.

Effect​

What an Effector Module actually executes on the host system and is external to Marine, such as curl, IPFS, Ceramic or websocket.

Mounted Binary​

A Mounted Binary is a special interface that provides an effector module the capability to call any binary, hosted by a peer, with the provided set of arguments to obtain a result. It makes it possible to integrate almost any other software (such as IPFS, Ceramic, and databases) in the Fluence ecosystem.

Particle File Vault​

Particle File Vault is a temporary folder that is created on the Peer for every incoming Particle and removed when the Particle expires. All the services within this Peer have access to this folder.

Particle File Vault is expected to be used to pass data between Compute Functions (distributed in the form of Marine Services) within a single AIR script, making them more composable and avoiding revealing this data to other Peers involved into this Particle's execution, which could happen if the data is returned as a plain text.

Compute Function​

An individual computational action, executed on a single peer. Marine Services is the default and preferred way to run Compute Functions. Other options are builtins, and native code, e.g. Javascript callbacks for JS client.

Compute Unit​

Smallest divisible compute capacity providers allocate and stake to the Marketplace and available to allocate to a Worker. Proved by Proof of Capacity as a part of Capacity Commitment. Every Worker has exactly this amount of resources.

Tetraplet​

Tetraplet is a data structure describing the origin of an argument to a function call. It contains four fields:

  • peer_id
  • service_id
  • function_name
  • functor

Tetraplets are the means to check and enforce distributed security invariants of a function by putting restrictions on its arguments, e.g.: the argument “is_authorized” must be provided by a function “check_auth” from “security” Compute Function run on the same Peer. Both Marine SDK and Fluence JS Client provides access to tetraplets.

Network​

Peer​

A Fluence Peer is a node in the Fluence Network, which behaves according to the Fluence protocol, therefore hosts and executes general purpose Compute Functions, thus providing users cloudless experience.

Fluence reference peers are comprised of the following components:

Fluence peers are identified by an unique Peer ID derived from the Peer's Public Key.

PeerId​

Logical address of a segregated Compute Functions execution environment. It is derived from a Public key and used to verify a Peer’s signatures, which itself is a part of Proof of Processing verified by AquaVM for every step of a Cloudless Function.

Host​

A Fluence Peer that participates in Fluence’s Kademlia network. Nox is the reference peer implementation.

Hosts are capable to act as Relays for Workers and Clients.

Host Peer ID can always be accessed from Aqua.

Deployment​

Worker​

A single instance of a Cloudless Deployment: Compute Unit allocated for Compute Functions in form of Marine Services and Cloudless Scheduler in form of Spells.

So Cloudless Deployment forms or many Workers, each having the same code installed, the same behavior expected.

A Worker is a part of a Peer's resources that, together with other Workers, constitutes a Subnet, handles the Deal, and isolates some resources. It has its own keypair and Peer ID.

Worker Definition​

A Worker Definition is a transportable deployment configuration of a Worker. It is built with the help of Fluence CLI, and used by Nox to deploy and update a Worker. It is part of Cloudless Distributive and registered in Deals.

Consists of:

Subnet​

A set of all Workers, instantiated from an individual Cloudless Deployment and interconnected by runtime communication, which serves to provide redundancy, durability, fault tolerance, load balancing and better security of Cloudless Function' distributed execution.

Gateway​

A HTTP-facing Fluence Client Peer that is capable of running Cloudless Functions based on incoming requests.

TODO See this repo for more.

Init Peer​

The Peer that initiates a Cloudless Function by creating a Particle and sending it over Fluence Protocol.

Init Peer ID can always be accessed from Aqua or via the Marine SDK.

Client (peer)​

A Fluence Peer connected to a Relay but is not participating in the Fluence Kademlia network, i.e., not a Host. Most likely a running Fluence JS Client (browser, CLI).

Client peers, as well as Workers, cannot be discovered using their respective PeerIds. Developer needs to discover what Host or Relay is advertized to Kademlia network, and use Aqua to ensure the right path is used.

Relay​

A Host, that participates in serving Cloudless Functions by providing its advanced connectivity capabilities, which includes:

  • Ability of a Host to send messages internally to hosted Workers
  • Ability of a Host to send messages to connected Client Peers

To execute code on a Peer that's behind a Relay, e.g., if using a web browser or behind a NAT, use the on peer via relay: construct available in Aqua.

Compute Marketplace​

The Fluence's Compute Marketplace is an on-chain institution comprised of a set of smart contracts that maintains provider offers to sell compute capacity, accepts developer offers to purchase compute capacity and attempts to match developer offers with suitable provider offers in a trustless manner. A successful match results in a Deal.

Deal​

A Deal governs capacity supply and demand among providers and developers over a set of attributes including capacity pricing and deal duration. Deals are the result of the Compute Marketplace matching provider and developer offers. Moreover, Deals contain a content-addressable reference (CID) of Cloudless Distributive that specify off-chain subnets in terms of topology, Scheduled Cloudless Functions, Compute Functions, and initial data.

Hence, a Deal is the necessary condition for the trustless provisioning, execution and billing of Fluence Cloudless Compute.

Provider​

An organization that participates in the Fluence Protocol by providing hardware resources for use.

Matching​

The process of mapping a Developer Offer with its requirements and Provider Offers with its capabilities, resulting in assigning Worker allocations on particular Hosts, as described inside a Deal.

Offer​

Provider Offer​

Provider Offer is a description of capabilities. In order to participate in the Matching process, Offer must present a Capacity Commitment and send Proofs of Capacity, so only PoC providers are eligible to provide capacity to the network, staking is not enough.

A provider offer includes the CU capacity, provider metadata, such as data center attributes, desired revenue, etc.

Developer Offer​

A Cloudless Distributive, combined with the capacity selection criteria, such as payment offer, data center type, duration, payment offer, etc., and an escrow payment.

Capacity Commitment​

A provider’s capacity commitment to the network backed by Proofs Of Capacity and eligible for capacity rewards.

A provider can seamlessly switch their resource allocation between Proof of Capacity and fulfilling Deals.

Capacity Commitment Prover​

A piece of software, augmenting each Nox peer, tasked with generating Proofs of Capacity for that Nox’s hardware zone.

Golden Particle​

Golden Particle is a Particle at a certain step of its life time, when its Particle Data contains a solution of a cryptographic puzzle, so it can act as a winning lottery ticket to distribute the rewards among all the participants contributing to the execution of this Particle.

A Golden Particle represents sampled Cloudless Function executions used by the Proof of Processing for reward distribution.