WO2023135443A1

WO2023135443A1 - Zero knowledge proof tender

Info

Publication number: WO2023135443A1
Application number: PCT/IB2022/050194
Authority: WO
Inventors: Rémi ROBERT; Aleksandra OBESO DUQUE
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2022-01-11
Filing date: 2022-01-11
Publication date: 2023-07-20

Abstract

A method performed by one or more network devices is disclosed for submitting a tender request of a tenant and comparing offers submitted by service providers responsive to the tender request in a verifiable manner without publicly disclosing details of the offers. The method includes submitting the tender request to a distributed ledger, obtaining a first commitment value corresponding to a grade of a first offer submitted by a first service provider and an encrypted message that includes the grade of the first offer, decrypting the encrypted message to obtain the grade of the first offer, and causing a first zero-knowledge proof to be generated and submitted to the distributed ledger proving that the grade of the first offer is higher than a grade of a second offer submitted by a second service provider, which includes proving that the first commitment value corresponds to the grade of the first offer.

Description

SPECIFICATION

ZERO KNOWLEDGE PROOF TENDER

TECHNICAL FIELD

[0001] Embodiments disclosed herein relate to the field of distributed ledger technology, and more specifically, to an implementation of a privacy-preserving tender process using a distributed ledger and zero-knowledge proofs.

BACKGROUND

[0002] Distributed ledger technology, and particularly blockchains, are being used to implement solutions allowing untrusting partners to transact with each other in a decentralized manner. A blockchain is a type of distributed ledger that has a growing list of records, called blocks, that are linked using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data. By design, a blockchain is resistant to modification of its data. This is because once recorded, the data in any given block cannot be altered retroactively without alteration of all subsequent blocks.

[0003] A smart contract is a computer program or a transaction protocol which is intended to automatically execute, control, and/or document relevant events and actions according to the terms of a contract or an agreement. The code and the agreements contained therein may be stored in a blockchain. Smart contracts may provide a basis for trusted computing. Through smart contracts it is possible to define the protocol that the actors have to follow. This has allowed pre-existing processes, such as auctions or tenders, to be replicated using distributed ledgers and improved upon.

[0004] Leveraging the blockchain provides several interesting properties to an auction/tender process such as immutability, transparency, and automation. With regard to immutability, once an auction/tender is started or a bid/offer is placed, a record thereof may be stored immutably into the distributed ledger, preventing the originating party from modifying their contribution. With regard to transparency, since the process is implemented in a smart contract, the participants can be provided with the guarantee that the same process will be applied similarly for everyone. Further, it might even be possible for the participant to audit and verify the functionality themselves. With regard to automation, at the end of the process, the outcome, as defined in the smart contract, is automatically applied, leaving no room for any bias or influence. [0005] The trust that the smart contract is being correctly executed is provided by the blockchain platform. This could be either through replication of the computation or through verifiable computation. With verifiable computation, a mathematical proof is provided with the computation result (computed by a prover) and allows the receiver (a verifier) to verify that the computation was performed correctly. Such a proof can be non-interactive, meaning that it does not require any interaction between the prover and the verifier beyond transmission of the proof and the result. Furthermore, such a proof can also be qualified as “zero-knowledge” if it does not reveal anything beyond the validity of the result (the value of the result and of any intermediary steps are not disclosed). An example of a non-interactive zero-knowledge proving scheme is zero-knowledge succinct non-interactive argument of knowledge (ZK-SNARK).

[0006] In existing blockchain-based tender process implementations, the execution guarantees come from execution replication or through trusted/verifiable computation provided by third parties. The problem with these implementations is that they require information regarding the tender to be spread to at least some of the blockchain participants. The actual number of participants to which the information has to be spread depends on the blockchain setup. In a tender process, this means that information regarding the offers made by the participants in the tender need to be disclosed.

[0007] Even though it is possible to leverage the private data capabilities of existing private blockchains (e.g., Hyperledger Fabric Private Data Collection), doing so lowers the execution guarantees. For example, when using private data capabilities, it is difficult to provide execution guarantees to organizations that do not have access to the data. This creates a tradeoff between data confidentiality and trusted computation.

[0008] Further, because a tender process involves comparing data “owned” by different organization, existing solutions that combine distributed ledger technology with zero-knowledge proofs may not be sufficient. Existing solutions presuppose that one entity has access to the data needed to perform the computation, which may make them incapable of handling comparison between values owned by different organizations. As a result, it may not be possible to build a viable technical solution solely based on private data.

SUMMARY

[0009] An example embodiment is a method performed by one or more network devices communicatively coupled to a distributed ledger to submit a tender request of a tenant and compare offers submitted by service providers responsive to the tender request in a verifiable manner without publicly disclosing details of the offers. The method includes submitting the tender request to the distributed ledger, wherein the tender request is associated with a grading function for grading offers submitted responsive to the tender request, obtaining a first commitment value corresponding to a grade of a first offer submitted by a first service provider and an encrypted message that includes the grade of the first offer, decrypting the encrypted message to obtain the grade of the first offer, and causing a first zero-knowledge proof to be generated proving that the grade of the first offer is higher than a grade of a second offer submitted by a second service provider, which includes proving that the first commitment value corresponds to the grade of the first offer and a second commitment value corresponds to the grade of the second offer, wherein the first zero-knowledge proof is submitted to the distributed ledger for verification and publication.

[0010] An example embodiment is a set of non-transitory machine-readable media having computer code stored therein, which when executed by a set of one or more processors of one or more network devices communicatively coupled to a distributed ledger, causes the one or more network devices to perform operations for submitting a tender request of a tenant and comparing offers submitted by service providers responsive to the tender request in a verifiable manner without publicly disclosing details of the offers. The operations include submitting the tender request to the distributed ledger, wherein the tender request is associated with a grading function for grading offers submitted responsive to the tender request, obtaining a first commitment value corresponding to a grade of a first offer submitted by a first service provider and an encrypted message that includes the grade of the first offer, decrypting the encrypted message to obtain the grade of the first offer, and causing a first zero-knowledge proof to be generated proving that the grade of the first offer is higher than a grade of a second offer submitted by a second service provider, which includes proving that the first commitment value corresponds to the grade of the first offer and a second commitment value corresponds to the grade of the second offer, wherein the first zero-knowledge proof is submitted to the distributed ledger for verification and publication.

[0011] An example embodiment is a method performed by one or more network devices communicatively coupled to a distributed ledger to submit an offer of a service provider responsive to a tender request of a tenant in a binding manner without publicly disclosing details of the offer. The method includes obtaining a grading function associated with the tender request, generating an offer that is responsive to the tender request, generating one or more zeroknowledge proofs proving that the service provider knows the offer, a first value used to generate a first commitment value corresponding to a grade of the offer, a serial number associated with the offer, and a second value used to generate a second commitment value corresponding to the serial number, submitting the one or more zero-knowledge proofs to the distributed ledger for verification and publication, generating an encrypted message that includes the grade of the offer, and providing the encrypted message to the tenant.

[0012] An example embodiment is a set of non-transitory machine-readable media having computer code stored therein, which when executed by a set of one or more processors of one or more network devices communicatively coupled to a distributed ledger, causes the one or more network devices to perform operations for submitting an offer of a service provider responsive to a tender request of a tenant in a binding manner without publicly disclosing details of the offer. The operations include obtaining a grading function associated with the tender request, generating an offer that is responsive to the tender request, generating one or more zeroknowledge proofs proving that the service provider knows the offer, a first value used to generate a first commitment value corresponding to a grade of the offer, a serial number associated with the offer, and a second value used to generate a second commitment value corresponding to the serial number, submitting the one or more zero-knowledge proofs to the distributed ledger for verification and publication, generating an encrypted message that includes the grade of the offer, and providing the encrypted message to the tenant.

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:

[0014] Figure 1 is a block diagram of an environment in which a privacy-preserving tender process can be implemented, according to some embodiments.

[0015] Figure 2A is a diagram showing interactions between components during the tender request creation phase and the offer creation phase, according to some embodiments.

[0016] Figure 2B is a diagram showing interactions between components during the offer comparison phase, according to some embodiments.

[0017] Figure 2C is a diagram showing interactions between components during the service contracting phase, according to some embodiments.

[0018] Figure 3 is a flow diagram of a method for implementing tenant-side operations of a privacy-preserving tender process, according to some embodiments.

[0019] Figure 4 is a flow diagram of a method for implementing service provider-side operations of a privacy-preserving tender process, according to some embodiments.

[0020] Figure 5A illustrates connectivity between network devices (NDs) within an exemplary network, as well as three exemplary implementations of the NDs, according to some embodiments. [0021] Figure 5B illustrates an exemplary way to implement a special -purpose network device, according to some embodiments.

DETAILED DESCRIPTION

[0022] The following description describes methods and apparatus for implementing a privacy-preserving tender process using a distributed ledger and zero-knowledge proofs. In the following description, numerous specific details such as logic implementations, opcodes, means to specify operands, resource partitioning/sharing/duplication implementations, types and interrelationships of system components, and logic partitioning/integration choices are set forth in order to provide a more thorough understanding of the present invention. It will be appreciated, however, by one skilled in the art that the invention may be practiced without such specific details. In other instances, control structures, gate level circuits and full software instruction sequences have not been shown in detail in order not to obscure the invention. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

[0023] References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0024] Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dotdash, and dots) may be used herein to illustrate optional operations that add additional features to embodiments. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain embodiments.

[0025] In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other. “Connected” is used to indicate the establishment of communication between two or more elements that are coupled with each other. [0026] An electronic device stores and transmits (internally and/or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and/or data using machine-readable media (also called computer-readable media), such as machine-readable storage media (e.g., magnetic disks, optical disks, solid state drives, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals - such as carrier waves, infrared signals). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors (e g., wherein a processor is a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, other electronic circuitry, a combination of one or more of the preceding) coupled to one or more machine-readable storage media to store code for execution on the set of processors and/or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code/data even when the electronic device is turned off (when power is removed), and while the electronic device is turned on that part of the code that is to be executed by the processor(s) of that electronic device is typically copied from the slower nonvolatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of that electronic device. Typical electronic devices also include a set of one or more physical network interface(s) (NI(s)) to establish network connections (to transmit and/or receive code and/or data using propagating signals) with other electronic devices. For example, the set of physical NIs (or the set of physical NI(s) in combination with the set of processors executing code) may perform any formatting, coding, or translating to allow the electronic device to send and receive data whether over a wired and/or a wireless connection. In some embodiments, a physical NI may comprise radio circuitry capable of receiving data from other electronic devices over a wireless connection and/or sending data out to other devices via a wireless connection. This radio circuitry may include transmitted s), receiver(s), and/or transceiver(s) suitable for radiofrequency communication. The radio circuitry may convert digital data into a radio signal having the appropriate parameters (e.g., frequency, timing, channel, bandwidth, etc.). The radio signal may then be transmitted via antennas to the appropriate recipient(s). In some embodiments, the set of physical NI(s) may comprise network interface controller(s) (NICs), also known as a network interface card, network adapter, or local area network (LAN) adapter. The NIC(s) may facilitate in connecting the electronic device to other electronic devices allowing them to communicate via wire through plugging in a cable to a physical port connected to a NIC. One or more parts of an embodiment may be implemented using different combinations of software, firmware, and/or hardware.

[0027] A network device (ND) is an electronic device that communicatively interconnects other electronic devices on the network (e.g., other network devices, end-user devices). Some network devices are “multiple services network devices” that provide support for multiple networking functions (e.g., routing, bridging, switching, Layer 2 aggregation, session border control, Quality of Service, and/or subscriber management), and/or provide support for multiple application services (e.g., data, voice, and video).

[0028] A tender process refers to a process by which an entity that is in need of good/services invites other parties to submit a proposal/bid/offer to provide these goods/services. As mentioned above, in existing blockchain-based tender process implementations, the execution guarantees come from execution replication or through trusted/verifiable computation provided by third parties. The problem with these implementations is that they require information regarding the tender to be spread to at least some of the blockchain participants. The actual number of participants to which the information has to be spread depends on the blockchain setup. In a tender process, this means that information regarding the offers made by the participants in the tender need to be disclosed.

[0029] An example use case is described below to further highlight the problem. In the context of service discovery, there may be a tenant and multiple service providers. The tenant submits a request for tender (also referred to herein as a tender request), defining the service they need, and attaching a function that can be used to evaluate the quality of an offer (i.e., grade the offer). All of these information/materials may be submitted to the service providers through a distributed ledger.

[0030] Each service provider may create an offer to fulfill the request and use the provided function to grade their offer. The service provider may then submit the offer to the distributed ledger. The service provider may either submit the offer publicly and allow others to verify the computation of the grade or keep the offer private. If the service provider wants to keep the offer private, they will need some mechanism to provide the guarantee that the grade was computed correctly.

[0031] At this point, for the tender process to be able to continue, each service provider needs to be committed to an offer (i.e., if they win, they need to provide a service contract with terms that match the terms of the offer). It should then be possible for the smart contract to sort these offers in order and identify the winning offer (the offer with the highest grade). There are three possibilities here. The first possibility is that the offers are completely public and everyone can compute the grade and sort the offers. There is no trusted computation issue here. However, the service providers have to disclose the full offer details which might give considerable information to their competitors. The second possibility is that the offers are not public (but their integrity can still be protected by the distributed ledger, for instance by using private data capabilities) but the grades of the offers are disclosed. In such a case, sorting the offers is straightforward but the process may still disclose a non-negligible amount of information. Since the function for computing the grade is known, and the space of the possible offers may not be large, it might be possible to discover some of the details of an offer based on its grade. Also, the process will still disclose a ranking of the offers, which in itself might not be desirable. The third possibility is that the offers and the grades are not public. In this case, each service provider may only store the grade of its offer in its private data storage. However, in this case, there is no way to sort the offers based on their grades while still preserving the privacy of the service providers.

[0032] Embodiments are disclosed herein for implementing a privacy -preserving tender process using a distributed ledger and zero-knowledge proofs. Embodiments disclosed herein provide the participants of the tender process with strong guarantees regarding the correct execution of the tender process, while disclosing a minimal amount of information (both in the nominal use and in the case where some data might be leaked by a misbehaving party).

[0033] In an embodiment, the tender process includes four phases: (1) request creation; (2) offer creation; (3) offer comparison; and (4) service contracting.

[0034] In the request creation phase, the tenant defines its tender request, which may include a function that can be used to grade an offer created by a service provider. Based on this function, the tenant may generate zero-knowledge proof materials to be used in the later phases.

[0035] In the offer creation phase, the service providers create offers to fulfill the tenant’s tender request. They may use the zero-knowledge proof materials (e.g., an arithmetic circuit) to grade their offer in a verifiable way and publish an offer commitment to the distributed ledger. The offer commitment may create a binding offer that does not disclose any details about the offer to anyone but the tenant. It still provides enough information for the offer to be used in the subsequent phases of the tender process.

[0036] In the offer comparison phase, based on the offer commitments that were submitted responsive to the tender request, the tenant may sort (in a publicly verifiable way) the offers based on their grades and determine the winning offer (the offer with the highest grade). The result, together with a zero-knowledge proof, is published to the distributed ledger, still without disclosing any additional details about the offers.

[0037] In the service contracting phase, the winning service provider (the service provider that submitted the winning offer) sends the tenant the service contract for the service delivery. A smart contract may ensure that the terms of the service contract correspond to the original offer and provides the other service providers with the guarantee that the winning service provider delivered the service they committed to.

[0038] Using embodiments disclosed herein, it is possible to implement a tender process, while providing strong guarantees of its correct execution to all the participants, without broadly disclosing the details of the offers or their associated grades, thereby preserving the privacy of the participants in the tender process. Embodiments disclosed herein include provisions to preserve the deniability of the participants in case one party leaks some sensitive information. For example, a misbehaving tenant cannot provide absolute proof that a service provider submitted a given offer. Embodiments disclosed herein may be implemented using existing distributed ledger solutions without significant changes to the distributed ledger protocols. Only a modification of the transaction validation may be needed to add the verification of the zero knowledge proofs, if the verification cannot be implemented in the smart contract layer itself. The amount of information disclosed may be configurable depending on the embodiment. Multiple alterations may be considered to tune the balance between the amount of information disclosure and trusted computing guarantees.

[0039] Embodiments will now be described with reference to the accompanying figures.

[0040] Figure 1 is a block diagram of an environment in which a privacy-preserving tender process can be implemented, according to some embodiments. As shown in the diagram, the environment includes a distributed ledger 140, a tenant 110, a service provider n 120 (which may be one of many service providers), and a trusted third party 130. The tenant 110, service provider 120, and trusted third party 130 may be communicatively coupled to the distributed ledger 140 and have access to the distributed ledger 140.

[0041] For ease of description, entities such as the tenant 110, service provider 120, and trusted third party 130 are described herein as performing certain operations. Unless the context indicates otherwise, this should be understood to mean that one of more electronic/network devices (e.g., which are owned, controlled, and/or managed by that entity) are performing the operations on behalf of the entity. Also, for ease of description, the distributed ledger 140 is described herein as performing certain operations. Unless the context indicates otherwise, this should be understood to mean that the peers implementing the distributed ledger 140 perform the operations individually or collectively, where the peers may be implemented by one or more electronic/network devices.

[0042] The distributed ledger 140 may be implemented using existing distributed ledger platforms supporting smart contracts or even a purpose-built one that integrates the business logic of embodiments disclosed herein at a lower level of the protocol stack. In an embodiment, the distributed ledger 140 is implemented based on blockchain technology. Depending on the desired privacy guarantees (e.g., depending on whether the identity of the service providers submitting offers responsive to the tender request should be public), the distributed ledger 140 may also support private transactions (transactions whose details are only accessible by specific peers of the distributed ledger) and/or anonymous transactions (transaction whose author cannot be identified (while some attributes of the author can still be guaranteed, such as their right to access the ledger for instance)). One example of a distributed ledger platform fulfilling these requirements is Hyperledger Fabric.

[0043] The distributed ledger 140 may be able to verify zero-knowledge proofs that are submitted as part of a transaction (assuming the necessary materials have been submitted to the distributed ledger 140 beforehand). Depending on the distributed ledger platform used, this may be implemented at the smart contract level, might involve the use of a plugin (if the distributed ledger platform supports it), and/or might involve extending the distributed ledger platform in another way.

[0044] The trusted third party 130 may be a passive actor in the system. The trusted third party 130 is included in the diagram to show that for some of the smart contracts to be executed in the distributed ledger 140 in a way that is trusted by all participants, the trusted third party 130 may be involved to take part in or validate the smart contract execution. The trusted third party 130 may be a normal participant in the distributed ledger 140. In case the distributed ledger platform has been extended to support additional functionality, the software used by the trusted third party 130 to participate in the distributed ledger 140 may need to include this extension.

[0045] The tenant 110 is an entity that initiates the tender process to collect and compare offers regarding a service that they would like to receive. The tender request may define the requirements of the service (e g., what the service needs to provide) as well as a grading function that can be used to grade offers submitted responsive to the tender request. The grades of the offers may be used to compare the offers and determine which offer is the winning offer.

[0046] At the end of the tender process, the tenant 110 may collect all of the offers submitted by the service providers, compare the offers based on their grades, and publish the result to the distributed ledger 140. As will be described in further detail herein, embodiments may do this without revealing any additional details about the offers.

[0047] The service provider 120 is an entity that may submit an offer responsive to a tender request. The service provider 120 may create an offer in a format that can be used as an input to the grading function. The service provider 120 may be responsible for the trusted execution of this grading function on its offer and the submission of a corresponding offer commitment to the distributed ledger 140.

[0048] At the end of the tender process, the winning service provider (the service provider that submitted the offer with the highest grade) submits a service contract to the tenant 110. As will be further described herein, embodiments may ensure that only the winning service provider 120 is able to submit a service contract to the tenant 110, and that the terms of the service contract result in the same grade that was promised in the offer commitment.

[0049] As shown in the diagram, the distributed ledger 140 includes a tender smart contract 170, zero-knowledge proof materials 160, a service schema 150, and a tender data structure 180.

[0050] The tender smart contract 170 may store the code of the business logic to be executed in the distributed ledger 140 during the course of the tender process. In an embodiment, some or all of the business logic of the tender smart contract 170 is embedded into the distributed ledger 140 itself. The details of the business logic handled by the smart contract 170 are further described herein.

[0051] The zero-knowledge proof materials 160, the service schema 150, and the tender data structure 180 represent the data that will be stored in the distributed ledger 140 during the tender process. It should be noted that for purposes of illustration, the diagram shows an “applicationlevel view” and does not necessarily reflect how the data would be stored “on-disk”. In the case of a blockchain, for instance, this data may be split into transactions stored as part of multiple blocks.

[0052] The zero-knowledge proof materials 160 represent the “fixed” materials that are used as part of the tender process. Such materials may be generated upon the initialization of the smart contract 170 on the distributed ledger 140 (or possibly upon initialization of the distributed ledger 140 itself) and are typically not modified thereafter except to fix bugs or modify the tender process.

[0053] The service schema 150 may describe the data structures that the service providers 120 can use to represent their service/offer. This representation may then be used by the grading function to evaluate and compare offers, and also used in the service contract to represent the contracted service.

[0054] The tender data structure 180 may be used to store information that is created as part of the tender process in the distributed ledger 140. A new instance of the tender data structure 180 may be created for each new tender process. As shown in the diagram, the tender data structure 180 may include a request data structure, multiple offer commitment data structures (one for each offer submitted responsive to the tender request), and a result data structure. [0055] The request data structure may be used to store information about the service that is expected by the tenant 110. The expectation may be represented by a grading function that is expressed in a form suitable for processing by a non-interactive zero-knowledge proving scheme (e.g., arithmetic circuit) as well as in a form understandable by the service providers 120. In an embodiment, the non-interactive zero-knowledge proving scheme is zero-knowledge succinct non-interactive argument of knowledge ZK-SNARK To make it possible to leverage zeroknowledge proofs, the request data structure may also be used to store the materials needed for the proof generation and verification (e.g., proving key and verification key). The request data structure may also be used to store the tenant public key to allow other participants to create encrypted messages that only the tenant 110 can decrypt/read. It should be noted that not all of the tender request data needs to be stored in the public part of the distributed ledger 140. In an embodiment, some of the tender request data might only be made available to a limited subset of parties. For example, the details of the service expected by the tenant could be made not to be public since the disclosure of such information might be harmful (e.g., if it is disclosed to competitors).

[0056] The offer commitment data structure may be used to store information regarding an offer commitment submitted by a service provider 120 responsive to a tender request. For example, as shown in the diagram, the offer commitment data structure may be used to store zero-knowledge proofs of execution and associated public inputs. As will be further described herein, the public inputs may include commitments (e.g., cryptographic values) that do not reveal any details about the offer but allow the verification of some properties when coupled with additional materials. As shown in the diagram, the offer commitment data structure may also be used to store encrypted data. The encrypted data may include the grade of the offer encrypted using the public key of the tenant 110. It should be noted that offer commitments do not disclose information to anyone but the tenant 110, and to the tenant 110 they may only disclose the grades of the offers, and not the contents of those offers. In cases where the offer commitment transaction is submitted anonymously, it may not even be possible for the tenant 110 to link an offer to a particular service provider 120.

[0057] The result data structure may be used to store information regarding the comparison of the offers submitted responsive to the tender request in terms of their grades, together with the zero-knowledge proof materials that allow for verifying that the comparison has been performed correctly.

[0058] As shown in the diagram, the trusted third party 130 includes a peer component 134 and a private data storage 132. As mentioned above, the trusted third party 130 may not have an active role in the tender process. As a result, it may only include standard components such as the peer component 134 and the private data storage 132. The peer component 134 and private data storage 132 may, as part of the distributed ledger protocols, participate in various processes such as consensus or smart contract execution.

[0059] As shown in the diagram, the tenant 110 and the service provider 120 include similar components, the difference being that they execute different parts of the business logic of the tender process. For example, both the tenant 110 and the service provider 120 may include a peer component (peer component 114 and peer component 124, respectively), a private data storage (private data storage 112 and private data storage 122, respectively), and a client component (client component 116 and client component 126, respectively).

[0060] The peer components 114 and 124 are similar to the peer component 134 of the trusted third party 130 in that they allow the tenant 110 and service provider 120, respectively, to participate in the distributed ledger 140. The private data storages 112 and 122 may store information used in the private transactions of the distributed ledger 140 that involve the tenant 110 and service provider 120, respectively. In an embodiment, the private data storages 112 and 122 are provided by the distributed ledger platform. The client components 116 and 126 may implement parts of the tender process business logic for the tenant 110 and the service provider 120, respectively (e.g., the other parts being implemented by the tender smart contract 170). The client components 116 and 126 may implement functionalities used for the tenant 110 and the service provider 120, respectively, to take part in the tender process. In addition to interfacing with the distributed ledger 140 and the tender smart contract 170 via the peer component 114, the client components 116 and 126 may implement some of the operations related to the generation of the zero-knowledge proofs and materials. In an embodiment, a party/entity may perform the role of a tenant in some tender processes while performing the role of a service provider in other tender processes.

[0061] In an embodiment, a privacy-preserving tender process is divided into four phases: (1) the request creation phase; (2) the offer creation phase; (3) the offer comparison phase; and (4) the service contracting phase. The different phases of the process can be seen as independent and providing complementary guarantees.

[0062] Figure 2A is a diagram showing interactions between components during the tender request creation phase and the offer creation phase, according to some embodiments.

Request creation

[0063] A goal of the request creation phase is for the tenant 110 to submit a tender request, responsive to which service providers can submit offers. The tender request may be stored in the distributed ledger 140 (e.g., using the request data structure) and used as a basis for the following operations handled by the smart contract (first in the tender, and then for the service delivery).

[0064] At operation 1, the tenant 110 designs a grading function (G) that can be used to grade offers. The grading function may be designed based on the tenant’s expectations/requirements for a service, together with the service schemas (e.g., service schema 150) that have been agreed upon beforehand and stored in the distributed ledger 140. In an embodiment, the grading function has multiple representations. For example, there may be one representation that is suitable for use with a non-interactive zero-knowledge proving scheme (e g., a grading arithmetic circuit) and one representation that can be understood and studied by the service provider 120 in a way that allows the service provider 120 to create a suitable offer. In an embodiment, for an offer that does not fulfill the tenant’s requirements, the grading function returns a grade of zero (or other value indicative of the lowest grade). Such a grade means that the offer is not suitable and cannot win the tender.

[0065] At operation 2, the tenant 110 generates zero-knowledge proof materials associated with the grading function that are needed for generating and verifying zero-knowledge proofs. The zero-knowledge proof materials may include a proving key associated with the grading arithmetic circuit (Pkg) and a verification key associated with the grading arithmetic circuit (Vkg). In a case where the tenant 110 wishes to use a predefined grading function, there may be no need for the generation of new zero-knowledge proof materials. In such a case, the tenant 110 may just need to generate the inputs for the predefined grading function.

[0066] At operation 3, the tenant 110 submits the tender request to the distributed ledger 140. The tender request may include the following information that is stored publicly: (1) G or a reference to G; (2) proving key Pkg, (3) verification key Vkg, and (4) the tenant’s public key (Tpk). In an embodiment, the grading function G may only be disclosed to suitable service providers 120 so as to avoid disclosing information too broadly. This could be done, for example, using private transactions/data.

[0067] At operation 4, a tender request event is generated informing the listening service providers 120 of the tender request.

Offer creation

[0068] A goal of the offer creation phase is for the service provider 120 to commit to an offer in a way that discloses minimal information, while still allowing the tender process to be performed correctly.

[0069] The notion of commitments may be used in this phase, which may be defined as follows: let COMM denote a statistically-hiding non-interactive commitment scheme (i.e., given randomness r and message m, the commitment is c := COMM r(m); subsequently, c is opened by revealing r and m, and one can verify that COMM_r(m) equals c). While a certain commitment scheme is described here to illustrate an embodiment, it should be understood that other types of commitment schemes may be used.

[0070] At operation 5, the service provider 120 obtains information about the tender request from the distributed ledger 140. This may include, for example, the grading function G, the associated proving key Pkg, and the tenant’s public key Th.

[0071] At operation 6, the service provider designs an offer (O) based on the tender request and its own service offering. In this phase, the service provider 120 may be able to experiment with multiple offer designs to try to maximize the grade of the offer they are willing to submit. [0072] At operation 7, the service provider 120 leverages the grading arithmetic circuit G and the associated proving key Pkg to generate a zero-knowledge proof (Pl) that may cover a few aspects. The first aspect may be to generate a proof proving that the service provider 120 correctly computed the grade of an offer O that they kept secret. So, based on the offer O as a private input, the grade of the offer O may be provided as a public output.

[0073] However, it may be desirable to keep the grade of the offer secret as well. As such, instead of outputting the grade itself, a commitment corresponding to the grade (cl) may be provided as a public output, where cl = COMM_r(grade). As a result, the zero-knowledge proof Pl proves that the service provider 120 knows a secret offer O and a secret/random number (r) that can be used to generate a given commitment cl.

[0074] Furthermore, it may be desirable to associate a secret unique serial number (sn) with the offer O. As such, a commitment corresponding to the serial number sn (c2) may be provided as a public output, where c2 = COMM_s(sn). The zero-knowledge proof Pl thus may also prove that the service provider 120 knows sn and a secret/random number 5 that can be used to generate a given commitment c2.

[0075] In the later phases, as will be further described herein, commitment cl may be used to ensure the tenant 110 that the service provider 120 has correctly computed the grade of its offer, while commitment c2 may be used to prove that a service provider 120 was the creator/ originator of a winning offer.

[0076] In an embodiment, as show in the diagram, the grading arithmetic circuit G does not have any public input. The private input of the grading function circuit G includes offer O, serial number sn, r, and v The public output of the grading arithmetic circuit includes commitment cl and commitment c2. Pl proves that the service provider 120 (SP) knows an offer O, serial number sn, r, and s such that they produce the commitments cl and c2. [0077] In the next phase, the tenant 110 may need to access the grade and the secret number r. As such, at operation 8, the service provider 120 encrypts this information using the tenant’s public key Tpk. The resulting encrypted message may be referred to as Sc. In some embodiments, as will be further described herein, the tenant may not need access to the secret number r. In such embodiments, secret number r may not be included in the encrypted message Sc.

[0078] At operation 9, the service provider 120 submits the offer to the distributed ledger 140. This may include the zero-knowledge proof Pl, the commitment cl corresponding to the grade, the commitment c2 corresponding to the serial number sn. and the encrypted message Sc

[0079] At operation 10, when validating the transaction (e.g., either as part of the tender smart contract 170, or in some lower layer of the stack), the peers implementing the distributed ledger 140 verify the validity of the zero-knowledge proof Pl. To do so, they may leverage the associated verification key Vkg that was included in the tender request. Any transaction with an invalid zero-knowledge proof may be rejected.

[0080] At operation 11, the tenant 110 is notified of the submission of an offer to its tender request.

[0081] The first two phases of the tender process (the request creation phase and the offer creation phase) may allow the service provider 120 to submit an offer to a tender request without disclosing details about the offer to anyone except to the tenant 110, and only disclosing information to the tenant 110, possibly anonymously, and in a repudiable way.

[0082] The role of the zero-knowledge proof Pl generated during the offer creation phase is to guarantee to the tenant 110 that there was no mistake (intentional or not) in the computation of the grade. If the offer wins the tender, the service provider 120 may be required to present the underlying offer and could reasonably be penalized for refusing to do so.

[0083] From the service provider side, embodiments allow to preserve their deniability. Even if the tenant 110 is malicious, the tenant 110 may not be able to provide any proof of the offer submission from a service provider 120. Besides, embodiments also support submitting an offer anonymously.

[0084] In an embodiment, there are separate arithmetic circuits for outputting commitment cl and commitment c2, and separate zero-knowledge proofs are generated for each commitment. For example, there may be one zero-knowledge proof proving that that the service provider 120 knows an offer O and r such as the execution of the grading arithmetic circuit generates the commitment cl. In addition, there may be another zero-knowledge proof proving that the service provider 120 knows the serial number sn and 5 such that the execution of the grading arithmetic circuit generates the commitment c2. [0085] Figure 2B is a diagram showing interactions between components during the offer comparison phase, according to some embodiments.

[0086] A goal of the offer comparison phase is to compare the offer commitments stored in the distributed ledger 140 in terms of their grades. The other participants in the distributed ledger 140 should be able to trust that the comparison has been done correctly without the tenant 110 having to reveal additional information.

[0087] At operation 12, the tenant 110 obtains the offer details from the distributed ledger 140. Also, for each of the offers, the tenant 110 decrypts the encrypted message Sc containing the grade of the offer and secret number r (e g., using the private key corresponding to the tenant’s public key Tpk).

[0088] At operation 13, the tenant 110 verifies that the commitment cl corresponding to the grade of the offer actually corresponds to the grade of the offer given the secret number r (e g., verifies that cl == COMM_r(grade)). This ensures that the grade decrypted from the encrypted message Sc matches the public commitment cl (the grade included in the encrypted message Sc corresponds to the commitment cl stored in the distributed ledger 140). It should be noted that operation 13 is not strictly necessary (it is optional). If the grade is incorrect, it will anyways be impossible for the tenant 110 to generate the necessary zero-knowledge proof later in this phase. [0089] At operation 14, the tenant 110 obtains, from the distributed ledger 140, the zeroknowledge proof materials that are to be used to perform comparisons of the offer commitments. These materials may include a comparison arithmetic circuit (C) and the associated proving key (Pkc).

[0090] In an embodiment, the comparison arithmetic circuit C may be represented using the following pseudocode:

}

[0091] The pseudocode shown above ensures that a first grade (a) is greater than a second grade (Z>), and that the respective commitments (cl a and cl_b) are the proper commitments for grade a and grade b given secret numbers r a and r_b.

[0092] The comparison arithmetic circuit C may be used to generate a zero-knowledge proof (7’2) proving that the grade corresponding to commitment cl a is greater than the grade corresponding to commitment cl b without disclosing the grades themselves.

[0093] At operation 15, the tenant 110 may use the comparison arithmetic circuit C to generate a zero-knowledge proof P2 proving that the grade corresponding to commitment cl is higher than the grade of corresponding to commitment c2. The tenant 110 may construct multiple similar zero-knowledge proofs covering the complete order by comparing the offer commitments two at a time.

[0094] For example, given four offers 01, 02, 03 and 04, the tenant 110 may generate one or more zero-knowledge proofs (multiple P2 proofs) that prove: 01 has a higher grade than 03, 03 has a higher grade than 02, and 02 has a higher grade than 04, which provides the complete ordering of the offers: 01 > 03 > 02 > 04. In an embodiment, the tenant 110 generates one or more zero-knowledge proofs (one or more P2 proofs) that just prove that one offer (e.g., 01) has a higher grade than all of the other offers (e.g., 01 > 02, 01 > 03, and 01 > 04).

[0095] In an embodiment, as show in the diagram, the public input of comparison arithmetic circuit C includes the commitment corresponding to grade a (COMM_r_a(grade_a)) and the commitment corresponding to grade b (COMM_r_b(grade_b)). The private input of the comparison arithmetic circuit C includes grade a, grade b, r a, and r b. Zero-knowledge proof P2 proves that the input commitments correspond to the grades and that grade a is higher than grade b. As will be further described herein below, there are various possible scheme to prove the ordering of offers.

[0096] At operation 16, the tenant 110 may submit the zero-knowledge proofs (e.g., multiple P2 proofs) to the distributed ledger 140 to be recorded in the result data structure. This provides the distributed ledger 140 with a clear record of which offer commitment is the winner of the tender (but not which service provider 120 made that offer or the contents of the offer). [0097] At operation 17, the peers implementing the distributed ledger 140 may verify the validity of the zero-knowledge proofs (multiple P2 proofs). To do so, they may leverage materials from the distributed ledger 140 including the verification key associated with the comparison arithmetic circuit (Vkc) (e.g., which may be stored as part of the zero-knowledge proof materials 160). If any of the zero-knowledge proofs is invalid, then the transaction may be rejected.

[0098] At operation 18, the service provider 120 is notified of the outcome of the tender process. The service provider 120 may determine at this point whether it is the winner of the tender based on the zero-knowledge proofs (the P2 proofs) submitted to the distributed ledger 140.

[0099] Depending on the method used to sort the offers, the amount of information disclosed can differ. However, the guarantee is the same: the offer with the highest grade among all the ones submitted to the distributed ledger 140 is identified in a guaranteed way.

[00100] The embodiment described above uses a simple scheme that limits the number of proofs generated. As a result, certain information is disclosed. For example, for every commitment, the tenant 110 is able to provide a verifiable zero-knowledge proof of the associated grade (using the associated grade and r decrypted from Sc). Also, the order between the offers is completely disclosed (but a simple variant could be used to only disclose the winning offer).

[00101] In another embodiment, less information can be disclosed using the following scheme. The service providers 120 do not disclose the secret value r but only the grade. As a result, the tenant 110 may not be able to provide any proof regarding the grades of the offers. The tenant 110 generates intermediary numbers and requests that the service providers 120 provide proof that the grade of their offer is greater (or lesser) than a particular intermediary number. Then, the tenant 110 may generate proofs for the relationships between the intermediary numbers (again using commitments), and from there the relationships between the offers (in terms of their grades) can be deduced. Depending on what relations are proven, it is possible to disclose the complete order, or only which offer had the highest grade. It should be noted that while these operations are described above as being performed by the tenant 110, it may also be implemented instead by a trusted third party 130.

[00102] As an example, the tenant 110 may choose a number (n) that is between the highest grade and the second highest grade, also choose a value x. The tenant 110 may request that each service provider 120 generate a zero-knowledge proof of the comparison between the grade of their offer against the number n. In this case, the public input to the comparison arithmetic circuit C may include the commitment corresponding to the grade of the offer (e.g., cl) and the commitment corresponding to the number n given value x (e.g., C0MM_x(n)). The private input to the comparison arithmetic circuit C may include the grade of the offer, the number n, r, and x. The resulting zero-knowledge proof may prove that the commitment matches the grade (using the private inputs) and that the grade is higher than or lower than the number n. This scheme allows for identifying the winning offer without disclosing r to the tenant 110. This scheme differs from the scheme shown in the diagram in that it changes the data disclosed to the tenant 110 (e.g., r does not need to be disclosed) and the tenant 110 obtains zero-knowledge proofs from the service providers 120 instead of generating them itself.

[00103] Figure 2C is a diagram showing interactions between components during the service contracting phase, according to some embodiments.

[00104] A goal of the service contracting phase is to enforce the outcome of the tender process. It is desired that all the participants should be provided with strong guarantees that the service contract submitted to the tenant 110 as an outcome of the tender process is coming from the service provider 120 that submitted the winning offer commitment and that the grade of the service contract is the same as the grade of the originally submitted offer. [00105] At operation 19, the winning service provider 120 obtains the zero-knowledge proof materials from the distributed ledger 140 needed to generate a zero-knowledge proof of the winning offer (P3). These materials may include the winning offer verification arithmetic circuit (S) and the associated proving key (Pks) (e.g., which may be stored as part of the zeroknowledge proof materials 160).

[00106] A goal of the zero-knowledge proof P3 is for the service provider 120 to be able to publish in the public part of the distributed ledger 140 a zero-knowledge proof that they have won a tender process.

[00107] At operation 20, the service provider 120 generates the zero-knowledge proof P3 using the materials obtained in the previous operation. The zero-knowledge proof P3 may provide proof of the following: the service provider 120 knows the serial number sn and secret number 5 such that the value K = COMM sCv/z) is part of the list of the winning offer commitments (stored in the distributed ledger 140) (K is one of the commitments (e.g., c2) of the offers).

[00108] In an embodiment, as show in the diagram, the public input of the winning offer verification arithmetic circuit S includes the serial number sn. The private input of the winning offer verification arithmetic circuit S includes . The resulting zero-knowledge proof P3 proves that the service provider 120 knows 5 and serial number sn such that C0M\1_s(.w) is the commitment of a winning offer.

[00109] At operation 21, the service provider 120 submits the service contract (which can be, but does not necessarily have to be, a smart contract) and also submits with it r, the serial number sn, and the zero-knowledge proof P3. The smart contract (e.g., tender smart contract 170) may store some information publicly (e.g., P3 and sn , while the other parameter (r) may only be used as part of the private smart contract execution and not stored in the distributed ledger 140.

[00110] At operation 22, the execution of the smart contract enforces the outcome of the tender process. After verifying the validity of the zero-knowledge proof P3 (e.g., leveraging a verification key associated with the winning offer verification arithmetic circuit S (Vks)), the smart contract may ensure in its private part that: (1) the grade of the service contract matches the grade from the offer; and (2) the service contract is coming from the winning service provider. The former may be ensured by making sure that the commitment corresponding to the grade of the service contract matches the commitment cl (computed using r disclosed with the service contract). Only the winning service provider knows r (in case the value is disclosed (e.g., in operation 9), a second commitment with another secret value can be used instead). As such, the latter can be ensured by the winning service provider disclosing r. [00111] The verification of that transaction is not straightforward, as it deals with sensitive information, particularly the content of the offer. Two possible options are disclosed herein. With the first option, this information may be shared with a trusted third party. In this case, the verification performed as part of the smart contract can be trusted because of the inclusion of a trusted third party. This trusted third party may provide guarantees of some sort that the information will not be leaked. The trusted third party may need to know the details of the offer and r.

[00112] With the second option, this information is only made accessible to the tenant 110 and the service provider 120. In this case, the verification performed as part of the smart contract can only be trusted if it is assumed that the tenant 110 and service provider 120 are not colluding. More generally, private verification that the service contract is according to the original offer and coming from the winner of the tender may be performed as follows. The service contract and r are disclosed to the verifiers. The verifiers compute the commitment for the service contract and verify that it matches the commitment from the offer. A limitation here is that no “public” proof is published. This may mean that if the limited parties responsible for validating the transaction are not trusted, the rest of the participants have no guarantees that the outcome of the service contract is respected. However, if a trusted third party is involved in the verification, this may be enough for other participants to trust that the tender outcome has been respected. In such a case the public verification described below may not be needed.

[00113] The smart contract may also provide some guarantee (but not a perfect guarantee) in its public part that the service contract is coming from the winning service provider of the tender (a guarantee that the service contract came from someone who won a tender for which no service contract has yet been contracted). The zero-knowledge proof P3 proves that the service contract is coming from the winner of the tender if the serial number sn was not already published.

[00114] While it is straightforward for the private part of the smart contract to verify that the transaction comes from the winner of the tender, it might not be straightforward to provide public guarantees. There may be two possible cases. The first case is one in which the service provider 120 is willing to disclose that they won the tender. In such a case, the winning service provider 120 may publish a proof that they were the originator of the offer (for example, by signing the new transaction with the same key that was used to sign the transaction containing the offer commitment or publicly publishing 5 and the serial number sn (no one but the winner should know 5 and sn so this proves that they are the winner). The second case is one in which the service provider 120 is not willing to disclose that they won the tender. In such a case, it means that it should not be possible to publicly link the transaction to that particular tender. In such a case, as described above, the service provider 120 may, by disclosing zero-knowledge proof P3, prove that they have won a tender. It is not perfect, but it raises the requirements for any misbehavior and allows for publicly tracking the number of created tenders versus the number of service contracts resulting from them. Any discrepancy would indicate that the system is not behaving as expected.

[00115] The guarantee that is provided in the service contracting phase is that the outcome of the tender process is respected. Generally, this means that a transaction on the distributed ledger 140 has to conform to the winning offer. Some values have to conform to the content of the offer, and some related entity (for instance the entity submitting the transaction) has to be the entity that created the winning offer.

[00116] Thus, embodiments may use distributed ledger technology and non-interactive zero- knowledge-proofs of computation to allow for the trusted execution of a tender process without the disclosure of unnecessary information (it preserves privacy). This may be achieved through the creation of a tender request incorporating zero-knowledge proof materials, creation of offer commitments with trusted grade computations leveraging the materials from the previous step, comparison of the offers using pre-agreed zero-knowledge proof materials (e.g., proving key and arithmetic circuit), and enforcement of the tender outcome leveraging the outputs from the previous steps.

[00117] Figure 3 is a flow diagram of a method for implementing tenant-side operations of a privacy-preserving tender process, according to some embodiments. The method may be performed by one or more network devices.

[00118] The operations in the flow diagrams will be described with reference to the exemplary embodiments of the other figures. However, it should be understood that the operations of the flow diagrams can be performed by embodiments other than those discussed with reference to the other figures, and the embodiments discussed with reference to these other figures can perform operations different than those discussed with reference to the flow diagrams.

[00119] At block 310, the one or more network devices submit a tender request to the distributed ledger, wherein the tender request is associated with a grading function for grading offers submitted responsive to the tender request. In an embodiment, the tender request includes a grading program adapted for a zero-knowledge proving scheme (e.g., a grading arithmetic circuit G), a proving key associated with the grading program adapted for the zero-knowledge proving scheme (e.g., Pkg), and a verifying key associated with the grading program adapted for the zero-knowledge proving scheme (e.g., Vkg). In an embodiment, the zero-knowledge proving scheme is ZK- SNARK and the comparison program adapted for the zero-knowledge proving scheme is an arithmetic circuit. [00120] At block 320, the one or more network devices obtain a first commitment value (e.g., cl) corresponding to a grade of a first offer submitted by a first service provider and an encrypted message (e.g., Sc) that includes the grade of the first offer. As shown in block 330, the distributed ledger may store one or more zero-knowledge proofs (e g., Pl) proving that the first service provider knows the first offer, a first value used to generate the first commitment value, a serial number associated with the first offer, and a second value used to generate a third commitment value corresponding to the serial number. In an embodiment, the first commitment value is generated as a public output of the grading program adapted for the zero-knowledge proving scheme.

[00121] At block 340, the one or more network devices decrypt the encrypted message to obtain the grade of the first offer.

[00122] At block 350, the one or more network devices cause a zero-knowledge proof (e.g., P2) to be generated proving that the grade of the first offer is higher than a grade of a second offer submitted by a second service provider, which includes proving that the first commitment value corresponds to the grade of the first offer and a second commitment value corresponds to the grade of the second offer, wherein the zero-knowledge proof is submitted to the distributed ledger for verification and publication. In an embodiment, the zero-knowledge proof is generated based on a comparison program adapted for a zero-knowledge proving scheme (e.g., a comparison arithmetic circuit C) and a proving key associated with the comparison program adapted for the zero-knowledge proving scheme (e.g., Pkc). In an embodiment, peers implementing the distributed ledger verify the zero-knowledge proof using a verifying key associated with the comparison program adapted for the zero-knowledge proving scheme (e.g., Vkc). In an embodiment, a public input of the comparison program adapted for the zero-knowledge proving scheme includes the first commitment value and the second commitment value, wherein a private input of the comparison program adapted for the zeroknowledge proving scheme includes the grade of the first offer, the grade of the second offer, the first value (that was used to generate the first commitment value), and a value used to generate the second commitment value.

[00123] In an embodiment, the one or more network devices causes one or more other zeroknowledge proofs to be generated and submitted to the distributed ledger for verification and publication, wherein the zero-knowledge proofs collectively prove that the first offer is a winning offer (and in some embodiments prove a grade ordering of offers submitted responsive to the tender request).

[00124] Figure 4 is a flow diagram of a method for implementing service provider-side operations of a privacy-preserving tender process, according to some embodiments. [00125] At block 405, the one or more network devices obtain a grading function associated with the tender request.

[00126] At block 410, the one or more network devices generate an offer that is responsive to the tender request.

[00127] At block 415, the one or more network devices generate one or more zero-knowledge proofs (e.g., PJ) proving that the service provider knows the offer, a first value (e.g., r) used to generate a first commitment value (e.g., cP) corresponding to a grade of the offer, a serial number associated with the offer (e.g., serial number sn), and a second value (e.g., s) used to generate a second commitment value (e g., c2) corresponding to the serial number.

[00128] At block 420, the one or more network devices submit the one or more zeroknowledge proofs to the distributed ledger for verification and publication. In an embodiment, the one or more zero-knowledge proofs is a single first zero-knowledge proof that is generated based on a grading program adapted for a zero-knowledge proving scheme (e.g., a grading arithmetic circuit G) and a proving key associated with the grading program adapted for the zero-knowledge proving scheme (e.g., Pkg). In an embodiment, a private input of the grading program adapted for the zero-knowledge proving scheme includes the offer (e.g., offer O), the serial number, the first value, and the second value, wherein a public output of the grading program adapted for the zero-knowledge proving scheme includes the first commitment value and the second commitment value. In an embodiment, peers implementing the distributed ledger verify the first zero-knowledge proof using a verifying key associated with the grading program adapted for the zero-knowledge proving scheme (Pkg). In an embodiment, the zeroknowledge proving scheme is ZK-SNARK and the grading program adapted for the zeroknowledge proving scheme is an arithmetic circuit.

[00129] At block 425, the one or more network devices generate an encrypted message that includes the grade of the offer.

[00130] At block 430, the one or more network devices provide the encrypted message to the tenant.

[00131] At decision block 435, the one or more network devices determine whether the service provider submitted the winning offer of the tender. If not, the process may end. Otherwise, if the service provider submitted the winning offer, then the process moves to the operation of block 440.

[00132] At block 440, the one or more network devices generate a second zero-knowledge proof (e.g., P3) disclosing the serial number (e.g., serial number sn) and proving that the service provider knows the serial number and the second value (e.g., 5). In an embodiment, the second zero-knowledge proof is generated based on a winning offer verification program adapted for the zero-knowledge proving scheme (e.g., winning offer verification arithmetic circuit S) and a proving key associated with the winning offer verification program adapted for the zeroknowledge proving scheme (e.g., Pks). In an embodiment, a public input of the winning offer verification program adapted for the zero-knowledge proving scheme includes the serial number, wherein a private input of the winning offer verification program adapted for the zeroknowledge proving scheme includes the second value

[00133] At block 445, the one or more network devices submit the second zero-knowledge proof to the distributed ledger for verification and publication. In an embodiment, peers implementing the distributed ledger verify the second zero-knowledge proof using a verifying key associated with the winning offer verification program adapted for the zero-knowledge proving scheme (e.g., Vks).

[00134] At block 450, the one or more network devices submit a service contract and the first value to the distributed ledger, wherein peers implementing the distributed ledger use the first value to verify that a grade of the service contract matches the grade of the offer and that the service contract is submitted by a winner of the tender request. In an embodiment, the peers implementing the distributed ledger verify that the grade of the service contract matches the grade of the offer based on using the first value to generate a third commitment value corresponding to a grade of the service contract and determining whether the third commitment value matches the first commitment value.

[00135] Figure 5A illustrates connectivity between network devices (NDs) within an exemplary network, as well as three exemplary implementations of the NDs, according to some embodiments. Figure 5A shows NDs 500A-H, and their connectivity by way of lines between 500A-500B, 500B-500C, 500C-500D, 500D-500E, 500E-500F, 500F-500G, and 500A-500G, as well as between 500H and each of 500A, 500C, 500D, and 500G. These NDs are physical devices, and the connectivity between these NDs can be wireless or wired (often referred to as a link). An additional line extending from NDs 500A, 500E, and 500F illustrates that these NDs act as ingress and egress points for the network (and thus, these NDs are sometimes referred to as edge NDs; while the other NDs may be called core NDs).

[00136] Two of the exemplary ND implementations in Figure 5A are: 1) a special-purpose network device 502 that uses custom application-specific integrated-circuits (ASICs) and a special-purpose operating system (OS); and 2) a general-purpose network device 504 that uses common off-the-shelf (COTS) processors and a standard OS.

[00137] The special-purpose network device 502 includes networking hardware 510 comprising a set of one or more processor(s) 512, forwarding resource(s) 514 (which typically include one or more ASICs and/or network processors), and physical network interfaces (NIs) 516 (through which network connections are made, such as those shown by the connectivity between NDs 500A-H), as well as non-transitory machine-readable storage media 518 having stored therein networking software 520. During operation, the networking software 520 may be executed by the networking hardware 510 to instantiate a set of one or more networking software instance(s) 522. Each of the networking software instance(s) 522, and that part of the networking hardware 510 that executes that network software instance (be it hardware dedicated to that networking software instance and/or time slices of hardware temporally shared by that networking software instance with others of the networking software instance(s) 522), form a separate virtual network element 530A-R. Each of the virtual network element(s) (VNEs) 530A-R includes a control communication and configuration module 532A- R (sometimes referred to as a local control module or control communication module) and forwarding table(s) 534A-R, such that a given virtual network element (e.g., 530A) includes the control communication and configuration module (e.g., 532A), a set of one or more forwarding table(s) (e.g., 534A), and that portion of the networking hardware 510 that executes the virtual network element (e.g., 530A).

[00138] In one embodiment software 520 includes code such as privacy-preserving tender process component 523, which when executed by networking hardware 510, causes the specialpurpose network device 502 to perform operations of one or more embodiments as part of networking software instances 522 (e.g., to implement a privacy-preserving tender process). [00139] The special-purpose network device 502 is often physically and/or logically considered to include: 1) a ND control plane 524 (sometimes referred to as a control plane) comprising the processor(s) 512 that execute the control communication and configuration module(s) 532A-R; and 2) a ND forwarding plane 526 (sometimes referred to as a forwarding plane, a data plane, or a media plane) comprising the forwarding resource(s) 514 that utilize the forwarding table(s) 534A-R and the physical NIs 516. By way of example, where the ND is a router (or is implementing routing functionality), the ND control plane 524 (the processor(s) 512 executing the control communication and configuration module(s) 532A-R) is typically responsible for participating in controlling how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing physical NI for that data) and storing that routing information in the forwarding table(s) 534A-R, and the ND forwarding plane 526 is responsible for receiving that data on the physical NIs 516 and forwarding that data out the appropriate ones of the physical NIs 516 based on the forwarding table(s) 534A-R.

[00140] Figure 5B illustrates an exemplary way to implement the special-purpose network device 502, according to some embodiments. Figure 5B shows a special-purpose network device including cards 538 (typically hot pluggable). While in some embodiments the cards 538 are of two types (one or more that operate as the ND forwarding plane 526 (sometimes called line cards), and one or more that operate to implement the ND control plane 524 (sometimes called control cards)), alternative embodiments may combine functionality onto a single card and/or include additional card types (e.g., one additional type of card is called a service card, resource card, or multi-application card). A service card can provide specialized processing (e.g., Layer 4 to Layer 7 services (e.g., firewall, Internet Protocol Security (IPsec), Secure Sockets Layer (SSL) / Transport Layer Security (TLS), Intrusion Detection System (IDS), peer-to-peer (P2P), Voice over IP (VoIP) Session Border Controller, Mobile Wireless Gateways (Gateway General Packet Radio Service (GPRS) Support Node (GGSN), Evolved Packet Core (EPC) Gateway)). By way of example, a service card may be used to terminate IPsec tunnels and execute the attendant authentication and encryption algorithms. These cards are coupled together through one or more interconnect mechanisms illustrated as backplane 536 (e.g., a first full mesh coupling the line cards and a second full mesh coupling all of the cards).

[00141] Returning to Figure 5A, the general-purpose network device 504 includes hardware 540 comprising a set of one or more processor(s) 542 (which are often COTS processors) and physical NIs 546, as well as non-transitory machine readable storage media 548 having stored therein software 550. During operation, the processor(s) 542 execute the software 550 to instantiate one or more sets of one or more applications 564A-R. While one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization. For example, in one such alternative embodiment the virtualization layer 554 represents the kernel of an operating system (or a shim executing on a base operating system) that allows for the creation of multiple instances 562A-R called software containers that may each be used to execute one (or more) of the sets of applications 564A-R; where the multiple software containers (also called virtualization engines, virtual private servers, or jails) are user spaces (typically a virtual memory space) that are separate from each other and separate from the kernel space in which the operating system is run; and where the set of applications running in a given user space, unless explicitly allowed, cannot access the memory of the other processes. In another such alternative embodiment the virtualization layer 554 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and each of the sets of applications 564A-R is run on top of a guest operating system within an instance 562A-R called a virtual machine (which may in some cases be considered a tightly isolated form of software container) that is run on top of the hypervisor - the guest operating system and application may not know they are running on a virtual machine as opposed to running on a “bare metal” host electronic device, or through para-virtualization the operating system and/or application may be aware of the presence of virtualization for optimization purposes. In yet other alternative embodiments, one, some or all of the applications are implemented as unikemel(s), which can be generated by compiling directly with an application only a limited set of libraries (e.g., from a library operating system (LibOS) including drivers/libraries of OS services) that provide the particular OS services needed by the application. As a unikernel can be implemented to run directly on hardware 540, directly on a hypervisor (in which case the unikemel is sometimes described as running within a LibOS virtual machine), or in a software container, embodiments can be implemented fully with unikemels running directly on a hypervisor represented by virtualization layer 554, unikemels running within software containers represented by instances 562A-R, or as a combination of unikemels and the above-described techniques (e.g., unikemels and virtual machines both run directly on a hypervisor, unikemels and sets of applications that are run in different software containers).

[00142] The instantiation of the one or more sets of one or more applications 564A-R, as well as virtualization if implemented, are collectively referred to as software instance(s) 552. Each set of applications 564A-R, corresponding virtualization construct (e.g., instance 562A-R) if implemented, and that part of the hardware 540 that executes them (be it hardware dedicated to that execution and/or time slices of hardware temporally shared), forms a separate virtual network element(s) 560A-R.

[00143] The virtual network element(s) 560A-R perform similar functionality to the virtual network element(s) 530A-R - e.g., similar to the control communication and configuration module(s) 532A and forwarding table(s) 534A (this virtualization of the hardware 540 is sometimes referred to as network function virtualization (NFV)). Thus, NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which could be located in Data centers, NDs, and customer premise equipment (CPE). While embodiments are illustrated with each instance 562A-R corresponding to one VNE 560A-R, alternative embodiments may implement this correspondence at a finer level granularity (e.g., line card virtual machines virtualize line cards, control card virtual machine virtualize control cards, etc.); it should be understood that the techniques described herein with reference to a correspondence of instances 562A-R to VNEs also apply to embodiments where such a finer level of granularity and/or unikemels are used. [00144] In certain embodiments, the virtualization layer 554 includes a virtual switch that provides similar forwarding services as a physical Ethernet switch. Specifically, this virtual switch forwards traffic between instances 562A-R and the physical NI(s) 546, as well as optionally between the instances 562A-R; in addition, this virtual switch may enforce network isolation between the VNEs 560A-R that by policy are not permitted to communicate with each other (e g., by honoring virtual local area networks (VLANs)).

[00145] In one embodiment, software 550 includes a privacy-preserving tender process component 553, which when executed by processor(s) 542, causes the general-purpose network device 504 to perform operations of one or more embodiments as part of software instances 562A-R (e g., to implement a privacy-preserving tender process).

[00146] The third exemplary ND implementation in Figure 5A is a hybrid network device 506, which includes both custom ASICs/special-purpose OS and COTS processors/standard OS in a single ND or a single card within an ND. In certain embodiments of such a hybrid network device, a platform VM (i.e., a VM that that implements the functionality of the special-purpose network device 502) could provide for para-virtualization to the networking hardware present in the hybrid network device 506.

[00147] A network interface (NI) may be physical or virtual; and in the context of IP, an interface address is an IP address assigned to a NI, be it a physical NI or virtual NI. A virtual NI may be associated with a physical NI, with another virtual interface, or stand on its own (e.g., a loopback interface, a point-to-point protocol interface). A NI (physical or virtual) may be numbered (a NI with an IP address) or unnumbered (a NI without an IP address). A loopback interface (and its loopback address) is a specific type of virtual NI (and IP address) of a NE/VNE (physical or virtual) often used for management purposes; where such an IP address is referred to as the nodal loopback address. The IP address(es) assigned to the NI(s) of a ND are referred to as IP addresses of that ND; at a more granular level, the IP address(es) assigned to NI(s) assigned to a NE/VNE implemented on a ND can be referred to as IP addresses of that NE/VNE.

[00148] Some portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of transactions on data bits within a computer memory. These algorithmic descriptions and representations are the ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consi stent sequence of transactions leading to a desired result. The transactions are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. [00149] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[00150] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method transactions. The required structure for a variety of these systems will appear from the description above. In addition, embodiments are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of embodiments as described herein.

[00151] An embodiment may be an article of manufacture in which a non-transitory machine- readable storage medium (such as microelectronic memory) has stored thereon instructions (e.g., computer code) which program one or more data processing components (generically referred to here as a “processor”) to perform the operations described above. In other embodiments, some of these operations might be performed by specific hardware components that contain hardwired logic (e.g., dedicated digital filter blocks and state machines). Those operations might alternatively be performed by any combination of programmed data processing components and fixed hardwired circuit components.

[00152] Throughout the description, embodiments have been presented through flow diagrams. It will be appreciated that the order of transactions and transactions described in these flow diagrams are only intended for illustrative purposes and not intended as a limitation of the present invention. One having ordinary skill in the art would recognize that variations can be made to the flow diagrams without departing from the broader spirit and scope of the invention as set forth in the following claims.

[00153] In the foregoing specification, embodiments have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Claims

CLAIMS What is claimed is:

1. A method performed by one or more network devices communicatively coupled to a distributed ledger to submit a tender request of a tenant and compare offers submitted by service providers responsive to the tender request in a verifiable manner without publicly disclosing details of the offers, the method comprising: submitting (310) the tender request to the distributed ledger, wherein the tender request is associated with a grading function for grading offers submitted responsive to the tender request; obtaining (320) a first commitment value corresponding to a grade of a first offer submitted by a first service provider and an encrypted message that includes the grade of the first offer; decrypting (340) the encrypted message to obtain the grade of the first offer; and causing (350) a first zero-knowledge proof to be generated proving that the grade of the first offer is higher than a grade of a second offer submitted by a second service provider, which includes proving that the first commitment value corresponds to the grade of the first offer and a second commitment value corresponds to the grade of the second offer, wherein the first zero-knowledge proof is submitted to the distributed ledger for verification and publication.

2. The method of claim 1, wherein the tender request includes a grading program adapted for a zero-knowledge proving scheme, a proving key associated with the grading program adapted for the zero-knowledge proving scheme, and a verifying key associated with the grading program adapted for the zero-knowledge proving scheme.

3. The method of claim 2, wherein the first commitment value is generated as a public output of the grading program adapted for the zero-knowledge proving scheme.

4. The method of claim 1, wherein the distributed ledger stores one or more zeroknowledge proofs proving that the first service provider knows the first offer, a first value used to generate the first commitment value, a serial number associated with the first offer, and a second value used to generate a third commitment value corresponding to the serial number.

5. The method of claim 1, wherein the first zero-knowledge proof is generated based on a comparison program adapted for a zero-knowledge proving scheme and a proving key associated with the comparison program adapted for the zero-knowledge proving scheme.

6. The method of claim 5, wherein peers implementing the distributed ledger verify the first zero-knowledge proof using a verifying key associated with the comparison program adapted for the zero-knowledge proving scheme.

7. The method of claim 5, wherein a public input of the comparison program adapted for the zero-knowledge proving scheme includes the first commitment value and the second commitment value, wherein a private input of the comparison program adapted for the zeroknowledge proving scheme includes the grade of the first offer and the grade of the second offer.

8. The method of claim 1, further comprising: causing one or more other zero-knowledge proofs to be generated and submitted to the distributed ledger for verification and publication, wherein the first zeroknowledge proof and the one or more other zero-knowledge proofs collectively prove that the first offer is a winning offer.

9. The method of claim 5, wherein the zero-knowledge proving scheme is zero-knowledge succinct non-interactive argument of knowledge (ZK-SNARK) and the comparison program adapted for the zero-knowledge proving scheme is an arithmetic circuit.

10. A method performed by one or more network devices communicatively coupled to a distributed ledger to submit an offer of a service provider responsive to a tender request of a tenant in a binding manner without publicly disclosing details of the offer, the method comprising: obtaining (405) a grading function associated with the tender request; generating (410) an offer that is responsive to the tender request; generating (415) one or more zero-knowledge proofs proving that the service provider knows the offer, a first value used to generate a first commitment value corresponding to a grade of the offer, a serial number associated with the offer, and a second value used to generate a second commitment value corresponding to the serial number; submitting (420) the one or more zero-knowledge proofs to the distributed ledger for verification and publication; generating (425) an encrypted message that includes the grade of the offer; and providing (430) the encrypted message to the tenant.

11. The method of claim 10, wherein the one or more zero-knowledge proofs is a single first zero-knowledge proof that is generated based on a grading program adapted for a zero- knowledge proving scheme and a proving key associated with the grading program adapted for the zero-knowledge proving scheme.

12. The method of claim 11, wherein a private input of the grading program adapted for the zero-knowledge proving scheme includes the offer, the serial number, the first value, and the second value, wherein a public output of the grading program adapted for the zero-knowledge proving scheme includes the first commitment value and the second commitment value.

13. The method of claim 11, wherein peers implementing the distributed ledger verify the first zero-knowledge proof using a verifying key associated with the grading program adapted for the zero-knowledge proving scheme.

14. The method of claim 11, wherein the zero-knowledge proving scheme is zero-knowledge succinct non-interactive argument of knowledge (ZK- SNARK) and the grading program adapted for the zero-knowledge proving scheme is an arithmetic circuit.

15. The method of claim 10, further comprising: responsive to a determination (435) that the offer is a winning offer of the tender request: generating (440) a second zero-knowledge proof disclosing the serial number and proving that the service provider knows the serial number and the second value; submitting (445) the second zero-knowledge proof to the distributed ledger for verification and publication; and submitting (450) a service contract and the first value to the distributed ledger, wherein peers implementing the distributed ledger use the first value to verify that a grade of the service contract matches the grade of the offer and that the service contract is submitted by a winner of the tender request.

16. The method of claim 15, wherein the second zero-knowledge proof is generated based on a winning offer verification program adapted for the zero-knowledge proving scheme and a proving key associated with the winning offer verification program adapted for the zeroknowledge proving scheme.

17. The method of claim 16, wherein a public input of the winning offer verification program adapted for the zero-knowledge proving scheme includes the serial number, wherein a private input of the winning offer verification program adapted for the zero-knowledge proving scheme includes the second value.

18. The method of claim 16, wherein peers implementing the distributed ledger verify the second zero-knowledge proof using a verifying key associated with the winning offer verification program adapted for the zero-knowledge proving scheme.

19. The method of claim 15, wherein the peers implementing the distributed ledger verify that the grade of the service contract matches the grade of the offer based on using the first value to generate a third commitment value corresponding to a grade of the service contract and determining whether the third commitment value matches the first commitment value.

20. A set of non-transitory machine-readable media having computer code stored therein, which when executed by a set of one or more processors of one or more network devices communicatively coupled to a distributed ledger, causes the one or more network devices to perform operations for submitting a tender request of a tenant and comparing offers submitted by service providers responsive to the tender request in a verifiable manner without publicly disclosing details of the offers, the operations comprising: submitting (310) the tender request to the distributed ledger, wherein the tender request is associated with a grading function for grading offers submitted responsive to the tender request; obtaining (320) a first commitment value corresponding to a grade of a first offer submitted by a first service provider and an encrypted message that includes the grade of the first offer; decrypting (340) the encrypted message to obtain the grade of the first offer; and causing (350) a first zero-knowledge proof to be generated proving that the grade of the first offer is higher than a grade of a second offer submitted by a second service provider, which includes proving that the first commitment value corresponds to the grade of the first offer and a second commitment value corresponds to the grade of the second offer, wherein the first zero-knowledge proof is submitted to the distributed ledger for verification and publication.

21. The set of non-transitory machine-readable media of claim 20, wherein the operations further comprise: causing one or more other zero-knowledge proofs to be generated and submitted to the distributed ledger for verification and publication, wherein the first zero- knowledge proof and the one or more other zero-knowledge proofs collectively prove that the first offer is a winning offer.

22. A set of non-transitory machine-readable media having computer code stored therein, which when executed by a set of one or more processors of one or more network devices communicatively coupled to a distributed ledger, causes the one or more network devices to perform operations for submitting an offer of a service provider responsive to a tender request of a tenant in a binding manner without publicly disclosing details of the offer, the operations comprising: obtaining (405) a grading function associated with the tender request; generating (410) an offer that is responsive to the tender request; generating (415) one or more zero-knowledge proofs proving that the service provider knows the offer, a first value used to generate a first commitment value corresponding to a grade of the offer, a serial number associated with the offer, and a second value used to generate a second commitment value corresponding to the serial number; submitting (420) the one or more zero-knowledge proofs to the distributed ledger for verification and publication; generating (425) an encrypted message that includes the grade of the offer; and providing (430) the encrypted message to the tenant.

23. The set of non-transitory machine-readable media of claim 22, wherein the operations further comprise: responsive to a determination (435) that the offer is a winning offer of the tender request: generating (440) a second zero-knowledge proof disclosing the serial number and proving that the service provider knows the serial number and the second value; submitting (445) the second zero-knowledge proof to the distributed ledger for verification and publication; and submitting (450) a service contract and the first value to the distributed ledger, wherein peers implementing the distributed ledger use the first value to verify that a grade of the service contract matches the grade of the offer and that the service contract is submitted by a winner of the tender request.