블록체인 데이터 접근법과 난점
On-Chain Analysis; 두 번째 - Amberdata #1
필력이 부족해 직접 글을 작성하는 것을 꺼렸지만, 이번 포스트에서 소개할 기업의 경우, 블로그의 목적이 가이드 및 대외 홍보라는 카테고리에 국한되어 있는 편이기에, 어쩔 수 없이 번역이 아닌 오리지널 포스팅을 하게 되었다.
어쩌면 데이터 노다지 블록체인
현대의 거의 모든 비즈니스는 디지털 시대에 접어들었고, 이에 따라 가장 주목받는 자산이자 자원으로 데이터를 손꼽곤 한다. 데이터를 다루는 직종은 가장 섹시한, 고수익 직업으로 뽑혔고, 데이터에 관련된 수많은 사회적 이슈들이 연달아 터지곤 하며, 규제가 마련되고, 관련 산업이 부단히 성장을 하고 있는 추세다.
21세기 가장 섹시한 직업으로 데이터 사이언티스트가 언급되었다. 출처 : HBR데이터를 누가 가장 많이 쥐고 있는지, 그 데이터를 비즈니스에 적용하기 위한 인사이트와 기술을 누가 가장 많이 구비하고 있는지에 따라 향후의 경쟁 구도가 뒤집힐 것으로 보인다는 의견도 적잖이 나오고 있다.
블록체인 기술은 데이터를 언급하면 거의 반드시 따라오는 하이테크 중 하나이다. 블록체인과 그의 파생 제품들에 대한 시선이 좋지 않은 관계로, 여기서는 너무 구체적으로 논하지는 않고, 블록체인 데이터로의 접근법과 그 난점에 대해 가볍게 이야기해보겠다.
각 블록체인이 서로 다른 특성과 개념을 지니고 있으나, 우리가 여기서 살펴볼 블록체인은 가장 흔하디 흔한, 모든 거래 데이터를 투명하게 기록했으며, 비가역성을 지니고 있으며, 누구든 쉽게 데이터에 접근할 수 있도록 설계된 것을 가리킨다.
즉, IT 공룡들이 천문학적인 비용을 들여가며 데이터 센터에 보관하고 관리하는, 방대한 데이터 뭉치들의 규모에 준하지만, 모두가 접근할 수 있는 데이터 노다지가 있는 곳이다.
그러나, 블록체인을 통한 데이터로의 접근은 말처럼 그리 쉬운 것은 아니다.
Amberdata의 Shawn Douglas는 작년 이드콘 발표 당시, 블록체인 데이터를 얻는 방법은 단 3가지라고 함축했다.
첫째는 블록체인 데이터를 받기 위한 풀-노드와 그 데이터를 저장할 아카이브 노드가 필요하다는 것
두 번째는 Graph라는 데이터 쿼리 프로토콜을 이용하는 것
마지막으로 세 번째는 API Provider를 통한 데이터 수집이라고 이야기했다.
1. Full-Node & Archival Node (이더리움 + AWS)
풀-노드와 그 외 아카이브 노드를 운용할 여력이 없어, 물어보니 대강 이런 느낌이라고 한다. 더글라스에 따르면, 풀-노드와 아카이브 노드를 운용하기 위해, AWS를 사용할 수 있는데, 이렇게 되면, 보통 매 달 3000~5000달러 정도 이상의 비용이 들며, 하드웨어 및 네트워크 환경에 따라 시간 및 비용적인 자원이 더 소모될 수 있다고 이야기한다.
2. the Graph (thegraph.com)
그래프는 오픈 소스 프로토콜 언어인 Graph QL이라는 것을 사용하는데, 이 방식으로 데이터를 수집할 때 두 가지 노드가 필요한 것으로 보인다. Gateway Node와 Query Node를 운용하여, 특정 토큰 혹은 디앱과 연동하여 스마트 계약에서 발생되는 데이터를 쿼리 해오는 방식이라고 한다.
여기서 문제는, 현재 거래 가능한 토큰은 총 3000개 이상이며, 스마트 계약은 1400만 개 이상이 있다고 한다. 여기서 모든 데이터를 수집하는데 필요한 노드(Query Node로서 Subgraph Node라고 한다)는 몇 개이며, 얼마나 많은 비용이 들어가고 실제로 가능한지에 대해서 알 수가 없다는 한계가 있다고 한다.
3. API Provider (infura.io)
infura.io의 데이터 대시보드여기서 더글라스는 API가 현존하는 데이터 수집 방식에서 가장 효율적이라고 강조한다. EdCon 당시 예시를 들었던 Infura라는 API 제공자는 데이터의 “작성” 기능에 치중되어 있어, 데이터 수집 혹은 데이터 분석에 대한 기능을 제공하지 않는 싸이퍼 형태의 프로젝트라고 이야기했다. (지금은 더 다양한 기능들이 열려 있다!)
대량의 데이터를 수집하고 분석하기 위한 초기 툴로서 API 제공자가 가장 높은 효율을 자랑한다는 데에 이견은 없는 것으로 알려져 있다.
그러나 여기서 문제는, “과연 이 데이터들이 옳은가”이다.
블록체인은 데이터 소스는 맞지만, 데이터 수집 툴은 아니다. 즉 제공자가 보여주는 데이터가 옳은지를 검증할 수 있어야 한다는 것이다.
예를 들어, (발표 당시 기준) 블록체인에서 생성되는 50개의 블록 중 통상 12~20개 이상의 엉클 블록 (Uncle or Ommer)이 생성되고, 블록 당 150 개 이상의 거래내역이 포함되어 있다. 만약 여기서 블록 재구성 (Block Reorg)가 발생하고, 사용자가 이용하는 API 제공자가 이런 상황에 대한 기능적 지원을 하지 않는다면, 지금까지 받은 모든 데이터는 잘못된 데이터라고 할 수 있다.
따라서, 더글라스는 온-체인 데이터와 오프-체인 데이터를 비교하는 과정을 통해 검증을 해야 한다고 강조한다. 이에 더해, De-Fi 관련 애플리케이션들의 데이터를 확인할 때 API Provider를 사용하게 되는데, 우리가 여기서 주의해야 할 것은 과연 그들이 수십수백 개의 스마트 계약을 기반으로 작동하고 있는, 여러 De-Fi 앱들의 DelegateCall과 Internal Messages를 제공하고 있는가, 혹은 지원하고 있는가이다.
안타깝게도 아직 대부분이 이에 대한 지원을 제공하고 있지 않다.
