Cambrian Architecture and Workflow

Cambrian's general principles of organisation, components and workflow

General Cambrian Architecture

At a basic level, the Cambrian architecture consists of several smart-contracts and modules that manage the interactions between protocol participants to ensure smooth and seamless operation.

• PoolManager — part that works with user’s assets, tokens whitelist, mint and burn cSOL, deposit and withdrawal funds.

• WorkerManager — part that manager system workers (node operators), enrols and delists them. The workers or nodes make up the AVS

• AVSManager — part that manages AVS enrollment and exit, as well as their accounting.

• StakingManager — staking implementation, it’s also the first part of a slashing system, that coordinates stake and determines what should be slashed. There is also a module for slashing as part of StakingManager. The principles of how slashing works are described in the "AVS Overview" section

Cambrian participants and components:

• Operators are those who manage Solana nodes and related nodes in Cambrian and offer their services to AVS developers where different products can be run. Operators are somewhat similar to validators, but instead of validating blocks on an independent blockchain network, they validate and maintain actively validated services (AVS) that represent different types of services. For providing capacity for AVS, they receive rewards from the protocols.

• Restakers - they can both delegate directly to SOL operators for restaking, and can restake LSTs such as mSOL, scnSOL, jSOL and others

• AVS - Actively Validated Services that are verified by operators and used as the basis for Middleware, which developers can configure to their needs.

• Middleware are services/applications/protocols running on top of individual AVSes. Middleware developers pay fees to operators to maintain the infrastructure (more about this in the section "AVS Reward Model").

• Endusers - users, which can be individuals, organisations or applications that use products (Middlewares) built on top of AVSes.

• Workers - Workers is another name for the operators of the individual nodes or clusters that make up the AVS for running Middleware and whose behaviour logic is managed by the WorkerManager.

Main workflow:

Firstly, users (stakers), workers, and AVSs register in the system, depositing their funds into specific accounts through PoolManager and WorkerManager, linking AVS nodes with Solana nodes, completing the initial system setup. Then, suppose AVS node operators receive messages instructing them to perform a certain amount of work for a particular AVS. In that case, they can participate in the validation of that AVS depending on the proposed conditions.

Similar to servers in AWS, AVS nodes can be of various general-purpose types depending on power, memory, bandwidth, and geographical location, as well as offering specific features like increased RAM, GPU, and storage volume.

After initialization, the following processes occur within Cambrian:

• It checks if the necessary number of nodes with the required power from workers (operators) with the specified token amount in restaking is available.

• It checks if the given AVS has enough collateral contributions to pay for its work and ensure good behavior.

• If both verification steps are successful, Cambrian schedules the workload for the workers.

• After all workers complete their workload, Cambrian verifies the result using the consensus mechanism.

• If the answer is satisfactory, it is passed on-chain.

Those employees (operators), who gave normal results and perform their work smoothly and in good faith, receive rewards depending on the proposed conditions.

And those workers (operators) who could not perform their work well (low uptime, unscrupulous behaviour) get slashing (more about this in the "Slashing" section).

Thus, this process appears fairly straightforward, but it is the core that enables the restaking process to function and forms a novel market for shared security.

Middleware:

Middleware is a term that refers to a layer or complex of technology software to enable interoperability between different applications, systems, components.

Currently, many dApps rely on additional services that Solana Validators and the Solana Virtual Machine (SVM) cannot provide directly. These required components are known as Middleware. Overall trust in these services is inextricably linked to trust in Middleware.

Middleware can be represented by the services and usecases we discuss in the "Usecases" section: data availability, coprocessors, FHE, TEE, MEV management, oracles, sidechains, threshold cryptography schemes etc. And there may be new usecases that have not even been invented yet. Middleware is software that runs on AVS and Cambrian.

That is, depending on the angle of view, Middleware can be either Cambrian, which powers the AVSs, or the AVSs themselves, which powers the dApps.