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

Specify BABE Temporary Clock Adjustment #263

Open
8 tasks
FlorianFranzen opened this issue Aug 17, 2020 · 2 comments
Open
8 tasks

Specify BABE Temporary Clock Adjustment #263

FlorianFranzen opened this issue Aug 17, 2020 · 2 comments
Assignees
Labels
specification Additions and Updates to the Specification

Comments

@FlorianFranzen
Copy link
Contributor

FlorianFranzen commented Aug 17, 2020

The basic idea of the algorithm is described in the research writeup.

However, to actually provide implementers with enough information to implement the algorithm, we will have to discuss the following open questions:

  • How does a host determine that his "clock does not work anymore?"
  • How does a host deal with software restarts?
    • Persistence of arrival times?
    • Persistence of clock synchronization?
  • How to ensure less the 5% temp. adjusters?
  • Do we really want to depend on GRANDPA?
  • Extend use of timestamp inherent?
  • How to dynamically change slot time and other params?
@FlorianFranzen FlorianFranzen self-assigned this Aug 17, 2020
@FlorianFranzen FlorianFranzen added the specification Additions and Updates to the Specification label Aug 17, 2020
@hndnklnc
Copy link

hndnklnc commented Oct 2, 2020

  • How does a host determine that his "clock does not work anymore?

I believe you mean by the clock does not work anymore is that the difference between the host and others are more than the expected difference. The purpose of the relative time protocol is to keep this difference small. So, as long as, the host runs the relative time, then his clock works always. If he was not able to run the relative time protocol because of e.g. disconnection or some other problem, then he can assume that his clock does not work anymore. So the short answer is that a host determines that his clock does not work anymore if he was not able to run the relative time protocol as specified.

I think a host can determine that he did not run the relative time protocol correctly when he sees in the final chain some blocks that he has never stored the arrival time of this block.

@FlorianFranzen
Copy link
Contributor Author

I will have to write up session key types and usage and the get in touch with @burdges

@FlorianFranzen FlorianFranzen added this to the Next release (v0.2.1) milestone Mar 25, 2022
@FlorianFranzen FlorianFranzen removed their assignment May 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
specification Additions and Updates to the Specification
Projects
None yet
Development

No branches or pull requests

2 participants