Introduction

この文書の目的はFutabaのユースケースとしてCross-chain governanceの提案を行い、その可能性について議論するためのものです。

Futabaはcross-chainのデータ取得に特化したcross-chain infraであり、smart contract上で他のチェーンのstateを簡単に扱えるようにします。詳細についてはこちらを参照してください。

最近では多くのプロトコルがMultichain化し、それに伴ってガバナンストークンも複数のチェーンでmintされています。しかし、投票を実際に行なっているのは単一のチェーンである場合が多いのに加えて、基本的にEthereumで投票するケースが多く、投票力の小さい投票者にとってはガス代がボトルネックになります。そのため、(1) ガス代が低いチェーン・ロールアップでの投票と、(2) MultichainのDappsに対応した投票システムが必要になります。

そこで、まずCross-chain governanceの現状と課題について確認し、解決策としてFutabaを利用したCross-chain governanceの紹介をします。

Assumptions

Multichain Dapps and Governance token

当然ですが、このCross-chain governanceは複数のチェーンに跨ってDappsを構築しているプロトコルを対象にしています。

それに加えて、Governance tokenが複数のチェーンに展開されているプロトコルに限定します。Governance tokenが単一のチェーンにのみ展開されている場合は必然的に投票を行うチェーンも単一となり、Proposalの反映のみCross-chainが必要になると考えられます。

<aside> ⚠️ 単一のチェーンにおいて、投票コストを下げるためにガス代が安いチェーンで投票をしたい場合にはFutabaを活用することが可能です。

ex. DappsやGovernance tokenをEthereum上で展開して、ガス代軽減のためにArbiturmで投票を実行する場合 ArbiturmでFutabaのquery()を利用してEthereumにあるGovernance tokenの量を参照し、それをもとにArbiturmで投票を実行します。

ただし、今回はより複数のネットワークを意識したものを提案するため、Governance tokenが複数のチェーンに展開されているプロトコルに限定します。

</aside>

On-chain voting

ここではSnapshotのようなオフチェーンでの投票ではなく、オンチェーンでの投票にフォーカスしています。

オンチェーンでの投票は投票結果に沿ったスマートコントラクトの自動執行の強制力があることに非常に価値があります。そのため、オンチェーンの投票はProgramableで、強い強制力が要求される提案に有効であり、一方で提案の実行にスマートコントラクトが必要でなく、重要度が低いような提案に関しては既存のオフチェーンの投票で充足していると考えています。

Messaging Protocol

後述するが、提案の実行に関してはMessaging protocolを使用します。Messaging Protocolとは任意のバイトデータを他のチェーンに送信し、destination chainで任意のコントラクトを実行できるProtocolであり、LayerZeroなどが代表的な例として挙げられます。

ここでは特定のMessaging Protocolについて言及はせず、単に提案の実行のために必要な任意のMessaging Protocolとします。