Charging for resource usage in a distributed network

Abstract

Aspects of the present invention relate to a computer-implemented method for accounting for and paying for the use of resources of a distributed network, the distributed network comprising a plurality of nodes, each configured to execute one or more computing units. The one or more computing units comprise one or more application units that provide application services to users of the distributed network. The embodied method comprises each network user executing one or more local user gas accounts in one or more of the application units, and processing payments for the use of resources of the distributed network via the local user gas accounts. Further aspects relate to a distributed network, a node of the distributed network, and a corresponding computer program product.

Description

[Technical field]

[0001] The present invention relates to a computer-implemented method for charging for the use of resources in a distributed network.

[0002] Further aspects relate to a distributed network, nodes of the distributed network, corresponding computer program products, and software architectures encoded on non-transitory media. [Background technology]

[0003] In a distributed network, multiple nodes are distributed. In computing, software and data are distributed across multiple nodes. The nodes define computing resources, and the distributed network may use distributed computing techniques.

[0004] An example of a distributed network is a blockchain network. A blockchain network is a consensus-based, block-based electronic ledger. Each block consists of transactions and other information. Additionally, each block contains a hash of the previous block, and blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain. Transactions may invoke small, well-known programs known as smart contracts.

[0005] In order for a transaction to be written to the blockchain, it needs to be "verified" and agreed upon by the network. In other words, the network nodes need to reach a consensus on which block will be written to the blockchain. Such agreement can be achieved through various consensus protocols.

[0006] In one type of blockchain network, consensus is achieved using a proof-of-work algorithm. Proof-of-work consensus protocols typically require work from the parties participating in the consensus protocol, which typically equates to computer time. Proof-of-work based cryptocurrency systems, such as Bitcoin, verify transactions and create new blocks by solving computationally intensive puzzles.

[0007] Another type of consensus protocol is based on the Proof-of-Stake algorithm. Such Proof-of-Stake protocols have the advantage that they do not require a large amount of time and energy for computation. In a Proof-of-Stake based blockchain network, for example, the creator of the next block is selected by a combination of random selection and a stake of each node in the network.

[0008] Consensus protocols used in blockchain networks can be designed to quickly reach a definite settlement of transactions included in a block by applying a "Byzantine Fault Tolerant" (BET) agreement protocol. "Synchronous" BFT protocols rely on the assumption of network synchronization for safety. "Asynchronous" BET protocols, on the other hand, are different. In asynchronous BFT protocols, typically less than 1 / 3 (one third) of the participating nodes can be tolerated being corrupted.

[0009] Apart from cryptocurrencies, distributed networks may be used for a variety of other applications, in particular to provide decentralized and distributed computational functions and services. To this end, distributed networks may use state machine replication protocols to ensure that applications run reliably and preserve state across multiple nodes, even in the presence of node crashes or hostile attacks.

[0010] US Patent Application Publication No. 2018 / 0006872 discloses a data plane API in a distributed computing network. In some embodiments, a distributed computing system includes a plurality of computing nodes that provide resources to users and a hierarchy of two or more tiers of controllers that couple the computing nodes to user interfaces via a control plane, where at least one computing node receives local application program interface (API) calls from applications running on at least the computing node that cause at least one computing node to configure local resources without requiring commands from the control plane.

[0011] US 2004 / 0117224 A1 discloses an apparatus for metering and accounting in a commercial e-services infrastructure. It addresses the requirement of handling composite services where higher level services are built using simpler underlying services, each of which may be autonomously owned and operated. The metering records of each underlying service of the composite service are correlated to allow accounting, on a per request or aggregate basis, for each customer-provider pair in a particular billing period, taking into account the usage and charges associated with the underlying services.

[0012] US Patent Application Publication No. 2004 / 02111665 discloses a method for generating a billing feed for a distributed network system and reselling resources of the distributed network system. In one embodiment, the method includes observing a plurality of messages transmitted and received between components of the distributed network system, generating a call flow diagram based on the plurality of messages of the distributed network system, outputting a charging feed for the distributed network based on the call flow diagram, and providing a billing feed including one or more billable events.

[0013] US 2004 / 02111665 discloses a method for forwarding messages through a network, which is implemented in a router of a distributed network comprising at least one constrained sub-network at the level of OSI Layer 7. The method comprises the steps of processing a unique format for an entire set of messages, identifying for a particular message the next router to be reached for forwarding the message to its recipient or to the recipient, identifying for a particular message a quality of transmission service, assigning a priority to the message as a function of the quality of service requirements identified in the previous step, and adapting the content of the message as it passes through the constrained sub-network.

[0014] One of the challenges of such distributed networks providing distributed computational services is to provide an efficient, flexible and secure billing mechanism for charging users as well as applications for using the network resources that the distributed network provides. Summary of the Invention [Means for solving the problem]

[0015] Accordingly, one object of one aspect of the present invention is to provide a method for charging for the use of network resources in a distributed network, which is advantageous for the computational resources of the distributed network in terms of efficiency, flexibility, and / or security, in particular, by providing a method for payment for or charging for resources.

[0016] According to an embodiment of a first aspect of the present invention, a computer-implemented method for charging or paying for the use of resources of a distributed network is provided. The distributed network comprises a plurality of nodes, each of the plurality of nodes configured to execute one or more computing units. The one or more computing units comprise one or more application units for providing application services to users of the distributed network. The embodied method comprises the steps of users of the network, in particular each user of the network, executing one or more local user gas accounts in one or more of the application units, and processing charges for the use of resources of the distributed network through or by the one or more local user gas accounts. According to such embodied method, local user gas accounts are provided in the one or more application units. Such local user gas accounts may facilitate efficient and flexible charging and payment for the use of resources by users. In particular, the provision of local user gas accounts may effectively reduce the number of messages required to process payments, and therefore may effectively reduce the traffic and associated bandwidth of the distributed network. A local user gas account is a local user gas accounting unit configured to locally pay for the usage of resources of a distributed network.

[0017] A local user gas account is an account executed in each application unit and owned by a corresponding user. The local user gas account is used to locally pay for the use of resources in the distributed network. The local user gas account may be referred to as a local user accounting unit or simply a local user account.

[0018] The resources may generally be physical or virtual resources of the distributed network and may be denoted as network resources. These resources may include computational resources such as the processing power of the processors of the distributed network, memory and storage resources, network connections and their associated bandwidth, e.g., for communication between different application units.

[0019] The resources may in particular be provided by nodes of the network, which may be embodied as computing systems or units, for example servers.

[0020] Charges, or payments, for the use of resources may be made in particular in gas or gas units. Gas may be defined as a complementary accounting unit that a distributed network uses to charge for the use of its resources, separate from the network's home currency. Gas may be referred to as fuel. Providing a complementary accounting unit provides the advantage that the cost of using resources can remain stable and independent from currency market fluctuations. In an analogy with a car, just as fuel or gas is needed to run a car, gas according to some embodiments of the present invention is needed to run the resources of a distributed network.

[0021] The terms "charging" and "payment" are to be understood broadly. They may include payments that are deducted from a local user's gas account and transferred to another account. They may also include application schemes where used gas is only "burned" after use without being transferred to another account. In other words, one may "pay" for the use of resources by "burning" or consuming gas, which is then removed from the network after its use. In this regard, "charging" and "payment" may be used as interchangeable terms.

[0022] A computation unit may be defined as a piece of software running on a node of the network and having its own unit state. According to some embodiments, a computation unit may be defined as a deterministic program with orthogonal persistence.

[0023] An application unit is a computing unit configured to provide application services to users of the network, which may include, for example, hosting websites, booking travel, providing messaging services, etc.

[0024] According to some embodiments, each node of the network executes one or more computational units and therefore maintains unit state for one or more computational units.

[0025] According to one embodiment, the method comprises a further step of a user of the network sending an ingress message requesting a primary application service to a primary application unit of one or more application units, the primary application unit and the primary application service executing a further step including arranging for a fee or payment for the use of resources by the primary application service via or by a local user gas account of the user at the primary application unit.

[0026] According to such an embodiment, the primary application unit sets an entry point for ingress messages of the users. An ingress message is to be understood as a message that a user of the distributed network sends to one of the application units of the network, more specifically to the respective primary application unit. According to such an embodiment, the user needs to have a local user gas account at least at the respective primary application unit, so that fees or payments for the usage of resources can be processed locally via or by the local user gas account at the primary application unit.

[0027] According to one embodiment, executing the primary application service comprises the primary application unit issuing one or more calls to one or more secondary application units.

[0028] Such secondary application units are to be understood as application units which do not directly receive ingress messages from users, but rather receive calls from the respective primary application units which received the ingress messages, in other words, in order to execute a primary application service, the primary application units contain the secondary application units and calls to the secondary application units require the support of the secondary application units.

[0029] It should be noted that the role of an application unit may change over time and may depend, among other things, on each incoming message and the corresponding application service. More specifically, in one example, the same application unit may act as a primary application unit when it receives an ingress message requesting a primary application service, and in another example, the same application unit may act as a secondary application unit when it receives a call from another application unit that acts as a primary application unit.

[0030] According to such an embodiment, the method may further comprise the step of one or more secondary application units executing one or more secondary application services.

[0031] According to one embodiment, the method may further include arranging for payment for the usage of resources by the secondary application service via or by a local user gas account of the primary application unit.

[0032] Thus, the secondary application unit supports the primary application unit in executing the secondary application services, while the primary application unit arranges payment for the use of resources that the secondary application unit requires for the execution of the secondary application services.

[0033] This provides an efficient payment scheme, more specifically, it avoids the user needing a separate gas account at the secondary application unit, and it avoids, for example, any messaging between the user currency account and the secondary application unit.

[0034] According to one embodiment, executing the one or more secondary application services includes the one or more secondary application units issuing one or more calls to the further secondary application units. Further, the method may include the one or more further secondary application units executing the one or more further secondary application services.

[0035] According to one embodiment, one or more calls can be executed in succession, thereby forming a call tree of any depth. According to another embodiment, the method allows a user of the network to execute a local user gas account at the secondary application unit and to process payment for the usage of resources by the secondary application unit through or by the local user gas account of the secondary application unit.

[0036] According to such an embodiment, users need to have local user gas accounts in the primary application unit and the secondary application unit. In such a way, the secondary application unit can directly charge for the use of resources required to execute the secondary application service from the local user gas account held by each user in the secondary application unit. Such a scheme provides more flexibility in charging, especially for applications where the computational amount of the secondary application service is difficult to assess in advance.

[0037] According to one embodiment, the method comprises the further step of each user of the network executing a wallet computation unit configured to manage a user currency account of the user. Further, the embodied method may include the step of sending a payment message from the wallet computation unit to a respective application unit to transfer a currency amount from the user currency account to a local user gas account of the respective application unit.

[0038] Such a method facilitates flexible and efficient resource billing. The user currency account provided by the wallet computation unit may be charged by the user, for example, from a conventional bank account. In this respect, it may provide an (external) interface to various external banking applications or external bank accounts. On the other hand, the user currency account may be used to internally transfer currency amounts from the user currency account to one or more local user gas accounts held by the respective user. This internal currency transfer may be performed by sending a payment message from the wallet computation unit to the application unit hosting the respective local user gas account.

[0039] The wallet computation units may be executed in gas units or another currency, e.g., a cryptocurrency or a stable coin pegged to a classic national currency such as the US dollar or the Euro. The exchange rate between the cryptocurrency or classic national currency and the gas units may be managed by the decentralized network, e.g., by a governance system of the decentralized network. As an example, the decentralized network may provide a global table with one or more exchange rates. According to some embodiments, the decentralized network may adjust the exchange rates to provide a generally stable cost for gas.

[0040] According to a further embodiment, the method comprises a step of each application unit executing a gas account for the application unit.

[0041] Such an application unit gas account makes charging for the use of network resources more efficient and flexible. The application unit gas account may be used to pay for application services, in particular instead of or in addition to the local user gas account. Furthermore, it is possible to charge for the resources that the application unit itself uses, for example its own storage. Furthermore, the application unit gas unit may be used to transfer gas between different application units, in particular between a primary application unit and a secondary application unit involved in a call.

[0042] According to one embodiment, the method further comprises the step of separately charging for receiving ingress messages, reading queries, executing received ingress messages, and / or executing received inter-unit messages, where the inter-unit messages are transmitted between computing units of the network.

[0043] This separate charging allows incorporating different technical charging schemes for different resource usages, can be used to enhance the security of the system and prevent or at least thwart attackers' attacks, and makes the charging scheme more flexible and agile.

[0044] Each local user gas account comprises an ingress subaccount configured to charge for the acceptance of ingress messages, a read query subaccount configured to charge for the reading of queries, and an execution subaccount configured to charge for the execution of messages, in particular the execution of accepted ingress messages and / or the execution of said accepted inter-unit messages.

[0045] This can be used to further improve the security of the system and limit the potential damage caused by faulty or malicious application units. In particular, the distributed network can be configured to specify a minimum balance that each of the separate sub-accounts must have before the distributed network can begin using resources for each request. As an example, a new ingress message is considered for acceptance only if the balance of each of the ingress sub-accounts exceeds a specified minimum ingress balance.

[0046] According to a further embodiment, the method comprises applying different accounting periods and / or charging times to ingress messages, read queries, and inter-unit messages. Such different accounting periods may be used to further facilitate different technical implementations of charging schemes and to prevent or hinder attacks on the distributed network.

[0047] According to one embodiment, the method may include charging for ingress messages when accepting or rejecting them for execution.

[0048] According to a further embodiment, the method includes charging in advance for the execution of an ingress message, in particular after the issuance of one or more calls to the secondary application unit.

[0049] Such an embodiment may effectively prevent or thwart an attack by filling it in the ingress message. More specifically, by charging early at different times, it may ensure that adversarial requested processing stops early, in particular as soon as the respective balances of the sub-accounts fall below the required minimum balance.

[0050] According to a further embodiment, the method comprises subsequently charging for read queries in a bundled manner, for example only after a predefined number of read queries have been executed.

[0051] This allows for more efficient processing of read queries. Such embodiments are particularly useful in distributed networks where application units run on multiple nodes forming a subnet and are replicated across multiple nodes of the subnet. In such networks, read queries do not need to be replicated across multiple nodes of the subnet, but can be processed independently at a single node of the subnet.

[0052] According to a further embodiment, the method comprises providing a separate read query sub-account for each node in each subnet, which may prevent or hinder attacks by flooding a single node with read queries. More specifically, a node may execute a read request only when it has sufficient balance in its individual read query sub-account; read requests are charged only after the fact in a bundled manner.

[0053] According to another embodiment, the method further comprises the steps of charging by the distributed network for usage of the storage resources of the distributed network, and paying from the gas account of each application unit for usage of the storage resources of the distributed network.

[0054] According to some embodiments, each application unit may be charged, for example, for a maximum amount of storage used in a defined period of time.

[0055] According to a further embodiment, the application units, in particular the primary application unit and each of the secondary application units, further comprise a step of charging a fixed price for the use of resources by the primary application unit and / or the secondary application unit, respectively.

[0056] Such a fixed price, on the one hand, facilitates an efficient payment procedure with low communication bandwidth usage, on the other hand, it facilitates fast billing, and furthermore, allows the processing of secondary application unit payments in an elegant and simple manner via the local user account of the primary application unit.

[0057] According to a further embodiment, the method comprises a step of the application units, in particular the primary application unit and / or the secondary application unit, respectively, charging in advance for the use of resources by the primary application service and / or the secondary application service, respectively. Furthermore, the method may comprise a further step of the application units, in particular the primary application unit and / or the secondary application unit, respectively, refunding unused parts of the prepayment.

[0058] This provides more flexibility.

[0059] According to a further embodiment, the method comprises a step of pre-refilling from an application unit gas account of each of the primary application unit and / or secondary application unit to ensure execution of the corresponding primary application service and / or secondary application service.

[0060] This provides more flexibility.

[0061] According to a further embodiment, the distributed network includes a plurality of subnets, where each of the plurality of subnets includes one or more of the plurality of nodes, and the method further comprises assigning each of the application units to one of the plurality of subnets and replicating the application units across each subnet.

[0062] Methods according to some embodiments of the present invention are particularly useful in such distributed networks comprising subnets with replicated application units.

[0063] In particular, the replication may be made easier by performing active replication of the unit state space of the computational units on each node of the execution subset, which according to some embodiments may include, among others, input queues, output queues, system state, and application or user state.

[0064] According to one embodiment, the distributed network is configured to replicate a set of computing units, in particular the state of the computing units, across subnets, so that the computing units of each subnet are always in the same state as long as they behave honestly. Different subnets, in particular computing units of different subnets, may communicate with each other by exchanging inter-subnet messages via messaging and consensus protocols.

[0065] According to an embodiment of another aspect of the present invention, a distributed network is provided.

[0066] The distributed network comprises a plurality of nodes, each of the plurality of nodes configured to execute one or more computing units, the one or more computing units including one or more application units, the application units configured to provide application services to users of the distributed network. The distributed network provides resources to the computing units, and each user of the network is configured to execute one or more local user gas accounts on the one or more application units. The distributed network is further configured to process payments for use of the resources of the distributed network through or by the local user gas accounts.

[0067] According to an embodiment of another aspect of the present invention, a node of a distributed network is provided.

[0068] According to an embodiment of another aspect of the present invention, there is provided a computer program product for operating a distributed network, the computer program product comprising a computer readable storage medium having program instructions embodied therein, the program instructions being executable by one or more of a plurality of nodes of the distributed network to perform, at one or more of the plurality of nodes, steps of the method of the present invention.

[0069] According to an embodiment of another aspect of the present invention, there is provided a software architecture encoded on a non-transitory computer readable storage medium, the software architecture configured to operate one or more nodes of a distributed network. The coded software architecture comprises program instructions executable by one or more of the plurality of nodes to cause one or more of the plurality of nodes to perform a method comprising the method steps of the present invention.

[0070] Features and advantages of one aspect of the invention may be applied to other aspects of the invention as appropriate.

[0071] Further advantageous embodiments are set forth in the dependent claims as well as in the following description. [Brief description of the drawings]

[0072] The invention will be better understood and further objects will become apparent from the following detailed description, such description being made with reference to the accompanying drawings, in which: [Figure 1] FIG. 1 is an exemplary diagram of a distributed network according to one embodiment of the present invention. [Diagram 2] FIG. 2 shows in more detail the computational units implemented in a typical node of the network. [Diagram 3] FIG. 3 is an exemplary diagram of a distributed network comprising multiple subnets according to one embodiment of the present invention. [Figure 4] FIG. 4 illustrates in more detail the computational units implemented in the distributed network of FIG. [Diagram 5] FIG. 5 is a schematic diagram of an inter-subnet message received at a subnet of the network of FIG. 3. [Figure 6] FIG. 6 is a schematic block diagram of the protocol components of a subnet protocol client. [Figure 7] FIG. 7 is an exemplary visualization of the workflow of the message protocol, the consensus protocol, and the associated components. [Figure 8] FIG. 8 illustrates in more detail an application unit according to one embodiment of the present invention. [Figure 9] FIG. 9 illustrates an exemplary local user gas account in greater detail, according to one embodiment of the present invention. [Figure 10] FIG. 10 is a diagram illustrating a billing / payment scheme according to one embodiment of the present invention. [Figure 11] FIG. 11 illustrates another billing / payment scheme according to one embodiment of the present invention. [Figure 12]FIG. 12 illustrates how a user of a decentralized network can recharge a local user's gas account. [Figure 13] FIG. 13 illustrates a billing scheme for read queries according to one embodiment of the present invention. [Figure 14] FIG. 14 illustrates how a primary application unit can use closures to manage calls to secondary application units. [Figure 15] FIG. 15 illustrates a flow chart of various steps of a computer-implemented method in accordance with one embodiment of the present invention. [Figure 16] FIG. 16 illustrates the main processes performed at each node of a network according to an embodiment of the present invention. [Figure 17] FIG. 17 illustrates a layer model showing the main layers involved in the exchange of messages between and within subnets. [Figure 18] FIG. 18 is a diagram illustrating generation of an input block by a consensus component in accordance with an exemplary embodiment of the present invention. [Figure 19] FIG. 19 shows the networking components in more detail. [Figure 20] FIG. 20 illustrates an exemplary embodiment of a node according to the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0073] <Mode of carrying out the invention> First, some general aspects and terminology of embodiments of the present invention are introduced.

[0074] According to one embodiment, a distributed network comprises a number of nodes arranged in a distributed fashion. In computing on such a distributed network, software and data are distributed across the nodes. The nodes define computing resources and the distributed network may use a particular distributed computing technology.

[0075] According to one embodiment, the distributed network may be embodied as a blockchain network, the term "blockchain" including all forms of electronic, computer-based and distributed ledgers.

[0076] FIG. 1 illustrates an exemplary block diagram of a distributed network 100 in accordance with one embodiment of the present invention.

[0077] The distributed network 100 comprises a number of nodes 10, which may also be denoted as network nodes 10 or computing nodes 10. Each of the number of nodes 10 is configured to execute one or more computational units. According to an embodiment, a computational unit is to be understood as a piece of software, in particular a piece of software that comprises or has its own unit state. The number of nodes 10 of the network 100 may be assigned to different subsets and / or subnets. Such an assignment may change over time.

[0078] According to this embodiment, the network 100 comprises a consensus subset of nodes 10 SS1 and an execution subset of nodes 10 SS2.

[0079] The computation units executed in the nodes 100 may be used by users of the network 100 to execute or request computational tasks or services, in particular application services. The computation units of the network 100 may execute, in particular execution messages, from a current set of execution messages. The execution messages may in particular comprise inter-unit messages exchanged between the computation units of the network and / or input messages, i.e. messages received from an external source, in particular from users of the network. The network 100 is configured such that a consensus protocol is first executed to reach agreement on the selection and processing order of execution messages from the respective current set of execution messages. Depending on the number of nodes 10 in the network 100, the consensus protocol is advantageously not executed by all nodes of the network, but only by a subset of the nodes 10 of the network 100, which is denoted below as consensus subset SS1. The consensus subset SS1 may be denoted as consensus subset. In this way, the nodes of the consensus subset SS1 are configured to execute a consensus protocol to reach agreement on the selection and processing order of execution messages from the current set of execution messages.

[0080] The execution of the execution messages may also advantageously not be performed by all nodes of the network 100, but only by a subset of the nodes 10 of the network 100. This subset may be denoted as execution subset SS2 in the following and may be denoted as execution subset SS2. The computational units of the execution subset SS2 then individually execute the selection of the execution messages in the processing order agreed upon in the previous consensus step. Each computational unit of the execution subset SS2 executes the execution in a deterministic manner, thereby modifying the unit state of the corresponding computational unit of the execution subset SS2.

[0081] According to one embodiment, the unit state should be understood as all data or information used by the computing unit, in particular the data that the computing unit stores in variables, but also the data that the computing unit obtains from remote calls. The unit state may in particular represent specific memory locations in the respective memory locations of the respective nodes. The contents of these memory locations at any point in the execution of the computing unit are called the unit state according to the embodiment. The computing unit may in particular be embodied as a stateful computing unit, i.e. the computing unit is designed according to the embodiment to remember previous events or user interactions.

[0082] According to some embodiments, each node in the network is assumed to follow a local clock that is roughly synchronized with the clocks of the other nodes.

[0083] 2 shows in more detail the computation units 15 running on the nodes 10 of the network 100. More specifically, the nodes 10 of the subset SS2 of FIG. 1 are shown with five computation units 15 running on them. More specifically, the five computation units 15 are a set of computation units CU21, CU22, CU23, CU24 and CU25. The set of computation units CU21, CU22, CU23, CU24 and CU25 runs on each node 10 of the subset SS2. Furthermore, the set of computation units CU21, CU22, CU23, CU24 and CU25 is replicated across the subset SS2 such that each of the computation units CU21, CU22, CU23, CU24 and CU25 will end up in the same unit state when they behave honestly. This may be implemented in particular by performing active replication in the unit state space of computing units CU21, CU22, CU23, CU24 and CU25 in each of the nodes 10 of subset SS2.

[0084] The computing units CU may provide different functions and may be of different types. One type of computing unit is an application computing unit configured to provide application services to users of the distributed network. For simplicity, the application computing unit is hereinafter referred to as application unit or AU. Another type of computing unit is a wallet computing unit that may be configured to manage user currency accounts of users of the network. And yet another type of computing unit is a system computing unit. Such a system computing unit may provide system or management functions to the distributed network.

[0085] FIG. 3 illustrates an exemplary block diagram of a distributed network 300 in accordance with one embodiment of the present invention.

[0086] The distributed network 300 includes a plurality of nodes 10 .

[0087] According to this embodiment, the multiple nodes 10 are distributed among multiple subnets 11. In the example of Fig. 1, four subnets 11 are provided, denoted SNA, SNB, SNC, and SND. The network 100 comprises a communication link 12 for intra-subnet communication within each subnet 11 and a communication link 13 for inter-subnet communication between different subnets of the subnets 11. Thus, the communication link 12 may also be denoted as an intra-subnet or peer-to-peer (P2P) communication link, and the communication link 13 may also be denoted as an inter-subnet or subnet-to-subnet (SN2SN) communication link. Each of the multiple subnets 11 is configured to execute a set of computing units in each node 10 of the respective subnet 11.

[0088] According to some embodiments of the present invention, subnets 11 are configured to replicate a set of computing units across each subnet 11. More specifically, subnets 11 are configured to replicate unit states of the computing units across each subnet 11.

[0089] The network 100 may in particular be a proof-of-stake blockchain network.

[0090] Proof of Stake (PoS) describes how a blockchain network can reach a decentralized consensus on which nodes can create the next block of the blockchain. PoS methods may use weighted random selection, whereby the weight of each individual node may be determined according to, among other things, the respective node's assets ("stake").

[0091] According to some embodiments of the asynchronous BET consensus protocol, it is assumed that less than 1 / 3 (one-third) of nodes in each subnet are corrupted, making artifacts generated and signed by the subnet fully trustable.

[0092] Figure 4 shows in more detail the computing units 15 executed in the nodes 10 of the network 300. More specifically, on the left side 401 of Figure 4, a node 10 of the subset SNA of Figure 1 is shown in which five computing units 15 are executed. More specifically, the five computing units 15 are a set of computing units CUA1, CUA2, CUA3, CUA4, and CUA5. The set of computing units CUA1, CUA2, CUA3, CUA4, and CUA5 is executed in each node 10 of the subnet SNA. Furthermore, the set of computing units CUA1, CUA2, CUA3, CUA4, and CUA5 is replicated across the subnet SNA such that each computing unit CUA1, CUA2, CUA3, CUA4, and CUA5 has the same unit state. This may in particular be implemented by performing active replication in the unit state space of computing units CUA1, CUA2, CUA3, CUA4 and CUA5 in each of the nodes 10 of the subnet SNA.

[0093] Further, on the right side 402 of Fig. 4, a node 10 of the subnet SNB of Fig. 1 is shown in which four computation units 15 are executed. More specifically, the four computation units 15 are a set of computation units CUB1, CUB2, CUB3, and CUB4. The set of computation units CUB1, CUB2, CUB3, and CUB4 is executed in each node 10 of the subnet SNB. Furthermore, the set of computation units CUB1, CUB2, CUB3, and CUB4 is replicated throughout the subnet SNB such that each computation unit CUB1, CUB2, CUB3, and CUB4 has the same unit state. As described above, we perform active replication in the space of unit states.

[0094] Referring back to FIG. 3, the network 300 is configured to exchange inter-subnet messages 16 between the subnets SNA, SNB, SNC, and SND via messaging and consensus protocols. The consensus protocols are configured to agree on the processing order of the inter-subnet messages 16 at each receiving subnet. For example, for the subnet SNB, it is referred to receiving inter-subnet messages 16 from the subnets SNA, SNB, SNC, and SND. The consensus protocols receive and process these inter-subnet messages 16 and execute a defined consensus algorithm or mechanism to agree on the processing order of the received inter-subnet messages 16.

[0095] According to some embodiments, the network 300 may be configured to run the consensus protocol separately in each subnet. That is, each of the subnets SNA, SNB, SNC, and SND runs its own consensus protocol independently, apart from other subnets. Thus, each of the subnets SNA, SNB, SNC, and SND can determine the order of messages it processes, within a defined range, independently of other subnets. Thus, each of the subnets SNA, SNB, SNC, and SND forms a consensus on a per-subnet basis based on the order of processing of received inter-subnet messages 16. Such a consensus may be considered a local consensus or a subnet consensus.

[0096] This concept is illustrated in more detail with reference to FIG.

[0097] FIG. 5 shows a schematic diagram of an inter-subnet message 16 received at the SNB of the subnet 11 of FIG.

[0098] The subnet SNB receives inter-subnet messages SNA-SNB from the subnet SNA, inter-subnet messages SNC-SNB from the subnet SNC, and inter-subnet messages SND-SNB from the subnet SND. A pool of these inter-subnet messages is processed by a consensus component 30, CSNB, which executes a consensus protocol locally in the subnet SNB. Hence, the consensus component 30 can be denoted as a subnet consensus component.

[0099] The consensus component 30 generates a queue of input blocks IB from the inter-subnet messages according to a predefined consensus algorithm or mechanism, and provides the queue of input blocks IB to the MSNBs configured to execute the messaging protocol for further processing of the input blocks IB.

[0100] According to some embodiments, each of the nodes 10 of each subnet 11 may participate in the consensus protocol. According to such embodiments, each of the subnets 11 may comprise, for example, between 10 and 100 nodes, in particular between 20 and 50 nodes. Such a number may provide an advantageous compromise between security and efficiency.

[0101] According to some other embodiments, the consensus protocol may be configured to elect committee members from multiple nodes 10 in each subnet 11 according to a predefined election scheme and to run the consensus protocol only with the elected committee members. Such an approach is particularly useful in subnets with a large number of nodes, e.g., subnets with 1000 or more nodes.

[0102] FIG. 6 illustrates a schematic block diagram of protocol components 600 of a subnet protocol client, for example, subnet protocol client 42 shown in FIG.

[0103] The solid arrows in Fig. 6 relate to execution messages, which consist of inter-unit messages and ingress messages. Ingress messages can in particular be modification queries from users. The dashed arrows relate to system information.

[0104] The protocol component 600 comprises a messaging component 61 configured to execute a messaging protocol, and an execution component 62 configured to execute an execution protocol, in particular execute inter-unit messages and / or modify queries. The protocol component 600 further comprises a consensus component 63 configured to execute a consensus protocol, a networking component 64 configured to execute a networking protocol, a state management component 65 configured to execute a state management protocol, an X-Net component 66 configured to execute a cross-subnet forwarding protocol, and an ingress message handler component 67 configured to process ingress messages received from external users of the network. The protocol component 600 further comprises a cryptography component 68. The cryptography component 68 cooperates with a security component 611, which may be embodied as a security application 43, for example, as described later with reference to FIG. 16. The protocol component 600 further comprises a state reader component 69 configured to receive read queries, or in other words, read requests from users.

[0105] The state leader component 69 is configured to cooperate with the state manager component 65. Read queries received and processed by the state leader component 69 are specifically embodied as non-modifying queries that do not permanently modify the unit state of the computational units. On the other hand, ingress messages received from the ingress message handler component 67 and passing through the consensus component 63 may be specifically embodied as modifying queries that modify the unit state of the respective computational unit executing the modifying query. Because read queries do not need to pass through the consensus component 63, they can be executed asynchronously at any node in the respective subnet, and are therefore much faster.

[0106] Additionally, the subnet protocol clients 42 may cooperate with a leader component 610, which may be part of the mainnet protocol clients 41, as described with reference to Figure 6. The mainnet leader component 610 may provide information that is stored by the mainnet and distributed to each subnet protocol client 42, including the assignment of nodes to subnets, public keys of nodes, assignment of computing units to subnets, etc.

[0107] The messaging component 61 and the execution component 62 are configured such that all computations, data, and state within these components are replicated identically across all nodes in their respective subnets, and more specifically, across all honest nodes in their respective subnets, as indicated by the waveform background of these components.

[0108] Such identical replication is achieved according to some embodiments, on the one hand, thanks to the consensus component 63, which ensures that the stream of inputs to the message component 61 is agreed upon by the respective subnets and thus identical by all nodes, more specifically by all honest nodes. On the other hand, this is achieved by the messaging component 61 and the execution component 62 being configured to perform deterministic and replicated computations.

[0109] The X-Net forwarding component 66 transmits message streams to and receives message streams from other subnets.

[0110] Most components access the encryption component 68 to execute encryption algorithms and the main net reader 610 to read configuration information.

[0111] The execution component 62 receives the unit states of the computation units and the incoming messages of the computation units from the message component 61, and returns the outgoing messages and updated unit states of the computation units. While performing this calculation, the gas or fuel consumption of the processed messages (queries) may be measured.

[0112] The message component 61 synchronizes with the input blocks received from the consensus component 63. That is, for each input block, the message component 61 performs the following steps: parses each input block to obtain the messages of its computation unit; and routes the messages to the respective input queues of the different computation units and schedules the messages to be executed according to the capacity allocated to each computation unit by the scheduler. Then, using the execution component 62, the messages are processed by the corresponding computation unit and the resulting messages to be sent are added to the output queues of the respective computation units. However, if the message is destined for a computation unit in the same subnet, it may be directly put into the input queue of the corresponding computation unit. The messaging component 61 finally routes the messages in the output queues of the computation units to the message streams of the subnet where the receiving computation unit is located and forwards these message streams to the state manager component 65 to be authenticated, i.e., signed by the respective subnet.

[0113] The state manager component 65 includes an authentication component 65a configured to authenticate the output streams of each subnet, which may be performed, for example, by a group signature of the computing units of each subnet.

[0114] Authentication component 65a may be further configured to authenticate certain variables of the unit state, and in particular, certain variables of the unit state snapshot, as described in more detail below.

[0115] Fig. 7 shows an exemplary visualization 700 of the message and consensus protocols and associated components, e.g., message component 61 and consensus component 63 of Fig. 6. More specifically, Fig. 7 visualizes the workflow of inter-subnet messages exchanged between a subnet SNB and subnets SNA and SNC. Furthermore, the subnet SNB exchanges incoming messages with multiple users U.

[0116] Starting at the bottom right of Figure 7, multiple input streams 701, 702 and 703 are received by consensus component 63. Consensus component 63 is a subnet consensus component executed by a subnet client of subnet SNB. Input stream 701 includes inter-subnet messages 711 from subnet SNA to subnet SNB. Input stream 702 includes inter-subnet messages 712 from subnet SNC to subnet SNB. Input stream 703 includes input messages 713 to subnet SNB from multiple users U.

[0117] The inter-subnet messages 711 and 712 include inter-unit messages exchanged between computing units of different subnets, as well as signaling messages. Signaling messages are used to acknowledge or not acknowledge receipt of an inter-unit message. The message component 61 is configured to transmit signaling messages from the receiving subnet to the corresponding sending subnet, i.e. in this example from the subnet SNB to the subnets SNA and SNC. The message component 61 is configured according to this example to store the transmitted inter-unit messages until an acknowledgment message is received for the respective inter-unit message. This ensures the delivery.

[0118] The consensus component 63 is configured to receive and process inter-subnet messages 711, 712 of the subnets SNA, SNC, and incoming messages 713 with the user U, and generate a queue of input blocks 720 from the inter-subnet messages 711, 712 and the incoming messages 713 according to a defined consensus mechanism implemented by a corresponding consensus protocol. Each of the input blocks 720 generated by consensus includes a set of input messages 713, a set of inter-subnet messages 711, 712, and an EP, which are execution parameters 714. The EP, which are execution parameters 714, may include, among others, a random seed, a specified execution time, and / or a height indicator. The consensus component 63 may also vary the number of messages in all input blocks based on the current load of the subnet.

[0119] The consensus component 63 then provides the queue of input blocks 720 to the message component 61. The message component 61 is configured to execute a message protocol to process the input blocks 720.

[0120] The message protocol and messages component 61 synchronizes with the input block 720 received from the consensus component 63 .

[0121] Before processing a received input block, the message component 61 may perform one or more pre-processing steps, including one or more input checks, which may be performed by the input check component 740.

[0122] According to some embodiments, input checks may be performed with different granularity. First, input checks may be performed on the entire input block. Such checks may be denoted as input block checks. These may comprise checking the height of the next input block. When the height of the next input block is lower than the height expected in the next turn, it is discarded. When an input block is not scheduled in the next turn, the message component 61 may initiate a node catch-up protocol. When an input block is present in the next turn, it is further processed by the message component 61.

[0123] Various types of messages (signaling messages, ingress messages, inter-unit messages) within an input block may be grouped together.

[0124] The input checks may further include an overload check to check whether the messaging component is currently overloaded and does not have sufficient capacity to perform the processing. For example, if an associated queue in a steered pool becomes full, the corresponding message may be rejected. Further input checks may include in-order delivery checks. To meet in-order delivery requirements, messages can be annotated, e.g., with a sequence number. If a message with a sequence number is received, the message component 61 may check whether it has the expected number and may reject it if different. Furthermore, the input checks component 740 may perform a validity check of the intended destination, i.e., whether the message is intended for a computing unit that is active in the corresponding subnet.

[0125] If the input checks are passed, the message of the respective input block 720 may be further processed by the message component 61. The corresponding message may then be added to a corresponding queue in the directed pool of the directed pool component 731.

[0126] In general, the messaging component 61 pre-processes the input block 720 by placing ingress, signaling, and inter-subnet messages appropriately into the directed pool component 731. Signaling messages in the incoming subnet stream are treated as acknowledgment of messages in the output queue and can then be removed.

[0127] In this example, the directed pool component 731 comprises unit-to-unit queues A1-B1, C1-B1, A2-B2, and C1-B2, and user-to-unit queues U-B1 and U-B2.

[0128] Following these pre-processing steps, the message component 61 invokes the execution component 62 (see FIG. 6) to execute as many induced pools as feasible during a single execution cycle, providing the specified execution time and the random seed as additional inputs. Following that execution cycle, the resulting output queues of messages are provided to the output queue component 733. Initially, the output queue component 733 comprises inter-unit and unit-to-user output queues. In this example, it comprises B1-A1, B1-C2, B2-A2, and B2-C3 as inter-unit output queues, and B1-U1 and B2-U4 as unit-to-user output queues. As an example, the message B1-A1 indicates a message from the computing unit B1 of the subnet SNB to the computing unit A1 of the subnet SNA. As another example, the message B1-U1 indicates a message from the computing unit B1 of the subnet SNB to the user U1.

[0129] The output queue component 733 post-processes the resulting output queue of messages, for example by forming a set of output streams per subnet, authenticated by the authentication component 65a as shown in Fig. 6 and disseminated by other components. In this example, the output streams SNB-SNA, SNB-SNC and SNB-U per subnet are provided. The message component 61 further comprises a state storage component 732 configured to store the state / unit state of the computational units of the respective subnet, in this example the state of the computational units B1 and B2 of the subnet SNB. The corresponding unit state is the working memory of each computational unit.

[0130] The message component 61 revolves around deterministically changing certain parts of the system state. In each round, the execution component 61 executes certain messages from the induced pool by reading and updating the state of each computational unit, and returns any outgoing messages that the executed computational unit wants to send. These messages enter the output queue component 733 and initially include unit-to-user messages and inter-unit messages between computational units of the network. Intra-subnet messages between computational units of the same subnet may be routed and delivered internally within the respective subnets, while inter-subnet messages are routed to output streams sorted by subnet destination.

[0131] Additionally, according to some embodiments, two states may be maintained to inform the rest of the system about which messages have been processed: a first part may be maintained for inter-subnet messages, and a second part may be maintained for incoming messages.

[0132] FIG. 8 illustrates an exemplary application (computing) unit 800 according to one embodiment of the present invention.

[0133] An application unit 800 comprises input queues 801, output queues 802, user or application state 803, and system state 804. All input queues 801 of an application unit (on a given subnet) collectively constitute a induced pool, while the input queues are part of the state of the application computing unit. Output queues 802 contain messages that need to be delivered to other application computing units, possibly in other subnetworks.

[0134] The application state 803 includes a main Web Assembly (Wasm) module that implements the functionality of the application computational unit and its associated modules, along with each instance of the modules. An instance of a Wasm module consists of memory, global variables, and tables.

[0135] System state 804 cannot be freely modified by the application compute unit's code, including metadata and other state maintained by the system on behalf of the application compute unit, in particular Wasm modules in compiled form, and the context of outstanding messages and callbacks.

[0136] Additionally, the system state 804 includes an application unit gas account for each application compute unit 800, as well as one or more local user gas accounts, denoted in this example as UGA1, UGA2, ..., UGAN. The user gas accounts include the current gas balances of each user U1, U2, ..., UN at the application compute unit 800.

[0137] FIG. 9 illustrates an exemplary local user gas account UGAX in greater detail, according to one embodiment of the present invention.

[0138] The local user gas account UGAX comprises an input subaccount 901, a read query subaccount 902, and an execution subaccount 903. The ingress subaccount 901 is configured to pay JJ for ingress messages that are accepted or rejected for further processing, in particular for ingress messages that are placed in the induced pool 731 as shown in Figure 7. Furthermore, when an ingress message passes consensus completely but does not pass input checks 740, it has already used network resources. Thus, according to some embodiments, the user is required to make payments for rejected input messages as well.

[0139] The read query subaccount 902 is configured to pay for read queries. Such read queries may be sent by users of the network to one or more nodes in the respective subnets. According to some embodiments, the nodes may periodically read snapshots of the unit states of the application units in the respective subnets, and users may access the read snapshots through read queries. Each node in each subnet has a separate read query subaccount RQSAN1, RQSAN2, RQSANN to charge for read queries.

[0140] The execution subaccount 903 may be configured to pay for the execution of messages, particularly the execution of on-gress messages, and may further be configured to pay for the execution of inter-unit messages according to some embodiments.

[0141] According to some embodiments, each respective sub-account must have sufficient balance or the corresponding request / action will not be processed. As an example, when an ingress sub-account 901 does not have sufficient balance, the corresponding incoming message will not be accepted.

[0142] Figure 10 illustrates a billing / payment scheme according to one embodiment of the present invention. In the example of Figure 10, it is assumed that only a single exemplary application unit AU1 of the distributed network 1000 is involved in the exemplary transaction and associated billing / payment. The application unit AU1 comprises an application unit gas account AGA that is owned by the application unit AU1 and that is used to pay for and receive payments for usage of network resources by the application unit AU1.

[0143] The application unit AU1 further includes a local user gas account UGA for a user U of the distributed network. The network is configured to process resource payments for network resources arising at the request of the user U via or by the local user gas account UGA. According to some embodiments, the local user gas account may be embodied as a metering or metering unit. In the illustrated example of Fig. 10, it is assumed that the user U is connected to the distributed network via a user interface UI.

[0144] In step 1001, a user U sends an ingress message IM to the application unit AU1. The ingress message IM is embodied as a message requesting a primary application service. The application unit AU1 acts as a primary application unit and sets an entry point in the distributed network 1000 for the incoming message. The primary application unit AU1 executes a primary application service requested by the user. The primary application service can generally be any kind of service, for example providing access to a website, booking a trip, ordering a postcard, etc. In the example of FIG. 10, it is assumed that the primary application unit AU1 is able to process the ingress message IM independently, without the need to involve other (not shown) application units of the distributed network 1000.

[0145] In step 1002, the application unit AU1 processes charges or payments for the use of network resources incurred or used by the primary application service. More specifically, the respective gas amount GA is deducted from a local user gas account UGA. According to some embodiments, the gas amount GA can simply be "burned", i.e., removed or eliminated from the system without being transferred to another account, or it can be transferred to a system account of the distributed network. According to some other embodiments, the gas amount can be transferred to the application unit gas account AGA.

[0146] Further, in step 1003, the application unit AU1 returns a response message RM to the ingress message IM via the user interface UI to the user U. The response message RM may be, for example, a requested web page and may be considered as a result provided to the user in response to the ingress message.

[0147] FIG. 11 illustrates a billing / payment scheme with reference to a distributed network 1100. FIG. 11 illustrates eight exemplary application units of the distributed network 1100 involved in an exemplary transaction and the associated billing / payment for the use of network resources involved in the transaction. More specifically, FIG. 11 illustrates application units AU1, AU2, AU3, AU4, AU5, AU6, AU7, and AU8. Each of the application units AU1, AU2, AU3, AU4, AU5, AU6, AU7, and AU8 constitutes an application unit gas account AGA. The application unit gas accounts AGA are gas accounts owned by the corresponding application units AU1, AU2, AU3, AU4, AU5, AU6, AU7, and AU8 and used by the respective application units to make and receive payments for the use of resources of the distributed network 1100.

[0148] According to some embodiments, the distributed network 1100 also charges for the use of storage resources it provides. Thus, the gas account AGA of each application unit can be used to pay for the use of the storage resources of the network by each application unit. These storage costs can be charged, for example, periodically, for example, according to a best-case billing scheme. In such a scheme, each application unit is charged for the maximum amount of storage space it has used in a predefined period. In addition to the application unit gas account AGA, the application unit AUX can comprise local user gas accounts UGA for users of the distributed network. These local user gas accounts UGA are configured to process payments for the use of network resources of the corresponding users of the distributed network 1100.

[0149] According to some embodiments, a user is required to have a user gas account UGA for each primary application unit to which the user wishes to send an ingress message requesting a primary application service.

[0150] In the illustrated example of FIG. 11, it is assumed that a user U is connected to the distributed network via a user interface UI.

[0151] According to some embodiments, the user U is informed in advance, for example by a browser plug-in, of the additional application unit AU, denoted below as secondary application unit. It needs to have a user gas account for requesting the respective primary application service. This may depend on the respective primary application service. According to some embodiments, in the secondary application unit, no further user gas account may be required, but for some primary application services, a separate user gas account may be required in each of the secondary application units involved in the respective primary application service. Such a browser plug-in may periodically check whether the respective user gas account is sufficiently charged. Otherwise, the user's ingress messages may be rejected.

[0152] According to some embodiments, when the call tree / execution tree of the respective request hits an application unit for which the user needs to have a local user gas account, the application unit may be written in a way that pays attention to the gas situation so as not to have to start from scratch and to inform the user. However, it may happen that the local user gas account no longer has a sufficient balance. According to some embodiments, the user interface UI may also provide the possibility to arrange for the replenishment of the respective user gas account from the user's wallet computing unit.

[0153] In this example, user U must and effectively has a local user gas account UGA in application unit AU1 and application unit AU5.

[0154] An exemplary process flow of the charging scheme may operate as follows.

[0155] In step 1101, a user U sends an ingress message IM to the application unit AU1. The ingress message IM is embodied as a message requesting a primary application service. The application unit AU1 acts as a primary application unit and sets the entry point in the distributed network for the ingress message IM. The primary application unit AU1 executes the primary application service request by the user. The primary application service can generally be any kind of service, such as providing access to a website, booking a trip, ordering a postcard, etc.

[0156] In this example, the requested primary application service cannot be performed by primary application unit AU1 alone, but requires the involvement of several additional application units, more specifically, application units AU2, AU3, AU4, AU5, AU6, AU7, and AU8, which are hereinafter referred to as secondary application units.

[0157] The involvement of secondary application units AU2, AU3, AU4, AU5, AU6, AU7 and AU8 is initiated or performed by primary application unit AU1 invoking one or more secondary application units, e.g. application units AU2 and AU3, in steps 1102 and 1103. The invocation may include the sending of a invocation message CM. The invocation message CM, which may be considered as an embodiment of an inter-unit message, may include a payment message PM.

[0158] According to some other embodiments, the payment message PM may also be sent separately.The call message to the secondary application unit comprises a request for the secondary application unit to execute a secondary application service.

[0159] In this example, secondary application unit AU3 issues further calls to further secondary application units, more specifically, secondary application unit AU3 issues a call to secondary application unit AU4 in step 1104 and a call to secondary application unit AU5 in step 1105.

[0160] The secondary application unit AU5 then sends respective paging messages CM to the secondary application units AU6, AU7 and AU8 in steps 1106, 1107 and 1108. These paging messages constitute a multiple paging.

[0161] The entire call or call message CM initiated by the incoming message IM can be shown as a call tree. More specifically, the calls or call messages issued in steps 1102 to 1108, including the initial ingress message issued in step 1101, can be considered as a call tree.

[0162] As mentioned above, the secondary application unit AU5 also includes a local user gas account UGA. This local user gas account UGA of the secondary application unit AU5 can be used to process charges or payments for the use of network resources required by the secondary application unit AU5 to execute secondary application services. These payments may include payments for secondary services of secondary application units AU6, AU7, and / or AU8 required by corresponding multiple calls. The call tree of this example shows different payment schemes for the different application units involved in the call.

[0163] More specifically, for the performance of its secondary application service, application unit AU2 charges, for example, 10 gas units, and application unit AU3 charges a fixed price of, for example, 20 gas units.

[0164] Gas is transferred between the application units by sending a payment message PM containing a fixed payment of 10 gas units from application unit AU1 to application unit AU2 in step 1102, and by sending a payment message PM containing a fixed payment of 20 gas units from application unit AU1 to application unit AU3 in step 1103. More specifically, these payment messages PM transfer a currency amount, in particular an amount of gas units, from the application unit gas account AGA of application unit AU1 to the application unit gas account AGA of application units AU2 and AU3, respectively.

[0165] The application unit AU4 prepays for the use of network resources to execute the secondary application service. The prepayment may be considered as the minimum gas required to be loaded on the message. The amount specified in the prepayment may be selected to be sufficient for the completion of the execution of the corresponding primary or secondary application service, e.g., approximately 99% probability. To further increase this probability, the primary or secondary application unit may use its own application unit gas account AGA to top up its respective prepayment and ensure the execution of the corresponding primary and / or secondary application service with an even higher probability, e.g., approximately 99.999% probability. In this example, it is assumed that the application unit AU3 tops up the prepayment of 5 gas units specified by the application unit AU4 with another 5 gas units from its own application unit gas account, making a total of 10 gas units available to the application unit AU4 to pay for the network resources required for the execution of the secondary application service.

[0166] For example, a respective quantity of gas of 10 gas units is transferred from application unit AU3 to application unit AU4 by sending a payment message PM including a prepayment of 5 gas units and a refill payment of 5 gas units from application unit AU3 in step 1104. Further, according to this example, the payment message PM sent in step 1103 also includes a prepayment of 5 gas units to be transferred from the application unit gas account of application unit AU1 to the application unit gas account of application unit AU3.

[0167] In contrast to the payment messages PM sent in steps 1102, 1103, 1106, 1107 and 1108, the amount of 10 gas transferred by the payment message PM in step 1104 to the application unit AU4 may not be credited to the application user gas account of the receiving application unit according to some embodiments. However, this amount may be used to directly pay for the actual usage of network resources and may be "burned", i.e., deleted or removed from the system. For example, in the actual case, the secondary application unit AU4 may be refunded 6 gas units, since it only needs 4 gas units for the secondary application service.

[0168] The refund may be performed by sending a refund message RIM from the application unit AU4 to the application unit AU3, which includes a refund of six gas units. The refund message RIM may be sent together with the response message RM in step 1123. It may also be embodied as a separate message. The application unit AU3 may then keep the five gas units, more specifically the amount of the five gas units it topped up from its own AGA, and return it to its own AGA. Furthermore, the application unit AU3 may refund the remaining unused part of the prepayment (one gas unit in this example) to the application unit AU1, for example, in step 1124, by sending a refund message RIM to the application unit AU1 (for example, as part of the response message or separately). The application unit AU1 may then refund this one gas unit to the local user gas account UGA of the user U.

[0169] The call, embodied as a call message CM issued in step 1105 to the secondary application unit AU5, entails a variable payment. More specifically, the application unit AU5 does not specify a fixed price for the secondary service, but specifies a variable price to be charged directly from the user gas account UGA executed by the user in the application unit AU5.

[0170] According to this example, the call message CM issued in step 1106 also carries a variable charge or payment. Thus, the application unit AU6 also includes a local user gas account UGA from which it directly charges the variable price, for example in step 1136.

[0171] Meanwhile, secondary application unit AU7 and secondary application unit AU8 charge a fixed price. More specifically, application unit AU7 charges a fixed price of 5 gas units, and application unit AU8 charges a fixed price of 7 gas units. For example, in steps 1107 and 1108, the respective amounts of gas are transferred from application unit AU5 to application unit AU7 and application unit AU8 by sending corresponding payment messages PM from application unit AU5 to application units AU7 and AU8. According to some other embodiments, the payment messages PM may be sent in separate steps. In response to the multiple calls issued to application unit AU6, application unit AU7, and application unit AU8, application unit AU5 generally receives response messages RM from application unit AU6, application unit AU7, and application unit AU8, as shown in step 1121.

[0172] After executing the respective secondary application service, the secondary application unit AU5 sends a response message RM to the application unit AU3 in step 1122. Furthermore, the secondary application unit AU4 sends a response message RM to the application unit AU3 in step 1123. This may include, for example, a refund message RIM of 6 gas units as described above. The secondary application unit AU3 then sends a response message RM to the primary application unit AU1 in step 1224, which may include, for example, a refund message RIM for one gas unit. The secondary application unit AU2 sends the response message RM to the primary application unit AU1 in step 1125. The primary application unit AU1 then provides the response message RM to the user U via the user interface UI in step 1226.

[0173] According to some embodiments, the distributed network is configured to separately charge for ingress messages, in particular for the acceptance of an ingress message for execution and for the execution of the message. In this regard, different accounting periods may be implemented for ingress messages and for the execution of ingress messages. As an example, when the distributed network is embodied as described in FIG. 7, an ingress message may be charged once it has successfully passed the input check 740 and entered the induced pool 731. Furthermore, the execution of an ingress message may be charged according to some embodiments after the primary application unit has performed some initial processing. According to embodiments, the execution of an ingress message may be charged after the primary application unit has issued one or more calls to secondary application units required to execute the respective ingress message.

[0174] Referring to the above example, in step 1131, the primary application unit AU1 may be charged for receiving the ingress message IM, more specifically after it enters the induction pool. This may involve, for example, a fee depending on the size of the IM, and the respective gas units being deducted, in particular, from the ingress subaccount 901 (see FIG. 9) of the user gas account. Furthermore, it may process, in step 1132, a fee or payment for the use of network resources caused by the ingress message IM. The respective payment is deducted from the user gas account UGA of the primary application unit AU1. These payments may include, for example, a fixed price of 10 gas units for application unit AU2, 20 gas units for application unit AU3, a prepayment of 5 gas units for application unit AU4, as well as a fixed price of, for example, 20 gas units for the execution of the primary application service by application unit AU1. Thus, in this example, after issuing the call, the primary application unit AU1 may deduct 55 gas units from the local user gas account of the primary application unit AU1 for the execution of the ingress message IM in step 1132. This deduction of the respective gas unit is taken in particular from the execution subaccount 903 (see FIG. 9) of the user gas account.

[0175] Step 1132 may be performed, for example, immediately before or after steps 1102-1103.

[0176] Thus, in step 1132, the user pays from his execution subaccount for each instruction being executed by the primary application unit AU1 as well as for calls made to other application units that do not provide their own user account. The cost charged may include gas sent with the call for a fixed payment, not just an upfront payment. According to some embodiments, the cost may also include an upfront payment for the execution of the closure that processes the final response / result. According to some embodiments, the change from the execution of the closure (unused amount of gas units) can be credited back to the execution subaccount of the user gas account. According to some embodiments, the developer can choose not to provide a closure to process the response / result of the call, in which case the developer is not charged for it. The closure may be specially configured so that when its execution cost exceeds the minimum closure cost, this additional cost is deducted from the execution subaccount.

[0177] With further reference to the above example, in step 1133, the secondary application unit AU5 may process charges and payments for the use of network resources by AU7 and AU8, as well as its own usage by deducting the total cost from the user gas account UGA of the application unit AU5. According to some other embodiments, the cost may be deducted from the application unit gas account AGA. Step 1133 may be performed immediately before or immediately after sending the call message CM in steps 1106, 1107, and 1108.

[0178] Similarly, in further steps 1134, 1135, 1137 and 1138, secondary application units AU2, AU3, AU7 and AU8 may process fees or payments for their respective usage of network resources.

[0179] According to some embodiments, each gas charged in steps 1131 through 1138 may be flared.

[0180] According to some embodiments, the respective payment method of each application can be specified in the interface description language (IDL) of the application unit. Thus, it can be specified by the respective programmer / developer of the application unit. In particular, the interface description of each application unit can specify whether the user is expected to have a local user gas account with the application unit and what the expected balance should be. In the latter case, when the application unit acts, for example, as a secondary application unit, there is no need for other application units, in particular the primary application unit, to gas call messages sent to that secondary application unit. According to some embodiments, the user and / or the respective primary application unit can compute the call tree. Also, in the IDL, it can be specified that a fixed price is paid to execute a function / call, and execution can be guaranteed, as long as the application unit's application unit gas account is not exhausted.

[0181] According to some embodiments, a fixed price is always charged the actual cost of execution, regardless of whether it is successful or not.

[0182] Additionally, the interface description may specify that a prepayment is required for the execution of each function / call, and this "minimum" amount of gas (specified as prepayment) must be included in the corresponding call message. According to some embodiments, this minimum amount of gas can be dynamically calculated by recording the maximum amount of gas ever consumed, and then multiplying it by a predefined factor, e.g., 1.5.

[0183] The manner in which a user of a decentralized network may upload a local user's gas account is illustrated in Figure 12. The figure is provided with reference to a decentralized network 1100 comprising application units AU1, AU2, AU3, AU4, AU5, AU6, AU7, and AU8, as described above.

[0184] As shown in Figure 12, a user U1 executes a wallet computing unit WCU1. The wallet computing unit WCU1 is configured to manage a user currency account of the user U1.

[0185] To replenish the local user gas account UGA from the user currency account provided by WCU1, user U1 sends a replenishment request RR to its wallet computation unit WCU1 in step 1201. Wallet computation unit WCU1 then sends a payment message PM to application unit AU1 in step 1202, sends a payment message PM to application unit AU5 in step 1203, and sends a payment message PM to application unit AU6 in step 1204. This enables application units AU1, AU5 and AU6 to transfer the currency amount from the user currency account to the local user gas account UGA.

[0186] The user currency account provided by the wallet computation unit WCU1 can be recharged / topped up by the user, for example, from a traditional bank account. In this respect, an interface to an external banking application or an external bank account can be provided. The wallet computation unit WCU1 can run in gas units or another currency, for example a cryptocurrency, a stablecoin, or a classic national currency such as US dollars or euros.

[0187] The exchange rate between the cryptocurrency or classical national currency and the gas currency can be managed by the decentralized network 1100 according to the respective needs of the application.

[0188] It should be noted that the gas account AGA of an application unit can be replenished, for example, by the owner of the respective application unit. For this purpose, the owner of the respective application unit can own a user currency account, which can also be denoted as the owner's currency account.

[0189] 13 illustrates a billing scheme for read queries according to an embodiment of the present invention. Subnet 11 may include five nodes N1, N2, N3, N4, and N5. Each of nodes N1, N2, N3, N4, and N5 may run a set of application units with their own unit states. The unit states of the set of application units are replicated across subnet 11.

[0190] Nodes N1, N2, N3, N4, and N5 periodically create read snapshots of the unit states of application units in subnet 11. To access the read snapshots, a user may send read queries to one or more of nodes N1, N2, N3, N4, and N5. Read queries are not charged all at once, but are subsequently charged in a bundled manner.

[0191] Further, according to some embodiments, each of nodes N1, N2, N3, N4, and N5 may have a separate read query sub-account RQSA (see also FIG. 9) for charging for read queries that they receive and process.

[0192] In this example, it is assumed that a user submits four read queries RQ1, RQ2, RQ3, and RQ4 to node N1. Furthermore, the user digitally signs each of the read queries. More specifically, the read queries RQ1, RQ2, RQ3, and RQ4 are signed with signatures sig1, sig2, sig3, and sig4, respectively.

[0193] The user is then charged in a bundled manner for the four read queries. This node N1 may send the total amount of gas units to be charged for the bundle of read queries RQ1, RQ2, RQ3, and RQ4, along with an aggregated signature, as a system ingress message to other nodes N2, N3, N4, or N5 in subnet 11.

[0194] The total amount of gas units is then aggregated and deducted from each user's read sub-account 902 (see FIG. 9).

[0195] As shown in Fig. 9, each of nodes N1, N2, N3, N4 and N5 may have separate read query sub-accounts RQSAN1, RQSAN2, RQSAN3, RQSAN4 and RQSAN5. According to some embodiments, node N1 may execute read queries RQ1, RQ2, RQ3 and RQ4 only if its separate read query sub-account RQSAN1 has a sufficient balance. This may, for example, prevent or hinder an attack on a single node, node N1 in this example, by flooding node N1 with read queries.

[0196] Figure 14 shows how a primary application unit AU1 receiving an ingress message can use closures to manage calls to secondary application units. In step 1401, user U sends an ingress message to application unit AU1. Application unit AU1 acts as a primary application unit. In one or more steps 1402, application unit AU1 sends further calls to one or more secondary application units.

[0197] In step 1403, application unit AU1 stores its current state, including the invocation context, as a closure.

[0198] The secondary application unit sends one or more responses / results back to the application unit AU1 as a response message in one or more steps 1404. The application unit AU1 then processes the response message using the state stored in the closure and sends the response message back to the user U in step 1405.

[0199] FIG. 15 illustrates a flowchart of method steps of a computer-implemented method for charging for usage of network resources in a distributed network, according to one embodiment of the present invention.

[0200] At step 1510, the distributed network includes one or more application (computing) units running on each of a plurality of nodes.

[0201] In step 1520, a user of the network executes a local user gas account on the primary application unit.

[0202] In step 1530, a user of the network sends an incoming message to the primary application unit.

[0203] In step 1540, the primary application unit issues a call to the secondary application unit.

[0204] In step 1550, the local user gas account of the primary application unit processes the payment for the use of the network resources by the primary application unit and the secondary application unit.

[0205] In step 1560, the secondary application unit executes the secondary application service and sends the result of the secondary application service back to the primary application unit. In step 1570, the primary application unit executes the primary application service, including using the result of the secondary application service, and sends a response message back to the user.

[0206] Thus, according to such a method, payment for the use of network resources can be made locally from the local user gas account of the primary application unit, and furthermore, payment procedures can be performed before the entire call tree is executed.

[0207] 16 illustrates the main processes performed in each node 10 of networks 100, 300, 1100, and 1300 according to an embodiment of the present invention. A network client of a network according to some embodiments of the present invention is a set of protocol components necessary for a node 10 to participate in the network. According to some embodiments, each node 10 is a member of a mainnet, typically a subnetwork, which means that each node runs a mainnet client, or a subnetwork client.

[0208] The node manager 40 is configured to start, restart and update the mainnet protocol clients 41 , the subnet protocol clients 42 and the security applications 43 .

[0209] According to some embodiments, each of the multiple subnets 11 is configured to run a separate subnet protocol client 42 at a corresponding node 10. The mainnet protocol client 41 is specifically configured to distribute configuration data between the multiple subnets 11. The mainnet protocol client 41 may be specifically configured to run only system computation units and not user-provided computation units. The mainnet protocol client 41 is a local client of the mainnet and the subnet protocol client 42 is a local client of the subnet.

[0210] The security application 43 stores the private keys of the node 10 and performs all operations with them. The security application 43 is configured to protect the private keys held by the node. More specifically, the private keys are held and processed in a separate execution environment (either a separate process or a separate Virtual Machine (VM)). The security application 43 is configured to operate with limited and controlled interfaces such that the private keys cannot be extracted via these interfaces. According to some embodiments, the security application is configured to operate like or similar to a Hardware Security Module (HSM). Thus, the security application 43 may be denoted as a software HSM.

[0211] 17 shows a layer model 1700 illustrating the main layers involved in the exchange of inter-subnet and intra-subnet messages. The layer model 1700 comprises a messaging layer 51 configured to function as a higher layer for inter-subnet communication. More specifically, the messaging layer 51 is configured to route inter-subnet messages between computing units of different subnets. Furthermore, the messaging layer 51 is configured to route ingress messages from users of the network to computing units of the network.

[0212] The layer model 1700 further includes a number of consensus layers 52 configured to receive inter-subnet messages as well as ingress messages from different subnets and organize them into a sequence of input blocks that are then further processed by the respective subnets, in particular by agreeing on a processing order. Additionally, the layer model 1700 comprises a peer-to-peer (P2P) layer 53 configured to organize and drive communication between nodes of a single subnet.

[0213] According to some embodiments, the network may include several further layers, in particular an execution layer configured to execute messages in the computational units of the network. A more detailed description of the interaction between the Mainnet Protocol Client 41 and the Subnet Protocol Client 42 is given below (see FIG. 16). The Mainnet Protocol Client 41 manages several registries that contain configuration information of the subnets. These registries are implemented by the computational units of the Mainnet, and since all nodes participate in the Mainnet, access to these registries can be easily implemented by state read operations.

[0214] That is, the Mainnet Reader 610 (see FIG. 6) may actually be a subcomponent of the Mainnet Protocol Client 41. Thus, interaction with this component results in interaction between the two isolated environments in which the Mainnet and Subnet Clients run.

[0215] Figure 18 illustrates the creation of blocks in a distributed network according to some embodiments of the present invention. The blocks may in particular be input blocks 720 as shown in Figure 7. They are created by the consensus component 63 running a consensus protocol, in particular the local subnet consensus protocol.

[0216] In this exemplary embodiment, three input blocks 1801, 1802, and 1803 are shown. Block 1801 includes multiple transactions, namely, transaction tx1.1, transaction tx1.2, and possibly further transactions, indicated by dots. Block 1802 also includes multiple transactions, namely, transaction tx2.1, transaction tx2.2, and possibly further transactions, indicated by dots. Block 1803 also includes multiple transactions, namely, transaction tx3.1, transaction tx3.2, and possibly further transactions, indicated by dots. Input blocks 1801, 1802, and 1803 are chained. More specifically, each block includes the block hash of the previous block. This cryptographically links the current block to the previous block. According to some embodiments, the transactions can be inter-subnet messages, ingress messages, and signaling messages.

[0217] According to some embodiments, input blocks 1801, 1802, and 1803 may be created by a proof-of-stake consensus protocol.

[0218] However, it should be noted that the input blocks generated by the consensus components do not need to be chained according to some embodiments. Rather, any consensus protocol that reaches some sort of agreement among the nodes of a subnet on the order in which received messages are processed may be used according to embodiments.

[0219] Figure 19 illustrates in more detail a networking component 1900 configured to perform a networking protocol. Networking component 1900 may be, for example, a more detailed embodiment of networking component 64 illustrated in Figure 6. Networking component 1900 includes a unicast component 1910 configured to perform inter-node communications, a broadcast component 1920 configured to perform intra-subnet communications, and a cross-net component 1930 configured to perform inter-subnet communications.

[0220] Referring now to FIG. 20, a more detailed block diagram of a network node 10 shown, for example, in the network 100 of FIG. 1 is shown, according to an embodiment of the present invention. The network node 10 establishes a computational node capable of performing computational functions and thus may generally be embodied as a computing system or computer. The network node 10 may be, for example, a server computer. The network node 10 may be configured to execute a computer-implemented method for charging for the use of network resources of a distributed network. The network node 10 may be operable with many other general purpose or special purpose computing system environments or configurations. The network node 10 may be described in the general context of computer system executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The network node 10 is shown in the form of a general purpose computing device. Components of the network node 10 may include one or more processors or processing units 2015, a system memory 2020, and a bus 2016 that couples various system components, including the system memory 2020, to the processor 2015. However. However, the present invention is not limited to these.

[0221] Bus 2016 represents one or more of several types of bus structures, such as a memory bus or memory controller, a peripheral bus, an Accelerated Graphics Port (AGP), a processor or local bus using any of a variety of bus architectures, including, but not limited to, an Industry Standard Architecture (ISA) bus, a MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0222] Network node 10 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by network node 10 and includes both volatile and nonvolatile media, removable and non-removable media.

[0223] The system memory 2020 may include computer system readable media in the form of volatile memory such as random access memory (RAM) 2021 and / or cache memory 2022. The network node 2010 may further include other removable / non-removable, volatile / non-volatile computer system storage media. As an example, the storage system 2023 may provide a non-removable, non-volatile magnetic medium (not shown, typically referred to as a "hard drive") for reading and writing. Although not shown, it may provide a magnetic disk drive for reading and writing to a removable non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading or writing to a removable non-volatile optical disk, such as a CD-ROM, DVD-ROM, and other optical media. In such a case, each may be connected to the bus 2016 by one or more data media interfaces. As further depicted and explained below, the memory 2020 may include at least one computer program product having a set (e.g., at least one) of program modules configured to perform the functions of some embodiments of the present invention.

[0224] Programs / utilities 2030 having a set (at least one) of program modules 2031, by way of example and not limitation, an operating system, one or more application programs, other program modules, and program data, may be stored in memory 2020. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may be implemented in a networked environment. The program modules 2031 generally implement the functionality and / or methodology of some embodiments of the invention as described herein. The program modules 2031 may perform one or more specific steps of a computer-implemented method for providing users of a distributed network access to computational results computed by the distributed network, such as one or more steps of the method described above.

[0225] The network node 10 may also communicate with one or more external devices 2017, such as a keyboard or pointing device, as well as a display 2018. Such communication may be effected via an input / output (I / O) interface 2019. Additionally, the network node 10 may communicate with one or more networks 40, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), via a network adapter 2041. According to some embodiments, the network 2040 may be, among other networks, a distributed network comprising multiple network nodes 10, e.g., the network 100 as shown in FIG. 1. As shown, the network adapter 2041 communicates with other components of the network node 10 via a bus 2016. Although not shown, it should be understood that other hardware and / or software components may be used in combination with the network node 10.

[0226] The network node 10 provides network resources to a corresponding distributed network. The network resources include, among other things, a processing unit 2015 and a memory 2020 including a storage system 2023.

[0227] Aspects of the invention may be embodied as a system, particularly a distributed network comprising multiple subnets, a method, and / or a computer program product, which may include a computer-readable storage medium (or media) having computer-readable program instructions that cause a processor to perform certain aspects of the invention.

[0228] A computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. As used herein, a computer-readable storage medium should not be construed as a transitory signal itself, such as an electric signal transmitted over a wire, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable).

[0229] The computer readable program instructions described herein can be downloaded from a computer readable storage medium to each computing / processing device or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can be comprised of copper transmission cables, optical fiber transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface of each computing / processing device receives the computer readable program instructions from the network and transfers the computer readable program instructions for storage in the computer readable storage medium of the respective computing / processing device.

[0230] Computer readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages. The programming languages ​​may be conventional procedural programming languages ​​such as Smalltalk, object oriented programming languages ​​such as C++, and the "C" programming language or similar programming languages.

[0231] Certain aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, networks, apparatus (systems) and computer program products according to embodiments of the invention.

[0232] Computer readable program instructions according to some embodiments of the present invention may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in the flowcharts and / or one or more block diagrams to produce a machine. These computer readable program instructions may also be stored on a computer readable storage medium capable of directing a computer, programmable data processing apparatus, and / or other device to function in a particular manner. The computer readable storage medium having the instructions stored thereon comprises an article of manufacture including instructions for performing aspects of the functions / acts specified in the flowcharts and / or one or more block diagrams.

[0233] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps such that the instructions, which execute on the computer, other programmable apparatus, or other device, implement the functions / acts specified in the flowcharts and / or block diagrams of one or more blocks, to generate a computer-implemented process.

[0234] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of networks, systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of an instruction, which comprises one or more executable instructions that implement a given logical function. In some alternative implementations, the functions shown in the blocks may differ from the order shown in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously. Also, the blocks may be executed in the reverse order depending on the functionality involved.

[0235] While presently preferred embodiments of the invention have been shown and described, it is to be clearly understood, however, that the invention is not limited thereto and may be otherwise embodied and embodied within the scope of the following claims.

Claims

1. 1. A computer-implemented method for charging for usage of resources of a distributed network, the distributed network comprising a plurality of nodes, each of the plurality of nodes configured to execute one or more computing units, the one or more computing units comprising one or more application units for providing application services to users of the distributed network; a user of the distributed network executing one or more local user gas accounts on one or more of the application units; billing for the usage of the resources of the decentralized network via the one or more local user gas accounts; a user of the distributed network sending an ingress message to a primary application unit of the one or more application units requesting a primary application service; the primary application unit performing the primary application service; the primary application service processes a billing for the usage of the resource via the local user gas account of the user at the primary application unit; selectively charging for accepting ingress messages, reading queries, executing the accepted ingress messages, and / or executing accepted inter-unit messages; The method, wherein the local user gas account is a local user gas accounting unit configured to locally pay for the usage of the resources of the distributed network.

2. 2. The method of claim 1, wherein the step of performing the primary application service includes the step of the primary application unit issuing one or more calls to one or more secondary application units, the method further comprising the step of the one or more secondary application units performing one or more secondary application services.

3. 3. The method of claim 2, wherein the step of performing one or more secondary application services includes the step of the one or more secondary application units issuing one or more calls to one or more further secondary application units, the method further comprising the step of the one or more further secondary application units performing one or more further secondary application services.

4. The method of claim 3 , wherein the one or more calls are made in series, thereby forming a call tree of arbitrary depth.

5. 5. The method of claim 2, further comprising a step of the one or more secondary application services processing payment for the usage of the resources via the local user gas account of the primary application unit.

6. the users of the distributed network executing one or more local user gas accounts on the one or more secondary application units; The method of claim 2 , further comprising the step of: processing payment for the use of the resources by the one or more secondary application services via the one or more local user gas accounts of the secondary application unit.

7. one or more users of the decentralized network, in particular each user of the decentralized network, executing a wallet computing unit configured to manage a user currency account of said user; 3. The method of claim 1 or 2, further comprising the step of sending a payment message from the wallet computation unit to a respective application unit, in the respective application unit, transferring a currency amount from the user currency account to the local user gas account.

8. The method according to claim 1 or 2, further comprising the step of each application unit executing an application unit gas account.

9. 9. The method of claim 8, further comprising the step of sending a payment message between a first application unit of the one or more application units and a second application unit of the one or more application units, transferring a gas fee from the application unit gas account or a user gas account of the first application unit to the application unit gas account of the second application unit.

10. Each of said local user gas accounts: an ingress subaccount configured to charge for receipt of said ingress messages; a read query subaccount configured to charge for reads of said queries; 3. The method of claim 1 or 2, further comprising: an execution sub-account configured to charge for execution of the accepted ingress messages and / or execution of the accepted inter-unit messages.

11. The method of claim 1 or 2, comprising applying different accounting periods and / or charging times for the ingress messages and the read queries.

12. the distributed network charging for use of storage resources of the distributed network; The method of claim 1 or 2, further comprising the step of debiting a usage fee for the storage resources of the distributed network from each application unit gas account.

13. The method of claim 1 or 2, further comprising the step of one or more of the application units charging a fixed price for the usage of the resources by the corresponding application service.

14. one or more of the application units prepaying for the use of the resources by the corresponding application service; The method of claim 1 or 2, further comprising the step of one or more of the application units refunding the unused portion of the prepayment.

15. The method according to claim 14, which cites claim 2, further comprising a step of topping up the prepayment from the application unit gas account of each of the primary application unit and / or secondary application unit to ensure the execution of the corresponding primary application service and / or secondary application service.

16. 3. The method of claim 1, wherein each of the computing units has its own unit state, and the distributed network comprises a plurality of subnets, the plurality of subnets comprising one or more of the plurality of nodes, the method further comprising the steps of assigning each of the application units to one of the plurality of subnets, and replicating the application units across the respective subnets.

17. The method of claim 16, wherein each node in each subnet is provided with a separate read query subaccount.

18. A distributed network comprising a plurality of nodes, each of the plurality of nodes configured to execute one or more computing units, the one or more computing units comprising one or more application units for providing application services to users of the distributed network, the distributed network comprising: providing resources for said computing unit; Each user of the distributed network executes one or more local user gas accounts in one or more of the application units; configured to process billing for use of the resources of the decentralized network via the local user gas account; A user of the distributed network sends an ingress message to a primary application unit of the one or more application units requesting a primary application service; The primary application unit performs the primary application service, The primary application service processes charges for the use of the resource through the local user gas account of the user at the primary application unit; Selectively charging for accepting ingress messages, reading queries, executing said accepted ingress messages, and / or executing accepted inter-unit messages; The local user gas account is a Local User Gas Accounting configured to pay locally for usage A distributed network is a unit.

19. 20. A node of the distributed network of claim 18, comprising: running one or more computing units comprising one or more application units for providing application services to users of the distributed network; Implementing one or more local user gas accounts in one or more of the application units; billing for the usage of the resources of the decentralized network via the one or more local user gas accounts; receiving an ingress message from a user of the distributed network requesting a primary application service from a primary application unit of the one or more application units; The primary application unit performs the primary application service, The primary application service processes charges for the use of the resource through the local user gas account of the user at the primary application unit; The local user gas account is a local user gas accounting unit configured to locally pay for the usage of the resources of the distributed network, the node.

20. 1. A computer program product for operating a distributed network comprising a plurality of nodes, the computer program product comprising a computer readable storage medium having program instructions embodied therein, the program instructions being executable by one or more of the plurality of nodes, the method comprising: said plurality of nodes executing one or more computing units comprising one or more application units providing application services to users of said distributed network; a user of the distributed network executing one or more local user gas accounts in one or more of the application units; charging for usage of resources of the decentralized network via the one or more local user gas accounts; receiving an ingress message from a user of the distributed network requesting a primary application service from a primary application unit of the one or more application units; the primary application unit performing the primary application service; the primary application service processes a billing for the usage of the resource via the local user gas account of the user at the primary application unit; selectively charging for accepting ingress messages, reading queries, executing the accepted ingress messages, and / or executing accepted inter-unit messages; The local user gas account is a local user gas accounting unit configured to locally pay for the usage of the resources of the distributed network.

21. 1. A computer program product for operating a node of a distributed network, the computer program product comprising a computer readable storage medium having program instructions embodied therein, the program instructions being executable by the node, the method comprising: said node executing one or more computing units comprising one or more application units providing application services to users of said distributed network; said node executing one or more local user gas accounts in one or more of said application units; charging for usage of resources of the decentralized network via the one or more local user gas accounts; receiving an ingress message from a user of the distributed network requesting a primary application service from a primary application unit of the one or more application units; the primary application unit performing the primary application service; the primary application service processes a billing for the usage of the resource via the local user gas account of the user at the primary application unit; selectively charging for accepting ingress messages, reading queries, executing the accepted ingress messages, and / or executing accepted inter-unit messages; The local user gas account is a local user gas accounting unit configured to locally pay for the usage of the resources of the distributed network.

Images