Security
Ripple 是如何解決共識期間的 sock-puppet 問題的？
我的印像是，Ripple 使用基於共識的系統來確定兩種付款中的哪一種是權威的，而另一種由於缺乏支持者而被拒絕。這種形式的決策似乎容易受到 sock-puppet 攻擊。
有人是否有可能在一家商店中創造高價值支出，然後通過精心定時的 sock-puppet 攻擊來否定它，從而使原始支出被具有更多（假）支持的較低價值支付所壓倒？
簡而言之，共識過程中資源是如何消耗的？
這樣的攻擊將如何進行？據推測，必須先達成對一項交易達成一致的共識，然後再達成對另一項交易達成一致的後續共識。否則，沒有人會依賴第一筆交易被接受，也就不會受到攻擊。
但是他們對第一個共識做了什麼？如果他們參與其中，他們現在已經驗證了兩個交易。每個人都會有絕對的證據證明他們是騙子，所以沒有人會關心他們是否驗證了第二個。
如果他們不參與，那麼每個人都會有絕對的證據證明他們驗證了與先前接受的交易相衝突的交易。同樣，每個人都會有絕對的證據證明他們是騙子。
也許你在想他們可能會試圖回過頭來聲稱第一個共識實際上與實際下降的方式不同，從而對過去提出了相互矛盾的看法。問題是，關於過去的資訊不是通過查看我們過去達成的共識來建立的。關於過去的資訊是通過查看目前的共識和行走雜湊鏈來了解過去發生的事情來建立的。對過去撒謊不會幫助你改變關於每個人現在在哪裡的共識。
本質上，共識僅用於通過一系列檢查點建立交易順序。沒有辦法說“將該交易移回過去，使其發生在過去”。一旦被驗證，過去是不可改變的。
對於這樣的攻擊，你可以做的是阻止網路達成共識。但是，你必須通過明顯不合理的行為來做到這一點，宣布沒有在達成共識方面取得進展的立場。一旦人們發現你這樣做，他們就會停止讓你參與共識過程，你必須重新建立信任。