Add data commitment logic #222
Conversation
|
@evan-forbes Please take a look if this is in the right direction. And also couple questions when you have time:
|
This just means that we have to effectively check that the signature provided is valid and is actually from the relevant eth address for that validator. This involves checking the current state to see what address is the one that is currently associated with that validator, and then verifying the evm friendly signature. This is typically done in the gravity module via this func |
|
@evan-forbes This means we need to add an extra field to |
|
That's a good question, while I think we could do either, I think staying consistent with the gravity bridge and |
|
Cool. Will try the former, and if it doesn't work, I will switch. Thanks |
…ta commitments confirm messages
x/qgb/config.go
Outdated
| config := sdk.GetConfig() | ||
| config.SetBech32PrefixForAccount(bech32PrefixAccAddr, bech32PrefixAccPub) | ||
| config.SetBech32PrefixForValidator(bech32PrefixValAddr, bech32PrefixValPub) | ||
| config.SetBech32PrefixForConsensusNode(bech32PrefixConsAddr, bech32PrefixConsPub) |
There was a problem hiding this comment.
Will we need also the consensus bech32 prefixes ?
There was a problem hiding this comment.
while it might not be done using this exact mechanism, this is already done using celes, so we should avoid doing this again using qgb. Surprised this doesn't break anything lol
There was a problem hiding this comment.
This is defined inside the module... maybe it is picked up per module?
There was a problem hiding this comment.
It makes sense for them to have it in their module, as they want to have grav addresses, but not ours as we will have celes. sdk.GetConfig is global (hence the "sealing"), and having different address types per module is not an sdk feature I'm aware of. The only addresses that we should have to manage are done so via the orchestrator and eth addresses, which we are keeping in the state.
Do things break when we remove them?
There was a problem hiding this comment.
not at all. Ill remove them then.
| } | ||
|
|
||
| prefixStore := prefix.NewStore(ctx.KVStore(k.storeKey), []byte(types.DataCommitmentConfirmKey)) | ||
| start, end := prefixRange([]byte(types.DataCommitmentConfirmKey)) // FIXME can we make this faster ? |
There was a problem hiding this comment.
This is supposed to be iterating over the whole data commitments store, right ?
There was a problem hiding this comment.
I think so, but am still ivestigating/thinking about this
x/qgb/config.go
Outdated
| config := sdk.GetConfig() | ||
| config.SetBech32PrefixForAccount(bech32PrefixAccAddr, bech32PrefixAccPub) | ||
| config.SetBech32PrefixForValidator(bech32PrefixValAddr, bech32PrefixValPub) | ||
| config.SetBech32PrefixForConsensusNode(bech32PrefixConsAddr, bech32PrefixConsPub) |
There was a problem hiding this comment.
while it might not be done using this exact mechanism, this is already done using celes, so we should avoid doing this again using qgb. Surprised this doesn't break anything lol
| } | ||
|
|
||
| prefixStore := prefix.NewStore(ctx.KVStore(k.storeKey), []byte(types.DataCommitmentConfirmKey)) | ||
| start, end := prefixRange([]byte(types.DataCommitmentConfirmKey)) // FIXME can we make this faster ? |
There was a problem hiding this comment.
I think so, but am still ivestigating/thinking about this
| for ; iterator.Valid(); iterator.Next() { | ||
| confirm := types.MsgDataCommitmentConfirm{} | ||
| k.cdc.MustUnmarshal(iterator.Value(), &confirm) | ||
| if confirm.BeginBlock <= beginBlock && confirm.EndBlock >= endBlock { | ||
| confirms = append(confirms, confirm) | ||
| } | ||
| } |
There was a problem hiding this comment.
note to self: dig into this more
|
@evan-forbes If this PR is good. We can merge :D |
* adds msgs + query proto * adds data commitment basic functions * adds data commitment query skeleton + server emitting events * linter changes * adds data commitment keeper + basic queries * persisting data commitment confirm on submission * adds data commitment confirms by validator query * adds verification for validator and ethereum address when handling data commitments confirm messages * adds data commitment by range keeper + query * adds comments * adds staking keeper to qgb and GetOrchestratorValidator implementation * adds delegate key query * adds qgb module address config * cosmetics * removes unnecessary comment * uses restricted version of staking keeper for QGB * cosmetics * removes config file
Adds data commitment logic.
Closes: #199