created_at2022-08-04 12:15:17.697684
updated_at2022-08-04 14:31:03.008054
descriptionDDC v2 Smart Contracts -- Orchestrate the network around clusters and buckets



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


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

    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

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

Buckets and Clusters

    actor App

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

        App ->> Contract: deposits funds

Nodes and Apps

    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 -- 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

Commit count: 0

cargo fmt