저자: 피터 토드
출처: https://petertodd.org/2025/fake-channels-and-rgb-lightning
라이트닝 네트워크 프로토콜의 직관적이지 않은 점 중 하나는 결제를 전달하는 중간 채널이 반드시 "실제" 채널일 필요가 없다는 것입니다. 앨리스가 앨리스 ↔ 밥 ↔ 찰리 ↔ 데이비드 경로를 통해 데이비드에게 비트코인으로 지불하려는 경우, 밥과 찰리 사이의 라이트닝 채널이 실제 채널(비트코인이 예치된 실제 채널)인지 가짜 채널인지는 중요하지 않습니다! 사실 앨리스에게는 데이비드가 비트코인을 받는지 여부조차 중요하지 않습니다. 앨리스에게 중요한 것은 데이비드가 지불을 수락했다는 사실(진실을 밝혔다는 사실)입니다. 만약 데이비드가 진실을 밝히지 않았다면 앨리스는 아무 이유 없이 그에게 돈을 지불하지 않았을 것입니다.
마찬가지로, 앨리스가 데이비드로부터 비트코인으로 결제를 받는 경로가 데이비드 ↔ 찰리 ↔ 밥 ↔ 앨리스인 경우, 앨리스는 데이비드가 찰리에게 실제 비트코인으로 지불하는지, 또는 찰리가 밥에게 무엇으로 지불하는지에는 관심이 없습니다. 앨리스에게 중요한 것은 밥이 자신에게 실제 비트코인을 보내도록 설득되었다는 사실뿐입니다.
기존 라이트닝 네트워크 프로토콜은 공개 채널이 유효한 UTXO에 대응하도록 보장합니다. 하지만 이는 오로지 DoS 공격 방지를 위한 것으로, 방송 가능한 채널 수를 제한하는 방법 이 필요합니다. 라이트닝 채널 UTXO를 가십 공지에 연결하는 방식 이 바로 우리가 (현재) 선택한 접근 방식입니다.
클라이언트 측 토큰 검증을 위한 라이트닝 채널
비트코인 위에 구축된 라이트닝 네트워크에서 공개적으로 접근 가능한 "가짜 채널"을 통해 안전하게 라이트닝 결제를 전송할 수 있다는 사실은 오랫동안 이론적인 주제로만 남아 있었습니다. 이는 상호 신뢰하는 당사자 간에 채널을 설정할 때 유동성 요구 사항을 줄이는 방법으로 구상되었지만, 실제로 구현된 적은 없습니다.
하지만 클라이언트 검증 토큰을 사용하는 라이트닝 채널의 경우에는 상황이 완전히 다릅니다.
요약하자면, 클라이언트 검증 토큰은 " RGB "와 같은 프로토콜을 사용하며, 비트코인 네트워크를 순수한 이중 지불 방지 메커니즘으로 간주합니다. 비트코인 프로토콜은 특정 코인이 단 하나의 거래 내역만 갖도록 보장합니다. 이 거래 내역의 유효성은 클라이언트(사용자 본인)가 검증합니다. 따라서 앨리스가 밥에게 1달러에 해당하는 이전 보유량(RGB 프로토콜 기반)을 주고 싶다면, 코인을 생성한 거래부터 최초 생성 시점까지의 전체 거래 내역을 제공하여 코인이 진짜임을 밥에게 확신시켜주기만 하면 됩니다.
이러한 이력이 글로벌하지 않기 때문에 클라이언트 검증 토큰은 엄청난 확장성 잠재력을 가지고 있습니다. 제가 이 블로그 게시물 에서 설명했듯이, 클라이언트 검증 토큰은 초당 수십억 건의 거래를 처리할 수 있습니다. 하지만 이러한 거래는 여전히 인체인 거래이므로 확인하는 데 시간이 걸립니다. 반면 라이트닝 거래는 거의 즉각적으로 처리될 수 있습니다.
따라서 RGB와 "Taproot Assets"는 모두 거래 클라이언트가 토큰을 검증할 수 있도록 라이트닝 채널을 개발하고 있습니다.
이로써 "가짜" 채널 문제로 다시 돌아가 보겠습니다. 자신이 소유한 RGB 토큰이 진짜임을 증명하려면 수 메가바이트(MB)의 거래 데이터가 필요할 수 있지만, 라이트닝 채널에서 이 토큰을 사용하는 경우에는 다른 사람의 라이트닝 채널에 진짜 RGB 토큰이 있는지 여부를 알 필요가 없습니다 ! 자신의 채널이 진짜이고 완전히 자체 관리된다는 증거만 있으면 충분합니다. 다른 사람이 가짜 화폐를 받아들이도록 속는다고 해도 그것은 당신의 문제가 아닙니다.
Taproot Asset “유니버스”
이로써 흥미로운 질문이 제기됩니다. 탭루트 자산 프로토콜에서 " 유니버스 "는 정말 필요한 것일까요? 이 설계의 핵심 아이디어는 라이트 클라이언트가 스스로 검증하는 대신, 거래하려는 자산에 대한 통화 검증을 제3자 "유니버스"에 맡기는 것입니다. 이러한 유니버스는 해당 자산에 대한 모든(또는 적어도 대부분의) 거래 내역을 알고 있어야 하며, 특정 블록 높이에서 모든 유효한 통화를 보장하기 위해 서명된 대규모 머클 트리를 생성해야 합니다.
일반적인 "라이트" 지갑이 라이트닝 채널만 사용하는 경우, 제3자에 의존하지 않고 자체 코인을 완벽하게 검증하는 데 필요한 데이터는 단 몇 MB에 불과합니다. 중간 라이트닝 채널의 진위 여부는 중요하지 않으므로, 클라이언트는 가십 메시지(예: 희소성 증거 기반의 DoS 공격 방지 메커니즘)를 사용하여 자체 경로를 구성할 수도 있습니다.
(위에)
