블록체인 데이터 심층 분석

각 블록체인은 거래 및 이벤트의 불변 기록을 보유합니다. Web3 애플리케이션은 알림, 대시보드, 의사 결정 또는 새로운 기능 개발을 위해 블록체인 데이터에 의존합니다. 이는 탈중앙화 애플리케이션부터 인프라, NFT에 이르기까지 모든 것의 기반이 되기 때문에 web3에서 매우 중요합니다.

이 가이드는 온체인 및 오프체인 데이터부터 블록체인 인덱싱과 subgraph에 이르기까지 블록체인 데이터의 모든 측면을 다룹니다. 이 가이드를 다 읽으면 블록체인 데이터가 어떻게 생성, 저장, 접근되는지 더 깊이 이해하게 될 것입니다.

온체인 데이터란?

온체인 데이터는 블록체인 네트워크에 저장된 모든 정보를 말합니다. 이는 네트워크에서 발생한 모든 거래의 불변 기록이며 누구나 열람할 수 있도록 공개되어 있습니다. 온체인 데이터에는 다음과 같은 여러 유형이 있습니다:

• 거래 데이터: 발신자와 수신자, 전송 금액, 거래 수수료 등 블록체인 상의 각 거래에 관한 정보를 다룹니다.
• 블록 데이터: 이전 블록의 해시, 블록에 포함된 거래, 블록의 타임스탬프, 채굴자 수수료 및 보상 등 블록체인 상의 각 블록에 관한 정보를 다룹니다.
• 스마트 컨트랙트 데이터: 블록체인에 배포된 모든 스마트 컨트랙트에 관한 정보로, 컨트랙트 코드 자체, 컨트랙트의 상태, 컨트랙트가 발생시킨 이벤트 등을 다룹니다.

오프체인 데이터와 달리 온체인 데이터는 변경할 수 없으며, 이는 블록체인 네트워크에 대한 전체적인 시각을 얻는 데 중요합니다. 이 데이터는 블록체인 상 자산의 이동을 추적하고, 거래가 성공적으로 처리되었는지 확인하며, 네트워크 활동에 대한 인사이트를 얻는 데 사용될 수 있습니다.

온체인 데이터의 문제는 효과적으로 접근하기가 번거로울 수 있다는 점입니다. 쉽게 이용할 수 있음에도 불구하고, 온체인 데이터는 기계가 읽을 수 있는 형식으로 인코딩되어 있습니다. 이는 보안을 우선시하지만 사람이 읽기 쉬운 정도는 희생합니다. 사람이 읽기 쉬운 형식으로는 JSON, XML과 같은 유형이 있으며, 이때 ABI(application binary interface)가 등장하게 됩니다.

데이터 구조는 어떻게 정의되는가?

앞서 언급했듯이 온체인 데이터는 일반적인 데이터처럼 저장되지 않습니다. 대신 바이트코드와 같은 기계가 읽을 수 있는 형식으로 저장되는 경우가 많습니다.

ABI(application binary interface)는 개발자가 데이터를 모니터링하고 사람이 읽을 수 있는 형식으로 디코딩하는 데 도움을 줍니다. 스마트 컨트랙트의 데이터 구조는 ABI를 사용하여 정의됩니다. ABI는 함수 선택자 역할을 하여 스마트 컨트랙트와 상호작용하는 방법과 각 함수가 받아들이고 반환하는 데이터 타입을 정의하는 데 도움을 줍니다. 다시 말해, 사람과 기계 모두가 쉽게 이해할 수 있는 방식으로 데이터 구조를 표현하는 표준 방법입니다.

블록체인 데이터는 어디에 저장되는가?

블록체인 데이터는 일반적으로 분산 원장에 저장됩니다. 즉, 단일 위치가 아니라 노드 네트워크 전체에 저장됩니다. 노드는 각 노드가 데이터의 사본을 유지하기 때문에 블록체인 데이터의 저장과 보안을 보장하는 기본 구성 요소입니다. 아래는 몇 가지 노드 유형과 이들이 대략적으로 작동하는 방식입니다:

• 풀 노드: 이름에서 알 수 있듯이 풀 노드는 전체 블록체인 히스토리와 네트워크의 최신 상태(최근 128개 블록)를 저장합니다. 최신 상태는 모든 클라이언트가 들어오는 거래를 검증하는 데 필요한 것입니다. 이론적으로 모든 이전 상태는 풀 노드에서 유도될 수 있지만, 이는 상당한 컴퓨팅 파워를 필요로 합니다. 최신 데이터와 블록체인의 상태에 접근해야 할 때 개발자는 풀 노드에 쿼리해야 합니다. 참고로 Ethereum에서 새 블록을 생성하는 평균 시간은 약 13초이며, 최근 28~29분 동안의 체인 상태만 조회할 수 있습니다.
• 아카이브 노드: 전체 블록체인 히스토리에 더해, 아카이브 노드는 모든 블록의 과거 상태에 대한 기록도 유지합니다. 이를 통해 아카이브 노드는 풀 노드에 비해 과거 데이터 요청을 훨씬 효율적으로 처리할 수 있습니다. 풀 노드처럼 상태 재생성이 필요하지 않기 때문에 과거 데이터가 필요할 때 개발자는 아카이브 노드에 쿼리해야 합니다. 분석 도구나 빠른 히스토리 접근이 필요한 다른 도구를 만드는 개발자에게는 아카이브 노드가 이상적입니다.
• 라이트 노드: 이 노드는 네트워크에서 거래하는 데 필요한 최소한의 데이터인 블록 헤더만 저장합니다. 개발자는 블록 헤더에서 기본적인 블록체인 데이터를 조회할 때 라이트 노드에 쿼리하는 것을 선택할 수 있습니다.

노드만이 데이터를 저장하는 방법은 아닙니다. 데이터는 데이터베이스, 클라우드 스토리지 서비스, 심지어 온프레미스 서버 등 오프체인에도 저장될 수 있습니다. 데이터를 오프체인에 저장하는 것이 온체인만큼 안전하지 않을 수 있지만, 저렴하고 빠르게 접근할 수 있기 때문에 여전히 많은 애플리케이션에 유용합니다. 데이터가 오프체인에 저장될 경우, 일반적으로 오프체인 데이터를 찾는 데 필요한 정보만 블록체인에 저장됩니다.

스마트 컨트랙트와 블록체인 스토리지

스마트 컨트랙트는 노드 내 블록체인에 저장되지만, 스마트 컨트랙트 자체도 데이터 저장을 위한 메커니즘을 가지고 있습니다. 스마트 컨트랙트의 데이터는 컨트랙트 스토리지 레이아웃이라는 것에 저장됩니다. 컨트랙트 스토리지 레이아웃은 컨트랙트의 스토리지 변수가 장기 메모리에 배치되는 방식을 규정하는 규칙을 말합니다.

Solidity(스마트 컨트랙트를 만들기 위한 고급 프로그래밍 언어)의 경우, EVM에 변수를 어디에 저장할지 지시할 수 있는 3가지 유형의 메모리가 있습니다: memory, calldata, storage.

Memory: 함수 실행 중 필요한 임시 데이터를 저장하는 데 사용됩니다

Calldata: 함수 인자를 포함하는 특수한 데이터 위치입니다

Storage: 블록체인에 영구적으로 데이터가 저장되는 곳입니다

데이터 스토리지 vs. 파일 스토리지

데이터 스토리지는 가장 단순한 형태로, 나중에 조회하고 사용할 수 있도록 데이터를 저장하는 과정입니다. 반면 파일 스토리지는 실제 파일이 해당 파일에 대한 메타데이터와 다른 위치에 저장될 때 데이터 스토리지와 구분됩니다. 이러한 분리는 일반적으로 성능 향상, 비용 절감, 또는 보안 강화를 위해 이루어집니다.

파일 스토리지를 데이터 스토리지와 분리하는 일반적인 방법은 IPFS나 Arweave와 같은 탈중앙화 파일 스토리지 시스템을 사용하는 것입니다. 이러한 시스템을 사용하면 사용자는 분산된 컴퓨터 네트워크에 파일을 저장할 수 있으며, 블록체인 자체에 저장해야 하는 데이터 양을 줄여 비용을 절감할 수 있습니다.

대략적으로, 파일에 대한 메타데이터는 온체인에 저장되고 파일 자체는 오프체인에 저장됩니다. 애플리케이션이 파일에 접근해야 할 때 메타데이터에서 IPFS 또는 Arweave URL을 가져올 수 있습니다. 이후 애플리케이션은 이 URL을 사용하여 IPFS 또는 Arweave에서 파일을 다운로드할 수 있습니다.

IPFS란?

IPFS는 각 파일이 CID(content identifier)를 기반으로 식별되는 콘텐츠 주소 지정 시스템을 사용합니다. CID는 저장 위치와 관계없이 항상 동일한 파일을 가리키는 고유한 해시입니다.

즉, 파일이 변경되거나 업데이트되면 해시도 변경됩니다. 이러한 콘텐츠 주소 지정 시스템 덕분에 파일은 위치가 아닌 CID를 기준으로 저장 및 조회될 수 있습니다.

IPFS가 작동하는 일반적인 흐름은 다음과 같습니다:

1. 파일에 대한 CID가 생성됩니다
2. 이후 파일이 IPFS 네트워크에 업로드됩니다
3. IPFS는 네트워크 내 어떤 노드가 해당 CID와 연결된 파일을 보유하고 있는지에 대한 정보를 DHT(distributed hash table)에 저장합니다
4. 이후 DHT를 해당 해시로 조회하여 파일을 저장하고 있는 노드를 찾을 수 있습니다
5. CID는 토큰 스마트 컨트랙트에 저장됩니다

Arweave

Arweave는 콘텐츠를 저장하고 접근하는 데 CID를 사용하며, 메타데이터에서 콘텐츠를 참조하는 또 다른 분산 스토리지 솔루션입니다. 주요 차이점은 Arweave가 노드가 데이터를 영구적으로 보관하도록 인센티브를 제공함으로써 인센티브와 영속성에 대해 다른 접근 방식을 취한다는 점입니다.

데이터 퍼블리싱 vs. 데이터 스토리지 vs. 데이터 가용성

블록체인 데이터를 더 잘 이해하려면 데이터 퍼블리싱, 스토리지, 가용성이 무엇을 의미하는지도 이해해야 합니다. 이 용어들을 간단히 정의하면: 데이터 퍼블리싱은 블록체인 상에서 데이터를 다른 사람이 이용할 수 있도록 만드는 과정이고, 데이터 스토리지는 블록체인에 데이터를 보관하는 과정이며, 데이터 가용성은 블록체인 네트워크의 모든 참여자가 데이터에 접근할 수 있음을 보장하는 것입니다.

데이터 가용성이 중요한 이유는 검증자가 Ethereum 블록체인에 블록을 추가할 때 해당 블록의 모든 거래 데이터를 네트워크 내 다른 검증자에게 방송해야 하기 때문입니다. 검증자는 모든 거래 데이터를 실행해야 하는 임무를 맡고 있으며, 이는 블록체인이 검증자가 실행할 수 있는 만큼의 거래만 처리할 수 있음을 의미합니다. 이것이 데이터 가용성 문제를 간단히 요약한 것입니다.

핵심적인 데이터 가용성 문제 중 하나는 전체 블록에 접근하지 않고도(데이터 퍼블리싱 없이) 블록이 공개되었는지 여부를 아는 것입니다.

데이터 퍼블리싱의 주요 문제는 블록 생성자가 알 수 없는 내용을 포함한 블록 위에 새로운 블록을 생성하지 않는다는 점입니다. 이는 공개되지 않은 데이터를 포함한 블록이 완전히 무시될 수 있음을 의미합니다. 데이터가 공개되면 데이터 스토리지 문제가 등장하는데, 풀 노드가 해당 데이터를 얼마나 오래 저장할지는 명확하지 않습니다. 노드가 데이터를 계속 보관하도록 강제할 수 없기 때문에 이는 우려스러운 부분이며, 데이터 가용성에 대한 우려를 더욱 가중시킵니다.

모듈형 블록체인과 대체 데이터 가용성

모듈형 블록체인은 특정 기능을 처리하는 블록체인입니다. 예를 들어, 모듈형 블록체인은 데이터 가용성에 집중하면서 실행이나 합의 등 다른 작업은 다른 블록체인이나 시스템에 의존할 수 있습니다.

모듈형 블록체인은 오프체인 데이터 스토리지, 데이터 압축, 샤딩 등 다양한 기법을 사용하여 Ethereum에 calldata를 게시하는 것보다 저렴하게 만드는 대체 데이터 가용성 레이어를 만듭니다.

대체 데이터 가용성 레이어를 사용하는 모듈형 블록체인의 한 예는 EigenDA입니다. EigenDA는 Arweave 위에 구축된 탈중앙화 데이터 가용성 레이어입니다. EigenDA는 사용자가 Arweave에 calldata를 게시한 다음 해당 calldata가 게시되었음을 Ethereum에 증명할 수 있도록 합니다. 이를 통해 사용자는 온체인에 calldata를 저장하는 데 따르는 높은 gas 비용을 지불하지 않고도 Ethereum에 calldata를 게시할 수 있습니다.

온체인 데이터의 유형

이제 온체인 데이터가 무엇인지 살펴보았으니, 다양한 유형의 온체인 데이터와 그것이 어떻게 생성, 저장, 접근되는지 더 깊이 알아보겠습니다.

거래 데이터란?

거래 데이터는 다음과 같이 블록체인 상 거래와 관련된 모든 정보를 포함합니다:

• 발신자
• 수신자
• 전송 금액
• 거래 수수료
• 거래 타임스탬프

이 데이터는 사용자가 블록체인에서 거래를 할 때마다 생성됩니다. 이후 네트워크 노드에 방송되어 거래를 검증하고 원장에 추가합니다.

거래 데이터는 Merkle 트리라고 하는 트리 데이터 구조 유형으로 저장 및 검증될 수 있습니다. Merkle 트리는 트리 내 각 노드가 자신이 담고 있는 데이터의 해시인 이진 트리로, 빠른 데이터 검증을 가능하게 합니다. Merkle 트리에서 데이터의 무결성을 검증하려면 트리의 루트 해시만 있으면 됩니다. Merkle 트리에 데이터를 저장하는 것은 블록체인의 크기를 최대한 작게 유지하는 데 도움이 됩니다. Merkle 트리에 대해 더 자세히 다룰 내용이 많으므로, Alchemy 문서에서 Merkle 트리에 대해 더 자세히 읽어볼 수 있습니다. 특히 Ethereum의 경우, 데이터는 Patricia Merkle Trie(radix trie(Patricia trie)와 Merkle 트리를 결합한 구조)를 사용하여 저장됩니다.

거래 데이터에 빠르게 접근하고 싶다면 Ethereum 거래의 경우 Etherscan과 같은 블록체인 탐색기를 사용하면 됩니다. 블록체인 탐색기는 사용자가 모든 거래 데이터를 보고 검색할 수 있도록 해주며, 토큰의 이동을 추적하거나, 사기성 거래를 식별하거나, 블록체인 애플리케이션을 개발하는 등의 용도로 사용될 수 있습니다. 특정 거래에 대한 데이터를 찾으려면 거래 해시가 필요합니다. 애플리케이션을 위해 블록체인 데이터에 정기적으로 접근해야 한다면 Alchemy가 도움이 될 수 있습니다.

메타데이터

메타데이터는 블록체인 상의 거래와 자산에 대한 추가 정보를 제공하는 데이터입니다. 여기에는 다음과 같은 추가 세부 정보가 포함될 수 있습니다:

• 자산의 이름 또는 심볼
• 자산의 총 공급량
• 자산의 소유권 이력
• 자산의 컨트랙트 주소

거래 데이터와 달리 메타데이터는 블록체인 운영에 필수적이지는 않지만, 블록 탐색기, 지갑, 대시보드 등의 애플리케이션을 만드는 개발자에게 유용합니다. 메타데이터는 스마트 컨트랙트나 블록체인에 의해 정의된 대로 자동으로 생성되거나(예: 거래 메타데이터), 사용자가 수동으로 정의할 수 있습니다(예: 자산 메타데이터).

메타데이터에 접근하기 위해 개발자는 getMetadata 쿼리를 사용할 수 있습니다. 이러한 쿼리를 사용하려면 개발자는 Alchemy API와 같은 블록체인 API를 사용해야 합니다. getMetadata 쿼리를 사용하면 개발자는 사용자가 블록체인 네트워크를 이해하고 상호작용하는 데 도움이 되는 다양한 애플리케이션을 만들 수 있습니다.

이벤트 데이터

이벤트 데이터는 스마트 컨트랙트가 거래를 실행할 때 발생시키는 데이터를 말합니다. 이 데이터에는 다음과 같은 정보가 포함될 수 있습니다:

• 발생한 이벤트의 유형
• 이벤트를 발생시킨 스마트 컨트랙트의 주소
• 이벤트에 대한 세부 정보(예: 전송된 토큰의 양, 자산의 새로운 소유자 등)

이 정보는 개발자가 스마트 컨트랙트의 활동을 모니터링하는 데 유용하며 로그를 통해 접근할 수 있습니다. 로그는 블록체인에서 발생한 모든 이벤트에 대한 기록이며 스마트 컨트랙트에 의해 생성됩니다. 이러한 로그는 거래 영수증에서 확인할 수 있으며 eth_getLogs에 요청을 보내 조회할 수 있습니다.

Calldata

Calldata는 함수가 호출될 때 스마트 컨트랙트에 전달되는 데이터입니다. 다시 말해, 외부 호출자로부터의 함수 인자가 스마트 컨트랙트로 전달되기 전에 저장되는 일종의 임시 데이터 저장소입니다. Calldata는 정수, 문자열, 배열 등 어떤 유형의 데이터든 포함할 수 있습니다. 이는 스마트 컨트랙트가 서로, 그리고 사용자와 통신할 수 있게 해주기 때문에 중요합니다. 예를 들어, NFT 스마트 컨트랙트에서 NFT의 소유권을 사용자에게 이전하는 데 calldata가 사용될 수 있습니다.

블록체인 상의 모든 연산에는 gas 수수료가 부과되며, calldata를 사용하는 경우도 예외는 아닙니다. L2 거래가 Ethereum에 게시될 때, calldata는 해당 거래에 포함됩니다. 이는 Ethereum 네트워크가 거래를 검증하고 호출되는 스마트 컨트랙트 함수를 실행하는 데 calldata가 필요하기 때문입니다. calldata에 사용되는 gas는 calldata의 크기와 calldata에 포함된 데이터의 유형에 따라 결정됩니다. Ethereum의 경우 각 블록이 포함할 수 있는 최대 calldata는 1,048,576바이트입니다.

Blob

Blob(binary large object)은 블록에 첨부된 blob이 올바른 데이터를 담고 있는지 네트워크가 확인하도록 함으로써 거래 검증을 더 효율적으로 만들기 위해 설계되었습니다. Blob은 proto-danksharding(calldata 비용을 줄이고 블록당 calldata 크기를 늘리기 위한 제안)과 관련하여 도입되었습니다.

Proto-danksharding은 blob-carrying transaction이라는 새로운 유형의 거래를 도입함으로써 블록체인의 calldata를 더 저렴하게 만든다고 합니다. Blob-carrying transaction은 일반 거래와 유사하지만 데이터 blob을 포함할 수 있습니다.

Blob-carrying transaction은 처리하는 데 그만큼 많은 gas가 필요하지 않기 때문에 일반 거래보다 저렴합니다. 이는 데이터 blob이 오프체인에 저장되어 거래에 포함될 필요가 없기 때문입니다.

데이터 blob과 blob-carrying transaction의 도입으로 Ethereum 블록체인에서 대량의 데이터를 더 저렴하게 저장하고 처리하는 것이 가능해질 것입니다.

블록체인 인덱싱이란?

책의 색인은 핵심 단어와 아이디어가 언급된 페이지 번호를 담고 있습니다. 이와 유사하게, 블록체인 인덱싱은 블록체인 데이터를 검색하고 쿼리하기 쉬운 방식으로 정리하고 저장하는 과정입니다. 이는 사용자가 더 효율적이고 효과적인 방식으로 데이터에 접근하고 분석할 수 있게 해주기 때문에 블록체인 데이터를 다룰 때 이해해야 할 중요한 개념입니다.

블록체인은 시간 순서 구조를 따르기 때문에 데이터가 여러 블록에 걸쳐 흩어져 있고 서로 얽혀 있을 수 있습니다. 인덱싱은 블록체인 데이터의 색인을 만들어 이 문제를 해결하고자 합니다.

이 색인은 검색과 쿼리에 최적화된 방식으로 블록체인 데이터의 일부를 저장하는 데이터베이스입니다. 데이터를 인덱싱하기 위해서는 거래 관련 정보 인덱싱, 주소 인덱싱, 스마트 컨트랙트 상호작용 인덱싱 등 다양한 인덱싱 방법이 있습니다. 인덱싱된 데이터는 이후 GraphQL, Alchemy 및 기타 web3 프로토콜이 제공하는 API를 통해 개발자가 접근할 수 있습니다.

일반적인 인덱싱 사용 사례

블록체인 인덱싱이 개발자가 데이터를 더 효율적으로 검색하고 쿼리하는 데 얼마나 유용한지 알았으니, 몇 가지 일반적인 인덱싱 사용 사례를 살펴보겠습니다.

거래 히스토리 인덱싱 - Uniswap 풀과 같은 것의 거래량과 유동성을 추적하고, 가장 큰 거래자와 고래를 식별하는 데 사용될 수 있습니다.

분석 및 리포팅을 위한 인덱싱 - 거래량, gas 수수료, 사용자 활동 등 다양한 지표에 대한 리포트를 생성하는 데 사용될 수 있습니다. 특정 스마트 컨트랙트, 암호화폐, 시장 동향의 성과를 추적하고 분석하거나, 사용자 활동(예: 활성 지갑 수, 처리된 거래 수 등)을 이해하는 데 특히 유용할 수 있습니다.

메타데이터 인덱싱 - NFT의 소유권과 이전을 추적하는 데 사용될 수 있습니다. 실용적인 예로는 특정 NFT 컬렉션의 거래 인덱스에 쿼리하여 구매/소유권 이력 등 관련 세부 정보를 파악할 수 있는 NFT 분석 도구가 있습니다.

스마트 컨트랙트 이벤트 인덱싱 - 토큰의 이동(예: 특정 ERC-20 토큰의 전송 이벤트), 대출 및 차입 활동을 추적하거나 NFT 시장을 더 잘 이해하는 데 사용될 수 있으며, 이는 몇 가지 구체적인 예시에 불과합니다. 전반적으로 스마트 컨트랙트 이벤트를 인덱싱하면 스마트 컨트랙트의 활동을 모니터링할 수 있으며, 이는 취약점이나 새로운 애플리케이션 및 서비스의 기회를 식별하는 데 도움이 될 수 있습니다.

오프체인 및 온체인 인덱스

인덱스는 온체인 또는 오프체인에 저장될 수 있으며, 각각 고유한 장단점이 있습니다. 예를 들어 Satsuma는 Alchemy가 인수한 온체인 인덱싱 프로토콜입니다. Satsuma는 API를 위한 쿼리 언어인 GraphQL을 사용하며, 네트워크 블록과 스마트 컨트랙트를 스캔하는 subgraph를 사용하여 단일 API 호출로 다양한 소스로부터 데이터를 수집하는 방식으로 작동합니다. 오프체인 인덱싱 프로토콜은 노드의 로컬 스토리지에 인덱스를 저장(예: SubQuery)하거나 AWS와 같은 전통적인 클라우드 서버에 저장하는 방식으로 작동하며, 이는 온체인 인덱싱보다 빠를 수 있습니다. 오프체인이든 온체인 인덱싱 프로토콜이든, 개발자는 쉽게 쿼리 언어를 사용할 수 있습니다:

• GraphQL - 개발자는 GraphQL을 사용하여 특정 ERC20 토큰의 전송 이력을 subgraph에 쿼리할 수 있습니다.
• SQL - 개발자는 SQL을 사용하여 특정 블록체인에 배포된 모든 스마트 컨트랙트 목록을 오프체인 인덱스에 쿼리할 수 있습니다.
• Elasticsearch - 개발자는 Elasticsearch를 사용하여 특정 블록체인에서 가장 인기 있는 NFT를 오프체인 인덱스에 쿼리할 수 있습니다.

블록체인 데이터는 어떻게 접근되는가?

온체인 데이터가 무엇이고 어떻게 저장되는지 배웠으니, 이제 개발자가 실제로 블록체인 데이터에 어떻게 접근할 수 있는지 더 깊이 살펴보겠습니다.

노드 쿼리하기

블록체인 데이터에 접근하는 가장 직접적인 방법 중 하나는 노드를 쿼리하는 것이지만, 이는 가장 많은 리소스를 소모하는 방법이기도 합니다.

노드를 쿼리하려면 JSON-RPC를 사용하여 풀 노드나 아카이브 노드(앞서 논의한 대로 블록체인의 전체 사본을 담고 있는 노드)를 통해 데이터에 접근해야 합니다. JSON-RPC를 사용하여 노드를 쿼리하려면 개발자는 호출하고자 하는 메서드, 해당 메서드의 파라미터, JSON-RPC 버전을 포함하는 JSON 객체를 노드에 보내야 합니다.

이는 노드를 쿼리하는 데 사용할 수 있는 JSON-RPC API를 제공하는 Alchemy와 같은 솔루션을 통해 쉽게 처리할 수 있습니다.

이벤트 필터는 특정 블록체인 이벤트에 대해 노드를 쿼리할 때도 유용할 수 있습니다. 이벤트 필터를 사용하려면 필터링하고자 하는 이벤트 유형과 이벤트의 파라미터를 지정해야 합니다. 이벤트 필터를 사용하는 쉬운 방법은 Alchemy의 Node API를 통하는 것입니다. Alchemy의 Node API는 노드를 실행하는 데 필요한 모든 인프라뿐만 아니라 노드와 쉽게 상호작용하고 쿼리할 수 있는 API 및 SDK를 포함하는 완전 관리형 서비스입니다.

웹훅을 이용한 데이터 스트리밍

웹훅을 이용한 데이터 스트리밍은 블록체인 데이터에 대한 실시간 업데이트를 받는 방법입니다. 이벤트 데이터는 커스텀 웹훅과 웹훅 변수를 사용하여 스트리밍될 수 있습니다. 이는 Alchemy와 같은 블록체인 인덱싱 서비스를 선택하고, 서버에 웹훅 엔드포인트를 만들고, 이벤트를 구독하고, 웹훅 변수를 구성함으로써 이루어집니다. 특히 Alchemy는 사용자가 새로운 거래, 새로운 스마트 컨트랙트 배포, 스마트 컨트랙트 상태 변경 등 다양한 블록체인 이벤트에 의해 트리거되는 커스텀 웹훅을 만들 수 있도록 지원합니다. Alchemy는 또한 최근 커스텀 웹훅을 업그레이드하여 개발자가 더 정밀하게 데이터 스트림을 좁히고 변수를 사용하여 웹훅 쿼리를 쉽게 업데이트할 수 있도록 했습니다.

Subgraph 쿼리하기

Subgraph는 커뮤니티가 만든 오픈소스 API로, Indexer, Curator, Delegator로부터 블록체인 데이터를 가져오는 데 사용됩니다. Subgraph는 GraphQL을 사용하여 구축되기 때문에 개발자는 GraphQL API를 사용하여 subgraph를 쿼리할 수 있습니다. Subgraph는 호스팅되거나 자체 호스팅될 수 있습니다. 호스팅된 subgraph는 GraphQL API URL에 GraphQL 쿼리를 보내서 쿼리할 수 있습니다. 자체 호스팅된 subgraph는 GraphQL 서버에 subgraph를 배포하여 쿼리할 수 있습니다. 이는 개발자가 자체 subgraph를 배포할 수 있게 해주는 Satsuma와 같은 솔루션을 통해 수행할 수 있습니다.

데이터 웨어하우스 쿼리하기

데이터 웨어하우스는 대개 구조화된 형식으로 된 과거 데이터를 쿼리하는 데 최적화되어 있습니다. 반면 데이터 레이크는 일반적으로 비구조화되거나 반구조화된 대량의 데이터를 저장합니다. Dune Analytics는 데이터 레이크에서 데이터를 쿼리, 추출, 시각화하는 데 사용할 수 있는 도구입니다. Dune은 데이터셋 탐색기와 같은 도구를 제공하여 다양한 체인, 데이터셋, 원시 블록체인 데이터 등을 탐색할 수 있게 해줍니다. 또한 데이터베이스를 백필하고 커스텀 웹훅으로 데이터를 스트리밍함으로써 자신만의 데이터 레이크를 만들 수도 있습니다.

결론

요약하면, 블록체인 데이터를 이해하는 것은 web3 인프라나 애플리케이션을 사용하거나 구축하려는 모든 개발자에게 유용합니다. 온체인 데이터는 블록체인에 저장되며 거래 데이터, 메타데이터, 이벤트 데이터, calldata, blob 등 여러 유형으로 나눌 수 있습니다. 이 데이터는 노드에 저장되며 사용 사례에 따라 다양한 방식으로 접근할 수 있습니다.