The TezEdge node: A deep dive into the Tezos P2P layer

Peer-to-peer networks are of particular interest to cryptocurrencies because they work well within the decentralized architecture of blockchain. A node communicates with other Tezos nodes through a peer to peer gossip network to distribute information about the state of the network.

Let’s say Alice wants to participate in the Tezos network. She’s interested in baking or maybe she’s a smart contract developer that wants to access data on the blockchain. Regardless of her motive, in order to participate in the Tezos network, she must set her device up as a node in the Tezos network. This set up is known as bootstrapping and it involves syncing with the network (downloading the current state of the blockchain). This process is divided into two parts:

• the handshaking process, during which peers exchange information about each other in order to create a trusted channel for communication.
• the bootstrapping process, in which a peer syncs with the current version of the blockchain.

The handshaking process

1. Generating a peer’s identity

First, before she can even connect to the P2P layer, Tezos requires new peers to complete a minor proof of work task through which they create an identity for their node. This proof of work task is a countermeasure against adversaries that could otherwise flood the Tezos network with thousands of fake peers (known as a Sybil attack). The proof of work involves the finding of a nonce. This proof of work task is similar (but much less difficult) to what Bitcoin miners solve when they mine new blocks. Once this nonce is discovered, the peer is awarded with a proof_of_work_stamp. Your node’s identity is based on this nonce.

Peers generate the following four types of information after solving the proof of work task:

peer_id: the identity of the peer, based on the nonce solved in the initial proof of work task.

public_key: the public key is given to other peers, who combine it with their private keys to create channel keys, creating trusted connections between peers.

secret_key: this is the peer’s own private key that is combined with the public key of other peers to form channel keys which are used to encrypt and decrypt messages sent between peers.

proof_of_work_stamp: a stamp that is used to prove the validity of a peer’s proof of work nonce.

2. Requesting a list of peers from the DNS

Alice now connects into the Tezos P2P network. Now she’ll need to figure out which peers to connect to. She requests a list of peers from a DNS server, which then delivers a peer list that contains the IP addresses of peers to whom Alice can connect. Although there can potentially be millions of peers in the Tezos network, she only connects to a few at a time. If necessary, Alice can later expand her peer list by requesting other peers for their peer lists.

Now having figured who she will connect to, Alice must establish a trusted connection with these peers, a process known as handshaking.

3. The handshake

Let’s say Alice wants to handshake Bob. Before the handshake starts, Alice generates a nonce (unrelated to the nonce from step 1) that serves as a counter for messages sent to Bob. Similarly, Bob generates a nonce that counts messages he sends to Alice. Then Alice and Bob exchange their proof of work stamps, public keys, nonces, listener ports and lists of versions.

Proof of work stamp

This is a stamp that was generated from the proof of work task Alice completed in step 1.

Public Key

The public key is generated in step 1 and is used for encrypting messages between peers.

Nonce

This nonce is a unique value generated by Alice before she begins a handshake with Bob. It works as a counter; Alice receives Bob’s nonce (the Bob-Alice nonce) and uses it to count the number of messages she received from Bob. In addition to the nonce received from Bob, Alice already has another nonce she generated before the handshake, the Alice-Bob nonce, which she uses as a counter for messages sent to Bob.

This nonce is not to be confused with the nonce involved in the initial proof of work task used to generate a peer’s identity.

Alice checks Bob’s proof of work stamp and vice versa. If both stamps are valid, Alice uses her private key and Bob’s public key to create a channel key. Bob does the same with his private key and Alice’s public key. Alice uses her channel key in combination with either nonce, depending on whether she is receiving (the Bob Alice nonce) or sending (the Alice Bob nonce) a message, specifically, to encrypt or decrypt the messages she exchanges with Bob.

Now they exchange the first encrypted message that contains metadata. After that, they exchange another message that contains Ack/Nack (accept/deny the connection).

If Alice receives Ack from Bob and vice versa, the handshake is successful and now they are ready to start exchanging encrypted messages.

Alice repeats this process with other peers until she has established a trusted connection with a sufficient number of peers. Although she has a trusted connection with only a certain amount of peers, she is indirectly connected to the entire Tezos distributed network, as pictured in the animation above.

When the channel is formed, the peers exchange other types of messages, including:

• Bootstrapping (syncing with the current version of the blockchain)
• Peer lists
• Injecting new operations
• New block publications
• Protocol changes

The bootstrapping process

1. Requesting and downloading the headers

Now that it is safe to communicate, Alice can start bootstrapping her node. She has to update with the latest state of the blockchain, which means downloading a history of all the blocks that have been published thus far on Tezos. Alice requests Bob’s most recent block header.

Each block header contains the following information:

level: the height of the block, from the genesis block

proto: number of protocol changes since the genesis block.

predecessor: the hash of the preceding block.

timestamp: the timestamp at which the block is claimed to have been created.

validation_pass: number of validation passes (also number of lists of lists of operations).

fitness: a sequence of sequences of unsigned bytes that represents the claimed fitness of the chain ending in this block. A block with greater fitness will be published in favor of a block with less fitness at the same block height.

operations_hash: The root hash of a Merkle tree of a list of root hashes of Merkle trees for various sets of operations in the block.

context: Hash of the state of the context after application of this block.

Consider the fact that Alice doesn’t know which block is the latest. This means she can’t identify one peer who has the latest version, and just download from him. Instead, she’ll connect to all successfully handshaked peers and begin to request a history of all blocks (block headers and operations) from each peer. Each peer samples their block history differently. Alice starts by downloading the most recent block from the peer’s earliest sample. Alice needs to download the blocks chronologically, from the oldest to the newest, reflecting the order in which these blocks were published.

2. Downloading operations and completing the blocks

Once the headers have been downloaded, Alice will begin completing the blocks by downloading the operations within them, starting with the oldest block (block level 1, the block immediately following the genesis block). This means all operations, including transaction data.

A block contains the following lists of operations:

Transactions: transactions of Tezos tokens between Tezos users. This is the standard operation used to transfer Tezos tokens to an account.

Delegations: this is used to delegate funds to a baker registered as a delegate. The source address for delegating XTZ to a delegate must be originated (KT1 address). A delegate can be marked as either active or passive. A passive delegate cannot be selected for baking or endorsement.

Originations: this operation is used to create originated accounts. Originated accounts have addresses starting with “KT1”. Originated accounts are used for two reasons. The first is delegation. To delegate Tezos tokens to a baker, the user’s source address must be originated (starting with “KT1”). The other reason is to support smart contracts, as an originated account can have associated Michelson code that will be executed when called upon.

Endorsement: the endorsement operation specifies the head of the chain as seen by the endorser of a given slot. The endorser is randomly selected to be included in the block that extends the head of the chain as specified in this operation. A block with more endorsements improves the weight of the chain and increases the likelihood of that chain being the canonical one.

Activations: this type of operation is used to activate accounts that had been allocated with Tezos tokens for their contributions to the initial fundraiser of the Tezos Foundation.

There are also other types of operations that are less common:

Seed nonce revelation: this is used to reveal the nonce involved in the generation of a peer’s identity.

Double endorsement evidence: a very rare type of operation that represents evidence of a double endorsement, i.e. when there are two endorsements for two blocks at the same block level.

Double baking evidence: a type of operation that represents evidence of double baking, in which a baker has attempted to bake (validate) two blocks at the same block level.

3. Applying operations to protocol

Now that Alice has all operations downloaded, she applies them to the protocol. It is important to note that the Tezos protocol lies outside of the P2P layer. The protocol validates the blocks and the operations in them. Once validated, the operations are applied, resulting in a ledger which contains various information, including the balances of all Tezos users. This data is then stored in the storage module. We will cover both the protocol and the storage in later articles.

We hope you enjoyed this article. This is the first part of our ongoing series that covers the technical details of the Tezos network.

To read more about Tezos and our Rust-based Tezos node, please subscribe to our Medium, follow us on Twitter or visit our GitHub. You can also help shape the Tezos Rust node by filling out the survey.