從 ICP 與 Solana 進行交互
比特幣、以太坊，以及現在的 Solana，互聯網計算機上的智能合約（也稱爲“容器”）可以以完全去中心化的方式與這三大主流區塊鏈進行交互，從而允許開發者創建獨特的多鏈去中心化應用程序（dapp），將 SOL 完全在鏈上兌換爲 BTC 已不再是夢想。
這是通過向互聯網計算機添加兩個新功能實現的，這兩個功能共同完成了 ICP 路線圖的 Helium 里程碑，從而使 Solana 和 ICP 更加緊密地聯繫在一起：
閾值 EdDSA 允許容器安全地計算 Ed25519 簽名，這是 Solana 交易使用的簽名方案；
SOL RPC 容器利用容器的功能發出 HTTPS 請求（HTTPS 外發），通過使用其 JSON-RPC 接口到達 Solana 區塊鏈。
第一個功能已在博客文章(使用 Schnorr 和 ECDSA 簽名解鎖 Chain Fusion)中介紹過，本文將重點介紹第二個功能，即 SOL RPC 容器。
概要
從非常高的層次來看，SOL RPC 容器爲容器提供相同的服務，就好像 Solana RPC 節點直接在互聯網計算機上可用一樣，從而使容器能夠與 Solana 區塊鏈進行交互；
該容器通過 HTTPS 調用聯繫多個 JSON-RPC Solana 提供商並聚合他們的響應來實現這一點，以避免單點故障；
它作爲由管理整個互聯網計算機（網絡神經系統）的 DAO 控制的服務運行，這意味着容器可以直接調用 SOL RPC 容器，而無需任何額外的設置（例如，不需要 API 密鑰），並且相信任何更改都需要社區審查和批准的提案。
如何使用
該容器現已上線，提案編號爲 #136985，位於信託子網上。
最好的入門方法是查看代碼庫，想先睹爲快嗎？以下是如何從命令行檢索 Solana 主網上最新完成的插槽：
以下是如何在容器內進行操作：
如您所見，我們還添加了一個客戶端庫（參見 sol_rpc_client crate），以便您可以輕鬆地從您的容器內部與 SOL RPC 容器進行交互。
不要忘記查看存儲庫中提供的示例，瞭解互聯網計算機上的容器如何在 Solana 上發送 SOL 或 SPL 代幣！
工作原理
簡而言之，SOL RPC 容器類似於 EVM RPC 容器，但有一個不同之處（如下所述）：
無單點故障：SOL RPC 容器公開了一個接口，該接口將幾個關鍵的 Solana JSON-RPC API 封裝成一個類型便捷的 Candid 接口，通過規範化和比較來自多個提供程序的給定調用結果來確保響應的一致性，默認情況下，每個請求將並行查詢 3 個不同的 Solana JSON-RPC 提供程序，並要求所有響應均相同，Dapp 可以針對每個調用自定義策略，以滿足其安全需求，而無需依賴單個提供程序，例如，他們可以要求 5 個提供程序中的 3 個對結果達成一致。
由網絡神經系統控制：網絡神經系統（NNS）是一個去中心化自治組織（DAO），它管理着互聯網計算機，從而使得構建由社區治理的民主化、去中心化應用程序成爲可能，SOL RPC 容器就是這樣一個應用的例子，它由 NNS 控制，這意味着它的治理與整個互聯網計算機的治理一樣安全，對容器代碼的任何更改，例如更改提供商的 URL，都必須通過提案進行，該提案必須經過（質押的）ICP 代幣持有者（也稱爲神經元）的仔細審覈和投票。
使用 Cycles 代替 API 密鑰：大多數 Solana JSON-RPC 提供商都需要 API 密鑰來驗證其 API 的調用，而這又需要一個賬戶，通常還需要信用卡，這使得使用他們的服務變得極其繁瑣，SOL RPC 容器的調用者無需管理 JSON-RPC 提供商及其 API 密鑰，相反，他們只需通過附加 cycles（互聯網計算機上的原生貨幣，用於支付資源費用，例如以太坊上的 gas）來支付調用費用。
可擴展：SOL RPC 容器爲部分（但非全部）Solana JSON-RPC 端點提供了 Candid 接口，對於其他端點，SOL RPC 容器提供了一個端點（jsonRequest）來發送任何 JSON-RPC 請求，以便您仍然可以從 SOL RPC 容器中受益（例如，查詢和聚合多個提供程序的響應），如果 SOL RPC 容器提供的提供程序無法滿足您的用例（例如，需要設置不同的速率限制），您還可以指定自己的自定義提供程序。
快速區塊時間 - 轉換
如果這聽起來很像 EVM RPC 容器，那是因爲它們非常相似，事實上，兩者都利用 HTTPS 調用通過提供的 JSON-RPC 接口訪問另一個區塊鏈，然而，一個關鍵的區別是，由於當前 HTTPS 調用的限制，SOL RPC 容器無法支持某些 Solana JSON-RPC 方法（例如 getLatestBlockHash），爲了理解這個問題，如果你嘗試在終端中獲取最新的最終區塊哈希，你可能會看到類似這樣的信息：
有趣的是，雖然執行所有 3 個請求只用了不到 1 秒，但所有結果都不一樣！現在想象一下 34 個節點並行執行該請求（這是信託子網上的節點數），你就能明白會發生什麼：大多數響應都會有所不同，節點將無法達成共識。
在 Solana 上，由於驗證者會在主鏈上投票，並且 Solana 的出塊時間很快（約 400 毫秒），給定承諾級別（即使已完成）的區塊高度會不斷變化，這意味着 Solana 在任何承諾級別上的區塊高度變化速度都比信託子網上 HTTPS 外發的典型延遲（大約 3 秒）更快。
這實際上不僅對 getLatestBlockhash 而且對許多其他端點（例如 getSlot）來說都是一個問題，但是，我們可以使用另一個技巧：HTTPS 調用還可以指定一個所謂的轉換函數，該函數允許節點在達成共識之前修改收到的響應，由於 getSlot 的結果只是一個數字，因此轉換隻需使用舍入（默認爲 20，但調用者可以指定）來人爲地增加時隙時間，從而增加達成共識的機會。
HTTPS 調用的一個限制是，指定的轉換是本地操作，僅考慮節點收到的響應，由於結果是一個固定長度的隨機字符串，因此這不足以支持 getLatestBlockHash，支持該方法，以及更普遍地說，支持任何具有快速變化響應的端點，將需要更復雜的轉換，例如，這可能涉及考慮其他節點收到的其他響應，以便能夠使用某種多數或中位數策略。
如何在沒有 getLatestBlockhash 結果的情況下發送 Solana 交易？基本上有兩種選擇：
使用持久事務；
通過以下組合檢索相當新的區塊哈希：
使用 getSlot，由於達成共識所需的舍入誤差，它將獲得相當新的時隙；
使用 getBlock 獲取該時隙的區塊，其中包含區塊哈希。
結論
SOL RPC 容器的發佈標誌着 ICP 路線圖 Helium 里程碑的完成，該里程碑使互聯網計算機上的智能合約能夠與 Solana 區塊鏈進行交互，立即查看 SOL RPC 代碼庫及其示例，開啓您的智能合約之旅：
github.com/dfinity/sol-rpc-canister
參考
EVM RPC 博客文章：
ICP <> 以太坊：ICP 的 EVM RPC 容器如何連接網絡
ICP 路線圖：Chain Fusion Helium
internetcomputer.org/roadmap#Chain%20Fusion-Helium
Solenoid 里程碑博客文章：
Solenoid：互聯網計算機的去中心化邊緣
關於 Schnorr 和 ECDSA 簽名的文章：
使用 Schnorr 和 ECDSA 簽名解鎖 Chain Fusion
你關心的 IC 內容
技術進展 | 項目信息 | 全球活動
收藏關注 IC 幣安頻道
掌握最新資訊
