Utreexo 프로젝트 중간 보고

요약: 본 아티클에서는 100x Group이 지원하는 캘빈 김(Calvin Kim)이 Utreexo의 이점에 대한 여러 주장과 이러한 이점이 실현된 범위에 대하여 다루어 보고자 합니다. 캘빈은 Utreexo의 도입에 관한 최신 버전의 주요 진행상황을 전하였습니다. 다만, 일반 사용자가 Utreexo 기술을 접하기까지는 아직 상당한 양의 추가 작업이 필요한 점을 참고해주시기 바랍니다.

2020년 7월에 발표된 프로젝트 진행 상황에서 저희의 Utreexo 프로젝트가 앞으로 Utreexo 어큐뮬레이터를 현재 Go로 작성된 비트코인 구현 방식인 btcd에 도입할 것임을 언급한 바 있습니다. 이에 대하여 해당 도입 방식을 새롭게 연구 성과로 선보일 수 있음에 매우 기쁩니다. 이번 성과 발표에서는 “Compact State Node (CSN)”이라 하는 새로운 부분 삭제 모델을 입증해보고자 합니다.

2020년 4월에 발표된 “ELI5: Utreexo – 확장 솔루션“에서 저는 CSN의 여러 장점에 대하여 다음과 같이 주장하였습니다:

  1. 아주 적은 킬로바이트 내에서 hdd 에서 ssd와 같이 빠르게 동기화 되는 풀노드 모드.
  2. 최초 블록 다운로드 병렬화 허용.
  3. 컨센서스를 데이터베이스 실행으로부터 독립시킴으로써 비트코인의 보안 강화 (현재는 구글이 개발한 것이 사용되고 있음).
  4. Utreexo의 비트코인 도입과정에서 포크가 필요 없음.

현재 개발 단계에서 3번과 4번 주장은 현재 구현이 된 상태입니다. 1번 주장은 킬로바이트로 축소한 노드 크기가 비 Utreexo 데이터에 병목현상이 발생하게 됨으로써 부분적으로만 구현이 가능합니다. 2번 주장은 아직 개발 진행 중입니다.

3번 주장이 중요한 이유

컨센서스가 독립적으로 데이터베이스 실행이 되게끔 함으로써 비트코인의 보안 강화 (현재는 구글이 개발한 것이 사용되고 있음)

수 년 동안 비트코인의 보안을 향상을 위하여 비트코인이 보유하고 있는 외부 의존도를 제거하는 것에 중점을 두어 왔습니다. 외부 의존도는 비트코인 개발자들이 작성하지 않지만 비트코인 소프트웨어가 작동하기 위해 필요한 어떤 코드를 말합니다. 외부 의존도는 여러 보안이 필수적인 프로젝트에서는 최대한 피하는 편인데, 이는 버그의 원인이 될 수 있기 때문입니다. 이에 대한 리스크는 외부 의존도를 검토하고, 검토한 코드의 사본을 보관해 최소화할 수 있습니다. 하지만, 이러한 방법은 완벽하지 않고, 비트코인 개발자들이 직접 작성, 시험 및 검토한 코드를 보유하는 것보다 좋지 않습니다. 이러한 이유로 비트코인 개발자는 비트코인에서 여러 외부 의존도를 배제하고 있습니다. (예시: OpenSSH 코드 제거)

현재 가장 큰 외부 의존도는 미사용잔액 세트(Unspent Transaction Output set) 또는 UTXO 세트와 블록 인덱스가 보관된 데이터베이스입니다. 사용된 데이터베이스는 구글이 사용하며, 이를 “LevelDB”라고 합니다. 버그가 없는 LevelDB는 비트코인 보안에 매우 필수적입니다. 만약 LevelDB에 버그가 있다면, 이중지불이 되거나 의도하지 않는 포크 발생의 원인이 되기도 합니다. 실제로 2013년 버클리 DB(LevelDB 이전에 사용된 데이터베이스)가 비트코인 코어에 사용된 방식이 이전 비트코인 코어 노드가 블록 225430을 읽지 못하여서 의도하지 않은 포크가 발생하게 되는 버그가 발생한 적이 있었습니다.

(앞서 언급된 UTXO 세트는 현재 지불할 있는 전세계 모든 비트코인의 세트를 의미합니다. UTXO 세트는 비트코인 컨센서스의 일부와 직접적으로 연결되어 있기 때문에 비트코인 보안에 필수적이며, LevelDB 여기에서 제거하는 것은 비트코인 회복탄력성을 향상하는데 매우 도움이 것입니다.)

3 주장 실현

데이터베이스로부터 독립해야만 하는 이유는 UTXO 세트가 6천만 개 이상의 UTXO로 구성이 되어 있는데, 모든 UTXO가 계속해서 추적이 되어야 하고, 느린 액세스는 초기 블록 다운로드 속도를 저하시킬 수 있으므로 빠르게 액세스할 수 있어야만 하기 때문입니다. 데이터베이스는 많은 수의 작은 데이터가 빠르게 액세스 할 수 있어야 하는 경우에 종종 사용됩니다.

하지만 Utreexo CSN에서는 데이터베이스가 전혀 필요하지 않습니다. 대신 UTXO의 소비자(spender)가 UTXO 데이터와 해당 UTXO가 존재한다는 Utreexo 어큐뮬레이터 증명을 제출하게끔 하였습니다. 이를 통해 UTXO 세트를 Utreexo CSN 실행 시 유지해야하는 필요성을 제거하게 되었습니다. 또한, UTXO 세트를 유지할 필요가 없으므로, LevelDB를 비트코인 컨센서스의 다른 필수 섹션에서 제거할 수 있게 됩니다.

현재 블록 검증이 Utreexo CSN 블록 검증과 비교하여서 메인 체인을 확장할 때 어떻게 작동하는지를 다음 표를 통해 설명해보겠습니다:

현재 블록 검증 Utreexo CSN 블록 검증
1. 작업 증명 확인 1. 작업 증명 확인
2. 매 입력 시, UTXO  세트 (LevelDB) 내 존재하는 참조 출력값 확인 2. 블록 내 참조된 UTXO 각각이 Utreexo 어큐물레이터 증명 및 인증을 보유하였는 지 확인
3. 매 입력 시, 스크립트와 서명 검증 3. 모든 입력에 대한 스크립트와 서명 검증

여기에서의 차이점은 Utreexo CSN 블록 검증에 대한 데이터베이스 액세스가 없다는 입니다. 대신, Utreexo 증명 검증을 사용합니다.

코드 변경은 블록 검증 기능이 동일하게 유지된다는 것을 고려했을 , 상당히 미미한 사항이었습니다. 어큐뮬레이터 증명을 확인한 , 현재 검증된 UTXO 데이터 (블록 검증 필요) UtxoViewpoint(비트코인 코어 CCoinsView 있음) 하는 현재의 UTXO 세트 캐시 구조로 변환되고, 이후 기존 검증 기능 진행되게 됩니다.

4번 주장이 중요한 이유

Utreexo 비트코인 도입 과정에서 포크가 필요 없음

새로운 기능을 위해 포크가 필요하다는 것은 비트코인과 같은 탈중앙화 시스템에서는 큰 리스크/도전 과제 입니다. 비트코인의 하드포크는 대부분 불가능한데, 이는 새로운 기능을 활성화하기 위한 이점이 체인 분리에 대한 가능성 보다 못하기 때문입니다. 소프트 포크 역시 상당 규모의 커뮤니티 동의가 필요하기 때문에 롤아웃하기 매우 어렵습니다.

반면, 만약 새로운 기능이 포크 없이 옵트인이 가능하다면, 이와 같은 기능 배치가 훨씬 더 단순해질 수 있습니다. BIP-152: 신규 블록 데이터 릴레이는 광범위하게 적용되고 포크가 필요 없는 기능의 대표적인 예입니다. 신규 블록 데이터에 옵트인된 노드는 이와 같은 방법을 선택할 수 있으며, 이 기능이 옵트인 되었기 때문에 이 기능을 사용하지 않는 사람에게는 어떤 변화도 발생시키지 않습니다.

4 주장 방법

4번 주장은 실현하기 가장 쉽습니다. 왜냐하면 태지 드리자(Tadge Dryja)가 Utreexo 논문을 최초로 작성했을 때 해결이 되었기 때문입니다. 저희는 새로운 Utreexo 노드와 현재 비트코인 노드를 연결하는 브릿지 노드라고 불리는 전환 노드를 보유함으로써 소프트 포크를 방지하고 있습니다.

브릿지 노드는 비 Utreexo 노드가 브릿지 노드에 연결될 때, 현재 비트코인 풀노드와 동일한 역할을 합니다. 하지만, Utreexo 노드가 브릿지 노드에 연결이 될 때, 정상 블록 상단에서 Utreexo 증명을 수행합니다. Utreexo 노드가 아닌 노드로 작동을 하는 것 입니다.

발표된 아티클에 언급된 바와 같이, 제공된 Utreexo 바이너리는 비트코인 테스트넷 네트워크의 방해를 피하기 위하여 작동시킨 브릿지 노드에”만” 연결하기 위하여 하드코딩 되었습니다.

1 주장이 중요한 이유

아주 적은 킬로바이트 내에서 hdd에서 ssd 같이 빠르게 동기화 되는 풀노드 모드

앞서 언급된 UTXO 세트는 풀노드를 작동하기 위하여 필수적인 부분입니다. 하지만, 이를 적용하는 경우가 증가하고 비트코인 유통량이 점점 정교 수량으로 나누어지면서, 해당 UTXO 세트는 크기가 커지게 됩니다. 현재, UTXO 세트의 크기 4GB이지만, 낮은 가격의 기기에서는 크기가 통제하기 힘들 정도로 커질 있습니다. 해당 UTXO 세트를 작은 사이즈로 만드는 것은 비트코인이 광범위하게 적용될 경우 매우 필수적인 사항입니다.

현재 비트코인 노드에서 UTXO 중 하나가 블록 내에서 참조가 될 때, 해당 노드가 디스크 또는 메모리 내 캐시에서 그 UTXO를 호출해야 합니다. 이것이 만약 노드가 느린 속도의 디스크를 보유하고 있을 때, 현재의 비트코인 내 병목현상이 발생하는 상황 중 하나이기도 합니다. 해당 블록이 부분 삭제될 때 캐시된 UTXO가 디스크에 작성되면서, 부분 삭제 노드와 함께 더 많은 제약 사항이 되게 됩니다. 이는 결국 비트코인 개발자 피터 우일(Pieter Wuille)이 여기에 언급한 바와 같이 부분 삭제된 노드가 부분 삭제되지 않은 노드와 대조적으로 동기화 되기 위해 더 느려지게 됩니다.

Utreexo CSN의 경우에는 UTXO 세트에 대한 디스크를 읽지 않기 때문에 속도가 느려지지 않습니다. 이를 통해 Utreexo CSN이 nvme ssd이든 hdd이든지 어떤 용량에서도 동일하게 작동을 하게 됩니다.

1 주장에 대한 현재 개발 진행

아주 적은 킬로바이트 에서의 풀노드 모드 대한 주장은 블록헤더를 포함하여 다른 메타데이터처럼 성공적으로 실현이 되지 않았고, 수백 메가바이트를 차지 했었습니다. chainstate 매우 작더라도,아주 적은 킬로바이트 내에서 풀노드라는 목표를 성취하기에는 다른 데이터가 무시해도 정도가 됩니다. 이번 개발 성과 발표에서 개발팀은 수백 메가바이트에 만족하였습니다.

비트코인 코어의 chainstates 자체와 비교했을 , 이러한 성과는 다음과 같이 설명할 있습니다:

보시는 바와 같이 Utreexo CSN의 chainstate 크기는 겨우 424 바이트이고, 노드가 차지하는 전제 크기에 대하여 라운딩 오차가 발생하게 됩니다. 사실, 재시작 시, 알려진 피어에 재접속할 때 사용되는 peers.json 파일은 205 킬로바이트로, 해당 chainstate 보다 약 483배 큽니다.

NVMe SSD와 HDD를 사용했을 때, 부분 삭제된 비트코인 코어와 Utreexo csn의 성능 차이는 다음 그래프와 같습니다.

이 테스트는 별도의 NVMe SSD를 읽 있는 다른 로컬 Utreexo 브릿지 노드에 벤치마킹 된 노드를 지정하여서 진행되었습니다. 블록 1,864,000의 디폴트 testnet3 assumevalid는 비트코인 코어에서 사용이 되었습니다. CNS에서는 assumevalid가 실행되었고, 블록 1,864,000로 설정이 되었습니다. 본 테스트는 testnet3 상에서 블록 높이 최대 1,906,000인 환경에서 진행되었습니다.

사용된 하드웨어 정보:

  • CPU: AMD Ryzen 3600
  • 메모리: 삼성 32GB DDR4 2666MHz
  • 로컬 서빙 노드 NVMe 드라이브: 2TB Sandisk ULTRA M.2 NVMe
  • 테스트 노드 NVMe 드라이브: 1TB HP SSD EX950 M.2
  • 테스트 노드 HDD: Western Digital WD10EZEX-22BN5A0 1TB 7200RPM

비트코어 노드에 배정된 플래그:

  • -prune=550
  • -connect=127.0.0.1
  • -disablewallet
  • -blocksonly
  • -testnet

비트코인 코어에서 NVMe SSD에서 실행할 때에는 784초가 소요된 반면, HDD에서는 1,066초가 소요되었씁니다. Utreexo CSN의 경우, NVMe SSD에서 실행할 때에는 1,643초가 소요된 반면, HDD에서는 1,700초가 소요되었습니다.

현재 Utreexo CSN 도입에 대하여 다수의 성능 최적화가 여전히 진행되고 있습니다. 비트코인 코어보다 노드가 훨씬 느린 btcd에서 포크를 했기 때문에 현재로서는 비트코인 코어보다 느립니다. 개발 상황 업데이트에 대하여 추후 발표할 예정이며, 해당 업데이트는 성능 개선에 중점을 두고 진행할 예정입니다.

2번 주장이 중요한 이유

최초 블록 다운로드의 병렬화 허용

혼선을 피하기 위하여, 여기에서 언급한 병렬화 체인 레벨에서의 병렬화를 적용합니다. 이는 단일 노드가 100,001~200,000 200,001~300,000 같이 다수의 블록 범위를 동시에 검증할 것임을 의미할 있습니다. 여기에서 제시한 주장은 (btcd 비트코인 코어에서 이미 실행되었기 때문에) 블록 트랜잭션 서명들이 병렬적으로 검증되는 블록 레벨 병렬화를 적용하지 않습니다.

전산 병렬화  다수의 프로세스를 동시에 실행하는 것을 지칭합니다. 이를 통해 사용가능한 하드웨어(CPU) 많이 사용할 있게 되고, 가동되지 않는 하드웨어가 있다면 성능을 향상시킬 수도 있습니다. 최근 년사이, CPU 개선은 물리적 제한 때문에 시계 속도 증가에 문제를 일으켜왔었습니다. 결과적으로, 시계 속도를 증가시키는 대신, 코어의 숫자를 향상시키는데 중점을 두어 왔습니다. 소프트웨어 개발 패러다임이 뒤를 이었고, 오늘날에는 많은 CPU 코어의 장점을 활용하기 위한 노력의 일환으로 병렬화의 중요성이 점점 커지고 있습니다.

최초 블록 다운로드의 병렬화는 풀노드를 동기화하는데 소요되는 시간 면에서 개인이 풀노드를 더 쉽게 작동할 수 있게 하면서, 게임체인저가 될 수 있는 상당한 가능성을 가지고 있습니다. 더 많은 노드는 비트코인 네트워크가 공격으로부터 더 회복 탄력성을 갖을 수 있게 만들 것 입니다. 이러한 맥락에서 병렬화는 비트코인의 보안성을 높인다고 볼 수 있습니다.

2 주장에 대한 현재 개발 진행 상황

어떤 블록을 검증하는 것은 이전 블록의 UTXO 세트에 달려 있습니다. 예를 들어 만약 블록 501 검증할 , 블록 500 UTXO 세트가 필요합니다. 하지만, UTXO 세트를 블록 500 보유하기 위해서, 블록 499 UTXO 세트가 필요하게 됩니다. 이전 블록의 UTXO 세트에 의존하는 것은 (하드코딩 ) 제네시스 블록에서부터 문제가 시작됩니다. 이러한 이유로 체인 레벨 병렬화에서의 어려움이 발생하게 됩니다.

Utreexo 적용하면 이러한 문제들이 훨씬 쉽게 해결됩니다. 왜냐하면 UTXO 세트가 기가바이트 단위가 아닌 바이트이기 때문입니다. 이러한 이유로 개발팀은 병렬검증에 대한 시작점으로서 전체 UTXO 세트 표현 전체를 소프트웨어로 하드코딩 하게끔 하였습니다.

피어가 악의적일 수 있고 허위 UTXO 세트를 제공할 수 있습니다. 하지만, 제네시스 블록으로부터 블록 높이 499 까지 검증할 때 사용하는 CPU 코어가 모두 다르기 때문에, 이러한 우려가 보안에 대한 전제조건을 낮추지는 못합니다. 개발팀은 블록 501부터 계속해서 검증하면서, 이러한 CPU 코어가 반면에 작동하지 않을 수 있다는 사실에 대한 장점을 활용하고 있습니다. 제네시스 블록부터 블록 높이 499까지의 검증이 완료되었을 때, 블록 높이 500의 블록과 UTXO 세트가 일치하는지를 보기 위하여 블록을 확인할 수 있습니다. 이를 통해 하드코딩 된 UTXO 세트 표현만이 힌트로 사용되어서, 더 빠른 처리가 가능하게끔 하며, 여전히 모든 것을 검증할 수 있습니다.

이러한 타입의 체인 레벨 병렬화를 지원하기 위하여, 코드베이스는 반드시 다수의 활성화된 chainstate 가지고 있어야만 합니다. chainstate 임의 n 숫자 하나 (또는 ) 갖을 어려움 점은 UTXO 세트의 n 숫자를 계속해서 추적해야 한다는 입니다. 하나의 UTXO 세트가 하나의 데이터베이스와 속도를 높이기 위한 목적으로 디스크 상의 UTXO 세트에 대한 하나의 캐시를 필요로 하기 때문에, 노드를 운영할 하드웨어 요구사항이 훨씬 높아집니다. 하지만, Utreexo CSN UTXO 세트를 보관하는 데이터베이스를 없애기 때문에, 이것은 문제가 되지 않습니다.

다수의 chainstate (비트코인 코어 CChainState, btcd에서의 Blockchain 타입) 도입하는 것은 이미 진행 중입니다. chainstate 단일의 데이터베이스를 보유할 필요가 없기 때문에 이러한 작업은 Utreexo CSN 광범위하게 단순화되었습니다. 이를 통해 chainstate 어떤 n 숫자든 실행할 있게끔 됩니다.

현재 개발팀은 네트워크 p2p 메시지가 chainstate 별로 어떻게 처리되는지에 대하여 계속해서 개발 입니다. 다른 방법( 개의 최초 블록 다운로드 매니저를 보유하는 , 어떤 블록이 어떤 chainstate 요구하는지를 계속 추적하는 ) 계속해서 찾고 지만, 아직 길이 상황입니다.

이번 릴리즈의 한계점

이번에 개발된 릴리즈에서는 체인 재구성과 멤풀를 지원하지 않고 있습니다. 그렇기 때문에 노드가 blocksonly모드에서 작동이 되고, 만약 reorg 발생한다면 노드가 충돌하게 됩니다. 가지 사항 아직 Utreexo 라이브러리에 적용이 되지 않았고, 이번 릴리즈가 데모 형식으로만 진행된 이유이기도 합니다. 개발팀은 비트코인 메인넷에 이번 릴리즈를 지원하지 않으며, 아직 알려진 버그가 매우 적기 때문에 실제 돈과 관련하여서 사용되어서도 안됩니다.

앞으로 개발 진행 사항

1 주장에 대한 현재 개발 진행 상황에서 언급한 바와 같이, Utreexo CSN 대한 성능 최적화를 진행할 예정입니다. 이는 Utreexo 어큐뮬레이터와 btcd 컴포넌트 모두 속도를 빠르게 하는 것을 포함합니다. 여러 버그가 수정이 되는 즉시 CSN 속도를 증가시키는 여러 이슈들을 인지하고 있습니다. (그저 실행과 테스트의 문제일 뿐입니다.)

재구성 지원을 실행하는 작업은 작년부터 시작을 하였고, 우선 해결해야 하는 여러 이슈가 있는 관계로 아직 진행 보류 중인 상태입니다. Reorg 빠른 시일 내에 도입일 예정입니다. 멤풀 지원 작업이 아직 시작되지 않았지만, 이것을 당분간 어떻게 도입할지에 대해서는 계획을 세우고 있습니다. 멤풀 지원은 올해 도입될 것이라고 매우 긍정적으로 말씀드릴 있습니다.

현재 Utreexo 어큐뮬레이터 코드는 Go 언어로 작성되었습니다. 어큐뮬레이터 코드를 Rust와 C++로 포팅하는 것은 아직 진행 중입니다. 이 개발 사항이 얼마나 걸릴지 정확하게 말씀드릴 수는 없지만, 토대를 가지고 해당 작업을 진행 중이며, 인간 수준의 병렬성은 매우 취약할 수 있습니다. 만약 많은 사람들이 이바지를 하고 싶다면 참여할 수 있는 방법은 아주 여러가지입니다!