隨著 Casper 協議持續達成一個越來越穩定的形式，人們對協議中將要被設定的各種各樣的引數也越來越感興趣，包括利率，費用，贖回期限，速度，需要用作股份的 ETH 最小數量，等等。這篇文章將是嘗試描述協議中包含的各種各樣權衡的系列文章的第一篇，並且將重點放在具有經濟最終化的協議中的去中心化與效率上。

首先，我們將會簡短地定義經濟最終化(economic finality)（我們將會假設一個 2/3 的閾值；Vlad Zamfir 將很快會指出我們實際上想要節點能夠設定他們自己閾值的能力）。

經濟最終化，版本1：狀態 H 是經濟上最終化的，如果至少 2/3 的驗證者簽署了證明 H 的訊息，並且在任何不包含 H 的歷史中，他們會損失他們全部保證金。

經濟最終化，版本2：狀態 H1 是經濟上最終化的，如果足夠多的驗證者簽署了證明 H1 的訊息，並且如果 H1 和一個衝突的 H2 同時被最終化，那麼會有相關證據可以用來證明至少 1/3 的驗證者是惡意的，並因此毀掉他們全部的保證金。

當前，我和 Vlad 都在致力於贊成版本2的協議。但是注意兩個版本的經濟最終化都需要（i）至少 2/3 的驗證者簽署某一訊息，（ii）驗證這些訊息的網路*（在後面有一個巨大的星號，因為證明發現是有方法來解決這個問題的，只不過他們基本上是分片思想的形式，所以對於一個“最大化簡單”版本的 Casper，我認為他們是帶外的）。

現在的意思是，為了狀態 H 能夠被最終化，網路必須驗證一個來自至少 2/3 的驗證者池的訊息

• 最終化時間：在狀態 H 被提議以後，經過多少秒，狀態 H 被最終化？

• 去中心化：這裡定義為驗證者池的大小，例如，一個區塊鏈可能有容納 1000 個活躍驗證者的空間。注意這個直接與可訪問性（即成為一個驗證者，必需的最小數量 ETH）有關。但是隨後關於這個會有更多資訊。

• 開銷：每秒全節點（包括驗證節點）需要驗證多少訊息？

理想情況下，我們想要最小化達成最終化所需的時間，最大程度的去中心化以及最小化的開銷。但不幸的是，我們不能三者兼得。具體來說，從上述給出的驗證者訊息的事實來看，我們得到這個數學等式：

f*o≥d*2/3

其中，f 是以秒為單位的最終化時間，o 是開銷，d 是驗證者池的大小（去中心化）。這是來自物理學中“速度=距離/時間”這一著名定理的一個簡單翻譯：如果你需要在 f 秒（“時間”）內處理 d*2/3 的訊息（“距離”），那麼每秒處理的訊息數量（“速度”）是 d*2/3 / f。注意在現實情況中，共識協議需要多輪訊息的輪換，所以上述等式極有可能是 f*o≥d*2，並且在正常情況下，會有超過 2/3 的節點出現。因此，為了方便，我們就使用：

f*o≥d

現在，讓我們列出一些引數來說明這個不等式。考慮類 PBFT 演算法的協議，其中，區塊 n 總是在開始下一個區塊 n+1 之前被最終化，並且假定區塊時間是 10 秒。假設你想支援 500 個驗證者，那麼，10*o≥500，所以開銷至少是每秒鐘處理50條訊息。

現在，考慮一個基於鏈的使用5秒區塊時間的權益證明協議，所以 o = 1/5，並且假設 10000 個驗證者。那麼，f/5≥10000，所以 f≥50000（例，14個小時）。一種中間途徑是使用大概 1000 個驗證者，每秒 1 條訊息的開銷，以及 1000 秒的最終化時間（大概15分鐘）。你可以自由地在這個等式中設定你自己的引數，看看什麼是可能的，什麼是不可能的。再一次強調，重要的結論是，我們不能擁有這 3 種特性，至少同時達到不可能。

所以，有四條前進的路線：

• 以高程度的去中心化與低開銷為目標，讓最終化時間特別長。交換用於超過一個小時的最終化時間，所以告知他們它仍然會是這樣。

• 以高程度的去中心化與短的最終化時間為目標，但是要求節點處理高開銷。告訴全節點操作者面對現實並接受這個事實，並致力於改進輕客戶端協議。

• 以低開銷與短的最終化時間為目標，使驗證權利變得難以接近。致力於改進去中心化的權益池軟體作為一個基本層次去中心化的次最好方案。

• 丟棄經濟最終化的目標。

注意在型別 1 的經濟最終化的上下文中，你可以嘗試得到“部分”的經濟最終化（例，在你需要獲取 67% 的驗證者保證金的 1/20 時間裡，獲取到對同一個訊息簽名的 3.33% 的驗證者保證金，這仍然是一大筆錢），但是在型別 2 的經濟最終化的上下文中，你不能做上述事情，因為你根本得不到經濟最終化，除非超過 50% 的驗證者對同一個狀態簽名。同樣，無論在哪一種上下文中，我們可以在三種特性之間尋找到權衡的方式。

對於權益池的確定性閾值簽名

注意，我們關於橢圓曲線配對預編譯的研究工作是很重要的，因為與 zk-SNARKs (零知識證明)演算法一起，早期的這些研究工作可以用來實現確定性閾值簽名。因此，我們可以有一個這樣的系統，在該系統中，我們在基本層面也許只有100個驗證者，但是期望這些驗證者中的大部分都是以池的形式出現。這些驗證者的驗證程式碼將會是一個閾值簽名的證實者（可以在常數時間內計算出），並且這個閾值簽名證明池中至少 2/3 的參與者贊成給定的雜湊值。每一個池自身也許有幾十個甚至幾百個參與者。

我們為什麼不能在高層面就使用確定性閾值簽名？首先，他們不會披露誰參與其中，僅僅是足夠的人蔘與其中。所以我們不知道獎勵誰，懲罰誰。第二，他們與密碼學抽象的目標相悖，之所以是密碼學抽象，是我們想要協議中的每一個使用者，包括驗證者，能夠使用他們想要使用的密碼學。

理論上，這些驗證者池可以以許多不同的方式管理。兩個最顯而易見的範例是：

• 全開放：存在一個智慧合約，任何人都可以通過該智慧合約加入驗證者池。

• 封閉的：驗證者池是由一組彼此瞭解的朋友構成的。

全開放的驗證者池是有風險的，因為一個攻擊者可以以大量身份加入該池，大體上可以發起 51% 攻擊；因此，全開放驗證者池中的參與值有著不是由於自己錯誤而導致財產損失的風險。然而，攻擊者也將損失與他們的受害者同樣多的資金（例，悲傷因子(griefing factor)的界限大約是 0.5-2 ）。封閉的驗證者池是更安全的，但是當然他們依賴於人們擁有信得過的不會共謀傷害他們的朋友。在現實中，可論證地，這種型別的驗證者池允許一個更加可容忍的去中心化水平，只要在基礎的驗證者集合中有足夠的“槽”，允許大量不同的驗證者池能夠被建立。

有另外一種型別的權益池，它使用可信的硬體而不是確定性閾值簽名；看Loi Luu 最近的部落格獲取更多資訊。再一次注意，這樣一個設計不要求整個網路信任一個特殊品牌的可信硬體；相反，它只要求在那個特定池中的參與者這樣做，一個魯棒的重度使用這種模式的網路極有可能包含大量使用不同可信硬體解決方案的不同驗證者池，還有青睞於確定性閾值簽名的使用者以及僅僅“自己單幹”的。

除了效率，權益池有另外一個優勢：它移除了個人參與者的負擔：(i) 100% 的線上時間以及(ii)不被黑客攻擊。

從驗證者數量到最小權益ETH

給定一個驗證者數量（例，d = 1000），接下來的問題是：這個如何轉換成對於使用者個人來說很重要的另一個變數 – 他們需要多少 ETH 來成為一個（基本層面）驗證者？對於此，有一些方案：

• 設定某個最低保證金規模（例，500 ETH），讓作為權益的 ETH 數量，還有總的驗證者數量（因此，要麼最終化時間，要麼開銷）浮動。

• 設定一個最大的驗證者數量，隨著當前活躍的驗證者數量接近最大值，增加最低保證金規模直到無窮大。

• 介於兩者之間的一些中間策略，例，你可以考慮設定最低保證金規模到等於當前權益驗證者的數量。

為了檢查最壞的情況，我們得到這麼一個簡單的數學公式：
總的作為保證金的以太幣 = 最低保證金規模 * 驗證者的數量
原因是很明顯以及無爭議的。現在，我們能夠做的就是允許擁有超過最低保證金規模的人們存一個更大的保證金，並且計算此次存款一次。如果這個發生了，然後現實中，我們將會得到一個比最壞情況更好的結果。假設 Zipf’s 定理是正確的，那麼一個給定保證金規模處的樂意的驗證者數量與那個規模是呈相反比例的，所以例如，在 1000 ETH 處的樂意的驗證者數量10倍於在 10000 ETH 處的驗證者數量。一種快速方法是假設對於每一個整數 n>= 1存在一個規模為最大驗證者保證金規模/n 的樂意驗證者，其中最大驗證者保證金規模本身是這個模型的一個輸出。

現在，固定某個驗證者數量。最大 k 個驗證者儲存的總的 ETH 數量，例如，對於所有 1<=n<=k 的最大驗證者保證金規模/n的和大概接近於最大驗證者保證金規模*（ln(k) + 0.5）（其中 ln 是自然對數，即求解最大驗證者保證金規模 * ，這是調和級數，其中 0.5 為尤拉-馬歇羅尼常數，參見wiki），所以我們得到以下等式：

驗證者數量 = 最大驗證者保證金規模 / 最低保證金規模

總的保證金以太幣 = 最大驗證者保證金規模 * (ln(驗證者數量) + 0.5)

如果我們固定任何兩個變數，然後我們就可以解出另外兩個變數的值。假設我們固定最小保證金規模到 500 ETH，並且假設 1000 萬 ETH 的總儲存規模。那麼我們可以解上述等式，得到下列結果：

• 2412 個驗證者

• 最大的驗證者有 1206000 ETH 的保證金規模

如果我們約減最低保證金規模到 50 個ETH，那麼我們會得到 19291 個驗證者；如果我們增加它到 1500 個ETH，那麼我們得到 911 個驗證者。可選地，我們能夠從另外一個方式解決這個數學問題：如果我們想要 1000 個驗證者的目標值，那麼最低保證金規模為一個均衡的大約 1350 個ETH。注意，全部這些都假設使用你想要的超過最低規模的保證金加入是可能的；如果我們沒有這個特性，那麼權衡方案會由於作為擁有更大保證金的驗證者的一個大約 log(n) 的因子變得更加糟糕，將不得不分裂他們自己到許多賬戶，每一次一個狀態最終化時都會生成許多簽名。為了這個原因，支援可變的超過最低保證金規模的保證金被認為是一件有益的事情。