twoeths

root cause is #4002

Some first analysis: - We need to benchmark `serializeExecutionPayload()` considering `MAX_BYTES_PER_TRANSACTION` = 1073741824 and `MAX_TRANSACTIONS_PER_PAYLOAD` = 1048576 - Also `JSON.stringify()` before we call execution engine new payload api - Need...

> @tuyennhv Could you prove first that performance is degraded for those servers? Also keep in mind that for `ctvpss` the execution client is in a different data center so...

> @tuyennhv You can run a snooper parithoshj/json_rpc_snoop:v1.0.0-x86 between the EL and CL to log the traffic and their timings. Run the container with command @dapplion the snoop tool works...

> The real question is: Why did the node get so busy in the first place? one reason is the high memory usage at that time causing long epoch transition

some great gossipsub metrics with v1.1.0: - 98% of peers are mesh peers - better peer score - number of subnets with mesh peers are consistently 64

some down side due to too many mesh peers - We drop more attestation gossip messages - gossipsub has to send / receive more messages ==> this is the main...

This is rare, the sync finished even before the network is started

with https://github.com/ChainSafe/persistent-merkle-tree/pull/52, we can get deserialized number if it contains less than 32 bits (right now we have to convert `h0..h7` to Uint8Array and from Uint8Array back to number) ```ts...

> Efficient in terms of CPU time, memory or what specifically? in CPU time, but I guess could be better in terms of memory too since there is no created...