fix: remove DecodeVanityData and return vanityData as raw hex

[eomti-wm]

Overview

Prevent potential runtime panics when decoding invalid block vanity data by enhancing error validation and type assertions.

Problem

When decoding a block's vanity data, accessing the resulting slice prior to verifying the decoding status causes an index out-of-range panic if the decoding fails. Additionally, performing type assertions on the decoded interfaces without validation causes interface conversion panics on malformed block data, leading to node instability.

Initial Approach — Superseded by Design Decision below

Solution

Ensure that decoding errors and slice lengths are validated immediately after decoding the bytes. Check the success of all subsequent type assertions before using the values.

Changes

• Add error check and slice length validation right after decoding the vanity data
• Validate type assertion success for all decoded fields to prevent runtime panics

---

Design Decision: Remove DecodeVanityData

While investigating the panic fixes above, a deeper structural issue was identified that led to a change in approach — removing DecodeVanityData entirely rather than applying defensive guards.

1. No protocol-enforced format
VanityData is an unconstrained 32-byte buffer. The protocol imposes no format requirement; validators can write arbitrary bytes. Defensively guarding against decode failures treats a symptom rather than the root cause.

2. Implicit cross-package coupling
DecodeVanityData hardcodes the RLP schema [uint, string, string, string] produced by eth package makeExtraData(). Any change to the encoding side in the eth package would silently break the decoding side in the wbft package with no compile-time signal.

3. No consensus role
The consensus engine never reads or validates VanityData content during block verification. The field serves purely as a 32-byte buffer for node metadata, with no functional impact on consensus.

Revised Changes

• Remove DecodeVanityData
• Return vanityData as a raw hex string in GetWbftExtraInfo, consistent with other byte fields (randaoReveal, seal signatures)

[avinashkamat48]

The guard logic now handles malformed RLP and wrong element types, but the PR does not appear to add a regression test for the panic cases it fixes. A small table test for DecodeVanityData with too-short lists and non-[]byte values in positions 0-3 would lock in the new fallback behavior and prevent a future refactor from reintroducing the same type assertion panic.

[eomti-wm]

During the panic fix investigation, a structural issue was identified in DecodeVanityData that led to removing the function rather than patching it.

The function implicitly depends on the RLP schema defined in eth package makeExtraData(). This creates a hidden coupling between the eth and wbft packages — a change on the encoding side would silently break the decoding side with no compile-time signal.

Furthermore, VanityData has no protocol-enforced format. It is a free 32-byte buffer with no consensus-layer validation, making any format assumption inherently fragile.

Removing DecodeVanityData and returning raw hex eliminates both the cross-package coupling and the entire class of decode-related panics at the source.

[hominlee-wemade]

LGTM

[colinkim]

LGTM

[0xmhha]

LGTM