Add exception to overseer communication and write up local and remote disputes #1176

rphmeier · 2020-06-01T00:29:33Z

No description provided.

roadmap/implementors-guide/guide.md

burdges · 2020-06-02T00:43:35Z

roadmap/implementors-guide/guide.md

+  - The session that the candidate has appeared in.
+  - Backing for that candidate
+  - The validation code necessary for validation of the candidate. [TODO: optimize by excluding in case where code appears in `Paras::CurrentCode` of this fork of relay-chain]
+  - Secondary checks already done on that candidate, containing one or more disputes by validators. None of the disputes are required to have appeared on other chains. [TODO: validator-dispute could be instead replaced by a fisherman w/ bond]


We could construct remote disputes as a series of related transactions, so individually these component transactions may not suffice, until we assemble all the component transactions.

Right - 1 transaction to open the dispute, periodic transactions to update the dispute, and then after closing, accept transactions to add evidence to the losing side.

burdges · 2020-06-02T09:57:53Z

roadmap/implementors-guide/guide.md

+
+When beginning a remote dispute, at least one escalation by a validator is required, but this validator may be malicious and desires to be slashed. There is no guarantee that the para is registered on this fork of the relay chain or that the para was considered available on any fork of the relay chain.
+
+So the first step is to have the remote dispute proceed through an availability process similar to the one in [the Inclusion Module](#The-Inclusion-Module), but without worrying about core assignments or compactness in bitfields.


I'm think a second availability game almost never helps because the pre-dispute availability game requires adversarial nodes vote available. We could run an availability game with a lower threshold f+1 which then says the block is reconstructable, unless those nodes lie.

We could just say that one dispute authorizes gossiping authenticated pieces, which works both local and remote. We pay for the dispute by extracting some fee from the disputer, which they massively recoup when they win the dispute, and governance refunds if strange shit happens.

We'd need some fee even to run an availability game, so making the fee a bit larger justifies gossiping all the pieces, and simplifies the code significantly. It's maybe costs governance more work since validators ask for refunds more when shit breaks, except really almost all the work there comes from the devs fixing whatever broke.

We would only need a new process if there wasn't already one on this chain or it was very old.

After some discussion with Jeff, we decided that a proof that availability was decided on the old chain shouldn't be too hard, provided we fix timeout logic in such a way that we can understand it. Any votes for a particular bitfield, after the backing transaction was included and before the timeout are either for this block or else we did decide that it was avilable before they could be votes for a future block. This is particularly sensible if we still have the backing transaction in the new fork.

The parathread like process is the only way we can handle older disputes, especially if we start dealing with some information that we need being pruned or session changes. But it sounds harder to code.

We can just gossip the block. As long as we have faith that this works, we can slash evryone who attested to the block a large amount if it doesn't.

I'm seemingly winning @AlistairStewart over to my view, but with backers paying, not the disputer. We probably want both backers and disputer to pay I think.

The availability proof actually is not easy and interferes quite a lot with state pruning.

Not requiring a second round of availability and having any honest parties gossip PoV & ValidationCode needed to prove invalidity sounds good to me. We can construct it as a bounded gossip protocol based on open disputes in different chains.

We shouldn't need an availability proof if the thing is actually largely available. If it's unavailable, then the escalator should rightly be slashed. Right? And the best incentive is to slash the backers, which are > than the 1 escalator

I posted a suggestion below.

burdges · 2020-06-02T10:03:06Z

roadmap/implementors-guide/guide.md

+
+We assume that remote disputes are with respect to the same validator set as on the current fork, as BABE and GRANDPA assure that forks are never long enough to diverge in validator set [TODO: this is at least directionally correct. handling disputes on other validator sets seems useless anyway as they wouldn't be bonded.]
+
+As with local disputes, the validators of the session the candidate was included on another chain are responsible for resolving the dispute and determining availability of the candidate.


It's slightly hard to parse this sentence, but it seemingly says the disputed chain's validator set resolves the dispute on the good chain? I'm not so sure..

Yes, and because we buffer validator sets they should be the same. More specifically, a block included in session X on the bad chain should use the validators of session X on the good chain, not the validators of session X+k. But the validators of session X would be the same on both chains.

If they aren't, then there's no point even attempting to slash a remote session X, as they won't be guaranteed to be bonded on the local/good chain.

rphmeier · 2020-06-02T21:59:57Z

I've also been thinking a bit about what happens when a chain is reverted. In practice, I think we want something like this:

There is a special inherent that can be included in a block which removes a candidate from pending availability and contains all the information to start a remote dispute about that candidate, including an escalation (typically by the block author)
When reverting a chain or realizing that an escalation will lead to eventual reversion of the chain, as a validator we can include that inherent in any blocks we author on chains where that candidate has not been disputed.
This will have the side effect of removing the candidate from availability on any chains where it is backed

burdges · 2020-06-03T10:02:41Z

I think our scheme should go roughly:

We've the availability distribution design that distributes pieces for candidates backed in the current chain directly using QUIC. We've an execution intrinsic(?) for when a candidate actually runs that checks the availability bitfields.

We've a dispute extrinsic(?) that consists of a candidate receipt with at least one backer, but not necessarily enough backing, a signature by a disputer, and some validator set roll up that gives slashable validators including the backers and disputer. A dispute extrinsic can be posted to any chain with several consequences:

Availability:
- We gossip the candidate's availability pieces among all validators. Any validator who receives 1/3rd shall check the block and post their vote. We do not halt normal availability distribution for the candidate. We could discuss gossiping only full blocks not availability pieces here, but the savings seems small relative to everything else, and availability pieces give authenticated progress in smaller chunks.
Votes:
- Votes cannot be gossiped or posted without the dispute extrinsic, but otherwise they can be copied to any chain, like the dispute extrinsic itself. We determine disputers and voters by the source chain, hence the validator set roll up, but disputers and voters must be slashable on the current chain.
- If 2f+1 vote valid or invalid then the loosing side gets slashed 100%, and non-voters eventually have their earnings penalized but not booted.
- If neither side gets 2f+1 then the candidate is deemed invalid, but neither side gets slashed per se, and instead all valid voters including backers have their earnings reduced to compensate for the distraction but again not booted. These distraction fees cover (a) most validators checking and storing the full block for some time and (b) an expected fork cost.
Fork choice:
- If the associated execution intrinsic was not yet posted, then it cannot be posted unless the vote concludes the candidate is valid. We could maybe weaken this to relay chain block producers who vote valid being allowed to post it, but probably unhelpful.
- If the associated execution intrinsic was posted, then the chain becomes invalid once we reach f+1 invalid votes. We need not abandon chain with less than f+1 invalid votes, but our fork choice rule could anticipate the vote in various way. Any relay chain block producer who votes invalid cannot build upon chains containing the associated execution intrinsic.

rphmeier · 2020-06-03T15:57:50Z

Generally looks good.

instead all valid voters including backers have their earnings reduced to compensate for the distraction but again not booted

Not sure how we do this. @thiolliere is there a reward points mechanism for this? @burdges over what period do we need to reduce earnings? @AlfonsoCev how much do we need to do this, economically speaking?

If the associated execution intrinsic was not yet posted, then it cannot be posted unless the vote concludes the candidate is valid. We could maybe weaken this to relay chain block producers who vote valid being allowed to post it, but probably unhelpful.

If the candidate is in the availability stage and occupying an availability core, I'd rather just remove the thing from availability so that it doesn't occupy an availability core the entire time the dispute is ongoing. If the candidate turns out to be good, the validators will get paid for their time, but the para could proceed regardless.

Not removing the thing from availability means we need to roll back further than strictly necessary.

Any relay chain block producer who votes invalid cannot build upon chains containing the associated execution intrinsic.

This is hard to enforce. But worth noting that any relay chain fork that has included the invalid candidate will have a remote dispute started on it that will eventually blacklist the chain, if it has any chance of becoming a viable chain.

burdges · 2020-06-03T16:13:57Z

We should avoid creating any mechanism for booting validators who maybe did nothing wrong, so "reduce earnings" means "minor slash without booting". We might require the slashing system here simply because the validators could come from some other chain. We can support that more easily in the slashing system than in the earnings system. We could otoh avoid the slashing system by restricting to the validators' self stake, assuming this stays cheap enough, which makes it simple across chains.

Yes, I suppose parathread want those cores liberated fast. We've changed the availability scheme from directed to gossiped to everyone, so yes we could just free up the core here.

We've lingering concerns about censoring parachains/parathreads here, or even censoring the relay chain with roll backs, which complicates saying when we fork the chain. In principle, we often fork only a block or so, and continue with the availability game almost done, but yes the dispute replaces the availability game.

burdges · 2020-06-04T10:26:26Z

I'll clarify for others: We cannot penalize anyone for not voting without an availability roll up, but doing a roll up sucks. We're discussing the "no roll up" design that

penalizes non-voters only when one sides gets 2f+1, and
makes "valid" voters pay distraction fees when neither side gets 2f+1 votes.

We need 1 to compensate for the harmful incentives created by 2 of course.

We could discuss further reduce the harmful incentives created by 2 by doing an availability roll up, but postpone any implementation work on this until next year, and after we've better formalized the protocol.

burdges · 2020-06-04T20:09:27Z

roadmap/implementors-guide/guide.md

+
+The goal of the dispute is to garner a 2/3+ (2f + 1) supermajority either in favor of or against the candidate.
+
+For remote disputes, it is possible that the parablock disputed has never actually passed any availability process on any chain. In this case, validators will not be able to obtain the PoV of the parablock and there will be relatively few votes. We want to disincentivize voters claiming validity of the block from preventing it from becoming available, so we charge them a small distraction fee for wasting the others' time if the dispute does not garner a 2/3+ supermajority on either side. This fee can take the form of a small slash or a reduction in rewards.


".. a small slash that does not chill or .."

We should discuss if the distraction fee should chill/boot validators @AlistairStewart

Pro-chill: Anyone who voted valid could gossip the pieces themselves.
Anti-chill: Attackers could file false disputes so that DoS attacks cause chilling.

Can DoS attack chill anyways via ImOnline? If so, maybe fix that one day..

Pro-chill: currently only nonzero slash chills.

@burdges What do you say about deferring this to a follow-up PR? I don't believe it substantially alters the meaning of the text, but is worth addressing

burdges · 2020-06-04T20:10:24Z

roadmap/implementors-guide/guide.md

+
+For remote disputes, it is possible that the parablock disputed has never actually passed any availability process on any chain. In this case, validators will not be able to obtain the PoV of the parablock and there will be relatively few votes. We want to disincentivize voters claiming validity of the block from preventing it from becoming available, so we charge them a small distraction fee for wasting the others' time if the dispute does not garner a 2/3+ supermajority on either side. This fee can take the form of a small slash or a reduction in rewards.
+
+When a supermajority is achieved for the dispute in either the valid or invalid direction, we will penalize non-voters either by issuing a small slash or reducing their rewards. We prevent censorship of the remaining validators by leaving the dispute open for some blocks after resolution in order to accept late votes.


Again "that does not chill" probably

rphmeier added 3 commits May 31, 2020 18:45

clarify exception to communication rule for responses

72a4219

add note about outside world

179b807

write up my understanding of local and remote disputes

4566ff3

rphmeier added A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes labels Jun 1, 2020

burdges reviewed Jun 1, 2020

View reviewed changes

roadmap/implementors-guide/guide.md Outdated Show resolved Hide resolved

burdges reviewed Jun 1, 2020

View reviewed changes

roadmap/implementors-guide/guide.md Show resolved Hide resolved

burdges reviewed Jun 2, 2020

View reviewed changes

clean up secondary checker language

fc8f55c

rphmeier mentioned this pull request Jun 2, 2020

Add an overview of Validity subsystems #1161

Merged

rphmeier mentioned this pull request Jun 3, 2020

Allow reverting finality and blacklisting chains. paritytech/substrate#6224

Open

amend to match Jeff's notes

8bb851f

burdges reviewed Jun 4, 2020

View reviewed changes

rphmeier mentioned this pull request Jun 5, 2020

Write out stubs for most backing and availability subsystems #1199

Merged

rphmeier merged commit 798f605 into master Jun 5, 2020

rphmeier deleted the rh-guide-edits branch June 5, 2020 17:55

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add exception to overseer communication and write up local and remote disputes #1176

Add exception to overseer communication and write up local and remote disputes #1176

rphmeier commented Jun 1, 2020

burdges Jun 2, 2020

rphmeier Jun 2, 2020

burdges Jun 2, 2020 •

edited

Loading

AlistairStewart Jun 2, 2020

AlistairStewart Jun 2, 2020

burdges Jun 2, 2020

rphmeier Jun 2, 2020 •

edited

Loading

burdges Jun 3, 2020

burdges Jun 2, 2020

rphmeier Jun 2, 2020 •

edited

Loading

rphmeier commented Jun 2, 2020

burdges commented Jun 3, 2020 •

edited

Loading

rphmeier commented Jun 3, 2020

burdges commented Jun 3, 2020

burdges commented Jun 4, 2020 •

edited

Loading

burdges Jun 4, 2020

rphmeier Jun 4, 2020

rphmeier Jun 4, 2020

burdges Jun 5, 2020

burdges Jun 4, 2020


		When beginning a remote dispute, at least one escalation by a validator is required, but this validator may be malicious and desires to be slashed. There is no guarantee that the para is registered on this fork of the relay chain or that the para was considered available on any fork of the relay chain.

		So the first step is to have the remote dispute proceed through an availability process similar to the one in [the Inclusion Module](#The-Inclusion-Module), but without worrying about core assignments or compactness in bitfields.


		We assume that remote disputes are with respect to the same validator set as on the current fork, as BABE and GRANDPA assure that forks are never long enough to diverge in validator set [TODO: this is at least directionally correct. handling disputes on other validator sets seems useless anyway as they wouldn't be bonded.]

		As with local disputes, the validators of the session the candidate was included on another chain are responsible for resolving the dispute and determining availability of the candidate.


		The goal of the dispute is to garner a 2/3+ (2f + 1) supermajority either in favor of or against the candidate.

		For remote disputes, it is possible that the parablock disputed has never actually passed any availability process on any chain. In this case, validators will not be able to obtain the PoV of the parablock and there will be relatively few votes. We want to disincentivize voters claiming validity of the block from preventing it from becoming available, so we charge them a small distraction fee for wasting the others' time if the dispute does not garner a 2/3+ supermajority on either side. This fee can take the form of a small slash or a reduction in rewards.


		For remote disputes, it is possible that the parablock disputed has never actually passed any availability process on any chain. In this case, validators will not be able to obtain the PoV of the parablock and there will be relatively few votes. We want to disincentivize voters claiming validity of the block from preventing it from becoming available, so we charge them a small distraction fee for wasting the others' time if the dispute does not garner a 2/3+ supermajority on either side. This fee can take the form of a small slash or a reduction in rewards.

		When a supermajority is achieved for the dispute in either the valid or invalid direction, we will penalize non-voters either by issuing a small slash or reducing their rewards. We prevent censorship of the remaining validators by leaving the dispute open for some blocks after resolution in order to accept late votes.

Add exception to overseer communication and write up local and remote disputes #1176

Add exception to overseer communication and write up local and remote disputes #1176

Conversation

rphmeier commented Jun 1, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

burdges Jun 2, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rphmeier Jun 2, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rphmeier Jun 2, 2020 • edited Loading

Choose a reason for hiding this comment

rphmeier commented Jun 2, 2020

burdges commented Jun 3, 2020 • edited Loading

rphmeier commented Jun 3, 2020

burdges commented Jun 3, 2020

burdges commented Jun 4, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

burdges Jun 2, 2020 •

edited

Loading

rphmeier Jun 2, 2020 •

edited

Loading

rphmeier Jun 2, 2020 •

edited

Loading

burdges commented Jun 3, 2020 •

edited

Loading

burdges commented Jun 4, 2020 •

edited

Loading