Define voting HIR format #110
Conversation
zeegomo
force-pushed
the
define-voting-hir
branch
from
c052c6f to
01e0450
Compare
zeegomo
force-pushed
the
define-voting-hir
branch
from
65c11a2 to
bc768d0
Compare
zeegomo
force-pushed
the
define-voting-hir
branch
from
451b395 to
c3af7b6
Compare
| /// key will be used. | ||
| pub voting_group: VotingGroup, | ||
| /// Voting power as processed by the snapshot | ||
| pub voting_power: Value, |
There was a problem hiding this comment.
Am I right that voting_power is referenced to the voting_key ?
| /// You can roughly read this as | ||
| /// "voting_key will participate in this voting round with role voting_group and will have voting_power influence" | ||
| pub struct VotingHIR { | ||
| pub voting_key: Identifier, |
There was a problem hiding this comment.
Is voting_key a user Identifier ? If so maybe it is better to rename it to users_voting_key to reflect that it belongs to user.
Otherwise I think we should provide a description for this field.
There was a problem hiding this comment.
I mean, who should this voting key belong to otherwise? If we rename the struct to VoterHIR would this be clearer?
There was a problem hiding this comment.
Yes, it looks better to me
| pub struct VotingHIR { | ||
| pub voting_key: Identifier, | ||
| /// Voting group this key belongs to. | ||
| /// If this key belong to multiple voting groups, multiple records for the same |
There was a problem hiding this comment.
But why does not to store it inside an array if we have multiple records ?
There was a problem hiding this comment.
I don't get what you are suggesting
There was a problem hiding this comment.
I am talking about to replace pub voting_group: VotingGroup, to the pub voting_group: Vec<VotingGroup>,, so to not create a one record for the voting_key
There was a problem hiding this comment.
but those voting groups might have different voting power, so you should also have a Vec of voting power, but then the relation between the two is not so tight anyway. Also, in the beginning we're probably only going to have one group per voter anyway, and this seems like the simplest solution to ma that is both not an overkill for now and flexible enough in the future.
| /// | ||
| /// You can roughly read this as | ||
| /// "voting_key will participate in this voting round with role voting_group and will have voting_power influence" | ||
| pub struct VoterHIR { |
There was a problem hiding this comment.
are we going to implement serde traits for this?
There was a problem hiding this comment.
Yes, even though we may want to serialize the voting key differently from the default bech32 encoding (e.g. hex). Maybe I should add some helper methods for that here
zeegomo
force-pushed
the
update-snapshot
branch
from
0419818 to
36a07ce
Compare
zeegomo
force-pushed
the
define-voting-hir
branch
from
4496c51 to
b3cc0df
Compare
|
superseded by #129 |
3 participants
Define High Level Intermediate Representation (HIR) for voting entities in the Catalyst ecosystem.
This is intended as a high level description of the setup, which is not enough on its own to spin a blockchain, but it's slimmer, easier to understand and free from implementation constraints.
You can roughly read this as "voting_key will participate in this voting round with role voting_group and will have voting_power influence"
This builds on the concept of voting groups as described in input-output-hk/vit-servicing-station#198
This is an intermediate step in the proposed process of spinning up a blockchain from the raw mainnet snapshot.
Such process is planned to look as follow:
Not sure if catalyst toolbox is actually the correct place to host this.