Velas 運作原理：歷史證明、EVM 與委託質押

要理解 Velas，需要掌握三個基本零件：快速為事件排序的方法、讓驗證者達成共識的方法，以及執行智慧合約的方法。Velas 從 Solana 承接了前兩個，再加上相容以太坊的執行層。以下說明這些零件如何銜接。

歷史證明：網路的時鐘

多數區塊鏈會浪費時間，因為節點得爭論「誰先發生」。Solana 的答案是歷史證明（Proof of History），這是一條雜湊鏈，每一步都證明距離上一步已經過了一段時間。可以把它想成用數學打造的共用碼錶。因為每個節點都能驗證順序，而不必協商順序，區塊才能在不到一秒的時間內產生。Velas 從 Solana 程式碼繼承了這個設計，所以區塊時間很短。你可以到原生瀏覽器查看目前的區塊高度與活動。

Tower BFT 與驗證者投票

排序不等於共識。驗證者仍需投票決定哪條分支才是正統。Tower BFT 就是投票協議，屬於實用拜占庭容錯的變體，並利用歷史證明的時鐘，讓投票越來越難被撤回。每次投票都會讓驗證者被鎖定在某條分支上一段逐漸變長的時間，所以倒戈的成本會越來越高。一筆交易所在的區塊上方累積越多以質押量加權的票數，這筆交易就越安全。

委託權益證明

驗證者需要質押才能參與，但你不必自己架設伺服器也能分一杯羹。VLX 持有者把幣委託給自己信任的驗證者，驗證者以這份權重投票，並從獎勵中抽取佣金，其餘歸委託人。委託不會轉移所有權：你的幣仍在自己的質押帳戶裡，之後也可以重新委託。官網會顯示驗證者數量與質押總量，健康的網路應有許多驗證者，且沒有哪一方一家獨大。我們的驗證者頁面教你如何評估，質押指南則說明操作流程。

內建的 EVM

以太坊虛擬機是執行 Solidity 位元碼的執行環境。Velas 在原生執行環境旁邊嵌入了一個。送往 EVM 地址的交易由 EVM 端處理，使用以太坊工具所預期的同一套 JSON-RPC 方法，例如 eth_getBalance。這就是為什麼 MetaMask 這類錢包只要設定網路就能連線。Velas EVM 端的 RPC 是公開的，我們的追蹤工具直接在你的瀏覽器中使用它。設定步驟請見EVM 相容性。

兩個地址世界

這種雙重性既是特色，也是學習曲線。如果你只用 EVM 端，它的行為就像另一條以太坊相容網路；進階使用者與驗證者則會與原生端互動。

哪裡提到了 AI

Velas 的資料提到「AI 強化的委託權益證明」。在文件中，這被描述為共識端的機器學習輔助，例如替驗證者的行為打分，而不是嵌在鏈裡的聊天機器人。哪些可以查證、哪些不行，我們在AI 整合文章中逐一說明。

速度到底代表什麼

官網上寫著「最高 75,000 TPS」。那是理想條件下的設計上限，不是平均的每日負載。對使用者而言，真正有用的指標是別的：一筆交易要多久確認，以及要花多少錢。在正常情況下，Velas 這兩項都不錯。數字請看手續費與速度，並排比較則見 Velas 與 Solana 比較。

跟著一筆交易走過整個系統

追蹤一筆交易，更容易記住這套架構。使用者在錢包裡簽署一筆轉帳。錢包把它送到 RPC 節點，節點轉給當前的區塊生產者。生產者把它放進區塊，並由歷史證明的時鐘替它相對其他事件的順序蓋章。其他驗證者重放這個區塊、依規則檢查，然後投票。隨著背後有質押支撐的票數累積，這筆交易從「只是被收錄」變成實質上不可逆。每個階段，錢包或瀏覽器都能顯示一個狀態，這就是為什麼同一筆交易在某個工具裡看起來還在等待，在查詢另一個節點的工具裡卻已確認。

如果這筆交易的目標是 EVM 地址，就由 EVM 執行環境處理，並以以太坊客戶端的方式計算 gas 費用，而外圍的共識仍是源自 Solana 的機制。這就是混合設計的重點：執行對以太坊開發者來說很熟悉，排序與共識則來自另一套設計。

開發者最先注意到的事

對開發者來說，最先遇到的實際差異很小也很具體：不同的鏈 ID、不同的 RPC 網址、不同的區塊瀏覽器，以及原生端需要不同的工具。標準的 Solidity 工具指向公開的 EVM RPC（evmexplorer.velas.com/rpc），用法與其他地方大致相同。合約驗證、gas 估算與事件索引的行為可能與以太坊主網略有不同，所以建議先小規模部署測試，並閱讀官方文件中的注意事項，不要預設每個邊角情況都完全一致。

需要記住的限制

分叉出來的程式碼必須追上上游的改進，而 Solana 自分叉以來進展很快。Velas 團隊維護自己的版本，所以功能與安全修補是依團隊自己的時程推出。網路的存活則取決於驗證者持續在線。這些本身都不是警訊，但在你依賴它之前，值得先到文件與新聞頁查看專案近期的動態。