# CoNTe: A Core Network Temporal Blockchain for 5G
## 3 Federated Byzantine Agreement Consensus
### Block Structure and Storage  
Blocks within Conte are composed of three parts; the block header, a list of transactions, and the previous block hash. Rather than a bespoke programming language and contract syntax, Conte flattens and standardizes possible operations to aid in interworking between networks, in a similar manner to IP packet structure. Each transaction is atomic and contains all of the information required for processing operations of the specific network function for which it is deployed, while also adhering to a single global format containing the sections below.  
* Contract ID: a globally unique integer value, serving as the identity of an Federated Byzantine Agreement (FBA).
* Contract Name: a non-unique string value, serving as a human readable name for a given FBA.
* Message Signature: the cryptographic signature, or public key of the network node proposing a transaction.
* Function: a rigidly defined struct value-defined as standard for each network function. An example struct being: [NF Name]; [Operation]. In the AUSF use case, this would designate: [AUSF]; [authorize], [AUSF]; [revoke], or others standard operations of the chains' designated network function.
* Message Body: an array value containing the core transaction data. In the example AUSF use case, this is the 5G Globally Unique Temporary Identifier (the 5G subscriber ID).
* Index Number: an incrementing integer value, designating a records position in the hashed chain.  
Conte is structured to allow a node to participate in multiple independent chains simultaneously. Rather than a monolith chain that grows in perpetuity, Conte intends new chains to be created, run in parallel, and retired after serving an intended purpose. This managed lifecycle can be months, years, or an indeterminate amount of time; partner networks may, for example, share subscriber data to grant access in cases of natural disaster. Because Conte requires full agreement to settle consensus, meaning that all peers of a given node must provide block confirmation before a block is considered to be final; there is no risk of fork and no increase of security through increasing the ledger length in perpetuity. This paradigm facilitates the negotiation of software upgrades among smaller subsets of peers for individual chains, and also with consideration to the expectation that network data is real-time data, whose value trends towards zero in time.  
Because the Conte blockchain stores living network data, it is important to allow a mechanism to prune or optimize storage. This is done in two ways; during an initial sync or in ongoing pruning. Returning to our example scenario of authorization, let us assume a network requirement where devices must be reauthorized every 90 days through a transaction renewing its permissions. Assuming that each network has an external record retention policy and mechanisms of network logging, this effectively places a 90-day expiry on the utility of transactions in the chain. In a scenario such as this, a node requesting to sync can do so by requesting all transactions from \(N\) date, rather than an entire chain growing in perpetuity. Because the chain length is not a mechanism of security, as in Ethereum, or assisting in reaching finality as in IOTA, the chain can be partially synced in this manner without risking safety of ongoing consensus, as defined by the intended use of the single chain, or microchain (Figure 4).