데이터 읽기와 쓰기의 확장성 확보하기

편집자 주: 본 글은 Tushar Jain과 Kyle Samani가 공동으로 작성하였습니다.

블록체인은 신뢰의 필요성을 최소화할 수 있는 특징들을 가진 데이터베이스입니다. 블록체인에는 다른 데이터베이스들과 마찬가지로 ‘읽기'와 ‘쓰기'라는 두 종류의 오퍼레이션이 존재합니다.

확장성을 지향하는 대부분의 블록체인이 가지고 있는 담론은 쓰기에 대한 것입니다. 이는 흔히 초당 트랜잭션(TPS)으로 측정하죠. 예를들어 이더리움의 경우 15-30 TPS, 바이낸스 스마트 체인은 160 TPS 가량, 솔라나는 50,000 TPS 수준입니다. 투자자들은 블록체인의 쓰기 능력의 확장성에 수억 달러를 투자했습니다.

블록 스페이스에 대한 수요는 기하급수적으로 증가했고, 우리는 이러한 블록체인에서 데이터를 읽는 것에 대한 수요가 훨씬 더 빠른 속도로 증가할 것으로 예상합니다. 인터넷에 있는 대부분의 주요 애플리케이션들은 기본적으로 특정 형태의 데이터베이스 애플리케이션이라고 할 수 있습니다. 그리고 대부분의 데이터베이스 애플리케이션들의 읽기 대비 쓰기의 비율은 100:1에서 10,000:1 가량됩니다. 왜 이러한 편중된 비율이 나타날까요? 당신이 10,000명의 인스타그램 팔로워가 있다고 가정해봅시다. 당신이 사진 하나를 올리고 팔로워들 중 10% 가량이 인스타그램을 켜서 사진을 보면 하나의 쓰기가(사진을 올리는 것) 1,000번의 읽기로 귀결됩니다. 만약 10,000명의 사람들이 한 자산을 거래하고 있는 상황에서 당신이 탈중앙 거래소에서 거래를 한 번 할 경우, 그 10,000명은 해당 거래를 읽어들이고 자산의 가격을 업데이트해야 합니다. 쓰기는 레이어 1 블록체인의 확장성에 의존합니다. 옵티미스틱과 zk-롤업 같은 솔루션들이 본격화되고, 솔라나와 같은 처리성능이 뛰어난 네트워크가 대중화되고 나면 쓰기가 발생하는 횟수가 폭발적으로 증가할 것이고 이는 곧 위에서 서술한 살펴본 바와 같이 읽기에 대한 기하급수적인 수요 증가로 이어질 것입니다.

블록체인 산업에 주어진 다음 중요한 과제는 바로 데이터 읽기의 확장성을 갖추는 것입니다.

대부분의 데이터베이스 애플리케이션들은 각각의 데이터 구조를 갖추고 있는데, 그 구조는 시스템에서 데이터를 어떻게 질의(쿼리) 할 것인지에 따라 달라집니다. 예를들어 텔레그램과 같은 채팅 앱을 살펴보죠. 텔레그램 시스템이 하나의 거대한 표(테이블)라고 생각하고, 그 테이블은 ‘사용자 ID’, ‘스레드 ID’, ‘타임스탬프’, ‘메시지 내용’ 헤더를 단 네개의 열로 구성되어 있다고 가정해봅시다. 이는 이론상으로는 가능한 것이지만 텔레그램을 얼마나 많은 사용자들이 쓰고 있고(5억명 이상) 거기서 얼마나 많은 양의 메시지가 매일 전송되는지를 생각해보면, 그 방식을 택할 시에는 퍼포먼스가 심각하게 저하될 것임을 짐작할 수 있습니다. 한 유저가 스레드를 클릭할 때마다 모든 쿼리가 한개의 테이블에서 발생하겠죠. 이는 매우 큰 문제를 불러일으킵니다. 쿼리를 분리해서 동일한 테이블에 쿼리를 날리지 않도록 설계하는 것이 훨씬 좋은 방식입니다.

다른 구조를 생각해볼수도 있습니다. 이번에는 각 스레드가 서로 다른 테이블에 저장되어 있고 각 테이블은 사용자 ID, 타임스탬프, 그리고 메시지 내용이라는 헤더를 보유한 세개의 열로 구성되어 있다고 가정해봅시다. 사용자가 텔레그램 UI를 클릭했을때 시스템은 해당 스레드의 메시지가 어느 테이블에 저장되어 있는지를 알고 있기 때문에 그 테이블에 신규 메시지가 있는지 쿼리를 보냅니다. 이러한 구조로 쿼리를 분리하면 퍼포먼스를 크게 개선할 수 있습니다.

블록체인에서 읽기의 확장성을 확보하는 것의 문제는 바로 그것이 블록체인이라는 점에 있습니다. 블록체인에서는 트랜잭션의 포맷을 미리 정의하지 않습니다. 블록체인은 단순한 트랜잭션의 연속입니다. 누구나 시간에 구애받지 않고 종류를 가리지 않고 트랜잭션을 발생시킬 수 있으며, 트랜잭션의 포맷은 다양하고 임의로 복잡하게 설계되어 있을 수 있습니다.

블록체인의 트랜잭션은 단일 테이블에 저장됩니다. 위의 텔레그램의 예를 통해 비추어 보면 이것이 얼마나 큰 퍼포먼스 상의 문제를 불러일으킬 수 있는지 알 수 있습니다. 블록체인에서는 애플리케이션의 종류가 한 가지로 정해져있지도 않고 특정 데이터 구조를 가지고 있다고 확정할수도 없기 때문에 이 문제는 더욱 심각해집니다. 애플리케이션은 수천가지가 있으며 각각의 애플리케이션들은 고유의 사용 방식과 데이터 구조를 가지고 있습니다.

표준 이더리움 클라이언트인 Go 이더리움(GETH) 클라이언트는 기초적인 쿼리 능력을 갖추고 있습니다. 예컨대 GETH에 “이 주소가 얼마만큼의 ETH를 가지고 있는가?” 등의 질의를 할 수 있죠. 이더리움은 머클트리 데이터 구조를 갖추고 있기 때문에 GETH는 이 질의에 대한 답을 쉽게 산출할 수 있습니다.

하지만 “이 50개의 유니스왑 풀들의 TVL이 각각 얼마만큼이고, 그 합은 얼마나 되는가?” 등의 복잡한 질의를 하는 경우를 생각해봅시다. 이 질의에 대한 답을 하기 위해서는 유니스왑 풀이 무언지 우선 알고 있어야 하며, 각 풀의 자산의 가격에 대해서도 알고 있어야 합니다.

기본적으로, GETH는 유니스왑이 무엇인지도 모르기 때문에 그러한 질의에 답변을 할 수 없습니다.

요약하면, 상호간에 관련이 있으면서도 중요한 세가지 문제가 있습니다.

1. 읽기의 확장성을 갖추는 것
2. 무엇을 쿼리를 해야하는지를 알기 위해 데이터 구조를 이해하고 있을 것
3. 쿼리 결과에 대한 검열저항성을 갖추는 것

개발자들에게 블록체인 데이터를 쿼리하는 것은 매우 힘든 과제이며, 이를 해결하기 위해서는 확장성이 있는 솔루션을 도입해야 합니다. 탈중앙화된 인덱싱 프로토콜인 The Graph는 이 문제를 해결하는데 선두에 서 있으며, 성공할 경우 “웹 3의 구글”이 될 수도 있는 프로젝트입니다.

멀티코인 캐피털은 2018년에 The Graph에 투자했으며, 쿼리 레이어가 웹 3 스택의 가장 중요한 레이어 중 하나로 부상할 것이라는게 당시의 투자 이론이었습니다. 이 글에서 The Graph를 다시 다루는 이유는 The Graph가 작게는 프로젝트 자체, 크게 보면 산업 전체에 있어 중요한 전환점에 있기 때문입니다. 크립토에서 가장 인기 있는 프로덕트 중 하나가 된 The Graph에서 호스팅한 서비스는 그 목적을 충실하게 수행했습니다. 이제 The Graph는 탈중앙화된 네트워크로 이전을 준비하고 있으며, 이러한 이전을 통해 위에서 언급한 3개의 문제들이 해결함으로서 완전히 탈중앙화된 애플리케이션의 탄생 가능성을 만들어내고 있습니다.

탈중앙성을 갖추는 것도 중요한 과제이지만, 확장성을 갖추는 것 또한 별도의 중요한 과제입니다. The Graph는 지난 해 약 20배 가량 성장하였으며 2021년 5월 한달 동안 250억 건이 넘는 쿼리를 처리했습니다. The Graph 재단은 최근 The Graph가 읽기 확장성 문제를 해결하는 것을 돕기 위해 두 건의 중요한 보조금을 조성했습니다. 첫 보조금은 인덱싱 퍼포먼스를 엄청나게 개선할 수 있는데 전문성이 있는 엔지니어들로 구성된 팀인 StreamingFast에 지급되었습니다. 두 번째 보조금은 누구나 쉽게 Graph의 노드를 개설하고 네트워크의 공급을 늘릴 수 있도록 돕는 팀인 Figment에 주어졌습니다.

첫 세대의 서브그래프가 호스티드 서비스에서 탈중앙화된 프로토콜로 이전됨에 따라 The Graph가 가진 비전이 이제 서서히 실현되어 나가고 있으며 네트워크 효과로 인해 아주 빠른 속도로 커져 가고 있습니다.

무한한 읽기 확장성 확보

모든 크립토 네트워크의 근간에는 중앙화된 조율 기관 없이 서로 간에 신뢰를 하지 않는 자들 간의 대규모 협력을 가능케 하기 위해 소프트웨어 상에 인코딩된 인센티브와 디스인센티브 체계가 있습니다. 블록체인 시스템에서 신뢰의 필요성을 최소화할 수 있는 것은 바로 이 때문입니다.

개괄적으로 설명하면, 이 프레임은 읽기의 확장성을 무한히 증가시키는 방향을 제시해줍니다. 바로 이성적이고 경제적 이유를 동기로 삼는 사람들에게 인센티브를 제공하여 그들이 데이터를 쿼리하는 사람들에게 읽기 기능을 제공하여 공급자 측에서 스스로 수요를 충당할 수 있도록 하는 크립토 경제 게임을 구축하는 것이죠.

전통 산업에서 회사들은 중앙화된 서비스를 만들고 더 많은 프로그래머들, 개발운영(dev-ops) 팀을 고용하여 대량의 서버를 관리하게 하는 낡은 방식으로 확장성을 갖춰나갔습니다. 이들은 수백만 시간을 들여 퍼포먼스와 비용을 최적화 하기 위한 아키텍쳐를 짜고 또 고치는 과정을 반복했죠.

The Graph는 다음과 같은 프로토콜입니다.

1. 독립적이고 이성적인 참여자들이 대량이 데이터세트(지원하는 블록체인의 모든 데이터)의 서브세트를 저장하고 인덱싱하는 것에 대한 인센티브를 제공합니다.
2. 이 서비스의 사용자들로 하여금 어떤 참여자들이 각각의 서브세트를 저장하고 있는지 찾을 수 있게 해줍니다.
3. 쿼리 제공자들이 잘못된 값이 아닌 유효한 결과값을 되돌려주는 것을 보장합니다.
4. 지불 절차를 관리합니다.

만일 인덱서들이(쿼리를 돌리는 사람들) 모든 요청에 대해 응답하지 못하면 어떻게 될까요?

수요가 공급을 초과하는 경우 시장의 참여자들(현재 활동중인 인덱서들과 외부자들 모두)은 모두 이 현상을 대가 지급 흐름을 통해 실시간으로 확인할 수 있습니다. 쉽게 리소스를 확보할 수 있거나 초과 리소스를 가지고 있는 사람들은 The Graph 소프트웨어를 다운로드 받고 구동시킬 수 있습니다. 이후 그들은 The Graph의 스마트 컨트랙트를 통해 스스로를 등록하여 검색될 수 있게 하고 현재 수요가 있는 데이터세트에 대한 인덱싱을 하고 사용자들을 위한 쿼리를 처리할 수 있습니다. 이러한 일련의 활동은 불과 몇분 또는 몇시간내에 완료될 수 있고 100% 자동화될 수 있습니다.

더 간단히 이야기하면, 쿼리 서비스에 대한 수요가 증가할수록, 이성적이고 경제적인 동기를 가지고 있는 공급자들은 스스로 나서서 그 수요를 충족시킬 것입니다. Kyle이 이 이론에서 2년 전 일반적인 용어로 설명한 바 있습니다.

데이터 구조의 확장성 확보

데이터 구조 문제를 해결하는데는 두 가지의 기술적 해법이 있습니다.

1) GETH에 모든 유니스왑 풀과 그 풀들과 관련된 모든 트랜잭션들(예: 입금, 출금, 거래 등)에 대해 질의한 후 GETH 외부의 프로그램으로 TVL을 계산하는 방법이 있습니다. 누군가가 해당 질의를 다시 하면 앞의 과정을 다시 반복해서 결과를 산출하여 업데이트 된 값을 제공하면 됩니다.

2) 거대한 테이블의 끝에 새로운 이더리움 트랜잭션이 추가될 때마다 시스템이 유니스왑 풀과 관련이 있는 것인지를 감지하고 관련이 있는 경우 GETH 외부에 있는 데이터베이스의 필드에 새로운 값을 기록하도록 하는 별도의 데이터 구조를 정의하는 방법이 있습니다.

The Graph는 #2 솔루션(이는 서브그래프 매니페스트라고 부릅니다) 방식대로 데이터 구조를 정의하여, 매니페스트 파일을 기반으로 한 데이터베이스 인덱싱 서비스와 탈중앙화된 노드 네트워크로 운영되는 실시간 쿼리 시스템을 구축할 수 있도록 하는 프레임워크를 제공해줍니다.

뿐만 아니라, The Graph는 2015년에 페이스북이 개발하고 오픈소스화한 쿼리 언어인 GraphQL을 사용하는 개발자들에게 쿼리를 노출해줍니다. GraphQL은 사용하기 매우 쉽기 때문에 개발자들을 위한 쿼리 인터페이스의 표준과도 같은 존재가 되었습니다. GraphQL의 우수성에 대한 좀 더 기술적인 설명은 여기에서 확인하실 수 있습니다.

앞서 언급한 문제를 해결하려는 솔루션은 다양합니다. 우리는 시장 세그먼트가 아래와 같이 나뉘어진다고 보고 있습니다.

포켓 네트워크는 유일하게 우하단에 위치해있다는 점에서 흥미롭습니다. The Graph의 성공을 토대로 볼 때, 개발자들은 더 빠르고 쉽다는 점에서 GETH에 RPC 호출을 하는 것보다 GraphQL과 서브그래프를 사용해 개발하는 것을 선호하는 것으로 보입니다.

검열저항성과 보안의 확장성 확보

The Graph의 최대 경쟁자는 Infura입니다. 그러나 Influra는 지나치게 단순한 서비스입니다. 수천의 GETH 노드들 간의 로드 밸런서에 불과하죠. 고차원적인 앱스트랙션은 엄두도 내지 못합니다. 다른 경쟁자들은 Infura 규모의 파편정도에 불과합니다.

Infura는 그것을 사용하는 디앱들의 중앙화된 병목지점이 됩니다. 디앱이 검열저항성을 갖추기 위해서는 중앙화된 통제요소를 반드시 제거해야합니다. 만일 Infura가 공격을 받아 사용자가 디앱을 사용할 수 있는 기능이 멈추어버린다면 이는 아주 큰 위협 벡터가 될 것입니다. The Graph는 독립적인 사람들이 쿼리 결과를 제공하기 위해 운영하는 인프라이자 글로벌 네트워크이기 때문에 검열 저항성을 갖추고 있습니다.

만약 Graph 인덱서가 잘못된 결과값을 산출할 경우 그들은 심한 패널티를 받을 수 있습니다. 쿼리를 요청한 사람이든 피싱을 하는 제3자이든 인덱서가 올바르지 않은 결과값을 생산했음을 탐지하면 그들은 블록체인에 그 잘못된 결과값을 보고할 수 있고 블록체인 자체가 진위 여부를 판별하는 최종 심판관의 역할을 하게 됩니다. 인덱서가 거짓말을 했다고 가정했을 때 블록체인은 인덱서의 본드(GRT로 구성된)를 슬래싱하고 악의적인 행동이 있었음을 보고한 사람에게 보상을 제공합니다.

이는 인덱서들에 의해 가장 많은 가치가 스테이킹 된, 가장 큰 쿼리 생태계가 가장 안전한 쿼리 시스템임을 의미합니다. 이는 다음과 같은 피드백 루프를 형성합니다.

결론

왜 탈중앙화를 하는가에 대해 묻는다면, 다음을 가능케 하기 때문이라고 답할 수 있습니다.

1. 작동을 멈출 수 없고 검영저항성이 있는, 완전한 서버없는 애플리케이션들
2. 데이터를 최대한 “말단"으로 옮겨 지연을 줄이고 퍼포먼스를 증가시킬 수 있음
3. 매일 수백만에서 수조 쿼리를 처리할 수 있는 확장성을 갖출 수 있는 훨씬 더 효율적인 방법

사람들은 탈중앙화에 대해 이야기할 때 그저 비트코인 처럼 검열저항성의 맥락에서만 이야기를 하곤 합니다. 이를 획득하는 가장 근본적인 메커니즘은 과도할 정도로 풍부한 리소스를 확보하는 것입니다.

The Graph의 경우, 탈중앙성을 확보하는 것은 검열저항성과 확장성을 모두 확보하는 결과로 이어집니다. 전 세계의 누구나 Graph 서버를 돌릴 수 있고 서브그래프 별로 어떤 쿼리 수요가 있는지 실시간으로 확인할 수 있습니다. 때문에 전세계의 기업형 개발자들/컴퓨터 너드들은 어떤 서브그래프가 공급 부족에 시달리고 있는지 파악하고 Graph 노드를 빠르게 만들어내어 쿼리를 제공하여 수입을 창출할 수 있습니다. 바로 이것이 Graph의 무한한 확장성의 동력임과 동시에 검열저항성을 갖추도록 하는 힘입니다.

이것이 바로 탈중앙화의 진정한 힘입니다.

고지사항: 멀티코인은 자사의 투자 활동과 관련하여 이해 충돌을 식별하고 효과적으로 관리할 수 있는 합리적 절차와 서면 작성된 정책을 수립하고 유지해오고 있습니다. 또한, 자사는 본 글의 공식 발행 이후 본 글에 언급된 자산에 대해 3일(‘무거래 기간’)동안 ‘거래 금지 정책’을 따를 것입니다. 발행 시점 당시, 멀티코인 캐피털은 GRT에 포지션을 보유하고 있습니다.