Inaccurate Inscription Numbering in Ordhook Database

duyquoc1508 commented 5 months ago

Description:

I encountered an issue while running ordhook on my server. The problem arises with the archive database obtained from the link https://archive.hiro.so/.

After downloading the latest version of the ordhook archive (rocksdb + sqlite) and running it, I noticed that while the number of blocks increases as expected, the inscription numbering does not start from the end of the previous block (n - 1). Instead, it starts from the end of the previous two blocks (n - 2). Consequently, all inscription numbers for the following blocks become incorrect.

I downloaded the database from April 1, 2024, and encountered this issue. Below is a log snippet after starting the service:

{"msg">Index lines from block #837194 to block #837227","level":INFO","ts":"2024-04-01T09:48:38.066411037Z"}

Expected Behavior:

The inscription numbering should start from the end of the previous block (n - 1) as per the standard behavior.

Steps to Reproduce:

Download the latest version of the ordhook archive from the provided link.
Start ordhook services using the downloaded archive.
Observe the behavior of the inscription numbering in the database.

Additional Information:

Version of ordhook archive used: mainnet-ordhook-sqlite-24-alpine-20240401.tar.gz Date of database download: April 1, 2024

Screenshots/Logs:

Environment:

Ordhook docker image: hirosystems/ordhook:2.1.0

Note: I would appreciate any assistance or insights into resolving this issue. Thank you!

duyquoc1508 commented 5 months ago

We have identified the issue lying within the sequence_metadata table in the sqplite database restored from the archive.

It appears that the sequence_metadata table consistently lacks a record for the last block (n - 1), regardless of the database version. This deficiency causes ordhook to increment the jubilee_inscription_number based on the preceding block (n - 2), as block (n - 2) is currently recognized as the latest block. However, the correct behavior should involve the existence of a record for block (n - 1), which represents the latest block height.

As a result, the incorrect numbering of inscription numbers occurs due to this discrepancy in the database.

duyquoc1508 commented 5 months ago

I've also discovered discrepancies in the HIRO API and the archive database, specifically regarding inscription numbering from block 837927 onwards. I suspect that the underlying issue mentioned earlier may be the root cause. This suspicion arises from the observation that the sequence_metadata table also lacks a record at block 837926.

To further illustrate this point, I conducted a small comparison exercise. I randomly selected an inscription ID from block 837930 (after 837927) and queried it against several other indexers. Here are the results:

Inscription ID: b3f51c7634e85f1c95d8f3c7fed0dabc8cb20b2dfafe495509bb6c6b51aeaa62i0

These findings reinforce the possibility that the inconsistencies stem from the missing record in the sequence_metadata table at block 837926. Your inscription number is less than other indexer system 6248 and 6248 is also the number inscription of block 837926.

I hope this additional information helps in further investigating and resolving the issue