idnits 2.17.00 (12 Aug 2021) /tmp/idnits9774/draft-trossen-rtgwg-impact-of-dlts-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 : ---------------------------------------------------------------------------- ** There are 26 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (2 March 2022) is 73 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'REF' is mentioned on line 123, but not defined == Outdated reference: A later version (-04) exists of draft-farrel-irtf-introduction-to-semantic-routing-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Trossen 3 Internet-Draft D. Guzman 4 Intended status: Informational Huawei Technologies 5 Expires: 3 September 2022 M. McBride 6 FutureWei 7 X. Fan 8 IoTeX 9 2 March 2022 11 Impact of DLTs on Provider Networks 12 draft-trossen-rtgwg-impact-of-dlts-01 14 Abstract 16 This document discusses the impact of distributed ledger technologies 17 being realized over IP-based provider networks. The focus here lies 18 on the impact that the DLT communication patterns have on efficiency 19 of resource usage in the underlying networks. We provide initial 20 insights into experimental results to quantify this impact in terms 21 of inefficient and wasted communication, aligned along challenges 22 that the DLT realization over IP networks faces. 24 This document intends to outline this impact but also opportunities 25 for network innovations to improve on the identified impact as well 26 as the overall service quality. While this document does not promote 27 specific solutions that capture those opportunities, it invites the 28 wider community working on DLT and network solutions alike to 29 contribute to the insights in this document to aid future research 30 and development into possible solution concepts and technologies. 32 The findings presented here have first been reported within the 33 similarly titled whitepaper released by the Industry IoT Consortium 34 (IIC) [IIC_whitepaper]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 3 September 2022. 53 Copyright Notice 55 Copyright (c) 2022 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Revised BSD License text as 64 described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Revised BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Main DLT Concepts . . . . . . . . . . . . . . . . . . . . . . 5 72 4. Communication in a DLT . . . . . . . . . . . . . . . . . . . 6 73 4.1. DLT Interactions . . . . . . . . . . . . . . . . . . . . 6 74 4.2. Resulting Communication Patterns . . . . . . . . . . . . 8 75 5. Challenges for Users and Provider Networks . . . . . . . . . 9 76 6. Experimental Insights . . . . . . . . . . . . . . . . . . . . 10 77 6.1. Types of DLT Peers . . . . . . . . . . . . . . . . . . . 11 78 6.2. Communication Waste . . . . . . . . . . . . . . . . . . . 11 79 7. Opportunities for Network Innovations . . . . . . . . . . . . 12 80 8. Relation to IETF/IRTF and IEEE SA Efforts . . . . . . . . . . 14 81 9. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 15 82 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 85 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 87 15. Informative References . . . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 The current routing system was initially designed for a single 93 purpose, namely reachability between end nodes. This capability is 94 utilized in many higher layer technologies in the form of overlays. 95 Distributed Ledger Technologies (DLT) are one such form of overlay 96 with the aim to facilitate communication patterns that allow a 97 distributed consensus among distributed, and generally unknown, 98 participants in the DLT overlay. 100 The realization of a DLT overlay follows that of other well-known 101 examples for distributed computing tasks, such as Torrents, 102 distributed file storage, among others. That is, DLTs form their own 103 overlay through contributing 'peers' that partake in the DLT. For 104 this, reachability information (in the form of IP addresses) of other 105 DLT peers is centrally maintained (in so-called 'bootstrap nodes') to 106 establish peer-specific pools of peers, within which each peer in 107 turn communicates for the specific purpose of the DLT. DLTs secure 108 the transactions using transport-level methods. As an overlay, DLTs 109 are little concerned with the underlying network(s) itself, simply 110 utilizing the provided IP reachability service for their purpose. 112 Continuing on the insights first reported in [IIC_whitepaper], this 113 document sheds light onto the realization of specific DLT overlay 114 mechanisms from the perspective of the resulting impact on the 115 utilized provider networks in the form of the actual communication 116 taking place. 118 For this, we outline the communication patterns upon which certain 119 forms of DLTs rely (Section 4.2) in order to implement the key DLT 120 concepts (Section 3). Based on our insights of those communication 121 patterns, we then identify a number of key challenges (Section 5) 122 through initial experimental results (Section 6) within an example 123 DLT platform (here, Ethereum [REF]). 125 Here, we explicitly recognize that those insights are highly 126 dependent on the specific DLT mechanisms under investigation and are 127 therefore not generally transferable to other DLT platforms and their 128 realization. For instance, DLT platforms relying on proof-of-work 129 for transaction verification tend to differ in their communication 130 from those relying on proof-of-stake. However, this document does 131 attempt to develop a wider methodology over time that may allow for 132 quantifying the impact on underlying networks across those different 133 types of DLTs. 135 While the quantification of DLT impact serves as an interesting 136 benchmark into the possible costs for operating DLTs, the identified 137 challenges give also rise to possible opportunities for network-level 138 innovations to improve on the situation observed in our experiments, 139 thereby reducing the identified impact on provider network. 140 Section 7 outlines a possible realization of those opportunities 141 through a constraint-based selection of communication relations, 142 utilizing semantic information beyond IP reachability. 144 With this in mind, we position an improved DLT performance as a 145 possible applicability for semantic routing, introduced in more 146 detail in [I-D.farrel-irtf-introduction-to-semantic-routing], while 147 also soliciting other possible realizations of an improved DLT 148 performance through network-level innovations. Moreover, we draw 149 connections with ongoing IETF/IRTF efforts (Section 8), where our 150 insights may provide useful input. 152 Note: This document does neither discuss the particular rationale for 153 selecting DLTs in order to realize the intended application purpose 154 nor the specific DLT mechanisms eventually used. It therefore does 155 not pass comment on the advisability or practicality of using DLTs 156 and their solutions, nor does it define any specific technical 157 solutions for reducing the observed provider impact. 159 2. Terminology 161 The following terminology is used throughout the remainder of this 162 draft: 164 Smart contract : distributed state machine over which transactions 165 will be executed and logged. 167 Transaction : cryptographically signed (set of) instruction(s) 168 against a smart contract. 170 Ledger : information on transactions 172 Block : set of verified ledger information 174 Blockchain : concatenated blocks with longest chain of blocks 175 representing the current consensus of ledger 176 information. 178 Peer : participant in the DLT, with a possible narrower 179 role of client or miner. 181 Client : a DLT peer issuing transactions towards a set of 182 miners. 184 Miner : a DLT peer receiving transactions from miners and 185 performing suitable block operations and exchanges to 186 maintain DLT information. 188 3. Main DLT Concepts 190 There has been ample work, such as [DLT_intro] [DLT_intro2], among 191 others, including in other SDOs such as the IEEE but also within the 192 IRTF/IETF [DINRGref], on defining main DLT concepts; we refer the 193 reader to those references for more details. We focus our brief 194 introduction here on those concepts most important to understand from 195 a communication perspective. 197 The core abstraction used in a DLT is that of a 'transaction', i.e., 198 a cryptographically signed (set of) instruction(s) to modify a state 199 machine, which in turn represents the distributed consensus the DLT 200 is trying to maintain. These transactions are executed within the 201 higher-level concept of a 'smart contract', which implements the 202 specific DLT application, such as for cryptocurrency, storage 203 management, decentralized governance, among others. 205 Valid transactions are maintained in a distributed 'ledger' in the 206 form of hashed information referred to as 'blocks'. Consensus is 207 represented through the longest available chain of blocks that can be 208 obtained from another DLT peer. 210 The validation of transactions, and therefore the inclusion into the 211 (distributed) ledger, is realized through the consensus layer, 212 realizing computational operations, such as Proof-of-Work, Proof-of- 213 Stake, and others. There has been much discussion on the 214 implications of those computational aspects, e.g., on energy 215 consumption, which is not the focus of this draft. 217 Figure 1 provides an overview of a typical layering within a DLT 218 architecture. The focus of this draft is on the layers below the 219 session, i.e. the communication that needs to be upheld in order to 220 facilitate transactions and block exchange within the DLT system. 222 +------------++---------------------------------------------------------+ 223 | Application|| User | DLT | DLT | DLT |Decentralized| 224 | Layer || Interface | Wallet | Explorer | Analytics | Finance | 225 +------------++---------------------------------------------------------+ 226 |App Protocol|| Identity | Token | Storage | DLT |Decentralized| 227 | Layer || Mgmt | Mgmt | Mgmt | Oracle | Governance | 228 +------------++-----------------------------+---------------------------+ 229 | Contract || Transaction | Smart | 230 | Layer || Engine | Contract | 231 +------------++-----------------------------+---------------------------+ 232 | Consensus || PoW/PoS/DPoS/PBFT/Raft/etc. | 233 | Layer || | 234 +------------++-------------------+------------------+------------------+ 235 | Session || Transaction | Block | Account | 236 | Layer || | | | 237 +------------++-------------------+------------------+------------------+ 238 | Transport || TCP | QUIC | TLS | 239 | Layer || | | | 240 +------------++-------------------+------------------+------------------+ 241 | Network || (DNS + ) IP | Service | Pub/sub | 242 | Layer || | Routing | overlay | 243 +------------++-------------------+------------------+------------------+ 244 | Resource || CPU | Storage | Transport | 245 | Layer || | | Network | 246 +------------++-------------------+------------------+------------------+ 248 Figure 1: DLT Conceptual Architecture [IIC_whitepaper] 250 4. Communication in a DLT 252 With our focus on the communication impact of DLTs, we now tease 253 apart the communication as it usually takes place in a DLT in order 254 to realize the transactions within a distributed ledger and the 255 maintenance of the latter. We first outline the interactions at a 256 higher level before delving into the communication patterns that 257 result from those. 259 As stated in the introduction, these insights are currently limited 260 to those obtained from Ethereum, a proof-of-work based DLT platform. 261 Future draft revisions will enrich this section with any differing 262 insights from other DLT realizations and platforms. 264 4.1. DLT Interactions 266 We can distinguish three core interactions in a DLT: 268 1. A client commits a transaction to the DLT. The transaction 269 request is being diffused across a set of DLT miners, which 270 respond to the transaction request separately and add the 271 transaction to their internal ledger information. The commit of 272 the transaction leads to the miners committing compute and 273 storage resources in relation to the smart contract that 274 underlies the transaction. For this, so-called 'proofs' will be 275 executed as part of the computational part of the DLT, although 276 some methods for proof require additional communication to take 277 place, e.g., election protocols. 279 2. The result of the aforementioned proof is a 'block' (of ledger 280 information) that the miners in turn commit to a set of (other) 281 DLT miners, which each receiving miner adds to their internal 282 blockchain. 284 3. A client may query the latest blockchain, again from a set of 285 miners to which the query is being sent. The longest returned 286 blockchain represents the most trustworthy ledger information 287 available. 289 We can see from those interactions above that communication in a DLT 290 is multipoint in nature, i.e., transactions or information (such as 291 blocks) are sent to a set of DLT peers, not just a single one. 293 Important here is that the set of DLT peers is a randomized sample 294 from a larger pool of available DLT peers; this is to achieve 295 diffusion among many DLT peers, avoiding repeated communication with 296 a fixed set of DLT peers and thereby reducing the threat of collusion 297 of information through a malicious set of DLT peers. 299 The consequence of that varying random nature of the multipoint 300 diffusion, however, is that repeated unicast replication is utilized 301 instead of efficient network-level multicast; this constitutes a 302 first recognizable impact on provider networks. 304 In the following subsection, we now focus on the communication 305 patterns that are utilized to achieve the aforementioned interaction. 306 Special attention is here given on the establishment of the pool of 307 DLT peers that is used in the multipoint operations that are executes 308 for each interaction, be it a transaction or the commitment of a 309 newfound (ledger) block. 311 4.2. Resulting Communication Patterns 313 As mentioned before, it is key for any DLT peer, be it a client or a 314 miner, to establish and maintain a 'pool of peers' from which it can 315 select a set of DLT peers for each intended interaction. Figure 2 316 outlines those steps, detailed in the following. Our insights on 317 realization were obtained from an Ethereum based experiment, using 318 the go-ethereum release V1.10.2-stable on a Linux-based machine, 319 operating out of Munich, Germany. 321 1. The first phase is that of a 'peer discovery'. For this, an 322 initial list of DLT peer information is obtained from a 323 'bootstrap node', of which only few exist in the DLT, holding the 324 IP address and port information of each DLT peer that has signed 325 up to the DLT overlay (other information may include DLT-specific 326 information, such as an overlay ID or similar). 328 2. This initial list of DLT peers is now contacted through a (UDP- 329 level) PING/PONG sequence, thereby discovering those DLT peers 330 that are reachable for the DLT interactions. 332 3. A successful discovery of the DLT peer is now followed with the 333 establishment of suitable transport security. Once successfully 334 secured, the discovered DLT peer is being added to the 'DLT pool' 335 list at the initiating DLT peer. 337 4. Once security is established, capabilities are exchanged that 338 ensure that the discovered peer can successfully complete 339 possible requests. Those capabilities may include HW 340 capabilities (e.g., GPU usage, certain memory build-out), SW 341 capabilities (use of certain hash functions, blockchain 342 checkpoint) and others. 344 5. The initiating DLT peer repeats now the previous steps 1 through 345 4 until the pool size reaches a defined limit. Unlike contacting 346 the bootstrap nodes, however, the newly and successfully 347 discovered DLT peers in the previous round are contacted instead 348 for obtaining a list of DLT peers. 350 6. Any member of the DLT pool is continuously checked for 351 connectivity through frequent (e.g., TCP-based) HELLO messages. 352 Any failed HELLO transaction leads to removing the DLT peer from 353 the pool and obtaining another DLT peer as replacement. 355 The final size of the pool is a matter of local configuration (in our 356 case about 28k DLT peers, significantly less than the size of the 357 overall DLT network, which was about 500k at the time of the 358 experiment). 360 Also, a DLT client may commence with transactions (to the DLT 361 overlay) already while the pool creation is still ongoing, thereby 362 progressing to the last step in Figure 2 once a suitable set of DLT 363 peers can be obtained from the overall (and possibly still growing) 364 local pool of peers. 366 +-------------------+ if DLT peer connection failed 367 | Obtain list |<--------------------------------------+ 368 | of DLT peers |<--+ | 369 +-------------------+ | if pool size +--------------+--- 370 | Node | | smaller than max | Maintain peer | 371 | discovery | | | connectivity | 372 +-------------------+ | +-----------------+ 373 | Transport | | 374 | security | | 375 +-------------------+ | 376 | Capability +---+ 377 | exchange | 378 +-------------------+ 379 | 380 | add discovered peers to pool of DLT peers 381 \|/ 382 +--------------------------------+ 383 | Obtain set of DLT peers | 384 | from pool of DLT peers | 385 +--------------------------------+ 386 | Transactions | 387 +--------------------------------+ 389 Figure 2: Steps of Communications in a DLT 391 5. Challenges for Users and Provider Networks 393 Considering the observed communication patterns in the previous 394 section, we can identify a number of challenges that need addressing: 396 1. Reachability information is required to interact with other 397 peers. For that, bootstrap nodes maintain IP addresses of all 398 peers (plus port information). As illustrated in Figure 2, new 399 DLT peers need to download and expand suitable reachability 400 information upon joining, either from bootstrap node or via 401 discovered nodes - see Figure 2, , requiring each DLT peer to 402 maintain a pool of peer as active connections. 404 2. Clients know nothing about capabilities of peers to serve 405 requests. In other words, the discovery in Figure 2 merely 406 ensures possible reachability but not necessarily successful 407 communication. As a consequence, the resulting approach, 408 illustrated in Figure 2, is to (1) contact potential peer, (2) 409 wait for connection, (3) inquire capabilities, (4) disconnect if 410 not matching. Here, peers may never reply to connection 411 establishment (step 2), usually resulting in additional latency 412 due to timeouts involved, prolonging therefore the establishment 413 of the pool of peers to communicate with. Such capabilities 414 often reflect the continuous evolution of business models over 415 DLT networks and may be dynamic in nature. For example, the 416 minimum transaction fee may depend on the 'DLT gas price', which 417 is set up at the transaction recipient (miner). 419 3. Peers map sending of transactions onto unicast communication, 420 which negatively impacts efficiency (bandwidth usage) and 421 transaction completion time. Here, the use of group-based 422 multicast approaches is difficult due to the random nature of the 423 set of peers selected for communication in every request 424 exchange, aiming at the diffusion of requests rather than 425 interacting with a stable (but possibly colluding) set of peers. 427 4. DLT peers need to expose their IP address to the DLT system, 428 replicated to the bootstrap nodes, but also other DLT peers by 429 virtue of the discovery process outlined in Figure 2. This may 430 lead to privacy and/or security issues in the form of geo- 431 identifying specific peers, DoS attacks on particular parts of 432 the DLT and others. 434 6. Experimental Insights 436 To shed some more light onto the possible impact on provider 437 networks, stemming from some of the challenges in Section 5, we 438 conducted experiments, using the same setup described in Section 4.2. 439 More details (and suitable graphical representations of our initial 440 results can be found in [IIC_whitepaper]). 442 Here, the goal was to undergo the steps needed to build up the needed 443 pool of DLT peers, after which we sought to synchronize to determine 444 the longest blockchain available in the discovered pool. The 445 resulting geographic spread of the discovered DLT peers included all 446 continents albeit with an expected clustering of nodes North America, 447 Europe, Asia, and Australia, with only few discovered in South 448 America and Africa. 450 6.1. Types of DLT Peers 452 Our first target was to differentiate types of DLT peers that stem 453 from the communication patterns in Figure 2. Specifically, we came 454 to differentiate the following types of DLT peers: 456 1. Non routable peers: This type include all those peers that never 457 positively responded to step 1 of the discovery, i.e. the PING/ 458 PONG to determine reachability. Reasons here may include to be 459 located behind a firewall, being intermittently available (and 460 switched off during the connection attempt), or simply having 461 left the DLT while still remaining in the information pool 462 maintained at the bootstrap nodes. 464 2. Signalling peers: This type includes peers that respond 465 positively to reachability but do not positively succeed in the 466 transport security or capability exchange steps (blockchain 467 checkpoint). 469 3. Dropped data peers: This type of peers successfully complete all 470 discovery steps, thereby end up in the pool of peers, but still 471 do not provide suitable data upon request (here a valid 472 blockchain information). The reasons here could be unavailable 473 information or not completing the transfer of information 474 (blockchain information can be very large, several GBs, so that 475 DLT peers may run out of available BW budget or decide to sever 476 the connection because of switch-off or other reasons during the 477 transfer). While here communication in the DLT does take place, 478 it is not successful in regards to the intended communication, 479 therefore wasted. 481 4. Data peers: This final type of peers successfully completes all 482 steps in Figure 2, i.e. not only the discovery but also the 483 intended transfer of DLT-relevant data. 485 In our experiments, we determined at about 18% of peers are of the 486 last type, i.e. successfully contribute to DLT purposes, while about 487 2% are of the third category, about 12% are non routable peers and 488 about 68% are signalling peers. In other words, almost 80% of all 489 attempted discoveries fails either because of the lack of 490 reachability or mismatching capabilities. 492 6.2. Communication Waste 494 Looking at the bandwidth usage across the different peer types allows 495 for shedding some light on the communication that needs to be carried 496 through the participating provider networks. 498 Given the amount of data for each blockchain synchronization, it is 499 not surprising that, despite forming a mere 18% of peers, the 'data 500 peers' account for about 58% of traffic in the overall system. This 501 is followed by the 'dropped data peers' with about 31.5% (since still 502 much data is sent albeit unsuccessfully). Both non routable and 503 signalling peers account for a total of slightly under 10% of data 504 used. 506 Although the amount of data that is wasted here accounts for 507 (significant) total of about 42%, the data-heavy operation of 508 synchronization large amounts of (blockchain) data is mainly to blame 509 for this; however, the synchronization has to happen for any DLT peer 510 to start operating as a possible DLT miner, so is not avoidable. 512 7. Opportunities for Network Innovations 514 The challenges outlined in Section 5 lead us to outline possible 515 opportunities for network innovations that may address those 516 challenges and reduce the observed impact on provider networks. We 517 stress here that none of the suggested approaches constitute 518 solutions for those opportunities but merely possible starting points 519 beyond which further study is required: 521 1. Addressing model: With the DLT overlay being realized over an IP 522 network, each DLT peer is being addressed via its IP(v4/v6) 523 address. With the discovery step selecting a dedicated DLT peer 524 (through its IP address), the discovery steps (see Figure 2) 525 include dedicated steps to ensure the reachability of the 526 specific DLT peer under discovery. Until reachability can be 527 ensured, traffic (in the form of PING/PONG messages) and latency 528 (through sending those messages, while needing to wait for a 529 timeout in case the DLT peer is not routable) need to occur, 530 despite the DLT peer not being eventually used for communication. 532 * Approaches such as those in [SOI][SarNet2021] may allow for 533 DLT peers to advertise their capability to serve as a miner by 534 using 'service announcements' that expose the capability to 535 serve transaction requests, which each announced DLT peer 536 representing a service instance of the announced mining 537 service. Such native L3 (or L3.5) level service routing 538 capability would therefore remove any of the discovery steps 539 and the maintenance of the dedicated DLT overlay 540 infrastructure. Furthermore, it would remove any visibility 541 of individual DLT peers' reachability information from other 542 miners, until directly communicating with a specific DLT peer 543 (for which the peer's IP address may be used, as suggested in 544 [SarNet2021]). Last but not least, being able to send a 545 request without previously forming a pool of DLT peers (which 546 is smaller than the number of all DLT peers in the overlay) 547 also increases the possible number of DLT peers to communicate 548 with rather than being limited to the peer-specific pool. 550 2. Constraint-based peer selection: Following on the aspect of 551 relying purely on reachability information in the form of IP 552 addresses, the discovery steps in Figure 2 further include a 553 number of capability-dependent selection criteria to finally 554 include a DLT peer in its pool of peers. Specifically, the 555 security and capability exchange may lead to a disconnect from a 556 successfully contacted DLT because of such exchange leading to 557 mismatching capabilities. Furthermore, even after an initial 558 capability exchange being successful, the actual transaction 559 itself may be constrained by capabilities such as available 560 resources (e.g., bandwidth or CPU), leading to unsuccessful 561 communication, which in turn will need to be compensated with 562 including another DLT peer into the diffusion request. 564 * Approaches such as [SarNet2021] may allow to constrain the 565 forwarding to one of possible many DLT peers. Hence, the 566 capabilities used in the current DLT steps Figure 2 could be 567 encoded as suitable constraints for such selection, the 568 constraints itself being advertised as part of the service 569 announcement (see above). As a result, the request will be 570 forwarded to those destinations only which have previously 571 announced constraints that match those of the request, thereby 572 ensuring the successful completion of the request - further 573 study is needed for those situations in which constraints may 574 change frequently, thereby leading to successful matching, yet 575 still unsuccessful request completion. 577 3. Diffusion multicast: The multipoint replication of the 578 transaction request to a set of DLT peers, chosen from the larger 579 DLT pool maintained at the initiating DLT peer, increases the 580 overall system but, in particular, individual client bandwidth 581 usage, which in turn impacts the provider network by needing to 582 provide the necessary resources for the replicated sending. 584 * Approaches such as those in [SOI][SarNet2021] may allow for 585 sending a service request to a given number of DLT peers, 586 where the replication is part of the constraint-based 587 forwarding decision, thereby optimizing the packet delivery 588 through in-network instead of endpoint-based replication. The 589 challenge here lies in preserving the diffusion character of 590 the multipoint operation. In other words, the set of DLT 591 peers used for the transactions changes for each request with 592 a randomization that attempts to prevent possible collusion 593 through DLT peers. With that, typical group-based methods, 594 most notably IP multicast, do not suffice. 596 8. Relation to IETF/IRTF and IEEE SA Efforts 598 Both, DLTs as well as routing innovations, are subject to 599 investigation in a number of related IETF and IRTF efforts. For 600 instance, the Decentralized Internet Infrastructure RG [DINRGref] has 601 been studying various aspects of DLTs and blockchains. Our findings 602 in this draft may provide additional input into the work of this RG, 603 while we would solicit feedback from this group of experts into the 604 specific insights we have derived so far. 606 There is no standard way of providing interoperability between DLT 607 networks. This results in difficulty of transferring or exchanging 608 virtual assets from one DLT network to another. An interoperability 609 architecture is being proposed in the IETF 610 [I-D.hardjono-blockchain-interop-arch] to permit two gateways, 611 belonging to distinct DLT networks, to conduct a virtual asset 612 transfer between them while ensuring the asset does not exist 613 simultaneously on both networks. The Open Digital Asset Protocol 614 (ODAP) [I-D.hargreaves-odap] is a gateway-to-gateway protocol to 615 perform a unidirectional transfer of a virtual asset. 617 Furthermore, routing innovations under the label of 'semantic 618 routing' have been the topic of recent work, see 619 [I-D.farrel-irtf-introduction-to-semantic-routing] for an overview. 620 With the examples of service routing as possible approaches to 621 realize the opportunities outlined in the previous subsection, a 622 stronger linkage to this activity should be considered. 624 While the DLT standardization efforts in IEEE SA mainly focus on the 625 upper layers of the DLT architecture, the decentrlaized identity 626 related standards (e.g., P2958 [P2958] and P3210 [P3210]) that are 627 currently under development might be relevant for addressing specific 628 challenges in the DLT network layer. 630 9. Open Questions 632 The work initially presented in [IIC_whitepaper] focussed on the 633 specific impact that DLT operations may have on provider networks, 634 thereby turning the attention not to the specific applications of DLT 635 but what their realization may mean to the underlying network 636 operators. 638 Although attempting from the onset to base our insights on actual 639 experiments we conducted, we recognize that those insights are only 640 the start to a possibly wider understanding beyond this initial work. 642 We therefore solicit not only feedback on the specific findings 643 presented in the previous sections, but also to specific questions 644 that our work has led to: 646 1. Correctness of observed DLT behaviour: Is our observed behaviour 647 correct or have we overlooked important aspects? 649 2. Transfer of insights: Our insights so far are based on the 650 Ethereum DLT system. How transferable are the observed patterns 651 of communication onto other DLT systems that are in use? 653 3. Differences in DLT realizations: If the answer to the previous 654 question leads to little transfer onto other DLT platform, can we 655 distil those difference with the goal to develop a wider 656 methodology to capture DLT behaviour? 658 4. Applicability of other network innovations: What other network 659 innovations may address the specific impacts we identified in our 660 study? Which ones beyond the ones currently listed should be 661 included? 663 Beyond the above rather high-level questions, our work has led to 664 rather specific questions that we intend to better understand. 665 Future revisions of this draft will likely extend on those in more 666 details. 668 10. Conclusions 670 This draft is a living document, originating from an initial study in 671 the impact of DLTs on provider networks [IIC_whitepaper]. 673 As such, the authors solicit feedback from the wider DLT and network 674 community to improve on the insights, transfer them onto more DLT 675 systems, and shed light onto how possible network innovations could 676 improve on the identified issues. 678 11. Security Considerations 680 This document does not introduce or modify any security mechanisms. 681 The nature of DLTs is to provide a high level of transactional 682 security through immutability of the data in blocks. But 51% attacks 683 are possible amongst miners particularly on smaller, private 684 blockchains where legitimate miners could be prevented from 685 completing blocks and new blocks could be created by illegitimate 686 miners. Smart contracts could become vulnerable if a function calls 687 the wrong contract either intentionally or through human error. 688 Transactional data meant to be private might be exposed. DLT attacks 689 most often involve accounts being hacked outside of the DLT domain. 691 12. Privacy Considerations 693 Since the IP addresses of DLT peers are exposed in the DLT system, 694 the DLT network layer might be subject to privacy leakage. This 695 document does not introduce any mechanisms for protecting IP address 696 privacy and the methods described in 697 [I-D.ip-address-privacy-considerations] could be employed to enhance 698 the privacy of DLT peers. 700 13. IANA Considerations 702 This draft does not request any IANA action. 704 14. Acknowledgements 706 This draft acknowledges the work done in the IIC Industrial Digital 707 Ledger focus group, leading to the whitepaper in [IIC_whitepaper]. 708 We would like to thank the co-authors of this whitepaper for their 709 work, specifically David Guzman (Huawei Technologies), Abhijeet 710 Kelkar (GEOOWN Consulting), Xinxin Fan (IoTex), Mike McBride 711 (Futurewei Technologies), Lei Zhang (iExec), Ulrich Graf (Huawei 712 Technologies) and Dirk Trossen (Huawei Technologies) but also Stephen 713 Mellor (IIC staff) who oversaw the process of organizing the 714 contributions. 716 15. Informative References 718 [DINRGref] "Decentralized Internet Infrastructure (dinrg)", WG DIN 719 Research Group, 720 . 722 [DLT_intro] 723 Antonopoulos, A. M., "Mastering Bitcoin, 2nd Edition", 724 Book O'Reilly Media, Inc., 2017, 725 . 728 [DLT_intro2] 729 Rauchs, M., Glidden, A., Gordon, B., Pieters, G., 730 Recanatini, M., Rostand, F., Vagneur, K., and B. Zhang, 731 "Distributed Ledger Technology Systems: A Conceptual 732 Framework", Report Cambridge Centre for Alternative 733 Finance, 2017, . 737 [I-D.farrel-irtf-introduction-to-semantic-routing] 738 Farrel, A. and D. King, "An Introduction to Semantic 739 Routing", Work in Progress, Internet-Draft, draft-farrel- 740 irtf-introduction-to-semantic-routing-03, 22 January 2022, 741 . 744 [I-D.hardjono-blockchain-interop-arch] 745 Hardjono, T., Hargreaves, M., Smith, N., and V. 746 Ramakrishna, "Interoperability Architecture for DLT 747 Gateways", Work in Progress, Internet-Draft, draft- 748 hardjono-blockchain-interop-arch-03, 6 November 2021, 749 . 752 [I-D.hargreaves-odap] 753 Hargreaves, M., Hardjono, T., and R. Belchior, "Open 754 Digital Asset Protocol", Work in Progress, Internet-Draft, 755 draft-hargreaves-odap-03, 6 November 2021, 756 . 759 [I-D.ip-address-privacy-considerations] 760 Finkel, M., Lassey, B., Iannone, L., and J. B. Chen, "IP 761 Address Privacy Considerations", Work in Progress, 762 Internet-Draft, draft-ip-address-privacy-considerations- 763 03, 10 January 2022, . 766 [IIC_whitepaper] 767 Trossen, D., Guzman, D., Kelkar, A., Fan, X., McBride, M., 768 Zhang, L., and U. Graf, "Impact of Distributed Ledgers on 769 Provider Networks", Whitepaper Industry IoT Consortium 770 Whitepaper, 2022, . 774 [P2958] "P2958: Standard for a Decentralized Identity and Access 775 Management Framework for Internet of Things", 776 Standard IEEE Standards Association., 777 . 779 [P3210] "P3210: Standard for Blockchain-based Digital Identity 780 System Framework", Standard IEEE Standards Association., 781 . 783 [SarNet2021] 784 Glebke, R., Trossen, D., Kunze, I., Lou, Z., Rueth, J., 785 Stoffers, M., and K. Wehrle, "Service-based Forwarding via 786 Programmable Dataplanes", Paper 1st Intl Workshop on 787 Semantic Addressing and Routing for Future Networks, 2021. 789 [SOI] Jiang, S., Li, G., and B. Carpenter, "A New Approach to a 790 Service Oriented Internet Protocol", Paper IEEE INFOCOM 791 2020 - IEEE Conference on Computer Communications 792 Workshops (INFOCOM WKSHPS), 2020. 794 Authors' Addresses 796 Dirk Trossen 797 Huawei Technologies 798 Munich 799 Germany 800 Email: dirk.trossen@huawei.com 802 David Guzman 803 Huawei Technologies 804 Munich 805 Germany 806 Email: david.guzman@huawei.com 808 Mike Mc Bride 809 FutureWei 810 Email: michael.mcbride@futurewei.com 812 Xinxin Fan 813 IoTeX 814 Email: xinxin@iotex.io