Validity(ZK) Rollup 在上傳資料類型上的選擇
除了上傳每一筆交易的完整資料，Validity Rollup 還可以選擇上傳 State Diff。什麼是 State Diff？選擇上傳交易資料或 State Diff 的差異在哪？
先備知識：
- 理解 Rollup 的運作方式以及 Rollup 的資料可得性（Data Availability）問題
- 理解 Validity Rollup 與 Optimistic Rollup 的差異
Recap on Rollup’s Data Availability
不管是 Validity Rollup 還是 Optimistic Rollup，它們都會將資料上傳到 L1（例如 Ethereum），讓所有人都可以透過存取 L1 來存取到該 Rollup 的資料，並藉此推導出 Rollup 最新的狀態，例如 Alice 有 10 USDT、Bob 有 5 USDT。
Validity Rollup 在 DA 上的優勢
兩種 Rollup 都會將完整的交易資料上傳到 L1，完整的交易資料包含發送者（sender）、接收者（to）及金額（amount）等等。但 Validity Rollup 在資料上能做的變化更多，像是 (1) 不需附上交易的簽名 或是 (2) 不上傳完整交易資料而是改成上傳 State Diff。這是因為 Validity Rollup 靠 Validity Proof 證明交易的合法性及狀態的正確性，而不需像 Optimistic Rollup 一樣需要每一筆交易的資料，並透過執行每一筆交易來驗證交易合法性及狀態的正確性。
(1) 不需附上交易的簽名
如果 Optimistic Rollup 上傳的交易資料不附上簽名，其他人就沒辦法驗證這筆交易有經過發送者授權，表示任何人都可以以 Alice 的名義把 Alice 的錢轉給自己。
(2) 用 State Diff 取代完整交易資料
State Diff 指的是狀態的改變，例如 Alice 的 USDT 餘額從 10 變成 5。一筆交易會改變狀態，也就會產生 State Diff，或甚至兩筆交易產生的部分 State Diff 會剛好抵銷，例如 Alice 轉出去 5 USDT 後又收到了 5 USDT。而一個包含多筆交易的區塊就會有很多 State Diff，其中也許有些 State Diff 彼此抵銷了，那就不會出現在最終「整個區塊的 State Diff」。
Validity Rollup 因為是用 Validity Proof 來證明狀態的正確性，所以 Validity Rollup 可以只上傳 State Diff，告訴大家「這些是這個區塊所產生的狀態變化，狀態的正確性已經由 Validity Proof 證明了，你們可以安心地由這些新的 State Diff 加上前一個區塊的狀態，來算出 Alice 在最新這一個區塊的狀態」。但 Optimistic Rollup 就沒辦法這麼做了，大家不會在沒有證明或親自執行交易的前提下就相信「這些是這個區塊所產生的狀態變化，你們可以安心地由這些新的 State Diff 加上前一個區塊的狀態，來算出 Alice 在最新這一個區塊的狀態」。
State Diff 的優點
節省成本
每一筆交易資料都會佔用數十 bytes 的空間（每一 byte 會耗費 16 gas），且壓縮空間有限。但用 State Diff 取代完整交易資料就可以透過選擇區塊要收入的交易來抵銷或疊加交易彼此的 State Diff 來進行優化，例如很多筆 Uniswap 上同一個交易對的交易或很多筆相同 ERC20 的轉帳放在同一個區塊裡，就能抵銷許多 State Diff，以及疊加 State Diff（例如交易對的 ERC20 餘額更新許多次但最終只會有一個 State Diff）。而區塊越大，能抵銷或疊加的 State Diff 就越多，所以對使用 STARK 證明系統的 Rollup 像是 StarkNet 來說，因為其本身就有交易越多，平攤的證明成本越低的特性，所以一個區塊能放越多交易越好，因此採用上傳 State Diff 的方式就能再進一步節省成本。
註：StarkNet 目前是唯一採用 State Diff 作法的 Validity Rollup 且交易量還不足以體現 State Diff 的優勢。期望未來當交易量上來後 StarkWare 能給一個完整的分析，和社群分享 State Diff 的效果。如果想要了解 StarkNet 的資料格式可以參考這裡。
節點能更快地同步到最新狀態
在介紹這個優點之前，先來對 L1 節點同步的方式做個 Recap。L1 例如 Ethereum 的節點的同步方式是藉由 p2p 網路來分享、索取區塊的資料，在拿到一個新的區塊時會先驗證區塊的有效性，接著再執行區塊裡的交易，確認交易有效性及交易執行完的狀態的正確性。
如果區塊鏈越長、包含越多交易，新節點加入網路後要進行完整的同步就越耗時。因此使用者的新節點在加入的時候可以選擇做一些 Trade-off，犧牲一些安全性來更快獲得最新狀態，因為使用者可能沒辦法等上好幾天甚至好幾個禮拜的時間才能知道自己當前在鏈上有多少錢。這個 Trade-off 大致的做法是向 p2p 其他節點索取某個區塊執行完後的完整狀態（每個地址的狀態），並在未驗證這個區塊及其內容的有效性之前，就先相信這個狀態並接著索取該區塊之後的新的區塊資料來計算新的狀態，並同時索取該區塊之前的區塊來驗證該區塊的有效性。如此節點就可以很快速地計算出最新的狀態來讓使用者查詢，並在背景慢慢同步並驗證。
但這裡要特別注意的是，這個同步方法的優點及目的是「能快速地獲得最新的狀態」，而不是「能快速地獲得歷史交易資料」。狀態是某個時間點的鏈的狀態，是執行過歷史所有交易所計算出來的狀態，有了狀態不代表有了歷史所有交易資料，歷史交易資料還是要在背景慢慢同步才能獲得。
那 Rollup 節點如何同步呢？Rollup 為了確保資料可得性所以將資料都寫到 L1 上，所以 L1 已經有完整的 Rollup 資料可供查詢。所有 Rollup 節點只需讀取 L1 就能獲得所需的資料，不需透過 p2p 網路。而且如果是 Validity Rollup 的話，Rollup 節點甚至不必親自執行過 L1 上讀取到的交易來驗證，因為已經有 Validity Proof 來確保資料的有效性及正確性。因此，如果是採用 State Diff 的 Validity Rollup，其節點只需從 L1 讀取出歷史所有的 State Diff 並一個一個疊加上去計算，就能非常快速地得出該 Rollup 最新的狀態，而且這個速度不是犧牲安全性所換來的。
State Diff 的缺點
雖然採用 State Diff 的 Validity Rollup 的節點可以很快地同步到最新狀態，但 State Diff 的缺點是：像前面提到的，有了狀態不代表有了歷史所有交易資料，所以如果使用者要查詢歷史交易資料，他仍然需要等節點慢慢同步，而且節點需要透過另外的管道（例如問 Sequencer/Operator 或 p2p 網路）去同步，因為上傳到 L1 的是 State Diff 而不是交易資料。所以為了讓節點能獲得歷史交易資料讓使用者查詢，我們還是需要一個 p2p 網路來同步。
註：節點可以向 Rollup 的 Sequencer/Operator 索取歷史交易資料，但這會造成 Sequencer/Operator 太大負擔且太中心化，所以最好的方式是運行一個 p2p 網路來互相分享資料。雖然 p2p 網路基本上都還在設計中，短期內都還是只能向 Sequencer/Operator 索取。
當節點透過 p2p 網路獲得一個區塊及裡面的交易資料，節點會執行過裡面的所有交易並比對執行完的狀態是否和 L1 上紀錄的狀態是一樣的。
狀態比對是比對狀態根（State Root），也就是整個狀態樹的樹根，只要樹根一樣就代表整體狀態是一致的。L1 上紀錄的狀態因為是有經過 Validity Proof 驗證的，所以可以當作 Source of Truth。只要 p2p 收到的區塊，發現裡面的交易執行完後的狀態和 L1 對不上，就可以知道這個 p2p 的區塊是無效的，直接丟棄。
註：隨著區塊越來越大，可以預期未來從 p2p 收到的區塊也會順便附上 Validity Proof，這樣 p2p 的節點就不需要每次收到一個區塊就執行一次裡面的所有交易，避免節點因為要執行交易而落後，最終跟不上鏈產區塊的速度。
更多關於採用 State Diff 的 Validity Rollup — StarkNet 如何進行節點同步的細節，可以參考：
Special thanks to Kimi Wu and Chih-Cheng Liang for reviewing and improving this post
TEM Medium 2023 有獎徵稿
TEM Medium 目前正在進行有獎徵稿！詳情請參考：
