szYhQaCz

1A Critical Review of: ’TrustChain: A Sybil-resistant Scalable Blockchain’
2
3Abstract. The possibilities of blockchain and ledger technology have peaked a large interest from both academia as well as corporate institutes and governments. Based on these technologies, new proposals and improvements are suggested on a regular basis. Some of these proposals are more successful than others, based on how well they match the demands of a corporate environment. One of these proposals is TrustChain, combining ledger technology with building trust amongst participants. In this short paper we provide a critical analysis on TrustChain. We conclude that TrustChain is a novel concept and offers a rich domain for academia due to its many open questions. However, TrustChain needs to solve several privacy, regulatory, scalability, and security aspects to make the protocol feasible in a business critical environment.
4
51 Introduction
6The success of Bitcoin [8] has inspired both academia as well as industry and governments to investigate its underlying blockchain technology. The main idea of blockchain technology is to provide a global state of all accounts in a decentralized environment. However, there are many challenges with this technology. These challenges have led to a wide range of improvements and new concepts. For both academia, businesses and governments, it is interesting to understand at a global level what these new improvements and concepts entail, and how these will hold in practice. In this short paper we provide an analysis on one of these new concepts called TrustChain [9]. We base our analysis on these two works: TrustChain [9] and Extended TrustChain [2]. We discuss TrustChain in Section 2. Next, we perform a critical analysis 3 on TrustChain, discuss the known issues, identify new issues, and discuss limitations in both the protocol as well as the research performed on TrustChain. Finally, we provide our conclusion in Section 4.
7We assume that the reader has a basic understanding of how decentralized cryptocurrencies operate. This includes the concepts of a peer-to-peer network, hashing, transactions and mining.
82 On TrustChain
9Similar to Bitcoin, TrustChain [9] allows creation of transaction between parties, without central control. Contrary to Bitcoin, there is no leader selection in TrustChain. Instead, TrustChain allows the creation of transactions based on trust. These transactions propagate in a peer-to-peer (P2P) network. A major challenge in P2P networks is that of a Sybil attack, where an attacker introduces many (virtual) nodes in the network. This allows multiple attack scenarios, including Denial of Service (DoS) attacks, Man-in-the-Middle (MitM) attacks, and Eclipse attacks [11]. Many decentralized cryptocrrencies combat Sybil attacks by relying on some form of temporarily leader election, for example proof-of-work [5]. TrustChain, however, aims to combat Sybil attacks by means of a Sybilresistant algorithm called NetFlow. This algorithm determines the trustworthiness of participants in an online community. Since no leader election is present, TrustChain claims to scale much better than, for example, Bitcoin. The paper on TrustChain [9] aims to provide three contributions:
101. TrustChain, a tamper-proof, scabale and blockchain-based data structure. 2. NetFlow, a Sybil-resistant model to determine trustworthiness. 3. A public experiment, which addresses free riding in online communities.
11In the following paragraphs we briefly outline the first two contributions.
122.1 TrustChain transactions
13Transactions in TrustChain may include the exchange of files, buying goods, and transferring money. Each transaction is cryptographically signed by each participant. This ensures that participation of each user involved in the transaction is irrefutable. TrustChain transactions are linked by adding the hashes of the last transaction of each individual participant in the newly created transaction. In principle, each transaction has two incoming and two outgoing pointers. Every participant grows their own transaction chain. All chains together form a graph, which is used as input for NetFlow (see next paragraph). After two participants have signed their transaction, they both add the transaction to their own chain. Transactions in a single chain are ordered by a sequence number, uniquely identifying the position of the transaction from its Genesis block. Nodes publish their transaction chains to other nodes, so that other nodes can verify the integrity of both new transactions and the chains themselves. The paper references to [6][4] on details on how this is done in detail. Particularly, in TrustChain a transaction can be considered as a mechanism where consensus is reached among participants of a specific transaction. This, however, easily allows fraud, such as a double spend attack. In essence, TrustChain aims at detecting fraud. Contrary to proof-of-based cryptocurrencies, that aim at preventing fraud by incentified leader selection.
142.2 Sybil resistant algorithm: NetFlow
15NetFlow is an accounting mechanisms that takes the TrustChain graph as input. This graph is built based on the interactions (i.e. transactions) between nodes. Based on this graph, NetFlow can determine the interactions of a node, the amount of work performed, and can assign a weight to a node to determine its contribution to the network. The weight of a node thus can be used to determine its level of trust. Based on this trust level, a node can be selected for future interactions. The main idea of NetFlow, therefore, is that of an accounting mechanism determining how much a participant takes and contributes to the community. If a node contributes more, its level of trust increases. Participant trying to cheat, or those that do not contribute or try to abuse the protocol may be refused service.
162.3 An Extended TrustChain
17An extended version of TrustChain is discussed in [2], which we name ETC. ETC introduces a new type of block called a checkpoint (CP) block. CP blocks aim to capture the state of the chain to which this block is added to, by adding a hash pointer of the chain in the block. It is, however, not clear what the hash pointer entails. This could be a reference to the last transaction of the chain, a selection of the last n-transactions of a chain, or the entire chain. Additionally, it aims to capture the state of the system as a whole based on a Byzantine consensus algorithm.
18ETC Consensus. Since ETC uses no proof-of method, a Byzantine consensus algorithm is proposed. As mentioned in [2], such algorithms do not scale well in the presence of a large number of nodes. Therefore, in ETC is a random selection of nodes is proposed. These nodes are called facilitators and they should reach agreement on the system state through the Byzantine consensus algorithm.
193 A Broad Analysis of TrustChain
20The idea of creating trusted transactions is in interesting approach, compared to traditional decentralized payment systems that use leader election. However, as we will discuss in the following paragraphs, trusted transactions introduce various challenges.
213.1 Self-identified Attacks
22First, we discuss the attacks and proposed solutions identified in the TrustChain paper.
23Attack: Hiding blocks. The idea here is that a participant only exposes transactions that increase its reputation. Transactions that decrease its reputation or not send (hidden). If a participant refuses to provide a transaction, it is suggested in the TrustChain paper to not to transact with the participant until all records (i.e. linked transactions) are verified.
24Analysis. In principle, this is not an attack, since transactions are being broadcast by the other party of a transaction. However, a malicious participant may have created a chain of transactions with another account that the malicious attacker also controls. By ’forking’ the transaction chain, an attacker may show only the full branch of a chain that is valid according to the participant. Towards another participant, the attacker shows the other branch of the fork, which also seems legit. Though, ultimately, this fraud will be detected, the paper does not discuss how fast fraud detection takes place. In case of online purchases of digital products, this may be an issue.
25Attack: Refusal to Sign. A participant can decide not to sign a transaction that is not in the participant’s favor. Two approaches are suggested to mitigate this attack. First, not interacting with the (non-signing) participant any longer. Second, by gradually building trust between the two interacting participants by splitting the transaction in smaller amounts.
26Analysis. The first approach is effective, but ruthless. One can imagine that a power outage appears on the (non signing) participant’s side, which immediately leads to exclusion. Also, the paper does not determine on which basis a participant is identified. If, for example, identification is based on IP-address, an attacker could copy the IP-address of another participant, execute the attack, which would lead to exclusion of honest participants. The second approach may be possible, but ultimately, the final transaction may not be signed. The argument that this costs an attacker more resources, also goes for the honest participant. Even so, an attacker may execute this attack to multiple participants, simply deleting previous transactions and saving disks space. This would primarily make honest participants waste resources.
27Attack: Whitewashing Whitewashing is the act of removing one’s own identity, assuming it has a bad reputation, and creating a new identity. It is not desired to refuse services to those that yet have to build their reputation. A possible approach to this problem is to prioritize new identities lower by the allocation policy defined.
28Analysis. If new identities can be created and reputation can be build, this attack is always possible and could hamper the system significantly. In essence, any attacker with patience gets a free out-of-jail card. A smart attacker would create at least two identities. One for regular transactions, and a second one for fraudulent transactions. Once the fraudulent identity is whitewashed, the attacker can continue with day-to-day transactions with its ’honest’ identity.
293.2 Analysis of TrustChain
30On Sybil attacks. TrustChain claims to be able to be Sybil-resistant. This claim is made under the assumption that an attacker aims to gain profit. However, the paper does not discuss the various types of Sybil attacks [11][10], or the motivation of an attacker[1]. Instead of gaining resources, a malicious attacker motivational goal may simply be disruption of the system. Various scenarios are possible with the introduction of numerous nodes under control of a malicious actor: node exclusion (Eclipse attack), transmission delay, routing table poisoning attack, or reputation building through sock puppets. These perspectives are not discussed in the paper, and we consider the claim ’Sybil-resistant’ made to be too strong based on the narrow definition in the paper.
31Scaling properties. TrustChain is indeed scalable, as shown by the experiments made. There is, however, no baseline defined. In practise, TrustChain will currently not meet the demands of a global payment service provider such as VISA. This financial institution can process 2000 transactions per second (tps), on average, with a maximum of 56.000 tps. Also, the conclusion made that TrustChain is able to scale to thousands of transactions is not strong. First, the graphs show that with increased hardware, the scaling only increases marginal. Second, the 210 transactions per second are taken from the initial time frame of measurement. The graph clearly shows that, over time, the rate of number of transactions becomes lower than the initial rate. Third, the number shown from the experiment on mobile phones reach to 28.7 tps. This is only a marginal improvement over Bitcoin, that can process 7 tps (14 with Segregated Witness [7]). Finally, as the paper itself also addresses, network latency is not taken into account. This will reduce further the number of transactions per second. To conclude the scaling analyses, considering there is no leader selection (e.g. PoW), we expect a much larger increase in scalability. The reason for the only marginal increase in number of transactions per second is not given in the paper. Update: Input received on 03 July 2017. Based on [3] additional TrustChain experiments show that transaction throughput is up to 8000 transactions per second. This already is a significant improvement over the 120 transactions per second [3]. However, the experiment was held given perfect conditions. Future experiments should show if the high transaction throughput still holds when incorporating practical elements such as nodes joining and leaving the network, global bandwidth differences, or possible DoS attacks.
32Dealing with system non-compliance. This method of dealing with unwanted behavior, however, is rather crude and ineffective. First, any malicious participant could easily create a new identity and build a reputation. This allows an unlimited abuse of the system. Second, if a life-time identity is being used (such as a passport), being excluded from a system can have strong consequences for an individual, either as a customer of as a member of society. Also, this binary method of dealing with non-compliance with the system rule set leads to ways to abuse the system. For example, in a worst case scenario, stealing and
33abusing the identity of a participant could lead to societal outcast of an honest participant. Fine-graining this method is required before the concept of trust and blockchain technology become practical for a business or governmental environment.
34TrustChain transactions. It is unclear what the exact content of a transaction is. Suppose a transaction consists of a file exchange. If two parties exchange large files (e.g. a digital movie), then the chain will grow in size significantly. It is unclear how TrustChain deals with storage issues.
35Denial of Service. In the paper the concept of Denial of Service (DoS) is not addressed. Particularly in peer-to-peer networks, this may be an issue, since flooding the network with legitimate transactions is a possibility.
36Basic networking properties. Additionally, it is unclear what the impact is of transaction verification, what the minimum bandwidth requirement is, and what storage capacity is needed for TrustChain to become fully operational.
37The Double Spend Avoidance. The paper claims to be able to avoid a double spend. This is not correct, since it actually is possible to perform a double spend. TrustChain, once a double spend is performed, is able to detect the double spend. However, TrustChain is unable to determine which branch is valid. This leads to dealing with system non-compliance (see paragraph above).
38Also, it is unclear how long it takes before a double spend is detected. This is of significant importance since TrustChain effectively allows for a double spend to be performed. A very simple way of performing a double spend is to create two identities controlled by a malicious actor. These identities perform two (this can be an arbitrary number of) transactions, both branching from the same chain of transactions. Next, the attacker could conduct transactions with honest participants and buy goods.
39On Trust. We acknowledge the innovative idea of re-introducing trust into blockchain technology. However, Nakamoto’s initial paper introduced a cryptographic payment system, so that trust in third parties was no longer needed. Considering that the system can easily be abused, and that trust becomes an important factor in TrustChain, the question arises why and if a central party can fulfill the role of the TrustChain protocol. In essence, the benefit of trust combined with blockchain technology is unclear.
40On ETC Consensus. In [2] several assumptions are made. Namely, a public key infrastructure (PKI) exists, and nodes are identified by their unique and permanent public key. These are strong assumptions. First, TrustChain [9] claims to be permissionless. However, a PKI introduces a central certificate authority (CA). ETC introducing a PKI significantly limits the permissionless attribute of TrustChain. Additionally, TrustChain claims to offer openness. However, intro
41ducing a central authority, together with a permanent public key, may actually limit the openness of the system. Also, selecting random nodes introduces ETC to the possibility of a Sybil attack. ETC claims to reach consensus efficiently because of NetFlow. As discussed above, NetFlow can be abused by simply building trust and abusing that trust. This would result that, eventually, ETC and TrustChain could eventually reach in invalid state. The paper [2] also states that the system consist of N nodes, of which n are facilitators. It is unclear if n is a proportional element of N. If so, introducing multiple nodes hampers the Byzantine consensus algorithm. If not, introducing multiple nodes at random increases the probability that multiple nodes of an attacker are selected.
424 Conclusion
43Trustchain is a novel academic approach that combines blockchain technology with the concept of trust. Compared to traditional blockchain technologies, that link blocks, TrustChain links transactions. This creates an immutable chain of transactions for each participating identity. Since there is, in principle, no need for a global consensus, TrustChain claims to be able to scale. TrustChain also aims to be Sybil resistant against malicious actors that are motivated by gaining resources. Upon detecting malicious behavior the identity is excluded from participating. There are, however, many open questions and issues to address related to TrustChain. Given our analyses in the previous Sections, we consider TrustChain to be a rich topic for academic research. Currently, in communities that have no critical impact on business, customers or society, (for example, digital content sharing) TrustChain could be useful. From an operational business perspective, however, TrustChain currently seems not to be able to reach the practical demands a business and its stakeholders make, since there are too many open questions and issues on scalability, security, privacy, and regulatory compliance. Once TrustChain becomes more mature and subject to further academic research, its global chance of success may improve.
44Acknowledgement
45Many thanks to the ING blockchain team for providing excellent feedback on the initial version of this document.
46References
471. J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten. Sok: Research perspectives and challenges for bitcoin and cryptocurrencies. In 2015 IEEE Symposium on Security and Privacy, pages 104–121. IEEE, 2015. 2. K. Cong. Extended TrustChain, July 2017. https://github.com/kc1212/ consensus-thesis/blob/master/thesis/thesis.pdf Accessed 03 Jul 2017.
483. K. Cong. Extended TrustChain, July 2017. https://github.com/kc1212/ consensus-thesis/raw/master/thesis/thesis.pdf Accessed 03 Jul 2017. 4. R. Delaviz, J. Pouwelse, and D. Epema. Targeted and scalable information dissemination in a distributed reputation mechanism. In Proceedings of the seventh ACM workshop on Scalable trusted computing, pages 55–66. ACM, 2012. 5. C. Dwork and M. Naor. Pricing via Processing, Or, Combatting Junk Mail, Advances in Cryptology. In CRYPTO92: Lecture Notes in Computer Science No. 740, page 139147. Springer, 1993. 6. D. Gkorou, J. Pouwelse, and D. Epema. Trust-based collection of information in distributed reputation networks. In Proceedings of the 30th Annual ACM Symposium on Applied Computing, pages 2312–2319. ACM, 2015. 7. E. Lombrozo, J. Lau, and P. Wuille. Segregated Witness (Consensus Layer). https://github.com/CodeShark/bips/blob/segwit/bip-codesharkjl2012-segwit.mediawiki Accessed 04 Aug 2016. 8. S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. https: //bitcoin.org/bitcoin.pdf Accessed 20 Jun 2017. 9. P. Otte, M. de Vos, and J. Pouwelse. Trustchain: A Sybil-resistant Scalable Blockchain. In preparation. 10. L. Wang. Attacks against peer-to-peer networks and countermeasures. In T110.5290 Seminar on Network Security, 2006. 11. Y. Yang and L. Yang. A survey of peer-to-peer attacks and counter attacks. In Proceedings of the International Conference on Security and Management (SAM), page 1. The Steering Committee of The World Congress in Computer Science, Computer Engineering and Applied Computing (WorldComp), 2012.