熟議の流れについて

フロー

  1. 提案者は、500DAIの供託とともに「Problem」と「Type」を記述したleglangファイルをブロックチェーンへ提出する。Problemは文字列であり、Typeは「通常(normal)、任命(assignment)、罷免(dismissal)、変数変更(variableUpdate)」がある。また、通常提案が国庫のうちの予めブロックチェーンに設定された比率(例: 0.25%)を上回る場合は自動的に「大規模熟議」となる。
  1. ブロックチェーンは、予めブロックチェーンに設定された人数の審議員らを抽選し、提案に登用する。
  1. 審議員らは、その提案を審議するに値するか決議を取る。
  1. 議決がTypeに依存した閾値を大きく下回るなら供託没収と熟議停止。
  1. 審議するに値すると判断された提案には、予めブロックチェーンに登録されたファシリテーターらからランダムに1名登用される
  1. ファシリテーターは提案にジャンルタグを任意の数だけ付与する
  1. ジャンルタグに対応した、予めブロックチェーンに登録された専門家らがランダムに登用される
  1. 参加者らは提案にModreq(Modification Request)を提出し、任意の数の「Proposal」を提案に記述する。
  1. Modreqの型は「problemId, proposalIndex, docIndex, List<Map<Map<CMD,string>,Map<targetLine,uint>,Map<newlineURL,URL>>>, quorum」である。つまりModreqは多数決によりマージされる。
  1. Proposalは、どのサブセットにいくら予算を注入するかを示す「Headerクラス」と、どのような法令を追加するかを示す複数の「Lawクラス」を持つ
  1. HeaderとLawは同じ「Docクラス」を継承しており、Docクラスは「List<Map<uint, URL>>型」である。つまり各行の文章をIPFSに保存したURLを持つ。
  1. 一通りModreqとQuorumが繰り返され、ProblemのProposalsが整ったところで、任命熟議は「ボルダルールに基づく投票」を行い、通常熟議と変数変更提案は「中央値ルールに基づく投票」を行い、大規模熟議と罷免熟議は多数決を行う。FinalJudgeTxが投票を担い、Proposalそれぞれに順位をつけることとなる。順位に対応したスコアがProposalに蓄積する。
  1. 最もスコアの高いProposalが採用され、Header情報を参照して予算が指定のサブセットに届き、対応するLawはLawViewerから参照される対象となる。

「決め方」について

ボルダルール

複数の性質の異なる選択肢から「多数派ではなく全員のために選ぶとき」に有効。合議的で、ある地区やジャンルの政治家を候補者から選ぶときに良い。
→任命熟議

中央値ルール

グラデーションのある複数の選択肢から一つ選択するのに良い。合議的。政策の具体化に好相性。
→通常熟議, +変数更新提案 

多数決

二択によい。全体のためというより多数派のための選択になるため、マイノリティはあえて黙殺される。正解のない究極の二択によい。
→Modreq,大規模熟議,罷免熟議, +Citizen Revision Proposal (国民増減提案) 


参考

ProposalDSL,LawDSL,LawViewerの原型について: +LVM 
UI要素およびラフ案参照: +熟議UIプロト