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

DAG란 무엇이며 블록체인과 무엇이 다른가요?​

**유향 비순환 그래프(Directed Acyclic Graph, DAG)**는 방향성을 가진 간선으로 노드를 연결하되, 어떤 경로를 따라가도 다시 시작점으로 돌아오지 않는 데이터 구조입니다. 분산원장 관점에서 DAG 기반 원장은 트랜잭션이나 이벤트를 하나의 직선형 체인이 아닌 거미줄 같은 그래프로 배치합니다. 즉, 전통적인 블록체인은 새로운 블록이 하나의 이전 블록만을 참조해 선형 체인을 이루지만, DAG에서는 한 노드가 여러 이전 트랜잭션이나 블록을 동시에 참조할 수 있습니다. 그 결과, 트랜잭션은 시간순 블록에 하나씩 묶여 처리되는 것이 아니라, 동시에 병렬로 확정될 수 있습니다.

블록체인이 블록으로 이루어진 긴 사슬처럼 보인다면, DAG 원장은 개별 트랜잭션이 가지를 뻗는 나무 혹은 웹에 더 가깝습니다. DAG에서는 새 트랜잭션이 이전의 한두 건 이상을 첨부하여 검증하기 때문에, 다음 블록에 실리길 기다릴 필요가 없습니다. 이러한 구조적 차이는 다음과 같은 특징을 만듭니다.

• 병렬 검증: 블록체인에서는 채굴자/검증자가 한 번에 한 블록씩 추가하므로, 트랜잭션은 새 블록이 생성될 때마다 묶음으로 확정됩니다. DAG에서는 여러 트랜잭션(혹은 소규모 “블록”)을 동시에 추가할 수 있고, 각 트랜잭션이 그래프의 서로 다른 부분에 연결됩니다. 이러한 병렬성 덕분에 네트워크가 긴 체인이 한 블록씩 늘어나는 것을 기다릴 필요가 없습니다.
• 전역 순서 부재: 블록체인은 모든 트랜잭션에 절대적인 순서를 부여합니다(각 블록이 하나의 직선 시퀀스 상의 위치를 갖습니다). 반면 DAG 원장은 트랜잭션의 부분 순서를 형성합니다. “가장 최신 블록”이 단일하게 존재하지 않고, 그래프의 여러 팁이 동시에 존재하면서 확장됩니다. 따라서 그래프 내 트랜잭션의 순서나 유효성에 대한 합의를 위해 별도의 합의 프로토콜이 필요합니다.
• 트랜잭션 확정: 블록체인에서는 트랜잭션이 채굴/검증된 블록에 포함되고, 그 블록이 체인에 채택된 뒤(보통 추가 블록이 쌓인 후) 확정됩니다. DAG 시스템에서는 새로운 트랜잭션 자체가 이전 트랜잭션을 참조함으로써 검증에 기여합니다. 예컨대 IOTA의 Tangle(DAG)에서는 각 트랜잭션이 이전 두 건을 승인해야 하며, 사용자들이 서로의 트랜잭션을 협력 검증하게 됩니다. 이를 통해 블록체인 채굴에서 존재하는 “트랜잭션 생성자”와 “검증자”의 구분이 희미해지고, 트랜잭션 발행자가 검증 작업도 일부 담당하게 됩니다.

중요한 점은, 블록체인은 사실 DAG의 특수한 형태라는 것입니다. 블록체인은 단일 체인 형태로 제한된 DAG로 볼 수 있습니다. 두 구조 모두 분산원장기술(DLT)의 일종으로서 불변성, 탈중앙화 등 공통 목표를 지니지만, DAG 원장은 구조적으로 “블록리스” 혹은 다중 부모 구조를 취하기 때문에 실제 특성이 달라집니다. 비트코인과 이더리움처럼 전통적인 블록체인은 직렬 블록을 사용하며 경쟁 블록(fork)은 대부분 버립니다. 반면 DAG 원장은 충돌이 없는 트랜잭션을 최대한 수용·정렬하려 합니다. 이러한 근본적 차이가 성능과 설계에서 다양한 차이를 낳습니다.

기술 비교: DAG와 블록체인​

DAG와 블록체인을 구조와 검증 방식 측면에서 비교해보면 다음과 같습니다.

• 데이터 구조: 블록체인은 트랜잭션을 담은 블록을 직선으로 연결하며, 각 블록은 하나의 이전 블록을 가리킵니다. DAG 원장은 그래프 구조를 택하고 각 노드가 트랜잭션이나 이벤트 블록을 의미하며, 여러 이전 노드를 참조할 수 있습니다. 유향 비순환 특성상 과거를 따라가도 출발점으로 되돌아가지 않습니다. 이 때문에 참조된 트랜잭션이 항상 앞에 오도록 하는 위상 정렬이 가능합니다. 요약하면 블록체인은 1차원 체인, DAG는 다차원 그래프입니다.
• 처리량과 동시성: 구조적 차이는 처리량에도 영향을 줍니다. 블록체인은 이상적으로도 블록을 하나씩 추가해야 하며(새 블록이 네트워크 전체에 전파·검증될 때까지 기다리는 경우가 많습니다), 이는 TPS(초당 트랜잭션 수)를 제한합니다. 예를 들어 비트코인은 57 TPS, 전통적인 PoW 이더리움은 1530 TPS 수준입니다. DAG 시스템은 많은 트랜잭션/블록을 동시에 원장에 기록할 수 있습니다. 여러 분기가 동시 성장해 나중에 합류할 수 있으므로 잠재 처리량이 크게 늘어납니다. 일부 최신 DAG 네트워크는 수천 TPS를 주장하며, 전통 결제 네트워크 수준에 도달하거나 능가한다고 합니다.
• 트랜잭션 검증 절차: 블록체인에서는 트랜잭션이 메모리풀에 대기하고, 채굴자/검증자가 새 블록에 담은 뒤 다른 노드가 전체 이력을 기준으로 검증합니다. DAG에서는 검증이 더 지속적이고 탈중앙화되어 진행됩니다. 새 트랜잭션이 과거 트랜잭션을 참조(승인)함으로써 검증 행위를 수행합니다. 예컨대 IOTA Tangle에서는 각 트랜잭션이 두 건을 확인하고 소규모 PoW를 수행해 해당 트랜잭션에 “투표”합니다. Nano의 블록-라티스에서는 각 계정이 자체 체인을 이루고 대표 노드의 투표로 검증합니다. 결과적으로 DAG는 검증 작업을 분산시키며, 단일 블록 생산자가 한 번에 처리하는 대신 많은 참여자가 동시에 다양한 트랜잭션을 검증합니다.
• 합의 메커니즘: 블록체인과 DAG 모두 어느 트랜잭션이 확정되었고 순서가 어떠한지 네트워크 전체가 합의해야 합니다. 블록체인에서는 주로 작업증명(PoW)이나 지분증명(PoS)으로 다음 블록을 생성하고 “가장 긴(혹은 가장 무거운) 체인이 승리한다”는 규칙이 적용됩니다. DAG에서는 단일 체인이 없기 때문에 합의가 더 복잡합니다. 고십(gossip) 프로토콜과 가상 투표(Hedera Hashgraph)나 MCMC 기반 팁 선택(초기 IOTA) 등 프로젝트별로 서로 다른 접근을 취합니다. DAG에서 합의를 이루면 처리량 측면에서 빠를 수 있지만, 동시에 존재하는 트랜잭션 간 충돌(더블스펜드 등)을 다루기 위해 정교한 설계가 필요합니다.
• 포크 처리: 블록체인에서 거의 동시에 두 블록이 만들어지면 “포크”가 발생하고, 결국 한 체인이 승리하고 다른 하나는 고아 블록으로 버려집니다. 이는 컴퓨팅 리소스를 낭비합니다. DAG에서는 포크를 추가 분기로 받아들이는 철학입니다. 그래프에 양쪽을 모두 포함시키고, 합의 알고리즘이 어떤 트랜잭션을 확정할지(충돌 시 어떤 것을 버릴지) 결정합니다. 덕분에 낭비되는 계산이 없어 효율적입니다. Conflux의 Tree-Graph(PoW DAG)는 생성된 모든 블록을 원장에 포함해 순서를 정하려는 예시입니다.

정리하면, 블록체인은 단순하고 엄격하게 순서를 부여하는 구조로 블록 단위 검증을 수행하며, DAG는 복잡한 그래프 구조를 통해 비동기·병렬 트랜잭션 처리가 가능합니다. DAG 원장은 이러한 복잡성을 다루기 위해 추가 합의 로직이 필요하지만, 네트워크 전체의 자원을 효율적으로 활용해 훨씬 높은 처리량과 효율을 기대할 수 있습니다.

DAG 기반 블록체인의 이점​

DAG 아키텍처는 전통 블록체인의 확장성·속도·비용 한계를 극복하기 위해 등장했습니다. 주요 장점은 다음과 같습니다.

• 높은 확장성과 처리량: DAG 네트워크는 트랜잭션을 병렬 처리해 높은 TPS를 달성합니다. 단일 체인 병목이 없어 네트워크 활동량이 늘수록 처리량이 증가합니다. Hedera Hashgraph는 베이스 레이어에서 초당 1만 건 이상 처리할 수 있다고 하며, 실제로 3~5초 이내에 트랜잭션을 확정합니다. DAG 기반 스마트컨트랙트 플랫폼인 Fantom도 일반적인 상황에서 1~2초 정도의 거의 즉시 확정을 제공합니다. 이런 확장성은 IoT 마이크로 결제나 실시간 데이터 스트림 같은 고빈도 사용 사례에 적합합니다.
• 낮은 수수료(무수수료 포함): 많은 DAG 원장은 수수료가 매우 낮거나 아예 없습니다. 마이너 보상이나 수수료에 의존하지 않는 설계 덕분입니다. IOTA와 Nano에는 필수 수수료가 없어 IoT나 일상적 소액 결제에 특히 유리합니다. Hedera나 Fantom처럼 수수료가 있는 경우에도 매우 낮고 예측 가능하며, 블록 공간 경쟁이 덜해 급등할 가능성이 적습니다. 예컨대 Hedera의 트랜잭션 수수료는 0.0001달러 수준입니다. DAG는 포크에서도 트랜잭션을 버리지 않기 때문에 낭비가 적고, 자원 효율성이 높습니다.
• 빠른 확정과 낮은 지연: DAG에서는 전역 블록에 포함되길 기다릴 필요가 없어 확정이 빠릅니다. Hedera Hashgraph는 aBFT 합의로 몇 초 안에 100% 확정합니다. Nano는 대표 투표 덕에 1초 미만으로 확정되는 경우가 대부분입니다. 지연이 짧으면 사용자 경험이 향상되고, 실생활 결제나 인터랙티브 애플리케이션에 적합합니다.
• 에너지 효율: 많은 DAG 네트워크는 PoW 채굴처럼 에너지 집약적 과정을 요구하지 않으므로 전력 소비가 매우 낮습니다. PoS 체인보다도 적은 에너지를 쓰는 사례가 있습니다. Hedera의 트랜잭션당 에너지 소비는 약 0.0001 kWh로 보고되며, 비트코인(수백 kWh)이나 다수 PoS 체인보다 훨씬 적습니다. 쓸모없는 계산을 제거하고, 트랜잭션을 버리지 않는 구조가 이러한 효율을 가능하게 합니다. DAG가 광범위하게 채택되면 막대한 에너지 절감이 기대됩니다. Hedera처럼 탄소 네거티브를 선언한 프로젝트도 있습니다.
• 채굴 없음 & 검증의 민주화: 많은 DAG 모델에서는 일반 사용자도 검증에 참여할 수 있습니다. IOTA에서는 트랜잭션을 발행하는 사용자가 다른 두 건을 검증하여 검증 작업이 네트워크 가장자리까지 분산됩니다. 고성능 채굴 장비나 대규모 스테이킹 없이도 참여할 수 있어 접근성이 높습니다(다만 네트워크에 따라 검증자나 코디네이터를 두는 경우도 있습니다).
• 고트래픽 처리: 블록체인은 높은 부하 시 메모리풀 과부하와 수수료 급등을 겪습니다. DAG 네트워크는 병렬 구조 덕에 트랜잭션 급증 시 여러 분기를 형성하여 동시에 처리하므로 혼잡을 완화합니다. 따라서 IoT 디바이스의 동시 데이터 전송이나 바이럴 DApp 이벤트에도 지연과 수수료 상승이 비교적 적습니다.

결론적으로 DAG 원장은 기존 블록체인이 취약했던 속도·비용·확장성 측면에서 더 나은 경험을 제공하려 합니다. 다만 이러한 장점 이면에는 구현상의 도전과제가 있으며, 이후 섹션에서 살펴봅니다.

DAG 기반 플랫폼의 합의 메커니즘​

DAG 원장은 자연스럽게 하나의 체인을 만들지 않기 때문에, 트랜잭션을 검증하고 원장 상태에 대한 합의를 이루기 위해 혁신적인 합의 방식을 필요로 합니다. 대표적인 사례는 다음과 같습니다.

• IOTA Tangle – 팁 선택과 가중 투표: IOTA의 Tangle은 IoT를 위해 설계된 트랜잭션 DAG입니다. 마이너가 없고, 각 트랜잭션이 작은 PoW를 수행하여 이전 두 건을 승인해야 합니다. 팁 선택은 마르코프 체인 몬테카를로(MCMC) 알고리즘으로 이루어지며, 가장 무거운 서브탱글을 우선시해 분열을 막습니다. 초기 IOTA에서는 후속 트랜잭션의 누적 승인 가중치로 확정을 측정했습니다. 그러나 보안을 위해 IOTA 재단이 운영하는 중앙화된 Coordinator 노드가 마일스톤 트랜잭션을 발행해 Tangle을 마무리했습니다. 이 구조는 중앙화 비판을 받았고, “Coordicide”(IOTA 2.0)에서 제거되는 중입니다. IOTA 2.0은 리더 없는 나카모토 스타일 합의를 DAG에서 실행합니다. 노드가 새로운 블록을 붙일 때 참조하는 트랜잭션의 유효성에 암묵적으로 투표하고, 스테이킹으로 선정된 검증자 위원회가 validation block을 발행해 가중 승인을 쌓아갑니다(approval weight). 충분한 승인을 얻으면 트랜잭션이 확정됩니다.
• Hedera Hashgraph – 고십과 가상 투표(aBFT): Hedera Hashgraph는 이벤트 DAG와 비동기 비잔틴 내결함성(aBFT) 합의를 결합합니다. 핵심은 **“gossip about gossip”**입니다. 각 노드는 트랜잭션 정보뿐 아니라 자신이 들은 고십 히스토리를 서명해 다른 노드와 공유합니다. 이로써 누가 언제 어떤 정보를 들었는지 구조까지 포함하는 해시그래프(DAG)가 만들어집니다. Hedera는 이 DAG를 바탕으로 가상 투표를 수행합니다. 실제 투표 메시지를 주고받는 대신, 노드가 DAG 구조를 분석해 투표 과정을 로컬에서 시뮬레이션합니다. 이를 통해 컨센서스 타임스탬프와 완전한 트랜잭션 순서를 도출하며, 공정하고 결정적인 결과가 나옵니다. Hashgraph 합의는 리더가 없고, 최대 1/3까지 악의적 노드를 허용하는 aBFT를 달성합니다. 현재 Hedera는 **39개의 기업 노드(평의회)**가 운영하는 허가형 구조지만, 지리적으로 분산돼 있습니다. 합의 알고리즘은 특허였으나 2024년부터 오픈소스로 공개되었습니다.
• Fantom Lachesis – 리더 없는 PoS aBFT: Fantom은 Lachesis라는 DAG 기반 합의를 사용하는 스마트컨트랙트 플랫폼입니다. Hashgraph에 영감을 받은 aBFT PoS 프로토콜로, 각 검증자는 수신한 트랜잭션을 이벤트 블록으로 묶어 로컬 DAG에 추가합니다. 이벤트 블록은 이전 이벤트를 참조하며, 비동기로 고십됩니다. 검증자들은 슈퍼 다수 노드가 본 이벤트를 루트 이벤트로 표시하고, 이를 Opera Chain이라는 선형 블록체인에 커밋합니다. 즉, DAG로 비동기 고속 합의를 이루고 최종 결과를 개발자 친화적인 블록체인 형태로 제공하는 방식입니다. Fantom 트랜잭션은 1~2초 정도에 확정되고, 벤치마크에서 수천 TPS가 가능하다고 보고됩니다. Lachesis에는 리더가 없으며, 모든 검증자가 이벤트 블록을 제출하고 프로토콜이 순서를 결정합니다. PoS 스테이킹으로 보안이 보장되며, 1/3의 오류 노드까지 허용합니다.
• Nano Open Representative Voting(ORV): Nano는 블록라티스라는 DAG 구조를 사용하는 결제용 암호화폐입니다. 각 계정이 자체 블록체인을 가지며, 계정 소유자만 업데이트할 수 있습니다. 계정 간 송금은 송신 계정의 전송 블록과 수신 계정의 수신 블록으로 처리되어 비동기적으로 연결됩니다. 합의는 ORV라는 대표자 투표로 이루어지며, 사용자가 잔액에 비례한 투표권을 대표 노드에 위임합니다. 대표자는 충돌 트랜잭션을 투표로 판별하고, 67% 이상의 가중치가 동의하면 트랜잭션이 **시멘트(확정)**됩니다. 솔직한 계정 소유자는 이중 지불을 하지 않으므로 포크는 드물며, 대표가 빠르게 거부합니다. 결과적으로 1초 미만의 확정이 일반적입니다. ORV는 PoS와 유사하게 투표 가중치가 잔액에 기반하지만, 스테이킹 보상이나 수수료가 없습니다. 채굴과 블록 생성이 없어, Nano는 무료이면서 효율적으로 작동합니다. 다만 대표 노드의 가용성에 의존하며, 투표권이 소수 노드에 집중될 수 있다는 점은 중앙화 우려로 지적됩니다.
• 기타 사례:
  • Avalanche 합의: Avalanche는 검증자들이 무작위로 서로를 샘플링해 선호하는 트랜잭션/블록을 결정하는 DAG 기반 합의를 사용합니다. X-Chain은 UTXO DAG로, 반복 샘플링으로 합의합니다. 확률적이지만 매우 빠르고 확장 가능하며, 약 1초 내 확정·서브넷당 4,500 TPS가 가능하다고 합니다.
  • Conflux Tree-Graph: Conflux는 비트코인의 PoW를 DAG 블록으로 확장한 플랫폼으로, 각 블록이 단일 부모뿐 아니라 알려진 이전 블록을 모두 참조합니다. 이를 통해 포크된 블록을 버리지 않고 전체 원장에 포함시켜 높은 처리량을 달성합니다. 이론적으로 3~6천 TPS까지 가능하며, 무거운 서브트리를 기준으로 순서를 정합니다.
  • 학술 프로토콜: SPECTRE, PHANTOM(DAGlabs의 고처리량 blockDAG), Aleph Zero(Aleph Zero 블록체인에서 사용하는 DAG aBFT), Parallel Chains/Prism, Sui의 Narwhal & Bullshark 등 다양한 DAG 프로토콜이 연구·실험되고 있습니다.

프로젝트마다 합의 구조는 용도에 맞게 조정되지만, 공통적으로 단일 직렬 병목을 피하려는 목표를 가집니다. 고십, 투표, 샘플링 등 다양한 알고리즘으로 동시 활동을 정렬하고, 한 번에 하나의 블록 생산자만 허용하는 방식에서 벗어나려는 접근입니다.

사례 연구: DAG 기반 프로젝트​

DAG 원장을 채택한 프로젝트는 다수이며, 설계 철학과 목표 시장이 다양합니다. 대표적인 예시는 다음과 같습니다.

• IOTA (The Tangle): IoT를 위해 설계된 초기 DAG 암호화폐입니다. Tangle은 각 트랜잭션이 두 건을 확인하는 DAG이며, IoT 기기간 무수수료 마이크로결제를 목표로 합니다. 2016년 출시 이후 초기에는 IOTA 재단의 Coordinator가 보안 강화를 위해 운영되었습니다. 현재는 완전한 탈중앙화를 위해 투표 기반 합의(앞서 설명한 리더리스 합의)를 도입 중입니다. 이론적으로 활동량이 많을수록 더 빨리 확정되며, 테스트넷에서 수백 TPS를 확인했습니다. IOTA 2.0은 IoT 수요에 맞춰 확장성을 제공할 것으로 기대됩니다. 활용 사례는 센서 데이터 스트리밍, 차량 간 결제, 공급망 추적, DID(IOTA Identity) 등입니다. 기본 레이어에는 스마트컨트랙트가 없고, 별도 레이어에서 제공됩니다. 트랜잭션 수수료가 없고, 발행자가 작은 PoW를 수행하는 방식이라 소액·고빈도 거래에 적합합니다.
• Hedera Hashgraph (HBAR): Hashgraph 합의를 채택한 퍼블릭 DLT입니다. 2018년 시작되었고 Google, IBM, Boeing 등 대기업이 구성한 평의회가 노드를 운영합니다. 현재는 최대 39개의 허가형 노드가 합의를 담당하지만, 누구나 네트워크를 사용할 수 있습니다. Hashgraph DAG 덕분에 1만 TPS 이상, 3~5초 확정이 가능하다고 합니다. 토큰 서비스(HTS), 합의 서비스(감사 로그용), EVM 호환 스마트컨트랙트를 제공하며, 공급망 추적, 대규모 NFT 발행, 광고 마이크로결제, DID 솔루션 등 다양한 엔터프라이즈 및 Web3 사례에 사용됩니다. Hashgraph는 포크가 발생하지 않고 공정한 순서를 보장하는 점이 특징입니다. 노드 수가 제한되어 탈중앙성은 낮지만, 글로벌 분산과 향후 개방 계획이 있습니다.
• Fantom (FTM): DAG 합의 Lachesis를 사용하는 레이어1 스마트컨트랙트 플랫폼입니다. 2019년 런칭 이후 2021~2022년 DeFi 붐에서 이더리움 호환이면서 빠르고 저렴한 성능 덕분에 인기를 얻었습니다. Opera 네트워크가 Lachesis aBFT를 수행하며, 검증자가 로컬 DAG에서 이벤트 블록을 유지하고 합의한 뒤 선형 체인에 커밋합니다. 결과적으로 약 1초의 확정과 수천 TPS를 제공합니다. EVM 호환성이 있어 Solidity 스마트컨트랙트와 기존 툴을 그대로 사용할 수 있어 DeFi 프로젝트 유입이 활발했습니다. DEX, 대출, NFT, 게임 등 다양한 DApp이 운영 중이며, 다수의 독립 검증자가 허가 없이 스테이킹할 수 있어 DAG 플랫폼 중에서는 비교적 분산화가 잘 되어 있습니다. 네이티브 토큰 FTM은 스테이킹, 거버넌스, 수수료에 사용되며, 거래 비용은 몇 센트 이하입니다.
• Nano (XNO): 2015년 RaiBlocks로 등장한 가벼운 암호화폐로, DAG 블록라티스를 사용합니다. 목표는 즉시·무수수료 P2P 디지털 화폐입니다. 각 계정은 자체 체인을 갖고, 송금 시 송신·수신 블록으로 처리됩니다. ORV 합의를 통해 사용자들이 잔액 가중치로 대표를 지정하고, 대표가 충돌 트랜잭션을 투표로 결정합니다. 대표 투표의 과반(67% 이상)이 동의하면 트랜잭션이 시멘트되어 되돌릴 수 없습니다. 일반적으로 1초 미만에 확정되며, 트랜잭션 크기가 작고 처리도 가벼워 IoT나 모바일 환경에서도 효율적입니다. 스마트컨트랙트는 지원하지 않고 결제에 특화되어 있습니다.

표: 주요 DAG 기반 원장 프로젝트 비교 (TPS = 초당 트랜잭션 수).

기타 DAG 프로젝트로는 조건부 결제와 데이터 저장을 다루는 Obyte(Byteball), IoT에 초점을 맞춘 IoT Chain(ITC), 합의에 DAG를 활용하는 Avalanche, 중국의 고처리량 PoW DAG인 Conflux, 학술 연구의 SPECTRE/PHANTOM 등이 있습니다. 위 네 가지 예시는 수수료 없는 IoT 거래부터 엔터프라이즈 네트워크, DeFi 스마트컨트랙트 체인까지 다양한 분야에서 DAG 구조가 사용되고 있음을 보여줍니다.

Web3 생태계에서의 DAG 활용 사례​

DAG 기반 블록체인은 높은 성능과 특유의 속성 덕분에 특정 분야에서 강점을 보입니다. 다음은 현재 또는 잠재적으로 Web3에서 주목받는 주요 활용 사례입니다.

• IoT: IoT 기기는 수백만 개 이상이 데이터를 전송하고 상호 결제할 수 있습니다. IOTA 같은 DAG 원장은 이런 시나리오를 위해 설계되었습니다. 무수수료 마이크로결제와 높은 빈도의 소액 처리 능력을 통해, 장치가 실시간으로 서비스나 대역폭을 지불할 수 있습니다. 예를 들면 전기차가 충전소에 자동 결제를 하거나, 센서가 데이터 마켓에서 실시간으로 데이터를 판매하는 방식입니다. IOTA Tangle은 스마트시티 파일럿, 공급망 IoT 통합, 탈중앙 데이터 마켓 등에서 활용되었습니다. 대규모 IoT 네트워크가 발생시키는 막대한 트랜잭션을 감당할 수 있는 확장성과, 소액 결제 경제에 맞는 낮은 비용이 강점입니다.
• DeFi: DEX, 대출, 결제 네트워크 등 DeFi 애플리케이션은 높은 처리량과 낮은 지연을 요구합니다. DAG 기반 스마트컨트랙트 플랫폼(Fantom 등)은 혼잡 상황에서도 거래를 빠르고 저렴하게 처리할 수 있습니다. 2021년 Fantom이 DeFi 붐을 맞았을 때, 이더리움 대비 혼잡과 수수료 문제가 훨씬 덜했습니다. 또한 DAG의 빠른 확정은 느린 체인의 블록 확정 대기 중 발생할 수 있는 거래 불확실성(슬리피지, MEV 등)을 완화합니다. Nano 같은 DAG 통화는 P2P 송금이나 다른 시스템의 L2 마이크로페이먼트 레일로 활용될 가능성도 있습니다. 고빈도 트레이딩이나 복잡한 DeFi 트랜잭션을 매끄럽게 처리할 수 있는 능력이 장점입니다.
• NFT와 게임: NFT 붐에서는 민팅과 전송 수수료가 큰 문제였습니다. DAG 네트워크(Hedera, Fantom 등)는 NFT 민팅 비용을 몇 센트 이하로 낮출 수 있어, 게임 자산·컬렉션·대규모 에어드롭 등에서 유리합니다. Hedera Token Service는 저렴하고 예측 가능한 수수료로 토큰과 NFT 발행을 지원하며, 콘텐츠 플랫폼과 기업 등에서 사용됩니다. 게임에서는 마이크로트랜잭션이 빈번하므로, 빠르고 저렴한 DAG가 보상 지급이나 아이템 거래를 지연 없이 처리합니다. 큰 규모의 게임/컬렉션이 수백만 사용자를 모아도 감당할 수 있는 고처리량이 장점입니다.
• 분산 ID(DID)와 자격 증명: DID 시스템은 ID, 자격 증명, 증명을 불변 원장에 기록해야 합니다. DAG는 잠재적으로 수십억 건의 ID 트랜잭션을 저렴하게 처리할 수 있어 주목받습니다. IOTA Identity는 did:iota 메서드를 제공하여 사용자가 자기 ID 문서를 Tangle에 앵커링하고, 검증자는 DAG에서 증명을 조회할 수 있습니다. Hedera도 DID 분야에 적극적이며, 학위·백신 인증·공급망 컴플라이언스 로그(Consensus Service) 등에서 활용되고 있습니다. DAG는 데이터 기록 비용이 낮고 빠르며, 키 회전이나 자격 추가 등 ID 상태 갱신에 유리합니다. Hashgraph처럼 공정한 타임스탬프 순서를 제공하는 기능은 감사/컴플라이언스에도 도움이 됩니다.
• 공급망 및 데이터 무결성: 공급망에서는 제조·운송·검수 등 다수 이벤트가 발생합니다. Hedera와 IOTA는 이러한 이벤트를 DAG 원장에 기록해 불변성과 투명성을 제공합니다. 고처리량 덕분에 대규모 공급망의 모든 항목을 기록해도 병목이 되지 않습니다. 수수료가 낮아 낮은 가치의 이벤트도 기록할 수 있습니다. 전력망이나 통신처럼 IoT 데이터 무결성을 요구하는 분야에서도 DAG에 로그를 남겨 사후 검증이 가능하도록 할 수 있습니다. Constellation Network의 DAG는 대용량 데이터 검증(예: 미 공군 드론 데이터)에 초점을 맞춘 사례입니다.
• 결제와 송금: Nano, IOTA와 같은 DAG 통화는 즉시·무수수료 거래가 가능해 결제에 적합합니다. Nano는 온라인 팁이나 해외 송금 등에서 사용 사례가 있으며, 몇 센트의 소액도 즉시 보낼 수 있습니다. DAG 네트워크는 고속 결제 레일로 POS 시스템이나 모바일 결제 앱에 통합될 수 있습니다. 실매장에서 DAG 기반 암호화폐로 커피 값을 지불해도 카드 결제 수준의 경험을 제공할 수 있습니다. Hedera의 HBAR도 빠른 확정과 낮은 수수료를 활용한 결제 실험이 진행 중입니다. 높은 용량 덕분에 대형 쇼핑 이벤트 같은 수요 폭증 상황에서도 성능을 유지할 수 있습니다.
• 실시간 데이터 피드와 오라클: 오라클은 외부 데이터를 스마트컨트랙트에 공급하기 위해 원장에 많은 데이터를 기록해야 합니다. DAG 원장은 높은 처리량으로 가격 피드, 날씨 데이터, IoT 센서 값을 타임스탬프와 함께 기록할 수 있습니다. Hedera Consensus Service는 일부 오라클이 데이터를 타 체인에 전달하기 전에 타임스탬프를 찍는 용도로 사용합니다. 빠른 속도로 데이터를 갱신할 수 있고, 데이터 스트림이 빨라도 대응할 수 있습니다. 분산형 Web3 분석이나 광고에서도 클릭/노출을 투명하게 기록하기 위해 DAG 백엔드를 사용할 수 있습니다.

이러한 활용 사례는 DAG 네트워크가 확장성·속도·비용 효율을 제공해 탈중앙화 가능한 영역을 넓힌다는 공통점을 보입니다. 트랜잭션 빈도가 높은 상황(IoT, 마이크로페이먼트, 머신 데이터)이나 빠르고 원활한 사용자 경험이 필요한 상황(게임, 결제)에 특히 강점을 발휘합니다. 물론 모든 유스케이스가 DAG로 이동하는 것은 아니며, 기존 블록체인의 안정성이나 네트워크 효과(Ethereum의 거대한 개발자 커뮤니티 등)가 중요한 경우도 있습니다. 그럼에도 DAG는 기존 체인이 감당하기 어려운 시나리오에서 틈새를 공략하고 있습니다.

DAG 네트워크의 한계와 도전과제​

DAG 기반 원장은 매력적인 장점을 제공하지만, 트레이드오프와 과제도 존재합니다. 주요 이슈는 다음과 같습니다.

• 성숙도와 보안: 많은 DAG 합의 알고리즘은 비교적 새롭고, 비트코인이나 이더리움처럼 장기간 검증된 것이 아닙니다. 따라서 알려지지 않은 취약점이나 공격 벡터가 있을 수 있습니다. 복잡한 구조가 공격 표면을 넓히기도 합니다. 예를 들어 DAG에 충돌하는 서브탱글을 스팸으로 주입해 혼란을 일으키거나, 병렬 구조를 악용해 합의 전에 이중지불을 시도할 수 있습니다. 실제로 IOTA는 초기 해킹 사건으로 네트워크를 일시 중단한 적이 있습니다. 또한 일부 DAG(IOTA의 Coordicide 이전 등)는 확정이 확률적이어서, 완전히 확정되기까지 불확실성이 존재했습니다(Hashgraph나 Fantom처럼 즉시 확정을 제공하는 DAG도 있습니다).
• 합의의 복잡성: DAG 합의는 고십, 가상 투표, 무작위 샘플링 등 복잡한 알고리즘을 요구합니다. 그 결과 코드가 방대하고 복잡해져 버그 가능성이 높아집니다. 개발자가 이해하거나 감사하기 어려워 도입이 더딜 수 있습니다. 블록체인의 최장체인 규칙처럼 직관적이지 않으며, Hashgraph의 가상 투표나 Avalanche의 반복 샘플링 등은 개념적으로 어렵습니다. 개발 도구나 라이브러리 생태계도 상대적으로 미성숙하여, 개발 경험이 블록체인보다 떨어질 수 있습니다.
• 탈중앙성 트레이드오프: 일부 DAG 구현은 성능을 위해 탈중앙성을 희생합니다. Hedera처럼 평의회 노드가 고정된 경우 누구나 합의 노드로 참여할 수 없고, 중앙화 비판을 받습니다. IOTA는 오랫동안 중앙 Coordinator에 의존했습니다. Nano는 대표 노드 몇 곳에 투표 가중치가 몰리는 경향이 있어 권력 집중 우려가 있습니다(이는 PoW 체인의 대형 채굴 풀 집중과 비슷한 현상입니다). 이론적으로는 고도로 분산된 DAG 네트워크도 가능하지만, 현실적으로 메이저 블록체인만큼 많은 노드를 확보한 사례는 많지 않습니다.
• 트래픽 의존성: 일부 DAG는 높은 트랜잭션량이 안정성과 성능에 필요합니다. IOTA의 보안 모델은 많은 정직한 트랜잭션이 상호 승인하며 무게를 쌓는 것에 의존합니다. 활동이 적으면 팁이 빠르게 승인되지 않거나, 공격자가 그래프 일부를 재구성하기 쉬워질 수 있습니다. 반면 전통 블록체인은 트랜잭션이 적어도 채굴자/검증자가 블록을 계속 만들면 안전성이 유지됩니다. 즉, DAG는 부하가 높을 때 강하지만 사용량이 낮으면 성능과 안정성이 저하될 수 있습니다. 이를 보완하기 위해 Coordinator나 백그라운드 트랜잭션을 사용하는 등 조치가 필요합니다.
• 순서 결정과 호환성: DAG는 부분 순서를 생성하기 때문에, 결정적인 순서를 얻기 위한 추가 합의가 복잡합니다. 상태를 갖는 스마트컨트랙트 실행에서는 트랜잭션의 완전한 순서가 필요하며, 충돌이 발생할 경우 모든 노드가 동일한 결론에 도달해야 합니다. Fantom처럼 최종적으로 선형 체인을 만들어 EVM 호환을 유지하는 방식이 있지만, 순수 DAG 위에서 상태를 관리하는 것은 어렵습니다. 기존 블록체인과 상호 운용하려면 추가 메커니즘이 필요합니다.
• 저장소와 동기화: DAG가 많은 병렬 트랜잭션을 허용하면 원장 크기가 빠르게 증가합니다. 보안에 영향을 주지 않는 선에서 오래된 트랜잭션을 프루닝하고, 전체 원장을 저장하지 않고도 검증 가능한 라이트 클라이언트 구조가 필요합니다. 연구에서는 도달성 문제라 부르며, 새로운 트랜잭션이 효율적으로 기존 트랜잭션을 참조할 수 있는지, 안전하게 기록을 축소할 수 있는지가 논의됩니다. 블록체인도 데이터 팽창 문제가 있지만, DAG 구조에서는 잔액 계산이나 부분 증명이 더 복잡해질 수 있습니다.
• 인지도와 네트워크 효과: 기술 외에도 DAG 프로젝트는 블록체인이 우세한 시장에서 신뢰를 얻어야 합니다. 많은 개발자와 사용자가 블록체인에 익숙하며, 기존 체인의 사용자·도구·인프라가 풍부합니다. DAG가 “블록체인 킬러” 같은 과장된 표현을 사용할 경우 회의적 시선을 받기도 합니다. 대규모 사용자 기반이나 “킬러 앱”을 확보하고 실제 가치를 입증하기까지 시간이 필요합니다. 거래소 상장, 커스터디, 지갑 지원 등 인프라 구축도 지속적으로 진행해야 합니다.

요약하면 DAG는 성능 향상을 위해 복잡성을 감수한 구조이며, 합의의 복잡성, 탈중앙화 수준, 신뢰 확보 등에서 도전과제가 있습니다. 연구 커뮤니티는 이러한 문제를 적극적으로 다루고 있으며, 2024년 SoK 논문에서도 다양한 설계와 트레이드오프가 정리되었습니다. 프로젝트가 성숙함에 따라 Coordinator 제거, 개방형 참여, 개발 도구 개선 등이 기대되지만, DAG vs 블록체인을 평가할 때 반드시 고려해야 합니다.

도입 추세와 향후 전망​

DAG 기반 블록체인은 전통적인 체인형 블록체인에 비해 아직 도입 초기 단계입니다. 2025년 현재 DAG를 대규모로 활용하는 퍼블릭 원장은 Hedera Hashgraph, IOTA, Fantom, Nano, Avalanche(일부) 등 소수에 불과합니다. 반면 체인형 블록체인이 여전히 주류입니다. 그러나 산업계와 학계 모두에서 DAG에 대한 관심이 점차 증가하고 있습니다. 주요 트렌드는 다음과 같습니다.

• 프로젝트와 연구 증가: DAG 또는 하이브리드 구조를 탐구하는 프로젝트가 늘고 있습니다. 예를 들어 Aleph Zero는 프라이버시 중심 네트워크로 빠른 순서를 위해 DAG 합의를 사용하고, Sui와 Aptos(Move 기반 체인)는 DAG형 메모리풀이나 병렬 실행 엔진을 도입했습니다. 학술 연구도 활발해 SPECTRE, PHANTOM, GhostDAG 등 새로운 프로토콜이 제안되고, 종합 분석(SoK)도 발표되고 있습니다. 공정성 확보, DAG 프루닝, 동적 환경에서의 보안 등 기존 약점을 해결하려는 연구 성과가 구현에 반영될 전망입니다.
• 하이브리드 모델 확산: 전통 블록체인도 성능 향상을 위해 DAG 개념을 내부적으로 도입하는 추세입니다. Avalanche는 겉보기엔 블록체인이지만, 내부 합의는 DAG 기반입니다. DeFi와 NFT에서 널리 사용되며, 사용자들이 DAG를 의식하지 않고도 빠른 체인을 이용할 수 있음을 보여줍니다. Fantom이 Opera Chain으로 DAG를 내부에 숨기고 개발자에게 친숙한 인터페이스를 제공하듯, 엔진은 DAG, 인터페이스는 체인인 형태가 더 확산될 수 있습니다.
• 기업 및 특수 분야 도입: 높은 처리량, 예측 가능한 비용, 허가형 네트워크에 대한 수용성이 있는 기업은 DAG 원장을 탐색하는 경향이 있습니다. Hedera 평의회 모델은 대기업을 끌어들여 금융자산 토큰화, 소프트웨어 라이선스 추적 등 사례를 추진하고 있습니다. 통신 정산, 광고 노출 추적, 은행 간 송금 같은 컨소시엄도 DAG DLT를 고려합니다. IOTA는 EU 지원 인프라, 디지털 ID 파일럿, 산업 IoT 프로젝트에 참여하고 있으며, 성공 시 업종별 도입으로 이어질 수 있습니다.
• 커뮤니티와 탈중앙화 개선: 초기 DAG 네트워크의 중앙집중적 요소는 점차 개선되고 있습니다. IOTA의 Coordicide가 성공하면 스테이킹과 커뮤니티 검증자를 통한 완전 탈중앙화가 달성됩니다. Hedera는 코드를 오픈소스로 공개했고, 장기적으로 거버넌스 분산을 계획하고 있습니다. Nano 커뮤니티도 대표 노드 분산화를 추진 중입니다. 이러한 움직임은 DAG 네트워크의 신뢰성 제고에 중요하며, Web3 커뮤니티에서의 수용성을 높입니다.
• 상호운용성과 레이어2: DAG는 확장 레이어나 상호운용 네트워크로 활용될 가능성도 있습니다. 예를 들어 DAG 원장을 고속 레이어2로 사용하고, 주기적으로 이더리움에 결과를 앵커링할 수 있습니다. 혹은 DAG 네트워크와 기존 블록체인을 브리지로 연결해, 비용이 가장 낮은 곳에서 자산을 이동·거래하는 방식도 가능합니다. 사용자 경험이 원활하다면 DAG에서 거래하면서 베이스 체인에 정산을 맡기는 조합이 가능합니다.
• 미래 전망 – 당분간 보완적 공존: 대다수 옹호자도 DAG가 블록체인을 완전히 대체하기보다는 보완적 대안이라고 인정합니다. 가까운 미래에는 블록체인과 DAG가 각기 강점을 살리는 이종 네트워크 환경이 이어질 것입니다. DAG는 마이크로트랜잭션과 데이터 기록 등 고빈도 백본을 담당하고, 블록체인은 고가치 정산이나 간단하고 견고한 용도에 적합할 수 있습니다. 장기적으로 DAG가 보안과 탈중앙성을 입증한다면 분산원장의 주류가 될 수도 있다는 전망도 있습니다. 특히 에너지 효율이 높아 규제 환경이 친환경 기술을 선호할 때 도입이 촉진될 수 있습니다.
• 커뮤니티 분위기: 일부 커뮤니티는 DAG를 차세대 DLT로 열정적으로 지지합니다. “DAG가 미래이고, 블록체인은 결국 전화 모뎀 같은 구식 기술이 될 것”이라는 주장도 나옵니다. 이러한 기대는 실제 성과로 입증되어야 하며, DAG는 속도와 더불어 탈중앙성과 보안을 희생하지 않음을 보여줘야 합니다.

종합하면, DAG의 미래는 신중하지만 긍정적입니다. 현재는 블록체인이 주류지만, DAG 플랫폼이 특정 분야에서 존재감을 확대하고 있으며 연구를 통해 양측의 장점을 결합한 발전이 예상됩니다. 블록체인은 DAG 개념을 채택하고, DAG는 블록체인의 거버넌스·보안 교훈을 흡수하며 상호 보완적인 생태계를 만들어갈 것입니다. 확장성·보안·탈중앙성의 트릴레마를 해결하기 위해 DAG는 주목해야 할 중요한 축으로 자리매김하고 있습니다.

Hedera의 표현을 빌리면, DAG 기반 원장은 디지털 통화와 분산 기술 진화에서 *“유망한 다음 단계”*입니다. 블록체인을 완전히 대체하는 만능 열쇠는 아니지만, 분산원장 전반을 향상시키는 혁신으로서 함께 발전해 나갈 것입니다.

출처: 본 보고서는 DAG 합의에 관한 학술 연구, IOTA·Hedera Hashgraph·Fantom·Nano 등의 공식 문서/백서, DAG vs 블록체인 비교를 다룬 기술 블로그와 기사 등 신뢰할 수 있는 자료를 기반으로 작성되었습니다. 이러한 참고문헌은 본문의 비교 분석, 장점, 사례 연구를 뒷받침합니다. Web3 연구 커뮤니티의 지속적인 논의 또한, 확장성·보안·탈중앙성 트릴레마 해결을 위해 DAG가 중요한 화두로 남을 것임을 시사합니다.

프라이버시가 공공 인프라가 되고 있습니다. 2025년에 개발자들은 데이터 저장만큼 쉽게 암호화를 수행할 수 있는 도구가 필요합니다. Mysten Labs의 Seal은 바로 그것을 제공합니다—온체인 접근 제어가 있는 탈중앙화 비밀 관리입니다. 이 튜토리얼은 신원 기반 암호화, 임계값 보안, 프로그래밍 가능한 접근 정책을 사용하여 안전한 Web3 애플리케이션을 구축하는 방법을 알려드립니다.

소개: Web3에서 Seal이 중요한 이유​

기존의 클라우드 애플리케이션은 단일 제공업체가 암호화된 데이터에 대한 접근을 제어하는 중앙화된 키 관리 시스템에 의존합니다. 편리하지만, 이는 위험한 단일 장애점을 만듭니다. 제공업체가 손상되거나, 오프라인이 되거나, 접근을 제한하기로 결정하면 데이터에 접근할 수 없거나 취약해집니다.

Seal은 이 패러다임을 완전히 바꿉니다. Sui 블록체인을 위해 Mysten Labs에서 구축한 Seal은 다음을 가능하게 하는 탈중앙화 비밀 관리(DSM) 서비스입니다:

• 신원 기반 암호화 - 콘텐츠가 환경을 떠나기 전에 보호됩니다
• 임계값 암호화 - 키 접근을 여러 독립적인 노드에 분산시킵니다
• 온체인 접근 제어 - 시간 잠금, 토큰 게이팅, 커스텀 인증 로직
• 스토리지 무관 설계 - Walrus, IPFS 또는 모든 스토리지 솔루션과 작동

안전한 메시징 앱, 게이티드 콘텐츠 플랫폼, 시간 잠금 자산 전송을 구축하든, Seal은 필요한 암호화 프리미티브와 접근 제어 인프라를 제공합니다.

시작하기​

전제 조건​

시작하기 전에 다음이 있는지 확인하세요:

• Node.js 18+ 설치
• TypeScript/JavaScript 기본 지식
• 테스트용 Sui 지갑 (Sui Wallet 등)
• 블록체인 개념에 대한 이해

설치​

npm을 통해 Seal SDK를 설치합니다:

npm install @mysten/seal

블록체인 상호작용을 위해 Sui SDK도 필요합니다:

npm install @mysten/sui

프로젝트 설정​

새 프로젝트를 생성하고 초기화합니다:

mkdir seal-tutorial
cd seal-tutorial
npm init -y
npm install @mysten/seal @mysten/sui typescript @types/node

간단한 TypeScript 구성을 생성합니다:

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

핵심 개념: Seal 작동 방식​

코드를 작성하기 전에 Seal의 아키텍처를 이해해 봅시다:

1. 신원 기반 암호화 (IBE)​

공개 키로 암호화하는 전통적인 암호화와 달리, IBE는 신원(이메일 주소나 Sui 주소 등)으로 암호화할 수 있게 해줍니다. 수신자는 해당 신원을 제어한다는 것을 증명할 수 있을 때만 복호화할 수 있습니다.

2. 임계값 암호화​

단일 키 서버를 신뢰하는 대신, Seal은 t-of-n 임계값 체계를 사용합니다. 5개 중 3개 키 서버를 구성할 수 있으며, 이는 3개 서버가 협력하여 복호화 키를 제공할 수 있지만 2개 이하로는 불가능함을 의미합니다.

3. 온체인 접근 제어​

접근 정책은 Sui 스마트 컨트랙트에 의해 시행됩니다. 키 서버가 복호화 키를 제공하기 전에 요청자가 온체인 정책 요구사항(토큰 소유권, 시간 제약 등)을 충족하는지 확인합니다.

4. 키 서버 네트워크​

분산된 키 서버들이 접근 정책을 검증하고 복호화 키를 생성합니다. 이 서버들은 단일 제어점이 없도록 다른 당사자들에 의해 운영됩니다.

기본 구현: 첫 번째 Seal 애플리케이션​

Sui 블록체인 정책을 통해 민감한 데이터를 암호화하고 접근을 제어하는 간단한 애플리케이션을 구축해 봅시다.

1단계: Seal 클라이언트 초기화​

// src/seal-client.ts
import { SealClient } from '@mysten/seal';
import { SuiClient } from '@mysten/sui/client';

export async function createSealClient() {
  // 테스트넷용 Sui 클라이언트 초기화
  const suiClient = new SuiClient({
    url: 'https://fullnode.testnet.sui.io'
  });

  // 테스트넷 키 서버로 Seal 클라이언트 구성
  const sealClient = new SealClient({
    suiClient,
    keyServers: [
      'https://keyserver1.seal-testnet.com',
      'https://keyserver2.seal-testnet.com',
      'https://keyserver3.seal-testnet.com'
    ],
    threshold: 2, // 3개 중 2개 임계값
    network: 'testnet'
  });

  return { sealClient, suiClient };
}

2단계: 간단한 암호화/복호화​

// src/basic-encryption.ts
import { createSealClient } from './seal-client';

async function basicExample() {
  const { sealClient } = await createSealClient();

  // 암호화할 데이터
  const sensitiveData = "이것은 내 비밀 메시지입니다!";
  const recipientAddress = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  try {
    // 특정 Sui 주소로 데이터 암호화
    const encryptedData = await sealClient.encrypt({
      data: Buffer.from(sensitiveData, 'utf-8'),
      recipientId: recipientAddress,
      // 선택적: 메타데이터 추가
      metadata: {
        contentType: 'text/plain',
        timestamp: Date.now()
      }
    });

    console.log('암호화된 데이터:', {
      ciphertext: encryptedData.ciphertext.toString('base64'),
      encryptionId: encryptedData.encryptionId
    });

    // 나중에 데이터 복호화 (적절한 인증 필요)
    const decryptedData = await sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientAddress
    });

    console.log('복호화된 데이터:', decryptedData.toString('utf-8'));

  } catch (error) {
    console.error('암호화/복호화 실패:', error);
  }
}

basicExample();

Sui 스마트 컨트랙트를 통한 접근 제어​

Seal의 진정한 힘은 프로그래밍 가능한 접근 제어에서 나옵니다. 특정 시간 이후에만 데이터를 복호화할 수 있는 시간 잠금 암호화 예제를 만들어 봅시다.

1단계: 접근 제어 컨트랙트 배포​

먼저 접근 정책을 정의하는 Move 스마트 컨트랙트가 필요합니다:

// contracts/time_lock.move
module time_lock::policy {
    use sui::clock::{Self, Clock};
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};

    public struct TimeLockPolicy has key, store {
        id: UID,
        unlock_time: u64,
        authorized_user: address,
    }

    public fun create_time_lock(
        unlock_time: u64,
        authorized_user: address,
        ctx: &mut TxContext
    ): TimeLockPolicy {
        TimeLockPolicy {
            id: object::new(ctx),
            unlock_time,
            authorized_user,
        }
    }

    public fun can_decrypt(
        policy: &TimeLockPolicy,
        user: address,
        clock: &Clock
    ): bool {
        let current_time = clock::timestamp_ms(clock);
        policy.authorized_user == user && current_time >= policy.unlock_time
    }
}

2단계: Seal과 통합​

// src/time-locked-encryption.ts
import { createSealClient } from './seal-client';
import { TransactionBlock } from '@mysten/sui/transactions';

async function createTimeLocked() {
  const { sealClient, suiClient } = await createSealClient();

  // Sui에서 접근 정책 생성
  const txb = new TransactionBlock();

  const unlockTime = Date.now() + 60000; // 1분 후 잠금 해제
  const authorizedUser = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  txb.moveCall({
    target: 'time_lock::policy::create_time_lock',
    arguments: [
      txb.pure(unlockTime),
      txb.pure(authorizedUser)
    ]
  });

  // 정책 생성을 위한 트랜잭션 실행
  const result = await suiClient.signAndExecuteTransactionBlock({
    transactionBlock: txb,
    signer: yourKeypair, // 당신의 Sui keypair
  });

  const policyId = result.objectChanges?.find(
    change => change.type === 'created'
  )?.objectId;

  // 이제 이 정책으로 암호화
  const sensitiveData = "이것은 1분 후에 잠금 해제됩니다!";

  const encryptedData = await sealClient.encrypt({
    data: Buffer.from(sensitiveData, 'utf-8'),
    recipientId: authorizedUser,
    accessPolicy: {
      policyId,
      policyType: 'time_lock'
    }
  });

  console.log('시간 잠금 데이터가 생성되었습니다. 1분 후에 복호화를 시도해보세요.');

  return {
    encryptedData,
    policyId,
    unlockTime
  };
}

실용적인 예제​

예제 1: 보안 메시징 애플리케이션​

// src/secure-messaging.ts
import { createSealClient } from './seal-client';

class SecureMessenger {
  private sealClient: any;

  constructor(sealClient: any) {
    this.sealClient = sealClient;
  }

  async sendMessage(
    message: string,
    recipientAddress: string,
    senderKeypair: any
  ) {
    const messageData = {
      content: message,
      timestamp: Date.now(),
      sender: senderKeypair.toSuiAddress(),
      messageId: crypto.randomUUID()
    };

    const encryptedMessage = await this.sealClient.encrypt({
      data: Buffer.from(JSON.stringify(messageData), 'utf-8'),
      recipientId: recipientAddress,
      metadata: {
        type: 'secure_message',
        sender: senderKeypair.toSuiAddress()
      }
    });

    // 탈중앙화 스토리지(Walrus)에 암호화된 메시지 저장
    return this.storeOnWalrus(encryptedMessage);
  }

  async readMessage(encryptionId: string, recipientKeypair: any) {
    // 스토리지에서 검색
    const encryptedData = await this.retrieveFromWalrus(encryptionId);

    // Seal로 복호화
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    return JSON.parse(decryptedData.toString('utf-8'));
  }

  private async storeOnWalrus(data: any) {
    // Walrus 스토리지와의 통합
    // 이는 암호화된 데이터를 Walrus에 업로드하고
    // 검색을 위한 blob ID를 반환합니다
  }

  private async retrieveFromWalrus(blobId: string) {
    // blob ID를 사용하여 Walrus에서 암호화된 데이터 검색
  }
}

예제 2: 토큰 게이티드 콘텐츠 플랫폼​

// src/gated-content.ts
import { createSealClient } from './seal-client';

class ContentGating {
  private sealClient: any;
  private suiClient: any;

  constructor(sealClient: any, suiClient: any) {
    this.sealClient = sealClient;
    this.suiClient = suiClient;
  }

  async createGatedContent(
    content: string,
    requiredNftCollection: string,
    creatorKeypair: any
  ) {
    // NFT 소유권 정책 생성
    const accessPolicy = await this.createNftPolicy(
      requiredNftCollection,
      creatorKeypair
    );

    // NFT 접근 요구사항으로 콘텐츠 암호화
    const encryptedContent = await this.sealClient.encrypt({
      data: Buffer.from(content, 'utf-8'),
      recipientId: 'nft_holders', // NFT 보유자를 위한 특별한 수신자
      accessPolicy: {
        policyId: accessPolicy.policyId,
        policyType: 'nft_ownership'
      }
    });

    return {
      contentId: encryptedContent.encryptionId,
      accessPolicy: accessPolicy.policyId
    };
  }

  async accessGatedContent(
    contentId: string,
    userAddress: string,
    userKeypair: any
  ) {
    // 먼저 NFT 소유권 확인
    const hasAccess = await this.verifyNftOwnership(
      userAddress,
      contentId
    );

    if (!hasAccess) {
      throw new Error('접근 거부: 필요한 NFT를 찾을 수 없습니다');
    }

    // 콘텐츠 복호화
    const decryptedContent = await this.sealClient.decrypt({
      encryptionId: contentId,
      recipientId: userAddress
    });

    return decryptedContent.toString('utf-8');
  }

  private async createNftPolicy(collection: string, creator: any) {
    // NFT 소유권을 확인하는 Move 컨트랙트 생성
    // 정책 객체 ID 반환
  }

  private async verifyNftOwnership(user: string, contentId: string) {
    // 사용자가 필요한 NFT를 소유하는지 확인
    // NFT 소유권을 위해 Sui 쿼리
  }
}

예제 3: 시간 잠금 자산 전송​

// src/time-locked-transfer.ts
import { createSealClient } from './seal-client';

async function createTimeLockTransfer(
  assetData: any,
  recipientAddress: string,
  unlockTimestamp: number,
  senderKeypair: any
) {
  const { sealClient, suiClient } = await createSealClient();

  // Sui에서 시간 잠금 정책 생성
  const timeLockPolicy = await createTimeLockPolicy(
    unlockTimestamp,
    recipientAddress,
    senderKeypair,
    suiClient
  );

  // 자산 전송 데이터 암호화
  const transferData = {
    asset: assetData,
    recipient: recipientAddress,
    unlockTime: unlockTimestamp,
    transferId: crypto.randomUUID()
  };

  const encryptedTransfer = await sealClient.encrypt({
    data: Buffer.from(JSON.stringify(transferData), 'utf-8'),
    recipientId: recipientAddress,
    accessPolicy: {
      policyId: timeLockPolicy.policyId,
      policyType: 'time_lock'
    }
  });

  console.log(`자산이 ${new Date(unlockTimestamp)}까지 잠겼습니다`);

  return {
    transferId: encryptedTransfer.encryptionId,
    unlockTime: unlockTimestamp,
    policyId: timeLockPolicy.policyId
  };
}

async function claimTimeLockTransfer(
  transferId: string,
  recipientKeypair: any
) {
  const { sealClient } = await createSealClient();

  try {
    const decryptedData = await sealClient.decrypt({
      encryptionId: transferId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    const transferData = JSON.parse(decryptedData.toString('utf-8'));

    // 자산 전송 처리
    console.log('자산 전송이 잠금 해제되었습니다:', transferData);

    return transferData;
  } catch (error) {
    console.error('전송이 아직 잠금 해제되지 않았거나 접근이 거부되었습니다:', error);
    throw error;
  }
}

Walrus 탈중앙화 스토리지와의 통합​

Seal은 Sui의 탈중앙화 스토리지 솔루션인 Walrus와 원활하게 작동합니다. 두 가지를 모두 통합하는 방법은 다음과 같습니다:

// src/walrus-integration.ts
import { createSealClient } from './seal-client';

class SealWalrusIntegration {
  private sealClient: any;
  private walrusClient: any;

  constructor(sealClient: any, walrusClient: any) {
    this.sealClient = sealClient;
    this.walrusClient = walrusClient;
  }

  async storeEncryptedData(
    data: Buffer,
    recipientAddress: string,
    accessPolicy?: any
  ) {
    // Seal로 암호화
    const encryptedData = await this.sealClient.encrypt({
      data,
      recipientId: recipientAddress,
      accessPolicy
    });

    // Walrus에 암호화된 데이터 저장
    const blobId = await this.walrusClient.store(
      encryptedData.ciphertext
    );

    // Seal과 Walrus 정보를 모두 포함하는 참조 반환
    return {
      blobId,
      encryptionId: encryptedData.encryptionId,
      accessPolicy: encryptedData.accessPolicy
    };
  }

  async retrieveAndDecrypt(
    blobId: string,
    encryptionId: string,
    userKeypair: any
  ) {
    // Walrus에서 검색
    const encryptedData = await this.walrusClient.retrieve(blobId);

    // Seal로 복호화
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData,
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });

    return decryptedData;
  }
}

// 사용 예제
async function walrusExample() {
  const { sealClient } = await createSealClient();
  const walrusClient = new WalrusClient('https://walrus-testnet.sui.io');

  const integration = new SealWalrusIntegration(sealClient, walrusClient);

  const fileData = Buffer.from('중요한 문서 내용');
  const recipientAddress = '0x...';

  // 암호화된 상태로 저장
  const result = await integration.storeEncryptedData(
    fileData,
    recipientAddress
  );

  console.log('Blob ID로 저장됨:', result.blobId);

  // 나중에 검색하고 복호화
  const decrypted = await integration.retrieveAndDecrypt(
    result.blobId,
    result.encryptionId,
    recipientKeypair
  );

  console.log('검색된 데이터:', decrypted.toString());
}

임계값 암호화 고급 구성​

프로덕션 애플리케이션의 경우 여러 키 서버와 함께 사용자 정의 임계값 암호화를 구성하고 싶을 것입니다:

// src/advanced-threshold.ts
import { SealClient } from '@mysten/seal';

async function setupProductionSeal() {
  // 여러 독립적인 키 서버로 구성
  const keyServers = [
    'https://keyserver-1.your-org.com',
    'https://keyserver-2.partner-org.com',
    'https://keyserver-3.third-party.com',
    'https://keyserver-4.backup-provider.com',
    'https://keyserver-5.fallback.com'
  ];

  const sealClient = new SealClient({
    keyServers,
    threshold: 3, // 5개 중 3개 임계값
    network: 'mainnet',
    // 고급 옵션
    retryAttempts: 3,
    timeoutMs: 10000,
    backupKeyServers: [
      'https://backup-1.emergency.com',
      'https://backup-2.emergency.com'
    ]
  });

  return sealClient;
}

async function robustEncryption() {
  const sealClient = await setupProductionSeal();

  const criticalData = "미션 크리티컬 암호화된 데이터";

  // 높은 보안 보장으로 암호화
  const encrypted = await sealClient.encrypt({
    data: Buffer.from(criticalData, 'utf-8'),
    recipientId: '0x...',
    // 최대 보안을 위해 모든 5개 서버 필요
    customThreshold: 5,
    // 중복성 추가
    redundancy: 2,
    accessPolicy: {
      // 다중 인증 요구사항
      requirements: ['nft_ownership', 'time_lock', 'multisig_approval']
    }
  });

  return encrypted;
}

보안 모범 사례​

1. 키 관리​

// src/security-practices.ts

// 좋은 방법: 안전한 키 유도 사용
import { generateKeypair } from '@mysten/sui/cryptography/ed25519';

const keypair = generateKeypair();

// 좋은 방법: 키를 안전하게 저장 (환경 변수 예제)
const keypair = Ed25519Keypair.fromSecretKey(
  process.env.PRIVATE_KEY
);

// 나쁜 방법: 키를 하드코딩하지 마세요
const badKeypair = Ed25519Keypair.fromSecretKey(
  "hardcoded-secret-key-12345" // 이렇게 하지 마세요!
);

2. 접근 정책 검증​

// 암호화 전에 항상 접근 정책 검증
async function secureEncrypt(data: Buffer, recipient: string) {
  const { sealClient } = await createSealClient();

  // 수신자 주소 검증
  if (!isValidSuiAddress(recipient)) {
    throw new Error('유효하지 않은 수신자 주소');
  }

  // 정책이 존재하고 유효한지 확인
  const policy = await validateAccessPolicy(policyId);
  if (!policy.isValid) {
    throw new Error('유효하지 않은 접근 정책');
  }

  return sealClient.encrypt({
    data,
    recipientId: recipient,
    accessPolicy: policy
  });
}

3. 오류 처리 및 대체 방안​

// 견고한 오류 처리
async function resilientDecrypt(encryptionId: string, userKeypair: any) {
  const { sealClient } = await createSealClient();

  try {
    return await sealClient.decrypt({
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });
  } catch (error) {
    if (error.code === 'ACCESS_DENIED') {
      throw new Error('접근 거부: 권한을 확인하세요');
    } else if (error.code === 'KEY_SERVER_UNAVAILABLE') {
      // 백업 구성으로 재시도
      return await retryWithBackupServers(encryptionId, userKeypair);
    } else if (error.code === 'THRESHOLD_NOT_MET') {
      throw new Error('사용 가능한 키 서버가 부족합니다');
    } else {
      throw new Error(`복호화 실패: ${error.message}`);
    }
  }
}

4. 데이터 검증​

// 암호화 전에 데이터 검증
function validateDataForEncryption(data: Buffer): boolean {
  // 크기 제한 확인
  if (data.length > 1024 * 1024) { // 1MB 제한
    throw new Error('암호화하기에 데이터가 너무 큽니다');
  }

  // 민감한 패턴 확인 (선택사항)
  const dataStr = data.toString();
  if (containsSensitivePatterns(dataStr)) {
    console.warn('경고: 데이터에 잠재적으로 민감한 패턴이 포함되어 있습니다');
  }

  return true;
}

성능 최적화​

1. 작업 일괄 처리​

// 효율성을 위해 여러 암호화를 일괄 처리
async function batchEncrypt(dataItems: Buffer[], recipients: string[]) {
  const { sealClient } = await createSealClient();

  const promises = dataItems.map((data, index) =>
    sealClient.encrypt({
      data,
      recipientId: recipients[index]
    })
  );

  return Promise.all(promises);
}

2. 키 서버 응답 캐싱​

// 지연 시간을 줄이기 위해 키 서버 세션 캐시
class OptimizedSealClient {
  private sessionCache = new Map();

  async encryptWithCaching(data: Buffer, recipient: string) {
    let session = this.sessionCache.get(recipient);

    if (!session || this.isSessionExpired(session)) {
      session = await this.createNewSession(recipient);
      this.sessionCache.set(recipient, session);
    }

    return this.encryptWithSession(data, session);
  }
}

Seal 통합 테스트​

단위 테스트​

// tests/seal-integration.test.ts
import { describe, it, expect } from 'jest';
import { createSealClient } from '../src/seal-client';

describe('Seal 통합', () => {
  it('데이터를 성공적으로 암호화하고 복호화해야 합니다', async () => {
    const { sealClient } = await createSealClient();
    const testData = Buffer.from('테스트 메시지');
    const recipient = '0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8';

    const encrypted = await sealClient.encrypt({
      data: testData,
      recipientId: recipient
    });

    expect(encrypted.encryptionId).toBeDefined();
    expect(encrypted.ciphertext).toBeDefined();

    const decrypted = await sealClient.decrypt({
      ciphertext: encrypted.ciphertext,
      encryptionId: encrypted.encryptionId,
      recipientId: recipient
    });

    expect(decrypted.toString()).toBe('테스트 메시지');
  });

  it('접근 제어 정책을 시행해야 합니다', async () => {
    // 인증되지 않은 사용자는 복호화할 수 없음을 테스트
    const { sealClient } = await createSealClient();

    const encrypted = await sealClient.encrypt({
      data: Buffer.from('비밀'),
      recipientId: 'authorized-user'
    });

    await expect(
      sealClient.decrypt({
        ciphertext: encrypted.ciphertext,
        encryptionId: encrypted.encryptionId,
        recipientId: 'unauthorized-user'
      })
    ).rejects.toThrow('접근 거부');
  });
});

프로덕션 배포​

환경 구성​

// config/production.ts
export const productionConfig = {
  keyServers: [
    process.env.KEY_SERVER_1,
    process.env.KEY_SERVER_2,
    process.env.KEY_SERVER_3,
    process.env.KEY_SERVER_4,
    process.env.KEY_SERVER_5
  ],
  threshold: 3,
  network: 'mainnet',
  suiRpc: process.env.SUI_RPC_URL,
  walrusGateway: process.env.WALRUS_GATEWAY,
  // 보안 설정
  maxDataSize: 1024 * 1024, // 1MB
  sessionTimeout: 3600000, // 1시간
  retryAttempts: 3
};

모니터링 및 로깅​

// utils/monitoring.ts
export class SealMonitoring {
  static logEncryption(encryptionId: string, recipient: string) {
    console.log(`[SEAL] ${recipient}에 대해 데이터 ${encryptionId} 암호화됨`);
    // 모니터링 서비스로 전송
  }

  static logDecryption(encryptionId: string, success: boolean) {
    console.log(`[SEAL] 복호화 ${encryptionId}: ${success ? '성공' : '실패'}`);
  }

  static logKeyServerHealth(serverUrl: string, status: string) {
    console.log(`[SEAL] 키 서버 ${serverUrl}: ${status}`);
  }
}

리소스 및 다음 단계​

공식 문서​

• Seal 문서: https://seal-docs.wal.app/
• GitHub 저장소: https://github.com/MystenLabs/seal
• Sui 문서: https://docs.sui.io/
• Walrus 문서: https://docs.wal.app/

커뮤니티 및 지원​

• Sui Discord: 커뮤니티 지원을 위한 #seal 채널 참여
• GitHub Issues: 버그 신고 및 기능 요청
• 개발자 포럼: 토론을 위한 Sui 커뮤니티 포럼

탐구할 고급 주제​

1. 커스텀 접근 정책: Move 컨트랙트로 복잡한 인증 로직 구축
2. 크로스 체인 통합: 다른 블록체인 네트워크와 함께 Seal 사용
3. 엔터프라이즈 키 관리: 자체 키 서버 인프라 설정
4. 감사 및 컴플라이언스: 규제 환경을 위한 로깅 및 모니터링 구현

샘플 애플리케이션​

• 보안 채팅 앱: Seal을 사용한 엔드 투 엔드 암호화 메시징
• 문서 관리: 접근 제어가 있는 엔터프라이즈 문서 공유
• 디지털 권한 관리: 사용 정책이 있는 콘텐츠 배포
• 프라이버시 보존 분석: 암호화된 데이터 처리 워크플로우

결론​

Seal은 Web3에서 프라이버시와 암호화를 인프라 수준의 관심사로 만드는 근본적인 변화를 나타냅니다. 신원 기반 암호화, 임계값 보안, 프로그래밍 가능한 접근 제어를 결합하여 개발자들에게 진정으로 안전하고 탈중앙화된 애플리케이션을 구축할 수 있는 강력한 도구를 제공합니다.

Seal로 구축하는 주요 장점은 다음과 같습니다:

• 단일 장애점 없음: 분산된 키 서버가 중앙 권한을 제거
• 프로그래밍 가능한 보안: 스마트 컨트랙트 기반 접근 정책이 유연한 인증 제공
• 개발자 친화적: TypeScript SDK가 기존 Web3 도구와 원활하게 통합
• 스토리지 무관: Walrus, IPFS 또는 모든 스토리지 솔루션과 작동
• 프로덕션 준비: 엔터프라이즈 보안 표준으로 Mysten Labs에서 구축

사용자 데이터 보안, 구독 모델 구현, 복잡한 다자간 애플리케이션 구축 등 무엇을 하든, Seal은 자신감을 가지고 구축하는 데 필요한 암호화 프리미티브와 접근 제어 인프라를 제공합니다.

오늘부터 구축을 시작하고, 프라이버시를 공공 인프라의 기본 부분으로 만드는 개발자들의 성장하는 생태계에 참여하세요.

구축을 시작할 준비가 되셨나요? @mysten/seal을 설치하고 이 튜토리얼의 예제로 실험을 시작하세요. 탈중앙화 웹은 프라이버시와 보안을 우선시하는 애플리케이션을 기다리고 있습니다.

소개​

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 스왑, 청산, 차익거래 기회는 순서 의존적 수익을 가집니다. 그들의 결과와 수익성은 다른 트랜잭션과의 관계에서 블록 내 어디에 위치하는지에 따라 변합니다. 이것은 순서를 제어하는 자에게 고위험 게임을 만듭니다.