Secure Financial Auctions and Credit Using Homomorphic Encryption

This article explores the application of encryption in financial infrastructure, focusing on three distinct examples: auctions, hybrid credit and insurance, and market implementations. The core idea is to leverage homomorphic encryption and multi-party computation to enable secure and private financial transactions without relying on trusted third parties.

Encrypted Auctions

Auctions are frequently used but typically involve a third-party auctioneer. This can lead to potential abuses, such as an auction manager manipulating bids to drive up prices, as seen in the example of Mortgage Capital Trading's use of a trade auction manager or the issues with P2P platforms in China. The goal is to conduct an auction without an auctioneer, using homomorphic encryption and multi-party computation.

Scheme 1: Bidder-Owned Servers

In this scheme, each bidder operates their own server. There are no third-party servers or contract nodes. 1. Bid Encryption: Each buyer encrypts their bid using public-private key pairs (as in homomorphic encryption) and sends the encrypted bid to other bidders. 2. Multi-Party Computation: The results of these encrypted messages are then exchanged among the bidders.

The BFV encryption algorithm, based on ring learning with error, is used. This involves polynomials with integer coefficients modulo some order polynomials. The public key (a, delta) is common, while secret keys (s, e) are agent-specific. Noise is added to prevent deciphering of the secret information.

Example with Two Bidders (A and B): * Agent A encrypts their bid and sends it to B. B cannot interpret it due to the secret key and error. * Agent B does the same, sending an encrypted bid to A. * Each agent then holds the ciphertext from the other. Agent A adds their own secret key pair to B's ciphertext, and B does the same for A's ciphertext.

• The difference between these transformed ciphertexts reveals `delta
• (bid_A - bid_B)`.
• While this reveals which bid was higher, it also reveals the exact bid values to both players, which is not ideal for privacy. This method is more problematic with more than two agents, as collusion could reveal bids.

Scheme 2: Contract Node

This scheme introduces a contract node (a third-party server running code, referred to as a pseudo-agent). 1. Centralized Communication: All communication goes to this contract node. 2. Encrypted Bids to Pseudo-Agent: Bidders send their encrypted bids to the pseudo-agent. 3. Additional Ciphertext: The pseudo-agent also requests additional ciphertext from each bidder, consisting of the sum of their private keys, also encrypted. 4. Pseudo-Agent Computation: The pseudo-agent performs the computations that the individual agents would have done in Scheme 1, but without ever having access to the bidders' secret keys. It receives the ciphertexts, adds error terms and other parts of the secret key (acting on behalf of each party), and performs algebraic operations to determine the difference in bids.

Generalized Multi-Party Computation (MPC) for More Than Two Agents: 1. Key Pair Generation: Each agent generates a public encryption key and a private decryption key. 2. Public Key Submission: All agents submit their public keys to the server. 3. Joint Public Key Creation: The server combines all public keys into a single shared joint public key. 4. Joint Public Key Distribution: This joint public key is distributed back to all agents. 5. Data Encryption: Agents use the common public key to encrypt their private data (bids), generating ciphertext. 6. Ciphertext Submission: Each agent sends their ciphertext to the server. 7. Encrypted Computation: The server performs computations on all the encrypted data, producing an encrypted result (Fully Homomorphic Encryption - FHE). 8. Encrypted Result Distribution: The server sends the encrypted result back to each agent. 9. Partial Decryption: Each agent uses their private key to partially decrypt the answer. 10. Partial Decryption Submission: Agents send their partially decrypted parts back to the server. The number of agents required for partial decryption to still yield an encrypted result can be chosen beforehand. 11. Final Decryption: The server combines the results of all partial decryptions to produce the final decrypted result, which is then shared with all agents.

This sequence allows for secure auctions with multiple participants, ensuring privacy while determining the outcome.

Addressing Complexity with More Than Two Agents: * Pairwise Comparisons: Use the two-agent case as a building block, making pairwise comparisons to deduce the highest bid. This can be computationally intensive for many agents. * Subgroup Division: Divide agents into subgroups, compute averages of encrypted bids within each subgroup, and eliminate bids lower than the average. This reduces the number of potential winners and comparisons.

Hybrid Credit and Insurance

This application addresses borrowing and lending with insurance, particularly against balance sheet shocks. Three contexts are provided: * Kenya (M-Pesa): Telecom agents need to carry inventory of both fiat money and e-credit. They informally help each other with liquidity, but revealing balance sheet status can be problematic. * Indonesia (Commercial Banks): Kiosk-based banks also face liquidity issues and struggle to find willing partners for rebalancing without revealing their financial state. * New York Markets (Broker-Dealers): Repo markets experience periodic liquidity problems, where broker-dealers run out of cash, leading to interest rate spikes.

The common element is that these entities have balance sheets, mediate trades, and experience random shortages. They need to make deals but want to avoid revealing their balance sheet status.

The Problem: * Ex ante insurance is beneficial for smoothing idiosyncratic liquidity shocks. * However, revealing shocks too quickly can damage beneficial trade. If a loss is known, the insured party might wait to enter a contract, making insurance impossible. Concealing past losses can enable insurance.

Formalizing with Mechanism Design: * Two Agents (A and B), Two Periods: A planner mediates. * Private Shocks: Agents have utility functions subject to privately observed shocks (e.g., to preferences, which can represent balance sheet urgency). * Revelation Principle: Agents truthfully report their shocks to the planner. * Planner's Role: The planner sees messages but ensures other agents don't. It's trusted not to reveal information. * Incentives: Incentives are designed for truth-telling. * Concealment: Concealing what happened in the first period is crucial to enable insurance in the second period, as full revelation can hinder trade.

Example Scenario: * Agent A has an unknown parameter (0.2 or 0.9) at date 0, known at date 1 (0.3). * Agent B has a known parameter at date 0 (0.9), unknown at date 1 (0.2 or 0.9). * Endowments are deterministic (5 for each agent, total 10). * Fully Revealed Communication: If information is fully revealed, insurance for Agent B is limited. For instance, if Agent A is patient, Agent B's allocation is the same regardless of their parameter at date 1. Lotteries are introduced to incentivize truth-telling, but overall insurance is suboptimal. * Concealed Information: By concealing information, better insurance can be achieved. The allocation at date 0 remains the same, but the probability distribution of outcomes changes. Agent B cannot definitively know Agent A's state, which allows for beneficial insurance. Lotteries are still used to deter lying.

Implementing with Encryption: * The central planner is replaced by code (a pseudo-agent). * Risk Pooling Contract: Agents agree to a contract, putting their assets in escrow, accessible by the code. * Communication Flow: Messages are exchanged between agents (encrypted) and between agents and the code. This involves both FHE (code acting on encrypted messages) and MPC (agents exchanging messages before submission to code). * Algebraic Properties: The encryption scheme must satisfy properties like commutativity and distributivity.

How it Works (Simplified): 1. Pre-Play Messages (A to B): Agent A sends two encrypted values to B: one for a high liquidity need (hA) and one for a low liquidity need (lA). The order is random and unknown to B. A also sends an encrypted vector (1,0 or 0,1) indicating the order. 2. B to C: B encrypts A's encrypted messages and sends them to the code (C). 3. Realized Parameter (A to B): When A's actual liquidity need is realized, A encrypts this value (m) and sends it to B. 4. B to A (Null Reference): B sends an encrypted null reference to A. 5. A to C: A encrypts the null reference. The code receives the encrypted value of A's message and the encrypted null reference. 6. B to A (Difference): B sends to A the encrypted difference between A's actual value and the pre-play messages. 7. A to C (Pair): A encrypts this pair of differences and sends it to C.

This complex exchange ensures that neither A nor B learns the other's private information, but the code receives enough information to determine when to randomize allocations. The code can effectively figure out if the actual realized value was sent first or not, thus knowing the ordering without knowing the actual message. This allows the code to implement the randomized allocations that provide better insurance.

Order Book Matching

This application focuses on matching orders in a market, such as repo. * Two Dealers: Dealers exchange assets (e.g., treasuries for money). * Pointwise Orders: Dealers submit orders (e.g., "1 Treasury for 1 Money," "2 T for 2 M"). * Escrow: The maximum amount of assets involved in potential trades is put into escrow by each dealer. * Encrypted Messages: Each trade order (T for M or M for T) is encrypted. * Code Matching: The code uses a comparison operator on these encrypted messages to find matches (e.g., "2 T for 2 M"). * Privacy: Agents do not have to reveal their orders, preventing issues like front-running.

This system uses smart contracts and encryption to facilitate trades securely and privately.

Current Limitations and Future Outlook

While these applications demonstrate the power of encryption in financial infrastructure, there are practical limitations: * Blockchain Integration: Running these encryption schemes directly on a fully validated blockchain is still challenging. Most examples operate off-chain or on layer 2 solutions. * Computational Cost: Fully homomorphic encryption can be computationally intensive. * Ongoing Research: Companies like Zama and Sunscreen are making progress in enabling encryption on the blockchain, but there's a need for more effective solutions in terms of multiplication, addition, and comparison operations.

Despite these challenges, there is confidence that fully operational encryption schemes will run on blockchains in the near future, addressing critical needs in areas like wholesale CBDC design.