本文由 AI 生成,請獨立核實重要資訊。

NEAR 無狀態驗證:第二階段分片

Crypto Wiki|Jul 24, 2026|4.5 (500 人評分)
AI 摘要

Learn how NEAR stateless validation eliminates validator storage requirements, enabling horizontal scalability without hardware centralization through...

NEAR 無狀態驗證是 NEAR Protocol 的 Nightshade 分片框架的第二階段升級,其中分塊驗證者不再維護分片狀態的持久本機副本。相反,分塊生產者將所有必需的狀態數據打包成狀態見證(state witness),這是一種加密數據結構,包含執行特定分塊所需的每項帳戶餘額、合約儲存條目和存取金鑰,並將其與分塊一同交付給驗證者。此設計使驗證者的硬體需求與網路狀態大小脫鉤,允許 NEAR 透過增加更多分片來水平擴展,而無需在其驗證者集上強制增加成比例的儲存成本。

本篇文章涵蓋了 NEAR Protocol 的介紹、Nightshade 分片技術的運作原理、無狀態驗證(stateless validation)的精確機制(包括狀態見證生命週期與驗證者角色階層)、對去中心化與可擴展性的益處、與以太坊無狀態藍圖的直接對比,以及對驗證者、質押者、開發者和任何評估在 NEAR 上部署去中心化應用程式(dApp)之人士的影響。

什麼是 NEAR Protocol?

NEAR Protocol 是一個第 1 層 (Layer-1) 的權益證明 (Proof-of-Stake) 區塊鏈,其使用 Nightshade 分片(NEAR 的專有分片框架)將交易處理分配到多個並行分片中,以極低的交易手續費實現高吞吐量。NEAR 旨在進行大規模去中心化應用的部署,其開發者工具和共識架構是建立在分片數量將隨著時間增長的假設之上。

NEAR 的核心架構

NEAR 運行為一個權益證明(Proof-of-Stake)網路,驗證者在此網路中質押 NEAR 代幣以參與共識,並在每個週期(Epoch,一個大約相當於半天的固定時間段)中被隨機分配到不同的分片(Shards)。NEAR Protocol 由 Illia Polosukhin(開創性機器學習論文「Attention Is All You Need」的共同作者)和 Alexander Skidanov 共同創立;NEAR 基金會負責監督協定持續的開發和生態系統的撥款。

NEAR 代幣有兩個主要功能:支付交易和合約執行的 Gas 費用,以及作為驗證者的抵押品進行質押,以獲得參與共識的權利。NEAR 智能合約會編譯為 WebAssembly (WASM),這是一種可移植的二進位格式,允許以 Rust 或 JavaScript 編寫的合約在確定性執行階段中執行。NEAR 上的交易處理遵循分塊 (chunk-based) 模型,其中每個分片在每個區塊間隔內都會產生一個分塊(平行處理的分片級區塊),所有分塊都會聚合到一個標準區塊中。

NEAR 與其他 L1 區塊鏈有何不同?

NEAR 與其他第 1 層區塊鏈的主要區別在於其執行分片模型,該模型將狀態和交易處理分散到各個分片中,而不是在單條鏈上處理所有執行。關鍵的差異化特點包括:

  • Nightshade 執行分片: NEAR 對狀態和計算都進行了分片,而不僅僅是數據可用性。這與以太坊的 Danksharding 方法 (EIP-4844) 不同,後者的目標是針對 Layer 2 Rollup 的數據可用性分片,而不是執行分片。
  • 無狀態驗證(第 2 階段): 區塊分片驗證者在沒有本地狀態存儲的情況下運行,這一設計選擇對去中心化和分片可擴展性具有直接影響,本文將對此進行深入探討。
  • WASM 智能合約運行時: 合約在 WASM 沙盒中運行,支持 Rust 和 JavaScript 作為主要開發語言。
  • 人類可讀的帳戶名稱: NEAR 帳戶使用具名標識符,而不是原始公鑰哈希。
  • 存儲質押模型: 合約通過質押 NEAR 代幣來支付鏈上存儲費用,將存儲成本與質押抵押品掛鉤,而不是按字節收費。
  • 趨近於零的交易手續費: NEAR 的費用結構旨在即使在適度的網絡負載下也保持易於負擔。

Solana 透過其 Sealevel 運行時以單鏈平行(single-chain parallelism)來擴展;NEAR 則透過跨獨立平行分片(independent parallel shards)進行分片(sharding)來擴展。這些是針對相同吞吐量問題的不同架構響應。以太坊的比較將在本文稍後進行專門論述。

什麼是無狀態驗證?

無狀態驗證是一種區塊鏈驗證模型,驗證者在其中處理交易時無需維護網路狀態的持久化本地跟單,而是將所有必要的狀態數據作為其驗證的每個區塊或分塊的一部分來接收。「無狀態」一詞是指驗證者與狀態存儲之間的關係,而非區塊鏈狀態本身,後者會持續存在並增長。從驗證者的角度來看,每項驗證任務在送達時都已預先封裝了完成該任務所需的所有內容。

有狀態與無狀態驗證:核心差異

有狀態驗證與無狀態驗證的差異,在於執行期間狀態資料的儲存位置:是在驗證器端,還是與工作本身有關。

有狀態驗證 (Stateful Validation)無狀態驗證 (Stateless Validation)
狀態存儲驗證者存儲分片狀態的完整本地副本(從數百 GB 到 TB 不等,且隨時間增加)驗證者不存儲任何持久性分片狀態
狀態訪問方式在交易執行期間從本地存儲資料庫讀取從隨每個區塊 (chunk) 交付的狀態見證 (state witness) 中讀取
硬體需求隨著鏈的增長,規模與網路狀態大小成正比與網路狀態大小解耦
去中心化影響高昂且不斷增長的存儲成本限制了驗證者的參與較低且穩定的成本使更廣泛的驗證者參與成為可能

在有狀態驗證中,驗證者是狀態保管者:它擁有相關分片資料的跟單,並在每次交易時進行查閱。在無狀態驗證中,狀態資料會隨工作一同傳輸。驗證者收到其所需的內容,加以使用,然後捨棄。

NEAR 為何需要無狀態驗證

在 NEAR 原始的有狀態架構下,分配給分片的每個區塊驗證者都必須維護該分片狀態的完整本地副本。隨著 NEAR 分片數量的增加,網絡中每個驗證者的存儲硬體需求也隨之增長。每個新增的分片都會為分配到該分片的驗證者增加成比例的存儲義務。這使得 NEAR 的擴容野心與驗證者參與的硬體成本門檻之間產生了直接的耦合。當網絡通過增加分片來提高吞吐量時,同時也提高了成為驗證者的成本,將參與者集中在擁有大型存儲基礎設施的營運商中。

無狀態驗證打破了這種耦合關係。分塊驗證者不再存儲任何分片狀態。它接收驗證每個分塊所需的確切狀態數據,針對該數據執行交易,然後將其丟棄。增加更多分片可以提高網絡吞吐量,而不會增加單個驗證者的存儲需求。這解決了區塊鏈擴展性三難困境中的一個核心矛盾:NEAR 可以透過增加分片來擴展吞吐量,而無需強制硬體中心化,同時狀態見證的加密完整性也確保了安全性。

了解分片:NEAR 擴展性的基礎

NEAR 的無狀態驗證運作於 Nightshade 分片架構內,該架構將網路的全局狀態和交易處理劃分為多個平行分片。理解此架構是後續機制解釋的先決條件,因為無狀態驗證是對驗證者如何在 Nightshade 結構中參與的一項特定升級。

NEAR 上的 Nightshade 分片如何運作

Nightshade 是 NEAR Protocol 的分片框架,在該框架中,區塊鏈的全局狀態被劃分到多個分片中,每個分片在每個區塊間隔內產生一個 chunk(分片層級的區塊)。多個 chunk 在所有活躍分片中平行產生,並由該時段的區塊生產者聚合為單個規範區塊。

Nightshade 的核心設計原則是將所有分片視為單一邏輯區塊鏈的組成部分,而非獨立的鏈。每個 NEAR 區塊包含每個活躍分片的一個區塊片段 (chunk)。這意味著即便交易處理是分散式的,全局帳本仍保持統一。跨分片交易是透過在分片之間傳遞訊息的非同步收據機制來處理的。

驗證者在每個 Epoch 都會被隨機分配到分片中,這降低了任何單一分片的驗證者集合被針對性攻擊或控制的風險。驗證者不會永久分配到特定的分片,而是會隨著每個 Epoch 進行輪轉,從而將責任和風險分散到整個網絡中。

Nightshade 的完整實施分為三個階段。第一階段建立了帶有分塊處理(chunk processing)的基本分片(sharding),驗證者在此階段維護完整的本地狀態副本。第二階段是無狀態驗證(stateless validation),這也是本文的主題。第三階段是動態重分片(dynamic resharding),這使 NEAR 能夠根據即時網路需求自動調整其分片數量。如需 NEAR 分片模型的完整技術文件,請參閱 docs.near.org/concepts/advanced/sharding.

--- ## NEAR 無狀態驗證的運作方式

NEAR 的無狀態驗證之所以能正常運作,是因為驗證區塊(chunk)所需的狀態資料會隨同該區塊本身一起傳輸,並由區塊生產者打包成狀態見證(state witness)。區塊驗證者同時接收該區塊及其狀態見證,僅使用見證資料執行所有交易,且從不查詢本地狀態資料庫。結果是 NEAR 網路中數量最多的驗證者類別,可以在幾乎沒有狀態儲存需求的狀況下運作。

什麼是狀態見證?

狀態見證是一種由分塊生產者產生的加密資料結構,其中包含執行特定分塊中的交易所需的所有狀態資料,包括受影響的帳戶餘額、合約儲存項目、存取金鑰和合約程式碼。

將狀態見證人(state witness)想像成法庭書記員在聽證會前準備好的案件卷宗:其中包含法官做出判決所需的所有文件,並事先準備妥當,這樣法官就不需要在訴訟過程中搜尋法庭檔案。在 NEAR 的架構中,狀態見證人就是那個案件卷宗。分塊驗證器(chunk validator)會與分塊(chunk)一起接收它,並僅使用其內容執行所有交易,而無需查詢本地狀態儲存。

狀態見證人生命週期涵蓋五個明確的階段:

  1. 內容: 狀態見證包含區塊中交易觸及之每個帳戶的帳戶餘額、合約儲存項目、存取金鑰及合約程式碼。僅包含執行期間實際讀取或寫入的狀態;整個分片狀態並未被打包。

  2. 生成: 該分塊生產者,負責構建分塊的驗證者角色,從其本地分片狀態副本中讀取相關狀態條目,並將它們打包成狀態見證。該分塊生產者保留其本地狀態,因為它必須能夠為未來的分塊生成見證。

  3. 傳輸: 分塊生產者將分塊及其狀態見證,共同廣播給當前區塊間隔內隨機指派至該分片的分塊驗證者。

  4. 執行: 每個分塊驗證器僅透過狀態見證數據執行分塊的交易。執行過程中絕不進行任何本地狀態查找。完成執行後,分塊驗證器會產出一份聲明,以確認分塊的有效性。

  5. 捨棄: 驗證完成後,區塊驗證者 (chunk validator) 會捨棄狀態見證 (state witness)。該見證不會被保留、儲存,也不會用於更新任何本地狀態資料庫。

狀態見證器結構正式指定為 NEAR 增強提案 (NEP)。如需精確規格和目前的 NEP 編號,請參閱 GitHub 上的 NEAR NEPs 儲存庫. 如需核心協議客戶端的實作細節,請參閱 GitHub 上的 nearcore 儲存庫.

Chunk Validator 與 Block Producer 的角色

NEAR 在無狀態驗證下的驗證器架構涉及三種不同的角色:分塊生產者、分塊驗證者和區塊生產者,每個角色都有不同的職責和狀態儲存要求。

分片區塊生產者 (Chunk Producer)分片區塊驗證者 (Chunk Validator)區塊生產者 (Block Producer)
主要職責構建分片區塊(分片層級的區塊)並產生狀態證明 (State Witness)使用狀態證明驗證分片區塊;產生見證簽名 (Attestation)將來自所有分片且經過簽名的分片區塊聚合為單個規範區塊
是否需要狀態儲存?是:維護完整的本地分片狀態以產生證明否:隨每個分片區塊接收狀態證明,並在使用後將其捨棄否:不直接處理分片狀態
無狀態驗證下的硬體影響硬體需求保持不變;分片區塊生產者仍需要狀態儲存分片區塊驗證者角色的儲存需求降至接近零狀態儲存需求無變化
驗證者數量較小的集合,每個區塊間隔內每個分片一名分片區塊生產者網路中的大多數驗證者較小的集合,每個區塊間隔一名區塊生產者

關鍵的結構性洞察在於,區塊分片驗證者 (Chunk Validators) 是網絡中數量最多的一類,而在無狀態驗證下,他們不再需要昂貴的存儲硬件。只有數量少得多的區塊分片生產者 (Chunk Producers) 仍保留狀態存儲需求,因為他們必須讀取本地狀態來為每個分片生成見證 (Witness)。這種不對稱性使得驗證者群體能夠在不按比例增加網絡總存儲成本的情況下擴張。去中心化的收益精確地集中在規模最大的驗證者類別中。

無狀態驗證下的驗證流程

以下步驟描述了從新的區塊間隔開始,到經驗證的區塊在 NEAR 上完成最終確認的過程。

  1. 區塊分片產出 (Chunk production): 被分配到每個活躍分片的區塊分片生產者會構建一個區塊分片 (chunk,即分片層級的區塊),其中包含在此區塊間隔內待處理的交易。

  2. 狀態見證生成: 區塊生產者從其本機分片狀態副本讀取相關的狀態條目,並將其打包成狀態見證,其中包含該區塊中的交易觸及的每筆帳戶餘額、合約儲存項目和存取金鑰。

  3. 傳輸至分片區塊驗證者: 分片區塊生產者將分片區塊及其狀態見證廣播給在此區塊時段中隨機分配到該分片的分片區塊驗證者。

  4. 無狀態執行: 每個分片驗證者僅使用狀態見證資料來執行分片的交易,在任何時間點都不會進行本地狀態查找。執行完成後,分片驗證者將對該分片的有效性進行證明,並丟棄狀態見證資料。

  5. 區塊組裝: 該時段的區塊生產者收集來自所有活躍分片的已證明資料塊,將其聚合為單個規範區塊,並將其廣播至網路以進行最終確認。

在步驟 3 和 4 的任一階段,區塊驗證器皆不需要本地狀態儲存。狀態見證器會在驗證操作期間提供所有必要的狀態存取。

NEAR 無狀態驗證的優勢

無狀態驗證為 NEAR 網路帶來了三個類別的改進:它降低了最常見驗證者類別的硬體要求、消除了有狀態驗證對分片數量和吞吐量所造成的擴展上限,並改善了開發者在網路上構建去中心化應用程式的基礎設施條件。

降低硬體要求與實現更高程度的去中心化

對於 NEAR 的驗證者集而言,無狀態驗證(stateless validation)最直接的影響是移除了將分片狀態儲存作為區塊片段驗證者(chunk validators)的硬體要求。在有狀態驗證下,區塊片段驗證者的儲存需求會隨著分片狀態的大小而與日俱增,隨著網絡處理更多交易並累積更多狀態,其規模會從數百 GB 增加到數 TB。這造成了逐漸增加的硬體成本門檻。

無狀態驗證完全消除了區塊片段驗證者的這項負擔。該角色對於狀態相關基礎設施的儲存需求降至趨近於零,僅剩下在區塊時間限制內進行交易執行和證明傳輸所需的運算與網路頻寬需求。

去中心化效應直接源於這項硬體變更。較低的儲存成本降低了運行區塊驗證者 (chunk validator) 的總營運成本,從而降低了參與的實際經濟門檻。這使得驗證者群體能夠更龐大且在地理分佈上更多樣化,進而降低了驗證者過度集中的風險。如果一個網路中大多數的驗證者都能在商用硬體上運行,那麼在結構上,它會比那些要求在儲存基礎設施投入大量資本支出的網路更具去中心化抗性。目前無狀態驗證下的區塊驗證者硬體需求規範,請參閱 docs.near.org/validator;) 上的文件以獲取最新數據。

在不犧牲安全性的情況下實現擴展性

無狀態驗證將 NEAR 的分片數量與驗證節點硬體需求脫鉤,從而消除了有狀態驗證對網路吞吐量造成的擴展上限。在先前的有狀態模型下,分片數量增加一倍,會要求指派給這些新分片的每個驗證節點配置成比例的額外儲存空間,這使得大量分片在經濟上受到限制。無狀態驗證打破了這種關係:增加分片可以提高網路容量,而不會增加每個驗證節點的儲存義務。

NEAR 的網路吞吐量大致上與分片數量成正比擴展。更多活躍分片意味著在每個區塊生成間隔內,能平行處理更多區塊片段,這會增加網路每秒可確認的交易數量。無狀態驗證是 NEAR 擴大規模並達到更高分片數量的先決條件。NEAR 基金會的官方文件會提供最新的吞吐量數據;若要查詢與特定分片配置相關的 TPS(每秒交易數)數據,請參閱 docs.near.org

這直接解決了區塊鏈可擴展性三難困境中的可擴展性這一環。在分片網絡上,可擴展性與去中心化之間的歷史性緊張關係源於增加容量通常會提高驗證者硬體成本,從而降低去中心化程度。無狀態驗證消除了導致這種權衡的機制,使 NEAR 能夠在不承受相應中心化壓力的情況下追求分片數量的增加。可擴展性模型在階段 3 動態重分片中得到充分發揮,NEAR 能夠根據即時網絡需求自動調整分片數量,無需任何手動協調。

開發者在 NEAR 上構建的意義

如果您正在評估 NEAR 作為部署平台,無狀態驗證會影響您在基礎設施層級的應用程式,而非合約層級。在您做出架構決策之前,有四個實際影響值得了解:

無需更改合約。 無狀態驗證是協議層級的變更。您的智能合約無需進行任何修改即可從中受益。部署在 NEAR 上的合約會自動在升級後且更具擴展性的網絡上運行。無需遷移步驟,無需重新部署,且 API 無任何變動。

隨著分片數量增長,吞吐量更高。隨著 NEAR 透過無狀態驗證增加更多分片,網路的總交易容量也會隨之提升。對於您的 dApp 而言,這意味著在需求高峰期時,網路壅塞的機率會降低,並且隨著網路擴展,交易成本也會更穩定且可預測。

更具彈性的基礎設施。 更具去中心化的驗證者集合,透過降低分塊驗證者參與的硬體門檻,減少了與中心化相關的網路中斷風險。正式運作的 dApps 將受益於更難被干擾的驗證者網路,因為該網路不易因營運商過度集中或少數資源充足驗證者的硬體故障而受影響。

以太坊開發者之路。 NEAR 支援 Aurora,一個 EVM 相容的執行環境,讓以太坊開發者無需將 Solidity 合約重寫成 Rust 或 JavaScript 即可部署到 NEAR 上。這些合約在相同的底層網路運行,並受益於相同的無狀態驗證基礎架構改進。


NEAR 無狀態驗證與以太坊無狀態路線圖之對比

熟悉以太坊無狀態客戶端路線圖的開發者會發現,NEAR 的無狀態驗證(stateless validation)解決了相同的底層問題:將驗證者與節點硬體從網路狀態規模中解耦。這兩種方法在不同的架構層級運作,並透過不同的機制實現,這是由兩個網路根本不同的結構所塑造的。它們並非相互競爭的設計,而是針對區塊鏈狀態增長所帶來的硬體負擔之平行應對方案。

NEAR 無狀態驗證Ethereum 無狀態客戶端
方法透過每個分塊(chunk)打包的狀態見證(state witnesses)進行分塊級別的無狀態驗證透過每個區塊打包的 Verkle 樹見證(Verkle tree witnesses)進行全鏈無狀態客戶端
機制分塊生產者為每個分塊生成狀態見證;分塊驗證者在沒有本地狀態的情況下執行Verkle 樹見證(EIP-4762)取代 Merkle 證明;客戶端在沒有完整狀態的情況下執行區塊
架構層級在分片執行環境中的分片(分塊)層級應用在單體(單鏈)執行環境中的全節點層級應用
目前狀態Nightshade 的第二階段;請在 docs.near.org 驗證目前的主網狀態長期路線圖項目;EIP-4762 規格正在積極開發中
主要目標讓分塊數量得以擴展,而無需成比例增加分塊驗證者的硬體需求降低全節點儲存需求,使無狀態執行客戶端對 Ethereum 而言更具可行性

這兩種方法都將驗證者或客戶端所需的狀態數據與待驗證的區塊或區塊分片(chunk)封裝在一起,因此執行方永遠不需要本地狀態數據庫。結構上的差異在於,NEAR 的無狀態驗證應用於分片系統中,針對構成其網路主體的分片級驗證者。而以太坊的無狀態路線圖則針對單體執行層上的全節點,在該層中,整個鏈的狀態最終必須透過 Verkle 樹見證(witnesses)而非本地狀態樹(trie)來進行定址。

在分片 (sharding) 的維度上,具體來說,NEAR 的 Nightshade 框架是一種執行分片設計,將狀態 (state) 和計算 (computation) 分割到各個分片上。Ethereum 的 Danksharding 提案則針對 Layer 2 Rollup 的數據可用性分片 (data availability sharding),而非執行分片設計。這些在架構上是不同的目標,服務於不同的網絡結構,因此,直接比較 Nightshade 和 Danksharding 需要承認它們解決的是不同的問題。

無狀態驗證在 NEAR 的路線圖中處於什麼位置?

Nightshade 的第 2 階段即是無狀態驗證。這一等效性值得明確說明,因為 NEAR 文件與社群討論有時會將「第 2 階段」與「無狀態驗證」交替使用,而了解目前處於哪一個階段,能讓您得知網路擴容架構的現狀。

Nightshade 的三個階段詳解

Nightshade 的全面實施分為三個獨特的階段,每個階段都建基於前一階段,並為下一個階段確立先決條件。

階段 1:基本分片 (已完成)

NEAR 將其網路狀態劃分為多個分片,每個分片都平行處理交易。驗證者維護著其負責分片的狀態的完整本地副本。區塊生產者將來自所有分片的區塊碎片匯總成單一的標準區塊。第一階段建立了基於區塊碎片的 Nightshade 架構,但將硬體要求直接與分片狀態大小綁定,這造成了可擴展性的上限,而這是第二階段要解決的問題。

第二階段:無狀態驗證(目前階段)

區塊驗證者不再維護本地分片狀態。區塊生產者會生成狀態見證,並將其與區塊一同交付。這將區塊驗證者的硬體需求與分片狀態大小脫鉤,使網路能夠擴展至更多分片,同時不會成比例增加驗證者的硬體成本。截至撰寫本文時,第二階段已在 NEAR 主網上啟動;有關確切的啟動日期和當前網路狀態,請參閱 NEAR Foundation 部落格) 和 docs.near.org,因為協議階段是逐步啟動的,並且會相應地更新文件。

階段 3:動態分片 (規劃中)

NEAR 將能夠根據即時網路需求自動增加或減少其分片數量,無需手動協調或驗證者硬體升級。無狀態驗證是動態重分片的直接先決條件:在第二階段(Phase 2)未啟動的情況下,增加分片將迫使驗證者承擔不成比例的儲存成本增加,使得自動分片調整在經濟上變得不切實際。第三階段(Phase 3)是實現 NEAR 上理論上無限水平擴展的架構步驟。

總體來說,這三個階段代表了 NEAR 從一個具有固定分片分配和有狀態驗證者的分片式區塊鏈,演進到一個動態可擴展的網絡,該網絡能自行調整其處理容量,而無需其驗證者集合在硬體成本上成比例增長。

NEAR 無狀態驗證:對驗證者與質押者的意涵

對於區塊片段驗證者而言,無狀態驗證消除了 NEAR 先前架構中最大的單一硬體成本驅動因素:維持分片狀態完整本地跟單的要求。這對驗證者營運的經濟效益以及參與驗證者行列的實際門檻有著直接影響。

過去,分片驗證者所需的儲存容量與其所分配分片的狀態大小成正比,且隨著網路累積更多帳戶、合約數據和交易歷史,該需求也隨之增加。分片驗證者的營運成本不僅包括運算和頻寬,還包括隨著網路成長而擴展的持續性儲存基礎設施。

在無狀態驗證(stateless validation)下運行的分片驗證者(Chunk validators)不再需要預留狀態存儲空間。其硬體需求轉向處理交易執行的計算能力,以及在區塊時間內接收狀態見證(state witnesses)與傳輸共識證明(attestations)的網路頻寬。這是一個根本上不同的成本配置:成本趨於穩定而非增長,且在任何給定的分片數量下,其成本均低於之前的模型。

無狀態驗證改變了分塊驗證者的硬體要求,但並未改變根本的質押合約機制。驗證者仍需質押超過席位門檻的 NEAR 代幣來參與共識,並且他們仍會因驗證者不當行為而面臨懲罰(slashing)。滿足該參與要求所需的硬體成本對分塊驗證者而言有所降低,這在方向上擴大了能夠以經濟上可行的營運成本運行分塊驗證節點的參與者群體。有關目前的硬體規格和質押席位門檻,請參閱 docs.near.org/validator.

請注意,區塊生產者(chunk producer)仍然需要完整的本地分片狀態來生成狀態證明(state witness)。硬體需求降低僅適用於區塊驗證者(chunk validator),這是網絡中數量最多的角色。區塊生產者保留了其狀態存儲需求,儘管他們僅佔總驗證者人數的一小部分。

要成為 NEAR 的驗證者,參與者需質押超過目前席位門檻的 NEAR 代幣,並執行驗證者軟體。如需反映無狀態驗證(stateless validation)要求的完整設定說明與最新硬體規格,請直接參閱 docs.near.org/validator)。

常見問題

NEAR Protocol 是用來做什麼的?

NEAR Protocol 是一個第1層區塊鏈,旨在部署去中心化應用程式,包括 DeFi 協議、NFT 平台、遊戲應用程式以及開發者工具。它使用 Nightshade 分片來處理跨越多個並行分片的交易,實現高吞吐量且交易費用接近零。NEAR 代幣支付交易和合約執行的燃料費,而驗證者則質押 NEAR 代幣作為抵押品來參與共識。

NEAR Protocol 如何運作?

NEAR 的核心運作方式是一個權益質押證明區塊鏈,並分為多個分片,每個分片平行處理交易。在每個區塊間隔中,每個分片都會產生一個 chunk(分片級別的區塊);區塊生產者會將這些 chunk 聚合為一個單一的規範區塊。驗證者在每個紀元 (epoch) 被隨機分配到分片,並負責執行和證明其所分配分片 chunk 中的交易。無狀態驗證使 chunk 驗證者無需維護本地分片狀態即可履行此職責。

什麼是 Nightshade 分片技術?

Nightshade 是 NEAR Protocol 的分片框架,網路的全局狀態與交易處理被分割到多個平行分片中。與將每個分片視為獨立的區塊鏈的設計不同,Nightshade 將所有分片視為單個邏輯區塊鏈的組成部分,每個區塊包含每個活躍分片的一個分塊。Nightshade 透過三個階段實現:基本分片(第一階段)、無狀態驗證(第二階段)和動態重分片(第三階段)。

區塊鏈中的狀態見證是什麼?

狀態見證是一種加密資料結構,包含驗證特定區塊或分塊所需的所有狀態資料,並將其打包傳送給驗證者,以便他們在執行期間無需存取本地狀態資料庫。在 NEAR Protocol 中,分塊的狀態見證包含該分塊中的交易所觸及的帳戶餘額、合約儲存項目和存取金鑰。分塊生產者會產生狀態見證,並將其與分塊一起傳輸給分塊驗證者,後者使用見證資料執行交易,並在產生其證明後將其捨棄。

NEAR 驗證者如何運作?

NEAR 驗證者在無狀態驗證下以三種不同的角色運作:分片區塊生產者、分片區塊驗證者和區塊生產者。分片區塊生產者透過從其本地分片狀態跟單讀取相關狀態,來構建分片區塊(分片級別的區塊)並生成狀態見證人。分片區塊驗證者接收分片區塊和狀態見證人,僅使用見證數據執行交易而無需本地狀態存儲,證明分片區塊的有效性,並丟棄該見證人。區塊生產者將來自所有活躍分片的已證明分片區塊聚合到單個規範區塊中。驗證者質押高於席位門檻的 NEAR 代幣以參與共識,並在每個 epoch 被隨機分配到各個分片。

無狀態驗證如何提高可擴展性?

無狀態驗證透過將分片數量與驗證者硬體需求解耦,來提升可擴展性。在有狀態驗證下,新增更多分片會要求分配到每個新分片的驗證者維持相對應的本地儲存,這造成了網路實際上能支援多少分片的硬體上限。在無狀態驗證下,分片驗證者會收到每個分片所需的全部狀態資料作為狀態見證,並在使用後丟棄,因此新增分片不會增加每個驗證者的儲存需求,允許 NEAR 透過增加分片數量來水平擴展,以同時處理更多交易。

NEAR 對開發者來說是個好的區塊鏈嗎?

NEAR Protocol 為開發者提供基於 WASM 的智慧合約,可使用 Rust 或 JavaScript 編寫,一種儲存質押模型,將合約儲存成本與質押的 NEAR 代幣掛鉤,Aurora EVM 相容性,讓以太坊開發者可以部署 Solidity 合約,以及人類可讀的帳戶名稱。無狀態驗證是一項協議級別的基礎設施改進,無需任何程式碼變更即可自動讓所有已部署的合約受益。隨著分片數量的增加,網路吞吐量容量隨之增長,合約也因減少的壅塞而受益。評估 NEAR 用於生產 dApp 部署的開發者,應查閱 docs.near.org 以取得目前的 SDK 規格和工具文件。

NEAR 的無狀態驗證是否已上線?

Nightshade 的第 2 階段(即無狀態驗證)已在 NEAR 主網上啟動。協定階段是逐步推出的,隨著每個階段達到完全啟動,NEAR 基金會將同步更新說明文件。如需了解最新的部署狀態,包括確切的啟動日期及任何特定階段的注意事項,請參閱 NEAR 基金會部落格 以及官方 NEAR 協定說明文件