Node Operators
The Mantle LSP system uses multiple Node Operators to run the Ethereum validators controlled by the protocol.
The system uses the off-chain services to coordinate creating and exiting validators (see Off-Chain Systems for more information). This saves a significant amount of money for Node Operators compared to writing the deposit information on-chain.
Node Operator technical requirements
The API which Mantle LSP requires is very simple and really consists of just a few endpoints.
A way to provision new validators
Our initiator service must have a way of requesting validator creation. We need an API to do this with these properties:
There must be an endpoint to return the data that is needed to make a valid deposit on the Ethereum beacon contract.
The creation endpoint must support allowing us to specify separate withdrawal credentials and Fee recipient addresses, as these are different contracts in our system.
It should be possible to request multiple validators in a single call, but this is not a hard requirement.
It should be possible to list previous creation requests that we've made. Not having this ability may mean that in failure scenarios we request new validators when we haven't used old ones.
It should specify an "expiration time" when the validator will become unusable if no deposit is made. If this is not specified, validators must stay valid indefinitely.
The endpoint can be synchronous or asynchronous. We are able to poll for jobs if creating the validators is not immediate.
An example of an API which fits this criteria is Blockdaemon's ["Post stake intent"](https://docs.blockdaemon.com/reference/postethereumstakeintent) endpoint, combined with the ["List stake intent"](https://docs.blockdaemon.com/reference/listcustomerplans) endpoint.
A way to exit current validators
Our allocator service must have a way of exiting validators. We need an API with these properties:
There must be an authenticated endpoint that allows us to specify a public key to be exited. The endpoint must return a signed [Voluntary Exit Message](https://eth2book.info/capella/part3/containers/envelopes/#signedvoluntaryexit) that can be used to exit the validator from the network.
The endpoint should contain the
fork_versionthat the message was created with. If not supplied, we will assume the current mainnet fork version.
An example of an API which fits this criteria is Blockdaemon's [Voluntary exit message](https://docs.blockdaemon.com/reference/generatesignedvoluntaryexit) endpoint
Optional: A way to list previously created validators
To allow for more efficient use of resources and easier recovery from failure, it would be helpful to have an endpoint that allows us to list validators that we have previously created through your API. If provided, we will call this endpoint first to check if there are unused validators we can use without provisioning more. If this is not provided, we will always create new validators.
Note: The endpoint is not required to say whether the public keys are already used or not, as we will check this.
>An example of an API which fits this criteria is Blockdaemon's [List stake intents](https://docs.blockdaemon.com/reference/liststakeintents) endpoint
Authentication
There must be some method of authentication and authorization to ensure that only we are able to create and exit our own validators.
We would prefer a simple method of authentication such as an API token, but we may be able to integrate with other mechanisms if needed.
Last updated