Primev poc #629
Primev poc #629
Conversation
…r to use this config
| received_bid_digest text NOT NULL, | ||
| received_bid_signature text NOT NULL, | ||
| bidder_node_address text NOT NULL, | ||
| PRIMARY KEY (provider_address, commitment_digest, block_number) |
There was a problem hiding this comment.
isn't there a canonical commitment hash we can use as primary key? If not, commitment_digest and provider_address alone should be unique without including the block_number, shouldn't it?
There was a problem hiding this comment.
the commitment hash is not sent back when submitting Bid via grpc, anyway we can use commitment_digest and provider_address as primary key.
| optional TraceContext trace = 3; | ||
| } | ||
|
|
||
| message Commitment { |
There was a problem hiding this comment.
can we import this from the primev repo instead of copy and pasting it?
There was a problem hiding this comment.
it does not support our message handler interface, that's why I had to create this new message
| @@ -0,0 +1,286 @@ | |||
| package primev | |||
There was a problem hiding this comment.
Can we use the multi event syncer from the service keyper here? The point of it was to avoid repeating all the event syncing code. Probably best to move it to medley so we don't have cross-keyperimpl dependencies. See e.g. eventtriggerregisteredprocessor.go for an example how to use it.
There was a problem hiding this comment.
makes sense, lets add it in a separate PR
| -- the schema. We'll use this to check we're using the right schema. | ||
|
|
||
| CREATE TABLE commitment( | ||
| tx_hashes text[] NOT NULL, |
There was a problem hiding this comment.
We have a separate table for txs. Does tx_hashes correspond to them? If so, we should get rid of the duplication and rely on referencing them (if it's for convenience it's better to aggregate in a query).
There was a problem hiding this comment.
yes, the query is already aggregated as InsertMultipleTransactionsAndUpsertCommitment
|
|
||
| // TODO: before sending the dec trigger, we need to check if majority of providers have generated commitments | ||
|
|
||
| h.decryptionTriggerChannel <- broker.NewEvent(decryptionTrigger) |
There was a problem hiding this comment.
I'm not sure if it's a good idea to send the trigger in the handler directly or if we should rather only dump the commitments in the db and then check in a separate goroutine if a trigger should be sent. I guess the advantage of doing it here is that it most tight timing-wise, but conceptually it seems wrong and we potentially delay propagation of the commitment.
There was a problem hiding this comment.
Also, in any case, this should check for context cancellation as it might block
There was a problem hiding this comment.
I was hoping the context would be managed by p2p package already as this is just a handler for a message, let me know if it still needs any update.
The trigger sending is done here, to ensure no extra complexity is added in the new go routine, maybe it would make sense to include it in a separate go routine, once we introduce checking for number of providers committed.
| @@ -0,0 +1,19 @@ | |||
| package p2pmsg | |||
There was a problem hiding this comment.
why is this in a separate file instead of just messages.go where all the other ones are?
There was a problem hiding this comment.
Added in the same file, I just wanted to keep it separate as it is a new thing added, but yeah, makes sense to include in same file too
merge main to primev poc
closes https://github.com/shutter-network/shutter-technical-pm/issues/23