Commerceblock는 Mercury Layer 프로토콜에서 statechains와 함께 사용할 수 있는 새로운 원자 스왑 프로토콜을 출시했습니다. HSM 서버는 두 개의 statechain을 원자적으로 스왑하는 기능과 Lightning 결제를 위한 statechain의 원자적 교환을 시행하는 기능을 도입했습니다. 이는 statechain과 Lightning Network 간의 구체적으로 정의되고 구축된 상호작용의 첫 번째 사례입니다. Ruben Somsen이 처음으로 statechain 개념을 제안했을 때부터 두 프로토콜 간의 시너지가 예상되었습니다. 이는 전체 statechain UTXO를 한 번에 전송해야 하는 한계를 해결하기 위한 방법으로 제안되었습니다.
기본 Statechain 스왑
새로운 스왑 프로토콜을 지원하기 위해 HSM 서버는 각 statechain을 추적하는 데이터베이스 항목에 몇 가지 새로운 필드를 추가해야 합니다. statechain 간 스왑을 용이하게 하기 위해 서버는 다음을 추적해야 합니다:
- Batch_id: 그룹 내에서 스왑되는 statechain을 연결하는 값입니다.
- Batch-time: 스왑이 실패할 경우 statechain을 “회수”할 수 있는 카운터를 시작하는 시간입니다.
- Locked: statechain이 잠겨 있고 일반 전송이 제한되는지 여부를 나타내는 값입니다.
이렇게 하면 HSM 서버는 안전한 원자 스왑을 보장하는 데 필요한 모든 변수를 추적하고 시행할 수 있습니다. 스왑을 시작할 때 사용자는 서로 직접 통신하여 공유 batch_id를 설정해야 합니다. 이 시점에서 그들은 정상적인 statechain 전송을 용이하게 하는 데 필요한 모든 정보를 거래하고, 해당 정보와 함께 batch_id 및 batch-time을 서버에 전송합니다. 그들은 본질적으로 일반 전송 프로세스를 시작하지만, 스왑에 참여하는 개별 statechain을 연결하고 그에 대한 타임아웃 기간을 지정하는 변수를 첨부합니다.
이 시점에서 서버는 전송 프로세스에서 동일한 batch_id를 사용하는 모든 statechain에 잠금을 적용합니다. 타임아웃이 만료되거나 데이터베이스에서 동일한 batch_id를 사용하는 모든 statechain이 현재 소유자에 의해 잠금 해제될 때까지 서버는 어떤 전송도 승인하지 않습니다. HSM이 스왑 로직을 시행하는 방식의 흥미로운 점은 누가 먼저 서버에 연락하는지는 중요하지 않다는 것입니다. 서버가 batch_id를 사용하는 메시지를 받으면 데이터베이스의 모든 statechain을 확인하고 해당 batch_id에 대해 기존 batch-time이 있으면 동일하게 설정합니다. 이는 누가 먼저 스왑을 등록하든 상관없이 모두가 타임아웃 기능을 위한 동일한 시간 값을 사용하도록 보장합니다.
스왑에 관련된 각 클라이언트는 이 시점에서 전송 프로토콜을 시작한 메시지를 확인하고 다운로드하며, 그것이 올바른지 확인한 후 자신의 statechain의 잠금을 해제하기 위해 서버에 메시지를 보냅니다. 누군가 스왑에 관련된 statechain의 수신 측에서 전송을 완료하려고 시도할 때, 서버는 동일한 batch_id를 가진 모든 statechain이 잠금 해제되었는지 확인합니다. 관련 batch_id가 있는 statechain 중 하나라도 여전히 잠겨 있다면 서버는 어떤 것도 최종 전송하지 않습니다. 스왑이 타임아웃 전에 성공하지 못하면 서버는 스왑 전송의 최종화를 계속 제한하지만, 현재 소유자가 스왑을 효과적으로 취소하기 위해 자신에게 새로운 전송을 초기화할 수 있도록 허용합니다.
Lightning Latch
statechain을 Lightning 결제로 스왑하는 Lightning Latch 기능은 statechain 간 스왑과 매우 유사하게 작동합니다. Lightning 스왑을 위해 서버가 추적해야 할 새로운 필드는 다음과 같습니다:
- Batch_id: 그룹 내에서 스왑되는 statechain을 연결하는 값입니다.
- Batch-time: 스왑이 실패할 경우 statechain을 “회수”할 수 있는 카운터를 시작하는 시간입니다.
- Pre-image: HSM 서버에 의해 생성된 Lightning 결제의 프리이미지입니다.
- Locked_1 및 locked_2: Lightning 스왑을 위한 두 개의 잠금 필드가 있으며, 각각 관련된 사용자에 의해 승인됩니다.
statechain 간 스왑과 마찬가지로, 사용자는 무작위 batch_id를 설정하고 공유합니다. 현재 statechain 소유자는 batch_id와 관련된 statechain을 가지고 서버에 메시지를 보내 Lightning 결제를 위한 해시락 프리이미지를 생성해 달라고 요청합니다. 이 사용자는 이 프리이미지를 사용하여 Lightning 송장도 생성하고, 두 번째 사용자는 서버에 연락하여 프리이미지를 생성했음을 확인합니다. 현재 statechain 소유자는 statechain 전송 프로세스를 시작하고 전송 메시지를 서버에 업로드합니다.
그 확인 후, statechain을 스왑하려는 두 번째 사용자는 Lightning 결제를 시작합니다. 이 시점에서 서버는 프리이미지를 가진 유일한 존재이므로 statechain 소유자는 결제를 아직 완료할 수 없습니다. 현재 소유자는 보류 중인 Lightning 결제를 확인한 후 서버에 첫 번째 잠금을 해제하기 위한 메시지를 보냅니다. 수신자는 마지막으로 전송 메시지를 확인하고, 유효한 경우 서버에 자신의 잠금을 해제하라는 메시지를 보냅니다.
이제 두 개의 잠금이 모두 해제되면 HSM 서버는 현재 statechain 소유자에게 프리이미지를 제공하여 Lightning 결제를 완료하고, 수신자에게 statechain 전송을 완료합니다.
이 계획은 statechain 운영자가 정직하게 기능할 것이라는 신뢰를 요구하지만, 이는 일반적으로 statechain을 사용하는 기존 신뢰 모델에 대한 근본적인 변화가 아닙니다. 운영자는 사용자의 자금에 대한 통제권을 가지지 않으며, Lightning 결제 세부정보에 대해 아무것도 알지 못합니다.
이것은 무엇에 좋은가?
이 계획은 statechains와 Lightning 채널 간의 원래 제안된 상호작용과는 거리가 멀지만, 단순한 출발점으로서 기존 Lightning 사용자에게 기능적 유용성을 제공합니다. 채널의 재조정은 많은 노드에 필요한 작업이며, 용량이 한쪽으로 완전히 밀려나면 해당 채널의 유용성은 제한됩니다. 많은 기업과 사용자가 온체인 수수료 상승으로 인해 Liquid를 이 메커니즘으로 사용하는 실험을 시작했습니다.
Statechains는 채널 잔액 관리를 위한 수수료 비용을 완화하기 위해 연합된 사이드체인에 대한 대안 메커니즘을 제공합니다. 자금을 직접 메인체인으로 스왑하거나 사이드체인을 사용하는 대신, 자금을 statechain으로 스왑하고 필요할 때까지 그곳에 보관할 수 있습니다. 자금을 채널로 다시 스왑하는 동안 수수료 절감 효과를 유지하면서도 메인체인에서 자금을 일방적으로 주장할 수 있는 능력을 유지할 수 있습니다.
또 다른 잠재적 사용 사례는 (트리거 경고) 서수 거래를 위한 보다 효율적인 시장의 가능성입니다. 서수는 특정 사토시로의 거래 이력에서 경로를 추적하는 인덱스 체계이므로, 쉽게 오프체인으로 statechain으로 옮길 수 있습니다. 이 동적 요소와 Lightning Latch의 조합은 서수를 저렴하고 빠르게 오프체인에서 구매할 수 있도록 할 수 있습니다. 누군가는 Lightning Network를 통해 즉시 오프체인에서 판매될 수 있는 시장을 구축할 수 있습니다.
언젠가는 Lightning 클라이언트가 특정 Lightning 노드가 신뢰하는 statechain 운영자를 인식할 수 있게 된다면, Latch를 사용하여 다양한 노드 간에 statechain을 전달하여 결제를 라우팅하는 데 도움이 될 수 있습니다.
순수한 statechain 간 전송의 경우, 이는 오프체인에서 코인을 혼합하는 coinjoin과 유사한 시스템 혼합을 재현하기 위한 메시지 전달 계층의 잠재력을 제공합니다. 이는 Commerceblock의 첫 번째 statechain 구현에서의 원래 혼합 기능과 유사합니다.
매우 간단한 출발점이지만, Lightning Latch와 statechain 스왑 기능은 statechains가 기존 Lightning Network와 통합되는 첫 번째 문을 열어줍니다. 이는 향후 다른 유사한 레이어와 함께 결제 라우팅 및 유동성 관리 측면에서 모두 원활하게 통합되고 단일 네트워크로 기능할 수 있도록 합니다. 우리는 계약의 필요성과 유용성에 대해 논의하더라도, 이미 가지고 있는 것을 기반으로 계속 구축할 수 있는 여지가 많이 남아 있습니다.
Commerceblock 팀이 프로토콜 뒤에 있는 논리를 설명하는 것을 들으실 수 있습니다:
Chatting with the Dr @TTrevethan about why to build lightning latch on @mercurylayer #bitcoin #layer2 pic.twitter.com/CKVG9aHTQ6
— Nicholas Gregory (@gregory_nico) March 15, 2024
보다 기술적인 설명은 여기에서 확인하실 수 있습니다:
Going through the technicals of how lightning latch will work with @TTrevethan on @mercurylayer #bitcoin #layer2 pic.twitter.com/aQIcjh2ukq
— Nicholas Gregory (@gregory_nico) March 16, 2024
