Bound finalized header, execution header and sync committee by RingBuffer and BoundedVec #814
Conversation
|
@ParthDesai Awesome! Many thanks and I'll review it together with team. |
| @@ -165,7 +175,7 @@ pub mod pallet { | |||
|
|
|||
| #[pallet::storage] | |||
| pub(super) type FinalizedBeaconHeaderSlots<T: Config> = | |||
| StorageValue<_, BoundedVec<u64, T::MaxFinalizedHeaderSlotArray>, ValueQuery>; | |||
| StorageValue<_, BoundedVec<(u64, H256), T::MaxFinalizedHeaderSlotArray>, ValueQuery>; | |||
There was a problem hiding this comment.
Just reminder, also require change in relayer side here
|
LGTM! Definitely a more elegant way for the pruing. Cost is some auxiliary storage and more r/w operations introduced so more weight will be consumed. Anyway, it's some O(1) operation so should be fine and would be nice if some benchmark accordingly. |
|
required Snowfork/cumulus#20 benchmark in comparison shows weight consumed increased by less than 1% can be safely ignored. |
|
@ParthDesai There is some more changes required to run e2e stack, if you do not mind I'll draft this one and we can review #815 instead. |
No problem. If you need any help with that, please let me know. |
Description
This PR is improvement over #810 as suggested by @yrong. Instead of using Pruning, now we are using modified version of RingBuffer to limit the runtime storage.
How
RingBufferworks?If number of items go beyond some threshold, the
RingBuffer::insertwill remove oldest entry.Advantage of
RingBufferThere is no while loop. The complexity is
O(1). And since it is abstracted, there is no clutter in application logic.