Add IL related endpoints #1
Conversation
types/focil/inclusion_list.yaml
Outdated
| @@ -0,0 +1,30 @@ | |||
| Focil: | |||
| InclusionLists: | |||
There was a problem hiding this comment.
why does this type need to be defined here? better to limit the types here to CL spec containers
| - Validator | ||
| summary: "Get inclusion list committee duties" | ||
| operationId: "getInclusionListCommitteeDuties" | ||
| description: "Requests the beacon node to provide a set of inclusion list committee duties for a particular epoch." |
There was a problem hiding this comment.
might wanna add a similar note as in getAttesterDuties in regard to reorgs
apis/validator/inclusion_lists.yaml
Outdated
| - Validator | ||
| operationId: "produceInclusionLists" | ||
| summary: "Produce inclusion lists" | ||
| description: Requests that the beacon node produce multiple InclusionList. |
There was a problem hiding this comment.
If we wanna create a individual IL for each validator should probably change the description here
apis/validator/inclusion_lists.yaml
Outdated
| - name: validator_indices | ||
| in: query | ||
| description: "Array of validator indices for which inclusion lists should be created." | ||
| required: true |
There was a problem hiding this comment.
do we really need to pass validator indices here? the probability that your node has 2 IL duties for the same slot is insanely low even if you have hundreds of keys on a single node.
I think we can just produce a single IL here similar to produceAttestationData and then in the rare case we have 2 validators we can either skip one of them when submitting the signed IL or we just sign the same IL twice, while this does not add much value I think this is still fine.
I think the main worry here is that this adds complexity to the EL that would have to produce multiple non-intersecting ILs for this to make a meaningful difference.
There was a problem hiding this comment.
based on how engine_getInclusionListV1 is defined right now we can only get a single IL per parentHash
There was a problem hiding this comment.
its weird to anyway get more inclusion lists on same slot doesn't matter if two or more vals have the IL duty on same slit
There was a problem hiding this comment.
I think the point of multiple inclusion lists is to beat someone using IL as DA, so this could just be fine and doesn't depend on num of val duties attached.
apis/validator/inclusion_lists.yaml
Outdated
| - ValidatorRequiredApi | ||
| - Validator | ||
| operationId: "publishInclusionLists" | ||
| summary: "Publish multiple inclusion lists" |
There was a problem hiding this comment.
would there be any drawbacks if we just publish a single IL assuming they have the same transactions? there is no penalty for missing IL duties so we could just deduplicate them on the validator client side (maybe somehting to discuss in FOCIL call)
There was a problem hiding this comment.
one can/should pubhish multiple ILs to not have them used as a DA.
There was a problem hiding this comment.
one can/should pubhish multiple ILs to not have them used as a DA.
could you please elaborate on that a bit, how would someone else be able to use my IL as DA if I don't publish mine? there is a gossip rule to check the signature so it would not be propagated by the network
In general since in FOCIL the ILs are just transient / part of local view of the node only I don't see how someone would use them for DA since you don't have any availability guarantees as far as I understand
beacon-node-oapi.yaml
Outdated
There was a problem hiding this comment.
do we want an api to retrieve ILs from op pool, similar to getPoolAttestations?
There was a problem hiding this comment.
do we want an api to retrieve ILs from op pool, similar to
getPoolAttestations?
Nice to have maybe for debugging purpose. Not required for ILC duty. Can re-visit it later
Co-authored-by: Nico Flaig <[email protected]>
No description provided.