feat: update links and img #568 (#571)

content/articles/a-trustless-and-simple-14k-tps-payment-l2-from-plasma-and-client-side-proving.md

@@ -19,7 +19,7 @@ projects: ["plasma-fold"]
 
 # A trustless and simple 14k+ TPS payment L2 from Plasma and client-side proving
 
-We are excited to present our latest work: PlasmaFold ([repo](https://github.com/dmpierre/plasma-fold), [eprint]()), an incrementally verifiable, simple and efficient payment L2 reaching 14k+ TPS. PlasmaFold operates under a "verifiable plasma" regime. On one hand, it uses plasma-like data availability requirements, restricting the amount of data posted by an aggregator to minimal amounts. On the other, it requires the plasma aggregator to verifiably build blocks and users to run a (lightweight) client-side prover.
+We are excited to present our latest work: PlasmaFold ([repo](https://github.com/dmpierre/plasma-fold), [eprint](https://eprint.iacr.org/2025/1300)), an incrementally verifiable, simple and efficient payment L2 reaching 14k+ TPS. PlasmaFold operates under a "verifiable plasma" regime. On one hand, it uses plasma-like data availability requirements, restricting the amount of data posted by an aggregator to minimal amounts. On the other, it requires the plasma aggregator to verifiably build blocks and users to run a (lightweight) client-side prover.
 
 This combination removes from the aggregator most of its cheating avenues while allowing users to exit the chain non-interactively at any point in time, without any particular assumptions regarding their liveness.
 
@@ -27,7 +27,7 @@ Our prototype implementation demonstrates a PlasmaFold aggregator running on low
 
 ## Protocol description
 
-We succinctly describe here the PlasmaFold L2 protocol, where further details can be found in the [eprint](). PlasmaFold runs on two kind of proofs: (1) a block proof $\Pi^{\mathsf{block}}_{t}$ produced by the aggregator and (2) a balance proof $\Pi^{\mathsf{balance}}_{id}$ managed by each user. 
+We succinctly describe here the PlasmaFold L2 protocol, where further details can be found in the [eprint](https://eprint.iacr.org/2025/1300). PlasmaFold runs on two kind of proofs: (1) a block proof $\Pi^{\mathsf{block}}_{t}$ produced by the aggregator and (2) a balance proof $\Pi^{\mathsf{balance}}_{id}$ managed by each user.
 
 First, the aggregator builds a transaction tree $\mathcal{T}^{\mathsf{tx}}_t$, composed of leaves consisting in transaction hashes. Before running the IVC prover, the aggregator proposes to each transaction sender with id $id$ the root $r^{\mathsf{tx}}_{t}$ along a merkle inclusion proof $\pi^{\mathsf{tx}}_{t}[id]$ for their corresponding $id$ and transaction within $\mathcal{T}^{\mathsf{tx}}_t$. Transaction senders acknowledge receiving and checking the proposal by sending back their signature over their transaction and the aggregator's transaction tree root $\mathtt{sign(} \mathsf{tx} \vert \vert r^{\mathsf{tx}}_{t}\mathtt{)}$.
 
@@ -35,8 +35,8 @@ When done, the aggregator runs his IVC prover. At each step, it ensures that eac
 
 When done, the aggregator posts $\mathcal{L}^{\mathsf{signer}}_{t}$ along with the block IVC proof $\Pi^{\mathsf{block}}_{t}$ containing the updated global UTXO tree root $r^{\mathsf{utxo}}_t$, the transaction tree root $r^{\mathsf{tx}}_{t}$ and the signer accumulator value $\mathtt{acc}^{\mathsf{signer}}_{t}$. The rollup contract checks the value of $\mathtt{acc}^{\mathsf{signer}}_{t}$ from the posted $\mathcal{L}^{\mathsf{signer}}_{t}$, correspondingly increments nonces of transaction senders and computes the block hash value $h^{\mathcal{blk}}_{t} = H(t, r^{\mathsf{tx}}_{t}, \mathtt{acc}^{\mathsf{signer}}_{t})$, where $t$ is the current block height.
 
-![plasmafold-txflow](https://hackmd.io/_uploads/S1UKUFRSgl.png)
-*Generating and verifying an IVC block proof in PlasmaFold*
+![plasmafold-txflow](/articles/a-trustless-and-simple-14k-tps-payment-l2-from-plasma-and-client-side-proving/plasmafold-txflow.png)
+_Generating and verifying an IVC block proof in PlasmaFold_
 
 Upon sending or receiving a transaction, users run their client-side IVC prover. At each step, the user's IVC recomputes $h{\mathcal{blk}}_{t}$, ensures that the claimed transaction is in the claimed transaction tree root $r^{\mathsf{tx}}_{t}$, updates the user's balance while preventing block or transaction replays using the block height $t$ and the transaction's index within $\mathcal{T}^{\mathsf{tx}}_t$.
 
@@ -59,12 +59,12 @@ Moreover, Ethereum's recent Pectra upgrade, which includes EIP-7691, doubled the
 
 ## Benchmarks
 
-To demonstrate the performance of PlasmaFold and study how transaction batch size impacts efficiency, we evaluate the aggregator and user IVC by measuring the circuit size, prover time, RAM usage and SRS size. We leverage a folding-schemes based IVC, namely [Nova]() and prototype both our aggregator and client-side prover using [Sonobe](), a modular folding-schemes library, built on top of arkworks. 
+To demonstrate the performance of PlasmaFold and study how transaction batch size impacts efficiency, we evaluate the aggregator and user IVC by measuring the circuit size, prover time, RAM usage and SRS size. We leverage a folding-schemes based IVC, namely [Nova](https://eprint.iacr.org/2021/370) and prototype both our aggregator and client-side prover using [Sonobe](https://github.com/privacy-ethereum/sonobe), a modular folding-schemes library, built on top of arkworks.
 
 First, since most blockchain wallets run within browsers, we compile to WebAssembly our client-side prover and run our benchmarks within a chrome browser with an apple m2 pro and 16GB of RAM.
 
-| $\textbf{Batch size}$  | $\vert\mathcal{F}_{\mathsf{user}}\vert$ | $\vert\mathcal{F}^{\mathsf{aug}}_{\mathsf{user}}\vert$  | $\mathsf{IVC}.\mathcal{P}$ (s) | $\textbf{RAM usage}$ (MB) | $\vert \mathsf{srs} \vert$ (MB)|
-|---|---|---|---|---|---|
+| $\textbf{Batch size}$ | $\vert\mathcal{F}_{\mathsf{user}}\vert$ | $\vert\mathcal{F}^{\mathsf{aug}}_{\mathsf{user}}\vert$ | $\mathsf{IVC}.\mathcal{P}$ (s) | $\textbf{RAM usage}$ (MB) | $\vert \mathsf{srs} \vert$ (MB) |
+| --------------------- | --------------------------------------- | ------------------------------------------------------ | ------------------------------ | ------------------------- | ------------------------------- |
 | 1                     | 19k (< recursive cost)                  | 76k                                                    | 2.8                            | 291                       | 73                              |
 | 2                     | 36k (< recursive cost)                  | 92k                                                    | 3.5                            | 343                       | 90                              |
 | 5                     | 87k                                     | 143k                                                   | 5.3                            | 579                       | 149                             |
@@ -73,8 +73,8 @@ First, since most blockchain wallets run within browsers, we compile to WebAssem
 
 Then, we run the aggregator benchmarks on a Linux PC with an Intel Core i9-12900K CPU and 64GB of RAM (transfer only mode):
 
-| $\textbf{Batch size}$  | $\vert\mathcal{F}_{\mathsf{user}}\vert$ | $\vert\mathcal{F}^{\mathsf{aug}}_{\mathsf{user}}\vert$  | $\mathsf{IVC}.\mathcal{P}$ (s) | $\textbf{RAM usage}$ (MB) | $\vert \mathsf{srs} \vert$ (MB)|
-|---|---|---|---|---|---|
+| $\textbf{Batch size}$ | $\vert\mathcal{F}_{\mathsf{user}}\vert$ | $\vert\mathcal{F}^{\mathsf{aug}}_{\mathsf{user}}\vert$ | $\mathsf{IVC}.\mathcal{P}$ (s) | $\textbf{RAM usage}$ (MB) | $\vert \mathsf{srs} \vert$ (MB) |
+| --------------------- | --------------------------------------- | ------------------------------------------------------ | ------------------------------ | ------------------------- | ------------------------------- |
 | 1                     | 257k                                    | 321k                                                   | 0.9                            | 2533                      | 313                             |
 | 2                     | 520k                                    | 585k                                                   | 1.5                            | 4108                      | 579                             |
 | 4                     | 1045k                                   | 1113k                                                  | 2.8                            | 7841                      | 1111                            |