-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
Implement historical headers in ICS03 #4647
Comments
Isn't the relayer the only party the needs access to this information? I don't think this needs to be stored in state. The relayer can get this information by querying Tendermint unless i am wrong. |
To update the client only the relayer need to access this information. However connection handshake requires the chain to inspect its past header in order to check if the other chain has correct header originated from this chain(because the other chain only can have the past header of this chain at the time this chain is inspecting the other chain's state with a known consensus state). function connOpenTry(
desiredIdentifier: Identifier, counterpartyConnectionIdentifier: Identifier,
counterpartyClientIdentifier: Identifier, clientIdentifier: Identifier,
proofInit: CommitmentProof, proofHeight: uint64,
timeoutHeight: uint64, nextTimeoutHeight: uint64) {
assert(getConsensusState().getHeight() <= timeoutHeight)
counterpartyStateRoot = get(rootKey(connection.clientIdentifier, proofHeight))
expectedConsensusState = getConsensusState()
expected = ConnectionEnd{INIT, desiredIdentifier, counterpartyClientIdentifier, clientIdentifier, timeoutHeight}
assert(verifyMembership(counterpartyStateRoot, proofInit,
connectionKey(counterpartyConnectionIdentifier), expected))
assert(verifyMembership(counterpartyStateRoot, proofInit,
consensusStateKey(counterpartyClientIdentifier),
expectedConsensusState))
assert(get(connectionKey(desiredIdentifier)) === null)
identifier = desiredIdentifier
state = TRYOPEN
connection = ConnectionEnd{state, counterpartyConnectionIdentifier, clientIdentifier,
counterpartyClientIdentifier, nextTimeoutHeight}
set(connectionKey(identifier), connection)
}
|
That's a little sad. I guess we just need to store a window of past headers. |
Yes it does not need to be the whole past headers. The |
Makes sense to me, although Ideally we could get these previous headers on the fly directly from Tendermint -- I still don't see why this isn't possible? |
I think it will include async communication between the app layer and tendermint layer on deliverTx execution, possibly causing some nondeterminism? I couldn't think an example case that this will cause a problem now but it seems safe to keep the deliverTx a single round operation. Tendermint core team will know about this better @alexanderbez |
@AdityaSripal now that ADR17 was merged, we can incorporate those changes to the ICS03 Connection keeper. There are a few comments that say |
I'll start working on this tomorrow |
closed via #5475 |
In Tendermint, the historical information of the blockchain is stored in Tendermint, not in the application, which means the application cannot access to them while processing the transaction.
The historical block header module can easily implemented, with a
BeginBlocker
thatpushes
ctx.Header()
into theKVStore
and exposing a getter to other modules. It can take additional argument to limit how many height it will store the headers.This is needed for ICS 03, which requires to be able to access its past headers.
The text was updated successfully, but these errors were encountered: