The communication network underlying an open blockchain is called a peer-to-peer network. The network consists of a large number of interconnected nodes. A node is just a computer that takes part in passing messages around and recording which messages have been sent. A peer-to-peer network allows any node to send a message to all other nodes that are currently part of the network. Each node in the network is connected to a small set of other nodes, the so-called neighbors. A message is sent in a peer-to-peer network by flooding it along the connections. When receiving a new message for the first time, a node sends it to all its neighbors, and then records the message as having been sent.

The neighbors of a node are selected at random. A network might for instance consist of 100.000 nodes, where each node is connected to a random selection of 100 other nodes. Picking the neighbors at random gives a very robust design, where all machines stay connected to each other via many routes, even as nodes come and go. Having many different routes for a message also prevents corrupted nodes from controlling which messages are sent. The network cannot be censored, as there is always a route along honest nodes that the message can follow.

One of the research topics we plan to address, is incentivisation in the peer-to-peer layer. When a cryptocurrency is running on top of the peer-to-peer layer, some of the transaction fees of the cryptocurrencies can be used to incentivize the nodes of the underlying peer-to-peer layer to behave honestly and efficiently. This will involve design of novel peer-to-peer layers and microeconomic analysis of such protocols.

Another research topic will be to derive precise mathematical specifications of what the peer-to-peer layer should be doing, i.e., which outputs does it deliver on which inputs, and under which conditions. Such a specification is ideally independent of exactly how the peer-to-peer layer implements the specification. Having a precise specification will allow to prove secure the layers running on top of the peer-to-peer layer, like the consensus layer, without knowing the details of the peer-to-peer layer. One simply proves that the consensus layer does what it is supposed to do, under the assumption that the peer-to-peer layer does what it is supposed to do. It will also provide a target specification for proving that a given peer-to-peer layer implementation actually behaves as it should, even when under attack. Such modular design is essential, as it allows to develop the peer-to-peer layer and the consensus layer independently. The mathematical specification of intended behaviour serves as the mutual contract between the layers.