Consumer is a SONM user which buys and uses the computing resources of other users (Suppliers) through the system. The purpose of the Consumer is to perform a specific task in an optimal way (most quickly, most cheaply, by the price / speed criterion, most reliably, or others).
Every Consumer should have his own Ethereum account, that is his unique identifier.
For Consumer main algorithm of using SONM is:
Full description about getting started as a Consumer is here.
Every Supplier should have his own Ethereum master account, that is his unique identifier. The master account receives all incomes and hold Supplier's profile and rating, enables Worker monitoring and setting up.
For Supplier main algorithm of using SONM is:
Full description about getting started as a Supplier is here.
Account is the Ethereum blockchain address. Cryptocurrency Ether and Ethereum tokens (SONM token and others) can be transferred between accounts.
Account address is a unique identifier for SONM user or Worker.
Any operation in SONM must be digitally signed by account's private key. The private key and account's address are generated while creating account. Generated private key and address are stored in a keystore file (UTC/JSON). SONM doesn't support other types of private key format.
You should always keep your account's keystore file and its password secure, because anyone can use your private key to spent all your tokens and Ether from your account. It's highly recommended that you use different accounts to operate SONM and to store your Ether and other ERC20 tokens.
Account usage for Consumers and Suppliers differs, see details below.
Using accounts by Consumer
Every SONM Consumer has one account. The Consumer can have multiple accounts, in that case SONM will treat these accounts as different Consumers. For example the Consumer needs to get a dedicated KYC certificate for each of his accounts.
SONM components' account usage:
Using accounts by Supplier
Every Supplier must have his own Ethereum master account, that is his unique identifier. The master account receives all incomes and holds Supplier's profile and rating. The account must be pointed in each Worker's configuration, it's mandatory option.
Supplier can also have optional administrative accounts to manage Workers while reducing risk of disclosing his master account's private key that can lead to loosing earned tokens, invalidating Supplier's rating and certificates. The adminitrative account can be use to monitor and setup Workers. Supplier can setup several administrative accounts. The accounts should be pointed in each Worker's configuration.
Furthermore, each Worker will use its own unique account to operate SONM marketplace. This account is connected to master account via special binding procedure. When Worker starts it attempts to register as Worker for selected master account and waits until master accepts the binding. Worker will not sell resources until master binding is not set up correctly.
Supplier's SONM components:
Resources are computer capacities for performing computational tasks: CPU, GPUs, RAM, storage and network. Computing resources are sold and bought on SONM market. But computing resources cannot be traded separately, they must be combined into virtual instance, similar to cloud provider's VDS instances. Each instance includes CPU(s), RAM, storage, network and optional GPU(s).
Computing resources of Suppliers may vary, for example one Supplier can have old Intel Celeron processor, others can use brand new Intel Xeon processor. But Customers need a uniform pricing for the resources, the less performant resource is, less expensive it should be on the market. To solve the problem SONM uses resource benchmarks.
The benchmark concept is somewhat similar to virtual CPU (vCPU) concept used by cloud providers. One cannot sell or buy selected nubore of cores, but one need to select a desirable (for Customers) and existing (for Suppliers) measure of a certain benchmark. For example, you cannot buy an instance with 3x NVidia GeForce GTX 1070 GPUs, but you can buy an instance with 75 MH/s Ethereum hashrate, or 20 GFLOPS. Ethereum hashrate and GFLOPS are two different benchmarks for GPU in that example. A Customer may set one or any subset of benchmarks in his BID-order, Supplier must provide all of benchmarks in his ASK orders. The list of available benchmarks is system-wide. It is updated by SONM team on regular basis to improve user experience.
Benchmarks are key-value pairs with int64 values. They are used while matching orders on the market. All BID order benchmarks must be less or equal than consequent ASK order benchmarks.
Order is data record that includes request to buy or sell specific computing resources.
Order is a placed offer on the Marketplace:
Order is characterized by the following parameters:
SONM performs decentralized orders matching according to the orders properties.
ASK order lifecycle
ASK orders are automatically created and placed on the Market by Worker for available resources. After the order is placed Worker monitors the Market searching appropriate BID orders to match. If the match is found Worker initiates deal creation.
When deal is settled ASK order is automatically inactivated by Market smartcontract.
When deal has finished, Worker node automatically place ASK order on the Market again.
BID order lifecycle via CLI
Consumer places a BID order directly on the Market using CLI.
When the order is placed Consumer's Client node monitors the Market searching appropriate ASK orders to match. If the match is found Worker initiates deal creation.
When deal is settled, BID order is automatically inactivated by Market smartcontract.
When the deal has finished, Consumer may place a BID order using CLI again.
Deal is a contract between Consumer and Supplier on the basis of their ASK and BID orders through the Ethereum smart contract in SONM blockchain, confirmed by SONM blockchain consensus and paid automatically through SONM blockchain tokens.
Deal can be time-bound (forward) or spot.
Forward deals have fixed duration (days, hours, minutes) guaranteed by Worker. That means Worker can't stop the Deal before it finishes. Still Consumer can stop the deal at any moment.
Spot deals don't have any specific duration. The deal can be closed by any side at any moment.
Deal settlement can be set up via two options:
After the Deal is settled, Worker periodically bills Market to receive SONM blockchain tokens earned and to freeze extra tokens from Consumer for the next timeframe. If the tokens could not be frozen, the Deal is autmatically closed.
Both Consumer and Supplier can initiate Change Request for changing Deal duration and price. Other side should approve duration or price change for changes take effect.
Consumer can stop Deal at any moment. Consumer can indicate to blacklist the Supplier while the Deal is closing, if he understands that resources provided are lower than he ordered.
Task is a computational or other task, which can be performed on computer resourses for a certain time.
Task is characterized by the parameters of the resource, which is necessary for its implementation and additional parameters.
Docker is used to perform Consumer's tasks in SONM. Task can be packaged in a Docker container and then effectively performed on Supplier's resourses.
SONM uses a dedicated blockchain for internal decentralized algorithms. SONM blockchain is much faster than Ethereum as it issues a block each 2-3 seconds. Moreover, it has no payments for gas, incentivising micropayments and small resource allocation contracts.
SONM blockchain is based on Ethereum technologies. Technically speaking it is a separate Ethereum network with unique genesis block and patched mining nodes that enable custom DDoS protection. Decentralised components of SONM are hist on SONM blockchain as Ethereum smartcontracts. For example, Market is a smartcontract that is responsible for order processing, deal processing and payments.
To convert SONM tokens between SONM blockchain and Ethereum the Gate is used.
Virtual currency used for payments in SONM is SONM token.
It is a ERC-20 standard token, based on Ethereum. The token is published both on Ethereum main network and in SONM blockchain. In the latter case the token is called SONM blockchain token. The tokens in both blockchains can be converted between each other at rate 1:1 using Deposit and Withdraw functions od SONM GUI.
Token's purpuse is to be used as a payment carrier for SONM computing power market. Token is designed as an utility token (not a securities) according to Singapore law (SFA, FAA), juridical practice and MAS definitions.
Each deal has a price in USD, but all transactions are made in SONM blockchain tokens using current SONM token rates on major cryptocurrency exchanges (Binance, Okex and others).
When the Comsumer creates a BID order, some tokens are prepaid for the future deal and are transferred to SONM Market:
If the Consumer cancelles the order, the tokens are returned him back.
After the deal is settled Worker initiates deal billing and tokens for the deal time already spent are transferred to his Master's account.