support pre-confirmations with DVT (distributed validator technology) clusters

[iurii-ssv]

Describe the feature

Somewhat related to #541 - we (SSV network) are interested in integrating preconfs with our DVT solution (ideally Bolt preconfirmations via commit-boost),

based on my understanding of how Bolt preconfirmations work I'll outline the "difficulties" DVT encounters if we were to try and do it today,

first a bit of background on DVT (distributed validator technology):

• "distributed validator" is a cluster of nodes (call it DVT) that manage Ethereum validator private key, this private key is split into shares (1 BLS key-share per DVT node) and in order for "distributed validator" to sign anything K out of N (say, 3 out of 4) key-share signatures need to be combined (each key-share signature signing the very same payload)
• DVT nodes are operated by different people who don't/can't trust each other, the only way they can sign something as "Ethereum validator" together as a group (for example preconfirmation request) is if they can independently verify the data they are signing needs to be signed at some moment in time (eg. they sign Ethereum attestation duties together as a group because each DVT operator runs their own local Ethereum node(s) they receive those duty-data from, and since it is an independent data source - DVT nodes can sign on it safely in byzantine-fault tolerant manner)

and now to the "difficulties" I'm hoping we can resolve in order to move forward integrating bolt & commit-boost (+ my thoughts on potential solutions):

• the most natural setup for DVT node operator would be to run its own bolt-sidecar and use that as the "source of truth" (just like DVT node operator currently runs its own Ethereum node, so it can get the info on when/what validator duties to execute)
• lets say we have a DVT cluster of 4 nodes to be concrete, each running its own bolt-sidecar - when preconf request from user comes in, the way bolt currently works, only 1 bolt-sidecar out of these 4 can receive and process this request
• issue (1): bolt-sidecar will ask DVT node to produce validator signature, DVT node in turn needs to coordinate with the rest of DVT cluster asking for partial signatures (so it can recombine it into Ethereum validator signature); now, how do other DVT nodes verify what data they are signing off on ? Malicious DVT node could hand-craft a payload that hurts this Ethereum validator DVT cluster manages - there is no way to tell; This can be addressed if ALL DVT nodes received that very same preconf sign-request from end user so they can all agree on what they are signing; Though I'm not 100% sure if we can sign something harmful/dangerous "blindly" within preconfs domain or not - maybe it's not an issue by itself ... unless it ties into issue (2)
• issue (2): even if issue (1) is solved - for example by requiring every preconf user-request to be sent/delivered to ALL bolt-sidecars in DVT cluster (or get rejected otherwise) - then we still have to make sure that block construction happens with the help of bolt-sidecar instance that is aware of ALL the constraints Ethereum validator managed to sign (there is no guarantee all 4 out of 4 bolt-sidecar instances got successful Ethereum validator preconf-singature from their respective DVT nodes); This can probably be solved by not only sharing preconf sign-request with ALL bolt-sidecar instances in this DVT cluster (and making sure they've acknowledged that) but also additionally making sure ALL bolt-sidecar instances got Ethereum validator signatures for preconf sign-request back from respective DVT nodes before providing a reply to the end user (essentially committing to his preconf request) - this way when the time to produce next block comes any DVT node in the cluster can propose this next block since all bolt-sidecar instance know all the constraints Ethereum validator ended up committing to (the "problem" is malicious DVT operator might propose a block that violates some of those constraints DVT cluster signed)

these solutions essentially sacrifice some preconf requests since not all of these will succeed across all the nodes every time, but keep implementation reasonably simple & let DVT cluster choose whichever node it wants to propose this particular next block (SSV currently round-robins between DVT nodes in the cluster, and also has some mechanisms for another DVT node to step in if the round-robin-chosen-one is failing to produce block in time)

maybe there are better ways to support preconfirmations in DVT setting ... WDYT ? Appreciate any help we can get!

Additional context

No response