Decentralized SPO Computing

Milestone Owner: Dagim Sisay - @dagiopia

Summary

NuNet enables SPOs to run computing workflows on community provisioned hardware, increasing resilience and aiding decentralization. The project is financed via grant from Cardano Catalyst Fund7. See project's short summary and full proposal on Catalyst or GDrive.

Main functionalities

Secure sandbox on user provided compute device;
Secure shell access for the node operator;
Compensating compute providers with NTX-ADA;
Pool data persistence infrastructure;
Appropriate device onboarding and management.

Demo

Demo showing how to download, install, onboard and list peers on NuNet network using a NuNet CLI.

Architecture by phase

Phase 1: It accomplishes above main functionalities 1, 2 and 5.

flowchart LR
    user((End user\n SPO))
 
    subgraph Service Provider's machine
       webapp[WebApp, UI\n or cmd line binary\n]
       dms1[DMS]
       adapter1[Adapter]
       webapp -- 1 - REST API -->dms1
       dms1 -- 2 - gRPC -->adapter1
    end

    user-->webapp

    subgraph Compute Provider's machine
       dms2[DMS]
       adapter2[Adapter]
       service[Cardano Node\ninside Firecracker Image]
       adapter2 -- 4 - gRPC -->dms2
       dms2 -- 5 - run VM image -->service
     end

    adapter1 -- 3 - py-ipv8 <-->adapter2
    user -- 6 - shell access through py-ipv8 \nbetween both DMSs/Adapters <-->service

DMS receives requests from the SPO to find a machine and run a Cardano node. The DMS has a REST API and the service provider can construct his own application like WebApp or GUI. We have a command line binary that is deployed with the DMS and calls the DMS REST API.
DMS passes these requests using gRPC to the Adapter on the service provider's machine.
The Adapter on the service's machine talks to the Adapter on the compute provider's machine via py-ipv8.
The Adapter on the compute's machine calls the local DMS using gRPC to inform the requests received.
DMS on the compute's machine run a firecracker image with a Cardano Node.
This firecracker image is encrypted and allows the operator to send commands via shell access through the py-ipv8 network. Actually this connection is not directly as in the diagram, it passes through the DMSs and Adapters on service and compute provider's machines.

Phase 2: It compensates compute providers with NTX-ADA, move adapter functionalities to DMS and change py-ipv8 to libp2p.

flowchart LR
    user((End user\n SPO))
 
    subgraph SPO's machine
       webapp[WebApp, UI\n or cmd line binary\n]
       dms1[DMS]
       webapp -- 1 - REST API -->dms1
    end

    user-->webapp

    subgraph Compute Provider's machine
       dms2[DMS]
       service[Cardano Node\ninside Firecracker Image]
       dms2 -- 4 - run VM image -->service
     end


    subgraph NuNet Infra
       blockchain[Cardano Node]
       oracle[Oracle]
       oracle -- 2 - Smart contract -->blockchain
    end

    dms1 -- 3 - libp2p <-->dms2
    dms1 -- 2 - gRPC -->oracle
    user -- 5 - shell access through libp2p\n between both DMS <-.->service

DMS receives requests from the SPO to find a machine and run a Cardano node. The DMS has a REST API and the service provider can construct his own application like WebApp or GUI. We have a command line binary that is deployed with the DMS and calls the DMS REST API.
Deals with tokenomics API: open/close a payment channel, put cost of work into the escrow, sign contract, verify the funds, release funds to compensate computational resources
DMS passes these requests using libp2p to the DMS on the compute provider's machine.
DMS on the compute's machine runs a firecracker image with a Cardano Node.
This firecracker image is encrypted and allows the operator to send commands via shell access through the libp2p network. Actually this connection is not directly as in the diagram, it passes through the DMSs on service and compute provider's machines.

Phase 3: It adds pool data persistence infrastructure.

TBD