Solanaは、エポック1035の開始時点にあたる9月15日約01:00 UTCに、メインネットでtxv1機能を有効化した。今回のアップグレードにより、最大トランザクションサイズは1,232バイトから4,096バイトへ拡大し、従来の3倍超となった。

追加された容量は、V1トランザクション形式を通じて利用できる。アプリケーションは利用前に明示的に対応を追加する必要がある一方、レガシートランザクションとV0トランザクションは従来の上限のまま完全にサポートされる。

大きなトランザクションは、より大きなSOL送金を意味しない

新たな上限が対象とするのは、トランザクションが運ぶ情報量であり、ユーザーが送金できるSOLの額ではない。通常の送金に必要なデータは、アカウント、命令、署名の数が少ないため、比較的限られている。

より高度な処理では、複数の命令、多数のアカウントアドレス、複数の承認、暗号学的証明などが必要になる場合がある。こうした情報量が従来の上限を超えた場合、開発者はペイロードを削減したり、処理を複数のトランザクションに分割したり、アドレスルックアップテーブルやトランザクションバンドルなどの代替手段を利用したりする必要があった。

Solanaは、Solanaの仕組みを解説したこのガイドで説明されているように、関係のないトランザクションを並行して処理できる。V1はこの実行モデルを変更しない。単一の処理に複数の関連する構成要素を含める必要がある場合に、より多くの余地を提供する。

これらの命令を1つのアトミックトランザクションとして送信すると、1つの単位として処理される。処理全体が成功するか、変更が取り消されるため、一部の命令だけが台帳に記録される状況を避けられる。

追加容量の恩恵を受ける可能性がある処理

• バッチ取引： 取引アプリケーションは、複数の確認を調整する代わりに、関連する命令を1つのトランザクションに組み込める。
• 大規模なマルチシグ承認： 複数人による処理の承認が必要な場合、財務管理用ウォレットや企業ウォレットは、より多くの署名とアカウント情報を収容できる。
• ゼロ知識証明： アプリケーションは基礎となる情報をすべて明らかにせずに条件が満たされていることを証明できるが、証明そのものに相当なトランザクション容量が必要になる可能性がある。
• オンチェーン署名方式： 一部の暗号署名形式では、従来、1つのSolanaトランザクションに収まらない量のデータが生成されていた。

Solana Foundationは、機密送金、ネストされたマルチシグ、バッチ処理、一部のオンチェーン署名方式を新形式の利用例として挙げている。

ほとんどのウォレット利用者は対応不要

今回の有効化に伴い、ユーザーがSOLを移動したり、新たなアドレスを作成したり、既存のアカウントを変換したりする必要はない。レガシー形式またはV0形式を使い続けるアプリケーションは、アップグレード前と同様に動作するはずだ。

アプリケーションがV1トランザクションの送信を選択した場合、ユーザーには対応するウォレットが必要になる。プロバイダーが対応を導入するのに合わせ、ウォレットソフトウェアを最新の状態に保つことで利用可能になるが、アプリケーション側はウォレットに署名を求める前に互換性を確認する必要がある。

ユーザーにとっては、複雑な処理で承認要求が少なくなる形で、今回の変更がいずれ現れる可能性がある。従来、複数の関連トランザクションを必要としていたサービスが、1回の要求を表示し、1回の確認を待つだけで済むようになる可能性がある。

開発者とインデクサーはソフトウェアを更新する必要がある

V1トランザクションの送信は任意だが、更新されていないインフラでは、V1トランザクションの読み取りが互換性の問題を引き起こす可能性がある。

トランザクションやブロックを取得するRPCサービスは、maxSupportedTransactionVersion: 1を設定する必要がある。この設定がない場合、V1トランザクションの要求がエラーになる可能性がある。また、対応していないトランザクションが1つ含まれているだけで、ブロック全体の要求が失敗する可能性もある。

インデクサーには別のリスクがある。V1では、コンピュート上限、ロード済みアカウントデータ上限、優先手数料がCompute Budget命令ではなく、transactionConfig内に保存される。従来の場所をスキャンし続けるソフトウェアは、トランザクションを誤って分類したり、リソース上限や優先手数料をゼロと報告したりする可能性がある。

V1トランザクションを作成するアプリケーションは、コンピュートユニット上限とロード済みアカウントデータ上限を明示的に設定しなければならない。新形式では、両方の値がデフォルトでゼロになるため、設定を省略すると実行前にトランザクションが失敗する可能性がある。

1,232バイトを超えるトランザクションは、base64エンコーディングを使用して送信する必要もある。base58による送信経路では、従来のサイズ上限が維持される。

V1は容量を増やす一方、別の上限も設ける

V1は、単にペイロードを大きくしたV0ではない。トランザクションに最大64個のアカウントアドレスを直接含められるが、アドレスルックアップテーブルには対応していない。重複するアカウントアドレスも拒否される。

これらのルールにより、アプリケーションチームには異なる設計上の選択肢が生じる。ルックアップテーブルがアカウント参照の効率的な方法となる場合、V0は引き続き有用だ。一方、V1は命令、署名、証明のためにより多くの容量を必要とする処理を想定している。

単純な支払いが新形式から恩恵を受ける可能性は低い。V1は、複雑な処理手順を置き換えられるアプリケーションや、従来は1つのトランザクションに収まらなかったデータを収容できるアプリケーションに適している。

大きなトランザクションには高い手数料がかかる可能性

バイト上限を引き上げても、すべてのV1トランザクションが自動的に高くなるわけではない。コストは、要求するリソース、署名数、アプリケーションが選択する優先手数料によって決まる。

大きなメッセージは、バリデーターの帯域幅をより多く消費する。Solanaのドキュメントによると、同等の優先度を求める小さなトランザクションと比べ、大きなトランザクションにはスケジューラーがより高い優先手数料を要求すると見込まれている。特に、ブロックスペースの需要が高い場合にその傾向が強まる。

V1では、優先手数料をlamports単位の合計額として表す。V0ではコンピュートユニットあたりの価格を使用するため、分析プラットフォームは比較前に2つの形式を正規化する必要がある。

ネットワーク活動によって優先手数料の需要は大きく変化する可能性があり、Solanaの最近の手数料データにもそのことが示されている。そのため開発者は、1つの大きな処理にまとめる利便性と、混雑時に取り込んでもらうためのコストを比較する必要がある。

有効化が普及の試金石に

今回のアップグレードにより、従来Solanaアプリケーションの設計を制約していた要因は取り除かれた。しかし、メインネットでの有効化は広範な利用を保証するものではない。開発者が顧客向け製品で新形式を信頼して利用するには、ウォレット、RPCプロバイダー、インデクサー、アプリケーションライブラリが新形式を正しく処理しなければならない。

初期の恩恵は、機密送金、機関投資家向けのマルチシグ構成、命令数の多いアプリケーションなど、すでに従来の上限に苦労している処理に現れる可能性がある。通常の送金では、既存の形式が引き続きより簡単な選択肢となる。

V1の重要性は、これらの処理を1つのアトミックトランザクションに収めることで、調整、署名、失敗試行にかかるコストを、必要なインフラ更新を正当化できるほど削減できるかどうかに左右される。

この記事は情報提供のみを目的としており、金融または投資に関する助言を構成するものではない。ウォレットの互換性、アプリケーションの対応状況、トランザクション手数料は変更される可能性がある。

出典：Coindoo