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.

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

[RFC] Long fork consensus #2227

Open
wants to merge 10 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@es92
Copy link
Contributor

commented Apr 12, 2019

I wrote up an RFC for adding a long fork consensus rule to Coda

It has a part 1, which would make the protocol secure under usual 51% assumptions and be easy to implement

It also has a part 2, which would function as a fallback for the chain to recover if the 51% assumption is ever violated

Evan Shapiro added some commits Apr 12, 2019

Evan Shapiro Evan Shapiro
Evan Shapiro Evan Shapiro
Evan Shapiro Evan Shapiro
Evan Shapiro Evan Shapiro
@nholland94
Copy link
Contributor

left a comment

Left a couple of questions, mostly around attempting to make this document more specific. Part 1 makes sense to me so far. Not able to follow Part 2 yet as there are too many TODOs. Would prefer to see Part 2 fleshed out in a convincing way before we fully commit to starting development on this mechanism.

Show resolved Hide resolved rfcs/0017-long-fork-consensus.md

We currently do not support long forks. This means that to join the network you need a recent checkpoint, in other words to have always been online or to trust another party that has always been online.

This adds support for a client to join the network at any point of time, regardless of if its been online recently. It adds this safely under a [50% + epsilon] security assumption. It also includes a mechanism to restore a chain to strength if this assumption was to be temporarily violated.

This comment has been minimized.

Copy link
@nholland94

nholland94 Apr 17, 2019

Contributor

I'm sure it's just a parameter I've forgotten from the paper, but how is epsilon defined here? Would be nice to just have a short mention here within the RFC.

Show resolved Hide resolved rfcs/0017-long-fork-consensus.md Outdated
@enolan
Copy link
Contributor

left a comment

I'd like to see the TODOs filled in.

Show resolved Hide resolved rfcs/0017-long-fork-consensus.md Outdated
Show resolved Hide resolved rfcs/0017-long-fork-consensus.md Outdated

Evan Shapiro added some commits Apr 17, 2019

Evan Shapiro Evan Shapiro
Evan Shapiro Evan Shapiro
Evan Shapiro Evan Shapiro
Evan Shapiro Evan Shapiro
staged_leger_.vote_stake += get_ledger_of_hash(staged_ledger.vote_hash).stake_of(transaction.public_key)
else
staged_leger_.vote_stake = 0
staged_ledger.vote_hash = transaction.vote_hash

This comment has been minimized.

Copy link
@es92

es92 May 23, 2019

Author Contributor

add check of account.vote_hash to account for duplicate voting


* if the `snarked_ledger` is being updated
* `if new_snarked_ledger.vote_hash == new_protocol_state.last_epoch_locked_checkpoint`
* set `current_protocol_state.min_epoch` to `MAX(current_protocol_state.min_epoch, new_snarked_ledger.voted_stake/staged_ledger.total_stake)`

This comment has been minimized.

Copy link
@es92

es92 May 23, 2019

Author Contributor

update current_protocol_state.min_epochs as well using inflation discount rule

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.