[Feature discussion] Adding IsSlashable api

[alonmuroch]

Hi attestant team!

Overview
I wanted to start a conversation around adding an isSlashable api point which receives as input the same params as the signing api but instead just returns true/ false for if the attestation/ proposal is slashable.

Why?
Specifically for SSV.Network we use a remote signer that's connected to the node, during the consensus phase one of the validations steps is to check a proposed attestation/ proposal are not slashable before the other peers decided on it.
It would be helpful to have that supported by dirk, after which, we can build an adapter for it to connect to the ssv node.

How?
The api end point should look like the signing endpoint, difference is the result it returns.
Ideally this can also be made into an EIP to extend on 3030.

Would love your thoughts/ comments

[mcdee]

There is a timing problem with any system that checks if something is slashable is that it is a point-in-time piece of information. So there is nothing to stop node A from checking if something is slashable (it isn't), node B then sending a signing request (that makes node A's information invalid) and then node A sending a signing request (which is rejected).

Another thing to point out with Dirk is that it does not allow repeat signing. So if nodes A and B both sent the same data as part of a signing request then even though it isn't technically slashable (as they both have the same data and hence will result in a duplicate signature rather than two different signatures). Not sure if that would cause problems with your proposed system or not.

A final concern would be that Dirk hides a lot of information in the name of security, so for example if user A attempts to sign something with a key with which they are not allowed to sign Dirk returns 'Denied'. If user B attempts to sign something that is slashable Dirk returns 'Denied'. If user C attempts to sign something with a key unknown to Dirk it returns 'Denied'. All of this is to avoid leaking information about which keys Dirk owns and who has access to them. Any slashing check API would need to provide a similar level of protection, which suggests that the endpoint may be more "isSignable" than "isSlashable".

[alonmuroch]

The timing aspect is interesting, I'm not sure it actually affects an application like SSV/ DVT as actual signing happens after consensus which is dependent on the proposed duty data is not slashable so timing might not play a security concern here.
Would you say the timing concern here is enough to not open up an isSlashable endpoint? or is it something that is ok to do as long as any use of Dirk will take that into consideration?

The last 2 points might be less of a concern IMO.