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

added branch determination and enclave configuration section to encla… (#1873) 

* added branch determination and enclave configuration section to enclave rfc

* spelling and grammar
This commit is contained in:
Eric Williams 2018-11-26 17:57:38 -08:00 committed by anatoly yakovenko
parent 58e3dd4cb6
commit 1695803248
1 changed files with 9 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
rfcs/0009-enclave.md
View File

@ -31,6 +31,15 @@ Secure Enclaves (such as SGX) provide a layer of memory and computation protecti
* The sign request contains the entry ID for the new vote
* Enclave verifies that new vote's entry ID is on the correct branch (following the rules #1 and #2 above)
## Branch determination
Due to the fact that the enclave cannot process PoH, it has no direct knowledge of branch history of a submitted validator vote. Each enclave should be initiated with the current *active set* of public keys. A validator should submit its current vote along with the votes of the active set (including itself) that it observed in the slot of its previous vote. In this way, the enclave can surmise the votes accompanying the validator's previous vote and thus the branch being voted on. This is not possible for the validator's initial submitted vote, as it will not have a 'previous' slot to reference. To account for this, a short voting freeze should apply until the second vote is submitted containing the votes within the active set, along with it's own vote, at the height of the initial vote.
## Enclave configuration
A staking client should be configurable to prevent voting on inactive branches. This mechanism should use the client's known active set `N_active` along with a threshold vote `N_vote` and a threshold depth `N_depth` to determine whether or not to continue voting on a submitted branch. This configuration should take the form of a rule such that the client will only vote on a branch if it observes more than `N_vote` at `N_depth`. Practically, this represents the client from confirming that it has observed some probability of economic finality of the submitted branch at a depth where an additional vote would create a lockout for an undesirable amount of time if that branch turns out not to be live.
## Challenges
1. The nodes are currently being configured with asymmetric keys that are generated and stored in PKCS8 files.