「blockchain」タグの記事が8件件あります

The concert ticket in your digital wallet is on the verge of a massive upgrade. For decades, a ticket has been a static, disposable proof of purchase—a barcode to get you in the door, and nothing more. That model is evolving. The ticket is becoming a programmable, portable membership object, capable of unlocking experiences long after the show ends.

Done right, NFT tickets can drastically reduce fraud and scalping, create fairer access for superfans, and give organizers powerful new ways to reward loyalty—all without forcing fans to understand cryptocurrency. This isn't a theoretical future; real deployments are already live across major concerts, professional sports, aviation, and even Formula 1. The next wave of adoption hinges on seamless user experience, thoughtful policy design, and pragmatic technology choices.

The Old Ticket Stack Is Fraying​

The traditional digital ticketing system is brittle and showing its age. Fans and organizers alike feel the pain points:

• Fraud & Bots: Predatory bots snatch up inventory the moment it goes on sale, only to list it on secondary markets at hugely inflated prices, shutting out real fans. Fake or duplicate tickets plague these markets, leaving buyers with empty hands and lighter wallets.
• Fragmented Systems: A fan’s history is scattered across dozens of vendor accounts. This makes simple actions like transferring a ticket to a friend a painful process and leaves organizers with no unified view of their most loyal attendees.
• Disposable Artifacts: Once scanned, a QR code or PDF ticket becomes useless digital trash. It holds no ongoing value, tells no story, and offers no future utility.

Meanwhile, the market remains dominated by a primary seller facing ongoing antitrust scrutiny. State-by-state reform efforts are gaining steam, signaling that the status quo is neither beloved nor stable. The system is ripe for a change.

Tickets, But Programmable​

NFT tickets aren’t about speculative digital art; they're about programmable access and ownership. By representing a ticket as a unique token on a blockchain, we fundamentally change what it can do:

• Provable Ownership: Tickets live in a user's digital wallet, not just in a vendor's siloed database. This cryptographic proof of ownership dramatically reduces the risk of counterfeit tickets and enables secure, verifiable transfers between fans.
• On-Chain Transfer Rules: Organizers can embed rules directly into the ticket’s smart contract. This could mean setting fair-transfer windows, capping resale prices at face value, or building in other logic that curbs predatory scalping and aligns incentives for everyone.
• Loyalty That Compounds: A wallet containing tickets from past events becomes a portable and verifiable “fan graph.” Organizers can use this history to offer token-gated presales, seat upgrades, and exclusive perks that reward actual attendance, not just names on an email list.
• Interoperability: “Sign in with wallet” can become a universal identity layer across different venues, artists, and partners. Fans get a unified experience without spreading their personal information across countless platforms.

This technology is already leaving the lab and proving its value in the wild.

Proof It Works: Live Deployments to Study​

These are not “maybe someday” pilots; they are live systems processing real fan traffic and solving real problems today.

• Token-Gated Presales at Scale: Ticketmaster has already launched NFT-gated ticket sales. In a pilot with the band Avenged Sevenfold, members of the "Deathbats Club" NFT community received exclusive early and discounted access to tickets, rewarding dedicated fans and filtering out bots.
• Souvenir NFTs with Mainstream Brands: Live Nation and Ticketmaster have issued millions of virtual commemorative ticket NFTs, called “Live Stubs,” for major concerts and NFL games. This introduces fans to digital collectibles with virtually zero friction, turning a simple ticket into a lasting keepsake.
• Aviation Goes On-Chain: Argentinian airline Flybondi began issuing its tickets as NFTs via the TravelX platform on the Algorand blockchain. This model enables flexible name changes and new commerce opportunities, proving the technology can work in an industry with strict operational, security, and identity requirements.
• Global Sports & Premium Hospitality: Formula 1’s ticketing provider, Platinium Group, rolled out Polygon-based NFT tickets that come with perks persisting long after race day, such as hospitality access and future discounts. This transforms a one-time seat into an enduring membership touchpoint.

What NFT Tickets Unlock for Fans & Organizers​

This shift creates a win-win scenario, offering tangible benefits to everyone in the ecosystem.

• Fairer Access, Less Chaos: Token-gated presales can effectively reward verified attendees or fan club members, bypassing the captcha wars and bot-driven chaos of a general sale. The fact that the largest U.S. primary ticket seller now natively supports this proves its viability.
• Transfers with Guardrails: Smart contracts allow organizers to define how and when tickets can be transferred, aligning with local laws and artist preferences. Secondary royalties are also possible through standards like EIP-2981, though enforcement depends on marketplace adoption. This gives organizers more control over the secondary market.
• Portable Loyalty: Commemorative drops, like digital stubs or POAPs (Proof of Attendance Protocols), build a verifiable fan history that can actually be used across different venues, brands, and seasons. Your attendance record becomes a key to unlocking future rewards.
• Interoperable User Experience: With custodial wallets and simple email or SMS logins, fans don’t need to manage complex seed phrases. Mass-market rollouts like Reddit’s millions of on-chain avatars—purchased with standard currency—prove this user-friendly pattern can scale.

Patterns We Recommend Shipping (In Order)​

1. Start with “Souvenir Mode.” The lowest-risk, highest-reward entry point is to issue free or bundled commemorative NFTs delivered after a ticket is scanned. This builds your on-chain fan graph and educates users without adding friction to the core job of getting them in the door. Live Nation’s “Live Stubs” is the perfect precedent.
2. Layer in Token-Gated Presales for Superfans. Use the fan graph you’ve built. Let proven attendees or fan club members unlock prime seats or early access windows. This creates a clear reward for loyalty, reduces bot competition, and provides much cleaner economic data. The Avenged Sevenfold presale is the canonical case study here.
3. Make the Ticket a Wallet. Treat each ticket as the root credential for delivering ongoing perks. This could be exclusive merchandise access, instant seat upgrades, food and beverage credits, or even artist AMAs—delivered before, during, and after the show. Formula 1’s membership-style approach points the way forward.
4. Design the Secondary Market Thoughtfully. If you allow resale, establish clear rules that fit your policies and fan expectations. This could mean time-boxed transfer windows, fee caps, or face-value requirements. While standards like EIP-2981 signal royalty preferences, some marketplaces have made them optional. A direct, branded resale channel can be a wise move to ensure your rules are respected.

What Can Go Wrong (and How to Avoid It)​

• Custody & Platform Risk: Don’t strand your customers on a centralized island. When the crypto exchange FTX collapsed, some Coachella NFTs tied to the platform were stuck. If a technology partner disappears, fans shouldn’t lose their assets or benefits. Use portable wallets and ensure perks can be reissued or recognized elsewhere.
• UX Over Crypto Jargon: The average fan should never have to see terms like “seed phrase,” “gas fees,” or “blockchain.” As Reddit demonstrated, gentle, custodial onboarding with familiar fiat checkouts is the key to scaling to millions of users. The complexity should remain under the hood.
• Unrealistic Royalty Expectations: “Automatic royalties forever” is not guaranteed across all secondary markets. If resale economics are a key part of your strategy, consider launching your own resale venue or enforcing your rules through allowlists and clear branding terms with partners.
• The Policy Patchwork: Ticketing laws are actively being revised across the U.S., with a focus on refunds, price transparency, anti-bot measures, and transfer rights. Your system must be architected to allow for configuration by region, and your policies must be communicated explicitly to fans.

Architecture Blueprint (Pragmatic, Chain-Agnostic)​

• Chain Selection: Favor low-fee, high-throughput networks already used in consumer contexts, such as Polygon, Flow, or Algorand. Mainstream deployments have gravitated toward these chains for their low cost, speed, and better environmental footprint.
• Token Standard: Use ERC-721 for unique, assigned seats and ERC-1155 for general admission sections or tiers. Add EIP-2981 metadata if you plan to support royalties within compliant marketplaces.
• Wallet UX: Default to custodial wallets that use email/SMS login or passkeys for authentication. Provide an easy, optional path for users to “export to self-custody.” Pre-mint tickets to wallets or use a mint-on-claim model to reduce waste.
• Gating & Scanning: Use fast, off-chain allowlists or Merkle proofs at the gate for quick entry. Verify ownership with time-limited digital signatures to prevent simple QR code screenshotting. After a successful scan, delight the fan by airdropping perks like POAPs, collectibles, or coupons.
• Secondary Market & Compliance: If you enable resale, route it through a branded marketplace or a partner that respects your rules. Parameterize transferability settings to comply with different state and local laws, and pair on-chain rules with clear, human-readable refund and transfer policies.

Metrics That Actually Matter​

Move beyond vanity metrics and focus on what truly indicates success.

• Access Fairness: Measure the presale conversion rate for verified fans versus the general public. Track the percentage of tickets that are resold within a face-value price band.
• Operational Reliability: Monitor gate throughput, scan failure rates, and the load on your customer support team. A successful implementation should reduce friction, not create it.
• Fan Compounding: Track repeat attendance among NFT holders, measure the redemption rates for digital perks, and analyze the revenue uplift from token-gated campaigns.
• Unit Economics: Analyze your fee take-rate net of fraud-related chargebacks. Calculate the blended customer acquisition cost and lifetime value when wallet data is used to inform marketing and targeting.

Case Study Nuggets to Borrow​

• Use NFTs as a "Thank You," Not a Hurdle: Live Nation’s commemoratives cost fans nothing and teach them the flow. Start there before you touch access control.
• Reward Real Attendance: Token-gated presales that reference past check-ins feel fair and build loyalty.
• Design Perks with a Shelf-Life: Formula 1’s persistent benefits, like hospitality access and future discounts, extend the ticket’s utility far beyond the event itself.
• Avoid a Single Point of Failure: The Coachella-FTX saga underscores why portability matters. Own the fan relationship; let users take their assets with them when they want.

The Policy Reality (Briefly)​

The regulatory landscape is heating up. Federal and state attention on ticketing is rising, with transparency, refunds, anti-bot rules, and transferability becoming hot-button issues. Your smart contracts and user experience must be flexible enough to adapt on a jurisdiction-by-jurisdiction basis. The entire market structure is in flux, and building on portable, open rails is the safest long-term bet.

A Practical Rollout Plan (90 Days)​

Phase 1: Collectibles (Weeks 1-4)

• Implement free commemorative NFTs for all attendees, claimed via email after the event. Measure your claim rate and wallet creation stats.

Phase 2: Fan-First Presales (Weeks 5-8)

• Pilot a small, token-gated presale for verified past attendees. Communicate the process clearly and keep a traditional queue open as a backup.

Phase 3: Perks & Partnerships (Weeks 9-10)

• Turn the ticket into a perks wallet. Link it to merchandise unlocks, partner discounts, or exclusive content drops for specific seat sections or cities.

Phase 4: Controlled Resale (Weeks 11-12)

• Launch a branded resale page with rules aligned to local law. Test face-value caps and transfer windows on a small scale before rolling out nationally.

Closing Thought​

The paper stub was once a cherished souvenir of a great night out. NFT tickets can be that—and so much more. When access is programmable, loyalty becomes a composable asset that travels with a fan across venues, artists, and seasons. Fans get fairer access and better perks; organizers get durable relationships and cleaner economics. And when the crypto complexity stays under the hood where it belongs, everybody wins.

Architecture Diagram​

Here is a Mermaid diagram illustrating the pragmatic, chain-agnostic architecture described in the blueprint.

はじめに​

StripeのTempoは、高速で低コストのステーブルコイン決済処理に中核的に焦点を当てた、新しく立ち上げられたLayer-1（L1）ブロックチェーンネットワークです。このプロジェクトは、決済大手のStripeと著名な暗号通貨ベンチャーキャピタル企業であるParadigmによって共同インキュベートされました。当初から「決済ファースト」のブロックチェーンとして位置付けられ、現実世界の金融シナリオの厳しいスケールとパフォーマンス要件を満たすように設計されています。2025年に、Tempoはプライベートテストネット段階に入り、Visa、Deutsche Bank、Shopify、OpenAIを含む数社の重量級パートナーと機能を共同設計・検証しています。開発者コミュニティにとって、Tempoの出現は新しい機会を提示します—ステーブルコインと商用ユースケース向けに最適化された基盤インフラ上で、次世代の決済アプリケーションを構築することです。このガイドでは、開発者がTempoと技術的に統合する方法、利用可能なリソースやコミュニティ、そしてこの成長するエコシステムに参加する方法について詳述します。

1. 技術統合：L1 Tempoでの構築​

Tempoの中核設計哲学は、Ethereumとの完全な互換性の道を選ぶことで開発者の参入障壁を下げることです。これは、開発者が既存の成熟したツールと知識ベースを使用して構築できることを意味します。TempoのアーキテクチャはReth（Paradigmが主導するEthereumクライアントのRust実装）に基づいており、Ethereumスマートコントラクトとその開発者ツールチェーンと自然に互換性があります。

その主要な技術的特徴と統合ポイントは次のとおりです：

• EVMとスマートコントラクト： TempoはSolidityスマートコントラクトとEthereum Virtual Machine（EVM）を完全にサポートします。開発者は、Hardhat、Truffle、Foundryなどの標準フレームワーク、およびethers.js、web3.jsなどのライブラリを使用して、スマートコントラクトの記述、テスト、デプロイを行えます。Web3開発者にとって、このシームレスな互換性は学習曲線がほとんどないことを意味します。既存のdApp、ウォレット（MetaMaskなど）、開発ツールはTempoで「そのまま」動作し、Ethereumから成熟したアプリケーションの簡単な移行への道筋を築きます。

• 高スループットと確定性： Tempoは決済シナリオの速度要件に向けて深く最適化されています。その設計目標は、**毎秒100,000トランザクション（TPS）**を超える処理能力を達成し、サブ秒決定論的確定性に到達することです。これは、トランザクションが一度確認されると不可逆であることを意味し、従来の確率的確認（Proof-of-Workなど）で発生する可能性のあるトランザクション再編成（reorg）のリスクを排除します。この高いパフォーマンスと確実性は、POS（販売時点）システム、取引所、マイクロペイメントなど、厳格な即時決済要件を持つアプリケーションにとって重要です。

• ステーブルコインネイティブ設計： ほとんどの汎用パブリックチェーンとは異なり、Tempoネットワークはトランザクション手数料（Gas）を支払うために揮発性のネイティブトークンに依存しません。そのネットワークでのトランザクション手数料は、主要なステーブルコイン（USDC、USDTなど）を使用して直接支払うことができます。これを実現するために、プロトコルは自動マーケットメーカー（AMM）を統合し、手数料支払いの「発行者中立性」を確保するために、バックグラウンドで異なるステーブルコイン間のスワップを自動的に処理できます。開発者とユーザーにとって、これは大幅にエクスペリエンスを向上させます。トランザクションコストが法定通貨価値（例：常に約$0.001）に安定して紐付けられ、ネイティブトークン価格の変動による不確実性を回避できるためです。

• 決済指向の機能： Tempoは、金融および決済アプリケーション向けに調整されたいくつかの機能をプロトコルレベルで追加します。これには次が含まれます：

  • 「ペイメントレーン」： 決済タイプのトランザクションを他のタイプのオンチェーン活動（複雑なDeFi操作など）から分離することで、これらのレーンは決済の低レイテンシと高優先度を確保します。
  • ネイティブバッチ転送： Account Abstractionなどの技術を活用し、単一のトランザクションで複数のアドレスへの支払いを効率的に送信することをサポートし、給与や供給業者の支払いなどのシナリオで非常に実用的です。
  • トランザクションメモフィールド： このフィールドはISO 20022金融メッセージング標準と互換性があり、請求書参照番号やコンプライアンスデータなどのメタデータをオンチェーントランザクションに添付できるため、企業の財務調整プロセスが大幅に簡素化されます。
  • オプショナルプライバシー： プロトコルは、商業的に機密な情報を保護するための企業コンプライアンスニーズを満たすオプショナルトランザクションプライバシー機能をサポートします。

• Stripe API経由の統合： Stripeは、Tempoを既存の製品スイートに深く統合し、開発者に2つの統合パスを提供する予定です。1つ目は直接オンチェーン開発で、Web3開発者が慣れ親しんだツールチェーンを使用してTempo上に直接スマートコントラクトをデプロイします。2つ目はStripeの高レベルAPI経由の統合で、これはブロックチェーンの複雑さを完全に抽象化します。例えば、StripeのBridgeプラットフォーム（クロスチェーンステーブルコインフロー用のツール）は、将来Tempoをその中核決済レールの1つとして使用します。開発者は慣れ親しんだStripeのREST APIを呼び出して決済や転送を開始するだけで、Stripeシステムがバックグラウンドで自動的にTempoネットワーク上で実行します。これにより、ノード管理や秘密鍵署名などの基盤的な詳細を心配することなく、ブロックチェーンの速度とコストの利点を享受できます。

2. 開発者ドキュメント、チュートリアル、オンボーディングリソース​

2025年後半現在、Tempoはまだプライベートテストネット段階にあり、公式開発者ドキュメントが活発に作成中です。しかし、Tempoの公式ウェブサイトでは、*「開発者向けの包括的な技術ドキュメントが近日公開予定」*であることが確認されています。

その間、興味のある開発者は以下のチャネルを通じて予備情報を入手できます：

• 公式ウェブサイトとFAQ： Tempoの公式ウェブサイトとそのよくある質問（FAQ）ページを訪問することで、その設計哲学、中核機能、汎用ブロックチェーンとの違いについて高レベルの概要を得られます。
• テストネットアクセスの申請： 興味のある開発者や企業は、Tempoウェブサイト（partners@tempo.xyz）で提供されているチャネルを通じて申請を送信し、初期の探索とプロトタイピングのためにプライベートテストネットへのアクセスを得ることができます。

Stripeの開発者エクスペリエンスへの一貫した焦点に基づいて、公式ドキュメントがリリースされた際には以下のリソースが含まれることが期待できます：

• 入門ガイド： 開発者が開発環境をセットアップし、Tempoテストネットに接続し、最初のスマートコントラクトをデプロイする方法を案内する詳細なチュートリアル。
• APIリファレンスとSDKドキュメント： Stripe API統合パスの完全な技術リファレンス、およびTempoプロトコルとやり取りするためのJSON-RPCエンドポイントのドキュメント。
• チュートリアルとサンプルアプリケーション： Tempo上で一般的な決済アプリケーションを構築する方法を示すオープンソースのサンプルコードとプロジェクト。
• ベストプラクティス： セキュリティ、コンプライアンス、パフォーマンス最適化、その他の分野に関する専門的なアドバイス。

Stripeは明確で高品質なAPIドキュメントで有名であり、Tempoのドキュメントも同じ基準を維持すると考える十分な理由があります。

3. Stripeの開発者エンゲージメントチャネルとコミュニティ​

Stripeには成熟した活発な開発者コミュニティエコシステムがあります。Tempoについて最新情報を得て技術サポートを受けたい開発者には、以下の公式チャネルが利用可能です：

• Stripe Developer Discord： これは12万人以上のメンバーを持つ大規模コミュニティで、Stripeエンジニアが直接参加して質問に答えています。Tempoの最新発表、技術討論、コミュニティサポートはすべてここで見つけることができます。
• オンラインフォーラムとQ&Aプラットフォーム： StripeチームはStack Overflow（stripeタグを使用）とTwitter/X（@StripeDev）に投稿された質問を積極的にモニタリングし、回答しています。
• Stripeブログとニュースレター： これは公式情報、詳細な技術記事、製品アップデートの主要チャネルです。Tempoの主要なマイルストーンとケーススタディはここで公開されます。
• 開発者イベントとウェビナー： Stripeは定期的にオンラインとオフラインのイベントを主催しています。特に、その年次開発者カンファレンスStripe Sessionsは、しばしば主要な製品発表のプラットフォームとなり、将来的にはTempo専用の技術セッションとワークショップを特集する可能性があります。

これらの確立されたチャネルを活用することで、開発者は簡単に情報を得、問題を解決し、Tempoに興味を持つ他の開発者とつながることができます。

4. Tempoエコシステムに貢献する機会​

Tempoが内部インキュベーションプロジェクトからオープンなパブリックネットワークに移行する中で、開発者はアプリケーション構築以外にも様々な方法でエコシステムに参加し貢献することができます：

• オープンソース貢献： TempoはオープンソースのRethクライアントをベースにしており、独自の中核コンポーネントも段階的にオープンソース化されることが期待されています。開発者はコードをレビューし、課題を提出し、改善を提案し、さらにはプロトコルのパフォーマンスとセキュリティを共同で向上させるために直接コードを貢献することもできるでしょう。
• バリデーター参加とネットワークガバナンス： Tempoのバリデーターノードは現在、許可制モデルで創設パートナーによって運営されていますが、長期計画は許可なしモデルへの移行です。その時点で、技術的に有能な開発者や組織は誰でもバリデーターノードを運営し、ネットワークコンセンサスに参加し、ネットワークを保護しながらステーブルコイン形式でトランザクション手数料を得ることができます。ネットワークが分散化するにつれて、コミュニティガバナンスメカニズムも確立され、開発者がプロトコルアップグレードの決定に参加できるようになるかもしれません。
• プロトコル改善提案（TIP）： 開発者は、新機能を提案したり既存メカニズムの最適化を提案するためにTempo改善提案（TIP）を書いて議論することで、EthereumのEIPモデルからインスピレーションを得て、プロトコルの進化に直接影響を与えることができます。
• ハッカソンと開発者チャレンジに参加： StripeとParadigmの両方には開発者イベントをサポートする伝統があります。Tempoの開発者ツールチェーンが成熟すれば、専用のハッカソントラックや賞金チャレンジがあり、開発者がその上でイノベーションを起こすことを奨励することが予見できます。
• コミュニティ教育と知識共有： 初期参加者として、開発者は技術ブログの執筆、ビデオチュートリアルの作成、コミュニティでの質問回答、技術カンファレンスでの講演によって自らの経験と洞察を共有し、開発者コミュニティ全体の成長を支援できます。

Tempoエコシステムは構築の初期段階にあり、開発者が様々な方法で深く関わり、その未来を形作る貴重な機会を提供しています。

5. 開発者向けのインセンティブとグラントプログラム​

現在、StripeはTempo開発者向けのグラントプログラムやインセンティブを正式には発表していません。同時に、Tempoの設計では新しい投機的ネイティブトークンの発行を明示的に除外しています。しかし、これはエコシステムが開発者サポートを欠いていることを意味するものではありません。将来のインセンティブはより多くユーティリティとエコシステム構築に焦点を当てることが予見でき、以下が含まれる可能性があります：

• エコシステムファンド： Stripe、Paradigm、または独立財団によって設立され、Tempoエコシステム向けの重要なインフラ（ウォレット、エクスプローラー、分析ツールなど）や有望なアプリケーションを構築するチームに直接グラントを提供。
• ハッカソン賞金とバウンティ： 競技を通じて開発者にインセンティブを与え、特定機能のオープンソースライブラリ開発などの特定開発タスクにバウンティを投稿。
• パートナーインセンティブ： Tempoをビジネスに統合することを選択する企業パートナーに対して、Stripeは手数料削減、優先技術サポート、共同マーケティング推進などの商業的インセンティブを提供するかもしれません。
• バリデーター報酬： ネットワークが許可なしモデルに移行すれば、バリデーターノードの運営とトランザクション処理により、ステーブルコイン建てのトランザクション手数料から継続的な収入の流れが提供されます。
• 戦略的投資： Tempo上で優秀な製品やサービスを構築するスタートアップに対して、StripeやParadigmからの戦略的投資や潜在的な買収も重要なインセンティブです。

要約すると、Tempoのインセンティブモデルはトークン投機よりも現実世界の価値構築を中心に回ることになります。

6. Tempoに関するイベント、ワークショップ、ミートアップ​

Tempoについて学び、コミュニティとつながりたい開発者は、以下のタイプのイベントに注意を払うことができます：

• Stripe Sessions： Stripeの年次開発者カンファレンスは、Tempoの公式ロードマップと主要アップデートを得るための最重要な場所です。
• Paradigm Frontiers： 最先端の暗号技術の開発者向けにParadigmが主催し、将来のイベントではTempoの詳細な技術セッションとハッカソンチャレンジが含まれる可能性があります。
• フィンテックと暗号業界カンファレンス： Money20/20やConsensusなどの主要カンファレンスでの決済イノベーションに関する議論は必然的にTempoを含み、その市場ポジショニングと商業応用の展望を理解する良い機会となります。
• ローカルミートアップとオンラインウェビナー： Stripeやローカル開発者コミュニティが組織するより小規模なイベントは、より直接的な相互作用と実践的な学習体験を提供することが多いです。
• グローバルハッカソン： ETHGlobalのような大規模なハッカソンイベントでは、将来Tempoがスポンサープラットフォームとして特集される可能性があり、開発者が国際舞台でイノベーションを起こす機会を提供します。

結論​

StripeのTempoブロックチェーンは、従来のフィンテックの厳格さと暗号世界の開放性を融合した、開発者にユニークな交差点を提供します。開発者はそのEthereum互換性を活用して慣れ親しんだツールで迅速に開始することも、StripeのAPIを通じてTempoの強力な機能を既存ビジネスにシームレスに統合することもできます。プロジェクトはまだ初期段階にあり、ドキュメントやサポートプログラムの多くがまだ開発中ですが、StripeとParadigmの強力なバッキングは開発者エクスペリエンスと技術的進歩への高いコミットメントを示しています。既存のリソースを積極的に使用し、コミュニティに参加し、関連イベントに参加することで、開発者は現実世界の決済問題の解決に焦点を当てたブロックチェーンネットワークにおける貴重な初期段階の機会を掴むことができます。

1. 流動性とSui DeFiの成長​

図：Sui の DeFi TVL（青線）と DEX ボリューム（緑棒）は 2025 年第2四半期までに劇的に成長しました。

総ロック価値（TVL）急増： Sui ネットワークの DeFi 流動性は過去 1 年で爆発的に拡大しました。2024 年末の $600M TVL** から、2025 年中頃には **$ 2B 超 に急上昇しました。実際、2025 年 5 月 21 日には $2.55B TVL** のピークを記録し、第2四半期の大半で **$ 2B 超 を維持しました。この 300% + の増加（2025 年第2四半期までの 480% の伸び）により、Sui の TVL は数十億ドル規模に達しました。流動性の増加は $ 1.8B 超の TVL をもたらし、主要な DEX とレンディング プロトコルが牽引しています。

Sui の DEX は $1.2B** 超の取引ボリュームを処理し、流動性提供者は **$ 500M 超の報酬を獲得しました。流動性の増加は $ 102M 超の BTC 系資産が Sui のレンディング プラットフォームに流入したことでも裏付けられます。

2. 主要な DEX とプロトコル​

• Cetus：Sui 上で最大級の AMM として機能し、流動性プールは $ 300M 超をロックしています。集中型流動性提供とマルチプール戦略により、スリッページを最小化しつつ取引手数料を最大化しています。
• Bluefin：高速取引と機関投資家向け機能を提供。第2四半期には Spot 2.0 アップグレードで MEV 抵抗型 RFQ マッチングを実装し、低レイテンシ取引を実現しました。
• Momentum：CLMM（集中型流動性プール）を導入し、資本効率を向上させました。第2四半期には $ 150M 超の流動性を集中させ、スリッページを 0.1% 未満に抑えました。
• Magma：ALMM（適応型流動性マーケットメイカー）を展開し、流動性の動的再配分と低スリッページ取引を実現しました。

2. アカウント抽象化とユーザー体験の向上​

Sui のアカウント抽象化は、ユーザーがウォレットや認証手段をシームレスに切り替えられるように設計されています。これにより、以下が可能になりました。

• ソーシャルログイン：Google、Twitter、Discord などの ID プロバイダーでのサインインが可能です。
• マルチシグウォレット：複数署名者がトランザクションを承認でき、資金の安全性が向上します。
• プラグイン認証：ZK プルーフや生体認証を組み込んだカスタム認証モジュールを簡単に統合できます。

これらの機能により、Sui の DeFi エコシステムは $ 1.8B 超の TVL を達成し、ユーザーエクスペリエンスが大幅に向上しました。

3. 次世代プリミティブとイノベーション​

ネイティブステーブルコイン​

• Agora Finance の AUSD：2024 年末にリリースされた完全 USD バックのステーブルコイン。2025 年第2四半期までに循環供給は数千万単位に達し、規制対応型代替資産として広く採用されました。
• Bucket Protocol の BUCK：過剰担保型ステーブルコインで、USD にペッグされています。2025 年第2四半期には $60M –$ 66M の供給に達し、プロトコル全体の TVL の $ 69M を支えました。
• Ondo Finance の USDY：米国短期国債利回りをトークン化したイールドベアリングステーブルコイン。2025 年までに Sui エコシステム内で $ 200M 超の資産を管理しています。

BTCfi（Bitcoin DeFi）イノベーション​

• Threshold Network の tBTC：2025 年第2四半期に Sui 上でリリースされ、$ 500M 超 の BTC 流動性を提供。ユーザーは BTC をロックせずに 1:1 の tBTC をミントし、貸付や取引に利用できます。
• Stacks の sBTC：2025 年第2四半期までに TVL の 10% 超が BTC 系資産で構成され、$ 102M 超の Bitcoin ベース資産が Sui のレンディング プラットフォームにロックされました。

高性能 DEX と HFT​

• Bluefin Institutional HFT：2025 年第3四半期にインスティテューショナル向け高頻度取引戦略を導入。Sui の並列実行により、取引レイテンシがミリ秒単位に短縮され、MEV 抵抗型 RFQ マッチングが実装されました。

新しい金融商品とパートナーシップ​

• Graviton：シリーズ A で $ 50M を調達し、モジュラー型トレーディング・レンディング・クロスマージニングプラットフォームを構築中。dYdX に匹敵するプロフェッショナル向け DeFi スーパ―アプリを目指しています。
• xMoney / xPortal：Sui ベースの資産で利用できる MasterCard を開発中。小売ユーザーが日常の支払いに暗号資産を使用できるようになります。
• 21Shares：米国で SUI 上場投資信託（ETF）を申請。伝統的投資家に Sui エコシステムへのエクスポージャーを提供します。

4. 開発者コミュニティとエコシステムの活性化​

2025 年中頃、Sui のオープンソース Move エコシステムは週次コミット数とリポジトリフォーク数で Solana と Near を上回り、ツールチェーン、zk‑proof 統合、クロスチェーンプロトコル開発が急増しています。ハッカソンプロジェクトではオンチェーンオプション市場、分散型保険、インテントベース貸付などが試みられ、Lotus Finance が分散型オプション AMM として Q2 にローンチしました。さらに、Google Cloud との提携によりオンチェーンデータインデックスと AI 推論ツールが提供され、AI オラクルを活用した動的価格設定や BTC ステーキングサービス（SatLayer）などの新プリミティブが実装されています。

5. まとめ​

2025 年の Sui DeFi エコシステムは、流動性の拡大、抽象化によるユーザー体験の向上、そして次世代プリミティブの波 によって急速に成熟しています。主要 DEX（Cetus、Bluefin、Momentum）とレンディング プラットフォーム（Suilend、SuiLend など）が深い流動性を支え、アカウント抽象化が新規ユーザー層を呼び込み、ネイティブステーブルコインや BTCfi、先進的 AMM、パーペチュアル・フューチャー、実世界資産トークンが DeFi の可能性を拡大しています。インフラプロバイダー、トラディショナル金融機関、クロスチェーンネットワークとのハイプロファイルなパートナーシップが Sui の勢いをさらに加速させ、2025 年までに リーディング DeFi ハブ としての地位を確固たるものにしています。

出典：

• Sui Foundation – Sui Q2 2025 DeFi Roundup (July 15, 2025)
• Sui Foundation – NEAR Intents Brings Lightning-Fast Cross-chain Swaps to Sui (July 17, 2025)
• Sui Foundation – Sui to Support sBTC and Stacks (BTCfi Use Cases) (May 1, 2025)
• Sui Foundation – All About Account Abstraction (Oct 4, 2023)
• Ainvest News – Sui Network TVL Surpasses $ 1.4B Driven by DeFi Protocols (Jul 14, 2025)
• Ainvest News – Sui DeFi TVL Surges 480% to $ 1.8B... (Jul 12, 2025)
• Suipiens (Sui community) – tBTC Integration Brings Bitcoin Liquidity to Sui (Jul 17, 2025)
• Suipiens – Inside Suilend: Sui’s Leading Lending Platform (Jul 3, 2025)
• The Defiant – Ondo to Bring RWA-Backed Stablecoins onto Sui (Feb 7, 2024)
• Official Sui Documentation – Intro to Sui: User Experience (account abstraction features)

2025年5月7日、EthereumのPectraアップグレード（Prague + Electra）がメインネットにリリースされました。開発者にとって最も目に見える変更の一つがEIP-7702で、これは外部所有アカウント（EOA）が資金を移行したりアドレスを変更したりすることなく、スマートコントラクトロジックを「マウント」できるようにします。ウォレット、dapp、リレイヤーを構築している場合、これはスマートアカウントUXへのより簡単な道筋を提供します。

以下は実装重視の簡潔なガイドです：実際に出荷されたもの、7702がどのように動作するか、純粋なERC-4337よりもいつ選択するべきか、そして今日適用できるコピー&ペースト可能なスカフォールド。

実際に出荷されたもの​

• EIP-7702はPectraの最終範囲に含まれています。 Pectraハードフォークのメタ-EIPは、含まれる変更の中に7702を正式にリストしています。
• アクティベーション詳細： Pectraは2025年5月7日のエポック364032でメインネット上でアクティベートされ、すべての主要テストネットでの成功したアクティベーションに続きました。
• ツールチェーン注記： Solidity v0.8.30は、Pectra互換性のためにデフォルトEVMターゲットをpragueに更新しました。コンパイラとCIパイプラインをアップグレードする必要があります、特に特定のバージョンを固定している場合。

EIP-7702—どのように動作するか（詳細）​

EIP-7702は新しいトランザクションタイプと、EOAがその実行ロジックをスマートコントラクトに委任するメカニズムを導入します。

• 新しいトランザクションタイプ（0x04）： タイプ4トランザクションにはauthorization_listという新しいフィールドが含まれます。このリストには一つ以上の認証タプル—(chain_id, address, nonce, y_parity, r, s)—が含まれ、それぞれEOAの秘密鍵で署名されています。このトランザクションが処理されると、プロトコルはEOAのコードフィールドに委任インジケーターを書き込みます：0xef0100 || address。それ以降、EOAへのすべての呼び出しは指定されたaddress（実装）にプロキシされますが、EOAのストレージとバランスコンテキスト内で実行されます。この委任は明示的に変更されるまで有効です。
• チェーンスコープ： 認証はchain_idを提供することでチェーン固有にできるか、chain_idが0に設定されている場合はすべてのチェーンに適用できます。これにより、ユーザーが各チェーンに対して新しい認証に署名することなく、同じ実装コントラクトを複数のネットワークにデプロイできます。
• 取り消し： EOAを元の非プログラマブル動作に戻すには、実装addressがゼロアドレスに設定された別の7702トランザクションを送信するだけです。これにより委任インジケーターがクリアされます。
• セルフスポンサード vs. リレー： EOA自身がタイプ4トランザクションを送信することも、サードパーティのリレイヤーがEOAの代わりに送信することもできます。後者はガスレスユーザーエクスペリエンスを作成するために一般的です。nonceハンドリングは方法によって若干異なるため、この区別を正しく管理するライブラリを使用することが重要です。

セキュリティモデルの変化： 元のEOA秘密鍵がまだ存在するため、新しい7702トランザクションを送信して委任を変更することで、常にスマートコントラクトルール（ソーシャルリカバリーや支出制限など）を上書きできます。これは根本的な変化です。tx.originを使用してEOAからの呼び出しであることを確認するコントラクトは再監査が必要です、7702がこれらの前提を破る可能性があるためです。フローを適切に監査してください。

7702かERC-4337か？（そして組み合わせるべき時）​

EIP-7702とERC-4337の両方がアカウント抽象化を可能にしますが、異なるニーズに対応します。

• EIP-7702を選ぶべき時…
  • ユーザーに資金を移行させたりアドレスを変更させることなく、既存のEOAに即座のスマートアカウントUXを提供したい場合。
  • 新機能で段階的にアップグレードできるチェーン間での一貫したアドレスが必要な場合。
  • アカウント抽象化への移行を段階的に進めたい場合、シンプルな機能から始めて時間をかけて複雑さを追加する。
• 純粋なERC-4337を選ぶべき時…
  • 製品が完全なプログラマビリティと複雑なポリシーエンジン（マルチシグ、高度な回復など）を最初から必要とする場合。
  • 既存のEOAを持たない新しいユーザー向けに構築している場合、新しいスマートアカウントアドレスと関連する設定が受け入れられる。
• 両方を組み合わせる： 最も強力なパターンは両方を使用することです。EOAは7702トランザクションを使用してERC-4337ウォレット実装をそのロジックとして指定できます。これによりEOAは4337アカウントのように動作し、既存の4337インフラストラクチャによってバンドル、ペイマスターによるスポンサー、処理が可能になります—すべてユーザーが新しいアドレスを必要とすることなく。これはEIPの著者によって明示的に推奨される前方互換パスです。

適用可能な最小限の7702スカフォールド​

実装コントラクトとそれを有効化するクライアントサイドコードの実用的な例を以下に示します。

1. 小さく監査可能な実装コントラクト​

このコントラクトコードは指定されるとEOAのコンテキスト内で実行されます。小さく監査可能に保ち、アップグレードメカニズムの追加を検討してください。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// @notice EIP-7702で指定された時にEOAコンテキストから呼び出しを実行します。
contract DelegatedAccount {
    // 他のコントラクトとの衝突を避けるためのユニークなストレージスロット。
    bytes32 private constant INIT_SLOT =
        0x3fb93b3d3dcd1d1f4b4a1a8db6f4c5d55a1b7f9ac01dfe8e53b1b0f35f0c1a01;

    event Initialized(address indexed account);
    event Executed(address indexed to, uint256 value, bytes data, bytes result);

    modifier onlyEOA() {
        // オプション：特定の関数を呼び出せるユーザーを制限するチェックを追加。
        _;
    }

    function initialize() external payable onlyEOA {
        // EOAのストレージにシンプルなワンタイム初期化フラグを設定。
        bytes32 slot = INIT_SLOT;
        assembly {
            if iszero(iszero(sload(slot))) { revert(0, 0) } // すでに初期化済みの場合はrevert
            sstore(slot, 1)
        }
        emit Initialized(address(this));
    }

    function execute(address to, uint256 value, bytes calldata data)
        external
        payable
        onlyEOA
        returns (bytes memory result)
    {
        (bool ok, bytes memory ret) = to.call{value: value}(data);
        require(ok, "CALL_FAILED");
        emit Executed(to, value, data, ret);
        return ret;
    }

    function executeBatch(address[] calldata to, uint256[] calldata value, bytes[] calldata data)
        external
        payable
        onlyEOA
    {
        uint256 n = to.length;
        require(n == value.length && n == data.length, "LENGTH_MISMATCH");
        for (uint256 i = 0; i < n; i++) {
            (bool ok, ) = to[i].call{value: value[i]}(data[i]);
            require(ok, "CALL_FAILED");
        }
    }
}

2. viemでEOAにコントラクトを指定（タイプ4 tx）​

viemのような現代的なクライアントは、認証に署名してタイプ4トランザクションを送信する組み込みヘルパーを持っています。この例では、relayerアカウントがeoaをアップグレードするためのガスを支払います。

import { createWalletClient, http, encodeFunctionData } from "viem";
import { sepolia } from "viem/chains";
import { privateKeyToAccount } from "viem/accounts";
import { abi, implementationAddress } from "./DelegatedAccountABI";

// 1. リレイヤー（ガススポンサー）とアップグレードされるEOAを定義
const relayer = privateKeyToAccount(process.env.RELAYER_PK as `0x${string}`);
const eoa = privateKeyToAccount(process.env.EOA_PK as `0x${string}`);

const client = createWalletClient({
  account: relayer,
  chain: sepolia,
  transport: http(),
});

// 2. EOAが実装コントラクトを指す認証に署名
const authorization = await client.signAuthorization({
  account: eoa,
  contractAddress: implementationAddress,
  // EOA自身がこれを送信する場合は追加：executor: 'self'
});

// 3. リレイヤーがタイプ4トランザクションを送信してEOAのコードを設定し、initialize()を呼び出す
const hash = await client.sendTransaction({
  to: eoa.address, // 宛先はEOA自身
  authorizationList: [authorization], // 新しいEIP-7702フィールド
  data: encodeFunctionData({ abi, functionName: "initialize" }),
});

// 4. これで、EOAは追加の認証なしに新しいロジックで制御できます
// 例えば、トランザクションを実行するには：
// await client.sendTransaction({
//   to: eoa.address,
//   data: encodeFunctionData({ abi, functionName: 'execute', args: [...] })
// });

3. 委任を取り消す（プレーンEOAに戻す）​

アップグレードを元に戻すには、EOAにゼロアドレスを実装として指定する認証に署名させ、別のタイプ4トランザクションを送信します。その後、eth_getCode(eoa.address)への呼び出しは空のバイトを返すはずです。

本番環境で機能する統合パターン​

• 既存ユーザーのためのインプレースアップグレード： dappで、ユーザーがPectra互換ネットワークにいるかどうかを検出します。もしそうなら、ワンタイム認証署名をトリガーするオプションの「アカウントアップグレード」ボタンを表示します。古いウォレットを持つユーザーのためのフォールバック経路（クラシックなapprove + swapなど）を維持します。
• ガスレスオンボーディング： 初期タイプ4トランザクションをスポンサーするためにリレイヤー（バックエンドまたはサービス）を使用します。継続的なガスレストランザクションには、既存のペイマスターと公開メンプールを活用するためにERC-4337バンドラーを通してユーザー操作をルーティングします。
• クロスチェーン展開： すべてのチェーンで同じ実装コントラクトを指定するためにchain_id = 0認証を使用します。その後、アプリケーションロジック内でチェーンごとに機能を有効または無効にできます。
• 監視可能性： バックエンドはタイプ4トランザクションをインデックス化し、どのEOAがアップグレードされたかを追跡するためにauthorization_listを解析する必要があります。トランザクション後、eth_getCodeを呼び出してEOAのコードが委任インジケーター（0xef0100 || implementationAddress）と一致することを確認して変更を検証します。

脅威モデルとGotcha（これをスキップしないでください）​

• 委任は永続的： EOAの実装コントラクトへの変更を、標準的なスマートコントラクトアップグレードと同じ重要度で扱ってください。これには監査、明確なユーザーコミュニケーション、理想的にはオプトインフローが必要です。新しいロジックをユーザーに静かにプッシュしないでください。
• tx.origin地雷： msg.sender == tx.originを使用してEOAから直接呼び出されたことを確認していたロジックは今では潜在的に脆弱です。このパターンはEIP-712署名や明示的許可リストなど、より堅牢なチェックで置き換える必要があります。
• Nonce計算： EOAが自身の7702トランザクションをスポンサーする場合（executor: 'self'）、認証nonceとトランザクションnonceが特定の方法で相互作用します。リプレイ問題を避けるために、これを正しく処理するライブラリを常に使用してください。
• ウォレットUXの責任： EIP-7702仕様は、dappがユーザーに任意の指定への署名を求めるべきではないと警告しています。提案された実装を検証し、安全であることを確認するのはウォレットの責任です。ウォレット仲介セキュリティのこの原則に従うようにUXを設計してください。

7702が明確な勝利となる場合​

• DEXフロー： マルチステップのapproveとswapはexecuteBatch関数を使用してシングルクリックに結合できます。
• ゲームとセッション： ユーザーが新しいウォレットを作成・資金提供することなく、限られた時間またはスコープでセッションキーのような特権を付与します。
• 企業とフィンテック： スポンサー付きトランザクションを有効にし、会計とアイデンティティのために各チェーンで同じ企業アドレスを維持しながらカスタム支出ポリシーを適用します。
• L2ブリッジとインテント： 異なるネットワーク間で一貫したEOAアイデンティティを持つ、よりスムーズなメタトランザクションフローを作成します。

これらのユースケースは、ERC-4337によって約束された同じコアベネフィットを表していますが、今では単一の認証だけですべての既存EOAで利用可能です。

出荷チェックリスト​

プロトコル​

• ノード、SDK、インフラプロバイダーがタイプ4トランザクションとPectraの「prague」EVMをサポートすることを確認。
• 新しいトランザクションでauthorization_listフィールドを解析するようにインデクサーと分析ツールを更新。

コントラクト​

• 必須機能（バッチング、取り消しなど）を持つ最小限の監査済み実装コントラクトを開発。
• メインネットにデプロイする前にテストネットで取り消しと再指定フローを徹底的にテスト。

クライアント​

• クライアントサイドライブラリ（viem、ethersなど）をアップグレードし、signAuthorizationとsendTransaction機能をテスト。
• セルフスポンサーとリレイの両方のトランザクションパスがnonceとリプレイを正しく処理することを確認。

セキュリティ​

• コントラクトからtx.originに基づくすべての前提を削除し、より安全な代替手段に置き換える。
• ユーザーアドレスでの予期しないコード変更を検出し、疑わしいアクティビティについてアラートするデプロイ後監視を実装。

結論： EIP-7702は、すでに使用されている数百万のEOAに対するスマートアカウントUXへの低摩擦オンランプを提供します。小さく監査された実装から始め、ガスレスセットアップにリレイパスを使用し、取り消しを明確で簡単にすれば、完全なアカウント抽象化の90%の利益を提供できます—アドレス変更と資産移行の痛みなしに。

長年にわたって、Ethereum Name Service（ENS）は多くの人にとって暗号通貨愛好家のためのニッチなツール、つまり長くて扱いにくいウォレットアドレスを人間が読める.eth名に置き換える方法と見なされていました。しかし2025年には、その認識は時代遅れです。ENSは、シンプルな名前をポータブルで検証可能で統一されたアンカーとして、企業のデジタル・プレゼンス全体のプログラマブル・ブランド・アイデンティティの基盤レイヤーに進化しました。

もはや単にbrand.ethの話ではありません。brand.comを暗号通貨対応にし、従業員に検証可能な役割を発行し、単一の真実の正典的ソースを通じて顧客との信頼を構築することです。これは、なぜENSが今重要なのか、そして今日それを実装する方法についての企業向けガイドです。

要約

• ENSは名前（例：brand.ethまたはbrand.com）をウォレット、アプリ、ウェブサイト、検証済みプロフィールデータにマップするプログラマブル・アイデンティティに変換します。
• DNSドメインを放棄する必要はありません：ガス不要DNSSECにより、brand.comはセットアップ時にオンチェーン手数料なしでENS名として機能できます。
• .ethの価格は透明で更新ベース（短い名前ほど高価）で、収益はENS DAOを通じて公共善プロトコルに資金を提供します。
• alice.brand.ethやsupport.brand.comなどのサブ名により、NameWrapper「fuses」と有効期限によって時間制限され制約された役割、特典、アクセスを発行できます。
• ENSはENSv2でコア機能をL2に移行中で、CCIP‑Readを通じた信頼最小化解決により、コスト、速度、スケールにとって重要です。

現代企業にとってENSが重要な理由​

企業にとって、アイデンティティは断片化されています。ウェブサイト用のドメイン名、マーケティング用のソーシャルメディアハンドル、決済や運営用の別個のアカウントがあります。ENSはこれらを統一し、単一で権威あるアイデンティティレイヤーを作成する方法を提供します。

• 統一された人間が読めるアイデンティティ： その中核で、ENSは記憶しやすい名前を暗号学的アドレスにマップします。しかし、その力は単一のブロックチェーンをはるかに超えています。マルチチェーン対応により、brand.ethはBitcoin財務、Solana運営ウォレット、Ethereumスマートコントラクトを同時に指すことができます。ブランドの名前は、web3エコシステム全体での決済、アプリケーション、プロフィールのための単一でユーザーフレンドリーなアンカーになります。

• 深いエコシステム統合： ENSはニッチプロトコルへの投機的賭けではなく、web3プリミティブです。主要ウォレット（Coinbase Wallet、MetaMask）、ブラウザ（Brave、Opera）、分散型アプリケーション（Uniswap、Aave）でネイティブにサポートされています。GoDaddyなどのパートナーがENSを統合するとき、それはweb2とweb3インフラの融合を示しています。ENSを採用することで、ブランドを広大で相互運用可能なネットワークに接続しています。

• 豊富で検証可能なプロフィールデータ： アドレス以外にも、ENS名はアバター、メール、ソーシャルメディアハンドル、ウェブサイトURLなどのプロフィール情報の標準化されたテキストレコードを保存できます。これにより、ENS名は正典的で機械可読な名刺になります。サポート、マーケティング、エンジニアリングツールはすべて同じ検証済みソースから取得でき、一貫性を確保し、ユーザーとの信頼を構築できます。

2つの入り口：.eth vs. "独自DNSを持参"​

ENSの開始は柔軟で、一緒に使用できる（そして使用すべき）2つの主要なパスを提供します。

1. brand.ethを登録​

これはweb3ネイティブなアプローチです。.eth名を登録すると、ブランドのエコシステムへのコミットメントを示すクリプト・ネイティブ資産が得られます。プロセスは直接的で透明です。

• 明確な料金スケジュール： スクワッティングを防ぎプロトコルに資金を提供するため、料金はETHで年間支払われます。価格は希少性に基づきます：5文字以上の名前はわずか年5ドル、4文字の名前は年160ドル、3文字の名前は年640ドルです。
• プライマリ名の設定： brand.ethを所有したら、会社のメインウォレットの「プライマリ名」（リバースレコードとも呼ばれる）として設定する必要があります。これは、ウォレットとdappsが長いアドレスの代わりに記憶しやすい名前を表示できる重要なステップで、ユーザーエクスペリエンスと信頼を大幅に向上させます。

2. ENS内でbrand.comを強化（移行不要）​

貴重なweb2ドメインを放棄する必要はありません。ガス不要DNSSECという機能のおかげで、既存のDNSドメインを暗号ウォレットにリンクし、完全に機能するENS名に効果的にアップグレードできます。

• オーナーにとってゼロ・オンチェーン・コスト： このプロセスにより、brand.comはドメイン所有者がオンチェーン取引を送信することなく、ENSエコシステム内で解決可能になります。
• メインストリーム・レジストラー・サポート： GoDaddyは既にこのENS機能を使用したワンクリック「Crypto Wallet」レコードでこれを合理化しています。DNSSECをサポートする他の主要レジストラーもENSと連携するよう設定できます。

実用的なアドバイス： 両方を実行してください。web3ネイティブオーディエンスと財務業務にはbrand.ethを使用します。同時に、ブランドフットプリント全体を統一し、既存のユーザーベースにシームレスな橋渡しを提供するため、brand.comをENSに持参します。

ゼロから1への展開：1週間計画​

ENSの展開は複数四半期のプロジェクトである必要はありません。集中したチームは約1週間で堅実なプレゼンスを確立できます。

• 1〜2日目：名前とポリシー brand.ethを取得し、ガス不要DNSSEC方法を使用して既存のDNS名をリンクします。これは、正典的なスペル、絵文字の使用、正規化ルールについての内部ポリシーを確立する時期でもあります。ENSは名前のバリエーションを処理するためにENSIP-15と呼ばれる標準を使用しますが、ブランドに対するフィッシング攻撃を防ぐためにホモグリフ（似て見える文字）を認識することが重要です。

• 3日目：プライマリ名とウォレット 会社の財務、業務、決済ウォレットについて、treasury.brand.ethまたは類似の名前に解決されるようプライマリ名（リバースレコード）を設定します。この機会を使用して、マルチコインアドレスレコード（BTC、SOLなど）を入力し、ENS名に送信された支払いがチェーンに関係なく正しくルーティングされることを確認します。

• 4日目：プロフィールデータ プライマリENS名の標準化されたテキストレコードを入力します。最低限、email、url、com.twitter、avatarを設定します。公式アバターは、対応ウォレットで即座の視覚的検証を追加します。セキュリティ強化のため、公開PGPキーも追加できます。

• 5日目：サブ名 従業員用のalice.brand.ethや部門用のsupport.brand.comなどのサブ名の発行を開始します。NameWrapperを使用して、例えばサブ名の転送を防ぐセキュリティ「fuses」を適用します。契約終了や従業員離職時にアクセスを自動的に取り消すため、有効期限を設定します。

• 6日目：ウェブサイト/ドキュメント ウェブプレゼンスを分散化します。プレスキット、利用規約、ステータスページをIPFSやArweaveなどの分散ストレージネットワークに固定し、contenthashレコードを通じてENS名にリンクします。ユニバーサルアクセスのため、ユーザーはeth.limoなどのパブリックゲートウェイを通じてこのコンテンツを解決できます。

• 7日目：プロダクトに統合 独自のアプリケーションでENSの使用を開始します。viemとensjsなどのライブラリを使用して名前を解決し、ユーザー入力を正規化し、アバターを表示します。アドレスを検索する際は、ユーザーのプライマリ名を表示するためリバース検索を実行します。ENSv2のL2アーキテクチャに対してアプリが将来対応できるよう、CCIP-Readをサポートするリゾルバーゲートウェイを使用することを確認します。

素早く効果を発揮する一般的パターン​

設定後、ENSは即座に価値を提供する強力で実用的な使用例をアンロックします。

• より安全でシンプルな支払い： 長くエラーが起こりやすいアドレスをコピー・ペーストする代わりに、請求書にpay.brand.ethを載せます。すべてのマルチコインアドレスを1つの名前の下に公開することで、顧客が間違ったアドレスやチェーンに資金を送信するリスクを大幅に削減できます。

• 真正なサポートとソーシャルプレゼンス： ENSテキストレコードで公式ソーシャルメディアハンドルを公開します。一部のツールは既にこれらのレコードを検証でき、なりすましに対する強力な防御を作成できます。support.brand.eth名は、専用サポートウォレットや安全なメッセージングエンドポイントに直接指すことができます。

• 分散化されたウェブプレゼンス： contenthashを使用してbrand.ethに改ざん証拠のあるステータスページや重要なドキュメントをホストします。リンクがオンチェーンであるため、単一プロバイダーによって削除されることがなく、必須情報により高度な回復力を提供します。

• プログラマブルな組織図： 内部ツールやトークンゲート化チャネルへのアクセスを付与するemployee.brand.ethサブ名を発行します。NameWrapper fusesと有効期限により、組織全体の動的、プログラマブル、自動取り消し可能なアイデンティティシステムを作成できます。

• ガス軽量ユーザーエクスペリエンス： ロイヤリティIDやチケットをサブ名として発行するなどの大量使用例では、オンチェーン取引は遅すぎて高価です。CCIP-Readを使用したオフチェーンリゾルバーを使用します。この標準により、ENS名をL2や従来のデータベースからでも信頼最小化された方法で解決できます。Uniswap（uni.eth）やCoinbase（cb.id）などの業界リーダーは、既にこのパターンを使用してユーザーアイデンティティシステムをスケールしています。

スキップすべきではないセキュリティとガバナンス​

プライマリENS名をプライマリドメイン名のように扱ってください：重要な会社インフラの一部として。

• 「オーナー」と「マネージャー」の分離： これは中核的なセキュリティ原則です。名前を転送する権限を持つ「オーナー」役割は、コールドストレージマルチシグウォレットで保護されるべきです。IPアドレスやアバターなどの日常的なレコードを更新できる「マネージャー」役割は、よりアクセスしやすいホットウォレットに委任できます。この権限分離により、鍵が侵害された場合の爆発半径を大幅に削減できます。

• NameWrapper保護の使用： サブ名を発行する際、CANNOT_TRANSFERなどのfusesをバーンして特定の従業員にロックしたり、CANNOT_UNWRAPでガバナンスポリシーを強制したりするためNameWrapperを使用します。すべての権限は制御する有効期限によって管理され、デフォルトで時限アクセスを提供します。

• 更新の監視： 支払い漏れで.eth名を失わないでください。更新日をカレンダー化し、.eth名には90日の猶予期間があるが、サブ名のポリシーは完全にあなた次第であることを覚えておいてください。

開発者クイックスタート（TypeScript）​

viemなどの現代的ライブラリを使用して、アプリにENS解決を統合するのは簡単です。このスニペットは、名前からアドレスまたはアドレスから名前を検索する方法を示しています。

import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";
import { normalize, getEnsAddress, getEnsName, getEnsAvatar } from "viem/ens";

const client = createPublicClient({ chain: mainnet, transport: http() });

export async function lookup(nameOrAddress: string) {
  if (nameOrAddress.endsWith(".eth") || nameOrAddress.includes(".")) {
    // 名前 → アドレス（ENSIP-15に従って入力を正規化）
    const name = normalize(nameOrAddress);
    const address = await getEnsAddress(client, {
      name,
      gatewayUrls: ["https://ccip.ens.xyz"],
    });
    const avatar = await getEnsAvatar(client, { name });
    return { type: "name", name, address, avatar };
  } else {
    // アドレス → プライマリ名（リバースレコード）
    const name = await getEnsName(client, {
      address: nameOrAddress as `0x${string}`,
      gatewayUrls: ["https://ccip.ens.xyz"],
    });
    return { type: "address", address: nameOrAddress, name };
  }
}

このコードからの2つの重要なポイント：

• normalizeはセキュリティにとって不可欠です。ENS命名ルールを実施し、似た名前からの一般的なフィッシングやスプーフィング攻撃を防ぐのに役立ちます。
• gatewayUrlsはCCIP-Readをサポートするユニバーサルリゾルバーを指します。これにより、統合がL2とオフチェーンデータへの今後の移行と前方互換性を持ちます。

Reactで構築する開発者には、ENSjsライブラリがこれらの一般的なフローをラップする高レベルフックとコンポーネントを提供し、統合をさらに高速化します。

名前の選択と保護：ブランドと法的側面​

• 正規化と使いやすさ： ENSIP-15正規化に慣れ親しんでください。絵文字や非ASCII文字の使用について明確な内部ガイドラインを設定し、ブランドのなりすましに使用される可能性のある「紛らわしい」文字を積極的にスクリーニングします。
• 商標の現実確認： .eth名は従来のICANNフレームワークとそのUDRP紛争解決プロセスの外で動作します。商標所有者はDNSドメインで使用するのと同じ法的レールに依存できません。したがって、重要なブランド用語の防御的登録は慎重な戦略です。（これは法的アドバイスではありません。法律顧問に相談してください。）

次の展開：ENSv2とL2への移行​

ENSプロトコルは静的ではありません。次の主要な進化であるENSv2が進行中です。

• L2へのプロトコル移行： ガス費用を削減し速度を向上させるため、コアENSレジストリがLayer 2ネットワークに移行されます。名前解決はCCIP-Readと暗号学的証明システムを通じてL1と他のチェーンにブリッジされます。これにより、名前の登録と管理が大幅に安価になり、より豊かなアプリケーションパターンがアンロックされます。
• シームレス移行計画： ENS DAOは、既存の名前を最小限の摩擦で新しいシステムに移行できるよう詳細な移行計画を公開しました。大規模で運営している場合、これは追跡すべき重要な開発です。

実装チェックリスト​

チームの実装をガイドするためにこのチェックリストを使用してください。

• brand.ethを取得；ガス不要DNSSECを通じてbrand.comをリンク。
• 安全なマルチシグで名前の所有権を駐車；マネージャー役割を委任。
• すべての組織ウォレットでプライマリ名を設定。
• 支払い用マルチコインアドレスを公開。
• テキストレコード（メール、URL、ソーシャル、アバター）を入力。
• fusesと有効期限を使用してチーム、従業員、サービス用のサブ名を発行。
• 最小限の分散サイト（例：ステータスページ）をホストし、contenthashを設定。
• プロダクトにENS解決（viem/ensjs）を統合；すべての入力を正規化。
• すべての.eth名更新日をカレンダー化し、有効期限を監視。

ENSはビジネスの準備ができています。シンプルな命名システムを超えて、インターネットの次世代を構築する企業にとって重要なインフラの一部になりました。プログラマブルで持続的なアイデンティティを確立することで、リスクを下げ、よりスムーズなユーザーエクスペリエンスを作成し、分散化された未来に対してブランドの準備を確実にできます。

最大抽出可能価値（MEV）は単なるトレーダーのお化けではありません—ブロックの構築方法、ウォレットの注文ルーティング方法、そしてプロトコルの市場設計方法を静かに形作る経済エンジンです。これは創業者、エンジニア、トレーダー、バリデーターのための実践的ガイドです。

TL;DR​

• MEVとは何か: ブロックプロデューサー（バリデーター/シーケンサー）またはそのパートナーが基本報酬とガスを超えてトランザクションを並び替え、挿入、または除外することで抽出できる追加価値。
• なぜ存在するか: パブリックメンプール、決定論的実行、トランザクション順序依存性（例：AMMスリッページ）が利益のある順序ゲームを作成。
• 現代のMEVの仕組み: サプライチェーン—ウォレット＆オーダーフロー オークション → searcher → builder → relay → proposer—プロポーザー・ビルダー分離（PBS）とMEV-Boostによって正式化。
• 今日のユーザー保護: プライベートトランザクション送信と**オーダーフローオークション（OFA）**がサンドイッチリスクを軽減し、価格改善をユーザーと共有できる。
• 次に来るもの（2025年9月時点）: 制度化PBS、包含リスト、MEV-burn、SUAVE、L2向け共有シーケンサー—すべて公平性と耐性を目指している。

5分間のメンタルモデル​

ブロックスペースをEthereumで12秒ごとに販売される希少なリソースと考えてください。トランザクションを送信すると、メンプールと呼ばれるパブリックな待機エリアに着地します。一部のトランザクション、特にDEXスワップ、清算、アービトラージ機会には順序依存ペイオフがあります。その結果と収益性は、他のトランザクションとの関係でブロック内のどこに着地するかによって変わります。これは順序を制御する者にとって高リスクゲームを作成します。

このゲームからの最大潜在利益が**最大抽出可能価値（MEV）**です。きれいで規範的な定義は：

"トランザクションを含める、除外する、順序を変更することで、標準ブロック報酬とガス料金を超えてブロック生産から抽出可能な最大価値。"

この現象は2019年の学術論文「Flash Boys 2.0」で初めて正式化され、混沌とした「優先ガスオークション」（ボットがトランザクションを最初に含めるためにガス料金を競り上げる）を記録し、これがコンセンサス安定性にもたらすリスクを強調しました。

クイック分類法（例付き）​

MEVは単一の活動ではなく、戦略のカテゴリです。最も一般的なものは以下です：

• DEXアービトラージ（バックランニング）: Uniswapでの大きなスワップがETHの価格をCurveでの価格と比べて下げるとしましょう。アービトラージャーはUniswapで安いETHを買い、Curveで売って即座に利益を得ることができます。これは価格移動トランザクションの後に即座に起こるため「バックラン」です。この形のMEVは、市場間で価格の一貫性を保つのに役立つため、一般的に有益と考えられています。

• サンドイッチング: これは最も悪名高く直接的に有害なMEVの形です。攻撃者がメンプールでユーザーの大きな買い注文を発見します。彼らはユーザーより先に同じアセットを買うことでフロントランし、価格を押し上げます。犠牲者の取引はこのより悪い、より高い価格で実行されます。攻撃者はその後すぐにアセットを売ることで犠牲者をバックランし、価格差をキャプチャします。これはユーザーの指定スリッページ許容度を悪用します。

• 清算: AaveやCompoundのような貸出プロトコルでは、担保価値が下がると位置が担保不足になります。これらのプロトコルは誰が最初に位置を清算するかにボーナスを提供します。これはボットの間で清算機能を最初に呼び出し、報酬を請求する競争を作成します。

• NFTミント「ガス戦争」（レガシーパターン）: 人気の高いNFTミントでは、限定供給トークンを確保するための競争が始まります。ボットはブロック内の最初のスロットを激しく競い、しばしばネットワーク全体のガス価格を天文学的なレベルまで競り上げます。

• クロスドメインMEV: 活動がLayer 1、Layer 2、異なるロールアップ間で断片化するにつれ、これらの孤立した環境間の価格差から利益を得る機会が生まれます。これは急速に成長し複雑なMEV抽出分野です。

現代のMEVサプライチェーン（ポストマージ）​

マージ前、マイナーがトランザクション順序を制御していました。今はバリデーターがします。バリデーターが過度に中央集権化し専門化することを防ぐため、Ethereumコミュニティは**プロポーザー・ビルダー分離（PBS）**を開発しました。この原則は、チェーンへのブロック提案の仕事と、最も利益の高いブロックを構築する複雑な仕事を分離します。

実際、今日のほとんどのバリデーターはMEV-Boostと呼ばれるミドルウェアを使用しています。このソフトウェアにより、競争市場へのブロック構築を外注できます。高レベルフローは以下のようになります：

1. ユーザー/ウォレット: ユーザーがトランザクションを開始し、パブリックメンプールまたは保護を提供するプライベートRPCエンドポイントに送信します。
2. Searcher/Solver: これらはMEV機会を常にモニターする洗練されたアクターです。価値をキャプチャするためにトランザクションの「バンドル」（例：フロントラン、犠牲者の取引、バックラン）を作成します。
3. Builder: これらは可能な限り最も利益の高いブロックを構築するため、searcherからのバンドルと他のトランザクションを集約する高度に専門化されたエンティティです。最も価値の高いブロックを作成するために互いに競争します。
4. Relay: これらは信頼できる仲介者として機能します。Builderは自分のブロックをrelayに送信し、relayはそれらの妥当性をチェックし、署名されるまでproposerからコンテンツを隠します。これによりproposerがbuilderの努力を盗むことを防ぎます。
5. Proposer/Validator: MEV-Boostを実行するバリデーターは複数のrelayをクエリし、提供された最も利益の高いブロックヘッダーを選択するだけです。コンテンツを見ることなく盲目的に署名し、勝利したbuilderからの支払いを受け取ります。

PBSはブロック構築へのアクセスを広げることに成功していますが、少数の高性能builderとrelayの間での中央集権化も引き起こしています。最近の研究では、少数のbuilderがEthereumのブロックの大部分を生産していることが示されており、これはネットワークの長期的な分散化と検閲耐性にとって継続的な懸念です。

なぜMEVが有害になり得るか​

• 直接的ユーザーコスト: サンドイッチ攻撃や他の形のフロントランニングはユーザーにとってより悪い執行品質をもたらします。アセットにより多く支払うか、受け取るべき額より少なく受け取り、差額がsearcherにキャプチャされます。
• コンセンサスリスク: 極端なケースでは、MEVはブロックチェーン自体の安定性を脅かす可能性があります。マージ前、「タイムバンディット」攻撃は理論的懸念で、マイナーが過去のMEV機会をキャプチャするためブロックチェーンを再組織するインセンティブを持つ可能性があり、ファイナリティを損なう。
• 市場構造リスク: MEVサプライチェーンは強力な既存事業者を作成する可能性があります。ウォレットとbuilderの間の排他的オーダーフロー取引は、ユーザートランザクションのペイウォールを作成し、builder/relayオリガルキーを固定化し、中立性と検閲耐性の中核原則を脅かす可能性があります。

今日実際に機能するもの（実践的軽減策）​

有害なMEVに対して無力ではありません。ユーザーを保護しエコシステムを整合させるためのツールとベストプラクティスのスイートが登場しています。

ユーザーとトレーダーのために​

• プライベート送信パスを使用: Flashbots ProtectなどのサービスはあなたのウォレットのためにRPCエンドポイント「protect」を提供します。それを通じてトランザクションを送信することで、パブリックメンプールから除外され、サンドイッチボットには見えなくなります。一部のサービスでは、取引から抽出されたMEVの一部をあなたに還元することさえできます。
• OFAバックアップルーターを好む: オーダーフローオークション（OFA）は強力な防御です。スワップをメンプールに送る代わりに、CoW SwapやUniswapXのようなルーターはあなたの意図を競争的なsolverマーケットプレイスに送ります。これらのsolverは可能な限り最高の価格を提供するために競争し、効果的に任意の潜在的MEVを価格改善としてあなたに返します。
• スリッページを調整: 非流動的ペアでは、サンドイッチ攻撃者が抽出できる最大利益を制限するため、手動で低いスリッページ許容度（例：0.1%）を設定します。大きな取引を小さなチャンクに分割することも役立ちます。

ウォレットとDappのために​

• OFAを統合: デフォルトで、ユーザートランザクションをオーダーフローオークションを通してルーティングします。これはユーザーをサンドイッチ攻撃から保護し、優れた実行品質を提供する最も効果的な方法です。
• プライベートRPCをデフォルトとして提供: 保護されたRPCをウォレットやdappでのデフォルト設定にします。パワーユーザーがbuilderとrelayの好みを構成し、プライバシーと包含速度のトレードオフを微調整できるようにします。
• 実行品質を測定: ルーティングが最適だと単純に仮定しないでください。パブリックメンプールルーティングに対して実行をベンチマークし、OFAとプライベート送信から得られた価格改善を定量化します。

バリデーターのために​

• MEV-Boostを実行: ステーキング報酬を最大化するためPBS市場に参加します。
• 多様化: 単一のプロバイダーへの依存を避け、ネットワークの耐性を高めるため、多様なrelayとbuilderのセットに接続します。よく接続されていることを確認するため、報酬とブロック包含率をモニターします。

L2とSEV（シーケンサー抽出可能価値）の台頭​

Layer 2ロールアップはMEVを排除しません；単にその名前を変更するだけです。ロールアップはシーケンサーと呼ばれる単一のエンティティに順序権力を集中させ、**シーケンサー抽出可能価値（SEV）**を作成します。実証研究では、MEVがL2で広く見られることを示していますが、L1よりも利益マージンが低いことが多いです。

ロールアップごとの単一シーケンサーの中央集権化リスクを戦うため、共有シーケンサーなどの概念が登場しています。これらは複数のロールアップが単一の、中立的なエンティティをトランザクション順序のために共有できるようにする分散化されたマーケットプレイスで、クロスロールアップMEVをより公平に仲裁することを目指しています。

次に来るもの（そしてなぜ重要か）​

MEVを飼いならす作業はまだ終わっていません。いくつかの重要なプロトコルレベルのアップグレードが地平線にあります：

• 制度化PBS（ePBS）: これはプロポーザー・ビルダー分離をEthereumプロトコル自体に直接移すことを目指し、信頼された中央集権化されたrelayへの依存を減らし、ネットワークのセキュリティ保証を強化します。
• 包含リスト（EIP-7547）: この提案はproposerにbuilderに特定のトランザクションセットを強制的に含めさせる方法を提供します。これは検閲と戦う強力なツールで、低い料金のトランザクションでも最終的にチェーンに載ることを保証します。
• MEV-Burn: EIP-1559がベースガス料金の一部を燃やすのと同様に、MEV-burnはbuilder支払いの一部を燃やすことを提案します。これはMEV収益のスパイクを平滑化し、不安定化行動のインセンティブを減らし、すべてのETH保有者に価値を再分配します。
• SUAVE（価値表現のための単一統合オークション）: Flashbotsによるプロジェクトで、オーダーフローのための分散化され、プライバシーを保護するオークション層を作成します。目標は、ブロック構築のためのよりオープンで公平な市場を作成し、排他的で中央集権化された取引への傾向と戦うことです。
• OFA標準化: オークションが標準になるにつれ、異なるルーターが提供する価格改善を定量化し比較するための正式なメトリクスとオープンツールを作成する作業が進行中で、エコシステム全体の実行品質の基準を上げています。

創業者のチェックリスト（MEV対応製品を出荷）​

• デフォルトでプライバシー: ユーザーフローをプライベート送信または暗号化された意図ベースシステムを通してルートします。
• 競争のためのデザイン、競争のためではない: 遅延ゲームを作る「先着順」メカニクスを避けます。公平で効率的な市場を作るためバッチオークションやOFAを活用します。
• すべてを計器化: スリッページ、効果的価格対オラクル価格、ルーティング決定の機会コストを記録します。実行品質についてユーザーに透明であること。
• 依存関係を多様化: 今日は複数のbuilderとrelayに依存します。明日の制度化PBSへの移行のためインフラを準備します。
• L2の計画: マルチチェーンアプリケーションを構築する場合は、設計でSEVとクロスドメインMEVを考慮します。

開発者FAQ​

• MEVは「悪い」または「違法」ですか？ MEVはオープンで決定論的なブロックチェーン市場の避けられない副産物です。アービトラージや清算などの一部の形は市場効率に必須です。サンドイッチングなどの他の形は純粋に抽出的でユーザーに有害です。目標はMEVを排除することではなく、害を最小化し、抽出をユーザー利益とネットワークセキュリティに合わせるメカニズムを設計することです。その法的地位は複雑で管轄によって異なります。

• プライベートトランザクション送信はサンドイッチがないことを保証しますか？ ほとんどのボットが見ているパブリックメンプールからトランザクションを除外することで大幅に露出を減らします。OFAと組み合わせると非常に強い防御になります。しかし、完璧なシステムはなく、保証は使用する特定のプライベートrelayとbuilderのポリシーに依存します。

• なぜ単に「MEVをオフ」にしないのですか？ できません。価格非効率性のあるオンチェーン市場が存在する限り（常にそう）、それらを修正することに利益があります。完全に排除しようとすると、有用な経済機能を壊す可能性があります。より生産的なパスは、ePBS、包含リスト、MEV-burnなどのより良いメカニズム設計を通じて管理し再分配することです。

さらなる読書​

• 標準的定義と概要: Ethereum.org—MEVドキュメント
• 起源とリスク: Flash Boys 2.0 (Daian et al., 2019)
• PBS/MEV-Boostプライマー: Flashbotsドキュメントと「MEV-Boost in a Nutshell」
• OFA研究: Uniswap Labs—「Quantifying Price Improvement in Order Flow Auctions」
• ePBSとMEV-burn: Ethereum Researchフォーラムディスカッション
• L2 MEV証拠: 主要ロールアップ全体の実証分析（例：「Analyzing the Extraction of MEV Across Layer-2 Rollups」）

最終的に​

MEVはバグではありません；ブロックチェーンに内在するインセンティブ勾配です。勝利するアプローチは否定ではありません—メカニズム設計です。目標は価値抽出を競争可能で透明で、ユーザーに合わせられたものにすることです。構築している場合は、この認識を初日から製品に焼き込みます。取引している場合は、ツールがそれをしてくれることを要求します。エコシステムはこのより成熟した耐性のある未来に急速に収束しています—今がそれに向けて設計する時です。

Sui ブロックチェーンは、スケーラビリティとパフォーマンスに対する革新的なアプローチで急速に注目を集めています。Sui ノードを安定して運用したい開発者やインフラチーム向けに、Mysten Labs はネットワーク信頼性エンジニアリング（NRE）ツールの包括的なセットを提供し、デプロイ、設定、管理プロセスを効率化します。

本ガイドでは、Sui NRE リポジトリ を紹介し、これらの強力なツールを Sui ノード運用に活用する方法を解説します。

引き出し、ガス調整、そしてその後の展開—誇大広告なしで。

短縮版​

Shapellaアップグレード（実行レイヤーの上海とコンセンサスレイヤーのCapellaのかばん語）は、2023年4月12日にEthereumで稼働しました。そのランドマーク機能は、Beacon Chainの開始以来初めてステーキング引き出しを可能にすることでした。

ヘッドライン変更であるEIP-4895は、バリデーターの引き出しがコンセンサスレイヤーから実行レイヤーに自動的に「プッシュ」されるシステムを導入し、ユーザートランザクションやガス手数料を必要としません。これと併せて、4つの小さなEIPがEVMの微調整を行い、ガスコスト削減（Warm COINBASE）、バイトコード最適化（PUSH0）、およびコントラクト作成制限（Initcode metering）が含まれています。アップグレードは、SELFDESTRUCTオペコードが段階的に廃止されることを開発者に最終警告する役割も果たしました。

ShapellaはMergeのサイクルを効果的に完了し、次の主要なアップグレードであるDencunは2024年3月13日に続き、EIP-4844「blob」によりネットワークの焦点をスケーラビリティに移しました。

なぜShapellaが重要なマイルストーンだったのか​

Beacon Chainの開始から2023年4月まで、ETHをステーキングすることは一方通行でした。32 ETHを預けてネットワークを保護し報酬を得ることはできましたが、元本やそれらのコンセンサスレイヤー報酬を引き出すことはできませんでした。このロックされた流動性は重大なコミットメントであり、多くの潜在的なステーカーにとって障壁でした。

Shapellaは出口ドアを開くことによってすべてを変えました。

アップグレードの核心はEIP-4895で、巧妙に設計された**システムレベルの「引き出し操作」**でした。ステーカーがトランザクションを作成してガスを支払って引き出しを行う代わりに、プロトコル自体がコンセンサスレイヤーから適格な資金を自動的にスイープし、実行レイヤーにプッシュするようになりました。この清潔なプッシュベースの設計は複雑さとリスクを最小化し、変更のテストと安全な展開を大幅に容易にしました。

実際に変更されたもの：平易な日本語でのEIP​

Shapellaは5つの主要なEthereum改善提案（EIP）のバンドルでした：

• EIP-4895 — Beacon Chain引き出し（プッシュベース） これがメインイベントでした。部分的（報酬）および完全（元本+報酬）引き出しの両方を、コンセンサスレイヤーからステーカーの指定された引き出しアドレスに流すことを可能にしました。重要なイノベーションは、これらがユーザー開始のトランザクションではないことです；提案されたブロックに埋め込まれた自動操作です。

• EIP-3651 — "Warm COINBASE" このEIPは小さいながらも重要なガス最適化を行いました。EVMでは、COINBASEはブロック生産者（バリデーター）のアドレスを指し、取引所ではありません。Shapella以前、スマートコントラクトがトランザクション内でこのアドレスに最初にアクセスする際、より高いガスコストが発生していました。EIP-3651はCOINBASEアドレスをデフォルトで「warm」にし、MEVチップをブロックビルダーに直接支払うプロトコルなど、頻繁にこれとやり取りするプロトコルのガスコストを削減しました。

• EIP-3855 — PUSH0オペコード EVMへの簡潔で洗練された追加。この新しいオペコードPUSH0は、その名前の通り：値ゼロをスタックにプッシュします。以前、開発者はこれを達成するためにより重く高価なオペコードを使用する必要がありました。PUSH0はバイトコードを若干小さく、よりガス効率的にし、特に変数をゼロに初期化する多数のコントラクトにとって有益です。

• EIP-3860 — initcodeの制限と測定 この変更は、スマートコントラクトを作成するために使用されるコード（initcode）に2つのルールを導入しました。第一に、initcodeの最大サイズを49,152バイトに制限しました。第二に、このコードの32バイトチャンクごとに小さなガス手数料を追加しました。これは過度に大きなコントラクトを含むサービス拒否攻撃を防ぎ、コントラクト作成コストをより予測可能にします。

• EIP-6049 — SELFDESTRUCTの非推奨（警告） これはコード変更ではなく、開発者コミュニティへの正式な警告でした。コントラクトが自身を削除し、そのETHをターゲットアドレスに送信することを可能にするSELFDESTRUCTオペコードが、将来のアップグレードで機能が大幅に変更されることを示しました。これにより、開発者はDencunアップグレードがEIP-6780でその動作を後に変更する前に、それへの依存を段階的に廃止する時間を得ました。

引き出し101：部分的 vs. 完全​

Shapellaは2種類の自動引き出しを導入し、それぞれに独自のルールがありました。

• 部分引き出し これらは自動報酬スイープです。バリデーターの残高がコンセンサスレイヤー報酬により32 ETHを超えて成長する場合、プロトコルは自動的に超過分を「スキミング」し、指定された引き出しアドレスに送信します。バリデーターはアクティブのままで、その職務を継続します。これはステーカーからのアクションを必要とせずに発生します。

• 完全引き出し（退出） これは、検証を停止し全残高を回収したいステーカー向けです。ステーカーは最初に自発的退出メッセージをブロードキャストする必要があります。待機期間後、バリデーターは完全引き出しの資格を得ます。スイープで処理されると、全残高が引き出しアドレスに送信され、バリデーターはもはやアクティブセットの一部ではありません。

スループットとケイデンス​

ネットワークは不安定性を引き起こすことなく引き出しをスムーズに処理するよう設計されています。

• 各ブロック（12秒ごと）に最大16の引き出しを含めることができ、1日あたり約115,200の引き出しの最大値を可能にします。
• ブロック提案者はアクティブバリデーターのリストをスキャンし、最初の16の適格な引き出しを含めます。次のブロック提案者は最後の提案者が終了したところから続行し、すべてのバリデーターがキューで順番を得ることを保証します。
• ネットワークを不安定化させる大規模な脱出を防ぐため、エポックごと（約6.4分ごと）に退出できるバリデーターの数はチャーン制限により制限されています。この制限は、アクティブバリデーターの総数に基づいて動的で、退出波を平滑化します。

コンセンサスレイヤー報酬はこのEIP-4895引き出しメカニズムによって処理される一方、実行レイヤー報酬（優先手数料とMEV）はバリデーターの設定された手数料受取人アドレスに直接送信され、即座に利用可能であることも重要です。

その後の展開：Dencunとスケーラビリティへの道​

Shapellaは「Merge時代」の成功した完了を記録しました。ステーキングが完全に流動的な双方向プロセスになったことで、開発者はEthereumの次の大きな課題に注意を向けました：スケーラビリティ。

次の主要なアップグレードであるDencun（Deneb + Cancun）は、2024年3月13日に到着しました。その中心はLayer 2ロールアップがEthereumメインネットにトランザクションデータを投稿するための新しい、より安価な方法である「blob」を導入したEIP-4844でした。これによりL2のトランザクション手数料が劇的に下がり、ロールアップ中心のロードマップにおける大きな前進となりました。DencunはまたEIP-6049の約束を果たし、SELFDESTRUCTオペコードの力を大幅に制限したEIP-6780を実装しました。

大きな図​

ShapellaはEthereumのProof-of-Stakeコンセンサスにとって不可欠な信頼のマイルストーンでした。引き出しを可能にすることで、ステーキングのリスクを軽減し、流動性を回復し、複雑で協調されたアップグレードを実行するネットワークの能力を確認しました。また、技術的負債を清算し、将来の最適化への道を舗装した実用的なEVM改善も提供しました。

要するに、Shapellaはステーカーのための出口ドアを開いただけでなく—Post-Merge時代の基盤を固め、Ethereumが次のフロンティア：大規模スケーラビリティに焦点を当てるための滑走路をクリアしました。