Open Validator Service Broker: Empowering Client Diversity

[sambacha]

@Izzy

for certain types of infra setups (i.e. cloud-native ones managed via kubernetes)

This is a great point, the specification allows Terraform as well as Kubernetes, here is an example using terraform and here is a pure Go example for enabling Service Brokers for Redis.

The specification doesn’t formalize specific requirements for provisioning a service (e.g. you must use this flavor of linux distro, with these packages installed, etc). Its focused primarily on:

• Provisioning new service instances
  A service instance is a provisioned instance of a service and plan as described in the service broker’s catalog.
• Connecting and disconnecting applications and containers from those service instances
• Deprovisioning service instances
  This action simply deletes all the resources created upon the initial provisioning of the service instance.

@Izzy

broker has set up their platform actually matches how they say they have set it up?

This question is more of an implementation detail. We assume that they are good-faith operators otherwise they would face repercussions.

@Izzy

For stETH to be fungible, it should explicitly not be linked to a specific validator or set of validators. This may make sense in protocols where users mint staking tokens that are directly attributable to a specific operator or set of validators, but this is not something Lido wishes to do. I guess you can pool “all Lido validators” together, but on the other hand you don’t want to do things like make the EL & CL nodes that are used for validating also public RPCs, it leads to a DDoS attack vector.

stETH is already linked de jure to all Lido validators. Node operators are i.e. implicitly subsidizing its peg.

The RPC Methods would not be accessible on nodes that are actually doing attestation/signing/etc. A sidecar node / failover node would be a possible candidate for such activity. Additionally, an internal messaging queue could be leveraged for facilitating access in a robust manner.

@Izzy

I think this is a really strong idea but there is a tension here with the kind of specific infrastructure it lends itself to.

At Manifold Finance we only use bare metal for production/staging environments. This would be compatible as well with other Cloud Service Provider offerings. In fact here is a matrix assessment of current cloud provider offerings where we can tell you exactly which SKU’s would be ordered to provide a reliable Eth2 instance.

At worst, we see this as a self reporting mechanism to help facilitate inter-node operator capacity and availability. Being able to report which specific versions of a client you are operating can be crucially important in circumstances related to block propagation and construction. Having this information so that we can enrich network topology construction will be important for establishing protections against correlated time-level attacks, reducing fault correlations, clock sync issues, etc.

Lots of great questions, will clarify some of the points of ambiguity and clarify some potential metrics and KPI’s that this should be driven by and should be used to benchmark against!

Much appreciated,

Sam