TNet Protocol (PDF)

File information

This PDF 1.5 document has been generated by TeX / pdfTeX-1.40.18, and has been sent on on 02/12/2017 at 00:11, from IP address 5.151.x.x. The current document download page has been viewed 752 times.
File size: 106 KB (7 pages).
Privacy: public file

File preview

Ledger Consensus through Voting in the
Trestor Network
Trestor Foundation∗
July 1, 2015

This whitepaper describes the Trestor Network (T-Net) consensus protocol, which achieves consensus on the account ledger among network
nodes in a decentralized manner. In addition, we compare the protocol
to the existing protocols Bitcoin and Ripple.



In 2009, pseudonymous author Satoshi Nakamoto published a network protocol called Bitcoin together with a reference implementation. Bitcoin solved a
problem which has been unsolved for a long time by researchers in the field
of computer science: Distributed consensus. This allowed for a payment system which works completely without any central authority. Users hold publicprivate key pairs which act as accounts, and the consensus protocol ensures
that a public ledger keeps track of all account balances.
Bitcoin’s consesus protocol is based on a process called “mining”. In this
process, users contribute computational power in order to secure distributed
consensus. The main problem with this approach is that it consumes a lot of energy. Some journalists estimate1 that every single Bitcoin transaction on average consumes 1.57 times the electricity consumed by an average US household
per day.
In contrast to that, Trestor implements a consensus protocol based on voting. Voting does not require the contribution of vast computational power,
which makes it much more energy-efficient. In order to do that securely, the
protocol has to make sure that an attacker can not set up a large number of
voters, which would gain him a majority. This paper describes how this is
achieved in the Trestor consensus protocol.


The Trestor Network (T-Net)

The Trestor Network is a peer-to-peer network with three distinguished types
of nodes: Validator nodes, Forwarding nodes and Wallets.
∗ Protocol

design by Arpan Jati, Abhiroop Sarkar and Stephan Verbücheln













Validator node


Forwarding node



encrypted connection


trusted connection

Figure 1: Graph of the Trestor network
The Validator nodes are the nodes, which keep track of the users’ accounts
in a shared ledger using a decentralized consensus protocol. Users’ accounts
are associated with EdDSA public keys. A user can use his EdDSA private key
in order to create signed transactions, which allows him to spend money from
his account.
Consensus on the ledger is achieved by voting among Validator nodes,
which is described in more detail later in this work. Forwarding nodes share
the ledger just like Validator nodes, but do not participate in any voting. Their
purpose is to distribute the load of communication between Wallets and the
core network of Validator nodes.
Wallets are the type of nodes that are run by the common user in the payment system. The Wallet manages a user’s cryptographic keys and is his tool
to send money to other users. The reference implementations are the Trestor
Wallet apps for Android and other systems.


Validator Nodes

Validator nodes play the key role in network decentralization. A Validator
node can be set up by any person or organization.
Validator nodes collect new transactions, which they receive from Forwarding nodes, and check them for validity. Every few seconds, the Validator nodes

will vote on sets of new transactions in order to decide, which of them should
be added to the account ledger. Every Validator node has the same vote on this
matter, rendering the decision fully decentralized.
After the voters have agreed on a transaction, they will process the transactions on the corresponding accounts in the ledger, and the users (sender and
receiver) will be informed that their transaction has been confirmed.
The voting is important to solve the issue which is widely known as doublespending problem. A dishonest user could try to defraud another user by sending a transaction, which seems valid, but is later showing to be invalid. This
could be achieved by creating two transactions at the same time, which in total
spend more money than the input account is holding. Each of them alone looks
valid, but they cannot both be processed.
This problem could be easily solved by having a central server keep track
of all transactions. But this server would have total control about the ledger
and be able to arbitrarily change account balances (or be forced to do this by
a powerful third party). In a decentralized network, a distributed consensus
algorithm is needed in order to prevent a small number of peers from changing
the ledger.



In order to be able to participate in voting, a Validator node needs to know the
current state of the ledger. If a Validator node is completely new or has been
disconnected from the network for some time, it has to get in sync.
The crucial problem at this point is to receive a valid hash of the current
ledger. There are multiple strategies which could be used to receive this hash.
One possibility would be to ask a known trusted Validator node. Another possibility would be to ask a set of nodes and consider the majority opinion. In
the latter strategy, not every single node has to be trusted, but only a majority
in that set. After the correct hash value has been received, a Validator node can
easily download parts of the ledger from any other node, and check whether
the received data matches the hash.
In order to perform this synchronization efficiently, Validator nodes store
the account ledger in form of a tree. A tree-synchronization algorithm allows
the Validator node to compare small parts of the ledger in a systematic way
and request only for those parts of the ledger from other peers, which are out
of sync.



In order to limit the ability for attackers to set up an arbitrary number of nodes,
every nodes has to be backed by a deposit account. The EdDSA public and
private keys of the account are used to authenticate the Validator node and
secure its communication.
Validator nodes will only consider votes from nodes, who have a certain
minimum balance in their deposit. In addition to that, the charging and discharging of balance accounts takes a certain amount of time (i.e. 6 hours) to
be processed. This prevents potential attackers from creating many validator
nodes in a short period of time. The appearance of a new Validator node will
be visible for the network 6 hours in advance.


Random Selection of Peers

When the network grows, the number of Validator nodes might become too
large to connect every Validator to every other one. In this case, every Validator
will only connect to smaller number of peers.
In order to retain the security of the network, the peers of a Validator have
to be chosen at random. This can be done, because the ledger’s deposit accounts implicitly provide a list of existing Validator nodes. A Validator node
can randomly choose a set of peers from that list with uniform distribution.



The process of voting consists of multiple phases. The collection phase collects
new transactions, checks them for basic validity and adds them to a queue.
This collecting can happen in parallel to the actual voting.
The actual voting consists of three phases: Merging phase, voting phase
and confirmation phase. Each phase is started after the previous one has finished. One full round of voting (merging, voting, confirmation) takes around
10 seconds. Most transactions will be confirmed in that round, if they are not
part of a double-spend attempt. Potentially unconfirmed transactions will be
processed in the next round.


Collection Phase

In the collection phase, a Validator node collects new transactions from Forwarding nodes. At this point, they are checked for basic validity. If a transaction has a valid signature, and the corresponding accounts provide enough
funds, it is added to the set of currently processed transactions.
Note that at this point there might still be multiple transactions, which
in combination exceed the balance of an account, even though each of them
would be considered valid on its own.


Merging Phase

In the merging phase, Validator nodes propagate the transaction IDs for all
of their known transactions. In this phase, no more new transactions from
forwarding nodes are included. New transactions from forwarding nodes will
be processed in the next round of merging.
In the meanwhile, Validator nodes ask their peers about the details of transaction IDs they learn and are not yet part of their own collection. They request
them from the peer, which sent the new transaction ID, check their validity and
add them to their own set. After that, they will include these transactions in
their own propagation efforts.
At the end of this phase, a large majority of nodes has knowledge about all
new transactions.



Voting Phase

In the voting phase, a Validator node takes all nodes that it received by a 60 %
majority of peers and assembles them into a ballot. A ballot is a set of transactions that are valid in combination.
If in the process of assembling the node discovers two transactions which
are in conflict (i.e. using the same funds from an account), both of them are
removed and the corresponding account is blacklisted until all of those transactions expire.
At the end of this phase, the Validator signs the ballot and sends it to its


Confirmation Phase

In the confirmation phase, a Validator counts how many peers voted on a set
of transactions. If a set of transactions reached a high majority of 75 %, the Validator node performs the corresponding transactions on the ledger and sends
out a confirmation message to its peers. The confirmation message allows a
node to propagate a majority ballot to its peers even if it has not voted Yes on
it. This is important, because a honest node might be unable to vote Yes on a
certain ballot, e.g. after it voted Yes on another ballot which is in conflict.


Security Considerations

After a voting was successful, the new ledger will be closed. As there is nothing
like a longest-chain rule, the history of a closed ledger can never be changed.
This means, that the only way to get disagreement about history is by causing the network to fork. An attacker, who wants to perform a double spend,
has to convince the victim’s wallet, that a transaction happened, even though
the majority of the network agrees on a different history.
Let n be the total number of Validator nodes, and m the number of peers
that each of them trusts in the voting. What happens, if the attacker wants to
mislead one Validator v?
Let v1 , . . . , vm be the nodes trusted by v. In order to convince v of a fake
ballot b0 while the network agrees on a ballot b, more than 50 % of v1 , . . . , vm
(assuming that the possible 25 % in disagreement all help the attacker, otherwise he would need even more) have to tell v that they voted for b0 (or that
they confirm b0 ).
In the case that the Validator is connected to all other Validators, it means
that the attacker has to control 50 % of all Validators. The fact that Validators
have to be backed by a deposit renders this infeasible.
What happens with a larger number of Validators, when not everybody is
connected to everybody? Let q be the total number of Validators controlled by
the attacker. The probability, that the attacker controls k of v’s trusted peers,
follows the hypergeometric distribution:
Pq ( X = k ) =

−k )


Let’s assume for example that the total number of nodes is n = 100 and
the number of connected peers is m = 25. What are the odds, that an attacker


Pq ( X = 13)

Figure 2: Probabilites for an attacker majority
controls more than 50 % of a v’s peers (which means at least 13), under the
assumption that he controls q (of the 100) nodes in total?
As we can see, even if the attacker controls 15 of the 100 nodes, the probability for a successful attack would be around 5.696 × 10−8 . With 20 controlled
nodes, the probability is still around 0.0019 %.


Comparison to Existing Protocols

Since the publication of Bitcoin by pseudonymous author Satoshi Nakamoto,
a lot of crypto-currencies have come up. They all share the property that user
uses some sort of private keys and a digital signature scheme to access his
money. The main differences between the many “altcoins” lies in the consensus
protocol, which manages the distributed ledger.



The main difference between Bitcoin and Trestor is that the Trestor consensus
protocol does not involve any mining. Consensus is achieved through voting
among Validator nodes.
The Bitcoin protocol does not distinguish between different types of nodes.
The original Bitcoin client was user wallet (managing user’s keys), network
server (providing the ledger to other peers) and miner at the same time. The
idea was that of full decentralization, everybody who wants can participate in
the network in every way.
Bitcoin mining can be viewed as a way of voting with computational resources. Not everybody is expected to have a equally powerful computer, but
the idea was that the mass of users will decide about the future direction of the
Over time, mining became professionalized. After the first users wrote mining programs for their video cards, mining with regular CPUs was rendered
almost useless. The next obvious step was that some users started using programmable circuits to create mining hardware. In 2015, Bitcoin mining has
reached the point where the only way to participate in mining is a investment

in hardware that was particularly designed for this purpose. Mining is highly
competitive, so a miner also has to make sure that he has premium Internet
connectivity and a cheap and reliable source of electricity.
Mining is now concentrated among professional miners, and those are organized into large mining pools. Normal users do not mine any longer (except
maybe for fun). Large mining pools have the largest influence on the network,
including changes in the protocol.
The Trestor network was designed with this development in mind. Trestor
distinguished the three different types of peers, because the normal user will
use a smartphone app which would be to weak for running a full Validator
node to begin with. This might give the impression, that Trestor is less decentralized than Bitcoin, if one only considers the protocol design. But if one
considers the actual development of the Bitcoin network, this is not the case.



Ripple also implements a consensus protocol based on voting. The main difference between Ripple and Trestor is, that Ripple servers keep lists of trusted
servers. This results in a very centralized structure of the underlying network
graph. Most servers will trust Ripple’s own servers, resulting in what they call
a “federated system”.
The Trestor network does not have such lists. All votes from Validator
nodes with a certain minimum amount of deposit are considered equally valid.
The only trust required in Trestor is during the bootstrapping of a new Validator node.


Download TNet Protocol

TNet Protocol.pdf (PDF, 106 KB)

Download PDF

Share this file on social networks


Link to this page

Permanent link

Use the permanent link to the download page to share your document on Facebook, Twitter, LinkedIn, or directly with a contact by e-Mail, Messenger, Whatsapp, Line..

Short link

Use the short link to share your document on Twitter or by text message (SMS)


Copy the following HTML code to share your document on a Website or Blog

QR Code to this page

QR Code link to PDF file TNet Protocol.pdf

This file has been shared publicly by a user of PDF Archive.
Document ID: 0000703851.
Report illicit content