WO2021211769A1 - Systems and methods for secure and correct computations - Google Patents

Abstract

The present disclosure provides a method of determining at least one global skyline object. The method includes generating a first set of one or more dominant object sums for a first party including a first local object, the first local object including at least one element, generating a second set of one or more dominant object sums for a second party including a second local object, the second local object including at least one element, generating a first random integer for the first party, determining how many elements included in the second local object dominate each element of the first local object based on the first random integer, and determining at least one element included in the first local object that is a globally dominant element.

Description

SYSTEMS AND METHODS FOR SECURE AND CORRECT COMPUTATIONS

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of priority to U.S. Provisional Patent Application No. 63/009,905, filed April 14, 2020, the contents of which are incorporated herein by reference in its entirety.

BACKGROUND

[0002] Certain computations require proof of computation and proof of encryption. In other words, certain computations require verification that the computation is performed correctly, and that no information has been leaked during the calculation. For example, certain financial computations, such as portfolio margin calculations, may require proof of computation and proof of encryption.

[0003] While certain techniques exist to provide proof of computation and proof of encryption for computations, they incur a significant performance cost, such as communication and computation overhead. The Skyline protocol commonly used to identify the most likely correct result obtained from computing on encrypted data can be usefully deployed in consensus validation systems, but its operation incurs a significant performance cost, both from a communication and computation overhead. Systems and methods for providing performance-efficient computations with proof of computation and proof of encryption are therefore desired.

SUMMARY

[0004] The disclosure addresses the need for performance-efficient computations with proof of computation and proof of encryption.

[0005] In some embodiments, the present disclosure provides a method of determining at least one global skyline object. The method includes generating a first set of one or more dominant object sums for a first party including a first local object, the first local object including at least one element, generating a second set of one or more dominant object sums for a second party including a second local object, the second local object including at least one element, generating a first random integer for the first party, determining how many elements included in the second local object dominate each element of the first local object based on the first random integer, and determining at least one element included in the first local object that is a globally dominant element.

[0006] In some embodiments, the generating a first set of one or more dominant object sums for a first party comprises: determining, for an element pair comprising a first local object and a second local object, whether an element in the first local object dominates an element in the second local object using a secure dominance comparison (SDC) protocol.

[0007] In some embodiments, the SDC protocol comprises: generating two duplicates of each of an encrypted first object element and an encrypted second object element, each of the duplicates having a length 2D.

[0008] In some embodiments, the SDC protocol comprises: generating two complimentary binary vectors of length 2D.

[0009] In some embodiments, the SDC protocol comprises: generating two random binary vectors of length 2D.

[0010] In some embodiments, the SDC protocol comprises: swapping elements of the duplicates based on values included in the two random binary vectors.

[0011] In some embodiments, the SDC protocol comprises: generating two supplemental vectors of length 2D based on the two complimentary binary vectors and the two random binary vectors.

[0012] In some embodiments, the SDC protocol comprises: generating four vectors of length D.

[0013] In some embodiments, the SDC protocol comprises: generating two supplemental vectors of length D based on a comparison of corresponding values in two vectors included in the four vectors of length D. [0014] In some embodiments, the SDC protocol comprises: encrypting the two supplemental vectors of length D.

[0015] In some embodiments, the SDC protocol comprises: generating four vectors of length 3D.

[0016] In some embodiments, the SDC protocol comprises: generating two hybrid vectors based on the two supplemental vectors of length D and the two supplemental vectors of length 2D.

[0017] In some embodiments, the SDC protocol comprises: encrypting the four vectors of length 3D.

[0018] In some embodiments, the SDC protocol comprises: generating hash values based on the two hybrid vectors using a hashing function.

[0019] In some embodiments, the SDC protocol comprises: decrypting the four vectors of length 3D.

[0020] In some embodiments, the SDC protocol comprises: generating two binary vectors of length 3D based on the decrypted four vectors of length 3D.

[0021] In some embodiments, the SDC protocol comprises: identifying which of the first object element and the second object element is dominant based at least in part on the hash values.

[0022] In some embodiments, the method further comprises: randomly choosing to evaluate whether the element in the first local object dominates the element in the second local object or whether the element in the second local object dominates the element in the first local object.

[0023] In some embodiments, the method further comprises: generating a first dominant objects counter associated with the first party and a second dominant objects counter set associated with the second party.

[0024] In some embodiments, the method further comprises: in response to determining that the element in the second local object dominates the element in the first local object, incrementing a counter included in the first dominant objects counter set that is associated with the element in the first local object.

[0025] In some embodiments, the method further comprises: encrypting the first dominant objects counter set.

[0026] In some embodiments, the method further comprises: decrypting the first dominant objects counter set to determine dominant Skyline objects in the first party.

[0027] In some embodiments, the method further comprises: encrypting the first objects counter set based on a first public key associated with the first party.

[0028] In some embodiments, the at least one global skyline object comprises data associated with at least one of a portfolio risk metric or final margin calculations.

[0029] In some embodiments, the portfolio risk metric comprises at least one of equity, liability, margin usage, or value at risk.

[0030] In some embodiments, the method further comprises: the at least one global skyline object comprises data associated with a credit risk metric.

[0031] In some embodiments, the method further comprises: the credit risk metric is a counterparty credit risk.

[0032] In some embodiments, the method further comprises: the first random integer is a thirty -two bit integer.

BRIEF DESCRIPTION OF THE DRAWINGS

[0033] FIG. 1 is an example embodiment of a computation system.

[0034] FIG. 2 is a state diagram of an example implementation of a portion of a skyline protocol.

[0035] FIG. 3 is a flowchart of an exemplary process for implementing a multi-party secure skyline protocol. [0036] FIG. 4 is a flowchart of an exemplary process for implementing a secure dominance comparison protocol.

[0037] FIG. 5 is a flowchart of an exemplary process for implementing a dominant objects counter protocol.

[0038] FIG. 6 is a diagram of an example computing architecture implementing the computation system of FIG. 1.

DETAILED DESCRIPTION

[0039] The present disclosure provides systems and methods for provably secure and correct execution of certain financial computations, without leakage of any private information, including the representation of the computation itself. In particular, the disclosure provides a zero-knowledge architecture that, upon performing computations on private data within multiple secure computing environments (e.g., Intel SGX enclaves, as described further below), produces both proof of computation and proof of encryption. The system's proof of computation verifies that compute resources executing the computation are producing the expected results; and, the system's proof of encryption verifies that no information associated with the input data, the computation(s), or the output data (i.e., results) is leaked. The present systems and methods provide privacy preserving computation, provably secure and correct, at a speed that is faster than comparable currently available infrastructure.

[0040] Referring to FIG. 1, an example embodiment of a computation system 100 in accordance with the present disclosure can be a financial computation system, such as a margin trading system, and/or a system to disintermediate credit provision. Generally, the system 100 can be any computation system in which security of the data is a priority, and thus the computing resources that operate on the data must do so while the data is encrypted, without decrypting the data except for in provably secure enclave functions such as SGX terminated TLS operations. Furthermore, the system 100 can be any computation system in which the users of the system must be able to confirm that the computing resources are producing accurate, properly encrypted output data. Finally, the system 100 can be any computation system in which the operations performed by the computing resources include computations (e.g., formulae; algorithms, etc.) that are openly accessible, accessible by a permissioned group, and/or that are themselves secret and cannot be disclosed to the users. Thus, the system 100 can receive encrypted data as inputs, perform secure computations on the inputs to produce encrypted output data, and generate proofs of both accurate computation (i.e., that the output is correct) and intact encryption, and provide the output data and the proofs to the proper recipient without revealing any information about the inputs themselves or the computations themselves.

[0041] In some embodiments, the system 100 can include a processor and a memory (not shown). In some embodiments, the processor can be any suitable hardware processor or combination of processors, such as a CPU and/or a GPU. In some embodiments, the memory can include any suitable volatile memory, non-volatile memory, storage, or any suitable combination thereof. For example, the memory can include RAM, ROM, EEPROM, one or more flash drives, one or more hard disks, one or more solid state drives, one or more optical drives, etc.

[0042] In FIG. 1, "D_from:to" denotes a flow of data from one portion to another, and "C module" denotes calculations in a module.

[0043] In some embodiments, the system 100 can allow multiple counterparties to offer portfolio margin to each other, without knowing any private data of each other that could be maliciously used, provide a regulatorily light technique of doing so (without needing a central clearer), and/or provide a robust audit trail to allow traders to resolve disputes bilaterally. In some embodiments, the system 100 can allow real-time credit risk scoring while preserving the privacy of sensitive trade and position information across counterparties.

[0044] The system 100 can include a zero knowledge module 144 implementing a secure computing environment on one or more special-purpose secure computing servers, a centralized or decentralized computing cluster, a distributed network of servers or personal computing devices each operating as a node 152 in the network, or another suitable computing architecture. In some embodiments, the zero knowledge module 144 can include a plurality of hardware-based and/or software-based private computing environments that isolate instances of application code and/or private data from processes executing outside of the private computing environment. For example, the private computing environments may comprise enclaves 148, 156 implemented with Intel Software Guard Extensions ("SGX") to encrypt and allocate regions of computer memory with hardware-based controls. Each enclave, for example a first enclave 148, can include a number of nodes 152. Computing resources of the zero-knowledge environment 144 can perform one or more computations using encrypted private data, and optionally also encrypted or non-encrypted public data, as inputs; outputs of the computations are also encrypted, and the computing resources further can apply the protocols described herein to produce proof of computation and proof of encryption. The zero knowledge (ZK) module 144 will be explained below.

[0045] The system 100 can further include a data management (DM) module 104 comprising a set of real-time and historical databases, analytics, event processors and interfaces to external modules. The DM module 104 can include a public data module 116 and a private data module 108 for a number of user instances 110, 112. The DM module 104 can aggregate and normalize public data, lower the computational workload for a ZK module 144, and provide an audit trail and replay functionality to resolve disagreements amongst counterparties.

[0046] The public data module 116 can include public data and analytics performed on that public data. The public data module 116 can receive data from feed handlers included in a market data feeds module 120 that can push real-time market data from exchanges to databases and real time analytics engine. The market data feeds module 120 can be implemented as a set of feed handlers (e.g. FIX adapters). The feeds can include all the data required to price and compute risk dimensions for arbitrary derivatives contracts. Feeding this data to each node 152 (not in a secure enclave) to be called upon by a secure enclave when required, can greatly reduce computational burdens within each secure enclave 148, 156. The goal is to have the secure enclaves only perform computations - or parts of computations - that need to be secure, leaving those computations that do not require security or privacy to be performed outside any secure enclave. In one embodiment, any nodes 152, or a frontend server of the ZK module 144, can receive input data such as feeds and DM public data, identify the data elements that are secure and separate them from the not- secure elements, and send secure data to secure enclaves and not-secure data to nodes 152 that are not in a secure enclave.

[0047] The private data module 108 can include a number of user instances 110, 112 that are segregated by user. The user instances 110, 112 can contain only data specific to the individual users. From the user’s perspective, a user instance (e.g., user instance 110) is a read-only database used for audit trail. In the system 100, the user instance can be a way to increase security and privacy by segregating data and feeds peruser. In some embodiments, the private data module 108 can operate on semi-private data. For example, in some embodiments, sensitive data such as trader positions, greeks and position sensitivity can only be processed in the ZK module 144. The private data module 108, on the other hand, can process data derived from the ZK module 144, such as the first derivative of the margin calculation and profit and loss (P&L). Thus, the private data module 108 can approximate changes in margin usage on a tick-by-tick basis, and probable signal breaches and other events to a custodian computing environment 124 in real-time as they happen.

[0048] The system 100 can further include one or more encryption clients 132, 140 installed in computing resources of entities participating in the system 100, in order to encrypt data to be used as inputs in the ZK module 144 and send the encrypted data to the ZK module 144. For example, a system 100 user may have an account with a custodian, and may be enabled to access the custodian's computing environment 124 via an application programming interface (API) 128. In some embodiments interactions with the API 128 can be done over two-way communication, but at least the API 128 enables the system 100 to send user-centric inputs, such as login information and account management commands, into the custodian computing environment 124. In some embodiments, the DM module 104 can call a set of remote procedure calls in order to directly reserve and release funds, and effectively freeze trading and withdrawal in case of adverse events such as flash crashes. In some embodiments, an encryption client 132 can be installed in the custodian computing environment 124 to encrypt private data of the user. The ZK module 144 can subscribe to balance data updates ("D cusfzk") for a given user, and the encryption client 132 can encrypt and send the balance data and other user data. In some embodiments, the system 100 can publish credit scores for lenders to use, or margin usage and settlement instructions to the custodian module 124 via an auditable database 108 included in the DM module 104. In some embodiments, the system 100 can include a SGX terminated TLS operation 160 (e.g., which can replace the encryption client 132), and can provide encrypted data to the ZK module 144. In this way, the SGX terminated TLS operation can remove the need for a dedicated encryption client. [0049] In some embodiments, the system 100 can also include an encryption client 140 installed in a trading venue computing environment 136. The encryption client encrypts and publishes trade and position data, which may be formatted in JSON format, to the ZK module 144. The trading venue module 136 can receive balance data from the API 128. In some embodiments, the system 100 can include a SGX terminated TLS operation 164 (e.g., which can replace the encryption client 140).

[0050] In some embodiments, the ZK module 144 can be implemented as a protocol implemented on top of Intel SGX, and combine a proof of computation protocol along with a Sigma protocol to provide fast, provably secure and correct computation within a secure enclave (.g., enclave 148). Example of the proof of computation protocol and the Sigma protocol are described below.

[0051] The ZK module 144 can implement a configurable consensus mechanism to validate outputs, and balance between computational burden of verification versus security and accuracy of outputs. Moreover, aside from fast verification of computation within a node, using vector clocks ensures that synchronization costs are also negligible across nodes held in different cloud servers.

[0052] Nodes can jointly perform the same tasks for consensus, but separate quora of nodes can also perform different orthogonal tasks for parallelization. The nodes can subscribe to market data updates and model data from the DM module 104, as well as encrypted position data from the trading venue module 136. Based on this information, the system 100 can compute risk dimensions, mark-to-market values of trades between counterparties, and/or a verifiably secure margin usage number.

[0053] This derived data is in turn processed by the private data module 108, where portfolio risk metrics (e.g., equity, liability, margin usage, Value at Risk (VaR), and/or other suitable metrics) to facilitate credit and/or or the final margin calculations, can be updated in real time. Furthermore, alerts on risk metrics such as solvency and/or leverage ratios and/or settlement instructions based on margin calculations can be computed. The data can be published over a network protocol that communicates directly with individual DM processes. In other words, an update for a given user will be published to that user’s private DM instance (e.g., the user instances 110, 112). In some embodiments, the system 100 can be used in performing computations on healthcare data without exposing any private health information (PHI). Finally, it can be used to perform virus scans of binary application code without exposing the set of signatures scanned. In some embodiments, the system 100 can be used to detect and/or filter the sending of illegal images on end-to-end encrypted messaging platforms. In these embodiments, received image files can be compared against a table of known illegal images, and blocked if a match is found.

[0054] The ZK module 144 can implement an encryption protocol. Fully homomorphic encryption (FHE) schemes can provide the strongest security layer for enabling arbitrary computations on encrypted data. However, FHE is not practical due to the computational burden. Thus, the ZK module 144 can implement partially homomorphic encryption, as partially homomorphic encryption is much more efficient than FHE.

[0055] The skyline protocol is a zero-knowledge proof process that is built up over time as an iterative, cumulative challenge-and-response protocol, in which each computational step concatenates a proof of the current step to the already existing proof of computation for all previous steps. So, for example, when computing Ax + B (where A and B are unchanging parameters, and x is secure data), a proof is constructed of A and B, then a partial proof of x is constructed (i.e. prove coming from trusted source, check timestamp, unique identifier, valid encryption connection with specified encryption method), then a proof of each computation is constructed (e.g. Ax, then Ax + B).

[0056] In essence, the skyline protocol can verify that the computation within a secure enclave is doing what is expected, and can generate proof that the data is encrypted, and there has been no leakage, including the representation itself.

[0057] FIG. 2 is a state diagram of an example implementation of a portion of a skyline protocol. Consider an authorized client 212 (e.g., a physician) who wishes to query the skyline tuples corresponding to query tuple q = (q [1], ..., q [m]) . As shown in FIG. 2, in order to protect the sensitive query tuple, the client uses the same public key pk to encrypt the query tuple and sends Epk(q) = (Epk(q[l]), .. .,Epk(q[m])) to a cloud server Cl 204. [0058] Referring to both FIG. 1 and FIG. 2, the system 100 can allow the cloud server Cl 204 to compute and return the skyline to the client 212 without learning any information about the data and the query. In addition to guaranteeing the correctness of the result and the efficiency of the computation, the computation should require no or minimal interaction from the client or a data owner 216 for practicality. To achieve this, the system 100 can assume there is an additional non colluding cloud server C 2 208, which will hold the private key sk shared by the data owner 216 and assist with the computation. This way, the data owner 216 does not need to participate in any computation. The client 212 also does not need to participate in any computation except combining the partial result from Cl 204 and C2 208 to form the final result.

[0059] The system 100 improves performance as compared to a system using the same computing resources and architecture and implementing the native skyline protocol, and furthermore proves both accuracy of the computations and encryption of the associated data, simultaneously.

[0060] Three novel protocols can be executed in the ZK module 144 to generate the referenced process improvements:

Secure Dominance Comparison (SDC)

Dominant Objects Counter (DOC)

Multi-Party Skyline (MPS)

Notation

A, B, C objects (plaintext or ciphertext) A <: B B dominates A (B occurs later in the sort order) A|B concatenation of A and B PartyK party K of the protocol Sky(DSK) Skyline objects of party K, length = D pkK public key of party K skK secret (private) key of party K +-* ordinary arithmetic operations pmt homomorphic operations (plus, minus, times)

[Obj]K the object Obj encrypted by the public key of K dcount(K,L,i) number of objects of Sky(DSK) which dominate the i-th object of Sky (DSL) pi (Obj) random permutation of object Obj pi ’(Obj) a different random permutation of object Obj

X <- Y variable X is assigned the value Y (previous value of X is destroyed) X b Y component- wise product of X and Y

SDC protocol

Example pseudocode for a process used for implementing an SDC protocol that can be used to replace a portion of the skyline protocol is shown below.

Input: PartyA has a keypair pkA,skA.

PartyB has pkA and [P]A and [Q]A.

Output: PartyB derives [domP]A and [domQJA.

PartyB performs the following steps:

1. Duplicate [P]A and [Q]A into 4 vectors of length 2D: [X]A and [X’]A and [Y]A and [Y’]A

2. Create a vector V of length 2D where the first D elements are 1 and the remainder are 0; create a vector V’ of length 2D where the first D elements are 0 and the remainder are 1

3. Create two random binary vectors sigma and sigma’ of length 2D

I. Swap the i-th elements of [X] A and [Y] A if the i-th element of sigma = 1

II. Swap the i-th elements of [X’]A and [Y’]A if the i-th element of sigma’ = 1

III. Compute W = V b sigma and W’ = V’ b sigma’

4.

I. Create four vectors with random positive integer members: alpha, alpha’, beta, beta’ all with length D

II. Generate a binary vector rho of length D where rhoi = 1 if alphai > betai ; and 0 otherwise

III. Generate a binary vector rho’ of length D where rho’i = 1 if alpha’i > beta’i ; and 0 otherwise

IV. Encrypt alpha, beta, alpha’ and beta’ using pkA

5.

I. Compute [S]A <- pi ([X | alphajA) Compute [T] A <- pi ([Y | beta] A) Compute G <- pi (W | rho)

II. Compute [S’]A <- pi’ ([X’ | alpha’JA)

Compute [T’JA <- pi’([Y’ | beta’JA)

Compute G’ <- pi’(W’ | rho’)

6. Use a hash function H to compute h = H(G) and h’ = H(G’)

7. Send the following to PartyA: [S]A [T]A [S’JA [T’JA h h’

PartvA now performs the following steps:

8. Decrypt [S]A [T]A [S’JA [T’JA using the private key skA

9. Construct two binary vectors and U’ of length 3D where:

I. if ti > si then ui = 1, else 0

II. if t’i < si then u’i = 1, else 0

10. If H(U) = h and H(U’) != h’ then set domS = 1 and domT = 0

11. else if H(U) != h and H(U’) = h’ then set domS = 0 and domT = 1

12. else set domS = 0 and domT = 0

13. end if

14. Send the following to PartyB : [domSJA [domTJA PartvB now performs the following step:

15. Set [domPJA = [domSJA and [domQJA = [domTJA

This completes the protocol. The streamlined secure dominance protocol can be used as a building block for other queries, helping a cloud server with two encrypted vectors determine which one is dominant over the other without needing the private key, held by another party.

DOC protocol

The Secure Dominance Comparison can be combined with the Dominant Objects Counter (DOC) protocol to further increase the efficiency of the Skyline protocol using a computationally efficient methodology to derive proof of computation. Example pseudocode for a process used for implementing a DOC protocol that can be used to replace a portion of the skyline protocol is shown below.

Inputs: PartyA has Sky(DSA) pkA skA pkB

PartyB has Sky (D SB) pkB skB pkA

Outputs: PartyA gets [dcount(A,B)]B for Sky(DSB)

PartyB gets [dcount(B,A)]A for Sky(DSA) Party A performs the following step:

1. Encrypt Sky(DSA) using pkA and sends the result to PartyB PartyB performs the following steps:

2. Encrypt Sky (D SB) using pkA

3. Create dominant objects counter arrays [dcount(B,A)]A and [dcount(A,B)]A and sets all elements to [OJA.

4. Creates an object pair list from the Cartesian product of [Sky(DSA)]A and [Sky(DSB)]A and then randomly shuffles this list.

5. For all pair (a,b) in the list created in step 4 do

6. Randomly compute one of the following two items:

I. ([domaJA, [dombJA) <- SDC(a,b)

II. ([dombJA, [domaJA) <- SDC(b,a)

7. Compute [dcount(B,A,i)]A = [dcount(B,A,i)]A p [domaJA where “I” is the index of “a” in the pair list, and “p” is homomorphic addition

8. Compute [dcount(A,B,j)]A = [dcount(A,B,j)]A p [dombJA where “j” is the index of “b” in the pair list

9. End for

Note: [dcount(B,A)]A and [dcount(A,B)]A contain the number of dominant objects for Sky(DSA) and Sky (D SB).

10. Generate an array r of positive integers, compute [e(A,B)]A = [dcount(A,B)]A p [r]A and also encrypt r using pkB to obtain [r]B

11. Send [e(A,B)J A and [r]B to PartyA Party A then performs the following steps:

12. Decrypt [e(A,B)]A using skA and then encrypt e(A,B) using pkB to obtain [e(A.B)]B

13. Compute [dcount(A,B)]B = [e(A,B)]B m [r]B where “m” denotes homomorphic subtraction

[0061] This completes the protocol.

[0062] MPS protocol

Here is described an efficient multi-party secure skyline computation method that computes the skyline on encrypted data and preserves the confidentiality of each party’s database objects, provably ensuring the data remains secure. Example pseudocode for a process used for implementing an MPS protocol that can be used to replace a portion of the skyline protocol is shown below.

Inputs: Each party has its local Skyline object, key pair, and public keys of all other parties.

So if X is a party the X has Sky(DSX), pDM, sDM and all pkY for all parties Y != X.

Outputs: Each party identifies its global Skyline objects using the DOC protocol:

The following steps are performed:

1. PartyX obtains all [dcount(X,Y)]Y for all parties Y ! = X.

2. For all parties X, for Sky(DSX) of PartyX each party generates a random integer r > 1, and then for all parties Y ! = X then Party Y computes [f(Y,X)]X = [dcount(Y,X)]X t r, where “t” denotes homomorphic multiplication.

3. If the number of parties is 2 then

4. PartyB sends [f(B,A)]A to PartyA

5. PartyA decrypts [f(B,A)]A using skA and then if f(B,A,i) = 0 then the i-th element of Sky(DSA) is a global Skyline element.

Else:

6. For all parties Z, with Z != A, collects all [f(Y,A)]A from party Y

7. PartyZ computes [sum(f(A)]A by using homomorphic addition on all the [f(Y,A)]A

8. PartyZ sends the [sum(f(A)]A to PartyA

9. PartyA decrypts [sum(f(A)]A using skA and if sum(f(As)) = 0 then the i-th element of Sky(DSA) is a global Skyline object

[0063] This completes the protocol.

[0064] The above protocols can be implemented by the system 100. Combining these protocols allows the system 100 to have secure computations within its enclave at speeds of at least lOOhz or lOms/batch of private data. Not only is performance of computations on encrypted data (i.e., in a zero-knowledge environment) improved with the system 100 over the native skyline protocol, the ZK module 144 can produce both proof of the computation and proof of the encryption.

[0065] FIG. 3 shows an exemplary process 300 for implementing a multi-party secure (MPS) skyline computation. In particular, the process 300 can be used to identify global Skyline objects for two or more parties. Each party can include a local Skyline obj ect including at least one element and a key pair including a public key and a private key. Each party can be aware of the public keys of all other parties.

[0066] At 304, the process 300 can generate a set of one or more dominant object sums for a first party and a second party included in the plurality of parties. In some embodiments, the process 304 can determine, for a first party included in a plurality of parties, how many elements included in the local object of the first party dominate each element of the local object included in at least one other party (e.g., the second party) included in the plurality of parties. Each sum included in the set of dominate sums can indicate how many elements included in the local object of the first party dominate each element of the local object included in at least one other party included in the plurality of parties, and may be referred to as dcount in the pseudocode above. For example, the process 300 can determine that two elements in a local object of the first party dominates a first element of a local object of a second party included in the plurality of parties. As another example, the process 300 can determine that zero elements in a local object of the first party dominates a second element of a local object of a third party included in the plurality of parties. The process 300 can also determine a set of one or more dominant object sums for the second party and the first party indicative of how many elements included in the local object of the second party dominate each element of the local object included in the second party.

[0067] At 308, the process 300 can generate a random integer greater than one for each local object included in each party in the plurality of parties. For example, the first party can be associated with a first random integer and the second party can be associated with a second random integer.

[0068] At 312, the process 300 can determine how many elements included in the local object of the second party dominate each element of the local object included in the first party based on the first random integer. The process 300 can calculate a set of one or more products for each pair of parties included in the plurality of parties by, for each element of the local object included in the first party (Party A), homomorphically multiplying the sum of how many elements included in the local object of the second party (Party B) dominate the element of the local object included in the first party (Party A) by a first random integer (integer A). Each product included in the set of products can be associated with an element of the local object included in the first party (e.g., the second element).

[0069] At 316, the process 300 can provide each set of products associated with each pair of a second party (Party B) and a first party (Party A) included in the plurality of parties to the first party (Party A). As described above, each set of products is generated by multiplying how many elements included in the local object of the second party (Party B) dominate each element of the local object included in the first party (Party A) by a first random integer (integer A).

[0070] At 320, the process 300 can determine, for each party, whether each element included in the local object of each party is a global element. If there are two parties in the plurality of parties, the process 300 can decrypt the set of products for the first party generated at 312 based on the secret key included in the first party. After decryption, the process 300 can determine if any of the products in the set of products are equal to zero. For each product that is equal to zero, the process 300 can determine that the element of the local object associated with the product is a global element. All other elements are non-global elements.

[0071] FIG. 4 shows an exemplary process 400 for implementing a Dominant Objects Counter (DOC) protocol to further increase the efficiency of the Skyline protocol using a computationally efficient methodology to derive proof of computation. In particular, the process 300 can be used to identify global Skyline objects for a first party and a second party. The first party can include a first local Skyline object including at least one element, a first public key, a first private key. The second party can include a second local Skyline object including at least one element, a second public key, a second private key. Each party can be aware of the public keys of the other party.

[0072] At 404, the process 400 can encrypt the first local obj ect in the first party using the first public key.

[0073] At 408, the process 400 can encrypt second local object in the second party using the first public key.

[0074] At 412, the process 400 can generate a first dominant objects counter set ([dcount(B,A)]A) for the first party and a second dominant objects counter set ([dcount(A,B)]A) for the second party. Each dominant objects counter sets can include a counter for each element in the first local object and the second local object. Each counter is initialized to zero.

[0075] At 416, the process 400 can determine, for each element in the first local object, how many elements in the second local object dominate the element. The process 400 can also determine, for each element in the second local object, how many elements in the first local object dominate the element . In some embodiments, the process 400 can generate an object element pair list based on the first local object and the second local object, and then randomly shuffles the object element pair list. Each element pair in the object element pair list can include an element in the first local object and an element in the second local object. In some embodiments, for each element pair in the object element pair list, the process 400 can randomly determine whether the element in the first local object dominates the element in the second local object or whether the element in the second local object dominates the element in the first local object using the SDC protocol described below. If the element in the first local object dominates the element in the second local object, the process 400 can increment (e.g., add one to) the counter included in the second dominant objects counter set that is associated with the element in the second local object. If the element in the second local object dominates the element in the first local object, the process 400 can increment to the counter included in the first dominant objects counter set that is associated with the element in the first local object. Each of the dominant objects counter sets can be encrypted using the first public key.

[0076] At 420, the process 400 can encrypt and send the first dominant objects counter set to the first party. In some embodiments, the process 400 can generate an array of positive integers, add the integers in the array of positive integers to the values in the first dominant objects counter set, and encrypt the array of positive integers based on the second public key.

[0077] At 424, the process 400 can decrypt the first dominant objects counter set at the first party using the first secret key and the second public key. In some embodiments, the process 400 can decrypt the first dominant objects counter set based on the first private key, encrypt the decrypted first dominant objects counter set based the second public key, and homomorphically subtract the encrypted array of positive integers from the encrypted first dominant objects counter set to determine the dominant Skyline objects in the first party. [0078] FIG. 5 shows an exemplary process 500 for implementing a Secure Dominance Comparison (SDC) protocol to further increase the efficiency of the Skyline protocol using a computationally efficient methodology to securely identify which of a pair of elements is dominant.

[0079] At 502, the process 500 can encrypt two object elements (e.g., data elements) P and Q, associated with parties, A and B, respectively, (e.g., object element P is associated with party A and object element Q is associated with party B) using a public key associated with one of the parties (e.g., party A). This can produce two encrypted object elements [P]A and [Q]A. In some embodiments, process 500 can include a computing device associated with party A encrypting P, and a computing device associated with party B encrypting Q. In some embodiments, each of encrypted objects [P]A and [Q]A can have a length of 2D. In some embodiments, P and Q can be binary. In some embodiments, the length 2D can be a number of 32-bit unsigned values.

[0080] At 504, the process 500 can create two duplicates of each encrypted object element as vectors of length 2D. For example, process 500 can create duplicates [X]A and [X’]A of encrypted object element [P]A (e.g., X[A] = dup([P]A) and [X’]A = dup([P]A)), and can create duplicates [Y]A and [Y’]A of encrypted object element [Q]A, each having a length 2D.

[0081] At 506, process 500 can create two complimentary binary V and V of length 2D, where the first D elements of V are 1 and the remainder are 0, and the elements of V are where the first D elements of V are 0 and the remainder are 1. For example, V can be represented as [1... 10...0] and V can be represented as [0... 01... 1]

[0082] At 508, process 500 can generate two random binary vectors s and s' of length 2D, where each position of the vector is randomly selected to be a zero or a 1. Each of the two random binary vectors s and s' are independently generated.

[0083] At 510, process 500 can swap elements of the duplicates based on the values in the vectors s and s' . For example, for positions of s that are 1, process 500 can swap the elements of [X]A and [Y]A, and for the positions of s' that are 1, process 500 can swap the elements of [X']A and [U'] A. In a more particular example, if s has a 1 at the 6^th position, [X] A includes a character "x" at the 6^th position, and Y[A] includes a character "y" at the 6^th position, at 510 process 500 can adjust the 6^th position of [X]A to be "y", and can adjust the 6^th position of [Y]A to be "x".

[0084] At 512, process 500 can generate two additional vectors W and W of length 2D by calculating pairwise products of V and s, and V and s' (e.g., W = Vha, where b indicates a pairwise product operation). For example, as V and V includes D Is and D 0s, the last D elements of W are 0, and the first 0 elements of W are 0.

[0085] At 514, process 500 can generate four vectors a, a',b and b' of length D, with each element of each vector including a random positive integer (e.g., a whole number greater than zero). In some embodiments, the random number can be any 32-bit integer (e.g., a 32-bit unsigned integer).

[0086] At 516, process 500 can generate and encrypt binary vectors p and p' of length D where the value of each element of p is based on a comparison of the corresponding values in vectors a and /?, and the value of each element of p' is based on a comparison of the corresponding values in vectors a' and b' . For example, for each element of p, if a > b , then process 500 can set that element to 1, and otherwise can be set to 0 (e.g., if a < b). Similarly, for each element of p', if a' > /?', then process 500 can set that element to 1, and otherwise can be set to 0 (e.g., if a' < b' ). Process 500 can encrypt p and p' using the public key associated with party A to generate encrypted vectors [p]A and [p']A.

[0087] At 518, process 500 can generate vectors [S]A, [S'] A, [T]A, [T']A (each of length 3D) that include both encrypted and swapped copies of [P]A and [Q]B (e.g., the versions of [X]A, [X']A, [Y]A, and [Y']A generated at 510), and corresponding vectors used to generate vectors p and p' (e.g., a and /?, and a and b). Additionally, process 500 can generate vectors G and G' that include W and p, and W and p', respectively. For example, process 500 can generate vector [S]A by concatenating (e.g., randomly concatenating) [X]A and a , and can generate vector [S']A by concatenating (e.g., randomly concatenating) [X']A and a'. As another example, process 500 can generate vector [T]A by randomly concatenating [Y]A and /?, and can generate vector [T']A by concatenating (e.g., randomly concatenating) [Y']A and b'. As yet another example, process 500 can generate vector G by randomly concatenating W and p, and can generate vector G' by concatenating (e.g., randomly concatenating) W and p'.

[0088] At 520, process 500 can use a hash function H to generate values h and h' that represent the result of hashing vectors G and G using H (e.g., h = H(G) and h' = H(G')). The length of the hash value may differ based on the hash function.

[0089] At 522, process 500 can transmit [S]A, [S']A, [T]A, [T']A, h, and h' to a computing device associated with party A.

[0090] At 524, process 500 can receive and decrypt [S]A, [S']A, [T]A, [T']A using the private key associated with the public key used to encrypt [P] A and [Q] A, to generate vectors S, S', T, and T'. It is noted that a number of different encryption techniques can be used as long as priv(pub(x))

= x.

[0091] At 526, process 500 can generate two binary vectors U and U' of length 3D where the value of each element of U is based on a comparison of the corresponding values in vectors S and T, and the value of each element of U' is based on a comparison of the corresponding values in vectors S' and T'. For example, for each element of U, if T > S, then process 500 can set that element to 1, and otherwise can be set to 0 (e.g., if T < S). Similarly, for each element of U', if S' > T', then process 500 can set that element to 1, and otherwise can be set to 0 (e.g., if T' < S').

[0092] At 528, process 500 can use hash function H to hash U and U', and can determine which of P and Q is dominant. For example, process 500 can compare the result of hashing U and U' to the values h and h'. If H(U) = h and H(U) ¹ h', process 500 can determine that S is dominant over T, and can set values domS=l and domT=0 to indicate the result. If H(U) ¹ h and H(U) = h', process 500 can determine that T is dominant over S, and can set values domS=0 and domT=l to indicate the result. Otherwise, if H(U) ¹ h and H(U) ¹ h', process 500 can determine that S and T are equal and/or that the result is inconclusive, and can set values domS=0 and domT=0 to indicate the result.

[0093] At 530, process 500 can transmit [domS]A and [domT]A to a computing device associated with party B and/or to a computing device that transmitted the [S]A, [S'] A, [T]A, [T']A, h, and h' to the computing device associated with party A. [domSJA can indicate a dominance value associated with an encrypted value of S.

[0094] At 532, process 500 can receive [domSJA and [domTJA, and can use these objects to associate values with P and Q indicative of which is dominant over the other. For example, process 500 can set [domPJA = [domSJA and [domQJA = [domTJA.

[0095] In some embodiments, a computing device associated with party B can perform a portion of the process 500 and a computing device associated with party A can perform other portions of the process. Additionally or alternatively, in some embodiments, a computing device associated with another entity (e.g., server 204, zero knowledge module 144) can perform a portion of the process 500. For example, in some embodiments, a computing device associated with party B can perform a portion of 502 (e.g., encrypting Q), and can perform 504-522 and 532, and a computing device associated with party A can perform a portion of 502 (e.g., encrypting P), and can perform 524-530. As another example, a computing device associated with party B can perform a portion of 502 (e.g., encrypting Q), one or more computing devices associated with party A can perform a portion of 502 (e.g., encrypting P), and can perform 524-530. In such an example, another computing device (e.g., server 204, zero knowledge module 144) can perform 504-522 and 532.

[0096] In some embodiments, the process 300 in FIG. 3, the process 400 in FIG. 4, and/or the process 500 in FIG. 5 can be used in lieu of a portion of the skyline protocol (e.g., to determine a dominance relationship between two objects without revealing the values to unauthorized parties).

[0097] Sigma Protocol

[0098] The system 100 can also check that the nodes (e.g., the nodes 152) being used are themselves the correct nodes to which sending private data is supposed to be sent, i.e. remote attestation. The system 100 can use the well-established Sigma protocol to perform this verification. In the system 100, remote attestation can occur when setting up nodes and upon refresh, and the frequency of the refresh can be adjusted at runtime to choose a balance between security of nodes required vs performance. [0099] Sigma protocol is a proof that consists of commitment, challenge and response. As a result of this exchange between the client and the service provider, a shared key between the enclave and the challenger is produced that can be used for encrypting secrets that are to be provisioned in the enclave. Once inside the enclave, these secrets could then be decrypted by the application, alongside the skyline protocol.

Forming Consensus

[00100] The system 100 can use a number of different data types within the ZK module 144 in order to develop consensus across nodes at a faster rate. As discussed, the level of consensus (number of nodes required to verify) can also be altered, balancing between security, accuracy and performance. Latency is exponentially increased as the number of nodes required for verification increases.

Data Types

1. Self(A)

Node A can provide a quote Quote(A) of its trusted computing base then can be verified by public keys or shared private symmetric keys (i.e. when a data source is alone but can be provable).

2. Pair(A,B)

Node A trusts node B because of remote attestation or an out-of-band exchange of symmetric keys. For example, two identical sources of market data, with the ability to rely on one as well as the other

3. Reflexive(A, B)

A and B mutually trust each other. When data can be converted from x to y, it can be assumed that it can equally be converted from y to x in the same way. In the system 100, currency conversion rates, or more likely, the conversion from position data and market data to different greek types can be used. It is possible to construct gamma from delta in the same way as its possible to construct delta from gamma, given the same constant information.

4. Transitive(A,B,C)

If A trusts B, and B trusts C, then A trusts C. As above, but with multiple interconnected data types, likely to be market data and position analytics that are linked by common formulae (e.g., Position +Market data -> Gamma -> Delta). 5. Oracle(A,[p])

[00101] A is universally trusted as an oracle for the list of properties/predicates [p] A can be the external trusted data source (i.e., an input where the input of data across another input cannot be verified, other than checking userlD, timestamp, encryption type etc.) For example, position data from a trading venue, or single source of market data can be included.

Consensus methods

[00102] In some embodiments, the below verification techniques can be implemented by the system to check the validity of data and check that data is being computed correctly with a certain degree of certainty.

1. SecureTimestamp(N)

Node N can provide a 64 bit timestamp that is non-decreasing and totally ordered on N. All nodes participate in a partially ordered vector clock protocol such that if T1 = ST(N) and T2 = ST(M) then one of the following must hold: T1 < T2; T1 = T2; T1 > T2; or T1 ~ T2 (order is undecidable). However, if either N or M is an oracle for ST, then it can assert (without proof) that T1 ~ T2 can be converted to one of the <=> relations.

2. SecureCounter(N)

Node N can provide a 64, 128, or 256 bit counter that is monotonic and totally ordered on N.

3. SecureUuid(N)

Node N can generate a universal unique identifier that is guaranteed to be unique across all nodes and all times. Note that the resulting UUID is not bound to N. Note also that there are no guarantees that UUID is (pseudo)random; there is not even a guarantee that UUID is usable for entropy.

4. SecureComputation(N, W, [X])

The node N can securely compute the value of any well-formed formula W, provided that all free variables in W are members of the set of variable-value bindings [X] It is not an error for unused variable bindings to exist in [X]

Consensus Model

[00103] For a node N a local model is a set of data types and computation methods bound to N. Multiple similar calculations can be computed on a single node (e.g. Margin Calculation 1 (MCI) & Margin Calculation 2 (MC2)), and enforce a local verification of node N by comparing output MCI and output of MC2, and checking they have some probabilistic polynomial time predicate V that can determine if there is sufficient consensus between the two outputs, given an acceptable error range and iteration count. Finally, it is always that case that V is reflexive and transitive.

[00104] The system 100 can use a trust model over a set of nodes [N], which is a set of local models for each node N. The validity of, say, a margin calculation, is confirmed by verifying outputs across each N, requiring some portion of N nodes confirming the validity of the output, given some agreed upon threshold of N and error bounds.

[00105] The amount of verification needed across nodes can be selected, and inside the local nodes themselves the appropriate trade-offs between accuracy, security and performance can also be selected after executing a provably secure and computationally accurate zero knowledge calculation using the SDC protocol, the DOC protocol, and the MPS protocol described above.

Data flows

[00106] Example data flows shown in FIG. 1 are now described.

D tv:zk

[00107] D_tv:zk can include encrypted positions and trades transmitted from the trading venue 136 to the ZK module.

Example:

[{ counterparty A uid: ...., counterpartyB uid: ..., instrument: BTC-27DEC-10000-C side: sell size: 10 timestamp: 1574364818098},

{ counterparty A uid: ...., counterpartyB uid: ..., instrument: BTC-27DEC size: 10 side: buy timestamp: 1574364818999},...] D md:DM pub

[00108] D_md:DM_pub can include public market data transmitted from exchanges included in the market data feeds module 120 to the public data module 116. The public market data can include order book data / quotes for perpetual swaps, futures and options, and/or an index and mark price stream.

D DM pub:zk

[00109] D_DM_pub:zk can include public market data and models transmitted from the public data module 116 to the ZK module 144.

[00110] Based on the raw public data from feed handlers, the system 100 can forward processed data to the ZK module 144. Processing the data can include performing sanity checks, filtering outliers, and computing mark prices. The system 100 can also compute model representations of the synthetic forward curve and volatility surface that are pushed to the ZK module 144.

D zk:DM priv

[00111] D zlcDM priv can include data derived from the ZK module 144 and transmitted from the ZK module to the private data module 108. For each user ID corresponding to a user instance included in the private data module 108, the ZK module 144 can publish the following derived data to the user instance, such as margin calculation, first derivative, and/or mark value of positions. The ZK module 144 can also publish verified margin usage per user.

Example:

[{ positioned: ..., counterparty A uid: ...., counterpartyB uid: ..., mark_value: 789123.5, delta: 100, vega: ..., timestamp: 1574364818098},

{ positioned: ..., counterparty A uid: ...., counterpartyB uid: mark_value: 9000.0, delta: 0.95, vega: ..., timestamp: 1574364818098},

{ counterpartyA uid: ..., margin_usage: 378234, timestamp: 1574364818098}]

D DM privxust

[00112] D DM privxust can include margin usage, P&L, and/or alerts and settlement instructions transmitted from the private data module 108 to the API 128.

Example: margin, pnl feed

[{ user uid = ..., counterparty _uid =..., margin_usage = 7000; timestamp = 1574364818098; position _pnl = 500;},

{ user uid = ..., counterparty _uid =..., margin_usage = 400; timestamp = 1574364818388; position_pnl = 500;},...]

Example: action { user uid = ..., action type = “freezejxading”;

}

Example: action { user uid = action_type = “approve_withdrawal”, amount = 7000, currency = BTC

}

D cust:DM priv

D_cust:DM_priv can include balance data transmitted from the custodian module 124 to trading venue module 136.

Example: margin, pnl feed

[{ user uid = ..., margin_usage = 7000; balance: 22000; timestamp = 1574364818098;},..]

Calculations

C DM pub (calculations that can be implemented by the public data module 116)

[00113] Synthetic Forward Curve: The forward curve is a function graph that defines the prices at which a contract for future delivery or payment can be concluded today. The synthetic forward curve can be constructed by interpolating points that correspond with observed mark to mark futures prices with synthetic futures prices derived from mark to mark option prices

[00114] Implied Volatility Surface: Implied volatility (IV) of an option contract is that value of the volatility of the underlying instrument which, when input in an option pricing model (such as Black-Scholes), will return a theoretical value equal to the current market price of said option. The implied volatility surface can be constructed by interpolating points that correspond with observed options mark prices.

[00115] Greeks: Based on the above, Greeks can be calculated for arbitrary instruments using a standard option pricing model C zk (Calculations that can be implemented by the ZK module 144)

[00116] In some embodiments, the ZK module 144 can compute all the above implemented by the public data module 116. The ZK module can use encrypted position data to compute derived data and portfolio aggregations per user, as well as leverage relative to the equity, or margin usage. Margin usage calculations can be performed with various techniques, for example, SPAN, VaR, and variations of these models.

C DM priv (Calculations that can be implemented by the private data module 108)

[00117] Based on the derived data pushed from the ZK module 144, the private data module 108 can generate calculations that are passed to the credit provider through aggregate, privacy preserving risk metrics and appropriate alerts. In some embodiments, calculations are passed to the Custodian or wallet in the form of real-time margin usage, P&L, and settlement instructions. The verified margin usage from the ZK module 144 can be taken as “truth” at the time corresponding to its timestamp. Until we receive the next verified margin usage number, the DM module 104 can use the derived data to approximate changes in margin usage.

[00118] In at least some embodiments, a computing device that implements a portion or all of one or more of the technologies described herein, including, but not limited to, the techniques to implement the functionality described with respect to FIG. 1 for an encryption client 132 (when not using SGX Terminated TLS operations), 140, a node 152, a secure enclave, a module 108, 116, 144 of the system 100, or the system 100 itself, can include one or more computer systems that include or are configured to access one or more computer-accessible media. FIG. 6 illustrates such a computing device 700. In the illustrated embodiment, computing device 700 includes one or more processors 710a, 710b, ..., 710n (which may be referred herein singularly as "a processor 710" or in the plural as "the processors 710") coupled to a system memory 720 via an input/output (I/O) interface 780. Computing device 700 further includes a network interface 640 coupled to I/O interface 780.

[00119] In various embodiments, computing device 700 may be a uniprocessor system including one processor 710 or a multiprocessor system including several processors 710 (e.g., two, four, eight, or another suitable number). Processors 710 may be any suitable processors capable of executing instructions. For example, in various embodiments, processors 710 may be general-purpose or embedded processors implementing any of a variety of instruction set architectures (ISAs ), such as the x86/x64, Power PC, RISC-V, SPARC, or MIPS ISAs, or any other suitable ISA. In multiprocessor systems, each of processors 710 may commonly, but not necessarily, implement the same ISA.

[00120] System memory 720 may be configured to store instructions and data accessible by processor(s) 710. In various embodiments, system memory 720 may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of memory. In the illustrated embodiment, program instructions and data implementing one or more desired functions, such as those methods, techniques, and data described above, are shown stored within system memory 720 as code 725 and data 726. The code 725 may particularly include program code 725a and/or other types of machine-readable instructions executable by one, some, or all of the processors 710a-n to implement all or part of the "dual proof' computation system (e.g., system 100 of FIG. 1) described herein; similarly, the data 726 may particularly include data 726a for performing computations, such as registers, cache layers, configuration information, private and semi-private data as described above, and so on.

[00121] In one embodiment, I/O interface 780 may be configured to coordinate I/O traffic between processor(s) 710a-n, system memory 720, and any peripheral devices in the device, including network interface 640 or other peripheral interfaces. In some embodiments, I/O interface 780 may perform any necessary protocol, timing, or other data transformations to convert data signals from one component (e.g., system memory 720) into a format suitable for use by another component (e.g., processor(s) 710a-n). In some embodiments, I/O interface 780 may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, for example. In some embodiments, the function of I/O interface 780 may be split into two or more separate components, such as a north bridge and a south bridge, for example. Also, in some embodiments some or all of the functionality of I/O interface 780, such as an interface to system memory 720, may be incorporated directly into processor 710. [00122] Network interface 740 may be configured to allow data to be exchanged between computing device 700 and other device or devices 760 attached to a network or network(s) 750, such as user computing devices and other computer systems described above, for example. In various embodiments, network interface 740 may support communication via any suitable wired or wireless general data networks, such as types of Ethernet networks, for example. Additionally, network interface 740 may support communication via telecommunications/telephony networks, such as analog voice networks or digital fiber communications networks, via storage area networks, such as Fiber Channel SANs or via any other suitable type of network and/or protocol.

[00123] In some embodiments, system memory 720 may be one embodiment of a computer- accessible medium configured to store program instructions and data for implementing embodiments of the present methods and apparatus. However, in other embodiments, program instructions and/or data may be received, sent, or stored upon different types of computer- accessible media. Generally speaking, a computer-accessible medium may include non-transitory storage media or memory media, such as magnetic or optical media, e.g., disk or DVD/CD coupled to computing device 700 via I/O interface 780. A non-transitory computer-accessible storage medium may also include any volatile or non-volatile media, such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., that may be included in some embodiments of computing device 700 as system memory 720 or another type of memory. Further, a computer- accessible medium may include transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as a network and/or a wireless link, such as may be implemented via network interface 740. Portions or all of multiple computing devices, may be used to implement the described functionality in various embodiments; for example, software components running on a variety of different devices and servers may collaborate to provide the functionality. In some embodiments, portions of the described functionality may be implemented using storage devices, network devices, or special purpose computer systems, in addition to or instead of being implemented using general-purpose computer systems. The term "computing device," as used herein, refers to at least all these types of devices and is not limited to these types of devices.

[00124] A network set up by an entity, such as a company or a public sector organization, to provide one or more services (such as various types of cloud-based computing or storage) accessible via the Internet and/or other networks to a distributed set of clients may be termed a provider network. Such a provider network may include numerous data centers hosting various resource pools, such as collections of physical and/or virtualized computer servers, storage devices, networking equipment, and the like, needed to implement and distribute the infrastructure and services offered by the provider network. The resources may in some embodiments be offered to clients in units called instances, such as virtual or physical computing instances or storage instances. A virtual computing instance may, for example, comprise one or more servers with a specified computational capacity (which may be specified by indicating the type and number of CPUs, the main memory size, and so on) and a specified software stack (e.g., a particular version of an operating system, which may in turn run on top of a hypervisor).

[00125] A number of different types of computing devices may be used singly or in combination to implement the resources of the provider network in different embodiments, including general- purpose or special-purpose computer servers, storage devices, network devices, and the like. In some embodiments a client or user may be provided direct access to a resource instance, e.g., by giving a user an administrator login and password. In other embodiments the provider network operator may allow clients to specify execution requirements for specified client applications and schedule execution of the applications on behalf of the client on execution platforms (such as application server instances, Java™ virtual machines (JVMs), general purpose or special purpose operating systems, platforms that support various interpreted or compiled programming languages, such as Ruby, Perl, Python, C, Rust, C++, Java and the like, or high performance computing platforms) suitable for the applications, without, for example, requiring the client to access an instance or an execution platform directly. A given execution platform may utilize one or more resource instances in some implementations; in other implementations multiple execution platforms may be mapped to a single resource instance.

[00126] In many environments, operators of provider networks that implement different types of virtualized computing, storage, and/or other network-accessible functionality may allow customers to reserve or purchase access to resources in various resource acquisition modes. The computing resource provider may provide facilities for customers to select and launch the desired computing resources, deploy application components to the computing resources, and maintain an application executing in the environment. In addition, the computing resource provider may provide further facilities for the customer to quickly and easily scale up or scale down the numbers and types of resources allocated to the application, either manually or through automatic scaling, as demand for or capacity requirements of the application change. The computing resources provided by the computing resource provider may be made available in discrete units, which may be referred to as instances. An instance may represent a physical server hardware platform, a virtual machine instance executing on a server, or some combination of the two. Various types and configurations of instances may be made available, including different sizes of resources executing different operating systems (OS) and/or hypervisors and with various installed software applications, runtimes, and the like.

[00127] It will be appreciated by those skilled in the art that while the invention has been described above in connection with particular embodiments and examples, the invention is not necessarily so limited, and that numerous other embodiments, examples, uses, modifications and departures from the embodiments, examples and uses are intended to be encompassed by the claims attached hereto. The entire disclosure of each patent and publication cited herein is incorporated by reference, as if each such patent or publication were individually incorporated by reference herein. Various features and advantages of the invention are set forth in the following claims.

[00128] Brief Glossary of Terms

[00129] This glossary is non-exhaustive and non-limiting, and provides the general understanding of certain terms of art in computer science and finance, which terms are used in this document.

[00130] Margin: Collateral that the holder of a financial instrument has to deposit with a counterparty (most often their broker or an exchange) to cover some or all of the credit risk the holder poses for the counterparty. This risk can arise if the holder has done any of the following: Borrowed cash from the counterparty to buy financial instruments; Borrowed financial instruments to sell them short; or, entered into a derivative contract. [00131] Portfolio Margin: The goal of portfolio margin is to align margin requirements with the overall risk of the portfolio. Portfolio margin usually results in significantly lower margin requirements on hedged positions than under traditional rules.

[00132] Counterparty: a legal entity, unincorporated entity, or collection of entities to which an exposure to financial risk might exist.

[00133] Clearing House: a financial institution formed to facilitate the exchange (i.e., clearance) of payments, securities, or derivatives transactions. The clearing house stands between two clearing firms (also known as member firms or participants). Its purpose is to reduce the risk of a member firm failing to honor its trade settlement obligations.

[00134] Central Clearing Counterparty: Many clearing houses adopt a Central Clearing Counterparty model (CCP). CCPs "mutualize" (share among their members) counterparty credit risk in the markets in which they operate. A CCP reduces the settlement risks by netting offsetting transactions between multiple counterparties, by requiring collateral deposits (also called "margin deposits"), by providing independent valuation of trades and collateral, by monitoring the credit worthiness of the member firms, and in many cases, by providing a guarantee fund that can be used to cover losses that exceed a defaulting member's collateral on deposit.

[00135] Market data: price and trade-related data for a financial instrument reported by a trading venue such as a stock exchange.

[00136] Derivative: a contract that derives its value from the performance of an underlying entity. This underlying entity can be an asset, index, or interest rate, and is often simply called the "underlying."

[00137] Greeks: in mathematical finance, the quantities representing the sensitivity of the price of derivatives such as options to a change in underlying parameters on which the value of an instrument or portfolio of financial instruments is dependent.

[00138] Custodian: a specialized financial institution responsible for safeguarding a firm's or individual's financial assets and is not engaged in "traditional" commercial or consumer/retail banking. [00139] SPAN: Developed in 1988 by Chicago Mercantile Exchange Inc. to effectively assess risk on an overall portfolio basis. SPAN is a market simulation based Value At Risk system which has been reviewed and approved by market regulators and participants worldwide.

[00140] Value at Risk (VaR): a statistical technique used to measure the amount of potential loss that could happen in an investment portfolio over a specified period of time. Value at Risk gives the probability of losing more than a given amount in a given portfolio.

Further Examples Having a Variety of Features:

[00141] Example 1 : A method of determining at least one global skyline object comprising: generating a first set of one or more dominant object sums for a first party comprising a first local object, the first local object comprising at least one element; generating a second set of one or more dominant object sums for a second party comprising a second local object, the second local object comprising at least one element; generating a first random integer for the first party; determining how many elements included in the second local object dominate each element of the first local object based on the first random integer; and determining at least one element included in the first local object that is a globally dominant element.

[00142] Example 2: The method of Example 1, wherein the generating a first set of one or more dominant object sums for a first party comprises: determining, for an element pair comprising a first local object and a second local object, whether an element in the first local object dominates an element in the second local object using a secure dominance comparison (SDC) protocol.

[00143] Example 3: The method of Example 2, wherein the SDC protocol comprises: generating two duplicates of each of an encrypted first object element and an encrypted second object element, each of the duplicates having a length 2D.

[00144] Example 4: The method of any one of Examples 2 to 3, wherein the SDC protocol comprises: generating two complimentary binary vectors of length 2D [00145] Example 6: The method of any one of Examples 2 to 5, wherein the SDC protocol comprises: generating two random binary vectors of length 2D. [00146] Example 7: The method of any one of Examples 2 to 6, wherein the SDC protocol comprises: swapping elements of the duplicates based on values included in the two random binary vectors.

[00147] Example 8: The method of any one of Examples 4 to 7, wherein the SDC protocol comprises: generating two supplemental vectors of length 2D based on the two complimentary binary vectors and the two random binary vectors.

[00148] Example 9: The method of any one of Examples 2 to 8, wherein the SDC protocol comprises: generating four vectors of length D.

[00149] Example 10: The method of Example 9, wherein the SDC protocol comprises: generating two supplemental vectors of length D based on a comparison of corresponding values in two vectors included in the four vectors of length D.

[00150] Example 11 : The method of Example 10, wherein the SDC protocol comprises: encrypting the two supplemental vectors of length D.

[00151] Example 12: The method of any one of Examples 2 to 11, wherein the SDC protocol comprises: generating four vectors of length 3D.

[00152] Example 13: The method of any one of Examples 8 to 12, wherein the SDC protocol comprises: generating two hybrid vectors based on the two supplemental vectors of length D and the two supplemental vectors of length 2D.

[00153] Example 14: The method of any one of Examples 12 to 13, wherein the SDC protocol comprises: encrypting the four vectors of length 3D.

[00154] Example 15: The method of any one of Examples 13 to 14, wherein the SDC protocol comprises: generating hash values based on the two hybrid vectors using a hashing function. [00155] Example 16: The method of any one of Examples 12 to 15, wherein the SDC protocol comprises: decrypting the four vectors of length 3D.

[00156] Example 17: The method of any one of Examples 16, wherein the SDC protocol comprises: generating two binary vectors of length 3D based on the decrypted four vectors of length 3D.

[00157] Example 18: The method of any one of Examples 15 to 17, wherein the SDC protocol comprises: identifying which of the first object element and the second object element is dominant based at least in part on the hash values. [00158] Example 19: The method of any one of Examples 2 to 18, further comprising: randomly choosing to evaluate whether the element in the first local object dominates the element in the second local object or whether the element in the second local object dominates the element in the first local object.

[00159] Example 20: The method of any one of Examples 2 to 19, further comprising: generating a first dominant objects counter associated with the first party and a second dominant objects counter set associated with the second party.

[00160] Example 21 : The method of any one of Examples 2 to 20, further comprising: in response to determining that the element in the second local object dominates the element in the first local object, incrementing a counter included in the first dominant objects counter set that is associated with the element in the first local object.

[00161] Example 22: The method of Example 21, further comprising: encrypting the first dominant objects counter set.

[00162] Example 23: The method of any one of Examples 21 to 22, further comprising: decrypting the first dominant objects counter set to determine dominant Skyline objects in the first party.

[00163] Example 23: The method of any one of Examples 21 to 22, further comprising: encrypting the first objects counter set based on a first public key associated with the first party. [00164] Example 24: The method of any one of Examples 1 to 23, wherein the at least one global skyline object comprises data associated with at least one of a portfolio risk metric or final margin calculations.

[00165] Example 25: The method of Example 24, wherein the portfolio risk metric comprises at least one of equity, liability, margin usage, or value at risk.

[00166] Example 26: The method of any one of Examples 1 to 25, wherein the at least one global skyline object comprises data associated with a credit risk metric.

[00167] Example 27: The method of Example 26, wherein the credit risk metric is a counterparty credit risk.

[00168] Example 28: The method of any one of Examples 1 to 27, wherein the first random integer is a thirty -two bit integer.

[00169] Example 29: A system comprising: at least one hardware processor that is configured to: perform a method of any one of Examples 1 to 28. [00170] Example 30: A non-transitory computer readable medium containing computer executable instructions that, when executed by a processor, cause the processor to perform a method of any one of Examples 1 to 28.

Claims

1. A method of determining at least one global skyline object comprising: generating a first set of one or more dominant object sums for a first party comprising a first local object, the first local object comprising at least one element; generating a second set of one or more dominant object sums for a second party comprising a second local object, the second local object comprising at least one element; generating a first random integer for the first party; determining how many elements included in the second local object dominate each element of the first local object based on the first random integer; and determining at least one element included in the first local object that is a globally dominant element.

2. The method of claim 1 , wherein the generating a first set of one or more dominant obj ect sums for a first party comprises: determining, for an element pair comprising a first local object and a second local object, whether an element in the first local object dominates an element in the second local object using a secure dominance comparison (SDC) protocol.

3. The method of claim 2, wherein the SDC protocol comprises: generating duplicates [X]A and [X’]A of each of an encrypted first object element P and an encrypted second object element Q respectively, each of the duplicates [X]A and [X’]A having a length 2D; generating two complimentary binary vectors V and V of length 2D; generating two random binary vectors s and s' of length 2D; swapping elements of the duplicates [X]A and [X’]A based on values included in the two random binary vectors s and s'; generating two supplemental vectors W and W of length 2D based on the two complimentary binary vectors V and V and the two random binary vectors s and s'; generating four vectors a, a',b and b' of length D; generating two supplemental vectors p and p' of length D based on a comparison of corresponding values in vectors a and b and a comparison of the corresponding values in vectors a' and b respectively; encrypting the two supplemental vectors p and p generating four vectors [S]A, [S'] A, [T]A, and [T']A of length 3D; generating two hybrid vectors G and G' based on the two supplemental vectors p and p' of length D and the two supplemental vectors W and W of length 2D; encrypting the four vectors [S]A, [S'] A, [T]A, and [T']A of length 3D; generating hash values h and h' based on the two hybrid vectors G and G using a hashing function H; decrypting the four vectors [S]A, [S'] A, [T]A, and [T']A of length 3D; generating two binary vectors U and U' of length 3D based on the decrypted four vectors [S]A, [S'] A, [T]A, and [T']A of length 3D; and identifying which of the first object element P and the second object element Q is dominant based at least in part on the hash values h and h'.

4. The method of claim 2, wherein the SDC protocol comprises: generating two duplicates of each of an encrypted first object element and an encrypted second object element, each of the duplicates having a length 2D; generating two complimentary binary vectors of length 2D; generating two random binary vectors of length 2D; swapping elements of the duplicates based on values included in the two random binary vectors; generating two supplemental vectors of length 2D based on the two complimentary binary vectors and the two random binary vectors; generating four vectors of length D; generating two supplemental vectors of length D based on a comparison of corresponding values in two vectors included in the four vectors of length D; encrypting the two supplemental vectors of length D; generating four vectors of length 3D; generating two hybrid vectors based on the two supplemental vectors of length D and the two supplemental vectors of length 2D; encrypting the four vectors of length 3D; generating hash values based on the two hybrid vectors using a hashing function; decrypting the four vectors of length 3D; generating two binary vectors of length 3D based on the decrypted four vectors of length 3D; and identifying which of the first object element and the second object element is dominant based at least in part on the hash values.

5. The method of claim 2, wherein the SDC protocol comprises: generating two duplicates of each of a first encrypted object element and a second encrypted object element, each of the duplicates having a length 2D; generating two complimentary binary vectors of length 2D; generating two random binary vectors of length 2D; swapping elements of the duplicates based on values included in the two random binary vectors; and generating two supplemental vectors of length 2D based on the two complimentary binary vectors and the two random binary vectors.

6. The method of claim 2, wherein the SDC protocol comprises: generating hash values based on two hybrid vectors using a hashing function; decrypting four vectors of length 3D; generating two binary vectors of length 3D based on the decrypted four vectors of length 3D; and determining which of a first object element and a second object element is dominant using the hashing function.

7. The method of claim 2 further comprising: randomly choosing to evaluate whether the element in the first local object dominates the element in the second local object or whether the element in the second local object dominates the element in the first local object.

8. The method of claim 2 further comprising: generating a first dominant objects counter associated with the first party and a second dominant objects counter set associated with the second party; in response to determining that the element in the second local object dominates the element in the first local object, incrementing a counter included in the first dominant objects counter set that is associated with the element in the first local object; encrypting the first dominant objects counter set; and decrypting the first dominant objects counter set to determine dominant Skyline objects in the first party.

9. The method of claim 8, wherein the encrypting the first dominant objects counter set comprises: encrypting the first objects counter set based on a first public key associated with the first party.

10. The method of claim 1, wherein the at least one global skyline object comprises data associated with at least one of a portfolio risk metric or final margin calculations.

11. The method of claim 10, wherein the portfolio risk metric comprises at least one of equity, liability, margin usage, or value at risk.

12. The method of claim 1, wherein the at least one global skyline object comprises data associated with a credit risk metric.

13. The method of claim 12, wherein the credit risk metric is a counterparty credit risk. 14 The method of claim 1, wherein the first random integer is a thirty -two bit integer.