[KIP-111] statedb pruning draft #112
Conversation
|
CLA Assistant Lite bot: I have read the CLA Document and I hereby sign the CLA You can retrigger this bot by commenting recheck in this Pull Request |
|
|
||
| ## Motivation | ||
| <!--The motivation is critical for KIPs that want to change the Klaytn protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the KIP solves. KIP submissions without sufficient motivation may be rejected outright.--> | ||
|
|
There was a problem hiding this comment.
기존의 pruning 기술과 비교하여 무중단, 자동화의 의미 설명과 강조 필요
|
|
||
| <!-- 이러한 특징으로 인해 과거 블럭의 trie node와 최신 블럭의 trie node가 동일한 trie node를 참조하게 되고, 그로 인해 reference count control이 어려워져 삭제가능한 trie node를 찾기 어려운 문제가 발생한다. StateDB는 trie구조로 되어 있으며, 매 블록이 생성될때마다 최소 5-6개에서 많게는 수만개의 trie-node가 새롭게 생성되고, 새롭게 생성된 개수만큼의 trie-node가 과거 데이터를 저장하는 trie-node로 변하게 된다. 이러한 이유로 Blockchain의 데이터는 꾸준히 증가만 하게 되고, 스토리지 측면에서 지속적으로 용량이 증가만 하게 된다. 블록체인에서 과거데이터도 중요하지만, 최신 데이터 만큼의 활용도나 중요도가 높은 것은 아니다. --> | ||
|
|
||
| ## Specification |
There was a problem hiding this comment.
도입된 exthash 부분 외에 어떻게 이를 활용하여 pruning을 하는지에 대한 자세한 설명 필요. 변경된 trie 구조가 어떻게 형성되는지와 삭제되는지 등
|
|
||
|
|
||
|
|
||
| ## Expected Effect |
There was a problem hiding this comment.
용량과 관련된 trade-off 도 언급해야할 거 같아요. 중복이 없기에 단일 state trie의 용량은 증가하지만, 시간이 지나더라도 state data 의 크기 증가 속도는 많이 줄어든다. 그리고, Klaytn 메인넷 기준으로는 중복된 노드가 약 n% 라서 예상되는 이득은 어느정도이다,.
There was a problem hiding this comment.
관련 내용 추가 했으며, 관련 내용으로 미디엄 문서를 추가하기 위해 실험 cypress, baobob기준으로 테스트 노드 실행 중.
KIPs/kip-111.md
Outdated
| ExtHashNonce를 6 byte로 정할 경우 초당 15000개 이상의 trie-node가 업데이트되면 count 역전현상이 일어날 수 있고, 시스템이 재부팅 되면 ExtHashNonce는 충돌이 날 수 있다. ExtHashNonce가 7 byte 가 되면 초당 390만개 이상의 trie-node가 업데이트 되어야 하기때문에 충분히 여유로운 숫자이다. | ||
|
|
||
|
|
||
| OR |
There was a problem hiding this comment.
대략적으로 아래와 같은 논리 고려할 수 있을 듯
방식이 안전하기 위한 조건
- timestamp 의 실제 시간이 증가되는 속도보다 counter 증가 속도가 낮아야한다.
초당 업데이트 수 ~~
다시 껏다 켯을 때... - Nonce 크기 자체가 가지는 충돌 저항성
위 조건 하에서 nonce가 증가하는 속도는 실제 시간 증가속도보다 낮다.
그렇다면, 실제로 nonce 가 증가하여 (한 바퀴 돌아서) 충돌값에 도달하는 시간은 실제 시간 증가 속도 보다 더 길다. 따라서, 지금 6바이트 사이즈에서 충돌이 발생하려면 ~ 년이 걸리고, nonce 의 증가속도는 항상 이보다 적으므로 ~년 이상 걸린다.
There was a problem hiding this comment.
"The reason for adding 7 bytes" 섹션으로 관련 내용 추가함
KIPs/kip-111.md
Outdated
|
|
||
| ExtHash is a hash with 7 bytes added to the original hash. This changes the Root Hash value when calculating the hash of MPT (Merkle Patricia Trie). This can cause a collision with nodes (servers) or past versions of the hash that do not use ExtHash. To solve this problem, when calculating the hash of MPT, you can get the same result as before by removing the last 7 bytes from ExtHash and calculating it. In this section, we will describe the process of getting the MPT Root Hash using the original Hash by changing ExtHash to Hash. | ||
|
|
||
| #### ExtHash에서 기존Hash 얻기 - step by step |
There was a problem hiding this comment.
순서도와 설명, pseudo code, 결과 예시를 추가
KIPs/kip-111.md
Outdated
| * statedb pruning을 사용하는 Server Node에서는 39byte Hash를 사용한다. | ||
| ``` | ||
| ref_32 = 32 byte - Hash | ||
| ref_39 = 39 byte - ExtHash |
There was a problem hiding this comment.
ExtHash = Hash | ExtHashNonce right ? instead of ExtHash = ExtHashNonce | Hash
(|: concat)
There was a problem hiding this comment.
add comment to
ref_32 = 32 byte - Hash
ref_39 = 39 byte - ExtHash = Hash(32 byte) + ExtHashNonce(7 byte)
The proposal for the implementation of StateDB Pruning.
References will be added later.