什么是DAOstack
DAOstack是一套軟件棧，它用于構建與運行DAOs(Decentralized Autonomous Organizations)，即去中心化自治組織。
所謂的去中心化自治組織，就是它們的運作，是建立在P2P軟件基礎上，并遵循無層級的決策。這些決策往往是針對大家共同擁有的資源，比如資金。DAOstack做的這些工作，正是其相信DAOs的結構，將改變我們的世界，因為它會讓人與人之間的協作，更加容易、直接，也更容易規模化。
DAOstack瞄準了構建DAOs的全流程，因此在它的軟件棧中包括了從P2P決策模塊，到全功能的用戶接口的所有構件。如果通過該棧的UI，甚至不需要太多的技術知識儲備，就可以構建用戶所需要的DAO。而且DAOstack還包含了將這些自治組織鏈接在一起的工具，因此隨著該DAOs網絡的成長，所有基于DAOstack的各DAO也將會隨著擁有更強的組織治理能力。
DAOstack架構
綜述
下面中DAOstack的架構圖：
從下往上看，架構圖中構件分別是：
Infra，它是完成通用去中心化決策的基礎組件；它是一組以太坊智能合約庫，包括投票機（voting machines）和聲譽系統（Reputation system）。
Arc，它是以太坊智能合約，用于注冊DAO的構建模塊和標準組件等，以實現我們想要類型的DAO；
Subgraph；它是基于TheGraph協議實現的，用來查詢DAOs狀態與信息的高速緩存（Caching Layer）。
Arc.js，它是一個Javascript的庫，方便Dapps來訪問Arc里的智能合約。
Dapps，它就是各DAO呈現給用戶具體的去中心化應用，比如去中心化選舉系統等。
DAOs，這其實已不是DAOstack的組成部分，而代表著遵行DAOstack機制運行著的一個個DAO。
智能合約（Smart Contracts）
Infra
Infra是一個用Solidity編寫的智能合約庫，它包含了DAOstack協議的2個主要組件：
投票機（Voting Machines）：它是一個通用型合約（所有的DAO都可以調用），將用于處理投票事務。每一個投票機都要遵循它自己預先設定的決策規則；根據DAOstack的共識協議，決策可以依據簡單的絕大多數同意通過規則，也可以更加復雜的邏輯。
投票權限管理（Voting Rights Management）：該系統就是一個智能合約，它用于確定投票權限是如何分布的；該系統會記錄每個投票參與方的投票權限大小；運行在DAOstack的DAOs，會用聲譽（reputation）來計量參與方的投票權限；這“聲譽”就是數字，將跟隨參與方參與提案投票的成功與失敗，而增長或減少。
Arc
Arc也是一個智能合約庫，它用于構建DAOs。它會調用Infra的投票機和投票權限管理系統，以向用戶提供去中心化的自治組織（DAOs）。除了調用Infra合約，用Arc構建的DAOs還會用到以下的基礎合約組件：
Avatar：它是DAO的賬戶，這個合約代表了DAO的地址，并掌管著它的資產。
Token：DAO原生的ERC20代幣，DAO根據協議可以鑄幣，并向它的成員發幣。
Plugins：插件，它們將為DAOs提供豐富的功能，可以各種方式擴展DAO的能力，例如：在Uniswap上做交易，授予投票參與方聲譽，升級DAO的合約，注冊新的插件和限制等等。
全局限制（Global Constraints）：通過插件用于規范一個DAO的行為，當DAO執行來自調用者的指令時，控制器（Controller）會檢查相應的限制，看看該調用是會違反，如有違反，將阻止這些調用的執行；這些限制將限定一個提案要花費多少，一個用戶可以擁有多少聲譽等等。
控制器（Controller）：它用于完成DAO的訪問控制；它將管理誰可以訪問DAO的哪個功能，也是DAO的限制控制的落地組件。
Arc V1中提出了通用型合約（uinversal contracts）的概念：合約只被部署一次，但可以被所有的DAOs使用或訪問。這樣可以節省gas費和部署的費用。插件和限制都可以是此類通用型合約。
子圖（Subgraph）
DAOstack目前基于 The Graph 協議，實現了一個子圖（subgraph），用于索引區塊鏈的事件（events），使得應用程序通過GraphQL的查詢語句，可以訪問這些events的信息。我們可以從這里獲取更多關于The Graph的文檔，也可以在Graph Explorer中找到我們定制的子圖。
Arc.js（Javascript庫）
Arc.js是一個Javascript的庫，將方便我們訪問Arc中的智能合約。它提供了方法，來與以下構件交互：
Arc智能合約：投票，創建提案，投注與執行提案等等。
DAOstack子圖：查詢DAO中的數據。
通過Arc.js，Javascript/Typescript的開發者可能編寫腳本和程序，來與已存在的DAOs進行交互，向DAOs發布提案，為提案投票或投注，執行決策結果，管理用戶的聲譽等，這些對于想要獲得基于區塊鏈去中心治理各種好處的開發者而言，特別有幫助，因為這樣不用直接面對智能合約的開發語言了。
去中心化應用（Dapps）
去中心化應用（dapps），其實也是典型的Web應用程序，但它與傳統Web應用程序最大的不同，是建立在去中心化的框架（例如區塊鏈）上。DAOstack目前自己創建并維護了兩個dapps：Common和Alchemy。
Alchemy是建立在DAOstack的全棧上：Arc.js，DAOstack的子圖，Arc和Infra。該應用將給用戶部署新的DAOs，查閱存在的DAOs，并與已存在的DAOs交互，比如投票，創建提案等等，帶來更加方便的途徑。
全息共識
全息共識這個詞主要意味著，識別一組人的共同意愿，不需要組織里絕大多數人都要參與共識這種活動。用另外一句話來講，全息共識是指代那些決策的技術，通過這些技術可以準確地代表組織整體的意見，但是又不需要組織中的個體都來參與投票或決策。這與傳統區塊鏈PoW等共識機制，要求所有有資格的人都要參與，是有本質不同的。
規模化問題
全息共識是DAOstack去中心化治理實現的關鍵點，因為它解決了去中心化系統中規模化的問題：它讓決議時，很好地在代表與大量的成員之間，做到了很好的平衡。我們都知道，一般治理系統中，如果決策更快，則意味著想要精確地代表系統中代表的意愿，就更加困難。
我們這里和這里來更多地了解這個規模化問題，以及全息共識是如何應對這個問題的。
共識協議
所謂的共識協議，這里是指DAOstack實現的所有技術，這些技術為DAOs實現了一個特殊的算法，基于這個算法或協議，再實現了DAOs中的投票機（Voting Machine）
這個共識協議，是全息共識基于智能合約的一個實現，它為運行在Infra層的投票機所遵循。
概覽
所有的提案是要提交到DAO。一旦提交，這些提案就成為了常規提案（regular proposals）。常規提案要想成功通過，就要獲得絕大多數（>50%）的投票。這個票數往往很難達到。
而遵循共識協議的每個提案，則還會有一個預測市場與之相關聯。在該預測市場中使用GEN代幣。DAO的成員，或一般公眾，可以使用GEN來對這些提案進行投注，他們可以押提案通過，也可以押提案不通過。押注對的，將獲得獎勵。缺省情況下，DAO也會投注GEN（它被稱作DAOstake），并押提案不通過。DAO這樣做，其實是提供經濟激勵，讓對提案是好的預測者，有積極性來預測該提案會通過。
當提案押注通過的GEN總數達到一定的門檻，就會被提速。也就是這類提案，只要相對多數（贊成票數多于反對票數）就可以通過。當然，這個條件相對需要絕對大多數來講，就更容易達到。
總的來講，這讓DAO可以更快地通過提案，并擁有高可信性，同時還不需要眾多的投票人參與。因為預測者都被激勵著來確保這些提案擁有較高的代表性。
協議狀態
一個打開著的提案（也就是還沒有被決策的提案），可以是以下狀態中的一種：
Queued：所有的提案一提交，缺省就會進入queued狀態，并會有一注押反對的（由DAO押的）；該投注的數額由minimumDaoBounty參數設置，此種狀態下的提案，在有絕對大數的投票，才能獲得最終決策（根據>50%的票數屬于哪方，而確定該提案是通過，還是不通過）。
Pre-boosted：在滿足S~u~/S~d~ > C^b^時，提案就會從Queued狀態變遷到Pre-boosted狀態；其中S~u~是支持提案的投注數，而S~d~則是反對提案的投注數，C是一個常量，而b是當前已提速的提案數量；在這個狀態下，提案將對所有成員打開，開始接收投注；而當反對的投注數增長較快，并且不滿足上述的不等式時，該提案將回退到Queued狀態。
Boosted：當提案持續待在Pre-boosted狀態一段時間（這個時間由preBoostedPeriodLimit參數來確定），就會進入這個boosted狀態；在這種狀態下的提案，則只要求相對多數就可以通過（例如贊成票多于反對票）；在這種狀態下，該提案將打開大家投票通道，而關閉投注通道；因此，一旦提案進入到了Boosted狀態，就再也回不到Queued或Pre-boosted狀態；這種狀態會持續boostedVotedPeriodLimit參數所設定的時間。
QuietEndingPeriod：這種狀態代表提案被決策的最后階段；在這個階段里，提案可能由通過變成不通過，也可能由不通過變成通過；只有當提案保持通過或不通過情形超過由quietEndingPeriod參數確定時間時，提案才處于最終被決策（采納或放棄）；這個狀態主要用來規避最后時刻投票沒有被統計到的情形。
投注與獎勵
以下是一個提案可能結果：
提案在隊列中，在規定的時間內，未能獲得任何決議；這種情況下，所有的押注將退回給相應的投注人。
該提交被采納或被否決；投注失敗者，將失去他們的押注，而勝出者將收回他們的押注，并按比例分享失敗者的押注；反對者的押注中還包括了DAOstake，只要DAO有GEN，每次提案提交，它會自動投注這注反對押注。
要注意的是，對于一個給出的提案，來自同一個地址的投注人可以進行多次投注。但是后面的投注要與前面的投注一致。也就是講如果你開始投注了贊成，那在后面的投注中也只能投贊成；不能投注兩方。
參數
下面是關于該共識協議中用到若干參數的解釋：
Address：這些參數存放的以太坊地址（不是該協議自己的地址）；例如：0x332b8c9734b4097de50f302f7d9f273ffdb45b84。
Activation Time：提案第一次提交的日期與時間（遵循 Unix time格式）；例如：12:00 PM UTC on July 14th, 2019 (active)。
Boosted Vote Period Limit：提案處于boosted狀態的時間跨度；例如：7 days (604800 seconds)。
DAO Bounty Constant：它是一個常量，被處于boosted狀態提案的平均反對押注數額所乘，用于計算出DAO自動投注的反對投注應該是多少；例如：10。
Proposal Reputation Reward：對通過的提案進行獎勵的數額；這個數額代表著投票的能力；例如：500 REP
Minimum DAO Bounty：指一個DAO針對每個提案最少要押注GEN的數量；這個押注是押提案不通過；例如：250 GEN
Pre-Boosted Vote Period Limit：是指一個提案保持某個可信分數（ upstake / downstake > boosting threshold）的時間長度；只有達到這個時間，才可能從Pre-Boosted狀態進入Boosted狀態。例如：1 day (86400 seconds)
Queued Vote Period Limit：這個參數用于設置非boosted態的提案（pre-boosted態或regular queue態），開放用于投票的時間量；例如：45 days (3888000 seconds)
Queued Vote Required：它用于設置所有聲譽（投票能力）在yes或no中的占比；該占比用來裁決一個non-boosted的提案是通過，還是被否決；例如：50%
Quiet Ending Period：它是一個時間跨度；它是因投票存在潛在結果而需要的；這個時間是要求維持同樣的結果一定時間，以確認該結果可以是正式的結果；例如：2 days (172800 seconds)
Threshold Constant：該參數控制著進入boosted狀態的速度，因為它設定了達到可信分數的門檻；而門檻將隨著當前處于boosted狀態提案數量的上升，而變得更高（threshold = threshold constant ^ 當前boosted提案數量）；例如：1.2
Voters Reputation Loss：它用來設置一個投票人投票能力如果在非boosted提案投票中失敗，將損失的投票能力占比；假如你有100個聲譽，而這個參數被設置為4%，就意味著你將因為投票失敗，而損失4個聲譽。
參考
-
DAOstack
-
https://github.com/daostack
總結
以上是生活随笔為你收集整理的什么是DAOstack的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： StreamNative翟佳：若无社区，
- 下一篇： python 基础语法--print，i