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

Implement broadcasting preimage #492

Closed
lunalee1012 opened this issue Jan 21, 2020 · 4 comments
Closed

Implement broadcasting preimage #492

lunalee1012 opened this issue Jan 21, 2020 · 4 comments

Comments

@lunalee1012
Copy link

@lunalee1012 lunalee1012 commented Jan 21, 2020

After registering as a validator in round R, a node must broadcast the preimage every round from round R + 1 based on the white paper. It ensures true randomness of the network without ability to manipulate data.

But, as described in the white paper, a node could regularly broadcasts multiple preimages in order to survive network outages. It might be efficient to broadcast multiple preimages periodically
at certain intervals instead of in every round.

Definition of Done:

  • The enrollment manager saves all preimages while hashing random number n times before enrollment.

  • A node broadcasts preimages and the round #s of the preimages through the gossip protocol.

  • The enrollment manager saves the received preimages and the round numbers into the DB.

How to implement:

  • The enrollment manager saves preimages into the DB in creating enrollment data and make registering(=enrolling) preceed with Q(=12) preimages.(The proper value of Q should be searched)

  • An API point called revealPreimages in every P(=1) hours with Q preimages.(The proper value of P should be searched)

  • The enrollment manager saves the preimages and round numbers of other validators into the DB.

  • The enrollment manager checks the validity of preimages received through the API and set an flag for an invalid validator into the DB or propagate the information of the invalid validator (it could be another new issue)

@AndrejMitrovic

This comment has been minimized.

Copy link
Member

@AndrejMitrovic AndrejMitrovic commented Jan 21, 2020

Also, according to the Yellow paper, a node can reveal multiple preimages in advance. This is in order to survive network outages.

@linked0

This comment has been minimized.

Copy link
Contributor

@linked0 linked0 commented Jan 21, 2020

Based on @AndrejMitrovic comment, I changed the API name to revealPreimages.

@AndrejMitrovic

This comment has been minimized.

Copy link
Member

@AndrejMitrovic AndrejMitrovic commented Jan 28, 2020

Also, according to the Yellow paper, a node can reveal multiple preimages in advance. This is in order to survive network outages.

Actually it doesn't have to reveal "multiple" ones. It just has to reveal the preimage for a specific block height.

For example, if a Node wishes to reveal preimages for the range of blocks #100 to #200, It could reveal the preimage for block height #200. Because it is a preimage, other nodes can figure out the preimage at block height #100 by hashing the preimage of block height #200 a 100 times.

Does it make sense to you?

@linked0

This comment has been minimized.

Copy link
Contributor

@linked0 linked0 commented Jan 28, 2020

It really makes sense. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.