WO2023030606A1

WO2023030606A1 - Distributed ledger technologies over constraint-based service routing

Info

Publication number: WO2023030606A1
Application number: PCT/EP2021/073927
Authority: WO
Inventors: David Guzman; Dirk Trossen
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2021-08-31
Filing date: 2021-08-31
Publication date: 2023-03-09

Abstract

Disclosed is a routing device (1) for routing of one or more packets to a service function, for example a mining service associated with a digital ledger. The routing device (1) comprises a processor (11) configured to: establish (21) a number of constraints for the routing of the one or more packets to a number of instances (potential miners M) of the mining service function. The established number of constraints define prerequisites for a service provisioning (mining) by the number of instances (capable miners M). The processor (11) is further configured to: selectively forward (22) the one or more packets to all instances (potential miners M) of the mining service function in accordance with the established number of constraints. This avoids unnecessary acts of communication in connection with transaction mining for the digital ledger.

Description

DISTRIBUTED LEDGER TECHNOLOGIES

OVER CONSTRAINT-BASED SERVICE ROUTING

Technical Field

The present disclosure relates generally to the field of network routing, particularly in support of digital ledger technologies (DLT). More specifically, the present disclosure relates to a routing device for routing one or more packets to a service function, a method of operating such routing device, and a computer program.

Background Art

A distributed ledger (or distributed ledger technology, DLT) may refer to a digital system for recording of transactions of assets, such as cryptocurrencies or smart contracts, by a distributed plurality of parties. Typically, a non-hi erar chi cal network of nodes, such as a peer-to-peer network, maintains identical local copies of the ledger per node. The blockchain, a particular DLT concept, serves as a public transaction ledger of the cryptocurrency ‘Bitcoin’, whereas Ethereum is a blockchain design with smart contract functionality. DLT for cryptocurrency may be mineable (i.e., one can claim ownership of new coins when contributing with a node) or not.

DLT transaction mining is schematically illustrated in FIG. 2: A client may issue (1) a new transaction, such as a transfer of cryptocurrency. The nodes bearing the digital ledger may validate (2) the new transaction as part of a block of similar transactions (this being referred to as the “mining”), add the block of validated transactions to the ledger and reach a concensus (3) on which of the local copies of the ledger is correct, using algorithms such as ‘proof of work’, ‘proof of stake’, voting systems, etc. Eventually, the nodes update their local copy of the ledger with the correct one, and the ordering client may then read (4) the validated transaction from the added block of validated transactions. A major issue of DLT transaction mining is that it tends to be initiated without an absolute baseline of information for efficient communication:

For example, to contact (other) miners, information on a reachability of miners is required, such as IP addresses and port information. New DLT members therefore need to download routing information from bootstrap nodes upon joining, and update regularly (at expense of bandwidth). According to public sources [1], [2], Ethereum’s ‘overlay routing table’ at some point included ~500k nodes. Each ‘routing entry’ includes a 32 bit IPv4 address, 2x16 bit port information (one for TCP and UDP, respectively) and a 512 bit Ethernet ID/address, a total of 72 bytes for each miner. According to this example, 500k x 72 bytes = 36 MByte of routing data that will need to be downloaded by every client and miner as well as regularly updated.

For example, to get served, information on a capability of miners to serve requests is required, such as using a specific hardware, hash algorithm or security algorithm. Clients thus need to contact potential miners (at expense of bandwidth), wait for connection responses (at expense of time), inquire capabilities (at expense of bandwidth) of responding miners, and disconnect if there is no match. In fact, some miners may never reply/respond and be timed out.

For example, to get served, a transaction may be sent to multiple capable miners in a specific network diameter (multipoint operation). In practice, “specific network diameter” may mean a random number of the available miners is selected, such as 47 miners on average according to public source [1], The multipoint operation is typically mapped onto unicast operations to all miners (at expense of bandwidth), despite a large share of this communication appears to be useless due to limited availability of miners (i.e., must be active and routable). This availability may be as small as 2,13% according to public source [2], In summary, only very few miners are contacted (here: 47 miners x 2,13% = ~1 miner), which diminishes a resilience of information (through few participating miners) and puts into perspective the point of using a DLT in the first place.

Overlay routing such as implemented in Ethereum and similar DLTs requires distribution of an overlay routing table to all participants, making joining the DLT an expensive operation (downloading dozens of megabytes of data per new DLT member). Constraint-based overlay routing will require updating the overlay routing table and a push of updates to all participants, raising concerns in terms of scalability and latency of forming constrained, particularly dynamic, groups.

Using election protocols to form groups in existing overlays, such as done in FileCoin albeit limited to mining operations only, not other constraints, needs the additional election protocol, adds latency due to the election method but also centralizes operations of the distributed^!) ledger technology.

Using IP multicast has issues with respect to scalability of multicast groups (given sets of communication and increased proliferation of DLTs in many scenarios), costs for setting up groups, and limited dynamicity of groups.

[1] Wang, T., Zhao, C., Yang, Q., Zhang, S., Member, S. (n.d.). Ethna : Analyzing the Underlying Peer-to-Peer Network of Ethereum Blockchain. 1-15.

[2] Gao, Y., Shi, J., Wang, X., Tan, Q., Zhao, C., Yin, Z. (2019). Topology Measurement and Analysis on Ethereum P2P Network.

Summary

It is an objective of the present disclosure to overcome these and other drawbacks. It is a specific objective to make a communication due to DLT transaction mining more efficient.

This is achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

According to a first aspect, a routing device for routing of one or more packets to a service function is provided. The routing device comprises a processor. The processor is configured to: establish a number of constraints for the routing of the one or more packets to a number of instances of the service function. The established number of constraints define prerequisites for a service provisioning by the number of instances. The processor is further configured to: selectively forward the one or more packets to all instances of the service function in accordance with the established number of constraints.

In other words, CBSR is used as a network level routing solution. That is, a request to foo.com can be sent to one or more service instances for foo. com, while the sending may be constrained by one or more constraints when doing so. As the prerequisites for a service provisioning by the number of service instances are established as the number of routing constraints, CBSR selectively forwards the one or more packets only to those of all instances of the service function who are actually capable of providing the service. As such, overlay networks such as DLTs may be provided with a dynamic network-level multicast service tailored to the overlay’s needs. For example, when interpreting miners as service instances realizing a mining service, e.g., miner.mydlt.org, and utilizing CBSR to send transactions and miners’ commitments to all service instances, forward network-level multicast may thus replace overlay multipoint replication, and forwarding of service requests to mining service instances may dynamically be constrained by those aspects that make receivers accept the request, avoiding many bandwidth and/or time-consuming acts of communication (such as unnecessary disconnects), making the communication more efficient.

In a possible implementation form, the processor may be configured to, so as to establish the number of constraints for the routing of the one or more packets to a number of instances of the service function: receive an identifier of the service function, an identifier of a particular instance of the service function, and a constraint of the number of constraints, the received constraint being defined by the particular instance of the service function.

Thereby, each identified particular instance of the number of instances of the identified service function may individually specify one (or more) constraints for the routing of the one or more packets directed to itself, enabling a maximum of flexibility and routing efficiency.

In a possible implementation form, the processor may further be configured to, so as to establish the number of constraints for the routing of the one or more packets to a number of instances of the service function: populate a constrained routing table (CRT) of the routing device with the received constraint, the received identifier of the service function, the received identifier of the particular instance of the service function, and an identifier of an adjacent device as a next hop from which the received constraint has been received.

Thereby, each routing device may maintain a routing state for the routing of the one or more packets to the number of instances of the service function, which enables a local forwarding decision-making at forwarding speed.

In a possible implementation form, the processor may further be configured to, so as to establish the number of constraints for the routing of the one or more packets to a number of instances of the service function: advertise the received constraint, the received identifier of the service function, the received identifier of the particular instance of the service function, and an identifier of the routing device as the next hop.

Thereby, the established number of constraints for the routing of the one or more packets to the number of instances of the service function may be distributed using known routing protocols, which enables efficient information dissemination across the network.

In a possible implementation form, the received constraint may comprise one of a capability of the particular instance; and a condition for the requested service.

Thereby, the established number of constraints for the routing of the one or more packets to the number of instances of the service function may represent various prerequisites for a service provisioning by the number of instances, which enables effective elimination of pointless acts of communication.

In a possible implementation form, the capability of the particular instance may comprise one of a capability of using a particular security function; a capability of using a particular hardware function; a capability of using a particular hash algorithm; a capability of verifying an applicable output pattern; of the particular hash algorithm; and a capability in accordance with an applicable epoch. Thereby, the established number of constraints for the routing of the one or more packets to the number of instances of the service function may represent various prerequisites for a service provisioning which actually depend on the respective instance’s own attributes.

In a possible implementation form, the capability of the particular instance may be associated with an expiry time after which the capability is dismissed.

Thereby, the established number of constraints for the routing of the one or more packets to the number of instances of the service function may be made “self-cleansing”.

In a possible implementation form, the condition for the requested service may comprise one of: a maximum network distance relative to an originator of the one or more packets; and a maximum geographic distance relative to the originator of the one or more packets.

Thereby, the established number of constraints for the routing of the one or more packets to the number of instances of the service function may represent various prerequisites for a service provisioning by the number of instances which actually depend on the respective instance’s true network-topological or geographic requirement (cf. the “specific network diameter” above).

In a possible implementation form, the processor may further be configured to, so as to selectively forward the one or more packets to all the instances of the service function in accordance with the established number of constraints: receive the one or more packets, an identifier of the service function and one or more matching values from an originator of the one or more packets; retrieve the established number of constraints, the respective identifier of the particular instance of the service function, and a respective next hop from the CRT of the routing device in accordance with the received identifier of the service function; select one or more of all the instances of the service function in accordance with the established number of constraints and the received one or more matching values; and forward the received one or more packets to the respective next hop associated with the selected one or more instances of the service function. In a possible implementation form, the processor may further be configured to, so as to select the one or more of all the instances of the service function in accordance with the established number of constraints and the one or more received matching values: select a respective instance of all the instances of the service function in accordance with a fulfillment of the established number of constraints of the respective instance by the one or more received matching values.

Thereby, constraint-based service routing may take into account both constraints of the originator of the one or more packets and constraints of the number of instances of the service function, resulting in a selection of one or more of all the instances of the service function which fulfills the needs of all involved entities.

In a possible implementation form, the service function providing a mining service associated with a digital ledger; and the identifier of the service function addressing all the instances of the service function.

Thereby, DLT transaction mining in general may benefit from constraint-based service routing taking into account the specific constraints of DLT transaction mining.

In a possible implementation form, the digital ledger may comprise a blockchain-type digital ledger.

Thereby, the specific blockchain-type DLT transaction mining may benefit from constraint-based service routing taking into account the specific constraints of blockchain-type DLT transaction mining.

According to a second aspect, a method of operating a routing device is provided. The method comprises: establishing a number of constraints for the routing of one or more packets to a number of instances of a service function, the established number of constraints defines prerequisites for a service provisioning by the number of instances. The method further comprises selectively forwarding the one or more packets to all instances of the service function in accordance with the established number of constraints. In a possible implementation form, the method may be performed by the routing device of the first aspect or any of its implementations.

According to a third aspect, a computer program is provided. The computer program comprises executable instructions which, when executed by a processor, cause the processor to perform the method of the second aspect or any of its implementations.

The technical effects and advantages described above in relation with the routing device equally apply to the method and the computer program having corresponding features.

Brief Description of Drawings

The above-described aspects and implementations will now be explained with reference to the accompanying drawings, in which the same or similar reference numerals designate the same or similar elements.

The drawings are to be regarded as being schematic representations, and elements illustrated in the drawings are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose become apparent to those skilled in the art.

FIG. 1 illustrates an exemplary scenario in accordance with the present disclosure;

FIG. 2 illustrates an exemplary DLT transaction mining;

FIG. 3 illustrates routing nodes and their configuration in accordance with the present disclosure;

FIG. 4 illustrates the method of FIG. 3 in its most concise representation, and applied to the DLT transaction mining of FIG. 2; and FIG. 5 illustrates the method of FIG. 3 in its most detailed representation, and applied to the DLT transaction mining of FIG. 2.

Detailed Descriptions of Drawings

In the following description, reference is made to the accompanying drawings, which form part of the disclosure, and which show, by way of illustration, specific aspects of implementations of the disclosure or specific aspects in which implementations of the present disclosure may be used. It is understood that implementations of this disclosure may be used in other aspects and comprise structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

For instance, it is understood that a disclosure in connection with a described method may also hold true for a corresponding apparatus or system configured to perform the method and vice versa. For example, if one or a plurality of specific method steps are described, a corresponding device may include one or a plurality of units, e.g. functional units, to perform the described one or plurality of method steps (e.g. one unit performing the one or plurality of steps, or a plurality of units each performing one or more of the plurality of steps), even if such one or more units are not explicitly described or illustrated in the figures. On the other hand, for example, if a specific apparatus is described based on one or a plurality of units, e.g. functional units, a corresponding method may include one step to perform the functionality of the one or plurality of units (e.g. one step performing the functionality of the one or plurality of units, or a plurality of steps each performing the functionality of one or more of the plurality of units), even if such one or plurality of steps are not explicitly described or illustrated in the figures. Further, it is understood that the features of the various exemplary implementations and/or aspects described herein may be combined with each other, unless specifically noted otherwise.

FIG. 1 illustrates an exemplary scenario in accordance with the present disclosure. The scenario comprises a communication network indicated by a cloud shape and comprising routing devices 1 interconnected by network layer (i.e., layer-3) links.

A “routing device” as used herein may generally relate to a network node suitable for layer-3 routing. In other words, the communication network may be a routed network, such as an IP network.

The routing devices 1 are suited for constraint-based service routing (CBSR) in accordance with the method 2 of operating a routing device 1 which will be explained in more detail in connection with FIGs. 3 - 5 below.

As used herein, service routing may refer to a routing in accordance with addressing of services rather than network interfaces. For example, service routing may use address foo.com/bar (in binary form) instead of the IP address offoo.com/bar. A number of instances of the service can be registered in the network, all of which can receive service requests for, e.g., foo.com/bar, possibly as forward multicast (i.e., be selected for service provisioning). Service clients may maintain affinity with a particular instance of the service after having been directed there for a first time. Service routing may be deployed in limited domains of the global internet, but interconnection to existing Internet services and other CBSR domains is possible using locator-based forwarding.

As used herein, CBSR may refer to a service routing wherein service instances can constrain their selection for service provisioning, by advertising constraint and matching operations together with service identifiers. Such information may be piggy-backed on packets of routing protocols and thus be distributed with a possibility for aggregation and suppression of advertisements. Service clients may request to match their demand against advertised supply (constraint) of the number of instances, by providing a matching value in the requests sent to the routing device 1, which in turn matches said matching value against advertised constraint info. Forwarding operation may be a two-stage process of longest prefix match (against service identifier) and demand/supply matching. This can be implemented in P4 (a programming language for network devices in software-defined networks, specifying how data plane devices process packets) at line-speed or through SW routing solutions such as eBPF. Attached to the communication network is a number of service clients C deployed at various network locations, and a number of instances SFi, SFi of a service function SF deployed at servers M (M for ‘miners’) at various network locations as well.

In this exemplary scenario, any of the service clients C may issue a request for service function SF, to be served by one or more selected instances of the number of service instances SFi. Such a mapping of a service request to one or more service instances may involve application-layer constraints, which effectively narrow down the number of instances potentially providing the service beforehand. However, the excluded service instances may still be contacted, resulting in unnecessary acts of communication, since the application-layer constraints are per se not known on the underlying routing layer which provides the communication service.

In accordance with the present disclosure, a more efficient communication may be achieved by constraint-based service routing taking into account the application-layer constraints, as will be explained in more detail below.

FIG. 2 illustrates an exemplary DLT transaction mining.

In step (1), a client C issues a transaction, such as sending a certain amount of cryptocurrency from himself to someone else. The transaction is submitted to miners within a given network diameter, such as defined by a random set of miners being chosen, miners within a topological or geographical distance or similar by, e.g., a wallet application (i.e., on the application layer) and stored in one or more pools of unconfirmed transactions waiting for a pick-up by a miner M on the blockchain. Miners M select a collection (i.e., a “block”) of unconfirmed transactions from the one or more pools, up to a maximum block size of the according blockchain, given the selected transactions may be executed according to the blockchain history (such as the client’s wallet balance suffices). Multiple miners M may select the same transactions to be included in their block.

Respective miners M may select transactions in accordance with application-layer constraints such as their own capabilities and/or condition for the requested service. Examples for capabilities include a capability of using a particular security function (e.g., Diffie-Hellman key exchange), a capability of using a particular hardware function (e.g., GPU), a particular hash algorithm (e.g., Ethash, hash_256), a capability of using verifying an applicable output pattern (e.g., a given number of leading zeros, see below) of the particular hash algorithm, and a capability in accordance with an applicable epoch of the digital ledger (e.g., playing a particular role such as block proposer, or attester). Examples for conditions for the requested service include a maximum network distance or a maximum geographic distance relative to service requestor/client C.

As for the security functions, security handshake could use existing TLS1.3 (with 1-RTT), and trusted mining service instances could use a public key to have service clients perform 0-RTT when issuing a transaction, while using a private key (or pre-shared symmetric key) when soliciting a commitment. This may reduce transactions, particularly short ones, to 0-RTT (round-trip time).

In step (2), a signature (verification) required by the block to be added to the collection of confirmed transactions (i.e., the blockchain) is determined. For example, ‘proof of work’, a commonly used consensus mechanism, uses a validation of computational power to verify transactions. The signature may be obtained by hashing the content of the block, including a ‘nonce’ that changes upon every hashing attempt, until the hash output is eligible as a signature (i.e., has a certain amount of leading zero’s). This process is referred to as mining.

In step (3), miners M who find an eligible signature (indicated by the light bulb symbol in FIG. 2) broadcast the block and its signature to other miners M, who verify and confirm the validity of the block’s signature and agree that the block can be added to the blockchain (i.e., committed). The other miners M may want to stop hashing the content of their blocks (indicated by the cross symbols in FIG. 2), since at least one of the included transactions is now confirmed and does not assure a mining reward.

In step (4), the client C may read the extended blockchain including the confirmed transaction.

FIG. 3 illustrates routing nodes 1 and their configuration in accordance with the present disclosure. The respective routing device 1 is for routing of one or more packets pt, such as a service request or a file transfer, to a service function.

The service function may particularly provide a mining service associated with a digital ledger, such as a blockchain-type digital ledger. A related communication is illustrated in FIG. 2 above.

The respective routing device 1 comprises a processor 11, and may perform a method 2 of operating the respective routing device 1, wherein the routing device 1 and the method 2 define mutually corresponding subject-matter.

The respective processor 11 is configured to establish 21 a number of constraints for the routing of the one or more packets pi to a number of instances of the service function.

The established number of constraints a,_e define prerequisites for a service provisioning by the number of service instances. In other words, the respective service instance may specify constraints under which it can provide the requested service and it therefore makes good sense to forward the service request to it.

So as to establish 21 the number of constraints for the routing of the one or more packets pi to the number of instances of the service function, the processor 11 may be configured to receive 211 an identifier SF of the service function, an identifier S , i e[ 1;I] of a particular instance of the service function, and a constraint a of the number of constraints.

The identifier SF of the service function may address all the instances of the service function.

As already mentioned, the received constraint a may be defined by the particular instance of the service function. Constraints may be encoded as a hash over various input parameters (for multiparameter constraints). Alternatively, CBSR could also provide multi-constraint formulation in service announcement (of note, ‘receive 211 (...) a constraint of the number of constraints’ leaves room for more than one constraint) and service request, in which case individual constraints are provided in announcements and requests. The received constraint a may comprise one of: a capability of the particular instance, and a condition for the requested service.

The capability of the particular instance may comprise one of: a capability of using a particular security function, such as a Diffie-Hellman key exchange; a capability of using a particular hardware function, such as a graphics processing unit (GPU); a capability of using a particular hash algorithm, such as Ethash, hash_256 and the like; a capability of verifying an applicable output pattern, such as a given number of leading zeros, of the particular hash algorithm; and a capability in accordance with an applicable epoch, e.g. playing a particular role such as block proposer, attester and the like. Static capabilities can be encoded in configuration or during set up. Dynamic capabilities due to events, such as a change in a number of leading zeros (of an output of a hashing algorithm for a successful proof of work) or the epoch in FileCoin cannot be preconfigured and may thus require updating the capability on a need basis. For example, every 10 minutes a new number of leading zeros x is announced to all the miners, with 1<%<256, x^ N. Miners may start mining using the new x since using the old value reduces the trustworthiness of any validated block of transactions, but miners may also mine using different x, representing different contracts.

The capability of the particular instance may be associated with an expiry time after which the capability is dismissed.

The condition for the requested service may comprise one of: a maximum network distance relative to an originator of the one or more packets /?<; and a maximum geographic distance relative to the originator of the one or more packets pi. For example, the maximum network distance may be measured in terms of a hop count between the originator and the particular instance of the service function which defined the condition. For example, the maximum geographic distance may be measured in kilometers in accordance with an arbitrary geographic coordinate system (GCS), and be encoded based on, e.g., geo-IP techniques, deployment configuration, or could extend to all miners in the network. As another example, the network distance may be measured in terms of logical distance within a binary tree of identifiers assigned to each miner instance, creating as a result a random set of miner instances which is considered to be ‘within the (overlay) network distance’ of the originator.

So as to establish 21 the number of constraints for the routing of the one or more packets pt to a number of instances of the service function, the respective processor 11 may further be configured to: populate 212 a constrained routing table CRT of the respective routing device 1 with the received constraint a, the received identifier SF of the service function, the received identifier SFi of the particular instance of the service function, and an identifier NH of an adjacent device as a next hop from which the received constraint a has been received.

So as to establish 21 the number of constraints for the routing of the one or more packets pt to a number of instances of the service function, the processor 11 may further be configured to: advertise 213 the received constraint a, the received identifier SF of the service function, the received identifier SFi of the particular instance of the service function, and an identifier NH of the routing device 1 as the next hop.

The respective processor 11 is further configured to selectively forward 22 the one or more packets pi to all instances of the service function in accordance with the established number of constraints Ci,e.

For example, a client may send an instruction (transaction) or a chunk of instructions (i.e., the one or more packets) to modify a state machine. In cryptocurrencies, those are instructions to modify account balances (e.g. a-100, b+100, m+fee). In Ethereum, it is a Smart Contract. A client sends these instructions or instruction through a commit message to all miners. Forwarding of the transactions is constrained (“ selective forwarding’’ by capabilities and conditions to find the „right miners“.

So as to selectively forward 22 the one or more packets pi to all the instances of the service function in accordance with the established number of constraints a,_e, the processor 11 may further be configured to: receive 221 the one or more packets pi, an identifier SF of the service function and one or more matching values nn from an originator of the one or more packets pr, retrieve 222 the established number of constraints a,_e, the respective identifier SFi of the particular instance of the service function, and a respective next hop NH from the constrained routing table CRT of the routing device 1 in accordance with the received identifier SF of the service function; select 223 one or more of all the instances of the service function in accordance with the established number of constraints a,_e and the received one or more matching values

and forward 224 the received one or more packets pi to the respective next hop NH associated with the selected one or more instances of the service function.

So as to select 223 the one or more of all the instances of the service function in accordance with the established number of constraints a,_e and the one or more received matching values

the processor 11 may further be configured to: select a respective instance of all the instances of the service function in accordance with a fulfillment of the established number of constraints a,_e of the respective instance by the one or more received matching values rm. For example, the one or more received matching values r may require the established number of constraints a,_e of the respective instance to encode a capability of the particular instance, such as a capability of using a GPU. In such a case, the constrained routing table CRT of the respective routing device 1 may have been populated 212 with a same value (0 for no capability, 1 for capability, >1 for multi-capability, such as multiple GPUs, for example). As a further example, the one or more received matching values mi may require the established number of constraints a,_e of the respective instance to encode a condition, such as a maximum network distance relative to the originator of the one or more packets pi. In such a case, the constrained routing table CRT of the respective routing device 1 may have been populated 212 with a device-specific value (i.e., the maximum network distance as defined by the particular instance of the service function minus its network distance to the respective routing device 1).

In summary, embedding service relationships and constraints into routing fabrics allows for fast joining of a DLT by clients and miners alike, thereby improving efficient use of the network.

Of note, FIG. 3 does not show any transition (arrow) between the steps of establishing 21 and selectively forwarding 22. In other words, there is no implied sequence or automaticity such as “first step 21, then step 22” or the like. Rather, these steps are triggered by respective stimulus. For example, the step of establishing 21 may be triggered by receiving routing constraints, whereas the step of selectively forwarding 22 may be triggered by receiving one or more packets to be forwarded.

FIGs. 4 and 5 illustrate the method 2 of FIG. 3 in different levels of detail, and applied to the DLT transaction mining of FIG. 2.

The method 2 of operating a routing device 1 comprises two basic steps, namely: establishing 21 a number of constraints for the routing of one or more packets pi to a number of instances (miners NT) of the mining service function; and selectively forwarding 22 the transaction to all instances (miners NT) of the mining service function in accordance with the established number of constraints Ci,e.

In FIGs. 4 and 5, these basic steps 21, 22 are depicted multiple times per routing device 1, which is due to the fact that the method 2 may support the DLT transaction mining of FIG. 2 several times.

In accordance with FIG. 5, the establishing 21 may comprise: receiving 211 an identifier SF of the service function, an identifier SFt of a particular instance of the service function, and a constraint a of the number of constraints; populating 212 a constrained routing table CRT of the respective routing device 1 with the received constraint a, the received identifier SF of the service function, the received identifier SFt of the particular instance of the service function, and an identifier NH of an adjacent device as a next hop from which the received constraint a has been received; and advertising 213 the received constraint a, the received identifier SF of the service function, the received identifier SFt of the particular instance of the service function, and an identifier NH of the routing device 1 as the next hop.

The established number of constraints a,_e defines prerequisites for a service provisioning by the number of instances (miners M).

In response to issuing a transaction by a service client C - see step (1) of FIG. 2 - comprising one or more packets pi, the transaction is supposed to be broadcasted to all capable miners M. Appropriately, the method 2 further comprises selectively forwarding 22 the one or more packets pt (transaction) to all instances (miners Af) of the mining service function in accordance with the established number of constraints a,e, which means that the transaction is effectively forwarded to one or more selected instances (miners A7) of the number of instances of the mining service function.

In accordance with FIG. 5, the selective forwarding 22 may comprise: receiving 221 the one or more packets pt, an identifier SF of the service function and one or more matching values mi from an originator of the one or more packets pr, retrieve 222 the established number of constraints ,e, the respective identifier SFi of the particular instance of the service function, and a respective next hop NH from the constrained routing table CRT of the routing device 1 in accordance with the received identifier SF of the service function; select 223 one or more of all the instances of the service function in accordance with the established number of constraints a,_e and the received one or more matching values

In response to receiving the one or more packets pi, the one or more selected instances (miners A7) may solicit a commitment to other miners to perform block operations according to a specific scope (e.g., epoch, output pattern) to find a suitable nonce (i.e., random number) which results in the applicable output pattern of leading zeros when hashing the block of transactions including the nonce. Such a commitment may be constrained by capabilities, such as used hash algorithm and number of leading zeros, which are limited by a lifetime of the commitment (usually lOmins).

Such capabilities of the particular instance may be associated with an expiry time after which the capability is dismissed, corresponding to the lifetime of the commitment.

Again, this constitutes a step of establishing 21 a number of constraints for the routing of one or more packets pi to the number of instances (miners A7) of the mining service function. In response to receiving the one or more packets pt, the one or more selected instances (miners M) may respectively start mining, too - see step (2) of FIG. 2.

Miners M who find an eligible signature (again indicated by the light bulb symbol in FIGs. 4 and 5) are supposed to submit the block and its signature (i.e., one or more packets pi) to other miners M within a given network diameter - see step (3) of FIG. 2 - for instance those miners M who committed to perform block operations according to a same specific scope.

Again, this constitutes a step of selectively forwarding 22 the one or more packets pi (the block and its signature) to all instances (miners M) of the mining service function in accordance with the established number of constraints a,_e, which means that the transaction is effectively forwarded to one or more selected instances (miners M) of the number of instances of the mining service function.

In response to receiving the one or more packets pi, the one or more selected instances (miners M) may verify and confirm the validity of the block’s signature and agree that the block can be added to the blockchain (i.e., committed). If so, these miners M may want to stop hashing the content of their blocks (indicated by the cross symbols in FIGs. 4 and 5), since at least one of the included transactions is now confirmed and does not assure a mining reward.

In response to reading the verified transaction by the service client C - see step (4) of FIG. 2 - comprising one or more packets pi, the one or more packets pi are supposed to be submitted to all capable miners M, and may be unicasted to a closest capable miner M for reasons of efficiency, such as by providing a matching value mt encoding a restrictive maximum network distance. This way, the service client C may read the extended blockchain including the confirmed transaction. Of note, a response to the ‘reading’ request is omitted for the sake of clarity.

The present disclosure has been described in conjunction with various implementations as examples. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed matter, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation. A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

1. A routing device (1) for routing of one or more packets to a service function, the routing device (1) comprising a processor (11) configured to:

- establish (21) a number of constraints for the routing of the one or more packets to a number of instances of the service function, the established number of constraints defining prerequisites for a service provisioning by the number of instances; and selectively forward (22) the one or more packets to all instances of the service function in accordance with the established number of constraints.

2. The routing device (1) of claim 1, the processor (11) being configured to, so as to establish (21) the number of constraints for the routing of the one or more packets to a number of instances of the service function: receive (211) an identifier of the service function, an identifier of a particular instance of the service function, and a constraint of the number of constraints, the received constraint being defined by the particular instance of the service function.

3. The routing device (1) of claim 2, the processor (11) further being configured to, so as to establish (21) the number of constraints for the routing of the one or more packets to a number of instances of the service function: populate (212) a constrained routing table (CRT) of the routing device (1) with the received constraint, the received identifier of the service function, the received identifier of the particular instance of the service function, and an identifier of an adjacent device as a next hop from which the received constraint has been received.

4. The routing device (1) of claim 2 or claim 3, the processor (11) further being configured to, so as to establish (21) the number of constraints for the routing of the one or more packets to a number of instances of the service function: advertise (213) the received constraint, the received identifier of the service function, the received identifier of the particular instance of the service function, and an identifier of the routing device (1) as the next hop.

5. The routing device (1) of any one of the claims 2 to 4, the received constraint comprising one of: a capability of the particular instance; and a condition for the requested service.

6. The routing device (1) of claim 5, the capability of the particular instance comprising one of: a capability of using a particular security function; a capability of using a particular hardware function; a capability of using a particular hash algorithm; a capability of verifying an applicable output pattern of the particular hash algorithm; and a capability in accordance with an applicable epoch.

7. The routing device (1) of claim 6, the capability of the particular instance being associated with an expiry time after which the capability is dismissed.

8. The routing device (1) of any one of the claims 5 to 7, the condition for the requested service comprising one of: a maximum network distance relative to an originator of the one or more packets; and a maximum geographic distance relative to the originator of the one or more packets.

9. The routing device (1) of any one of the preceding claims, the processor (11) further being configured to, so as to selectively forward (22) the one or more packets to all the instances of the service function in accordance with the established number of constraints: receive (221) the one or more packets, an identifier of the service function and one or more matching values from an originator of the one or more packets; retrieve (222) the established number of constraints, the respective identifier of the particular instance of the service function, and a respective next hop from the constrained routing table (CRT) of the routing device (1) in accordance with the received identifier of the service function; select (223) one or more of all the instances of the service function in accordance with the established number of constraints and the received one or more matching values; and forward (224) the received one or more packets to the respective next hop associated with the selected one or more instances of the service function.

10. The routing device (1) of claim 9, the processor (11) further being configured to, so as to select (223) the one or more of all the instances of the service function in accordance with the established number of constraints and the one or more received matching values: select a respective instance of all the instances of the service function in accordance with a fulfillment of the established number of constraints of the respective instance by the one or more received matching values.

11. The routing device (1) of any one of the preceding claims, the service function providing a mining service associated with a digital ledger; and the identifier of the service function addressing all the instances of the service function.

12. The routing device (1) of claim 11, the digital ledger comprising a blockchain-type digital ledger.

13. A method (2) of operating a routing device (1), the method (2) comprising:

- establishing (21) a number of constraints for the routing of one or more packets to a number of instances of a service function, the established number of constraints defining prerequisites for a service provisioning by the number of instances; and selectively forwarding (22) the one or more packets to all instances of the service function in accordance with the established number of constraints.

14. The method (2) of claim 13, being performed by the routing device (1) of any one of the claims 1 to 12.

15. A computer program, comprising executable instructions which, when executed by a processor, cause the processor to perform the method (2) of claim 13 or claim 14.