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

GHOST estimator should return _children_ of the heaviest subtree. #28

Open
afck opened this issue Mar 20, 2019 · 5 comments
Open

GHOST estimator should return _children_ of the heaviest subtree. #28

afck opened this issue Mar 20, 2019 · 5 comments

Comments

@afck
Copy link
Contributor

afck commented Mar 20, 2019

Definition 4.31 (Casper the Friendly Ghost) gives the estimator as:
ℰ(σ) = GHOST({g}, σ)
which is the set of all blocks occurring in σ that are reachable from the genesis block g by always picking a child with maximum score. In particular, all elements of ℰ(σ) are blocks that are already the estimate of a message in σ, so that estimator wouldn't allow creating new blocks.

Should that definition be changed to instead allow all conceivable children of the elements of GHOST({g}, σ)? Because the next estimate should not be a block that has been proposed before, but a new child.

@adiasg
Copy link
Contributor

adiasg commented Mar 20, 2019

The purpose of the estimator here is to return the tip blocks winning under the GHOST rule. It doesn't return new blocks for proposal from a given protocol state.

We should introduce a dichotomy in the usage of estimator: generate new blocks vs. verify blocks in protocol state. The estimator function that generates new blocks will be useful in describing validator behavior, and hence isn't mentioned in this draft (which concerns itself with reasoning about things after we reach a particular protocol state).

@afck
Copy link
Contributor Author

afck commented Mar 20, 2019

I understand that the GHOST function is meant to return the winning tips.
But the estimator ℰ(σ) defines what consitutes a legal message: A message's estimate is required to be an element of ℰ(σ), where σ is the message's justification (Definition 2.7). That means if in σ, all estimates are g, then with the above estimator, ℰ(σ) = {g}, and therefore the new message's estimate also must be g. Thus all messages in all protocol states would have estimate g.

If I'm not misreading this, I think the definition 4.31 should be something like this instead:
ℰ(σ) = {b | Prev(b) ∈ GHOST({g}, σ)}

@HarikrishnanBalagopal
Copy link

HarikrishnanBalagopal commented Mar 7, 2021

I understand that the GHOST function is meant to return the winning tips.
But the estimator ℰ(σ) defines what consitutes a legal message: A message's estimate is required to be an element of ℰ(σ), where σ is the message's justification (Definition 2.7). That means if in σ, all estimates are g, then with the above estimator, ℰ(σ) = {g}, and therefore the new message's estimate also must be g. Thus all messages in all protocol states would have estimate g.

If I'm not misreading this, I think the definition 4.31 should be something like this instead:
ℰ(σ) = {b | Prev(b) ∈ GHOST({g}, σ)}

Yes but it's actually even worse than that because the way it is defined now, it goes into an infinite recursion:
image
image
image

  1. We call GHOST({g}, \sigma) where \sigma = {(g, v1, {}), (g, v2, {}), (g, v3, {})}
  2. The children of g is {g} (because prev(g) = g)
  3. So best children will also be {g}.
  4. So you end up calling GHOST({g}, \sigma) again.

Sidenote:
@afck @adiasg are you guys maintainers on this repo? There are some open issues and pull requests that are from 2018 and 2019 that haven't been resolved yet. Has the repo been abandonded?

@afck
Copy link
Contributor Author

afck commented Mar 7, 2021

No, I'm not a maintainer.

@adiasg
Copy link
Contributor

adiasg commented Mar 7, 2021

I'm not a current maintainer. Unaware of the status of this repo.

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

No branches or pull requests

4 participants
@afck @HarikrishnanBalagopal @adiasg and others