TODO list

[mhchia]

Short term

poc code

• Goal: Support the scenario:
  • Nodes join the overlay
    • with bootnodes
    • without bootnodes. Nodes are connected through predefined topology
  • Join shards
  • Jump(leave and join) to other shards
  • Receive relayed collations
  • Broadcast collations
  • Synchronize old collations with peers
  • Synchronize ShardPreferenceTable with peers
    • It is useful when a node just joined the network, without knowledge of ShardPreferenceTable
• TODO
  • Code review
    • Ensure code is written correctly
      • stream is closed correctly?
      • connection is maintained correctly?
      • Golang knowledge
  • Add direct API for peers back
    • RequestCollation
    • RequestShardPreferenceTable
      • First define message interface
      • request options
        • Request the whole table(map[peerID -> shardPreferenceBits])
        • Ask the table only for nodes listening specific shard?
  • CLI(can be finished soon)
    • list peers
      • of pubsub topic
      • connection of host
    • join shard
      • subscribe shard
      • connect to nodes in the shard
      • broadcast shard preference
    • leave shard
      • unsubscribe shard
      • broadcast shard preference
  • Handshake protocol
    • To replace AddPeer
    • What should be exchanged when handshaking?
      • Check for anything?
      • Exchange shard preference table?
    • Refactor
      • Remove unnecessary code
      • Design and restructure code
  • Misc
    • Save blocks
      • In memory or cache(temporary)
      • In db
        • which db to use?
    • DHT persistance?
      • Should DHT records saved in filesystem when a node is down?
  • Log
    • All events should be logged
      • AddPeer
      • Broadcastcollation
      • Subscribe/Unsubscribe shards
    • Design: log emit(log type, log signatures)
    • Use log correctly
      • INFO, DEBUG, ...
  • Communication with Python
    • Bindings or RPC
      • First list all possibilities
    • Design the interface between Python and Go
      • Should be abstract enough for easily replaceable in Python side
  • Survey Validator in gossipsub
    • Validator
    • Need RPC/IPC between validator function in Go and Python side
      • RPC/IPC is used when go side and python side are individual processes(so no bindings in this case)
      • or other easier communication betwee go and python code(still need bindings)
  • Peer management
    • How to maintain the peers of the overlay network
      • Through ConnManager
        • [!] Cannot find the reference to control it in pubsub, should ask why later
      • Determine the max size of the peer list
      • Does the peers meaning the ones with connections or just knowing the address

Test

• Deployment
  • Current script
    • A lot more messy
  • Survey both local and cross-servers deployment
    • Use containers like docker?
    • Survey ansible for small scale, and kubernates for larger scale
      • example: ipfs with kubernates
    • Survey terraform for managing EC2 instances
• Spec
  • Network topology
    • Description for nodes(latency, connections, actor(role), ...)
    • Spinning up nodes at beginning or gradually?
    • Test should be deterministic(can be reproduced)
    • Survey if YANG helps?
  • Failure conditions
• Simulation(not necessary to be done)
  • Simulate all nodes in one simulator process? or simulate with one node with mocked network
  • Mock network(Implement a self-defined Swarm or use the existing fake network if there is)
• Formal model
  • TLA+
    • Nice tutorial
    • Issue proposing formal model: Swarm
      • Implement formal model for Swarm's syncing protocol with TLA+ ethersphere/swarm#535

Tracing

• Survey tracing tools
  • OpenTracing, opensensus
    • e.g. survey by ipfs
  • Other key words
    • Jaeger, Zipkin
  • Grafana
    • e.g. http://stats.swarm-gateways.net/?orgId=1
• Log aggregation
  • for easier bug reproduction and visualization
• Visualization
  • Gantt chart: through opentracing?
  • Draw events through nodes

Longer term

• Other peer discovery approach
  • Rendezvous protocol(might have security issue. Need to survey more)
    • see Other peer discovery mechanism #47

fjl: If you want to use rendezvous system, there are many options: do I run my own rendezvous server just for my project? if no, can I use a public one? who runs that?
Are servers connected to each other? How can they decide if a registration is spam?
How does the client choose which rendezvous server it uses? If other rendezvous servers are registered, how does it know if they are bad? What's the incentive to run a rendezvous server for normal users?

• Attack prevention
  • When fetch something from gossipsub, we should be able to know the sender and the relayer of the message. If the message is malicious, we should ban the both of them.
  • DoS/DDoS
    • Seems hard to solve
• Survey QUIC
  • Might be useful for a quicker transport layer
• Message interface for testnet across implementation
  • Use protobuf?

[hwwhww]

@mhchia I updated the issue content via copypasting your notes!

[mhchia]

Thanks a lot!

[mhchia]

Follow-ups of #54

TODO

• Change getCollation in request.go to make use of EventNotifier, requesting real data from Python side
• Refactor and clean up
  • removeSimplify AddPeer
    • Seems failing when directly replacing AddPeer with connect
• Update gx versions of the dependencies, especially go-log, go-libp2p-kad-dht, go-libp2p-pubsub
• Add bunch of RPCs for peer queries and synchronization
• Change prints to logs
• Change the result of CLIs to a better form