Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove trust on history archives in captive core #3172

Closed
bartekn opened this issue Oct 29, 2020 · 1 comment · Fixed by #3203
Closed

Remove trust on history archives in captive core #3172

bartekn opened this issue Oct 29, 2020 · 1 comment · Fixed by #3203
Assignees

Comments

@bartekn
Copy link
Contributor

bartekn commented Oct 29, 2020

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:
    type LedgerHashesStore interface {
    	// First argument indicates if the hash for the given sequence is available.
    	GetLedgerHash(sequence uint32) (bool, xdr.Hash, error)
    }

The first issue seems quite complicated, so let's focus on the second case first.

@tamirms
Copy link
Contributor

tamirms commented Nov 13, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants