blockworks-foundation
/
solana
mirror of https://github.com/blockworks-foundation/solana.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

wip, initial explanation on vote signer validator and stake owner relationship

This commit is contained in:
Anatoly Yakovenko 2019-01-30 11:27:35 -08:00 committed by Greg Fitzgerald
parent 952ab2bde5
commit 31b0d14856
1 changed files with 49 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
book/src/enclave.md → book/src/vote-signer.md
View File

@ -1,9 +1,14 @@
# Signing using Secure Enclave # Secure Vote Signing
This document defines the security mechanism of signing keys used by the The gaol of this design is to address the following challenges with voting:
fullnodes. Every node contains an asymmetric key that's used for signing
and verifying the votes. The node signs the vote transactions using its private * Validators execute untrusted code in a potentially insecure VM.
key. Other entities can verify the signature using the node's public key. * Validators sign the result of their work and submit consensus votes.
* Votes that violate consensus rules could be used to slash the stake used in the vote.
Every node contains an asymmetric key that's used for signing and verifying the
votes. The node signs the vote transactions using its private key. Other
entities can verify the signature using the node's public key.
The node's stake or its resources could be compromised if its private key is The node's stake or its resources could be compromised if its private key is
used to sign incorrect data (e.g. voting on multiple forks of the ledger). So, used to sign incorrect data (e.g. voting on multiple forks of the ledger). So,
@ -14,6 +19,45 @@ protection. An enclave can be used to generate an asymmetric key and keep the
private key in its protected memory. It can expose an API that user (untrusted) private key in its protected memory. It can expose an API that user (untrusted)
code can use for signing the transactions. code can use for signing the transactions.
## Vote Signers, Validators and Stake Owners
A validator is a fullnode that is connected to the cluster and
executes transactions. A validator computes all the possible forks
that are concurrently active in the cluster. A validator picks the
best possible fork to vote and requests the vote signer to sign the
vote.
A vote signer evaluates the vote proposed by the validator and signs
the vote only if it does not violate a slashing condition. A vote
signer only needs to maintain minimum state regarding the votes it
signed, and the votes signed by the rest of the cluster. It doesn't
need to process a full set of transactions.
A stake owner is an identity that has control of the staked capital.
The stake owner can delegate their stake to the vote signer. Once
a stake is delegated, the vote signer votes represent the voting
weight of all the delegated stakes, and produce rewards for all the
delegated stakes.
A single validator could do work for multiple vote signers. For a
single vote signer to observe votes from multiple validators and
only vote if M/N agree. For a single vote signer to be delegated
multiple stakes. For a single stake owner to delegate a portion of
the stake to multiple vote signers.
For simplicity, the intial rollout should focus on the following
configuration:
* 1:1 relationship between validator and vote signer. The validator
can use the vote signer's public key as its identity. This key
should have some sols to pay for execution of votes.
* Stake Owner can delegate the entire stake to a single vote signer.
And a vote signer may have more than 1 stake delegated to them.
The vote signer may need to submit multiple votes to register a
vote with a stake public key that does not fit into a single
transaction.
## Message Flow ## Message Flow
1. The node initializes the enclave at startup 1. The node initializes the enclave at startup