idnits 2.17.1 draft-pouwelse-trustchain-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 43 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 5, 2018) is 2150 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Pouwelse, Ed. 3 Internet-Draft Delft University of Technology 4 Intended status: Informational June 5, 2018 5 Expires: December 7, 2018 7 Trustchain protocol 8 draft-pouwelse-trustchain-01 10 Abstract 12 Trustchain is a protocol for a networked datastructure, designed to 13 act as a trust ledger. This protocol acts as a decentralized 14 alternative to platforms like eBay, Airbnb, and Uber. It is 15 specifically designed to record transactions among strangers without 16 central control, support high transaction volumes, be application 17 neutral, and avoid vendor lock-in. The protocol defines recording 18 transactions in an ordered list using an append-only datastructure, a 19 new communication overlay, and a horizontally scalable consensus 20 protocol based on checkpoint consensus, called CHECO. Trustchain has 21 resistance to traditional blockchain attacks, such as the 51 percent 22 majority attack. This is achieved by using a graph-based append-only 23 datastructure combined with a personal blockchain for each 24 participant with their own genesis block. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 7, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Trustchain Stack: Engineering trust . . . . . . . . . . . . . 5 65 3. Trustchain Fabric: internal data structure . . . . . . . . . 7 66 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 7 67 3.2. TxBlock specification . . . . . . . . . . . . . . . . . . 9 68 3.3. Asynchronicity . . . . . . . . . . . . . . . . . . . . . 10 69 3.4. CHECO: Consensus protocol and block format . . . . . . . 11 70 4. IPv8: Overlay for identity, discovery and trust . . . . . . . 11 71 4.1. Identity establishment and discovery . . . . . . . . . . 12 72 4.2. Attestations and trust . . . . . . . . . . . . . . . . . 12 73 4.3. Peer-to-peer cryptographically signed messaging . . . . . 25 74 4.4. NAT traversal . . . . . . . . . . . . . . . . . . . . . . 25 75 5. Attack resistances . . . . . . . . . . . . . . . . . . . . . 26 76 5.1. Sybil attacks . . . . . . . . . . . . . . . . . . . . . . 26 77 5.2. Double spending attack . . . . . . . . . . . . . . . . . 26 78 5.3. Replay attack . . . . . . . . . . . . . . . . . . . . . . 27 79 5.4. Whitewashing attack . . . . . . . . . . . . . . . . . . . 27 80 5.5. Spam attack . . . . . . . . . . . . . . . . . . . . . . . 27 81 5.6. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 28 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 88 1. Introduction 90 For the past 10 years various distributed ledgers have been deployed 91 and used. This protocol aims to establish some form of trust using 92 software. 94 Creating trust between strangers is at the core of numerous 95 successful Internet companies. Starting 22 years ago, Craigslist 96 offered an unmoderated mailing list of advertisements and gossip on 97 which buyer and seller could be trusted. eBay formalised this in 98 1997 and introduced a star-based rating system that enables traders 99 to build a trustworthy profile [resnick2002trust]. The e-commerce 100 platform was launched at a time when people were still hesitant to 101 use their credit card on a technology called The Internet. Nowadays, 102 people let strangers sleep in their houses using Airbnb (since 2008). 103 We trust Uber (since 2009) with our physical security and get into 104 cars late at night with a driver that has not undergone a criminal 105 background check or given a government license. 107 The Trustchain protocol aims to create a generic approach and 108 continues this evolution of building trust. Compared to successful 109 central platforms, we propose a distributed open underlying 110 infrastructure, based on blockchain inspired technology. Bitcoin 111 created money without the need for banks [nakamoto2008bitcoin]. In 112 the past, people were required to trust a central bank and a host of 113 other intermediaries when making payments [kokkola2011payment]. The 114 fundamental technology of Bitcoin, blockchain, radically reduced the 115 need to trust financial middlemen. It bootstrapped an economy where 116 no one can be stopped from spending their money. Despite widespread 117 speculation and ecosystems being worth billions, blockchain in 118 general suffers from scalability issues due to inefficient mechanisms 119 for fraud prevention. Bitcoin is theoretically limited to seven 120 transactions per second and Ethereum has a throughput of around 20 121 transactions per second [vukolic2015quest]. Despite various 122 scalability efforts like proof-of-stake and sharding, broader 123 adoption of blockchain stays out. Mt. Gox was at one point the 124 largest Bitcoin exchange worldwide. While a majority of Internet 125 users trust the company behind popular platforms, the events 126 involving Mt. Gox highlighted how digital trust can be established 127 and compromised[mcmillan2014inside]. In 2014, hackers stole Bitcoin, 128 worth around $460 million at that time. This event, together with 129 major data breaches in 2017 at high-profile companies like Uber and 130 Equifax, exposed the weakness of centralized architectures 131 [apostle2017uber]. These events motivated this proposed protocol 132 around decentralised infrastructures, not owned or operated by a 133 single authority. The generic problem of building trust between 134 strangers resides on the edge of technology, sociology and 135 behavioural science [yan2008trust]. The question whether someone can 136 be trusted, depends on properties like personality, level of 137 authority, culture and past behaviour. In this protocol, we address 138 the trust problem from a technological perspective, using tamper- 139 proof interactions on a scalable blockchain. This structure is built 140 to help ease the detection of fraudulent behaviour and 141 misrepresentation. Trust calculations are out of scope of this work, 142 we provide the enabling mechanisms. 144 1.1. Purpose 146 This draft describes the Trustchain architecture, protocols and the 147 used technologies, designed to model application neutral trust 148 between interacting parties. Trustchain relies on a new 149 communication layer on top of existing communication networks, which 150 is designed with carrier-grade NAT infrastructure in mind, as well as 151 the network protocol based on the CrawlRequest and TxBlock message 152 types. A consensus protocol called CHECO (Cong et al, 2017 153 [cong2017blockchain]) is incorporated into Trustchain, which will be 154 discussed but not elaborated in this draft. It is based on the 155 blockchain paradigm where the complete network represents a ledger 156 where agents' transactions infer an amount of trust between the 157 involved parties, as is described by pouwelse, 2017 158 [pouwelse2017trustlaws]. 160 As protocols have slowly been moving towards the business layer in 161 the past decade, Trustchain is implemented on top of a networking 162 overlay and as such is network agnostic. Other examples of moving 163 networking to the business layer are: R3 Corda (Brown, 2017 164 [brown2017introducing]) and IOTA (Atzori, 2016 165 [atzori2016blockchain]). The overlay, audaciously called IPv8, 166 provides encrypted communication between public keys. This overlay 167 has integrated NAT puncturing to support, for instance, Android-to- 168 Android overlay communication, does not require any central server, 169 lacks central authorities, and can run directly on top of UDP, TCP, 170 or other protocols. As such, IPv8 provides a set of communication 171 methods and messages that provide the required functionality to let 172 Trustchain function properly on both PC networks or smartphone-only 173 networks. 175 1.2. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [RFC2119]. 181 1.3. Terminology 183 Identity 184 The actual user representation, but can not be directly used, 185 since all information is identifier based. 187 Identifier 188 A reference that is owned by a given identity, referring to this 189 identity. Any identity can have multiple identifiers, whilst 190 staying anonymous. 192 Agent 193 A node in the Trustchain network representing an identifier for a 194 given identity. 196 Message 197 The basic unit of Trustchain communication. A message will have 198 different representations on the wire depending on the transport 199 protocol used. Messages are typically multiplexed into a 200 datagram for transmission. 202 Datagram 203 A sequence of messages that is offered as a unit to the 204 underlying transport protocol (UDP, etc.). 206 Transaction 207 An interaction between two agents containing information on both 208 parties and what has been transacted. This is application 209 agnostic, meaning that any given application can infer what type 210 of information it needs based on a collection of transactions. 212 Signature 213 A cryptographic function that used the private key to create a 214 representing string, which can be verified by any other party 215 using the signer's public key. 217 Hash 218 The result of applying a cryptographic hash function, more 219 specifically SHA-256 [FIPS180-4], to a piece of data. 221 2. Trustchain Stack: Engineering trust 223 Our principal mechanism to establish some form of trust is: if 224 everyone keeps their secret keys secure, then no signed transaction 225 can be spoofed on the overlay by any significant likelihood. We 226 refer to the Trustchain protocol when discussing the mechanism to 227 record interactions which are cryptographically signed by multiple 228 parties. We explicitly do not support transactions signed by only a 229 single party, which is the foundation of Bitcoin. Our foundation is 230 a multi-signature agreement, without mono-signature support. The 231 Trustchain stack refers to the full system which also includes the 232 upper application layer, the network overlay and self-sovereign 233 identity layer. Together they form a complete solution stack. 235 The concept of a Self-Sovereign Identity (SSI) (Abraham, 2017 236 [abrahamself]) means that agents have full control over their 237 identity data, and provide it to those who need to validate it, 238 without relying on a central repository of identity data of any kind. 239 A large part of any SSI based system is rooted in the problem of 240 proofs and attestations: proof can be anything, such as a secret 241 message that is re-encrypted with a shared secret. But the most 242 challenging part is working with attestations. An Attestation refers 243 to the process wherein a third party validates that according to 244 their records, the claims are true, that is, a more transitive 245 property of trust: C attests to B that A is who it claims to be, 246 Azouvi et al, 2017 [azouvi2017secure]. As such, an attestation from 247 the right authority could be more trustworthy than a proof, which 248 might have been forged. However, attestations can be a burden on the 249 agent as the information can be sensitive, hence, the information 250 needs to be maintained so that only specific agents can access it. 251 Our stack does not constrain the choice of SSI system, but our 252 implementation is focused on the Boneh-Franklin [boneh2004secure] 253 2-DNF scheme ("Evaluating 2-DNF Formulas on Ciphertexts"). 255 Based upon the assumption that these identities are persistent and 256 secure, the new architecture (or Fabric) is designed to use Peer-to- 257 Peer communication to increase the transaction throughput. This 258 communication is based on the new networking overlay: IPv8, which 259 handles peer discovery, making connections with them across NAT boxes 260 and peer-to-peer cryptographically signed messaging. As IPv8 is 261 transport and application agnostic, it can run over any transport 262 protocol: it does not depend on IP and may run on top of NDN, XIA, 263 and other new Internet architectures. 265 To ensure that the blockchain is always in a valid state, a new 266 horizontal scaling consensus protocol is proposed: CHECO. CHECO is 267 specifically designed to counter the vulnerabilities that a 268 distributed, permissionless, multi-chain architecture will have to 269 cope with (although this also creates innate vulnerabilities to other 270 kinds of attacks). By creating an indication of the state of 271 validity for each agent, the responsibility of verification lies with 272 the agent itself. A malicious agent in an invalid state can easily 273 be detected, and should be avoided for interactions. 275 We do not constrain or limit the applications utilising this 276 blockchain, as each transaction block can contain information of 277 arbitrary content and length. Currently, there is a basic 278 decentralised market implemented. More specialised markets have to 279 also be implemented and emulated such as an open Taxi service market 280 and a mortgage investment market. Multiple applications can be used 281 at the same time, next to the decentralised market, for instance: it 282 could be used for byte accounting in an ad-hoc Manet 283 [jethanandani2017accounting]. 285 +--------------------------+ 286 | | 287 | | 288 | | 289 +--------------------------+ 290 | | 291 | CHECO | 292 | | 293 +--------------------------+ 294 | | 295 | Trustchain Fabric | 296 | | 297 +--------------------------+ 298 | | 299 | IPv8 | 300 | | 301 +--------------------------+ 302 | | 303 | Self-Souvereign Identity | 304 | | 305 +--------------------------+ 307 Figure 1 309 3. Trustchain Fabric: internal data structure 311 Trustchain is designed to be a non-blocking format for agents that 312 supports simultaneous interactions with other agents. Non-blocking 313 is a requirement rooted in the immutability of the chain and the 314 strict ordering of the blocks. To support this, the blocks are 315 designed to be dependent on signing by all participating agents, and 316 will be called TxBlocks henceforth, as is described in this section, 317 along with the macro data structure in which these blocks are used. 319 3.1. Architecture 321 In contrast to traditional blockchains, in Trustchain every agent in 322 the network has its own genesis node, in essence creating a personal 323 blockchain for each agent. Each interaction creates a new 324 transaction block, which is based on the last block of the two (or 325 more) concerned parties. This does not only influence the block- 326 creation speed, but also the amount of effort needed to verify a 327 chain. Along with some other security properties, this is one of the 328 implicit capabilities of this protocol. 330 By removing the proof-of-work mechanism needed for classic blockchain 331 implementations, Trustchain yields inherent horizontal scalability. 333 However the cost of scalability is that each application requires a 334 mechanism to guard against transaction spam and abuse. Trustchain is 335 based on the assumption that both parties agree on the transaction 336 before signing it, making tampering inherently easy to detect. One 337 of the aspects that supports this is the fact that Trustchain is 338 organised as a set of temporally ordered, intertwining chains, which 339 form a Directed Acyclic Graph (DAG). This is called a "bottom-up 340 consensus model", giving the participants the responsibility to 341 verify the correctness of the transaction instead of a central 342 (sometimes randomly chosen) elected leadership. 344 Trustchain depends on signatures from all participants in a 345 transaction, creating an n-to-n node. This system is extendable, as 346 mentioned before, by extending the transaction description to provide 347 specific properties. Each transaction is stored in a block, in 348 agreement-block format, each block has parts that are signed and 349 submitted by all participating parties, where the initial request is 350 called the block-proposal and a completely signed and validated block 351 is called an agreement-block (where a pair indicates the cooperation, 352 not the limitation to two participating parties). These are signed 353 and sequenced so that each sequence number is unique in its accessory 354 chain, as can be seen below in the general structure diagram. 356 +---------+--+---------+ 357 | | 358 | Transaction A with D | 359 | | 360 | | 361 +----------------------+ 362 | sequence number A: 3 | 363 +----------------------+ 364 | signed by A | 365 +----------------------+ 366 | sequence number D: 49| 367 +----------------------+ 368 | signed by D | 369 +---------+--+---------+ 370 | | 371 | +----------------------+ 372 | | | 373 +---------+--+---------+ +---------+--+---------+ 374 | | | | 375 | Transaction A with C | | Transaction D with B | 376 | | | | 377 | | | | 378 +----------------------+ +----------------------+ 379 | sequence number A: 2 | | sequence number D: 48| 380 +----------------------+ +----------------------+ 381 | signed by A | | signed by D | 382 +----------------------+ +----------------------+ 383 | sequence number C: 4 | | sequence number B: 12| 384 +----------------------+ +----------------------+ 385 | signed by C | | signed by B | 386 +---------+--+---------+ +---------+--+---------+ 387 | | | 388 | +----------------------+ 389 | | 390 +---------+--+---------+ 391 | | 392 | Transaction A with B | 393 | | 394 | | 395 +----------------------+ 396 | sequence number A: 1 | 397 +----------------------+ 398 | signed by A | 399 +----------------------+ 400 | sequence number B: 11| 401 +----------------------+ 402 | signed by B | 403 +---------+--+---------+ 405 Figure 2 407 3.2. TxBlock specification 409 Using the proposal-block and agreement-block formats means singing 410 the blocks on the current views of the respective parties: the 411 requester and the responder(s). Each party signs and fills the block 412 with the information that it has at that specific point in time. The 413 requester fills the structure with its own previous hash and its own 414 part of the transaction data, signs it and sends it to the 415 responder(s), which in turn construct the other sections of the 416 block, if it agrees with the content before sending it back. This 417 nullifies any ordering and asynchronicity issues, since the requester 418 constructs the block with the information that it has, and keeps it 419 in memory while it waits on the responder to send the finished block 420 back. 422 +--------+----------------------------+--------------+--------------+ 423 | Number | Description | Type | Size (bytes) | 424 +--------+----------------------------+--------------+--------------+ 425 | 1 | Requester public key | Char array | 74 | 426 | 2 | Requester sequence number | Unsigned int | 4 | 427 | 3 | Responder public key | Char array | 74 | 428 | 4 | Responder sequence number | Unsigned int | 4 | 429 | 5 | Requester previous hash | Char array | 32 | 430 | 6 | Signature | Char array | 64 | 431 | 7 | Transaction block size (n) | Unsigned int | 4 | 432 | 8 | Transaction block | Char array | n | 433 | | *Total:* | | 256 + n | 434 +--------+----------------------------+--------------+--------------+ 436 Table 1: TxBlock fields description 438 3.3. Asynchronicity 440 Because there is the need to communicate between the requester and 441 responder(s), there will be a delay which may be significant. To 442 have a high level of asynchronicity and enable multiple peers 443 interacting simultaneously, extending the chain should be possible 444 while waiting for a response. In order to do this, the block refers 445 to the previous block using the hash of the requester's part, since 446 this is the only stable reference at that point. The other hash 447 reference (the "previous hash responder") can then either be the 448 "hash requester" or "hash responder" part of the head-block of the 449 responder chain. Which one is used depends on whether the responder 450 was the requester or responder in its previous interaction. This 451 mechanic is also used for the "previous hash requester" field, but 452 this reference is known when the block is created. In effect, this 453 results to theoretically unlimited horizontal scalability: the more 454 actors are active on the chain, the more throughput can be achieved. 455 Though this is in fact limited by the memory speed, or database 456 slowdown when the chain grows. 458 One of the drawbacks of this mechanic is when the responder does not 459 sign and respond, whether because it will/can not. In such cases, 460 there will be an orphan block. While this is not a vulnerability in 461 itself, it might be the starting point of a certain type of attack 462 (the other "normal" types of attacks used for blockchains can be 463 mitigated, at least to a certain level, as is described in 464 resistances (Section 5).). The adversary might let someone initiate 465 a transaction, i.e. a block creation, after which it will create an 466 orphan. Doing this multiple times in a short time span will force 467 the requester to use a considerable amount of processing power and 468 memory, all the while injecting orphan blocks into its chain. As 469 mentioned before, this is not a vulnerability in itself, but might be 470 a launchpad for a more elaborate attack. Although, one coping method 471 could be to split larger, more vulnerable transactions up into 472 multiple smaller transactions. This way, the consequences stay the 473 same for the malicious actor, but the losses are smaller. 475 3.4. CHECO: Consensus protocol and block format 477 The final part of the Trustchain Fabric is CHECO, a horizontally 478 scaling consensus protocol specifically designed for multi-chain 479 implementation and completely application agnostic. CHECO is based 480 on three separate protocols: A consensus protocol, a transaction 481 protocol and a validation protocol, as well as an extension of the 482 architecture by introducing a new type of block next to the TxBlock: 483 CpBlock. Every round a set of so-called facilitators is selected at 484 random, which collect the CP and TX blocks, to feed to the validation 485 protocol, after which, the results are broadcast before a new round 486 starts. 488 CHECO is designed to create an internal state ledger for each chain, 489 without having to rely on separate methods or instances. This is 490 achieved by introducing a new block: the Checkpoint block (CpBlock), 491 which contains a hash pointer to the previous block, along with a 492 hash of the consensus result, round and sequence number and, lastly, 493 a signature. The consensus result is defined as a tuple containing 494 the validity states of the blocks agreed on by the facilitators of 495 that round and the round number. If your chain is deemed valid, a 496 CpBlock is injected, thus validating the state of the chain. While 497 the content of the injected CpBlock differs from the TxBlock, these 498 blocks do not interfere with the transaction protocol, since they fit 499 in the architecture without modifying it. 501 Instead of requiring a proof-of-work (as seen in more conventional 502 blockchain implementations), CHECO is round based, creating a 503 consensus state every so often, thus enabling a fully asynchronous 504 and horizontally scaling protocol. These facilitators are chosen 505 randomly each round, and will collect the CpBlocks from all other 506 nodes since their last CpBlock. Validation is done using the 507 Asynchronous Common Subset (ACS) algorithm based on HoneyBadgerBFT 508 (Miller et al, 2016 [miller2016honey]), a byzantine consensus 509 algorithm. 511 4. IPv8: Overlay for identity, discovery and trust 513 To enable this new platform to function properly, a new method to 514 find, connect to and manage agents was needed. Additionally, new 515 models for identity verification, network discovery and inter-peer 516 trust were required to enable these agent methods. IPv8 is a network 517 stack, a set of protocols and models, that separates concerns and 518 enables applications (such as Trustchain) to use the needed methods 519 and protocols, without giving up interoperability and upgradeability. 520 On top of this interface lies the actual Trustchain overlay, which 521 uses the components and protocols of the IPv8 interface to create the 522 specific functionalities needed for Trustchain to function. 524 IPv8 is built by closely abiding to the Unix Philosophy of creating 525 small components that are easy to understand and test. This is 526 mainly why the complete networking system used in Tribler was re- 527 written as a generic networking interface, enabling modifications and 528 additions without losing any functionality. Although agents might 529 use different protocols based on their capabilities, IPv8 is a basic 530 layer over a multitude of networking components and subsystems, 531 creating a means to communicate with other agents regardless of 532 networking capabilities. An open source reference implementation 533 based on Python is available on Github, called py-ipv8. 534 Interoperable open implementations in Java and Kotlin are still only 535 partially functional. 537 4.1. Identity establishment and discovery 539 Identities are created, attested and distributed over the Trustchain 540 using IPv8 as the communication interface. These are all public and 541 self sovereign, leading to distribution when an agent creates a new 542 identity, and are organised using a Public Key Infrastructure (PKI). 543 This distribution is done to agents who have (or might have) an 544 interest in obtaining the identity of this agent, since they are in 545 the same cluster or due to other factors. Spreading information this 546 way is called Gossiping, since agents learn of new identities, and 547 spreading them among directly connected agents like a gossip would 548 spread. 550 Discovering identities is done based on Distributed Hash Tables 551 (DHT), somewhat similar to the Domain Name System (DNS) currently 552 used for the web, using Random-Walk and Live-Edge-Walk: discovery 553 protocols for DHTs, respectively based on making random DHT queries 554 in order to learn about a large number of identities quickly and 555 making pseudo-randomised queries about the agents with the highest 556 trust scores in the network. The use of random-walks enables DHTs to 557 converge much faster, whilst having a small load at the very 558 beginning. Furthermore, by traversing the live edges, Trustchain is 559 more spam and Sybil attack resistant. 561 4.2. Attestations and trust 563 The primary problem with identities and proofs is falsification, and, 564 thus, these need to be verified to prevent this. However, even 565 proofs can be forged, leading to the problem of needing trust in a 566 proving party, which can not be solved by having a more centralised 567 proving party. This is where attestations are used: a witness 568 reports that the identity in question is actually valid. This 569 requires some level of trust between the agents. Attestations are a 570 method to enable agents to validate interactive zero-knowledge proofs 571 (ZKPs) within a network of agents, a so-called web-of-trust 572 [azouvi2017secure], where the transitive property of trust is used to 573 prevent the need for every agent to verify an identity itself as is 574 noted in Section 2. 576 In this case, the probabilistic homomorphic asymmetrical encryption 577 scheme of Boneh-Franklin [boneh2004secure] is used to validate these 578 proofs, meaning that a form of randomness is used in the encryption, 579 and computations on the ciphertext result in a valid plaintext. 580 Using Boneh-Franklin leads to these ZKPs to be hardened against 581 chosen plaintext attacks (an attacker can encrypt the suspected 582 plaintext to see if the ciphertexts match) with the probabilistic 583 aspect. These attestations are tied to metadata, which can be 584 verified separately. The related identities are stored internally in 585 a database, and the aforementioned metadata attributes are gossiped 586 around the network using Trustchain. 588 4.2.1. Technical view of Attestations and Verifications 590 4.2.1.1. Attributes 592 Attributes are a generic term which can essentially refer to any 593 verifiable piece of information. For instance, an attribute may 594 define a peer's identity, the amount of cryptocurrency in one's 595 digital wallet, or perhaps, something as simple as one's previous 596 number of transactions. In the context of Trustchain, Attributes 597 mainly refer one's identity. 599 4.2.1.2. Attestations 601 In a truly distributed peer-to-peer system, where peers regularly 602 communicate and exchange information (hence they exchange attributes) 603 there is a need of verifying the veracity of attributes, without 604 relying on a well-known, well-trusted tertiary party / peer. 605 Attestations are a means which make this task possible. They allow 606 peers to verify the truthfulness of Attributes through a validation 607 process, using interactive zero-knowledge proofs. A system based on 608 Attestations is founded on the fact that, intrinsically, there exists 609 a degree of trust between the peers of a system. To this extent, 610 attestations are, generally speaking, a means through which peer C 611 vouches to peer B that A is indeed telling the truth. Unlike normal 612 centralized systems, where C is a well-known entity, in this case, C 613 may be any trustworthy fellow peer. This enforces the idea that 614 trust is transitive, hence there is no need for a trusted central 615 peer to exist, since one can rely on other peers to attest for the 616 veracity of Attributes. 618 4.2.1.2.1. The Attestation process 620 As its name suggests, the Attestation Process is a mechanism through 621 which a peer (the Attestee) requests the attestation of one of its 622 Attributes from another fellow peer (the Attester). The process is 623 initiated by the Attestee. If the process is successful, and the 624 Attribute has indeed been attested, the Attester produces an 625 attestation as proof, which is returned to the Attestee. This should 626 complete the process. In the sections that follow, the messages 627 exchanged during the aforementioned process are detailed. 628 Additionally, a more detailed, high-level description of the peer 629 interaction is also presented. 631 4.2.1.2.2. Message types 633 The following sections present the different types of messages that 634 are exchanged between the Attestee and Attester peers during the 635 attestation process, namely the Attestation Request message and the 636 Attestation Response message. A section on the prefix field, which 637 is employed in all messages used towards peer communication, is also 638 presented in what follows. 640 4.2.1.2.2.1. Preamble field 642 The preamble field is present in all the messages employed in 643 Trustchain towards peer communication. Consequently, it plays an 644 important role in inter-peer communication. Figure 3 presents its 645 generic structure. 647 +-------------+-------------+---------------------+---------------+ 648 | 0 (1B) | ver_nr (1B) | peer_key_hash (20B) | msg_type (1B) | 649 +-------------+-------------+---------------------+---------------+ 651 Figure 3: The structure of the Preamble / Prefix field. The size of 652 each field is specified in parentheses in Bytes. 654 A description of the Preamble field's elements is presented in 655 Table 2. 657 +---------------+--------+------------------------------------------+ 658 | FIELD | OCTETS | DESCRIPTION | 659 +---------------+--------+------------------------------------------+ 660 | 0 | 1 | The initial byte of any message is 0 | 661 | | | (0x00). | 662 | | | | 663 | ver_nr | 1 | The current implementation version. | 664 | | | | 665 | peer_key_hash | 20 | A hash of the key of the message | 666 | | | sender's master peer. | 667 | | | | 668 | msg_type | 1 | Indicates the nature of the message. For | 669 | | | instance, when 'msg_type = 5', the | 670 | | | message will be an ATTREQ. Similarly, | 671 | | | when 'msg_type = 2', the message is | 672 | | | either ATTRESP or VFRESP. Other types | 673 | | | are also available. | 674 +---------------+--------+------------------------------------------+ 676 Table 2: Description of fields in the Preamble / Prefix field 678 4.2.1.2.2.2. The Attestation Request Message 680 The Attestation Request message (ATTREQ), is forwarded by the 681 Attestee towards the Attester, in order to indicate the Attestee's 682 desire to have one of its attributes attested by the Attester. The 683 structure of the ATTREQ message is presented in Figure 4. 685 +--------+---------------------------------+----------------------+----------------+ 686 | Number | Description | Type | Size (bytes) | 687 +--------+---------------------------------+----------------------+----------------+ 688 | 0 | Preamble / Prefix | Char Array | 23 | 689 +--------+---------------------------------+----------------------+----------------+ 690 | 1 | Public Key in Binary Format | Unsigned Short Array | n | 691 +--------+---------------------------------+----------------------+----------------+ 692 | 2 | Global Time (Lamport Timestamp) | Unsigned Long Long | 8 | 693 +--------+---------------------------------+----------------------+----------------+ 694 | 3 | Attestation Metadata | Char Array (Raw) | 33 + m | 695 +--------+---------------------------------+----------------------+----------------+ 696 | | *Total:* | | 64 + n + m | 697 +--------+---------------------------------+----------------------+----------------+ 699 Figure 4: The structure of an ATTREQ message. 701 A description of the ATTREQ's fields is presented in Table 3. 703 +-------------+--------+----------+---------------------------------+ 704 | FIELD | OCTETS | TYPE | DESCRIPTION | 705 +-------------+--------+----------+---------------------------------+ 706 | Preamble / | 23 | Char | Generic message preamble, as | 707 | Prefix | | Array | presented in Section | 708 | | | | 4.2.1.2.2.1, with msg_type = 5. | 709 | | | | | 710 | Public Key | n | Unsigned | The Attestee's public key in | 711 | | | Short | binary format. n = | 712 | | | Array | bin_public_key_char_length * 2, | 713 | | | | since each Unsigned Short | 714 | | | | element is 2 Bytes in size. | 715 | | | | | 716 | Global Time | 8 | Unsigned | A Lamport Timestamp (Scalar | 717 | | | Long | Clock) associated with the | 718 | | | Long | message. | 719 | | | | | 720 | Attestation | 33 + m | Char | Holds a string having the | 721 | Metadata | | Array | pattern: '{"attribute": | 722 | | | (Raw) | "attr_name", "public_key": | 723 | | | | pub_key}' (without the ' | 724 | | | | characters). The attr_name and | 725 | | | | pub_key tokens are replaced by | 726 | | | | actual values. The minimal size | 727 | | | | of the field is 33 Bytes (if | 728 | | | | both tokens would be omitted). | 729 | | | | m is the cumulative string | 730 | | | | length of the values in the | 731 | | | | attr_name and pub_key tokens. | 732 +-------------+--------+----------+---------------------------------+ 734 Table 3: Description of the fields in an ATTREQ message 736 4.2.1.2.2.3. The Attestation Response Message 738 The Attestation Response message (ATTRESP), is forwarded by the 739 Attester towards the Attestee, in order to send the previously 740 requested attestation to the Attestee. It should be noted that 741 ATTRESP messages are sent only in case the attestation is successful. 742 If the attestation fails, no such messages are sent. Furthermore, 743 the attestation may be of arbitrary length, hence, it is impractical 744 to send it entirely at once. Consequently, the attestation is broken 745 up into smaller chunks (at most 800 Bytes) and each chunk is packed 746 as part of an ATTRESP message. The structure of an ATTRESP message 747 is presented in Figure 5 749 +--------+---------------------------------+----------------------+--------------+ 750 | Number | Description | Type | Size (Bytes) | 751 +--------+---------------------------------+----------------------+--------------+ 752 | 0 | Preamble / Prefix | Char Array | 23 | 753 +--------+---------------------------------+----------------------+--------------+ 754 | 1 | Public Key in Binary Format | Unsigned Short Array | n | 755 +--------+---------------------------------+----------------------+--------------+ 756 | 2 | Global Time (Lamport Timestamp) | Unsigned Long Long | 8 | 757 +--------+---------------------------------+----------------------+--------------+ 758 | 3 | Attestation Blob Hash | Char Array | 20 | 759 +--------+---------------------------------+----------------------+--------------+ 760 | 4 | Sequence Number | Unsigned Short | 2 | 761 +--------+---------------------------------+----------------------+--------------+ 762 | 5 | Attestation Blob Chunk | Char Array (Raw) | 800 | 763 +--------+---------------------------------+----------------------+--------------+ 764 | | *Total:* | | 853 + n | 765 +--------+---------------------------------+----------------------+--------------+ 767 Figure 5: The structure of an ATTRESP message. 769 A description of the ATTRESP's fields is presented in Table 4. 771 +-------------+--------+----------+---------------------------------+ 772 | FIELD | OCTETS | TYPE | DESCRIPTION | 773 +-------------+--------+----------+---------------------------------+ 774 | Preamble / | 23 | Char | Generic message preamble, as | 775 | Prefix | | Array | presented in Section | 776 | | | | 4.2.1.2.2.1, with msg_type = 2. | 777 | | | | | 778 | Public Key | n | Unsigned | The Attester's public key in | 779 | | | Short | binary format. n = | 780 | | | Array | bin_public_key_char_length * 2, | 781 | | | | since each Unsigned Short | 782 | | | | element is 2 Bytes in size. | 783 | | | | | 784 | Global Time | 8 | Unsigned | A Lamport Timestamp (Scalar | 785 | | | Long | Clock) associated with the | 786 | | | Long | message. | 787 | | | | | 788 | Attestation | 20 | Char | A hash of the entire | 789 | Blob Hash | | Array | attestation blob. This can be | 790 | | | | used to check the integrity and | 791 | | | | completeness of the | 792 | | | | reconstructed blob on the | 793 | | | | Attestee's side. | 794 | | | | | 795 | Sequence | 2 | Unsigned | The message's sequence number | 796 | Number | | Short | in the sequence of ATTRESP | 797 | | | | messages sent for the | 798 | | | | particular attestation. | 799 | | | | | 800 | Attestation | 800 | Char | A chunk of the attestation | 801 | Blob Chunk | | Array | blob. | 802 | | | (Raw) | | 803 +-------------+--------+----------+---------------------------------+ 805 Table 4: Description of the fields in an ATTRESP message 807 4.2.1.2.3. Attestee-Attester Interaction - Attestation Process 809 The following summary refers to the interaction between Attestee and 810 Attester during the attestation process. The timeline diagram in 811 Figure 6 shows the timing relationships in such an interaction. 812 Table 5 gives a brief reminder of the messages employed in the 813 attestation process. 815 The Attestee forwards an ATTREQ message to the Attester, with the 816 aim of requesting attestation for an Attribute, as indicated in 817 the ATTREQ message. 819 After receiving the ATTREQ, and successfully completing the 820 attestation process, the Attester responds with a series of 821 ATTRESP messages. The message sequence may be of arbitrary 822 length. At a high-level, the sequence of ATTRESP message returns 823 the new attestation, hence, each message will contain a chunk of 824 the attestation blob. Additionally, each ATTRESP message also 825 contains a hash of the entire attestation blob, a message sequence 826 number, and additional message fields. If the attestation is 827 unsuccessful, no ATTRESP messages are returned. 829 The Attestee receives the sequence of ATTREQ messages from the 830 Attester, and puts them together. The Attestee will know it has 831 received the entire attestation blob, when the hash of the 832 attestation blob, present in the ATTREQ messages, matches a 833 locally computed hash of the reconstructed attestation blob. 835 Attestee Attester 837 v v 838 | | 839 | ATTREQ | 840 | +------------------> | 841 | | 842 | | 843 | Attest 844 | | 845 | | 846 | ATTRESP #1 | 847 | <------------------+ | 848 | . | 849 | . | 850 | . | 851 | ATTRESP #N | 852 | <------------------+ | 853 | | 854 | | 855 Attestation | 856 Complete | 857 | | 858 | | 859 v v 861 Figure 6: Timeline diagram of the messages exchanged between Attestee 862 and Attester during the attestation process. 864 +---------+---------------------------------------------------------+ 865 | MESSAGE | USE | 866 +---------+---------------------------------------------------------+ 867 | ATTREQ | Attestee message to Attester requiring the attestation | 868 | | of an indicated Attribute. | 869 | | | 870 | ATTRESP | Attester message to Attestee provided that attestation | 871 | | was successful. Each ATTRESP carries a part of the | 872 | | successful attestation blob. | 873 +---------+---------------------------------------------------------+ 875 Table 5: Attestation process message summary 877 4.2.1.3. Attestation Verification 879 Whilst Attestations are employed towards ensuring that peers are 880 truthful in regards to some of their Attributes, the Attestation 881 Verification request is employed towards ensuring that the 882 Attestations themselves are valid. The employed mechanism does not 883 stray far away from that which is employed in the case of 884 Attestations. In fact, they are structurally similar: during the 885 process of an Attestation Verification a peer C vouches to peer B 886 that A is indeed telling the truth regarding a supplied Attestation. 887 Once more, this enforces the idea that trust is transitive, hence 888 there is no need for a trusted central peer to exist, since one can 889 rely on other peers to attest for the veracity of an Attestation. 891 4.2.1.3.1. Attestation Verification Process 893 The Verification process defines an interaction between two peers, 894 the Requester peer, and the Verifier peer, wherein the Requester 895 demands that the Verifier verifies one of its attestations (that is, 896 an attestation of the Verifier). Intuitively, the Requester peer 897 initiates the process. If the verification is successful, the 898 Verifier should return the verified attestation. This should 899 complete the process. In the sections that follow, the messages 900 exchanged during the aforementioned process are detailed. 901 Additionally, a more detailed, high-level description of the peer 902 interaction is also presented. 904 4.2.1.3.1.1. Attestation Verification message types 906 The following sections present the different types of messages that 907 are exchanged between the Requester and Verifier peers during the 908 verification process, namely, the Verification Request message and 909 the Verification Response message. Incidentally, the Verification 910 Response message is identical to the Attestation Response message, 911 which was presented in Section 4.2.1.2.2.3. 913 4.2.1.3.1.1.1. The Verification Request Message 915 The Verification Request message (VFREQ), is forwarded by the 916 Requester towards the Verifier, so as to demand that the Verifier 917 verifies one of its attestations, and then sends it back to the 918 Requester. The structure of the VFREQ message is presented in 919 Figure 7. 921 +--------+-----------------------------------+----------------------+--------------+ 922 | Number | Description | Type | Size (Bytes) | 923 +--------+-----------------------------------+----------------------+--------------+ 924 | 0 | Preamble / Prefix | Char Array | 23 | 925 +--------+-----------------------------------+----------------------+--------------+ 926 | 1 | Public Key in Binary Format | Unsigned Short Array | n | 927 +--------+-----------------------------------+----------------------+--------------+ 928 | 2 | Global Time (Lamport Timestamp) | Unsigned Long Long | 8 | 929 +--------+-----------------------------------+----------------------+--------------+ 930 | 3 | Hash of the Verified Attestation | Char Array | 20 | 931 +--------+-----------------------------------+----------------------+--------------+ 932 | | *Total:* | | 51 + n | 933 +--------+-----------------------------------+----------------------+--------------+ 935 Figure 7: The structure of an VFREQ message. 937 A description of the VFREQ's fields is presented in Table 6. 939 +-------------+--------+----------+---------------------------------+ 940 | FIELD | OCTETS | TYPE | DESCRIPTION | 941 +-------------+--------+----------+---------------------------------+ 942 | Preamble / | 23 | Char | Generic message preamble, as | 943 | Prefix | | Array | presented in Section | 944 | | | | 4.2.1.2.2.1, with msg_type = 1. | 945 | | | | | 946 | Public Key | n | Unsigned | The Requester's public key in | 947 | | | Short | binary format. n = | 948 | | | Array | bin_public_key_char_length * 2, | 949 | | | | since each Unsigned Short | 950 | | | | element is 2 Bytes in size. | 951 | | | | | 952 | Global Time | 8 | Unsigned | A Lamport Timestamp (Scalar | 953 | | | Long | Clock) associated with the | 954 | | | Long | message. | 955 | | | | | 956 | Verified | 20 | Char | A hash of the attestation which | 957 | Attestation | | Array | needs to be verified. | 958 | Hash | | | | 959 +-------------+--------+----------+---------------------------------+ 961 Table 6: Description of the fields in an VFREQ message 963 4.2.1.3.1.1.2. The Verification Response Message 965 The Verification Response message (VFRESP) is identical in structure 966 to the Attestation Response message (ATTRESP), since both return an 967 attestation. For the VFRESP's structure please see section 968 Section 4.2.1.2.2.3. The two messages differ only slightly in terms 969 of semantics, since one is returned as a response to a successful 970 attestation request, thus returning a new attestation, while the 971 other (the verification) is returned upon a successful verification 972 request, thus returning the recently verified attestation. A 973 sequence of VFRESP messages should only be returned when the 974 verification was successful, i.e. the attestation could be verified. 975 As was the case in the ATTRESP messages, the verified attestation may 976 be of arbitrary length, hence, it is impractical to send it entirely 977 at once. Consequently, the attestation is broken up into smaller 978 chunks (at most 800 Bytes) and each chunk is packed as part of a 979 VFRESP message. 981 Since the semantics of some of the fields in the VFRESP messages 982 slightly differ than those in the ATTRESP messages, a description of 983 the VFRESP's fields is presented in Table 7. 985 +-------------+--------+----------+---------------------------------+ 986 | FIELD | OCTETS | TYPE | DESCRIPTION | 987 +-------------+--------+----------+---------------------------------+ 988 | Preamble / | 23 | Char | Generic message preamble, as | 989 | Prefix | | Array | presented in Section | 990 | | | | 4.2.1.2.2.1, with msg_type = 2. | 991 | | | | | 992 | Public Key | n | Unsigned | The Verifier's public key in | 993 | | | Short | binary format. n = | 994 | | | Array | bin_public_key_char_length * 2, | 995 | | | | since each Unsigned Short | 996 | | | | element is 2 Bytes in size. | 997 | | | | | 998 | Global Time | 8 | Unsigned | A Lamport Timestamp (Scalar | 999 | | | Long | Clock) associated with the | 1000 | | | Long | message. | 1001 | | | | | 1002 | Attestation | 20 | Char | A hash of the entire | 1003 | Blob Hash | | Array | attestation blob. This can be | 1004 | | | | used to check the integrity and | 1005 | | | | completeness of the | 1006 | | | | reconstructed blob on the | 1007 | | | | Requester's side. | 1008 | | | | | 1009 | Sequence | 2 | Unsigned | The message's sequence number | 1010 | Number | | Short | in the sequence of VFRESP | 1011 | | | | messages sent for the | 1012 | | | | verification. | 1013 | | | | | 1014 | Attestation | 800 | Char | A chunk of the attestation | 1015 | Blob Chunk | | Array | blob. | 1016 | | | (Raw) | | 1017 +-------------+--------+----------+---------------------------------+ 1019 Table 7: Description of the fields in an VFRESP message 1021 4.2.1.3.2. Requester-Verifier Interaction - Verification Process 1023 The following summary refers to the interaction between Requester and 1024 Verifier during the verification process. The timeline diagram in 1025 Figure 8 shows the timing relationships in such an interaction. 1026 Table 8 gives a brief reminder of the messages employed in the 1027 verification process. 1029 The Requester forwards a VFREQ message to the Verifier, with the 1030 aim of requesting the verification of an Attribute's attestation, 1031 as indicated by the attestation hash in the VFREQ message. 1033 After receiving the VFREQ, and successfully completing the 1034 verification process, the Verifier responds with a series of 1035 VFRESP messages. The message sequence may be of arbitrary length. 1036 At a high-level, the sequence of VFRESP message returns the 1037 recently verified attestation, hence, each message will contain a 1038 chunk of the attestation blob. Additionally, each VFRESP message 1039 also contains a hash of the entire attestation blob, a message 1040 sequence number, and additional message fields. If the 1041 verification is unsuccessful, no VFRESP messages are returned. 1043 The Requester receives the sequence VFRESP messages from the 1044 Verifier, and puts them together. The Requester will know it has 1045 received the entire attestation blob, when the hash of the 1046 attestation blob present in the VFRESP messages matches a locally 1047 computed hash of the reconstructed attestation blob. 1049 Requester Verifier 1051 v v 1052 | | 1053 | VFREQ | 1054 | +------------------> | 1055 | | 1056 | | 1057 | Verify 1058 | | 1059 | | 1060 | VFRESP #1 | 1061 | <------------------+ | 1062 | . | 1063 | . | 1064 | . | 1065 | VFRESP #N | 1066 | <------------------+ | 1067 | | 1068 | | 1069 Verification | 1070 Complete | 1071 | | 1072 | | 1073 v v 1075 Figure 8: Timeline diagram of the messages exchanged between 1076 Requester and Verifier during the verification process. 1078 +---------+---------------------------------------------------------+ 1079 | MESSAGE | USE | 1080 +---------+---------------------------------------------------------+ 1081 | VFREQ | Requester to Verifier requiring the verification of an | 1082 | | attestation, as indicated in the VFREQ message. | 1083 | | | 1084 | VFRESP | Verifier to Requester provided that verification was | 1085 | | successful. Each VFRESP carries a part of the recently | 1086 | | verified attestation. | 1087 +---------+---------------------------------------------------------+ 1089 Table 8: Verification process message summary 1091 4.3. Peer-to-peer cryptographically signed messaging 1093 Most messages that are sent between peers are encrypted, the keys are 1094 retrieved from either the PKI, and verified based on the key 1095 attestations, or from the internal database after verification has 1096 already been done. Encryption is done using the ECDSA encryption 1097 scheme [johnson2001elliptic], which is an Elliptic Curve based 1098 cryptography system. This enables IPv8 to send messages effectively 1099 to a multitude of agents when (at the least) their identities are 1100 known, preferably also attested for. Having such a low bar to 1101 encrypt messages discourages the use of unencrypted communication 1102 channels, making interactions secure almost as early as the 1103 handshake, since the first message sent to any agent can be already 1104 encrypted with its respective key (which is retrieved from the 1105 database, other agents or the initial bootstrapping list). 1107 4.4. NAT traversal 1109 Network Address Translation (NAT) is omnipresent in the modern 1110 Internet, mostly due to networks being separated and the limited 1111 amount of global IP addresses available. Most consumer devices are 1112 behind a number of layers of NAT, but data center nodes can be behind 1113 NAT for security or virtualisation reasons. Containerised 1114 deployments are making things worse, as every peer based 1115 communication scheme must have a way to traverse NATs, otherwise 1116 operations will be affected. Even nodes meant to run with real IP 1117 addresses must implement NAT traversal techniques, as they may need 1118 to establish connections to peers behind NAT. Message puncturing 1119 based on UDP is key to this overlay. It conducts a random network 1120 walk to preserve connectivity under churn. Participants help each 1121 other to puncture the NAT infrastructure. Each participant will 1122 periodically introduce and connect some of its neighbors. When their 1123 random neighbors do not yet know each other, a new participant is 1124 discovered. Carefully timed concurrent UDP messages are used to 1125 traverse carrier-grade NAT infrastructures. Implementation, 1126 deployment and measurements of smartphone users has shown that it is 1127 possible to build a healthy overlay without servers, even if nearly 1128 100 percent of users are behind a NAT (Android-to-android overlay 1129 [TUDelft2018trustchain]). 1131 5. Attack resistances 1133 For blockchain implementations, attack resistance is an important 1134 requirement, especially with horizontal scalability. Therefore, 1135 Trustchain will have to cope with the same difficulties and attacks 1136 that other blockchain implementations have to, but due to the novel 1137 structure it introduces, these threats can be countered. With this 1138 novel structure, validation, uncertainty, and tamper proofing can be 1139 handled in a more intuitive manner while throughput does not need to 1140 suffer. 1142 5.1. Sybil attacks 1144 One of the most difficult attacks to repel, for a blockchain 1145 implementation, is the Sybil attack, where many agents are injected 1146 into the chain (and authenticity cannot easily be verified) to 1147 subvert a large portion of the system's voting power or trust (see 1148 section 3.3). Usually peer verification is used to protect against 1149 this kind of attacks (for instance: proof-of-work), usually resulting 1150 in slow systems. But when the influence of the attacker is large 1151 enough, even these methods will not be able to stop such an attack. 1153 Trustchain deals with this problem by having an inherently different 1154 structure, where each peer has its own origin. On top of that, 1155 transaction injection can only be done with two valid signatures, 1156 meaning a Sybil attacker can only create trust with itself. This 1157 results in a network of disconnected agents that have no relation 1158 outside of their own cluster, which can easily be identified. Even 1159 when the Sybils acquire some degree of trust from outside of their 1160 cluster, by using accounting mechanisms, the profit from such an 1161 attack can only be weakly beneficial with bounded profit (using 1162 Netflow, not discussed in this paper) (Otte et al, 2017 1163 [otte2017trustchain]). 1165 5.2. Double spending attack 1167 Using control over the blockchain to create a fork and creating two 1168 different transaction branches is called double spending. This kind 1169 of attack can be applied with relative ease to single chain 1170 implementations of the blockchain by injecting two conflicting 1171 transactions at the same time. Trustchain deals with this kind of 1172 attack by having the chain verified with each CHECO round, during 1173 which the hidden transaction can be easily found. By broadcasting 1174 both blocks as a proof-of-fraud the malicious agent will have 1175 decreased trust and can be blacklisted or refused service. 1177 5.3. Replay attack 1179 Using the transaction signature of the counterpart, a malicious agent 1180 can try to replay a transaction on the blockchain, which results in 1181 increased trust or may be used to gain credits. CHECO and the novel 1182 structure make it trivial to find the conflicting blocks when 1183 verifying the counterparty's chain. The two blocks with the same 1184 outgoing pointer together make the proof-of-fraud, which then can 1185 then be used to decrease the trust in the malicious party and can be 1186 blacklisted or refused service. 1188 5.4. Whitewashing attack 1190 Abusing the permissionless structure of Trustchain to create 1191 additional identities at any given point can negate the effect of 1192 having trust, so this kind of attack differs from a Sybil attack. 1193 When an agent suffers from reputation loss, it can simply discard its 1194 current identity and take on a new one. Since refusing service to 1195 agents with little trust will affect usability and willingness to 1196 join the network, an adequate solution can be prioritising 1197 strategies. One method for implementing this is described in the 1198 paper discussing Netflow (not discussed in this paper) (Otte et al, 1199 2017 [otte2017trustchain]). 1201 5.5. Spam attack 1203 Since the TxBlocks have dynamic size, spam (in the sense of useless 1204 data in the transaction field) can be used to clog an agent's network 1205 or database with excessively large messages, slowing down its 1206 operations or bringing it to a complete halt due to memory/network 1207 being full. This kind of attack can be coped with by having a 1208 throttle per connection to keep some bandwidth available and a limit 1209 on the size of the message. If large messages are to be expected, a 1210 file based buffer will enable large message transfer without 1211 exceeding the memory capacity. 1213 Another type of spam can be identified as a collection of useless 1214 messages, clogging the network and database with large amounts of 1215 empty messages, which is possible since transactions do not require 1216 an agent to pay transaction costs (as BitCoin does). Though this is 1217 easily countered by not accepting those messages, leading to the 1218 malicious agent having a lot of orphan blocks. 1220 5.6. DDoS 1222 When massive quantities of useless or empty messages are sent over a 1223 network, it might get congested, leading to dropped operations, 1224 network congestion, unreachability of agents, or, in the most extreme 1225 cases, even to system failure due to overload. Due to the 1226 distributed, peer based communications architecture, this is not 1227 feasible without flooding the network of the malicious agent itself, 1228 as it has to send messages to each target individually. 1230 6. Acknowledgements 1232 We very much thank the European Union for providing us the required 1233 funding for this work. Through EU FP6 and FP7 funding instruments we 1234 have been developing and deploying our own distributed ledger fabric 1235 since August 2007. An estimated 3.4 million Euro has been granted 1236 through these specific projects and leading directly to this work 1237 ([P2P-Fusion], [P2P-Next],[QLectives]). 1239 We thank master student Stijn for his help with writing of this 1240 draft. 1242 7. IANA Considerations 1244 This memo includes no request to IANA. 1246 All drafts are required to have an IANA considerations section (see 1247 Guidelines for Writing an IANA Considerations Section in RFCs 1248 [RFC5226] for a guide). If the draft does not require IANA to do 1249 anything, the section contains an explicit statement that this is the 1250 case (as above). If there are no requirements for IANA, the section 1251 will be removed during conversion into an RFC by the RFC Editor. 1253 8. Security Considerations 1255 From a security perspective, the usage of novel structures such as 1256 Trustchain might lead to new kinds of attacks. We consider this risk 1257 of less importance for a private and consortium network, where all 1258 participants are known to the operator and authentication mechanisms 1259 are used to restrict access to the network. 1261 For the public blockchain networks, the usage of Trustchain might 1262 lead to new kinds of attacks. For instance, an attacker might be 1263 able to pollute the chain with refusal to sign attacks to decrease 1264 trust. The scope of such attacks and security violations needs to be 1265 investigated and is not part of this draft. 1267 9. References 1269 [abrahamself] 1270 Abraham, A., "Self-Sovereign Identity", 2017, 1271 . 1274 [apostle2017uber] 1275 Apostle, J., "The Uber data breach has implications for us 1276 all.", 2014, . 1279 [atzori2016blockchain] 1280 Atzori, M., "Blockchain-based architectures for the 1281 internet of things: a survey", 2016, 1282 . 1285 [azouvi2017secure] 1286 Azouvi, S., Al-Bassam, M., and S. Meiklejohn, "Who am i? 1287 Secure identity registration on distributed ledgers", 1288 2017, . 1291 [boneh2004secure] 1292 Boneh, D. and X. Boyen, "Secure identity based encryption 1293 without random oracles", 2004, 1294 . 1297 [brown2017introducing] 1298 Brown, R., "Introducing R3 Corda: A Distributed Ledger for 1299 Financial Services", 2016, 1300 . 1303 [cong2017blockchain] 1304 Cong, K., Ren, Z., and J. pouwelse, "A Blockchain 1305 Consensus Protocol With Horizontal Scalability", 2017, 1306 . 1309 [FIPS180-4] 1310 Gallagher, P., "Secure hash standard (shs)", 2008, 1311 . 1314 [jethanandani2017accounting] 1315 Jethanandani, M., "Accounting in NETCONF and RESTCONF", 1316 2017, . 1319 [johnson2001elliptic] 1320 Johnson, D., Menezes, A., and S. Vanstone, "The elliptic 1321 curve digital signature algorithm (ECDSA)", 2001, 1322 . 1324 [kokkola2011payment] 1325 Kokkola, T., "The payment system: Payments, securities and 1326 derivatives, and the role of the Eurosystem.", 2011, 1327 . 1330 [mcmillan2014inside] 1331 McMillan, R., "The inside story of Mt. Gox, Bitcoin's $460 1332 million disaster.", 2014, 1333 . 1335 [miller2016honey] 1336 Miller, A., Xia, Y., Croman, K., Shi, E., and D. Song, 1337 "The honey badger of BFT protocols", 2016, 1338 . 1340 [nakamoto2008bitcoin] 1341 Nakamoto, S., "Bitcoin: A peer-to-peer electronic cash 1342 system", 2008, . 1345 [otte2017trustchain] 1346 Otte, P., de Vos, M., and J. Pouwelse, "Trustchain: A 1347 Sybil-resistant scalable blockchain", 2017, 1348 . 1351 [P2P-Fusion] 1352 "P2P-Fusion project", 2018, 1353 . 1355 [P2P-Next] 1356 "Next Generation Peer-to-Peer Content Delivery Platform", 1357 2018, . 1359 [pouwelse2017trustlaws] 1360 Pouwelse, J. and M. de Vos, "Laws for creating trust in 1361 the blockchain age", 2017, . 1364 [QLectives] 1365 "QLectives project", 2018, 1366 . 1368 [resnick2002trust] 1369 Resnick, P. and R. Zeckhauser, "Trust among strangers in 1370 Internet transactions: Empirical analysis of eBay's 1371 reputation system", 2002, 1372 . 1375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1376 Requirement Levels", BCP 14, RFC 2119, 1377 DOI 10.17487/RFC2119, March 1997, 1378 . 1380 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1381 IANA Considerations Section in RFCs", RFC 5226, 1382 DOI 10.17487/RFC5226, May 2008, 1383 . 1385 [TUDelft2018trustchain] 1386 Pouwelse, J., "Trustchain - creating trust with software", 1387 2018, . 1390 [vukolic2015quest] 1391 Vukolic, M., "The quest for scalable blockchain fabric: 1392 Proof-of-work vs. BFT replication.", 2011, 1393 . 1396 [yan2008trust] 1397 Holtmanns, S. and Z. Yan, "Trust modeling and management: 1398 from social trust to digital trust.", 2008, 1399 . 1402 Author's Address 1403 Dr. J.A. Pouwelse (editor) 1404 Delft University of Technology 1405 Delft 1406 Netherlands 1408 Phone: +31 15 2782539 1409 Email: j.a.pouwelse@tudelft.nl