【契約民主主義】コントラクト設計

1. プリセットされた提案がいくつか存在する。これはプロトコルのソースコードとして実装はされず、デプロイされたコントラクトに注入される初期データとして実装される。市政の単位で具体的に列挙すると「提案選別局」「市民管理局」「税管理局」が必要である。

2. 国民は自らのブロックチェーンアドレスを個人番号と紐づける。政府は個人番号をスマートコントラクト上で管理していなければならない。個人番号の追加と削除が政府管轄の団体の鍵で権限で可能である必要がある。個人番号管理団体のアドレスを登録する特殊なクラスの提案が必要である。

3. 提案は「提案者アドレス、提案内容データへのIPFSのURL、ランダムに選ばれた審議員アドレス、政府によって選定される専門家アドレス、審議員の票」の状態を持っている。

4. 審議員の投票コントラクトは barrywhitehat /semaphore のようなzk-SNARKsを用いた匿名投票を再利用するか、政府のみ誰が誰に投票したか知りうるCoinJoin的な設計になる。

5. 既存の法や行政に反対したり改善する活動もまた提案としてインクリメンタルに行われる。

6. 戦時の戒厳(非常事態宣言)は、「時間制限付きの提案投票権の全権政府委任提案」として実装される。一定期間がすぎると再度審議投票が必要。実質的な「スマートコントラクト上の軍事独裁政権」となる。

7. 提案によって新たな行政組織を同じブロックチェーン上のスマートコントラクトとして実装する場合、税収の向け先は国庫スマートコントラクトアドレスにしなければならない。

8. 国庫への納税は自国通貨のERC-20トークンにより行われる(例: 円)。しかしコントラクト内部では運用の目的で $LEND などのデリバティブにUniswapで変換されて保管され、運用益を上げる。提案可決時の引き出しにおいて、相当額の $LEND がUniswapなどで変換されて提案者に送信される。

9. 政府は一院制であり、内閣府構成員は試験及び提案を経て選ばれる。構成員のアドレスは提案時に定義され、提案の可決とともに登録される。この提案から登録は自動で行われるべきものであり、「登録用の提案」という特殊なクラスが必要であることが示唆される。除名に関しても特殊なクラスの提案が必要だろう。

10. ロジック部のコントラクトをupdatableにするプロキシが必要。どのロジックを選択するの意思決定はonlyOwnerではなく提案と真偽と投票で行われる。したがってコントラクト更新のための特別なクラスの提案が必要で、その提案は更新後のコントラクトアドレスを提案時に定義されていなければならない。国庫残高や提案のストレージコントラクトは疎結合になっていなければならない。

11. onlyCourt modifierにより裁判所権限で許可すべき操作のため、裁判所アドレスを同上の仕組みで登録できなければいけない。onlyCourt modifierはステーブルコインや証券トークンのような、国の介入があったほうが効率的な派生プロトコルで使用可能であり、裁判所を計算機資源として使用可能にするものである。

12. 開発者引き出し可能枠を毎年割り当ててwithdrawコントラクトでvalidateするのに使用できること。割当率は提案で変更可能な変数とし、特殊な提案クラスで操作するものとする。開発者アカウントの新規任命は同上。