Mathematical Model of Billing for TheOoL DAO

TheOoL DAO: Functional Purpose and Principles of Organization

Internet TheOoL.net (Nenashev & Khryashchev, 2019; Nenashev et al., 2021; TheOoL White Paper, 2022) is a decentralized application (DApp) (Marchesi et al., 2020; Wu, 2019) that implements DAO algorithms. It combines the functions of private web hosting, a secure audio-video-text communication system and a payment system, as well as an environment for developing and executing custom DApps. DAO TheOoL at the user level implements two main principles (Nenashev et al., 2021; TheOoL White Paper, 2022): abstraction of the user and user data from the technology of their processing, storage and delivery; management of information and its distribution solely by the user-owner of this information. The implementation of the first principle, on the one hand, excludes the identification of the ownership of information by a specific user by the owners of the technical infrastructure where information is directly stored and processed, and on the other hand, it excludes the possibility of disrupting the operation of this infrastructure by user actions. The second principle is aimed at ensuring the complete anonymity of the network participant, suppressing his digital footprint.

On a technical level, TheOoL.net is a peer-to-peer network of data storage, processing and access nodes that provides users with private network space and full control over their digital footprint. Network communication in this network provides affordable, high-speed cloud services for secure distributed computing and cloud storage, as well as tools for automatic price regulation within the system (Nenashev & Khryashchev, 2019; Nenashev et al., 2021; TheOoL White Paper, 2022). Designed primarily to build ultra-secure geographically distributed corporate automated information systems with low information security and infrastructure maintenance costs (Nenashev & Khryashchev, 2019), TheOoL.net can be used by private network participants as a private network space.

TheOoL DAO: Classification of Participants and Analysis of Activities

TheOoL.net defines three classes (roles) of participants: providers of computing resources (performers), content owners/providers (customers), and content consumers (readers).

The Contractor provides for a fee the computing resources belonging to him, while providing the QoS level required by TheOoL.net rules.

The customer places the content in the TheOoL cloud on the computing resources of the performers. At the same time, it determines the QoS requirements, the content retention period, and the number of content backups. When placing content, the customer determines the order of access to content by readers: exclusive (m), group (g) (with the ability to edit (rw) or without it (r) or public (p), paid (c) or free (f).

The exclusive storage mode assumes a level of security comparable to storing data on a personal computer offline. In this mode, access to content and information about the existence of content in the TheOoL network is available only to the customer. Group access, regardless of the mode (rw or r), provides security comparable to working in an isolated local network, with the exception of controlling access to the work nodes of readers - members of an admitted group, if they are outside a certain controlled zone. In this case, the effectiveness of the subsystem of protection against unauthorized access built into TheOoL nodes is determined solely by the personal discipline of readers. The public order of access allows access to read content to any reader in the TheOoL network but does not allow you to determine the customer - the owner of the content, nor does it allow the customer or other persons to collect information about content readers.

A certain legal relationship (smart contract) is established between readers and the content owner within TheOoL DAO, which determines the rules and order of access to content: access time parameters, access mode [r/rw; c/f]. If a public access order is established, an open contract with access mode [r; f] signed by the customer. For readers, the smart contract in the modes [r/rw; f] is advisory in nature and does not require their consent at the time of its generation. Smart contracts in [r/rw; c] require the mandatory consent of all parties. The customer forms [r/rw; c] and sends it to many potential readers as an offer, which they can accept at their discretion during the validity period of the smart contract. Simultaneously with the conclusion of a contract between the customer and his readers, when placing content, a smart contract is formed between the customer and a group of performers.

TheOoL DAO: Classification of Financial Interactions

Internet TheOoL.net assumes that the services of performers and access to content within the framework of smart contracts must be paid for and some commission must be charged from each payment. Since integration with an external payment service can lead to a number of vulnerabilities, an internal payment tool was implemented that allows billing and payments to be made directly inside the secure space of TheOoL DAO. The methods for constructing a mathematical model for billing the TheOoL network are determined by the architecture of this network, its purpose and the mathematical model of the network, which is a queuing network designed to process large sets of structured data in real time (Nenashev et al., 2021).

For the purposes of this study, 2 main classes of financial interactions (smart contracts) can be defined in TheOoL network: 1. Reader-customer interaction; 2. Interaction between the customer and the performer. From the point of view of building a billing system, interactions of the first class are of no interest, since the parameters of contracts and the order of their execution are determined by counterparties voluntaristically. Therefore, we will focus on the interactions of the second class, the rules of which completely determine the algorithms of the network.

Mathematical Model of TheOoL DAO Billing

Billing in TheOoL DAO begins with the fact that the contractor forms an offer towards an arbitrary customer (public offer) when registering the contractor's hardware node. The performer node in the network characterizes the rating ${\epsilon }_j\left(t_i\right)$, which is the ratio of the availability functions $d\left(t_i,d\left(t_{i-1}\right)\right)$ and performance $r\left(t_i,\stackrel{-}{V_j}\right)$ of the node:

${\epsilon }_j\left(t\right)=r\left(t_i\stackrel{-}{V_j}\right)/d\left(t_i,d\left(t_{i-1}\right)\right)$ (1)

Here $t_i=t_{i-1}+\delta ,i=\stackrel{-}{\mathrm{О}\dots k}$ is a discrete moment of time in the interval, $\left[t_0,t_k\right]$, $t_0$ is the moment of registration of the executor node in the network, $t_k$ is the moment of exclusion of the executor node from the network, $\delta$ is a discrete time step, $\stackrel{-}{V_j}$ is the vector of available node resources at time $t_i$ taking into account the queue of jobs (Nenashev et al., 2021), $j=\stackrel{-}{1\cdots {\xi }_c}$ is the sequence number (identifier) of the node among ${\xi }_c$ available performer node system.

At time $t_0$ the primary rating of the node ${\epsilon }_j\left(t_i\right)$ is performed. The network requirements for the availability factor are determined by the equation $\mathrm{0,9}\pm \mathrm{0,05}\le d(t_i,d\left(t_{i-1}\right))$. At the time of network initialization, the availability factor is $d\left(t_0\right)=1$, and then it is determined by the functional:

$d\left(t_i,d\left(t_{i-\mathrm{1}}\right)\right)=\left\{\begin{array}{c}\mathrm{1},\mathrm{}\mathrm{}\mathrm{i}=\stackrel{-}{\mathrm{0}\dots \mathrm{100}}\\ d\left(t_i,d\left(t_{i-\mathrm{1}}\right)\right),\mathrm{}\mathrm{}i>\mathrm{100}\end{array}\right.$ (2)

If the availability parameter is below the expected values for 50 evaluation cycles, the performer node will be forcibly removed from the network.

After being included in the network, each node sets a calculated rating and forms a pool of public offers to use its resources in one configuration or another. Thus, a vector of prices for the use of the computing resources of the node ${\stackrel{-}{C}}_j^c$ will be formed, which contains the minimum prices acceptable for the owner of the node. Each coordinate ${\stackrel{-}{C}}_j^c$ is equivalent to the coordinate $\stackrel{-}{V_j}$, in other words, the sets of coordinates of these vectors are equivalent: $\left|{\stackrel{-}{C}}_j^c\right|=\left|{\stackrel{-}{V}}_j\right|$. Additionally, each executor node is assigned a queue of unaccepted works ${\psi }_j\left(t_i\right)$ and based on $\stackrel{-}{V_j}$ the maximum length of the queue of unaccepted works ${\phi }_j\ge \left|{\psi }_j\left(t_i\right)\right|$ (Nenashev et al., 2021). From the public offers of the executor nodes $P_j\left(t_i\right)=\left\{{\epsilon }_j\left(t_i\right),{\stackrel{-}{C}}_j^c,\stackrel{-}{V_j},{\psi }_j\left(t_i\right),{\phi }_j\right\}$, taking into account (1) and (2), a set of $K$ public offers for the provision of computational resources available to the customer at time $t_i$:

$K=\left\{\begin{array}{c}{P}_1\left(t_i\right)\\ \dots ,\\ P_{{\xi }_c}\left(t_i\right)\end{array}\right\}$ (3)

The set K remains relevant until the end of the cycle and is updated at time $t_{i+1}$.

If it accepts an offer from a node owned by a specific contractor, the contractor receives a reward from this customer through the TheOoL payment subsystem. As an address for receiving payment for performing computational work, the network uses the identifier of the node (j), which belongs to a particular performer ${\Lambda }_c=\left\{{\omega }_c,{\Omega }_c,{\Xi }_c\right\}$, here ${\omega }_C=\left\{skey,pkey,UID\right\}$ is the identifier of the key $skey$, public key $pkey$ and network identifier $UID$, which is also the main address for receiving rewards, ${\Omega }_c=F\left({\omega }_C{\Xi }_c\right)$ - a set of pseudo addresses for accruing rewards generated for each j-th node belonging to the performer from the set ${\Xi }_c\in \left[1,{\xi }_c\right]$. When receiving income from the execution of offers $P_j\left(t_i\right)$, an abstract movement of funds $j\to {\omega }_c^j,{\omega }_c^j\in {\Omega }_c$ is recorded in the blockchain of the built-in payment system TheOoL, but in fact, the movement $j\to {\omega }_c$ is performed, which is verified by a group of 3 randomly selected nodes consensus, which confirm the legitimacy of debiting from j account "nowhere" and crediting to account ${\omega }_c$ "nowhere". Thus, information about the owner of the executor nodes is not available for external analysis, except for the fact that a particular ${\omega }_c$address receives rewards from owning unknown nodes in the set $\left[1,{\xi }_c\right]$ (due to the presence of such incoming transactions).

The customer, for his part, places in the TheOoL network a computational task (content) $L_m={\{l}_1^m,\dots l_n^m\},m=\stackrel{-}{1\dots {\xi }_q}$, which is divided by the algorithm of the subscriber node into elementary subtasks $l_r^m,r=\stackrel{-}{1\dots n}$ (Nenashev et al., 2021). Then one sets the network requirements and access parameters $B_m=\left\{B_1^m,\dots ,B_n^m\right\},m=\stackrel{-}{1\dots {\xi }_q}$, determines the maximum acceptable price level $C_m=\left\{{\stackrel{-}{C}}_1^m,\dots ,{\stackrel{-}{C}}_n^m\right\},m=\stackrel{-}{1\dots {\xi }_q}$, indicates the lifetime of the computational task in the network $T_m$ multiple of $\delta$ and the requirements for QoS by specifying the minimum allowable rating level of the executor node ${\epsilon }_m$. Moreover, $\left|L_m\right|=\left|B_m\right|=\left|C_m\right|$. The elementary tasks $w_r^m={\{T}_m,{\epsilon }_m,l_r^m,B_r^m,{\stackrel{-}{C}}_r^m\},r=\stackrel{-}{1\dots n}$ obtained in this way are connected into the super task $W_m=\left\{\begin{array}{c}{T}_m\end{array}\right.,{\epsilon }_m,\begin{array}{c}{L}_m\end{array},\begin{array}{c}{B}_m\end{array},\begin{array}{c}{C}_m\end{array}\}$ with a common address for charging and debiting payments m, and the product $T_m\bullet \begin{array}{c}{C}_m\end{array}$ determines the rules for their further distribution among subaccounts $r,r=\stackrel{-}{1\dots n}$ associated with elementary subproblems $l_r^m$. Then from (3) we select a suitable performer

$P=\underset{\sum {\stackrel{-}{C}}_j^c}{min}\left\{P_j\left(t_i\right)\right|({\epsilon }_m\ge {\epsilon }_j\left(t_i\right))\wedge \left({\phi }_j\ge \left|{\Psi }_j\left(t_i\right)\right|\right)\wedge \left(\sum {\stackrel{-}{C}}_j^c\le \sum {\stackrel{-}{C}}_r^m\right)\wedge \left(\forall {\mathrm{}B}_r^m\le \forall \mathrm{}\stackrel{-}{V_j}\right)\}$

For each $w_r^m\in W_m$ we write this $w_r^m$ to the queue of unaccepted jobs of the executor node selected for it $w_r^m\Rightarrow {\Psi }_j\left(t_i\right)$.

At time $t_{i+1}$ the control algorithm generates smart contracts $S{K}_m=F_{SK}\left(\left\{s{k}_1^m,\dots ,s{k}_n^m\right\}\right),s{k}_r^m=F_{sk}\left(w_r^m,P\right),r=\stackrel{-}{1\dots n}$, where $F_{SK}$ and $F_{sk}$ are predefined scripts of smart contracts for the execution of the customer’s computational task and its elementary subtask, respectively. The actual payment (transfer of funds from the customer to the contractor) is performed at the end of each discrete step $\delta$, which allows the contract to be automatically terminated ahead of schedule if the contractor violates the established QoS requirements. In this case, a new executor node is assigned to execute the task.

The customer, like the contractor, has the identifier ${\omega }_z=\{skey,pkey,UID\}$ in which the $UID$, like the contractor, plays the role of the main address for crediting or debiting payments. The customer transfers funds to this address to pay for the services of contractors from external payment systems through interfaces built into TheOoL payment system. The processing of customer payments related to the execution of tasks set by him in the TheOoL network is carried out through the payment virtualizing entity ${\Lambda }_z=\left\{{\omega }_z,{\Omega }_{z,}{W}_z\right\}$, which contains a set of addresses of existing super contracts $W_z$ and ${\Omega }_{z,}=F({\omega }_z,W_z)$ - a set of pseudo addresses for transferring rewards due to the performers of the m-th contract from the set $W_zϵ\left[1,{\xi }_q\right]$. When making payments, the abstract movement of funds ${\omega }_z^m\to m,{\omega }_z^m\in {\Omega }_z$, but in fact, the movement ${\omega }_z\to m$, which is verified similarly to the process of moving rewards to the accounts of performers, which makes it possible to hide the content of the customer's payments from an external observer, except for the very fact of their commission.