Submitted by d3e4
https://github.com/code-423n4/2023-03-canto-identity/blob/077372297fc419ea7688ab62cc3fd4e8f4e24e66/canto-namespace-protocol/src/Tray.sol#L163
https://github.com/code-423n4/2023-03-canto-identity/blob/077372297fc419ea7688ab62cc3fd4e8f4e24e66/canto-namespace-protocol/src/Tray.sol#L264-L268
https://github.com/code-423n4/2023-03-canto-identity/blob/077372297fc419ea7688ab62cc3fd4e8f4e24e66/canto-namespace-protocol/src/Utils.sol#L136-L174
Only 256 Zalgo distortions are possible, which is a miniscule fraction of the actual combinations possible.
A Zalgo tile is defined by a letter and a modification consisting of a combination of characters above, over and below the letter. The modification consists of a selection of 1 up to 7 characters from a set of 46 characters above the letter, 0 or 1 from 5 over the letter, and 1 to 7 from 47 below the letter. Thus there is a total of $(46^1 + 46^2 + ... + 46^7)*(5^0 + 5^1)*(47^1 + 47^2 + ... + 47^7) = 1.38e24$ different Zalgo modifications possible per letter.
However, the distortions are uniquely determined by characterModifier which is a uint8. So only 256 different distortions per letter are possible.
When a tray is bought, _drawing sets the tile,
and, if luck would have it that it is a Zalgo tile, characterModifier is set to a pseudo-random uint8, i.e. in the range 0..255.
This characterModifier uniquely determines the distortion in characterToUnicodeBytes at L136-L174:
Note that there is also a similar bottleneck issue with iteratePRNG, which is reported as a separate issue.
Let characterModifier have a range of at least 0..1.38e24. Since it therefore cannot be a uint8, simply let it be a uint256 (or at least a uint88).
OpenCoreCH (Canto Identity) acknowledged and commented:
d3e4 (warden) commented:
