The invention concerns a method for provable remote execution of a computer program as well as a network client configured to perform the method .

EP 1 016 049 Bl shows an apparatus and a method for veri fying honest gaming transactions over a communications network, and particularly for veri fying gambling transactions over the Internet . The random sequence created during a game and decisive for the outcome of the game for each player can be reconstructed using the deterministic randomi zation process based on a cooperative seed generation process . The purpose of this method is that players as well as regulators are able to reassemble any game to prove that the host ( typically a casino ) and all players played the game honestly . The method is limited to a provable application of game rules that are known to all participants beforehand . This publication does not disclose or even hint at the possibility of provable remote execution of a general computer program .

It is an obj ect of the invention to provide an auditable and potentially validated result of the execution of a given computer program at a client computer with minimal latency due to network communication not required by the computer program itsel f and with minimal computing ef fort for other computers during runtime .

To solve this obj ect , the invention proposes a method according to claim 1 and a network client according to claim 13 .

The disclosed method proposes provable remote execution of a computer program by a network client having a client private key, the method comprising the steps of : receiving by the network client a copy of the computer program, executing by the network client the computer program, generating by the network client a digital signature of at least a final state of the computer program with the client private key, transmitting by the network client the digital signature of the final state for validation of the execution of the computer program .

The digital signature may be based on the final state and the computer program itsel f . The final state may for example be the aggregation of the results output by the computer program . For example , it may comprise a memory snapshot of the finished computer program, e . g . including its head and/or stack and any other memory areas accessed or written by the computer program . At a higher level , the state may be defined as a collection of all variables allocated at the end of the computer program . Or it may be limited by definition to the content of a particular state variable or of a particular state memory area or of particular state registers . Typically, it will be useful to include at least those results of the remote execution in the final state that have been the purpose for which the computer program has been designed and executed . The digital signature may for example be an encrypted version of a hash value over at least the final state and the computer program (wherein the final state and/or the computer program may in general be replaced by their respective hash values that are at least as long as the new hash value ) , using the client private key as the encryption key for either asymmetric or symmetric encryption . According to another example , the digital signature may be a keyed- hash message authentication code (HMAC ) using the client private key as secret key and at least the final state and the computer program as the message to be authenticated . Generally, the digital signature and the client private key can be used in any way that allows secure attribution of the signed final state hash to the network client . This attribution enables a trans fer of value in exchange for the remote execution performed by the network client and thus an incentive for the network client to participate in the remote execution . The present disclosure therefore also provides a secure incentivising scheme for delegating computing work as distributed computing closer to remote data sources at the "edge" of a network ("edge computing" ) , e . g . the Internet .

In order to make the digital signature veri fiable and thus the remote execution provable , any association between the final state and the computer program is suf ficient . The final state may be only implicitly bound to a particular computer program ( for example , a program identi fier and revision may be part of the final state or di fferent program identi fiers and revisions may otherwise indirectly af fect the final state such that they result in di f ferent and discernible final states ) . In general , it is suf ficient that the computer program subj ect of the remote execution can be identi fied for potential later validation of the execution . For that purpose , any identi fier can be used, such as a name and revision of the program or a resource locator ( e . g . URL ) for accessing a copy of the computer program . The computer program may for example be provided in a decentralised manner, e . g . via the Interplanetary File System ( IPFS ) . The use of a hash value of the computer program as the identi fier, for example , has the additional advantage , that the integrity of the computer program can be checked before execution by the network client as well as before any potential validation of the execution . However, in any of those situations it is not necessary that the information identi fying the computer program as such being signed with the digital signature as long as the digitally signed final state is at least implicitly bound to the identi fied computer program as mentioned above .

Optionally, executing the computer program may comprise the step of determining by the network client a state hash of at least one intermediary state of the computer program, wherein the digital signature generated by the network client is based on the final state and at least one state hash of an intermediary state . In this way, the digital signature not only confirms the final state as such, but a sequence of at least one intermediary state before the final state . The sequence incorporates the concept of time and run-time into the provable result of the remote execution . The hash function ( s ) used for generating the state hash and as part of the digital signature introduce entropy, more speci fically information entropy, into the method and thus enforce a particular direction of the sequence ( an "arrow of time" ) , providing security against attempts to forge an execution result based on a guess or approximation thereof . The intermediary states may be defined by the computer program itsel f ( cooperative state triggers ) or by general constraints of the executing system, such as a predefined number of executed commands since the last intermediary state (pre-emptive state triggers ) . The state hash at those intermediary states may be determined in a similar fashion as the digital signature of the final state . The di f ferent definitions of " state" described above in detail apply not only to the final state , but may also apply to any intermediary state .

In one embodiment , the disclosed method comprises determining by the network client state hashes of the at least two sequential intermediary states of the computer program, wherein the second state hash and every later state hash is computed from at least the corresponding intermediary state and the previous state hash . In this way, a sequence of multiple intermediary states is defined and indirectly attested by the digital signature of the final state . The sequence is ensured essentially by a hash- linked list roughly similar to the basic data structure used in blockchains . Especially for computer programs having a relatively small ( or low entropy) state and having potentially multiple ways to reach a given state , the use of those intermediary state hashes ensures that the network client can not take any shortcuts .

In this context , the disclosed method may comprise : receiving by the network client a genesis hash (wherein the "genesis hash" need not be an actual hash value and may be any value that can be used to initiali ze or " seed" the hash chain, preferably a value of the same memory si ze as the subsequent state hashes , for example a random value ) , and determining by the network client the first state hash from at least the corresponding intermediary state and the received genesis hash . The use of an externally provided genesis hash introduces the possibility to perform two or more parallel remote executions of the same computer program and with a di f ferent genesis hash to compare the results while the final states are not interchangeable and thus each parallel remote execution is guaranteed to run fully and independently . It should be noted that the results may be comparable only to the extent that they are independent from the genesis hash, which may be not strictly true but only statistically i f the genesis hash is used as genesis seed of a deterministic random number generator af fecting the execution and thus the final state ( see below) . Alternatively, the genesis hash may also be derived from a hash of the computer program combined with an identi fier or identity of the network client .

In a further embodiment of the disclosed method, the copy of the computer program received by the network client may be digitally signed and the method may comprise the steps of : before executing the computer program, veri fying by the network client that the digital signature of the computer program is by a trusted authority . In other words , the copy of the computer program received by the network client may be digitally signed and the network client may require a valid digital signature of the copy in order to authenticate the computer program before spending resources on its execution . This may be particularly useful i f the remote execution is carried out in exchange for some type of value or payment , in which case the network client will have an interest to perform only executions cryptographically associated with a trusted authority guaranteeing the validity of the exchange or cryptographically associated with a binding transaction ( e . g . a smart contract releasing a defined payment upon provable remote execution of a computer program referenced in the smart contract by its digital signature ) .

This disclosure has particularly promising applications in the remote execution of computer programs processing local inputs . Speci fically, the computer program of the disclosed method may be configured to receive input data locally available at the network client during executing the computer program, wherein the network client records the input data received and provides the recorded input data together with the final state . Such locally available input data may for example include user inputs , such as user reactions or commands , as well as measurements or readings of local sensors , instruments or other interfaces . The processing of such inputs within the framework of the present disclosure enables ef ficient and virtually latency- free ( or even soft or hard real-time ) processing of such inputs while at the same time providing provable execution, wherein the outcome or result of the execution can be audited and validated asynchronously or after the fact .

In situations where the final state is associated with a value ( e . g . a winning game score ) and depends on a particular user input , it may be desirable to limit the possibilities of overexecution, that is , forking of the program execution in search of the user input achieving the highest value final state . Such limitation may be achieved in that the network client receives input data af fecting the final state from a network during executing the computer program . This type of input data, not being local , cannot be foreseen by the network client , thus forcing it to collapse the tree of forked states to one particular branch prior to reaching the final state . The network input data ( or non-local input data ) may for example be implemented by regular update handshakes based on random information (" state checks" ) , but anything changing the final state meets the purpose . The non-local input data may be received from a remote server or a network of servers , in any event from at least one remote network host di f ferent from the network client . In this way it can be foreseen, that the state checks are generated by a system under the control of a di fferent party than the network client , e . g . a trusted authority or a public consensus network .

More speci fically, the network client may for example expect to receive input data af fecting the final state from the network at one or more instances during executing the computer program, wherein said one or more instances are predefined or defined by the computer program . The validation of the execution can then reconstruct the same expectation and check whether this expectation has been met . In this way, it can be detected during validation i f a fraudulent network client ignores or skips the state checks . In practice , the network client may stop executing the computer program if at least one expected input is missing . In such a case , no valid final state can be reached any more , regardless of the reasons that led to the expected input being missed . The act of "receiving" in this context is not limited to either the client sending a request before receiving the input data ( the client polls for the input data ) or the client receiving the input data without such prior request ( the input data is pushed to the client ) . The digitally signed final state in this embodiment includes the proof that all state checks have been taken into account during execution of the computer program according to the well-defined expectation .

In this context , the expected input data may be unpredictable during each execution of the computer program . For example , the expected input data may contain a random number or speci fically a stochastic random number . Alternatively or additionally, the expected input data may include entropy from a source outside the control of the network client , such as a public consensus network or a trusted oracle reporting a sensor reading influenced by a stochastic physical process .

In general , the computer program may use randomly generated data, wherein the randomly generated data is generated locally by the network client . More speci fically, in this particular context "randomly generated" refers to generation with a deterministic random generator . I f the generated data influences the final state , the process of random generation is such that it can be reproduced for the purpose of validation . That is , during validation, the validating execution of the computer program can generate the same random data .

In one embodiment concerning a computer program using randomly generated data, the disclosed method may comprise the steps of : receiving by the network client a genesis seed; and generating by the network client the randomly generated data based on the received genesis seed . The genesis seed together with the deterministic generation function determines , which random data is generated during the execution of the computer program . Di fferent genesis seeds will result in di fferent random data, while identical genesis seeds will result in the same random data being generated . Thus , by using an unpredictable genesis seed, the generated random data is also unpredictable , at least in its entirety or initially, before the first random data is generated . The genesis seed may be provided by a trusted authority, which may be a service provided by one or more trusted providers or it may be a consensus network of an arbitrary number of trusted or untrusted providers , as discussed below in more detail . The genesis seed may optionally be identical to the genesis hash mentioned above in connection with the generation of state hashes .

Speci fically, i f the genesis seed is provided by one or more trusted providers , in one particular embodiment the disclosed method may comprise : generating by a network server a genesis seed based on the computer program, a current time stamp and/or a server private key; and transmitting the generated genesis seed from the network server to the network client . In this case , the genesis seed may be linked to the computer program ( i . e . one particular instance , version or revision thereof ) , to a particular time stamp when the remote execution is started, and/or to a particular trusted provider securely identi fied by a cryptographic key .

Alternatively, as mentioned above , the network client may derive a genesis seed and/or a genesis hash from a publicly accessible state , for example from data confirmed with a secure consensus protocol , such as one or more data elements integrated into a public ledger, distributed or not , ( e . g . implemented by a block chain) , for example a wallet address , a contract address , a token ID, or a transaction ID .

The scope of the present disclosure extends to a network client configured to perform the method steps attributed to the network client in the method described above and a system configured to perform the method steps of the network client and the network server in the method described above .

Referring now to the drawings , wherein the figures are for purposes of illustrating the present invention and not for purposes of limiting the same : Fig . 1 schematically shows an exemplary information flow scheme that illustrates the di f ferent states during a provable remote execution of a computer program by a network client in chronological sequence ;

Fig . 2 schematically illustrates the content of two blocks on a block chain used for initialising and proving the remote execution of the computer program;

Fig . 3 schematically shows a data flow scheme of a provable remote execution that illustrates how di f ferent data sources and parameters influence the result ;

Fig . 4 schematically illustrates two parallel remote executions creating two independent sequences of states according to Fig . 1 ;

Fig . 5 schematically shows a data flow scheme of the validation of a provable remote execution according to Fig . 3 ;

Fig . 6 shows a transition between two states of a game used as an exemplary application of a provable remote execution; and

Fig . 7 shows a simpli fied activity diagram according to the Unified Modeling Language standard .

In one embodiment , the provable remote execution may be provided as a cryptographic protocol defining a method that allows for non- fungible software runtime (NFRT ) execution . A network client performing such a NFRT execution receives a copy of the computer program ( or, simply put , " software" ) that it shall execute . For starting the NFRT execution, it initialises the software to a - possibly unique - genesis state . Beginning from this genesis state , an NFRT state evolution according to this embodiment follows a strict one-way continuity by using cryptographic hash functions on every state change . The so- formed continuous chain of state hashes can be reproduced and validated with the external input data that is stored during the NFRT execution : It consists of at least one NFRT data block that includes information about the computer program ( the application code ) , a genesis hash, a digitally signed final state hash as well as any external input data or state checks ( see below) . Long NFRT executions or multiple-stage software execution can be split up into multiple subsequent NFRT blocks that form a hash pointer based blockchain data structure . Each single NFRT block can be reproduced and validated independently .

The provable remote execution provided according to the cryptographic protocol ("NFRT protocol" ) ensures that software , operated in untrusted client environments , is being executed in an authori zed way without being tampered with . This particular exemplary embodiment is based on the recognition that it can be useful to increase information entropy with each change of software state to form a strong one-way continuity of the state evolution .

Fig . 1 shows a simpli fied schematic view of an exemplary information flow scheme that illustrates the NFRT state evolution . Starting from a genesis state ( represented by a genesis hash 1 ) , cryptographic hash functions are used upon every state change to compute a state hash 2 of the current software state , which can be a final state 3 , an initial or "genesis" state 4 or an intermediary state 5 . The state hash 2 of the final state 3 is the final state hash 6 . The repeated and iterative application of a cryptographic hash function creates a " state evolution" 7 that is a continuous sequence ( or " stream" ) of hash values ( the state hashes 2 ) until the final state 3 is reached, allowing for the computation of the final state hash 6 . Each state hash 2 increases the information entropy of the system, which makes it practically infeasible to reverse the state evolution 7 from any given point , as well as to skip steps in the state evolution 7 .

In addition to the information entropy achieved by the repeated application of a hash function, physical entropy may be introduced by input data 8 locally available at the network client and processed by the computer program during execution ( at runtime ) , which can influence the state evolution 7 and consequently the final state 3 and final state hash 6 .

Moreover, the state hashes 2 can be used as cryptographically secure pseudo-random numbers to seed application random-number generators (RNGs ) used by the computer program . The immediate feedback of randomness achieved in this case gives the state evolution 7 an even stronger dependency on its preceding states . In applications where humans or the environment interact with the software by providing input data 8 , the feedback of pseudorandom entropy to the state - and thus to the output - increases the introduction of physical entropy .

The NFRT protocol of this embodiment is executed in three consecutive steps , starting with an initialisation handshake when a network client requests an authorised NFRT execution from an authority, e . g . a trusted network server . Once the initialisation is finished and authorised by the authority, the protocol is being operated together with the execution of the respective computer program on the network client ( e . g . the client device ) , to which the NFRT protocol is being applied .

This may also include optional regular update handshakes (" state checks" ) between the network client and the authority during runtime . In that case , a continuous connection between the network client and the authority is required . Those state checks can be conducted to avoid attacks based on client environment virtualisation ( see below) . After the runtime execution is finished, the protocol allows the authority ( e . g . a network server di f ferent from the network client ) to validate and prove the correctness , authenticity and integrity of the remote execution based on the NFRT data . The three subsequent steps of the NFRT protocol are described in more detail in the following .

As mentioned above , each authorised NFRT execution starts with a handshake to agree on a particular computer program and - possibly unique - initialisation parameters . The initialisation parameters are used to set the computer program into a genesis state . After the network client ' s request to start an NFRT execution is authorised, the initialisation can be provided by an authority' s digital signature of some unique runtime information ( for example , including a unique genesis seed) as well as of a hash of the computer program that will be executed by the network client . The signature may be used as genesis hash 1 for the state evolution 7 , and thus defines together with the genesis state 4 of the computer program the first state hash 2 . I f the application uses RNG elements for initialisation or in the first state update, the genesis hash 1 may also be used as the genesis seed, i . e . an initial RNG seed . The initialisation signature from the authority is also used by the network client or the public to validate the legitimacy of the seed and the computer program, for example a particular executable application file .

Fig . 2 shows an overview of the data and information flow at the initialisation for an NFRT execution . Usage of an RSA signature scheme and a SHA3 hashing scheme would be suitable choices to implement the digital signature and the state hashes respectively . To authorise an NFRT execution, the authority - for example , a network server 9 - digitally signs with its server private key 10 a block header 11 comprising unique information 12 about the given runtime execution as well as the program hash 13 of the authorised computer program . The resulting digital signature 14 will be validated 26 by the network client 15 , and is also used for the genesis hash 1 and genesis seed 16 . The network server 9 may optionally also provide the computer program 17 in the form of application code executable by the network client 15 .

After the initialisation is finished, the network client 15 creates one or more data blocks 18 to store the NFRT data ( also , "NFRT blocks" ) . Each block 18 includes a block header 19 comprising a block header hash 20 , which is a cryptographic hash of the block header 11 , 19 of the previous block, to form a hash pointer-based blockchain . An NFRT block 18 further comprises a log 21 of any external entropy sources , such as input data 8 or state checks , and the final state hash 6 resulting from the NFRT execution 22 . The block header 19 may also comprise a copy of the unique runtime information 12 or other unique block information 23 as well as a digital signature 24 of the block header 19 generated by the network client 15 with a client private key 25 . This digital signature 24 is available only when the block header 19 is complete , including the final state hash 6 . By using the digital signature 24 as genesis seed 16 for subsequent NFRT blocks 18 , the protocol can enforce that the execution of the computer program for generating the subsequent NFRT blocks 18 can only be started after the execution of the computer program for generating present NFRT block 18 is finished .

The computer program 17 does not have to be exchanged every time an NFRT execution 22 is performed, but comparing the program hash 13 to check whether the network client 15 will run an authorised version of the computer program 17 is useful and sufficient to avoid worthless executions of obsolete program versions . Otherwise , that is , in case of a hash mismatch, an update of the computer program should be conducted by receiving a new copy of the computer program with the network client 15 . In the present example , an agreement on the computer program as well as the genesis seed 16 is required for an authority to eventually be able to validate the NFRT data during an ( optional ) asynchronous and potentially downstream validation .

After seeding the computer program state with the genesis hash 1 as described above , the NFRT execution 22 on the network client 15 can start . Every time the software state changes , e . g . due to an external input or processes in the software logic, the NFRT protocol is followed . For example , this may happen or be triggered in every frame of a computer game ( e . g . 60 times per second) , or in case of a remote vending machine once every couple of weeks when it is used . Also , high frequency applications related to sensorics or automation systems can be operated within the present NFRT framework .

Fig . 3 schematically shows the data flow scheme of the NFRT protocol according to the present embodiment during operation and execution of the computer program 17 . At every state update ("evolution step" ) , the protocol reads the software state and the previous state hash ( in case of the initial state the genesis hash) and based on this information generates a new state hash 27 . With ongoing runtime , this creates a seamless chain of state hashes 2 , one for every state update ( see Fig . 1 ) . This hash chain can be interpreted as a continuous information entropic state evolution 7 starting from the genesis hash 1 and eventually reaching the final state hash 6 . Information entropy is being increased in every step by the hashing algorithm, and physical entropy can be brought into the system with external input data 8 (user inputs , communication with other devices , etc . ) . For anyone to be able to later validate the NFRT and reproduce the hash chain, all external inputs 8 are logged together with ( at least ) the final state hash 6 . Logging also the full hash chain is optional and, i f storage and trans fer capacity allow for it, has the benefit of seeing exactly where problems ( in terms of deviations from the original hash chain during validation) occur and thus could help with the identi fication of bugs or errors . It is , however, not required for the use of the NFRT technology .

The most recent intermediary state hash ( or the genesis hash) can be used as RNG seed 28 for subsequent continuation of the NFRT execution to immediately introduce cryptographically secure pseudo-randomness back to the runtime execution . This process of entropy feedback prohibits the network client 15 from tampering by using pre-written input data 8 in, e . g . , in gaming scenarios : Every software state would depend on the full history of states , which forces the player to always react to the unique and realtime software situation . As RNGs are based on pseudo-randomness and the hashing algorithm is deterministic as well , all the entropy and pseudo-randomness can be reproduced later in the validation process based on the input data 8 recorded in the log 21 .

Some attack vectors to tamper with an NFRT execution are based on the creation of multiple copies of any state and let them evolve independently ( e . g . , by using Al systems or bots on virtual client machines to produce di f ferent input values ) . Each state evolution would be a legitimate one , as a continuous state hash chain would always be valid .

Fig . 4 illustrates the creation and evolution of two independent state evolutions 7a, 7b based on what can be called a " fork attack" . The network client 15 may use di f ferent input data 8a, 8b during execution of the computer program 17 , for example to try di f ferent movements in a game and test , which movements achieve the higher game score . Consequently, based on the di fferent input data 8a, 8b, also the game states will di f fer, including the final states 3a, 3b, as well es their respective state hashes 2a, 2b and final state hashes 6a, 6b . When both final states 3a, 3b are determined, the network client 15 could identi fy the final state 3a, 3b associated with the higher game score and generate a digital signature 24 only for the identi fied preferred final state . In particular in cases where the authorisation for NFRT execution granted by the network server 9 is tied to a participation fee ( like in game tournaments ) , this fork attack would allow network clients to gain an unfair advantage ( over other network clients and/or over the host ) . To limit the advantage of this attack, for example the network server 9 , acting as authority in the present embodiment , can randomly send state checks 29 to the network client 15 , including a randomly chosen "nonce" 30 , which is a cryptographic nonce , i . e . an arbitrary number that can be used j ust once in a cryptographic communication ( see Fig . 3 ) . The network client 15 according to the NFRT protocol includes the nonce 30 into the next state hash 27 . Information about in which state the nonce 30 is included is sent immediately to the network server 9 and recorded there for use during NFRT validation 31 . I f the network client 15 would not detect a random state check 29 within a given time frame , it could be assumed that the connection to the network server 9 has been lost or is throttled on purpose , and the NFRT protocol can enforce stopping the execution based on the missing random state checks 29 . This form of random state checks also limits advantages of executing the computer program 17 in a virtual environment that runs slower or faster than real time - or making save states and using replays . All attacks based on virtualisation and multiplication of a software state are then limited to the time between two random state checks 29. The higher the requirements for integrity of an NFRT execution are , the shorter the average time between two random state checks 29 can be chosen .

The result of the NFRT execution 32 is an NFRT block 18 comprising the authorised genesis hash 20 , 1 (which can be the hash of the block header of the preceding NFRT block) , the final state hash 6 , and the log 21 of the external input data 8 of the whole runtime ( see Fig . 2 ) . The NFRT block 18 contains a block header 19 which includes information to form a hash pointer based blockchain data structure . An NFRT block 18 or multiple NFRT blocks can be validated during NFRT validation 31 . The NFRT validation 31 can be performed by the network server 9 or by a di fferent trusted authority and for example any participant of a public consensus network other than the network client 15 itsel f . To carry out the NFRT validation 31 , the validating entity ( in this example , the network server 9 ) receives the NFRT block 18 created by the network client 15 , reproduces the hash stream of the state evolution 7 by executing the computer program 17 of the same initial parameters , input data and running state checks until it obtains a reproduced final state hash . I f the reproduced final state hash matches the final state hash in the NFRT block 18 , the network server 9 generates a block certi ficate 33 using the server private key 10 . The block certi ficate 33 can be transmitted to the network client 15 , which can use it as a proof of the correct NFRT execution and attach it to the NFRT block 18 , thereby creating a validated NFRT 34 .

Fig . 5 shows the data and information flow scheme of an NFRT validation 31 . After at least one NFRT block 18 has been transmitted by the network client 15 , it will be received to be ( optionally) validated by the respective authority - which can be the public or, in this example , the trusted network server 9 . The validator ( e . g . , the server/host , public, etc . ) has access to the exact same computer program 17 which was executed during the NFRT execution by the network client 15 . By using the genesis hash 20 , 1 as well as the log 21 of the input data 8 and state checks 29 contained in the NFRT block 18 , the network server 9 can reproduce the whole state evolution 7 by reproducing each state hash 35 of the state hash chain and recreating the RNG seed 28 based on the current reproduced state hash 35 . I f random state checks 29 were used, the network server 9 must also include those from the state check log 36 into the reproduction of the state evolution 7 . The network server 9 then compares 37 the final state hash 6 of the NFRT block 18 with the reproduced final state hash 35 and validates the NFRT block 18 i f the hash values match by generating a block signature 38 using the server private key 10 . The NFRT block 18 combined with the block signature 38 form a block certi ficate 33 . The network client 15 can receive the block certi ficate 33 from the network server 9 , validate the block certi ficate 33 with the server public key 39 and assemble the validated NFRT 34 for further use or exchange .

I f the NFRT consists of a series of multiple NFRT blocks , they can be validated together and in parallel . The network client 15 receives the block certi ficate 33 for the last NFRT block, which confirms not only the correctness of that last NFRT block, but also of hash-linked previous unvalidated NFRT blocks . Hence , the network client 15 eventually controls a validated NFRT 34 .

To further illustrate the present disclosure , another detailed embodiment is described with an exemplary execution and the generated data . This embodiment provides an example of a simple gaming application that can be securely operated and validated according to the NFRT protocol implementing the present method . This embodiment uses random state checks , and thus requires a continuous connection between the network client and the source of the state checks , e . g . a network server, which acts as authority, or any other (public ) authority .

The protocol starts with an NFRT execution request from the network client to the network server as the relevant authority . This example requires that both the network client as well as the network server have access to the application code of the computer program that will be executed on the network client .

As mentioned above , the computer program in this embodiment implements a simple game , which is about catching falling obj ects 40 with a player-controlled platform 41 at the bottom of the screen 42 . A new obj ect appears with a probability of 1 / 3 at a random position in the top row 43 each frame and is randomly appointed the label "0" ( increases score by 1 ) or "X" ( decreases score by 1 ) . The game state is updated once a second ( 1 fps ) , in which all falling obj ects 40 move downwards one row and the player can move the platform 41 to the left , the right , or not at all . The game is finished i f the player reaches a score of 2 points ( after starting at an initial score of 0 points ) . For the particular execution example discussed here , the game grid forming the screen 42 is of si ze 4 rows x 4 columns with indexed rows and columns .

Fig . 6 shows an exemplary transition between two possible game states 44 , 45 . The first state 44 depicted on the left in Fig . 6 contains two "X" elements 46 and one "0" element 47 , with the platform 41 in the leftmost column 48 . During this frame , the user gives local input data at the network client to move the platform 41 one cell to the right . The movement happens in the next frame , which also moves all existing elements 40 down one row . A new "0" element 49 appears randomly in the leftmost column, while the "X" element 46 previously located in the rightmost column ( 4 ) disappears .

The example NFRT request has an expiration time of two minutes and includes random state checks with a frequency of less than 10 seconds . The created NFRT can only be validated by the network server, as state check data is not stored in the NFRT block, but only locally by the network server . I f public validation would be required, the NFRT block would also include certi fied information of state checks ( that is , a state check log) , so that anyone can reproduce the state evolution with all external entropy sources .

Also , it is noteworthy, that this example only produces one single NFRT block for an entire game . I f the client would request to have an NFRT for two games in a row, the second game can be initiali zed with a hash including the header and the final state hash of the first NFRT block as new genesis hash . The client would create a new block header for the second block of a new NFRT data block chain, which can subsequently and independently be validated by the server or any public authority . In the present example, the computer program may be identi fied by a hash value , e . g . generated by the SHA3-256 hash function . The digital signature of the NFRT data block may be an RSA- encrypted hash computed with the SHAKE256 hash function . Similarly, any state hash may be computed using the SHAKE256 hash function . The NFRT block may further comprise an expiration time stamp, which defines a latest time for success ful validation . The computer program may be implemented such that it expects random state checks at least every ten seconds and stops execution i f it waits for a new random state check longer than ten seconds .

The software state of the computer program, which together with the previous state hash forms the payload for the state hash in this example comprises the current position/column of the player, the complete game map including all elements ("X" and "0" ) and their positions , the current score of the player, a nonce received with a latest random state check, and all user inputs together with a timestamp in "game time" ( e . g . in the simplest case , a state counter, which counts the states the game went through previously) .

The nonce generated by the network server can be a 32bit random number combined with a timestamp representing the system clock (UNIX time in seconds ) of the server system . After generation, this nonce is sent to the network client as part of the random state check . The server and/or the client can keep track of the generated and exchanged random state checks by storing the generated nonce together with a timestamp in game time and - optionally ( for cross-checking) - with the latest state hash . The history of random state checks stored in this way is used during validation to reproduce the same nonces at the same time as during execution .

Any party, other network clients , service or trusted authorities , performing a validation of a NFRT block execute the computer program themselves and replay user inputs and random state checks from the data contained in the NFRT block as described above . I f the validation arrives at the same final state hash that is included in the NFRT block, the validating entity may generate a validation certi ficate e . g . by encrypting the block header hash with their own private key using for example SHAKE256-RSA.

To further illustrate the above embodiment more in detail , a concrete execution of the example game is described with all involved parameters , data and input step by step . To properly calculate the hashes and random (RNG) values , initial conditions for a NFRT execution as well as the RSA key pairs of both client and server are given . The network client sends an NFRT authorisation request for the given software with the ID " Examp le_Game_vO . 8 . 0" on Feb 22nd, 2022 , at 22 : 35 GMT to the network server, with an expiration date two minutes after . The network server creates an NFRT block header, a hash of the block header, and the genesis seed, which is actually a digital signature formed by an encrypted version of the block header hash, according to the client ' s request .

After the block header and the genesis seed are transmitted to the network client , the network client will decode the genesis seed with the server' s public key and checks i f the code hashes as well as the header hashes match . After authentication is completed, the network client starts the NFRT execution using the genesis seed to create the initial state . The state hashes are produced by providing the given information to the hashing algorithm as a string, e . g . in the case of the initial state hash or the state hash of state S5

The following table provides a detailed view of the state evolution of the runtime from the initial state S O to the final state S 6 , where the user reaches the defined winning game score of 2 . The user inputs ( in states S2 , S3 , and S5 ) as well as the state check from the server ( state S2 ) provide external entropy whenever they occur . The variable "obj ectMatrix" holds the current game map . The displayed state is a graphical representation of the content of the variables "obj ectMatrix" and "playerColumn" as it is seen by the player during the game . After the game score reaches 2 points , the network client updates and compiles the NFRT block to the following value , digitally signs it with its private key, and sends it for validation to the network server .

I f the final state hash of the NFRT block is identical with the final state hash of the reproduced state evolution on the server side , the network server would sign a certi ficate on the NFRT block to send to the client , using a SHAKE256-RSA scheme :

The present disclosure extends to a network client executing the client-side game code and protocol as described above and showing the displayed state to the player on a computer screen as well as accepting inputs from the user, e . g . via a keyboard, computer mouse , touchpad or touchscreen . Moreover, the present disclosure further extends to a system comprising such a network client as well as a network server executing the server-side protocol as described above and performing on-demand validation .

The activity diagram in Fig . 7 diagrammatically illustrates a more generali zed version of the game application of the previous embodiment by showing an exemplary activity flow and data flow .

To further illustrate the present disclosure , the following pseudo code shows an exemplary implementation of an NFRT protocol as described above . This example comprises three code blocks , two of them are executed by the network client and e . g . , operated on a client machine ("CLIENT" and "CLIENT_RUNTIME" ) , and one is executed by a network server and e . g . , operated on a server machine ("SERVER" ) . The server code is actively listening to an authori zation request from the client , which the client sends when running the "CLIENT-HANDSHAKE" code block . This includes the initiali zation handshake and provides the required seed data for the NFRT game execution .