mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
abf99d05fc
Restructured from flat .tex/.pdf files into per-paper subdirectories. Added Antje Worring as co-author on all papers. Synced PDFs to pdfs/ for download site.
69 lines
3.0 KiB
TeX
69 lines
3.0 KiB
TeX
\section{Encrypted State Transitions}
|
|
|
|
\label{sec:state-transitions}
|
|
|
|
\subsection{State Model}
|
|
|
|
In the FHE VM, contract state variables are stored as ciphertexts. A contract's
|
|
storage maps \texttt{bytes32} keys to FHE ciphertexts:
|
|
|
|
\[
|
|
\textsf{State}: \texttt{bytes32} \to \textsf{FHECiphertext}
|
|
\]
|
|
|
|
An encrypted state transition $T$ transforms encrypted state $S$ to encrypted
|
|
state $S'$:
|
|
\[
|
|
S' = T(S, \textsf{ct}_{\text{input}})
|
|
\]
|
|
|
|
where $\textsf{ct}_{\text{input}}$ is the encrypted transaction input. The transition
|
|
$T$ is a composition of homomorphic operations (addition, multiplication, comparison)
|
|
applied to encrypted values. At no point during execution does any plaintext value
|
|
appear in the EVM state, logs, or transaction receipt.
|
|
|
|
\subsection{Encrypted ERC-20 Token}
|
|
|
|
As a concrete example, consider an encrypted ERC-20 token where balances are FHE
|
|
ciphertexts:
|
|
|
|
\begin{algorithm}[ht]
|
|
\caption{Encrypted ERC-20 transfer (pseudocode).}
|
|
\label{alg:encrypted-transfer}
|
|
\begin{algorithmic}[1]
|
|
\Require Sender $s$, receiver $r$, encrypted amount $\textsf{ct}_{\text{amt}}$
|
|
\Require Encrypted balances $\textsf{ct}_{s}$, $\textsf{ct}_{r}$
|
|
\State $\textsf{ct}_{\text{sufficient}} \leftarrow \textsf{FHE.GTE}(\textsf{ct}_{s}, \textsf{ct}_{\text{amt}})$ \Comment{Encrypted comparison}
|
|
\State $\textsf{ct}_{s}' \leftarrow \textsf{FHE.CMux}(\textsf{ct}_{\text{sufficient}}, \textsf{FHE.Sub}(\textsf{ct}_{s}, \textsf{ct}_{\text{amt}}), \textsf{ct}_{s})$
|
|
\State $\textsf{ct}_{r}' \leftarrow \textsf{FHE.CMux}(\textsf{ct}_{\text{sufficient}}, \textsf{FHE.Add}(\textsf{ct}_{r}, \textsf{ct}_{\text{amt}}), \textsf{ct}_{r})$
|
|
\State Store $\textsf{ct}_{s}'$ and $\textsf{ct}_{r}'$
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
The \textsf{FHE.CMux} (conditional multiplexer) selects between two encrypted values
|
|
based on an encrypted condition bit, implementing the balance check without revealing
|
|
whether the sender has sufficient funds.
|
|
|
|
\subsection{Verification of Encrypted Transitions}
|
|
|
|
A challenge unique to FHE smart contracts: validators cannot verify the correctness
|
|
of encrypted state transitions by re-executing on plaintext (they don't have the
|
|
plaintext). Instead, validators verify:
|
|
|
|
\begin{enumerate}[leftmargin=2em]
|
|
\item \textbf{Ciphertext well-formedness}: Every input ciphertext has noise within
|
|
the valid range and was encrypted under the contract's public key.
|
|
\item \textbf{Operation correctness}: Each homomorphic operation was applied
|
|
correctly (deterministic given the ciphertexts and operation type).
|
|
\item \textbf{Noise budget}: The output ciphertext's noise level does not exceed
|
|
the decryption threshold.
|
|
\end{enumerate}
|
|
|
|
Since FHE operations are deterministic given the same inputs, validators can re-execute
|
|
the homomorphic computation on the ciphertexts and verify that the output matches.
|
|
This does not require knowledge of the plaintext.
|
|
|
|
%% ========================================================================
|
|
%% 5. FHE VM ARCHITECTURE
|
|
%% ========================================================================
|