크로스체인 스왑이 안전하게 정산되려면 무엇이 필요할까요?

목차

• HTLC에는 두 가지 경로가 있습니다.
• 그 비밀은 두 사슬을 연결한다
• 타임록 순서가 핵심입니다.
• 주문이 잘못되면 어떡하죠?
• 안전창이 중요한 이유
• 옴니스톤이 제공하는 것
• 합의에 앞서 증거 수집이 이루어집니다.
• 1. 거래를 찾으세요
• 2. 거래를 정산하세요
• 크로스체인 스왑에 시간이 더 오래 걸리는 이유는 무엇일까요?
• TON이 또 다른 차원을 더합니다
• 원자성에는 실질적인 비용이 따른다
• 일이 잘못되면 어떻게 될까요?
• 적합한 견적이 없습니다
• 사용자가 계속 진행하지 않습니다
• 무역이 중단되었다
• 네트워크 혼잡
• 체인 재구성
• 모든 것이 정상 작동합니다
• 더 큰 교훈
• 결론
• 유용한 링크

크로스체인 스왑은 대개 간단하게 설명됩니다. 비밀 키와 타이머를 사용하여 자금을 잠근 다음 거래를 완료하거나 자금을 돌려받는 방식입니다.

그건 맞는 말이지만, 가장 중요한 부분을 놓치고 있어요.

진정한 과제는 두 개의 독립적인 블록체인을 조율하여 어느 쪽도 상대방에게 거래를 완료하거나 자금을 회수할 충분한 시간을 주지 않고는 상대방의 자산을 가져갈 수 없도록 하는 것입니다.

바로 이런 점에서 해시 타임락드 컨트랙트(HTLC)가 등장합니다.

해시락은 동일한 비밀 키를 통해 양측을 연결합니다. 타임락은 청구 및 환불이 발생할 수 있는 시점을 결정합니다.

HTLC에는 두 가지 경로가 있습니다.

HTLC는 잠긴 자금에 두 가지 가능한 결과를 제공합니다.

청구 조건: 수신자가 청구 마감일 전에 정확한 비밀 정보를 제공하는 것.

환불: 기한이 지난 후, 송금인은 계약 규정에 따라 자금을 환불받을 수 있습니다.

간소화된 버전은 다음과 같습니다.

if valid_secret
and claim_window_is_open:
    release_to_receiver

else if refund_time_has_arrived:
    return_to_sender

이것은 예시를 위한 의사 코드이며, STONfi의 실제 운영 환경에서 사용되는 코드가 아닙니다.

중요한 점은 계약서에 두 가지 결과가 모두 사전에 명시되어 있다는 것입니다.

환불은 반드시 절차상의 오류는 아닙니다. 오히려 설계의 일부입니다.

그 비밀은 두 사슬을 연결한다

교환은 무작위로 정해진 비밀로 시작됩니다.

시작자는 비밀 정보를 비공개로 유지하고 해시값만 공개합니다.

secret = generate_random_secret()
hashlock = hash(secret)

publish(hashlock)
keep_private(secret)

나중에 비밀 키가 스왑의 한쪽을 주장하는 데 사용될 때, 해당 키는 온체인에 공개됩니다.

다른 참가자는 동일한 비밀 키를 사용하여 다른 체인에서 해당 HTLC를 청구할 수 있습니다.

이것이 바로 두 개의 독립적인 체인이 서로 직접 통신하지 않고도 협력할 수 있는 방법입니다.

하지만 HTLC는 조건부 지급일 뿐입니다.

크로스체인 스왑을 위해서는 양쪽에 하나씩 필요합니다.

타임록 순서가 핵심입니다.

앨리스가 다른 체인에서 밥으로부터 자산을 얻고 싶어한다고 가정해 봅시다.

두 HTLC 모두 동일한 해시락을 사용하지만 마감 시간은 다릅니다.

목적지 측 마감일은 출발지 측 환불 마감일 보다 빨라야 합니다.

그 시간 간격 덕분에 두 번째 참가자는 비밀이 공개된 후 반응할 시간을 갖게 됩니다.

TIME ───────────────────────────────────────►

Destination HTLC
[──────── claim window ────────| deadline ]

                               ↓
                         secret revealed

Source HTLC
[──────────────────────────────| deadline ]

                         reaction window

정확한 소요 시간은 체인과 해당 체인의 확인 가정에 따라 달라집니다.

원칙은 변하지 않습니다.

마감 시한이 늦춰진 것은 비밀이 공개된 후 조치를 취해야 하는 참가자를 보호하기 위한 것입니다.

주문이 잘못되면 어떡하죠?

앨리스의 원래 잠금이 먼저 만료된다고 가정해 봅시다.

앨리스는 자신의 돈을 환불할 수 있습니다.

하지만 그녀는 여전히 그 비밀을 알고 있다.

밥의 HTLC가 계속 활성화되어 있다면, 앨리스는 그 비밀을 폭로하고 나중에 밥의 자산을 차지할 가능성이 있습니다.

해시락은 실패하지 않았습니다.

마감 시한 설정은 그렇게 되었습니다.

그렇기 때문에 두 타임록 간의 관계는 아토믹 스왑에서 가장 중요한 부분 중 하나입니다.

안전창이 중요한 이유

비밀이 밝혀진 후, 상대방은 다음과 같은 시간을 필요로 합니다.

• 거래를 감지하세요
• 비밀을 읽어보세요
• 주장을 생성하고 전파하세요
• 확인을 기다리세요
• 혼잡 또는 최종 결과 지연을 처리합니다.

따라서 현실적인 네트워크 환경을 고려했을 때 마감 시간 간격은 충분히 커야 합니다.

규모가 너무 작으면 거래 지연으로 불필요한 위험이 발생할 수 있습니다.

규모가 너무 크면 자본이 필요 이상으로 오랫동안 묶이게 됩니다.

따라서 시간 제한은 단순히 계약서에 추가되는 숫자가 아니라 엔지니어링 결정 사항입니다.

옴니스톤이 제공하는 것

HTLC는 결제 문제를 해결합니다.

그것들은 시장 문제를 해결하지 못합니다.

거래 상대방은 누구이며, 어떤 조건으로 제공하는가?

바로 이 부분에서 옴니스톤은 또 다른 차원을 더합니다.

STONfi는 Omniston을 RFQ 기반 시스템으로 설명하며, 사용자를 유동성 소스 및 스왑 실행을 위한 리졸버와 연결합니다. 크로스체인 경로의 경우, HTLC 기반 아토믹 스왑을 통해 결제를 처리할 수 있습니다. STONfi Omniston 문서를 참조하십시오.

간략화된 흐름은 다음과 같습니다.

User request
     ↓
RFQ
     ↓
Resolvers / liquidity sources
     ↓
Available quotes
     ↓
Selected route
     ↓
Settlement

이는 거래를 찾는 것과 거래를 결제하는 것을 구분하는 것입니다 .

합의에 앞서 증거 수집이 이루어집니다.

크게 두 단계로 나뉩니다.

1. 거래를 찾으세요

사용자가 견적을 요청합니다.

해결사는 사용 가능한 조건을 제시하며 응답할 수 있습니다.

적합한 대안을 찾지 못하면, 정산이 시작되지 않았으므로 HTLC 환불 없이 요청이 만료될 수 있습니다.

2. 거래를 정산하세요

경로가 선택되면 크로스체인 정산이 시작됩니다.

견적 마감일과 HTLC 마감일은 서로 다른 역할을 하기 때문에 이러한 구분이 중요합니다.

견적은 제시된 가격이 유효한 기간을 결정합니다.

타임락은 자금이 결제 단계에 들어간 후 발생하는 상황을 결정합니다.

크로스체인 스왑에 시간이 더 오래 걸리는 이유는 무엇일까요?

동일 체인 스왑은 하나의 블록체인 환경 내에서 작동합니다.

크로스체인 스왑은 두 개의 독립적인 체인을 조정해야 합니다.

두 체인은 하나의 거래 상태를 공유하지 않으므로, 정산 프로세스에서는 한 체인의 이벤트가 다른 체인에서 관찰 가능하고 조치 가능한 상태가 되기까지 시간이 필요합니다.

즉, 추가 대기 시간 중 일부는 보안 모델의 일부라는 뜻입니다.

절충점은 간단합니다.

체인 간 협업이 많을수록 시간이 더 많이 걸립니다.

TON이 또 다른 차원을 더합니다

TON은 비동기 메시지 전달을 사용하므로 계약 상호 작용으로 인해 추가 메시지와 상태 변화가 발생할 수 있습니다.

간소화된 STONfi 워크플로는 다음과 같습니다.

User
  ↓
Jetton wallet
  ↓
Router
  ↓
Pool
  ↓
Settlement

크로스체인 거래는 해당 흐름에 또 다른 블록체인과 자체 확인 프로세스를 추가합니다.

따라서 무역을 다음과 같이 생각하기보다는 일련의 상태로 생각하는 것이 더 좋습니다.

submit transaction → instantly finished

정확한 거래 추적은 최초 거래 이후에도 결제가 계속될 수 있기 때문에 중요합니다.

원자성에는 실질적인 비용이 따른다

HTLC가 제공하는 보안에는 단점이 따릅니다.

지연 시간: 사용자는 확인 절차와 시간 잠금 보안 시간 동안 기다려야 할 수 있습니다.

자본 동결: 거래가 진행되는 동안 리졸버 자본은 계속 투입될 수 있습니다.

거래 비용: 청구 및 환불에는 거래가 필요하며 네트워크 수수료가 발생할 수 있습니다.

거래 중단: 참여자가 응답을 중단하면 다른 참여자의 자본이 일시적으로 묶이게 됩니다.

HTLC는 원고를 보호하지만 모든 경제적 비용을 없애지는 않습니다.

일이 잘못되면 어떻게 될까요?

적합한 견적이 없습니다

요청 기간이 만료되었습니다.

HTLC가 생성되지 않았으므로 환불할 사항이 없습니다.

사용자가 계속 진행하지 않습니다

견적 기간이 결제 시작 전에 만료되면 사용자는 다른 견적을 요청할 수 있습니다.

무역이 중단되었다

HTLC는 결국 환불 조건을 충족하게 되며, 이에 따라 계약 규정에 따라 관련 자금을 회수할 수 있습니다.

네트워크 혼잡

시간차는 비밀이 공개된 후 두 번째 참여자가 소유권을 주장할 시간을 제공합니다.

해당 기간이 충분한지는 마감일을 설정할 때 사용된 가정에 따라 달라집니다.

체인 재구성

최종 정산은 참여 체인들의 확인 및 확정 여부에 따라 달라집니다.

안전범위는 현실적인 조건을 고려해야 합니다.

모든 것이 정상 작동합니다

사용자는 목적지 자산을 획득하는 과정에서 비밀을 공개합니다.

리졸버는 비밀 키를 확인하고 이를 사용하여 다른 체인에서 해당 자산을 확보합니다.

양측은 인간 관리자의 승인 없이 합의에 도달했습니다.

더 큰 교훈

HTLC에서 중요한 부분은 단순히 해시락이나 타이머만이 아닙니다.

이것이 바로 두 개의 HTLC가 함께 작동하는 방식입니다 .

해시락은 거래들을 연결합니다.

그 비밀은 양측이 관찰할 수 있는 사건을 만들어낸다.

마감일을 분산시키면 대응할 수 있는 시간이 생깁니다.

환불 조건에는 미리 정의된 복구 경로가 제공됩니다.

Omniston은 RFQ 및 리졸버 모델을 통해 거래 발굴을 처리함으로써 또 다른 차원의 기능을 추가합니다.

그러니까 두 가지 별개의 질문이 있습니다.

HTLC 거래는 어떻게 안전하게 결제될 수 있을까요?

옴니스톤: 시스템은 어떻게 유동성을 찾아 거래를 실행할 수 있나요?

이러한 문제들을 분리해 놓으면 아키텍처를 더 쉽게 이해할 수 있습니다.

결론

자금이 해시락 뒤에 배치된다는 이유만으로 크로스체인 스왑이 신뢰 최소화되는 것은 아닙니다.

타이밍 또한 매우 중요합니다.

두 HTLC(고위험군)는 비밀을 공개했을 때 상대방이 합의의 자기쪽 부분을 완료할 충분한 시간을 확보할 수 있도록 마감일을 정해야 합니다.

이는 실질적인 상충 관계를 야기합니다. 추가적인 시간 소요, 일시적인 자본 묶임, 거래 수수료 발생, 그리고 혼잡 및 최종성 문제를 고려해야 할 필요성 등이 그것입니다.

Omniston은 RFQ 기반 검색 및 해결사를 통해 시장 계층을 추가하고, HTLC는 지원되는 크로스체인 흐름에 대한 결제 메커니즘을 제공합니다.

핵심 아이디어는 간단합니다.

훌륭한 결제 시스템은 성공을 위한 명확한 경로와 실패를 위한 명확한 경로를 필요로 합니다.

거래가 완료되면 계약에 따라 결제가 진행됩니다.

그렇지 않을 경우, 환불 조건에는 미리 정해진 해결 방법이 있습니다.