如何對抗作弊節點？
據我所知，乙太坊上大致有兩種合約呼叫。一種旨在改變區塊鏈的全域狀態（即改變一些儲存值或轉移資金）。另一種只是從區塊鏈中獲取數據而無需任何修改。
第一種交易將在乙太坊網路上廣播，但第二種交易只會發送到你有 RPC 連接的節點。
我的問題是：雖然第一種合約呼叫可以通過區塊鏈共識算法得到保障，那麼第二種呢？如果您連接的節點作弊並為 dApp 提供錯誤數據怎麼辦？有什麼辦法可以防止此類節點作弊的情況發生嗎？
這並不完全是關於信任隨機節點。這是關於信任你用來與區塊鏈通信的節點——你很可能將兩種類型的交易都發送到同一個節點。如果你不信任那個節點，那麼你就不能真正信任任何東西——你甚至不知道該節點是否真的連接到區塊鏈，或者它是否只是給你隨機結果。
這就是為什麼通常較大的項目執行自己的節點的原因。那裡有節點提供者（例如 Infura），但由於區塊鏈中無信任通信的性質，向項目添加額外的信任要求（外部服務提供者）是沒有意義的。基本上人們傾向於使用此類服務提供商的唯一原因是它們易於使用並且您不需要維護自己的節點。
我的建議是僅將外部節點提供程序用於測試和其他類似的東西，但特別是如果您有一個嚴肅的項目，您應該考慮執行自己的節點。
只是為了擴大勞裡的回答，這個問題可以改寫，
如果我不相信自己的設備怎麼辦？
這可能是一個問題，但不僅限於乙太坊節點。它一直延伸到金屬。您究竟想要做什麼將取決於您賦予您想要保護的資產的價值。例如，沒有人會阻止您建立自己的鏈下節點集群，檢查具有不同堆棧的區塊鏈，並確認對任何查詢的一致同意。他們應該始終100% 同意——否則，就會出現故障。拉響警報！
是的，但我們/我們的使用者/有人使用 Infura。
這就是將“你的節點”角色外包給服務，這與將“你的硬體”角色外包給雲提供商沒什麼不同。乙太坊的信任模型沒有改變——仍然可以理解，你信任自己的設備，但你已經委派了責任。您和您的使用者有責任問自己是否足夠信任 Infura，或者您是否會更信任自己的節點。
資訊洩露
節點服務的一個不明顯的問題是只讀操作的公開。許多合約的編寫都理解一個
view或pure呼叫是在使用者和他們的節點之間而不是廣播到網路。通過擴展，可以假設除使用者之外的任何人都不知道機密輸入，但是當外包節點服務可以觀察輸入時，這種假設就會失效。例如，考慮一個公開散列函式的合約，也許是為了確保任何語言的任何客戶端都能夠始終模仿合約使用的確切散列算法：
function hashHelper(uint nonce, bytes32 salt) public pure returns(bytes32) { return keccak256(abi.encodePacked(address(this), msg.sender, none, salt)); }這個人為的例子接受一些輸入並返回一個雜湊值。
nonce猜測該雜湊是否出現在區塊鏈上應該是不切實際的。但是，如果節點即服務協助生成雜湊，那麼他們會看到輸入，也會看到雜湊。如果他們不誠實，他們可以觀察已知的雜湊值出現在鏈上，並且他們可能通過在其他任何人（呼叫只讀函式的發送者除外）之前知道這個幻數來獲得一些東西。包含這樣一個函式可以說是一個很好的做法，以確保未來的客戶總是有辦法計算這樣的東西，但即使合約提供了方便的捷徑，也有利於在客戶端計算這樣的東西也是一個好主意.
本地節點還是輕客戶端？為什麼不兼得？
在實踐中，您通常希望呈現一個 Web UI 並為使用者提供選擇，因此輕量級客戶端/移動設備可以使用 Infura（或類似的），而其他人可以執行自己的節點。有EIP-1102需要考慮。它極大地改善了使用者體驗，並且傳統的連接方法將被淘汰。
所有這些考慮因素使得初始化客戶端有點像關注網路。看看這個教程，它展示瞭如何在瀏覽器支持的情況下實現 EIP-1102，如果可能的話回退到注入的 Web3，如果他們正在執行的話，進一步回退到使用者自己的節點。
- https://status.im/developer_tools/run_on_status/eip-1102.html
- https://github.com/b9lab/eip-1102-example
希望能幫助到你。