Discussion thread for https://github.com/ethereum/EIPs/pull/2386
NCC had the following concerns while auditing the EIP-2386 implementation in Nimbus, see https://github.com/ethereum/EIPs/pull/2386#issuecomment-693575270:
The EIP 2386 specification is silent on a number of aspects including:
The maximum length of the
namestring and expectations regarding Unicode normalization.
The type or maximum allowed
The type or maximum expected
versionvalue (though this is currently hardcoded and thus not yet necessary).
Required or expected behavior when extraneous fields are present.
For example, allowing a
namestring of length one gigabyte is not necessary and may surface downstream impacts stemming from unexpected/unnecessary memory allocations.
namestring is a simple identifier, different UTF-8 encodings may arise from malicious intent or simply the broad range of participating devices, operating systems, languages and applications. Characters with accents or other modifiers can have multiple correct Unicode encodings. For example, the Á (a-acute) glyph can be encoded as a single character U+00C1 (the “composed” form) or as two separate characters U+0041 then U+0301 (the “decomposed” form). In some cases, the order of a glyph’s combining elements is significant and in other cases different orders must be considered equivalent. Normalization is the process of standardizing string representation such that if two strings are canonically equivalent and are normalized to the same normal form, their byte representations will be the same. Only then can string comparison and ordering operations be relied upon. Performing this step is best practice to support user expectations related to rendering consistency.
numbertype having a 53-bit floating-point mantissa. Further, if this value is related to an
indexin EIP 2333, then a constraint of 232 is more reasonable.
Specifying similar constraints for
versioncan be done alongside other modifications for completeness, though this is not currently necessary.
Specifying required or expected behavior when extraneous fields are present will improve implementation interoperability.
To summarize, it is recommended to consider a maximum string length for
nameand to indicate that implementations should immediately normalize this value to the NKFC form per section 2.11.2.B.2 of Unicode Technical Report #36. Additionally, consider specifying the type and maximum values for both the
versionvalues, as well as what should happen if extraneous fields are present.