-
Notifications
You must be signed in to change notification settings - Fork 39
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 FendermintExterns::get_tipset_cid #508
Comments
For EVM compatibility, we only need a lookback of 256 blocks. It may be possible to ask CometBFT to sync X blocks from the network on node init. From then onwards, we assume CometBFT would maintain sync and inform us of new blocks so we can maintain the lookback live. If it's possible to guarantee that CometBFT can sync N blocks, on init we could find a way to suspend Fendermint init until the lookback cache has been filled. However, @akosh.farkash pointed out that this may not be easy. It also couples IPC further to CometBFT, which ain't good. As @akosh.farkash suggested, the alternative is to create a "chain history actor" to store the lookback in state. Resolving this syscall would then involve making a transient call to this actor. Alternatively, that actor could be an extended version of the system actor; in which case we'd have to fork builtin-actors (bad), or replace the system actor with our custom version at genesis (better). I'd choose this path if we wanted to prevent system actor sprawl, but I also don't have strong opinions. If we generalise this actor to something like a "chain metadata actor", it comes broader in scope and more useful down the line as a good home for future chain-dependent/specific functionality. |
In conclusion, I think @aakoshh has it right and this shouldn't be hard too implement. From my POV:
Chain metadata actor methodsstruct State {
blockcid_lookback: Amt<Optional<Cid>>,
}
struct ConstructorParams {
blockcid_lookback_len: u64,
}
// method num = 1
pub fn constructor(params: ConstructorParams);
// method num = 2, this can take the epoch or can fetch it through a syscall; it's needed in case we need to skip positions? (e.g. null rounds)
pub fn push_blockcid(cid: Cid);
// method num = frc42!
// Returns the configured lookback length.
pub fn blockcid_lookback_len() -> u64;
// method num = frc42!
// Returns the CID of the block at [`rewind`] many blocks in the past.
// Can return None if the requested position was a null round in chains that support such behaviour.
// Returns an error if the requested position is beyond the lookback.
// Returns another error if the requested position is within lookback but would make us seek backwards beyond genesis.
pub fn blockcid(rewind: u64) -> Result<Optional<Cid>>; |
Rest of the TODOs tracked in #568. |
Implement get_tipset_cid so any contract using the
BLOCKHASH
Solidity function doesn't crash the node.Things to consider:
AMT
and schedule it to be executed by thecron
actor and store a configurable (in genesis) number of block hashes in the actor state itself, so that snapshot export/import restores the pre-agreed length of history, and then we implementget_tipset_cid
based on this actor.The text was updated successfully, but these errors were encountered: