LUNC（Terra Luna Classic）の緊急管理・復興について｜1.2% TAX Burnなどの改善提案

※この記事は『Terra Rebels』として知られるDiscordグループの下で自己組織化された複数のコミュニティメンバーによって執筆されたLUNC（Terra Luna Classic）の改善提案『Emergency Management and Recovery of Luna Classic（Luna Classicの緊急管理・復興について）』の内容を日本語訳したものとなります。

【原文著者】
Edward Kim, Tobias Andersen, Marventus, Justin Tabish, A.E., Pedro Borges, David Schmidt, Matthew Western

LUNC（Terra Luna Classic）の緊急管理に向けて講じた措置概要

2022年5月上旬、アルゴリズム型ステーブルコインがペッグを維持できなくなり、Terraのエコシステムが崩壊しました。TFL（Terraform Labs）はLUNAと UST を守るために緊急措置を取りましたが、その数日後にTFLはLuna 2.0のために突然放棄しました。Luna Classicのブロックチェーンはこの2カ月間、不具合のまま中途半端な状態となっていたのです。

Luna Classicのコミュニティは困難な状況に直面しながらも、ブロックチェーンを構築して復旧させるために自己組織化して団結しています。この改善提案は、私たちコミュニティがUST デペッグ 後の数週間におけるLuna Classicブロックチェーンの緊急管理に向けて講じた措置の概要を説明するものです。

影響を受けたステークホルダーの懸念を軽減し、外部パートナー・取引所・サードパーティ開発者の信頼を構築するために、オンチェーン（on-chain）で実施される内容を正確に概説しています。

Luna Classicのコミュニティ・バリデータ・開発者に対して「ガバナンス をどのように実現できるか」について具体的なステップの概要を説明します。我々は、自分達のコードをオープンに監査して改善するためのあらゆる意見を歓迎します。真のコミュニティ ブロックチェーン として共に前進していきましょう。

TFL（Terraform Labs）が発行するLUNAとUSTについて

Terraのフレームワークは「Terra LUNA」と「Terra UST」で構成されています。このペアはLUNAとUSTの間でスワップ＆ミント（鋳造）機能を用いてアルゴリズム型 ステーブルコイン である「UST」の価格を1ドルに固定します。

USTの価値が1ドル以下になると、UST保有者はUSTを燃やして1LUNAを ミント し、USTの流通量を減らして価格を上昇させることができます。USTの価値が1ドル以上になると、LUNA保有者は1 LUNAを燃やして1 USTをミントすることができ、わずかな利益を得て、USTの価格を1ドルに戻すことができます。

しかし、2022年5月10日にUSTは1ドルの大台を割り込み、24時間以内に40％の投げ売りを開始、UST価格は4日間で1ドルから13％にまで下落しました。

LUNA財団は価格安定性を守るために30億ドル以上のビットコインを投入、さらに設計通りUSTとLUNAを連動させるアルゴリズムがUSTの崩壊を避けるために数兆LUNAをミントしましたが、その枠組みが大量の売りを支えきれず、Terraのエコシステムは壊滅的なデススパイラルに見舞われることになりました。

USTデペッグ時の緊急措置

ステーブルコインが崩壊した時、TFLは3つの緊急措置を開始しました。1つ目はコミュニティプールのUSTをバーンすること、2つ目はイーサリアム上に存在するクロスチェーンの3億7,100万USTをバーンすること、3つ目はガバナンス攻撃から防衛するために2億4,000万LUNAをステークすることでした(*1)。

しかし、Dev氏がTwitterで「LUNAチェーンは危険であり、その瞬間に4Mで乗っ取られる可能性がある」と指摘しました(*2)。IBC チャンネル・デリゲーション・新しいバリデータの作成を無効にするパッチが考案されました。

セキュリティパッチを作成したTFLの開発者は「一度Terra Classicと呼ばれているものがローンチしたら、これは明らかに元に戻される」と述べています。LUNAとUSTのスワップ接続も無効化されました。

この主な理由の一つは、数値の精度、すなわちマーケットモジュールが供給する小数点以下の桁数を使い果たしていたためです。デペッグのポストモーテムはGitHubでご覧いただけます。

ガバナンスとリプレゼンテーション

TFLのセキュリティパッチはLUNAのハイパーインフレを止め、チェーンを攻撃から守るものであったものの、このパッチはプロトコルの変更であり、Terra Classicの文書と統治手続きによれば、提案とコミュニティの投票が必要です。

ですが、この提案は公表されず、投票も行われなかったため、このパッチはこれらの受け入れられたガバナンス手続きに反してインストールされました。とはいえ、開発者とバリデーターが誠実に行動し、緊急時に的確な決断をしたことを疑う理由はありません。

TFL（Terraform Lab）の受託責任

TFLからは、2ヶ月前のあの瞬間からLuna Classicブロックチェーンのサポートや継続について何の連絡も行われていません。TFLに何度も連絡を取ろうと試みましたが、苛立たしい沈黙が続いています。著者がTFLと連絡を取ろうとした試みは以下の通りです。

1. GitHubのプルリクエストでコンタクトをとること
2. Terra-Moneyのリポジトリ上で開発者に直接メールを送ること
3. Discordを通じたメッセージ
4. Telegramを通じたメッセージ
5. 相手のカレンダーへのスケジューリング依頼
6. LinkedInを通じたコネクションリクエスト
7. Terra-Moneyのウェブサイトの求人情報に応募
8. TFLメンバーを Terra Rebels のGitHub orgに招待し、3週間の共同オーナーシップを割り当て。コミュニケーションに失敗したためメンバーへ降格。

TFLの開発者の中には、実装や解決策についてコメントや貢献をしてくれた人が何人もいます。しかし、彼らは組織とは無関係に善意で行動しています。

Terra Rebelsは、今後もTFLとコミュニケーションをとる努力を続けていきます。私たちは、これは共生関係になりうると考えています。

TFLはコードベースを維持する開発者のコミュニティを持ち、TFLはTerraブロックチェーンの微妙な仕組みを含む、4年間に行われた40万件のコードコミットに対する洞察を提供することができます。

TFLと連絡が取れればシステムの改良は桁違いに早くなるはずです。しかし残念ながら公式発表がないため、私たちはTFLがすでにチェーンを放棄したという前提で動いています。

コミュニティブロックチェーン

PoS（Proof-of-Stake）を採用したブロックチェーンは「バリデータ・コミュニティ・開発者」の3主体による三位一体と考えることができます。Lunaブロックチェーンの創設者の一人であるDo Kwon氏は、LUNAが崩壊した際に開発者にLuna 2.0チェーンのサポートを約束するように求め、次のように語りました。

『行動喚起：我々はTerraの開発者に、早急にパブリックチャンネルでフォークのサポートを表明し、ビルドすることを約束するよう促します。』

このように開発者がterra Classicチェーンを放棄し、コミュニティとバリデータを置き去りにしたために三位一体が崩れました。また、トークンの価値が急落して新しいメンバーが数百万LUNAをわずか数ドルで入手できるようになったため、LUNC・UST保有者などのコミュニティも劇的に変化しました。

開発者がいなくなりコミュニティの人間構成が一新されたことによって、当初の三位一体のメンバーとして残っているのは今私たちが話しているようにバリデータだけとなりました。

バリデータは徐々にチェーンを離れており、130人中90人しかアクティブになっていません。デペッグ イベントから2ヶ月が経過した今でもバリデーションは壊れたままです。ステーキングがチェーン運営の絶対的な基本であるPoSブロックチェーン「Luna Classic」では、デリゲーションと ステーキング がまだ無効化されています。

しかし、Luna Classicのエコシステムが壊れたわけではありません。新しいコミュニティがLuna Classicの背後に結集しているのです。この改善提案の執筆者は『Terra Rebels』として知られるDiscordグループの下で自己組織化されたコミュニティのメンバーです。

私たちはTFLとは何の関係もありませんし、現時点ではいかなる中央組織や確立された団体の下でも働いていません。私たちコミュニティは、投票プロセスを通過したコミュニティの提案に基づき、公平に開発者の空白を埋めています。

次のセクションで『Terra Classic Decentralized Autonomous Organization（DAO）』で可決された提案と、それに関連する実装を説明します。採択された場合、コミュニティからの代表者と検証者の新しい波が「Luna Classic」に出資することになり、Luna Classicはコミュニティが所有し運営する真のブロックチェーンとなります。

提案4095：既存のアクティブバリデータセットのみにステーキング/デリゲーションを再有効化する

この提案は、6月21日に90.67%（149M）の賛成票、総投票数165.32 M / 321.22 Mで可決されました。本提案は以下の変更を行うことを目的としています。

1. Terra Classicのステーキング / デリゲーションを現在有効なバリデータに限定して60日間有効化する。新たしいバリデータを作成する機能はブロック高#8905758（2022年8月22日頃）までは無効のままとする。
2. 新しいバリデータの作成は、ブロック高#8905758（2022年8月22日頃）以降のみ可能

提案された解決策と実装

ステータス - 実装済み
プルリクエスト - https://github.com/terra-money/cosmos-sdk/pull/

const StakingPowerUpgradeHeight = 7603700
// StakingPowerRevertHeight re-enables the creation of validators after this
// block height. This has been computed as approximately August 22, 2022. 68 days from June 15
// With an average of 7 second blocks, there are approximately 8.571 blocks per minute (60/7)
// 8.571 * 60 min * 24 hrs * 68 days = 839,272 blocks
// current block height on June 15 is 8,066,486
// projected block on August 22 is 8,066,486 + 839,272 = 8,905,758
const StakingPowerRevertHeight = 8905758

// DelegatePowerRevertHeight re-enables the ability to delegate stake to existing validators
// This is an approximate block height of adoption. The exact block height can be agreed upon
// if governance 4095 passes and validators agree to adopt the code patch.
// projected block 5 days from now, June 20 is
// 8.571 * 60min * 24 hrs * 5 days = 61,711 blocks
// current block height on June 20 is 8,146,938
// projected block on June 25 is 8,146,938 + 61,711 = 8,208,649.
// This is approximate and will be adjusted if needed
const DelegatePowerRevertHeight = 8208649

「StakingPowerRevertHeight」と「DelegatePowerRevertHeight」という2つのブロックの高さが定義されている。これらはプレースホルダーの値であり、バリデータと相談しながら調整される。「DelegatePowerRevertHeight」が決まったら、「StakingPowerRevertHeight」を60日後に計算する予定である。

ctx := sdk.UnwrapSDKContext(goCtx)
currHeight := ctx.BlockHeight()
if currHeight > StakingPowerUpgradeHeight &&
currHeight < StakingPowerRevertHeight {
return nil, sdkerrors.Wrapf(types.ErrMsgNotSupported,
"message type %T is not supported at height %d", msg,
currHeight)
}

ハイライトされた変更は、指定されたRvertHeightに達したときに表示されます。CreateValidatorが再び機能するようになることを示しています。Delegationについても同様に、より早いブロックでリベートしています。

func (k msgServer) Delegate(goCtx context.Context, msg
*types.MsgDelegate) (*types.MsgDelegateResponse, error) {
ctx := sdk.UnwrapSDKContext(goCtx)
currHeight := ctx.BlockHeight()
if currHeight > StakingPowerUpgradeHeight &&
currHeight < DelegatePowerRevertHeight {
return nil, sdkerrors.Wrapf(types.ErrMsgNotSupported,
"message type %T is not supported at height %d", msg,
currHeight)
}

懸念事項と潜在的な落とし穴

【懸念事項：アップグレードによってチェーンが止まってしまう】

新しいコードを採用するためにチェーンを停止させる必要があるのではないかという懸念を耳にしたことがあります。このようなことはあってはなりません。RevertHeightは、RevertHeightが効力を発揮する前にコンセンサスの失敗から保護します。

したがって、バリデータは自由にコードをアップグレードできるはずです。バリデータの2 / 3がそのコードを採用する限りチェーンは停止しないはずです。

【懸念事項：ステーキングを再有効化するとBFT攻撃を受ける可能性がある】

この攻撃は、ステーキングパワーによる検証者の2 / 3が悪意のある行為者であるというもので、すべてのブロックチェーンに潜在する攻撃です。しかし「コミュニティが所有するLUNA」と「ステーキングされたLUNA」のバランスが悪いため、委任とステーキングが再有効化されるとこの攻撃の可能性はより高くなります。

私たちはこの攻撃を2つの方法で軽減します。まず、最初の60日間は既存のバリデーターにのみ委任を開放します。この期間の攻撃は、すでにチェーンを忠実に実行することを表明している既存のバリデータからしか発生し得ません。

我々は、そのような攻撃の可能性がゼロではないことを認めつつも、その可能性は極めて低いと考えています。さらに、ゲーム理論的な観点から、ステーキングは21日間ユーザーのコインを拘束することになります。この間の攻撃は市場価格にマイナスの影響を与えることになります。

チェーンへの攻撃は、悪意のある攻撃者にも金銭的損失をもたらすことになるため、攻撃の可能性が低くなると考えられます。もしも、裕福な個人やグループがチェーンを攻撃するために数億ドル分を購入してチェーンを攻撃した場合、LUNCとUSTの時価総額を考えるとその人々は「代金を支払った」ことになるので、それを受け取る権利があります。

しかし、このような状況では委任前のスナップショットにロールバックしてチェーンをフォークし、そのバージョンのチェーンを放棄することになり、攻撃者は破滅的な金銭的損失を被ることになるでしょう。

だからといって、セキュリティを重視して慎重に進めるべきでないということではありません。予防措置として、我々は超党派のステークを達成するためのコストを大幅に抑制することで、そのような攻撃の阻害を行います。

我々はバリデータにスクリプトを提供し、バリデータが委任を有効にした最初のブロックでそのバリデータに委任することを可能にします。バリデータは最初のブロックにステークを行うだけでなく、我々コミュニティも信頼できるバリデータにコインを均等に委譲することになります。

バリデータに対しては、バリデータノードのメンプールサイズを大きくし、最小ガス量を増やすことを提案します。さらに、この移行を支援するための追加的な提案を歓迎します。プロトタイプのスクリプトは以下の通りです。

#!/bin/bash
var=$(terrad query block)
final=$(echo $var | awk -F ’"height":"|","time"’ ’{print $2}’)
while (( $final < $5 ))
do
sleep 3
var=$(terrad query block)
final=$(echo $var | awk -F ’"height":"|","time"’ ’{print $2}’)
done
terrad tx staking delegate $1 $3 --from=$2 --chain-id=rebel-1
--gas=auto --gas-adjustment=1.4

このスクリプトは3秒ごとにブロックの高さをチェックし、目標とするブロックの高さに達すると、指定した量をバリデータ・アカウントに委譲するものです。

提案3568：全取引の1.2％をタックスバーン

この提案は、6月9日に83.32%（140M）の賛成票、総投票数168.13M/321.22Mで可決されました。本提案は以下の変更を行うことを目的としています。

• LUNCにTax Burnメカニズムを導入して総供給量を削減
• 各売買取引にTax + Burnのメカニズムを実装
• 1.2% Tax Burnのメカニズムは総供給量が100億LUNCになるまで有効
• それ以降このメカニズムは無効となり、総供給量は決して変更不可

この仕組みは、すべての取引に導入され、条件が満たされるまで、すべての取引所が同じことを行うよう、Terraチームによってすべてのソーシャルメディアに公式に提案されなければなりません。もう一つは、Terraチームの公式バーンアドレスをソーシャルメディア上で共有することです。

この提案は、コミュニティの注目を集めるために行われたもので、提案2975はかなりの税金がかかるため、コミュニティは1.2％という数字を望んでいます。私たちは一緒にこれを行うことができます。

投票はすでにたくさん行われていますが、この提案はLUNCのために物事を加速させる助けになるもので、そして投資家・開発者・検証者をこのプロジェクトに呼び戻すことになるでしょう。

提案された解決策と実施方法

ステータス - 実装済み
コード - https://github.com/terra-rebels/classic-core/tree/burntax_via_stability

最初に紹介する変更は、AnteHandlerであるante.go.です。AnteHandlerはTendermintのデコレーターのセットで、CheckTxとDeliverTxの両方でトランザクション（取引履歴）をチェックします。これらのメソッドは、ブロックチェーンに提案されたすべてのトランザクションに対して実行されます。

cosmosante.NewValidateMemoDecorator(options.AccountKeeper),
cosmosante.NewConsumeGasForTxSizeDecorator(options.AccountKeeper),
cosmosante.NewDeductFeeDecorator(options.AccountKeeper,
options.BankKeeper, options.FeegrantKeeper),
NewBurnTaxFeeDecorator (options.TreasuryKeeper,
options.BankKeeper), // burn tax proceeds
cosmosante.NewSetPubKeyDecorator(options.AccountKeeper), //
SetPubKeyDecorator must be called before all signature
verification decorators
cosmosante.NewValidateSigCountDecorator(options.AccountKeeper),
cosmosante.NewSigGasConsumeDecorator(options.AccountKeeper,
sigGasConsumer),

ここでは、NewBurnTaxFeeDecoratorと呼ばれる新しいデコレータを採用し、定義しています。これは、TFLがUSTの安定税を実装するために導入した NewTaxFeeDecorator とほぼ同じものです。異なるのは送り手からTAXを引いた直後、つまりcosmosante.NewDeductFeeDecoratorの直後にTAX BurnするためにBankKeeperモジュールを渡している点です。ここでは、新しいデコレータの実装である burntax.go ファイルを示します。このファイルもtax.go (TFL stability tax decorator)と同じであることを簡単に確認することができます。

package ante
import (
"fmt"
sdk "github.com/cosmos/cosmos-sdk/types"
sdkerrors "github.com/cosmos/cosmos-sdk/types/errors"
"github.com/cosmos/cosmos-sdk/x/auth/types"
)
// BurnTaxFeeDecorator will immediately burn the collected Tax
type BurnTaxFeeDecorator struct {
treasuryKeeper TreasuryKeeper
bankKeeper BankKeeper
}
// NewBurnTaxFeeDecorator returns new tax fee decorator instance

func NewBurnTaxFeeDecorator(treasuryKeeper TreasuryKeeper,
bankKeeper BankKeeper) BurnTaxFeeDecorator {
return BurnTaxFeeDecorator{
treasuryKeeper: treasuryKeeper,
bankKeeper: bankKeeper,
}
}

前述したように、唯一の違いは、対象となるすべての取引についてTAX Burn処理を行うために、Bankモジュールを持ち込むことです。

AnteHandlerは安定税と全く同じ方法でTAXを計算します。しかし、ここでは安定税のように税収を記録するだけでなく、GasとTAXを徴収したFeeCollectorモジュールから、総供給量を減らす処理をするBurnModuleにコインを送ります。

// AnteHandle handles msg tax fee checking
func (btfd BurnTaxFeeDecorator) AnteHandle(ctx sdk.Context, tx
sdk.Tx, simulate bool, next sdk.AnteHandler) (newCtx
sdk.Context, err error) {
feeTx, ok := tx.(sdk.FeeTx)
if !ok {
return ctx, sdkerrors.Wrap(sdkerrors.ErrTxDecode, "Tx must
be a FeeTx")
}
msgs := feeTx.GetMsgs()
//At this point we have already run the DeductFees AnteHandler
and taken the fees from the sending account
//Now we remove the taxes from the gas reward and immediately
burn it
if !simulate {
// Compute taxes again. Slightly redundant
taxes := FilterMsgAndComputeTax(ctx,
btfd.treasuryKeeper, msgs...)
// Record tax proceeds
if !taxes.IsZero() {
btfd.bankKeeper.SendCoinsFromModuleToModule (ctx

types.FeeCollectorName, treasury.BurnModuleName ,
taxes )
if err != nil {
return ctx,
sdkerrors.Wrapf(sdkerrors.ErrInsufficientFunds,
err.Error())
}

FeeCollector から BurnModule に実際にトークンを送るには、SendCoinsFromModuleToModule エンドポイントを AnteHandler に公開する必要があるので、ハンドラに keeper.go ファイルからこの関数にアクセスするよう指示します。このコードによって AnteHandler がアクセスできるようになり、コインを直接燃やすことができるようになります。

// BankKeeper defines the contract needed for supply related APIs
(noalias)
type BankKeeper interface {
SendCoinsFromAccountToModule(ctx sdk.Context, senderAddr
sdk.AccAddress, recipientModule string, amt sdk.Coins) error
SendCoinsFromModuleToModule (ctx sdk.Context, senderModule
string, recipientModule string, amt sdk.Coins) error
}

ここで実際の税率は、既存のトレジャリーパラメータTaxRateを介して取得されます。この税率は、ここで定義されているように、税制とトレジャリーモジュールによって調整されます。tk.GetTaxRate メソッドは、このパラメータを照会します。

// computes the stability tax according to tax-rate and tax-cap
func computeTax(ctx sdk.Context, tk TreasuryKeeper, principal
sdk.Coins) sdk.Coins {
taxRate := tk.GetTaxRate(ctx)

最後に、既存の税金の AnteHandler と treasury モジュールの両方に、Luna に課税しないロジックがありました。Luna に課税するという制限を取り除き、バーンが適用されるようにしました。

for _, coin := range principal {
//Originally only a stability tax on UST. Changed to tax
Luna as well.
//if coin.Denom == core.MicroLunaDenom || coin.Denom ==

sdk.DefaultBondDenom {
if coin.Denom == sdk.DefaultBondDenom {
continue
}

treasury/keeper/keeper.go

// GetTaxCap gets the tax cap denominated in integer units of the
reference {denom}
func (k Keeper) GetTaxCap(ctx sdk.Context, denom string) sdk.Int {
// allow tax cap for uluna
//if denom == core.MicroLunaDenom {
// return sdk.ZeroInt()
//}

以下は、1.2%のTAXで課税されたトークンを有効にして適切にバーンするために、ガバナンスによって渡される必要がある正確なパラメーターの変更を示しています。

{
"title": "Param Change Policy",
"description": "Update tax policy",
"changes": [
{
"subspace": "treasury",
"key": "TaxPolicy",
"value": {"rate_min": "0.012", "rate_max": "0.012",
"cap":{"denom": "usdr", "amount": "10000000" },
"change_rate_max": "0.0"}
},
{
"subspace": "treasury",
"key": "RewardPolicy",
"value": {"rate_min": "1.0", "rate_max": "1.0",
"cap":{"denom": "unused", "amount": "0" },
"change_rate_max": "0.0"}
}
],
}

1.2%を達成するために、rate min と rate max パラメータを 0.012 に設定する必要があります。TAXはまさにこの数値に固定されることになります。usdr単位で許容されるTAXの合計には上限があります。

これは任意で高く設定することができます。変化率の最大値を0.0に設定すると、ブロックチェーンのエポック（約一週間）の間にTAXが変化するのを防ぐことができます。TAXが制定されるには、エポックを経過する必要があります。

報酬ポリシーのレートの最小値とレートの最大値は1.0に設定し、変化率の最大値は0.0に設定する必要があります。これには説明が必要です。エポックの終わりに、トレジャリーはそのエポックでバーンされたトークンの総数を計算します。

次にその正確な金額をすぐにミントし、これらを報酬としてバリデーターとコミュニティプールに分配し、古い署名モデルの一部として提供します。

報酬ポリシーは、これをどれだけ燃やし、どれだけ分配するかを指定します。1.0または100%は、新しく作成されたすべてのLunaがすぐに焼かれ、配布されないことを示します。

これらのパラメータの変更は、同じプロポーザルで同時に行う必要があります。 でなければTAXは報酬のために利用され、燃やされない可能性があります、

懸念事項と潜在的な落とし穴

【懸念事項：TAXは長期的な成長に悪影響を及ぼす】

このTAXがLuna Classicのエコシステムにとってプラスまたはマイナスの触媒となるかどうかはまだわかりません。私たちは公平を保ち、投票プロセスを通過したコミュニティの提案に従って開発します。

トランザクションに課税するとチェーン上のアクティビティが減少する可能性が高いことは認識していますが、Luna Classicランドスケープの進化に合わせて柔軟に実装できるように構成しました。

TAXはいつでもパラメーターの提案を介して変更でき、エポックごとに調整するために変動税率を利用することもできます。民主的なプロセスを通じて、Luna Classicコミュニティは健全な長期的成長を維持するために適応することができます。

【懸念事項: このTAXによって特定の DApps および取引所への接続が切断される】

これはおそらく事実です。Terra Station・Terra Faucet・TerraのChrome拡張機能などのツールで内部的に問題が発生することは既に確認されています。

これらのツールは、ガス料金を計算するために1Lunaのダミートランザクションを使用してブロックチェーンをプローブするように設計されています。取引量を増やすとガス料金が再計算されず取引が失敗します。

パラメータ提案のガバナンスがこれを可決することを示している場合、大規模な調整されたマーケティングおよび広報キャンペーンを実施する必要があります。Terra Classicチェーンとやり取りするためのロジックをアップグレードするには、開発者とサードパーティに連絡する必要があります。

しかし、明るい兆しが見えています。私たちのコード変更は、2022年2月まで実施されていたUST安定税に基づいています。ガバナンス提案172は、この税率を0に引き下げました。

これは、USTステーブルコインを利用していた開発者と取引所がすでにこのロジックを持っていることを意味します。Luna Classicで同じロジックを再度有効にするだけです。

議題4080：50%の取引手数料をコミュニティ・プールに分配

この提案は6月15日に、総投票数191.23M / 321.22Mで94.79% (181M) の賛成票を得て可決されたパラメータ提案です。提案の内容は以下の通りです。

取引手数料の50%をコミュニティプールに分配（35%は毎月のコミュニティプールでの提案で消費され、10%はエコシステム開発者にエアドロップされ、5%はコアTerra Classic開発に保持）、「基本提案者」と「ボーナス提案者」の報酬をそれぞれ0.01と0.04から0.03と0.12に引き上げ。

{
"subspace": "distribution",
"key": "communitytax",
"value": "0.500000000000000000"
}
{
"subspace": "distribution",
"key": "baseproposerreward",
"value": "0.030000000000000000"
}
{
"subspace": "distribution",
"key": "bonusproposerreward",
"value": "0.120000000000000000"
}

実施された解決策

ステータス - アクティブ
これはパラメータ変更の提案であったため、パラメータはガバナンスモジュールによって自動的に実装されました。

懸念事項と潜在的な落とし穴

【懸念事項：毎月バーン提案を開始するのは誰か？】

現時点では誰が毎月バーン提案を開始するのかが不明です。著者はこの提案の作成者と連絡を取り合っていますが、コミュニティ バーンの正式なスケジュールや責任については知りません。

【懸念事項：コミュニティ資金の乱用を防ぐものは何か？】

コミュニティプールの配布は配布ガバナンスの提案によって定義されます。コミュニティとバリデーターはこれらの資金の分配に投票する必要があります。

議題1299：IBCの再有効化

これはパラメータ提案で、総投票数158.15M / 321.22Mで95.14%（150M）の賛成票を得て可決されたものです。提案の内容は以下の通りです。

Terraバリデーターは、Osmosisおよびその他のIBC DEXのUSTおよびLUNAプールでの一時的な損失を防ぐための一時的な解決策としてIBCを無効にしました。 残念ながら、これによりUSTとLUNAがチェーン間で転送されなくなります。

現在約154.7MのUSTがOsmosisだけでスタックしています。この提案はチェーン間のUSTとLUNAの転送を再度有効にし、ロックを解除します。

Changes
{
"subspace": "transfer",
"key": "SendEnabled",
"value": "true"
}
{
"subspace": "transfer",
"key": "ReceiveEnabled",
"value": "true"
}

提案された解決策と実施方法

ステータス - 未実装
このパラメータの提案は可決されましたが、IBCはパラメータスペースではなくコードで無効にされました。IBCを再度有効にするための技術コードは簡単ですが、現時点では実装されていません。 懸念事項と潜在的な落とし穴を参照してください。

懸念事項と潜在的な落とし穴

USTデペッグの間、IBCの脆弱性に関する重大な懸念がありました。私たちは2人のCosmos開発者に連絡を取りました。1人は最初にチャンネルを閉鎖し、もう1 人はUSTがデペッグ時に早期に再開しないように警告しました。

OsmosisやJunoなどのチェーン間チームと話し、最初に関与したCosmos開発者に相談する予定です。IBCの再開が安全であることを確認するにはさらなる調査が必要です。

Rebel-1 TestNet

2022年6月24日、提案3568と4095のコード変更が提案された「Rebel-1」TestNetが稼働しました。TestNetは48時間の間に7人のコミュニティバリデーターによってサポートされ、時間とハードウェアを寄付しました。

1 週間後の時点でTestNetには11のバリデーターがあり、新しいメンバーが毎日オンボーディングされています。TestNet には、既存のTerra Stationデスクトップ アプリとChrome拡張機能からアクセスできます。資金の分配はFaucet NodeJSアプリケーションを通じて自動的に行われます。

コードの変更では、4095コードをテストして、ロジックが委任を無効にし、指定されたブロックの後に委任を有効にするかどうかを確認しました。これは成功しました。 私たちの3568テストには、オンチェーントランザクションで正しいTAXが計算されているかどうかが含まれていました。

また、TAX Burnを設計どおりに実行するために設定する必要があるガバナンスパラメータの提案もテストしました。 私たちのテストでは「コードが期待どおりに機能している」という結論に達しました。Columbus-5での統合テストが進行中です。

結論と今後のLUNC（Terra Luna Classic）の方向性

今後の方向性として、Luna ClassicとUSTの間のアルゴリズムによるステーブルコイン接続は、Terraエコシステムの重要かつ有用な差別化要因であると考えています。このトピックは、すぐに講じる必要がある緊急措置の範囲を超えているため、別の文書でより詳細に説明する予定です。

結論として、承認されたガバナンス提案をどのように実装できるかについての技術仕様を提示しました。コミュニティやバリデーターからの信頼を築くためにコードを公に監査し、完全な透明性を求めるさまざまな提案について懸念を表明します。

最後にコードベースの検証と実装についてより大きなコミュニティに支援を求めます。 私たちは、私たちが開発したものではなく、作成者によるガイダンスも与えられていないレガシーコードベースを採用しています。知識やリソースをお持ちの方は、Terra Classicエコシステムの再構築にご協力いただけるようご連絡ください。

金銭上の免責事項 - Luna Classicブロックチェーンの緊急管理における支援に対して金銭的な補償を受けている作成者はいません。 何人かの著者はLUNCとUSTの保有という形で個人的な金銭的利益を開示しています。

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