DAOテクノロジーハブ

DAOガバナンスにおけるオンチェーン/オフチェーン投票システムの技術的比較と実装戦略

はじめに：DAOガバナンスにおける投票の重要性

分散型自律組織（DAO）は、スマートコントラクトとコミュニティの合意形成によって運営される新しい組織形態です。そのガバナンスの中核を担うのが「投票システム」です。メンバーは投票を通じて、プロトコルのアップグレード、資金の配分、新たな提案の承認など、多岐にわたる意思決定に参加します。

DAOの投票システムは大きく「オンチェーン投票」と「オフチェーン投票」の二つに分類されます。それぞれのシステムは異なる技術的特性を持ち、DAOの目的や規模に応じて最適な選択が求められます。本稿では、これら二つの投票メカニズムについて、技術的な側面から詳細に解説し、その比較と実践的な実装戦略について考察します。

オンチェーン投票システム

オンチェーン投票とは、ブロックチェーン上にデプロイされたスマートコントラクトを通じて、投票のプロセス全体（提案作成、投票、結果集計、実行）が完結するシステムです。

技術的仕組みと特徴

オンチェーン投票は、通常、ERC-20などのガバナンストークンを保有するユーザーに投票権が付与され、投票アクション自体がトランザクションとしてブロックチェーンに記録されます。これにより、以下の技術的特徴が実現されます。

• 完全な透明性と耐改ざん性: すべての投票記録はブロックチェーンに永続的に保存され、誰でも検証可能です。特定の主体による不正な操作は極めて困難です。
• 自動的な実行: 投票結果に基づいて、スマートコントラクトが自動的に次のアクション（例：資金移動、プロトコルパラメータ変更）を実行できます。これは「アトミックな実行」とも呼ばれ、手動介入なしに決定が実行されるため、信頼性の高いシステムを構築できます。
• 高度な分散化: 中央集権的なサーバーや管理者への依存がありません。

技術的メリットとデメリット

メリット:

• 確実な実行保証: 投票結果に基づき、スマートコントラクトが確実にアクションを実行します。
• 高い信頼性: ブロックチェーンの特性により、投票の整合性が保証されます。
• 究極の分散性: 完全なP2Pのガバナンスを実現します。

デメリット:

• Gasコスト: 各投票アクションがオンチェーントランザクションとなるため、Gas代が発生します。参加者が増えるほど、全体のコストは増加します。
• スケーラビリティと速度: ブロックチェーンの処理能力に依存するため、大規模なDAOでは投票プロセスが遅延する可能性があります。
• 複雑性と柔軟性の欠如: 一度デプロイされたスマートコントラクトのロジック変更は困難であり、重大なバグ修正や機能追加には複雑なアップグレードメカニズム（プロキシパターンなど）が必要です。

実装例：Solidityによるシンプルな投票コントラクトの概念

以下は、イーサリアム上でオンチェーン投票を実現するためのシンプルなSolidityコントラクトの概念的な骨格です。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol"; // OpenZeppelin ERC20インターフェースをインポート

contract SimpleOnchainVoting {
    IERC20 public governanceToken; // ガバナンストークンのアドレス

    struct Proposal {
        uint256 id;
        string description;
        uint256 yesVotes;
        uint256 noVotes;
        uint256 creationBlock;
        uint256 endBlock;
        bool executed;
        address proposer;
    }

    mapping(uint256 => Proposal) public proposals;
    uint256 public nextProposalId;

    // ユーザーが特定の提案に投票済みかどうかを追跡
    mapping(uint256 => mapping(address => bool)) public hasVoted;

    event ProposalCreated(uint256 proposalId, string description, address proposer);
    event Voted(uint256 proposalId, address voter, bool support, uint256 voteWeight);
    event ProposalExecuted(uint256 proposalId);

    constructor(address _governanceTokenAddress) {
        governanceToken = IERC20(_governanceTokenAddress);
    }

    /**
     * @dev 新しい提案を作成します。
     * @param _description 提案の説明
     * @param _votingPeriodBlocks 投票期間をブロック数で指定
     */
    function createProposal(string memory _description, uint256 _votingPeriodBlocks) public returns (uint256) {
        require(_votingPeriodBlocks > 0, "Voting period must be greater than zero");
        uint256 proposalId = nextProposalId++;
        proposals[proposalId] = Proposal({
            id: proposalId,
            description: _description,
            yesVotes: 0,
            noVotes: 0,
            creationBlock: block.number,
            endBlock: block.number + _votingPeriodBlocks,
            executed: false,
            proposer: msg.sender
        });
        emit ProposalCreated(proposalId, _description, msg.sender);
        return proposalId;
    }

    /**
     * @dev 提案に投票します。
     * @param _proposalId 提案ID
     * @param _support 賛成ならtrue、反対ならfalse
     */
    function vote(uint256 _proposalId, bool _support) public {
        Proposal storage proposal = proposals[_proposalId];
        require(proposal.id == _proposalId, "Proposal does not exist");
        require(block.number <= proposal.endBlock, "Voting period has ended");
        require(!hasVoted[_proposalId][msg.sender], "Already voted on this proposal");

        uint256 voterBalance = governanceToken.balanceOf(msg.sender); // トークン残高を投票重みとする
        require(voterBalance > 0, "No governance tokens to vote");

        if (_support) {
            proposal.yesVotes += voterBalance;
        } else {
            proposal.noVotes += voterBalance;
        }
        hasVoted[_proposalId][msg.sender] = true;
        emit Voted(_proposalId, msg.sender, _support, voterBalance);
    }

    /**
     * @dev 投票期間が終了した提案を実行します。
     * @param _proposalId 提案ID
     */
    function executeProposal(uint256 _proposalId) public {
        Proposal storage proposal = proposals[_proposalId];
        require(proposal.id == _proposalId, "Proposal does not exist");
        require(block.number > proposal.endBlock, "Voting period has not ended");
        require(!proposal.executed, "Proposal already executed");

        // 簡略化のため、ここでは「yesVotesが多い」という条件で実行可否を判断
        // 実際のDAOでは、クォーラム（投票参加率）や閾値（過半数など）のロジックを追加
        if (proposal.yesVotes > proposal.noVotes) {
            // ここに提案の実行ロジックを記述（例：資金移動、別のコントラクト呼び出し）
            // 例: transferFundsToTreasury(proposal.amount);
            proposal.executed = true;
            emit ProposalExecuted(_proposalId);
        } else {
            // 提案が否決された場合の処理
        }
    }
}

（概念図を挿入：オンチェーン投票のフロー：提案、投票、結果集計、実行のライフサイクルを示すフロー）

このコードはあくまで概念的なものであり、実際のプロダクション環境では、クォーラム要件、閾値、タイムロック、アップグレード可能性、投票委任（Delegated Voting）、スナップショットブロック番号による投票権の確定など、より複雑なロジックとセキュリティ対策が求められます。

オフチェーン投票システム

オフチェーン投票とは、投票プロセス自体はブロックチェーンの外で行われますが、投票権の確認や結果の検証にはブロックチェーンのデータ（通常はウォレットのアドレスとその時点でのトークン残高など）を利用するシステムです。投票結果は最終的にオンチェーンアクションとして実行される場合と、情報共有のみに留まる場合があります。

技術的仕組みと特徴

オフチェーン投票の主な特徴は、ユーザーがトランザクションを送信する際にGas代を支払う必要がない点です。ユーザーは自身のウォレットで投票内容に署名（EIP-712などの標準を利用）し、その署名済みのメッセージを中央サーバーや分散型ストレージ（IPFSなど）に送信します。

• 署名ベースの検証: ユーザーのウォレットアドレスとブロックチェーン上のデータ（例：特定のブロックでのトークン残高）を組み合わせることで、投票権を確認します。
• IPFSなどでのデータ保存: 投票内容はIPFSなどの分散型ストレージに保存され、リンク（CID）がブロックチェーンイベントとして記録されることもあります。
• オンチェーン連携の可能性: オフチェーンで集計された投票結果は、通常、マルチシグウォレット（例：Gnosis Safe）を介してオンチェーンでの資金移動やスマートコントラクト呼び出しに利用されます。

主要ツールと技術的アプローチ

1. Snapshot: 最も広く利用されているオフチェーン投票プラットフォームの一つです。

• Gasレス投票: ユーザーは投票内容に署名するだけであり、Gas代はかかりません。
• スナップショットブロック: 特定のブロック高におけるトークン残高に基づいて投票権を決定します。これにより、投票期間中にトークンが移動しても投票権は固定されます。
• IPFSへの保存: 投票データはIPFSに保存され、改ざん耐性のある状態で公開されます。
• The Graph Protocolとの連携: ブロックチェーンのイベントを効率的にクエリし、投票権の計算や提案の表示に利用します。
• Gnosis Safeとの連携: Snapshotで可決された提案は、Gnosis Safeのマルチシグトランザクションとして作成され、DAOの資金移動やコントラクト実行に利用されることが一般的です。

2. Tally: オンチェーンとオフチェーンの両方のガバナンス活動を追跡・表示するためのプラットフォームです。主にCompoundやUniswapのような大手プロトコルで利用されており、提案のライフサイクル、投票、議決権の委任などを包括的に管理します。

技術的メリットとデメリット

メリット:

• Gasレス: ユーザーはGas代を支払う必要がないため、投票への参加障壁が低い点が大きな利点です。
• 高速な処理: ブロックチェーンの混雑に左右されず、投票の作成や集計が迅速に行えます。
• 高い柔軟性: UI/UXの改善、複雑な投票ロジックの導入、投票方法の多様化（単一選択、複数選択など）が容易です。
• 試行錯誤の容易さ: 低コストでガバナンスの実験が可能です。

デメリット:

• オンチェーン実行の課題: オフチェーン投票結果をオンチェーンに反映させるためには、通常、マルチシグウォレットの署名者による手動実行が必要です。この段階で中央集権的な信頼モデルが導入される可能性があります。
• 信頼モデルの考慮: 投票データがブロックチェーン外に保存されるため、データの整合性や可用性に対する信頼モデルを考慮する必要があります。IPFSなどの分散型ストレージを利用することで、このリスクは軽減されます。
• アトミック実行の欠如: 投票結果の実行が自動化されないため、実行の遅延や、意図しない変更が発生するリスクがわずかに存在します。

（概念図を挿入：オフチェーン投票からオンチェーン実行へのフロー：Snapshotでの投票からGnosis Safeでの実行までのフロー）

オンチェーン vs オフチェーン投票システムの技術的比較

二つの投票システムは、異なるトレードオフを持ちます。プロジェクトのニーズに応じて適切な選択を行うことが重要です。

| 特性項目 | オンチェーン投票 | オフチェーン投票 | | :--------------- | :----------------------------------------------- | :------------------------------------------------- | | 投票コスト | 高い（Gas代が必要） | 無料（署名のみ、Gas代不要） | | 処理速度 | 遅い（ブロックチェーンの混雑に依存） | 速い（リアルタイムに近い） | | 実行の自動性 | 高い（スマートコントラクトによるアトミック実行） | 低い（通常、手動または外部トリガーによる実行） | | 耐改ざん性 | 極めて高い（ブロックチェーンの不変性） | 高い（署名検証、IPFS保存など）だが、オンチェーンに比べると一段階落ちる | | 柔軟性 | 低い（コントラクト変更が困難） | 高い（UI/UX、投票ロジックの変更が容易） | | 分散性 | 究極の分散型 | 投票プロセス自体は分散型だが、実行には中央化要素が入りうる | | 透明性 | 完全な透明性 | 投票データは公開されるが、実行は別プロセス | | 複雑性 | スマートコントラクトの設計・監査が複雑 | システム全体の統合が複雑（署名、ストレージ、実行層） |

（概念図を挿入：オンチェーン vs オフチェーン 投票システム比較：決定力、コスト、速度、セキュリティなどの比較表）

ハイブリッド型アプローチ：両者の利点を組み合わせる

多くの成熟したDAOでは、オンチェーンとオフチェーンの投票システムを組み合わせた「ハイブリッド型アプローチ」が採用されています。これは、それぞれのシステムの利点を活用し、欠点を補完するための戦略です。

典型的なハイブリッド型アプローチは以下のようになります。

1. オフチェーンでの意思決定:

   • 日常的な議論や、Gasコストをかけたくない多数の小規模な提案、予備投票などはSnapshotなどのオフチェーンツールで行われます。
   • これにより、コミュニティの参加を促し、迅速な合意形成を図ります。

2. オンチェーンでの最終実行:

   • オフチェーンで可決された重要な提案（例：プロトコルアップグレード、大規模な資金移動）は、最終的にオンチェーンのスマートコントラクトを通じて実行されます。
   • この際、Gnosis Safeのようなマルチシグウォレットがよく利用されます。DAOの選出されたコントリビューターが、オフチェーンの投票結果に基づいてGnosis Safeのトランザクションに署名し、ブロックチェーン上で実行します。

このアプローチにより、投票コストを抑えつつ高い参加率を維持し、かつ重要な決定事項についてはブロックチェーンのセキュリティと信頼性を享受することが可能になります。

実装戦略と考慮事項

DAOのガバナンスシステムを設計・実装する際には、以下の技術的・運用的な考慮事項が重要です。

1. 投票メカニズムの選択:

   • DAOの目的と規模: 大規模で資金移動が頻繁に発生するDAOでは、Gasコストを抑えるオフチェーン投票が有効です。一方、コード変更がメインの技術系DAOでは、変更の確実性が求められるためオンチェーン投票が選択されることもあります。
   • 分散化の度合い: どの程度の分散化を追求するかによって、システム設計が変わります。完全なオンチェーンガバナンスは究極の分散化を提供しますが、柔軟性が失われます。
   • セキュリティとリスク許容度: 資金を扱う場合は、セキュリティ監査済みのスマートコントラクトの利用や、プロキシパターンによるアップグレード可能性の確保が不可欠です。

2. セキュリティ監査の重要性: スマートコントラクトに実装されるガバナンスロジックは、DAOの資金や機能の根幹をなすため、専門家による厳格なセキュリティ監査が必須です。不具合は甚大な被害をもたらす可能性があります。

3. アップグレード可能性とモジュール性: DAOの機能は進化し続けるため、スマートコントラクトをアップグレード可能な設計にすることが推奨されます。OpenZeppelin Upgradesなどのライブラリを利用したプロキシパターンが一般的です。また、ガバナンスロジックをモジュール化することで、将来的な変更や拡張が容易になります。

4. オラクルと外部データ連携: DAOがリアルワールドのデータやオフチェーンのイベントに基づいて意思決定を行う場合、Chainlinkなどの分散型オラクルサービスとの連携が技術的に不可欠です。

5. 参加障壁の低減: Gasコストの削減（オフチェーン投票）、分かりやすいUI/UX、投票委任（Delegated Voting）メカニズムの導入は、コミュニティの投票参加を促す上で重要です。特に投票委任は、専門知識を持つコントリビューターに投票権を委ねることで、DAOの意思決定の効率性を高めます。

まとめ

DAOの投票システムは、その健全な運営と進化に不可欠な技術的基盤です。オンチェーン投票はブロックチェーンの不変性と実行の確実性を提供しますが、コストと速度の課題があります。一方、オフチェーン投票はGasレスで柔軟性に富みますが、オンチェーン実行への信頼モデルを考慮する必要があります。

多くのDAOでは、これら二つのアプローチの利点を組み合わせたハイブリッドモデルを採用し、効率性と分散化のバランスを図っています。DAO開発に携わるエンジニアとして、これらの技術的特性を深く理解し、プロジェクトの具体的な要件に合わせて最適な投票システムを設計・実装することが、成功への鍵となります。

DAOテクノロジーハブでは、今後も個別のDAOツールや実装パターンに関する詳細な記事を提供してまいりますので、ご期待ください。