Block sync, SPV

Block sync problem

1. 받아야할 블록데이터의 양이 증가(크기 및 시간지연 문제)
1. light node(or SPV node)사용.
2. 필요없는 데이터의 크기를 압축(compession), or 삭제(pruning)
3. 블록데이터 구조를 변경하여 크기를 줄임

2. 유효성 검증(메인 체인에 포함된 블록인지, 트랜잭션이 블록에 포함되었는지 등, 비트코인 로직은 여기)
블록과 트랜잭션의 검증시의 시간지연을 줄임 (실제로 검증을 할지는 모르겠으나..)
1. SPV Proofs : HVHH, Compact SPV, NiPoPow, FlyClient, BlockQuick..?
• skiplist

SPV client의 블록 동기화에 Bloom Filter를 사용하는 이유.(BIP 37)

• 동기화시에 전체 트랜잭션을 다운받을 필요가 없다. 자신과 관련이 없는 대부분의 트랜잭션을 버리게됨. 이는 동기화로 인한 시간지연과 메모리, 대역폭 낭비로 이어짐.

• Bloom Filter는 확률론적이며, false positives rate는 client에의해 결정되는데, 정확성과(precision)과 대역폭 사용량(bandwidth usage)사이 trade off가 있다.
높은 fpr→ 정확성이 떨어져 client에 어떤 트랜잭션이 있는지 peer가 정확히 알수 없음
낮은 fpr → peer가 트랜잭션을 IP주소와 상관시킬수 있게됨. privacy문제

• Bloom Filter는 compact하며, membership query가 빠르다
필터 매칭 알고리즘이 있어, 풀노드는 데이터를 누락할수 없게되고, DoS 공격 가능성을 최소화하면서 성능을 만족시킬수 있다.
(SPV노드는 자신이 원하는 트랜잭션을 특정하지 않고, 일종의 패턴만을 풀노드에 제공하여 어느정도 DoS를 회피가능하다. 자신이 원하는 트랜잭션 외에 패턴과 일치하는 여러 트랜잭션을 받을수 있기때문)

SPV Proofs

• SPV Proofs : merkleblock message 의 파싱은 미디엄글 참고

Compact SPV

NIPoPoW

FlyClient