알렉스 마이어스 지음
출처: https://btctranscripts.com/bitcoinplusplus/2022/2022-06-07-alex-myers-minisketch-lightning-gossip
이 글은 저자가 Bitcoin++ 2022 컨퍼런스에서 한 연설을 Michael Folkson이 필사한 것입니다. 연설 슬라이드는 여기에서 확인하실 수 있습니다: https://endothermic.dev/presentations/magical-minisketch
미니스케치 저장소: https://github.com/sipa/minisketch
Rusty Russell이 Lightning Network 소문을 위해 Minisketch를 사용하는 것에 대해 이야기했습니다: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001741.html
Bitcoin Core PR Review Club에서 Minisketch에 대한 세 가지 토론:
소개
저는 Lightning 개발에 완전 초보이고, 얼마 전 Core Lightning 팀에 합류했습니다. Minisketch에 대해 이야기하고, 가십 네트워크에서 배운 내용을 공유해 드리겠습니다.
주제
라이트닝 네트워크에서 가십 프로토콜의 역할에 대해 먼저 이야기해 보겠습니다. 여러분 모두 라이트닝 네트워크에 대해 잘 알고 계시거나, 적어도 어느 정도 알고 계시겠죠? 라이트닝 네트워크의 작동 방식에 대한 배경 설명은 길게 하지 않겠습니다. 대신, 가십이 라이트닝 네트워크 운영에 어떻게 밀접하게 연관되어 있는지 설명하겠습니다. 그런 다음, 미니스케치의 작동 방식을 간략하게 살펴보고, 사례 연구를 살펴본 후, 미니스케치를 활용하여 라이트닝 네트워크에서 가십을 최적화하는 방법을 보여드리겠습니다.
가십의 역할
라이트닝 네트워크에서 가십의 역할을 예를 들어 설명하는 것이 흥미로울 것 같아서 간단한 라이트닝 네트워크 거래부터 시작해 보겠습니다.
라이트닝 결제 보내기
일반 사용자의 관점에서 보면, 소위 "라이트닝 결제"는 휴대폰에서 지갑 앱을 먼저 열고 QR 코드나 스캔 가능한 텍스트(송장)에 카메라를 비추는 방식일 수 있습니다. 그러면 앱에서 거래 내역과 비고를 표시하고, 금액이 대략 맞는지 확인한 후 "보내기"를 클릭합니다. 운이 나쁘지만 않다면, 잠시 후 휴대폰 화면에 녹색 체크 표시가 나타나 결제가 성공적으로 전송되었음을 나타냅니다.
하지만 그 자리에 있던 사람들은 모두 열광적인 사람들이었기 때문에 좀 더 깊이 파고들어 볼 수 있을 것 같았습니다. 휴대전화 화면 뒤에서 실제로 무슨 일이 일어나고 있는 걸까요?
라이트닝 결제 - 고급
Core Lightning Client에는 더 많은 정보를 얻는 데 사용할 수 있는 다양한 명령줄 명령이 있습니다.
lightning-cli listpays <BOLT 11>이 명령을 입력하면 실제로 어떤 일이 일어나는지 확인할 수 있습니다. 결제가 완료되면 라이트닝 네트워크에서 결제할 때 받는 영수증과 비슷한 프리이미지가 나타납니다. 흥미롭게도, 이 결제는 12개의 작은 부분으로 나뉜다는 것을 알 수 있습니다. 이 12개의 결제 경로는 모두 결제를 완료하기 위해 계산됩니다.
lightning-cli listpaystatus <BOLT 11> 좀 더 자세히 살펴보겠습니다. 클라이언트가 12개의 경로만 시도한 것이 아니라 실제로 53개의 경로를 시도했음을 알 수 있습니다. 이를 "다중 경로 결제"라고 합니다. 일부 경로는 시간 초과로 실패했습니다. 결제가 성공하기 전에 실패 정보를 받았습니다. 이 CLI 명령은 이 데이터를 출력합니다. 하지만 실제로는 실패한 각 시도에서 수행된 홉(전달) 수를 알 수 있으며, 텍스트 인코딩된 문자열( 0x1007... )을 얻습니다. 이 문자열을 다른 도구(devtools/decodemsg)에 전달하면 디코딩할 수 있습니다. 이는 BOLT4의 일부이며, 사양에 따르면 1007 temporary_channel_failure 의미합니다.
"채널 업데이트 실패"( 0x1000 새 채널 업데이트 포함)도 있는데, 이는 이 노드에서 발표한 결제 전달 요구 사항 변경 사항을 놓쳤다는 것을 의미합니다. 모든 메시지가 어니언 라우팅되기 때문에 이 중간 노드는 우리가 누구인지, 결제가 어디로 갈지 전혀 모릅니다. 그래서 "당신이 누구든 간에, 잘못된 사람에게 말하고 있는 것 같습니다. 당신이 가진 정보 중 일부가 오래되었고, 이 부분을 확인해 보세요."라는 메시지가 표시됩니다. 이 경우, 이 채널에서 부과할 수수료, cltv_expiry_delta 값, 그리고 타임아웃에 추가할 블록 수에 대한 정보를 얻을 수 있습니다. 중요한 것은 channel_flags=1 입니다. 그다지 인상적이지 않지만 프로토콜 사양을 살펴보면 채널이 비활성화되었음을 나타냅니다. 전달 경로를 계산할 때 이 정보가 없었던 것은 분명합니다. 바로 이 때문에 이 경로가 작동하지 않는 것입니다.
라이트닝 결제 - 요약
이 기본 사례에서 무엇을 배웠을까요? 이 간단한 사례에서도 결제를 위해 70개의 서로 다른 채널을 사용했습니다. 일부 채널에 대한 정보는 최신 상태가 아니었지만, 새로운 가십 메시지를 검색하고 네트워크 지형 지도와 같은 라우팅 그래프를 업데이트할 수 있었습니다. 새로운 정보를 활용하여 경로를 다시 계산하고 결제를 성공적으로 진행할 수 있었습니다.
가십의 역할
처음에 물었던 질문으로 돌아가 보겠습니다. 라이트닝 네트워크에서 가십은 일반적으로 어떤 역할을 할까요? 삶의 가십과 마찬가지입니다. 가십은 직접 소통하지 않는 피어에 대한 간접적인 정보입니다. 라이트닝 네트워크에서는 다양한 노드가 서로 연결되어 있습니다. 여러 노드에 직접 연결되어 있을 수도 있지만, 예를 들어 왼쪽 하단에 있는 경우, 이 영역에 없는 다른 노드에 대한 정보를 수집해야 합니다. 이 작업은 node_announcement 라는 가십 메시지를 통해 수행됩니다.
이는 node_announcement 라는 가십 메시지를 통해 이루어집니다. node_announcement 메시지는 노드의 공개 키와 노드에 도달할 수 있는 네트워크 주소(직접 연결하려는 경우)를 제공합니다. 예를 들어 IP 주소, 어니언 주소, 웹 소켓 등 무엇이든 가능합니다.
다음으로 알아야 할 것은 채널의 위치입니다. channel_announcement 메시지가 있습니다. 이 메시지는 노드 A와 노드 B 사이에 채널이 존재하며, 온체인 해당 채널에 자금을 조달한 트랜잭션이 있음을 나타냅니다. "짧은 채널 ID"가 나열되어 있는데, 이 정보는 채널을 검색하고 온체인 어떤 UTXO가 자금을 조달하는지 확인하는 데 필요합니다. 이 정보는 개인 정보 보호에는 좋지 않지만, 서비스 거부 공격(DoS)을 방지하는 데 유용합니다. 메시지를 보내는 사람은 채널을 연 UTXO가 있음을 증명해야 하기 때문입니다.
이제 네트워크의 기본 토폴로지를 알았으니 경로를 파악할 수 있습니다. 하지만 더 많은 정보가 있으면 좋겠습니다. 그래서 channel_update 메시지를 준비했습니다. 이 메시지에는 위 예에서 보았듯이 처리 수수료, 채널이 전달할 수 있는 최대 HTLC 수, 비활성화 여부 등의 정보가 포함되어 있습니다. 이러한 정보는 모두 경로 계산 시 부적합한 경로를 제거하는 데 도움이 됩니다.
이제 경로를 구성하는 데 필요한 모든 정보를 얻었습니다. 그런데 제 발표 제목이 "라이트닝 가십 네트워크"인 이유는 무엇일까요? 방금 라이트닝 네트워크에 대해 이야기했던 것 아닌가요? 간단히 말해서, 두 개념이 완전히 동일하지는 않습니다. 차이점은 우리가 보는 노드 간의 연결이 라이트닝 네트워크에서는 (결제) 채널이라는 것입니다. 하지만 가십에 참여할 때는 노드의 하위 집합과만 통신합니다. 정확한 개수는 구현 방식에 따라 다릅니다. 제가 기억하기로 코어 라이트닝은 5개의 피어 노드를 사용하고, 연결된 노드 중 3~5개와 가십을 주고받습니다. 가십 객체는 피어 노드일 필요는 없습니다. 어떤 노드와도 가십을 주고받을 수 있습니다. 프로토콜을 이해하고 아직 모르는 정보를 제공할 수 있다면 노드일 필요도 없습니다. 네트워크 상태에 대한 새로운 정보를 수집할 수 있다면, 양방향 통신은 환영받습니다. 가장 중요한 세부 사항은 가십 프로토콜이 플러드 전파 모드로 작동한다는 것입니다. 예를 들어, 5명의 가십 피어에 연결되어 있다면, 그중 한 피어로부터 메시지를 수신하는 즉시 다른 4명의 피어에게 브로드캐스트합니다. 이는 모든 파트너에게 정보를 빠르게 전달할 수 있기 때문에 정보 전달 초기 단계에서 매우 효율적입니다. 하지만 정보가 몇 홉을 거치고 나면 효율성이 떨어지기 시작합니다. 여러 피어에서 동일한 데이터를 수신하게 되는데, 이는 효율성 저하의 징후입니다.
가십 통계
다음은 Lightning Network 상태에 대한 몇 가지 기본 통계입니다. 현재 전체 Lightning Network에는 80,000개의 채널과 17,000개의 퍼블릭 노드가 있습니다. 위의 플러드 전파 모델로 돌아가서, 최소 그룹 크기(상호 연결된 세 개의 가십 피어)에 있는 경우 메시지가 네트워크 전체로 전파되려면 최소 14개의 홉이 필요합니다. 가십 전파에는 고유한 한계가 있습니다. 실제로는 수신하는 모든 가십 메시지를 일괄 처리한 후 60초에서 90초 동안 기다립니다. Core Lightning은 60초를 사용하지만, LND는 90초 루프를 사용하는 것으로 보입니다. 수신하는 모든 새 가십 메시지를 모든 가십 피어에게 주기적으로 브로드캐스트합니다. 각 홉 사이에 60초에서 90초의 간격을 둔 14개의 홉은 긴 시간입니다. 실제로 네트워크 노드의 95%가 13분 이내에 새 메시지를 수신하는 것을 확인했습니다. 모든 사람이 새로운 정보를 볼 수 있을 때까지 20분 정도 기다려야 할 수도 있습니다. 적어도 이는 유용한 경험 법칙입니다.
"미니스케치"란 무엇인가요?
이제 방향을 바꿔 "미니스케치"를 소개하겠습니다. 최선을 다하겠습니다.
Minisketch는 집합 조정 프로토콜입니다. "집합 조정"이란 무엇일까요? 두 데이터 집합이 있는데, 이 벤 다이어그램에서 두 집합이 크게 겹치는 것을 볼 수 있습니다. 이 경우 두 데이터 모두 유효하며, 두 집합 모두 업데이트되도록 새 데이터의 일부를 모두 가져오도록 해야 합니다. 이때 두 집합 간의 "대칭 차이"가 중요합니다. 바로 이 부분에서 Minisketch가 도움을 줍니다. 몇 달 전 저와 같은 경험을 하셨다면, 이 문제를 해결하는 것이 매우 어렵고 두 집합을 조정하는 것이 결코 쉬운 일이 아니라고 생각하실 수도 있습니다. 상대방이 무엇을 놓치고 있는지 모르기 때문에 필요 이상으로 많은 정보를 보낼 수도 있습니다. 하지만 저처럼, 그런 생각은 틀릴 수도 있습니다. Minisketch에는 정말 멋진 기능들이 있습니다.
배경
미니스케치는 실제로 "BCH 오류 정정 코드"라고 불리는 오류 정정 코드 계열에 속합니다. 버클리캠프-매시 알고리즘처럼 맵을 사용합니다. 아주 간단하고 추상적인 예를 하나 들어보겠습니다.
BCH 예시
각각 (1, 2, 3) 과 (1, 2, 3, 4) 의 요소를 포함하는 두 개의 데이터 집합이 있다고 가정해 보겠습니다.
두 집합을 일치시키고 싶다면, 둘 다 모든 데이터를 가지고 있는지 확인하는 것이 좋은 방법입니다. 각 집합의 모든 원소의 합을 계산하는데, 하나는 6이고 다른 하나는 10입니다. 만약 우리가 왼쪽 집합에 있고 오른쪽 집합과 동기화하고 싶다면, "내 집합의 원소의 합은 6입니다. 두 집합의 차이인 10 - 6 = 4 구하면, 이것이 내가 놓친 원소입니다."라고 말합니다. 정말 좋은 방법이고, 기본적으로 그냥 빼는 것과 같습니다. 하지만 이 방법은 차이가 원소 하나일 때만 작동합니다. 원소가 두 개 이상이면 작동하지 않습니다. 하지만 또 다른 방법이 있습니다.
두 가지 차이점을 인코딩하고 싶다고 가정해 보겠습니다. 배열에 있는 모든 요소의 단순 합을 넣으면 됩니다. 이것이 바로 우리의 배열입니다. 배열의 첫 번째 요소는 집합에 있는 모든 요소의 단순 합이고, 두 번째 요소는 집합에 있는 모든 요소의 제곱의 합입니다. 이는 모두 기본적인 수학입니다. 이 배열을 다른 사람들에게 전달하려고 합니다. 이제 이전보다 두 배나 많은 두 차이점을 조정해야 합니다. 이 두 차이점을 합치면 됩니다. "첫 번째 차이점은 요소들의 단순 합의 차이고, 두 번째 차이점은 요소들의 제곱의 합의 차입니다." 대수를 다시 생각해 보세요. 여기에는 두 개의 방정식이 있고, 두 개의 미지수가 있습니다. 즉, 우리는 그것들을 풀 수 있다는 뜻입니다!
차이의 개수가 증가하고 순서가 증가할수록 문제는 점점 더 어려워집니다. 바로 이 부분에서 Berlekamp-Massey 알고리즘이 등장하는데, 이는 매우 효율적인 해결책입니다.
큰 스케치 구성하기
어떤 크기의 집합에도 이 작업을 수행할 수 있습니다. 차수 n까지 상승 수 있습니다. 당연히 차수가 클수록 문제를 푸는 데 시간이 더 오래 걸립니다. 차수 n에 상승 때까지 모든 항목을 인코딩해야 합니다. 하지만 이 방법은 효과가 있으며, 관련된 요소의 수에 관계없이 두 집합의 차이를 구할 수 있습니다.
미니스케치
미니스케치 저장소: https://github.com/sipa/minisketch
Pieter Wuille이 개발한 C++ 라이브러리입니다. PinSketch 알고리즘을 구현하며, 다양한 아키텍처와 하드웨어에서 작동합니다. 테이블을 사용하여 근 찾기 프로세스를 최적화하고 시간을 절약합니다. Pieter는 순수 Python 구현도 개발했는데, 그 자체로 놀랍습니다. 500줄의 코드만으로도 저를 놀라게 할 만한 온갖 계산을 실행할 수 있습니다. 코드 또한 매우 읽기 쉽습니다. GitHub 페이지를 직접 확인해 보시기를 추천합니다.
미니스케치 사용하기
하지만 저처럼 엔지니어라고 가정해 봅시다. 이 재밌는 수학을 실제로 어떻게 활용할 수 있을까요? 이렇게요.
먼저 스케치를 초기화합니다. 이를 위해 인코딩하려는 데이터의 폭을 알아야 합니다. 여기서는 64비트를 사용합니다. 먼저 데이터 폭을 입력하고, 그다음 용량을 입력합니다. 용량은 두 집합 간에 조정하려는 차이 요소의 수입니다. 두 집합의 차이가 5개라고 생각되면 8을 선택하여 약간 초과하도록 할 수 있습니다. 하지만 너무 초과해서는 안 됩니다. 그런 다음 집합 데이터를 입력하고 합성 값을 계산합니다. 이 과정은 "큰 스케치 구성" 섹션에서 설명한 것과 정확히 같습니다. 그런 다음 결과를 직렬화하여 앨리스에서 밥으로 전송합니다.
밥도 똑같은 과정을 거칩니다. 스케치를 만든 다음 두 스케치를 병합합니다. 정말 흥미로운 점은 너비는 같아야 하지만, 용량은 다를 수 있다는 것입니다. 수학적으로 배열을 잘라내어 두 스케치의 크기가 같도록 한 다음 두 스케치를 병합할 수 있습니다. 용량은 약간 더 작지만(서로 다른 요소의 개수와 같지는 않지만), 여전히 꽤 잘 작동합니다. 그런 다음 Berlekamp-Massey 알고리즘을 사용하면 두 집합의 차이가 결과로 나옵니다.
블랙박스 특성
이 수학 함수는 어떤 속성을 가질까요? 2비트부터 64비트까지의 데이터를 지원합니다. 정말 멋진 점은 직렬화 후 스케치 크기, 즉 노드 간에 전송해야 하는 데이터의 크기가 스케치 용량(즉, 해결하려는 차이 요소의 개수)에 데이터 너비를 곱한 값이라는 것입니다. 스케치 용량을 적절하게 선택하면 데이터에서 100%의 효율성을 얻을 수 있습니다(전송된 요소의 개수는 추출하는 누락된 요소의 개수와 정확히 일치합니다).
草图序列化体积= 草图容量* 数据宽度정말 놀라웠어요. 하지만 알아두어야 할 몇 가지가 더 있습니다. 스케치 크기가 커질수록 조정 시간은 (선형적으로) 상승. 실제로 얼마나 많은 요소를 다르게 하고 싶은지에 따라 조정 시간은 이차적으로 상승. 그래서 우리는 모두 서로 다른 요소의 개수를 제한하고 싶어 합니다. 집합의 차이가 너무 커서 당황하고 싶지 않을 테니까요.
한정
몇 가지 기본 사항을 기억해야 합니다. 스케치를 초기화할 때 0개의 요소를 인코딩할 수 없습니다. 다른 숫자는 괜찮지만, 0이 아니어야 합니다. 또 다른 점은 각 스케치의 요소 수, 즉 두 컬렉션의 차이가 너무 크지 않도록 하는 것입니다(스케치의 용량을 초과하지 않도록). 일반적으로 이는 문제가 되지 않지만, 한 스케치에는 50개의 요소가 있고 다른 스케치에는 100개의 요소가 있는데 스케치 용량이 10개뿐이라고 가정해 보겠습니다. 용량이 부족해서 문제를 해결할 수 없습니다. 다행히도 문제를 해결할 수 없는 경우 경고 메시지가 표시되고 "이 방정식을 만족하는 다항식을 찾을 수 없습니다."라는 메시지가 표시됩니다. 대부분의 경우 이 방법은 작동합니다.
얼레이
이 기술을 미래에 어떻게 활용할 수 있을지에 대한 배경 정보를 알려드리겠습니다. 비트코인 네트워크는 라이트닝 가십 네트워크와 매우 유사한 문제에 직면해 있습니다. 바로 거래 플러딩이 확장성이 떨어진다는 것입니다. Erlay 프로토콜에 대해 들어보셨다면 Minisketch가 바로 이러한 목적으로 개발되었다는 것을 알고 계실 것입니다. Erlay는 Minisketch를 사용하여 거래 풀의 모든 거래를 인코딩합니다. 이렇게 인코딩된 스케치는 비트코인 네트워크의 다른 사용자들과 공유할 수 있습니다. 거래 ID는 32바이트이지만, Minisketch에는 8바이트의 데이터만 있습니다. 따라서 발견된 차이가 어떤 거래를 나타내는지 확인하기 위해 거래 ID를 더 작은 지문으로 압축해야 합니다. 이를 위한 해시 함수가 있습니다.
노드는 인벤토리 세트도 조정합니다. 이는 상황을 조금 더 복잡하게 만드는 또 다른 요소입니다. 전체 거래 풀이 있다고 가정해 보겠습니다. 이를 위한 한 가지 방법은 모든 거래를 스케치에 인코딩하는 것입니다. 모든 피어가 이 작업을 수행한 후, 서로의 거래 풀에 차이가 있는지 확인해야 합니다. 하지만 이는 Erlay의 작동 방식과 일치하지 않습니다. Erlay는 노드가 통신하는 모든 피어를 추적하고 "마지막으로 통신한 지 15초가 지났는데, 아직 말씀드리지 못한 내용의 목록을 만들었습니다. 알려드릴 다섯 가지 내용은 다음과 같습니다."라고 말합니다. 동시에, 당신의 피어인 Bob도 똑같은 작업을 수행하지만, 수집한 내용은 일곱 가지일 수 있습니다. Erlay는 거래 풀에 있는 거래(수천 개의 거래일 수 있음)의 인코딩을 요청하지 않고, 이 다섯 가지 거래와 일곱 가지 거래의 인코딩만 요청합니다. 두 거래를 조정하면 세 가지 차이점만 발견될 수 있습니다. 조정이 완료되면 이러한 인벤토리 세트가 지워지고 두 피어는 다음 라운드로 넘어갑니다. 다음 15초 동안 발생한 새로운 사항을 기록합니다.
라이트닝 네트워크 가십 vs. 비트코인 거래 전달
비트코인 네트워크가 거래 전달에서 직면하는 문제는 라이트닝 네트워크 가십의 문제와 매우 유사하지만 몇 가지 차이점도 있습니다. 첫째, 짧은 해시 함수를 사용하여 64비트 지문을 생성하려고 할 때마다 충돌에 대해 걱정해야 합니다. 누군가 이를 악용하여 동일한 지문을 생성하는 거래 ID(해시 값)를 계속해서 찾으려고 시도할 수 있습니다. 이는 서비스 거부 공격 인터페이스가 됩니다. 이는 실제로 우려스럽습니다. 또한 개인 거래에 대한 타이밍 분석이 있습니다. 가십에서는 모든 정보가 자연스럽게 공개되므로 아무것도 숨길 필요가 없습니다. 또한 해시 함수를 사용하지 않도록 하는 작은 트릭이 있습니다. 데이터 유형이 하나만 있는 것이 아니라 전달하려는 메시지 유형이 3가지입니다.
가십에 적용
이러한 메시지에는 channel_update , node_announcement , 그리고 channel_announcement 의 세 가지 유형이 있습니다. channel_announcement 거래 수수료, 채널 사용 상태(활성화 또는 비활성화), 지원되는 최대 HTLC 용량 등에 대한 정보가 포함됩니다. 이는 가십 네트워크 트래픽의 97%를 차지할 것으로 예상되는데, 이는 상당한 양의 트래픽이므로 효율성을 높이고자 합니다. 처음 두 메시지( channel_update , node_announcement )는 2주 동안만 유효하므로 반복적으로 브로드캐스트됩니다.
도전
우리의 과제는 세 가지 메시지 유형을 모두 인코딩해야 한다는 것입니다. 8바이트만 사용할 수 있지만, "Short Channel ID(SCID)"라는 도구를 사용합니다. 이는 온체인 자금 조달 거래와 채널을 연결하는 정보입니다. 온체인 모든 거래는 고유합니다. 이는 우리가 사용할 수 있는 매우 유용한 단축 방법입니다. node_announcement 에는 이 노드와 연결된 채널이 없으므로 짧은 채널 ID를 사용하기 어렵습니다. 이상적으로는 노드의 공개 키인 노드 ID를 참조해야 합니다. 하지만 공개 키도 32바이트이므로 해싱하거나 다른 작업을 해야 합니다.
코딩 체계
실제로 이 정보를 인코딩할 때 블록 높이, 거래 인덱스, 짧은 채널 ID인 출력 인덱스와 같은 데이터를 사용할 수 있습니다. "이 노드의 가장 오래된 채널"과 해당 노드가 채널의 어느 쪽에 있는지와 같은 노드 알림 메시지를 참조할 수 있습니다. 이렇게 하면 어떤 노드에 대해 이야기하고 있는지 일관되게 파악할 수 있습니다. 이는 일반적으로 8바이트의 데이터이며, 우리는 이를 8바이트에 맞추려고 합니다. 이는 불필요한 몇 비트를 줄이는 것뿐입니다. 블록에 32,000개의 거래만 포함되어 있다면 이 정도면 충분할 수 있습니다. 라이트닝 채널에 자금을 지원하는 경우, 자금 지원 거래에 1,000개의 출력이 있을 가능성은 낮습니다. 메시지 유형 및 해당 노드가 채널의 어느 쪽에 있는지와 같은 다른 정보를 위한 공간이 있도록 몇 바이트를 절약했습니다. 이를 통해 정확히 64비트로 어떤 가십 메시지를 브로드캐스팅하고 있는지 확인할 수 있습니다. 마지막으로 타임스탬프가 있습니다. 정기적으로 전송되는 메시지의 경우, 어떤 메시지가 최신이고 어떤 메시지가 오래된지 알아야 합니다. 메시지를 구분하는 데 도움이 되는 몇 가지 정보가 있으면 도움이 됩니다.
집단 중재의 이점
이게 왜 그렇게 매력적인 걸까요? 간단히 말해서, 가십 대역폭을 최소 60% 절약할 수 있다는 겁니다. 이렇게 하면 더 많은 피어와 통신할 수 있죠. 더 많은 피어와 통신하는 건 가십의 신뢰성을 높여주기 때문에 아주 좋은 일입니다. 특히, 피어 알림 메시지는 과거에는 문제가 많았는데, 다른 두 메시지의 경우 놓쳤는지 알 수 있는 간단한 휴리스틱이 있기 때문입니다. 채널 업데이트 메시지의 경우, 앞서 예시에서 보았듯이 최악의 경우 결제 경로가 실패하고 오류 패킷이 업데이트를 가져와서 피드백을 받을 수 있습니다. 하지만 피어 알림 메시지는 어떨까요? 노드의 IP 주소를 알려줍니다. 노드의 IP 주소가 변경되었는데 보이지 않는다면 더 이상 연결할 수 없을 수도 있습니다. 이는 매우 안 좋은 상황이고, 향상된 신뢰성에서 실질적인 이점을 얻을 수 있을 것으로 기대됩니다.
다음은 무엇인가요?
몇 가지 궁금한 점이 있습니다. 그중 하나는 글로벌 스케치를 유지하거나 각 피어에 대한 인벤토리를 설정할 수 있다는 것입니다. 두 가지 접근 방식 모두에 대한 주장이 있습니다.
또 다른 점은 수신되는 가십 메시지에 속도 제한이 있다는 것입니다. 가십 메시지의 속도 제한을 매우 엄격하게 적용하면 스케치 용량이 크게 줄어들 수 있습니다. 이 집단 중재 기능을 사용하는 구현의 경우, 사람들이 속도 제한을 적용할 시간 단위에 대해 합의할 수 있다면 좋을 것 같습니다. 저는 블록 높이를 사용하는 쪽으로 기울고 있습니다. 사람들을 설득하려고 합니다. 모든 가십 메시지를 현재 블록 높이와 연결할 수 있다면 어떨까요? 예를 들어 블록당 가십 메시지 하나, 또는 100블록마다 하나씩 등입니다. 이미 전체 노드를 실행하고 있으므로 이를 확인하는 것은 매우 쉽습니다.
마지막으로, 장기적으로는 가십(gossip)에서 짧은 채널 ID를 없애고 싶습니다. 짧은 채널 ID는 개인정보 유출의 원인이 되기 때문입니다. 미사용 거래 내역을 모두 공개하고 싶지는 않을 것입니다. 아직은 준비가 완전히 된 것은 아니지만, 일단 준비가 되면 다양한 피어 노드에 대응하는 인벤토리 수집 체계를 구축할 것입니다. 이는 지금 우리가 어떤 선택을 해야 할지 보여주는 좋은 예가 될 수 있습니다.
결론적으로
가십을 사용하면 전체 라이트닝 네트워크를 한눈에 보고 경로를 파악할 수 있습니다. 미니스케치(Minisketch)는 정말 멋지니 모두 한번 사용해 보세요. 라이트닝 네트워크 가십의 안정성을 높이는 데 미니스케치가 활용되기를 바랍니다.
(위에)
