A Technical Guide to ProSecutor’s Blockchain-Based AIGC Design

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

4 PROSECUTOR DESIGN

In this section, we describe the ProSecutor design. We start with the architecture overview, including parallel chains and data structure. Then, we describe the layer-2 design of ProSecutor to support reputation calculation and atomic fee-ownership transfers in mobile AIGC, namely reputation roll-up and duplex transfer channels.

4.1 Architecture Overview

4.1.1 Parallel Chains and Stakeholders

As shown in Fig. 1-Part A, ProSecutor adopts a hierarchical architecture with two parallel chains. The bottom one is called Anchor Chain, whose functions are operating smart contracts and recording all the historical events happening in mobile AIGC, including reputation updates, feeownership transfers, etc. MASPs serve as the full anchor chain nodes that run consensus mechanisms, save the entire ledger copy, and synchronize messages with others. Without loss of generality, we equip the anchor chain with Delegated Proof-of-Stake (DPoS) [42]. In DPoS, every full node stakes tokens and competes for the super nodes, which take turns generating new blocks at pre-configured time intervals. Such ordered block generations bring high throughput and resource efficiency, making ProSecutor suitable for mobile environments. Due to resource constraints, clients rely on MASPs to access the anchor chain. To maintain the reputation records, super nodes also serve as the Reputation Coordinators (RCOs). Finally, we build a public key infrastructure in ProSecutor. Specifically, each participant owns a public-private key pair based on Security Hash Algorithm256 (SHA256) [30] for asymmetric encryption/decryption and digital signatures. Note that the unique identity and address of every ProSecutor stakeholder are also represented by its public key.

To protect the security of mobile AIGC, in some cases, the newly generated AIGC outputs should be saved on the blockchain to defend against malicious tampering. Given the large size of AIGC content, we further deploy the Storage Chain to save the valuable storage capacity of MASPs. Using Inter-Planetary File System (IPFS) [43], the storage chain can split large AIGC outputs into chunks and preserve them on professional storage nodes. For simplicity, the storage chain does not maintain an independent ledger. Instead, the file storage function is invoked by the anchor chain using IPFSstyle HTTP requests. To fetch any stored content, the clients should provide the corresponding storage recipient, which contains the SHA256 result of the entire content as the key. Such a hierarchical architecture is designed to decouple the data recording and file storage.

4.1.2 Smart Contracts for ProSecutor-Aided Mobile AIGC

With ProSecutor, the traditional mobile AIGC described in Section 3.1 can be extended into the blockchain-aided mobile AIGC with two features: 1) all the historical events are recorded on the anchor chain, and 2) all the operations are conducted automatically by smart contracts. To do so, we refine the Ethereum data structure by developing new transactions and smart contracts (see Fig. 2).

• Opinion_Update transaction: Recall that ProSecutor maintains a reputation scheme for modeling OS2AS. Hence, we design Opinion_Update transaction to col- 6 lect the opinion of the client toward the selected MASP after each round of AIGC service. To this end, the MASP’s address, the user’s opinion, and the reference to specify the AIGC service should be packed.

• Reputation_Roll-up contract: To support reputation roll-up, we design Reputation_Roll-up contracts, which submit the roll-up block with thousands of opinion update records to the anchor chain and update the reputation of each MASP.

• Transfer_Channel contract: The transfer channels are maintained by Transfer_Channel contracts. Accordingly, index indicates the channel index; Opt. refers to the channel operations on the anchor chain, including establish and close.

In the following sections, we illustrate the details of how the data structure supports the proposed mechanisms.