Terra Classic：Prop 11516「Dappコントラクトのホワイトリスト化」に関する複数の問題点

この記事は、Terra Classicの著名なコミュニティメンバーであるStrathCole氏（@ColeStrathclyde）が2023年6月21日に公開した『#LUNC: The issue(s) with proposal 11516』の内容を日本語訳した記事となります。

Prop 11516の提案内容について

Prop 11516「Dapp コントラクトのホワイトリスト化」が ガバナンス 投票を通過してからしばらく経ちます。

この提案の目的は、税率を0.2％から0.5％に引き上げることに対する "補償" として「DAppコントラクトをホワイトリストに登録すること」でした。

このアイデアが何であるかは理解していますが、私の見解では「この提案とホワイトリストの両方に複数の問題がある」と感じています。

Prop 11516は、投票のためにStationに掲載されており、提案内容は こちら で読むことができます。

しかし、これにはあまり情報が含まれておらず、主に、以前公開されたAgoraでの議論に言及していました。Agoraの投稿自体にもホワイトリストに関する情報はほとんど含まれていません。

代わりにそのテキストには、このトピックに関する以前のAgoraの議論への言及がありました。

個人的には、この構造が非常に混乱すると感じています。4つの提案のセットだったことは理解していますが、掲載された各提案には個別の議論の投稿があるべきだと思います。

とはいえ、この点は私がこの提案に対して感じている問題ではありません。

Prop 11516の問題点

私が考えるProp 11516「Dapp コントラクトのホワイトリスト化」についての具体的な問題点は以下の通りです。

問題1：シグナリング提案時の記載内容

提案に添えられたAgoraのテキストには「Stationでシグナリング提案として掲載される」と書かれていました。

シグナリング提案自体は全く問題ありませんが「実際の投票時に含める内容」を明確に記載しておくべきでした。

しかし、この点には「提案書には "コントラクトのホワイトリスト化" とはっきり明記されているのでは」と反論することもできるでしょう。

問題2：不明確な情報

提案の意図（私の個人的な印象）は単に「DAppプロバイダーが0.5％の高い税率について不満を言わないようにすること」でした。

これは提案自体で間接的に示されており、議論の中でも言及されていました。

問題は「誰がホワイトリストに登録されるべきか」ということです。Stationでの提案では次のように述べられています。

Burn Taxの増加を補償するために、DappコントラクトをBurn Taxからホワイトリストに登録すべきです。

しかし、Agoraでは次のように述べられています。

Burn Taxの引き上げによって、DEXなどのDappsの取引量や使用量が減少する可能性があります。
これを補償するために、TerraswapやAstroportなどのDapp契約をBurn Taxesからホワイトリストに登録することを提案します。

これは、主に貢献度の高いDAppsに利益をもたらすことを意図しており、すべてのDAppsには該当しないということなのでしょうか？さらに議論の中で別の発言がなされていました。

これはDappsに影響はありません。
DappsはLUNA 2.0だけでなく、cosmwasm上で構築されるすべての Cosmos Dappsと完全な互換性を持つようにTaxが適用されないため、簡単に移植できるようになります。

これは以前の発言とは全く異なる意味を持っています。理由は後ほど説明します。

最初のAgoraのテキストでは、ホワイトリスト登録に関して再び異なる表現がされていました。

これは、コントラクトがホワイトリストに登録されるのではなく「メッセージタイプがホワイトリストに登録されること」を意味するのです。

これは、提案が述べていることとは異なります。最初のAgoraのコメントで以下のような発言がありました。

これも提案では述べられておらず、ガバナンスを通じて特定のコントラクトをホワイトリストに登録することについて考えさせるものです。

問題3：コミュニティの理解

ご覧のように、私はこの提案の意図、つまり「どのように実装されることになるのか」という点で100％の確信が持てないのです。そして、コミュニティも90％以上理解していないことを確信しています。

さらに、L1 Task forceが何を意図しているのかも全く不明です。それについては こちら で確認できます。

実装するための提案

私がなぜProp 11516「Dapp コントラクトのホワイトリスト化」が実装されることすらあり得ないと考えるのか、どのようにそれを実行できるかについてのさまざまな解釈を説明します。

Case1：コントラクトアドレスのホワイトリスト登録

この方法が選ばれた場合、それは「BINANCEのホワイトリスト登録」と似たような仕組みになります。（正確ではない）

コントラクトアドレスがチェーンにガバナンス、またはハードコーディングで追加されます。これらのアドレスから、またはこれらのアドレスへの各トランザクションがTaxから除外されます。

Case2：全コントラクトアドレスの入出金のホワイトリスト登録

これは「新旧問わず、すべてのコントラクトがTaxを支払わなくて済むようになること」を意味します。

これを悪用すると「AからBへの単純な送金でコントラクトを悪用してTaxを回避する」といったことが可能になってしまいます。

Case3：MsgExecuteContract（および同様のもの）のホワイトリスト登録

この方法が選ばれた場合、コントラクトアドレスは重要ではなくなります。

課税されないのは特定のメッセージタイプで「コントラクトの実行、および類似のもの」です。これは二重課税となる「ユーザーからコントラクトへ」「コントラクトからターゲットウォレットへ」をなくし、後者だけが引き続き課税されます。

ガバナンスによるホワイトリスト登録？

Case1が使用されたと仮定すると、ホワイトリスト登録はこれらのアドレスのすべてのトランザクション、入金および出金に適用されるのでしょうか？ ホワイトリスト登録はガバナンスによって行われるのでしょうか？

これは、新しいコントラクトごとにTaxから免除されるために完全なガバナンス投票を経なければならないことを意味します。

これは、Coin factories（通貨生成プラットフォーム）、DEX、NFT Marketsなどには利益をもたらさない可能性があります。なぜなら、毎回ガバナンスを経る労力は単純に意味がないからです。

また、Case2で述べたように、大きなプロジェクトがこれを悪用するのは "簡単" です。

より具体的な実装提案・投票を

それは、考え抜かれた提案を作成し、それをガバナンス投票に持ち込むすべての人々の努力を私は評価しています。

この提案も例外ではありません。

しかし、私の見解では、L1チームは「ホワイトリスト登録」に関する具体的なガバナンス提案が作成され、投票を通じて可決されるまで解決策を実装すべきではありません。

現在、この問題に取り組むには不確実性が多すぎると私は考えています。Prop 11516に対して「賛成」を投票したとき、コミュニティが望んでいた実装が何かを確信することはできません。

私自身、ホワイトリスト登録に賛成ではないことは周知の事実ですが、ガバナンスを無視し、それを実装しないべきだと言っているわけではありません。

私は「実装される前に、メリット、デメリットを含めた方法が明確にされ、具体的な実装が投票を通じて可決される必要がある」と言っているのです。

もしこの提案が今すぐ実装されるならば、開発者は "Case2" を採用する必要があると思います。なぜなら、ガバナンスを通過したものは非常にオープンで一般的な方法で表現されているからです。

また、このテキストがProp 11516の提案者であるdfunk氏への非難のように聞こえたらお詫びします。それは全く本意ではありません。

他の多くの人たちと同じように、彼は思考を巡らせ、選択肢や解決策を提示するために多くの努力を払っています。

読んでいただきありがとうございます。

LUNC（Terra Luna Classic）を購入できる取引所はこちら