Loading...
熟議の流れについて
フロー
提案者は、500DAIの供託とともに「Problem」と「Type」を記述した
leglangファイル
をブロックチェーンへ提出する。Problemは文字列であり、Typeは「通常(normal)、任命(assignment)、罷免(dismissal)、変数変更(variableUpdate)」がある。また、通常提案が国庫のうちの予めブロックチェーンに設定された比率(例: 0.25%)を上回る場合は自動的に「大規模熟議」となる。
ブロックチェーンは、予めブロックチェーンに設定された人数の審議員らを抽選し、提案に登用する。
審議員らは、その提案を審議するに値するか決議を取る。
議決がTypeに依存した閾値を大きく下回るなら供託没収と熟議停止。
審議するに値すると判断された提案には、予めブロックチェーンに登録されたファシリテーターらからランダムに1名登用される
ファシリテーターは提案にジャンルタグを任意の数だけ付与する
ジャンルタグに対応した、予めブロックチェーンに登録された専門家らがランダムに登用される
参加者らは提案にModreq(Modification Request)を提出し、任意の数の「Proposal」を提案に記述する。
Modreqの型は「problemId, proposalIndex, docIndex, List<Map<Map<CMD,string>,Map<targetLine,uint>,Map<newlineURL,URL>>>, quorum」である。つまりModreqは多数決によりマージされる。
Proposalは、どのサブセットにいくら予算を注入するかを示す「Headerクラス」と、どのような法令を追加するかを示す複数の「Lawクラス」を持つ
HeaderとLawは同じ「Docクラス」を継承しており、Docクラスは「List<Map<uint, URL>>型」である。つまり各行の文章をIPFSに保存したURLを持つ。
一通りModreqとQuorumが繰り返され、ProblemのProposalsが整ったところで、任命熟議は「ボルダルールに基づく投票」を行い、通常熟議と変数変更提案は「中央値ルールに基づく投票」を行い、大規模熟議と罷免熟議は多数決を行う。FinalJudgeTxが投票を担い、Proposalそれぞれに順位をつけることとなる。順位に対応したスコアがProposalに蓄積する。
最もスコアの高いProposalが採用され、Header情報を参照して予算が指定のサブセットに届き、対応するLawはLawViewerから参照される対象となる。
「決め方」について
ボルダルール
複数の性質の異なる選択肢から「多数派ではなく全員のために選ぶとき」に有効。合議的で、ある地区やジャンルの政治家を候補者から選ぶときに良い。
→任命熟議
中央値ルール
グラデーションのある複数の選択肢から一つ選択するのに良い。合議的。政策の具体化に好相性。
→通常熟議,
+
変数更新提案
多数決
二択によい。全体のためというより多数派のための選択になるため、マイノリティはあえて黙殺される。正解のない究極の二択によい。
→Modreq,大規模熟議,罷免熟議,
+
Citizen Revision Proposal (国民増減提案)
参考
ProposalDSL,LawDSL,LawViewerの原型について:
+
LVM
UI要素およびラフ案参照:
+
熟議UIプロト
Please turn on JavaScript to use Paper in all of its awesomeness. ^_^
フロー
「決め方」について
ボルダルール
中央値ルール
多数決
参考