Where are archival nodes in the P2P Gossip network story?

I haven’t seen any clarification about the archival nodes role in the new story. Let’s say that there are no relay nodes (as they will be optional) in the network for a second, archival nodes are still necessary, right?!

Question for someone who is familiar with the current implementation,

  1. How regularly archival nodes are called by participation nodes (and maybe wallets)?

  2. What are the hardware/network requirements for archival nodes?

In the new model,

  1. Are archival nodes permissionless?

  2. How does a node/wallet decide which archival node to use?

  3. How are archival nodes paid or incentivized?

Reddit

1 Like

There is support for purely archival servers (not even nodes) with a DNS bootstrap.
But it is not enabled neither on mainnet nor on testnet.

see: host -t SRV _archive._tcp.mainnet.algorand.network

I this case archival entities can be simple web storage servers with 2TB+ capacity and fast uplink.
I use this setup on Algorand co-chains where all types of nodes are non archival.

As for current mainnet setup - all relays are archival so any participation node that connects to the network can source recent catchup or any block from any of the 110 permissioned relays. Blocks are sourced randomly from multiple archival entities.

I am running a relay and the archival traffic is almost non existent compared to gossip traffic.
Happens only when someone does a catchup.

I am curious myself how this is going to work in the new model.

I tried to see how this is solved in other places - if one want to setup a mirror node for Hedera it only costs $2000 to download the archive off off the GCP cloud. :joy:

1 Like

Thanks for the comment.

There is support for purely archival servers (not even nodes) with a DNS bootstrap.

  • How are new transactions ingested to these servers if not on the network?

Blocks are sourced randomly from multiple archival entities.

  • A node only needs a recent history, correct? How often or when the older history is read/needed by non-archival nodes? Also, is it the case that every participation node keeps the state of all accounts on the network? And when they read the latest account state, they trust the archival node and do not verify any past transaction up to that point, correct?

How are new transactions ingested to these servers if not on the network?

There is no ingestion tool (that I know of) - it can be a simple script that downloads msgpack blobs from a node and dumps them into a file. But it also can be a node in archival node.

A node only needs a recent history, correct? How often or when the older history is read/needed by non-archival nodes? Also, is it the case that every participation node keeps the state of all accounts on the network? And when they read the latest account state, they trust the archival node and do not verify any past transaction up to that point, correct?

Nodes source missing blocks from all connected peers. Presently they happen to be relays but in the future they will be both designated archivers / fat relays and p2p nodes . If a node misses only recent blocks (after a restart / upgrade / network outage) it will source them from non-archival peers as they are going to keep some recent blocks ( not less than 320).

Blocks are sourced from random peers/relays so all of them would have to collude on alternate history . Catchup verifies the blocks and makes sure they form a proper chain.

When starting from scratch with a fast catchup you trust a “label” provider. You request this catchup (account state) from a random archive but then begin the process of downloading 1000 blocks from random places - and they have to form a proper, validated chain .

1 Like

From what I’ve seen in code in p2p mode nodes can announce their services as archival/catchup