Cutting Blockchain Costs with Reputation Rollup | HackerNoon

Table of Links

Abstract and 1. Introduction

1.1 Background

1.2 Motivation

1.3 Our Work and Contributions and 1.4 Organization

2. Related Work

   2.1 Mobile AIGC and Its QoE Modeling

   2.2 Blockchain for Mobile Networks

3. Preliminaries

4. Prosecutor Design

   4.1 Architecture Overview

   4.2 Reputation Roll-up

   4.3 Duplex Transfer Channel

5. OS2a: Objective Service Assessment for Mobile AIGC

   5.1 Inspiration from DCM

   5.2 Objective Quality of the Service Process

   5.3 Subjective Experience of AIGC Outputs

6. OS2A on Prosecutor: Two-Phase Interaction for Mobile AIGC

   6.1 MASP Selection by Reputation

   6.2 Contract Theoretic Payment Scheme

7. Implementation and Evaluation

   7.1 Implementation and Experimental Setup

   7.2 Prosecutor Performance Evaluation

   7.3 Investigation of Functional Goals

   7.4 Security Analysis

8. Conclusion and References

7.2 ProSecutor Performance Evaluation

Firstly, we evaluate the performance and resource efficiency of ProSecutor. We consider the following metrics.

• Throughput: The average number of transactions that can be processed in one second. The unit is Transaction per Second (TPS).

• Storage Costs: The size of the entire blockchain ledger. The units are bytes or MegaBytes (MB).

• Confirmation Latency: The time from when a transfer operation is submitted to when it is registered on the ledger. The unit is second.

Figs. 7(a)-(c) show the throughput, storage costs, and confirmation latency of BlockEmulator and ProSecutor, respectively. Specifically, we change the workload of the mobile AIGC market by adjusting the speed of transaction injection. For blockchain configurations, the block generation interval is five seconds. Each anchor chain and roll-up block can carry up to 2000 and 500 transactions, respectively.

1) Throughput: Fig. 7(a) illustrates that the throughput of BlockEmulator stalls at 387 TPS after the workload reaches 500 TPS. To further explore the throughput upper bound of the traditional blockchain architecture, we enable BlockEmulator to generate one new block every second and use a latency-free internal network for message synchronization. As illustrated by the blue bars in Fig. 7(a), the throughput cannot exceed 1740 TPS even in such an ideal environment. The limited throughput greatly hinders the system’s scalability in adapting to large-scale AIGC markets with huge reputation lists. With reputation roll-up, however, all Opinion_Update transactions can be compressed and offloaded from the anchor chain. Moreover, multiple RCOs can work in parallel, each of which manages the reputation of a subset of MASPs. Hence, the throughput for reputation processing can increase linearly with the increasing network scale, supporting frequent reputation updates while saving the valuable capacity of the anchor chain.

2) Storage Costs: Fig. 7(b) shows the storage costs with and without reputation roll-up when the workload is 100 TPS, 200 TPS, and 500 TPS. In BlockEmulator, each block header and transaction occupy 120 and 99 bytes, respectively. As a result, the size of the anchor chain ledger grows 34.07 MB/hour, 68.06 MB/hour, and 136.03 MB/hour under

the workload of 100 TPS, 200 TPS, and 500 TPS. Such storage costs are unaffordable for numerous mobile devices with limited storage capacity, such as smartphones and laptops. Contributed to reputation roll-up, ProSecutor can offload all the Opinion_Update transactions from the anchor chain, only maintaining the 32-byte transaction hashes. Consequently, the storage costs can be reduced by at most 67.5%. Furthermore, RCOs can upload historical reputations to the storage chain and thus further reduce local storage costs as long as they can fetch the integral transaction information for reputation tracing.

3) Confirmation Latency: Fig. 7(c) illustrates the confirmation latency of BlockEmulator and ProSecutor, with the increasing workload from 100 TPS to 5000 TPS. Firstly, blue bars show the theoretical lower bound, which is five seconds, i.e., the block generation interval. We can observe that BlockEmulator suffers from increasing latency since more transactions are kept in the transaction pool when the speed of transaction injection exceeds the maximum throughput. Such a high latency prevents clients from efficiently utilizing the mobile AIGC services. In contrast, assisted by duplex transfer channels, ProSecutor enables each client-MASP pair to perform ownership-fee transfers locally without queuing in the transaction pool. Consequently, the confirmation latency is only determined by the channel capability for completing the procedure elaborated in Section 4.3, which is around 3.4 seconds in our testbed.