StarkNet 介紹：Full Node 與 Data
當我們在使用 StarkNet 所提供的 API 來與區塊鏈互動時，可能會看見 SequencerRPC 和 NodeRPC 兩種選項，使用起來好像也沒太大的差別；大家如果查看 StarkNet 的架構設計時，可能也會疑惑 Sequencer 已經做好「驗證交易」、「決定交易順序」、「構建區塊」等行為了，那 Full Node 又是做什麼用的？跟 Ethereum 我們認識的 Full Node 哪裡不一樣？
本篇文章會介紹 Full Node 在 StarkNet 上擔任什麼角色，以及當前 StarkNet 上的 Full Node Project，部分概念在其他 Layer2 也可以通用，同時將一些容易混淆的內容一起做比較，包含：
- Ethereum Full Node vs. StarkNet Full Node
- StarkNet Sequencer vs. StarkNet Full Node
- RPC Node Providers vs. Full Node Project
同時也會提到關於 StarkNet Data（狀態、交易、storage、proofs 等）的內容，例如此時此刻哪個角色的 Data 才是最新的，是否完整，是否經過驗證等等。
Travel Preparations
- 本文延續前篇：StarkNet 介紹：重點部件 Overview，建議大家先閱讀前篇再服用這篇 Full Node 的介紹文章
- 本文會聚焦在 StarkNet 的 Full Node 上，與其他 Layer 2 的 Full Node 設計可能會有雷同之處但每條鏈的設計都會有所不同
- Sequencer 在許多資料中又會叫做 Operator、Validator、Supernode、Block Producer，大部分情況下是通用的，但大家還是需要自行注意是否與本文指的 Sequencer 同義
- 本文會不斷提到 state_diff，也就是交易在經過執行之後新狀態 S’ 與執行前的狀態 S 的差距，例如以下這個網站很好的顯示了一筆交易執行之後會有怎麼樣的狀態變更：Arbitrary transaction view
Author: ChiHaoLu(chihaolu.eth) @ imToken Labs
Introduction of Full Node
在 StarkNet 中，Node（節點）通常指的都是 Full Node（全節點），它不會對交易進行驗證跟執行、排序打包、提供任何 STARK Proof，它唯一的工作就只用於查詢當前的 StarkNet 狀態。
一個又一個的 StarkNet Full Node 會組成一個 P2P 網路，彼此同步資料維持資料的一致性及快速同步。
Ethereum Full Node vs. StarkNet Full Node
在開始介紹 StarkNet Full Node 之前，我們可以先複習一下 Ethereum 的 Full Node。Ethereum（L1）與 StarkNet（L2）都有 Full Node 這個名詞，但意義卻大不相同，這裡簡單帶過 Ethereum Full Node 的任務：
- 儲存完整的 Ethereum 區塊鏈數據，包含所有的交易紀錄跟狀態訊息（但會定期修剪，例如只儲存近 128 個區塊，所以並不是真的儲存從創世區塊到現在的所有狀態），它會與其它節點相互聯絡交換最新的區塊跟數據，以確保整個網路的一致性和可靠性。
- 負責驗證新的交易和區塊的有效性，檢查交易的簽名和合法性且這筆交易遵循 Protocol 定義的規則。
- 提供數據查詢服務，也就是提供 JSON RPC Call，用戶可以用 Full Node 查到地址餘額、交易歷史、合約代碼、合約執行結果。
- Full Node 通過驗證共識機制（PoW 或 PoS）來維護網路的安全性和一致性。它們驗證區塊的生成，確保新的區塊按照 Protocol 規則添加到區塊鏈中。
Ref. Ethereum Documentation & HOW A TRANSACTION GETS EXECUTED IN ETHEREUM POS
StarkNet Full Node 的特色與作用整理如下：
- 在本地（Local DB）儲存整個 StarkNet 的資訊：包含所有的狀態、交易、合約程式碼、storage、proofs。
- 利用 L1（Ethereum）驗證當前存的 State 是正確的，更細一點來說它會一個一個區塊計算 StarkNet 狀態的 Patricia-Merkle Trie Root，並與 L1 進行比較確認。這意味著它存的 contract code 和 storage 都可以在本地得到驗證。
- 提供了 StarkNet JSON-RPC API（例如
starknet.js或starknet.py），可以讓所有人藉由這個 API 跟區塊鏈互動，例如查詢 Global 或 Account 的狀態等。 - 因為在本地存了所有狀態，Full Node 可以自行模擬執行任何交易（不用跟 sequencer 發起任何 request，可以離線做到這件事情，但當然太久沒同步導致最新的鏈上狀態變了，那這個模擬就會跟實際情況不同），更進一步來說它可以讓用戶去估計交易的手續費，還有得到交易執行之後的 state_diff 會是什麼。
- Full Node 這個角色除了執行 StarkNet Cairo VM 等系統之外，還會連到 Ethereum 的 Node，因此他可以獨立地（即在不查詢其他 L2 節點的情況下）回答有關 StarkNet 當前的狀態查詢，也包括 L1 的狀態，並且自行透過 L1 驗證狀態是否正確。
而兩條鏈上 Full Node 的差別是：
- 在 Ethereum 中，網路中的每個 Ethereum Full Node 都將處理當前這筆交易，它需要重新執行整筆交易，以確保當前狀態的正確性。同時還有驗證共識機制的結果，對交易和網路安全性起到至關重要的作用。
- 在 StarkNet 中，StarkNet 只會由少數節點（Sequencer 和 Prover 等特殊角色）處理交易，而 Full Node 在驗證上只需要參考 L1 Core Contract 就可以獲得安全可靠的區塊、state 資料（都經過 STARK proof 驗證）；或甚至從其對等節點（P2P）接收當前狀態的資料備份，並僅僅通過 STARK proof 就可以驗證該狀態是否有效不需執行過交易。作用上並沒有如 Ethereum 的 Full Node 重要，唯一的工作也就只有讓用戶跟 StarkNet 互動和查資料而已。
Full Node in StarkNet Architecture
我們可以從 Full Node 在 Transaction Life Cycle 的哪裡，來更好理解 Full Node 在 StarkNet 中與其它角色的互動關係。假設用戶發起了一筆交易：
- RECEIVED：Sequencer 接收到這筆最新的交易
- PENDING：Sequencer 處理此交易後，交易通過了驗證和執行過程，已經加入正在構建的區塊
- ACCEPTED_ON_L2：包含此交易的該區塊已在 Layer 2 被發布
- ACCEPTED_ON_L1：包含此交易的 state_diff 在 Layer 1 被驗證
在 StarkNet Core Contract 接收了 Sequencer 傳來的 state_diff 並且透過 Verifier 驗證成功之後，StarkNet Core Contract 就會更新合約儲存的 State Root 到新的 State（ACCEPTED_ON_L1）。但為了節省 Gas Fee，這個「狀態轉換」會以 calldata 的形式發送，而不是記錄到合約的 Storage 中。
這個 calldata 會被 Full Node 處理之後成為它本地（Local DB）存的 StarkNet 歷史記錄，也是其紀錄 StarkNet 最新區塊的依據。關於這部分 Layer 2 資料紀錄在 Layer 1 上的內容，待會在「StarkNet Data」章節處會有更多敘述。
而關於 state_diff 和 calldata 是長什麼樣子，以及如何 decode，有興趣可以參考官方文件：StarkNet Doc — On-Chain Data
Who needs to run a Full Node?
普通用戶需要跑 Full Node 嗎？
- Full Node 使任何人能夠在本地保存和驗證 StarkNet 的所有狀態，準確地追蹤發生的一切。但這意味著需要巨大的儲存空間跟不間斷的伺服器來運作一個 Full Node，這對普通用戶來說是一個不小的成本，所以可以使用 RPC Node Provider（e.g. Infura、Alchemy，待會會有專門章節介紹）就好，不用自己跑 Full Node。
開發者需要跑 Full Node 嗎？
- 如果需要使用許多底層的操作，且最精準的獲得 StarkNet 資料並且針對這些資料做處理，或是需要自己刻 JSON RPC Call 沒有提供的 API，那確實需要自己跑一個 Full Node。但如果僅僅是需要一些普通開發上的操作，與 Node Provider 互動算是頗足夠的選項了。
運行 Full Node 有什麼好處嗎？
- 運行 Full Node 本身並不會直接獲得任何好處，Full Node 本來就不會處理組建區塊的相關內容，在 StarkNet Full Node 只是單純作為狀態觀察和紀錄者。
- 然而將 Node Provider 服務提供給用戶是可以從中獲取利潤的，就像是我們需要大量使用 Infura、Alchemy 等服務時就需要付費。
- 如果今天我們不信任 Node Provider 提供的區塊資訊，或者不想被這些第三方角色追蹤我們的資料，那我們也可以自行考慮 run 一個 Full Node
StarkNet Data
Data Synchronization
Full Node 同步 StarkNet 的狀態到本地有三種方式，分別為：
- 從 Ethereum 上的 StarkNet Core Contract 的 calldata decode 並取得 state_diff
- 與 StarkNet 其他 Full Node 們進行 P2P 同步
- 向 StarkNet Sequencer Gateway 發起 request 同步狀態（Sequencer 一定是第一個知道最新狀態的人，因為目前只有他會處理真正交易和決定區塊內容）
那如果這三者的內容不同，那一個 Full Node 會怎麼決定當下資料？
- 如果 Sequencer 和 P2P Network 的內容不同，目前的做法是 Full Node 應該選擇 Sequencer 的資料，因為 Sequencer 是唯一的資料來源。然而，未來將會有多個 Sequencer 存在，那麼依賴的就是共識演算法（Sequencer 與 P2P Full Node Network 交織的一個共識機制），這個演算法目前仍在設計中。
- 如果 L1（從 L1 Core Contract decode 而來的資料）和 L2（以 Sequencer 為主）的內容不同，Full Node 需要自己決定如何處理（根據不同開發商）。在 Pathfinder 中只將資料標記為 Accepted on L1 或 Accepted on L2：例如 L1 比 L2 延遲了數個區塊，那就需要等 L1 跟上再同步。如果是 L1 跟 L2 針對同一個區塊有不同結果，那就以 L1 為主。
在 Full Node 的設計上其實有不同的演算法可以選擇，例如 Pathfinder 希望 Full Node 的演算法是：
- 當前最主要獲取最新區塊的方式是透過與其他 StarkNet Full Node 進行 P2P Sync，可以快速地直接獲取任意區塊，雖然可以呈現最新的區塊但有機率被 revert。不過現行的所有 Full Node 都是使用 Sequencer Gateway Request 最新資料，因為他們正在構思一個 Full Node 之間同步資料的方式。
- Full Node 針對當前獲取的目標區塊進行 L1 驗證，驗證成功這個新的區塊才會被更新進 Full Node 的 Local DB，只要 L1 沒有 reorg 那這個區塊就不會被 revert。
更深入一點說這三個 sync 資料的方式代表著不同的意涵：
- 向 Sequencer Gateway Request 資料可以第一步取得最新資料，也就是「獲得 Layer2 上最近的狀態（區塊、交易）」，但需要等待 Sequencer 的回應因為 Sequencer 目前承受著巨大的負擔，且我們需要相信 Sequencer。
- 向 Ethereum 索取資料並進行驗證是可以確保資料正確，也就是「獲得 Layer1 上最新確認的 Layer2 狀態（區塊、交易）」。
- 向其他 StarkNet Full Node 進行 P2P Sync 可以快速的獲得區塊資料，且大幅減輕 Sequencer 的負擔。但有可能在同步的過程中有遺漏，也就是節點有可能錯過一個新區塊，並且需要進行修復以填補間隙。
那今天 Full Node 跟 P2P Sync 到的區塊和自己紀錄的有遺漏怎麼修復？
- 解決的方式仰賴於 ZK Rollup 的設計，我們可以針對特定的 L2 區塊去找特定的 L1 記錄相對應 state_diff 的內容進行驗證。甚至可以並行化處理，例如有一個 Full Node 一次同步了最新的三個區塊，那他可以獨立且同時驗證這三個區塊。所以即便我們有遺漏也沒關係，仍然可以給予當前我們能給予的最新狀態，之後再慢慢補齊。
Comparison
StarkNet Sequencer vs. StarkNet Full Node
現在我們已經知道 Full Node 是什麼了，那我們可以接續前篇的 Sequencer 簡介之後，更深入的看 Sequencer 這個角色以及其跟 Full Node 的比較。
Sequencer 實際上是一個 StarkNet 網路的主節點（又稱作 Super Node），是一個被特別設計、有更多重要功能的 Full Node。因為它本身就是一個 Full Node，所以需要做的事情都少不了，包含運行一個 Ethereum Full Node。
此外，它控制交易的排序、經過 StarkNet AA Protocol 驗證交易並且收取交易手續費，執行交易時使用相應的輸入執行 StarkNet OS Cairo 得到 trace，再使用 StarkNet Prover 產生證明結果提交給 L1 Verifier，最終知會 StarkNet Core Contract 以更新 StarkNet 最新的 state_diff。
如果不知道什麼是 StarkNet AA Protocol 可以無視，先當作是 Sequencer 驗證一筆交易是否有經過用戶授權且執行成功的一個流程即可。
而用戶與 Sequencer 的互動方式與任何 Full Node 互動的方式非常類似，例如用戶可以將他們的錢包 network URL 指向 Sequencer，可以起到與 Full Node 一樣的作用；也可以直接向 Sequencer 送交易或詢問鏈上狀態。
RPC Node Providers vs. Full Node Project
以下是目前的 StarkNet Full Node 開發商與它們的 Project：
- Starkware — Papyrus：Starkware 官方推出，使用 Rust 撰寫的 Full Node，StarkNet 官方開發的 Sequencer 會使用 Papyrus 作為 Infra
- Eqlabs — Pathfinder：同樣使用 Rust 撰寫的 Full Node
- NethermindEth — Juno：Nethermind 使用 Golang 撰寫的 Full Node，Nethermind 知名的 Project 很多，包含 Ethereum 的執行客戶端，還有可以將 Solidity 轉成 Cairo 的 Warp
不同的 Full Node 指的是不同公司開發的 Full Node Project（Full Node Client），雖然同步的資料都是一樣的，可以得到相同的最新且被 Layer 1 驗證的狀態。但以不同的程式語言、不同演算法實作或著重的點不同，還是會在效率跟使用體驗上有所差異，例如 Papyrus 自己建立一個 key/value storage 而不是透過遍歷 Merkle-Patricia 來找資料。
當前的三個 Full Node Project 處於合作狀態，即便用戶跑著不同的 Full Node 他們彼此還是能夠通過 P2P 層進行通信和同步。
目前的 Full Node Project 都在經歷痛苦的 Breaking Change（一切都要感謝 Starknet v0.11.0 和 Cairo 1.0），所以 Papyrus 甚至不建議大家現在使用它。
我們常常看見了一些 RPC Node Provider 提供了跟 Full Node Project 一模一樣的 API，實際上他們只是選擇了上述的其中一個 Full Node Project 來跑 Full Node，並且提供一個 API services，並不是 Full Node 的開發商，例如 Infura 選擇了 Pathfinder Full Node Client。
有了 RPC Provider 的幫助，開發者在整合 L1 和 L2 的服務時也更加方便，因為他們只要使用同一把 Project Key 然後設定不同網路就可以一次處理好全部設定跟 Pricing。
以下是目前有提供 StarkNet Node API services 的提供商：
以下是相關 Watchlist，未來有新的節點服務 StarkNet 官方會更新在此：
Special thanks to NIC Lin & Cyan Ho for reviewing this post, and Mirko-von-Leipzig@eqlabs for replying lots of my questions.
TEM Medium 2023 有獎徵稿 TEM Medium 目前正在進行有獎徵稿！詳情請參考： https://medium.com/taipei-ethereum-meetup/tem-medium-call-for-papers-with-prize-2023-q1-f384828f902f
