"blockchain" 태그로 연결된 6개 게시물개의 게시물이 있습니다.

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를 기존 제품군에 깊이 통합하여 개발자에게 두 가지 통합 경로를 제공할 계획입니다. 첫 번째는 직접 온체인 개발로, Web3 개발자가 익숙한 툴체인을 사용하여 Tempo에 직접 스마트 컨트랙트를 배포합니다. 두 번째는 Stripe의 고수준 API를 통한 통합으로, 블록체인의 복잡성을 완전히 추상화합니다. 예를 들어, Stripe의 Bridge 플랫폼(크로스체인 스테이블코인 플로우용 도구)은 미래에 Tempo를 핵심 정산 레일 중 하나로 사용할 것입니다. 개발자는 익숙한 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의 강력한 지원은 개발자 경험과 기술적 발전에 대한 높은 헌신을 시사합니다. 기존 리소스를 적극적으로 활용하고, 커뮤니티에 참여하며, 관련 이벤트에 참여함으로써, 개발자들은 실제 결제 문제 해결에 초점을 맞춘 블록체인 네트워크에서 귀중한 초기 단계 기회를 포착할 수 있습니다.

2025년 5월 7일, 이더리움의 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 트랜잭션을 스스로 제출할 수도 있고, 제3자 릴레이어가 EOA를 대신하여 제출할 수도 있습니다. 후자는 가스없는 사용자 경험을 만드는 데 일반적입니다. 논스 처리는 방법에 따라 약간 다르므로, 이 구별을 올바르게 관리하는 라이브러리를 사용하는 것이 중요합니다.

보안 모델 변경: 원래 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. 릴레이어가 EOA의 코드를 설정하고 initialize() 호출하기 위해 타입-4 트랜잭션을 보냄
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)와 일치하는지 확인하여 변경을 검증합니다.

위협 모델 및 주의사항 (이것을 건너뛰지 마세요)​

• 위임은 지속적입니다: EOA의 구현 컨트랙트 변경을 표준 스마트 컨트랙트 업그레이드와 같은 심각성으로 다루세요. 이는 감사, 명확한 사용자 커뮤니케이션, 이상적으로는 옵트인 플로우를 필요로 합니다. 사용자에게 조용히 새로운 로직을 푸시하지 마세요.
• tx.origin 지뢰: msg.sender == tx.origin을 사용하여 호출이 EOA에서 직접 왔는지 확인하는 로직은 이제 잠재적으로 취약합니다. 이 패턴은 EIP-712 서명이나 명시적 허용 목록과 같은 더 견고한 검사로 대체되어야 합니다.
• 논스 수학: EOA가 자체 7702 트랜잭션을 후원하는 경우(executor: 'self'), 인증 논스와 트랜잭션 논스가 특정한 방식으로 상호작용합니다. 재생 문제를 피하기 위해 이를 올바르게 처리하는 라이브러리를 항상 사용하세요.
• 지갑 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 함수 테스트.
• 셀프 스폰서 및 릴레이 트랜잭션 경로 모두 논스와 재생을 올바르게 처리하는지 확인.

보안​

• 컨트랙트에서 tx.origin에 기반한 모든 가정을 제거하고 더 안전한 대안으로 교체.
• 사용자 주소에서 예상치 못한 코드 변경을 감지하고 의심스러운 활동에 대해 알려주는 배포 후 모니터링 구현.

결론: EIP-7702는 이미 사용 중인 수백만 개의 EOA에 대한 스마트 계정 UX로의 저마찰 진입로를 제공합니다. 작고 감사된 구현으로 시작하고, 가스리스 설정을 위해 릴레이 경로를 사용하며, 취소를 명확하고 쉽게 만들면, 전체 계정 추상화의 90% 이익을 제공할 수 있습니다—주소 변경과 자산 마이그레이션의 고통 없이.

수년 동안 이더리움 네임 서비스(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 "퓨즈"와 만료에 의해 시간 제한되고 제약된 역할, 혜택 및 액세스를 발행할 수 있습니다.
• 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 이름을 표준적이고 기계 판독 가능한 명함으로 전환합니다. 지원, 마케팅 및 엔지니어링 도구 모두 동일한 검증된 소스에서 가져올 수 있어 일관성을 보장하고 사용자와의 신뢰를 구축합니다.

두 가지 진입로: .eth vs. "자신의 DNS 가져오기"​

ENS 시작은 유연하며, 함께 사용할 수 있고 사용해야 하는 두 가지 주요 경로를 제공합니다.

1. brand.eth 등록​

이것은 web3 네이티브 접근 방식입니다. .eth 이름을 등록하면 생태계에 대한 브랜드의 헌신을 신호하는 암호 네이티브 자산을 얻게 됩니다. 프로세스는 직접적이고 투명합니다.

• 명확한 수수료 일정: 스쿼팅을 방지하고 프로토콜에 자금을 지원하기 위해 수수료는 ETH로 매년 지불됩니다. 가격은 희소성에 기반합니다: 5자 이상 이름은 연간 단 5달러, 4자 이름은 연간 160달러, 3자 이름은 연간 640달러입니다.
• 기본 이름 설정: brand.eth를 소유하면 회사의 메인 지갑에 대한 "기본 이름"(역방향 레코드라고도 함)으로 설정해야 합니다. 이는 지갑과 dapp이 긴 주소 대신 기억하기 쉬운 이름을 표시할 수 있게 하는 중요한 단계로, 사용자 경험과 신뢰를 극적으로 향상시킵니다.

2. ENS 내에서 brand.com 향상 (마이그레이션 불필요)​

가치 있는 web2 도메인을 포기할 필요가 없습니다. 가스리스 DNSSEC라는 기능 덕분에 기존 DNS 도메인을 암호 지갑에 연결하여 완전히 기능하는 ENS 이름으로 효과적으로 업그레이드할 수 있습니다.

• 소유자를 위한 제로 온체인 비용: 이 프로세스는 도메인 소유자가 온체인 트랜잭션을 제출하지 않고도 brand.com이 ENS 생태계 내에서 해결 가능하게 만듭니다.
• 주류 레지스트라 지원: GoDaddy는 이미 이 ENS 기능으로 구동되는 원클릭 "Crypto Wallet" 레코드로 이를 간소화했습니다. DNSSEC를 지원하는 다른 주요 레지스트라도 ENS와 작동하도록 구성할 수 있습니다.

실용적 조언: 둘 다 하세요. web3 네이티브 청중과 재무부 운영에는 brand.eth를 사용하세요. 동시에 전체 브랜드 발자국을 통합하고 기존 사용자 베이스에 원활한 브리지를 제공하기 위해 brand.com을 ENS로 가져오세요.

제로에서 원으로의 배포: 일주일 계획​

ENS 배포가 다분기 프로젝트일 필요는 없습니다. 집중된 팀은 약 일주일 안에 강력한 존재감을 확립할 수 있습니다.

• 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를 사용하여 서브네임 전송을 방지하는 등의 보안 "퓨즈"를 적용하세요. 계약이 종료되거나 직원이 떠날 때 자동으로 액세스를 취소하기 위해 만료일을 설정하세요.

• 6일차: 웹사이트/문서 웹 존재감을 탈중앙화하세요. 보도자료 키트, 서비스 약관 또는 상태 페이지를 IPFS나 Arweave와 같은 탈중앙화 저장소 네트워크에 고정하고 contenthash 레코드를 통해 ENS 이름에 연결하세요. 범용 액세스를 위해 사용자는 eth.limo와 같은 공개 게이트웨이를 통해 이 콘텐츠를 해결할 수 있습니다.

• 7일차: 제품에 통합 자체 애플리케이션에서 ENS 사용을 시작하세요. viem과 ensjs와 같은 라이브러리를 사용하여 이름을 해결하고, 사용자 입력을 정규화하며, 아바타를 표시하세요. 주소를 조회할 때 사용자의 기본 이름을 표시하기 위해 역방향 조회를 수행하세요. ENSv2의 L2 아키텍처에 대해 앱이 미래 대응되도록 CCIP-Read를 지원하는 리졸버 게이트웨이를 사용하는지 확인하세요.

빠르게 효과를 내는 일반적인 패턴​

설정되면 ENS는 즉각적인 가치를 제공하는 강력하고 실용적인 사용 사례를 잠금 해제합니다.

• 더 안전하고 간단한 결제: 길고 오류가 발생하기 쉬운 주소를 복사하고 붙여넣는 대신 청구서에 pay.brand.eth를 기재하세요. 모든 멀티코인 주소를 하나의 이름 아래 게시함으로써 고객이 잘못된 주소나 체인으로 자금을 보내는 위험을 대폭 줄일 수 있습니다.

• 진정한 지원 및 소셜 존재감: ENS 텍스트 레코드에 공식 소셜 미디어 핸들을 게시하세요. 일부 도구는 이미 이러한 레코드를 확인할 수 있어 가장 강력한 방어를 만들 수 있습니다. support.brand.eth 이름은 전용 지원 지갑이나 보안 메시징 엔드포인트를 직접 가리킬 수 있습니다.

• 탈중앙화된 웹 존재감: contenthash를 사용하여 brand.eth에 변조 방지 상태 페이지나 중요한 문서를 호스팅하세요. 링크가 온체인에 있기 때문에 단일 공급자에 의해 삭제될 수 없어 필수 정보에 대해 더 높은 수준의 복원력을 제공합니다.

• 프로그래머블 조직도: 내부 도구나 토큰 게이트 채널에 대한 액세스를 부여하는 employee.brand.eth 서브네임을 발행하세요. NameWrapper 퓨즈와 만료일로 전체 조직을 위한 동적이고 프로그래머블하며 자동으로 취소 가능한 아이덴티티 시스템을 만들 수 있습니다.

• 가스 경량 사용자 경험: 서브네임으로 충성도 ID나 티켓을 발행하는 것과 같은 대량 사용 사례의 경우 온체인 트랜잭션은 너무 느리고 비쌉니다. CCIP-Read와 함께 오프체인 리졸버를 사용하세요. 이 표준은 ENS 이름을 L2나 심지어 전통적인 데이터베이스에서도 신뢰 최소화 방식으로 해결할 수 있게 합니다. Uniswap(uni.eth) 및 Coinbase(cb.id)와 같은 업계 리더들은 이미 이 패턴을 사용하여 사용자 아이덴티티 시스템을 확장하고 있습니다.

건너뛰어서는 안 되는 보안 및 거버넌스​

주요 ENS 이름을 주요 도메인 이름을 다루듯 다루세요: 회사 인프라의 중요한 부분으로.

• "소유자"와 "관리자" 분리: 이것은 핵심 보안 원칙입니다. 이름을 전송할 권한을 가진 "소유자" 역할은 콜드 스토리지 멀티시그 지갑에서 보호되어야 합니다. IP 주소나 아바타와 같은 일상적인 레코드를 업데이트할 수 있는 "관리자" 역할은 더 접근 가능한 핫 지갑에 위임될 수 있습니다. 이러한 권한 분리는 키가 손상된 경우의 폭발 반경을 대폭 줄입니다.

• NameWrapper 보호 사용: 서브네임을 발행할 때, 특정 직원에게 잠그기 위해 CANNOT_TRANSFER와 같은 퓨즈를 태우거나 거버넌스 정책을 시행하기 위해 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 };
  }
}

이 코드에서 두 가지 핵심 사항:

• normalize는 보안에 필수적입니다. ENS 명명 규칙을 시행하고 비슷해 보이는 이름으로부터의 일반적인 피싱 및 스푸핑 공격을 방지하는 데 도움이 됩니다.
• gatewayUrls는 CCIP-Read를 지원하는 범용 리졸버를 가리킵니다. 이는 통합이 L2 및 오프체인 데이터로의 향후 이동과 호환 가능하게 만듭니다.

React로 구축하는 개발자를 위해 ENSjs 라이브러리는 이러한 일반적인 흐름을 래핑하는 상위 수준 훅과 컴포넌트를 제공하여 통합을 더욱 빠르게 만듭니다.

이름 선택 및 보호: 브랜드 및 법적 측면​

• 정규화 및 사용성: ENSIP-15 정규화에 익숙해지세요. 이모지나 비ASCII 문자 사용에 대한 명확한 내부 가이드라인을 설정하고, 브랜드를 가장하는 데 사용될 수 있는 "혼동 가능한" 문자를 적극적으로 선별하세요.
• 상표 현실 확인: .eth 이름은 전통적인 ICANN 프레임워크와 UDRP 분쟁 해결 프로세스 외부에서 운영됩니다. 상표 소유자는 DNS 도메인에 사용하는 것과 동일한 법적 기반에 의존할 수 없습니다. 따라서 주요 브랜드 용어의 방어적 등록은 신중한 전략입니다. (이것은 법적 조언이 아닙니다; 법무진과 상담하세요.)

다음 단계: ENSv2 및 L2로의 이동​

ENS 프로토콜은 정적이지 않습니다. 다음 주요 진화인 ENSv2가 진행 중입니다.

• L2로의 프로토콜 이동: 가스 비용을 줄이고 속도를 높이기 위해 핵심 ENS 레지스트리가 레이어 2 네트워크로 이전될 것입니다. 이름 해결은 CCIP-Read와 암호화 증명 시스템을 통해 L1과 다른 체인으로 연결될 것입니다. 이는 이름 등록 및 관리를 크게 저렴하게 만들어 더 풍부한 애플리케이션 패턴을 잠금 해제할 것입니다.
• 원활한 마이그레이션 계획: ENS DAO는 기존 이름이 최소한의 마찰로 새 시스템으로 이동할 수 있도록 상세한 마이그레이션 계획을 발표했습니다. 대규모로 운영하는 경우 이는 따라야 할 주요 개발 사항입니다.

구현 체크리스트​

팀의 구현을 안내하기 위해 이 체크리스트를 사용하세요.

• brand.eth 확보; 가스리스 DNSSEC를 통해 brand.com 연결.
• 안전한 멀티시그에 이름 소유권 보관; 관리자 역할 위임.
• 모든 조직 지갑에 기본 이름 설정.
• 결제용 멀티코인 주소 게시.
• 텍스트 레코드 (이메일, URL, 소셜, 아바타) 작성.
• 퓨즈와 만료를 사용하여 팀, 직원 및 서비스용 서브네임 발행.
• 최소 탈중앙화 사이트 (예: 상태 페이지) 호스팅 및 contenthash 설정.
• 제품에 ENS 해결 (viem/ensjs) 통합; 모든 입력 정규화.
• 모든 .eth 이름 갱신 날짜 캘린더 기록 및 만료 모니터링.

ENS는 비즈니스에 준비되어 있습니다. 단순한 명명 시스템을 넘어 차세대 인터넷을 위해 구축하는 모든 회사에게 중요한 인프라 요소가 되었습니다. 프로그래머블하고 지속적인 아이덴티티를 확립함으로써 위험을 줄이고, 더 부드러운 사용자 경험을 만들며, 브랜드가 탈중앙화된 미래에 준비되도록 보장합니다.

최대 추출 가능 가치(MEV)는 단순히 트레이더의 무서운 존재가 아닙니다—블록이 어떻게 구축되고, 지갑이 어떻게 주문을 라우팅하며, 프로토콜이 어떻게 시장을 설계하는지를 조용히 형성하는 경제적 엔진입니다. 다음은 창업자, 엔지니어, 트레이더, 검증자를 위한 실용적인 가이드입니다.

TL;DR​

• MEV가 무엇인가: 블록 생산자(검증자/시퀀서) 또는 그 파트너들이 기본 보상과 가스를 넘어서 트랜잭션을 재배열, 삽입, 또는 제외함으로써 추출할 수 있는 추가 가치.
• 왜 존재하는가: 공개 메모리풀, 결정론적 실행, 트랜잭션 순서 의존성(예: AMM 슬리피지)이 수익성 있는 순서 게임을 만듭니다.
• 현대 MEV의 작동 방식: 공급망—지갑 & 주문 흐름 경매 → 검색자 → 빌더 → 릴레이 → 제안자—제안자-빌더 분리(PBS)와 MEV-Boost에 의해 공식화.
• 오늘날의 사용자 보호: 프라이빗 트랜잭션 제출과 **주문 흐름 경매(OFA)**가 샌드위치 위험을 줄이고 사용자와 가격 개선을 공유할 수 있습니다.
• 앞으로 올 것들(2025년 9월 기준): 제도화된 PBS, 포함 목록, MEV-burn, SUAVE, L2용 공유 시퀀서—모든 것이 공정성과 회복력을 목표로 합니다.

5분 멘탈 모델​

블록스페이스를 이더리움에서 12초마다 판매되는 희소한 자원으로 생각해보세요. 트랜잭션을 보내면, 메모리풀이라는 공개 대기 영역에 도착합니다. 일부 트랜잭션들, 특히 DEX 스왑, 청산, 차익거래 기회는 순서 의존적 수익을 가집니다. 그들의 결과와 수익성은 다른 트랜잭션과의 관계에서 블록 내 어디에 위치하는지에 따라 변합니다. 이것은 순서를 제어하는 자에게 고위험 게임을 만듭니다.

이 게임에서 최대 잠재적 이익이 **최대 추출 가능 가치(MEV)**입니다. 깔끔하고 표준적인 정의는 다음과 같습니다:

"트랜잭션을 포함시키고, 제외하고, 순서를 변경함으로써 표준 블록 보상과 가스 수수료를 초과하여 블록 생산에서 추출 가능한 최대 가치."

이 현상은 2019년 학술 논문 "Flash Boys 2.0"에서 처음 공식화되었으며, 혼란스러운 "우선순위 가스 경매"(봇들이 자신의 트랜잭션이 먼저 포함되도록 가스 수수료를 경쟁적으로 올림)를 문서화하고 이것이 합의 안정성에 초래하는 위험을 강조했습니다.

빠른 분류법(예시 포함)​

MEV는 단일 활동이 아니라 전략의 범주입니다. 가장 일반적인 것들은 다음과 같습니다:

• DEX 차익거래(백러닝): Uniswap의 큰 스왑이 ETH 가격을 Curve의 가격 대비 떨어뜨린다고 상상해보세요. 차익거래자는 Uniswap에서 싼 ETH를 사서 Curve에서 팔아 즉석 이익을 얻을 수 있습니다. 이것은 가격 이동 트랜잭션 이후에 즉시 일어나기 때문에 "백런"입니다. 이러한 형태의 MEV는 시장 간 가격의 일관성을 유지하는 데 도움이 되므로 일반적으로 유익한 것으로 여겨집니다.

• 샌드위칭: 이것이 가장 악명높고 직접적으로 해로운 MEV 형태입니다. 공격자가 메모리풀에서 사용자의 큰 매수 주문을 발견합니다. 그들은 사용자보다 먼저 같은 자산을 사는 것으로 선행하여 가격을 올립니다. 피해자의 거래는 이 더 나쁜, 더 높은 가격에 실행됩니다. 공격자는 그 다음 즉시 자산을 파는 것으로 피해자를 후행하여 가격 차이를 포착합니다. 이것은 사용자가 지정한 슬리피지 허용치를 악용합니다.

• 청산: Aave나 Compound 같은 대출 프로토콜에서, 담보 가치가 떨어지면 포지션이 담보 부족 상태가 됩니다. 이러한 프로토콜들은 포지션을 가장 먼저 청산하는 자에게 보너스를 제공합니다. 이것은 봇들 간에 청산 함수를 가장 먼저 호출하고 보상을 청구하려는 경쟁을 만듭니다.

• NFT 민팅 "가스 전쟁"(레거시 패턴): 인기 있는 NFT 민트에서, 한정 공급 토큰을 확보하기 위한 경쟁이 시작됩니다. 봇들은 블록의 가장 이른 슬롯을 위해 치열하게 경쟁하여, 종종 전체 네트워크의 가스 가격을 천문학적 수준까지 경쟁적으로 올렸습니다.

• 크로스 도메인 MEV: 활동이 레이어 1, 레이어 2, 다른 롤업들 간에 분산되면서, 이러한 격리된 환경들 간의 가격 차이로부터 이익을 얻을 기회가 생깁니다. 이것은 빠르게 성장하고 복잡한 MEV 추출 영역입니다.

현대 MEV 공급망(포스트-머지)​

머지 이전에는 채굴자들이 트랜잭션 순서를 제어했습니다. 이제는 검증자들이 합니다. 검증자들이 과도하게 중앙집권화되고 전문화되는 것을 방지하기 위해, 이더리움 커뮤니티는 **제안자-빌더 분리(PBS)**를 개발했습니다. 이 원칙은 체인을 위해 블록을 제안하는 일과 가장 수익성 있는 블록을 구축하는 복잡한 일을 분리합니다.

실제로 오늘날 대부분의 검증자들은 MEV-Boost라고 불리는 미들웨어를 사용합니다. 이 소프트웨어는 그들이 블록 구축을 경쟁 시장에 외주할 수 있게 합니다. 고수준 플로우는 다음과 같습니다:

1. 사용자/지갑: 사용자가 트랜잭션을 시작하여, 공개 메모리풀이나 보호를 제공하는 프라이빗 RPC 엔드포인트에 전송합니다.
2. 검색자/솔버: 이들은 MEV 기회를 위해 메모리풀을 지속적으로 모니터링하는 정교한 행위자들입니다. 이 가치를 포착하기 위해 트랜잭션의 "번들"(예: 선행, 피해자의 거래, 후행)을 만듭니다.
3. 빌더: 이들은 검색자들의 번들과 다른 트랜잭션들을 집합하여 가능한 한 가장 수익성 있는 블록을 구축하는 고도로 전문화된 개체들입니다. 가장 높은 가치의 블록을 만들기 위해 서로 경쟁합니다.
4. 릴레이: 이들은 신뢰할 수 있는 중개자로 작동합니다. 빌더들은 자신의 블록을 릴레이에 제출하고, 릴레이는 유효성을 확인하고 서명될 때까지 제안자로부터 내용을 숨깁니다. 이것은 제안자가 빌더의 노고를 훔치는 것을 방지합니다.
5. 제안자/검증자: MEV-Boost를 실행하는 검증자는 여러 릴레이를 쿼리하고 제공된 가장 수익성 있는 블록 헤더를 단순히 선택합니다. 내용을 보지 않고 맹목적으로 서명하고 승리한 빌더로부터 지불금을 받습니다.

PBS가 블록 구축에 대한 접근을 성공적으로 넓혔지만, 소수의 고성능 빌더와 릴레이 간의 중앙집권화도 초래했습니다. 최근 연구들은 소수의 빌더들이 이더리움 블록의 대부분을 생산한다는 것을 보여주며, 이는 네트워크의 장기적 분권화와 검열 저항에 대한 지속적인 우려입니다.

왜 MEV가 해로울 수 있는가​

• 직접적 사용자 비용: 샌드위치 공격과 다른 형태의 선행 거래는 사용자에게 더 나쁜 실행 품질을 초래합니다. 자산에 더 많이 지불하거나 받아야 할 것보다 적게 받게 되며, 차이는 검색자에게 포착됩니다.
• 합의 위험: 극단적인 경우에, MEV는 블록체인 자체의 안정성을 위협할 수 있습니다. 머지 이전에 "시간 도적" 공격은 채굴자들이 과거의 MEV 기회를 포착하기 위해 블록체인을 재조직할 인센티브를 가질 수 있는 이론적 우려였으며, 최종성을 훼손했습니다.
• 시장 구조 위험: MEV 공급망은 강력한 기존 업체들을 만들 수 있습니다. 지갑과 빌더 간의 독점적 주문 흐름 거래는 사용자 트랜잭션에 대한 페이월을 만들고, 빌더/릴레이 과점을 고착화하며 중립성과 검열 저항의 핵심 원칙을 위협할 수 있습니다.

오늘날 실제로 작동하는 것들(실용적 완화책)​

해로운 MEV에 대해 무력하지 않습니다. 사용자를 보호하고 생태계를 정렬하기 위한 도구와 모범 사례 세트가 등장했습니다.

사용자와 트레이더를 위해​

• 프라이빗 제출 경로 사용: Flashbots Protect 같은 서비스는 지갑을 위한 "보호" RPC 엔드포인트를 제공합니다. 이를 통해 트랜잭션을 보내면 공개 메모리풀에서 제외되어 샌드위치 봇들에게 보이지 않습니다. 일부 서비스는 심지어 거래에서 추출된 MEV의 일부를 환불해줄 수 있습니다.
• OFA 지원 라우터 선호: 주문 흐름 경매(OFA)는 강력한 방어책입니다. 스왑을 메모리풀에 보내는 대신, CoW Swap이나 UniswapX 같은 라우터들은 당신의 의도를 솔버들의 경쟁 시장에 보냅니다. 이 솔버들은 가능한 한 최고의 가격을 주기 위해 경쟁하여, 잠재적 MEV를 가격 개선으로 효과적으로 당신에게 돌려줍니다.
• 슬리피지 조정: 비유동적 페어의 경우, 샌드위치 공격자가 추출할 수 있는 최대 이익을 제한하기 위해 낮은 슬리피지 허용치(예: 0.1%)를 수동으로 설정하세요. 큰 거래를 작은 덩어리로 나누는 것도 도움이 될 수 있습니다.

지갑과 Dapp을 위해​

• OFA 통합: 기본적으로 사용자 트랜잭션을 주문 흐름 경매를 통해 라우팅하세요. 이것은 사용자를 샌드위치 공격으로부터 보호하고 우수한 실행 품질을 제공하는 가장 효과적인 방법입니다.
• 프라이빗 RPC를 기본값으로 제공: 지갑이나 dapp에서 보호된 RPC를 기본 설정으로 하세요. 파워 유저들이 빌더와 릴레이 선호도를 구성하여 프라이버시와 포함 속도 간의 트레이드오프를 미세 조정할 수 있도록 하세요.
• 실행 품질 측정: 라우팅이 최적이라고 단순히 가정하지 마세요. 공개 메모리풀 라우팅에 대해 실행을 벤치마크하고 OFA와 프라이빗 제출로부터 얻은 가격 개선을 정량화하세요.

검증자를 위해​

• MEV-Boost 실행: 스테이킹 보상을 최대화하기 위해 PBS 시장에 참여하세요.
• 다각화: 단일 제공자에 대한 의존을 피하고 네트워크 복원력을 향상시키기 위해 다양한 릴레이와 빌더 세트에 연결하세요. 잘 연결되어 있는지 확인하기 위해 보상과 블록 포함률을 모니터하세요.

L2와 SEV(시퀀서 추출 가능 가치)의 부상​

레이어 2 롤업들은 MEV를 제거하지 않습니다; 단지 이름을 바꿀 뿐입니다. 롤업들은 시퀀서라고 불리는 단일 개체에 순서 권력을 집중시켜 **시퀀서 추출 가능 가치(SEV)**를 만듭니다. 실증적 연구는 MEV가 L2에서 널리 퍼져있다는 것을 보여주지만, 종종 L1보다 낮은 이익 마진을 가집니다.

롤업당 단일 시퀀서의 중앙집권화 위험을 대처하기 위해, 공유 시퀀서와 같은 개념이 등장하고 있습니다. 이들은 여러 롤업이 트랜잭션 순서를 위해 단일한 중립적 개체를 공유할 수 있게 하는 분산화된 마켓플레이스로, 크로스-롤업 MEV를 더 공정하게 중재하는 것을 목표로 합니다.

다음에 올 것들(그리고 왜 중요한가)​

MEV를 길들이는 작업은 아직 끝나지 않았습니다. 몇 가지 주요한 프로토콜 수준 업그레이드가 지평선에 있습니다:

• 제도화된 PBS(ePBS): 이는 제안자-빌더 분리를 이더리움 프로토콜 자체로 직접 이동시켜, 신뢰할 수 있는 중앙집권화된 릴레이에 대한 의존성을 줄이고 네트워크의 보안 보장을 강화하는 것을 목표로 합니다.
• 포함 목록(EIP-7547): 이 제안은 제안자가 빌더가 특정 트랜잭션 세트를 포함하도록 강제할 수 있는 방법을 제공합니다. 이는 검열과 싸우는 강력한 도구로, 낮은 수수료의 트랜잭션도 결국 체인에 올라갈 수 있도록 보장합니다.
• MEV-Burn: EIP-1559가 기본 가스 수수료의 일부를 소각하는 것과 유사하게, MEV-burn은 빌더 지불의 일부를 소각하는 것을 제안합니다. 이는 MEV 수익 급등을 부드럽게 하고, 불안정화 행동에 대한 인센티브를 줄이며, 모든 ETH 보유자에게 가치를 재분배할 것입니다.
• SUAVE(가치 표현을 위한 단일 통합 경매): 주문 흐름을 위한 분산화되고 프라이버시를 보존하는 경매 레이어를 만들기 위한 Flashbots의 프로젝트입니다. 목표는 블록 구축을 위한 더 열려있고 공정한 시장을 만들고 독점적이고 중앙집권화된 거래로의 경향과 싸우는 것입니다.
• OFA 표준화: 경매가 표준이 되면서, 다른 라우터들이 제공하는 가격 개선을 정량화하고 비교하기 위한 공식 메트릭과 공개 도구를 만드는 작업이 진행 중이며, 전체 생태계에서 실행 품질의 기준을 높이고 있습니다.

창업자의 체크리스트(MEV 인식 제품 출시)​

• 기본적으로 프라이버시: 사용자 플로우를 프라이빗 제출이나 암호화된 의도 기반 시스템을 통해 라우팅하세요.
• 경쟁이 아닌 경매를 위한 설계: 지연 게임을 만드는 "선착순" 메커닉을 피하세요. 공정하고 효율적인 시장을 만들기 위해 배치 경매나 OFA를 활용하세요.
• 모든 것을 계측: 슬리피지, 효과적 가격 대 오라클 가격, 라우팅 결정의 기회 비용을 기록하세요. 실행 품질에 대해 사용자에게 투명하세요.
• 의존성 다각화: 오늘은 여러 빌더와 릴레이에 의존하세요. 내일의 제도화된 PBS로의 전환을 위해 인프라를 준비하세요.
• L2 계획: 멀티체인 애플리케이션을 구축한다면, 설계에서 SEV와 크로스 도메인 MEV를 고려하세요.

개발자 FAQ​

• MEV는 "나쁜" 것인가 "불법"인가? MEV는 열려있고 결정론적인 블록체인 시장의 피할 수 없는 부산물입니다. 차익거래와 청산 같은 일부 형태들은 시장 효율성에 필수적입니다. 샌드위칭 같은 다른 형태들은 순전히 추출적이고 사용자에게 해롭습니다. 목표는 MEV를 제거하는 것이 아니라 해를 최소화하고 추출을 사용자 이익과 네트워크 보안에 맞추는 메커니즘을 설계하는 것입니다. 법적 지위는 복잡하고 관할권에 따라 다릅니다.

• 프라이빗 트랜잭션 제출이 샌드위치가 없음을 보장하나요? 대부분의 봇들이 찾고 있는 공개 메모리풀에서 트랜잭션을 제외함으로써 노출을 크게 줄입니다. OFA와 결합되면 매우 강한 방어가 됩니다. 그러나 완벽한 시스템은 없으며, 보장은 사용하는 특정 프라이빗 릴레이와 빌더의 정책에 따라 다릅니다.

• 왜 단순히 "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는 버그가 아닙니다; 블록체인에 내재된 인센티브 경사입니다. 승리하는 접근법은 부정이 아닙니다—메커니즘 설계입니다. 목표는 가치 추출을 경쟁 가능하고, 투명하며, 사용자에게 맞춰진 것으로 만드는 것입니다. 구축 중이라면, 첫날부터 제품에 이러한 인식을 구워 넣으세요. 거래 중이라면, 도구가 당신을 위해 이를 하도록 요구하세요. 생태계는 이 더 성숙하고 복원력 있는 미래로 빠르게 수렴하고 있습니다—지금이 이를 위해 설계할 때입니다.

출금, 가스 조정, 그리고 그 이후의 일들—과대광고 없이.

요약​

Shapella 업그레이드는 Shanghai(실행 레이어용)와 Capella(합의 레이어용)의 합성어로, 2023년 4월 12일에 이더리움에서 실행되었습니다. 주요 특징은 Beacon Chain 출시 이후 처음으로 스테이킹 출금을 가능하게 한 것입니다.

헤드라인 변경사항인 EIP-4895는 검증자 출금이 합의 레이어에서 실행 레이어로 자동으로 "푸시"되는 시스템을 도입했으며, 사용자 트랜잭션이나 가스 수수료가 필요하지 않습니다. 이와 함께 EVM을 미세 조정하는 4개의 작은 EIP들이 배포되었는데, 가스 비용 절감(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개의 주요 이더리움 개선 제안(EIP)의 번들이었습니다:

• EIP-4895 — Beacon Chain 출금 (푸시 기반) 이것이 메인 이벤트였습니다. 부분적(보상) 및 완전(원금 + 보상) 출금 모두가 합의 레이어에서 스테이커의 지정된 출금 주소로 흐를 수 있게 했습니다. 핵심 혁신은 이것들이 사용자가 시작하는 트랜잭션이 아니라는 것입니다; 제안된 블록에 내장된 자동 작업입니다.

• EIP-3651 — "Warm COINBASE" 이 EIP는 작지만 중요한 가스 최적화를 만들었습니다. EVM에서 COINBASE는 블록 생산자(검증자)의 주소를 가리키며, 거래소가 아닙니다. Shapella 이전에는 스마트 컨트랙트가 트랜잭션 내에서 이 주소에 처음 접근할 때 더 높은 가스 비용이 발생했습니다. EIP-3651은 COINBASE 주소를 기본적으로 "warm"하게 만들어, MEV 팁을 블록 빌더에게 직접 지불하는 것과 같이 이와 자주 상호작용하는 프로토콜의 가스 비용을 줄였습니다.

• EIP-3855 — PUSH0 오피코드 EVM에 대한 간단하지만 우아한 추가입니다. 이 새로운 오피코드 PUSH0는 말 그대로의 기능을 합니다: 값 0을 스택에 푸시합니다. 이전에 개발자들은 이를 달성하기 위해 더 무겁고 비싼 오피코드들을 사용해야 했습니다. PUSH0는 바이트코드를 약간 더 작고 가스 효율적으로 만들며, 특히 변수를 0으로 초기화하는 수많은 컨트랙트에 유용합니다.

• EIP-3860 — initcode 제한 및 측정 이 변경사항은 스마트 컨트랙트를 생성하는 데 사용되는 코드(initcode)에 대한 두 가지 규칙을 도입했습니다. 첫째, initcode의 최대 크기를 49,152바이트로 제한했습니다. 둘째, 이 코드의 32바이트 청크마다 작은 가스 수수료를 추가했습니다. 이는 과도하게 큰 컨트랙트와 관련된 서비스 거부 공격을 방지하고 컨트랙트 생성 비용을 더 예측 가능하게 만듭니다.

• EIP-6049 — SELFDESTRUCT 중단 (경고) 이는 코드 변경이 아니라 개발자 커뮤니티에 대한 공식 경고였습니다. 컨트랙트가 스스로를 삭제하고 ETH를 대상 주소로 보낼 수 있게 하는 SELFDESTRUCT 오피코드가 향후 업그레이드에서 기능이 대폭 변경될 것이라고 알렸습니다. 이는 개발자들이 Dencun 업그레이드가 나중에 EIP-6780으로 그 동작을 변경하기 전에 의존성을 단계적으로 제거할 시간을 주었습니다.

출금 101: 부분적 vs. 완전​

Shapella는 각각 고유한 규칙을 가진 두 가지 유형의 자동 출금을 도입했습니다.

• 부분 출금 이들은 자동 보상 수집입니다. 검증자의 잔액이 합의 레이어 보상으로 32 ETH 이상으로 증가하면, 프로토콜이 자동으로 초과 금액을 "스킴"하고 지정된 출금 주소로 보냅니다. 검증자는 활성 상태를 유지하고 그 역할을 계속합니다. 이는 스테이커의 어떤 조치도 필요로 하지 않습니다.

• 완전 출금 (퇴장) 이는 검증을 중단하고 전체 잔액을 회수하려는 스테이커를 위한 것입니다. 스테이커는 먼저 자발적 퇴장 메시지를 방송해야 합니다. 대기 기간 후, 검증자는 완전 출금 자격을 얻습니다. 수집에서 처리되면, 전체 잔액이 출금 주소로 보내지고, 검증자는 더 이상 활성 세트의 일부가 아닙니다.

처리량과 주기​

네트워크는 불안정성을 야기하지 않으면서 출금을 원활하게 처리하도록 설계되었습니다.

• 각 블록(12초마다)에 최대 16개의 출금이 포함될 수 있어, 하루에 약 115,200개의 출금이 최대치로 가능합니다.
• 블록 제안자는 활성 검증자 목록을 스캔하고 처음 16개의 적격 출금을 포함합니다. 다음 블록 제안자는 마지막이 중단한 곳에서 계속하여, 모든 검증자가 대기열에서 순서를 얻도록 보장합니다.
• 대량 탈출이 네트워크를 불안정화시키는 것을 방지하기 위해, 에포크당(약 6.4분마다) 퇴장할 수 있는 검증자의 수는 유출 제한으로 제한됩니다. 이 제한은 총 활성 검증자 수를 기반으로 동적이며, 퇴장 파도를 완화합니다.

합의 레이어 보상은 이 EIP-4895 출금 메커니즘으로 처리되는 반면, 실행 레이어 보상(우선 수수료 및 MEV)은 검증자의 구성된 수수료 수신자 주소로 직접 보내지고 즉시 사용 가능하다는 것도 중요합니다.

그 다음에 온 것: Dencun과 확장성으로의 길​

Shapella는 "Merge 시대"의 성공적인 완료를 기록했습니다. 스테이킹이 이제 완전히 유동적인 양방향 프로세스가 되면서, 개발자들은 이더리움의 다음 큰 도전에 주의를 돌렸습니다: 확장성.

바로 다음 주요 업그레이드인 Dencun (Deneb + Cancun)이 2024년 3월 13일에 도착했습니다. 그 중심은 Layer 2 롤업이 이더리움 메인넷에 트랜잭션 데이터를 게시할 수 있는 새롭고 더 저렴한 방법인 "blob"을 도입한 EIP-4844였습니다. 이는 L2에서 트랜잭션 수수료를 극적으로 낮췄고 롤업 중심 로드맵에서 대규모 전진이었습니다. Dencun은 또한 SELFDESTRUCT 오피코드의 권력을 크게 제한한 EIP-6780을 구현하여 EIP-6049의 약속을 이행했습니다.

큰 그림​

Shapella는 이더리움의 Proof-of-Stake 합의에 대한 필수적인 신뢰 이정표였습니다. 출금을 가능하게 함으로써 스테이킹의 위험을 줄이고, 유동성을 복원하며, 복잡하고 조정된 업그레이드를 실행할 네트워크의 능력을 확인했습니다. 또한 기술적 부채를 정리하고 향후 최적화의 길을 닦은 실용적인 EVM 개선사항들을 제공했습니다.

요약하면, Shapella는 스테이커들을 위한 출구 문을 열었을 뿐만 아니라—Post-Merge 시대의 기반을 고체화하고 이더리움이 다음 개척지인 대규모 확장성에 집중할 수 있는 활주로를 정리했습니다.