블록체인 데이터 완전 분석

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

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

온체인 데이터란 무엇인가?

온체인 데이터란 간단히 말해 블록체인 네트워크에 저장된 모든 정보를 뜻합니다. 이는 네트워크에서 발생한 모든 트랜잭션의 불변 기록이며 누구나 볼 수 있도록 공개되어 있습니다. 온체인 데이터에는 다음과 같은 여러 유형이 있습니다:

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

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

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

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

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

ABI(application binary interface)는 개발자가 데이터를 모니터링하고 사람이 읽을 수 있는 형식으로 디코딩하는 데 도움을 줍니다. 스마트 컨트랙트의 데이터 구조는 ABI를 사용하여 정의됩니다. 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는 DHT(distributed hash table)에 해당 CID와 연관된 파일을 보유한 네트워크 내 노드에 관한 정보를 저장합니다
4. 이후 해시를 이용해 DHT를 조회함으로써 파일을 저장하고 있는 노드를 찾을 수 있습니다
5. CID는 토큰 스마트 컨트랙트에 저장됩니다

Arweave

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

데이터 게시 vs. 데이터 저장 vs. 데이터 가용성

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

데이터 가용성이 중요한 이유는 검증자가 Ethereum 블록체인에 블록을 추가할 때, 해당 블록의 모든 트랜잭션 데이터를 네트워크의 다른 검증자들에게 브로드캐스트해야 하기 때문입니다. 검증자는 모든 트랜잭션 데이터를 실행하는 임무를 맡고 있으며, 이는 블록체인이 검증자가 실행할 수 있는 만큼의 트랜잭션만 처리할 수 있다는 것을 의미합니다 - 이것이 바로 데이터 가용성 문제를 간단히 설명하는 것입니다.

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

데이터 게시와 관련된 주요 문제는 블록 생성자가 알려지지 않은 내용을 담은 블록 위에 새 블록을 생성하지 않는다는 것입니다. 즉, 게시되지 않은 데이터를 담은 블록은 아예 무시될 수 있습니다. 데이터가 게시되고 나면 데이터 저장의 문제가 등장하지만, 풀 노드가 그 데이터를 얼마나 오래 저장할지는 불명확합니다. 노드에게 데이터를 계속 보관하도록 강제할 수 없기 때문에 이는 우려스러운 부분이며, 데이터 가용성에 대한 더 많은 우려를 낳습니다.

모듈러 블록체인과 대안적 데이터 가용성

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

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

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

온체인 데이터의 유형

온체인 데이터가 무엇인지 살펴보았으니, 이제 온체인 데이터의 여러 유형과 이들이 어떻게 생성, 저장, 접근되는지 더 자세히 살펴보겠습니다.

트랜잭션 데이터란 무엇인가?

트랜잭션 데이터는 블록체인 상의 트랜잭션과 관련된 다음과 같은 모든 정보를 담고 있습니다:

• 송신자
• 수신자
• 전송 금액
• 트랜잭션 수수료
• 트랜잭션의 타임스탬프

이 데이터는 사용자가 블록체인에서 트랜잭션을 실행할 때마다 생성됩니다. 이후 트랜잭션을 검증하고 원장에 추가하기 위해 네트워크 노드로 브로드캐스트됩니다.

트랜잭션 데이터는 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는 정수, 문자열, 배열 등 어떤 유형의 데이터든 담을 수 있습니다. Calldata는 스마트 컨트랙트가 서로 통신하고 사용자와 통신할 수 있게 해주기 때문에 중요합니다. 예를 들어, NFT 스마트 컨트랙트에서 NFT의 소유권을 사용자에게 이전하는 데 calldata가 사용될 수 있습니다.

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

Blob

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

Proto-danksharding은 blob-carrying transaction이라는 새로운 유형의 트랜잭션을 도입함으로써 블록체인에서 calldata를 더 저렴하게 만드는 것으로 알려져 있습니다. Blob-carrying transaction은 일반 트랜잭션과 유사하지만 데이터 blob을 담을 수 있습니다.

Blob-carrying transaction은 처리하는 데 필요한 가스가 적기 때문에 일반 트랜잭션보다 저렴합니다. 이는 데이터 blob이 오프체인에 저장되어 트랜잭션에 포함될 필요가 없기 때문입니다.

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

블록체인 인덱싱이란 무엇인가?

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

블록체인은 시간순으로 정렬된 구조를 따르기 때문에 데이터는 수많은 블록에 흩어져 있고 서로 뒤섞일 수 있습니다. 인덱싱은 블록체인 데이터의 색인을 만듦으로써 이 문제를 해결하고자 합니다.

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

일반적인 인덱싱 사용 사례

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

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

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

메타데이터 인덱싱 - NFT의 소유권과 전송을 추적하는 데 사용될 수 있습니다. 실용적인 예로는, 특정 NFT 컬렉션의 트랜잭션 색인을 쿼리하여 구매/소유권 이력 및 기타 관련 세부사항을 파악할 수 있는 NFT 분석 도구가 있습니다.

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

오프체인 및 온체인 인덱스

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

• GraphQL - 개발자는 GraphQL을 사용하여 특정 ERC20 토큰의 전송 이력을 서브그래프에 쿼리할 수 있습니다.
• 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는 또한 최근 커스텀 웹훅을 업그레이드하여 개발자가 더 정밀하게 데이터 스트림을 좁히고, 변수를 사용하여 웹훅 쿼리를 손쉽게 업데이트할 수 있도록 했습니다.

서브그래프 쿼리

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

데이터 웨어하우스 쿼리

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

결론

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