[블록체인] 16. Lightning Network (2) : Commitment Sign & Payment Channel

이제 LN의 큰 흐름을 이해했으니, 디테일한 부분과 확장된 기능들을 살펴보자.

 

앨리스와 밥 사이에 P2P 네트워크를 통해 실제 거래가 발생하면 페이먼트 채널이 업데이트된다.

이때 commitment transaction 을 추가하는 것은 둘 사이의 P2P 네트워크로 데이터만 전송하면 되므로 1~2초면 끝난다.

이런 점에서 비트코인과 비교하면 매우 빠른 속도로 결제가 이루어진다.

 

또한 엘리스와 밥 사이의 페이먼트는 암호화 시켜서 보낼 수 있으므로 확실한 프라이버시가 보장된다.

지난 글에서 처럼 카페 사장과 손님의 예시로 들자면, 앨리스가 밥의 카페에서 얼마나 자주 커피를 마시는 지는 앨리스와 밥만 알 수 있고, 제 3자는 알 수 없다. 모든 거래 내역은 숨겨지고, 그 최종 거래금액만 네트워크에 뿌려지기 때문이다.

비트코인에서는 모든 트랜잭션이 공개되어 있으므로, 위 거래를 순수하게 비트코인의 트랜잭션으로 진행했다면 앨리스와 밥 사이의 거래 횟수와 같은 정보는 모두 공개적으로 알 수 있게 된다.

 

엘리스와 밥 사이의 commitment payment 가 발생할 때마다, 이전의 commitment payment 는 사용할 수 없는 과거의 commitment 가 된다. (이를 revoke된다고 표현한다.)

하지만 결국 commitment transaction 도 비트코인의 트랜잭션이고, 그냥 revoke 되었더라도 충분히 뿌려서 컨펌받을 수는 있다. 물론 그 경우엔 지난 글에서 정리한대로 상대방이 응징할 것이다.

 

그렇다면 실제로 Commitment transaction을 어떻게 생성하는지 과정을 살펴보자.

 

 

A와 B 사이에 commitment transaction을 생성할 대는 위와 같이 commitment_signed 요청과 revoke_and_ack 응답을 주고받는 형식으로 commitment transaction을 생성한다.

 

commitment_signed 는 앨리스가 밥에게 밥이 필요한 앨리스의 서명을 주는 것을 말한다.

revoke_and_ack 에서는 밥이 앨리스에게 자신의 이전 commitment 트랜잭션에 대한 secret_key를 제공한다.

 

그 다음에는 마찬가지로 밥이 앨리스에게 앨리스가 필요로 하는 서명을 제공하면, 앨리스는 그 응답으로 자신의 이전 트랜잭션에 대한 secret key 를 제공한다.

(만약에 밥이 ack를 안보내고 서명만 받은 채 잠수를 타면 어떻게 될까? 그때는 그 트랜잭션을 뿌리더라도 revocation key에 대한 서명을 앨리스만 갖고 있으므로 밥이 자신의 트랜잭션을 뿌려버리면 앨리스가 응징할 수 있을 것 같긴하다. 그렇다면 밥은 어떻게 revocation key를 알고 있을까? 구체적으로 revocation key를 어떻게 만드는 지를 알아야 할 것 같다.)

 

 

위 그림과 같이 Commitment #2까지 주고받은 상황에서 Commitment #3을 생성한다고 해보자.

밥의 카페에서 앨리스가 2만 사토시를 주고 커피를 사마시는 상황이다.

 

이때 앨리스와 밥은 서로 #3 트랜잭션에 대한 서명을 주고 받는다.

#3 트랜잭션은 각자가 자신에게 맞는 형태의 트랜잭션을 갖고 있고, 이 트랜잭션으로부터 돈을 꺼내 쓰려면 각자 상대방의 서명이 필요하기 때문이다.

 

그래서 두 파트너는 네트워크에 뿌리지만 않았지 사실상 서명이 완료된, 언제든 뿌릴 수 있는 commitment transaction을 갖고 있으므로 언제든 이 트랜잭션으로부터 자신의 돈을 받을 수 있다.

 

또한 이전 트랜잭션이 revoke 되었다는 증거로, 이전 트랜잭션을 내가 뿌린다면 상대방이 내 돈을 가져갈 수 있도록 나의 약점인 secret key를 서로에게 제공한다.

이로써 이전 트랜잭션은 (실제로는 비트코인 네트워크에 유효한 트랜잭션으로서 뿌릴 수 있지만) 사실상 폐기된 것과 같은 효과를 갖는다.

 

 

만약 앨리스가 revoked 된 트랜잭션을 뿌렸고, 밥이 이를 432블록(3일)이 지나기 전에 알아차렸다면, 앨리스가 제공했던 revocation key에 대한 서명을 사용해서 앨리스가 자신의 주소로 보내려던 7만 사토시와 자기 자신으로 원래 보내지던 7만 사토시를 모아 14만 사토시를 자신이 챙겨갈 수 있다. 이렇게 상대방을 응징하는 트랜잭션을 가리켜 '페널티 트랜잭션' 이라고 한다.

(revocation key 는 일종의 public key와 같고, 이에 대한 서명은 앨리스가 밥에게 제공한다.)

 

그리고 치팅을 방지하는 핵심은 자신의 돈을 바로 꺼낼 수 없도록 막은 3일의 타임 락 과 revocation key 2가지가 핵심적인 기능이다.

 

만약 앨리스가 마치 밥이 치팅한 것처럼 속이고 밥이 알려준 revocation key를 이용해서 모든 돈을 뺏어가려고 한다면, 이는 어떻게 막을 수 있을까? 그때는 밥이 치팅했다는 것은 밥이 구성한 형태로 트랜잭션을 만들어서 뿌려야 한다는 뜻인데, 이 형태에 대해 밥의 서명을 앨리스는 알지 못한다. output index의 순서가 자신의 것과 다르므로 해시값이 달라져서 서명도 달라지기 때문이다.

 

채널의 파트너는 지금까지 revoke된 모든 commitment transactions 에 대한 secret key를 모두 가지고 있다.

이 개수가 너무 많아서 보관하기 힘들어 보이는데, 사실 마지막 key 하나만 갖고 있으면 나머지 key를 모두 계산할 수 있는 로직이 존재한다고 한다. (P2P 네트워크 사이에서 앨리스와 밥만 갖고 있으면 되니 네트워크 전반적으로도 부담되지 않는다.)

---

 

그렇다면 두 사람이 합의 하에 채널을 닫는 것은 어떻게 할 수 있을까?

채널이 닫히는 경우는 크게 3가지가 있다.

 

1. 정상적으로 합의 하에 종료하는 경우

2. 파트너가 잠수를 타서 나머지 한 쪽이 강제로 다 받아내는 경우 (자신의 마지막 commitment transaction을 네트워크에 뿌린다.)

3. 파트너가 나를 속여서 페널티 트랜잭션을 통해 응징하는 경우

 

채널을 닫는 과정은 위와 같이 진행된다.

(근데 이 페이지에 대해 설명이 없으셨다..)

먼저 앨리스와 밥이 서로 닫는 것에 합의하기 위해서 채널을 닫자는 요청을 보내고 승낙이 이루어지면, 각자가 가진 최종 커밋먼트 트랜잭션 중 하나를 합의하에 뿌리고 그로부터 돈을 자신의 계좌로 옮기면 되지 않을까.. 싶기는 하다.

---

Announcing the Channel

지금까지는 Payment Channel 이 앨리스와 밥 사이에 직접 1:1로 연결된 상황만 생각했었다.

그런데 내가 직접 페이먼트 채널이 연결되어 있지는 않지만, LN 내에서 연결된 다른 사람에게 돈을 보내고 싶을 수도 있다.

LN은 이런 경우에도 페이먼트하는 방법을 고려하였다.

 

 

 

위 그림을 보면 앨리스와 밥이 직접 연결되어있고, 밥은 Chan과 연결되어있고, Chan은 다이나와 연결되어 있다.

이때 앨리스가 다이나에게 1만 사토시를 전송하고 싶어한다. LN은 이렇게 둘 사이에 직접적으로 페이먼트 채널이 만들어져 있지 않더라도 결제할 수 있는 방법을 제공한다.

 

앨리스와 밥 사이의 채널을 통해 1만 사토시를 밥에게 지불하고, 밥은 chan에게 1만 사토시를 지불하고, Chan이 다이나에게 1만 사토시를 지불하면 결과적으로 앨리스는 다이나에게 1만 사토시를 지불하게 된 것과 같다.

 

물론 이 과정에서 밥과 Chan 사이 채널은 앨리스와 다이나 사이에 아무런 연관성이 없기 때문에 그 중간 통로를 빌려주는 역할만 하게 되고, 그렇다면 이 둘은 이 과정에서 수수료를 받고자 할 수 있다.

그래서 실제로 이걸로 사업도 할 수 있다. 직접적인 페이먼트 채널이 존재하지 않은 상대방에게 돈을 지불하고자 할 때 자신의 채널을 경유해서 지불하면 상대방에게 지불할 수 있으니 자신에게 수수료를 내고 대신 지불하라고 하는 것이다.

 

이를 위해서 채널을 빌려주려는 사람은 자신의 페이먼트 채널을 광고하게 된다.

먼저 빌려주려는 채널의 두 파트너가 서로 채널을 광고하는데 동의하면, 이 채널을 public channel 로 만들고, LN의 gossip protocol 을 통해 다른 노드에게 자신의 채널 정보를 뿌린다. (이때 채널의 capacity, fee, timelock 등도 함께 광고한다. 타임락은 내 채널을 통해 페이먼트를 진행할 때, 만약 타임락 기간 동안 응답이 없으면 그냥 전달하기를 포가하겠다는 뜻이다.)

(가쉽 프로토콜은 일종의 브로드캐스트와 비슷하다)

이런 식으로 public channel 들이 쌓이게 되면 신규 노드가 LN에 들어왔을 때 gossip protocol을 통해 public channel 정보들을 받고, 라우팅 문제를 풀 듯이 하나의 노드로부터 다른 노드로 가는 경로를 자체적으로 구성하여 public channel 을 통해 돈을 지불할 수 있게 된다. (경로를 보내려는 사람(=source)이 직접 알아서 찾아야 하기 때문에 LN의 확장성이 좋지 않다고 평가받는다. source base path finding은 확장성이 안좋기 때문이다.)

 

물론 원하는 경우에는 두 파트너 사이의 채널을 공개하지 않고 unannounced channel 로 유지할 수 있다.

이 경우에는 이 채널의 존재를 알고 있는 소수의 사람들만 채널을 이용할 수 있게 된다.

 

Invoice

앨리스가 다이나에게 1만 사토시를 페이먼트하고 싶다고 요청을 보내면 다이나는 앨리스에게 invoice(견적서)를 발급한다.

invoice에는 payment identifier, 수신자 (다이나), 송금액 (1만 사토시), text description 이 들어갈 수 있다.

앨리스는 이 정보를 받으면 invoice에 대해 지불함으로써 다이나에게 돈을 보낼 수 있다.

그리고 invoice에 대한 페이먼트는 atomic 하게 전송된다. 즉, 목적지에 도착해서 정상적으로 전송이 되거나, 전송이 되지 않거나 두 가지 결과만 발생하고, 중간까지만 보내지는 일은 일어나지 않는다.

 

invoice는 QR 코드, 이메일, 웹사이트에서 제공하는 데이터 등 다양한 수단으로 받을 수 있다.

마치 비트코인에서 수신자가 자신의 address 를 제공해서 이곳으로 보내도록 유도하듯, LN에서는 수신자가 invoice를 만들어서 송신자에게 보낸다.

 

비트코인에서는 돈을 지불할 때 트랜잭션을 만들고 비트코인 네트워크에 브로드캐스트해서 지불했다.

나의 트랜잭션을 어떤 채굴자가 받아서 채굴하는지는 관심사가 아니다.

하지만 LN에서는 invoice에 대해 페이먼트를 하고, 이 페이먼트는 정해진 목적지까지 라우팅이 되는 차이가 존재한다.

그래서 앨리스는 다이나로 지불하려는 경우, 다이나까지의 경로를 직접 찾아야 하고, 그 사이의 경유지는 몇 명이든 존재할 수 있다.

이때 라우팅은 onion routing 방식을 사용하는데, 뒤에서 자세히 정리한다.

 

결론적으로 LN의 invoice 는 비트코인의 address와 같은 개념이다.

그리고 LN의 payment는 비트코인의 트랜잭션과 같은 개념이다.

 

 

payment identifier는 payment hash로 부르기도 한다.

payment hash를 생성하는 과정은 다음과 같다.

 

1. 페이먼트 해시를 생성하고자 하면, 먼저 random number 로서 r을 고른다. 이 숫자는 preimage 또는 payment secret 이라고 부른다.

2. H = SHA256(r) 일 때, 이 H 값이 payment hash가 된다.

 

페이먼트 해시를 쓰는 이유는 앨리스가 페이먼트를 전송하는 과정에서 경유하는 밥과 chan을 신뢰할 수 없기 때문이다.

나에게 들어온 돈을 그냥 꿀꺽하고 안보낼 수도 있는 것이다. (잠수를 타거나, 못 받은 척을 하거나)

 

그래서 이를 방지하기 위해 invoice 에 해시값을 포함시켜서 보낸다.

그리고 다이나가 인보이스를 만들 때 사용한 r 값은 나중에 영수증으로서 제공한다.

 

앨리스와 다이나 사이에 페이먼트가 이루어지는 과정은, 실제로 앨리스가 밥에게 돈을 제공해서 시작하는 것이 아니라, chan이 다이나에게 1만 사토시를 제공하면, 다이나가 chan에게 r 값을 영수증으로 제공하고, chan은 밥에게 1만 사토시를 요구한다.

밥이 chan에게 1만 사토시를 제공하면, 다시 밥이 r 값을 받아서 앨리스에게 1만 사토시를 요구하는 방법으로 정산이 이루어진다.

 

이 r값만 알 수 있다면 실제로 돈을 지불했음에 대한 증거가 되니, 이 값은 쉽게 알아낼 수 없어야한다.

만약 chan이 r 값을 알아내는데 성공했다면 다이나에게 돈을 보내지 않고 돈을 보낸척 r값을 밥에게 제공하는 방법으로, 최종적으로 앨리스로부터 1만 사토시를 대신 가로챌 수 있게 된다.

(그러면 만약 앨리스가 밥으로부터 r 값을 받은 뒤에 잘 보내졌구나? 고마워 난 안 낼게~ 하고 도망가면 어떻게 될까?)

 

---

 

Invoice에는 해시 이외에 추가적인 메타 데이터가 들어간다.

 

1. text description (옵션)

 

2. 라우팅 힌트

라우팅 힌트는 unannounced channel 을 경유해서 전달하려는 경우, 이 채널은 알려지지 않았으므로 라우팅 힌트를 통해 채널 정보를 전달해서 경유한다. 그래서 unannounced 채널도 다른 노드가 경유해서 페이먼트를 전송할 수 있다.

 

3. capacity

다른 채널을 경유할 때는 당연히 내가 보내려는 돈이 그 채널의 capacity 보다 작아야 한다.

그런데 앨리스가 밥을 경유해서 돈을 보내는데, 밥의 잔액이 부족하다고 해보자.

이 경우에는 밥이 앨리스의 요구를 들어줄 수 없다.

(밥과 chan 사이 채널에, 현재 밥 쪽의 잔액이 1만이 안된다고 하면, 밥의 잔액으로 1만 사토시를 챈에게 보낼텐데, 밥은 앨리스로부터 1만 사토시를 받는다는 보장이 있지 않으면 챈에게 보내지 않을 것이다. 따라서 앨리스의 부탁을 포워딩 시킬 수 없으므로 capacity 정보도 유용한 정보가 된다... 라고 하는데, 이해가 안된다. capacity는 밥과 chan 사이에 주고받을 수 있는, 최초에 개설된 funding 금액이 아닌가? 왜 밥의 잔액과 관련이 있는걸까? 여기에서의 capacity는 밥의 잔액을 의미하는 것이었을까?)

 

4. expiry date

invoice에는 유효기간 정보도 함께 들어있다.

수신자(다이나)는 모든 preimage(r 값)를 가지고 있어야 한다.

왜냐하면 앨리스에게는 H(r)을 보냈으므로 자신에게 돈이 올 때, 즉, commitment transaction이 올 때 내가 돈을 꺼낼 주소는 H(r) 이기 때문이고, 자신에게 H(r)을 보낸 chan 에게는 자신이 돈을 받았다는 증거로 r을 제공해야 하기 때문이다.

 

이때 다이나가 워낙 인기가 많은 셀럽과 같은 존재라서 자신이 받을 돈이 많다면, 수많은 r 값을 관리해야 하고, 이는 부담스러울 것이다.

그래서 invoice의 유효기간을 설정하고, 유효기간이 지난 r 값은 모두 버린다. (물론 자신이 정상적으로 수신한 r 값에 대해서도 버린다.)

(실제로도 견적서에는 유효기간이 있다. 특정 장비를 주문한다고 할 때도 그 장비의 가격이 들쭉날쭉 바뀔 수 있기 때문에 이때까지는 이 가격에 팔겠다는 식으로 유효기간을 명시한다.)

 

 

Delivering the Payment

페이먼트 해시는 여러 페이먼트 채널 사이에서 페이먼트를 이동하는데 사용된다.

이때 LN에서 사용하는 통신 프로토콜은 크게 3가지가 있다.

 

- P2P Gossip Protocol

- Path finding

- Routing

 

 

P2P Gossip Protocol

송신자가 수신자의 목적지까지 가는 경로를 찾는데 사용할 채널 정보를 받아오는 프로토콜 (정보 수집 프로토콜)

채널의 announcement 가 gossip protocol을 통해 LN 네트워크를 구성하는 노드들에게 전달된다.

그래서 각 노드는 정보를 받으면 또 자신의 주변 노드에게 전파하고, 주변 노드도 또 주변에 전파하는 방법으로 announcement 정보가 퍼져나간다.

 

그래서 LN에서 노드와 노드 사이에 연결이 되어있다는 뜻은 꼭 직접적인 페이먼트 채널로 연결되어 있지 않아도 괜찮다.

그냥 gossip protocol 을 통해서 연결이 되어있다면 그것도 연결된 것이라고 볼 수 있다.

즉, 채널 파트너가 아니더라도, 가쉽 프로토콜을 통해서 데이터를 주고받을 수 있다면 연결된 것이다.

 

두 파트너가 채널을 생성한 다음에는 이 채널을 공개할 지 말 지 결정할 수 있다.

만약 채널을 공개하게 되면 channel_announcement 라는 메세지를 주변 노드에 뿌린다.

주변 노드(피어)는 채널 announcement 정보가 맞는지 검증한다. 존재하지 않는 채널 정보가 퍼지면 페이먼트가 전달되다가 끊길 수도 있기 때문이다. 검증은 비트코인 블록체인에 이 채널의 funding transaction이 들어있는지 확인하는 것으로 검증할 수 있다.

이때 통신 부담을 줄이기 위해서 내가 이미 들은 채널 광고는 다시 주변에 광고하지 않는다.

 

 

가쉽 프로토콜로는 payment channel 의 메타데이터도 주고받는다.

이 메타데이터는 routing 결정을 내리는 다른 노드에게 유용하며, channel_update 메세지를 통해 서로가 알고있는 채널 정보를 업데이트 할 수 있다. 채널 정보의 업데이트는 과도한 통신이 발생하는 것을 막기 위해 채널당 하루에 대략 4번까지만 이루어질 수 있다.

 

예를 들어, 밥과 chan 사이의 capacity 가 500만인데, 대부분의 잔액이 chan쪽에 몰려있어, 밥은 큰 금액을 받을 수 없는 상황이라면 이 채널로 페이먼트를 보내면 안되기 때문에 이런 정보를 하루에 4번 정도 포워딩 시킬 수 있다.

 

---

 

가쉽 프로토콜을 사용할 때 발생할 수 있는 주요 문제점으로는 전달되는 정보가 partial 하다는 문제가 있다.

예를 들어, 어떤 채널이 광고 되었는데, 그 채널의 capacity 이외에도 그 채널을 구성하는 a, b의 잔액이 현재 얼마인지 정보를 알아야 그 채널을 사용할 수 있다. 하지만 a, b 사이의 잔액 정보는 매번 동적으로 바뀌기 때문에 이 정보를 실시간으로 정확하게 아는 것이 매우 어렵다.

 

그래서 동작할 때는 a-b 사이 채널로 일단 보내보고, 만약 그쪽의 local balance가 충분하지 않다면 다시 돌아와서 다른 쪽으로 시도해보는 시행착오를 통해 페이먼트를 전달한다(..)

 

그렇다면 왜 a, b 사이의 구체적인 balance 정보나 전체 네트워크 구성 형태를 알 수 없는걸까?

 

1. 사용자 privacy : 두 채널을 구성하는 파트너가 자신의 잔액을 공개적으로 알리기를 꺼릴 것이다. 왜냐하면 자신의 잔액이 변동될 때마다 주변에 알려지면 내가 상대방과 돈을 주고 받았다는 사실이 모두에게 알려지는 것이기 때문이다.

 

2. payment amount 를 증가시키기 위해 (?) : 앨리스와 다이나 사이의 페이먼트 말고도, 밥이 찰리와 페이먼트를 하는 등 여러 페이먼트가 네트워크를 통해 중간 경로를 공유하면서 갈 수 있다. 예를 들어 여러 개의 페이먼트가 B-C 사이의 채널을 모두 공유한다면 그 채널이 병목이 될 수 있다. (이런 문제가 해결되지 않은 거랑 구체적인 balance 정보를 주지 않는 거랑 무슨 상관이지..?)

 

3. 라이트닝 네트워크의 구성 형태(토폴로지)가 계속 변할 수 있다 : 토폴로지는 피어와 피어 사이의 연결로 구성된 일종의 그래프 형태를 나타낸다. LN을 구성하는 노드는 언제든 자유롭게 떠나고 참여할 수 있기 때문에 그 형태가 매우 다이나믹하게 변한다.

따라서 내가 B-C 페이먼트 채널을 통해서 페이먼트를 전송하려고 했는데, 알고보니 B가 네트워크를 빠져나간 상태일 수도 있다.

이렇게 노드가 활동을 안하거나 네트워크를 탈퇴하는 등의 이유로 네트워크의 구성 형태가 변화하므로 정확한 토폴로지 형태의 정보를 주고받는 것이 힘들다.

 

 

Path Finding & Routing

Gossip Protocol은 공개된 채널 정보를 전체 노드에게 뿌리는 것이 목적이었다면, 이 정보를 기반으로 실제 경로를 찾는 패스 파인딩이 필요하다.

앨리스가 다이나에게 페이먼트를 전송하기 위해서 자신과 연결된 라이트닝 네트워크의 P2P 채널 정보를 모으고, 내가 연결된 채널로부터 어떻게하면 다이나까지 갈 수 있을지 그 경로를 직접 찾는다.

이를 가리켜 source-based protocol 이라고 한다.

나중에 LN을 사용하는 사람들이 늘어나면 개선될 여지가 있지만, 현재는 이렇게 송금할 노드가 직접 찾는다.

 

그리고 이렇게 찾은 경로를 토대로 직접 페이먼트를 전달하는 것을 가리켜 라우팅이라고 한다.

LN에서는 라우팅으로 onion-routed protocol 을 사용한다. (onion-routed 라는 말은 일반적인 용어)

양파 껍질이 계속해서 까도 까도 안쪽이 나오듯이 보안을 유지한 채 목적지로 데이터를 보내는 것을 의미한다.

그래서 path 가 계층적으로 쌓여있고, 각각의 계층이 암호화 되어있어서 그 계층에서 보내는 그 노드만 한번에 볼 수 있도록 되어있다.

 

onion-routed 방식의 유명한 프로토콜로 토어(토르) 라고 하는 미국 해군 연구소에서 만든 라우팅이 있고,

이 방식은 목적지를 알아보지 못하는 상태, 확실한 프라이버시를 보장한 상태로 목적지까지 보내는 방식이다.

그리고 LN에서 라우팅 알고리즘으로 이 알고리즘을 사용한다.

 

컴퓨터 네트워크에서 IPv6를 구현할 때, IPv6를 지원하지 않아서 이를 데이터로 감싸고 있는 IPv4 노드의 라우팅 방식에서도 최종 목적지는 알고있고, 그 목적지로 가는 가장 빠른 경로를 자신의 라우팅 테이블에서 확인해서 보냈다.

 

하지만 토르 알고리즘은 최종 목적지는 최종 목적지 자신인 노드만 알고 있으며, 각각의 노드는 내가 받은 이 데이터를 어디로 넘겨야 할 지만 알고 있다. 심지어 최종 목적지 직전의 노드도 내가 넘기고 있는 노드가 최종 목적지라는 사실을 모르며, 최종 목적지에 해당하는 노드만, 자신이 받은 데이터가 자신에게 온 데이터라는 것을 알 수 있다.

 

이때 계속해서 데이터를 감싸다보면 데이터의 길이가 점점 늘어나게 되고, 데이터의 길이로부터 다음에 보낼 노드가 목적지 노드일 것이라는 것을 유추할 수 있는 문제로 인해, 모든 데이터의 길이를 동일하게 맞춘다.

그리고 이를 위해서 데이터 뒤에 더미데이터를 붙이는 방식을 사용한다.

 

어떤 노드가 자신이 받은 데이터를 다음 노드로 보낼 때 이를 위해 읽은 정보가 있다면, 그 정보는 더이상 쓰이지 않으니 제거하는 대신 뒤에 더미데이터를 붙여서 길이를 그대로 유지하는 것이다.

그렇다면 더미 데이터와 실제 데이터를 구분해서 실제 데이터의 길이를 유추할 수 있지 않을까? 하는 문제가 있다.

이를 위해서 암호화를 사용하며, 암호화된 데이터와 랜덤한 쓰레기 값을 길이 맞추기 위해서 붙인 값을 중간 경유지 노드는 구분할 수 없다.