You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since run-from feature was merged (#3163) ingestion system trusts history archives completely in the init stage of buildState and resumeState when Stellar-Core subprocess is started. The reason is that Stellar-Core requires both the sequence and the hash of the previous ledger we want to start from. Currently we get these values from history archives but we shouldn't trust them.
There are two issue we need to fix:
In buildState we usually don't have any information about the previous ledgers (we do when rebuilding state). In such case a recommended way to obtain the ledger hash is to sync Stellar-Core (stellar-core run) and wait for the latest ledger close.
In resumeState we usually have hash of the previously closed ledger. In such case we should allow passing LedgerHashStore interface implementation that will allow CaptiveCore get info about known ledger hashes (as suggested by @tamirms). The interface can be very simple:
typeLedgerHashesStoreinterface {
// First argument indicates if the hash for the given sequence is available.GetLedgerHash(sequenceuint32) (bool, xdr.Hash, error)
}
The first issue seems quite complicated, so let's focus on the second case first.
The text was updated successfully, but these errors were encountered:
before stellar core starts streaming tx meta it will validate the ledger chain from consensus all the way back to the start ledger hash. In other words, stellar core run should never emit untrusted ledgers no matter what start ledger hash you provide. So if the ledger hash provided by the history archives is corrupt, the worst impact it will have on horizon is that ingestion will be blocked because the stellar core run command will exit with an error before streaming any ledgers.
In the resume state we can prevent this scenario where ingestion is blocked by always using the horizon db to determine ledger hashes. In the build state it is possible that the horizon db is empty so we may not find the ledger hash in the horizon db. But, even if we did have the correct ledger hash, we still need to process the history archives in the build state. So, no matter what, ingestion will be blocked in the build state until the history archives are fixed. Because of this fact, I think we should leave the build state as is.
Since run-from feature was merged (#3163) ingestion system trusts history archives completely in the init stage of
buildState
andresumeState
when Stellar-Core subprocess is started. The reason is that Stellar-Core requires both the sequence and the hash of the previous ledger we want to start from. Currently we get these values from history archives but we shouldn't trust them.There are two issue we need to fix:
buildState
we usually don't have any information about the previous ledgers (we do when rebuilding state). In such case a recommended way to obtain the ledger hash is to sync Stellar-Core (stellar-core run
) and wait for the latest ledger close.resumeState
we usually have hash of the previously closed ledger. In such case we should allow passingLedgerHashStore
interface implementation that will allow CaptiveCore get info about known ledger hashes (as suggested by @tamirms). The interface can be very simple:The first issue seems quite complicated, so let's focus on the second case first.
The text was updated successfully, but these errors were encountered: