This document discusses the challenges of using distributed ledger technology (DLT) at the network edge. It finds that DLT is currently ill-suited for edge computing due to high latency and lack of locality. Permissioned and localized DLT designs may be necessary to enable edge use cases. The document also describes a blockchain emulator called NEBULA that can evaluate DLT performance under different network parameters and consensus protocols.

1. Leo Eichhorn Θ
Tanya Shreedhar ∆
Aleksandr Zavodovski
‡
Nitinder Mohan Θ
Θ
Technical University of Munich
∆
IIIT Delhi
‡
Uppsala University
Distributed Ledgers for Distributed Edge:
Are we there yet?
Interdisciplinary Workshop on (de) Centralization in the Internet
(IWCI’21)

2. From Clouds to Ledgers
2
Cloud
Edge
Edge
Edge
Blockchain

3. Crowdsourced Edge Computing Marketplace
3
Fig. 1: Devices, roles and activities in a crowdsourced edge computing marketplace using blockchain. [5,6,7]
Smart Contracts
Off-chain provision
Smart Contracts

4. Research Interest in Edge & DLT – Are we there yet?
4
• Majority focuses on Edge, performance overheads of DLT are underrepresented [5,6,7].
• DLT bottlenecks in latency & throughput ( = big edge computing driver)? [2]
Fig. 2: Google Scholar publications mentioning distributed ledgers and edge computing in title
or abstract.

5. Blockchain Parameters
5
• P2P-Network:
 Size and topology
 Bandwidth and latency
VS
City wide
Global

6. Blockchain Parameters
6
• P2P-Network:
 Size and topology
 Bandwidth and latency
• Block creation rate:
 Minutes vs. sub-second
 Randomly vs. deterministic
VS
City wide
Global

7. Blockchain Parameters
7
• P2P-Network:
 Size and topology
 Bandwidth and latency
• Block creation rate:
 Minutes vs. sub-second
 Randomly vs. deterministic
• Consensus protocol:
 Number of consensus nodes
 Permissioned vs. permissionless
VS
Committee (DPoS)
Public & Equal (PoW)
VS
City wide
Global

8. Metric: Confirmation Latency
8
 After sending a transaction, how long until it is “immutably” on chain.
 Stale blocks and forks due to latency, concurrency, attacks, …
Fig. 3: Stale blocks and confirmed stale blocks with auctions in DLT.

9. Networked Blockchain Emulator (NEBULA)
9
• N-to-M mapping of emulated peers to hosting machines
• Potential for hardware-in-the-loop
• Maintainable, extensible, realistic

10. Networked Blockchain Emulator (NEBULA)
10
• N-to-M mapping of emulated peers to hosting machines
• Potential for hardware-in-the-loop
• Maintainable, extensible, realistic
Recall parameters:
• Networks of arbitrary topology, latency, size
• Peers create transactions and blocks at specific rates
• Modular consensus protocols, here:
Proof-of-X (PoX) & Delegated PoS (DPoS)

11. Experiment Setup
11
• 15 VM cluster (60 cores), 1 Gbps Ethernet
• Different network topologies based on cloud reachability measurements [12]:
 Small, city wide (100 nodes, 10 ms avg.)
 Large (2700 global ASNs, 36 ms avg.)
• Deploy PoX and DPoS blockchains in each networks
 Measure latency and staleness of random transactions while increasing block rate
VS
DPoS
PoX

12. Results
12
• PoX in large networks adds > 500 ms latency overhead
• Low latency PoX possible in small networks (but: stale blocks!)
• DPoS more promising - stale blocks are avoided by limiting consensus to few, well-connected nodes
(a) PoX (b) PoX Stale Blocks (c) DPoS
100ms
100ms
100ms

13. Discussion
13
• DLT network needs to be restricted to the local edge, i.e. the smart city
• How to facilitate such an environment?
 Permissioned DLT under central authorities
 Interledger [3]
Fig. 4: Locally sharded blockchains for edge computing.

14. Discussion
14
• Clear mismatch between DLT and edge:
 Traditional DLT reaches consensus by sharing data with every single node of a global network
 Edge is localized by design, consuming data directly where it is produced
 DLT network needs to be restricted to the local edge (i.e. sharding)
• Limiting network size using permissioned access governed by central authority nullifies original incentives of using DLT:
 Open participation
 Trustless consensus
 “Privacy and security by design”
 Use global interledger instead of central authority
• Rise of crowdsourcing and cryptocurrencies (Bitcoin, Folding@home, Dfinity “Internet Computer”, etc.)
vs.
Dominance of big cloud providers with significant presence in edge (smart devices, phones, etc.)

15. Future Directions
15
• How to generate a publicly verifiable proof of edge membership
 Proof is sent to public interledger or central entity
 Access to local edge market is authorized
• Baseline discussion: fully permissioned DLT and trust in edge
 Trusted entities in edge
 Performance vs. Trust
• DLT for edge use cases not reliant on low latency (but locality, bandwidth, etc.)

16. [1] W. Wang et al., "A Survey on Consensus Mechanisms and Mining Strategy Management in Blockchain Networks," in IEEE Access, vol. 7, pp. 22328-22370, 2019, doi:
10.1109/ACCESS.2019.2896108.
[2] N. Mohan, L. Corneo, A. Zavodovski, S. Bayhan, W. Wong, and J. Kangasharju. 2020. Pruning Edge Research with Latency Shears. In Proceedings of the 19th ACM
Workshop on Hot Topics in Networks (HotNets '20). Association for Computing Machinery, New York, NY, USA, 182–189. doi: 10.1145/3422604.3425943
[3] V. A. Siris, P. Nikander, S. Voulgaris, N. Fotiou, D. Lagutin, and G. C. Polyzos. Interledger approaches. IEEE Access, 7:89948–89966, 2019.
[4] K. Wright, M. Martinez, U. Chadha and B. Krishnamachari, "SmartEdge: A Smart Contract for Edge Computing," 2018 IEEE International Conference on Internet of Things
(iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), Halifax,
Canada, 2018, pp. 1685-1690, doi: 10.1109/Cybermatics_2018.2018.00281.
[5] Nardini, M. et al. “A Blockchain-based Decentralized Electronic Marketplace for Computing Resources.” SN Comput. Sci. 1 (2020): 251.
[6] A. G. Tasiopoulos, O. Ascigil, I. Psaras and G. Pavlou, "Edge-MAP: Auction Markets for Edge Resource Provisioning," 2018 IEEE 19th International Symposium on "A World
of Wireless, Mobile and Multimedia Networks" (WoWMoM), Chania, Greece, 2018, pp. 14-22, doi: 10.1109/WoWMoM.2018.8449792.
[7] A. Zavodovski, S. Bayhan, N. Mohan, P. Zhou, W. Wong and J. Kangasharju, "DeCloud: Truthful Decentralized Double Auction for Edge Clouds," 2019 IEEE 39th
International Conference on Distributed Computing Systems (ICDCS), Dallas, TX, USA, 2019, pp. 2157-2167, doi: 10.1109/ICDCS.2019.00212.
[8] S. Alqahtani and M. Demirbas, Bottlenecks in blockchain consensus protocols, 2021. arXiv: 2103.04234 [cs.DC]
[9] B. Xu, D. Luthra, Z. Cole, and N. Blakely, “Eos: An architectural, performance, and economic analysis,” 2018.
[10] G. Wood et al., “Ethereum: A secure decentralised generalised transaction ledger,” Ethereum project yellow paper, vol. 151, no. 2014, pp. 1–32, 2014.
[11] J. P. Queralta and T. Westerlund, “Blockchain for mobile edge computing: Consensus mechanisms and scalability,” CoRR, vol. abs/2006.07578, 2020. arXiv:2006.07578.
[12] Lorenzo Corneo, Maximilian Eder, Nitinder Mohan, Aleksandr Zavodovski, Suzan Bayhan, Walter Wong, Per Gunningberg, Jussi Kangasharju, and Jörg Ott. 2021.
Surrounded by the Clouds: A Comprehensive Cloud Reachability Study. In Proceedings of The Web Conference 2021 (WWW ’21). Association for Computing Machinery, New
York, NY, USA. https://doi.org/10.1145/3442381.3449854
Bibliography
16

17. Backup
17

18. DPoS + BFT
18
A
B
C
A B C
A A B B C C
Current BP Other BPs
[2/3 ACKs received]
D
D D D
A1 irreversible
“Pipelined” BFT

19. DPoS + BFT Stale Blocks
19
A B C
A A B B C C D D D
A B C
A A B
B
C C D D D
A B
C
A
A
B
B
C C D D D

20. DPoS + BFT Parameters
20
A
B
C
D
 Rate of blocks
 Number of blocks per BP
 Number of BPs
 BP order (travelling salesman)
 Increase duration of final interval / Skip last blocks

21. BFT
21
• Traditional BFT can be used in blockchain by reaching consensus on each block in rounds.
• Not scalable to large numbers of nodes [8].

22. Edge Computing Feasibility
22
• For edge computing to be feasibile [3]:
 Latency should be below 100ms
 Bandwidth should be above 1GB

23. Task Offloading in Edge
23
• Unmanaged hardware is susceptible to crashes and service handoffs
• Short running Lambda functions necessitate fast deployment

24. Parameters &
Measurements
24
• Total of 26 blockchain parameters
• Easy configuration of multiple experiments
and runs

25. Scalability
25
• Precision of results depends on hosts’ real-
time capabilities due to multi threading of
peers.
• High CPU loads resulting from long
processing queues introduce additional
latency, thus stale blocks.

26. Validation
26
• Comparing the emulator to Ethereum [2], Bitcoin [3], Dogecoin and Litecoin [4] and an
existing simulator [5].

27. Blockchain Scalability Trilemma
27