작가: 로즈비프
출처: https://delvingbitcoin.org/t/ln-summit-2024-notes-summary-commentary/1198
약 3주 전, 일본 도쿄에 30명 이상의 라이트닝 네트워크 개발자와 연구원들이 모여 3일 동안 라이트닝 네트워크 프로토콜(및 관련 비트코인 P2P 프로토콜 및 합의 프로토콜)의 현재 상태와 미래에 대해 많은 논의를 했습니다. 개발 관련 문제.
이전에 마지막 컨퍼런스는 2022년 6월 미국 캘리포니아주 오클랜드에서 열렸습니다: LN Summit 2022 Notes & Summary/Commentary . 컨퍼런스 노트의 대략적인 요약은 LN Summit Oakland 2022 - Google Docs 에서 확인할 수 있습니다.
이번 Lightning 개발자 컨퍼런스에 대한 간략한 내용은 Lightning Summit Tokyo - 2024 - Google Docs 에서 확인할 수 있습니다. 그리고 우리가 합의한 일일 주제 일정은 여기에서 확인할 수 있습니다: Lightning Summit.md · GitHub .
(최선을 다했음에도 불구하고) 노트에 나오지 않고, 위 일정에도 반영되지 않은 패널토론이 많다는 점을 언급할 필요가 있습니다.
모든 것을 말했지만, 여기에 주요 토론 주제와 결론(몇 가지 의견과 함께)을 요약하려는 시도가 있습니다. 참석자들이 3일 동안 이루어진 토론과 결정에 대한 요약에서 부정확하거나 불완전한 부분을 발견하면 응답하고 빈칸을 채워주세요.
트랜잭션 패키지 전달 및 V3 커밋 트랜잭션은 어떻습니까?
이것은 우리의 첫 번째 큰 토론 주제이며 Bitcoin Core 28.0의 최신 릴리스 후보(이 글을 쓰는 시점에 이미 릴리스됨)의 릴리스에 이어집니다.
수수료 추정 및 기본 약속
현재까지 제안된 최신 커밋 트랜잭션 설계에 뛰어들기 전에 오늘날의 커밋 트랜잭션 설계가 어떻게 작동하고 그 단점이 어디에 있는지 간략하게 설명하고 싶습니다.
(현재 Lightning 채널에서 약정 거래가 어떻게 작동하는지 이미 알고 있다면 이 섹션을 건너뛸 수 있습니다.)
라이트닝 네트워크 설계의 핵심 측면은 "일방적 출구" 개념입니다. 어느 쪽이든 언제든지 강제로 채널을 종료하고 지연 후 자금을 돌려받을 수 있어야 합니다. 한 당사자가 오래되고 취소된 상태를 온체인 에 게시하여 상대방을 속일 수 있기 때문에 이러한 지연이 필요합니다. 이 시간 창을 통해 정직한 당사자는 특정 상태가 취소될 때만 공개되는 비밀 값을 알고 있음을 증명함으로써 적의 자금 요청을 거부할 수 있습니다.
채널에서 일방적으로 인출하는 기능은 HTLC 계약 실행을 시행하는 데 필요한 핵심 모듈 이기도 합니다. HTLC 계약은 "취소 또는 환불" 기능을 구현하여 멀티홉 라이트닝 네트워크 결제를 가능하게 합니다. 이러한 계약에는 절대 시간 지점에 따라 결정되는 지연(절대 시간 잠금)이라는 또 다른 지연 모듈 함께 제공됩니다. 라이트닝 네트워크에서 결제를 전달하는 경로에서 각 홉은 커밋된 트랜잭션을 확인하고 오랫동안 결제할 수 없는 HTLC를 타임아웃하기 위해 T 블록(CLTV의 시간 잠금 차이)의 시간 창을 갖습니다. 이러한 커밋된 거래를 적시에 확인할 수 없는 경우 기록된 후속 HTLC가 시간 초과되어 시간 초과/환매 경쟁이 발생하기 때문에 "일방적인 환매"로 인해 자금을 잃을 리스크 있습니다.
(역자 주: 지불을 전달할 때 노드는 이전 노드로부터 "들어오는 HTLC"를 받고 다음 노드에 "나가는 HTLC"를 제공합니다. 다운스트림 노드가 지불을 허용하지 않을 때 실패하고 원본을 반환하지 않는 경우 노드의 유일한 방법은 블록에 의해 확인된 트랜잭션을 얻고 온체인 나가는 HTLC의 값을 검색하는 것입니다. 그러나 들어오는 HTLC에도 만료 시간이 있습니다. , 다운스트림 노드는 원본 이미지를 사용하여 나가는 HTLC의 값을 수령하다 하며(수수료 경쟁에 참여) 노드의 자금 손실이 발생하므로 노드는 나가는 것을 허용해야만 이를 피할 수 있습니다. HTLC는 들어오는 HTLC가 일종의 경주/순 손실 시간이 초과되기 전에 블록에 의해 확인됩니다.
노드가 커밋된 트랜잭션(일방적인 종료의 경우)을 적시에 확인받을 수 있는 능력은 효과적인 수수료 예측 능력에 달려 있습니다. 일방적으로 수정할 수 없는 커밋 트랜잭션의 처리 수수료가 충분하지 않은 경우 제때에 승인되지 않습니다(노드의 트랜잭션 풀에서도 승인되지 않습니다!). 현재 채널 개시자는 최신 약정 거래에 대한 처리 수수료를 높이거나 낮추기 위해 상대방에게 update_fee 메시지를 보낼 수 있습니다. 이는 중요한 도구이지만 발신자는 커밋된 거래에 대해 훨씬 더 높은 수수료를 지불할 준비를 해야 하거나(거래가 방송된 후 다음 블록에서 항상 확인되도록 보장하기 위해) 예측을 위해 많은 노력을 기울여야 합니다. 향후 처리 요율. 개시자는 커밋된 거래에 대한 모든 처리 수수료를 지불해야 하기 때문에 응답자는 이 처리 수수료에 직접 영향을 미칠 수 없습니다. 반대로 현재 이 처리 수수료 수준을 수락하지 않으면 강제로 채널을 닫으려고 할 수 있습니다. .
앵커 출력이 여기에 있습니다!
현재 커밋 거래 형식의 일부 단점을 해결하기 위해 사람들은 "앵커 출력"[ 1 ]을 제안했습니다. 일반적인 아이디어는 두 당사자가 약정 거래에서 소액 단위의 출력을 얻을 수 있다는 것입니다. 이 출력은 한 당사자만 사용할 수 있습니다(다른 당사자는 이를 사용할 수 없음). 이 더스트 출력은 나중에 약정 거래에 대한 추가 처리 수수료를 허용합니다. 이 설계는 예상 수수료 요구 사항을 완화하지만 필요성을 완전히 없애지는 않습니다. 이제 목표는 더 이상 다음 블록에서 커밋된 트랜잭션을 확인하는 것이 아니라 노드의 트랜잭션 풀 에 들어갈 수 있을 만큼 높은 수수료를 갖는 것입니다. 거래가 거래 풀에 들어가면 양 당사자는 처리 수수료를 추가하고 최종적으로 커밋된 거래를 확인할 수 있습니다. 또한 이 방법을 사용하면 미결제 HTLC 계약을 청산할 때 더 높은 수준의 일괄 처리를 달성하기 위해 2단계 HTLC 거래를 함께 묶을 수도 있습니다. 그러나 다음 블록에 진입하는 데 필요한 처리 수수료와 유사하게 거래 풀에 진입하는 데 필요한 처리 수수료는 지속적으로 변화하고 있습니다. 노드에는 약 300MB의 기본 트랜잭션 풀 공간 상한이 있기 때문에 들어오는 트랜잭션 수가 점차 증가함에 따라 노드도 가장 낮은 속도의 일부 트랜잭션을 포기하기 시작하여 트랜잭션 풀에 들어가기 위한 수수료 임계값이 증가합니다. . 마지막으로, 기존 앵커 트랜잭션에서 제공할 수 있는 최대 처리 수수료가 트랜잭션 풀에 진입하기에 충분하지 않을 수 있습니다. 이때 커밋된 트랜잭션도 노드에 의해 폐기됩니다. 이때, 트랜잭션 확인을 원하는 노드는 자신이 커밋한 트랜잭션을 브로드캐스트할 수 없으므로(기존 P2P 네트워크 사용), 이는 TA가 제 시간에 이를 확인하지 못할 수도(또는 완전히 확인하지 못할 수도 있음) 의미합니다. 경주는 피할 수 없다.
이 경로를 따라 개발자와 연구원은 거래 브로드캐스팅과 관련된 일련의 미묘한 메커니즘을 발견했으며 실제로 공격자가 거래 풀에서 거래를 "십자가로 만드는"(고의적으로 확인되지 않도록 방지)의 거래 풀 전달 전략을 허용했습니다 . . 알려진 다양한 십자가형 공격 인터페이스는 BIP 125 및 오늘날 널리 사용되는 트랜잭션 풀링 전략(다중 상위 트랜잭션 제한)과 관련된 변형을 활용합니다.
(이번에는) V3, TRUC, 1P1C가 옵니다!
다음은 "V3 트랜잭션"과 "TRUC(블록 확인까지 제한된 토폴로지)"입니다. 라이트닝 네트워크 개발자의 궁극적인 꿈은 update_fee 완전히 제거하고 커밋된 거래를 수수료 없이 만드는 것입니다. 이렇게 하면 어떤 수수료를 설정해야 할지 파악하는 데 필요한 모든 추측이 필요합니다. 그러나 이 작업만 수행하면 거래에 수수료가 없다고 약속하면 거래 풀에서 해당 거래가 승인되지 않으므로 비트코인 P2P 네트워크에 전파되지 않습니다.
TRUC(예: BIP 434)(새로운 유형의 앵커 출력)와 "낙관적 1 부모 1 자식" 트랜잭션 패킷 전달 전략의 조합은 현재 라이트닝 네트워크 트랜잭션의 문제를 실질적으로 해결할 수 있는 가장 잘 알려진 솔루션이 되었습니다. 전달 및 확인 문제.
TRUC는 소수의 시나리오에서 BIP 125의 성능 저하를 해결하기 위해 새로운 트랜잭션 교체 규칙 세트를 도입했습니다. 또한 문제를 더욱 제한하기 위해 새로운 트랜잭션 토폴로지 크기 제약 세트를 추가합니다. TRUC 트랜잭션은 버전 번호 필드 값 3(BIP 125와 같은 시퀀스 필드 대신)을 사용하여 트랜잭션이 이 새로운 규칙 세트를 자발적으로 사용함을 나타냅니다.
또한 Bitcoin Core 28.0에서는 새로운 표준 공개 키 스크립트 유형 "PayToAnchor(P2A)"를 사용할 수 있습니다[ 2 ]. P2A는 CPFP 수수료 추가를 위한 새로운 특수 Segwit v1 출력( OP_1 <0x4e37> )입니다. 이 출력을 사용하는 입력에는 빈 감시 입력이 있어야 하며 서명 없이 사용할 수 있습니다. 이 새로운 유형의 출력의 향후 버전에서는 생성된 블록(CPFP를 통해)과 동일한 블록에서 출력이 소비되는 한 결과적으로 출력이 먼지로 변할 수 있습니다.
이 새로운 커밋 트랜잭션 형식을 위해 설계된 마지막 모듈 다음과 같습니다. 1 상위 1 하위(1P1C) 트랜잭션 패키지 전달 [ 4 ]. 1P1C는 기본적으로 기회주의적 패킷 전달입니다. 새로운 P2P 메시지(전체 네트워크에 배포하는 데 시간이 걸릴 수 있음)에 의존하는 대신 노드가 고아 트랜잭션(아직 입력 트랜잭션을 알지 못하는 트랜잭션)을 수신할 때 동작을 변경할 수 있습니다. 노드는 이 하위 트랜잭션을 고아 트랜잭션 풀에 저장하지 않지만 상위 트랜잭션의 수수료가 로컬 트랜잭션 풀의 수수료 임계값보다 낮은 경우에도 하위 트랜잭션을 보고한 노드에서 선택적으로 상위 트랜잭션을 요청하려고 시도합니다.
시너지 효과를 내기 위해 이 세 가지 새로운 트랜잭션 전달 기본 요소를 사용하여 위에서 언급한 오랜 문제를 해결하기 위해 Lightning 채널의 약정 트랜잭션 형식(예: 앵커)을 재설계할 수 있습니다. t-bast는 x.com 이라는 새로운 약정 거래 형식의 프로토타입을 시작했습니다.
그럼에도 불구하고 아직 해결되지 않은 문제는 다음과 같습니다.
- 커밋된 거래에서 발생하는 먼지를 어떻게 처리합니까?
- P2A 방식을 사용하면 현재처럼 채굴 수수료로 전환되는 대신 모든 먼지를 앵커 출력에 투입할 수 있습니다. 이는 과도한 먼지 출력과 관련된 일부 알려진 문제를 해결하지만 P2A 앵커 출력에는 서명을 사용할 필요가 없기 때문에 새로운 문제도 발생합니다.
- P2A 출력이 "키리스"가 되어야 합니까?
- 출력이 키리스인 경우 제3자는 즉시 앵커 출력 청소를 도울 수 있습니다(현재와 비교하면 채널에 참여하는 두 당사자만 앵커 출력이 확인된 후 16블록까지 앵커 출력을 즉시 청소할 수 있습니다).
- 위의 사항과 관련하여, 배출된 먼지를 모두 P2A 앵커에 넣으면 P2A 앵커를 청소하는 사람이 모든 먼지 배출의 가치를 빼앗아 갈 수 있습니다. 당연히 채굴자는 서명 요구 사항이 없다는 가정 하에 가장 안정적으로 자금을 청구할 수 있는 사람입니다.
- 어떤 사람들은 서명 요구 사항을 유지해야 한다고 주장합니다. 이는 다른 사람들이 커밋된 거래를 확인하려는 참가자를 방해하는 것을 방지하기 때문입니다. 이는 TRUC+P2A 조합에서 발견되지 않은 결함(아직 발견되지 않은 공격의 리스크 초래할 수 있음)에 대한 리스크 을 방지하기 위한 것입니다.
- V3 트랜잭션의 바이러스 전파 특성이 고급 채널 접합과 관련된 특정 애플리케이션 시나리오에 영향을 줍니까?
- V3 트랜잭션의 확인되지 않은 모든 하위 항목은 V3 트랜잭션으로 유지되어야 합니다. 따라서 이것이 하나의 거래 배치로 여러 거래 흐름을 충족시키려고 하는 채널 접합의 사용에 영향을 미칠 것이라는 우려가 있습니다. V3 트랜잭션 유형의 입소문 특성으로 인해 확인되지 않은 변경 출력을 소비하는 사람은 누구나 자신의 능력을 넘어서는 V3 트랜잭션을 계속 사용하게 됩니다.
새로운 TRUC 규칙은 일종의 트랜잭션 패키지 RBF도 허용합니다. 충돌하는 새로운 트랜잭션 패키지가 들어오면 노드는 기존 트랜잭션 패키지 RBF와 일치하려고 시도합니다. 1P1C의 맥락에서는 이를 "형제 퇴거"라고도 합니다[ 5 ].
위의 모든 정보는 지갑 개발자를 위한 이 편리한 가이드에서 자세한 내용을 확인할 수 있습니다 [ 6 ].
먼지 배출 처리는 이번 회의 이후 더욱 구체적인 새로운 계획 중 하나가 될 수 있습니다. 여기에서 우리는 새로운 전달 동작에 의존할 수 있도록 P2P 네트워크의 충분한 노드가 새 버전으로 업그레이드될 때까지 기다리는 동안 새로운 V3 커밋 트랜잭션이 어떻게 나타나는지 알아낼 것입니다.
또한 이러한 변화가 라이트닝 노드 뒤의 지갑이 UTXO 재고를 처리하는 방식에 더욱 영향을 미칠 것이라는 점도 지적할 가치가 있습니다. 이 방법을 사용하면 주어진 약정 거래에 처리 수수료가 부과되지 않습니다. 거래를 확인하려면 노드가 기존 UTXO를 사용하여 약정 거래를 고정 해야 합니다 . 그렇지 않으면 약정 거래가 방송될 수도 없습니다. 실제로 이는 채널이 적시에 폐쇄될 경우 지갑이 온체인 자금을 예약해야 함을 의미합니다. 채널 접합 및 잠수함 스왑과 같은 도구를 사용하여 지갑에서 자금을 이동하거나 여러 온체인 상호 작용을 일괄 처리할 수 있습니다.
PTLC 및 단순화된 약정 거래 형식
다음 회의에서는 "PTLC(Point Time Lock Contract)"와 "Simplified Channel State Machine"의 조합에 중점을 두었습니다. 언뜻 보기에 이 두 주제는 어떤 식으로든 관련이 없어 보일 수 있지만, PTLC의 설계 고려 사항으로 인해 발생하는 까다로운 상황 중 일부는 현재 채널 상태 머신 프로토콜을 수정하여 해결할 수 있음을 곧 알게 될 것입니다. "라이트닝 채널"). 커밋 프로토콜(LCP)")은 완화하기 위한 단순화된 변형입니다.
먼저 PTLC에 대해 간략히 소개하겠습니다. 현재 라이트닝 네트워크 프로토콜에서는 결제 해시를 사용하여 다중 홉 청구 또는 저하 장치를 구현하여 신뢰가 최소화된 다중 홉 결제를 허용합니다. 이 프로토콜은 간단하지만 개인 정보 보호 측면에서 큰 단점이 있습니다. 전체 전달 경로를 구성하는 모든 채널에서 결제를 전달하는 해시 값이 동일하므로 적이 두 위치를 점유하는 경우 결제를 쉽게 연결할 수 있습니다. ("다중 경로 결제(MPP)" 주기를 깨는 동시에).
이러한 개인정보 보호 허점을 해결하기 위해 개발자들은 몇 년 전 해시와 사전 이미지를 지불하는 대신 타원 곡선과 개인 키를 사용하도록 전환할 것을 제안했습니다. 2018년에는 ECDSA 및 Schnorr 서명 체계 전반에 걸쳐 "어댑터 서명"을 사용하여 이 새로운 구성을 실제로 인스턴스화할 수 있는 공식 체계가 등장했습니다[ 7 ]. 이는 taproot 업그레이드가 활성화될 때까지 기다릴 필요가 없다는 점에서 흥미롭습니다(Schnorr 서명이 활성화됩니다). 이와 대조적으로 다중 홉 잠금은 ECDSA 홉과 Schnorr 홉으로 구성된 경로에서 전송될 수 있습니다. 결국 여러 가지 이유로 이 하이브리드 접근 방식은 배포되지 않았습니다. 이점은 더 간단하고 균일한 Schnorr 서명 전용 다중 홉 잠금을 배포할 수 있다는 것입니다.
지금은 "대칭형 라이트닝 채널(LN-Symmetry)"의 특정 설계를 연구하는 것 외에도 istagibbs는 메시지 전파부터 상태 머신 플러그인까지 다양한 설계 공간을 탐색했습니다[ 8 ].
그의 연구 결과 중 일부를 논의한 후 우리는 몇 가지 주요 설계 문제에 초점을 맞추기 시작했습니다.
단일 서명 또는 다중 서명 기반 어댑터 서명을 사용해야 합니까? 두 방법 모두 서명을 생성하는 데 사용된 어댑터 포인트
T통해 제안자는 서명을 HTLC에 서명하는 데 필요한 개인 키를 보완할 수 있습니다.musig2 서명 알고리즘을 기반으로 하는 어댑터 서명은 크기가 더 작지만(두 개의 서명이 아닌 하나의 서명으로 끝남) 추가 조정 요구 사항이 추가됩니다. 두 당사자 모두 새 약정 트랜잭션을 적절하게 생성하려면 nonce 값을 제공해야 하기 때문입니다.
단일 서명 기반 어댑터는 더 큰 서명(현재 2단계 HTLC 트랜잭션과 같이 두 개의 서명 포함)을 갖지만 HTLC 서명을 평소대로
commit_sig와 함께 보낼 수 있으므로 프로토콜이 더 간단합니다.musig2 어댑터 시그니처 디자인을 사용하기로 결정한 경우 현재의 전이중 비동기 LCP 흐름을 유지하려고 합니까? 아니면 더 단순화하고 간단한 동기식 약속 상태 머신 프로토콜을 사용해야 할까요?
2단계 HTLC 트랜잭션에 musig2 nonce를 도입하면 기존 LCP 프로토콜이 더욱 복잡해집니다. 왜냐하면 상태 변경을 제안하는 당사자는 더 이상
commit_sig메시지와 함께 2단계 HTLC 트랜잭션의 서명을 보낼 수 없기 때문입니다. 안전하게 계속하려면 응답자의 서명 조각을 사용하세요.그러나 채널 상태 머신 프로토콜을 라운드 기반 으로 수정하면 일부 x-put을 희생하더라도 가능한 인터리브 실행을 처리하는 방법에 대해 걱정할 필요가 없습니다(양 당사자가 동시에
update_add_sig+commit_sig보냅니다). ). 이는 프로세스 간소화라는 주제로 이어집니다.
라운드 기반 채널 상태 머신 프로토콜
오늘날의 Lightning Network 프로토콜에서는 전이중 비동기 상태 머신을 사용합니다. 즉, 양측은 사전에 상대방과 상의하지 않고도 언제든지 상태 변경을 제안할 수 있습니다. 언제든지 우리는 4가지 유형의 커밋 트랜잭션을 가질 수 있습니다. 한쪽 당사자에 대해 확정된 커밋 트랜잭션과 아직 구성되지 않은 커밋 트랜잭션(서명은 수신되었지만 철회 비밀 값은 아직 전송되지 않음) . 양 당사자가 계속해서 서명을 보내고 자신의 기존 커밋 트랜잭션을 취소한다고 가정하면 결국 양 당사자의 "커밋 트랜잭션 체인 헤드"는 동일한 진행 중인 HTLC 세트를 다루게 됩니다.
이 디자인은 연결 시작 시 양측이 여러 개의 취소 비밀 값을 보내더라도 슬라이딩 윈도우에서 이를 소비하기 때문에 상대방을 기다리지 않고 계속해서 새로운 상태를 보낼 수 있기 때문에 처리량 친화적입니다. 새로운 실행 취소 비밀 값이 메소드에 설정될 때마다 이전 상태가 무효화될 수 있습니다. 이는 TCP의 슬라이딩 윈도우 기능과 유사합니다.
이 프로토콜의 단점은 실행 중에 발생한 불일치나 오류를 복구하는 것이 절대 불가능하다는 것입니다. 양 당사자 모두 마음대로 업데이트를 보내기 때문에(다시 보낸 후에도 계속 보내기 때문에) 일시 중지하거나 되감아서 계약 상태를 복원할 방법이 없습니다.
한 가지 예는 채널의 예비금입니다(역자 주: 참가자가 잔액 소진한 후 취소된 약정 거래를 손실 없이 보낼 수 없도록 하기 위해 잔액 에서 사용할 수 없는 부분). 현재 약정 거래에서는 어느 당사자가 HTLC를 추가하기를 원하든 채널 개시자는 자신의 자본 투입으로 수수료를 지불해야 합니다. 그러나 언제든지 나타날 수 있는 새로운 HTLC에 대한 비용을 실제로 지불하려면 채널 스폰서가 자체 채널 적립금을 사용하여 수수료를 지불해야 할 수도 있습니다. 양측은 언제든지 HTLC를 제안할 수 있기 때문에 이러한 까다로운 상황을 방지하려면 향후 HTLC에 대한 수수료 처리를 위한 충분한 버퍼 자금을 남겨 두어야 합니다. 하지만 상대방의 미래 HTLC를 정확하게 예측하기는 어렵습니다.
라운드 기반 프로토콜이 있으면 이러한 까다로운 상황을 모두 미리 파악한 다음 항상 채널 실행을 재개하고 비용이 많이 드는 강제 폐쇄를 피할 수 있습니다. 이러한 턴 기반 프로토콜은 RTS(전송 요청) 및 CTS(전송 지우기)[ 8 ]를 기반으로 하는 흐름 제어 프로토콜과 유사합니다.
정상적인 실행 중에 두 당사자는 교대로 커밋된 트랜잭션 집합에 대한 변경 사항을 제안합니다(HTLC 추가 또는 제거). 한 쪽이 아무런 변경도 하지 않으면 다른 쪽이 먼저 갈 수 있습니다. 중요한 점은 이 단순화된 계약에서 양 당사자가 일련의 변경 사항에 대해 명시적으로 반대(NACK)하거나 동의(ACK)할 수 있다는 것입니다. 변경 사항에 반대할 수 있는 기능이 있으면 잘못된 프로세스에서 복구할 수 있어 잘못된 종료 요구 사항에 대해 프로토콜이 더욱 강력해집니다.
musig2 기반 PTLC를 사용하면 라운드 기반 실행에서 양측 모두 nonce 값을 미리 보낼 수 있으므로 nonce 값의 비동기 교차 교환에 대한 분석적 어려움이 제거됩니다. 또 다른 이스터 에그는 현재 상태 머신 프로토콜에 대한 자세한 설명이 부족하기 때문에 이 프로토콜이 분석하기가 훨씬 쉬울 수 있다는 것입니다.
오프체인 팬시 쇼: SuperScalar, Channel Factory 등
컨퍼런스 첫날이 끝날 무렵, 우리는 "공유 UTXO 소유권"을 활용하여 활성화할 수 있는 오프체인 채널 구성, 즉 오프체인 채널 생성, 저렴한 자체 보관형 모바일 지갑(신규 사용자 유치)에 중점을 두었습니다. , 다자간 거래 실행의 일괄 처리. 관련 제안에는 채널 팩토리, 타임아웃 트리, 방주, 클락 등이 포함됩니다.
최근 발표된 제안인 SuperScalar [ 9 ]는 사용자 제어 모바일 라이트닝 지갑의 "라스트 마일" 문제를 해결하기 위해 많은 기본 요소를 결합하려고 시도합니다. SuperScalar는 LSP(Lightning Network Service Providers)가 자금을 훔칠 수 없도록 하고 논의된 비트코인 합의 변경에 의존하지 않으며 궁극적으로 시스템이 진행됨에 따라 개선할 수 있는 능력을 유지하는 동시에 일부/모든 사용자를 허용하면서 현상 유지를 변경하려고 시도합니다. 오프라인으로.
SuperScalar에 대한 가장 적절한 설명은 이중 소액 결제 채널[ 10 ], John Law가 제안한 "Timeout Trees"[ 11 ], 그리고 SuperScalar를 인스턴스 코디네이터가 자금을 분산하고 기회비용을 최소화하라.
여기에서 전체 계획을 다루지는 않을 것이며, 대신 위에 언급된 Delving Bitcoin 게시물을 살펴보는 데 관심이 있는 사람을 추천합니다. 회의 후 Z는 자신의 계획에 대한 몇 가지 새로운 반복을 제안하여 몇 가지 단점을 해결하고 다른 방향으로 포크.
요약하면 위의 세 가지를 결합하면 큰 트랜잭션 트리가 됩니다. 각 트랜잭션(리프)은 LSP와 사용자에 속하는 일반적인 두 당사자 채널입니다. 채널(리프)에서 시작하여 각 레벨 위로는 해당 하위 트리의 참가자로 구성된 또 다른 다중 서명 장치입니다. 또한 각 리프에는 추가 자금 L이 포함된 추가 출력이 있으며, 이는 LSP와 사용자가 온라인 상태인 한 채널에 추가 유동성을 할당하는 데 사용할 수 있습니다. 더 많은 참가자가 온라인에 접속하면 트랜잭션 트리의 상위 지점도 다시 서명될 수 있으므로 채널 용량을 더 큰 규모로 재할당할 수 있습니다.
이 래더링 기술을 통해 LSP는 오프체인 트리 구조의 여러 인스턴스에 자금을 할당할 수 있습니다. 타임아웃 트리 기술은 모든 사용자에게 지연 기반 종료 경로를 제공하는 데 사용됩니다. 이 구성에서는 강제 종료를 위해 항상 전체 트랜잭션 트리를 공개해야 하는 것은 아닙니다. 일정 시간이 지나면 인스턴스의 모든 자금이 LSP에 제공됩니다. 이는 사용자가 Ark 구조의 공유 VTXO가 작동하는 방식과 유사하게 구조의 다음 인스턴스/래더로 점프해야 함을 의미합니다(시간 제한 트리 형식도 사용함). 결과적으로 이 구조의 모든 채널은 더 이상 무한한 수명을 갖지 않습니다. 사용자는 모든 자금을 밖으로 옮기거나 LSP와 협력하여 다음 인스턴스에서 새 채널을 얻습니다. 그렇지 않으면 사용자는 자금을 잃게 됩니다.
SuperScalar 인스턴스의 수명은 활성 단계와 종료 단계의 두 단계로 나눌 수 있습니다. 활성 단계 동안 사용자는 정상적으로 채널을 사용할 수 있습니다. 인스턴스를 일찍 종료하도록 선택할 수도 있지만 대부분의 경우 오프라인 상태를 유지할 수 있습니다. 종료 단계에서 사용자는 온라인에 접속하거나 자금을 이체하거나 다른 인스턴스로 마이그레이션 해야 합니다 . 또한 보안 창이 내장되어 있습니다. 일단 사망 기간이 시작되면 LSP는 더 이상 사용자와 협력하여 거래 트리를 업데이트하지 않으며 결제만 로그아웃할 수 있습니다(LSP는 모든 채널의 일부이지만 하위 채널은 구현될 수도 있으며 추가적인 신뢰가 필요합니다).
추가 출력 L로 돌아가면, 앞에서 언급한 것처럼 출력 L은 LSP가 마음대로 사용할 수 있는 것입니다. 사용자에게 추가 채널 용량이 필요한 경우 LSP는 L의 비용으로 대상 사용자 A와 함께 새로운 하위 채널을 생성할 수 있습니다. 그러나 LSP는 다른 사용자 B와 L에 서명할 수도 있습니다. 즉, 출력 L을 오프체인에서 반복적으로 소비할 수도 있습니다. 이러한 지출 중 한 가지 버전만 온체인 나타날 수 있습니다. 이는 본질적으로 LSP가 초과 인출되어 잠재적으로 자금을 훔치거나 사용자가 자신의 것이라고 생각한 자금을 잃을 수 있음을 나타냅니다. 한 가지 해결책은 두 번 서명할 경우 개인 키가 노출되도록 하는 서명 체계를 사용하는 것입니다. 이러한 체계를 구성하는 방법에는 OP_CAT, 서명을 7개 이상의 인스턴스로 나누기 또는 이 문서에 설명된 두 개의 어댑터 서명 체계를 사용하는 방법이 있습니다[11].
상위 계층에서 이중 소액 결제 채널을 사용한다는 것은 내부 업데이트 수가 증가함에 따라 사용자가 이 구성에서 벗어나기 위해 발행해야 하는 거래 수도 증가한다는 것을 의미합니다. 늘 그렇듯 우리는 결국 블록체인의 경제성과 관련하여 피할 수 없는 상충 관계에 직면하게 됩니다. 결제 시작 비용이 결제 자체의 가치를 초과하면 결제가 발생하지 않거나, 비용을 절약하기 위해 보안을 희생하는 시스템에서 발생합니다. . 즉, 강제 종료에는 추가 비용이 필요하기 때문에 이러한 구조에서 사용자가 소규모 채널을 갖는 것은 의미가 없을 수 있습니다. 소규모 채널을 경제적으로 만들려면 코디네이터가 보조금을 지급해야 하거나 사용자가 채널을 온체인 노출할 필요가 없습니다. 즉, 항상 다음 SuperScalar 래더로 이동할 수 있습니다.
또 다른 흥미로운 주제는 추측입니다. 온체인 트랜잭션을 전혀 사용하지 않고는 오프체인 채널에 안전하게 참여하는 것이 불가능합니다. 이것이 왜 어려운지 알아보기 위해 Alice와 Bob이 이미 채널을 가지고 있고 Carol이 채널에 참여하기를 원하는 시나리오를 생각해 보십시오. Alice와 Bob은 Carol의 공개 키를 사용하여 새로운 상태를 생성하고 채널의 커밋 트랜잭션에 세 번째 출력을 추가합니다. Carol은 이것이 최신 상태임을 확신시키기 위해 Alice와 Bob에게 몇 가지 정보를 요청하지만 실제로는 A와 B가 항상 가짜 상태 업데이트 기록을 위조할 수 있습니다. 루트의 다중 서명 설치에는 두 명의 서명자만 있으므로 A와 B는 항상 Carol에게 커밋된 트랜잭션을 두 배로 지출하고 Carol을 채널에서 제거하고 그녀에게 커밋된 잔액 훔칠 수 있습니다. 잠시 생각해 보면 이것이 PoS 체인의 "Nothing at 스테이크" 문제와 유사하다는 것을 알 수 있습니다. A와 B가 Caorl을 속이기 위해 역사를 위조하는 데에는 비용이 들지 않습니다.
이 불가능한 추측의 주요 결론은 완전한 오프체인 동적 멤버십(누구나 언제든지 들어오고 나갈 수 있음)을 구축하려면 (1) 루트 서명자에 대한 신뢰 또는 (2) 특정 유형의 전가 + 처벌 메커니즘이 필요하다는 것입니다. ; 또는 (3) 온체인 거래. 첫 번째 범주의 솔루션에는 Liquid, Statechian 및 Ark가 포함됩니다. 솔루션의 두 번째 범주인 우리는 지난 1년 동안 정직한 참여자 가정에 의존하고 대화형 온 온체인 사기 증명을 활용하여 사기를 규명하고 처벌하는 BitVM과 같은 솔루션의 출현을 보았습니다. 마지막 범주에는 Ark, SuperScalar 및 일반적으로 John Law의 Timeout Tree와 같은 구성이 포함됩니다. 마지막 범주의 체계에서 사용자는 온체인 트랜잭션에 의해 생성된 새로운 출력을 사용하여 리프에서 루트까지 유효하고 변경 불가능한 트랜잭션 집합을 검증하여 일방적으로 자신의 새로운 채널을 소환할 수 있습니다.
정리하자면, 이 부분의 의미 있는 요약은 다음과 같습니다.
- 개발자와 서비스 제공업체는 온체인 공간을 줄이고 자본 효율성을 높이기 위해 사용자를 온보딩할 수 있는 새로운 방법을 찾고 있습니다.
- 유망한 솔루션은 채널 팩토리, 타임아웃 트리, 다자간 채널, 임시 오프체인 자금 교환 프로토콜(Ark 프로토콜 제품군) 등의 기술을 조합한 것으로 보입니다.
- 불필요한 복잡성이 너무 많이 발생하는 것을 방지하기 위해 모든 새로운 프로토콜은 점진적인 배포 계획을 따라 모듈 순차적으로 제공하고 각 새 모듈 이전 모듈 기반으로 구축될 가능성이 높습니다.
부활절 달걀 링크: 번개 연설
회의 사이에 사람들이 자신이 개발하고 있는 흥미로운 것에 대해 이야기할 수 있는 번개 토크 이벤트가 있었습니다.
이러한 대화에서 나타난 뛰어난 전자 기능은 사용자가 잘못된 강제 종료 요구로부터 복구할 수 있는 능력이었습니다. 이와 같은 일은 소프트웨어 구현 간의 불일치 등 다양한 이유로 항상 발생하며, 가장 일반적인 이유는 처리 수수료에 대한 불일치입니다. 여기서의 기본 아이디어는 채널이 강제로 폐쇄될 경우 적이 가능한 한 빨리 자금을 사용할 수 있도록 추가 키를 제공하는 것입니다. 이는 온체인 거래를 시작하지 않은 당사자를 대표하는 순전히 이타적인 행동일 뿐만 아니라 상대방에게 실제로 도움이 될 수 있는 우호적인 행동이기도 합니다.
기계적으로 이를 달성하는 한 가지 방법은 경로를 취소하여 상대방이 출력을 지우도록 최선을 다하는 것입니다(일반적인 사용법과 반대). 일부 사람들은 파생된 출력 구성을 약간 수정하여 채널 재구축 메시지에 새 정보를 캡슐화하는 방법에 대해서도 논의했습니다. 비방송 당사자는 공개되는 내용이 최신임을 확실히 알고 확인을 받은 경우에만 해당 정보를 공개합니다.
험담을 덜 짜증나게 만드세요
다음날 아침 첫 번째 세션은 가십 프로토콜을 통해 달성할 수 있는 구체적인 개선 사항을 찾는 것이었습니다.
가십 동기화 단서
라이트닝 네트워크의 가십 프로토콜은 잘 정의된 구조를 가지고 있지만 구현에 따라 많은 동작 영역을 남겨둡니다. 이러한 동작의 예는 다음과 같습니다. 얼마나 많은 동기화 피어를 유지해야 합니까? 가십 메시지 수신 속도를 제한해야 합니까? 새로 입력된 채널은 어떻게 확인되나요(있는 경우)? 누락된 채널을 찾기 위해 정기적으로 토폴로지 맵을 무작위로 검사해야 합니까? 매번 처음부터 모든 것을 다운로드해야 합니까?
토론 중에 대부분의 경우 각 구현은 유사하게 구현하지 않은 내용을 다른 구현으로부터 배웠습니다. 몇 달/주마다 새로운 채널 업데이트나 채널 공지 전파를 방해하는 미묘한 버그를 발견합니다. LND는 가시성과 의사소통을 돕기 위해 최근에 수행한 가장 큰 개선 사항이 가십 쿼리 요청에서 채널 업데이트 타임스탬프 정보를 사용하기 시작한 것임을 발견했습니다. 이 정보가 없으면 노드는 상대방과 동일한 채널 세트(scid 기반)를 가지고 있더라도 상대방이 더 새로운 채널을 가질 수 있다는 것을 식별할 수 없습니다. 구현이 오랫동안 비활성화된 "좀비 채널"을 제거하지만 가십을 적극적으로 동기화하지 않는 경우 가십 쿼리 요청에서 채널 업데이트 타임스탬프를 확인하지 않으면 이전 좀비 채널을 다시 얻을 수 없습니다. 네트워크 토폴로지 다이어그램의 일부입니다.
가십 2.0
다음으로, 코드명 "Gossip 2.5"(또는 대화 대상에 따라 "2.0")라는 가십 프로토콜에 대해 새로 제안된 수정 사항을 살펴보겠습니다. 지난 사양 회의 이후 LND는 사양[14] 및 구현[ 15 ]을 발전시켜 왔습니다. 현재 해당 사양은 추가 검토/피드백을 기다리고 있으며, 올해부터 LND는 해당 프로토콜을 e2e 환경(신규 채널만 해당)에서 작동하도록 만들었습니다.
우리가 논의한 새로운 추가 사항 중 하나는 채널 발표 메시지에 SPV 증거를 추가하는 것이었습니다. 일부 구현은 조건부로 또는 무조건적으로 선언된 채널의 온체인 자금을 전혀 확인하지 않습니다(LND와 같은 전자는 --routing.assumechanvalid 플래그를 사용합니다). P2P 네트워크를 완전히 사용하는 라이트 클라이언트(예: Neutrino 클라이언트)의 경우 블록에서 수만 개의 트랜잭션을 가져오는 것은 전력/대역폭/CPU에 큰 부담이 될 수 있습니다. 채널 발표 메시지가 SPV 증명을 전달할 수 있지만 항상 커밋할 수 있다면 채널의 존재는 최신 블록 헤더 체인을 통해서만 확인할 수 있습니다. 최종 페이로드의 해시 다이제스트/루트만 서명된 경우 추가 증거가 필요하지 않은 모든 노드는 보낸 사람에게 이 정보를 생략하도록 요청할 수 있습니다. 과거에 LND는 일괄 처리 수준에서 집계를 지원하고 재사용할 수 있는 증거 형식을 개발했습니다[ 16 ].
상호 운용성 테스트와 관련하여 다른 구현에는 현재 다른 우선 순위 구현이 있거나 musig2를 통합하기 위해 업스트림 라이브러리의 진행 상황을 기다려야 할 수도 있습니다(이 개발자 회의 후 libsecp 라이브러리의 musig2 PR이 병합되었습니다!). 현재 testnet4를 지원하는 주요 구현이 없으므로 아직 라이트닝 채널이 없을 수 있으며 참석자 모두 testnet4를 gossip 2.0의 첫 번째 시험장으로 만드는 데 동의했습니다!
Gossip 2.0은 이전 채널 업데이트 메시지의 타임스탬프 필드를 취소하고 이를 블록 높이로 대체합니다. 피어가 각 블록을 한 번만 업데이트할 수 있도록 지정할 수 있으므로 속도 제한이 단순화됩니다. 블록 높이가 전 세계적으로 균일하기 때문에(시간대와 같은 로컬 속성이 없음) 다양한 집단 조정 프로토콜에 더 적합합니다. 몇몇 참석자들은 기존 미니 스케치 구현을 용도 변경하는 방법에 대해 연구를 수행했으며, 서로 다른 한계에 직면하더라도 결국 여러 가지 다른 것을 동시에 사용하게 될 수 있습니다.
(참고: 이 시간 동안 노트북에 커피를 쏟았습니다. 문제 해결을 위한 토론의 상당 부분을 놓쳤습니다.)
지불 분배에 대한 근본적인 제한
그런 다음 세션 중 하나에서는 Lightning Network 경로 찾기/라우팅에 대한 최신 연구에 대해 논의했습니다. 주요 주제는 지불 채널 네트워크에서 지불을 분배하는 근본적인 한계를 이해하려는 일부 새로운 연구에 대한 프레젠테이션/토론/양자 채널의 한계 /논문/지불 채널 네트워크의 수학적 이론.pdf)]입니다.
간단히 말해서, 이 연구에서는 네트워크 토폴로지를 일련의 에지와 정점으로 모델링하며, 각 에지는 로컬 잔액, 원격 잔액 및 총 용량이라는 세 가지 속성을 갖습니다. 샘플 토폴로지가 주어지면 지불이 전달될 수 있는지 여부, 즉 "수취인"에게 원하는 잔액 최종 상태를 제공하는 일련의 쌍별 잔액 수정이 있는지 여부를 결정할 수 있습니다. 이 연구는 기존의 탐욕 기반 경로 찾기 알고리즘을 실행하지 않고 대신 전 세계적으로 지불의 타당성을 조사합니다. 이 접근 방식은 결제 기간 동안 강제 재조정을 수행하여 불만족스러운 결제 흐름이 실행되도록 하는 기능을 자연스럽게 포착합니다.
필연적으로 일부 결제 흐름은 달성이 불가능합니다. 이유는 다음과 같습니다: 채널 용량 부족, 발신자 잔액 부족, 수신자 신용 부족 등. 이런 일이 발생하면 이 모델 내에서 네트워크의 현재 잔액 수집에 자금을 추가하거나 인출하기 위해 온체인 트랜잭션이 발생해야 합니다. 이러한 온체인 거래의 예로는 채널 열기, 채널 닫기, 채널 연결 또는 잠수함 호출 사용 등이 있습니다.
위의 주의 사항과 몇 가지 시작 가정(토폴로지 다이어그램, 잔액 분포, 두 노드 간 지불 가능성의 샘플 분포)을 기반으로 지불 채널 네트워크의 효과적인 처리량에 대한 상한선을 도출할 수 있습니다. 이 값(T)에 도달하기 위해 블록체인 대역폭 TPS(Q)를 예상되는 실행 불가능한 지불 발생률(R)로 나눕니다. 즉, T = Q/R입니다. T를 (예를 들어) 47,000 TPS로 하고 현재 메인 체인의 TPS(약 14)를 대체하면 R을 0.029%로 얻을 수 있습니다. 즉, 47,000 TPS는 0.029% 지불이 이루어져야 달성할 수 있습니다 가능하지 않습니다.
궁극적으로 이러한 수치는 단순화된 가정을 기반으로 한 단순한 수학으로 귀결됩니다. 이 모델이 고려하지 않는 한 가지 측면은 온체인 상호작용이 일괄 처리될 수 있다는 것입니다. 즉, 여러 채널/사용자가 단일 온체인 트랜잭션으로 오프체인 용량/대역폭을 구성할 수 있다는 것입니다. 위의 파생은 온체인 거래를 실행할 필요가 전혀 없는 균형 지불(예: 수수료 없이 두 노드 간에 주고받는 지불)을 고려하지 않지만 TPS 파생을 고려하지 않습니다. 그럼에도 불구하고 그러한 모델은 시스템의 한계에 대한 추상적인 감각을 얻는 데 유용합니다.
다자간 채널 및 신용 채널
또한 이 연구는 실행 불가능한 결제 수를 줄이는 데 도움이 될 수 있는 두 가지 기본 요소, 즉 다자간 채널과 네트워크 내 신용을 식별합니다.
다자간 채널은 채널 그래프에 여러 사용자를 집계하여 효과적으로 완전히 연결된 새로운 하위 그래프를 형성합니다. 여기서 직관은 다음과 같습니다. 각 방향에서 채널에 추가되는 자금의 양을 상수로 취급하면 참가자 수를 늘리면 각 사용자가 가질 수 있는 최대 자금 금액도 늘어납니다. 이 최대 금액을 늘리면 잔액/용량 제약으로 인해 실현 불가능한 결제 횟수가 줄어듭니다.
그런 다음 크레딧이 있고 아이디어는 간단합니다. 결제가 불가능할 경우 특정 홉에서 크레딧을 도입하여 채널의 용량을 영구적으로 또는 일시적으로 확장하는 동시에 특정 당사자의 잔액 늘릴 수 있습니다. 시스템 리스크 최소화하기 위해서는 이러한 신용이 네트워크의 핵심에 도입되어서는 안 되고 가장자리에만 존재해야 하는 것으로 보입니다. 이론적으로 Taproot Assets와 같은 프로토콜을 사용하면 사용자가 채널에서 기본적으로 주소 지정/검증 가능한 신용 개념을 표현할 수 있으므로 결제 실행 가능성을 높이는 동시에 사용자 온보딩 비용을 줄일 수 있습니다.
모바일 사용자 참여를 위한 최종 단계 문제
결국 우리는 모바일 셀프 커스터디 지갑의 고객 확보와 사용자 경험에 초점을 맞춘 두 개의 별도의 관련 세션을 가졌습니다. 첫째, 모바일 사용자 경험 및 시작과 관련이 있기 때문에 "라스트 마일" 문제가 있습니다[ 17 ].
현재 라이트닝 네트워크에서 대부분의 사용자 경험 문제는 한 사용자가 다른 사용자에게 비용을 지불하려고 시도할 때 발생하지만 수신자는 자체 관리되는 모바일 지갑을 사용합니다. 이는 인터넷 인프라 및 대역폭의 라스트 마일 전송 문제와 유사합니다. 네트워크 내부에는 인트라넷 내에서 신속하게 정보를 교환할 수 있는 고대역폭의 "느슨한 파이프"가 포함되어 있습니다. 그러나 인트라넷에서 최종 대상으로 정보를 보내는 것은 더 많은 비용이 들고 신뢰성이 떨어지며 속도가 느려집니다.
고객 확보 비용 및 채널 유동성
라이트닝 네트워크의 맥락에서 다뤄야 할 것은 노후화된 인프라나 높은 구축 비용이 아니라, 모바일 기기 자체의 다양한 특성입니다. 항상 온라인 상태인 라우팅 노드와 달리 모바일 노드는 새로 들어오는 업데이트에 서명하기 위해 깨어나야 합니다. 또한, 모바일 노드가 순 결제 사용자가 되기를 희망하는 경우(그러나 메인 체인 자금이 없고 라이트닝 네트워크에 직접 진입하는 경우) TA에 대한 유동성 라인을 잠그기 위한 라우팅 노드가 있어야 합니다. 이 첫 번째 채널의 설정은 라우팅 노드의 관점에서 볼 때 자본을 차지합니다. 왜냐하면 모바일 노드가 이제부터 네트워크를 종료하고 채널의 자금이 유휴 상태로 남을 가능성이 있기 때문입니다. 오랫동안 오프라인 상태였던 사용자로부터 자금을 회수하려면 라우팅 노드가 채널을 강제로 폐쇄하고 온체인 처리 수수료와 시간(상대 시간 잠금이 만료될 때까지 대기, 최대 2주)을 지불해야 합니다.
라스트 마일 유동성 비용에 대해 더 깊이 파고들면서 경제적 측면에서 몇 가지 근본적인 한계에 부딪히기 시작합니다. 사용자가 채널에서 10 사토시만 받고 채널을 열기 위해 1,000 사토시(온체인 처리 수수료)를 지불해야 하는 경우 해당 사용자와 연결을 설정하면 라우팅 노드의 순 손실이 발생합니다(물론 말할 것도 없습니다). 현재 네트워크에는 여전히 1,000개의 사토시가 있습니다). 채널의 최소 용량에는 제한이 있습니다. 라우팅 노드가 비활성 사용자에게 할당한 자본(수집 금액)은 대신 네트워크의 고속 채널에 할당될 수 있으며, 여기서 라우팅 수수료는 채널 개설 비용을 충당하기 위해 벌어집니다. 비용이 균등하게 분배되고 보조금이 지속될 수 있다고 가정할 때 인프라 도구에는 Phoenix Wallet의 JIT 채널 시스템, Liquidity Ads [ 18 ], Lightning Pool을 사용한 Sidecar 채널, Amboss의 Magma 등이 포함됩니다.
프로토콜로 인한 사용자 경험 문제
온라인 상호 작용 요구 사항 및 온체인 처리 수수료 외에도 현재 프로토콜 설계에는 몇 가지 추상화가 포함되어 있으며 이는 결국 최종 사용자의 모바일 지갑에 들어가고 고객 확보 비용이 됩니다. 한 가지 예는 채널 예비입니다. 양 당사자가 수명 주기 전반에 걸쳐 걱정할 사항(사기 시도 방지)을 갖도록 하려면 항상 채널에 작은 잔액(보통 약 1%)을 유지해야 합니다. 지갑에 있는 전체 잔액 다른 지갑으로 이체하려는 경우가 많지만 항상 적은 금액을 유지해야 한다는 사실을 알게 되므로 사용자에게는 실망스러울 수 있습니다. 또한, 온체인 처리 수수료가 증가함에 따라 경제적으로 효율적인 채널 용량도 증가합니다.
유동성 수수료 리베이트
먼지/소량 출력 문제에 대한 최근 해결책은 "수수료 리베이트"라고 불리는 phoenixd [ 21 ]에서 사용하는 개념입니다. 수수료 환불은 향후 결제 크레딧을 구매하는 데 사용되는 환불 불가능한 결제입니다. 사용자가 특수 라우팅 노드(이 프로토콜 플러그인을 지원하는 노드)로부터 자금을 받았지만 사용자에게 아직 채널이 없을 때마다 자금은 이 수수료 환불 탱크에 들어가게 됩니다. 사용자가 이 리베이트 항아리에 충분한 자금을 축적하면 라우팅 노드는 TA와 채널을 열고 항아리에 있는 리베이트를 사용하여 서비스 수수료와 온체인 처리 수수료를 지불합니다. 채널을 개설하는 데 필요한 최소 금액은 서비스 및 온체인 수수료에 따라 다릅니다.
실용적인 관점에서 보면 수수료 리베이트는 잘 작동합니다. 사용자가 결국 충분한 돈을 받는다면 채널이 열릴 때까지 기다리지 않고도 즉시 자금을 받을 수 있습니다. L1 UTXO를 형성할 만큼 충분한 자금이 확보되면 이 UTXO를 생성하기 위한 수수료 리베이트 팟을 지불받을 수 있습니다. 이 기술은 ecash(미결 자금을 표시하기 위해 민트 금액을 사용)와 같은 시스템 또는 Taproot Assets(Pocket Universe에 표시된 자산의 UTXO를 사용하여 L1의 수수료를 상쇄함)을 사용하는 신용 채널과 결합될 수 있습니다.
이 시점에서 논의는 채널 팩토리와 유사한 다양한 오프체인 구성과 특정 온 온체인 수수료, 사용자 수 및 해당 사용자 간의 잔액 분배라는 맥락에서 그 제한 사항으로 돌아갑니다. 기본적으로 타임아웃 트리를 기반으로 이와 같은 구성을 상상한다면, 각각 1개의 사토시만 가지고 있는 1억 명의 사용자가 있다면 전체 트리를 펼치는 것은 비용 효율적이지 않을 것입니다 . ( 온체인 가 1사토시를 초과했기 때문에) 사용자가 자금을 다른 장소로 이동할 수 있는 내장 메커니즘이 있어 코디네이터가 모든 자금을 한 번에 가져갈 수 있다고 상상한다면(Ark의 모델과 유사), 사용자가 제 시간에 종료하지 못하면, 1 BTC는 코디네이터에 의해 압수됩니다. 온체인 자금을 되찾으려는 모든 사용자는 모든 자금을 소각하는 것과 같기 때문에 일부 참석자들은 기존 잔액 모두 소각하는 데 사용할 수 있는 "큰 빨간색 버튼"을 상상했습니다. 이상적으로 이러한 화상에는 코디네이터가 사기를 저지를 수 없도록 증거를 확인할 수 있는 일종의 스크립트(또는 클라이언트)가 필요합니다.
위의 시나리오는 다소 단순한 사고 실험이지만, 온체인 수수료 및 소규모 UTXO와 관련하여 우리가 가지고 있는 몇 가지 근본적인 한계를 조롱하고 있다고 생각합니다. 여기에는 새로운 것이 없습니다. 이 메커니즘은 대부분의 풀 노드가 기본적으로 더스트 출력 개념을 사용하는 이유입니다. 처리 수수료를 지불하기 위해 UTXO 가치의 1/3을 사용하는 것은 비용 효율적이지 않습니다. ) . 오프체인 시스템에서도 마찬가지입니다. 오직 일종의 보조금이나 외생적 가치 시스템만이 구조의 역할을 할 수 있습니다. 메인 체인(또는 더 높은 수준)에서 비경제적인 모든 전송은 필연적으로 BTC를 계정 단위로 사용하지만 더 저렴한 수수료를 위해 보안을 희생하는 다른 시스템으로 마이그레이션됩니다.
볼트 12: 다음은 무엇입니까?
짙은 안개가 공기를 가득 채우고, 맛있는 음식에 둘러싸여 시원한 음료와 스키야키를 즐길 수 있으며, BOLT12의 PR이 라이트닝 네트워크 사양 창고에 통합됩니다! 이날 오전 마지막 세션에서 우리는 BOTL 12의 다음 단계, 즉 원본 버전에서 잘라낸 플러그인과 우리가 원하는 것이 무엇인지에 대해 논의했습니다.
잠재적인 BOLT12 플러그인
논의할 첫 번째 플러그인은 송장 교체입니다. 사용자가 제안을 사용하여 송장을 받았지만 너무 오래 전에 지불하여 모든 블라인드 경로 및/또는 송장 자체가 만료되는 시나리오를 생각해 보십시오. 이 시나리오에서는 사용자가 교체 송장을 요청할 수 있으면 유용합니다. 다른 새 송장을 요청하기 위해 Offer를 직접 사용하는 것과 어떻게 다른지는 상황에 따라 달라질 수 있습니다.
일부 구현자가 가장 복귀하고 싶은 영역은 반복 결제입니다. 반복 지불의 일부는 원래 사양에 포함되었지만 일부는 결국 제거되었습니다. 정기 결제와 관련된 매개변수에는 시간 간격, 결제 창, 한도, 시작 및 종료 시간이 포함됩니다. 수신자가 사용할 수 있는 약간의 트릭은 해시 체인을 활용하여 저장해야 하는 사전 이미지의 수를 최소화하는 것입니다. (초기 조정 중에) 발신자에게 특별한 소금/시드를 전달할 수 있는 경우 발신자와 수신자만이 이러한 사전 이미지가 정확히 하나의 해시 체인을 구성한다는 것을 알 수 있습니다.
인증에 관해서는 BIP 353의 역버전이 제안되었다. 기본 아이디어는 사용자가 노드의 공개 키를 도메인 이름에 바인딩할 수 있도록 하는 것입니다. 이는 노드 Y가 특정 서비스/도메인 이름/회사와 연관되어 있음을 식별하는 데 사용될 수 있습니다.
양파 메시지 속도 제한 및 배압 전송
세션이 끝나면 관심은 Onion 메시징과 여러 주요 구현의 현재 구현/동작 상태로 옮겨졌습니다. 한 가지 주제는 지갑이 제안을 얻을 수 없을 때 지갑이 폴백을 처리하는 방법과 관련 사용자 경험에 미치는 영향입니다. Onion Messaging은 피드백 메커니즘이 내장되어 있지 않은 신뢰할 수 없는 최선의 네트워크이므로 메시지가 전달되지 않을 수도 있습니다. 따라서 지갑은 다른 경로를 시도하고 메시지를 다시 보내거나 지갑 요청이 실패할 경우 대체할 수 있는 다른 메커니즘을 준비해야 합니다.
일반적으로 현재 상황은 단일 홉 양파 메시지 라우팅 또는 직접 연결을 사용하는 것입니다. "직접 연결"은 P2P에서 수신자, 경로를 막는 진입 노드 또는 더 짧은 경로를 사용하여 메시지를 보내려고 진입 노드에 연결하는 노드에 직접 연결하는 것을 의미합니다. 이러한 시도도 실패하는 경우(수신 중인 노드가 없거나 수신자가 온라인이 아닌 경우 등) 노드에는 다른 대체 솔루션이 필요하거나 어떤 형태로든 자발적인 지불을 보내려고 시도합니다.
메시징으로 돌아가서 일종의 속도 제한이 필요하다는 것은 분명합니다. 처음에는 노드에 무료 예산이 있을 수 있지만 메시지 전달은 제한되어야 합니다. 그렇지 않으면 노드가 자신도 모르게 10GB의 어니언 메시지 트래픽을 무료로 전달할 수 있습니다(제 생각에는 무료 계층 이후에는 대부분의 노드가 결국 전환해야 할 것입니다). 대역폭을 측정하는 결제 시스템에 적용[ 22 ]). 따라서 노드는 일종의 대역폭과 속도 제한을 적용해야 합니다. 일반적인 메시징 사용량에 비해 네트워크가 과도하게 프로비저닝된 경우 사용량이 아직 구성된 대역폭 제한에 도달하지 않았기 때문에 서비스가 상대적으로 높게 유지됩니다. 그러나 네트워크가 메시징 활동(게임 세션 등을 라이브 스트리밍하려는 사람들)과 연결되어 있으면 공유지의 비극으로 인해 대부분의 메시지 전송 시도가 실패하기 때문에 서비스가 방해를 받게 됩니다. 더욱이, 메시지가 삭제되거나 전달되지 않거나 수신자가 오프라인인 경우의 차이를 구별할 수 없으므로 사용자 경험에 더 큰 어려움을 초래합니다.
토론은 결국 메일링 리스트[ 23 ]에서 이전에 제안된 이전 배압 속도 제한 알고리즘으로 바뀌었습니다. 이 알고리즘을 사용하는 동안 노드는 마지막으로 메시지를 보낸 피어에 대한 비교적 간단한 설명을 유지할 수 있습니다. 피어가 제한을 초과하면 노드는 트래픽 발신자에게 onion_message_drop 메시지를 보냅니다. 그런 다음 발신자는 메시지를 보낸 사람을 추적하려고 시도하고 onion_message_drop 메시지를 더 뒤로 전파하여 프로세스의 속도 제한을 반감. 발신자가 30초 간격 내에 속도 제한을 초과하지 않으면 수신자는 일반 속도 제한에 도달할 때까지 속도 제한을 두 배로 늘려야 합니다.
여기에는 다음과 같은 몇 가지 공개 질문이 아직 남아 있습니다. 노드가 어떻게 플러딩 메시지를 특정 피어에 올바르게 귀속시킬 수 있습니까? 노드가 다른 노드를 트랩하여 메시징 활동을 차단할 수 있습니까? 플러딩된 메시지의 소스를 올바르게 확인하려면 추가 메타데이터가 필요합니까? 이 솔루션은 이러한 속도 제한을 알고 있지만 여전히 제한 내에서 대역폭을 최대한 남용하려고 시도하는 공격자에 대해 저항력이 있습니까? 이 계획이 처음 등장했을 때, 계획의 효율성과 저항성을 측정하기 위해 몇 가지 기본 시뮬레이션이 실행되었습니다[ 24 ]. 예비 결과는 고무적이며 몇 가지 추가 연구 질문을 생성합니다[ 25 ].
결국 일부 참석자들은 배압 알고리즘에 대한 작업/연구를 재개하고 단기적으로 보수적인 속도 제한 매개변수를 적용하는 데 동의했습니다.
