2 releases
0.5.1 | Aug 4, 2022 |
---|---|
0.5.0 | Aug 4, 2022 |
#13 in #ddc
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
~5–18MB
~222K SLoC