채널 접합에 대한 간단한 설명

기본적으로 "접속"은 간단한 개념입니다. 즉, 라이트닝 채널의 크기를 조정하는 기능입니다. 그러나 시간이 지남에 따라 Lightning 채널의 크기를 조정하는 이 기능이 종종 예상치 못한 많은 추가 이점을 제공하고 Lightning 네트워크의 성능을 근본적으로 향상시킬 것이라는 것이 점점 더 분명해졌습니다.

채널 접합은 다음 두 가지 측면에서 개선을 가져옵니다.

사용자 중심 개선

첫 번째 측면은 상대적으로 설명하기 쉽습니다. 시중에는 많은 비트코인 ​​지갑 앱이 있으며 이는 확실히 좋습니다. 하지만 이러한 개발자들이 자체 앱을 개발할 때 문제에 직면하게 됩니다. 이 앱을 비트코인 ​​지갑으로 만들어야 할까요, 아니면 라이트닝 지갑으로 만들어야 할까요?

대부분의 지갑은 둘 중 하나를 선택하지만 좀 더 야심찬 지갑은 두 가지 모두를 선택합니다! 보다 근본적인 관점에서 보면 물론 두 가지를 모두 수행하는 것이 최선의 솔루션입니다.

하지만 이로 인해 문제가 발생합니다. 이 지갑에는 "두 세트의 잔액"이 있습니다. 하나는 (“체인”) 비트코인 ​​잔액이고 다른 하나는 라이트닝 채널의 비트코인 ​​잔액입니다. 새로운 사람을 비트코인으로 데려간 적이 있는지는 모르겠지만, 두 가지 잔고 세트를 갖는 것은 신규 사용자에게 혼란스러울 수 있다는 점은 말씀드릴 수 있습니다. 숙련된 비트코인 ​​사용자에게는 이것이 문제가 되지 않지만 우리는 모든 사람이 비트코인을 사용할 수 있기를 바랍니다.

이 "두 세트의 잔액" 문제는 설계 문제가 아니며 두 모델(온체인 펀드와 라이트닝 채널)이 근본적으로 다르기 때문에 "하나의 세트"로 전환할 수 없습니다. 그렇지 않으면 새로운 사용자 문제가 발생합니다. : 오랜 지불 지연 및/또는 엄청난 수수료를 업데이트합니다.

그리고 채널 스플라이싱이 네트워크에서 구현될 수 있다면 비밀 무기가 되어 "균형 세트" 지갑을 가능하게 만들 것입니다. 채널 접합을 통해 이 두 밸런스를 저렴한 비용으로 상호 운용(서로 변환)할 수 있기 때문입니다.

백엔드 유동성 개선

두 번째 측면인 백엔드의 유동성 증가는 이해하기 어려울 수 있지만 라이트닝 네트워크에 더 중요한 영향을 미칩니다("잔액 세트" 앱과 비교).

라이트닝 네트워크는 네트워크 전체에 분산된 많은 "마이크로" 뱅크에서 실행됩니다. 이들 은행은 단 하나의 서비스, 즉 특정 방향으로 돈을 이동시키는 서비스만 제공합니다.

전통적인 은행 업무에는 소수의 "실제" 은행을 신뢰할 수 있는 네트워크에 승인하는 거대한 "허브" 은행이 필요합니다. 하지만 라이트닝 네트워크는 그 반대입니다. 모든 사람이 자신의 은행을 열도록 허용하는 것은 어떨까요? 서로 소통할 수 있는 다수의 소규모 은행이 '탈중앙화 은행'이 될 수 있을까? 충분한 사람들이 이를 수행한다면 우리는 결국 중앙은행만큼 신뢰할 수 있는, 또는 훨씬 더 신뢰할 수 있는 것을 만들 수 있습니다!

이런 일이 실제로 일어났습니다. 라이트닝 네트워크의 "마이크로뱅크" 수는 계속 증가하고 있으며 곧 미국의 5,000개보다 훨씬 많은 100,000개의 마이크로뱅크를 갖게 될 것입니다.

이러한 마이크로뱅크는 귀하의 거래를 라우팅하기 위해 서로 경쟁하므로 가장 저렴한 서비스를 제공합니다. 그러한 은행이 결제를 진행하려면 비트코인의 "라이트닝 계정" 중 하나에 이미 일부 자금이 저장되어 있어야 합니다.

이러한 마이크로뱅크는 귀하의 거래를 라우팅하기 위해 서로 경쟁하므로 가장 저렴한 서비스를 제공합니다. 그러한 은행이 결제를 진행하려면 비트코인의 "라이트닝 계정" 중 하나에 이미 일부 자금이 저장되어 있어야 합니다.

몇 가지 구체적인 수치를 알려드리겠습니다. 성공적인 라이트닝 은행은 일반적으로 100개의 라이트닝 계정을 유지합니다. TA는 지속적으로 이러한 계정 간에 자금을 이동하고 다음 사용자가 결제를 시작해야 하는 방향을 예측해야 합니다. 만약 그 사람이 계정 잔액이 100,000 사토시인 "샐리의 샌드위치 가게"로 가는 길에 있다면, 여러분이 Sally로부터 샌드위치를 ​​사고 싶을 때 결제를 위해 그 사람을 선택할 수도 있습니다.

이제 100개의 계좌를 관리하는 마이크로뱅크 중 하나가 소비자 행동을 추측하기 위해 계좌 간에 지속적으로 돈을 이동한다고 상상해 보세요. 이것은 꽤 어렵습니다! 사실 사람들의 행동은 예측하기가 매우 어렵고, 당신과 같은 일을 하고 싶어하는 경쟁자가 많기 때문입니다.

그렇다면 채널 스플라이싱은 이것과 어떤 관련이 있습니까? 글쎄, 이러한 계좌 간에 자금을 이동하는 데는 비용이 많이 듭니다. 실제로 이러한 번개 은행에는 지속적인 계좌 폐쇄 및 개설이 필요합니다. 또한 예상치 못한 수요가 발생할 경우 라이트닝 네트워크에 배포할 수 있는 “예비”로 자금을 유지해야 합니다.

채널 접합은 비용이 많이 드는 계좌 폐쇄 및 개설의 필요성과 유휴 "예비" 자금을 유지할 필요성을 모두 제거합니다. 이를 통해 마이크로뱅크의 운영 비용, 복잡성 및 유휴 자본 문제가 크게 줄어들 것입니다. 채널 스플라이싱(Channel Splicing)은 "라이트닝 계정" 간에 자금을 직접 이체할 수 있도록 함으로써(최대한 비용 효율적) 이 모든 작업을 수행합니다. 더 좋은 점은 채널 접합을 통해 이러한 마이크로뱅크가 더 이상 소위 "중앙 집중식 유동성 공급자"에 의존하지 않고 독립적으로 유지될 수 있도록 함으로써 전체 네트워크를 더욱 강력하게 만드는 것입니다.

이는 Lightning 마이크로뱅크를 운영하는 사람들에게 매우 흥미로운 일이며, 물론 귀하와 같은 Lightning Network 사용자에게도 마찬가지입니다. 이러한 마이크로뱅크가 보다 효율적으로 운영될 수 있다면 비용 절감은 자연스럽게 더 저렴한 수수료와 보다 안정적인 결제의 형태로 사용자에게 전달될 것입니다.

채널 접합 기술 개요

채널 스플라이싱은 라이트닝 채널(채널의 자금 UTXO)에 있는 자금을 새로운 "스플라이싱된" UTXO로 이동하는 것을 의미합니다. 구체적인 작업은 매우 간단합니다. 2/2 다중 서명 거래에 서명하여 자금을 새로운 위치로 이동합니다. 그러나 이 프로세스를 신뢰할 수 없는 상태로 유지하는 것은 그리 간단하지 않습니다.

원래 자금을 조달한 UTXO와 하위 HTLC 거래를 실제로 이동하려면 먼저 새로운 "접합" UTXO에 대한 약정 거래를 재구성해야 합니다.

그러나 새 채널에 대해 복사된 Promise 상태를 다시 생성하기 전에 현재 채널의 상태가 즉시 변경되지 않는지 확인해야 합니다. 그래서 우리는 "STFU"로 축약되는 "SomeThing Fundamental is Underway"라는 새로운 번개 상태를 도입했습니다.

STFU는 일정 기간 동안 현재 채널의 약속 상태 변경을 금지합니다.

채널에 참여하는 두 노드는 대화형 전송 프로토콜을 사용하여 트랜잭션 협상을 시작합니다. 각 당사자는 차례가 되면 입력과 출력을 모두 추가할 수 있습니다. 현재 채널의 자금 조달 UTXO가 협상된 거래에 대한 입력으로 추가됩니다.

양 당사자는 다른 채널을 열거나 다른 채널 접합을 처리하는 등 관련 없는 활동에 대해 추가 입력 및 출력을 자유롭게 추가할 수 있습니다. 이러한 모든 활동은 하나의 트랜잭션으로 결합됩니다.

거래 협상 및 구축이 완료된 후 양측은 최종 거래를 검증하고 거래 잔액이 기대치와 일치하는지 확인한 후 채굴자에게 합리적인 금액의 수수료를 지불합니다. 그런 다음 거래에 서명하고 상대방에게 서명을 제공합니다.

거래 협상 및 구축이 완료된 후 양측은 최종 거래를 검증하고 거래 잔액이 기대치와 일치하는지 확인한 후 채굴자에게 합리적인 금액의 수수료를 지불합니다. 그런 다음 거래에 서명하고 상대방에게 서명을 제공합니다.

거래가 방송된 후, 양측은 거래가 6개의 블록 확인을 받을 때까지 기다립니다. 그런 다음 접합이 "완료"된 것으로 간주됩니다. 이때 원래 채널의 상태는 삭제하고 접속된 채널의 상태에만 관심을 가질 수 있습니다. 이렇게 하면 데이터베이스 공간을 많이 절약할 수 있습니다.

(번역자 주: 여기 설명은 너무 거칠습니다. 양측의 기존 채널 UTXO는 UTXO A이고, 그들이 형성하려는 스플라이스 채널 UTXO는 UTXO B라고 가정합니다. 먼저, 양측은 UTXO용 채널 UTXO를 구성해야 합니다. B. 커밋된 트랜잭션은 무신뢰 보장인 새 채널의 첫 번째 상태로 사용되며, 이후 양 당사자는 UTXO B의 트랜잭션을 생성하고 이를 브로드캐스팅하기 위해 서명합니다. UTXO B가 충분한 블록 확인을 얻기 전에 원본 채널은 계속 운영되며, 각 당사자는 원래 채널의 상태를 업데이트하면 새 채널의 상태도 업데이트해야 하며, UTXO B가 충분한 블록 확인을 획득하면 더 이상 원래 채널의 상태를 업데이트할 수 없거나 원래 채널과 관련된 데이터를 삭제하면 채널의 정상적인 작동에 영향을 주지 않고 채널 크기를 변경할 수 있습니다.)

채널 접합을 구현하는 방법

접합을 지원하지 않는 것부터 접합을 지원하는 것까지 Lightning 구현을 수행하는 데는 여러 단계가 있습니다.

먼저, 채널 상태에서 자금 세부 정보 덮어쓰기를 허용할지, 아니면 연결된 채널 상태를 완전히 새로운 상태로 처리할지 결정해야 합니다. 두 접근 방식 모두 작동할 수 있으며 어느 것이 더 이상적인지는 구현이 채널 상태를 구성하는 방법에 따라 다릅니다.

두 가지 복제된 채널 상태 세트의 이점은 다음과 같습니다.

두 세트의 복제된 채널 상태의 단점:

채널 상태가 하나만 있으면 다음과 같은 이점이 있습니다.

채널 상태가 하나만 있으면 단점:

어떤 접근 방식을 취하든 채널 ID와 짧은 채널 ID를 관리하려면 추가 작업이 필요하며, 특히 이를 전체 코드 기반으로 처리해야 하는 키로 사용하는 경우에는 더욱 그렇습니다.

특정 코드 베이스에 대해 각 접근 방식의 장점과 단점(리팩터링의 어려움과 버그 도입의 위험)을 고려해야 합니다.

다음으로 재사용 가능한 대화형 트랜잭션 빌딩 블록이 필요합니다. 이 모듈은 모든 TX_ADD_INPUT/TX_ADD_OUTPUT 유형 메시지를 처리합니다. 또한 이중 자금 조달을 지원하려면 이 모듈이 필요합니다. 이것이 바로 많은 구현에서 이중 자금 조달을 위한 모듈을 개발하는 이유입니다.

이 모듈은 향후 "접속 후 연결" 및 기타 Lightning Network 사양 추가에도 유용할 것입니다.

대화형 거래 프로토콜은 양방향 자금 조달 변형과 매우 유사하지만 몇 가지 차이점이 있습니다. 이러한 모듈이 다양한 시나리오에서 실행될 수 있도록 개발할 때 이러한 차이점을 염두에 두십시오.

다음 자연스러운 단계는 "STFU" 논리를 구현하는 것입니다. 많은 사람들은 STFU 프로토콜이 상상했던 것보다 더 복잡하다고 생각합니다. 이는 STFU 메시지가 실제로 STFU 모드에 대한 요청이기 때문입니다. "STFU"가 다시 수신되지 않으면 활성화되지 않습니다.

다음 자연스러운 단계는 "STFU" 논리를 구현하는 것입니다. 많은 사람들은 STFU 프로토콜이 상상했던 것보다 더 복잡하다고 생각합니다. 이는 STFU 메시지가 실제로 STFU 모드에 대한 요청이기 때문입니다. "STFU"가 다시 수신되지 않으면 활성화되지 않습니다.

상대방이 HTLC 추가, 커밋된 트랜잭션 업데이트 등 다른 작업으로 바쁜 경우 작업이 완료될 때까지 STFU에 응답하지 않습니다.

이 글을 쓰는 시점에서는 채널 스플라이싱만 STFU 모드를 사용하지만 이는 향후 변경될 가능성이 높습니다. 따라서 STFU 모듈을 개발할 때 향후 용도에 대해 생각해 보는 것이 좋습니다.

STFU 모드와 관련하여 몇 가지 특별한 고려 사항이 있습니다. 양측이 동시에 채널 스플라이싱을 초기화하려는 경우는 드뭅니다. 이러한 복잡한 상황을 올바르게 처리하는 것을 잊지 마십시오.

일반적으로 초기화에서는 입력과 출력으로 구성된 PSBT(부분 서명된 비트코인 ​​트랜잭션)를 처리해야 합니다. 사용자는 이 트랜잭션에 입력과 출력을 추가하고 상대적인 채널 크기 변경 금액을 추가할 수 있습니다. splice_ack뿐만 아니라 splice도 보내려면 상대 수량 변경 사항을 보내야 합니다. 양 당사자 모두 변동 금액을 제공할 수 있으므로 수신 당사자가 PSBT 변동 금액을 알릴 수 있는 플러그인을 개발해야 합니다.