본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 01. 15:18

다중 레그 거래의 원자성 (Atomicity): 하나의 preimage가 세 개의 레그를 동시에 결제해야 할 때

요약

자율 에이전트가 수행하는 다중 단계(multi-leg) 거래에서 발생하는 원자성 결여 문제를 다룹니다. 중간 단계에서 자산이 고립되거나 가격 리스크에 노출되는 '결제 후 희망하기' 방식의 위험성을 지적하고, 전체 경로를 하나의 운명으로 묶는 원자적 거래의 필요성을 설명합니다.

핵심 포인트

  • 다중 홉 거래 시 인벤토리, 가격, 상대방 리스크가 복리로 증가함
  • 단일 레그 원자적 스왑만으로는 전체 경로의 안전성을 보장할 수 없음
  • 모든 레그가 성공하거나 모두 취소되는 완전한 원자성 구현이 핵심
  • Hash-time-lock contracts를 활용한 다중 레그 확장 가능성 제시

하나의 자율 에이전트(Autonomous agent)가 3단계(three-leg) 거래를 시작합니다. 첫 번째 레그(Leg one): BTC를 지불하고 ETH를 받습니다. 두 번째 레그(Leg two): 받은 ETH를 두 번째 상대방에게 전달하고 USDC를 받습니다. 세 번째 레그(Leg three): 해당 USDC를 컴퓨팅 예약(compute reservation)을 위해 판매자에게 결제합니다. 첫 번째와 두 번째 레그는 완료되었습니다. 그런데 세 번째 상대방이 응답이 없습니다.

이제 에이전트는 원하지도 않았던 USDC를, 이미 자신에게 불리하게 움직여 버린 가격으로 보유하게 되었으며, 처음 두 레그를 되돌릴 방법도 없습니다. 에이전트는 거래에서 패배한 것이 아닙니다. 자신의 인벤토리(Inventory)에 대한 통제력을 상실한 것입니다.

이것은 단일 레그 원자적 스왑(single-leg atomic swaps)이 해결하지 못하는 실패 모드이며, 자율 에이전트들이 끊임없이 마주치는 문제입니다. 왜냐하면 에이전트의 "거래"는 단 한 번의 홉(hop)인 경우가 드물기 때문입니다. 그것은 하나의 경로(path)입니다. 이 포스트는 전체 경로를 원자적(atomic)으로 만드는 것에 관한 것입니다. 즉, 모든 레그가 결제되거나, 아니면 모든 레그가 취소되어, 누군가가 잘못된 자산을 보유하게 되는 중간 상태가 전혀 남지 않도록 하는 것입니다.

'결제 후 희망하기(Settle-then-hope)'가 기본값이며, 이것이 문제입니다

원자성(atomicity) 없이 오늘날 다중 홉(multi-hop) 거래가 어떻게 실행되는지 살펴보겠습니다. 당신은 첫 번째 레그를 결제합니다. 그다음 두 번째 레그를 "시도"합니다. 그다음 세 번째 레그를 "시도"합니다. 각 "시도"는 새로운 리스크를 동반한 새로운 협상입니다. 이를 '결제 후 희망하기(settle-then-hope)'라고 부릅시다.

모든 중간 홉은 경로를 따라 복리로 쌓이는 세 가지 비용을 수반합니다:

  • 인벤토리 리스크 (Inventory risk). 레그 사이의 단계에서 당신은 보유하고 싶지 않은 자산을 보유하게 됩니다. 마켓 메이킹(market-making) 에이전트에게는 때때로 괜찮을 수 있습니다. 하지만 방향성 경로(directional path)를 실행하는 에이전트에게 이는 순수한 노출(exposure)입니다.
  • 가격 리스크 (Price risk). 경로 중간에 시장이 움직입니다. 처음 시작할 때 세 번째 레그를 가치 있게 만들었던 견적(quote)은 첫 번째와 두 번째 레그가 완료될 때쯤에는 이미 손실 상태(underwater)일 수 있습니다.
  • 상대방 리스크 (Counterparty risk). 위에서 세 번째 상대방이 그랬던 것처럼, 각 레그의 상대방이 단순히 나타나지 않을 수 있습니다. 당신은 도달한 홉 단계에서 고립됩니다.

대부분의 올해 출시되는 자금 결제 인프라는 단일 레그 또는 2자 간 케이스를 매우 잘 최적화합니다. 지급결제(Payment-rail) 청산 및 원자성 OTC 데스크 모두 두 당사자 간의 교환을 안전하게 만듭니다. 이것은 현실적이고 유용합니다. 다중 레그 원자성은 다른 문제입니다. 이는 N개의 상대방에 걸쳐 N개의 레그와 어쩌면 N개의 체인을 하나의 결제 운명으로 묶는 것에 관한 것입니다. 단일 레그를 해결한다고 해서 경로가 해결되는 것은 아닙니다.

핵심 트릭: 모든 레그를 잠그는 비밀 게이트

해시 시간 잠금 계약(Hash-time-lock contracts)은 이미 두 당사자에게 원자성을 제공합니다. A는 hash(s) 뒤에 자금을 잠급니다. B는 동일한 hash(s) 뒤에 해당 자금을 잠급니다. A가 B의 자금을 청구하기 위해 s를 공개할 때, 이 공개는 공공이므로 B도 A의 자금을 청구하는 데 같은 s를 사용합니다. 원자적입니다: s가 공개되어 두 레그가 모두 완료되거나, 시간이 초과된 후 아무도 공개하지 않아 둘 다 환불됩니다.

다중 레그로 확장하는 것은 거의 놀라울 정도로 직접적입니다: 경로의 모든 레그에 걸쳐 동일한 해시 잠금 H = hash(s)를 사용합니다. 단일 사전 이미지(s)가 전체 체인을 잠급니다.

Leg 1: A --BTC--> B (H로 잠김)
Leg 2: B --ETH--> C (H로 잠김)
Leg 3: C --USDC--> D (H로 잠김)
...

어떤 에이전트도 끼일 수 있는 중간

Leg 1 타임아웃: T0 + 12h (가장 김 — A가 가장 먼저 공개하므로, 가장 큰 안전 마진이 필요함)
Leg 2 타임아웃: T0 + 8h
Leg 3 타임아웃: T0 + 4h (가장 짧음 — D가 가장 먼저 청구하며, 위쪽으로 연쇄 반응(cascade)을 트리거함)

하류(downstream) 당사자가 가장 먼저 청구하면 s가 공개되며, 이는 모든 상류(upstream) 당사자가 각자의 환불 창(refund window)이 열리기 전에 청구할 수 있는 충분한 잔여 시간을 제공합니다. 이는 Lightning 결제 라우팅(payment routing)을 작동하게 만드는 것과 동일한 안전 논리이며, 이를 결제 경로에서 이질적인(heterogeneous) 크로스체인(cross-chain) 거래 경로로 일반화한 것입니다.

내재화해야 할 결과: 최악의 경우 자본 잠금(capital lockup) 기간은 사다리의 가장 레그(leg)에 의해 결정되며, 이는 모든 참여자에게 동시에 적용됩니다. 5개의 레그로 구성된 경로는 최상단 단계의 지속 시간 동안 모든 사람의 자본을 잠급니다.

솔직히, 어디서 문제가 발생하는가

만약 우리가 행복한 경로(happy path)만을 설명했다면 이것은 마케팅이었을 것입니다. 이 구조에는 실질적이고 명시적인 한계가 있으며, 이를 사용할지 결정하는 에이전트는 이를 반드시 알아야 합니다:

  • 무료 옵션 문제 (The free-option problem). 비밀값(secret) 보유자는 모든 레그가 잠긴 후 시장 상황을 지켜보고 공개 여부를 선택할 수 있습니다. 이는 변동성 및 잠금 시간(lockup time)에 비례하는 가치를 지닌 무료 옵션입니다. 완화 방법으로는 짧은 타임아웃 창, 비밀값 보유자가 거래 미완료 시 몰수당하는 환불 불가능한 수수료, 또는 예치된 담보(collateral) 등이 있습니다. 하지만 그 어떤 것도 옵션의 가치를 정확히 0으로 만들지는 못합니다.
  • 레그 수에 비례하는 자본 잠금. 모든 레그는 최악의 경우 지속 시간 동안 동시에 잠깁니다. 경로가 길어질수록 유지 비용이 비싸집니다.
  • 활성성 가정 (Liveness assumption). 누군가는 창(window) 내에 s를 공개하기 위해 온라인 상태가 되어야 합니다. 원자성(Atomicity)은 자금을 보호하여 아무도 돈을 잃지 않게 하지만, 악의적인 당사자(griefing party)가 접속을 끊음으로써 전체 경로를 해제(unwind)하도록 강제할 수 있습니다. 즉, 안전성은 보장되지만 완료가 보장되는 것은 아닙.
  • 체인 간 해시 함수 호환성. 크로스체인 경로는 모든 체인이 동일한 preimage의 동일한 해시를 검증할 수 있을 때에만 원자적입니다.

SHA-256은 이식 가능한 선택지입니다. 저렴한 네이티브 해시(native hash)로 Keccak을 사용하는 체인의 레그(leg)는 SHA-256 경로를 명시적으로 필요로 하며, 그렇지 않으면 공유 비밀(shared-secret) 속성이 조용히 깨지게 됩니다.

원자적 다중 레그(Atomic multi-leg)는 에이전트에게 가장 중요한 차원에서 '결제 후 희망하기(settle-then-hope)' 방식보다 엄격하게 더 안전합니다. 즉, 잘못된 자산을 보유한 채 경로 중간에 고립되는 일이 절대 발생하지 않습니다. 하지만 이러한 안전성은 자본 효율성(capital efficiency)과 라이브니스(liveness) 요구사항을 대가로 얻어집니다. 이것이 바로 트레이드오프(trade-off)입니다. 이를 통합하는 모든 이에게 명확하게 고지하십시오.

에이전트가 MCP를 통해 이를 표현하는 방법

이를 MCP 서버 뒤에 배치하는 목적은 에이전트가 개별 홉(hop)을 수동으로 오케스트레이션하는 것이 아니라, 하나의 _경로(path)_를 기술해야 하기 때문입니다. 밀봉 입찰(sealed-bid) RFQ는 전체 레그 세트—자산, 체인, 상대방 슬롯, 그리고 이들을 결합할 단일 해시락(hashlock)—를 포함합니다. 응답자들은 각 레그에 대해 입찰하며, 매칭된 세트는 하나의 H를 공유합니다. 타임락 래더(timelock ladder)는 경로의 길이와 관련된 체인들로부터 도출됩니다. 에이전트는 세 개의 독립적인 결과가 아닌, 하나의 결제 결과에 대해 추론합니다.

오늘날의 정확한 체인 상태 현실은 다음과 같습니다: Ethereum 메인넷은 엔드투엔드(end-to-end)로 가동 중입니다. Bitcoin HTLC는 Signet에서 검증되었으며, 메인넷 적용을 대기 중입니다. Sui 컨트랙트는 배포 및 CLI 테스트를 마쳤으며, 게이트웨이 배선(gateway wiring)이 진행 중입니다. 이 세 가지를 모두 거치는 경로는 오늘날 부분적으로 구축 가능하며, 각 레그가 온라인 상태가 됨에 따라 엔드투엔드로 구축될 수 있습니다. 서두의 예시에서 BTC-to-ETH 레그가 현재 가동 중인 부분입니다. 어떤 홉에서도 브릿지(bridge), 수탁자(custodian)

만약 에이전트(agent)의 다음 거래가 하나의 홉(hop)이 아닌 경로(path)라면, 당신은 어느 레그(leg)에서 고립되는 위험을 감수하시겠습니까?

문서 및 MCP 도구 안내: hashlock.markets/docs. 프로토콜 설계 및 거래량 방법론: hashlock.markets/methodology. MCP 서버: hashlock-tech/mcp (scoped). 코드: Hashlock-Tech/hashlock-mcp. 암호학적 기초는 SSRN의 백서(whitepaper)에 기술되어 있습니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0