프루닝

프로젝트도 끝나고 휴식으로 충전도좀 하고!! 

다시 기본적인 블록체인의 이론에대해 정리 해보는 시간을 가져보자

 

프루닝(Pruning)? 

경량화 기법으로, 인공 지능 분야에서 검색 모델을 학습한후에 불필요하거나 중요도가 낮은 노드 등을 제거하는 기술

 

이게 무슨말이냐면 

중요한건만 냅두고 불필요한건 삭제하자 이런말이다 

블록체인에서는 오래된 블록체인 데이터를 자동으로 삭제하는데 사용이된다 

 

대표적으로 비트코인과 이더리움에 대해 알아보자

 

- 비트코인

비트코인 노드는 블록체인의 사본을 보관하고 네트워크를 실행하는데 필요한 여러 태스크를 수행 하는데

많은 스토리지를 낭비하는 문제가 있다 

 

많은 스토리지?

비트코인은 300GB 이상을 차지하는 블록체인 DB가 있는데 2009년부터 지금까지 해당 네트워크가 중단된적이 없기떄문에 엄청난 데이터가 저장 되어 있다

 

비트코인의 문제점 : "블록체인 크기의 가속화된 성장"

이문제를 해결하기위해 비트코인팀은 Block file pruning이라는 bitconin core 0.11.0 version에 추가 

 

해당 기능을 탑재하면 다음과 같은 이점을 얻을수있습니다 

• Block pruning을 통해 작은 버전의 '풀 블록체인'을 실행 가능
• 참조할 가능성이 없는 불필요한 정보를 삭제 10GB 미만으로 추정
• prune mode 에서는 지갑을 실행하면 이전 트랜잭션과 오래된 체인 기록이 삭제되어 디스크 공간을 절약

 

  비트코인 네트워크는 모든 트랜잭션을 가지고있기에 오래된것부터 최신 것까지 전부 가지고있습니다 

하지만 블록을 실행하고 검증하는 데 중요한 것 은 블록 내 트랜잭션  내의 인/아웃풋의 사용 가능 여부 인데 

굳이 모든 트랜잭션을 저장하지않아도 된다

 

지금은 풀 블록체인을 다운로드하여 올바른지 확인하고 필요한 '최신 정보'만 복사한뒤 나머지는 버리게 됩니다.

저장한 블록체인은 풀 블록체인의 자식 트리(머클트리)이며, 원본 블록체인의 부분 복사본입니다.   

 

 

 

- 이더리움 

 

이더리움에서는 프루닝을 State Trie Pruning 라고 합니다

이게 뭐냐면 현재 상태를 Prefix tree 일종인 Modified Merkle Patricia Trie(MPT,상태전이 머클 확장 페트리샤 트리..) 로 저장을 합니다 

 

여기서 이더리움 상태는 Account 상태인데 key-value 구조로 저장합니다 

사용자가 늘어나면 당연 이더리움 어카운트가 계속 늘어나고 늘어나면 버거워지고 느려졌습니다 

이를 해소하기위해 이더리움이 추가 보안한 머클트리가 MPT 

 

MPT는 State Root의 Hash를 계산하기 위해 전체를 볼 필요가없습니다 수정된 브랜치의 Hash만 다시 계산하조 

그래서 root Hash를 빠르게 찾을수가있습니다 

 

State Trie Pruning

MPT는 새로 삽입되는 노드의 수를 최소화 하는데 

위 그림에서 Block N과 Block N+1 차이는 A의 오른쪽 자식값이 10 에서 20으로 변경된거 밖에없조?

이렇게 되면 변경된 값말고는 나머지는 그대로 사용이 가능하다는 말입니다 

그래서 MPT는 푸른색으로 그려진 3개의 노드만 새로 추가해서 위 그림처럼 구성하게 됩니다

 

그러면 갱신된 Block N+1은 붉은색이제 필요없으니 지워도 되겠조?

프루닝은 불필요한걸 제거하는 기술이니깐요 

하지만 지울수가 없다네요..ㅜㅜ

 

그이유는 이더리움은 블록의 Finality를 보장 하지 않아서 입니다

다른 말로는 Block N + 1  이 Block N으로 다시 Retract  될수도 있고 web3.js API 통해서 과거의 State에 접근하는것도 가능해야하기 떄문이조 그래서 현재 상태에서 안 쓰이는 노드를 바로 지울수는없습니다 ..

 

그렇다고 영원히 남겨둘수도없조... 현재 최신 State 크기의 이더리움은 약 25GB인데 과거 State 전부 저장하면 300GB 넘어갑니다 게다가 이 크기는 참여자가 많을수록 점점 늘어나겠조 그래서 현실적으로 전부 저장하는것 또한 힘듭니다 

 

결과적으로 이더리움은 과거의 State를 127개로 제한했고 그보다 오래된 State는 지울수있게 했습니다 

하지만 DB에 저장되어있는 과거 데이터를 찾아 지우는것도.. 쉬운건 아니조 .. 

 

 

이더리움 프루닝의 문제

 

앞서 말한 이유로 이더리움은 프루닝을 쉽게 사용하기가 어렵습니다 

그래서 제한적으로 적용하고있는데 Go-Ethereum 에서는 매우 한정적으로 STP하는데 

State Trie에 대해 캐시를 사용하고 이 캐시에만 저장된 노드에 대해서는 Pruning을 하고 DB에 저장된 노드는 Pruning을 하지 않는 방식입니다. 캐싱된 노드는 서버가 정상적으로 종료되거나, 생성된 지 128Block이 지났거나, 캐시 크기를 넘겼거나, 마지막으로 캐시된 노드가 DB에 저장된 지 5분이 지나면 DB에저장됩니다 즉 위 조건을 만족하기 전에는 Cache에서 삭제된 노드는 DB에 저장하지 않습니다.

 

그런데 생성된 지 5분이 지나지 않아서 삭제되는 노드는 그리 많지 않습니다. 따라서 대부분의 삭제됐어야 할 노드는 여전히 DB에 남아 있습니다. 이에 대해 이더리움에서는 State Pruning을 구현하는 것을 계속 시도하는데 STP가 실제로 구현 되기전에는 Fast Sync를 사용을 권장하고 있습니다.

 

다음은 세 과정을 거치면, 새 노드에서는 Fast Sync로 동기화된 상태까지의 Garbage Node 없이 유효한 노드만 관리할 수 있습니다.

1. 새 클라이언트를 생성

2. 기존 클라이언트에서 새 클라이언트로 Fast Sync를 받는다

3. 기존 클라이언트를 제거한다.

 

이렇게 보면 되게 좀? 이런 생각이 드는데 위험 부담이 있는 Garbage Collection을 구현하는 것보다는 안전하고 현실적인 해결책이라는걸 알아야합니다 

 

결과적으로 이더리움은 Garbage Collection이 구현되기 전까지는 계속 위와 같은 방식을 사용 할 수 밖에 없습니다..ㅠ