#cluster #provider #contract #bucket #smart-contracts #ddc #around

nightly no-std ddc_bucket

DDC v2 Smart Contracts -- Orchestrate the network around clusters and buckets

2 releases

0.5.1 Aug 4, 2022
0.5.0 Aug 4, 2022

#9 in #ddc

Apache-2.0

135KB
2.5K SLoC

DDC Concepts

Problem Statement:

  • Organizing a service between service providers and users.
  • Make it easy for users.
  • Make it flexible for app developers.
  • Support access control and encryption.
  • Support replication, recovery, scaling.
  • Support multiple types of services.
  • Validate the quality of service.
  • Manage flows of payments and custody of deposits.
  • Be reachable from web apps.

The functionalities are separate between DDC core and a number of DDC engines.

DDC Core

The core of DDC is responsible for the following tasks.

  • discover available services, and details to decide to what services to subscribe. E.g., engine name and version, some identity or reputation of providers.
  • discover how to connect to nodes (URLs, etc) to obtain the service.
  • discover the status of a user’s subscribed services, including one’s own.
  • identify the owners or parties authorized to use subscribed services.
  • advertise the existence of one’s provided services.
  • discover the price of services.
  • pay for services on a recurring basis.
  • calculate due fees and verify payments.

This is achieved by a smart contracts, interfaces, and data formats.

DDC Engines

A DDC engine does this:

  • register the details of a node running the engine into the core.
  • store data.
  • respond to queries.
  • authorize operations in the engine as specified by the subscriber.
  • verify that sufficient payments were received or are expected to be received.
  • collaborate with other nodes for partitioning and replication of services.
  • provide a method of validation of the quality of service.
  • consent to the validation process and its eventual consequences.

DDC Core Smart Contract

Cluster

A cluster is the main coordination point between a set of nodes and a set of users.

Governance of a cluster.

There are several decisions required to organize a service around a cluster:

  • Which providers and which nodes are semi-trusted to provide correct services.
  • Whether a node should be removed from the cluster, and which new nodes should take on its service responsibilities.
  • Whether a provider actually did provide correct services and is entitled to payments.
  • Whether a provider misbehaved and should be penalized or excluded.
  • To update the cluster metadata if necessary.
  • To change the governance scheme of the cluster.

A cluster may be managed by a trusted party using an external account, or by a smart contract. A smart-contract-as-manager may in turn take cluster-related decisions by consensus of several accounts in a multisig, by consensus of a community in a DAO or a reputation system, and by cryptonomics such as proof-of-storage based on zero-knowledge crypto, or by connecting to the nominated-proof-of-stake mechanism of the blockchain itself.

Interactions between parties

  • Providers registers Nodes. node_create
  • Providers signal trust to a Manager. node_trust_manager
  • Manager creates a Cluster and reserve some capacity from Nodes. cluster_create cluster_reserve_resource
  • Owner creates a Bucket in a Cluster. bucket_create
  • Owner deposits some funds. account_deposit
  • Owner or Manager report Bucket resource usage. bucket_alloc_into_cluster
  • Manager collects funds from Owner to the Cluster pool. bucket_settle_payment
  • Manager distributes the funds to Providers. cluster_distribute_revenues

Providers and Clusters

sequenceDiagram
    actor Provider
    participant Contract
    actor Manager

    Provider ->> Contract: trusts a manager
    Provider ->> Contract: registers his nodes

    Manager ->> Contract: discovers and selects nodes
    Manager ->> Contract: creates a cluster

    loop
        Manager ->> Contract: maintains the cluster
        Contract ->> Provider: distributes payments
    end

Buckets and Clusters

sequenceDiagram
    actor App

    App ->> Contract: discovers and selects a cluster
    App ->> Contract: creates a bucket

    loop
        App ->> Contract: deposits funds
    end

Nodes and Apps

sequenceDiagram
    actor App

    App ->> Node: requests a service within a bucket
    Node ->> Contract: checks the status of the bucket
    Node ->> App: serves the request

Interactions between contract components

graph LR

    Bucket[[Bucket]]
    Account[Account]
    Cluster((Cluster))
    Node[(Node)]

    Bucket -- is owned by --> Account
    Bucket -- uses resources --> Cluster

    Cluster -- reserves resources --> Node
    Cluster -- takes payments from --> Account

    Node -- is owned by --> Account
    Cluster -- distributes payments to --> Account

An example network

graph BT;

Cluster_1((Cluster 1))
Cluster_1 -. is managed by ..-> Manager_1
Cluster_1 -- vNode_0 --> Node_1
Cluster_1 -- vNode_1 --> Node_2
Cluster_1 -- vNode_2 --> Node_1
Cluster_1 -- vNode_3 --> Node_2

Node_1[(Node 1)]
Node_1 -. is owned by .-> Provider_1

Node_2[(Node 2)]
Node_2 -. is owned by .-> Provider_2

Bucket_1[[Bucket 1]]
Bucket_1 -. is owned by ...-> User_1
Bucket_1 -- is allocated into --> Cluster_1

Dependencies

~6–11MB
~196K SLoC