System and method for decentralized real-time communication

Abstract

System (100) for real-time communication over a communication network (10), the system (100) comprising resource servers (210), a blockchain (140) and a decentralized network coordinator, DNC, (130) defined in terms of one or several smart contracts (142) defined on the blockchain (140). The DNC (130) is configured to process blockchain transactions from the resource servers (210); store, on the blockchain (140), updated routing information (143) and status information regarding individual resource servers (210); execute an automated voting, resulting in an updated set of rating scores for one or several of the resource servers (210); and allow each of a plurality of peers (20) to access communication information from the blockchain (140), allowing the peer (20) to initiate communication over the transport layer protocol and using non-blockchain communication transactions, with a selected resource server (210). The selected resource server (210) routes the non-blockchain communication and receives remuneration from the DNC (130).

Description

[0001] and method for decentralized real-time communication

[0002] The present invention relates to systems and methods for real-time communication in distributed and decentralized contexts.

[0003] In many cases a plurality of entities have a need to communicate with each other in realtime. In decentralized contexts, this causes problems in terms of, for instance, scalability and standardization, that may influence both the costs associated with setting up communication channels and performing the actual communication.

[0004] For instance, in peer-to-peer systems, communication between peers can take place in realtime, but as the number of peers grow overhead costs for the peers keeping the connection between them typically grows faster than the number of peers. For instance, routing table information needs to be constantly updated and shared between peers.

[0005] Concretely, conventional decentralized networking solutions such as Distributed Network Protocol (DNP) and Real-Time Framework (RTF), that both rely heavily on point-to-point (or master-slave) communication models, are not originally designed for scalability. With each additional peer added into such a network, maintaining real-time consistency and synchronization across all of the peers can be very challenging.

[0006] Also, in many such decentralized contexts, peers having different configurations or properties may want to communicate. This will cause problems for the peers to agree on communication format and communicated information.

[0007] The management of communication systems involving many or disparate peers may often involve much work to keep track of performance and availability of peers, and so forth. It is often difficult to automate such management tasks, since the nature of various problems that can occur can vary in unexpected ways. The present invention solves at least some the above-described problems, and offers a communication solution providing both horizontal scalability, standardization among different communicating peers and a decentralized trust model not requiring any manual intervention.

[0008] Hence, the invention relates to a system for real-time communication over a digital communication network, the system comprising a plurality of resource servers, referred to in the following as the resource servers, each connected to the digital communication network and configured to communicate using a transport layer protocol; a blockchain; and a decentralized network coordinator, DNC, in the form of a decentralized application defined in terms of one or several smart contracts defined on the blockchain.

[0009] In some embodiments, the DNC is configured to process blockchain transactions from each of the resource servers; allow each of the resource servers to access the updated routing information; receive from one or several sending ones of the resource servers blockchain transactions indicating a respective current status information of the sending resource server and / or of one or several other ones of the resource servers; organize and execute an automated voting among the resource servers and / or providers of the resource servers resulting in an updated set of rating scores for one or several of the resource servers, the voting being based on the current status information; and allow each of a plurality of peers to access communication information from the blockchain, the communication information being useful for the peer to initiate communication, the initiated communication being over the transport layer protocol and using non-blockchain communication transactions, with a selected one of the resource servers.

[0010] In some embodiments, the selected resource server is configured to, in response to an initiated communication from the peer and using the updated routing information, route nonblockchain communication transactions over the transport layer protocol between the peer and a different resource server and / or a different one of said peers. In some embodiments, the DNC is configured to provide remuneration to the selected resource server in the form of a blockchain token representing a value in dependence of the updated rating score for the selected resource server.

[0011] In some embodiments, the system further comprises a plurality of validating blockchain nodes, each storing the blockchain including the DNC and each configured to propagate the blockchain by validating blocks using a consensus algorithm.

[0012] In some embodiments, each blockchain transaction is validated by the DNC using a registered public key of each of the resource servers, the public key corresponding to a private key of said each resource server, the private key being used by said each resource server to sign the blockchain transaction; store, on or in connection to the blockchain and based on the processed blockchain transactions, updated routing information regarding digital communication between individual ones of the resource servers.

[0013] In some embodiments, each blockchain transaction from each individual resource server is directed to only one of the validating blockchain nodes.

[0014] In some embodiments, the system further comprises one or several non-validating blockchain nodes that are configured to not participate in the consensus algorithm.

[0015] In some embodiments, the transport layer protocol is TCP, UDP, SCTP, CCP, RSVP or RUDP.

[0016] In some embodiments, each resource server is configured to periodically send a heartbeat blockchain transaction to the DNC.

[0017] In some embodiments, the DNC is configured to receive the heartbeat blockchain transaction and to update the current rating score information based thereon.

[0018] In some embodiments, the DNC is configured to organize and execute an automated voting among the resource servers and / or providers of the resource servers regarding the registration of a new resource server, and as a result of a positive vote register the new resource server.

[0019] In some embodiments, the DNC is configured to organize and execute an automated voting among the resource servers and / or providers of the resource servers regarding the banning of a particular registered re-source server, and as a result of a positive vote update the current rating score information for the particular registered resource server or ban the particular registered resource server from further participation in the system.

[0020] In some embodiments, an operating logic of the DNC is entirely defined in terms of the one or several smart contracts.

[0021] In some embodiments, the blockchain token is a fungible token.

[0022] In some embodiments, the DNC is configured to store a script, the script defining implementation-specific logic useful for a set of one or more of said resource servers.

[0023] In some embodiments, the DNC is configured to receive, from a script-requesting one of the resource servers, a script-requesting blockchain transaction and, in response to the receiving, provide the script to the script-requesting resource server.

[0024] In some embodiments, the script-requesting resource server is configured to use the script as a part of a software functionality provided by the script-requesting resource server to a peer communicating with the script-requesting resource server.

[0025] In some embodiments, the implementation-specific logic is configured to produce a result that is de-pendent on information relating to an updated status or communication activity of more than one of the peers and / or relating to topological proximity on the digital communication network of resource servers being involved in routing communication over the transport layer protocol between two or more peers. In some embodiments, one, several or all of the resource servers are configured to query the DNC for the updated routing information instead of relying on routing information previously stored in or by the resource server itself.

[0026] In some embodiments, the DNC is configured to receive, from an information-providing one of the resource servers, a routing information containing blockchain transaction comprising routing-related information for the information-providing resource server and, in response to the receiving of the routing information containing block-chain transaction, update the current routing information.

[0027] In some embodiments, the DNC is configured to receive, from a specification-providing one of the resource servers, a specification-providing blockchain transaction, the specificationproviding blockchain transaction comprising specification information regarding a hardware and / or software property of the specification-providing resource server.

[0028] In some embodiments, the DNC is configured to, in response to the specification-providing blockchain transaction, store on the blockchain the specification information or a derivative thereof and / or to update the current rating score information based on the specification information.

[0029] In some embodiments, the system further comprises a set of tags, each tag being descriptive of a type of resource server.

[0030] In some embodiments, the DNC is configured to store, on the blockchain, tag information regarding one or several tags pertaining to one or several of the resource servers as a function of the specification information and / or as a function of a topological location of the one or several resource servers in the digital communication network.

[0031] In some embodiments, the DNC is configured to select the selected resource server based on the tag information and further based on specific information regarding the requesting peer, a topological location of the requesting peer in the digital communication network and / or a specific property of a communication requested by the requesting peer.

[0032] In some embodiments, the DNC is configured to, in reaction to a change in the tag information, select as the selected resource server a different resource server, and to initiate a reconnection protocol with respect to the requesting peer to the different resource server.

[0033] In some embodiments, a reporting one of the resource servers is configured to detect and re-port to the DNC a predetermined misconduct of a particular peer, the reporting being in the form of a reporting blockchain transaction.

[0034] In some embodiments, the DNC is configured to, in response to the reporting blockchain trans-action, organize and execute a voting among the resource servers and / or providers of the resource servers and / or among the peers relating to the misconduct.

[0035] In some embodiments, the DNC is configured to, in the case of a positive vote, take a predetermined action in relation to the particular peer.

[0036] In some embodiments, the predetermined action is to update information on the blockchain regarding the ignoring of the particular peer.

[0037] In some embodiments, the resource servers are configured to ignore initiated communications from the particular peer as a function of the updated information.

[0038] In some embodiments, the resource servers are individual game servers providing functionality of a centralized or decentralized computer game.

[0039] In some embodiments, one or several peers is a respective player in the computer game.

[0040] In some embodiments, the system is a system for administrating, monitoring and managing a set of autonomous vehicles or vessels. In some embodiments, one or several peers is a respective one of the autonomous vehicles or vessels, or a fixedly installed installation for administrating, monitoring and / or managing the set of autonomous vehicles or vessels.

[0041] In some embodiments, the system is a system for providing a virtual private network, VPN.

[0042] In some embodiments, one or several of the resource servers is a VPN server.

[0043] Moreover, the invention relates to a method for real-time communication over a digital communication network, wherein a system comprises a plurality of resource servers, referred to in the following as the resource servers, each connected to the digital communication network and configured to communicate using a transport layer protocol; a blockchain; and a decentralized network coordinator, DNC, in the form of a decentralized application defined in terms of one or several smart contracts defined on the blockchain.

[0044] In some embodiments, the method comprising the steps the DNC receiving and processing blockchain transactions from each of the resource servers; the DNC storing updated routing information regarding digital communication between individual ones of the resource servers; one or several of the resource servers accessing the updated routing information; the DNC receiving from one or several sending ones of the resource servers blockchain transactions indicating a respective current status information of the sending resource server and / or of one or several other ones of the resource servers; the DNC organizing and executing an automated voting among the resource servers and / or providers of the resource servers resulting in an updated set of rating scores for one or several of the resource servers, the voting being based on the current status information; one or several of a plurality of peers accessing communication information from the blockchain, the communication information being useful for the peer to initiate communication, the initiated communication being over the transport layer protocol and using non-blockchain communication transactions, with a selected one of the resource servers; the selected resource server routing, in response to an initiated communication from the peer and using the updated routing information, non-blockchain communication transactions over the transport layer protocol between the peer and a different resource server and / or a different one of said peers; and the DNC providing remuneration to the selected resource server in the form of a blockchain token representing a value in dependence of the updated rating score for the selected resource server.

[0045] Furthermore, the invention relates to a computer software product defining a decentralized network coordinator, DNC, in the form of a decentralized computer software application defined in terms of one or several smart contracts defined on a blockchain, the one or several smart contracts being configured to, when executed on one or several processors of said system, perform the steps receiving and processing blockchain transactions from each of a plurality of resource servers, referred to in the following as the resource servers; storing updated routing information regarding digital communication between individual ones of the resource servers; receiving from one or several sending ones of the resource servers blockchain transactions indicating a respective current status information of the sending resource server and / or of one or several other ones of the resource servers; organizing and executing an automated voting among the resource servers and / or providers of the resource servers resulting in an updated set of rating scores for one or several of the resource servers, the voting being based on the current status information; providing communication information useful for a peer to initiate communication, the initiated communication being over a transport layer protocol and using non-blockchain communication transactions, with a selected one of the resource servers; and providing remuneration to the selected resource server in the form of a block-chain token representing a value in dependence of the updated rating score for the selected resource server.

[0046] In some embodiments, the computer software product is configured for real-time communication over a digital communication network, the DNC being part of a system also comprising the plurality of resource servers, each connected to the digital communication network and configured to communicate using the transport layer protocol, the computer software product being configured to, when executed on one or several processors of said system, perform the additional steps causing one or several of the resource servers to access the updated routing information; causing one or several of a plurality of peers to access communication information from the blockchain, the communication information being useful for the peer to initiate communication, the initiated communication being over the transport layer protocol and using non-blockchain communication transactions, with the selected one of the resource servers; and causing the selected resource server to route, in response to an initiated communication from the peer and using the updated routing information, non-blockchain communication transactions over the transport layer protocol between the peer and a different resource server and / or a different one of said peers.

[0047] The computer software product may be implemented by a non-transitory computer-readable medium encoding instructions that cause one or more hardware processors located in the system to perform the above-described method steps.

[0048] In the following, the invention will be described in detail, with reference to exemplifying embodiments of the invention and to the enclosed drawings, wherein:

[0049] Figure 1 is an overview of a system;

[0050] Figure 2 is a simplified view of a blockchain;

[0051] Figure 3 is a simplified view of a resource server; and

[0052] Figures 4 and 5 are flowcharts illustrating methods.

[0053] The Figures share the same reference numerals.

[0054] This invention generally relates to an approach to networking in real-time applications, such as gaming, particularly addressing the challenge of integrating the real-time, fast-paced nature of such applications with the predictability and reliability required in blockchain technology. The proposed solution involves the use of a blockchain as a coordinating layer, that can be managed by a Decentralized Autonomous Organization (DAO) to facilitate efficient and reliable networking for gaming and other applications. On a general level, the present invention proposes a DAO-governed real-time networking message system and method, in which the DAO oversees and manages network service providers and their associated network servers (in the following denoted "resource servers"). The DAO can consist of all the providers that participate in the network. The DAO is an autonomous organization that governs itself by voting on new providers that should be included in the network, the providers and / or their resource servers monitoring and reporting on each other when they are not online. According to a governance mechanism, the DAO facilitates voting to allow or revoke network provider access, thereby controlling the registration of their public keys in a DNC (see below). A protocol is established according to which the DAO, in agreement with providers, defines hardware specifications for resource servers and ensures these specifications are adhered to. Prior to a new provider and / or resource server joining, the providers can communicate via traditional means and negotiate with the new provider on the specifications that they should adhere to, e.g. that they expect a certain amount of CPU cores, RAM, physical location and / or network speed.

[0055] Further generally, the present invention proposes a system and method for decentralized content moderation within a real-time networking framework, enabling resource servers to report misbehaving peers (see below) by using their provider private keys, thereby initiating a moderation action; allowing peers to participate in the moderation process through a voting mechanism, enhancing community-driven governance; implementing a dynamic filter list managed by the DNC, which is accessible to all resource servers for real-time updates on moderated peers; and possibly ensuring all resource servers adhere to the filter list by ignoring messages from peers identified as misbehaving, maintaining network integrity and user safety.

[0056] As the term is used herein, a "blockchain transaction" is a record of an event, digitally signed for ensuring its authenticity, that is shared amongst a network of computers, generally called nodes. Each blockchain transaction can contain information such as the sender's and receiver's details, for instance represented as public keys or addresses, an amount or asset being transferred, and / or a timestamp. After the transaction is initiated, it must be validated by a majority of nodes in the network of nodes managing the blockchain on which the blockchain transaction exists. This can take place through a per se conventional process known as a consensus algorithm. Such a blockchain transaction, once confirmed, cannot be reversed, and instead becomes a permanent part of the blockchain, or more specifically of the digital ledger that constitutes the blockchain.

[0057] A "blockchain" is a collection of blocks, each containing such blockchain transactions, where the blocks are mathematically connected in a certain order by a later block containing the result of a one-way function (such as a hash function) the input of which is the payload of a previous block. The blocks will typically be stored in a distributed manner across several nodes that participate in said consensus algorithm to establish and validate additional blocks on the blockchain. Each such node can store parts of, or the entire, blockchain data structure.

[0058] As the term is used herein, a "smart contract" is a self-executing computer software program stored on a blockchain, typically in the form of one or several blockchain transactions wherein the computer software program is stored as a part of the corresponding blockchain transaction payload. Such smart contracts are configured to automatically execute transactions, such as moving assets between parties or updating various state information such as of a database 149, when certain specified conditions specified in the smart contract code are met. Such execution takes place automatically, without the need for a trusted third party. It is noted that such a "transaction", executed as a result of a definition of a smart contract, can itself be, but does not have to be, a "blockchain transaction".

[0059] As the term is used herein, a "Decentralized Networking Coordinator" (DNC) is a decentralized application, a so-called dApp, that runs on a blockchain. The DNC is defined in terms of one or several smart contracts that are configured to, when activated on the blockchain based on certain conditions being fulfilled, perform a logic of the DNC. Hence, such a DNC can constitute a piece of software functionality that runs completely autonomously, without requiring any manual input whatsoever from any user but that automatically and autonomously reacts to said conditions by executing said logic in relation to the blockchain on which it is defined. Typically, various parts of the DNC-defined logic, such as one or several software algorithms, are triggered by blockchain transactions defined in relation to said one or several smart contracts.

[0060] As the terms is used herein, and specifically in the context of blockchains, a "token" refers to a digital asset, such as a cryptocurrency asset, that is built (defined) on an existing blockchain. Tokens do not normally have their own blockchain, but depend on the underlying technology of the blockchain they are built upon. Tokens can be used to represent a wide range of digital assets or utilities and are often used for blockchain asset transactions within their specific environment.

[0061] There are two well-known types of such tokens.

[0062] The first type is fungible tokens, that are identical to each other and interchangeable. Examples include ERC-20 tokens on the Ethereum blockchain. For instance, in case a blockchain project issues fungible utility tokens such tokens can be configured to provide holders with the ability to access and use various services of the project, such as premium features or voting rights within the project's ecosystem.

[0063] The second type is non-fungible tokens (NFTs), that are unique and non-interchangeable. Examples include ERC-721 tokens on the Ethereum blockchain. NFTs have conventionally been used for digital art or collectibles, in the sense that artists can create unique tokens on a blockchain, each non-fungible tokens representing a particular piece of their digital artwork, and users can then purchase these tokens to "own" the original digital pieces.

[0064] As the term is used herein, a "cryptocurrency" is a carrier of a value, that can be translatable to a monetary value, the carrier possibly being in the form of a token of the mentioned type, such as a fungible token. For instance, a certain amount of such a cryptocurrency on a particular blockchain can be associated with a blockchain address (such as a public key) of a particular blockchain in the sense that the owner of a private key corresponding to said public key has the capacity to "spend" the certain amount by signing a blockchain transaction to that effect onto a different blockchain address. As the term is used herein, a "decentralized autonomous organization" (DAO) is a type of organization represented by rules encoded as a transparent computer program controlled by shareholders and potentially no-one else. Financial transactions, as well as any logic, algorithms and rules in relation to the operations of the DAO are maintained on a blockchain, making the logical structure and functionality of the DAO open and accessible to all parties involved. DAOs allow for open, organized, and decentralized decision-making structures by deploying smart contracts on a blockchain defining and encoding said logical structure and functionality. For instance, a DAO can be configured so that owners or shareholders in the DAO can make proposals and vote on changes or decisions, which the DAO then automatically enforces on the blockchain. For example, a DAO can manage itself. The logical structure and functionality of the DAO can, in practice, be implemented using a DNC of the type described above, in a way so that the DAO can affect the DNC to reflect varying needs, or alternatively in a non-modifiable manner so that for instance the functionality defined by the DNC always stays the same.

[0065] Figure 1 shows an overview of a system 100 that can comprise a DAO 150 of said general type. The DAO 150 can be configured to govern one or several network service providers 200 and to manage a network of resource servers 210 through democratic voting processes. Each of the DAO 150, the network service providers 200 and the resource server 210 can form part of the system 100 or be separate entities, external to the system 100.

[0066] The system 100 can furthermore incorporate a DNC 130 to facilitate network service provider 200 registration, resource server 210 maintenance and / or content moderation as described herein.

[0067] Unless explicitly stated, the functionality of the DAO 150 can be completely defined by the DNC 130, that in turn can be completely defined by a set of one or more smart contracts on a blockchain 140. The blockchain 140 itself can comprise one or more parallel blockchains and / or one or more subchains. The solution proposed herein can involve the integration of a DAO-driven governance model with real-time messaging capabilities, ensuring a secure, efficient, and user-regulated networking environment.

[0068] More particularly, the system 100 is configured for real-time communication between peers 20 and / or resource servers 210 over the digital communication network 10.

[0069] There may be at least one, such as a plurality of, for instance at least three, or at least ten or even at least one hundred, resource servers 210. Each resource server 210 can be connected to the digital communication network 10 and configured to communicate with the various other entities described herein over the digital communication network 10 and using a transport layer protocol. The transport layer protocol can be a layer 4 according to the conventional OSI (Open System Interconnection) model for computer communications.

[0070] The system 100 can also comprise the blockchain 140, that can be distributed across a plurality of blockchain nodes. In some cases, one, some or all of the resource servers 210 each is or comprises such a blockchain node.

[0071] The system 100 can further comprise the DNC 130, in the form of a decentralized application of the above-discussed type, defined in terms of one or several smart contracts 142 defined on the blockchain 140. Hence, the DNC 130 can be defined on the blockchain 140, and in Figure 1 the DNC 130 and blockchain 140 are therefore marked as the same entity. It is, however, realized that the blockchain 140 can (and typically is) be configured with additional functionality in addition to the DNC 130, and that the DNC 130 can comprise, or be defined in terms of, logic or functionality residing outside of the blockchain 140. One example of such outside logic or functionality is functionality for reading external information sources, another example is functionality for affecting states of external entities. Such external sources or entities can be, for example, other blockchains or software functionality available via APIs. Some of the functionality of the DNC 130 can also, in some embodiments, be defined in terms of smart contracts on external blockchains. The DNC 130 is responsible for things like orchestration, payments and voting as described herein.

[0072] In Figure 1, the DAO 150 can be of the above-discussed type, and 200 is one or several providing parties ("providers"), that can be, for instance, shareholders to the DAO 150. In practical examples, the DAO 150 can consist of, or comprise, any, some or all of the providers 120. Hence, the providers 120 can govern themselves, via the DAO 150, by voting on things such as allowing additional providers 120 into the system 100, as well as moderating themselves, such as getting rid of providers 120 that do not behave according to predetermined rules or by reporting each other to affect current ratings regarding individual providers 120 and / or network resource providers 210. Each provider 200 can have, provide, be associated with and / or communicate with zero, one or several resource servers 210.

[0073] The network resource servers 210 can be configured to communicate directly with the DNC 130. All communication between the various parties described herein can take place over the internet 10, or over a different suitable digital wired and / or wireless communication network.

[0074] One or several peers 20 have a need to utilize the system 100, and in particular to communicate among each other and / or with one or several of the network resource servers 210. The peers 20 also communicate directly with the DNC 130, for instance in order to figure out which network resource server 210 to use to fulfill such needs. The peers 20 can be thought of as users of functionality provided by the system 100, and in particular of resources provided by the resource servers 210. For instance, the peers 20 can be computers used by players in a computer game; vehicles operated by drivers in a traffic system; or connecting computers to a VPN (Virtual Private Network) service.

[0075] Each of the peers 20 can use the network resource servers 210 to engage in real-time communication using various transport layer protocols, such as TCP (Transmission Control Protocol) and UDP (User Datagram Protocol), according to application needs. SCTP (Stream Control Transmission Protocol), CCP (Compression Control Protocol), RSVP (Resource Reservation Protocol) and RUDP (Reliable User Datagram Protocol) can also be useful alternatives. This real-time communication, that can be a communication between different peers 20 and / or a communication between each peer 20 and one or several network resource server 210, can be a non-blockchain communication service, providing an interface for peers 20 to submit and receive non-blockchain real-time messages among each other and / or in relation to one or several network resource servers 210.

[0076] Each peer 20 can be a computer software implemented functionality executing on a physical or logical piece of hardware. Such hardware can in itself be centralized or distributed, and can comprise a CPU or other computing processor; a RAM or other digital computer memory; a computer bus or other digital communication arrangement; and one or several peripherals such as one or more of a keyboard, a computer mouse, a display, a speaker, a microphone and a wired or wireless digital communication interface. The corresponding can individually be true for each of the other entities described herein, in particular for the DAO 150, the providers 200, the resource servers 210 and / or the blockchain nodes 110, 120.

[0077] If nothing else is stated, all functionality described herein is performed automatically, digitally and electronically, and by corresponding software functions executing on such computer hardware.

[0078] The blockchain 140 can be stored, in each or any storing node 110, 120, on a persistent storage medium, such as a physical or virtual hard drive.

[0079] In Figure 1, 110 denotes validating blockchain nodes and 120 denotes non-validating blockchain nodes. The system 100 can comprise one or several, such as at least three, such as at least ten, or even at least one hundred, validating blockchain nodes 110; and / or one or several, such as at least three, such as at least ten, such as at least one hundred, or even at least one thousand, non-validating blockchain nodes 120. It is noted that all such nodes 110, 120 are nodes to one and the same blockchain 140 (the blockchain 140 being of the abovedescribed general type and used by the system 100 in the ways described herein). Each such node 110, 120 can store part of the blockchain 140 or the entire blockchain 140. A per se conventional consensus algorithm can be run across the validating blockchain nodes 110 so as to propagate the blockchain 140 over time in a way allowing the validating nodes 110 to agree on a most recent state of the blockchain 140 at each point in time that is locally synchronized to, and stored in, each validating node 110. This propagation can take place by the agreement on, and adding of, new blocks to the blockchain 140. Non-validating nodes 120 do not participate in the validation of blocks of the blockchain 140, but receive synchronization information allowing them to locally keep a synchronized copy of parts of the, or the entire, blockchain 140. In some cases, there are more non-validating nodes 120 than validating nodes 110.

[0080] A validating node 110 can also be denoted a "full node"

[0081] A non-validating node 120 can also be denoted a "replica node" or a "read-only node", and is also known in the art as a "lightweight" or "SPV" (Simplified Payment Verification) node. In a blockchain network, this is a node that does not fully validate all transactions or blocks. Instead, it can sometimes download only a part of the blockchain 140, or rely on one or several full nodes 110, to send and receive transactions. Non-validating nodes 120 can be "read-only" in the sense that they are configured to view and broadcast transactions but not to participate in the consensus protocol or the block validation process. Their purpose is to allow users to interact with the blockchain 140 with less resource usage (like CPU power, storage, or bandwidth), making them suitable for devices with lower capacity. Nonvalidating nodes 120 also allow the blockchain 140 to be scaled horizontally by adding additional non-validating nodes 120 that can be used for querying data from the blockchain 140 without impacting other nodes 110, 120 in the system 100.

[0082] Figure 2 is a simplified view of the blockchain 140, comprising blocks 141 that each in turn can comprise one or several blockchain transactions 147. Each such blockchain transaction can comprise one or more of the following pieces of information:

[0083] One or several smart contracts 142, defining the DNC 130 as described above. • Resource node 210 status and / or routing information 143, and / or a reference to such information 143 stored not directly on the blockchain 140.

[0084] • An application-specific script 144, and / or a reference to an application-specific script 144 stored not directly on the blockchain 140.

[0085] • Resource node 210 and / or peer 20 rating score information 145, and / or a reference to such information 145 stored not directly on the blockchain 140.

[0086] • Tag information 146, and / or a reference to such information 146 stored not directly on the blockchain 140.

[0087] In addition, each block 141 can comprise a previous block hash 148 or a result of another one-way function securely tying together the blocks 141 in an ordered sequence.

[0088] Figure 3 is a simplified view of a resource server 210, possibly comprising a private key 211 and / or routing information 213. The private key 211 can be the private key of a publicprivate key pair, such as a PKI (Public Key Infrastructure) key pair. The private kay 211 can be stored by the resource server 210 in a way making it unknown to other entities. A corresponding public key 212 can be stored by the DNC 130, as is shown in Figure 2. The private key can belong to a provider 200 in charge of the resource server 210, or the private key can belong directly to the resource server 210.

[0089] It is understood that Figure 2 is a simplified view, and that the information 212, 142, 143, 144, 145 and 146 shown in Figure 2 is not necessarily stored as a part of individual blockchain transactions 147. As is well-known per se, there are other ways to store information "on" a blockchain 140, including so-called "coloured coins". In particular, all the information 212, 142, 143, 144, 145 and 146 does not have to be included in, or even be associated with, each blockchain transaction 147. What is important is that the one or several smart contracts defining the functionality of the DNC 130 include functionality that can store, update and access the information 212, 142, 143, 144, 145, 146. Preferably, any, some or all of the information 212, 142, 143, 144, 145, 146 is stored in a way so that it is cryptographically protected by the structure of the blockchain 140, and cannot be mutated without spoofing the blockchain 140. For instance, this can be achieved by storing a hash of relevant information as a part of a validated blockchain transaction 147 in at least one block 141. Either way, the information 212, 142, 143, 144, 145, 146 is hence stored "on" the blockchain 140 in a broad sense. As the exact storage principle on the blockchain 140 does not affect the other functionality described herein, this is not elaborated on further.

[0090] Each blockchain node 110, 120 can hence store a local copy of a part of the blockchain 140, or the entire blockchain 140, such local copy being synchronized and updated across the network of blockchain nodes 110, 120 so that each such local copy is replicated over time. This replication can be a result of the consensus mechanism used by the validating blockchain nodes 110 to lock in new blocks 141.

[0091] It is understood that the replication can be continuously ongoing, but that each marginal replication may not be immediate, but can take some time to accomplish. However, the blockchain 140 as a whole can be viewed as a well-defined set of information that can be accessed, perhaps at some delay depending on the detailed implementation of the replication algorithm, and evaluated. In particular, that the DNC 130 is implemented as a set of at least one smart contract "on" the blockchain means that any of the blockchain nodes 110, 120 can be accessed to read a current state of the blockchain 140, and that at least any one of the validating blockchain nodes 110 can be accessed to initiate a blockchain transaction 147 giving rise to the DNC 130 reacting in accordance with the functionality defined by said one or more smart contracts. In the following, the DNC 130 will be described as one logical entity that can be accessed in a logically unambiguous manner, even if it is understood that a mechanism of the general type described is typically used to interact with this logical entity. The corresponding applies to the blockchain 140.

[0092] In particular, the DNC 130 can be configured, in other words defined in terms of said one or more smart contracts on the blockchain 140, to receive and process blockchain transactions 147 from each of the resource servers 210. The resource servers 210 each comprises software functionality configured to at least initiate such blockchain transactions, and also configured to read and interpret information off the blockchain 140 as described herein. The DNC 130 can furthermore be configured to validate each received blockchain transaction using a respective public key 212 which has been registered with the DNC 130 for each particular resource server 210, and in particular for the particular resource server 210 initiating the blockchain transaction 147 to be validated. As mentioned, the public key 212 corresponds to the private key 211 of the initiating resource server 210.

[0093] The resource server 210 is configured to use its private key 211 to sign the or each blockchain transaction 147 it initiates. Hence, the public key 211 can be used by the DNC 130 to verify that the blockchain transaction 147 in question was indeed signed using the private key 211 corresponding to the public key 212 stored on the blockchain 140 and associated with the initiating resource server 210 in question.

[0094] The DNC 130 is configured to, in reaction to the receipt of such blockchain transaction 147 which it has verifiably received from the resource server 210 in question, store, on or in connection to the blockchain and based on the processed blockchain transactions, updated routing information 143 regarding digital communication between individual ones of the resource servers 210.

[0095] The routing information 143 can be updated based, for instance, on the fact that the resource server 210 signing the blockchain transaction 147 is alive, in the sense that it signed the blockchain transaction 147 and provided it to the DNC 130. This informs the DNC 130 that the resource server 210 is available for receiving routed real-time communication messages. The blockchain transaction 147 can also contain information making it explicit that said functionality is available at the resource server 210 and / or information regarding an updated or amended set of communication and / or processing functionality of the resource server 210.

[0096] The routing information 143 can be updated based on information provided as a part of, or associated with, the signed blockchain transaction 147. Namely, the DNC 130 can be configured to receive, from the signing resource server 210, a piece of routing information as a part of, or associated with, the signed blockchain transaction such that the routing information comprises routing-related information for the information-providing resource server 210. Such routing-related information can be specific to the signing resource server 210, and can for instance comprise information about a current communication capability and / or capacity of the resource server 210, and / or information regarding a current communication connection between the resource server 210 and one or several of other resource servers 210. The DNC 130 can further be configured to, in response to the receiving of the routing information-containing blockchain transaction, update the current routing information 143 in the DNC 130. The routing information 143, as well as any other information stored by or in the DNC 130 can be stored on or in connection to the blockchain 140 in any of the ways described above, so that the information is tied to the blockchain 140 in a safe manner, in the sense that the blockchain 140 itself needs to be changed (spoofed) in order to change the information stored.

[0097] Moreover, the DNC 130 can be configured to allow each of the resource servers 210 to access the updated routing information 143 of the DNC 130. Such access can be a simple reading by the resource server 210 in question of the blockchain 140, since the routing information 143 is stored thereon. In other cases, the DCN 130 can receive a routing-querying blockchain transaction from a querying one of the resource servers 210 and, in response thereto, provide the updated routing information 143 to the querying resource server 210.

[0098] The system 100 can also, in some embodiments, comprise a separate software module configured to accept queries regarding information stored on or in connection to the blockchain 140 and to respond by reading and returning such information to a querying entity.

[0099] In general, all requests from resource servers 210 to modify status information stored on or in connection to the blockchain 140 will normally be conveyed using blockchain transactions initiated by a requesting resource server 210. Such blockchain transactions can be signed by the requesting resource server 210, using its private key as described above. However, in other embodiments any or all requests by resource servers 210 to read status information stored on the blockchain 140 can simply be resolved by the resource server 120 reading directly (or indirectly, via a blockchain 140 read-out service) the corresponding information from the blockchain 140.

[0100] In some embodiments, at least one, but possibly several or even all of the resource servers 210 are configured to, at least intermittently or periodically, request the updated routing information 143 (in other words, from the blockchain 140), instead of relying on routing information 213 previously stored in or by the resource server 210 itself. In other words, the routing information 213 stored in or by the resource server 210 can be updated using the corresponding routing information 143 stored by the DNC 130. This updating can occur for all or parts of the routing information 213 stored in or by the resource server 210, and can take place periodically or as triggered by certain predetermined conditions. Generally, the routing information 213 stored by each resource server 210 is at least partly provided from the DNC 130 and the routing information 213 stored by each resource server 210 is updated over time using corresponding routing information provided from the DNC 130.

[0101] Hence, this way the blockchain 140 takes over the task of orchestration of communication routing between peers 20 and resource servers 210, and acts as a trusted and fair central component, in effect removing that responsibility from the resource servers 210 themselves. Each resource server 210 does not need to keep updating a locally held routing table using continuously collected routing information collected by the resource server 210 itself. Instead, the blockchain 140 can be responsible for this updating, based only on routing- related information received from the individual resource servers 210, and the resulting updated routing information 143 can simply be downloaded to each resource server 210. This provides for more efficient updating of the routing information 213 store in or by each resource server 210. In particular, the resource servers 210 can rely on the DNC 130 as a central distributed component to provide the relevant routing table(s). This simplifies the responsibility of each resource server 210, since it does not have to constantly synchronize with all the other resource servers 210. Instead, each resource server 210 only needs to communicate with the DNC 130 to get the routing table(s). In particular, the routing information 143 held centrally by the DNC 130 can take into consideration the global view of the network topology, involving all available and interconnected resource servers 210, as opposed to only the respective individual view of the network topology local to each individual resource server 210.

[0102] In some embodiments, all changes to the routing information 143 stored by the DNC 130 need to be updated via a formal, duly signed blockchain transaction to the DNC 130, for instance from individual resource servers 210.

[0103] It is understood that the routing information 143 stored by the DNC 130 can be in the form of a routing table and / or other type of routing-related information, such as communication availability or reliability information regarding individual resource servers 210 and / or regarding communication paths between individual resource servers 210; and / or communication speed or bandwidth information regarding individual resource servers 210 and / or regarding communication paths between individual resource servers 210. The routing information 143 can be stored in any suitable manner, as long as it is unambiguously accessible and consumable, such as readable and parsable, by each requesting resource server 210.

[0104] In a manner that may be similar to the storing of the routing information 143, the DNC 130 can be configured to store, on or in connection to the blockchain and based on the processed blockchain transactions, updated rating score information 145 for one, several or all of the resource servers 210.

[0105] In particular, the DNC 130 can be configured to receive, from one or several sending ones of the resource servers 210, blockchain transactions 147 indicating a respective current status information of the sending resource server 210 and / or of one or several other ones of the resource servers 210. Such blockchain transactions can also be signed and verified as described above. For instance, the current status information can be the above-mentioned blockchain transaction indicating that the initiating resource server 210 is alive, in which case the routing-information update transaction and the status-information transaction can be one and the same blockchain transaction. However, the current status information provided by the resource server 210 can also comprise more detailed information, such as regarding an updated current available communication speed, processing speed, bandwidth and / or application-specific functionality of the initiating resource server 210.

[0106] The current status information provided by the resource server 210 can also comprise information regarding one or several other resource servers 210 than the resource server initiating the status-updating transaction. For instance, resource servers 210 can be configured to moderate each other by periodically or intermittently pinging each other. If a resource servers 120 finds that another resource server 120 does not respond to such pinging, it can be configured to report that to the DNC 130 via a corresponding status-updating blockchain transaction. In other embodiments, specific incidents such as an unexpected non-response to a communication message of a certain resource server 210, or the unexpected interruption, delay or scrambling of communications sent from the certain resource server 210, can be reported by a different resource server 210 to the DNC 130, using a corresponding blockchain transaction, reporting that the certain resource server 210 was not working as expected at the particular point in time.

[0107] Hence, the DNC 130 is configured to keep an updated status information regarding the resource servers 210. This status information can be a part of the routing information 143, or can alternatively be kept as a separate set of information by the DNC 130, that can then be stored on or in connection to the blockchain 140 in the general manner discussed above.

[0108] Then, the DNC 130 can be configured to organize and execute an automated voting among the resource servers 210, the voting being based on said current status information stored by the DNC 130. In this voting, as well as all votings described herein where resource servers 210 participate, providers 200 of the resource servers 210 can vote instead or in addition to the resource servers 210 themselves. Irrespectively of if a provider 200 or a resource server 210 votes, the vote is preferably in a corresponding voting blockchain transaction 147, that can be signed using the corresponding private key and processed on the blockchain 140 by the DNC 130. As discussed above, the current status information can be of different types. For example, a resource server 210 can periodically or intermittently send blockchain transactions to the DNC 130 to report that they are online, healthy and / or available. The result of such blockchain transaction is that the blockchain transaction, and hence the related status information, is recorded on each blockchain node 110, 120 that runs the DNC 130 so that it is accessible for all resource servers 210. Another example is the self-monitoring logic where each resource server 210 pings each other's networking services from time to time. If a resource server 210 fails to reach another resource server 210, then they will report it to the DNC 130 using a blockchain transaction in the corresponding manner.

[0109] The automatic voting can be implemented and defined in terms of said one or several smart contracts on the blockchain 140, and can be configured to allow each resource server 210 to vote in relation to one or several particular resource server(s) 210 based on current status information accessed by the voting resource server 210 from the DNC 130. The voting can be free, in the sense that an operator 200 in charge of the voting resource server 210 can subjectively evaluate the current status information with respect to a particular resource server 210 to vote about; or it can be rule-based, so that a particular read current status information automatically results in a certain vote by the operator 200 or the resource server 210. Such rule-based voting can be based on predetermined or dynamically changing voting rules defined by the operator 200 or voting resource server 210 in question, and can be the same or different across different operators 200 and / or voting resource servers 210. The vote can be in the form of a corresponding initiated, and possibly signed, blockchain transaction 147, carrying the voting information from the initiator of the vote blockchain transaction 147.

[0110] In some embodiments, it is the operator 200 that does the voting, by initiating the vote blockchain transaction 147. Such blockchain transaction 147 can be signed using the private key of the operator 200 or corresponding resource server 210 operated by the operator 200, in the manner generally described above. In other embodiments, it is the resource server 210 that does the voting, possibly at the command of an operator 200 of the resource server 210. Generally, the voting can be within the realm of the DAO 150. In other words, the participants to the DAO 150 can vote for items on the blockchain 140. What is said here regarding the vote based on the current status information can be equally applicable for any other voting mechanisms in the system 100.

[0111] The voting mechanism can be a simple majority, or supermajority, voting procedure. The voting mechanism, once the voting blockchain transactions 147 have been initiated and reached the DNC 130, can be fully automated and impossible to affect in any other way than voting parties throwing their vote in the form of corresponding voting blockchain transactions 147 that are consumed by, and acted upon, by the DNC 130 as stipulated by said one or several smart contracts. Such smart contract voting mechanisms are well-known as such, and will not be described in any detail herein.

[0112] The voting can result in that the rating score information 145 stored by the DNC 130 on the blockchain 140 is automatically updated, for one or several of the resource servers 210, as a consequence of the vote result.

[0113] More particularly, each resource server 210 can have an individual rating score stored in or by the DNC 130. Said one or several smart contracts can then be programmed to deduct the rating score of a particular resource server 210 that underperforms as reported by one or several of the other resource servers 210, for instance by it failing to stay online. The one or several smart contracts can also be programmed to allow a resource server 210 to raise or recover their rating score if they are reported, such as by self-reporting or by reporting by other resource servers 210, to stay online over a certain minimum time period.

[0114] The voting can be, but does not have to be, explicit, in the sense that specific voting blockchain transactions 147 have to be issued for each cast vote, but can instead be based directly on said reporting so that a particular reporting behavior unambiguously results in a particular outcome in terms of changed rating scores. In a simple example, if enough resource servers 210 and / or operators 200 report a certain resource server 210 to malfunction or misbehave, so that a required majority or supermajority is reached on the issue, then the one or several smart contracts can be configured so that certain resource server 210 as a result automatically has their rating score lowered. Hence, in this example the voting blockchain transaction and the reporting blockchain transaction can actually be one and the same blockchain transaction 147.

[0115] However, the voting can also be explicit, and be organized for instance periodically or upon the request of the DNC 130 itself or any of the resource servers 210.

[0116] In addition to the DNC 130 being configured to allow the resource servers 210 to access information stored on the blockchain 140, the DNC 130 can also be configured to allow each of the peers 20 access to information stored on the blockchain 140. In a way corresponding to the access provided to the resource servers 210, the access to the peers 20 can also be provided by the DNC 130 accepting information-requesting blockchain transactions 147 from the peers 20 and / or by the peers 20 simply reading information stored on the blockchain 140 themselves and / or the peers 20 using said additional information-providing additional software function in turn reading information stored on or in connection to the blockchain 140.

[0117] At any rate, the DNC 130 can be configured to allow each of the plurality of peers 20 to access communication information from the blockchain 140, the communication information being useful for the peer 20 to initiate communication, the initiated communication being over said transport layer protocol and using non-blockchain communication transactions, with a selected one of the resource servers 210. As will be clear from the below, the information-accessing peer 20 can be the one selecting the resource server 210, but the typical situation is that the DNC 130 automatically selects the resource server 210 for the peer 20 to communicate with based on certain criteria. In other words, the peer 20 be allotted a resource server 210 to use for communication in the particular current setting. The selected resource server 210 can be a point of direct contact for communications to and from the peer 20.

[0118] The selected one of the resource servers 210 is then configured to, in response to an initiated communication from the peer 20 based on the communication information received from the DNC 130, route real-time communication between the peer 20 and a different resource server 210 and / or between the peer 20 and a different one of the peers 20. This routing can take place using the updated routing information 143 that the selected one of the resource servers 210 has received from the DNC 130 as described above. The real-time communication comprises non-blockchain communication transactions that are mediated over the transport layer protocol, such as TCP, UDP, SCTP, CCP, RSVP or RUDP. In preferred embodiments, the real-time communication does not encompass any blockchain transactions but only non-blockchain communication message transactions.

[0119] Furthermore, the DNC 130 can be configured to provide remuneration to the selected one of the resource servers 210 for the routing services provided by the selected resource server 210. The remuneration is at least partly, such as completely, in the form of one or several blockchain tokens. Such blockchain tokens can, for instance, be cryptographically tied to the blockchain 140 in a way which is conventional as such, and can be automatically spent, as a result of the execution of said one or several smart contracts in connection to the resource server 210 being selected for routing and / or in connection to an automatic verification by the DNC 130 that the routing actually occurred, to a public key or blockchain address controlled by the resource server 210 or an operator 200 in charge of the resource server 210.

[0120] The remuneration can be configured to represent a value that depends on the updated rating score for the selected resource server 210. For instance, a better or higher rating score for a resource server 210 can result in a higher renumeration for the same routing service performed, and vice versa.

[0121] This way, the DNC 130 can be configured to achieve fully automatic routing of peers' communication between each other and with different resource servers 210, the routing being based on dynamically updated and current routing information that depends on varying operating prerequisites for the resource servers 210.

[0122] The tokens can be fungible tokens. For example, the DNC 130 can be programmed to automatically distribute tokens to each resource server 210, or corresponding operator 200, once every month, or at any other suitable time interval, or directly in connection to each performed routing service, in reaction to the resource server 210 sending a blockchain transaction 147 to report that they are online.

[0123] For instance, tokens can represent anything from a unit of value (like a digital dollar), a service (such as right to cloud storage), or a vote in the governance system of a specific project.

[0124] As discussed above, the system 100 can comprise a plurality of validating blockchain nodes 110, each storing part of the, or the entire, blockchain 140, including the DNC 130. Each such validating blockchain node 110 can be configured to propagate the blockchain 140 by validating blocks, using a consensus algorithm in collaboration with the other validating blockchain nodes 110. Such consensus algorithms are well-known as such, and can include elements of proof-of-work, proof-of-stake and / or simple voting mechanism.

[0125] In some embodiments, each blockchain transaction 147 from each individual resource server 210 is directed to only one of the blockchain nodes 110, such as a validating blockchain node 110 or, in some cases, a non-validating blockchain node 120 that can then forward such blockchain transaction 147 to a validating blockchain node 120 for processing and addition to the blockchain 140 using said consensus mechanism.

[0126] The one or several non-validating blockchain nodes 120, that are configured to not participate in the consensus algorithm, can provide routing, status and / or rating score information of the above-discussed type to requesting parties, such as to a resource server 210 or a peer 20. This is possible because, even if such non-validating blockchain nodes 120 cannot participate in the validation of additional blockchain transactions 147, they can still hold part of, or the entire, blockchain 140, and as a result also said information.

[0127] In particular, the DNC 130 may hold, such as store on or off the blockchain 140 or be associated with, a database 149 with information about available resource servers 210. The database 149 can be indexed and / or searchable. In particular, non-validating nodes 120 can be configured to access or replicate the information in this database 149. It is realized that validating nodes 110 can also be configured to access or replicate the information in the database 149. Such database 149 will normally be stored on or in connection to the blockchain 140 in the way generally described above, and hence be cryptographically tied to the blockchain 140 in a secure manner and without any system 100 participants being able to modify the database 149 information without using the mechanisms of the DNC 130.

[0128] Using the above-described mechanisms, the DNC 130 can be configured to incentivize, via said tokens, resource servers 120 to behave "well", in an unambiguously defined sense, such as to have a high up-time and not prematurely exit the network. This can be achieved using the rating score information 145 programmed as part of the one or several smart contracts defining the DNC 130 functionality, dictating steps configured to achieve that resource servers 210, with a high up-time and otherwise "good" behavior in said sense, are paid extra tokens, while resource servers 210 that misbehave in one or more well-defined ways are paid less tokens. If certain defined conditions are met, the DNC 130 can even be configured to evict certain resource servers 210 from the system 100, such as if they go under a predetermined scoring rate threshold.

[0129] The blockchain 140 implementation achieves the above in a decentralized manner. The blockchain 140 essentially allows the scaling of the system 100, ensuring high resource server 210 availability without compromising on the decentralized aspect.

[0130] The blockchain 140 can be configured for horizontal scaling by adding additional non-validating nodes 120, wherein such non-validating nodes 120 can store and possibly index said database 149 over available resource servers 210. In some cases, at least one, some or each of the individual resource servers 210 can selectively connect to to their very own non-validating node 120 for full horizontal scalability.

[0131] Hence, while a blockchain node 110, 120 is potentially configured to be very powerful, so that it can handle a massive amount of concurrent requests and / or requests per time unit, it is also possible to introduce non-validating nodes 120 as additional nodes that individually can replicate the same state and data integrity. It is noted that this addition does not incur any additional stress on the blockchain 140 network of nodes 110, 120.

[0132] As mentioned initially, using conventional decentralized networking solutions, with each additional node added into such a network, maintaining real-time consistency and synchronization across all of the nodes can be very challenging in terms of communication overhead, compute and so forth.

[0133] Figure 4 illustrates a method for operating the system 100. In a first step 401, the method starts. Figure 5 offers a similar view, in the form of a simplified flow chart of certain select activities flowing between the various actors described herein.

[0134] In an optional subsequent step 402, the DNC 130 can be configured to receive a request to register an additional resource server 210, such as in the form of a corresponding blockchain transaction 147 initiated from the new resource server 210 itself or an operator 200 wanting to deploy the new resource server 210.

[0135] In an optional subsequent step 403, the DNC 130 can then be configured to organize and execute an automated voting among the resource servers 210 regarding the registration of this new resource server 210. This voting can be of the general type discussed above, and be conducted in the corresponding manner. In connection to the voting, or before, the voting entities can be provided with information about the new resource server 210, for instance provided by the provider 200 wanting to deploy the new resource server 210 and mediated by the DNC 130 using corresponding information-carrying blockchain transactions 147.

[0136] In an optional subsequent step 404, performed as a result of a positive vote, the DNC 130 can be configured to register the new resource server 210 with the system 100. From that point on, the new resource server 210 can be configured to form part of the plurality of resource servers 210 in the system 100 in the various ways described herein, and in particular information regarding the new resource server 210 can be stored in said database 149. Concretely, the voting can comprise a majority or a supermajority of the providers 200 or the resource servers 210 having to sign a respective blockchain transaction 147 wherein they explicitly approve that this new provider is welcome to join, such as using a predetermined format for the blockchain transaction 147.

[0137] In connection to steps 402-404, the public key corresponding to the private key of the new resource server 210 can be supplied, such as by the new resource server 210 or the provider 200 in charge of the new resource server 210, to the DNC 130. However, it is realized that the public key does not necessarily have to be provided to the DNC 130, what is important is rather that the DNC 130 has access to the public key in some way to be able to perform the above-discussed validation of blockchain transactions 147.

[0138] In an optional step 405, one, several or each resource server 210 can be configured to periodically send a heartbeat blockchain transaction to the DNC 130, that the DNC 130 is configured to receive.

[0139] In an optional subsequent step 406, the DNC 130 can be configured to receive the heartbeat blockchain transaction and to, in an optional subsequent step 407, update the current rating score and / or status information 143, 145 with respect to the sending resource server 210 based thereon. For instance, the rating score information 145 can be caused to increase (improve), or at least not to decrease (worsen), based on the fact that the heartbeat blockchain transaction was received and processed by the DNC 130.

[0140] In an optional set of steps 408-409, the DNC 130 can be configured to organize and execute an automated voting among the resource servers 210 or providers 200 regarding the banning of a particular registered resource server 210, and as a result of a determined positive vote update the current rating score information 145 for the particular registered resource server 210 or ban the particular registered resource server 210 from further participation in the system 100. The vote can be initiated, for instance, by a provider 200 or a resource server 210. In a step 410, the DNC 130 can receive and process blockchain transactions from any, some or each of the resource servers 210 as described above, each blockchain transaction being validated by the DNC 130 using the registered public key 212 of each particular resource server 210, the public key 212 corresponding to a private key 211 of the particular resource server 210, the private key 211 being used by the particular resource server 210 to sign the blockchain transaction. At least some of these blockchain transactions can be heartbeat transactions of the above-described type. Any of the blockchain transactions 147 described herein, and initiated by the resource servers 210 or the providers 200, can be signed by the corresponding private key.

[0141] In a subsequent step 411, the DNC 130 can store updated routing information 143 as described above, the routing information 143 being regarding the routing of digital communication non-blockchain transactions between individual ones of the resource servers 210.

[0142] In a subsequent step 412, one or several of the resource servers 210 can access the updated routing information 143, as described above.

[0143] In a step 413, the DNC 130 can store updated rating score information 145 for one or several of the resource servers 210, for instance based on received heartbeat blockchain transactions 147 and / or updated status information blockchain transactions 147 from one or several of the resource servers 210, in the manner described above. For instance, the DNC 130 can receive from one or several sending ones of the resource servers 210 blockchain transactions to this end, indicating a respective current status information of the sending resource server 210 and / or of one or several other ones of the resource servers 210.

[0144] In a subsequent step 414, the DNC 130 can organize and execute an automated voting among the resource servers 210 or providers 200, resulting in an updated set of rating scores for one or several of the resource servers 210 as described above, the voting being based on the current status information. In an optional subsequent step 415, the DNC 130 can receive a request from one of the peers 20, the request being in the form of a blockchain transaction 147 to this end and being a request for communication with the system 100.

[0145] In an optional subsequent step 416, the DNC 130 can select one of the resource servers 210 for providing to the requesting peer 20 such communication with the system 100.

[0146] In some embodiments, the selection of the resource server 210 can take place in other ways or by other entities, such as the peer 20 itself selecting a resource server 210 based on information available on the blockchain 140.

[0147] In a subsequent step 417, one or several of the peers 20 can access communication information from the blockchain 140, the communication information being useful for the peer 20 in question to initiate communication, the initiated communication being over the transport layer protocol and using non-blockchain communication transactions, with the selected one of the resource servers 210. This access can also be performed as generally described above.

[0148] In a subsequent step 418, the selected resource server 210 can route non-blockchain communication transactions over the transport layer protocol between the peer 20 and a different resource server 210, or between the peer 20 and a different one of the peers 20. The routing can be in response to an initiated communication from the peer 20.

[0149] In a subsequent step 419, the DNC 130 can provide remuneration to the selected resource server 210 for the performed routing services, in the form of a blockchain token as described above, the token representing a value in dependence of the updated rating score for the selected resource server 210. The remuneration can also, or instead, be provided to a provider 200 of the resource server 210 in question.

[0150] In an optional step 420, the DNC 130 can receive, from a resource server 210 (herein denoted a "specification-providing resource server"), a specification-providing blockchain transaction 147. This specification-providing blockchain transaction 147 can be the same as any of the above-described blockchain transactions 147, such as a blockchain transaction issued by the resource server 210 to apply for registration; to provide a heartbeat signal; and so forth, such a blockchain transaction 147 then also containing a specification information payload. The specification information comprises information regarding a hardware and / or software property of the specification-providing resource server 210, such as regarding an available processing power, communication bandwidth, a particular software functionality, a particular software or hardware profile, part or version, and so forth. The specification information can be added information not previously known to the DNC 130 or be updated information.

[0151] In response to the specification-providing blockchain transaction 147, the DNC 130 can be configured to, in a subsequent step 421, store on or in connection to (as described above) the blockchain 140 the specification information or a derivative thereof. The derivative can, for instance, be a translation of the received specification information into an internal information format used by the DNC 130. In addition to such storing, or alternatively, the DNC 130 can be configured to update the current rating score information 145 based on the specification information. For instance, in case an improved communication bandwidth as compared to a previously specified communication bandwidth for the same resource server 210 is stipulated in the specification information, the current rating score information for that resource server 210 can be increased (improved).

[0152] In some embodiments, the DNC 130 is configured to hold tag information 146, such as in the database 149 and in the manner generally described above, stored on or in connection to the blockchain 140. The tag information 146 can comprise a set of tags or labels, and also information making it possible for the DNC 130 to associate each resource server 210 with zero, one or several such tags or labels.

[0153] Each tag or label can individually signify a particular capability or capacity of a resource server 210, such as pertaining to communication, routing, computation, storage or having specific hardware or software functionality. Put another way, the tag information 146 can comprise a set of tags, each tag being descriptive of a type of resource server 210.

[0154] The tag information 146 can be information with respect to one or several tags in turn pertaining, directly or derivatively according to the tag information 146, to one or several of the resource servers 210 as a function of the specification information received as described above. The tag information can also, or alternatively, relate to one or several of the resource servers 210 as a function of a topological location of the one or several resource servers 210 in the digital communication network 10, such as an absolute topological location and / or a relative topological location of one resource server 210 in relation to another resource server 210.

[0155] As the term is used herein, a "topological location" can be a logical location on the network 10 as defined in terms of communication paths in relation to other entities on the network 10.

[0156] In some embodiments, the DNC 130 can be configured to select the selected resource server 210, for instance in step 416 described above, based on the tag information 146. In embodiments, the selection can be made based on specific information regarding the requesting peer 20, such as a specific type of peer 20 in cases where there are different types of peers 20; a topological location of the requesting peer 20 in the digital communication network 10, such as topological closeness between the requesting peer 20 and the selected resource server 210 on the network 10; and / or a specific property of a communication requested by the requesting peer 20 such as any specific communication or functionality requirements of the peer 20 connected to its request.

[0157] In an optional step 422, the DNC 130 can be configured to receive a specification-providing blockchain transaction 147 containing or otherwise carrying updated or changed specification information. The DNC 130 can then be configured to, as a result of this receiving, change or update the tag information 146. In reaction to a change of the tag information 146, that for instance can be the result of step 422, the DNC 130 can be configured to select, in an optional step 423, as the selected resource server 210 for a particular peer 20 a different resource server 210. The different resource server 210 can be selected based on the same or corresponding criteria as the first selected resource server 210, but reflecting the changed prerequisite in terms of the tag information.

[0158] Then, in an optional subsequent step 424, the DNC 130 can be configured to initiate a reconnection protocol with respect to the requesting peer 20 to the different resource server 210.

[0159] It is realized that the DNC 130 can orchestrate several such communications connections with respect to several peers 20 simultaneously, where each of these peers 20 can connect to the same or different resource server 210 for routing of communication across the communication network 10 and the system 100. Then, the DNC 130 can be configured to apply a balancing mechanism when selecting resource routers 210 for different peers 20, so that the peers 20 are distributed more or less evenly across available resource servers 210.

[0160] The system 100 can also be configured to monitor and regulate peer 20 behavior.

[0161] Hence, in an optional step 425, a reporting one of the resource servers 210 can be configured to detect and report to the DNC 130, using a blockchain transaction 147 of the abovedescribed general type (a "reporting" blockchain transaction 147), a misconduct of a particular peer 20 that has been detected by the reporting resource server 210. The misconduct can belong to a set of one or several possible and predetermined (such as parameterized) misconducts, objectively observed by the reporting resource server 210, such as the peer 20 becoming unresponsive or using more resources, such as in terms of communication bandwidth, compute or similar, than expected. The misconduct can also be application-specific, such as a peer 20 being detected to cheat in a computer game to which the resource server 210 forms a part. Then, in an optional subsequent step 426, the DNC 130 can be configured to, in response to the reporting blockchain transaction 147, organize and execute a voting among the resource servers 210 relating to the reported misconduct by the peer 20. Alternatively or in addition, the DNC 130 can be configured to, in response to the reporting blockchain transaction 147, organize and execute a voting among the peers 20 relating to the reported misconduct by the peer 20.

[0162] In an optional subsequent step 427, performed in case of a positive vote, the DNC 130 can be configured to take a predetermined action in relation to the particular peer 20, such as banning the peer 20 or reducing / limiting its resource usage.

[0163] In some embodiments, a possible predetermined action is to update information on or in connection to the blockchain 140 regarding the peer 20, such as information regarding the misconduct or related status information regarding the peer 20, for instance information regarding that the particular peer 20 is to be ignored.

[0164] Then, in an optional subsequent step 428, one or several resource servers 210 are configured to access this information on or in connection to the blockchain 140 (the access taking place as generally described above), to gain information about the current status of the peer 20 in the system 100.

[0165] In an optional subsequent step 429, the one or several resource servers 210 can be configured to ignore initiated communications from the particular peer 20, as a function of the information accessed from the blockchain 140. By simply ignoring misbehaving peers 20 based on information automatically stored on or in connection to the blockchain 140 to this end, an efficient self-regulation can be achieved.

[0166] In practical examples providers 200 and / or resource servers 210 provide their public keys to the DNC 130 in connection to them being registered in the system 100. In other words, the public keys are provided to the DAO, that, via various voting mechanism, manages these resource servers 210, granting or revoking access to the system 100. Prior to registration, the DAO (DNC 130) and the responsible provider 200 can agree on the hardware specifications for resource server 210 to be registered, such as CPU and RAM memory specifications, and these hardware specifications can then be registered alongside the public key, on or in connection to the blockchain 140. Such agreement on the hardware specifications can be achieved via traditional means by using traditional communication (such as email) and a conventional agreement.

[0167] Providers 200 can be required to keep their resource servers 210 active by periodically sending a blockchain transaction 147 message, signed using their private key.

[0168] The DAO (DNC 130) can be configured to create and manage said tags representing various operational contexts or use-cases, such as "production", "development", "testing", "chat", "game server", etc., and peers 20 can then request resource servers 210 based on these tags. The DNC 130 can then be configured to match such requesting peers 20 with suitable resource servers 210 based on tag validity and relevance in each individual case.

[0169] The tags can, in some embodiments, be intentionally kept generic, and can for instance be based on a topological network 10 map. For instance, in a computer game-type implementation, available tags can include "development" and "production" to signify the type of resource server 210, as well as "region A", "region B" and "chat" to signify the topological location of the resource server 210. Such topological location can be with respect to a physical layout of the network 10 and / or a virtual map in the computer game, for example. Hence, "region A" can mean a first virtual map region inside the computer game; "region B" can mean a second virtual map region inside the computer game; whereas "chat" is not connected to any particular virtual map region but is accessed by peers 20 to chat with other players in the game globally.

[0170] In the case of autonomous driving implementations, the tags could instead be structured according to "countryA", "regionA", "streetA" and so forth, allowing resource servers 210 representing vehicles to broadcast their current location and resource servers 210 representing traffic lights to broadcast their current state using corresponding tags.

[0171] This way, an application developer can define a set of tags that are to be available, and each peer 20 can be configured to determine what tags to request when requesting a resource servers 210 from the DNC 130. In some embodiments, each peer 20 can connect to more than one resource server 201 at the same time. For example, a peer 20 associated with a vehicle at a particular intersection may want to also connect to resource servers associated with streets connected to that intersection.

[0172] Connected peers 20 can verify, such as periodically, with the DNC 130 to ensure the resource server 210 allocated for their specific tag remains appropriate, and, in case of any changes in resource server 210 allocation, peers 20 can follow reconnection protocols to transition to the new resource server 210, maintaining seamless network service to each peer 20 across varying operating conditions. This can be part of steps 423 and 424 described above.

[0173] As discussed above, once a peer 20 has connected to a particular resource server 210, it can engage in real-time communication with various transport layer protocols, such as TCP, UDP, SCTP, CCP, RSVP or RUDP, according to application needs. This process can be contentmoderated by the DNC 130, for instance based on resource servers 210 reporting misbehaving peers 20 as described, using their private keys to sign corresponding blockchain transactions 147 received and processed by the DNC 130.

[0174] If a resource server 210 detects and reports a peer, a voting process can be triggered by the DNC 130 as described (step 425), that resource servers 210 and / or other peers can participate in, in order to determine the status of such reported peers 20. Peers 20 that are voted to not behave according to the predetermined rules can be kept and maintained in a dynamic filter list in the DNC 130 (for instance stored in database 149), this filter list being consumed by resource servers 210 to update their moderation settings in real-time. Resource servers 210 can adhere to the filter list by ignoring messages from moderated peers 20 (step 429), ensuring the integrity and safety of the system 100, essentially isolating those peers 30 to not interact with others until they are removed from the filter list.

[0175] In some embodiments, it may be desirable to keep some or all of the resource servers 210 generic in terms of an application in which they are deployed. For instance, one and the same resource server 210 can be used in the context of several different computer games.

[0176] To achieve this, at least one of, such as several or even all of, the resource servers 210 can be configured to support a pluggable and extendable logic that is incorporated in the resource server 210, and that can be extended using a plugin from an external source, such as from the DNC 130.

[0177] In examples, such plugin can be in the form of anti-cheat detection logic specific to a particular computer game. For example, in a computer game where one player can shoot another one inside a virtual world, a non-blockchain networking message passing or being available to a resource server 210 can be evaluated, using such an anti-cheat plugin that is downloaded and used within a broader pluggable and extendable anti-cheat logic, with respect to if the involved players (peers 20) actually are in near proximity to each other or not, in the virtual world, and / or if they indeed have a clear line-of-sight. If this is not so, an anticheat alert can be issued in the form of a misconduct-reporting blockchain transaction 147 to the DNC 130 as described above, the reported misconduct being in relation to the peer 20 that was said to (but could not reasonably) shoot another peer 20.

[0178] The plugin can be in the form of a script code, such as a piece of code stored in text format inside the DNC 130. The DAO can upload 150 and update such scripts. The providers 200 can download the script and plug it into their resource servers 210, or each resource server 210 can automatically access the script directly from the DNC 130.

[0179] More generally, the DNC 130 can be configured to store such a plugin, that can be in the form of a script of said type, defining implementation-specific logic useful for a set of one or more of said resource servers 210. Then, in an optional step 430, the DNC 130 can be configured to receive, from a scriptrequesting one of the resource servers 210, a script-requesting blockchain transaction and, in response to the receiving, in an optional subsequent step 431, provide the script to the script-requesting resource server 210. This requesting and providing can be accomplished using corresponding blockchain transactions 147 as generally described above.

[0180] Alternatively, the resource server 210 can read the script directly from the blockchain 140, in which case step 430 is not needed.

[0181] After receiving (downloading) the script, the resource server 210 can, in an optional subsequent step 432, plug it into its pluggable / extendable logic and use it as a part of its logic. In particular, the resource server 210 can be configured to use the downloaded script as a part of a software functionality provided by the resource server 210 to or in connection to a peer 20 communicating with the resource server 210.

[0182] Once implemented in the resource server 210, in an optional subsequent step 433, the script (the implementation-specific logic) can be configured to produce a result that is dependent on information relating to an updated status or communication activity of more than one of the peers 20. For instance, anti-cheat mechanisms can be used to detect cheating behavior in a computer game for any player (peer 20) in the computer game.

[0183] The script can also, or alternatively, be used by the resource server 210 to produce a result relating to topological proximity on the digital communication network 10 of resource servers 210 being involved in routing communication over the transport layer protocol between two or more peers 20. For example, the anti-cheat logic can build on the notion of in-game proximity between the communicating peers 20, using information about what resource servers 210 the peers 20 connect to to determine if the peers 20 are "close" or not, in terms of the in-game geography. In an optional subsequent step 434, the method can iterate back to any of the above-described steps zero, one or several times.

[0184] Eventually, in a subsequent step 435, the iteration stops and the method ends.

[0185] Figure 4 illustrates, using arrows, various possible execution paths through the method.

[0186] There are many different possible concrete embodiments for the principles described herein technology, in particular various distributed networking solutions that are not governed by a single entity.

[0187] In a first example, the resource servers 210 are individual game servers involved in providing the software functionality of a centralized or decentralized computer game, such as a computer game providing access to several players simultaneously, the players possibly being capable of cooperation and / or interaction with each other. Each player can be represented by an individual peer 20.

[0188] In such cases, each resource server 210 can be responsible for managing a particular part of the computer game, such as an in-game location, section or entity, and / or a plurality of resource servers 210 can collaborate to provide communication / routing functionality to player-representing peers 20 that can use one or several such resource servers 210 to connect to the computer game logic in various ways. In such cases, a peer 20 being ignored by the resource servers 210 as described above can mean the effective banning of the playing peer 20 from the game entirely.

[0189] Routing information can, in such examples, be put together as a function of, or at least taking into consideration, an in-game geography or logic structure so as to provide efficient communications between peers 20 and resource servers 210 in the context of the computer game. The computer game can then be managed by a central or distributed server, in turn communicating with the resource servers 210 directly of via the DAO 150. The real-time non-blockchain communication between peers 20 and / or resource servers 210 routed by the resource servers 210 can be, for instance, chat correspondence between peers 20; information about position and movement for particular peers 20; or status information about non-peer objects, such as a virtual bullet fired by one of the peers 20.

[0190] In a second example, the system 100 is for managing of autonomous vehicles or vessels, such as cars, trucks, motorcycles, buses and / or boats in a traffic grid. Then, vehicles need to be able to communicate with each other, and possibly also with road infrastructure such as traffic lights. In practice, there are then many different manufacturers of vehicles and they all need to be able to talk and trust each other in a decentralized and fair way, without compromising real-time performance. For example, a car made by a first manufacturer may not want to trust a communication network constructed by a different manufacturer, since that other manufacturer might be inclined to prioritize their own vehicles in various traffic situations.

[0191] More particularly, the system 100 can then be a system for administrating, monitoring and managing a set of autonomous vehicles or vessels, wherein one or several peers 20 can individually represent, or form part of, a respective one of the autonomous vehicles or vessels. Alternatively or in addition, one or several peers 20 can individually represent, or form part of, a fixedly installed installation for administrating, monitoring and / or managing the set of autonomous vehicles or vessels, such as traffic light, highway sign or pop-up pollar.

[0192] Each resource server 210 can then be responsible for managing communication between such actors in the system, in the form of vehicles and pieces of fixed infrastructure. A peer 20 being ignored by the resource servers 210 as described above can mean the effective banning of the playing peer 20 from the automatic traffic control, implying that such vehicle needs to be manually controlled.

[0193] Routing information can, in such examples, be put together as a function of, or at least taking into consideration, an real-world geography or traffic communication system hardware topology so as to provide efficient communications between peers 20 and resource servers 210 in the context of the traffic system. Such traffic system can be completely decentralized, managed by the DAO 150.

[0194] Various tags could signify geographic location, type of entity and / or available functionality or fault states.

[0195] The real-time non-blockchain communication between peers 20 and / or resource servers 210 routed by the resource servers 210 can be, for instance, information shared between the participants, such as vehicle position, heading, speed and acceleration; green-light or boat lock status; roadwork information; aggregate traffic information; and so forth.

[0196] In a third example, the system 100 is for providing a VPN (Virtual Private Network) service to end users. The system 100 can then be used to create a network of individual VPN services, managed in a decentralized and trusted manner via the DAO 150. Users can connect through multiple VPNs instead of a centralized single one, allowing for more secure and private web browsing. The DNC 130 could be configured to handle traffic routing, payment (via fungible tokens as described above) and compensation to servers.

[0197] For instance, VPN services VPNx, VPNy and VPNz could join together and register as providers 200 in DNC 130, resulting in them being able to utilize the above-described tag system for discerning between countries and regions. When an end user (a peer 20) wishes to use a VPN, it can be allotted to, or select, a VPN server (a resource server 210) from any of VPNx, VPNy and VPNz as a function of the tag information (country and region) that the user indicates an interested in. At different points in time, various ones of the services VPNx, VPNy and VPNz can be allottable / selectable for different regions. This provides a wider total coverage for the VPN service as compared to VPNx, VPNy and VPNz operating independently, and can also help to distribute communication data across multiple different VPN providers instead of all the data going through just one provider, further adding to security considerations. More particularly, the system 100 can then be a system for providing a VPN service, and wherein one or several of the resource servers (210) is a VPN server.

[0198] Routing information could be information indicating to what resource provider 210 a particular peer 20 is to connect for the VPN connection, or how more complex VPN communication (possibly utilizing one resource server 210 acting as a proxy or a sub-VPN for another resource server 210) is to be routed.

[0199] The real-time non-blockchain communication could be the actual browsing communication performed over the established VPN connection.

[0200] Tag information could include properties of each VPN service provider, such as bandwidth capacity, service level agreements or policies.

[0201] It is understood that these are only three examples, and that the possible applications of the principles described herein are numerous.

[0202] Above, preferred embodiments have been described. However, it is apparent to the skilled person that many modifications can be made to the disclosed embodiments without departing from the basic idea of the invention.

[0203] It is realized that the present specification describes a number of principles that can be applied in various types of systems and methods for real-time communication, and that the concrete examples are for illustration. In particular, many additional features can be used in addition to the ones described above.

[0204] In general, all the presented embodiments are freely combinable pending compatibility. This particularly applies to the described methods, systems and computer software functions. Hence, the invention is not limited to the described embodiments, but can be varied within the scope of the enclosed claims.

Claims

C L A I M S1. System (100) for real-time communication over a digital communication network (10), the system (100) comprising a plurality of resource servers (210) , referred to in the following as the resource servers (210), each connected to the digital communication network (10) and configured to communicate using a transport layer protocol; a blockchain (140); and a decentralized network coordinator, DNC, (130) in the form of a decentralized application defined in terms of one or several smart contracts (142) defined on the blockchain (140), wherein the DNC (130) is configured to process blockchain transactions from each of the resource servers (210); store, on or in connection to the blockchain (140) and based on the processed blockchain transactions, updated routing information (143) regarding digital communication between individual ones of the resource servers (210); allow each of the resource servers (210) to access the updated routing information (143); receive from one or several sending ones of the resource servers (210) blockchain transactions indicating a respective current status information of the sending resource server (210) and / or of one or several other ones of the resource servers (210); organize and execute an automated voting among the resource servers (210) and / or providers (200) of the resource servers (210) resulting in an updated set of rating scores for one or several of the resource servers (210), the voting being based on the current status information; and allow each of a plurality of peers (20) to access communication information from the blockchain (140), the communication information being useful for the peer (20) to initiate communication, the initiated communication being overthe transport layer protocol and using non-blockchain communication transactions, with a selected one of the resource servers (210),wherein the selected resource server (210) is configured to, in response to an initiated communication from the peer (20) and using the updated routing information (143), route non-blockchain communication transactions over the transport layer protocol between the peer (20) and a different resource server (210) and / or a different one of said peers (20), and wherein the DNC (130) is configured to provide remuneration to the selected resource server (210) in the form of a blockchain token representing a value in dependence of the updated rating score for the selected resource server (210).

2. System (100) according to claim 1, wherein each blockchain transaction is validated by the DNC (130) using a registered public key (212) of said each resource server (210), the public key (212) corresponding to a private key (211) of said each resource server (210), the private key (211) being used by said each resource server (210) to sign the blockchain transaction.

3. System (100) according to claim 1 or 2, further comprising a plurality of validating blockchain nodes (110), each storing the blockchain (140) including the DNC (130) and each configured to propagate the blockchain (140) by validating blocks using a consensus algorithm.

4. System (100) according to claim 3, wherein each blockchain transaction from each individual resource server (210) is directed to only one of the validating blockchain nodes (110).

5. System (100) according to claim 3 or 4, further comprising one or several non-validating blockchain nodes (120) that are configured to not participate in the consensus algorithm.

6. System (100) according to any preceding claim, wherein the transport layer protocol is TCP, UDP, SCTP, CCP, RSVP or RUDP.

7. System (100) according to any preceding claim,wherein each resource server (210) is configured to periodically send a heartbeat blockchain transaction to the DNC (130), and wherein the DNC (130) is configured to receive the heartbeat blockchain transaction and to update the current rating score information (145) based thereon.

8. System (100) according to any preceding claim, wherein the DNC (130) is configured to organize and execute an automated voting among the resource servers (210) and / or providers (200) of the resource servers (210) regarding the registration of a new resource server (210), and as a result of a positive vote register the new resource server (210); and / or wherein the DNC (130) is configured to organize and execute an automated voting among the resource servers (210) and / or providers (200) of the resource servers (210) regarding the banning of a particular registered resource server (210), and as a result of a positive vote update the current rating score information (145) for the particular registered resource server (210) or ban the particular registered resource server (210) from further participation in the system (100).

9. System (100) according to any preceding claim, wherein an operating logic of the DNC (130) is entirely defined in terms of the one or several smart contracts (130).

10. System (100) according to any preceding claim, wherein the blockchain token is a fungible token.

11. System (100) according to any preceding claim, wherein the DNC (130) is configured to store a script, the script defining implementation-specific logic useful for a set of one or more of said resource servers (210), wherein the DNC (130) is configured to receive, from a script-requesting one of the resource servers (210), a script-requesting blockchain transaction and, in response to the receiving, provide the script to the script-requesting resource server (210), andwherein the script-requesting resource server (210) is configured to use the script as a part of a software functionality provided by the script-requesting resource server (210) to a peer (20) communicating with the script-requesting resource server (210).

12. System (100) according to claim 11, wherein the implementation-specific logic is configured to produce a result that is dependent on information relating to an updated status or communication activity of more than one of the peers (20) and / or relating to topological proximity on the digital communication network of resource servers (210) being involved in routing communication over the transport layer protocol between two or more peers (20).

13. System (100) according to any preceding claim, wherein one, several or all of the resource servers (210) are configured to query the DNC (130) for the updated routing information (143) instead of relying on routing information (213) previously stored in or by the resource server (210) itself.

14. System (100) according to any preceding claim, wherein the DNC (130) is configured to receive, from an information-providing one of the resource servers (210), a routing information (143) containing blockchain transaction comprising routing-related information for the information-providing resource server (210) and, in response to the receiving of the routing information (143) containing blockchain transaction, update the current routing information (143).

15. System (100) according to any preceding claim, wherein the DNC (130) is configured to receive, from a specification-providing one of the resource servers (210), a specification-providing blockchain transaction, the specification-providing blockchain transaction comprising specification information regarding a hardware and / or software property of the specification-providing resource server (210), and wherein the DNC (130) is configured to, in response to the specification-providing blockchain transaction, store on the blockchain (140) the specification information or aderivative thereof and / or to update the current rating score information (145) based on the specification information.

16. System (100) according to claim 15, further comprising a set of tags, each tag being descriptive of a type of resource server (210), and wherein the DNC (130) is configured to store, on the blockchain (140), tag information (146) regarding one or several tags pertaining to one or several of the resource servers (210) as a function of the specification information and / or as a function of a topological location of the one or several resource servers (210) in the digital communication network (10).

17. System (100) according to claim 16, wherein the DNC (130) is configured to select the selected resource server (210) based on the tag information (146) and further based on specific information regarding the requesting peer (20), a topological location of the requesting peer (20) in the digital communication network (10) and / or a specific property of a communication requested by the requesting peer (20).

18. System (100) according to claim 17, wherein the DNC (130) is configured to, in reaction to a change in the tag information (146), select as the selected resource server (210) a different resource server (210), and to initiate a reconnection protocol with respect to the requesting peer (20) to the different resource server (210).

19. System (100) according to any preceding claim, wherein a reporting one of the resource servers (210) is configured to detect and report to the DNC (130) a predetermined misconduct of a particular peer (20), the reporting being in the form of a reporting blockchain transaction, wherein the DNC (130) is configured to, in response to the reporting blockchain transaction, organize and execute a voting among the resource servers (210) and / or providers (200) of the resource servers (210) and / or among the peers (20) relating to the misconduct, andwherein the DNC (130) is configured to, in the case of a positive vote, take a predetermined action in relation to the particular peer (20).

20. System (100) according to claim 19, wherein the predetermined action is to update information on the blockchain (140) regarding the ignoring of the particular peer (20), and wherein the resource servers (210) are configured to ignore initiated communications from the particular peer (20) as a function of the updated information.

21. System (100) according to any preceding claim, wherein the resource servers (210) are individual game servers (210) providing functionality of a centralized or decentralized computer game, and wherein one or several peers (20) is a respective player in the computer game.

22. System (100) according to any one of claims 1-20, wherein the system (100) is a system for administrating, monitoring and managing a set of autonomous vehicles or vessels, and wherein one or several peers (20) is a respective one of the autonomous vehicles or vessels, or a fixedly installed installation for administrating, monitoring and / or managing the set of autonomous vehicles or vessels.

23. System (100) according to any one of claims 1-20, wherein the system (100) is a system for providing a virtual private network, VPN, and wherein one or several of the resource servers (210) is a VPN server.

24. Method for real-time communication over a digital communication network (10), wherein a system (100) comprises a plurality of resource servers (210) , referred to in the following as the resource servers (210), each connected to the digital communication network (10) and configured to communicate using a transport layer protocol; a blockchain (140); and a decentralized network coordinator, DNC, (130) in the form of a decentralizedapplication defined in terms of one or several smart contracts (142) defined on the blockchain (140), the method comprising the steps the DNC (130) receiving and processing blockchain transactions from each of the resource servers (210); the DNC (130) storing updated routing information (143) regarding digital communication between individual ones of the resource servers (210); one or several of the resource servers (210) accessing the updated routing information (143); the DNC (130) receiving from one or several sending ones of the resource servers (210) blockchain transactions indicating a respective current status information of the sending resource server (210) and / or of one or several other ones of the resource servers (210); the DNC (130) organizing and executing an automated voting among the resource servers (210) and / or providers (200) of the resource servers (210) resulting in an updated set of rating scores for one or several of the resource servers (210), the voting being based on the current status information; one or several of a plurality of peers (20) accessing communication information from the blockchain (140), the communication information being useful for the peer (20) to initiate communication, the initiated communication being over the transport layer protocol and using non-blockchain communication transactions, with a selected one of the resource servers (210); the selected resource server (210) routing, in response to an initiated communication from the peer (20) and using the updated routing information (143), non-blockchain communication transactions over the transport layer protocol between the peer (20) and a different resource server (210) and / or a different one of said peers (20); and the DNC (130) providing remuneration to the selected resource server (210) in the form of a blockchain token representing a value in dependence of the updated rating score for the selected resource server (210).

25. Computer software product defining a decentralized network coordinator, DNC, (130) in the form of a decentralized computer software application defined in terms of one or several smart contracts (142) defined on a blockchain (140), the one or several smartcontracts (142) being configured to, when executed on one or several processors of said system (100), perform the steps receiving and processing blockchain transactions from each of a plurality of resource servers (210), referred to in the following as the resource servers (210); storing updated routing information (143) regarding digital communication between individual ones of the resource servers (210); receiving from one or several sending ones of the resource servers (210) blockchain transactions indicating a respective current status information of the sending resource server (210) and / or of one or several other ones of the resource servers (210); organizing and executing an automated voting among the resource servers (210) and / or providers (200) of the resource servers (210) resulting in an updated set of rating scores for one or several of the resource servers (210), the voting being based on the current status information; providing communication information useful for a peer (20) to initiate communication, the initiated communication being over a transport layer protocol and using non-block- chain communication transactions, with a selected one of the resource servers (210); and providing remuneration to the selected resource server (210) in the form of a blockchain token representing a value in dependence of the updated rating score forthe selected resource server (210).

26. Computer software product according to claim 24, the computer software product being configured for real-time communication over a digital communication network (10), the DNC (130) being part of a system (100) also comprising the plurality of resource servers (210), each connected to the digital communication network (10) and configured to communicate using the transport layer protocol, the computer software product being configured to, when executed on one or several processors of said system (100), perform the additional steps causing one or several of the resource servers (210) to access the updated routing information (143); causing one or several of a plurality of peers (20) to access communication information from the blockchain (140), the communication information being useful for the peer(20) to initiate communication, the initiated communication being over the transport layer protocol and using non-blockchain communication transactions, with the selected one of the resource servers (210); and causing the selected resource server (210) to route, in response to an initiated coms’ munication from the peer (20) and using the updated routing information (143), non-block- chain communication transactions over the transport layer protocol between the peer (20) and a different resource server (210) and / or a different one of said peers (20).

Images