Unexpected Behaviour Hex-Encoding Negative `BigInt`s

I would like to report some behaviour that seems unexpected to me.

What is the current behavior?

Encoding a negative BigInt value will return the hex of its absolute value. So -42 will be encoded as 0x2a.

What is the expected behavior?

Looking into the code, it looks like num::BigInt::to_bytes_be returns the big-endian bytes for its absolute value. This causes typeConversions.bigIntToHex to encode absolute values of its BigInt parameter.

This is a bit unexpected to me, and I would have expected either:

1. To sign prefix the hex value (so 42 becomes 0x2a and -42 becomes -0x2a). This is more inline with how num::BigInt would hex-format values.
2. To hex encode the value in 2's compliment notation. (so 42 becomes 0x2a and -42 becomes 0xd6). In looking at the code, this encoding implementation requires no leading 0s in the hex representation. This would mean that with 2's compliment, there would be multiple numbers with the same hex representation (for example 255 would be 0xff and -1 would also be 0xff).
3. Disallow hex-encoding negative big integers. From the documentation for the typeConversions.bigIntToHex implementation in the HostExports, it mentions go-ethereum encoding rules as the reference. By those rules, hex marshalling for negative numbers is explicitly prohibited, so following that here would also make sense:

   Negative integers are not supported at this time. Attempting to marshal them will return an error. Values larger than 256bits are rejected by Unmarshal but will be marshaled without error.

Unfortunately, all of these suggestions would be breaking changes (which I imagine should be avoided for subgraph host function implementations).

Comienza leyendo la implementación de typeConversions.bigIntToHex en HostExports y el comportamiento de num::BigInt::to_bytes_be. Compara la referencia de codificación documentada de go-ethereum con los tres comportamientos propuestos para valores negativos y, a continuación, determina qué política es aceptable sin romper la compatibilidad de las funciones del host. Se considera terminado cuando el comportamiento y las implicaciones de compatibilidad estén decididos y cubiertos por las pruebas o la documentación pertinentes.