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

hare3: support multiple smeshers #5085

Closed
Tracked by #261
dshulyak opened this issue Sep 26, 2023 · 0 comments
Closed
Tracked by #261

hare3: support multiple smeshers #5085

dshulyak opened this issue Sep 26, 2023 · 0 comments

Comments

@dshulyak
Copy link
Contributor

dshulyak commented Sep 26, 2023

the end goal is to support multiple identities in hare3 protocol

storing multiple smeshers and registration

type Hare needs to store collection of smeshers, this collection is extended with a Register(Smesher) call.

type Protocol interface {
    Register(*EdSigner)
}

Register can't fail, so if atx doesn't exist yet it simply registers smesher in the internal collection.

in order to prevent new participants joining mid session when hare session starts, session needs to copy pointers to registered smeshers at that time and store them in different collection.

eligibility and emitting messages

computing ecvrf is ~200us. ed25519 sig is ~100us.

lets assume that we target 10_000 identities. that is about 3s of on cpu time for every message. we need to parallelize that to support this amount. the efficient approach would be to create N worker goroutines managed by hare. each worker will accept batch of vrf's to compute / messages to sign and output result. this is also good change that can be submitted after initial implementation to simplify review.

we also should disable vrf / sig verification which is run when nodes Publish message. to implement check that message is emitted by our own host.ID() and do the necessary skip.

to vote on the same set of proposals, proposals method should be modified to not vote on the proposal if atx that belongs to any smesher is lower than the proposals base height.

otherrefactoring

reference to vrf signer needs to be moved out of the legacy oracle https://github.com/spacemeshos/go-spacemesh/blob/develop/hare/eligibility/oracle.go#L75

@dshulyak dshulyak moved this to 📋 Backlog in Dev team kanban Sep 26, 2023
@dshulyak dshulyak moved this from 📋 Backlog to 🔖 Next in Dev team kanban Sep 27, 2023
@dshulyak dshulyak self-assigned this Sep 27, 2023
bors bot pushed a commit that referenced this issue Oct 6, 2023
closes: #5085

this change refactors original hare oracle to accept key that will be used to determine eligibility. and extends hare3 with a collection of keys that can be used to participate from the same physical node.

limitation is that ecvrf and ed signatures are computed sequentially and may cause messages to be delayed, if number of nodes are larger then 100. larger numbers are useful only if we expect it to be used with smallest possible atxs, which is by itself a problem.
@dshulyak dshulyak moved this from 🔖 Next to 🏗 Doing in Dev team kanban Oct 6, 2023
@bors bors bot closed this as completed in d70d8c7 Oct 6, 2023
@dshulyak dshulyak moved this from 🏗 Doing to ✅ Done in Dev team kanban Oct 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant