어니언 라우팅

모든 라이트닝 결제는 1,366바이트 크기의 고정된 패킷 안으로 들어가고, 그 층은 한 겹씩 벗겨지므로, 중계 노드는 자신의 앞 노드와 뒤 노드만을 알게 되고 그 이상은 알지 못합니다. 패킷은 각 홉에서 같은 크기를 유지해 경로의 길이와 그 안에서의 자신의 위치를 감춥니다. 경로 중간의 낯선 사람으로부터의 프라이버시는 강하지만, 양 끝의 지갑이나 거래소로부터의 프라이버시는 그렇지 않습니다.

작동 방식

어니언 라우팅은 경로를 홉마다 한 겹씩 층으로 암호화하며, 반대 순서로 감싸므로 가장 바깥층을 벗기는 것이 어떤 노드든 수행할 수 있는 유일한 작업입니다.

BOLT 4는 이 구조를 Sphinx라고 부르며, 홉마다 페이로드를 붙이는 방식으로 확장합니다. 결제가 이동하기 전에, 지갑은 경로상의 모든 노드의 공개 키를 알고 각 노드에 대해 ECDH를 사용해 공유 비밀을 유도합니다. 공유 비밀마다 네 개의 키가 나옵니다. rho는 패킷을 난독화하는 바이트 스트림을 생성하고, mu는 무결성 HMAC를 계산하며, um은 귀환 경로의 오류를 인증하고, pad는 필러를 시드합니다. 그 스트림은 영으로 채운 값에 96비트의 영 논스를 사용해 ChaCha20을 실행한 것으로, 여기서 안전한 이유는 어떤 키도 재사용되지 않기 때문입니다.

패킷에는 네 개의 필드와 하나의 고정 크기가 있습니다. 버전 바이트(현재 0x00), 임시 키 역할을 하는 33바이트 압축 secp256k1 점, 1,300바이트의 홉 페이로드, 32바이트의 HMAC입니다. 이는 전송 중 1,366바이트이며, 길이 접두사가 필요하지 않습니다.

조립은 역순으로 진행됩니다. 1,300바이트 영역은 ChaCha20 스트림에서 나온 무작위 바이트로 시작하고, 마지막 홉부터 첫 홉까지 각 홉에 대해 공간을 만들기 위해 오른쪽으로 시프트되어 먼 쪽 끝이 경계 밖으로 밀려나 버려집니다. 253바이트 미만의 페이로드의 경우 시프트 양은 그 페이로드의 길이에 33을 더한 값입니다. 길이 바이트 1개와 HMAC 32바이트입니다. 각 시프트 뒤에는 해당 홉의 rho 스트림과의 XOR이 이어지며, 이는 앞선 층들을 다시 뒤섞습니다.

홉이 읽는 것은 타입이 붙은 짧은 필드 목록입니다. 타입 2는 밀리사토시 단위의 amt_to_forward이고, 타입 4는 outgoing_cltv_value로 다음에 제시할 HTLC에 부과해야 하는 타임록이며, 타입 6은 short_channel_id로 사용할 채널을 지정하지만 노드는 같은 상대에 대한 다른 채널로 대체할 수 있습니다. 그 짧은 채널 ID 대신 최종 노드는 타입 8을 받으며, 이는 32바이트의 결제 비밀과 총액을 담습니다.

한 단계가 더 있어 연속된 패킷을 연결할 수 없게 만듭니다. 각 홉은 임시 키를 블라인딩 계수로 조정한 뒤 다음으로 넘기므로, 같은 어니언이 거치는 모든 링크에서 서로 무관한 바이트처럼 보입니다. BOLT 4는 그 한계를 솔직히 인정합니다. 난독화는 "does not preclude the possibility of packet association by an attacker via traffic analysis."라고 밝히고 있습니다.

비트코인을 구매할 때 이것이 중요한 이유

어니언 라우팅은 경로 중간의 낯선 사람으로부터는 보호하지만 경로 양 끝에서는 아무도 보호하지 않으며, 이것이 라이트닝 프라이버시에 대해 가장 많이 오해되는 점입니다.

첫 홉은 보통 이미 관계가 있는 서비스이며, 무작위 중계 노드보다 훨씬 많은 것을 봅니다. 이 사이트의 Phoenix 리뷰는 ACINQ의 자체 FAQ를 완화 없이 인용합니다. "The current version of Phoenix offers no advantage regarding privacy over existing, hosted, custodial wallets. We (ACINQ) know the final destination and amount of payments." Phoenix는 이 사이트의 순위에서 4.0 평가를 받으며 진정한 자기 보관형으로, 12개 단어 시드로 보호되는 휴대폰 속의 실제 노드입니다. 수탁과 프라이버시는 별개의 문제이며, Phoenix는 그중 하나에만 잘 답합니다.

받는 쪽도 나을 것이 없습니다. Strike는 자금이 앱에 있는 동안 수탁형이며 본인 확인을 요구하므로, 자신의 지갑으로 하는 라이트닝 출금은 어니언이 몇 홉을 건넜든 Strike에게 금액과 시점, 결제한 인보이스를 알려 줍니다. Wallet of Satoshi는 이 사이트에서 주의 상태와 2.7 평가를 받는데, 부분적으로는 회사가 키를 보유하기 때문이며, 이미 수탁형 라이트닝 서비스를 EU에서 철수했습니다.

그러므로 어니언 라우팅을 규제 회피 수단으로 읽지 마십시오. 그것은 국가별 가이드의 어느 합법성 항목이 자신에게 적용되는지를 바꾸지 않고, 판매한 거래소로부터 구매를 숨기지 않으며, 지갑의 운영자가 양 끝 중 하나일 때는 아무것도 제공하지 않습니다. 그래도 그것이 주는 것은 가치가 있습니다. 한 번도 들어본 적 없는 라우팅 노드는 누가 누구에게 지불하는지의 그래프를 만들 수 없고, 자신이 송신자인지 또 다른 홉인지 알 수 없으며, 짧은 경로와 긴 경로를 구별할 수 없습니다.

한 번도 들어본 적 없는 두 노드를 거쳐 Strike 인보이스를 지불하는 경우

라이트닝으로 Strike 인보이스를 지불하면 경로의 각 노드가 무엇을 알고 무엇을 모르는지 드러납니다.

지갑이 네 개 노드의 경로를 선택한다고 가정해 보겠습니다. 자신의 상대 노드, 공개 라우팅 노드 두 곳, 그다음 Strike입니다. 패킷은 Strike에서부터 거꾸로 구축됩니다. Strike의 페이로드에는 최종 금액과 결제 비밀이 들어갑니다. 각 중간 페이로드에는 하류의 모든 노드 수수료를 여전히 포함한 amt_to_forward, 해당 노드가 공지한 델타만큼 낮춘 outgoing_cltv_value, 사용할 링크의 short_channel_id가 들어갑니다.

두 번째 라우팅 노드는 정확히 하나의 페이로드만 읽습니다. 그것은 앞 노드가 HTLC를 넘겼다는 것과 조금 더 작은 HTLC를 다음으로 제시해야 한다는 것을 알게 됩니다. 그것은 Strike가 끝에 있다는 것을 알지 못하고, 이용자가 시작에 있다는 것도 알지 못하며, 경로가 네 홉인지 여덟 홉인지 구별할 수 없습니다. 자신이 넘기는 영역이 받은 것과 같은 1,300바이트이기 때문입니다.

그 노드에 중계를 위한 유동성이 없으면 귀환 패킷을 만듭니다. 자신의 um 키로 계산한 HMAC, 실패 코드, 실패 메시지와 패딩의 합이 최소 256바이트가 되도록 선택한 패딩, 그리고 그 결과를 ammag 키에서 나온 스트림과 XOR한 값입니다. 돌아오는 길의 모든 홉이 이를 다시 난독화합니다. 지갑은 층을 벗긴 뒤 루프가 27번 실행될 때까지 계속 복호화하며, 이는 TLV 페이로드 형식이 허용하는 가장 긴 경로이므로, 실패한 노드는 반복된 시도의 타이밍으로 자신의 위치를 알아낼 수 없습니다. 더 새로운 노드는 귀속 데이터도 붙입니다. 4바이트로 잘라낸 HMAC로, 최대 20홉 크기의 경로에 대해 210개이며, 유지 시간은 100밀리초 단위입니다.

어니언 라우팅 vs 블라인드 경로

어니언 라우팅은 결제를 운반하는 노드로부터 경로를 숨기고, 블라인드 경로는 지불하는 사람으로부터 경로의 끝부분을 숨깁니다.

단순한 어니언 라우팅은 공유 비밀이 그 키들에 대한 ECDH에서 나오기 때문에 송신자가 모든 노드의 실제 공개 키를 알아야 합니다. 경로 블라인딩은 마지막 구간에서 이를 뒤집습니다. 수신자는 조정된 노드 ID의 사슬을 만들어 BOLT 4의 자체 예시에서 Bob을 Bob prime으로, Carol을 Carol prime으로 바꾼 다음, 송신자에게 소개 지점과 홉마다 하나의 암호화된 블롭을 넘깁니다. 송신자는 읽을 수 없는 블롭들을 어니언으로 감쌉니다. 둘은 경쟁하지 않고 결합됩니다. BOLT 4는 모든 어니언 메시지가 경로 블라인딩을 사용하도록 요구하며, 어니언 메시지는 결제 어니언과 같은 패킷 형식을 사용합니다.

어니언 라우팅 vs HTLC

어니언 라우팅은 지시를 운반하고 HTLC는 돈을 운반하며, 라이트닝 결제는 각각이 다른 쪽을 검증하기 때문에 둘 다 필요합니다.

어니언은 홉에게 어디로 전달할지와 얼마를 전달할지 알려 줍니다. HTLC는 채널에서 실제로 제시되는 조건부 결제입니다. 페이로드 영역은 송신자와 그 홉만 생성할 수 있는 패킷 전체의 HMAC로 덮이므로, 노드는 자신에게 제시된 HTLC를 자신을 위해 기록된 amt_to_forward와 outgoing_cltv_value와 비교하고, 그것들이 일치하지 않으면 실패로 처리합니다. 이는 상류 노드가 조용히 금액을 깎는 것을 잡아냅니다. 둘은 분리되기도 합니다. 어니언 메시지(타입 513)는 돈을 운반하지 않는 같은 구조이며, 중간 홉은 그것에 대해 결코 오류를 반환하지 않습니다.