papers/lux-decentralized-cloud/sections/06-provider-portability.tex

\section{Provider Portability}
\label{sec:portability}

The fundamental sovereignty guarantee of the Lux provider model is
portability: a user can switch from provider $\mathcal{P}_1$ to
provider $\mathcal{P}_2$ without data loss, service interruption,
or requiring cooperation from $\mathcal{P}_1$.

\subsection{Portability Protocol}

The provider switch protocol proceeds in four phases:

\begin{enumerate}
    \item \textbf{Capability announcement.} User announces intent to switch
    by registering $\mathcal{P}_2$ as an authorized provider for the capsule
    on the I-Chain.

    \item \textbf{Data replication.} User's capsule client retrieves all
    encrypted blobs from $\mathcal{P}_1$ and uploads them to $\mathcal{P}_2$.
    Since blobs are encrypted under the user's key (not the provider's key),
    no re-encryption is needed.

    \item \textbf{Receipt migration.} All chain receipts referencing
    $\mathcal{P}_1$ remain on-chain and are augmented with a pointer to
    $\mathcal{P}_2$ for future interactions.

    \item \textbf{SLA transfer.} The SLA contract is updated to reference
    $\mathcal{P}_2$. Outstanding payment obligations to $\mathcal{P}_1$
    are settled through the epoch boundary.
\end{enumerate}

\begin{theorem}[Lossless Provider Switch]\label{thm:portability}
Given a capsule $C$ with data encrypted under key $k$ stored at provider
$\mathcal{P}_1$, and a target provider $\mathcal{P}_2$ with sufficient
storage capacity, the provider switch protocol completes with zero data
loss and bounded downtime $\Delta t \leq 2\tau_{\max}$, even if
$\mathcal{P}_1$ is uncooperative, provided the encrypted blobs were
replicated to at least $f + 1$ storage providers under the capsule's
durability policy (where $f$ is the maximum number of Byzantine providers).
\end{theorem}

\begin{proof}
The proof follows from two properties:

\textbf{Data independence.} All blobs stored at $\mathcal{P}_1$ are
encrypted under $k$, which $\mathcal{P}_1$ does not possess. The blobs
are self-contained: their integrity can be verified by the user via
Merkle proofs committed on-chain during upload. Therefore, any copy of
the blob (from $\mathcal{P}_1$, from a replica provider, or from the
user's local cache) is equally valid.

\textbf{Availability under Byzantine faults.} Under the capsule's
durability policy, blobs are replicated to $n$ storage providers with
$n \geq 2f + 1$. If $\mathcal{P}_1$ is uncooperative (refuses to serve
reads), the user retrieves blobs from the remaining $n - 1 \geq 2f$
honest providers. Since at most $f$ of these may also be Byzantine, at
least $f + 1$ honest providers remain, which suffices for complete data
retrieval.

\textbf{Bounded downtime.} During the switch, the capsule client reads
from $\mathcal{P}_1$ (or replicas) and writes to $\mathcal{P}_2$ in
parallel. The maximum downtime is bounded by the time to detect
$\mathcal{P}_1$ failure ($\leq \tau_{\max}$) plus the time to reroute
to $\mathcal{P}_2$ ($\leq \tau_{\max}$).
\end{proof}

\subsection{No Re-Encryption Requirement}

A critical property distinguishing the Lux model from centralized cloud
migration is the absence of re-encryption. In AWS or GCP, data at rest
is encrypted with provider-managed keys (AWS KMS, Google Cloud KMS).
Migrating data requires decrypting with the source provider's key and
re-encrypting with the destination provider's key---a process that
exposes plaintext during transfer and requires active cooperation from
the source provider.

In the Lux model, data is encrypted under the user's capsule key. The
provider never holds a decryption key. Migration is a simple byte-copy
of ciphertext blobs. No key rotation, no re-encryption, no plaintext
exposure.