add slot hashes sysvar #121
Conversation
| let mut len_buf = [0u8; VEC_LENGTH_SIZE]; | ||
|
|
||
| let result = unsafe { | ||
| crate::syscalls::sol_get_sysvar( |
There was a problem hiding this comment.
It is a bit expensive to use a syscall just to get the number of entries. Better to use the syscall to get all the data.
| let len = Self::len()?; | ||
|
|
||
| for i in 0..len { | ||
| if let Some(entry) = Self::get_entry(i) { |
There was a problem hiding this comment.
This approach works, but it will be expensive to use multiple syscalls to iterate over them. It will be better to follow a similar approach as PodSlotHashes and Instructions sysvar.
| let len = Self::len()?; | ||
|
|
||
| for i in 0..len { | ||
| if let Some(entry) = Self::get_entry(i) { |
There was a problem hiding this comment.
Same comment here, it will be expensive to iterate using the syscall.
|
Thanks for the PR. While this approach will work, it will be expensive to use it – a syscall takes
Off-chain clients can use the SDK crate right? I am not sure what would be the benefit of using this one. |
Add SlotHashes sysvar support to Pinocchio
This PR adds support for the SlotHashes sysvar to the Pinocchio library, providing on-chain programs with efficient access to historical slot hash data.
Implementation details
slot_hashes.rsmodule in thesysvarsdirectorySlotHashesSysvarstruct with methods to efficiently access specific entries using direct syscallssysvar on chain methods
get_entry(index): Access a specific slot-hash entry by indexget_hash(slot): Find the hash for a specific slotposition(slot): Find the position of a slot in the collectionlen(): Get the number of entries availableThis implementation allows Pinocchio-based programs to access the SlotHashes sysvar in a way that's compute-efficient and memory-efficient, avoiding the need to deserialize the entire data structure.
question for @febo:
Can I add a std-featured off-chain SlotHashes struct to the implementation? I'd like to include a convenience wrapper that uses Vec for off-chain tooling when the "std" feature is enabled. This would make the API more familiar for off-chain use cases while keeping the core implementation no_std compatible. Would this approach be acceptable for the Pinocchio library's design philosophy?