Implement bls_to_execution_changes beacon endpoint #11845
Conversation
potuz
changed the title
| req *http.Request, | ||
| ) (apimiddleware.RunDefault, apimiddleware.ErrorJson) { | ||
| if _, ok := endpoint.PostRequest.(*SubmitBLSToExecutionChangesRequest); !ok { | ||
| return true, nil |
There was a problem hiding this comment.
Should this return true, nil if !ok?
There was a problem hiding this comment.
Every other wrapper does this so I'll follow this pattern so I didn't want to change it, pinging @rkapka that may have had a reason. This can never happen anyway in runtime.
| } | ||
| bs.BLSChangesPool.InsertBLSToExecChange(alphaChange) | ||
| if st.Version() >= version.Capella { | ||
| if err := bs.Broadcaster.Broadcast(ctx, alphaChange); err != nil { |
There was a problem hiding this comment.
This broadcast feels a bit silent. I wonder if we can log something at the end that we successfully inserted indices x, y, z into the pool and broadcast them, but failed indices a, b, c and neither inserted nor broadcast
There was a problem hiding this comment.
For our users we will provide a verbose version in prysmctl that will log everything detailed. A curl to the endpoint will only log on errors. I feel it's a good compromise cause otherwise the UX with prysmctl will log everything twice
| err, | ||
| ) | ||
| } | ||
| return nil, status.Errorf(codes.InvalidArgument, "One or more BLSToExecutionChange failed validation") |
There was a problem hiding this comment.
To be most informative, why don't we tell the user that all other indices not in the failure list succeeded and were included in the pool + broadcast to the network? People might think a failure could mean none of them succeeded. Can we included the indices in the error?
There was a problem hiding this comment.
The nicest UX would be to tell the user the validator indices for which the failures correspond to
There was a problem hiding this comment.
Dito above, James' PR is the user facing end. This implements the backend only
This PR implements the main logic for the REST endpoint https://ethereum.github.io/beacon-APIs/?urls.primaryName=dev#/Beacon/submitPoolBLSToExecutionChange.
It takes an array of signed
BLS_TO_EXECUTION_CHANGEmessages and validates their signature. Valid messages are then added to the local pool.If the headstate is prior to the Capella fork, then the message is validated against the capella fork version, this allows users to fill their pool before the Capella fork happens.
If in addition the headstate is of version Capella, the beacon will broadcast these messages.