# EPF5 Week 1 Updates Still in the discovery phase of the EPF, I'm interested in learning more about RLP and serailization on the execution layer, as well as looking for possible improvements. RLP is a self-describing/schemaless serialization scheme. It needs to be schemaless since parties won't always know what kind of format a received message will have, it could be a transaction or a block. RLP is: - compact - self-describing (so both parties don't need a schema beforehand) - deterministic - simple What kind of messages get RLP encoded on the execution layer? - blocks - transactions - [more examples in reth `net` crate](https://github.com/paradigmxyz/reth/tree/main/crates/net/eth-wire-types/src) [Why RLP? - Stack Exchange](https://ethereum.stackexchange.com/questions/19092/why-was-rlp-chosen-as-the-low-level-protocol-encoding-algorithm) Practically speaking, I can't see why RLP should be self-describing. The format of messages already seems to be described in devp2p and implementations I've read (like reth-net). So why is there an assumption that we don't know what we're receiving in advance? Is there any room for using some schemas or hybrid between schema/schemaless? What low-hanging fruits are there in terms of optimizations? Would they be backwards compatible? How can we find and test this? Crates like `criterion` and `flamegraph` on `alloy-rlp` is probably a good place to start. Is there an intersection between serialization and data availability sampling? Some people to reach out to include: - Georgios Konstantopoulos since he works on reth - Manu Nalepa since he works on the p2p layer at Prysm - The teams at Chainbound and Bloxroute, they would have stats on the overhead of RLP encoding/decoding and some good feedback/leads > RLP is intended to be a highly minimalistic serialization format; its sole purpose is to store nested arrays of bytes. Unlike protobuf, BSON and other existing solutions, RLP does not attempt to define any specific data types such as booleans, floats, doubles or even integers; instead, it simply exists to store structure, in the form of nested arrays, and leaves it up to the protocol to determine the meaning of the arrays. -- Ethereum's design rationale Would be interesting if there was a way to have faster reads through a [skip list](https://en.wikipedia.org/wiki/Skip_list) type traversal. ## Grandine? If I can't identify any worthwhile RLP related project, I might shift my attention to working on improvements to [Grandine](https://github.com/grandinetech/grandine). It looks pretty interesting. Since I'm already learning about serialization I could work on adding support for SSZ StableContainers or other P2P layer stuff. This way I'm still making progress in the same "direction" ### This week's links - https://epf.wiki/#/wiki/EL/RLP - https://epf.wiki/#/wiki/CL/SSZ - https://eth2book.info/capella/part2/building_blocks/ssz/ - https://eips.ethereum.org/EIPS/eip-7688 - https://github.com/ethereum/devp2p/blob/master/caps/eth.md - https://medium.com/@markodayansa/a-comprehensive-guide-to-rlp-encoding-in-ethereum-6bd75c126de0 - https://senacor.blog/introducing-nachricht-a-self-describing-data-interchange-format/ - https://github.com/cognitect/transit-format - https://github.com/real-logic/simple-binary-encoding/wiki/Design-Principles - https://en.wikipedia.org/wiki/Marshalling_(computer_science) - https://github.com/alloy-rs/rlp - https://ethresear.ch/t/blob-serialisation/1705/21 - https://arxiv.org/pdf/2108.05513/1000 - https://github.com/ethereum/devp2p/blob/master/caps/eth.md ### Discussions - https://ethresear.ch/t/discussion-p2p-message-serialization-standard/2781/14 - https://github.com/ethresearch/p2p/issues/15