1. Ledger Consensus through Voting in the
Trestor Network
Trestor Foundation∗
July 1, 2015
Abstract
This whitepaper describes the Trestor Network (T-Net) consensus pro-
tocol, 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.
1 Introduction
In 2009, pseudonymous author Satoshi Nakamoto published a network proto-
col 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 sys-
tem which works completely without any central authority. Users hold public-
private 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 en-
ergy. Some journalists estimate1 that every single Bitcoin transaction on aver-
age 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 vot-
ing. 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.
2 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 and Stephan Verbücheln
1http://motherboard.vice.com/read/bitcoin-is-unsustainable
1

2. W
V
F
F
F
F
F
V
V
V
W
W
W
V
F
Validator node
Forwarding node
Wallet
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 pay-
ment 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.
3 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 Forward-
ing nodes, and check them for validity. Every few seconds, the Validator nodes
2

3. 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 trans-
actions 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 double-
spending problem. A dishonest user could try to defraud another user by send-
ing 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.
3.1 Synchronization
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 pos-
sibility 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.
3.2 Deposits
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 dis-
charging 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.
3

4. 3.3 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 ac-
counts implicitly provide a list of existing Validator nodes. A Validator node
can randomly choose a set of peers from that list with uniform distribution.
4 Voting
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 fin-
ished. 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.
4.1 Collection Phase
In the collection phase, a Validator node collects new transactions from For-
warding nodes. At this point, they are checked for basic validity. If a trans-
action 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.
4.2 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 trans-
action 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.
4

5. 4.3 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 transac-
tions 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 trans-
actions expire.
At the end of this phase, the Validator signs the ballot and sends it to its
peers.
4.4 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 Val-
idator 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.
4.5 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 caus-
ing 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 b 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, other-
wise he would need even more) have to tell v that they voted for b (or that
they confirm b ).
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) =
(m
k )(n−m
q−k )
(n
q)
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
5

6. q Pq(X = 13)
0 0.000000
5 0.000000
10 0.000000
15 0.000000
20 0.000019
25 0.000560
30 0.005254
35 0.024519
40 0.069433
45 0.132072
50 0.177635
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 proba-
bility for a successful attack would be around 5.696 × 10−8. With 20 controlled
nodes, the probability is still around 0.0019 %.
5 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.
5.1 Bitcoin
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 re-
sources. 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
network.
Over time, mining became professionalized. After the first users wrote min-
ing programs for their video cards, mining with regular CPUs was rendered
almost useless. The next obvious step was that some users started using pro-
grammable circuits to create mining hardware. In 2015, Bitcoin mining has
reached the point where the only way to participate in mining is a investment
6

7. 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 or-
ganized 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 de-
centralized 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.
5.2 Ripple
Ripple also implements a consensus protocol based on voting. The main dif-
ference 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 Valida-
tor node.
7