이 글은 비트코인 분야의 자가 교육을 받은 교육자이자 기술 중심의 비트코인 팟캐스트 호스트인 신오비의 의견 기고입니다.
BOLT 12는 Blockstream의 러스티 러셀(Rusty Russel)이 제안한 것으로, Lightning을 통한 결제 방식을 최적화하고 궁극적으로 BOLT 11의 후계자가 되는 것을 목표로 합니다. BOLT를 구성하는 다양한 기능들이 있지만, 이 글에서는 그 중 하나의 거래 비용과 문제에 주로 초점을 맞추겠습니다. 먼저, BOLT 제안의 주요 기능 몇 가지를 간단히 요약하겠습니다:
BOLT: (Basis of Lightning Technology; 비트코인 개선 제안서 [BIP] 사양의 Lightning 버전)
* 블라인드 경로: 결제 송장과 양파 메시지 모두에 사용됩니다. 이는 결제 또는 양파 메시지 회로의 마지막 몇 개 홉을 미리 정의하고 암호화하여 발신자가 무엇을 보내고 있는지 알 수 없도록 하면서도 의도한 수신자에게 도착할 수 있게 합니다.
* 슈노르 서명: 이는 Lightning 결제를 조정하거나 노드와의 통신에서 서명이 사용되는 모든 다양한 장소에서 슈노르 멀티시그를 활용할 수 있도록 합니다.
* 지불자 증명: 노드는 이제 송장을 요청할 때 특별한 키를 생성하여 서명을 통해 결제를 했음을 증명할 수 있습니다. 이는 환불 시 실제 지불자만이 이를 청구할 수 있도록 보장합니다.
* 송장 머클 트리: 송장은 이제 각 개별 필드에 커밋된 머클 트리로 인코딩됩니다. 이렇게 하면 결제를 했거나 송장을 받았음을 증명해야 할 경우, 전체 송장을 보여줄 필요 없이 선택적으로 어떤 부분을 공개할지를 결정할 수 있습니다.
이 모든 것들이 함께 “Lightning 제안”을 구성합니다. 이는 단일 정적 QR 코드를 게시하여 양파 메시지를 통해 노드를 핑하고 Lightning 네트워크에서 특정 결제를 위한 Lightning 송장을 받을 수 있게 합니다. 현재 BOLT 11 송장은 생성된 단일 결제에만 유효하며, 키센드 결제는 송장 없이 결제를 가능하게 하지만, 수신 노드가 서명한 송장에서 결제 세부 정보를 받을 수 없고 이를 향후 기록으로 보관할 수 없습니다. BOLT 12는 두 가지의 모든 이점을 가능하게 하여, 수신 노드에 결제를 용이하게 하는 단일 정적 데이터를 제공하면서도 각 개별 결제의 세부 정보를 포함한 송장을 받을 수 있게 합니다. 간단히 말해, 이는 송신자가 거래를 승인하지 않을 경우 수신자가 돈을 청구할 수 없도록 하면서 스트리밍 결제, 구독 결제 등을 신속하고 쉽게 조정할 수 있게 합니다.
블라인드 경로를 사용함으로써, Lightning 네트워크의 가장 큰 개인 정보 보호 단점을 대폭 개선합니다: 결제를 받는 수신자가 결제를 받는 과정에서 발신자에게 많은 개인 정보를 노출하는 문제입니다. 이는 그들의 채널과 관련된 온체인 UTXO 및 Lightning 네트워크 그래프에서 그들의 위치(즉, 어떤 노드에 연결되어 결제를 받고 있는지)를 포함합니다. 블라인드 경로는 결제를 받을 때와 송장 메시지를 발신자에게 다시 보내기 위해 핑을 받을 때 모두 사용됩니다.
BOLT 12는 Lightning 네트워크 전반에 걸쳐 결제를 조정하는 새로운 방식을 용이하게 하기 위해 여러 요소가 결합된 것입니다. 제안에 대한 가장 큰 비판 중 하나는 일반 목적의 양파 메시지 포함과 이로 인해 새로운 서비스 거부(DoS) 공격 벡터가 열릴 것이라는 우려입니다. 저는 여기서의 논리가 완전히 잘못되었다고 생각하며, 그 이유를 설명하겠습니다.
Lightning 프로토콜의 가장 큰 DoS 문제(및 개인 정보 보호 문제) 중 하나는 프로빙입니다. 각 채널은 비트코인 프로토콜의 거래 크기 제한으로 인해 언제든지 483개의 HTLC(해시 시간 잠금 계약)를 열 수 있으며, 이는 대기 중인 결제를 나타냅니다. 이는 채널 종료 거래가 실제로 체인에 정산될 수 있도록 보장하며, 너무 커서 메모리 풀에서 거부되지 않도록 합니다. 프로빙은 결제를 통해 채널을 스팸하는 행위로, 정보 수집을 위해 고의적으로 실패하도록 설계된 채널을 통해 자금을 어떻게 균형 있게 분배하는지를 알아내기 위해 사용됩니다. 이는 대역폭을 소모하고, 진짜 결제를 처리하는 데 사용할 수 있는 공간을 낭비하며, 네트워크 자원을 낭비하고 결제를 비공식화하는 데 사용될 수 있는 정보를 유출합니다.
프로빙 거래의 문제는, 이들이 단 한 사트도 지불하지 않고 임의의 메시지를 전달하는 데 사용될 수 있다는 것입니다. 결제가 성공하지 않도록 설계된 네트워크를 통해 결제를 라우팅하고 수신자에게 임의의 데이터를 포함시킨 다음, 결제를 실패하게 만들 수 있습니다. 이는 Lightning 네트워크의 결제 프로토콜을 남용하여 임의의 정보를 무료로 전송하는 것이며, 현재 이를 막을 방법이 없습니다. 라우팅하는 결제가 진짜인지 아니면 단순히 데이터를 전달하기 위해 노드를 남용하는 것인지 알 수 없습니다; 결제가 실패하면 자연적으로 실패했는지 아니면 처음부터 실패하도록 설계되었는지 알 수 없습니다. 이는 Sphinxchat이 작동하는 방식과 유사하지만, 그들은 결제를 보내고 네트워크를 무료로 남용하지는 않습니다.
궁극적으로, Lightning 프로토콜의 이러한 사용은 “진짜” 경제적 결제(물론, 누가 “진짜” 경제 활동을 판단할 것인가에 대한 의문이 있지만)에서 사용할 수 있는 HTLC 슬롯 형태의 제한된 처리량을 포화시키고, 현재 아무도 이에 대해 보상을 받지 않는 방식으로 남용될 수 있습니다. 이는 Lightning 네트워크에서 이미 존재하는 매우 실제적인 DoS 위험입니다.
프로빙 문제와 그것이 생성하는 DoS 문제에 대한 몇 가지 제안된 해결책이 있으며, 그 중 주요한 것은 결제가 실제로 성공하기 전에 결제에 대한 수수료를 지불하는 아이디어입니다. 이는 송신자가 결제가 성공적으로 완료되었는지 여부와 관계없이 결제에 대한 수수료를 지불해야 한다는 것을 의미하기 때문에 매우 논란이 많은 제안입니다. 이와 관련된 모든 제안된 해결책의 본질은 이 글의 범위를 벗어나지만, 요점은 제안된 해결책이 있으며 현재 구현되지 않았다는 것입니다. 핵심 포인트: 구현되지 않았습니다.
따라서, 저에게는 일반 양파 메시지가 Lightning에 대해 “새로운 DoS 공격 벡터를 열었다”는 주장은 완전히 잘못된 주장입니다. 그 공격 벡터는 지금 이미 존재합니다. 사실, 이는 일반 양파 메시지보다 더 나쁩니다. 왜냐하면 결제를 라우팅하는 데 필요한 제한된 자원을 낭비하기 때문입니다 — HTLC 슬롯입니다. 일반 양파 메시지는 그렇지 않습니다.
양파 메시지는 끌 수 있는 기능이므로, 귀하의 노드는 이를 완전히 중계하지 않도록 선택할 수 있으며, 또한 속도를 제한할 수 있습니다. 제가 의미하는 바는 귀하의 노드가 초당 “x” 메시지 또는 초당 “y” 양의 데이터를 전달하도록 설정할 수 있으며, 이러한 한계를 초과하는 모든 것을 중계하지 않도록 거부할 수 있다는 것입니다. 이렇게 하면 귀하의 노드는 일반 메시지를 전달하는 데 소비되는 자원의 양을 쉽게 관리할 수 있습니다.
다시 말해, BOLT 12는 새로운 DoS 공격 벡터를 열지 않습니다; 단순히 결제 처리 능력에 영향을 미치는 기존의 공격 벡터를 이동시켜 결제 중계에 영향을 미치지 않거나 HTLC 슬롯을 소모하지 않는 곳으로 이동시킵니다. 또한 결제 흐름을 더욱 제한하지 않고 자원 소비를 완화할 수 있는 방법이 있습니다. 가장 나쁜 상황은 네트워크에서 대규모 스팸 이벤트가 발생하여 양파 메시지 용량이 포화되어 BOLT 12 제안을 사용하거나 네트워크를 통해 송장을 받는 능력이 저하되는 것입니다.
이는 결제 중계에 영향을 미치지 않으며, BOLT 11 송장을 받고 결제하는 능력을 방해하지 않습니다; 단지 BOLT 12를 사용하여 송장을 가져오려는 시도가 양파 메시지로 스팸이 발생하는 한 실패할 것이라는 의미입니다. 또한 약간의 대역폭 사용 증가를 처리하고 싶지 않은 개별 노드는 선택적으로 양파 메시지를 중계하지 않을 수 있습니다. 현재 모든 기능은 계속 작동하며, 기존의 DoS 공격 벡터는 임의의 메시지를 전달하고 싶어하는 사람들이 HTLC 슬롯을 낭비하거나 결제 처리에 방해가 되지 않는 방식으로 이를 수행할 수 있는 일종의 완화 장치를 갖게 됩니다. 또한 새로운 기능을 선택적으로 사용하지 않으려는 사람들은 그렇게 할 수 있습니다.
요약하자면, 저는 BOLT 12에 대한 “DoS 벡터” 주장이 터무니없다고 생각합니다. 사람들이 모든 작업 요소의 복잡성, 이를 구현하는 데 필요한 개발 시간 또는 제안의 다른 측면에 대한 주장을 하고 싶다면, 이는 모두 유효한 주장이라고 생각합니다. 그러나 양파 메시지와 새로운 DoS 벡터에 대한 주장은 설득력이 없습니다.
이 글은 신오비의 게스트 포스트입니다. 표현된 의견은 전적으로 그들의 것이며 BTC Inc 또는 Bitcoin Magazine의 의견을 반드시 반영하지는 않습니다.
