From 16958032488818051ca12e489ec0cc6b700323b4 Mon Sep 17 00:00:00 2001 From: Eric Williams Date: Mon, 26 Nov 2018 17:57:38 -0800 Subject: [PATCH] =?UTF-8?q?added=20branch=20determination=20and=20enclave?= =?UTF-8?q?=20configuration=20section=20to=20encla=E2=80=A6=20(#1873)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * added branch determination and enclave configuration section to enclave rfc * spelling and grammar --- rfcs/0009-enclave.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/rfcs/0009-enclave.md b/rfcs/0009-enclave.md index e0aafb6d4..761c48784 100644 --- a/rfcs/0009-enclave.md +++ b/rfcs/0009-enclave.md @@ -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.