Primev poc #629

blockchainluffy · 2025-09-12T08:34:04Z

closes https://github.com/shutter-network/shutter-technical-pm/issues/23

…r to use this config

…tion

rolling-shutter/keyperimpl/primev/abi/ProviderRegistry.abi

jannikluhn · 2025-09-22T22:16:27Z

rolling-shutter/keyperimpl/primev/database/sql/schemas/primev.sql

+    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)


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?

the commitment hash is not sent back when submitting Bid via grpc, anyway we can use commitment_digest and provider_address as primary key.

jannikluhn · 2025-09-22T22:18:35Z

rolling-shutter/p2pmsg/gossip.proto

  optional TraceContext trace = 3;
 }
+
+message Commitment {


can we import this from the primev repo instead of copy and pasting it?

it does not support our message handler interface, that's why I had to create this new message

jannikluhn · 2025-09-23T17:46:40Z

rolling-shutter/keyperimpl/primev/providerregistrysyncer.go

@@ -0,0 +1,286 @@
+package primev


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.

makes sense, lets add it in a separate PR

rolling-shutter/keyperimpl/primev/abi/ProviderRegistry.go

jannikluhn · 2025-09-23T18:03:13Z

rolling-shutter/keyperimpl/primev/database/sql/schemas/primev.sql

+-- the schema. We'll use this to check we're using the right schema.
+
+CREATE TABLE commitment(
+    tx_hashes text[] NOT NULL,


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).

yes, the query is already aggregated as InsertMultipleTransactionsAndUpsertCommitment

rolling-shutter/keyperimpl/primev/handler.go

jannikluhn · 2025-09-23T18:16:46Z

rolling-shutter/keyperimpl/primev/handler.go

+
+	// TODO: before sending the dec trigger, we need to check if majority of providers have generated commitments
+
+	h.decryptionTriggerChannel <- broker.NewEvent(decryptionTrigger)


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.

Also, in any case, this should check for context cancellation as it might block

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.

jannikluhn · 2025-09-23T18:18:39Z

rolling-shutter/p2pmsg/primevcommitment.go

@@ -0,0 +1,19 @@
+package p2pmsg


why is this in a separate file instead of just messages.go where all the other ones are?

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

rolling-shutter/keyperimpl/primev/config.go

…-commit

merge main to primev poc

ylembachar · 2025-10-08T14:17:33Z

rolling-shutter/docs/rolling-shutter.md

 * [rolling-shutter op-bootstrap](rolling-shutter_op-bootstrap.md)	 - Bootstrap validator utility functions for a shuttermint chain
 * [rolling-shutter op-keyper](rolling-shutter_op-keyper.md)	 - Run a Shutter optimism keyper node
 * [rolling-shutter p2pnode](rolling-shutter_p2pnode.md)	 - Run a Shutter p2p bootstrap node
+* [rolling-shutter primevkeyper](rolling-shutter_primevkeyper.md)	 - Run a Shutter keyper for PrimeV POC


(General) I think we should add a dedicated spec document for this new keyper implementation under the existing docs/spec.md that describes the high-level design, key components, and how it differs from other implementations. Ideally we should have that for all implementations, but we can start here as part of this PR.

ylembachar · 2025-10-08T15:04:32Z

rolling-shutter/keyperimpl/primev/database/sql/schemas/primev.sql

+    received_bid_digest text NOT NULL,
+    received_bid_signature text NOT NULL,
+    bidder_node_address text NOT NULL,
+    PRIMARY KEY (commitment_digest, provider_address)


Is the commitment digest unique per commitment to use it as a primary key here?

The commitment digest is the hash of Bid struct, which will be signed by any provider, so combination of commitment digest and provider address will always be unique

ylembachar · 2025-10-08T15:36:37Z

rolling-shutter/keyperimpl/primev/database/sql/queries/primev.sql

+        $11
+    FROM inserted_transactions
+    ON CONFLICT (provider_address, commitment_digest)
+    DO UPDATE SET


We're assuming here that we are receiving the same commitment with a different set of transactions? Is that possible? Given that you are using the digest and bidder address as a primary key, shouldn't these fields be immutable?

This is using provider address, which is builder's address, which can be different for same commitment

ylembachar · 2025-10-08T15:51:02Z

rolling-shutter/keyperimpl/primev/config.go

+
+type PrimevConfig struct {
+	SyncStartBlockNumber     uint64         `shconfig:",required"`
+	SyncMonitorCheckInterval uint64         `shconfig:",required"`


I think SyncStartBlockNumber and SyncMonitorCheckInterval can be moved to the general configuration as not specific to PRIMEV.

This would be a change affecting all keyper implementations, I suggest we do it in a separate PR

ylembachar · 2025-10-08T16:14:45Z

rolling-shutter/keyperimpl/primev/config.go

+	return nil
+}
+
+func (c *PrimevConfig) SetDefaultValues() error { //nolint:unparam


SetDefaultValues() and SetExampleValues() both set empty or zero values for required configuration fields. I think it would be better to either provide meaningful defaults/example values or remove them altogether if not applicable.

We cannot add exact values to these, as they depend on which chain it is running on, testnet/mainnet.
It is added here, just so that an example config file is generated, which would need to be modified to add exact values, like in other keyper implementations

blockchainluffy added 17 commits July 24, 2025 19:07

feat: add primev keyper definition and commitment gossip message

cf0fbf1

feat: add basic database queries and schema

0941870

feat: add provider registry event syncer

42865d9

fix: sql definition issue

535106e

update commitment message to include identities

ccae033

update config to include primev chain config and update providerSynce…

f16acd2

…r to use this config

fix: CI to build docker image

e099c72

fix CI for build

5909157

fix primev keyper database mismatch

868cb00

fix: getting block header for primev chain

4b56c49

primev: identity calculation to use bidder node address

fc0e18c

add logs for commitment message

dfc6fbd

update message middleware

7130772

update bidder node address verification

bdfb398

update commitment handler to check msg type

08baf1d

update commitment message handling to include correct identity genera…

b00a818

…tion

update commitment table to include bid related fields

9178d2f

blockchainluffy self-assigned this Sep 12, 2025

blockchainluffy requested review from jannikluhn, ulope and ylembachar September 12, 2025 08:34

primev: use random generated identity prefix

4212a0f

jannikluhn reviewed Sep 23, 2025

View reviewed changes

blockchainluffy added 7 commits September 24, 2025 14:19

primev: use provider registry contract binding as dependancy from mev…

6436aad

…-commit

primev: update schema primary and foreign keys and queries

47f2300

primev: include commitment message in the existing message file

5d6d4ae

primev: update config to not include http enabled flags

b8e1b10

primev: update commitment handler to generate dec trigger at the end

a7c0d0c

Merge branch 'main' into primev-poc

1947f4e

merge main to primev poc

primev: resolve build after merging main

f0a5508

blockchainluffy requested a review from jannikluhn September 25, 2025 09:08

fix: rs-generate ci

52f62fc

ylembachar reviewed Oct 8, 2025

View reviewed changes

update example config values

a32b372


		// TODO: before sending the dec trigger, we need to check if majority of providers have generated commitments

		h.decryptionTriggerChannel <- broker.NewEvent(decryptionTrigger)

Primev poc #629

Are you sure you want to change the base?

Primev poc #629

Uh oh!

Conversation

blockchainluffy commented Sep 12, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants