# CoNTe: A Core Network Temporal Blockchain for 5G
## 3 Federated Byzantine Agreement Consensus
### Transaction and Protocol Messages  
Joining consensus on a Conte blockchain occurs by configuring a peer and mutually validating identity through exchange of public keys. In addition to public key exchange, a peering request arrives with either a genesis block, containing a randomly generated contract ID, or a request to sync, containing the contract ID of an existing chain that is the target of synchronization. It is assumed that 5G core networks are connected pair-wise, rather than fully peer-to-peer. Structuring consensus in this way allows it to function when networks are operating peer-to-peer, but also when sensitive infrastructure is siloed behind firewalls and strict route controls. Nodes may also proxy or pass block proposals while using NEF operations, in compliance with 3 GPP 5G design. Conte exposes secure RESTful APIs for protocol messaging between nodes, including GET and POST operations. Protocol messages include: peer, sync, propose, acknowledge, negative acknowledge, commit, and prune. * Peer: initialize connection to new contract peer. * Sync: after initial connection, or during conflicting commits, a node can request to sync transactions. This sync includes a check to confirm a known peer with the longest change, and a verification of new blocks by re-hashing them using the SHA-256 algorithm. * Propose: issue a new transaction. A new block can be proposed by any member of the network. The block must be signed with a cryptographic key to validate identity. Each block is sent as unicast to all peers of a given node, which forwards the proposal, until reaching nodes at the graph edge. For bandwidth efficiency, a node may delay block proposal, until it has multiple transactions to submit-in which case, these may be bundled into a single block. A node is considered a graph edge after receiving the same proposed block from all its known peers. * Acknowledge: provides confirmation of acceptance of new transaction blocks. Once a proposed block is received, its header, body, and signature data is validated and an acknowledgment is returned. A node must receive an acknowledgment for each forwarded block proposal, before propagating back its own aggregate acknowledgment. Nodes receiving invalid blocks, competing blocks with the same index value, or out of sequence blocks send a negative acknowledgment, aborting consensus. * Negative Acknowledge: deny confirmation of blocks in case of conflicting block data, such as index position, aggregate hash, or message signature. Figure 4: Example of multiple network function-specific blockchains running across operators. * Commit: a final notification that a block is committed locally by a proposing node, signaling that remaining nodes handling consensus as clear to add the block into their respective local chains. Conte ensures that no two nodes store different blocks with the same index value, by aborting consensus when encountering conflicting data or error. In states where acknowledgment is received from all peers, the block is committed to the local chain and a final commit message is issued to peers (Figure 5), who commit the block in their local chain and propagate the commit forward toward edge nodes. * Prune: nodes that fail to reach consensus may initiate a request to prune from peer lists, any peer which has failed to respond to three consecutive proposals. Prune requests forward propagate in a manner that is similar to a propose message, with the full network reaching consensus to prune the peer. A negative acknowledgment may be sent if the target peer is responsive elsewhere in the network. Because Conte requires full confirmation in order to reach finality in a manner that is similar to TCP error correction, a given message is repeated if an expected response is not received within a given timeout, until a pruning state is triggered. Algorithm 1 shows simplified pseudo-code of Conte message functions.