Struct StorageApi

pub struct StorageApi;

Implementations

impl StorageApi

pub fn epoch_index(&self) -> StaticAddress<(), EpochIndex, Yes, Yes, ()>

Current epoch index.

pub fn authorities(&self) -> StaticAddress<(), Authorities, Yes, Yes, ()>

Current epoch authorities.

pub fn genesis_slot(&self) -> StaticAddress<(), GenesisSlot, Yes, Yes, ()>

The slot at which the first epoch actually started. This is 0 until the first block of the chain.

pub fn current_slot(&self) -> StaticAddress<(), CurrentSlot, Yes, Yes, ()>

Current slot number.

pub fn randomness(&self) -> StaticAddress<(), Randomness, Yes, Yes, ()>

The epoch randomness for the current epoch.

Security

This MUST NOT be used for gambling, as it can be influenced by a malicious validator in the short term. It MAY be used in many cryptographic protocols, however, so long as one remembers that this (like everything else on-chain) it is public. For example, it can be used where a number is needed that cannot have been chosen by an adversary, for purposes such as public-coin zero-knowledge proofs.

pub fn pending_epoch_config_change( &self, ) -> StaticAddress<(), PendingEpochConfigChange, Yes, (), ()>

Pending epoch configuration change that will be applied when the next epoch is enacted.

pub fn next_randomness(&self) -> StaticAddress<(), NextRandomness, Yes, Yes, ()>

Next epoch randomness.

pub fn next_authorities( &self, ) -> StaticAddress<(), NextAuthorities, Yes, Yes, ()>

Next epoch authorities.

pub fn segment_index(&self) -> StaticAddress<(), SegmentIndex, Yes, Yes, ()>

Randomness under construction.

We make a trade-off between storage accesses and list length. We store the under-construction randomness in segments of up to UNDER_CONSTRUCTION_SEGMENT_LENGTH.

Once a segment reaches this length, we begin the next one. We reset all segments and return to 0 at the beginning of every epoch.

pub fn under_construction_iter( &self, ) -> StaticAddress<(), UnderConstruction, (), Yes, Yes>

TWOX-NOTE: SegmentIndex is an increasing integer, so this is okay.

pub fn under_construction( &self, _0: impl Borrow<Param0>, ) -> StaticAddress<StaticStorageKey<Param0>, UnderConstruction, Yes, Yes, ()>

TWOX-NOTE: SegmentIndex is an increasing integer, so this is okay.

pub fn initialized(&self) -> StaticAddress<(), Initialized, Yes, (), ()>

Temporary value (cleared at block finalization) which is Some if per-block initialization has already been called for current block.

pub fn author_vrf_randomness( &self, ) -> StaticAddress<(), AuthorVrfRandomness, Yes, Yes, ()>

This field should always be populated during block processing unless secondary plain slots are enabled (which don’t contain a VRF output).

It is set in on_finalize, before it will contain the value from the last block.

pub fn epoch_start(&self) -> StaticAddress<(), EpochStart, Yes, Yes, ()>

The block numbers when the last and current epoch have started, respectively N-1 and N. NOTE: We track this is in order to annotate the block number when a given pool of entropy was fixed (i.e. it was known to chain observers). Since epochs are defined in slots, which may be skipped, the block numbers may not line up with the slot numbers.

pub fn lateness(&self) -> StaticAddress<(), Lateness, Yes, Yes, ()>

How late the current block is compared to its parent.

This entry is populated as part of block execution and is cleaned up on block finalization. Querying this storage entry outside of block execution context should always yield zero.

pub fn epoch_config(&self) -> StaticAddress<(), EpochConfig, Yes, (), ()>

The configuration for the current epoch. Should never be None as it is initialized in genesis.

pub fn next_epoch_config( &self, ) -> StaticAddress<(), NextEpochConfig, Yes, (), ()>

The configuration for the next epoch, None if the config will not change (you can fallback to EpochConfig instead in that case).

pub fn skipped_epochs(&self) -> StaticAddress<(), SkippedEpochs, Yes, Yes, ()>

A list of the last 100 skipped epochs and the corresponding session index when the epoch was skipped.

This is only used for validating equivocation proofs. An equivocation proof must contains a key-ownership proof for a given session, therefore we need a way to tie together sessions and epoch indices, i.e. we need to validate that a validator was the owner of a given key on a given session, and what the active epoch index was during that session.