Implementation of Archive Node on TRON

[halibobo1205]

Background

Currently, Java-tron does not support Archive Node. An archive node can query historical state data from the blockchain. Unlike a fullnode, an archive node not only saves the most recent blockchain state data but also completely records all historical state data from the genesis block to the latest block. This allows users to directly query state data such as account balances and contract storage at any block height without needing to recalculate from the genesis block (replay transactions), greatly improving the efficiency of historical state data queries.

Rationale

Why should this feature exist?

Fullnodes only store the current latest block state (used to verify new blocks), while archive nodes additionally store state snapshots of each historical block (e.g., balances for each address, contract storage data, etc.). Archive nodes can support historical state queries. For example, querying the balance of an address at block height 10,000 cannot be directly provided by a fullnode, but an archive node can do this.

What are the use-cases?

• DApp developers: testing and verifying smart contract behavior under different historical states
• Data analysis services: providing advanced analytical functions based on historical states
• Researchers: analyzing historical transaction patterns, state changes, and network behavior

Specification

Support Ethereum-compatible interfaces, including but not limited to:

• eth_getBalance: query an account's balance at a specific block height
• eth_getCode: query contract bytecode at a specific block height
• eth_getStorageAt: query the value at a specific position in contract storage at a specific block height
• eth_call: execute read-only contract calls on the state at a specific block height

Implementation

Archive nodes need a world state trie, which TRON needs to implement.

Ethereum state trie implementation

Ethereum supported a state trie in its initial version, implementing core state trie logic:

1. The block header contains three roots: transactionRoot, receiptRoot, and stateRoot
2. Every block state data change is reflected in the stateRoot
3. Account data, including contracts (nonce, balance, storageRoot, codeHash), is all uniformly encapsulated in the account
4. Uses MPT (Merkle Patricia Trie) for state data storage (including CRUD operations)

TRON's current situation

1. The block header contains 2 roots: txTrieRoot and accountStateRoot. TxTrieRoot is consistent with Ethereum's transactionRoot, but accountState only includes balance (the proposal is not enabled) and does not include contract data (storageRoot, codeHash) like ETH does.

2. Supports historical account balance queries: After enabling balance.history.lookup, account balances at specific heights can be queried via wallet/getaccountbalance.

3. State data is quite dispersed and not fully encapsulated in accounts (e.g., contract data, TRC10 are stored separately in different DBs). After organization, 25 databases need state statistics, including account data, TRC10 data, contract data, voting data, delegation data, etc. All state data needs to be organized and collected to generate the stateRoot

Implementation considerations for Archive nodes:

1. stateRoot generation
   TRON's state data is quite dispersed, involving many state databases. Unlike ETH, which generates root directly based on accounts, TRON needs to collect dispersed state data to generate a stateRoot.

2. Should stateRoot participate in consensus?
   Consensus issues:

   • A proposal is needed to generate stateRoot at a specified height, requiring consideration of how to calculate the initial effective height of stateRoot, whether to generate a genesis stateRoot based on the current state, and if not, how to ensure network-wide data consistency.
   • Historical data before this cannot generate stateRoot, and cannot support historical state queries.
   • Generating and verifying state roots impacts performance, potentially reducing TPS and transaction execution efficiency, affecting SRs and the ordinary fullNode.

3. Compatibility with all ETH state query interfaces

   • Support for eth_getBalance, eth_getCode, eth_getStorageAt, eth_call
   • Future support for eth_getBlockReceipts(Implement eth_getBlockReceipts method #5910 ) and debug_traceCall(Support the debug_traceCall API #5778 )
   • For discussion: whether to support eth_getTransactionCount (requires adding nonce field to Account, requiring a hard fork proposal) and eth_getProof (requires storageRoot, lite fullnodes, L2 support, etc.)

4. Performance impact
   Archive nodes significantly impact block execution and transaction execution efficiency, especially when historical state data is large. The implementation must ensure the normal operation of block synchronization and transaction execution.

5. Storage impact
   The transaction volume of TRON is far greater than that of ETH, with the archive node data expected to be 3-4 times that of ETH, estimated at 80 T+. Current single disk storage will be limited, requiring consideration of using multiple segmented Archive Nodes combined into a complete historical query collection.

Based on the above analysis, stateRoot will not participate in consensus to reduce the impact on SRs and the ordinary fullnodes during archive node implementation. Segmented multi-disk storage of state data will be used to solve single-disk storage limitations. Additionally, since archive-related functionality implementation involves significant changes affecting many functions, integration into the main branch is not currently considered, and development will first proceed on an independent branch.

[waynercheung]

Hi @@halibobo1205 , it's a good news that TRON will implement an archive node to offer the historical information.

And about the stateRoot generation, you have mentioned that it's different with ETH, can you provide more details about it?
such as is there also a MPT for account?

[lily309]

As I understand it, since java-tron uses protobuf as a prototype for database storage and API interaction. In the definition of the TRON protocol, the structure of accounts is more complex, so what kind of form will the archive node take when storing these historical account states?

A simple example may make it easier to describe the problem, for example, the structure of account A has balance/stake information/vote information, etc. If in a certain block, account A initiates a transfer, then only one balance field in the information of account A has changed. In the archive node implementation, does the account A corresponding to the height of the block where the transaction occurred still store all the complete account information? Or is there some special storage structure that reduces the storage overhead?

[halibobo1205]

@lily309 still stores all the complete account information. The storage may become larger in this case, but the query operation will become easier. Still, at the same time, due to the database storage becoming larger, the query may also increase the time-consuming.
Storing only changing fields is good for storage, but it can get complicated for queries. Are there any known optimizations?
BTW, if Tron only implements historical queries, replace the MPT with flat KV(such as erigon's Flat KV) instead of MPTs?

[halibobo1205]

stateRoot generation
ETH is about the MPT of the account; Tron's state data is split and not centralized in the account. The MPT tree is roughly designed as follows:

1. Each type of data has its own MPT

2. All data forms a single MPT

@waynercheung, I favor the second one, which I'll explain in more detail later.

[lily309]

Understood.

Of course, I'm also quite interested in erigon, who have implemented an archive node for Ethereum with only a tiny disk space.

I may not know much about the exact technical details yet, but it's nice to see that the TRON development community is considering a more efficient storage structure to solve the huge disk footprint problem posed by archive nodes, so if you guys have a follow-up update, please let me know.

[waynercheung]

Hi @halibobo1205 , where is the storage of contract data?
Does the "Storage Keys" in the above image include the contract data?

For ETH, each account has a storage root, as "Storage trie is where all contract data lives. There is a separate storage trie for each account." mentioned by storage-trie.

[waynercheung]

@waynercheung, I favor the second one, which I'll explain in more detail later.

Hi @halibobo1205 , I have another question about this, to my knowledge, java-tron has an important concept called 'proposal'. Is this data included in the MPT tree?

[Federico2014]

Ethereum will use the Verkle tree to replace Merkle-Patricia Trie. Will you consider adopting the Verkle tree directly to improve performance?

[317787106]

@halibobo1205 The stateRoot can compare with other nodes to ensure consistency, but how to query the balance by specifying the block height in eth_getBalance? Accumulate changes?

[317787106]

There are 25 database modifications included, so what is the selection criteria? receiptRoot of ETH is not generated, it's transactioninfo of TRON, why not used instateRoot ?

[halibobo1205]

Does the "Storage Keys" in the above image include the contract data?

Yes, contract data, Tron is currently associated with code, contract, storage-row, contract-state, that is, if using a separate root, there are 4.
cc @yanghang8612

[waynercheung]

Yes, contract data, Tron is currently associated with code, contract, storage-row, contract-state, that is, if using a separate root, there are 4. cc @yanghang8612

What does the "Storage Row Data" mean?
It just includes the contract data or it also includes other data?

Besides that, for Tron, there is only one MPT and just one stateRoot?
Because for ETH, there are four MPT which is State Trie, Storage Trie, Transactions Trie and Receipts Trie, and there are three roots: stateRoot, transactionsRoot and receiptsRoot.

[bladehan1]

Ethereum has implemented the path-based-storage-model to solve the problem of dynamic pruning of the world state tree for ordinary full nodes. In this change (or considering the future), ordinary full nodes also generate StateRoot. Should we consider using the path-based-storage-model?

[fortuna502]

There are 25 database modifications included, so what is the selection criteria? receiptRoot of ETH is not generated, it's transactioninfo of TRON, why not used instateRoot ?

@halibobo1205 Can you show more details about the 25 database? what are they?