Proof-of-Stake

要求超過 2/3 的驗證者簽名(按存款加權)是數據可用性問題的解決方案嗎?

  • August 13, 2018

眾所周知,數據可用性問題是區塊鏈系統中的主要問題之一。因此,如果權益證明方案需要一個區塊來收集至少 2/3 驗證者的簽名,並按存款加權,那麼這個問題還存在嗎?

是的,因為一般的權益證明方案,您唯一聲明的要求是收集至少 2/3 驗證者的簽名,按押金加權(我的編輯,否則您可以在 6,000 名驗證者中擁有 4,000 名,最低保證金為設計不當,太小,超過加權存款的 2/3,行為錯誤,預期收益高於損失最低存款的預期損失,從而損害區塊鏈)不能保證數據可用性,因為超過三分之一的驗證者不能保證不會出錯,通用的股權證明共識協議也不能保證拜占庭容錯。換句話說,在超過 67% 的驗證者串通的賄賂攻擊者或協調多數模型中,它是不安全的。

除了使用糾刪碼之外,公證人還可以嘗試下載(檢查可用性)並可能驗證(檢查有效性,如果也充當執行者)排序規則或塊。如果公證人無法下載排序規則,他們可以對其投 0 票(0 表示不同意,1 表示同意)。這些公證人可以通過可公開驗證的隨機源(例如 RANDAO 或 BLS 聚合簽名)隨機改組。然後,由隨機公證人子集組成的委員會也可以對這些選票執行 BLS 聚合簽名。對於超過 gas 限制的非常大的交易,可以在鏈下儲存和驗證交易,例如使用 IPFS、Truebit 等。

另請參閱來自https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQs>和<https://github.com/ethereum/wiki/wiki/Sharding-FAQs的 CTRL+F “availab”片段.

可以從經濟上懲罰股權證明中的審查制度嗎?

與回復不同,審查制度更難證明。區塊鏈本身無法直接區分“使用者 A 嘗試發送交易 X 但遭到不公平審查”、“使用者 A 嘗試發送交易 X 但由於交易費用不足而無法進入”和“使用者 A 從未嘗試過”發送交易 X”。另請參閱有關數據可用性和擦除程式碼的說明。但是,有許多技術可用於緩解審查問題。

首先是通過停止問題來抵抗審查。在該方案的較弱版本中,該協議被設計為圖靈完備的,因此驗證者甚至無法判斷給定的交易是否會導致不希望的行為,而無需花費大量的處理能力來執行交易,從而使自己容易受到拒絕服務攻擊。這就是阻止 DAO 軟分叉的原因。

在該計劃的更強版本中,交易可以在近期到中期的某個時間點觸發有保證的效果。因此,使用者可以發送多個交易,這些交易彼此互動並與預測的第三方資訊互動以導致某些未來事件,但驗證者不可能知道這將發生,直到交易已經包含(並且經濟上最終確定)阻止他們為時已晚;即使排除所有未來的交易,驗證者希望停止的事件仍然會發生。請注意,在這個方案中,驗證者仍然可以嘗試阻止所有交易,或者可能是所有交易都沒有附帶一些正式的證據來證明它們不會導致任何不希望的事情,但這將需要禁止非常廣泛的交易,以至於基本上破壞整個系統,這將導致驗證者由於以存款計價的加密貨幣的價格會下跌,因此會貶值。

第二個,由 Adam Back 描述,要求交易是時間鎖加密的。因此,驗證者將在不知道內容的情況下包含交易,並且只有在以後才能自動顯示內容,到那時再取消包含交易為時已晚。然而,如果驗證者足夠惡意,他們可以簡單地同意包含帶有加密證明(例如 ZK-SNARK)的解密版本是什麼的交易;這將迫使使用者下載新的客戶端軟體,但攻擊者可以方便地提供此類客戶端軟體以便於下載,並且在博弈論模型中,使用者將有動力一起玩。

也許在權益證明環境中可以說的最好的情況是,使用者還可以安裝一個軟體更新,其中包括一個刪除惡意驗證器的硬分叉,這並不比安裝軟體更新來進行交易難多少“審查友好”。因此,總而言之,這個方案也是適度有效的,儘管它確實以減慢與區塊鏈的互動為代價(請注意,該方案必須是強制性的才能有效;否則惡意驗證者可以更容易地過濾加密交易而無需過濾更快的未加密交易)。

第三種選擇是在分叉選擇規則中包含審查檢測。這個想法很簡單。節點監視網路中的交易,如果他們在足夠長的時間內看到一筆費用足夠高的交易,那麼他們會為不包括該交易的區塊鏈分配較低的“分數”。如果所有節點都遵循這個策略,那麼最終一個包含交易的少數鏈會自動合併,所有誠實的線上節點都會遵循它。這種方案的主要缺點是離線節點仍然會跟隨多數分支,如果審查是暫時的,並且在審查結束後他們重新登錄,那麼他們最終會在與線上節點不同的分支上。因此,該方案應更多地被視為促進硬分叉上自動緊急協調的工具,而不是在日常分叉選擇中發揮積極作用的工具。工作量證明算法和基於鏈的權益證明算法選擇可用性而不是一致性,但 BFT 風格的共識算法更傾向於一致性;Tendermint明確選擇一致性,而 Casper 使用混合模型,該模型更喜歡可用性,但提供盡可能多的一致性,並使鏈上應用程序和客戶端在任何給定時間都知道一致性保證的強度。

另請參閱https://github.com/ethereum/wiki/wiki/Sharding-FAQs#what-might-a-basic-design-of-a-sharded-blockchain-look-like

分片區塊鏈的基本設計可能是什麼樣的?

一個簡單的方法如下。為簡單起見,此設計僅跟踪數據塊;它不會嘗試處理狀態轉換函式。

存在稱為提議者的節點,它們接受分片上的 blob k(取決於協議,提議者選擇哪個k或隨機分配一些k)並創建排序規則,因此它們也充當整理者,因此充當提議者和整理者的代理可以被稱為prolators。排序規則有一個排序規則標頭,一條短消息,格式為“這是碎片上的 blobk排序規則,父排序規則是 0x7f1e74,blob 的 Merkle 根是 0x3f98ea”。每個分片的整理形成一條鏈,就像傳統區塊鏈中的塊一樣。

還有一些公證人會下載並驗證隨機分配的分片中的排序規則,並在每個週期通過隨機信標鏈將它們洗牌到新的分片(使用一些可驗證的隨機函式,例如由 BLS 聚合簽名產生的塊雜湊或RANDAO,儘管後者已被測試容易被操縱),並在排序規則中對數據的可用性進行投票(假設沒有 EVM,如果有 EVM,他們也可以充當執行者,對數據的有效性進行投票)。

然後,委員會還可以檢查這些來自公證人的投票,並決定是否在主鏈中包含排序規則頭,從而建立與分片中排序規則的交叉連結。其他各方可能會質疑委員會、公證人、提議者、驗證者(使用 Casper Proof of Stake)等,例如通過互動式驗證遊戲或通過驗證有效性證明。

一條由所有人處理的“主鏈”仍然存在,但這條主鏈的作用僅限於儲存所有分片的排序規則頭。分片的“規範鏈”是分片k上最長的有效排序規則k鏈,其所有標頭都在規範主鏈內。

請注意,現在在這樣的系統中可以存在幾個“級別”的節點:

  • 超全節點- 完全下載每個分片的每個排序規則,以及主鏈,完全驗證一切。
  • 頂級節點——處理所有主鏈區塊,讓它們“輕客戶端”訪問所有分片。
  • 單分片節點- 充當頂級節點,但也完全下載並驗證它更關心的某個特定分片上的每個排序規則。
  • 輕節點——僅下載和驗證主鏈區塊的區塊頭;不處理任何排序規則頭或事務,除非它需要讀取某個特定分片狀態下的某些特定條目,在這種情況下,它將 Merkle 分支下載到該分片的最新排序規則頭,並從那裡下載 Merkle 證明狀態中的期望值。

簡短的回答是肯定的,這些問題仍然存在,但規模很小但可以容忍。

對此的解決方案將是一個完美的拜占庭容錯系統(BFT)。

引用自:https://ethereum.stackexchange.com/questions/50976