작성자: 익명
이 시리즈의 두 번째 기사 에서는 비트코인 프로토콜의 개선으로 라이트닝 채널의 구축 방법과 최종 효과가 향상될 수 있다는 점을 지적했습니다. 하지만 실제로는 채널 구축과 밀접한 관련이 있지만 상대적으로 주목받지 못했던 영역에서 라이트닝 채널은 비트코인 프로토콜의 합의 규칙, 즉 거래 수수료 지불을 업그레이드하지 않고도 지속적으로 최적화되어 왔습니다.
라이트닝 채널에서는 채널 상태가 커밋 거래로 표현되며, 각 커밋 거래가 체인으로 전송될 수 있으므로 이러한 거래에 대한 거래 수수료를 고려해야 합니다. 수수료 지불 방법은 채널 내에서 사용 가능한 잔액 과 거래 일괄 처리 가능성에 영향을 미치며, 이는 결국 사용자 경험에 영향을 미칩니다.
이 글에서는 Lightning Channels의 수수료 지불 설계가 어떻게 점진적으로 최적화되었는지, 그리고 이러한 최적화가 사용자 경험을 어떻게 개선했는지 살펴보겠습니다. 독자는 먼저 Lightning Network의 작동 원리와 보안 요구 사항을 이해해야 합니다.
시작하기에 앞서, "간단한" 질문 하나를 생각해 보세요. 채널은 두 당사자가 공동으로 소유하고 있으며, 두 당사자 모두 채널에서 잔액 보유할 수 있습니다. 그렇다면 거래가 체인에 제출되어야 할 때, 누가 처리 수수료를 지불해야 할까요? 비트코인 거래에서는 이것이 어떻게 이루어지나요?
좋아요, 비트코인 거래 수수료 지불 방법부터 시작해 보겠습니다.
취급 수수료 지불 및 추가
비트코인 거래가 블록에 의해 확인되면, 입력 자금의 합계와 출력 자금의 합계의 차액은 블록을 채굴한 채굴자에게 수집될 수 있습니다. 이 차이를 "처리 수수료"라고 하며, 채굴자가 블록에 거래를 포함시키는 주된 동기가 됩니다.
거래를 구성할 때 사용자는 거래에 대한 입력 및 출력을 선택하며, 이에 따라 거래 수수료의 크기도 결정됩니다. 그러나 수수료 시장은 급격하게 변화할 수 있으며, 사용자가 선택한 수수료 규모는 나중에 사용자가 원하는 시간 내에 거래를 확인하기에 부족할 수도 있습니다. 그러므로 수수료를 "추가"하는 것을 고려해야 합니다. 이는 사용자 경험을 개선하는 데 필요합니다.
RBF
그 중 하나는 "수수료 대체"라고 불리는 방법으로, 원래 거래의 입력의 일부 또는 전부를 사용하여 새로운 거래를 시작하고, 새로운 거래(대체 거래)에 원래 거래보다 더 높은 수수료를 부과하는 원칙에 기반을 두고 있습니다. 이를 통해 채굴자들이 대체 거래를 패키징하도록 유도합니다. 아래 그림과 같이(금액에 주의하세요):
graph LR U1(UTXO #0, 500 sats) --> T0[Tx #0] T0 -.-> P0(Payment #0, 300 sats) T0 -.-> C0(Change #0, 150 sats) T0 -.-> F0{{Fee #0, 50 sats}} U1 --> T1[Tx #1] T1 -.-> P1(Payment #1, 300 sats) T1 -.-> C1(Change #1, 100 sats) T1 -.-> F1{{Fee #1, 100 sats}}또한 Tx #1이 UTXO #0을 이중 지출하려고 시도하고 두 거래가 "경쟁"하는 것으로 생각할 수도 있습니다. 하지만 Tx #1이 더 높은 수수료를 제공하기 때문에 채굴자들은 당연히 이 거래를 선호할 것입니다. 이는 우리가 "거래 수수료 추가"라고 부르는 효과를 가져오고 채굴자들이 먼저 거래를 패키징하도록 유도합니다.
CPFP
또 다른 방법은 원래 거래의 출력을 사용하여 새로운 거래를 시작하고 새로운 거래에 더 높은 수수료를 부과하는 것입니다. 이렇게 하면 채굴자가 새로운 거래를 패키징하려면 원래 거래도 패키징해야 합니다(즉, 이전 거래와 새로운 거래는 전체, 즉 "거래 패키지"로 처리되어 거래 풀의 다른 거래와 경쟁합니다). 이것을 "자녀가 아버지를 대신 지불(CPFP)"이라고 합니다. 다음 그림과 같이:
graph LR U1(UTXO #0, 500 sats) --> T0[Tx #0] T0 -.-> P0(Payment #0, 300 sats) T0 -.-> C0(Change #0, 150 sats) T0 -.-> F0{{Fee #0, 50 sats}} C0 --> T1[Tx #1] T1 -.-> C1(Change #1, 50 sats) T1 -.-> F1{{Fee #1, 100 sats}}RBF와 비교했을 때 CPFP는 단점이 있습니다. 새로운 거래는 추가 블록 공간을 차지해야 합니다(즉, 새로운 거래소 에서 발생하는 거래 수수료의 일부는 원래 거래에 추가되는 것이 아니라 거래 자체를 확인하는 데 사용됩니다). 반면 RBF는 기본적으로 이런 것이 필요하지 않습니다. 즉, 두 가지 방법을 모두 사용할 수 있는 상황에서는 RBF가 더 효율적이고 경제적입니다.
이러한 기본 개념을 바탕으로 번개 채널의 디자인을 살펴보겠습니다.
레거시 채널
graph LR Channel(The Chennel, 2-of-2 Multi-sig) --> TC1[Commit #1] TC1 -.-> TR(To Remote) TC1 -.-> TC(To Local) TC1 -.-> OH(An Offered HTLC) TC1 -.-> RH(A Received HTLC) OH --> HT[HTLC-Timeout tx] RH --> HS[HTLC-Success tx]위 그림은 채널 참여자의 채널 상태와 관련된 거래를 보여줍니다. 제공된 HTLC와 받은 HTLC는 각각 해당 참여자가 다른 당사자에게 제공한 HTLC와 다른 당사자로부터 받은 HTLC를 나타냅니다. 페널티 기반 라이트닝 채널 보안 규칙(LN-Penalty)을 일관되게 적용하기 위해서는 두 가지 유형의 출력 모두 사전 서명된 거래여야 하며(위 그림에는 그려지지 않은 거래 출력에 페널티 분기가 배치됨) [2] . 위 그림에 나와 있는 두 가지 유형의 거래(약정 거래와 HTLC 관련 거래) 모두 수수료 지불 및 추가 문제를 고려해야 합니다.
원래 Lightning Network 사양은 수수료 지불을 위해 다음과 같은 설계를 했습니다. (1) 채널 개시자는 항상 커밋 거래에 대한 수수료를 지불합니다(이것은 이 시리즈의 다섯 번째 기사에서 언급된 " 일방향 자금 조달 " 설계와 밀접하게 연관되어 있습니다). (2) HTLC 거래에서는 거래 수혜자가 수수료를 지불합니다. 또한, 커밋 거래의 특수한 특성으로 인해 RBF는 거의 사용할 수 없지만(한 당사자가 체인에 커밋 거래를 추가하려고 하지만 다른 당사자가 협조하지 않아 이전에 서명된 커밋 거래를 대체할 새 거래를 형성할 수 없는 강제 폐쇄 시나리오를 상상해 보세요) 커밋 거래는 CPFP 사용을 용이하게 하도록 설계 되지 않았습니다 . To Local 출력이 거래 브로드캐스터에게 직접 제공되지만 이 출력에는 시간 잠금이 있어 즉시 사용할 수 없으므로 하위 거래를 시작하는 데 즉시 사용할 수 없습니다. HTLC 거래 자체에도 상대방의 서명이 필요하며, 그 출력에도 시간 잠금 분기가 있습니다.
이 디자인은 다음과 같은 측면에서 사용자 경험에 영향을 미칩니다.
- 항상 한쪽 당사자에게 수수료를 지불하라고 요구하는 것은 불공평합니다.
- 커밋 거래는 RBF를 사용할 수 없으며 CPFP용으로 설계되지 않았으므로 구축 단계에서 확인될 만큼 충분히 높은 수수료가 보장되어야 합니다. 그러나 미래에 커밋 거래가 체인에 등록되는 시점이 불확실하기 때문에 이는 거의 해결할 수 없는 문제가 됩니다. 유일한 실용적인 해결책은 수수료를 매우 보수적으로 과대평가하는 것입니다 [3] . 하지만 이러한 수수료는 채널 자금의 일부를 차지하게 되어 채널의 유용성을 감소시킵니다.
- 또한 수수료 시장도 변동할 것이고, 이로 인해 추정 수수료의 변동이 채널 참여자들의 가용 잔액 에도 변동을 초래하여 이용자들에게 혼란을 야기할 것입니다. 게다가 온체인 수수료가 높은 기간(사람들이 수수료 절감을 위해 Lightning Network를 가장 많이 사용하려는 기간이기도 함)에는 사용 가능한 채널 용량이 크게 압축되고 Lightning Network의 유용성이 약화됩니다 [4] .
그러면 어떻게 최적화할 수 있을까?
앵커 채널
"앵커 채널"의 아이디어는 커밋 트랜잭션에서 각 당사자에게 즉시 사용 가능하지만 낮은 가치의 추가 출력을 마련하는 것입니다(다른 모든 출력에 대해 최대 1블록의 상대적 시간 잠금을 추가하는 동시에). 이를 통해 각 당사자가 커밋 트랜잭션을 브로드캐스트한 후 앵커 출력을 사용하여 CPFP를 시작할 수 있습니다. 물론 앵커 출력 자체의 가치가 낮으므로 사용자는 거래 수수료를 성공적으로 추가하기 위해 하위 거래에 추가 자금을 투입해야 합니다.
또한 앵커 채널은 HTLC 거래에 대담한 트릭을 적용합니다. 한 당사자가 다른 당사자의 HTLC 거래에 서명할 때 해시 태그 "SIGHASH_SINGLE | ANYONECANPAY" [5] 를 사용합니다. 이 태그는 서명이 입력(즉, 대상 HTLC)과 출력 의 쌍만 다루도록 만들고, 이 입력과 출력의 쌍을 다른 유효한 거래로 결합할 수 있도록 합니다. 이를 통해 사용자는 여러 개의 사전 서명된 HTLC 거래를 하나로 결합할 수 있습니다. 또한, Lightning Network 사양에서는 앵커 채널 자체의 HTLC 거래에는 어떠한 처리 수수료도 부과되지 않아야 한다고 구체적으로 규정하고 있습니다. 즉, 사용자는 자신이 받을 만한 모든 HTLC 거래를 하나의 거래로 결합(일괄 처리)한 다음, 입력을 추가하고 출력을 변경하여 처리 수수료를 지불해야 합니다.
이 두 가지 디자인을 결합하면 라이트닝 채널 구현이 간소화되고 거래 수수료가 잔액 차지하는 문제가 최적화됩니다.
- 약정거래에서는 처리수수료를 지불하기 위해 약정거래 자체에 전적으로 의존할 필요는 없습니다. 대신, 비교적 안정적인 처리 수수료를 설정할 수 있으며, 추가 처리 수수료 문제는 앵커 출력을 기반으로 시작된 하위 거래에 맡길 수 있습니다. 이런 방식으로 채널의 가용 잔액 을 수수료가 차지하는 문제가 완화됩니다.
- 이는 거래 수수료를 추정해야 하는 문제를 완전히 해결하지는 못한다는 점에 유의하세요. 수수료 시장의 변동으로 인해 노드가 전달하는 거래에 대한 수수료율의 임계값도 변동합니다. 완료된 거래가 언제든지 확인될 수 있다는 보장은 더 이상 없지만, 여전히 노드 보급을 유치할 만큼 수수료율이 충분히 높아야 합니다. 전파가 불가능하다면 CPFP 방법은 효과가 없습니다. 하지만 난이도는 낮아졌습니다.
- HTLC 거래에서는 거래 수수료가 더 이상 거래 입력(즉, HTLC)에 의해 지불되지 않으므로 수수료 수준이 HTLC 거래의 구성과 바람직성에 어떻게 영향을 미치는지 고려할 필요가 없습니다.
앵커 채널을 사용할 때 비용은 사용자가 거래 수수료를 지불하기 위해 지갑에 사용 가능한 온체인 자금이 있는지 확인해야 한다는 것입니다.
복잡한 사실
비트코인 거래의 구조와 수수료가 부과되는 방식을 고려하면, 위의 개선 사항을 적용하는 것이 자연스럽고 간단할 것이라고 생각할 수도 있습니다. 하지만 자연스러운 진행이라고 할지라도 사실은 그렇게 쉬운 일이 아닙니다. 이는 여러 거래소 형성할 수 있는 순차적 관계(토폴로지)가 다양하기 때문입니다. RBF나 CPFP에 관계없이 이러한 동작을 허용하는 것은 트랜잭션 개시자가 트랜잭션을 전파하는 노드의 리소스 일부를 차지하도록 허용하는 것과 같습니다. 이러한 작업은 제한되어야 하며, 그렇지 않으면 공격자가 트랜잭션을 대체하고 트랜잭션 패키지를 구성하는 방식으로 트랜잭션을 전파하는 노드에 DoS 공격을 가할 수 있습니다. 반면, 행동을 제한하는 데 사용되는 이러한 규칙은 공격을 시작하는 데 사용될 수도 있습니다.
예를 들어. CPFP 동작을 제한하기 위해 Bitcoin Core의 거래 풀 규칙에서는 확인되지 않은 거래가 최대 24개의 하위 거래만 가질 수 있도록 요구합니다. 위의 앵커 채널의 커밋 거래에서 두 당사자 모두 앵커 출력을 가지고 있기 때문에 한 당사자는 자신의 앵커 출력을 사용하여 커밋 거래에 24개의 하위 거래를 추가할 수 있고, 이를 통해 다른 당사자가 CPFP를 시작하는 것을 방지할 수 있습니다. 이러한 공격(일명 "트랜잭션 고정 공격")의 리스크 으로 인해 위의 Bitcoin Core 규칙은 예외를 허용합니다. 자식 거래의 가중치가 1000vB 미만이고 확인되지 않은 상위 거래가 하나만 있는 경우, 해당 자식 거래는 확인되지 않은 상위 거래의 25번째 자손 거래가 될 수 있습니다. 이 예외 규칙(Carve Out이라고 함)은 위에서 언급한 앵커 채널이 안전하게 작동하도록 허용합니다(하지만 여전히 적대자의 영향을 받을 리스크 제거할 수는 없습니다) [6] .
궁극적으로 비트코인 전체 노드로 구성된 네트워크와 각 노드가 적용하는 거래 풀 규칙은 라이트닝 채널과 같은 계약 프로토콜의 보안 의존성을 구성합니다(이러한 프로토콜은 종종 사용자 자금의 보안을 보장하기 위해 거래가 즉시 확인되도록 요구함). 하지만 이러한 거래 풀 규칙은 완벽하지 않을 수 있습니다. 신뢰할 수 있고 남용에 강한 거래 풀 규칙을 설계하는 것은 쉽지 않습니다.
2022년 이후 비트코인 개발자들은 거래 풀 규칙에 대한 새로운 아이디어를 형성하기 시작했으며, 그 중 가장 유명한 것은 "v3 거래 [7] "와 "클랜 거래 풀 [8] "입니다. 전자는 거래 간 토폴로지를 제한하여 더욱 정교한 규칙의 설계를 지원하는 반면, 후자는 더 나은 RBF 규칙을 지원하기 위해 거래 풀의 내부 순서 재설계하고자 합니다. 흥미로운 점은, 부족 거래 풀이 CPFP-Carve Out을 허용하지 않기 때문에 v3 거래(현재는 "TRUC 거래"로 이름이 변경됨)가 부족 거래 풀로의 연결 고리가 될 것입니다.
다음 섹션에서는 Bitcoin Core 28.0에서 이러한 아이디어의 구현을 소개합니다(자세한 내용은 이 가이드 [9] 참조). 또한 Lightning 채널이 이를 사용하여 사용자 경험을 개선하는 방법도 소개합니다.
1P1C 거래 패키지 기반 새로운 패러다임
우선, 비트코인 코어 28.0은 "1P1C 거래 패키지"라는 새로운 거래 풀 단위를 도입합니다. 이름에서 알 수 있듯이, 이는 두 개의 부모-자식 거래로만 구성된 거래 패키지입니다. 이들은 다른 거래 풀 단위(거래 단위나 다른 1P1C 거래 패키지 등)와 블록 확인을 놓고 전체적으로 경쟁하게 됩니다. 이 중 모거래의 수수료율은 하한인 1사토시/vB만 충족하면 되며, 언제든지 변동하는 거래 풀 진입 수수료율 임계값을 고려할 필요가 없습니다.
둘째, 1P1C 거래 패키지에 따라 그 안의 모든 거래가 버전 번호 "3"을 사용하는 경우 "TRUC 거래" 규칙이 적용됩니다. 거래 단위의 볼륨은 10kvB를 초과할 수 없으며 하위 거래의 볼륨은 1kvB를 초과할 수 없습니다. 더 이상 상위 거래율에 대한 요구 사항이 없습니다(0율이 될 수 있음). 가장 중요한 점은 동일한 부모 거래에 다른 하위 거래가 추가되는 경우, 원래 하위 거래와 동일한 입력을 사용하는지 여부에 관계없이 두 거래 간의 충돌로 간주되어 RBF 대체 규칙이 적용된다는 것입니다.
즉, 28.0은 거래 패키지의 전달을 허용하지만, 거래 패키지의 형태는 두 개의 거래로만 제한되며, 하위 거래 수준에서의 직접적인 충돌이나 경쟁은 이 형태를 파괴할 수 없습니다. 이러한 제약은 대체 규칙을 분석하고 설계하는 데 따르는 어려움을 크게 줄여줍니다.
번개 채널로 돌아가서:
- 라이트닝 채널의 커밋 거래가 v3 거래를 채택하면 거래 수수료를 직접 부담할 필요가 없어 거래 수수료를 추정해야 하는 문제와 채널 용량을 차지하는 거래 수수료에 대한 문제가 완전히 해결됩니다!
- 더 이상 수수료 변경을 고려할 필요가 없고, 수수료 협상도 없으며, 수수료 의견 불일치로 인한 성가신 채널 폐쇄도 없습니다!
- 더 이상 Carve-Out에 의존하지 않으므로 각 측면에 앵커 포인트를 설정할 필요가 없으며, 양쪽에서 사용할 수 있는 단일 앵커 포인트 출력만 설정하면 됩니다. 이를 통해 약정 거래의 규모를 줄이고 경제성을 약간 개선할 수 있습니다. 키 없이도 사용할 수 있는 앵커 출력을 사용하는 것도 가능합니다 [10] .
결론
기사 서두에 나온 질문으로 돌아가 보겠습니다. 약정 거래에 대한 거래 수수료는 누가 지불해야 할까요? 이상적으로는 누가 거래를 체인에 올리고 싶어하든 거래 수수료를 지불해야 합니다. 오늘날 1P1C 거래 패키지와 TRUC 거래의 지원을 통해 마침내 이 이상을 실현할 수 있게 되었습니다.
각주
1. https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#channel-foundment-v1 ↩
2. https://ellemouton.com/posts/htlc-deep-dive/ ↩
3. 피터 토드가 제안한 흥미로운 아이디어는 채널 참여자가 상태를 업데이트할 때 서로 다른 수수료 수준으로 동일한 채널 상태에 대한 여러 세트의 커밋 거래에 서명할 수 있도록 하는 것입니다. 이를 통해 참여자는 온체인으로 전환할 때 특정 상황에 따라 적절한 수수료로 커밋 거래를 브로드캐스트할 수 있으며, 이때 RBF를 시작할 수 있습니다. 하지만 상상할 수 있듯이 이 버전은 모든 유형의 채널 참여자에게 적합하지 않을 수 있습니다. 자세한 내용은 https://www.btcstudy.org/2024/01/07/v3-transactions-review-by-peter-todd/#%E6%89%8B%E7%BB%AD%E8%B4%B9%E6%9B%BF%E6%8D%A2 를 참조하세요 .
4. https://www.btcstudy.org/2024/01/12/rethinking-lightning-by-benthecarman/ ↩
5. 비트코인 거래 입력에 대한 서명을 생성할 때, 시그하쉬라는 태그를 사용하여 서명이 적용되는 거래 부분(즉, 자금 소유자가 동의한 자금의 사용)을 나타낼 수 있습니다. 서명으로 덮인 부분만 변경되면 서명이 무효화되어 비트코인 스크립트 검증 과정을 통과할 수 없게 됩니다. 일반적인 태그는 "SIGHASH_ALL"인데, 이는 서명이 모든 거래 입력과 출력을 포함한다는 것을 의미합니다. 거래 입력과 출력의 어떤 부분이든 추가, 삭제 또는 변경하면 서명이 무효화됩니다. 자세한 내용은 https://www.btcstudy.org/2021/11/09/bitcoin-signature-types-sighash/를 참조하세요 .
6. https://www.btcstudy.org/2022/08/08/anchor-outputs/ ↩
7. https://bitcoinops.org/en/topics/version-3-transaction-relay/ ↩
8. https://www.btcstudy.org/2024/01/16/an-overview-of-the-cluster-mempool-proposal/ ↩
9. https://www.btcstudy.org/2025/01/07/bitcoin-core-28-wallet-integration-guide/ ↩
10. https://delvingbitcoin.org/t/which-ephemeral-anchor-script-should-lightning-use/1412 ↩
