core: use finalized block as the chain freeze indicator

[rjl493456442]

This pull request uses the finalized block tag as the indicator for chain freezing.

Originally, the latest 90K blocks will be retained in the key-value store by default, which are regarded as "non-finalized" in the context of Proof-of-work. However, in Proof-of-stake, we do have the concrete finalized block tag from the consensus client. Therefore, it makes more sense to directly rely on the Finalized for chain freezing.

[rjl493456442]

+-----------------------+-------------------------+------------+------------+
|       DATABASE        |        CATEGORY         |    SIZE    |   ITEMS    |
+-----------------------+-------------------------+------------+------------+
| Key-Value store       | Headers                 | 40.50 KiB  |         68 |
| Key-Value store       | Bodies                  | 10.57 MiB  |         68 |
| Key-Value store       | Receipt lists           | 3.94 MiB   |         68 |
| Key-Value store       | Difficulties            | 3.51 KiB   |         68 |
| Key-Value store       | Block number->hash      | 2.79 KiB   |         68 |
| Key-Value store       | Block hash->number      | 734.69 MiB |   18789667 |
| Key-Value store       | Transaction index       | 11.85 GiB  |  345141413 |
| Key-Value store       | Bloombit index          | 3.71 GiB   |    9398764 |
| Key-Value store       | Contract codes          | 7.40 GiB   |    1138162 |
| Key-Value store       | Hash trie nodes         | 0.00 B     |          0 |
| Key-Value store       | Path trie state lookups | 717.70 KiB |      17925 |
| Key-Value store       | Path trie account nodes | 35.77 GiB  |  308295102 |
| Key-Value store       | Path trie storage nodes | 147.55 GiB | 1473547813 |
| Key-Value store       | Trie preimages          | 0.00 B     |          0 |
| Key-Value store       | Account snapshot        | 10.52 GiB  |  228143289 |
| Key-Value store       | Storage snapshot        | 78.07 GiB  | 1088002277 |
| Key-Value store       | Beacon sync headers     | 575.00 B   |          1 |
| Key-Value store       | Clique snapshots        | 0.00 B     |          0 |
| Key-Value store       | Singleton metadata      | 206.41 MiB |         19 |
| Light client          | CHT trie nodes          | 0.00 B     |          0 |
| Light client          | Bloom trie nodes        | 0.00 B     |          0 |
| Ancient store (Chain) | Headers                 | 8.67 GiB   |   18789600 |
| Ancient store (Chain) | Hashes                  | 680.93 MiB |   18789600 |
| Ancient store (Chain) | Bodies                  | 459.60 GiB |   18789600 |
| Ancient store (Chain) | Receipts                | 170.73 GiB |   18789600 |
| Ancient store (Chain) | Diffs                   | 297.63 MiB |   18789600 |
| Ancient store (State) | History.Meta            | 1.35 MiB   |      17922 |
| Ancient store (State) | Account.Index           | 155.86 MiB |      17922 |
| Ancient store (State) | Storage.Index           | 217.18 MiB |      17922 |
| Ancient store (State) | Account.Data            | 171.45 MiB |      17922 |
| Ancient store (State) | Storage.Data            | 64.33 MiB  |      17922 |
+-----------------------+-------------------------+------------+------------+
|                                  TOTAL          | 936.35 GIB |            |
+-----------------------+-------------------------+------------+------------+

By deploying it on a benchmark node, we can see there are only 68 blocks left in the key-value store.

[rjl493456442]

Dec 15 13:58:41 DEBUG[12-15|05:58:41.524] Deep froze chain segment                 blocks=13660 elapsed=11.461s     number=18,789,504 hash=90583b..da9370
Dec 15 14:02:30 DEBUG[12-15|06:02:30.085] Deep froze chain segment                 blocks=32    elapsed=20.450ms    number=18,789,536 hash=975a14..6accff
Dec 15 14:08:30 DEBUG[12-15|06:08:30.089] Deep froze chain segment                 blocks=32    elapsed=22.812ms    number=18,789,568 hash=83fc05..4f70c7
Dec 15 14:15:30 DEBUG[12-15|06:15:30.093] Deep froze chain segment                 blocks=31    elapsed=23.591ms    number=18,789,599 hash=8f91a3..952b64

[holiman]

I disagree. The notion of Finalized means that the protocol does no longer allow reverting it. However, manual intervention could still be used to revert a chain which is finalized-by-protocol.

90K is, IIRC, chosed to give us a "human reasonable timeframe" (a couple of days) to react to chain splits / consensus errors, do an emergency release and let users switch over.

[karalabe]

Keeping 90K in leveldb is not that relevant though as long as we cann still reorg back that much. Moving the blocks to the freezer should not impact that, would it?

[holiman]

Moving the blocks to the freezer should not impact that, would it?

Good point! If that is the case, then I agree

[rjl493456442]

Yes, the intention is just moving chain segments from the live database to freezer, instead of having the notion that this part of segment is no longer revertable.

We can still do SetHead with a target lower than freezer head; and it's possible to reorg chain to a block below the freezer head.

[holiman]

What is the reason for the +1 and - 1 ?

[rjl493456442]

Because in the f.freezeRange(nfdb, first, limit), we will freeze the blocks in range [first, limit], limit is also included. The frozen block number is limit-first+1.

The freezerBatchLimit is the cap of the block number, therefore the limit is capped to freezerBatchLimit + first - 1 if too many blocks in a single run.

[holiman]

LGTM

[fynnss]

For further thought, it seems that there is no benefit to store those block data into kvdb first, then move to ancient.

We can just hold these block data in memory, and when it come to finalized, then persist it into ancientdb.

BTW, it's currently freezing once a minute, If it go faster then less then 68 blocks will be stored in kvdb.

[rjl493456442]

The benefits probably is not worthwhile, as the stability is always the priority one thing. Keep chain segment in memory will introduce a tons of issues and complexities. Thanks and Best regards Gary rong

…

On Tue, Feb 6, 2024 at 5:15 PM Fynn ***@***.***> wrote: For further thought, it seems that there is no benefit to store those block data into kvdb first, then move to ancient. We can just hold these block data in memory, and when it come to finalized, then persist it into ancientdb. BTW, it's currently freezing once a minute, If it go faster then less then 68 blocks will be stored in kvdb. — Reply to this email directly, view it on GitHub <#28683 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNO6OPKCRADWXHNCLJNRJTYSHYCVAVCNFSM6AAAAABAV5Q5D6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRZGA4DENRUHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[karalabe]

Mostly nitpicks

[rjl493456442]

@karalabe Updated, please take another look.

[karalabe]

SGTM

[KidiIT]

All reviewed and approved🫶❤️