This content originally appeared on HackerNoon and was authored by EScholar: Electronic Academic Papers for Scholars
Table of Links
1.3 Our Work and Contributions and 1.4 Organization
Related Work
Prosecutor Design
OS2a: Objective Service Assessment for Mobile AIGC
OS2A on Prosecutor: Two-Phase Interaction for Mobile AIGC
Implementation and Evaluation
7.1 Implementation and Experimental Setup
7.2 Prosecutor Performance Evaluation
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.
\
:::info Authors:
(1) Yinqiu Liu, School of Computer Science and Engineering, Nanyang Technological University, Singapore (yinqiu001@e.ntu.edu.sg);
(2) Hongyang Du, School of Computer Science and Engineering, Nanyang Technological University, Singapore (hongyang001@e.ntu.edu.sg);
(3) Dusit Niyato, School of Computer Science and Engineering, Nanyang Technological University, Singapore (dniyato@ntu.edu.sg);
(4) Jiawen Kang, School of Automation, Guangdong University of Technology, China (kavinkang@gdut.edu.cn);
(5) Zehui Xiong, Pillar of Information Systems Technology and Design, Singapore University of Technology and Design, Singapore (zehuixiong@sutd.edu.sg);
(6) Abbas Jamalipour, School of Electrical and Information Engineering, University of Sydney, Australia (a.jamalipour@ieee.org);
(7) Xuemin (Sherman) Shen, Department of Electrical and Computer Engineering, University of Waterloo, Canada (sshen@uwaterloo.ca).
:::
:::info This paper is available on arxiv under CC BY 4.0 DEED license.
:::
\
This content originally appeared on HackerNoon and was authored by EScholar: Electronic Academic Papers for Scholars
EScholar: Electronic Academic Papers for Scholars | Sciencx (2025-06-25T14:00:03+00:00) Cutting Blockchain Costs with Reputation Rollup. Retrieved from https://www.scien.cx/2025/06/25/cutting-blockchain-costs-with-reputation-rollup/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.