This repository was archived by the owner on Nov 15, 2023. It is now read-only.
Add challenge phase to multi-phase crate #8253
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
coriolinus
added
A3-in_progress
Contributor
Author
|
After discusssion, it appears that the challenge phase should come after the unsigned phase. If the best current solution is successfully challenged, then we just have to fall back to on-chain elections. |
Initially, I'd put the challenge phase before the unsigned phase. The reasoning was that at the end of the signed phase, we had a stack of potential solutions, and in the event of a successful challenge to one of them, we could simply fall back to the next. However, it turns out that for efficiency, we only perform the transform which creates the input data for a PJR check after doing the feasibility checks. In other words, a miner attempting to do PJR checks on the input stack would need to do that transform themselves, which is more work than we wish to require of them. Also, putting the challenge phase after the unsigned phase is an important protection against a malicious validator. An evil validator could in theory simply ignore the goodness of the signed solution and submit its own, unfair solution. Having the challenge phase after the unsigned phase means that there is recourse in the event that such a validator does so: if the validator submits a solution that violates PJR, then miners have incentive to challenge that solution, which would result in the validator being slashed. This should result in a nash equilibrium which favors validators remaining honest.
coriolinus
force-pushed
the
prgn-challenge-phase
branch
from
1e30225 to
ec9c1d6
Compare
Contributor
|
@coriolinus I highly think that this PR will not come to action anytime within the next month or so, and it has already been stale for a month. I think if I don't close it for now, @gnunicorn will someday soon anyhow :D shall we close to keep both the PR list and project columns cleaner? |
Contributor
Author
|
Sure, it'll probably be easier to restart from scratch than to handle all
the merge conflicts which will arise.
…On Thu, Apr 1, 2021 at 2:10 PM Kian Paimani ***@***.***> wrote:
@coriolinus <https://github.com/coriolinus> I highly think that this PR
will not come to action anytime within the next month or so, and it has
already been stale for a month. I think if I don't close it for now,
@gnunicorn <https://github.com/gnunicorn> will someday soon anyhow :D
shall we close to keep both the PR list and project columns cleaner?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8253 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3V4TXO2HM54ENTBP5PA4DTGRPCTANCNFSM4YRG7LXA>
.
--
Wichtige Mitteilung
Diese Mitteilung wurde von Parity Technologies
Deutschland GmbH kommuniziert, eine im Handelsregister des Amtsgerichtes
Charlottenburg unter HRB 190583 B registrierte Gesellschaft mit
beschränkter Haftung (GmbH). Die Geschäftsführerin der GmbH ist Frau Dr.
Jutta Steiner. Der registrierte Geschäftssitz ist Glogauer Straße 6 in
10999 Berlin, Deutschland.
Diese Mitteilung enthält Informationen welche
vertraulich sind und welche eventuell die Vertraulichkeit der
Rechtsberatung ("Anwaltsgeheimnis") berühren. Sie ist ausschließlich für
den/die vorgesehenen Empfänger bestimmt. Wenn Sie nicht der/die
beabsichtigte(n) Empfänger sind, benachrichtigen Sie bitte ***@***.***
***@***.***> und löschen Sie diese Nachricht sofort.
Unsere
Datenschutzrichtlinie, einschließlich die Art und den Umfang von
personenbezogenen Daten, die wir erfassen, wie wir diese Daten erfassen und
verarbeiten, an wen wir sie in Bezug auf die von uns angebotenen Dienste
weitergeben dürfen, sowie bestimmte Rechte und Optionen, die Sie in dieser
Hinsicht haben, finden Sie unter: https://www.parity.io/privacy/
<https://www.parity.io/privacy/>
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Requires #8236 and #7910.
Adds an explicit challenge phase to the multi-phase election system. This helps ensure that all transactions satisfy PJR, which is an absolute quality floor.
Note that this currently puts the challenge phase currently falls after the signed phase, not after the unsigned phase. This is so that when a solution is successfully challenged, we can fall back to the next in the queue. However, that brings the obvious problem that unsigned solutions cannot be checked. Very willing to adjust that part of the design if necessary.