rawNewBlockPacket / rawBlock¶
NEW-ETC — no upstream or core-geth original.
| File | protocol_pow.go |
| Symbol | rawNewBlockPacket |
| Ref | etc/v1.17.4-full-node |
NEW-ETC, deliberately not a revival — there is no purge source for it. Upstream never bounded the NewBlockMsg decode: the only hardening it ever applied to that path was #19573 (cdfe9a3a2, 2019), which added Header.SanityCheck and the packet's tdlen bound, bounds only unbounded scalar and byte fields, runs AFTER the full decode, and is described by its own author as "annoyance"-level protection against log spam. It never bounded the number of transactions or uncles, and types.Block.DecodeRLP has no bounds at all. Upstream then deleted the message with the merge rather than solving it, so there is nothing to revive. What IS copied is the pattern upstream still uses for the one unsolicited message it kept, TransactionsMsg: decode into rlp.RawList (which only counts items), reject on the count, and let the consumer materialize later via Items(). rawBlock mirrors the block encoding [header, txs, uncles] with the two lists held as rlp.RawList in the manner of the BlockBody type #33835 introduced, which is why the body can also be verified against the header — through the shared hashBodyParts helper — before anything is materialized. Withdrawals are deliberately absent from rawBlock, so a PoW block carrying them is now rejected at decode as having too many elements rather than decoded and rejected later. The item caps replace the tracker.Fulfil check that a request-response message gets; a broadcast has no request id to be matched against. maxBlockUncles = 2 is the ethash/etchash consensus limit, and mirrors the constant of the same name in core-geth. maxBlockTransactions = 5000 is a flat bound, NOT derived from the announced gas limit: doing that arithmetic on this message would be self-defeating, since the gas limit is a header field the sender controls. It equals upstream's maxTransactionAnnouncements, and corresponds to a ~105M gas limit at the 21000 gas floor, more than an order of magnitude above ETC's current one. core-geth solves the same problem in checkNewBlockItems (1570234d2) with a hand-rolled pre-decode walk and a per-tx-type footprint model. That weight is not needed here: it exists because core-geth has no rlp.RawList to express "count but do not materialize".
// rawNewBlockPacket is the receiving side's view of NewBlockMsg, holding the
// block body encoded so that its item counts can be checked, and the body
// verified against the header, before any of it is materialized. A broadcast
// carries no request id, so there is nothing to match it against: the counts
// are all that stands between the message size limit and the heap.
type rawNewBlockPacket struct {
Block rawBlock
TD *big.Int
}