Terra Classic：障壁を下げるためにBurn Taxの実装を見直す｜StrathCole

この記事は、Terra Classicの著名なコミュニティメンバーであるStrathCole氏（@ColeStrathclyde）が2023年10月27日に公開した提案『Rework Implementation of Burn Tax to lower Barriers』の内容を日本語訳した記事となります。

提案の要点

Burn Taxは必要不可欠ではあるがdApp開発者にとっては複雑になっている
Burn Taxを廃止するのではなく「ガス代に統合すること」を提案
Taxとガス代控除を組み合わせることによりコントラクト開発を簡素化できる

Contents

Burn Taxの背景
既存のBurn Taxにおける問題点
解決策の提案
メリット
潜在的な懸念
よくあるご質問
まとめ

Burn Taxの背景

Terra Classic（LUNC）は2022年後半からBurn Tax（現在0.5%）を採用しています。

このうち80%はBurnウォレットに、10%はバリデータ報酬に、残りの10%はコミュニティプールに使われます。

現時点でこのTaxはTerra Classicコミュニティにとって必要不可欠なものですが、dApp 開発者にとってはある種の複雑さをもたらします。

既存のBurn Taxにおける問題点

Terra ClassicにおけるBurn Taxのルーツは、USTCのみを対象としていた暴落前の「安定税」にあります。しかし、この既存の機能を使用することで以下のような複雑な問題が生じました。

契約では、ガス代は送金された資金から自動的に差し引かれますが、Taxは差し引かれないため、開発者は手動で計算して調整する必要がある。このため、Terra Classicのコードを他の Cosmos チェーンに適応させたり、その逆を行ったりする際に余分な作業が発生する
シミュレーション・エンドポイントはガスの推定値を提供するだけなので、クライアント、つまりdAppsは自分でTaxを計算しなければならない
これらのTerra Classic固有の調整により、監査済みのdAppの移行が面倒になり、再監査が発生する可能性がある

ガス代の値上げを支持する単純なTaxの撤廃は、dAppプロバイダーに不当に影響を与え、高額取引からの税収を大幅に減らすことになるため、理想的ではありません。

解決策の提案

Burn Taxを廃止するのではなく「ガス代に統合すること」を提案します。提案内容は以下の通りです。

ガス代に新しいガバナンスパラメーターを導入し、最初は現行料金に設定する
Burn Tax（安定税）パラメーターを別のTaxモジュールに移す
ポストハンドラーで、送られたコインを決定し、Taxを計算して特定のガス量に換算する
「消費としてのガス」と「Taxとしてのガス」の比率を計算する
この比率に基づいてTaxに起因する手数料部分を確認する
ガス代分を残してTaxに関連する過剰な料金を払い戻す
この比率を用いて現在の分配パラダイムを維持したまま、Burnや報酬などに資金を適切に分配する
コードを変更することなくコントラクトとdAppsをシームレスに運用できるように、その時点で未使用の安定税（Burn Taxではない）をゼロに設定する

メリット

このアプローチは、Taxとガス代控除を組み合わせることによりコントラクト開発を簡素化する
クライアントサイドのdAppsの場合、税金の計算は除外することができ、シミュレーションエンドポイントのガス代の見積もりだけに頼ることができる

潜在的な懸念

L1 チームの元メンバーとの議論では、このアイデアの実現可能性が示唆されていますが、実際の導入には予期せぬ課題が生じる可能性があります。

さらに、シミュレートされたガス代は実際の必要量を過小評価する傾向があるため、クライアントは「乗数」を使用することがよくあります。

この乗数は「Taxガス」にも影響し、上記の払い戻しプロセスが保証されます。特に取引を成功させるために必要なコイン残高については、より深い調査が必要となります。

また、現在のところ、すべてのクライアント（サードパーティウォレットなど）が正しくTaxを処理しているわけではありません（課税すべきでないのに委任に課税するなど）。

コミュニティメンバーであるdfunk氏によると「これにより現時点ではコミュニティプール資金調達の約40～50％（7日間に基づく指標値）がこの実装によって除去され、CP資金調達率が低下する可能性が高い」とのことです。

ただし、これらの手数料は現在チェーンに取られていますが、本来は取ってはいけないものであることを念頭に置く必要がある。

よくあるご質問

Q：この提案によってBurn Taxが変更されたり削除されたりするのか？
A：いいえ。税率も分配モデルも変わりません。

Q：この提案が導入された後、既存のコントラクトをやり直す必要がある？
A：はい。チェーン上の既存のコントラクトは、現在Taxを差し引いたコインを送っているため更新が必要です。そのため、Taxを差し引く新しい実装では、更新されるまで二重にTaxを支払うことになります。

Q：既存のクライアント（terra.js / feather.jsなど）もアップデートする必要がある？
A：コントラクトと同じです。

Q：問題を軽減できる？
A：はい。安定税を乱用する代わりに、Taxに関する新しいガバナンスパラメータ-を導入することができます。安定税（実際のBurn Taxではない）をゼロに設定することで、固定税額を持たないすべてのコントラクトの二重課税問題を軽減することができます。

Q：既存のコントラクトは機能しなくなる？
A：いいえ。既存のコントラクトは機能し続けます。

Q：投票が可決された場合、完了までの時間は？
A：これはまだ不明です。重要な作業であるため、自主的にでも取り組むには、まずコミュニティによる委任が必要です。コミュニティの承認を得る前に、すべての調査とコンセプトの実証を行うことは作業時間を無駄にするリスクがあります。

Q：誰がこれを実施するのか？
A：この作業はL1なので、L1の開発者が取り上げる必要があります。少なくとも1人のL1開発者からサポートのサインはありましたが、現時点では開発を引き受ける "固定チーム"はありません。

Q：ガス代は全体的に高くなるのか？
A：いいえ。コインを伴わない取引（コインを送らないコントラクトコールなど）のガス代は変わりません。課税対象となる取引だけでも税額相当のガスが発生することになります。

Q：すべての取引に課税されるのか？
A：いいえ。課税対象となる取引は現在と同じリストになります。つまり、報酬の委任や引き出しなどはこれまで通り非課税です。課税対象リストをより簡単に変更できるように、これらのメッセージタイプをパラメーターに追加するかどうかを検討する必要があります。

Q：これはホワイトリスト（BINANCEなど）に影響する？
A：いいえ。システムは既存のホワイトリスティング・ロジックをTax計算に再利用できます。

Q：なぜ安定税を使い続ける代わりに新しいTaxパラメータを導入するのか？
A：ほとんどのコントラクトやdAppsは、課税に必要なコインを計算するために、現在の税率をチェーンに問い合わせます。ガス代にTaxが含まれていると、二重払いになってしまいます（後に払い戻されます）。これは、新しい個別のパラメーターを使用し、安定税を暴落前の値であるゼロに設定することで回避できます。