テクノロジーインサイト一覧へ戻る
2026.09.16

Circle の Arc がパブリックメインネットを公開:USDC をガスにした許可型 L1 が EVM 互換の前提を崩す箇所(18桁と6桁の二重表現、WETH の不在)

Circle の Arc がパブリックメインネットを公開:USDC をガスにした許可型 L1 が EVM 互換の前提を崩す箇所(18桁と6桁の二重表現、WETH の不在)

何が起きたか

Circle は9月16日、Arc のパブリックメインネットを公開した。それまでは100超の機関・エコシステム事業者が参加するプライベートメインネットとして運用されていた。Arc は EVM 互換の L1 で、実行層に Ethereum クライアントの Reth、合意層に Malachite を使う。Malachite は Informal Systems が開発した Tendermint 系の BFT エンジンで、現在は Circle が保守している。Circle の説明では、トランザクションは「未確定」か「完全に確定」のどちらかで、バリデータの3分の2超がコミットした時点で確定し、再編成(リオルグ)は起きない。ブロック間隔は約0.5秒である。

バリデータは許可型(PoA)で、Circle が選定する。創設バリデータは Circle のほか、BlackRock、DTCC、Galaxy、Global Payments、ICE、Mastercard、MoneyGram、SBI、Standard Chartered、住友商事、Visa の11機関である。コントラクトの配備と取引は誰でも行えるが、ブロック生成は選ばれた機関に限られる。プルーフ・オブ・ステークへの移行やプライバシー機能は後続のアップグレードとして予定されている。Circle は公開日に「ARC」トークンを100億枚発行したが、これは技術的なマイルストーンであり、一般公開を約束するものではないとしている。ガスは引き続き USDC で支払う。

解こうとしている問題:手数料の価格変動と決済の確定

Arc の設計判断は二つの問題に向けられている。一つは手数料の価格変動である。ガスを変動資産で払うチェーンでは、利用者は事前にその資産を調達しなければならず、事業者は手数料をドル建てで見積もれない。Arc はガスを USDC 建てにし、基本手数料に下限を設けた。Arc のドキュメントによれば、下限は20 gwei である。9月20日にノードを直接照会した開発者の報告でも、観測したブロックの基本手数料はすべて20 gwei だった。単純送金(21,000ガス)のコストは約0.00042 USDC になる。

もう一つは確定の曖昧さである。確率的ファイナリティのチェーンでは「何承認待てばよいか」が利用者側の判断に委ねられるが、支払い、為替、証券決済にはそれが許されない。BFT 系合意と限定されたバリデータ集合によって、確定を二値にしている。

トレードオフ:互換性の「ずれ」と、誰が止められるか

代償は二つある。第一は EVM 互換性の細部のずれである。ネイティブ資産は USDC だが、EVM の慣行に合わせて18桁で数えられる。eth_getBalance、msg.value、ガス計算はすべて18桁である。同じ残高を ERC-20 として扱うコントラクト(0x3600000000000000000000000000000000000000)は、他チェーンの USDC と同じく6桁である。両者は別の資産ではなく同一残高の二つの見え方で、変換係数は10の12乗になる。Arc のドキュメントは、ERC-20 側は6桁未満を切り捨てるため、balanceOf が0でもネイティブ残高が0とは限らないと注意している。

さらに Arc にはネイティブ資産を包む WETH が存在しない。ネイティブ資産がすでに ERC-20 の顔を持つためである。Uniswap のデプロイ表では、チェーン5042の WETH9 アドレスは「Unsupported Protocol」とされ、呼び出すと必ず失敗する最小限のコントラクトが置かれている。ラップを経由するルーターの経路は、ここで意図的に止まる設計である。

第二は検閲耐性と中立性である。バリデータは Circle が選び、Arc のセキュリティページは「バリデータ層での制裁対応」を運用モデルの一部と明記している。Arc のドキュメントは、十分な残高があってもブロックリストなどの規則によってネイティブ送金が失敗しうると記している。これは規制対応を必要とする機関にとっては要件であり、パーミッションレスなチェーンを前提とする設計にとっては別の前提条件になる。どちらが良いかではなく、接続する側が自社の要件と照らして選ぶべき設計上のトレードオフである。

手数料の仕組みにも独自の点がある。Arc の手数料モデルは EIP-1559 に移動平均と下限を組み合わせたもので、通常の負荷では基本手数料が下限に張り付いて動かない。前述の実測報告によれば、ブロックヘッダーの extraData には次のブロックの基本手数料が入っていた。手数料を事前に確定させる設計であり、ドル建てで固定された見積もりを前提にできる。ただしこれは Ethereum の手数料市場とは挙動が異なる。混雑時の優先度付けを priority fee に頼るロジックは、そのままでは同じ効果を持たない可能性がある。加えて Arc は EIP-4844 のタイプ3(blob)トランザクションに対応しておらず、ウォレットは任意の EVM トランザクション型を受け付ける場合、これを拒否する必要がある。

想定される落とし穴

最も起きやすいのは、桁の取り違えによる「黙った誤り」である。ERC-20 の金額(6桁)をそのまま msg.value に渡すと10の12乗分の1しか送られず、逆にネイティブ額を transfer に渡すと桁外れの額を送ろうとする。どちらもエラーではなく、金額違いとして現れる。circlefin/arc-node の Issue では、ウォレットで残高が10の12乗倍や10の12乗分の1で表示される事例が報告されている。

次に、インデクサの二重計上である。Arc の互換性ガイドによれば、ERC-20 の transfer() を1回呼ぶと、18桁のシステムイベントと6桁の ERC-20 Transfer イベントの両方が発行される。ネイティブ送金ではシステムイベントだけが出る。ネイティブ送金とログの両方を拾う設計では、同じ移動を二度数える。残高表示でも、eth_getBalance と balanceOf を合算すると同じ残高を二重に数えることになる。

三つ目はアドレス表の流用である。他チェーンの「正規アドレス」を前提にしたツールは Arc では通用しない。開発者の実測報告によれば、Uniswap v3 の他チェーンでの正規アドレスには、Arc 上では Uniswap v3 ではない別のコントラクトが置かれていた。コード長の確認と実呼び出しなしに、アドレスを信頼してはならない。

四つ目は、ティッカーによる資産の識別である。Arc 上の USDC は 0x3600…0000 の一つのアドレスだけだが、コントラクトの名前やシンボルは誰でも自由に付けられる。同じ実測報告は、公開から数日のうちに「USDC」を名乗る別のトークンと本物の USDC のペアが、ローンチパッド系の取引所で高い取引量を記録していたことを確認している。資産の許可リストは、ティッカーではなくアドレスで管理する必要がある。

【技術インサイトとアクション】

  1. 「EVM 互換」は命令セットとツールチェーンの互換を意味し、金額の単位やネイティブ資産の意味の互換までは保証しない。ネイティブ資産をステーブルコインにしたチェーンでは、桁の境界がすべての送金経路に現れる。 [インテグレーター・コントラクト開発者] Arc への統合前に、ネイティブ(18桁)と ERC-20(6桁)の変換を一か所の関数に集約し、msg.value と transfer の双方で桁を検証する単体テストを必須にする。
  2. 一つの資産が複数のインターフェースとイベントを持つと、残高と履歴の集計が二重になる。表示や会計は、どちらか一方を正とする明示的なルールがなければ破綻する。 [インテグレーター・データ基盤担当] インデクサと残高表示を実装する段階で、ネイティブ残高を正とし、ERC-20 のイベントとネイティブのシステムイベントの重複を除く規則を定義し、テストネットで同一送金の二重計上がないことを確認する。
  3. 許可型のバリデータ集合と制裁対応は、決済の確定性と引き換えに、送金が「残高があっても失敗しうる」チェーンを生む。これは設計上の前提であり、障害ではない。 [プロダクト側] Arc を決済経路に採用するかどうかの判断の段階で、送金失敗(ブロックリスト等による revert)時の業務フローと、パーミッションレスな経路との使い分けを要件として明文化する。

【引用:出典】

本記事は公開情報に基づく技術解説であり、投資助言を目的としたものではありません。