Skip to content
This repository has been archived by the owner on Feb 1, 2024. It is now read-only.

PoET 2.0 Consensus - Updated #20

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

kulkarniamol
Copy link

@kulkarniamol kulkarniamol commented Jul 10, 2018

Proposes an new PoET Consensus mechanism designed to provide the
PoET functionality without requiring SGX Platform Services.

Deprecates PR#12.

Signed-off-by: kulkarniamol [email protected]

Proposes an new PoET Consensus mechanism designed to provide the
PoET functionality without requiring SGX Platform Services.

Signed-off-by: kulkarniamol <[email protected]>
infrastructure.

This document details a new mechanism for the PoET algorithm that overcomes
some of the challenges with the original algorithm.

Choose a reason for hiding this comment

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

Suggest a wording more like "extends the original algorithm to new platforms"


Sawtooth includes an implementation which simulates the secure instructions.
This should make it easier for the community to work with the software but
also forgoes Byzantine fault tolerance.

Choose a reason for hiding this comment

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

Strictly speaking... it does give you BFT. The problem is that it is trivially easy to "compromise" nodes (so the 3f+1/2f+1 guarantees are easy to violate).

This should make it easier for the community to work with the software but
also forgoes Byzantine fault tolerance.

PoET 2.0 essentially works as follows:

Choose a reason for hiding this comment

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

Suggest that you link to the full description of PoET v1.


+ The `WaitCertificate` contains a `Duration` as well as a related `WaitTime`.
The `Duration` is a 256-bit random number generated using the secure
RNG available within the SGX. The `WaitTime` is derived from the

Choose a reason for hiding this comment

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

There is no reason to compute the WaitTime in the enclave. Since the wait time is essentially meaningless to the enclave. All the other validators can do the conversion from the random number/duration into a time. That would allow you to just call Duration what it really is... a random number.

+ On the originating validator, the `WaitTime` is used to throttle broadcast of
claim blocks. Upon creating the `WaitCertificate`, the validator waits
until `WaitTime` seconds have elapsed before broadcasting the block over
the gossip network

Choose a reason for hiding this comment

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

I would suggest that you describe how the wait time is computed from the random number. The computation is more or less the same as the computation from PoET v1.

double WaitTime # The number of seconds to wait, as a function of the
# Duration and the LocalMean
double LocalMean # The computed local mean
byte[32] BlockID # The BlockID passed in to the Enclave

Choose a reason for hiding this comment

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

see comments above. this information is redundant.

>The implication of this change is that the signup data is lost each time the
>enclave is unloaded or the platform is restarted. The enclave has to register
>afresh with a new set of keys each time it gets loaded.

Choose a reason for hiding this comment

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

i'm confused. poet 1 doesn't store signup data, it stores the identity of the monotonic counter. we regenerate data on reboot because the protocol REQUIRES that the enclave re-register, not because there is no sealed storage. Sealed storage without a monotonic counter cannot prevent replay attacks (just copy an old version of sealed storage into place if you want to have multiple signups for the processor).

current `WaitCertId_{n}` to upper layers for registration in
EndPoint registry.
* Goto 1

Choose a reason for hiding this comment

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

This appears to be missing the two delays that are necessary. The first delay is the time between registration & use of the registration. The second is the delay between subsequent registrations for the processor.

>Note 1: In practice, the WC may be calculated by recording the system time at
>the moment of the arrival of the Sync Block and subsequently subtracting this
>timestamp from the current time.

Choose a reason for hiding this comment

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

Its probably worth receiving several blocks and computing an average over those blocks to ensure that you don't favor a low-latency neighbor or a cheating neighbor.


An early arriving block (where `WC < CC'`) is considered 'Ineligible'. The block
is cached for `CC' - WC` seconds until it becomes 'Eligible'. It is then
broadcast to neighboring peers over the Gossip Network.

Choose a reason for hiding this comment

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

it will be broadcast assuming that another, better claim is not received before the timer expires.

>subtracting this timestamp from the current time (`WC = CurrentTime - BaseTime`).

>Note 2: Notice that the CC is a function of the WaitTime, which is computed within
>the enclave.
Copy link
Contributor

Choose a reason for hiding this comment

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

Not important that it's computed within the enclave. Only enclave trusted function is the RNG. If we compute WaitTime in the enclave it is for convenience / readability of having all the logic in one method.

EndPoint registry (otherwise sender needs to re-sign).

4. Verify the `WaitCertificate.LocalMean` is correct by comparing
against `LocalMean` computed locally.
Copy link
Contributor

Choose a reason for hiding this comment

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

Verify wait time similarly

@hartm
Copy link

hartm commented Sep 4, 2018

I have a question about this fork resolution process. Can someone explain why we only need to compare chain lengths (rather than check the total number of "work" done on the chain--i.e., incorporate the population estimate)?

Here's my thought process: suppose I controlled a small group of nodes. We could could fork off everything to a side chain and then wait for the "difficulty" to go down. In the steady state, due to the population adjustment, we would be adding blocks at the same rate as the main chain. We could let this go on for a while--maybe we would get lucky and accumulate blocks at a slightly (sublinear) rate faster than the main chain. Then, at some point, we could add in a bunch of new members and use these to add much more blocks than expected and try to catch up to the main chain. It's possible there's some mathematical reasoning that says this is impossible, but it's not immediate (and needs to be written up if this is becomes the spec).

Does anyone have an explanation for why this doesn't work? Am I misunderstanding something here? Thanks!

@cmickeyb
Copy link

cmickeyb commented Sep 4, 2018 via email

@hartm
Copy link

hartm commented Sep 6, 2018

Thanks for the in-depth explanation Mic.

I guess my point is the following: since you're storing the randomness of the block winner in the chain, you can compute the population estimate trivially. Consider the following formula:

W(chain, block_start, block_end) = \sum_{i = block_start}^{block_end} Population_Estimate(block_i).

The function W can be computed (with the current and proposed estimators) solely from the raw random numbers in the enclave, and is probably the most direct measure of "work" on a blockchain using PoET that we can possibly manage.

Now consider the following rule for deciding which branch of a fork to take. Suppose we have two branches: branch_1 and branch_2, with b_1 and b_2 blocks each, respectively. Let block number b* be the last block that both have in common.

We choose branch_1 if:

W(branch_1, b* + 1, b* + b_1) > W(branch_2, b* + 1, b* + b_2)

and branch_2 otherwise (we can break ties based on equality in some deterministic manner, say based on the randomness of the most recent block). Note that this functionality exactly agrees with your analysis above and simplifies it considerably, eliminating the need for a case-by-case analysis.

Is there a reason something like this doesn't work? It seems like a much simpler rule than what you're proposing, and leads us nicely in the direction of provable security (which I care about, obviously). Thanks!

efficiency. Existing system clock synchronization mechanisms like NTP
etc. may be sufficient for PoET 2.0 requirements.

Network latencies may be exploited by malicious nodes to broadcast blocks
Copy link
Contributor

Choose a reason for hiding this comment

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

Some of the points in this section sound like they could be moved to/or repeated in the currently empty drawbacks section.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants