최근 클레이튼 코어 개발팀이 작성한 How to Efficiently Process and Manage Blockchain Data 관련 질문이 있습니다.
해당 글에서는 기존 프루닝 방식의 한계점에 대해 다음과 같이 서술하고 있습니다.
(…) MPT와 같은 데이터 구조가 노드 간에 공유된 중첩 데이터를 사용한다는 점입니다. 즉, 노드 A가 노드 B와 동일한 데이터를 참조할 수 있으며, 이러한 경우 노드 B를 무심코 삭제하면 노드 A에 복구 불가능한 데이터 손실과 손상이 발생할 수 있습니다. 다중 참조 데이터 관리의 이러한 어려움은 지금까지 효율적인 온라인 가지치기를 방해해왔습니다.
Exthash를 도입하면서 위와같은 문제를 해결할 수 있었다고 되어 있는데요, 여기서 질문이 있습니다.
- Exthash를 도입하면서 동일한 데이터에 대해 참조하는 링크가 노드에 따라 고유한 값으로 바뀌었다고 했는데요, 고유한 링크여도 동일한 데이터를 참조하고 있으므로 해당 링크를 삭제했을 때 원본 데이터가 삭제되는 문제는 없나요?
- 만약 링크만 삭제되는 거라면 기존에 문제점이라고 서술해주신 부분이 왜 문제가 되는지 잘 이해가 되지 않습니다. 동일한 참조 링크여도 삭제했을 때 원본 데이터가 삭제되지 않는 것이면 큰 문제가 안될 것 같거든요.
위 질문 관련해서 추가 설명 부탁드려도 될까요?
답변을 드리기전 Exthash가 어떻게 동작하고 저장하는지를 그림과 설명으로 작성한 문서가 있어 첨부 합니다.
참조 문서 : StateDB Live Pruning: 블록체인 데이터 용량의 효율적 관리
질문에 답변을 드리면,
“Exthash를 도입하면서 동일한 데이터에 대해 참조하는 링크가 노드에 따라 고유한 값으로 바뀌었다고 했는데” 이렇게 생각하신 부분에서 오해가 생긴 듯 합니다.
Exthash는 링크가 아니고 key/value store의 key입니다.
현재 Klaytn의 MPT를 저장하는 스토리지는 LevelDB로 Key/Value store 입니다.
Exthash를 도입하기전 MPT의 데이터는 key - 32byte로 되어 있었으며, value를 keccak256으로 hash한 값이 key로 사용되었습니다. 따라서 value가 같으면 key가 동일하고 key가 동일 하기 때문에 LevelDB에서 1개의 key로 value가 관리 됩니다.
하지만 Exthash를 쓰게 되면 이때 MPT의 데이터는 key - 32byte + 7byte( index - incremental count )로 7바이트를 추가로 사용합니다. LevelDB에 저장 할 때마다 1씩 증가하는 incremental count용 7바이트가 추가 되어 key는 총 39byte를 사용하게 되고 value가 같더라도 Exthash의 앞 부분 32바이트는 동일하지만 뒤 7바이트가 중복될 수는 없습니다. 따라서 Exthash는 중복되지 않으며, LevelDB에 저장될 때도 다른 key로 저장되기 때문에 value가 같더라도 다른 Key로 관리되어 중복을 걱정하지 않고 언제든 삭제가 가능합니다.
참고로 key가 32바이트에서 39바이트로 증가했기 때문에 22%정도 용량이 증가할 요인이 발생합니다.
그리고 key의 중복이 없기 때문에 데이터를 따로 저장하면서 DB용량이 늘어날 수 있지만, 저희가 데이터를 분석해 본 결과는 key가 중복될 확률이 2% 내외 이기 때문에 DB용량을 크게 증가 시키지는 않습니다.
실제로 기존의 off line으로 진행하던 pruning과 live pruning과의 LevelDB 용량 차이는 25% 이내 입니다.
1개의 좋아요
@ethan_kr
상세한 답변 감사합니다.
중복 상황에서 key value가 한 번 더 저장되면서 용량이 크게 증가하지 않을까 싶었는데, 그런 상황 자체가 많이 발생하지는 않는군요.
덕분에 잘 이해한 것 같습니다. 