ssvlabs/ssv-network

registerValidator- ownerAddress and cluster data

Closed this issue · 1 comments

There are two questions we wish to clarify
a. ownerAddress
image

The SSV contract uses the msg.sender to handle the ownerAddress and pay for the SSV. The cluster balance to which the validator belongs is used to pay for the ssv required for the validator to run.
User -> BatchSSV (Contract a) -> deposit + ssv registerValidator (Contract b)
At this point, contract b receives the address of contract a (msg.sender)

Requirement: The user calls contract a, and contract a calls Contract b. Only the code of Contract a can be modified, and the msg.sender of Contract b needs to be the user address. However, tx.origin cannot be resolved, contract b uses msg.sender.
delegatecall can be used, and delegatecall will execute the code of the target contract in the context of the current contract, including the message sender (user address) and message data. In this way, contract B will think that the caller is the user address when it is executed.

The delegatecall will affect the contract upgrade and has certain risks.

To modify the msg.sender of the RegisterValidator method, Contract A can use delegatecall to execute Contract B in the context of Contract A with the user address as the message sender. However, this has certain risks and may affect contract upgrade. Do you have any suggestions for our team?

b. registerValidator()- Cluster parameter
If we need to batch process 10 registerValidators transactions. At this time, the incoming cluster is a copy of the data scanned by the cluster-scanner, but each registerValidator will change the data of the cluster.
We are concerned that it may not work, considering that we want to implement this with a contract, and contracts cannot subscribe to events.
Off-chain implementations cannot guarantee the atomicity of this batch of executions. Either all of the operations in the transaction will be completed successfully, or none of them will be completed at all for an atomic transaction

is it possible to find an alternative solution that would work within the limitations of a contract?

image

hi @derricktan23 Thanks for posting your issue. Before all, sorry for the late reply. Please have a look at the README file to learn about the new architecture of the contracts we released for Jato-v2.

Use the correct msg.sender
You pointed right to the possible solutions and risks. Would it be possible for you to manage the original msg.sender and pass it as a parameter to registerValidator function? The current implementation of registerValidator does not support it, but we could think about providing a secure way of handling it for this type of cases.

registerValidator()- Cluster parameter
In this case, an efficient batch registration of validators is the way to go. We are working on this too.

Thanks!