WO2020212349A1

WO2020212349A1 - Methods and systems for validating data in a distributed computing network

Info

Publication number: WO2020212349A1
Application number: PCT/EP2020/060465
Authority: WO
Inventors: Adrian Waller; Naomi FARLEY
Original assignee: Thales Holdings Uk Plc
Priority date: 2019-04-15
Filing date: 2020-04-14
Publication date: 2020-10-22
Also published as: GB2575896A; GB201905316D0; GB2575896B

Abstract

A computer-implemented method for validating data in a distributed computing network, the network comprising a plurality of nodes, the method comprising generating, by a node in the network, a ciphertext by encrypting a message using (i) a public key of a public/private key pair and (ii) data that is to be validated, transmitting, from the node that generated the ciphertext, a request to one or more other node(s) in the network to decrypt the ciphertext, the one or more other nodes being configured to decrypt the ciphertext using a token generated using (i) the private key of the public/ private key pair and (ii) information against which the data is to be validated, and determining, based on the result of decrypting the ciphertext, whether or not the data is valid.

Description

Methods and systems for validating data in a distributed computing network

FIELD

Embodiments described herein relate to methods and systems for validating data in a distributed computing network.

BACKGROUND

Blockchain and Distributed Ledger Technology (DLT) is gaining increasing interest as a way in which to record an audit trail and other data about transactions in a distributed setting, without the need for a central authority in the network. So-called "smart contracting" further enhances the utility of this technology, by adding the ability to specify, agree and execute any kind of contract between two parties using the blockchain framework. Here, a“smart contract” may be understood to refer to both a conventional agreement, such as that in which two parties agree the sale of a particular item of property, and also to other forms of agreement, such as where an authorised user requests and is able to obtain access permission to a private resource, such as a records database, for example.

In practice, a smart contract is implemented as a piece of digital code that sits on the blockchain. Users can call functions within the smart contract, or add new smart contracts to the blockchain, by executing one or more transactions. The result of executing a transaction may be to provide input(s) to a function contained within a particular smart contract, which may in turn trigger the execution of that contract.

Details of a particular transaction and its execution can be handled and recorded by other parties (nodes) in the network, sometimes referred to as“miners”. Not only does the process effectively outsource the execution of the transactions to the third-party miners on the blockchain network, but it essentially guarantees that each transaction is executed correctly and that no party can modify or falsely repudiate the conditions of the transaction. A problem that arises here, however, is that the miners need to see all details of the transaction, including the inputs to the transaction, in order to execute it. These details may be sensitive for many reasons, e.g. payment details, and so this is not ideal as miners are in general not trusted with such information. Other parties may also wish to, or need to, verify the details of the executed transaction before it is committed to the blockchain, which raises the same sensitivity issues. In addition, all details of the transaction will be published on the blockchain, in theory allowing anyone else in the blockchain network to read them. The fact that there are many, potentially untrusted, parties being able to execute, read and verify transaction details is a fundamental requirement of how DLTs work, and hence restricting this in any way would remove the benefits of using a DLT based approach.

To address the above issues, a number of approaches have been proposed. The first is the use of standard encryption and associated key management, in order to restrict who can access sensitive data about a transaction. However, whilst this restricts the number of parties who can read such data, a fundamental problem remains in that miners will need to be given the decryption key in order to execute the transaction. It also restricts who can verify details of transactions either before committing a block to the blockchain or after it has been published, which may interfere with the model of how DLT technology provides its benefits.

A second approach is the application of so called "zero-knowledge" cryptographic techniques, such as ones based on "zk-SNARKS" ("Zero-Knowledge Succinct Non- Interactive Argument of Knowledge"). These techniques allow anyone to validate a computation based on published and non-sensitive evidence only, and could in theory be used to allow anyone to validate a transaction without revealing any sensitive details of the transaction itself. For example, the techniques may be used to validate the transactions within a block prior to its publication on the blockchain, or to re-validate past decisions in order to check the work of the validation nodes. However, zk-SNARK techniques are not designed to protect the execution of a transaction, i.e. their use case is to allow someone to verify that a computation has been performed correctly based on provided evidence, where the evidence does not leak any information about the computation. In order to actually execute a transaction, the miners will still need to be able to see all the sensitive details of that transaction. Moreover, even in terms of validating past decisions, the zk-SNARKs approach is computationally intensive and cannot easily be supported by current blockchain frameworks such as the Ethereum based smart contracting framework, for example.

Other approaches include those based on Computing on Encrypted Data using e.g. Homomorphic Encryption HE, or Multi-Party Computation MPC. In some variants of MPC, all privacy related computations may be offloaded to an off-chain network, with the blockchain being used solely to keep a record of what happened. Although these techniques can allow organisations to hide data from one another, they do not permit the validation and execution of decisions without involvement of the data owners themselves. Accordingly, these techniques do not fit the use case of a DLT or blockchain framework, in which the main motivation is to outsource execution of the contracts to other nodes in the network.

In summary, smart contracting is a convenient and potentially low cost environment in which to specify, agree and enforce any kind of agreement. However, at present the detailed and potentially sensitive inputs to the contract need to be available to miners who execute the contracts, and to those who verify blocks either before committing them to the blockchain or as part of future validation of existing blocks. The third-party miners and verifiers are in general not fully trusted, and indeed the fact that they are not is itself a fundamental feature of the distributed environments in which DLT is designed to operate.

There is a continuing need, therefore to find ways of allowing miners to execute transactions on behalf of other parties in the network, and so retain the advantages afforded by the blockchain / DLT, whilst still ensuring details of those transactions remain confidential between the parties involved.

SUMMARY

According to a first aspect of the present invention, there is provided a computer- implemented method for validating data in a distributed computing network, the network comprising a plurality of nodes, the method comprising:

generating, by a node in the network, a ciphertext by encrypting a message using (i) a public key of a public/private key pair and (ii) data that is to be validated; transmitting, from the node that generated the ciphertext, a request to one or more other node(s) in the network to decrypt the ciphertext, the one or more other nodes being configured to decrypt the ciphertext using a token generated using (i) the private key of the public/private key pair and (ii) information against which the data is to be validated; and

determining, based on the result of decrypting the ciphertext, whether or not the data is valid.

According to a second aspect of the present invention, there is provided a computer- implemented method for validating data in a distributed computing network, the network comprising: receiving, by a node in the network, a ciphertext comprising an encrypted message, the message being encrypted using (i) a public key of a public/private key pair and (ii) data that is to be validated;

receiving, by the node, a token generated using (i) the private key of the public/private key pair and (ii) information against which the data is to be validated; decrypting the ciphertext using the token; and

outputting the result of the decryption to the network.

According to a third aspect of the present invention, there is provided a computer- implemented method for validating data in a distributed computing network, the network comprising a plurality of nodes, one of the nodes being configured to generate a ciphertext by encrypting a message using (i) a public key of a public/private key pair and (ii) data that is to be validated, the method comprising:

generating a token using (i) the private key of the public/private key pair and (ii) information against which the data is to be validated; and

providing the token to another node of the network for use in decrypting the ciphertext.

In each case above, the data to be validated may comprise data that is used to execute a transaction in the distributed computing network. The information against which the data is to be validated may define criteria that the data must meet in order for the transaction to be executed legitimately. The execution of the transaction may itself be used to trigger execution of a smart contract in the distributed computing network, for example by calling a function contained within that smart contract.

The data may be determined to be valid in the event that the decryption of the ciphertext by the token returns the message. The data may be determined to be invalid in the event that the decryption of the ciphertext by the token returns a different message.

The message may be encrypted by an algorithm that takes as input components of both the public key and the data that is to be validated. The token may be generated by an algorithm that takes as input components of both the private key and the information against which the data is to be validated.

The information against which the data is to be validated may be expressed in the form of a function. The function may be a Predicate. The data to be validated may comprise one or more attributes of a product. The information against which the data is to be validated may comprise a customer acceptance policy that specifies conditions that the product must meet in order to be accepted by the customer.

According to a fourth aspect of the present invention, there is provided a computing device for use in a distributed computing network, the computer device comprising a processor configured to carry out a method according to any one of the first, second and third aspects of the present invention.

According to a fifth aspect of the present invention, there is provided a distributed computing network comprising a computer device according to the fourth aspect of the present invention. Each node in the network may store a copy of a ledger that logs details of previous requests to validate data and the outcome of those requests.

According to a sixth aspect of the present invention, there is provided a computer readable medium comprising computer executable code that when executed by a computer will cause the computer to carry out a method according to any one of the first, second and third aspects of the present invention.

Embodiments described herein implement a scheme in which it is possible to protect sensitive details of transactions, while at the same time allowing others to execute contracts and verify the results before or after publication on the blockchain.

BRIEF DESCRIPTION OF DRAWINGS

Embodiments of the invention will now be described by way of example with reference to the accompanying drawings in which:

Figure 1 shows a peer-to-peer network of nodes in which an embodiment of the invention may be implemented; and

Figure 2 shows a schematic of a sequence of steps carried out in an embodiment of the invention. DETAILED DESCRIPTION

Figure 1 shows a peer-to-peer network 100 of nodes that supports a distributed ledger in the form of a blockchain. Each node stores a copy of the blockchain 101 , which comprises a record of transactions that have been carried out. Each time a new transaction is carried out, a record of that transaction is made by one of the nodes, which forms part of a new block added to the blockchain. The information is circulated to each of the nodes in the network, which in turn update their own copies of the blockchain.

A particular node 103 may transmit a request to the rest of the network to execute a transaction. For example, the node may issue a request for the network to confirm authorisation to access a database administered by another node on the network. The node may more straightforwardly request the other nodes to validate a function, by confirming that values provided by that node are consistent with the function. In each case, it is desirable that the other node(s) are able to perform the validation and/or execution of the transaction without being privy to the details contained therein. Once a node has performed this validation, it can log the executed transaction in a new block in the blockchain.

An example will now be described whereby one of the nodes 103 in the network tasks other node(s) in the network to validate a set of data, whilst the details of the data are kept confidential. In this example, the data comprises a set of parameter values that the node wishes to validate against a function i.e. to determine whether or not those values satisfy that function. For example, the data may comprise the values {xi , X2, ... , Xn, yi}, and the node may wish to check whether these values satisfy the function y = F(x), where x is a vector with n elements. It is desirable for the other nodes in the network to perform this check, without those nodes being aware of the actual values {xi, X2, . . . , Xn, yi}, or even the fact that they comprise numerical values, and similarly without the nodes being aware of the nature of the function F.

In order to allow the other nodes on the network to perform the desired function, the node 103 is provided with an encryption key Keyp_Ubiic, which forms one part of a public/private key pair. The private key Keypn_vate is in turn held by the party that holds the information against which the node 103 wishes to validate the data. In the present example, the two parties are one and the same i.e. it is the same single node that holds both the values {xi, X2, . . . , x_n, yi} and the function F. However, in other cases discussed later on, there may be two parties involved in the transaction, in which case the private key will be held by the second party to the transaction. (So, for example, the node 103 may hold the values {xi, X2, . . . , x_n,_, yi}, together with the public key, Keyp_Ubiic, and another party may hold the private key, Key_Private, together with the function F, where the function F comprises information against which the node 103 wishes to validate the values {xi, X2, . . . , x_n, yi}).

The node 103 uses Keyp_Ubiic, together with the data that it wishes to validate,“Data” (in this case, the parameter values {xi ,X2, . . . ,x_n, yi}), to encrypt a message. For example, the node 103 may encrypt a simple message comprising the value“1”, to obtain a ciphertext X:

X = Encode [(1), {Data + Key_Pubiic}]

Next, a token is produced by combining the function F with the private key Key_Private.

The ciphertext and the token are sent to the other nodes in the network (the“miners”) who are tasked with carrying out the decryption of the ciphertext X, using the token:

Dec [(X), token]

If the values {xi , X2, . . . , x_n, yi} satisfy the function, the decryption of the ciphertext by one of the miners will result in recovery of the underlying message, namely, the value “1”. However, if the values {xi , X2, . . . , x_n, yi} do not satisfy that function, the decryption will result in a different outcome i.e. a different value from 1. Thus:

If Dec [(X), token] = 1 , the parameter values are consistent with the function.

If Dec [(X), token] ¹ 1 , the parameter values are not consistent with the function.

Note that "decrypt correctly" requires some means to differentiate between a correctly decrypted message and an incorrectly decrypted message. In practice, this can be easily achieved by making sure that correct messages form an extremely small subset of the set of all possible messages. In this case, incorrect decryption results in a randomly selected message from the set of all messages, which will have an extremely low probability of also being in the subset of correct messages. The actual content of the message itself is irrelevant, and only knowledge of whether it decrypts correctly is of interest, as this signals that the data is valid. If on decryption the result is "1", then it is known that the data satisfies the validation criteria. Any other value indicates that the data did not satisfy the validation criteria.

The miners publicise the result of their determination, allowing nodes in the network to see whether or not the parameter values are consistent with the function. Importantly, the miners do not have any knowledge of the function itself, nor the parameter values that are being tested - the only information available to the miners as a result of the decryption is that certain parameters have been shown to be consistent with (or inconsistent with) a particular function.

One way of instantiating the above example is with a so-called“Predicate Based Encryption PBE” scheme, as described in more detail below. It will be appreciated that Predicate Based Encryption is just one example of a suitable scheme for implementing the steps above, and other schemes will also be applicable.

When using Predicate Based Encryption, the function F is restricted to being a mathematical“Predicate”. A Predicate is a function that returns a Boolean

(TRUE/FALSE) value. Typically, such functions involve a combination of Boolean valued operations, such as AND, OR, NOT, <, =, etc. Predicate Based Encryption can be used in any instance in which a smart contract is expressible as a mathematical Predicate. In the present example, a determination is made as to whether the

Predicate F(xi , X2, ... ,x_n) = TRUE for a set of input values {xi ,X2, ... ,x_n}.

More formally, a Predicate Based Encryption scheme consists of four different algorithms, which can be referred to as“Setup”,“GenKey”,“Encrypt” and“Decrypt”, respectively.

The Setup algorithm takes as input a security parameter n and outputs a set of public scheme parameters (which are used by the algorithms below) as well as a public- private key pair Key_Pubiic and Keyp_riVate,

The GenKey algorithm takes as input Keyp_nvate as output by Setup, and a description of the predicate F. The GenKey algorithm outputs a Token.

The Encrypt algorithm takes as input Keyp_Ubiic as output by Setup, a set of attributes {xi ,X2, ... ,x_n} and a message M. In the example above, the message M is“1”. The Encrypt algorithm outputs a ciphertext X. The Decrypt algorithm takes as input the Token output by the GenKey algorithm and a ciphertext X. It outputs either M (i.e.“1” in the above example) or some other symbol that is not equal to M (so a message or symbol such as 1, where that symbol is not equal to 1 in the present example).

Any Predicate Encryption scheme from the literature can be mapped to the example above using the four algorithms, Setup, GenKey, Encrypt and Decrypt. To give a specific example, we can consider the KSW Predicate Encryption scheme as described in the journal publication“Predicate Encryption Supporting Disjunctions, Polynomial Equations, and Inner Products” (Jonathan Katz, Amit Sahai, Brent Waters, J.

Cryptology 26(2): 191-224 (2013)). The KSW scheme works as follows.

1. Setup

The Setup algorithm takes as input a security parameter n and produces

(p, q, r, (G, Gs_T, e) where p, q and r are distinct primes, (G, (G _T are cyclic groups where (G =

(G_p x (G_q x (G_r and e is a bilinear map e : G x G ® G_T such that

have

practice, these groups and the bilinear map can be constructed using Elliptic Curve Pairings, further detail of which is provided in the above journal publication“Predicate Encryption Supporting Disjunctions, Polynomial Equations, and Inner Products”. Generators g_p, g_q, g_r of groups (G_p, Gs_q, (G_r respectively are also found. N is set to equal pqr. Together, these form the public parameters of the scheme.

^Ri_,u ^R2_,i ^E <G _r, h_{1 i}, h_{2 i} e ⁽G_p for i = 1 , ... ,n, R₀ e ⁽G_r, are chosen uniformly at random. Then, the public-private key pair is generated as follows, where we denote the binary group operations by · :

2. Gen Key

The Predicate F is first represented as a vector v = (v_l ... , v_n) with integer values between 0, 1 ,, ... , N-1. Methods for doing so are also described in the above journal publication“Predicate Encryption Supporting Disjunctions, Polynomial Equations, and Inner Products” (see also Decrypt below). Then, GenKey chooses

e Ί_r for i = 1 ,

... , n, f₁, f₂ 1_q , R_s (G_r, Q₆ e G_q at random. Using Keyp_nvate from Setup and v, the GenKey algorithm outputs:

3. Encrypt

The Encrypt algorithm uses Keyp_Ubiic along with the set of attributes which are represented as vector x =(xi , X2, ... ,x_n ) where X_j e Ί_N for all i e {1, ..., n). Methods for representing the attributes in this way are described in the above journal publication “Predicate Encryption Supporting Disjunctions, Polynomial Equations, and Inner Products” (see also Decrypt below). Encrypt first generates values at random for s, a, b e Ί_N and R_3,i, R_4,i e (G_r for i = 1 ,... ,n. The algorithm then outputs the ciphertext:

4. Decrypt

The Decrypt algorithm takes as input the Token as output by the GenKey algorithm and a ciphertext X (as output by the Encrypt algorithm). The Decrypt algorithm outputs:

Following the proof in the above journal publication“Predicate Encryption Supporting Disjunctions, Polynomial Equations, and Inner Products”, the output from the Decrypt algorithm is shown to be equivalent to:

where (x,v) is the inner product of the two vectors x and v. Hence, the Decrypt algorithm outputs 1 if {x,v) = 0 mod N. On the other hand, if {x,v) ¹ 0, then the Decrypt algorithm will output a value not equal to 1 with very high probability.

The key to this scheme working is a method (described in the above journal publication “Predicate Encryption Supporting Disjunctions, Polynomial Equations, and Inner Products”) for encoding a Predicate F as a vector v with integer values in the range 0,... ,N-1 , and a set of attributes as a vector x with integer values in the range 0,... ,N-1 , in such a way that:

• F(xi, X2, ... , x_n) = TRUE implies that ( x,v ) = 0 .

• F(xi, X2, ... , Xn) = FALSE implies that ( x,v ) ¹ 0 with very high probability.

Thus, by using a scheme such as that above, a miner can determine whether a set of parameters satisfies a Function F, without the miner having any knowledge of the actual parameters or the nature of the function F itself.

Referring again to Figure 1 , a second example will now be described in which a DLT is used to record information relevant to the supply chain of a product. In this example, a user of the node 103 wishes to check whether a product passes the acceptance policy of the customer of the product, whereby the acceptance policy is maintained by another node 104 in the network (the customer, for example), and information about the product is maintained by node 105. In order to achieve this, it is necessary - as before - to validate a set of data against another set of information. In this instance, the data to be validated is a set of product attributes that specify details of the product, such as identity, origin, the identity of parts which the product is comprised and/or supplier of the product. The information against which these data are to be validated is a Customer Acceptance Policy (CAP) that is held by the Customer, or a node who acts on the behalf of the customer. The CAP specifies details of what criterion the product needs to satisfy in order for the Customer to accept the product; for example, the Customer Acceptance Policy may specify that certain parts must be contained in the product, and that the product must be produced by one of a set of‘approved’ entities (e.g. Supplier A or Supplier B).

To determine whether the product passes the CAP, the product presented by node 105 must be verified against the CAP provided by node 104. Here, node 103

executes/triggers a smart contract whereby the product passes the CAP (and the Customer accepts and pays for the product, for example) on the condition that the product attributes are consistent with the CAP; that is, the product has the requisite attributes to be accepted by the Customer. The goal is to allow the other nodes in the network (such as node 103) to validate the product’s attributes against the CAP, without those nodes being privy to the details of the attributes or the Policy. Figure 2 shows the system for managing such supply chain acceptance in the present embodiment. Both the product’s attributes, and the CAP are recorded on the DLT, each provided and signed by a respective Trusted Entity 201 , 203. The product’s attributes are signed by their issuers, to allow them to be verified. In the case of the CAP, a Smart Contract (SC) can be created in which the CAP is contained. The SC defines an algorithm that can be called by an entity to obtain a decision on whether a given product satisfies the given policy. The product’s attributes are provided as an input to the algorithm, which will then evaluate the CAP against the product’s attributes. Thus, a product’s compliance with the CAP can be checked by calling the algorithm in the CAP SC, which will in turn check the policy against the product's attributes.

As in the previous example, a Predicate Based Encryption PBE scheme may be used when executing the smart contract. A Predicate can be derived from criteria in the CAP. For example, the predicate may take the form:“If Supplier of Part = Supplier A or Supplier B, output = 1”, or“If Supplier of Part = Supplier A or Supplier B, output =

True”.

Referring to Figure 2, step 1 , the supplier of the product publishes the details of the product on the DLT. Rather than simply publishing the product's attributes, the supplier instead uses the product’s attributes together with the public key Keyp_Ubiic to encrypt the message "1" and obtain a ciphertext X:

X = Enc [(1), ProductMributes + Key_Pubiic]

The ciphertext X is then published on the DLT. It will be appreciated that the ciphertext reveals no information about the product attributes used during its encryption (at least to those without the private key Keypn_vate- see later). The ciphertext also reveals no information about the message either.

In step 2, the Customer creates a CAP SC, in which the CAP is used to generate a Predicate, such as“If Supplier of Part = Supplier A or Supplier B, output = 1”, or“If Product = Part 1 and Part 2, output = True”. Using the PBE scheme, the Customer (or a Trusted Party on behalf of the Customer) creates the token, or Predicate specific decryption key, for the Predicate. The Token is included in the CAP SC, together with code to evaluate the Token against a ciphertext. It will be appreciated that the Token reveals no information about the Predicate used in its creation. In step 3, a product compliance checker 205 issues a request to check that a certain product passes the CAP.

In step 4, the CAP SC code is executed: the CAP SC obtains the ciphertext from the DLT, and using the Token in the CAP SC, the miners attempt to decrypt the ciphertext. The Miners perform decryption of the ciphertext X as follows:

Dec [(X), token]:

In step 5, a determination is made as to whether the product's attributes satisfy the Predicate (from which it can in turn be inferred whether or not the product satisfies the CAP). The determination is made based on the outcome of decrypting the ciphertext.

If the result of decrypting the message is "1", then it is determined that the product’s attributes do satisfy the Predicate and a "pass" message is returned to the product compliance checker. Thus:

If Dec [(X), token] = 1 , the product passes the CAP

If Dec [(X), token] ¹ 1 , the product does not pass the CAP.

The ciphertext will only decrypt correctly to the original message if the token is for a Predicate that is satisfied by the product’s attributes used in encrypting the message. If the result of decrypting the message is any other output, then the user's attributes are deemed not to satisfy the Predicate and a“fail" message is returned to the product compliance checker.

The encrypted message and the token can be provided as proof that the contract was executed correctly, as these can be evaluated by verifiers of blocks on the blockchain at any future time. In addition, keeping details of the Predicate to be executed from the miners and verifiers is a significant advantage. This allows details of the CAP to be kept secret, which is often desirable when the product is sensitive, and/or when the customer does not want to reveal their product acceptance requirements.

The steps above can be generalized to other settings, with the execution of the smart contract or validation of its execution being expressed as a Predicate, and the sensitive data being expressed as one or more attributes (which is PBE scheme dependent).

Thus, in the described embodiments, the miners are able to execute transactions (the 'functions') on protected sensitive inputs, and also allow others to verify the correct execution of the transactions on protected sensitive inputs. Executing a transaction (which itself may then trigger the execution of a particular smart contract) involves the miner validating that the Predicate evaluates to TRUE, which for the PBE scheme involves attempting to decrypt the encrypted message. If the decrypted value is "1" then the transaction has been executed correctly. Verifiers of blocks can similarly attempt to decrypt the recorded values, and verify that the transaction was executed correctly. The details of the Predicate itself can be kept hidden from miners and verifiers, and the miners and verifiers do not need to have access to the private key or even the scheme's public key. Any party is able to evaluate a function on those attributes without learning any details of the attributes.

It will be appreciated that if only one PBE scheme is used across multiple

organisations, and these have both Products and Customer Acceptance Policies, then these organisations will be able to infer each other's Attributes and Predicates (they have to share all the keys). If a PBE scheme is associated with each customer’s Customer Acceptance Policies only, then this could be used to achieve the hiding properties indicated above with the various types of scheme.

Embodiments do not require significant modification to existing blockchain tools and infrastructure. Encryption and token creation can be carried out offline, in separate applications. In embodiments in which PBE is used, the PBE based functions, which are executed by miners and verifiers can be encoded as part of the code for the smart contract in question, in which case no modifications would be needed. In order to validate transactions in the blockchain infrastructure without smart contracting, modifications can be made to the validation code in order to incorporate PBE functions.

Embodiments allow contracts in a smart-contracting DLT environment to be executed while protecting sensitive inputs to the contract from being revealed. Embodiments further allow details of a transactions to be verified after execution, either to validate them before committing to a block on a blockchain, or as part of validation in future by those checking the contents of the blockchain.

Embodiments can be implemented in any smart contracting environment, and can be used to validate data to be added to blocks in any blockchain environment, with or without smart contracting. Whilst embodiments can be implemented in public applications of blockchains, they are also applicable in private and permissioned environments that are more typical for industrial applications of DLT. Such

environments may include, for example, ones in which not all parties are fully trusted, such as for "need to know" controls within an organization or for collaborations involving multiple companies or other organisations.

Embodiments can allow smart contracting to be used more widely, in situations where concerns about confidentiality currently prevent or limit its application.

Implementations of the subject matter and the operations described in this specification can be realized in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations of the subject matter described in this specification can be realized using one or more computer programs, i.e., one or more modules of computer program instructions, encoded on computer storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or in addition, the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. A computer storage medium can be, or be included in, a computer- readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

While certain embodiments have been described, these embodiments have been presented by way of example only and are not intended to limit the scope of the invention. Indeed, the novel methods, devices and systems described herein may be embodied in a variety of forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the invention. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the invention.

Claims

1. A computer-implemented method for validating data in a distributed computing network, the network comprising a plurality of nodes, the method comprising:

2. A computer-implemented method for validating data in a distributed computing network, the network comprising:

receiving, by a node in the network, a ciphertext comprising an encrypted message, the message being encrypted using (i) a public key of a public/private key pair and (ii) data that is to be validated;

outputting the result of the decryption to the network.

3. A computer-implemented method for validating data in a distributed computing network, the network comprising a plurality of nodes, one of the nodes being configured to generate a ciphertext by encrypting a message using (i) a public key of a public/private key pair and (ii) data that is to be validated, the method comprising: generating a token using (i) the private key of the public/private key pair and (ii) information against which the data is to be validated; and

4. A computer implemented method according to any one of the preceding claims, wherein the data is determined to be valid in the event that the decryption of the ciphertext by the token returns the message, and wherein the data is determined to be invalid in the event that the decryption of the ciphertext by the token returns a different message.

5. A computer-implemented method according to any one of the preceding claims, wherein the message is encrypted by an algorithm that takes as input components of both the public key and the data that is to be validated.

6. A computer-implemented method according to any one of the preceding claims, wherein the token is generated by an algorithm that takes as input components of both the private key and the information against which the data is to be validated.

7. A computer-implemented method according to any one of the preceding claims, wherein the information against which the data is to be validated is expressed in the form of a function.

8. A computer-implemented method according to claim 8, wherein the function is a Predicate.

9. A computer-implemented method according to any one of the preceding claims, wherein the data to be validated comprises one or more attributes of a product, and the information against which the data is to be validated comprises a customer acceptance policy that specifies conditions that the product must meet in order to be accepted by the customer.

10. A computing device for use in a distributed computing network, the computer device comprising a processor configured to carry out a method according to any one of the preceding claims.

11. A distributed computing network comprising a computer device according to claim 10.

12. A distributed computing network according to claim 11 , wherein each node in the network stores a copy of a ledger that logs details of previous requests to validate data and the outcome of those requests.

13. A computer readable medium comprising computer executable code that when executed by a computer will cause the computer to carry out a method according to any one of claims 1 to 9.