아카이브 노드: 노드 설정의 정점

Running an archive node for a blockchain like Ethereum or Polygon is an undertaking that’s both labor-intensive and costly. It’s more or less the pinnacle of node setups. The node will require good hardware, maintenance (i.e., good monitoring), and also time—at least whenever monitoring kicks in or a new release is due. Typically, one will only take this on for a specific reason.

Ethereum 또는 Polygon과 같은 블록체인의 아카이브 노드를 실행하는 것은 노동 집약적이고 비용이 많이 드는 작업입니다. 이는 노드 설정의 정점에 가깝습니다. 노드에는 좋은 하드웨어, 유지 관리(예: 좋은 모니터링) 및 시간이 필요합니다. 적어도 모니터링이 시작되거나 새 릴리스가 예정될 때마다 그렇습니다. 일반적으로 특정 이유로만 이 작업을 수행합니다.

An archive node is more than a full node. A full node “only” stores the entire blockchain, whereas an archive node additionally stores every state that each smart contract and transaction ever had (i.e., at every block height). However, the additional data of an archive node can be reconstructed from the data of a full node.

아카이브 노드는 전체 노드 그 이상입니다. 전체 노드는 전체 블록체인을 "만" 저장하는 반면, 아카이브 노드는 각 스마트 계약 및 트랜잭션의 모든 상태(즉, 모든 블록 높이)를 추가로 저장합니다. 그러나 아카이브 노드의 추가 데이터는 풀 노드의 데이터로부터 재구성될 수 있다.

Since this often leads to discussions on Twitter or online forums, I like to bring an analogy to Bitcoin: An archive node for Ethereum is akin to a Bitcoin node that stores the UTXO (Unspent Transaction Output) set valid at every block height. This isn’t particularly interesting for Bitcoin because (a) these data can be reconstructed much faster and (b) they don’t hold any special informational value. It’s different with Ethereum because there are smart contracts whose intermediate states are stored, making it possible to directly query, for example, how much USDT an account had at any given time (block height).

이는 종종 트위터나 온라인 포럼에서 토론으로 이어지므로 비트코인에 비유하고 싶습니다. 이더리움의 아카이브 노드는 모든 블록 높이에서 유효한 UTXO(사용되지 않은 거래 출력) 세트를 저장하는 비트코인 ​​노드와 유사합니다. (a) 이러한 데이터는 훨씬 빠르게 재구성될 수 있고 (b) 특별한 정보 가치를 보유하지 않기 때문에 비트코인에서는 특히 흥미롭지 않습니다. 중간 상태가 저장되는 스마트 계약이 있기 때문에 Ethereum과 다릅니다. 예를 들어 특정 시간에 계정에 USDT가 얼마나 있는지(블록 높이) 직접 쿼리할 수 있습니다.

I synchronized my first archive node for the Ethereum ecosystem in 2019. It was out of pure curiosity: I had purchased a lot of server hardware for a project (96 cores, 768 GiB RAM, over 40 TiB SSD storage) and wanted to push it to the limit. So, I synchronized an archive node for Ethereum using geth, which took exactly 7 days and 22 hours. I still remember it so precisely because I discussed the topic on coinforum.de and documented my progress.

저는 2019년에 이더리움 생태계를 위한 첫 번째 아카이브 노드를 동기화했습니다. 그것은 순수한 호기심에서 비롯되었습니다. 프로젝트를 위해 많은 서버 하드웨어(96개 코어, 768GiB RAM, 40TiB SSD 스토리지 이상)를 구입했고 이를 푸시하고 싶었습니다. 한계까지. 그래서 Geth를 사용하여 Ethereum용 아카이브 노드를 동기화했는데 정확히 7일 22시간이 걸렸습니다. 나는 coinforum.de에서 주제에 대해 논의하고 진행 상황을 문서화했기 때문에 아직도 그것을 매우 정확하게 기억합니다.

Long-term, better reasons are needed. That’s a significant difference between Ethereum and Bitcoin. Bitcoiners synchronize the entire blockchain out of idealism. In Ethereum, most users utilize node providers like Infura or Alchemy. These providers allow roughly 100,000 free API calls, sufficient for smaller projects and wallets.

장기적으로 더 나은 이유가 필요합니다. 이것이 이더리움과 비트코인의 중요한 차이점입니다. Bitcoiners는 이상주의를 바탕으로 전체 블록체인을 동기화합니다. Ethereum에서는 대부분의 사용자가 Infura 또는 Alchemy와 같은 노드 공급자를 활용합니다. 이러한 공급자는 소규모 프로젝트와 지갑에 충분한 약 100,000개의 무료 API 호출을 허용합니다.

When and for whom is an archive node useful?

아카이브 노드는 언제, 누구에게 유용합니까?

It becomes critical when one wants or needs to conduct blockchain analyses. If, for instance, you want to know which accounts held what amounts of a token on Ethereum at any time, you need to scan the blockchain block by block to find all addresses and then query the historical balances for each ERC20 transaction. This quickly exceeds the free API calls provided by Alchemy and Infura and can become expensive fast. In such cases, an archive node is worthwhile because scanning all blocks leads to as many API calls as there are blocks in the blockchain. Ethereum currently has over 20 million blocks.

블록체인 분석을 원하거나 수행해야 할 때 이는 매우 중요합니다. 예를 들어, 언제든지 이더리움에서 어떤 계정이 얼마만큼의 토큰을 보유하고 있는지 알고 싶다면 블록체인을 블록별로 스캔하여 모든 주소를 찾은 다음 각 ERC20 거래에 대한 과거 잔액을 쿼리해야 합니다. 이는 Alchemy 및 Infura에서 제공하는 무료 API 호출을 빠르게 초과하며 빠르게 비용이 많이 들 수 있습니다. 이러한 경우 모든 블록을 스캔하면 블록체인에 있는 블록 수만큼 API 호출이 발생하므로 아카이브 노드가 가치가 있습니다. 이더리움은 현재 2천만 개 이상의 블록을 보유하고 있습니다.

I now operate such nodes for clients. The reasons can sometimes be absurd. For instance, a company offers assistance in complying with EU regulations, which require demonstrating the CO2 consumption for each crypto asset. If you have a token on Ethereum, you must trace back all past transactions and swaps to calculate the gas used by the token. The gas corresponds to the required computational power and thus serves as an indicator of CO2 consumption.

나는 이제 클라이언트를 위해 그러한 노드를 운영하고 있습니다. 그 이유는 때로는 터무니없을 수 있습니다. 예를 들어, 한 회사는 각 암호화폐 자산의 CO2 소비량을 입증해야 하는 EU 규정을 준수하는 데 도움을 제공합니다. 이더리움에 토큰이 있는 경우 토큰에 사용되는 가스를 계산하려면 과거의 모든 거래와 스왑을 추적해야 합니다. 가스는 필요한 계산 능력에 해당하므로 CO2 소비량의 지표 역할을 합니다.

This is, of course, ludicrous. As a Proof-of-Stake blockchain, Ethereum consumes very little energy, and synchronizing an archive node likely generates far more CO2 than you could ever save through the regulation (if at all). But it’s not my job to ask such questions, but rather to set up nodes.

물론 이것은 터무니없는 일입니다. 지분 증명 블록체인인 이더리움은 에너지를 거의 소비하지 않으며, 아카이브 노드를 동기화하면 규정을 통해 절약할 수 있는 것보다 훨씬 더 많은 CO2가 생성될 가능성이 높습니다. 하지만 그런 질문을 하는 것은 내 일이 아니라 노드를 설정하는 일이다.

What resources are needed to operate an Ethereum archive node?

이더리움 아카이브 노드를 운영하려면 어떤 리소스가 필요합니까?

The differences between nodes and clients can be substantial. I have experience with Ethereum, Polygon, and Solana.

노드와 클라이언트 간의 차이는 상당할 수 있습니다. 저는 Ethereum, Polygon, Solana에 대한 경험이 있습니다.

Using the Nethermind client, Ethereum requires about 15 terabytes of storage for the execution layer data, 8 CPU cores (preferably 16 for synchronization), and 128 gigabytes of RAM. An alternative client is Erigon, which requires only three terabytes of data. Erigon stores data differently than Nethermind, using a flat architecture that only saves deltas between some blocks. This may result in slightly longer query times for historical data but saves a lot of space.

Nethermind 클라이언트를 사용하는 Ethereum에는 실행 계층 데이터를 위한 약 15테라바이트의 스토리지, 8개의 CPU 코어(동기화의 경우 16개 권장) 및 128GB의 RAM이 필요합니다. 대체 클라이언트는 3테라바이트의 데이터만 필요한 Erigon입니다. Erigon은 일부 블록 사이의 델타만 저장하는 평면 아키텍처를 사용하여 Nethermind와 다르게 데이터를 저장합니다. 이로 인해 기록 데이터에 대한 쿼리 시간이 약간 길어질 수 있지만 많은 공간이 절약됩니다.

For a server, the demand is moderate. Once synchronized, less is needed. The biggest challenge is the hard drives, or rather the SSDs. To understand why, you must know how smart contracts work with the Ethereum Virtual Machine (EVM). I’ll keep it brief: Each smart contract has its own virtual memory space, which may load different parts depending on the account. This leads to numerous read and write operations (I/O) with each new block and during synchronization.

서버의 경우 수요가 보통입니다. 일단 동기화되면 더 적은 양이 필요합니다. 가장 큰 과제는 하드 드라이브, 오히려 SSD입니다. 그 이유를 이해하려면 EVM(Ethereum Virtual Machine)에서 스마트 계약이 어떻게 작동하는지 알아야 합니다. 간략하게 설명하겠습니다. 각 스마트 계약에는 자체 가상 메모리 공간이 있으며, 이는 계정에 따라 다른 부분을 로드할 수 있습니다. 이로 인해 각 새 블록과 동기화 중에 수많은 읽기 및 쓰기 작업(I/O)이 발생합니다.

Therefore, traditional hard drives (HDDs) are outdated; SSDs are needed. Users of Nethermind must chain several SSDs together to store at least 15 terabytes. This can quickly cost a four-figure amount if

따라서 기존 하드 드라이브(HDD)는 구식입니다. SSD가 필요합니다. Nethermind 사용자는 최소 15테라바이트를 저장하기 위해 여러 SSD를 함께 연결해야 합니다. 다음과 같은 경우에는 빠르게 4자리 금액의 비용이 발생할 수 있습니다.