民主治理軟體專案的技術可能性

數位服務如 Drobox、GitHub 通常由公司帶領產品走向，並且傾聽用戶回饋來完善服務。這個循環運作完善時，用戶可以付費得到它需要的軟體，而公司可以因此獲利。這樣的流程可以稱為是產品治理（或是公司治理，看治理的對象是什麼）。

由於部分的產品是純粹的軟體服務，產品的邏輯大多都在程式裡面完成，要修改這些邏輯通常需要透過軟體開發人員協助達成。但既然是純數位的服務，那有沒有可能直接透過客戶的回饋甚至投票直接決定產品的走向呢？是否有一種方式可以達成就連管理者也無法否決治理決議的技術可能性呢？

這就是我們今天想探討的社會實驗  —  民主治理軟體專案的技術可能性。

探索與假設

首先假設一個小範圍的軟體服務來評估可行性如何。假設有一個待辦事項軟體服務，使用者可以註冊帳號，並且使用這個軟體紀錄待辦事項。

當我們要設計一個可以反饋使用者需求，自動化採納提案的框架，該怎麼做呢？當一個使用者想加入一個功能「增加 Priority 欄位」並且發起投票後採納，我們需要克服哪些技術障礙？

第一件可以做的事情是採用開放原始碼的授權，並且在 GitHub 接受用戶的 Pull Request，這樣的話想要修改邏輯的使用者可以透過這個途徑完成。

接下來要如何同意這個修改可以合併入源碼中呢？我們可以透過一個投票系統來完成這件事情，但設計一個可以永續發展專案的投票機制是個很龐大的主題，這邊我們先暫且不討論，但可以說我們需要一個投票系統來達成。最簡單的方式可以做成「如果這個 Pull Request 得到 10 個讚就合併入專案源碼」，我們可以透過另一台伺服器監控投票狀況，如果投票通過就讓 Pull Request 自動合併入專案。

接下來要處理的是部署的問題，我們可以透過像是 GitHub Action 這樣的持續整合 (Continuous Integration, CI) 的服務達成自動部署，最終的目的可能是部署到 AWS 上面的伺服器主機，完成整個專案治理框架。

問題

但這樣的技術真的有辦法達成完全民主的治理框架嗎？通過投票的提案就一定可以加入到系統當中嗎？仔細觀察上面的例子就可以發現有很多狀況無法達成。

首先這個投票系統會觸發 Pull Request 合併入專案，這項工作會需要一個伺服器執行，如果這個伺服器提供者的利益跟這個提案有衝突時，他很有可能會停止伺服器運作，讓這個提案無法通過。

部署也是一樣的問題，甚至當服務架構在 GitHub 或 AWS 上面也一樣，只要服務提供者的利益跟提案衝突，每個環節都會有一個管理者，管理者的權力無法完全放棄，只能轉移給另外一個人。但是另一個人依然會有管理權限，當利益衝突時，總是會有人可以按下那個停止按鈕。

就像是最近發生的 GME 在 Robinhood 與其他券商只能賣卻不能買的事情一樣，當利益衝突時，總是有一個切入點讓當權者控制。

所以，全然民主的數位產品治理在目前的技術框架上仍然無法完成嗎？並不是，如果這個專案的核心邏輯運作在區塊鏈上就會有達成的可能。

解方

我們一樣假設還是相同的待辦事項軟體，使用者介面可能還是需要放在 Web 上面，但核心邏輯可以搬到區塊鏈上，透過 Web 介面跟區塊鏈互動。首先為了可以修改程式邏輯，我們可以使用 openzeppelin-upgrades 套件 來將系統分成兩個部分，Proxy 與 Implementation。

Proxy 本身存放了服務的資料與一些些邏輯。本身的邏輯不多，主要是一個 upgrade(imp) 的功能來設定新的 implementation。而 implementation 則是真正的邏輯所在，以待辦事項服務來說，可能會有 addTodo(), removeTodo() 等邏輯，但取用資料時還是會跟 Proxy 取用資料。

一般使用者都會直接呼叫 Proxy 上的功能如 addTodo() 或 removeTodo()，執行時 Proxy 會直接調用 implementation 的邏輯。

當邏輯需要升級時會先部署一個新的 implementation，接下來再透過 proxy 的 upgrade() 指定新的 implementation 真正的所在處，如此一來就可以完成升級。

那誰可以升級邏輯呢？ openzeppelin-upgrades 定義了一個 admin 的角色，只有 admin 才可以執行升級，而這樣的設計可以讓我們透過民主機制來升級。這個 admin 除了是真的持有密鑰的使用者外，同時也是可以是另外一個程式。如此一來，我們可以把 admin 設定給一個投票程序，整個升級程序就可以變成民主決定。

回到原本的情境，如果有人想要加一個新功能時，此時他可以直接先把修改過的核心邏輯 implementation 部署到區塊鏈上去，這個新的邏輯我們稱為 impV2。

此時待辦事項的 proxy 還沒指向新邏輯，所以還會是舊邏輯。此時使用者可以發起投票來決定待辦事項軟體要不要執行 upgrade(impV2) 升級到他的新邏輯。接下來使用者開始進行投票，如果過了門檻之後投票程序就會開放任何一個人透過 callUpgarde() 執行 upgrade(impV2)，此時就連系統管理者都無法阻止核心邏輯的升級了。

在這樣的情況下，整個軟體服務的治理將可以轉變成民主治理模式，完成前面提到無法在中心化系統達成的框架。在原本的中心化系統中，不論如何追到最後總是有一個中心化的仲裁者，而區塊鏈上的程式由不特定的礦工執行，這樣的結構大幅度地降低權力的集中。

同時區塊鏈上的智能合約就是一段程式，也可以透過程式控制各式各樣的邏輯，既可以設計成集中權力管理，同時也可以選擇設計成非集中權力的管理。這樣的彈性讓我們可以完成民主治理的數位產品。

講到這裡我想大家會有很多疑問，畢竟目前幾乎所有主流的服務都是採用集中式的管理方法，剛開始會有很多觀念需要多花點時間思考才能想通。

並不是說民主的管理機制就一定是最棒的，但是去中心化的平台讓這件事情成為可能，從原本我們別無選擇只能用集中式的治理方式，只能靠「信任」來維繫管理者真的會執行大家一起決定的事情（就連現在的民主政治其實也是依靠信任），純數位的產品在區塊鏈上反而可以透過平台的特性來達成更多元的治理方式。

當然這樣的模式下會遭遇什麼困難沒有人可以料到，也沒有太多參考範例，前面會有各式各樣的困難等著需要去面對。

而這就是我現在參與一個去中心化金融 (Decentralized Finance, DeFi) 產品 Perpetual Protocol 的目標治理方式，朝著去中心化治理 (Decentralized Governance) 模式前進。我們現在還是集中式的治理模型，但經常在談論未來我們要如何過渡到一個去中心化的治理機制。

這場實驗的終點是什麼我還不知道，但我是帶著興奮又忐忑不安的心情在探索這樣的可能。如果你對這樣的設計也有興趣也歡迎討論，另外如果對 DeFi 有興趣的話就更好了，這是我們的招募信箱！