---
# System prepended metadata

title: snarkOS network TODOs
tags: [snarkOS, aleo]

---

###### tags: `snarkOS`, `aleo`

# snarkOS network TODOs

priority items:
- enforce a handshake time limit
- test block-related messages
- transaction-related messages
- transactions are not currently being propagated

TODO later, ordered by applicability/priority:
- inbound messages should be deduplicated based on some cache of hashes of recent messages
- there should be some way for broadcasts to not be sent to the same peers multiple times
- restrict incoming message sizes based on the type of the payload
- the version in `Version` probably doesn't need to be a `u64`
- test block propagation scenarios + duplication
- limit `Block` rebroadcasting or dedup incoming broadcasts
- introduce per-connection/`Channel` stats with sent+received count+bytes; they could extend `PeerInfo`
- `WriteHalf` should ideally not be locked

NICE TO HAVE, in no particular order:
- ditching peers with a high RTT
- rename instances of "thread" to "task" where appropriate (some stragglers are still left)
- bumping stat counters doesn't require `Ordering::SeqCst`; `Relaxed` suffices for such purposes
- some methods perform a `clone()` where a regular reference could do
- shouldn't `BlockHeight` be `u64` (it's `u32`) for future-proofing? depends on mining speed
- the `Version` message type could have a better name, e.g. `Metadata` or `NodeInfo` that indicates there's more than just the version there
- it may not be necessary to have both the `Block` and `BlockSync` messages; this depends on whether there's some other way of determining whether an inbound block is to be propagated
- the buffer for reading messages could be used more efficiently
- improve the readability of peer disconnect in `inbound`
- block sync batching and expose state to `rpc`
- Seperate consensus and network storage 
