-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Attestation API updates for Electra #6557
Conversation
Could use updates to https://github.com/status-im/nimbus-eth2/blob/unstable/ncli/resttest-rules.json Not sure why 1115e4d was premature? |
The reason why it is premature is because these new endpoint versions are not yet implemented in ncli and without those missing developments, the tests will fail if we add the resttest-rules.json. |
I'm not sure I understand, probably I'm missing something. https://github.com/status-im/nimbus-eth2/blob/unstable/ncli/resttest.nim doesn't really implement any endpoint versions to begin with. It just uses the input from Lines 395 to 486 in e3fcd8b
It does not use, for example, |
Apologies, confused with different calls on validator interfaces.
|
The existing getPoolAttestations semantics, and the apparently intended semantics of getPoolAttestationsV2, treat each parameter as an optional filter:
The existing nimbus-eth2/beacon_chain/rpc/rest_beacon_api.nim Lines 1277 to 1303 in bf4abf8
However, this does not address
which, indeed. The documentation is clear that it's supposed to be exactly one consensus fork, and this is where V2 is trickier:
is not in the non-V2 getPoolAttestations, so the question doesn't come up.
The most spec-correct way I can see is, when
invariant than to return a few more attestations for a basically debugging endpoint every few months. |
This came up in ethereum/beacon-APIs#458 and that's basically the conclusion they came to also |
writer.endRecord() | ||
stream.getOutput(seq[byte]) | ||
except IOError: | ||
default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
default
is already atemplate
defined by the Nim standard library, so just as a point of naming, unless there's a quite compelling reason to name a symbol literallydefault
(or one is writing effectively an type-specialized implementation of thattemplate
) it's less confusing to use a different name; and- more significantly, it's unclear why at all to define
var default: seq[byte]
in general and then only use it in theexcept
part of thetry
/except
. One can just directly usedefault(seq[byte])
here and only incur the runtime cost on theexcept
case.
I do see that various other things in eth2_rest_serialization
adopt this pattern, but I don't see any reason to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one.
If I'm not mistaken "default" is a reserved keyword in several languages. Given that the whole file is using the same nomenclature, I didn't pay much attention to it.
The second point, I would say that the runtime cost is not a problem given that the whole exception mechanism is already a performance hit, but exception handling should be simple and mem allocation/deallocation should never fail.
Regarding your suggestion, template code will be injected/replace in place, however, what are the impacts of allocating a sequence on except scope? any leak possbility or anything that we might be missing nim-wise?
Neverthless, I'm adressing this on #6580
still doesn't have to be done in this PR though |
#6582 should fill in the rest of attester slashing infrastructure |
New GET and POST v2 versions for block and pool attestations according to spec ethereum/beacon-APIs/pull/448 .
New Attester slashing endpoints still need to be implemented, given that they still lack support on code base.pool attester slashings api changes #6585