Skip to content
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.

Sign up for GitHub

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

SIMD 0054: Sysvar for active stake #56

Closed
wants to merge 3 commits into from
Closed

SIMD 0054: Sysvar for active stake #56

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
a785628
init
0xNineteen Jun 7, 2023
7a19372
update
0xNineteen Jun 7, 2023
b4a9b79
incorp comments
0xNineteen Jun 7, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
89 changes: 89 additions & 0 deletions proposals/0054-sysvar-get-active-stake.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,89 @@
---
simd: '0054'
title: Sysvar for active stake
authors:
- x19
category: Standard
type: Core
status: Draft
created: 2023-06-7
feature: (fill in with feature tracking issues once accepted)
---

## Summary

We propose to add a new sysvar that contains vote account pubkeys and
their corresponding active stake.

## Motivation

Currently, if a validator wants to prove its active stake to a program,
it needs to
pass in all of the stake accounts which have delegated to it. This is
Comment on lines +21 to +22
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: there are a few truncated line breaks like this through out... would be good to clean them up

infeasible due to the large number of stake accounts this would require.

Using the proposed sysvar, a program can look up the corresponding
vote account and verify the amount of active stake it has delegated to it.

This sysvar would unlock new use cases which use stake amount in their logic
including on-chain governance, attestations, and more.

## Alternatives Considered

None

## New Terminology

None

## Detailed Design

- sysvar structure: `Vec<(vote_account: Pubkey, active_stake_in_lamports: u64)>`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i would suggest an additional field

  • epoch_stake: u64 -- total active stake for the epoch

- sysvar address: `SysvarStakeWeight11111111111111111111111111`

0xNineteen marked this conversation as resolved.
Show resolved Hide resolved

### Ordering

The sysvar structure would be sorted by `vote_account` in ascending order
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might pay to add an additional Vec<u16> of indexes into the vote-account-address-sorted vector, which is instead sorted by stake to ease "first N% stake" lookups

to improve look-up speeds. There will also never be any
duplicate `vote_account` entries.

### Serialization

The serialization format of the sysvar will use a u64
for the vector's length, followed by 40 bytes per entry
(32 bytes for the Pubkey and 8 for the active stake).

### Maximum Sysvar Size

We also need to consider a maximum data size for the sysvar.
Currently, there are 3422 vote accounts on mainnet (1818 active and 1604 delinquint),
so we can use a maximum limit of 4096 entries and still include
all the vote accounts for now.
Using 4096 as the max number of entries the size would be (8 + 40 * 4096) =
163,848 bytes. Once the number of entries exceeds the max allowed,
vote accounts with the least amount of stake will be removed from the sysvar.
Comment on lines +59 to +65
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

im very suspicious of this coming back to bite us in the future. there arent 4096 validators today, but there could be someday, and it puts us in the unfortunate position of needing to decide whether to keep increasing the size of the sysvar, or make smaller validators second-class citizens. i especially dont like that this creates a disincentive to decentralization. this isnt a theoretical concern because (at least according to our marketing materials...) we already have over 2000 active voting nodes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

im very suspicious of this coming back to bite us in the future. there arent 4096 validators today, but there could be someday, and it puts us in the unfortunate position of needing to decide whether to keep increasing the size of the sysvar, or make smaller validators second-class citizens. i especially dont like that this creates a disincentive to decentralization. this isnt a theoretical concern because (at least according to our marketing materials...) we already have over 2000 active voting nodes

I agree, I think size of the sysvar should be much higher(or no limit if that doesn't introduce other problems) so that it can store all the vote accounts for the following reasons:

  • If we truncate the sysvar to the top stakers, in the case that one of the voters becomes delinquent for a certain slot, we won't be able to verify consensus since the sysvar would update every epoch.
  • Account size isn't a concern here because before reach that limit there would be other bottlenecks in the system as a consequence of having so many nodes in the network.


### Changes Required

Stake weight information should already be available on full node clients
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this sysvar contain stakes before or after reward calculation ?

since it's required to construct the leader schedule. Since stake weights
can only be
modified on a per-epoch basis, validators will only need to update this
account on epoch boundaries.

We would also need a new feature gate to activate this sysvar.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

move to security section. broken consensus -> loss of availability -> security


## Impact

Implementing the proposed sysvar will enable new types of programs which are
not possible now,
improving Solana's ecosystem.
Comment on lines +79 to +81
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not a particularly valuable statement. elaborate with examples


## Security Considerations

None

## Backwards Compatibility

Existing programs are not impacted at all.