-
Notifications
You must be signed in to change notification settings - Fork 16
feat: gossiping the latest valset in P2P layer in case they get pruned #560
Conversation
orchestrator/broadcaster.go
Outdated
@@ -3,6 +3,8 @@ package orchestrator | |||
import ( | |||
"context" | |||
|
|||
types2 "github.com/celestiaorg/celestia-app/x/qgb/types" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the standard thing is naming this qgbtypes
instead of types2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
definitely not blocking, just for future reference, celestiatypes
is better, but imo we should be specific with our imports to improve readability. for instance, what happens if we need to import "github.com/celestiaorg/celestia-app/x/blob/types"
or "github.com/celestiaorg/celestia-core/types"
as well? personally I'm not a fan of naming everything types, but the sdk and tendermint don't agree lol
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
concerning this, what do you think of making it a rule in CI? I looked for existing tools that can do this but found none, so maybe we can do a simple bash script that takes all the imports in the project, filter those we want to have the same name across all repos, then check whether the right name is used or not.
I don't think it's worth it tbh, it would just make it harder to commit code, but if there is a good reason for it, I'm in
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I'm 100% down for adding CI to look at import names. For packages with types I think we could define a linter that is generic enough to be useful. Not sure about other package names that frequently require renaming
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
p2p/dht.go
Outdated
// GetLatestValset looks for the latest valset in the DHT. | ||
// The key will be returned by the `GetValsetKey` method. | ||
// Returns an error if it fails. | ||
func (q BlobstreamDHT) GetLatestValset(ctx context.Context) (types2.Valset, error) { | ||
encoded, err := q.GetValue(ctx, GetLatestValsetKey()) // this is a blocking call, we should probably use timeout and channel | ||
if err != nil { | ||
return types2.Valset{}, err | ||
} | ||
valset, err := types.UnmarshalValset(encoded) | ||
if err != nil { | ||
return types2.Valset{}, err | ||
} | ||
return valset, nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iirc, you mentioned that the the main concern with this approach is that we aren't verifying the valdiator set that is gossipped. Would that be possible though (in a futuer PR ofc)? We should be able to query the current validator set, and from that we should be able to measure the diff in power between the one we recieve that this one afaiu.
does that make sense or am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, we could, but I didn't want to add that check because it will be checked implicitly when sending the update to Blobstream. So, no need to do it explicitly here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you mind pointing out that check really quickly for my own understanding? thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will be done here:
in the contract
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but is it possible to gossip and invalid value? also, isn't the issue for folks deploying a new contract? would that check still be hit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, an invalid value can be gossiped, but will be rejected by the contract when relaying events.
For the deployment part, I didn't implement the ability to use the P2P valset to deploy because it's super risky and there is no way to trust it.
only some minor comments, but otherwise LGTM |
Co-authored-by: Evan Forbes <[email protected]>
Actually, I am facing an issue with the serialization of date to json. If you check the CI, you will see the tests failing, however, they're not failing locally. But when I use a different environment, they still fail expecting different time. So, I am thinking of actually omitting the time during serialization since it's not needed to create the hash or calculate the threshold etc. |
@evan-forbes I did 755ff25 to fix the issue of serialization via creating a struct that doesn't have the The What do you think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still thinking about the extra gossiping check. I think we might need something like it (see that thread), but that shouldn't block this PR
the getting rid of the time makes sense. in the past with serializing time that needed to be kept, I've often had to overwrite marshaling methods to fix that one annoying type. |
Can you link me to some code that does this? I'm curious |
Added the changes discussed async. Will wait until we test this using an archive node to merge. |
Codecov Report
@@ Coverage Diff @@
## main #560 +/- ##
==========================================
+ Coverage 34.23% 34.80% +0.56%
==========================================
Files 26 27 +1
Lines 2100 2221 +121
==========================================
+ Hits 719 773 +54
- Misses 1295 1354 +59
- Partials 86 94 +8
|
I will merge this and test it once we have an archive node ready for testing. And if something is broken, we can fix it in a separate PR. |
Overview
Closes #556
Checklist