Assumptions
Alice 블록을 갖고있고, Bob은 블록을 받아야하는 상황.(마이너끼리 혹은 마이닝풀 내에서 Peer에게 전송)
Alice의 블록에 이미 Bob의 pool에 있는 중복되는 트랜잭션이 많다고 가정하고, Bob에게 없는 트랜잭션만을 받기 위함. 혹은 누락된 트랜잭션을 받기 위함.
데이터 전송에 최소 대역폭 사용을 목표로함.
XThin Blocks
- Alic가 블록을 갖고있다는 사실을 알리면
- Bob은 자신의 pool에 있는 트랜잭션을 이용한 Bloom filter를 생성하여, getdata요청과 함께 전송한다.
- Alice는 블록의 header와 트랜잭션id 리스트를 전송한다.
결과 : 그러나 결국 Compact Blocks 보다 더 많은 데이터를 전송하게 됨.
+또 다른 방법(존재하지않는 프로토콜)
- Alic가 블록을 갖고있다는 사실을 알리면
- Bob이 자신의 pool 사이즈(m)를 Alice에게 알려주면서 getdata요청한다.
- Alice는 블록의 모든 트랜잭션에 대해 블룸필터를 생성하고, 블록 header와 함께 전송한다.
- Bob은 받은 블룸필터로 pool에서 필요한 트랜잭션들을 찾아낸다.
- FPR(False Positive Rate)는 블룸필터의 크기가 크고, 검색할 원소의 수가 작을수록 낮아짐. (블룸필터의 크기는 트랜잭션 수와 관련이 있다)
- FPR = 1/m으로 설정하면(pool에 있는 m개의 트랜잭션들 중 1개가 false positive된다는 의미), 한 블록당 한 트랜잭션꼴로 잘못 포함하게 되어 (pool의 모든 트랜잭션을 비교한다고 할때, 트랜잭션수 m을 곱하면 1/m * m = 1 이므로) Bob은 매번 블록 생성에 실패하게된다.
- FPR을 좀 더 낮추어 1/100m으로 설정하면, Bob은 100개 블록당 한번씩 블록 생성에 실패하게된다. (1/100m * m = 0.01 = 1%이므로) 이 경우에는 Compacts blocks가 더 낫다.
결과 : mempool의 크기에 따라 전송 데이터량이 결정된다. 크기가 클수록 전송할 데이터량도 많아진다.
bloom filter의 false positive rate를 줄이기 위해서는 bloom filter의 크기가 커야하고 검색할 원소의 수(pool의 트랜잭션 수)가 적어야하므로 단독 사용에 한계가 있다.
References
Scaling Bitcoin Stanfornd 2017 - Graphene: A New PRotocol for Block Propagation Using Set Reconciliation
