2020 年 8 月 Solana 發表了 Stake-o-Matic 程式，此程式幫助代幣持有者平均委託代幣至各驗證人，目標是打造去中心化的股權分布。

透過研究原始代碼與文件，熟悉了這項程式之後，我們對此程式表示十分認同並著手進行優化，以下將開放我們的版本並闡述我們的觀點。

此 URL 是我們的 stake-o-matic 的版本:
https://github.com/forbole/solana/tree/stake-o-matic/forbole/stake-o-matic

與原始版本的區別

1. 停止創建未委託的權益

在原始版本中，Stake-o-Matic 起先會為每一個在清單中的驗證人創建兩種權益帳號，分別是基本權益與獎勵權益帳號。然而進入委託階段時權益帳號只會派給符合資格的驗證人，產生多數未被委託的權益帳號，造成資源的浪費。
因此，我們決定改善流程，只為符合資格的驗證人創建權益帳號，來避免未被委託的權益占用資源的問題。

2. 從不合格的驗證人收回權益

原始的 Stake-o-Matic 會基於驗證人狀態，像是區塊跳過率( skip rate )來評定他們的品質。 當驗證人掉線或是不符合優良驗證人的標準時，在他身上的基本或獎勵權益將會被停用，成為未被委託的權益，直到他們的狀態達到標準後才會被重啟。
與上面提及問題一樣，未被委託的權益會占用資源且不會得到任何的收益。 所以在我們的新設計上，若驗證人在經過權益停用階段之後還是不符合委託資格的話，這些未被委託的基本或是獎勵權益則將會被收回。
此外，掉線的驗證人也會從觀察清單被移除。他們還是有機會再次加入清單獲得權益，關於新增的機制我們將在下一個觀點上說明機制。

3. 選擇新的驗證人填補空缺

為了選擇新的驗證人來取代被移除掉的驗證人，我們製作了過濾機制，透過傭金率、總權益比重及區塊跳過率來選擇優良的驗證人。

4. 使用客製化標準自動產生初始驗證人清單

原始程式會使用 cluster 做為參數獲取驗證人清單，其中並沒有任何機制排除掉線的驗證人，導致在一開始就會有很多未被委託的權益帳號，增加管理的難度。
為了解決這個問題，我們當初使用手動的方式新增有名且優質的驗證人至清單，並且成功執行了程式，但這明顯地不是一個去中心化的作法。

這使得提及於上一個觀點的想法──過濾機制的誕生，它除了可以使用在填補空缺上以外，也幫助我們決定了初始的驗證人清單。換句話說，過濾機制也使管理委託權益變得更為簡單。

如何使用

首先請先從 github 複製代碼並使用 cargo 建置。

git clone https://github.com/forbole/solana
git checkout stake-o-matic/forbole
cd solana/stake-o-matic
cargo build

接著使用以下命令來執行。

../target/debug/stake-o-matic <ADDRESS> <KEYPAIR> \
— quality-block-producer-percentage 75 \
— baseline-stake-amount 0.01 \
— bonus-stake-amount 0.05 \
— validator-list validator.yaml \
— validator-min-length 20 \
— stake-percentage-cap 5 \
— commission-cap 100 --confirm

stake-percentage-cap 和 commission-cap 會被使用在過濾機制上，而 validator-min-length 是決定最少委託驗證人數量的參數。

注意:
在 testnet 上驗證人的傭金率大多被設定為 100%，在 testnet 使用本程式請設定 commission-cap 至 100。
請確認收回權限與你所使用的公鑰同一。

未來

Stake-o-Matic 的原始設計是透過驗證人二次委託來分散代幣分布，但是我們認為這個想法可以直接實現在代幣持有者上。可以想像一下，有一個圖形化介面程式執行於本地環境，並且藉由過濾機制來確認驗證人清單，幫助我們週期地自動改組權益分布。

根據目前的架構，權益帳號被分為基本與獎勵帳號委託至每一個驗證人。然而我們已經使用了過濾機制來產生優良驗證人清單，這表示我們可以將兩種帳號合而為一，從而增加管理權益的效率。

這些想法還在討論中，期望在下一個版本能夠看到他們實現。

參考資料

• Stake-o-Matic Delegation Matching Program, Eric Williams
• Playing with Solana Stake-o-Matic, Smith