From d6372ab1c08749a95dee45e728fbfefb0ea19830 Mon Sep 17 00:00:00 2001 From: Joe C Date: Tue, 26 Mar 2024 19:02:21 -0500 Subject: [PATCH] clarifying changes --- proposals/0133-syscall-get-epoch-stake.md | 40 +++++++++++------------ 1 file changed, 19 insertions(+), 21 deletions(-) diff --git a/proposals/0133-syscall-get-epoch-stake.md b/proposals/0133-syscall-get-epoch-stake.md index 2a9841351..8310191be 100644 --- a/proposals/0133-syscall-get-epoch-stake.md +++ b/proposals/0133-syscall-get-epoch-stake.md @@ -17,9 +17,9 @@ A syscall to retrieve a vote account's delegated stake for the current epoch. ## Motivation Currently, on-chain programs have no knowledge of the current epoch's stake and -how much active stake is delegated to a certain vote account. +how much active stake is delegated to any vote account. -If this data was available for querying by on-chain programs, it would unblock +If this data were available for querying by on-chain programs, it would unblock many use cases, such as validator governance and secondary consensus mechanisms, that were previously not possible on Solana. @@ -29,21 +29,20 @@ support for a pending feature gate. ## Alternatives Considered -An alternative design has been proposed in the past for using an on-chain sysvar -account to store all of the current epoch's stake. It was proposed in -[SIMD 0056](https://github.com/solana-foundation/solana-improvement-documents/pull/56). +[SIMD 0056](https://github.com/solana-foundation/solana-improvement-documents/pull/56) +proposes using an on-chain sysvar account to store all of the current epoch's +stake. -Using a sysvar account to store even just the current epoch's stake introduces a -size limitation on the number of entries that can be stored, which the number of -validators on Solana could surpass in the future. +Because account data is finite, using a sysvar account to store even just the +current epoch's stake limits the number of entries that can be stored. The +amount of validators in one Solana cluster could surpass this number in the +future. -By offering access to this information through only a syscall, we can avoid this -account maximum size constraint. However, the syscall approach also makes the -data more cumbersome to retrieve off-chain than the sysvar approach. - -While retrieving this data off-chain may not be straightforward, it remains -entirely feasible. Conversely, on-chain programs currently do not have this -capability at all. +Exposing epoch-stake information through a syscall avoids this account maximum +size constraint. While the syscall approach does not offer the easy off-chain +retrieval of a sysvar, there are existing ways to get epoch-stake data off +chain. The priority of a new design should be making the data available to +on-chain programs. ## New Terminology @@ -73,18 +72,17 @@ uint64_t sol_get_epoch_stake( ); ``` -`var_addr` must be the starting address of at least 8 bytes of writable VM -memory to store the `u64` response. If not, the syscall will abort the VM with -an access violation. +`var_addr` must be the starting address of 8 bytes of writable VM memory to +store the `u64` response. If not, the syscall will abort the VM with an access +violation. If the provided vote address corresponds to an account that is not a vote account or does not exist, the syscall will write `0` for active stake. ## Impact -This new syscall directly unlocks highly relevant network data for a wide range -of protocols. Developers seeking to access vote account stake will be positively -impacted. +Dapp developers will be able to query vote account stake for the current epoch +from within on-chain programs. ## Security Considerations