We will introduce (as part of the genesis config) a minimum delay d between the introduction of a new committee and the withdrawal of the stake (e.g. an epoch could last one day, and that duration could be two weeks).
So all certificates signed by a committee that is no older than d are still backed by validator stake.
And if a certificate has any descendants or message recipients that can be verified that way, i.e. they have been re-certified, they also can trusted indirectly.
So we should allow uploading a vector of certificates to a validator in a request. The validator checks that:
the certificates form a chain, i.e. link to each other by parent hash,
the highest certificate is signed by a committee no older than d,
and all certificates are valid,
and then executes them. This may require several requests for very long chains; if the client starts supplying the highest certificates first, the validator knows that they are legitimate.
Finally, we need to rethink the acceptance criterion for cross-chain messages:
A block with an incoming message should be accepted if a quorum of validators can verify that the message was actually sent, i.e. verified the sending block. This does not depend on which epoch the receiving chain is in.
Clients—especially when making fast blocks—will want to make absolutely sure that the validators will still accept the received message, so they should only include messages which are sent by a block signed by a committee no older than e.g. d / 2, so have a sufficient margin of error.
We will introduce (as part of the genesis config) a minimum delay
dbetween the introduction of a new committee and the withdrawal of the stake (e.g. an epoch could last one day, and that duration could be two weeks). So all certificates signed by a committee that is no older thandare still backed by validator stake.And if a certificate has any descendants or message recipients that can be verified that way, i.e. they have been re-certified, they also can trusted indirectly.
So we should allow uploading a vector of certificates to a validator in a request. The validator checks that:
d,and then executes them. This may require several requests for very long chains; if the client starts supplying the highest certificates first, the validator knows that they are legitimate.
Finally, we need to rethink the acceptance criterion for cross-chain messages:
d / 2, so have a sufficient margin of error.