온체인 데이터 실전 분석

Published in

Decipher Media ｜디사이퍼 미디어

45 min readMar 5, 2024

Disclaimer: 본 글은 서울대학교 블록체인 학회 디사이퍼(Decipher)의 Weekly Session에서 온체인 데이터 실전 분석을 주제로 발표한 내용을 기반으로 작성되었습니다. 해당 글은 온체인 데이터 분석의 전반적인 내용을 바탕으로 작성자의 주관적인 의견을 포함하여 작성하였으며, 본 글에 포함된 어떠한 내용도 투자 조언이 아님을 명시합니다. 이에 따라 본 글의 어떠한 내용도 투자 조언으로 해석되어서도 안 됩니다.

Author

하서빈, 윤정수, 이이준 of Decipher

Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)

Reviewed By 김동혁, 박순종

1. 블록체인 데이터란 무엇인가?

1.1 일반 데이터와 블록체인 데이터의 차이점

우리는 구글과 같은 대형 인터넷 검색 플랫폼을 통해 다양한 사진과 영상에 담긴 정보를 확인할 수 있습니다. 예를 들어 구글에서 어떤 정보를 검색하여 클릭하게 될 때 컴퓨터는 해당 웹(서버)에 데이터를 요청하게 됩니다. 해당 서버는 요청받은 데이터를 유저에게 보여주는데, 구글 내에서 업로드되는 텍스트, 사진, 영상, 음성 등 모든 데이터는 하이퍼텍스트 전송프로토콜(HTTP) 방식과 같은 중앙화 구조의 데이터 서버로 존재합니다. 이러한 중앙 집중형 서버는 간혹 문제가 생길 경우 복구될 때까지 유저 모두가 이용하지 못하는 단점이 생깁니다. 또한 플랫폼 운영 주체에 의해 정보에 대한 검열이 이루어지는 등 개인정보 유출, 프라이버시 침해 등이 발생할 수 있다는 점이 존재합니다.

금융 데이터의 경우도 마찬가지입니다. 은행의 경우 각 은행의 데이터베이스를 통해 거래를 확인하고 청산하기까지 송금은행, 중개 은행, 지급은행, 중앙은행, 금융결제원 등 많은 미들맨이 거쳐 갈 수 있는 구조입니다. 금융 시스템의 경우 인증과 데이터 거래 증명을 위해 이런 미들맨 또는 인증기관이 필요하므로 보안을 위해 여간 번거로운 게 아닙니다. 또한 모든 장부를 관리하는 통일된 거래내역이 있는 사진의 데이터 전문기관 즉, 이런 중앙집중형 데이터베이스를 이용하게 되면 아무리 보안 유지에 시간적, 금전적으로 힘쓴다고 하더라도 집중 해킹을 당하거나 화재 등 사고가 일어날 경우 데이터 손실 가능성이 매우 높습니다. 설령 복구작업을 진행한다고 하더라도 복구 기간의 피해는 적지 않을 것입니다.

최근 몇 년 전 발생한 카카오 서비스의 일시 중단 사태는 데이터센터에서 발생한 사고를 발단으로 전 국민의 생활에 크고 작은 영향을 미치게 되었습니다. 실제로 카카오 서비스 중 생계와 직면한 서비스의 경우 서비스를 이용하는 사업자들이 일시적으로 고객과의 연결이 실패하는 등, 적지 않은 피해를 보았습니다. 이는 데이터의 저장과 활용을 단일 기업에 의존할 때 발생할 수 있는 문제를 실감하게 하였으며, 반대로 *단일 실패점(single point of failure)이 없는 탈중앙화 방식의 데이터 저장 및 관리의 중요성을 나타내는 사례로도 볼 수 있습니다.

반면 중앙 집중형 방식에 비해 블록체인 데이터는 특정 기관에 의존하여 신뢰하는 것이 아닌 검증을 통해 분별할 수 있으며, 분산원장이라고 하는 분산화된 장부를 통해 유저가 거래내역을 직접 공유할 수 있는 시스템을 가지고 있습니다. 진입장벽의 난이도는 높지만 누구든 언제나 24시간 내내 자신이 원하는 데이터에 접근할 수 있다는 가용성이 있고, 모든 거래 정보가 전 세계 컴퓨터로 구동되는 탈 중앙화된 노드에 분산되어 저장되기 때문에 체인에 등록된 기록은 아무도 삭제하거나 변경, 위조할 수 없게 됩니다. 또한 분산 저장이라는 것은 데이터 센터 정전, 화재와 같은 외부 장애가 발생하더라도 전체 네트워크가 멈춰버리는 단일 실패점이 없다는 뜻이고 이는 다른 통신망들이 계속 작동하여 블록체인이 유지됨을 말합니다.

1.2 온체인 데이터와 오프체인 데이터

앞서 블록체인 데이터라고 개괄적으로 표현했지만, 블록체인 데이터는 온체인 데이터와 오프체인 데이터로 구분할 수 있습니다. 온체인 데이터는 블록체인상에서 언제, 어디로, 얼마나 코인(토큰)이 이동했는지 등 일어나는 모든 트랜잭션에 대한 기록을 말합니다. 트랜잭션을 통해 모든 정보, 가령 거래된 특정 코인의 수량과 가격, 지갑 내 자산의 이동, 수수료와 같은 정보를 모두 확인할 수 있습니다. 왼쪽 그림은 온체인 데이터 플랫폼인 크립토퀀트(CryptoQuant)의 데이터 목록인데, 각 체인 카테고리에 따라 어떤 온체인 데이터를 제공하는지 나열되어 있는 걸 확인할 수 있습니다. 또한 이더스캔(Etherscan)과 같은 블록 익스플로러(Block Explorer)를 활용하여 가공되지 않은 온체인 데이터를 확인할 수 있는데, 오른쪽 사진은 이더스캔에 기록된 수많은 트랜잭션 중 하나입니다. 위 사진을 통해 확인할 수 있듯 온체인 데이터에는 트랜잭션마다 언제(Timestamp), 어떤 주소에서(From), 어떤 주소로(To), 얼마만큼의 토큰이(Value) 수수료는 얼마를 지불하고(Transaction Fee) 이루어졌는지 확인할 수 있습니다.

이렇게 데이터가 온체인 상에 기록되었을 때 언제 어디서든 누구나 데이터 확인이 가능하나, 블록체인에 모든 데이터를 저장하지는 않습니다. 블록체인에 많은 양의 데이터를 저장하려면 시간과 비용이 많이 들고, 비효율적이기 때문입니다. 이렇게 블록체인 이외의 외부 공간에 데이터를 기록하는 데이터를 오프체인 데이터라고 합니다. 체인 내에서 발생한 트랜잭션 데이터가 아닌 외부에서 데이터를 처리하고 오프체인으로 기록하는 방식입니다.

오프체인 데이터에 대해 설명하는 기준에 대해 먼저 말씀드리자면 데이터 저장 방식, 연산이 어디서 일어나는지에 따라 상이할 수 있으나 필자의 경우 이더리움 체인을 기점으로 확장성 솔루션- 데이터 저장 방식을 기준으로 하였고 IFPS 같은 p2p식 저장, 레이어 2(Layer2)의 오프체인 저장인 플라즈마(Plasma), SNARKs/STARKs , 사이드 체인으로 나열할 수 있습니다. 다른 체인인 비트코인의 경우 라이트닝 네트워크나 스택스와 같은 레이어2가 그 역할을 하고 있고 다른 레이어1인 솔라나나 니어는 애초에 확장성을 장점으로 만들어졌기에 사이드체인/L2는 구축 과정이 어려운 점이 있어 글에서는 제외하였습니다.

1.3 오프체인 저장 방식의 현황

IPFS

다시 돌아가서, 대표적으로 여러 체인이 데이터를 저장하는 데 사용하는 방식은 IPFS(Inter Planetary File System)가 많이 사용되고 있습니다. IPFS는 토렌트(Torrent)처럼 P2P 방식으로 대용량 파일과 데이터를 수많은 노드에 호스팅하고 백업할 수 있는 방식입니다. 만약 IPFS에서 시스템이 요청받으면 노드가 응답을 시작하는 네트워크로 해당 요청을 보내고, 그러면 네트워크 전체에서 사용 가능한 데이터를 전달할 수 있는 노드의 응답을 받게 되는데, 이때 SHA-256 해시를 사용해 고유 해시값을 생성하고 데이터를 보호하며 CID를 통해 데이터를 찾고 전송하는 작업을 합니다. 즉 유저가 IPFS 방식으로 데이터를 네트워크에 업로드하면 데이터마다 고유 해시값이 생성되고, 해시값은 영구적으로 사용하게 됩니다. 만약 데이터가 필요해서 다시 가져오고 싶다면 해시값을 검색하여 다시 찾을 수 있습니다.

웹으로 공유하기 위해 데이터를 가져오는 방식은 기존의 웹과 비교했을 때 어떤 방식으로 작동할까요? IPFS와 HTTP 형식의 구조를 비교해 보면, 기존의 HTTP(Hyper Text Transfer Protocol) 방식은 데이터가 위치한 곳의 주소를 찾아가서 원하는 콘텐츠를 한꺼번에 가져오는 방식이었지만, IPFS는 분산 해시 테이블(DHT)을 사용하여 데이터의 내용을 변환한 해시값을 이용하여 전 세계 여러 노드에 분산 저장되어 있는 콘텐츠를 찾아 빠른 속도로 가져온 후 하나로 합쳐서 보여주는 방식으로 작동합니다.

IPFS는 이러한 구조를 구현하기 위해 분산 해시 테이블(DHT:Distributed Hash Table) 구조를 사용하는데 이는 중앙 시스템이 아닌 각 노드가 키(key)를 값으로 맵핑하는 기능을 하는 방식입니다. 분산 해시 테이블은 IPFS의 데이터 검색 시스템 역할을 하여 네트워크가 데이터를 추적하고 빠르게 찾는 데 도움을 줍니다. 일반 해시 테이블은 키(key)가 해시되어 한 곳에 저장되는 키(key)값 저장소이지만, IPFS의 경우 키(key)는 데이터 블록의 콘텐츠 식별(CID:Contents ID)을 하는 역할을 하고, 키(key)값은 각 블록을 보유한 묶음체입니다. 이 키(key)값은 특정 데이터를 찾을 위치에 대한 정보를 저장하게끔 구성되어 있고, DHT는 네트워크의 수많은 노드에 걸쳐 배포하고 저장, 추적, 검색하는 세 가지 역할을 합니다.

과거의 분산 해시 테이블은 호스트가 다음 호스트에게 직접 물어보며 데이터값을 찾아야 하기에 시간이 오래 걸렸지만 IPFS에서 사용하는 분산 해시 테이블은 주기적인 업데이트를 통하여 데이터를 찾는 성능과 안정성을 향상하고 있습니다. 현재 IPFS로 유명한 프로토콜은 파일코인(Filecoin) ,알위브(Arweave), 비트토렌트(BitTorent)가 있는데 다양한 체인 생태계의 NFT 플랫폼, 프로토콜들과 협업하여 NFT 메타데이터 및 콘텐츠를 영구적으로 저장하는 스토리지 프로토콜로 자리매김하고 있습니다.

Data Privacy

반면, IPFS는 공개된 분산 저장소이기에 데이터 보안을 위해 암호화나 주소를 숨기는 기술들이 연구되었지만, 접근 주소가 노출되면 누구든지 데이터에 접근이 가능한 부분이 문제가 되고 있습니다. 더욱이 유럽의 일반정보보호 규정(GDPR)이나, 미국의 캘리포니아주 소비자 프라이버시 법(CCPA) 등 세계적으로 개인정보보호법이 강화되면서 민감 정보를 블록체인에 업로드하고 모든 참여자가 익명화된 정보를 공유하는 것도 위험해졌습니다. 이러한 문제점으로 보았을 때 엔터프라이즈용 대용량 데이터는 IPFS와 같은 공개된 분산 저장소에 저장하기엔 보안성 측면에서 한계가 존재합니다. 그러한 솔루션으로 오프체인 저장용 데이터 프라이버시 관련 기술이 발전하고 있습니다. 대표적으로 기밀 데이터를 온체인에 기록하지 않고 참여당사자 간에만 공유하는 기법을 사용하는 하이퍼렛저 패브릭(Hyperledger Fabric)의 프라이빗 데이터 컬렉션(Private Data Collections), 프라이버시 매니저(Privacy Manager)를 이용한 쿼름(Quorum)의 기밀 거래 처리 기능이 있으나, 이 또한 상대적으로 낮은 인지도와 그에 따른 활용도 측면에서, 대용량 데이터 처리 부분에서 해결해야 할 챌린지는 남아있는 상황입니다.

Layer 2 Scaling Solutions

레이어2를 살펴보면 데이터 저장 방식을 온체인과 오프체인으로 나누게 됩니다. 대부분의 롤업(Rollup)방식은 온체인으로 저장하되, 발리디움(Validium)과 플라즈마(Plasma)는 오프체인으로 저장합니다. 발리디움은 zk롤업처럼 영지식 증명(Zero-knowledge Proof)을 활용하여 오프체인 트랜잭션을 확인하는 레이어2 솔루션입니다. 확인하는 방법은 사이드체인 트랜잭션을 한 번에 묶고 각 처리에 대해 영지식증명을 생성해서 거래가 유효한지, 오프체인에 업데이트 되었는지를 확인합니다. zk롤업과 가장 큰 차이점은 zk롤업은 증명 후 이더리움 메인넷에 전송하지만 발리디움은 오프체인의 트랜잭션 데이터를 이더리움에 저장하지 않고 오프체인에 저장한다는 점입니다. 최근 이더리움 커뮤니티와 트위터에서는 셀레스티아나 발리디움을 두고 레이어2 솔루션이 아니다는 주장 vs 오프체인 거래에 영지식 증명을 활용하지만 보안을 위해 이더리움 메인넷에 의존하는 것이니 레이어2 솔루션이다라는 의견들이 팽배한 모습을 보여주고 있습니다.

플라즈마 방식은 플라즈마는 이더리움 메인 체인을 복사하여 여러 계층의 사이드 체인을 생성, 독자적이고 병렬적인 연산을 수행하며 “Full Layer 2” 구성으로 데이터를 모두 오프체인으로 이동시킵니다. 과거 이더리움 확장성 문제를 해결하는 희망으로 플라즈마가 기대를 받았었지만 여러 문제점을 보였고, 플라즈마 기술을 포용하고 문제점을 개선한 롤업이 확장성 솔루션의 선두 주자가 되었습니다. 트랜잭션 데이터를 오프체인에만 보관하는 이런 방식은 결론적으로 데이터 가용성(Data availability)이 낮습니다. 즉, 이더리움 메인넷에서 블록을 검증할 때, 오프체인에 저장된 트랜잭션 데이터에 접근하지 못하는 문제를 가지고 있어 단점을 갖게 되지만, 확장성 측면에서는 강력한 장점이기도 합니다.

1.4 온체인 데이터 관찰의 중요성

온체인 데이터는 크게 가공되지 않은 로우 데이터(Raw data)와 라벨링, 온체인 데이터를 가공한 온체인 지표들로 구분할 수 있습니다. 가공되지 않은 로우 데이터를 분석하기에는 일반적으로 한계가 존재합니다. 분석 난이도 또한 높기에 대부분 온체인데이터를 쉽게 검색하고 직관적으로 확인하고 실시간으로 추적할 수 있게 시각화한 서비스를 제공하는 온체인 데이터 플랫폼 시장이 확대되고 있습니다.

온체인 데이터를 제대로 읽고 활용할 수 있다면 이러한 이점이 있습니다

유의미한 투자의사 결정에 활용 : 코인 거래량 변동, 상승/하락 시그널, 장단기 보유자, 미체결약정, 활성 주소 수, 활성 유저, 네트워크 사용 증가량, 채굴자 수익, 프로젝트 리저브(보유 물량), 거버넌스 활동, 토큰 유통 흐름, 네트워크 수수료, 전체 트랜잭션 수 등을 통해서 의미 유추 가능
유저 활동으로 보는 시장 트렌드 조사 : 유동성, 네트워크 이용자 수, 프로젝트 민팅 트랜잭션, 테스트 넷 또는 에어드랍 활성 지갑 수, 디파이 풀 거래량으로 보는 트렌드 파악, 지역별 카테고리 선호도
범죄 추적, 이상 탐지 모니터링 (리스크 관리) : 대량 이동 코인 흐름, 재단 물량 출금, 디파이 풀 해킹 추적, 러그 프로젝트 자금 지갑 추적 등 리스크 관리

그럼 이런 이점들을 적용해서, 유의 온체인 데이터 활용 니즈에 맞게 제공하고 있는 플랫폼은 대표적으로 아래와 같습니다. 플랫폼마다 제공하는 서비스에 대한 특징은 이렇습니다.

Nansen : 메인 지갑과 버너 지갑(Burner wallet)의 상세 트래킹 등 자금흐름 추적에 매우 용이
Etherscan : 개별 트랜잭션의 정보 확인이 쉬움
Dune Analytics : Query 베이스. 데이터 가공 및 주제별 대시보드 제작 가능. 트렌디한 대시보드가 특징
Flipside Crypto : Query 베이스. 대시보드 내 탭 생성 가능. 대시보드 전체 쿼리 새로고침 가능
Footprint Analytics : 코딩 없이 시각화 가능, 차트 결과에 SPL모드를 함께 서비스
CryptoQuant : 비트코인 온체인 데이터가 주요 서비스, 시장 거래 흐름 및 현황을 쉽게 확인 가능
Arkham : Nansen의 무료 상위 호환 버전. 상세 기관 라벨링 서비스와 비주얼라이징 가능. 대시보드 커스텀 제작이 편리하며 토큰을 이용한 토크노믹스 구현
Glassnode : CryptoQuant에 없는 지표들이 존재한다는 점, 매주 고분량의 인사이트 리포트 발간

이렇게 온체인 데이터의 구성과 현재까지의 현황, 유저들이 온체인 데이터를 관찰했을 때의 용이성과 그 니즈에 맞게 나온 서비스 플랫폼들의 특징을 통해 이제 저희 팀은 플랫폼 백(back)단에서 체인의 특징에 따라 어떤 핵심을 가지고 온체인 데이터를 분석해야 하는지 알아보고 온체인 데이터의 접근 과정에 대해 기술적으로 살펴보려고 합니다.

2. 온체인 데이터 분석 환경 이해하기

Dune Analytics과 같은 온체인 데이터 업체들을 확인해 보면, Opensea의 트레이딩 데이터 테이블, ERC-20 Transfer Event 테이블 등 이미 디코딩된 테이블들을 많이 만들어두었기 때문에, SQL에 관한 지식이 있다면 누구나 기본적인 분석은 쉽게 수행할 수 있습니다. 하지만, 내가 만든 컨트랙트나 아직 남들이 디코딩하지 않은 프로젝트를 내가 먼저 디코딩하고 싶은 경우에는 Raw 데이터에 대한 이해가 수반되어야 합니다.

EVM 체인과 UTXO 체인의 데이터가 어떻게 보관되는지를 이해하고, 이를 바탕으로 데이터를 가공하는 방법을 알아봅시다.

2.1 데이터베이스로서의 블록체인

Source: https://dev.mysql.com/doc/refman/8.0/en/pluggable-storage-overview.html

데이터베이스를 생각하면 떠오르는 가장 대표적인 예시는 MySQL, PostgreSQL과 같은 관계형 데이터베이스 (RDB)입니다. 관계형 데이터베이스는 크게 파일 시스템과의 소통을 담당하는 스토리지 엔진, 그리고 스토리지 엔진에 데이터를 기록하거나, 조회하는 방식을 추상화해 주는 쿼리 엔진으로 구분이 됩니다. 주로, SQL이라는 언어를 통해 SELECT name, age, company FROM person 과 같은 방식으로 데이터를 조회하거나, INSERT INTO person VALUES ('정수', 31, Decipher) 와 같은 방식으로 데이터를 쉽게 삽입할 수 있습니다.

블록체인도 저장되어 있는 데이터를 기록하거나 조회하는 것이 가능하기 때문에 데이터베이스라고 볼 수 있습니다. 그런데, 우리가 알고 있는 관계형 데이터베이스와는 근본적인 차이가 있는데요, 관계형 데이터베이스는 한 번 쓴 데이터를 빈번하게 수정(Update) 하는 반면에 블록체인의 데이터는 한번 컨펌되고 나면 다시는 수정되지 않는다는 특징이 있습니다. MySQL과 같은 트랜잭션을 지원하는 데이터베이스 (OLTP)의 언어 SQL에서 중요하게 쓰이는 기능이, 여러 서비스에서 데이터를 동시에 쓰려고 할 때, 충돌을 방지하기 위해 잠금(Lock)을 거는 기능인데, 블록체인은 중앙화된 Lock Service가 없기 때문에, 발생할 수 있는 충돌 상황을 합의(Consensus)레벨에서 풀어낸다는 특징이 있습니다. 그렇기 때문에, 블록체인은 Append-Only의 특성을 가지고 있고, 대부분 쓰기에 유리한 LSM Tree 기반의 LevelDB와 같은 스토리지 엔진을 직접 기록에 사용합니다. 다만, 이 스토리지 엔진은 로우 레벨의 데이터베이스이기 때문에, 직접 접근해 분석을 하는 것이 일반 개발자들에게도 어려운 편입니다.

그리고, 관계형 데이터베이스는 상태를 조회하는데 초점이 있고, 블록체인은 상태를 기록하는데 초점이 있습니다. 조회, 기록 둘 다 관계형 데이터베이스와 블록체인이 지원하는 기능인데, 이런 목적의 차이가 발생하는 이유는 각자가 정의하는 ‘분산’을 하는 목적의 차이에서 기인합니다. 블록체인의 분산은 모두가 동일한 데이터를 저장하고 동일한 데이터를 검증하는 것이 목적인 분산이고, 일반 데이터베이스의 분산은 데이터를 잃지 않기 위함이거나, 연산을 분산해 효율적인 데이터 처리를 하기 위한 분산입니다.

관계형 데이터베이스는 데이터를 나눠서 저장하는 목적이, 데이터를 읽거나 쓰는 효율을 증가 시키기 위해서일 뿐이지 그 데이터는 ‘나와 내가 허가한 나를 신뢰하는 사람’만 볼 수 있는 것입니다. 그래서, 내가 저장해둔 것을 잃지 않고 나중에 꺼내보는 것에 초점이 있는 것이 관계형 데이터베이스의 특징입니다. 반면에, 블록체인은 내가 기록한 것을 모든 노드에 멀리 알리고, 이를 모두에게 검증받는데 초점이 있습니다. 내가 상태 변환 (UTXO 전송, 스마트 컨트랙트 실행)을 실행했다는 것을 모두가 알게 하는 것을 더 중요하게 생각하는 특징이 있습니다.

2.2 EVM 원본 데이터 이해하기

Dune Analytics이나 CryptoQuant 등의 온체인 데이터 플랫폼에는 이미 Opensea NFT Purchase, Token Transfer와 같은 디코딩된 이벤트 테이블들이 많이 만들어져 있습니다. 그렇기 때문에, 일반적인 분석은 SQL 사용법에 대해서만 익숙해진다면, 쉽게 수행할 수 있습니다. 다만, 본인이 만든 컨트랙트를 분석하거나, 아직 디코딩 테이블이 만들어지지 않은 데이터를 분석하기 위해서는 EVM 데이터의 발생 원리와 그 구조에 대해 이해하는 것이 필요합니다.

Source: An interpretation of the Ethereum project yellow paper (2014)

Ethereum Yellow Paper에는 노드와 블록에 데이터를 저장하는 방식이 상세히 설명되어 있고, 대부분의 온체인 업체들은 노드 원본 데이터를 아래와 같이 테이블 포맷으로 재가공해 유저들에게 제공합니다.

이 중, blocks, logs, receipts, traces, transactions 데이터를 이해한다면 디코딩 테이블을 쉽게 만들어낼 수 있습니다.

State

Ethereum Yellow Paper의 정의에 따르면, EVM은 Account Based State와 이 State를 변화 시키는 기능 (Arbitrary state transition functions)으로 구분할 수 있습니다. EVM의 World State는 특정 시점 (Block)의 모든 Account State의 합으로 정의됩니다.

이 때, Account에 포함되는 요소는 아래 그림에서처럼, Nonce, Balance, Account Storage, Code 4가지 입니다. 다만, 이더리움의 Account는 일반적으로 유저를 지칭하는 외부 소유 계정 (EOA)과, Contract로 구분되는데, Account Storage와 Code는 EOA가 아닌 오로지 Contract의 Storage에만 저장됩니다.

이를 직관적으로 이해할 수 있는 예시는 ERC-20 토큰입니다. USDT 토큰의 계정별 잔액은 개별 계정(EOA)의 저장 공간에서 관리되는 것이 아닌, Contract의 Storage에서 mapping(address => uint256) 과 같이 관리됩니다. 그렇기 때문에, 토큰 코드에 function addBlackList (address _evilUser) 과 같은 함수가 있다면, 토큰의 Transfer를 호출할 권한을 차단하는 것이 가능한 것입니다.

그림에서 볼 수 있는 것처럼, 모든 상태 정보를 매 블록에다가 기록하는 것은 용량 제한으로 불가능하기 때문에, 계정의 상태정보는 트리 구조를 이용해 루트 노드의 해시값만 블록에 저장합니다.

위의 내용을 바탕으로, 온체인 데이터의 accounts 테이블에서 EOA와 Contract를 구분하는 방식을 예시로 알아봅시다.

Contract와 달리, EOA는 storage와 code값을 가지지 않기 때문에 Account Storage Trie와 코드가 항상 비어있고, 그렇기 때문에 storage_hash 값은 비어있는 머클트리의 값인0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421 , code_hash값은 항상 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 값을 가지게 됩니다.

State Transition

Storage 자체는 블록에 해시값만 기록되기 때문에, 실제로 우리가 생각하는 유의미한 데이터는 상태 변경(State Transition) 기능인 transaction과 그 부산물에서 관찰할 수 있습니다.

Transaction은 그 출발지가 반드시 EOA이고, EVM의 상태를 변경하는 기본 작업 단위입니다. transaction 가스와 관련된 정보, 대상이 되는 Contract인 to, 전송하는 이더리움의 양인 value, 그리고 함수를 실행하는데 필요한 data, 그리고 서명 정보인 v, r, s 필드가 있습니다.

일반 노드에는 존재하지 않지만, 아카이브 노드에는 Trace 데이터도 포함되어 있습니다. Trace는 transaction이 실행되는 상세 과정을 포함합니다. 이는 모든 함수 호출, 메시지 호출, 상태 변경 데이터들이 포함됩니다. Trace를 internal transaction이라고 부르기도 합니다.

transaction이 실행된 결과는 transaction receipt라는 영수증에 포함되어 나옵니다. 해당 영수증에서는 트랜잭션의 성공 유무, 사용한 가스량, 그리고 트랜잭션 실행 중에 컨트랙트 개발자가 선언해둔 Event에 대한 Log도 확인할 수 있습니다. 대부분의 분석은, 이 이벤트 로그를 활용하는 것만으로도 쉽게 진행할 수 있습니다.

Event Log

Ethereum Yellow Paper에 선언된 로그의 정의입니다. 이를 쉽게 풀어쓰면 Log data는 ‘최대 4개의 topic 필드를 가지는 array와 data 필드’로 구성되어 있습니다.

Dune Analytics에서 ethereum.logs 테이블을 확인해보면, topic1부터 topic4까지가 각각의 필드로 선언이 되어 있는 것을 볼 수 있습니다.

이 topic이라는 필드가 어떻게 구성되는지 상세히 이해해보도록 합시다. topic1은 이벤트 로그라면 반드시 존재하는데, 이는 이벤트의 고유 식별자를 의미합니다. 아래의 예시를 살펴보도록 하겠습니다.

이더리움의 토큰 표준인 ERC-20은 토큰 전송이 일어났을 때, 위와 같은 포맷의 event Transfer 를 반드시 호출하도록 정의되어 있습니다. event Transfer의 전달 인자는 from 주소, to 주소, 그리고 보내는 양인 value로 구성이 되어있는데, 이 때 topic1에 들어가는 값은 이벤트의 시그니처입니다. 시그니처는 전달 인자의 이름 (_from, _to, _value)를 빼고 Transfer(address,address,uint256) 과 같이 전달인자의 타입만 남겨 표준화한 후 Keccak-256 hash 변환을 하고 난 값입니다. 그렇기 때문에, event Transfer가 발생한 경우에는 topic1의 값은 반드시 ddf252ad1be2c89b6… 값이 남게 됩니다. 따라서, 전체 log 테이블에서 topic1을 해당 해시값으로, 그리고 원하는 토큰의 컨트랙트를 바탕으로 필터링을 진행한다면, 특정 토큰의 Transfer 이벤트를 모두 조회할 수 있습니다.

토픽은 최대 4개의 필드를 가질 수 있다고 했는데, EVM 설계에서 event는 최대 3개의 indexed 필드를 가질 수 있도록 설계되어 있습니다. 위 Transfer 이벤트의 경우에는 from, to가 indexed argument로 선언되어 있는데, 이 경우에는 topic2에는 from의 주소, topic3에는 to의 주소가 들어가게 됩니다. 따라서, 노드의 API나, 온체인 데이터 테이블에서 특정 주소를 기준으로 데이터를 쉽게 필터링할 수 있습니다.

그리고, index되지 않은 필드들은 data 필드에 몰아서 저장되게 됩니다. 여기서는 index 되지 않은 인자는 토큰의 전송량인 _value가 유일하기 때문에, data 필드의 값은 토큰의 전송량이 됩니다.

위의 내용을 바탕으로, ethereum.logs 테이블을 이용해 token_transfer 디코딩 테이블을 만드는 SQL 수도 코드는 다음과 같이 정리할 수 있습니다.

이벤트 데이터는 분석 목적 뿐 만이 아니라, 노드에서 직접 데이터를 실시간으로 구독하는데도 유용하게 이용됩니다.

위의 예시는 web3.js와 노드의 websocket endpoint를 이용해 특정 토큰 (SAI)의 Transfer 이벤트를 실시간으로 구독하는 예시입니다.

스마트 컨트랙트 코드가 공개되지 않은 경우라도, 개발자가 이벤트를 남겨놓고, 그 시그니처가 일반적으로 널리 쓰이는 시그니처인 경우에는 이를 분석하는 것도 가능합니다. 아래는 클레이튼의 덱스 어그리게이터를 이용해 스왑을 진행한 예시입니다.

Explorer에서 확인을 했을 때, token transfer의 내용을 보고는 해당 swap event의 출발지는 어떤 토큰이고, 도착지는 어떤 토큰인지 쉽게 분석하기 어렵습니다.

하지만, 컨트랙트 개발자는 시그니처가 이미 해독되어 있는Swap(address,address,address,address,uint256,uint256) 이벤트를 남겼기 때문에 출발 토큰 컨트랙트와 도착 토큰 컨트랙트를 쉽게 찾아낼 수 있습니다. Topic 1은 컨트랙트를 실행한 EOA의 주소이고, Topic 2는 from token (native KLAY), Topic 3는 to token (KCD) 인 것을 역으로 추론할 수 있습니다.

Trace Data

Trace Data는 조금 더 낮은 레벨에서의 분석에 사용되는데, 해당 데이터에는 트랜잭션과 달리, 트랜잭션 내부에서 컨트랙트가 또 다른 컨트랙트를 호출한 경우까지 모두 기록되어 있습니다.

Source: https://medium.com/coinmonks/ethereum-data-evm-traces-simplified-5e297e4f40a4

EVM의 트랜잭션 출발점은 반드시 EOA이지만, EOA가 호출한 컨트랙트가 프록시 컨트랙트일 수도 있고, 다른 컨트랙트를 호출하는 경우는 상당히 빈번합니다. 이런 컨트랙트가 컨트랙트를 호출하는 경우는 트랜잭션 데이터만으로는 필터링이 어렵기 때문에, 특정 함수 호출을 분석하기 위해서는 trace 데이터를 이용해야 합니다.

Trace data가 기록되는 경우는 EOA가 컨트랙트를 생성하는 경우인 create, 컨트랙트를 파괴하는 경우인 suicide, 그리고 대부분의 분석 대상인 call이 있습니다. call은 EOA간 eth를 전송하는 경우에도 기록이 되고, 스마트 컨트랙트를 호출하는 경우에도 기록이 됩니다. Trace data는 Internal Transaction이라 불리기도 하고, 아카이브 노드에서만 조회할 수 있는 데이터입니다.

Transaction은 유저가 실행한 회수, Log는 개발자가 컨트랙트에 남긴 로그의 수, 그리고 Trace는 트랜잭션 내에서 발생한 함수호출 등을 전부 기록하기 때문에 데이터의 양이 상대적으로 많습니다. DApp 개발에서 Trace 데이터는 디버그 목적으로 주로 활용되지만, 온체인 분석에서는 Log가 남지 않는 특정 함수 호출 분석 등에 유용하게 활용될 수 있습니다.

Trace 데이터를 활용하는 예시로, ERC-20 토큰인 테더(USDT)의 addBlackList 함수 호출 내역을 분석해 보도록 하겠습니다. 해당 함수는, 자금 세탁이나 해킹 사건 등에 연루된 주소들의 token transfer를 제한하는 기능이 구현되어 있습니다.

이벤트 로그를 분석했을 때와 같은 방식으로, 메소드 시그니처를 Keccak-256으로 변환해 해시 값을 구합니다.

그 중, 메소드 시그니처는 앞의 4바이트를 사용합니다. 해당 4바이트 값을 이용해 trace 데이터의 input 값의 시작이 해당 4바이트로 시작하는 경우를 필터링하면 됩니다.

위 쿼리를 해석해보면, 2024년 1월에 발생한 trace 데이터 중에, input이 빨간 박스로 시작하는 경우를 찾아주고, 그 to_address가 USDT contract address인 경우를 찾아달라는 의미입니다. 그 결과가 아래 테이블인데, input의 시작이 우리가 지정한 모양임을 확인할 수 있고, 그 다음 32바이트부터는 주소들이 들어가 있는 것을 확인할 수 있습니다. 여기서 1월 2일에 발생한 trace 데이터를 상세히 들여다보도록 합시다.

해당 주소를 확인해보니, 오르빗 브릿지의 이더 볼트 자금을 탈취한 Drainer의 주소가 나왔습니다. 오르빗 브릿지가 테더사와의 협조를 통해 해당 계정에 있는 $0.2M의 USDT를 성공적으로 동결했다는 것을 알 수 있습니다.

해당 함수의 실행은 EOA의 컨트랙트 호출로부터 시작되기 때문에, transaction 테이블에서도 쉽게 조회할 수 있을 것 같지만, transaction table에서 해당 정보를 조회하기 위해서는, EOA가 Bitfinex의 MultiSig 컨트랙트를 호출한 후, 해당 컨트랙트가 addBlackList 함수를 호출한다는 사실을 알아야 쉽게 조회할 수 있습니다.

2.3 UTXO 원본 데이터 이해하기

UTXO 기반 체인들은 주로 자금의 흐름만 분석하는 경우가 대부분이었는데, 최근엔 Inscription, BRC-20, SRC-20 등의 새로운 시도가 등장하면서 온체인 분석의 기회의 땅이 되었습니다. 다만, 해당 내용을 이해하기 위해서는 비트코인 스크립트에 대한 이해가 선행되어야 하기 때문에, 이는 향후 과제로 남겨두고, UTXO의 데이터 모델에 대한 이해를 하는 것을 목표로 하도록 하겠습니다.

비트코인 스크립트는 솔리디티와 같은 바이트 코드를 추상화해주는 프로그래밍 언어가 없기 때문에 스크립트 해석이 난해한 편입니다. 다만, 트랜잭션 코드는 반드시 Input과 Output으로 쪼개지기 때문에 자금 이동 분석은 쉽게 진행할 수 있습니다.

자금 증명 등을 해야하는 거래소의 경우는 논외이지만, EVM 체인들과 달리 UTXO 기반 체인들은 주소를 재사용하지 않는 것이 일반적입니다. 비트코인 트랜잭션은 서명을 통해 과거 비트코인 주소들의 소유권을 증명하는 해제 스크립트, 그리고 비트코인을 잠글 새로운 주소와 관련된 잠금 스크립트로 구성됩니다.

Source: https://read.cryptodatabytes.com/p/how-to-analyze-bitcoin-data-with

위 그림의 가운데 Old block을 보면, 트랜잭션이 Older Block의 output 2개 주소에 대한 소유권을 증명하고, 2개 주소를 새로운 input으로 사용해서, 새로운 3개의 주소에 output으로 보낸 것을 알 수 있습니다. 해당 트랜잭션으로 2개 주소의 비트코인이 3개 주소의 비트코인으로 분배되었다고 이해할 수 있습니다.

파싱된 스크립트의 예시입니다. Input에는 과거에 소비되지 않은 비트코인 주소(UTXO) 들과 소비할 값, 그리고output에는 새로 보낼 주소와 보낼 양이 각각 적혀 있습니다. 위 예시에서는 1900 BTC가 2개의 주소에 각각 700 BTC, 1200BTC로 쪼개져 전송됩니다.

자금의 흐름을 분석할 때 알아야 할 것은 위 내용이 전부입니다. 비트코인의 자금 흐름 추적은, Zk 등의 익명성 기반 송금이 아니기 때문에, 노력을 기울이면 가능하지만 EVM에 비해서는 그 난이도가 높은 편입니다. 그 이유는 비트코인은 주로 주소를 재사용하지 않는다는데 있습니다.

우리가 관심있는 데이터는 특정 주소라기보다는 특정 엔티티(entity)라 불리는 논리적인 개념입니다. 엔티티는 거래소 지갑들의 묶음, 그레이스케일 ETF 펀드 지갑의 묶음, 사토시의 지갑 Patoshi의 묶음과 같은 개념입니다. 그런 엔티티 지갑 묶음 정보가 있어야, 거래소 입출금량, ETF 자금 입출금, 사토시의 지갑은 깨어났는가? 와 같은 분석이 가능하기 때문입니다.

이런 주소들을 특정 엔티티로 묶는 것을 ‘address clustering’이라 부릅니다. 이를 수행하기 위해서는 트랜잭션에 대한 이해를 기반으로 휴리스틱 알고리즘의 적용이 필요합니다.

Source: De-Anonymization of the Bitcoin Network Using Address Clustering (2020)

위에 제시된 알고리즘이 가장 기본적인 클러스터링 알고리즘 예시입니다. 하나의 트랜잭션에 여러 주소들이 한 번에 소비되는 경우, 한 명의 엔티티가 저 주소들을 전부 소유하고 있다고 합리적으로 추론할 수 있습니다. 다만, 항상 이런 추론이 옳은 것은 아닙니다. CoinJoin과 같은 자금세탁 트랜잭션의 경우에는 여러 엔티티의 여러 아웃풋이 한 번에 소비되지만, 이 경우에는 Input들이 모두 하나의 엔티티가 아니기 때문입니다.

위와 같은 클러스터링 분석을 진행하기 위해서는 BlockSci와 같은 툴을 이용해 비트코인의 트랜잭션을 전부 그래프 모델로 변환해야 합니다. 하지만, 해당 그래프 분석은 개인 분석 목적으로 진행하기에는 상당히 고비용의 연산과 저장공간을 필요로 합니다. 그렇기 때문에 이러한 분석은 GlassNode나 CryptoQuant, Chainalysis와 같은 플랫폼에서 제공해주는 데이터를 이용하기도 합니다.

2.4 온체인 데이터 특징

블록체인 데이터 분석을 진행하며 놓치지 않아야 할 특징이 있습니다. 블록체인과 관계형 데이터 베이스를 다시 비교해보도록 하겠습니다. 블록적인 이산적인(Discrete) 타임스탬프를 가진 데이터베이스라고 볼 수 있고, 관계형 데이터베이스는 연속적인(Continuous) 타임스탬프를 가진 데이터베이스라고 볼 수 있습니다. 연속적인 타임스탬프를 가진 데이터베이스는 상태가 아주 작은 시간 단위로 계속 변화하기 때문에, 노드 사이의 물리적 거리와 빛의 속도에 영향을 받고, 모든 분산 노드가 최신 상태라고 여기는 상태가 서로에겐 최신 상태가 아닐 수 있습니다.

Source: Designing Data-Intensive Applications

관계형 데이터베이스에서는 동일 자원에 대해 동시 쓰기 문제가 발생할 때, 중앙화된 Lock Service를 이용합니다. (Shared Sequencer는 Lock Service의 하위 집합이라 볼 수도 있습니다). 사진에서처럼 어떤 방을 예약하려고 할 때, 특정 클라이언트가 Lock을 잡아두고 있는 동안은 다른 클라이언트는 해당 데이터의 상태를 변경할 권한이 없습니다. Lock Service를 이용해 이중 예약, 더블 스펜딩과 같은 문제를 방지할 수 있습니다.

반면, 블록체인은 이산 타임스탬프를 가지고 있기 때문에, 노드에서 연산을 진행할 때 내가 가진 최신 블록 상태를 남들도 가지고 있을 것이라 가정하고, 일단 연산을 해서 채굴된 블록을 네트워크에 전파하기 시작합니다. 하지만, 블록체인도 마찬가지로 네트워크 이슈로 먼 거리에 있는 두 채굴 노드가 서로 통신이 닿는 시간보다 짧은 시간 차이로, 거의 동시에 블록을 채굴하는 순간적인 포크 상황이 발생할 수도 있습니다. 이런 문제를 무신뢰성(Trustless) 라는 블록체인의 특징을 지키기 위해 합의 레벨에서 해결합니다.

Source: https://www.alchemy.com/overviews/what-is-a-reorg

비트코인의 경우에는 분기가 발생했을 때, 가장 긴 체인을 표준(Canonical) 블록체인으로 채택합니다. 그리고, 분기된 블록은 네트워크에서 버려집니다. 그렇기 때문에, 분석가 입장에서 과거 블록 정보가 아닌, 최신의 블록 정보를 사용하는 경우에는 내가 가진 블록 정보가 언제든 합의 레벨에서 버려질 수 있다는 점(Re-organization)을 인식하고 개발을 진행해야 합니다. 더 이상, 블록에 담긴 정보가 변하지 않는 상태를 ‘블록이 finalized 되었다’ 라고 표현하는데요, 이더리움의 경우 1 epoch, 즉 6.4분 정도 지난 블록을 finalized되었다고 표현합니다.

3. 온체인 데이터 접근 방식

이번 챕터에서는 분석을 위하여 온체인 데이터에 접근하는 다양한 방법을, 저수준의 스토리지 엔진에 직접 접근하는 방식부터 고수준의 OLAP 플랫폼을 사용하는 방법까지 차례로 설명해드리도록 하겠습니다. 본 글의 목적은 개발 경험이 없는 독자들도 온체인 데이터의 구조와 접근 방식을 쉽게 이해할 수 있도록 하는 것입니다. 따라서 코드에 대한 설명을 하기보다, 온체인 데이터에 접근하는 다양한 방식에 대한 설명에 초점을 맞추어 설명하고자 합니다.

3.1 스토리지 엔진

이번 파트에서는 저수준의 스토리지 엔진인 LevelDB에 직접 접근하여 온체인 데이터를 확인해보도록 하겠습니다. 실제 온체인 데이터 분석 과정에서 분석가들이 스토리지 엔진의 데이터에 직접 접근하는 일은 드물기 때문에, 이 파트의 목적은 스토리지 엔진을 직접 다루는 과정이 얼마나 비효율적이고 복잡한지 이해하는 데에 있습니다. 이를 통하여, 온체인 데이터 분석에 있어서 보다 효율적이고 접근하기 쉬운 방법의 필요성을 인식할 수 있을 것입니다.

LevelDB는 Google이 개발한 LSM Tree 기반의 key-value 저장 데이터베이스입니다. LSM Tree는 데이터를 디스크에 직접 쓰는 대신, 먼저 메모리 내의 이진 트리인 memtable에 추가하고, memtable이 일정 크기에 도달하면 디스크 내의 SSTable에 flush하는 방식으로 작동합니다. 이 과정 덕분에 key가 이미 정렬된 상태로 쓰기 작업을 효율적으로 수행할 수 있습니다. 이러한 특성은 append-only 특성을 가진 블록체인 데이터에 특히 적합하여, 비트코인이나 이더리움 등에서 널리 사용됩니다.

LSM Tree에 데이터가 저장되는 방식. Source: https://loosie.tistory.com/873#LSM(Log_Structured_Merge)_Tree

그러나 LevelDB 내의 데이터를 직접 읽고 해석하는 것은 간단한 일이 아닙니다. 데이터베이스 구조가 복잡할 뿐만 아니라, 블록체인 데이터의 인코딩 방식이 직관적이지 않기 때문입니다.

예를 들어, 이더리움의 LevelDB에 접근해 보았을 때, 우리가 직접 해석하기 어려운 형태의 키와 값이 나타납니다. 이 데이터는 RLP(Recursive Length Prefix) 방식으로 직렬화되어 있으며, 이를 유저가 이해할 수 있는 정보로 변환하기 위해서는 복잡한 디코딩 과정이 필요합니다. 물론 라이브러리를 사용할 수 있지만, 이 과정은 온체인 데이터에 접근하여 분석하고자 할 때 상당히 번거롭고 복잡한 단계입니다.

이더리움 LevelDB에서 확인한 Key, Value 값. Source: Decipher

따라서, 일반적으로는 스토리지 엔진에 직접 접근하는 방식보다는 노드 인터페이스를 통해 온체인 데이터에 접근하는 방식이 선호됩니다.

3.2 노드 인터페이스

이번 파트에서는 분석을 위한 온체인 데이터 접근 방법 중, 노드 인터페이스를 통한 접근에 대하여 설명 드리겠습니다. 노드 인터페이스는 블록체인 노드에 저장된 데이터에 접근하기 위해 사용되는 가장 일반적인 방법 중 하나입니다. 일반적으로 HTTP나 WebSocket 같은 프로토콜을 활용한 API를 제공하게 되는데, 유저들은 이 API를 통하여 트랜잭션을 전송하고, 블록 정보, 트랜잭션 정보, 스마트 컨트랙트 상태 등 온체인 데이터를 조회할 수 있으며, 네트워크 상태를 포함한 다양한 정보를 모니터링할 수 있습니다.

예를 들어, 비트코인은 bitcoind라는 데몬을 통해 HTTP 기반의 JSON-RPC 인터페이스를 제공합니다. 여기서 ‘데몬’이란, 유저가 직접 관리하지 않아도 백그라운드에서 실행되는 프로그램을 의미합니다. 이 RPC 인터페이스를 통해, 유저는 블록 정보나 트랜잭션 상세, 네트워크 상태 등을 쿼리할 수 있습니다. 예를 들어 비트코인 노드에서 정보를 쿼리하는 경우, bitcoin-cli라는 커맨드 라인 인터페이스를 사용하여 bitcoind와 상호작용할 수 있습니다.

bitcoin-cli를 통해 확인한 비트코인 블록 정보. Source: Decipher

이더리움도 유사하게, geth와 같은 노드 소프트웨어를 통해 JSON-RPC 인터페이스를 제공합니다. web3.js나 ethers.js와 같은 라이브러리를 사용하면, 이더리움 블록체인과 효율적으로 상호작용할 수 있습니다. 실제로, 이 라이브러리들을 활용하여 최신 블록 번호를 쿼리하는 것은 매우 간단하며, 결과도 정확하게 얻을 수 있습니다.

테스트 코드를 통해 확인한 이더리움 블록 정보. Source: Decipher

노드 인터페이스를 통한 접근 방식은 빠르고 실시간으로 최신 블록 데이터를 얻을 수 있는 이점이 있어, 실시간 대시보드 구축이나 DApp 개발에 유리합니다. 하지만, EVM 노드의 경우 응답 시간이 길어지거나 과부하가 발생할 수 있는 단점이 있으며, 이 방법으로 얻은 데이터는 분석 목적으로 최적화되지 않았다는 점을 염두에 두어야 합니다.

노드 인터페이스를 통한 데이터 접근 방식은 분석을 위한 데이터를 얻는 데에는 한계가 있으며, 특히 전체 블록을 스캔하여 데이터를 분석하고자 할 때에는 적합하지 않습니다. 이러한 이유로, 분석 목적으로는 보통 OLAP 플랫폼을 사용하는 것이 더 효율적입니다. 그럼에도 불구하고, 노드 인터페이스를 통한 데이터 접근 방식은 실시간 정보를 빠르게 반영해야 하는 상황 등에서 유용하게 사용될 수 있습니다.

3.3 OLAP 플랫폼을 이용한 온체인 데이터 분석

이번 파트에서는 온체인 데이터를 분석하기 위한 접근 방법으로 OLAP, 즉 Online Analytical Processing에 대하여 살펴보도록 하겠습니다. OLAP은 대규모 데이터셋을 효과적으로 분석할 수 있게 해주는 소프트웨어 기술을 말하며, 데이터 웨어하우스나 데이터 마트 등의 저장소에 저장된 데이터를 다룹니다. 이러한 데이터 저장소는 보통 테이블 형태로 구성되어 있으며, 각 테이블은 데이터를 두 차원으로 재구성하는 데에 최적화되어 있습니다. OLAP 도구는 이 데이터를 분석하기 용이한 형태로 재가공하여, 블록체인의 온체인 데이터 분석에 효과적인 데이터를 구성합니다.

블록체인의 데이터가 분산 저장되어 있는 것과 다르게, OLAP은 이러한 데이터를 분산 데이터베이스에 재적재하여 분석 목적으로 최적화하는 과정으로 볼 수 있습니다. 예를 들어, 이더리움의 경우 20억 건이 넘는 트랜잭션을 처리해야 하지만, OLAP 도구 중 하나인 BigQuery와 같은 플랫폼은 이를 몇 초 내로 처리할 수 있습니다.

그러나 OLAP 플랫폼 간에는 사용하는 기술이 다를 수 있으며, 이에 따라 SQL 표준에도 차이가 있습니다. 예를 들어 CryptoQuant는 BigQuery를 사용하지만, Dune Analytics는 처음에는 PostgreSQL을 기반으로 시작했다가 다음에는 SparkSQL, 그리고 현재는 Trino 기반의 OLAP를 사용합니다.

예시로, 비트와이즈의 비트코인 ETF 밸런스 조회 과정을 Google Cloud Platform의 BigQuery를 사용해 살펴보도록 하겠습니다.

BigQuery의 퍼블릭 데이터셋에서 가공된 온체인 데이터 테이블을 활용하여, 트랜잭션 데이터의 스키마와 최신 수정 시간 등을 확인할 수 있습니다.

그리고 이렇게 가공된 데이터를 쿼리하여 유저가 알아보고 싶은 정보를 확인할 수 있습니다.

이와 같이, OLAP를 활용한 온체인 데이터 분석은 복잡한 블록체인 데이터를 이해하고 활용하는 데 있어 필수적입니다. 비록 노드 인터페이스에서와 같이 모든 데이터를 실시간으로 처리할 수는 없지만, OLAP는 대규모 데이터셋을 효율적으로 분석할 수 있도록 합니다.

3.4 온체인 데이터 분석을 위한 스킬셋?

지금까지 소개한 온체인 데이터 접근 방법들, 즉 스토리지 엔진에 직접 접근하는 방식부터 OLAP을 활용하는 방법에 이르기까지, 모두 일정 수준 이상의 코드 작성 능력을 전제로 합니다. 게다가 BigQuery, Trino와 같이 다양한 플랫폼 혹은 소프트웨어에서 표준화 되지 않은 쿼리 언어를 사용해야 하는 상황은 온체인 데이터 분석을 더욱 어렵게 할 수 있습니다.

이러한 상황 속에서 온체인 데이터 분석은 오직 코드와 쿼리 작성 능력을 가진 이들만의 영역일까요? 물론 코딩 능력이 전무하다면 데이터 분석 작업에 어려움을 느낄 수 있겠으나, 최근에는 상황이 점차 변화하고 있습니다. 바로, GPT-3.5, GPT-4, LLaMA-2 와 같은 대규모 언어 모델(Large Language Model, LLM)의 등장 덕분입니다. 이러한 모델들은 코드와 쿼리 작성을 이전보다 훨씬 용이하게 만들어주었고, 이제는 프롬프팅만 잘 해준다면 전문적인 쿼리 작성 능력 없이도 온체인 데이터 분석 작업을 수행할 수 있게 되었습니다.

물론, 이것이 비전문가도 전문가처럼 온체인 데이터 분석을 할 수 있다는 것을 의미하지는 않습니다. 그러나, 온체인 데이터 분석에 있어서 코딩이나 쿼리 작성 능력보다도 온체인 데이터에 대한 깊은 이해가 더욱 중요해졌으며, 원하는 분석 목표에 맞춰 조금 더 학습하면 누구나 온체인 데이터를 주체적으로 활용할 수 있는 시대가 되었다고는 할 수 있겠습니다.

Dune Analytics의 template 기능 화면. Source: Decipher (Dune Analytics)

Dune Analytics에서도 어떤 데이터를 어떻게 활용해서 분석 결과를 도출할 것인지에 대한 명확한 스키마가 있으면, 직접 쿼리를 작성하지 않고도 원하는 분석 결과를 얻을 수 있습니다.

Dune Analytics의 Dune AI 기능 화면. Source: Decipher (Dune Analytics)

더 나아가, Dune AI에서는 자연어 입력을 받아 SQL 쿼리를 자동으로 생성 및 실행해주는 기능까지 제공하여 온체인 데이터 분석의 접근성을 높여줍니다.

4. 마무리

본 글에서는 온체인 데이터가 무엇인지, 어떻게 저장되고, 활용되는지 전반에 대하여 살펴보았습니다. 먼저 블록체인 데이터가 무엇인지, 온체인 데이터와 오프체인 데이터가 어떻게 구분되며 활용될 수 있는지 알아보고, 블록체인 데이터를 처리하는 대표적인 유형인 EVM 기반 체인과 UTXO 기반 체인에서의 데이터 저장 방식과 핵심 요소를 분석해보았습니다. 그리고, 온체인 데이터 분석을 위하여 온체인 데이터에 접근할 수 있는 방법들에 대하여 알아보았습니다.

Web 2.0에서는 데이터가 명확하게 식별되고 쉽게 해독될 수 있음에도 불구하고, 은행 시스템과 같은 격리된 서버에 저장되어 일반 유저의 접근이 제한적이었습니다. 반면, Web 3.0에서는 데이터가 공개적으로 접근 가능한 노드에 저장되어 누구나 데이터에 접근할 수 있습니다. 하지만, 이 데이터를 의미 있게 해석할 수 없다면 그 가치를 이해하기 어렵습니다. 이러한 맥락에서, Web 3.0는 데이터 분석의 중요성과 수요가 크게 증가하는 기회의 장이라고 할 수 있습니다.

본 글이 온체인 데이터의 본질에 대한 이해를 심화시키고, 블록체인 기술과 그 안의 온체인 데이터 분석에 대한 관심을 높일 수 있는 계기가 되었기를 바랍니다. 더 나아가, 각자의 필요와 목적에 맞는 방식으로 온체인 데이터를 효과적으로 활용할 수 있는 견고한 기반을 마련할 수 있기를 바랍니다.