Use `Bytes32` for `error_message`

`ErrorMessage.error_message` is a leftover from an older version of SSZ
that was able to encode unbounded lists. This is no longer the case -
all collection types now have a fixed upper bound on length.

In general, the `error_message`, just like the `graffitti` field, should
not be interpreted in any particular way except for debugging and vanity
- as such, using the same type, a `Bytes32`, seems reasonable.

An alternative would be `List[byte, 256]` which maybe could be
"reasonably backwards compatible" with whatever clients are are doing
now - depending on how they are dealing with this field type that no
longer exists in the SSZ spec :) It would however be the only place
where `List[uintN, N]` is used in the current spec.

As an exercise, this could be considered a security issue since it's
essentially unbounded and undefined behaviour.
This commit is contained in:
Jacek Sieka 2020-05-21 15:33:47 +02:00
parent 7770accf96
commit 56309342c0
No known key found for this signature in database
GPG Key ID: A1B09461ABB656B8
1 changed files with 2 additions and 2 deletions

View File

@ -391,11 +391,11 @@ The `ErrorMessage` schema is:
```
(
error_message: String
error_message: Bytes32
)
```
*Note*: The String type is encoded as UTF-8 bytes without NULL terminator when SSZ-encoded. As the `ErrorMessage` is not an SSZ-container, only the UTF-8 bytes will be sent when SSZ-encoded.
*Note*: By convention, the `error_message` is a sequence of bytes that can be interpreted as a UTF-8 string up to 32 bytes - a 0 byte shortens the string in this interpretation. Clients MUST treat as valid any bytes.
### Encoding strategies