Add versioned attestation and attester slashing events

[nflaig]

Alternative solution to https://github.com/ethereum/beacon-APIs/pull/459 which adds versioned attestation and attester slashing events.

As highlighted in the other PR, bumping the whole events api to v2 introduces a lot of implementation complexity while adding two new events should be trivial.

The un-versioned events will only support phase0 types and hence consumers need to use to versioned events post-electra. From a client implementation perspective, the best solution is likely to stop emitting un-versioned events altogether on fork transition instead of converting electra to phase0 objects.

Part of https://github.com/ethereum/beacon-APIs/issues/445

[dapplion]

What if consumers first decode a type

{
  data: {
    slot: u64
  }
}

and use the slot number to decode the attestation. Since it's a stream event 2 epochs after the fork all attestations will be electra. A bit hacky but the *_versioned solution doesn't feel too clean either. Will we keep adding *_versioned topics as data structures change?

[nflaig]

What if consumers first decode a type

That would work as well and simplifies things a little bit when emitting events, I am open to that solution but from previous discussion there was preference to use a versioned container.

Will we keep adding *_versioned topics as data structures change?

Depends on if we change the types I listed here https://github.com/ethereum/beacon-APIs/pull/459#issuecomment-2232984112, that's why another solution would be to version all those and bumping the apis to v2.

The un-versioned events are deprecated now and could be removed in the future so at least some cleanup in that regard, although the event name would not be as clean.

[rkapka]

I think I am slightly leaning towards leaving this work to the consumer.

[mcdee]

Having a v2 of the events stream with every event versioned looks like a cleaner long-term solution.

[rolfyone]

Having a v2 of the events stream with every event versioned looks like a cleaner long-term solution.

If we do go down the v2 route, can we make sure we have version on every object? otherwise this is just going to repeat itself next time...

[nflaig]

Closing this as preference seems to be to either go with a v2 or not do anything at all and extract slot to determine fork type. We have implemented the later on Lodestar for now as it does not require any spec change.

Let's continue discussion regarding v2 in https://github.com/ethereum/beacon-APIs/pull/459