[Savant DAO — 1편] 블록체인 데이터 서비스
TL;DR
- 현존하는 블록체인 데이터 서비스들이 제공하는 기능 대부분은 OLAP
- 대부분의 use-cases가 분석용이라면 + insert가 매우 느리고, delete도 없는 블록체인 특성상 데이터 서비스가 RDB를 사용할 경우 column storage에 데이터를 저장하는 것이 효율적일 것
Dune, Nansen, The Graph, Nakji 등 블록체인 데이터 서비스들이 작년 가을부터 올해 초까지 큰 규모의 투자유치를 성공하며 메인넷 데이터에 대한 분석에 대한 시장의 needs가 크다는 것을 보여주고 있다. 각 회사마다 내새우는 주된 차별점은 다르겠지만 이들의 “블록체인 데이터 분석” 기능의 현재는 어떤지, 왜 그런지, 성능개선을 위해 어떤 점을 바꾸면 좋을지 (+ 사업적인 room이 있을지) 공부하기 위해 이 글을 썼다. 글은 아래와 같이 구성되어 있다.
a.전통적 RDBMS: Row storage와 Column storage
b. 블록체인 데이터 서비스에 대한 간단 요약 (Operations & use-cases 중심)
c. 개인적인 생각
a. RDBMS: Row storage 와 Column storage
데이터베이스, 그 중 관계형 데이터베이스는 크게 row storage와 column storage로 분류할 수 있다. 둘은 태생부터 목적이 다르기에 데이터를 저장하는 방식 및 operation에 따른 성능 또한 많이 다른데, 본론에 들어가기 앞서 그 둘의 구조 및 장단점을 간단하게 살펴보고 블록체인 데이터 서비스로 넘어가도록 하자.
데이터를 저장하는 방식이 다르기때문에, row storage 의 경우 데이터에 대한 insert/delete 등이 빈번하게 발생하는 시나리오에서 빠르게 동작하는 한편, column storage 의 경우 데이터의 분석이 빈번하게 발생하는 시나리오에 대해 빠르게 동작한다.
지갑주소와 각 지갑의 잔액 정보만을 담은 테이블이 있다고 생각해보자. 이 테이블의 데이터를 실제로 disk 혹은 memory에 저장할 때, row storage의 경우 한 ‘row’의 데이터, 즉 하나의 통짜 데이터를 연속해서 저장하는 반면, column storage는 한 ‘column’의 데이터, 즉 아래의 예시에서는 ‘지갑 주소’, ‘잔액’ 등 과 같은 정보를 연속해서 저장한다.
잔액 평균을 구하고자 할 때 컴퓨터가 동작하는 방식은 대략 아래와 같다.
Row Storage
1) row1에 가서, 해당 계정의 balance 값을 찾고
2) row2에 가서, 해당 계정의 balance 값을 찾고
3) row3에 가서, 해당 계정의 balance 값을 찾고
4) 앞서 찾은 세 값을 더한 후 평균을 구함Column Storage
1) Balance가 담긴 첫 위치로 가서
2) 순서대로 값들을 더한 후 평균을 구함
이와 별개로, column storage 의 경우 데이터 타입에 따라 dictionary encoding 등의 압축기법을 활용하여 데이터를 엄청나게 압축할 수도 있다.
b. 블록체인 데이터 서비스들에 대한 간단 요약
- Target Network
-이더리움, Solana, Polygon 등 EVM 계열 네트워크는 대부분 지원
2. 주 Operation
- Scan
- real-time coin price / gas price
- 사실 가격의 경우 메인넷 데이터는 아니지만 대부분 궁금해하는/필요로 하는 정보라 같이 제공을 하는 것 같음
- 시간 단위 Median/Max/Min 등 aggregation 포함인 것도 있음
- latest block, txs - Count (per 1H, 3H, 1day, 1week, …)
- 공개된 대부분의 기능이 Count에 집중돼있음 (Sorting을 포함해서)
- e.g. #tx, #active address, #user by entity, #tx by smart contract, TPS, … - Filter
- 기본적인 hash filter 에는 대부분 거의 유료 서비스 (The Graph 제외)
3. 주된 Use-case
- 고래 지갑 tracking
- Gas Tracker
- NFT Tracker
- DeFi/GameFi 프로젝트 Tracker
- 데이터 API (유료 서비스 구독자는 주로 크립토 퀀트?)
c. 개인적인 생각
현재 각 서비스들에서 유료버전을 사용하지 않고 사용할 수 있는 기능의 대부분은 Scan / Filter / Aggregation 정도 Operation인 것으로 확인된다. (Dune에서 Join 쿼리를 실행시킬 수는 있지만 너무 느려 그 결과물을 보기가 힘들었다) 이는 아마도 1) 사용자에게 필요한 대부분의 기능이 Join 보다는 앞서 말한 Operation을 빠르게 하는 것에 있기에 Join등의 복잡한 쿼리가 필요 없을 수도 있고 혹은 2) 아직까지 블록체인 데이터 서비스의 기술 스택이 복잡한 작업을 처리하기에는 한계가 있을 수 있다.
실제로 Dune은 백엔드 DB로 오픈소스 관계형 데이터베이스인 PostgreSQL 을 사용한다고 공개하였는데 PostgreSQL에서 기본적으로 제공하는 빌트인 타입에 256 bit 데이터 타입은 존재하지 않는다. (당연히 byte 타입은 존재하나, byte type에 대한 aggregation filter 등이 얼마나 잘 동작할까?) 아마도 기존 서비스들은 byte type 으로 데이터를 저장하고 그 위에 별도의 인덱스를 달아서 어느정도 쿼리가 가능하게 하지 않았을까 싶다.
글을 준비하며 크립토 트레이딩 등 관련 회사를 다니는 지인 몇에게 Nansen, Dune 등에 대한 블록체인 데이터 서비스와 관련하여 물어본 적이 있다. 회사마다 차이는 있겠지만 실제로 사용하는 혹은 사용하고자 하는 방식에 따르면 앞서 말한대로 사용자가 복잡한 쿼리를 필요로 하지 않기때문에 (+아마도 기술적인 어려움도 있어서!) 기존 회사들이 앞서 소개한 Operation의 최적화 및 임베디드 그래프 등의 작업에 집중하고 있을 것 같기도 하다.
- 메인넷 데이터를 트레이딩에 사용하지 않고 올해 들어 내부적 needs가 생겨 리서치 중
- 고래 관련 지표, 특정 지갑 (e.g. 거래소)의 유통량이 어떻게 되는지, 알트 코인 대상 여러 지표들 추적, 대시보드 개발용
- NFT 마켓플레이스와 관련된 데이터를 추적하는데 사용 (User, Revenue 등 온체인 메트릭)
만약 실제로 사용자들의 주된 needs가 1 (Join보다는 기본적인 분석을 빠르게 하는 것) 에 있다면 delete가 없고 insert 가 매우 적은 (상대적으로) 블록체인 특성상 row storage base인 PostgreSQL 보다는 columnar storage RDB를 사용하면 큰 성능 향상을 낼 수 있을 것으로 생각된다. (조사할 땐 별 생각을 못했는데, 글로 정리하다보니 빠른 프로토타이핑을 위하여 오픈소스 RDB인 PostgreSQL로 시작은 했지만 지금은 여러가지 시도를 준비하고 있을 수 있다는 생각도 든다)
역사적으로 필요에 의해 기술이 혁신되기도 하지만, 기술의 혁신에 따라 새로운 필요가 생기고 새로운 시장이 개척되기도 하였다. 블록체인 데이터 서비스가 지금 제공하는 기능의 Performance 최적화에 그치지 않고, 새로운 혁신을 일으켜 앞으로 태동할 많은 DeFi 프로젝트들의 성장을 돕는 발판이 되길 바란다.
