Theoretical Background

This chapter presents the set of concepts required to follow the remainder of the work. The premise adopted is that the reader needs no prior knowledge of the domain. Each thematic block is introduced from the most elementary level and developed up to the point where it connects directly with the solution proposed in §4.2. The order of topics goes from the outermost (the public blockchain infrastructure) to the innermost (the theory of the auction mechanism), passing through the cryptographic pillars that make the intersection between the two possible.

2.1 Blockchain and smart contracts

This section builds the base concepts: what a blockchain is (§2.1.1), Bitcoin as a starting point (§2.1.2), Ethereum's leap into programmability (§2.1.3), the EVM's execution and cost model (§2.1.4) and, finally, the public observability of the mempool (§2.1.5), the property that connects this background to the central problem of the work.

2.1.1 What a blockchain is

A blockchain is a public ledger (an official, chronological record of transactions), distributed and replicated across a network. Its central data structure is a chain of blocks, each containing a set of transactions. Each block carries the result of a cryptographic hash function (a deterministic transformation that produces a short, unique value from any input) applied to the previous block, forming a chain that makes it infeasible to alter old records without invalidating every later block (NAKAMOTO, 2008). Combining that structure with a consensus protocol, which defines which is the next valid block, allows multiple participants to keep an identical copy of the ledger without having to trust one another or a central authority.

By way of a controlled analogy, one may think of the blockchain as a notebook kept in sync by several auditors scattered around the world. Each new page is proposed by an auditor and validated collectively; once accepted, it is sealed and distributed. Later attempts to tamper with old pages fail because each seal depends on all previous seals. The difference from traditional records is that nobody needs to own the notebook: the notebook is the sum of the copies held by the auditors.

2.1.2 Bitcoin as a starting point

The first practical realisation of that architecture was Bitcoin, described by Nakamoto (2008) in a short and influential whitepaper¹. Bitcoin defined a decentralised digital-currency protocol operating over a public blockchain, with transactions signed by cryptographic keys and validated by a Proof of Work consensus mechanism, in which participants compete to solve a computationally expensive problem, and the first to find the solution earns the right to propose the next block and receive a reward. The script embedded in Bitcoin transactions is deliberately limited: it allows signature checks and some conditional operations, but is not Turing-complete, that is, it supports neither loops nor arbitrary computation.

That simplicity was a design choice, meant to minimise the attack surface and guarantee termination. The cost, however, was the impossibility of programming sophisticated behaviours on top of Bitcoin without resorting to external layers. That was the trigger for the next generation of blockchains.

2.1.3 Ethereum and the leap into programmability

Ethereum, proposed by Buterin (2014) in the foundational whitepaper and formalised by Wood (2014) in the Yellow Paper², generalised the blockchain idea by introducing a Turing-complete execution model. Every node in the network runs an abstract virtual machine, the Ethereum Virtual Machine (EVM), capable of processing arbitrary bytecode³. The programs stored on the blockchain are called smart contracts, and can implement any computable logic within the limits of the resources available.

The practical consequence is profound. Instead of the blockchain executing only balance transfers, it comes to execute programs: auctions, token markets, governance systems, price oracles, lending schemes, decentralised vaults. The cost of that expressiveness is that every operation executed must be paid for in an internal unit called gas, calibrated to reflect the computational, storage and communication cost imposed on the network.

Smart contracts on Ethereum are typically written in Solidity, a high-level language that compiles to EVM bytecode. The life cycle is simple: a contract is deployed through a special transaction, receives a unique address and starts to expose public functions that other contracts or users may invoke. The contract's state (its variables in persistent memory) is kept on the blockchain and updated by each successful call.

2.1.4 EVM, gas and transactions

The EVM is a stack machine with arithmetic, logical, control-flow, storage read/write and inter-contract communication instructions (WOOD, 2014). Each instruction has an associated gas cost. When a user sends a transaction, they declare a maximum amount of gas they are willing to spend and a unit price in the network's currency. The transaction runs until it reaches the limit or terminates normally; if it reaches the limit, the state is reverted, but the gas consumed up to that point is still charged.

This model serves three purposes. First, it prevents infinite loops and denial-of-service attacks, since every execution has a finite cost. Second, it creates an implicit priority auction: transactions that pay more per unit of gas tend to be included sooner. Third, it provides an objective and comparable measure of computational cost, a property that will be exploited extensively in the evaluation of Chapter 5.

Every transaction goes through three stages: it is created and signed by the user's wallet, it is propagated across the peer-to-peer network⁴ and becomes visible in a waiting area called the mempool, and finally it is included in a block by a block producer (a validator⁵, in the case of current Ethereum, which has operated under Proof of Stake since 2022). These three stages are public and observable by any node in the network.

2.1.5 Mempool and public observability

The mempool is the critical point for the central problem of this work. Although it is an implementation detail rather than a structure formally fixed in the protocol, it is, in practice, the space where pending transactions sit exposed until they are confirmed. Any node can read the mempool. Bots, validators and adversarial observers read it all the time (DAIAN et al., 2020).

This observability does not follow from an implementation flaw, but from the fact that, for a transaction to be included in a block, it must have been propagated across the network beforehand. Transparency is the counterpart of decentralisation: for multiple nodes to reach agreement on which is the next block, all of them need to know the candidate transactions. Any privacy mechanism applied on top of a public blockchain must deal with that property. In particular, any mechanism that intends to hide auction bids must guarantee that the content of the bid, and not merely its existence, remains inaccessible throughout the exposure window.

The literature proposes stopgaps for this exposure. Private mempools such as Flashbots Protect⁶ hide the individual transaction from the public mempool, but require trust in the service operator and fragment the network.

Threshold encryption schemes (in which decryption happens only when a minimum fraction of the holders of key shares cooperate) at the consensus level promise to encrypt transactions until block inclusion, but they involve honesty assumptions among validators (for instance, that a majority fraction will not cooperate to censor or reorder transactions) that have not yet been realised in production. Deterministic ordering by timestamp eliminates part of the reordering, but does not attack observation-based frontrunning. Across all of these approaches, what one observes is a recurring pattern: the mitigations reduce the attack surface along one dimension and displace it to another.

2.2 Cryptography: from the fundamentals to FHE

This section walks the cryptographic trail that culminates in FHE: the symmetric and asymmetric fundamentals (§2.2.1), hash functions (§2.2.2), the concept of homomorphism (§2.2.3), partially homomorphic constructions (§2.2.4), Gentry's breakthrough (§2.2.5) and the evolution of the schemes up to TFHE (§2.2.6).

2.2.1 Symmetric and asymmetric cryptography

Modern cryptography, in its broadest sense, studies how to transform messages so as to make them intelligible only to authorised recipients. Two major paradigms dominate the literature.

Symmetric cryptography uses a single key shared between sender and receiver. The same key that encrypts is the one that decrypts. This paradigm is computationally efficient and is the basis of ciphers such as the Advanced Encryption Standard (AES). The burden, however, is the key distribution problem: for two parties to communicate securely, they must first have exchanged a secret key over some secure channel.

Asymmetric cryptography, or public-key cryptography, solves that problem. Each participant holds a pair of mathematically related keys: a public one, which may be disclosed to anyone, and a private one, kept secret. What is encrypted with one can only be decrypted with the other. The construction was proposed in seminal form by Diffie and Hellman (1976), in an article entitled New directions in cryptography. Shortly afterwards, Rivest, Shamir and Adleman (1978) published RSA, the first concrete and widely adopted public-key encryption scheme. The central idea enables two fundamental operations. First, anyone can encrypt a message for the holder of the private key, ensuring confidentiality in communication. Second, the holder of the private key can produce a signature over the message that any other participant can verify, ensuring authenticity and integrity.

On public blockchains, asymmetric cryptography is what allows each user to have an identity (represented by the public key, or by an address derived from it) and to sign transactions without revealing the private key.

2.2.2 Cryptographic hash functions

Cryptographic hash functions are deterministic functions that take an input of arbitrary size and produce an output of fixed size. Functions such as SHA-256, used in Bitcoin (NAKAMOTO, 2008), and Keccak-256, used in Ethereum (WOOD, 2014), are designed to satisfy three key properties: they are one-way, since, given a hash, it is computationally infeasible to recover the original input; they are collision-resistant, since it is infeasible to find two distinct inputs that produce the same hash; and they are deterministic, since the same input always yields the same output.

Hash functions are ubiquitous in cryptographic systems. They form the backbone of the block chaining described in the previous section, underpin structures such as Merkle trees, are part of digital signature schemes, and are the central ingredient of the commit-reveal scheme discussed in §1.2.3.

2.2.3 The concept of homomorphism in cryptography

In algebra, a function $f$ is said to be homomorphic with respect to an operation $\circ$ when $f(a \circ b) = f(a) \circ f(b)$. Carried over into cryptography, the concept yields a peculiar property: there are schemes in which operations over the ciphertext correspond to operations over the plaintext. Applying an addition over two ciphertexts (encrypted texts, that is, messages already transformed by encryption), for example, and then decrypting, produces the same result as adding the plaintexts and decrypting.

This property makes it possible to delegate computation over confidential data to untrusted parties: the untrusted party manipulates ciphertexts and returns a result ciphertext, without ever having access to the plaintexts involved. The recipient, holding the private key, decrypts only the final result (GENTRY, 2009).

2.2.4 Partial constructions: additive and multiplicative

Schemes with homomorphic properties have existed since the 1970s, but they supported only one of the basic algebraic operations, not both simultaneously.

RSA, proposed by Rivest, Shamir and Adleman (1978), is multiplicatively homomorphic: the product of two ciphertexts decrypts as the product of the plaintexts. Schemes such as ElGamal share that property. Other schemes, such as that of Paillier (1999), are additively homomorphic: the sum (in an appropriate field) of two ciphertexts decrypts as the sum of the plaintexts. These constructions are called partially homomorphic, or Partially Homomorphic Encryption (PHE).

Although useful in specific applications, such as electronic voting and statistics over encrypted data, partial constructions are limited. Arbitrary computations require combining additions and multiplications, and no classical scheme offered that combination. For over three decades, the existence of a construction that would allow arbitrary functions to be computed over encrypted data was an open problem.

2.2.5 Gentry and the first viable FHE

Gentry (2009), in his doctoral thesis at Stanford, presented the first truly viable Fully Homomorphic Encryption (FHE) scheme. The construction starts from a partially homomorphic scheme based on lattices and introduces a technique called bootstrapping: with each operation, the ciphertext accumulates noise that grows with the complexity of the computation; when the noise approaches a threshold, bootstrapping applies a homomorphic decryption that reduces the noise without needing access to the private key. The result is a scheme capable of computing functions of arbitrary depth.

The original construction was extremely costly in computational terms and impractical for any real application. Its importance, however, was conceptual: it proved that FHE exists and opened the way for a rapid succession of improvements.

2.2.6 Evolution: BGV, BFV, CKKS and TFHE

After Gentry's work, the community developed several families of FHE schemes, each optimised for specific kinds of workload.

The BGV scheme, proposed by Brakerski, Gentry and Vaikuntanathan in 2014, was an efficiency milestone in homomorphic computation over exact integers. It drastically reduced the cost of each operation through modulus-switching techniques that avoid the need for bootstrapping in circuits of bounded depth known at compile time. BFV, whose acronym combines the authors Brakerski, Fan and Vercauteren, was built in two stages. Brakerski (2012) proposed a scale-invariant scheme based on the Learning With Errors problem (LWE, formalised in §2.4.2), an alternative to BGV in that it dispenses with modulus switching and keeps noise growth linear in the number of homomorphic multiplications. Fan and Vercauteren (2012) then ported that construction to the polynomial ring (RLWE), making it computationally efficient. Also aimed at exact integers, BFV is widely used in libraries such as SEAL (Microsoft) and PALISADE.

The CKKS scheme, proposed by Cheon, Kim, Kim and Song in 2017, specialised in approximate arithmetic over real or complex numbers. Instead of encrypting exact integers, it encrypts reals with a controlled precision, making it the natural choice for applications in machine learning and statistics over encrypted data.

Finally, the TFHE scheme, initially proposed by Chillotti, Gama, Georgieva and Izabachène in 2016 and extended in Chillotti et al. (2020a), operates on the torus, a mathematical structure that allows an extremely fast bootstrapping to be built, on the order of a few tens of milliseconds. Instead of operating over large vectors of integers as BGV/BFV do, TFHE is optimised for Boolean circuits and for operations of low arithmetic depth interleaved with evaluations of non-linear functions. That characteristic is exactly what makes TFHE suitable for smart contract applications, where comparison, conditional selection and bit-manipulation operations are frequent.

The CONCRETE library, published by Chillotti et al. (2020b) at the WAHC workshop, is the reference implementation of TFHE maintained by Zama, and is the basis on which on-chain FHE platforms such as Zama's own fhEVM and Fhenix CoFHE are built.

2.3 TFHE and the Fhenix CoFHE platform

This section brings the theory closer to the platform adopted: how TFHE works at a high level (§2.3.1), the encrypted types exposed by Fhenix (§2.3.2), the homomorphic operations relevant to the contract (§2.3.3), the architecture of the CoFHE coprocessor together with the Threshold Services Network (§2.3.4) and the TSN decryption flow (§2.3.5) that the implementation in this work employs.

2.3.1 TFHE at a high level

Without going into the details of the mathematical machinery, TFHE can be understood from three design decisions. First, it encrypts values based on a hard computational problem called Learning With Errors over the torus, introduced in its classical version by Regev (2005). The ciphertext is a vector of numbers that carries the plaintext disguised by controlled random noise. Second, the homomorphic operations are defined as manipulations over those vectors that preserve the noise-to-plaintext relation, with the noise growing at every step. Third, bootstrapping acts as a noise-reduction operation that can, at the same time, evaluate an arbitrary function over the disguised plaintext, turning a maintenance operation into a useful one.

The practical consequence is that TFHE allows arbitrary circuits to be built over ciphertexts, with the dominant cost concentrated in each bootstrapping call. Simple operations (additions, multiplications by constants) are cheap; operations that involve comparisons or conditional selections (such as gt, eq and select) usually trigger bootstrapping and are therefore orders of magnitude more expensive. That difference will be central to the gas analysis in Chapter 5.

2.3.2 Encrypted types in Fhenix

Fhenix (2026a) is an FHE platform for EVM-compatible blockchains. At its core is a coprocessor called CoFHE (Confidential FHE coprocessor) that attaches to existing chains such as Ethereum, Arbitrum and Base, without requiring a dedicated network. The coprocessor architecture is, broadly speaking, the same as the one adopted by Zama's fhEVM in its current version (HINDI, 2024); the substantive difference between the two platforms lies in the decryption model, detailed in §2.3.4. The platform provides a Solidity library, @fhenixprotocol/cofhe-contracts/FHE.sol, which offers the following native encrypted types:

• euint8, euint16, euint32, euint64 and euint128: encrypted unsigned integers, with the indicated number of bits;
• ebool: encrypted Boolean values;
• eaddress: encrypted wallet addresses.

To receive a value encrypted by the client, Fhenix uses structures called InEuint* (for example, InEuint64). The client encrypts the value in the browser using the @cofhe/sdk package, based on TFHE in WebAssembly (WASM), and the library produces a struct containing the handle (a short reference to a ciphertext, similar to a pointer) and the signature of the CoFHE verifier. The contract converts that struct into an internal euint64 by calling FHE.asEuint64(encInput), without having to deal directly with the raw ciphertext.

Ciphertexts are large objects (on the order of tens of kilobytes for 64-bit types), and storing them in full in storage (the blockchain's persistent memory, in which a contract's data survives between calls and whose use is paid for in gas) would be prohibitively expensive. Fhenix works around this by means of symbolic execution: storage on the blockchain keeps only handles, deterministic identifiers derived from the operation and its operands, while the actual ciphertexts and the FHE computation are delegated to the off-chain coprocessor (executed outside the main blockchain), as detailed below (FHENIX, 2026b).

2.3.3 Relevant homomorphic operations

Fhenix's FHE.sol library exposes a set of homomorphic operations in Solidity analogous to the one offered by other on-chain FHE platforms. For the purposes of this work, the most relevant operations are the following.

The FHE.add(a, b) operation takes two integer ciphertexts and returns the ciphertext of their sum. The variants FHE.sub and FHE.mul cover subtraction and multiplication, at increasing cost. The FHE.gt(a, b) operation returns an encrypted ebool indicating whether the first operand is greater than the second, without revealing either of them. The variants FHE.lt, FHE.eq, FHE.ne, FHE.gte and FHE.lte cover the remaining comparisons. The FHE.select(c, a, b) operation takes an encrypted ebool c and two ciphertexts a and b, returning a if c is true and b otherwise, without revealing which branch was taken. This operation is the encrypted equivalent of a ternary operator and is a key piece of the homomorphic masking technique used in the solution proposed in §4.2.

There are also Boolean logic operations that combine ebool ciphertexts: FHE.and, FHE.or and FHE.not. Combined with FHE.eq and FHE.select, they make it possible to express the deterministic first-match pattern used to handle ties between equal bids, detailed in §4.2. The FHE.max(a, b) operation returns the greater of two integer ciphertexts without revealing which one it is, and is used to find the winning bid by homomorphic tournament.

For access control over handles, the library exposes three primitives. FHE.allowThis(handle) authorises the contract itself to operate over a ciphertext in future calls, without which the handle is not reusable. FHE.allow(handle, address) authorises a specific address to decrypt the ciphertext, useful, for instance, so that the winner of an auction can recover their own bid. FHE.allowPublic(handle) marks the ciphertext as publicly decryptable, allowing any participant to request decryption from the threshold network described in subsection 2.3.5.

2.3.4 Architecture: CoFHE and the Threshold Services Network

Fhenix's architecture is composed of three layers (FHENIX, 2026b). The Solidity contracts run normally on a conventional EVM chain, such as Ethereum, Arbitrum or Base, that is, on-chain (executed and recorded inside the main blockchain, with all of its costs and guarantees). CoFHE is an off-chain network of coprocessors that stores the actual ciphertexts and executes, in a pipeline, the homomorphic operations requested by the contracts. The Threshold Services Network (TSN) is a third layer, dedicated exclusively to decryption: it holds the decryption key distributed among multiple participants via secret sharing (a cryptographic technique in which a secret is split into shares such that only the combination of a minimum number of shares allows it to be reconstructed), and no decryption occurs unless at least t out of N participants cooperate; that minimum number of participants is what is called a quorum.

The typical flow of an encrypted operation is as follows. The Solidity contract receives a handle as input (coming from an earlier call or from a freshly converted InEuint* struct). When the contract calls an operation such as FHE.gt(handleA, handleB), the EVM in fact executes a command that records the operation and produces a new handle for the result. The actual computation, over the large ciphertexts, is executed by CoFHE, which maintains the correspondence between handles and ciphertexts. The contract can chain as many operations as it wishes, manipulating handles, without any ciphertext ever entering the blockchain's storage.

Both Fhenix and Zama's fhEVM (ZAMA, 2024; HINDI, 2024) operate, in their current version, with decryption distributed via threshold Multi-Party Computation⁷. The substantive difference between the two platforms lies in the orchestration of the reveal flow, detailed in §2.3.5: Zama operates through an oracle callback inside the contract (an automatic call that an external service triggers back into the contract when a value is ready to be delivered), whereas Fhenix exposes the TSN as a service queried by the client, with no callback. This contrast affects how the contract's life cycle must be modelled and is taken up again in §4.1.

The model is efficient in on-chain storage, but introduces coupling between three systems (the blockchain, CoFHE and the TSN). That coupling is one of the sources of the robustness discussion in Chapter 5.

2.3.5 Decryption via the TSN

The last piece of the architecture is decryption. At some point, the contract must expose a plaintext value to a user or to another contract. For example, at the end of the auction, the closing price and the identity of the winner must be published so that payment can be made. In Fhenix, this is done through a client-orchestrated flow, instead of the in-contract oracle callback adopted by Zama's fhEVM.

When the contract decides that a given ciphertext should become accessible, it calls FHE.allowPublic(handle). That handle becomes publicly decryptable, but the decryption itself happens outside the contract. An off-chain client (the user's frontend, a designated bot or any interested participant) queries the TSN via the SDK and receives the plaintext value accompanied by a collective signature from the threshold network. That value is then published back on-chain in a subsequent transaction, for example finalizeSettlement(clearPrice, clearWinner), and the contract verifies, with FHE.verifyDecryptResult, that the plaintext values do in fact correspond to the encrypted handles marked earlier.

The total latency of this operation is dominated by the round trip with the TSN and by the subsequent publication transaction, not by block time itself. The difference from Zama's fhEVM lies in who orchestrates the decryption. In Zama, the oracle triggers a callback inside the contract, leaving it passive while it awaits the oracle's call. In Fhenix, it is an external participant that decrypts via the TSN and publishes the result, leaving the contract passive while it awaits that publication. In both cases decryption is asynchronous and imposes on the developer the need to model the contract's life cycle as an explicit state machine (for example, distinguishing the bidding phase, the reveal-request phase and the settlement phase), with provision for a timeout should no participant publish the result in good time.

2.4 Resistance to quantum attacks

This section justifies a relevant side property of the cryptographic choice. It presents the quantum threat to classical cryptography (§2.4.1), the family of lattice problems on which TFHE rests (§2.4.2), the argument that makes it considered quantum-resistant (§2.4.3) and the practical reason why that matters in immutable public records (§2.4.4).

2.4.1 Quantum computing and classical cryptography

Quantum computing is a computational model that uses properties of quantum mechanics (superposition, entanglement, interference) to perform certain tasks at a significantly lower computational cost than classical computers as the problem size grows. Although quantum computers large enough to represent a concrete threat do not yet exist, two quantum algorithms published in the 1990s showed that the eventual arrival of such computers compromises substantial parts of classical cryptography.

The first is Shor's algorithm (SHOR, 1994), which solves the integer factorisation problem and the discrete logarithm problem in polynomial time on a quantum computer. Since the security of RSA depends on the hardness of factorisation, and the security of elliptic-curve-based schemes (including the signatures used in Bitcoin and Ethereum) depends on the discrete logarithm, both schemes become insecure in the presence of a quantum computer of sufficient scale.

The second is Grover's algorithm (GROVER, 1996), which quadratically speeds up search in unstructured spaces. For symmetric cryptography and hash functions, the effect is less catastrophic: doubling the key size (for instance, moving from AES-128 to AES-256) restores the same level of security. For asymmetric cryptography, however, there is no analogous countermeasure, and the problem must be attacked by replacing the scheme entirely.

2.4.2 Lattice-based cryptography and LWE

The cryptographic community's response to the quantum threat was the search for computational problems that remain hard even for quantum computers. That field became known as post-quantum cryptography (PQC). The United States National Institute of Standards and Technology (NIST) conducted, over the course of the 2010s, a standardisation process for PQC schemes, which culminated in the finalisation of several families of algorithms as official standards.

Among the most promising families is lattice-based cryptography. Lattices are mathematical structures formed by integer combinations of vectors in a Euclidean space, and they admit computational problems (finding the shortest vector, finding the closest vector) whose hardness resists, as far as is known, efficient quantum algorithms.

The concrete computational problem that underpins most modern PQC constructions is Learning With Errors (LWE), introduced by Regev (2005). In essence, given a set of linear equations perturbed by noise, it is hard to recover the exact solution. The hardness of LWE can be reduced to the hardness of lattice problems, offering well-founded security guarantees.

2.4.3 Why TFHE is considered quantum-resistant

The relevance of LWE in this work is that TFHE, the scheme used by Fhenix CoFHE, is built precisely on a variant of the problem, LWE over the torus (Torus LWE) (CHILLOTTI et al., 2020a). Since the security of TFHE derives from the hardness of that problem (REGEV, 2005), and since the problem remains hard, within the current state of the art, even in the face of quantum attacks, it follows that TFHE is considered a scheme resistant to quantum attacks. It is worth noting that TFHE is not itself one of the post-quantum standards selected by NIST, which cover key-encapsulation mechanisms and digital signatures (such as Kyber and Dilithium); it does share with those standards, however, the same family of computational hardness (lattices and LWE), from which its security comes.

This property distinguishes TFHE from classical constructions based on RSA or elliptic curves. Even if an auction executed with FHE is recorded on a public blockchain and its ciphertexts remain available indefinitely, they will not become decryptable through the mere arrival of quantum computers. The signatures that authorise transactions on Ethereum, by contrast, are vulnerable: keys exposed today may be compromised in the future.

2.4.4 Harvest Now, Decrypt Later

This difference motivates a class of attacks called Harvest Now, Decrypt Later (HNDL). The idea is simple: the adversary collects encrypted data today and stores it, counting on the future advance of quantum computing to decrypt it. For systems with a short useful life, the risk is low. For systems where the data must remain confidential for decades, or where the records are immutable and public, as on a blockchain, the risk becomes substantial.

Mallick et al. (2025) and Ipsen (2026) discuss this class of attack in detail in the specific context of blockchains. Ipsen, in particular, stresses that the practical challenge is not so much the existence of PQC algorithms, already partly standardised, but the coordination of the migration in decentralised systems that lack central governance and were not designed for cryptographic agility.

For a confidential auction recorded on-chain, the quantum-resistant property of TFHE offers an important additional guarantee: the secrecy of the losing bids has no expiry date dictated by the evolution of quantum computing. It is a property that adds to the others and that reinforces the argument in favour of the architecture proposed in this work.

2.5 Auction theory

This section closes the background with auction theory: the basic typology (§2.5.1), the distinction between open and sealed formats (§2.5.2), the mechanism design framework (§2.5.3), the formal rules of the Vickrey auction (§2.5.4), the high-level proof of truthfulness (§2.5.5) and the reasons why this mechanism matters for fair allocation (§2.5.6).

2.5.1 Basic typology

An auction is a formal mechanism for allocating scarce goods based on competitive offers from participants. The classical literature identifies four canonical single-unit auction formats, described in detail by Krishna (2009).

The English auction (or open ascending auction) is the most familiar format: the auctioneer opens the bidding with a reserve price and participants raise their offers in successive rounds; the last to bid wins and pays the value of their offer. The auction is open, in the sense that each bid is publicly observed by the other participants during the bidding.

The Dutch auction (or open descending auction) is the opposite: the auctioneer starts with a high price that decreases progressively, and the first participant to accept the current price wins, paying that amount. It is also open.

The first-price sealed-bid auction changes the paradigm. Each participant submits a single sealed offer, without knowing the offers of the others. At the end, the auctioneer opens all the offers and the highest bid wins, paying exactly the amount offered.

The Vickrey auction (second-price sealed-bid auction) is a variation on the previous one, with a change that seems small but has profound consequences: the highest bid wins, but pays only the value of the second-highest bid. That modification was proposed by Vickrey (1961), in an article that earned the author, decades later, the Nobel Prize in Economics.

2.5.2 Sealed-bid versus open-cry

The distinction between open-cry and sealed-bid auctions runs deeper than it first appears. In open auctions, each participant makes decisions sequentially, observing the bids of the competitors. In sealed-bid auctions, each participant decides in isolation, without that observation.

There is a known theoretical equivalence between some of these forms: the English auction with small increments is strategically equivalent to the Vickrey auction, under certain hypotheses, because the winner ends up paying, on average, the value of the second-highest bid (the runner-up's bid, at the moment they dropped out). Analogously, the Dutch auction is strategically equivalent to the first-price sealed-bid auction, because in both cases the participant must decide how much they are willing to pay without knowing the bids of the others (KRISHNA, 2009).

These equivalences, however, depend on hypotheses that are not satisfied in adversarial environments such as public blockchains, as discussed in Chapters 2 and 6. In particular, the property that makes the Vickrey auction attractive, truthfulness, presupposes that the bids remain effectively sealed.

2.5.3 Mechanism design

The field of mechanism design studies the design of interaction rules that induce socially desirable behaviours in environments where participants hold private information and pursue individual interests. Applied to auctions, it answers questions such as: which payment rule maximises the auctioneer's revenue? Which rule encourages participants to reveal their true values? Which rule is robust against collusion?

Krishna (2009) is the canonical reference for the modern treatment of the subject. The three researchers who contributed most to the foundations of the field (Hurwicz, Maskin and Myerson) received the Nobel Prize in Economics in 2007. The concept most relevant to this work is that of incentive compatibility, or truthfulness: a rule is said to be incentive-compatible when, for each participant, the strategy of revealing their true value is a dominant strategy, that is, it is the best response regardless of what the others do.

Incentive-compatible mechanisms have enormous practical appeal: they eliminate the need for the participant to compute sophisticated strategies, reduce the cost of participation and, in general, produce more efficient allocations. When applied to auctions, they give rise to the so-called truthful auctions, or Dominant Strategy Incentive Compatible (DSIC) auctions.

2.5.4 Vickrey: formal rules

To fix notation, consider a single-unit auction with $n$ participants. Each participant $i$ has a private value $v_i$ representing how much the item is worth to them. Each participant submits a bid $b_i$. The Vickrey rule (VICKREY, 1961) is as follows:

1. Allocation: the item is allocated to the participant with the highest bid, that is, $i^* = \arg\max_i b_i$ (the notation $\arg\max$ returns the index $i$ that maximises the bid $b_i$).
2. Payment: the winner pays the second-highest bid, that is, $p = \max_{i \neq i^*} b_i$.

In the event of a tie at the highest bid, some deterministic tie-breaking rule (for example, order of arrival) must be adopted. Participants who did not win pay nothing.

2.5.5 Truthfulness and a high-level proof

The central property of the Vickrey auction is the following theorem (VICKREY, 1961; KRISHNA, 2009): for each participant, bidding exactly their true value (that is, $b_i = v_i$) is a weakly dominant strategy. This means that, whatever the behaviour of the other participants, participant $i$'s outcome from bidding $v_i$ is at least as good as from bidding any other value.

The proof proceeds by case analysis. Consider a specific participant with value $v$, and let $p$ be the highest bid among the other participants (that is, the second-highest bid overall, from that participant's point of view).

Suppose the participant decides to bid $b > v$. There are three cases to consider. If $p < v$, the participant wins in both scenarios (bidding $b$ or bidding $v$) and pays $p$ in both cases: the outcome is the same. If $p > b$, the participant loses in both scenarios: the outcome is the same. If $v < p < b$, the participant loses by bidding $v$ (outcome: zero) and wins by bidding $b$, but pays $p$ for something worth only $v$: the outcome is negative, that is, $v - p < 0$. In no scenario is bidding $b > v$ strictly better than bidding $v$, and in at least one scenario it is strictly worse.

Now suppose the participant decides to bid $b < v$. Again there are three cases. If $p < b$, the participant wins in both scenarios and pays $p$: the outcome is the same. If $p > v$, the participant loses in both: the outcome is the same. If $b < p < v$, the participant loses by bidding $b$ (outcome: zero) and would win by bidding $v$, paying $p < v$ for something worth $v$: the outcome would be $v - p > 0$. Bidding $b < v$ is strictly worse in that scenario and is never strictly better.

Combining the two cases, bidding $b = v$ is never worse than any alternative, and in some scenarios is strictly better. The strategy $b = v$ is therefore weakly dominant. The argument depends critically on the payment rule (second price): if the winner paid their own bid, as in a first-price auction, bidding $v$ would cease to be optimal, since the participant would have an incentive to mask their true value in order to preserve margin.

2.5.6 Why Vickrey matters for fair allocation

The truthfulness property has relevant practical consequences on three fronts. First, it greatly simplifies the participant's strategic reasoning: it is enough to declare the true value, with no need to model the behaviour of the others. Second, it guarantees an allocation that is efficient in the economic sense, that is, the item goes to the participant who values it most, which maximises aggregate welfare (KRISHNA, 2009). Third, it is robust to asymmetric information: even if participants have very different levels of information about the asset being auctioned, all of them have an interest in revealing their true values.

For these reasons, the Vickrey auction occupies a privileged place in theory and in practical applications. Online advertising platforms, spectrum allocation systems, institutional markets and various other competitive allocation situations draw directly or indirectly on it. The condition that sustains those cases is, however, that the bids remain effectively sealed. When that condition fails, the mechanism loses the truthfulness property. The use of FHE in this work responds to that failure.

It is worth making explicit, finally, why it is the second-price rule, and not the first-price one, that makes the mechanism interesting. In a first-price auction, the winner pays what they bid, and therefore tends to bid below their true value in order to preserve margin (a practice known as bid shading); the bid ceases to reveal the true valuation. The second price removes that incentive, since the amount paid does not depend on one's own bid, and it is that which makes truth the optimal strategy. This subtle inversion is the contribution that earned Vickrey the Nobel Prize in Economics. For this work, it matters for two combined reasons: economically, it is the rule whose usefulness most depends on the secrecy of the bids, and which is therefore most harmed by on-chain transparency; technically, it is the computation of the second-highest value without revealing the winner that gives rise to the exclusion problem (§4.2.2), the central challenge of the implementation in this work.

2.6 Synthesis

The five bodies of knowledge presented throughout this chapter articulate directly in the solution proposed by the work. The public blockchain (§2.1) is the infrastructure on which the auction is executed, and whose public transparency creates the central problem. Classical cryptography (§2.2) provides the primitives (signatures, hashes) that sustain the basic operation of the network and that are insufficient to protect bids. FHE, in particular TFHE as realised by Fhenix CoFHE (§2.3), provides the tool that makes it possible to run the mechanism's computation over encrypted data. TFHE's quantum-resistance property (§2.4) reinforces the long-term robustness of the secrecy guarantee. And auction theory (§2.5) provides the Vickrey mechanism, with its truthfulness property, which defines what needs to be computed and why that property is essential.

The following chapters mobilise these elements in specific ways. Chapter 3 situates this work in relation to the literature. Chapter 4 develops the work in four integrated blocks: §4.1 formalises the problem and the threat model, §4.2 details the proposed solution, in particular the handling of the exclusion problem, §4.3 specifies and models the system, §4.4 describes the concrete implementation of the contract and of the graphical interface, and §4.5 consolidates the guarantees obtained by the architecture. Chapter 5 presents the evaluation methodology, the results collected and the corresponding discussion.