저자: shew

요약

GCC Research 칼럼의 "암호 공유지의 비극" 시리즈에 오신 것을 환영합니다.

이 시리즈에서는 암호화폐 세계에서 규범을 점점 더 충족하지 못하고 있는 핵심 공공재에 초점을 맞출 것입니다. 이는 전체 생태계의 기본 인프라이지만, 인센티브 부족, 불균형적인 거버넌스, 심지어 중앙집중화 심화와 같은 문제에 직면하는 경우가 많습니다. 암호화폐 기술의 이상과 중복성 및 안정성이라는 현실은 이러한 영역에서 심각한 시험대에 오르고 있습니다.

이번 호에서는 이더리움 생태계에서 가장 영향력 있는 애플리케이션 중 하나인 폴리마켓(Polymarket)과 그 데이터 인덱싱 도구에 초점을 맞춥니다. 올해 폴리마켓은 트럼프 대통령 당선, 우크라이나 희토류 거래에서의 오라클 조작, 그리고 젤렌스키 대통령의 정장 색깔에 대한 정치적 베팅을 둘러싼 사건들을 중심으로 여론의 중심에 섰습니다. 폴리마켓이 지닌 막대한 자본과 시장 영향력은 이러한 논란을 더욱 어렵게 만듭니다.

하지만 이 제품의 핵심 구성 요소인 데이터 인덱싱은 "탈중앙화된 예측 시장"을 대표하는 제품으로서 과연 진정으로 탈중앙화된 것일까요? The Graph와 같은 공공 인프라는 왜 본래의 역할을 다하지 못했을까요? 진정으로 유용하고 지속 가능한 데이터 인덱싱 공공재는 어떤 형태를 취해야 할까요?

1. 중앙집중형 데이터 플랫폼의 다운타임으로 인한 연쇄반응

2024년 7월, 골드스카이(Goldsky)는 6시간 동안의 서비스 중단을 경험했습니다. 골드스카이는 웹 3.0 개발자를 위한 실시간 블록체인 데이터 인프라 플랫폼으로, 인덱싱, 서브그래프, 스트리밍 데이터 서비스를 제공하여 데이터 기반 탈중앙화 애플리케이션을 신속하게 구축할 수 있도록 지원합니다. 이로 인해 이더리움 생태계의 상당 부분이 마비되었습니다. 예를 들어, DeFi 프런트엔드는 사용자 포지션과 잔액 데이터를 표시할 수 없었고, 예측 시장인 폴리마켓(Polymarket)은 정확한 데이터를 표시할 수 없었습니다. 프런트엔드 사용자들은 수많은 프로젝트를 전혀 사용할 수 없는 것처럼 보였습니다.

분산 애플리케이션 세계에서 이런 일은 일어나서는 안 됩니다. 결국 블록체인 기술은 단일 장애 지점을 없애도록 설계되지 않았습니까? 골드스키 사건은 불편한 진실을 드러냈습니다. 블록체인 자체는 최대한 분산화되어 있지만, 블록체인을 기반으로 구축된 애플리케이션의 인프라에는 종종 수많은 중앙 집중식 서비스가 포함되어 있다는 것입니다.

그 이유는 블록체인 데이터 색인 및 검색이 비배타적이고 비경합성인 디지털 공공재이기 때문입니다. 사용자는 종종 이러한 서비스가 무료이거나 매우 저렴할 것이라고 기대하지만, 이러한 서비스는 하드웨어, 스토리지, 대역폭 및 운영 인력에 대한 지속적이고 집중적인 투자를 필요로 합니다. 지속 가능한 수익 모델이 없다면 승자 독식의 중앙 집중식 구조가 형성됩니다. 서비스 제공업체가 속도와 자본에서 선점 우위를 점하게 되면, 개발자들은 모든 쿼리 트래픽을 해당 서비스로 유도하여 단일 종속 지점을 재구축하는 경향이 있습니다. 깃코인(Gitcoin)과 같은 공익 프로젝트는 "오픈소스 인프라는 수십억 달러의 가치를 창출할 수 있지만, 개발자들은 종종 이를 통해 대출금을 상환할 수 없다"고 반복해서 강조해 왔습니다.

이는 탈중앙화된 세계가 공공재 자금 지원, 재분배, 또는 커뮤니티 주도 이니셔티브를 통해 Web3 인프라를 시급히 다각화해야 함을 강력하게 일깨워줍니다. 그렇지 않으면 중앙화 현상이 불가피하게 발생할 것입니다. DApp 개발자는 로컬 기반 제품을 개발하고, 기술 커뮤니티는 DApp 설계 시 데이터 검색 서비스 장애를 고려하여 데이터 검색 인프라 없이도 사용자가 프로젝트와 원활하게 상호 작용할 수 있도록 해야 합니다.

2. Dapp에서 보는 데이터는 어디에서 나오나요?

골드스키와 같은 사고가 발생하는 이유를 이해하려면 DApp의 작동 원리를 더 깊이 파고들어야 합니다. 일반 사용자에게 DApp은 일반적으로 온체인 컨트랙트와 프런트엔드, 두 부분으로 구성됩니다. 대부분의 사용자는 이더스캔과 같은 도구를 사용하여 온체인 거래 상태를 추적하고, 프런트엔드에서 필요한 정보를 얻고, 거래를 시작하고, 컨트랙트와 상호 작용하는 데 익숙합니다. 하지만 사용자 프런트엔드에 표시되는 이러한 데이터는 실제로 어디에서 오는 것일까요?

필수 데이터 검색 서비스

사용자의 보유 자산과 각 포지션의 마진 및 부채 상태를 표시해야 하는 대출 프로토콜을 구축한다고 가정해 보겠습니다. 프런트엔드가 체인에서 직접 이 데이터를 읽어오도록 하는 것은 순진한 생각입니다. 그러나 실제로 대출 프로토콜 계약은 사용자 주소가 포지션 데이터를 쿼리하는 것을 허용하지 않습니다. 계약은 포지션 ID를 사용하여 포지션의 특정 데이터를 쿼리하는 함수를 제공합니다. 따라서 프런트엔드에 사용자의 포지션 상태를 표시하려면 현재 시스템의 모든 포지션을 검색한 다음 현재 사용자에게 속한 포지션을 찾아야 합니다. 이는 누군가에게 수백만 페이지의 원장에서 특정 정보를 수동으로 검색하도록 요청하는 것과 같습니다. 기술적으로는 가능하지만 매우 느리고 비효율적입니다. 실제로 프런트엔드가 이러한 검색 프로세스를 완료하는 것은 어렵습니다. 대규모 DeFi 프로젝트의 검색 작업이 로컬 노드가 서버에서 직접 수행하더라도 종종 몇 시간이 걸립니다.

따라서 데이터 수집을 가속화하기 위한 인프라를 구축해야 합니다. Goldsky와 같은 기업들이 이러한 데이터 인덱싱 서비스를 제공합니다. 다음 다이어그램은 애플리케이션에 제공할 수 있는 데이터 인덱싱 서비스 유형을 보여줍니다.

이 시점에서 일부 독자들은 이더리움 생태계 내에 TheGraph라는 탈중앙화 데이터 검색 플랫폼이 존재하는지 궁금해할 수 있습니다. 이 플랫폼과 Goldsky는 어떤 관련이 있을까요? 그리고 많은 DeFi 프로젝트들이 더 탈중앙화된 TheGraph 대신 Goldsky를 데이터 제공자로 사용하는 이유는 무엇일까요?

TheGraph/Goldsky와 SubGraph의 관계

위의 질문에 답하려면 먼저 몇 가지 기술적 개념을 이해해야 합니다.

1. SubGraph는 개발자가 온체인 데이터를 읽고 요약하는 코드를 작성하고, 특정 메서드를 사용하여 이 데이터를 읽고 프런트엔드에 표시하는 데 사용할 수 있는 개발 프레임워크입니다.
2. TheGraph는 AssemblyScript로 작성된 SubGraph 프레임워크를 개발한 초기 분산형 데이터 검색 플랫폼입니다. 개발자는 이 SubGraph 프레임워크를 사용하여 계약 이벤트를 캡처하고 데이터베이스에 기록하는 프로그램을 작성할 수 있습니다. 사용자는 Graphql 메서드를 사용하여 이 데이터를 읽거나 SQL 코드를 직접 사용하여 데이터베이스를 읽을 수 있습니다.
3. 일반적으로 SubGraph를 운영하는 서비스 제공자를 SubGraph 운영자라고 합니다. TheGraph와 Goldsky는 모두 SubGraph 호스트입니다. SubGraph는 개발 프레임워크이므로 이를 사용하여 개발된 애플리케이션은 서버에서 실행되어야 합니다. Goldsky 문서에서 다음을 확인할 수 있습니다.

여기 독자 중 일부는 SubGraph에 여러 개의 연산자가 있는 이유가 궁금할 것입니다.

이는 SubGraph 프레임워크가 실제로 블록 내에서 데이터베이스에서 데이터를 읽고 쓰는 방법만 규정하기 때문입니다.

SubGraph 프로그램으로 데이터가 어떻게 유입되는지, 그리고 최종 출력 결과가 어떤 종류의 데이터베이스에 기록되는지에 대한 구현은 없습니다. 이러한 내용은 SubGraph 연산자가 직접 구현해야 합니다.

일반적으로 SubGraph 연산자는 더 빠른 속도를 달성하기 위해 노드를 수정합니다. TheGraph, Goldsky 등 연산자마다 전략과 기술적 솔루션이 다릅니다.

TheGraph는 현재 Firehouse 기술 솔루션을 사용하고 있습니다. 이 기술 솔루션 도입 후 TheGraph는 이전보다 더 빠른 데이터 검색을 달성할 수 있게 되었습니다. 그러나 Goldsky는 SubGraph를 구동하는 핵심 프로그램을 공개하지 않았습니다.

위에서 언급했듯이 TheGraph는 분산형 데이터 검색 플랫폼입니다. Uniswap v3 서브그래프를 예로 들면, Uniswap v3에 대한 데이터 검색을 제공하는 많은 운영자가 있다는 것을 알 수 있습니다. 따라서 TheGraph는 서브그래프 운영자를 위한 통합 플랫폼이라고 할 수 있습니다. 사용자는 자신의 서브그래프 코드를 TheGraph에 전송할 수 있으며, TheGraph 내부에는 사용자가 데이터를 검색하는 데 도움을 줄 수 있는 운영자가 있습니다.

골드스키의 가격 모델

Goldsky와 같은 중앙 집중형 플랫폼의 경우, Goldsky는 리소스 사용량에 기반한 간단한 청구 시스템을 사용합니다. 이는 인터넷에서 가장 일반적인 SaaS 청구 방식이며, 대부분의 기술 담당자가 잘 알고 있습니다. 아래 그림은 Goldsky의 가격 계산기를 보여줍니다.

TheGraph의 가격 모델

TheGraph는 기존 청구 방식과 완전히 다른 수수료 구조를 가지고 있습니다. 이 수수료 구조는 GRT의 토큰 경제학과 관련이 있습니다. 다음 그림은 GRT의 전반적인 토큰 경제학을 보여줍니다.

1. DApp이나 지갑이 Subgraph에 요청을 할 때마다 지불된 쿼리 수수료는 자동으로 분할됩니다. 1%는 소각되고, 약 10%는 Subgraph의 큐레이션 풀(큐레이터/개발자)로 흘러 들어가며, 나머지 약 89%는 지수 리베이트 메커니즘에 따라 컴퓨팅 파워를 제공하는 인덱서와 위임자에게 지불됩니다.
2. 인덱서는 온라인 접속 전에 10만 GRT 이상을 스테이킹해야 합니다. 잘못된 데이터를 반환할 경우 삭감됩니다. 위임자는 GRT를 인덱서에게 위임하고, 앞서 언급된 89% 중 비례적으로 몫을 받습니다.
3. 큐레이터(일반적으로 개발자)는 Signal을 사용하여 자신의 Subgraph 본딩 곡선에 GRT를 스테이킹합니다. Signal 수치가 높을수록 더 많은 인덱서가 자원을 할당하게 됩니다. 커뮤니티 경험에 따르면 여러 인덱서의 주문을 확보하기 위해 5,000~10,000 GRT를 모금하는 것이 좋습니다. 큐레이터는 로열티의 10%도 받습니다.

TheGraph의 쿼리당 수수료:

TheGraph 백엔드에 API 키를 등록하고, 해당 API 키를 사용하여 TheGraph 운영자가 검색한 데이터를 요청하세요. 이러한 요청은 요청 수에 따라 요금이 부과됩니다. 개발자는 API 요청 비용으로 GRT 토큰의 일부를 플랫폼에 미리 예치해야 합니다.

TheGraph의 Signal 스테이킹 수수료:

SubGraph 배포자는 TheGraph 플랫폼 내 운영자의 도움을 받아 데이터를 검색해야 합니다. 위에서 언급한 수익 분배 방식에 따라, 다른 참여자들에게 제 쿼리 서비스가 더 좋고 더 많은 수익을 얻을 수 있다고 알려야 합니다. GRT를 스테이킹해야 하는데, 이는 광고와 유사하며 수익을 보장하여 사람들이 참여하도록 유도하는 방식입니다.

테스트 기간 동안 개발자는 SubGraph를 TheGraph 플랫폼에 무료로 배포할 수 있습니다. TheGraph는 사용자의 일부 검색을 지원하고 테스트 목적으로 무료 할당량을 제공합니다. 이 할당량은 프로덕션 환경에는 적합하지 않습니다. 개발자가 SubGraph가 TheGraph의 공식 테스트 환경에서 잘 작동한다고 판단하면 공개 네트워크에 게시하고 다른 운영자가 검색에 참여할 때까지 기다릴 수 있습니다. 개발자는 단일 운영자에게 보장된 검색 액세스를 위해 직접 비용을 지불할 수 없습니다. 대신 여러 운영자가 서비스를 제공하기 위해 경쟁하여 단일 종속성을 피합니다. 이 프로세스는 GRT 토큰을 사용하여 SubGraph에서 큐레이션(시그널링이라고도 함)을 수행해야 합니다. 이를 위해 개발자는 배포된 SubGraph에 일정량의 GRT를 스테이킹해야 합니다. 운영자는 스테이킹된 GRT가 특정 수준(이전에는 10,000 GRT)에 도달할 때만 SubGraph 검색 프로세스에 참여합니다.

불량한 청구 경험은 개발자와 전통적인 회계사를 곤란하게 만듭니다.

대부분의 프로젝트 개발자에게 TheGraph 사용은 비교적 번거로운 과정입니다. Web3 프로젝트의 경우 GRT 토큰 구매는 비교적 쉽지만, 배포된 SubGraph를 큐레이팅하고 운영자를 기다리는 과정은 매우 비효율적입니다. 이 과정은 최소 두 가지 문제를 야기합니다.

1. 스테이킹할 GRT 양의 불확실성과 운영자 유치에 걸리는 시간. 과거 SubGraph를 배포했을 때, 저는 TheGraph 커뮤니티 앰배서더와 직접 협의하여 스테이킹할 GRT 양을 결정했습니다. 하지만 대부분의 개발자에게는 이 데이터를 얻기가 쉽지 않습니다. 게다가 충분한 GRT를 스테이킹한 후에도 운영자가 개입하여 정보를 찾는 데 시간이 걸립니다.
2. 비용 계산 및 회계 복잡성. TheGraph는 토큰 경제학을 사용하여 수수료 구조를 설계하기 때문에 대부분의 개발자에게 비용 계산이 복잡해집니다. 더 현실적으로, 기업이 이러한 비용을 회계 처리한다면 회계 담당자가 비용 구조를 제대로 이해하지 못할 수도 있습니다.

"좋은 게 낫냐, 중앙집중화하는 게 낫냐?"

물론 대부분의 개발자에게는 Goldsky를 직접 선택하는 것이 더 간단합니다. 청구 방식은 누구나 쉽게 이해할 수 있으며, 결제만 하면 거의 즉시 사용할 수 있어 불확실성이 크게 줄어듭니다. 이로 인해 블록체인 데이터 인덱싱 및 검색 서비스에서 단일 제품에 의존하는 상황이 발생하기도 했습니다.

TheGraph의 복잡한 GRT 토큰 경제는 분명 광범위한 도입을 저해했습니다. 토큰 경제가 복잡할 수는 있지만, 이러한 복잡성이 사용자에게 노출되어서는 안 됩니다. 예를 들어, GRT의 큐레이션 및 스테이킹 메커니즘은 사용자에게 노출되어서는 안 됩니다. 더 나은 접근 방식은 사용자에게 간소화된 결제 페이지를 제공하는 것입니다.

TheGraph에 대한 위의 비방은 제 개인적인 의견이 아닙니다. 저명한 스마트 컨트랙트 엔지니어이자 Sablier 프로젝트의 창립자인 Paul Razvan Berg 또한 트윗을 통해 이러한 의견을 표명했습니다. 해당 트윗은 SubGraph와 GRT 청구 시스템 출시 시 사용자 경험이 매우 좋지 않았다고 언급했습니다.

3. 기존 솔루션

데이터 검색의 단일 실패점(SPOF)을 해결하는 방법에 대해서는 이미 위에서 언급했습니다. 즉, 개발자는 TheGraph 서비스 사용을 고려할 수 있지만, 절차가 더 복잡해질 것입니다. 개발자는 큐레이션 스테이킹 및 API 수수료 지불을 위해 GRT 토큰을 구매해야 합니다.

현재 EVM 생태계에는 다양한 데이터 검색 소프트웨어가 있습니다. 자세한 내용은 Dune이 작성한 "EVM 인덱싱 현황"이나 rindexer가 작성한 EVM 데이터 검색 소프트웨어 요약을 참조하세요. 최근 논의 내용은 이 트윗을 참조하세요.

이 문서에서는 Glodsky 문제의 구체적인 원인을 다루지 않습니다. Glodsky는 현재 원인을 알고 있지만 기업 사용자에게만 공개하고 있습니다. 즉, 현재로서는 제3자가 Glodsky 문제의 정확한 원인을 파악할 수 없습니다. 보고서를 바탕으로, 검색된 데이터를 데이터베이스에 쓰는 데 문제가 있었을 가능성이 있다고 추론할 수 있습니다. 이 간략한 보고서에서 Glodsky는 데이터베이스에 접근할 수 없었으며 AWS와 협력한 후에야 접근이 복구되었다고 언급했습니다.

이 섹션에서는 주로 다른 솔루션을 소개합니다.

1. 포더(Poder)는 뛰어난 개발 경험과 손쉬운 배포를 갖춘 간편한 데이터 검색 서비스 소프트웨어입니다. 개발자는 서버를 임대하여 직접 배포할 수 있습니다.
2. 로컬 우선(Local-first)은 네트워크 연결이 끊긴 상황에서도 개발자가 우수한 사용자 경험을 제공하도록 장려하는 흥미로운 개발 개념입니다. 블록체인이 존재하면 로컬 우선의 제약을 어느 정도 완화하여 사용자가 블록체인에 접속할 때 우수한 사용자 경험을 제공할 수 있습니다.

숙고하다

다른 소프트웨어 대신 ponder를 추천하는 이유는 무엇일까요? 구체적인 이유는 다음과 같습니다.

1. Ponder는 공급업체 의존성이 없습니다. Ponder는 원래 개인 개발자들이 개발한 프로젝트였기 때문에 다른 회사에서 제공하는 다른 데이터 검색 소프트웨어와 달리, Ponder는 사용자가 Ethereum RPC URL과 Postgres 데이터베이스 링크만 입력하면 됩니다.
2. Ponder는 훌륭한 개발 환경을 제공합니다. 저는 과거에 Ponder를 개발에 여러 번 사용해 왔습니다. Ponder는 TypeScript로 작성되었고 핵심 라이브러리는 주로 Viem을 사용하기 때문에 개발 환경이 매우 좋습니다.
3. Ponder는 더 높은 성능을 가지고 있습니다

물론 몇 가지 문제가 있습니다. Ponder는 아직 빠르게 개발 중이므로, 개발자들은 이전 프로젝트가 업데이트로 인해 작동하지 않는 상황에 직면할 수 있습니다. 이 글은 기술적인 소개가 아니므로 Ponder 개발 과정에 대한 자세한 내용은 다루지 않겠습니다. 기술적인 지식이 있는 독자는 관련 문서를 참고하시기 바랍니다.

폰더에 대한 더 흥미로운 세부 사항은 부분적 상용화를 시작했다는 점인데, 폰더의 상용화 경로는 이전 기사에서 논의한 "격리 이론"과 매우 일치합니다.

여기서는 "분리 이론"을 간략하게 소개합니다. 공공재의 공공성으로 인해 무제한의 사용자에게 서비스를 제공할 수 있다고 주장합니다. 따라서 공공재에 요금을 부과하면 일부 사용자는 사용을 중단하게 되고, 사회적 편익은 극대화되지 않습니다(이를 경제학 용어로 "더 이상 파레토 최적이 아니다"라고 합니다). 이론적으로 공공재는 사용자마다 다른 가격을 책정할 수 있지만, 차등 가격 책정으로 인한 비용이 편익을 상회할 가능성이 높습니다. 따라서 공공재가 무료인 이유는 본질적으로 무료이기 때문이 아니라, 고정된 요금이 사회적 편익을 해치고, 현재로서는 각 사용자에게 차등 가격을 책정할 저렴한 방법이 없기 때문입니다. 분리 이론은 공공재 내에서 가격을 책정하는 한 가지 방법을 제시합니다. 즉, 동질적인 집단을 고립시키고 그들에게 요금을 부과하는 것입니다. 분리 이론이 모든 사람이 공공재를 무료로 누리는 것을 막지는 않지만, 일부 사람들에게 요금을 부과하는 방법을 제시합니다.

Ponder는 고립 이론과 유사한 방법을 사용합니다.

1. 우선, ponder를 배포하려면 특정 지식이 필요합니다. 개발자는 배포 과정에서 RPC 및 데이터베이스와 같은 외부 종속성을 제공해야 합니다.
2. 배포 후 개발자는 Ponder 애플리케이션을 지속적으로 운영하고 유지 관리해야 합니다. 예를 들어, 데이터 요청이 백그라운드 스레드에서 Ponder의 온체인 데이터 검색에 영향을 미치지 않도록 로드 밸런싱을 위한 프록시 시스템을 사용해야 합니다. 이는 일반 개발자에게는 다소 복잡한 작업입니다.
3. 현재 Ponder는 완전 자동 배포 서비스인 marble의 내부 테스트를 진행 중입니다. 사용자는 플랫폼에 코드만 전달하면 자동 배포가 가능합니다.

이는 분명히 "격리 이론" 원칙을 적용한 것입니다. Ponder 서비스를 직접 운영하고 유지 관리할 의향이 없는 개발자는 고립되고, 이러한 개발자는 유료로 간소화된 Ponder 배포 서비스를 이용할 수 있습니다. 물론 Marble 플랫폼의 등장이 다른 개발자들이 Ponder 프레임워크를 사용하여 무료 및 자체 호스팅 배포를 하는 것을 막지는 못했습니다.

폰더와 골드스키의 청중은 누구였을까?

1. 완전히 공급업체에 의존하지 않는 공공재인 Ponder는 다른 공급업체에 의존하는 데이터 검색 서비스보다 소규모 프로젝트를 개발하는 데 더 인기가 있습니다.
2. 대규모 프로젝트를 운영하는 일부 개발자는 반드시 ponder 프레임워크를 선택하지 않습니다. 대규모 프로젝트에서는 종종 검색 서비스가 충분한 성능을 갖춰야 하며 Goldsky와 같은 서비스 제공자는 충분한 가용성을 보장하는 경우가 많기 때문입니다.

둘 다 위험이 있습니다. 최근 골드스키 사건에서 알 수 있듯이, 개발자는 잠재적인 타사 서비스 중단을 완화하기 위해 자체적인 폰더 서비스를 유지하는 것이 좋습니다. 또한, 폰더를 사용할 때는 RPC 반환 데이터의 유효성을 고려해야 합니다. 최근 Safe는 잘못된 RPC 반환 데이터로 인해 검색 엔진이 다운되었다고 보고했습니다. 골드스키 사건이 잘못된 RPC 반환 데이터와 관련이 있다는 직접적인 증거는 없지만, 골드스키도 비슷한 문제를 겪었을 가능성이 있다고 생각합니다.

지역 우선 개발 철학

로컬 우선 전략은 지난 몇 년 동안 뜨거운 화두였습니다. 간단히 말해, 로컬 우선 전략을 구현하려면 소프트웨어에 다음과 같은 기능이 필요합니다.

1. 오프라인 작업
2. 클라이언트 간 협업

현재 로컬 우선 기술과 관련된 대부분의 논의는 CRDT(Conflict-free Replicated Data Type)를 다룹니다. CRDT는 사용자가 여러 기기에서 작업할 때 충돌을 자동으로 해결하고 데이터 무결성을 유지할 수 있도록 하는 충돌 없는 데이터 형식입니다. CRDT를 간단히 설명하면, 간단한 합의 프로토콜을 사용하는 데이터 유형이라고 볼 수 있습니다. 분산 환경에서 CRDT는 데이터 무결성과 일관성을 보장할 수 있습니다.

하지만 블록체인 개발에서는 앞서 언급한 로컬 우선(local-first) 소프트웨어 요구 사항을 완화할 수 있습니다. 프로젝트 개발자가 제공하는 백엔드 인덱싱 데이터 없이도 사용자가 프런트엔드에서 최소한의 사용성을 유지하면 됩니다. 더 나아가, 블록체인은 클라이언트 간 협업을 위한 로컬 우선 요구 사항을 이미 충족하고 있습니다.

DApp의 맥락에서 로컬 우선 개념은 다음과 같이 구현될 수 있습니다.

1. 캐시 키 데이터: 프런트엔드는 잔액 및 보유 자산과 같은 중요한 사용자 데이터를 캐시해야 하므로 인덱싱 서비스를 사용할 수 없는 경우에도 사용자는 마지막으로 알려진 상태를 볼 수 있습니다.
2. 성능 저하 기능 설계: 백엔드 인덱스 서비스를 이용할 수 없을 때 DApp은 기본적인 기능을 제공할 수 있습니다. 예를 들어, 데이터 검색 서비스를 이용할 수 없을 때 RPC를 사용하여 체인에서 일부 데이터를 직접 읽어올 수 있으며, 이를 통해 사용자는 기존 데이터의 최신 상태를 확인할 수 있습니다.

이 로컬 우선 DApp 설계 철학은 애플리케이션 복원력을 크게 향상시켜 데이터 검색 서비스 장애 발생 시 가용성 손실을 방지합니다. 사용성과 관계없이, 최고의 로컬 우선 애플리케이션은 사용자가 로컬 노드를 실행한 후 Trueblocks와 같은 도구를 사용하여 로컬에서 데이터를 검색하도록 요구합니다. 탈중앙화 또는 로컬 검색에 대한 자세한 내용은 "말 그대로 아무도 탈중앙화 프런트엔드와 인덱서에 관심이 없다"라는 게시물을 참조하십시오.

4. 마무리 생각

6시간 동안 이어진 골드스키(Goldsky) 시스템 중단 사태는 생태계에 경종을 울렸습니다. 블록체인은 본질적으로 탈중앙화와 단일 장애점(SPOF)에 대한 저항성을 제공하지만, 이를 기반으로 구축된 애플리케이션 생태계는 여전히 중앙 집중식 인프라 서비스에 크게 의존하고 있습니다. 이러한 의존성은 전체 생태계에 시스템적 위험을 초래합니다.

이 글에서는 오랜 역사를 가진 분산형 검색 서비스인 TheGraph가 오늘날 널리 사용되지 않는 이유를 간략하게 설명하며, 특히 GRT 토큰 경제로 인해 발생하는 복잡성에 대해 논의합니다. 마지막으로, 더욱 강력한 데이터 검색 인프라를 구축하는 방법을 다룹니다. 개발자들이 Ponder 셀프 호스팅 데이터 검색 프레임워크를 비상 대응 옵션으로 활용하고, Ponder의 유망한 상용화 경로를 제시할 것을 권장합니다. 마지막으로, 로컬 우선 개발 철학을 통해 개발자들이 데이터 검색 서비스 없이도 작동 가능한 애플리케이션을 구축하도록 장려합니다.

현재 많은 Web3 개발자들이 데이터 검색 서비스의 단일 장애점 문제를 인지하고 있습니다. GCC는 더 많은 개발자들이 이 인프라에 관심을 갖고 분산형 데이터 검색 서비스를 구축하거나, DApp 프런트엔드가 데이터 검색 서비스 없이도 실행될 수 있는 프레임워크를 설계하기를 기대합니다.