Arc での金融アプリケーションの開発：動作が異なる4つの点

Quicknode

2026年10月8日 — 読了時間6分

シェア

「お気に入り」として追加

Arc は、現実世界の価値を移動させるアプリケーション向けに設計されています。EVM実行環境を維持しているため、既存のSolidityコントラクトや使い慣れたEthereum ツールは引き続き利用可能であり、一方で手数料、決済、その他の金融上の要件はネットワーク自体に組み込まれています。

これらの選択により、契約に関連するシステムが変更されます。以下の4つの相違点のうち2つは、本日よりArc で公開されています。残りの2つはロードマップ上の項目であり、現時点での機能ではなく、今後の方向性として捉えてください。

1. ガス代としてのUSDC

ステーブルコインのアプリケーションでは、1つのアクションを実行するために、多くの場合2つの資産が必要となります。すなわち、移動されるステーブルコインと、実行費用を支払うための別のトークンです。これにより、資金を調達すべき残高が1つ増え、価格設定が必要な資産が1つ増え、さらに、ユーザー に資金はあるもののガスが不足している場合に、mode というエラーが発生する原因となります。

Arc これにより、by の分割が解消され、USDCがネイティブなガス資産となります。取引手数料とアプリケーションの価値は同じ会計単位で表されるため、ユーザー は別途ガストークンを取得することなく取引を行うことができます。また、財務・会計システムも、追加の価格換算手順を経ることなく、送金とその実行コストをドル建てで記録できます。Arcの手数料設計は、ネットワーク需要の変動を平準化し、コストの見積もりを容易にする一方で、標準的な手数料RPCメソッドにより、アプリケーションは実行時に現在の値を読み取ることができます。

統合に関するある詳細については、設計上の配慮が必要です。ネイティブUSDCは、ガス料やEVM値の転送において18桁の小数点以下を使用しますが、そのERC-20インターフェースでは、おなじみの6桁の小数点以下のUSDC表現が使用されます。これらは2つの資産ではなく、同じ残高を表す2つの視点に過ぎません。したがって、ウォレットや台帳は、両方を表示したり合計したりするのではなく、これらの視点を統一する必要があります。 インデクサーも同様の対応が必要です。なぜなら、ERC-20の取引では1回の動きに対してネイティブのシステムイベントとインターフェースイベントの両方が生成される可能性があるのに対し、ネイティブ送金ではシステムイベントのみが生成されるからです。 メインネット 当社のArc のUSDCインデックス作成ガイドにある例では、2つの実際のUSDC移動に対して、4つの転送形式のログが表示されています。重要なポイントは、Arc は個別のガス資産を排除するものであり、USDCの単一の正規ビューの必要性を排除するものではないということです。

2. 決定論的ファイナリティ

多くのネットワークでは、ブロック内にトランザクションが含まれているからといって、アプリケーションがそれを安全に「決済済み」として扱うことができるとは限りません。サービスは、より多くの確認を待ち、直近のアクティビティを暫定的なものとして扱い、チェーンが再編成された場合に備えてロールバックパスを保持します。

ArcMalachite BFTコンセンサスでは、その中間状態が排除されています。トランザクションは「未確認」か「確定」のいずれかであり、コミットされたブロックは再編成されることはありません。アプリケーションは、確認深度を信頼度スコアに変換するのではなく、ブロックがコミットされた時点で処理を実行することができます。

これにより、オンチェーン の結果を受けて別の場所で開始されるワークフロー（元帳の更新、在庫の放出、他のサービスへの通知、次のトランザクションの開始など）が簡素化されます。確認のしきい値や再編成のロールバックロジックは、アプリケーションの状態マシンを離れる可能性があります。Arc では、1秒未満での不可逆的な決済が、測定された本番環境のサービスレベル契約ではなく、ネットワーク設計上の特性として記載されているため、チーム は、ユーザー が経験する完全なパスを引き続き測定する必要があります。

ファイナリティは、運用上の信頼性 に取って代わるものではありません。接続が切断されたり、コンシューマーが再起動したり、配信が再試行されたり、データベースがタイムアウトしたりすることがあります。耐久性のある取り込み、冪等な書き込み、リプレイセーフな効果、および調整は、依然として不可欠です。Arc は、チェーンの回答をファイナルなものにします。アプリケーションは、その回答を確実に処理する必要があります。

3. 独立した実行モデルとしてのプライバシー

金融アプリケーションでは、取引を独立したシステムに移行することなく、機密性を確保する必要がある場合がよくあります。取引条件、残高、ポジション、あるいは取引相手先については、開示を管理する必要がある一方で、その結果生じる価値の変動については、公開されているオンチェーン の取引履歴と整合性が保たれている必要があります。

Arc Privacy Sector(APS) は、Arc が計画している対応策です。これはロードマップに盛り込まれていますが、まだ利用可能ではないため、現在の製品に関する約束というよりは、将来のアーキテクチャの方向性を示すものと捉えるべきです。

APSは、パブリックEVMと並行してSolidityコントラクトを実行するための機密性の高い実行環境として設計されています。パブリック状態とプライベート状態は同一のブロックにコミットされるため、両環境のコントラクトがアトミックに相互作用することが可能になります。これにより、別途のブリッジや遅延メッセージング層に依存することなく、機密性の高い状態を非公開に保ちつつ、関連するパブリックな効果を処理するワークフローを実現できます。

プライバシーの境界は明示的になります。関数、ストレージ、イベントはデフォルトで非公開by に設定され、アプリケーション側が、何を公開し、どのコントラクトと相互作用させるかを決定します。これにより、機密性は、公開データがすでに生成された後にそれを隠そうとするレイヤーではなく、実行設計の一部となります。APSは現時点では利用できませんが、その意図される利点は明らかです。それは、Solidityやアトミックな構成を犠牲にすることなくプライバシーを確保できるという点です。

4. ポスト量子ウォレットの署名

現在、ウォレットを保護している署名方式は、十分な能力を備えた量子コンピュータに対しては、今後も安全性を維持できない可能性がある。長期的に価値を維持するアプリケーションの場合、その可能性に備えることは、土壇場でのソフトウェア更新ではなく、移行の問題となる。

Arcのポスト量子ロードマップは、SLH-DSA-SHA2-128sウォレット署名向けのベータ版・オプトイン方式のサポート から始まります。 メインネット。オプトインしたウォレットは、この新しい方式を使用してトランザクションを承認できます。この保護はウォレットに適用されますが、バリデーターの署名には及ばず、またArc のコンセンサスをポスト量子化にするものではありません。

サポート プロトコルは、あくまで第一歩に過ぎません。ハードウェアウォレット、署名サービス、SDK、カストディポリシー、復旧システム、取引ツールなどはすべて、この仕組みを正しく処理する必要があります。規格は依然として進化し続けているため、Arc は、即時の切り替えではなく、段階的な移行を通じて普及が進むと見込んでいます。

このロードマップでは、保護機能を段階的に拡充していきます。ウォレット関連の作業に続いて、プライベート実行のためのポスト量子暗号化やオフチェーンインフラのアップグレードが行われますが、バリデーターの署名については引き続き長期的な課題となります。したがって、このベータ版の実用的な価値は明確です。すなわち、参加するウォレットに対し、ネットワークの他の部分で利用可能な保護機能を過大評価することなく、ポスト量子認証スキームを早期にテストし、導入する道筋を提供するものです。

ネットワーク設計からアプリケーションの挙動まで

これらの違いには、共通の目的があります。『Arc 』は、定期的な財務要件をネットワークにより近づけることを目指しています。具体的には、価値と手数料の安定した単位、明確な決済境界、機密性の高い実行への道筋、そしてウォレット認証を進化させる方法などです。EVM互換性により、開発者 は、すでに慣れ親しんだスマートコントラクトやツールを放棄することなく、その基盤を活用することができます。

アプリケーションには、依然として正確な会計処理、信頼性の高いデータパイプライン、綿密なアクセス制御、そして安全なウォレットインフラストラクチャが必要です。Arc は、こうしたシステムの基盤そのものを変革し、これまで慣れ親しんできた複雑な問題を解消する一方で、正確に理解しておく必要がある新たな制約をもたらします。

Quicknode 対応 Arc JSON-RPCおよびWSSエンドポイントを通じて、デバッグおよびトレースネームスペースを備えたアーカイブへの完全なアクセス、WebSocketサブスクリプション、 Webhooks、および Streams。今すぐArc で開発を始めましょう Quicknode 今すぐxml-ph-0000@deepl.internalで開発を始めましょう。