Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
Implement serialization and deserialization of
- [ ] [bool](https://github.com/ethereum/eth2.0-specs/blob/master/specs/simple-serialize.md#bool)
In order to be able to easily swap RLP with SSZ, we should try to expose the same API interface to the outside world, in particular:
- [`ssz.encode(obj, sedes=None)`](https://github.com/ethereum/pyrlp/blob/master/rlp/codec.py#L20)
- [`ssz.decode(obj, sedes)`](https://github.com/ethereum/pyrlp/blob/master/rlp/codec.py#L209)
The code should be easily and cleanly extendable to support other types.
[py-rlp](https://github.com/ethereum/pyrlp/) may be used as a reference. They split up encoding in two parts: First, they `serialize` arbitrary Python types using [sedes objects](https://github.com/ethereum/pyrlp/tree/master/rlp/sedes) to (nested lists of) bytes, which they `encode` in the second step to the final single byte string. The appropriate sedes type can either be passed explicitly or be inferred from the type of the Python object (note that the latter might not be possible in SSZ due to different encoding of fixed and arbitrary length byte objects). Deserialization works the other way around, but the sedes object must be passed explicitly, as there is no way to infer it.
Sedes objects are also used to define composite types. While not part of this milestone, an [equivalent](https://github.com/ethereum/eth2.0-specs/blob/master/specs/simple-serialize.md#container) exists in SSZ and we'll need them later. It might be a good idea to stick to this design, but it is not necessary if we can come up with something better that also allows for defining composite types.
The code should be well tested. If an architecture similar to the one from `pyrlp` is chosen, the serialization/deserialization should be tested independently from encoding/decoding. There should be tests that check that
- valid inputs are serialized/deserialized/encoded/decoded to the correct outputs
- serialization/deserialization/encoding/decoding of invalid inputs is detected whenever possible and appropriate exceptions are thrown
If there are non-trivial parts of the code that are not directly touched by above tests, there should be separate test cases for those as well.
All tests should pass of course.