Snapshot Sync Implementation

#Klaytn

현재 클레이튼에서는 전체 싱크(Full Sync)만을 지원합니다. 전체 싱크란 블록 헤더와 트랜잭션을 다른 피어(peer)로부터 받고, 트랜잭션을 재실행하면서 최신 블록까지 동기화하는 기술을 의미합니다. 이더리움에서는 더 빠른 동기화를 위한 기술로 스냅 싱크(Snap Sync)를 구현하였는데요. 스냅 싱크란 전체 싱크와는 다르게 트랜잭션을 재실행하는 대신, 최신 블록의 스냅샷 데이터와 리시트(receipt)를 추가로 가져와서 빠르게 동기화하는 기술을 의미합니다. 이더리움의 스냅 싱크 구조 및 방식과, 클레이튼과의 차이점 그리고 이더리움의 스냅 싱크를 클레이튼으로 옮겨오면서 발생하는 문제점 등을 공유하고자 합니다.

발표자 : jk.oh

크러스트유니버스의 클레이튼 코어 데브팀 스토리지 파트에서 개발하고 있는 JK입니다. 가까운 미래에는 블록체인이 없는 세상을 상상할수 없다고 굳게 믿고 있습니다.

Transcript

1. 오정균 JK.Oh Krustuniverse Copyright 2022. Kakao Corp. All rights reserved. Redistribution or public display is not permitted without written permission from Kakao. Snapshot Sync Implementation if(kakao)2022
2. য়੿Ӑ JK 자기소개 경력사항 [16~19] BSc. University of Groningen [19~22] GroundX (Klaytn, KAS) [22~] Krustuniverse (Klaytn Core Dev, Storage Part)
3. 블록동기화 Full Synchronization Fast Synchronization Snapshot Synchronization 결과 및 이슈
4. https:/ /if.kakao.com/2020/session/34 https:/ /if.kakao.com/2020/session/44
5. 블록동기화 Full Synchronization Fast Synchronization Snapshot Synchronization 결과 및 이슈
6. 블록 동기화(Sync) 최신 블록을 처리하기 위해 이미 네트워크에서 처리한 블록들을 다운로드하고 검증 및 처리하는 과정 동기화 종류 Full Fast Snap 다운로드 데이터 블록헤더, 트랜잭션 블록헤더, 트랜잭션, 영수증 
 특정블록의 모든 State Trie 노드 블록헤더, 트랜잭션, 영수증 
 특정블록의 모든 State Trie Leaf 노드 특징 모든 트랜잭션을 재실행하고 모든 블록에 대해서 State 전이가 일어남 모든 State Trie 노드를 네트워크를 통 해서 다운로드 함 State Trie Leaf노드만 다운로드하고 로컬에서 재구성함 걸리는 시간 (~96M) 3 Weeks X 4 - 5 Days
7. 블록 동기화(Sync) 최신 블록을 처리하기 위해 이미 네트워크에서 처리한 블록들을 다운로드하고 검증 및 처리하는 과정 동기화 종류 Full Fast Snap 다운로드 데이터 블록헤더, 트랜잭션 블록헤더, 트랜잭션, 영수증 
 특정블록의 모든 State Trie 노드 블록헤더, 트랜잭션, 영수증 
 특정블록의 모든 State Trie Leaf 노드 특징 모든 트랜잭션을 재실행하고 모든 블록에 대해서 State 전이가 일어남 모든 State Trie 노드를 네트워크를 통 해서 다운로드 함 State Trie Leaf노드만 다운로드하고 로컬에서 재구성함 걸리는 시간 (~96M) 3 Weeks X 4 - 5 Days
8. 블록 동기화(Sync) 최신 블록을 처리하기 위해 이미 네트워크에서 처리한 블록들을 다운로드하고 검증 및 처리하는 과정 동기화 종류 Full Fast Snap 다운로드 데이터 블록헤더, 트랜잭션 블록헤더, 트랜잭션, 영수증 
 특정블록의 모든 State Trie 노드 블록헤더, 트랜잭션, 영수증 
 특정블록의 모든 State Trie Leaf 노드 특징 모든 트랜잭션을 재실행하고 모든 블록에 대해서 State 전이가 일어남 모든 State Trie 노드를 네트워크를 통 해서 다운로드 함 State Trie Leaf노드만 다운로드하고 로컬에서 재구성함 걸리는 시간 (~96M) 3 Weeks X 4 - 5 Days
9. 블록과 상태(State) ࠶۾ ೻؊ … ౟ے੥࣌ 1 ౟ے੥࣌ 2 State ৔ഐ: 100 KLAY ৔ࣼ: 200 KLAY ৠࣽ: 300 KLAY … ࠶۾ ৔ࣻૐ 2 ৔ࣻૐ 1
10. 블록과 상태(State) ࠶۾ ೻؊ … ౟ے੥࣌ 1 ౟ے੥࣌ 2 State ৔ഐ: 100 KLAY ৔ࣼ: 200 KLAY ৠࣽ: 300 KLAY … ࠶۾ ৔ࣻૐ 2 ৔ࣻૐ 1
11. 블록동기화 Full Synchronization Fast Synchronization Snapshot Synchronization 결과 및 이슈
12. - 헤더를 다운로드 및 검증한다 - 트랜잭션 데이터를 다운로드 및 검증한다 - 트랜잭션을 실행한다 - 상태전이가 일어난다 - 영수증을 리턴한다 - 최신블록까지 동기화한다 Full synchronization
13. Full synchronization ࠶۾ ೻؊ … ౟ے੥࣌ 1 ౟ے੥࣌ 2 State … ৔ഐ: 100 KLAY ৔ࣼ: 200 KLAY ৠࣽ: 300 KLAY
14. Full synchronization ࠶۾ ೻؊ … ౟ے੥࣌ 1 ౟ے੥࣌ 2 State … ׮਍۽٘ ߂ Ѩૐ ৔ഐ: 100 KLAY ৔ࣼ: 200 KLAY ৠࣽ: 300 KLAY
15. Full synchronization ࠶۾ ೻؊ … ౟ے੥࣌ 1 ౟ے੥࣌ 2 State … ׮਍۽٘ ߂ Ѩૐ ৔ഐ: 100 KLAY ৔ࣼ: 200 KLAY ৠࣽ: 300 KLAY
16. Full synchronization ࠶۾ ೻؊ … ౟ے੥࣌ 1 ౟ے੥࣌ 2 State ৔ഐ: 200 KLAY ৔ࣼ: 200 KLAY ৠࣽ: 400 KLAY … प೯ ৔ࣻૐ 2 ৔ࣻૐ 1
17. Full synchronization ࠶۾ ೻؊ … ౟ے੥࣌ 1 ౟ے੥࣌ 2 State ৔ഐ: 200 KLAY ৔ࣼ: 200 KLAY ৠࣽ: 400 KLAY … ৔ࣻૐ 2 ৔ࣻૐ 1
18. Full synchronization State 1 ࠶۾ 1 ࠶۾ 2 ࠶۾ 3 ࠶۾ 4
19. Full synchronization State 1 ࠶۾ 1 ࠶۾ 2 ࠶۾ 3 ࠶۾ 4
20. Full synchronization State 1 ࠶۾ 1 ࠶۾ 2 ࠶۾ 3 ࠶۾ 4
21. Full synchronization State 1 ࠶۾ 1 ࠶۾ 2 ࠶۾ 3 ࠶۾ 4 State 2
22. Full synchronization State 1 ࠶۾ 1 ࠶۾ 2 ࠶۾ 3 ࠶۾ 4 State 2 State 3
23. Full synchronization State 1 ࠶۾ 1 ࠶۾ 2 ࠶۾ 3 ࠶۾ 4 State 2 State 3 State 4
24. Full synchronization State 1 ࠶۾ 1 ࠶۾ 2 ࠶۾ 3 ࠶۾ 4 State 2 State 3 State 4
25. - 헤더를 다운로드 및 검증한다 - 트랜잭션 데이터를 다운로드 및 검증한다 - 트랜잭션을 실행한다 (오래걸림) - 상태전이가 일어난다 - 영수증을 리턴한다 - 최신블록까지 동기화한다 Full synchronization
26. 블록동기화 Full Synchronization Fast Synchronization Snapshot Synchronization 결과 및 이슈
27. - 헤더를 다운로드 및 검증한다 - 트랜잭션 데이터를 다운로드 및 검증한다 - 특정블록까지 영수증 데이터를 다운로드한다 - 모든 상태 노드들을 다운로드한다 - Full 동기화로 전환 한다 - 최신블록까지 동기화한다 Fast synchronization
28. Full synchronization ࠶۾ ೻؊ … ౟ے੥࣌ 1 ౟ے੥࣌ 2 State ৔ഐ: 200 KLAY ৔ࣼ: 200 KLAY ৠࣽ: 400 KLAY … प೯ ߂ Ѩૐ ৔ࣻૐ 2 ৔ࣻૐ 1
29. Fast synchronization ࠶۾ ೻؊ … ౟ے੥࣌ 1 ౟ے੥࣌ 2 State ৔ഐ: 100 KLAY ৔ࣼ: 200 KLAY ৠࣽ: 300 KLAY … ৔ࣻૐ 2 ৔ࣻૐ 1 ׮਍۽٘
30. Fast synchronization ࠶۾ ೻؊ … ౟ے੥࣌ 1 ౟ے੥࣌ 2 State ৔ഐ: 200 KLAY ৔ࣼ: 200 KLAY ৠࣽ: 400 KLAY … ৔ࣻૐ 2 ৔ࣻૐ 1 ׮਍۽٘
31. Fast synchronization ࠶۾ 1 ࠶۾ 2 ࠶۾ 3 ࠶۾ 4
32. Fast synchronization ࠶۾ 1 ࠶۾ 2 ࠶۾ 3 ࠶۾ 4
33. Fast synchronization ࠶۾ 1 ࠶۾ 2 ࠶۾ 3 ࠶۾ 4
34. Fast synchronization ࠶۾ 1 ࠶۾ 2 ࠶۾ 3 ࠶۾ 4
35. Fast synchronization ࠶۾ 1 ࠶۾ 2 ࠶۾ 3 ࠶۾ 4 State 4
36. Fast synchronization ࠶۾ 1 ࠶۾ 2 ࠶۾ 3 ࠶۾ 4 State 4 pivot ࠶۾
37. Fast synchronization State State
38. Fast synchronization State State ׮਍۽٘
39. - 헤더를 다운로드 및 검증한다 - 트랜잭션 데이터를 다운로드 및 검증한다 - 특정블록까지 영수증 데이터를 다운로드한다 - 모든 상태 노드들을 다운로드한다 (오래걸림) - Full 동기화로 전환 한다 - 최신블록까지 동기화한다 Fast synchronization
40. 블록동기화 Full Synchronization Fast Synchronization Snapshot Synchronization 결과 및 이슈
41. - 헤더를 다운로드 및 검증한다 - 트랜잭션 데이터를 다운로드 및 검증한다 - 특정블록까지 영수증 데이터를 다운로드한다 - 모든 Leaf 노드들만 다운로드 한다 - 다운로드받은 Leaf 노드들로 로컬에서 트라이를 재구성한다 - Full 동기화로 전환 한다 - 최신블록까지 동기화한다 Snap synchronization
42. Fast synchronization State State ׮਍۽٘
43. Snap synchronization State ׮਍۽٘ State
44. Snap synchronization State State Trie ੤ҳࢿ State
45. - 기존 자료구조로 Account, Storage 데이터를 얻기 위해서 - 모든 Trie들을 순회하여 Leaf 노드에 도달해야 함 - O(log(n)) - LevelDB 읽기 성능이 굉장히 느림 - 이를 개선하기 위해서 새로운 데이터 레이어가 필요하다 State snapshot
46. - State snapshot 레이어 - 최신 블록(128개)들의 모든 Leaf 노드들을 저장 - Disk 레이어 (디스크) - 특정 State Trie의 모든 Leaf 노드들을 디스크에 Key/Value 형태로 저장한다 - O(log(n)) -> O(1) - Diff 레이어 (메모리) - 오직 특정 블록에서 바뀐 Leaf 노드들을 메모리에 저장한다 - 매 블록 처리할 때마다 하나의 레이어가 생성된다 - 128개이상의 Diff 레이어가 생기면, Disk 레이어로 머지한다 State snapshot
47. - State snapshot 레이어 - 최신 블록(128개)들의 모든 Leaf 노드들을 저장 - Disk 레이어 (디스크) - 특정 State Trie의 모든 Leaf 노드들을 디스크에 Key/Value 형태로 저장한다 - O(log(n)) -> O(1) - Diff 레이어 (메모리) - 오직 특정 블록에서 바뀐 Leaf 노드들을 메모리에 저장한다 - 매 블록 처리할 때마다 하나의 레이어가 생성된다 - 128개이상의 Diff 레이어가 생기면, Disk 레이어로 머지한다 State snapshot
48. - State snapshot 레이어 - 최신 블록(128개)들의 모든 Leaf 노드들을 저장 - Disk 레이어 (디스크) - 특정 State Trie의 모든 Leaf 노드들을 디스크에 Key/Value 형태로 저장한다 - O(log(n)) -> O(1) - Diff 레이어 (메모리) - 오직 특정 블록에서 바뀐 Leaf 노드들을 메모리에 저장한다 - 매 블록 처리할 때마다 하나의 레이어가 생성된다 - 128개이상의 Diff 레이어가 생기면, Disk 레이어로 머지한다 State snapshot
49. State snapshot ৠࣽ: 100KLAY ৔୍: 200KLAY ୍࢚: 300KLAY ৠࣽ: 200KLAY ৔୍: 300KLAY … ৠࣽ: 400KLAY 129 ୭न࠶۾ 1 ࠶۾ֈߡ 2 3 Diff ۨ੉য Disk ۨ੉য झշࢫ ۨ੉য
50. State snapshot ৠࣽ: 100KLAY ৔୍: 200KLAY ୍࢚: 300KLAY ৠࣽ: 200KLAY ৔୍: 300KLAY … ৠࣽ: 400KLAY 129 1 ࠶۾ֈߡ 2 3 Diff ۨ੉য Disk ۨ੉য झշࢫ ۨ੉য ৠࣽ: 500KLAY 130 ୭न࠶۾
51. State snapshot ৠࣽ: 200KLAY ৔୍: 200KLAY ୍࢚: 300KLAY ৠࣽ: 200KLAY ৔୍: 300KLAY … ৠࣽ: 400KLAY 129 2 ࠶۾ֈߡ 2 3 Diff ۨ੉য Disk ۨ੉য झշࢫ ۨ੉য ৠࣽ: 500KLAY 130 ୭न࠶۾
52. - 데이터 읽기 - 요청된 블록의 Diff 레이어부터 가장 오래된 Diff 레이어까지 순차적으로 데이터를 찾는다 - Diff 레이어에 존재하지 않는다면 Disk 레이어에서 찾는다 State snapshot
53. State snapshot ৠࣽ: 200KLAY ৔୍: 200KLAY ୍࢚: 300KLAY ৠࣽ: 200KLAY ৔୍: 300KLAY … ৠࣽ: 400KLAY 129 2 ࠶۾ֈߡ 2 3 Diff ۨ੉য Disk ۨ੉য झշࢫ ۨ੉য ৠࣽ: 500KLAY 130 ୭न࠶۾ ୭न ҅ઝ ੿ࠁ ઑഥ ৠࣽ ৔୍ ୍࢚
54. State snapshot ৠࣽ: 200KLAY ৔୍: 200KLAY ୍࢚: 300KLAY ৠࣽ: 200KLAY ৔୍: 300KLAY … ৠࣽ: 400KLAY 129 2 ࠶۾ֈߡ 2 3 Diff ۨ੉য Disk ۨ੉য झշࢫ ۨ੉য ৠࣽ: 500KLAY 130 ୭न࠶۾ 3ߣ ࠶۾੄ ҅ઝ ੿ࠁ ઑഥ ৠࣽ ৔୍ ୍࢚
55. State snapshot ৠࣽ: 200KLAY ৔୍: 200KLAY ୍࢚: 300KLAY ৠࣽ: 200KLAY ৔୍: 300KLAY … ৠࣽ: 400KLAY 129 2 ࠶۾ֈߡ 2 3 Diff ۨ੉য Disk ۨ੉য झշࢫ ۨ੉য ৠࣽ: 500KLAY 130 ୭न࠶۾ 1ߣ ࠶۾੄ ҅ઝ ੿ࠁ ઑഥ ࠛоמ
56. - State snapshot 동기화 - Trie 생성 외 다른 과정은 Fast Sync와 동일함 - 해시 범위 기반 요청 - 0x000…000 ~ 0xfff…fff - 스냅샷 데이터 검증 - 요청된 구간 내 첫번째 계좌와 마지막 계좌의 머클증명을 통한 검증 - State Trie 재구성 - 동적 피봇팅 - Heal 단계 Snap synchronization
57. - State snapshot 동기화 - Trie 생성 외 다른 과정은 Fast Sync와 동일함 - 해시 범위 기반 요청 - 0x000…000 ~ 0xfff…fff - 스냅샷 데이터 검증 - 요청된 구간 내 첫번째 계좌와 마지막 계좌의 머클증명을 통한 검증 - State Trie 재구성 - 동적 피봇팅 - Heal 단계 Snap synchronization
58. - State snapshot 동기화 - Trie 생성 외 다른 과정은 Fast Sync와 동일함 - 해시 범위 기반 요청 - 0x000…000 ~ 0xfff…fff - 스냅샷 데이터 검증 - 요청된 구간 내 첫번째 계좌와 마지막 계좌의 머클증명을 통한 검증 - State Trie 재구성 - 동적 피봇팅 - Heal 단계 Snap synchronization
59. - State snapshot 동기화 - Trie 생성 외 다른 과정은 Fast Sync와 동일함 - 해시 범위 기반 요청 - 0x000…000 ~ 0xfff…fff - 스냅샷 데이터 검증 - 요청된 구간 내 첫번째 계좌와 마지막 계좌의 머클증명을 통한 검증 - State Trie 재구성 - 동적 피봇팅 - Heal 단계 Snap synchronization
60. Snap synchronization (해시 범위 기반 요청) Peer 1 Peer 2 0x000…000 0xfff…fff 0x100…000 0x200…000 0x300…000 0x400…000 … Peer 3 Peer 4 root hash
61. Snap synchronization (스냅샷 데이터 검증) 0x000…000 Peer 1 0x100…000
62. Snap synchronization (스냅샷 데이터 검증) 0x000…000 Peer 1 0x100…000 root hash
63. Snap synchronization (스냅샷 데이터 검증) 0x000…000 Peer 1 0x100…000 root hash root hash !=
64. Snap synchronization (스냅샷 데이터 검증) 0x000…000 Peer 1 0x100…000 root hash
65. Snap synchronization (스냅샷 데이터 검증) 0x000…000 Peer 1 0x100…000 root hash root hash ==
66. Snap synchronization (State Trie 재구성) State ୭न࠶۾ Remote Local pivot झշࢫؘ੉ఠ ઓ੤ ҳр
67. Snap synchronization (State Trie 재구성) State ୭न࠶۾ Remote Local pivot झշࢫؘ੉ఠ ઓ੤ ҳр
68. Snap synchronization (State Trie 재구성) State ୭न࠶۾ Remote Local pivot State झշࢫؘ੉ఠ ઓ੤ ҳр
69. Snap synchronization (State Trie 재구성)
70. Snap synchronization (State Trie 재구성)
71. Snap synchronization (State Trie 재구성) ׮਍۽٘
72. Snap synchronization (State Trie 재구성)
73. 블록동기화 Full Synchronization Fast Synchronization Snapshot Synchronization 결과 및 이슈
74. 단계 설명 걸린 시간 Block 데이터 다운로드 헤더, 트랜잭션, 영수증데이터 등 다운로드 1-2일 State Sync Stage Snapshot 데이터 다운로드 및 Trie 생성 6시간 Heal Stage 수정해야할 State Trie Node 다운로드 4-5일 Snapshot Regeneration Trie 수정 후 snapshot 레이어 수정 2시간 Cypress 네트워크에서 약 96M 블록까지의 싱크를 기준으로함 - 아래와 같이 Heal Stage에서 가장 오래 시간이 소요되며 이를 개선 중 - Heal Stage에서 병목현상이 있음 결과 및 이슈
75. 이더리움 기준 파라미터 수정 - number of difflayers (128+) - pivoting block interval (64+) - hash spaces (16+) Klaytn에서는 블록동기화 이외에 노드의 chaindata의 압축버전을 URL을 통해서 제공하고 있음 이를 다운받고 압축해제 하는데 약 1-2일정도 소요됨 Heal stage 성능개선을 통해서 약 snap sync도 1-2일정도 소요될 것으로 예상됨 결과 및 이슈
76. 이더리움 기준 파라미터 수정 - number of difflayers (128+) - pivoting block interval (64+) - hash spaces (16+) Klaytn에서는 블록동기화 이외에 노드의 chaindata의 압축버전을 URL을 통해서 제공하고 있음 이를 다운받고 압축해제 하는데 약 1-2일정도 소요됨 Heal stage 성능개선을 통해서 약 snap sync도 1-2일정도 소요될 것으로 예상됨 결과 및 이슈
77. 클레이튼에 대해 더 잘 알고 싶다면? 크러스트 유니버스는 지금 채용 중!