Техническое руководство по проектированию AIGC на основе прокуратуры на основе блокчейна
25 июня 2025 г.Таблица ссылок
Аннотация и 1. Введение
1.1 Фон
1.2 Мотивация
1.3 Наша работа и вклады и 1.4 организация
Связанная работа
2.1 Mobile AIGC и его моделирование QOE
2.2 блокчейн для мобильных сетей
Предварительные
Прокурор дизайн
4.1 Обзор архитектуры
4.2 REPUTITY ROLL-UP
4.3 Дуплекс -передаточный канал
OS2A: Объективная оценка услуг для мобильного AIGC
5.1 Вдохновение от DCM
5.2 Объективное качество процесса обслуживания
5.3 Субъективный опыт выходов AIGC
OS2A на прокуратуре: двухфазное взаимодействие для мобильного AIGC
6.1 Выбор MASP по репутации
6.2 Схема теоретического оплаты контракта
Реализация и оценка
7.1 Реализация и экспериментальная настройка
7.2 Оценка эффективности прокуратуры
7.3 Исследование функциональных целей
7.4 Анализ безопасности
Заключение и ссылки
4 Прокурор дизайн
В этом разделе мы описываем дизайн прокурора. Мы начинаем с обзора архитектуры, включая параллельные цепочки и структуру данных. Затем мы опишем дизайн прокурора Layer-2 для поддержки расчета репутации и переводов по атомной оплате в мобильном AIGC, а также каналах передачи репутации и передачи дуплекса.
4.1 Обзор архитектуры
4.1.1 Параллельные цепочки и заинтересованные стороны
Как показано на рис. 1-Частике А, прокурор принимает иерархическую архитектуру с двумя параллельными цепями. Нижний называется цепочкой якоря, функции которых выполняют интеллектуальные контракты и регистрируют все исторические события, происходящие в мобильных AIGC, включая обновления репутации, передачи платежниками и т. Д. MASP служат полноценными узлами цепи, которые запускают консенсусные механизмы, сохраняют всю копию книги и синхронизируют сообщения с другими. Без потери общности мы экипируем якорную цепь делегированным доказательством устремления (DPOS) [42]. В DPO есть каждая полная узловая ставки и конкурирует за супер-узлы, которые по очереди генерируют новые блоки с предварительно настроенными интервалами времени. Такие упорядоченные поколения блок обеспечивают высокую пропускную способность и эффективность ресурсов, что делает прокурора подходящим для мобильных сред. Из -за ограничений ресурсов клиенты полагаются на MASP для доступа к цепочке якоря. Для ведения записей репутации супер -узлы также служат координаторами репутации (RCO). Наконец, мы строим инфраструктуру общедоступного ключа в прокуроре. В частности, каждый участник владеет государственной частной парой ключей, основанной на алгоритме Hash Security256 (SHA256) [30] для асимметричного шифрования/дешифрования и цифровых подписей. Обратите внимание, что уникальная идентичность и адрес всех заинтересованных сторон прокурора также представлены его открытым ключом.
Чтобы защитить безопасность мобильного AIGC, в некоторых случаях недавно сгенерированные выходы AIGC должны быть сохранены на блокчейне для защиты от злонамеренного подделки. Учитывая большой размер контента AIGC, мы дополнительно развертываем цепочку хранения, чтобы сохранить ценную емкость хранения MASP. Используя межпланетную файловую систему (IPFS) [43], цепочка хранения может разделить большие выходы AIGC на куски и сохранить их на профессиональных узлах хранения. Для простоты цепочка хранения не поддерживает независимую бухгалтерскую книгу. Вместо этого функция хранения файлов вызывается цепочкой привязки с использованием HTTP -запросов IPFSstyle. Чтобы получить любой сохраненный контент, клиенты должны предоставить соответствующий получатель хранилища, который содержит результат SHA256 всего контента в качестве ключа. Такая иерархическая архитектура предназначена для отделения записи данных и хранения файлов.
4.1.2 Умные контракты для прокурора мобильного AIGC
При прокуроре традиционный мобильный AIGC, описанный в разделе 3.1, может быть расширен на мобильный AIGC с двумя функциями с двумя функциями: 1) Все исторические события записаны в цепочке якоря, и 2) все операции проводятся автоматически с помощью интеллектуальных контрактов. Для этого мы уточняем структуру данных Ethereum, разработав новые транзакции и интеллектуальные контракты (см. Рис. 2).
• Транзакция мнения_апдата:Напомним, что прокурор поддерживает схему репутации для моделирования OS2AS. Следовательно, мы разрабатываем мнение_updateТранзакция в COL-6 лекции о мнении клиента в сторону выбранной MASP после каждого раунда службы AIGC. С этой целью, адрес MASP, мнение пользователя и ссылка на указание службы AIGC должны быть упакованы.
• Контракт REPUTICE_ROLL-UP:Для поддержки репутации мы разрабатываем контракты на репутацию reputation_roll-up, которые представляют рулонный блок с тысячами записей об обновлении мнений в цепочку привязки и обновляем репутацию каждого MASP.
• Контракт Transfer_channel:Каналы передачи поддерживаются с помощью контрактов Transfer_channel. Соответственно, индекс указывает индекс канала; Опт. Относится к операциям канала в цепочке якоря, включая установление и закрытие.
В следующих разделах мы иллюстрируем детали того, как структура данных поддерживает предлагаемые механизмы.
Авторы:
(1) Yinqiu Liu, Школа компьютерных наук и инженерии, Технологический университет Наняна, Сингапур (yinqiu001@e.ntu.edu.sg);
(2) Hongyang Du, Школа компьютерных наук и инженерии, Технологический университет Нанян, Сингапур (hongyang001@e.ntu.edu.sg);
(3) Dusit niyato, Школа информатики и инженерии, Наньянский технологический университет, Сингапур (dniyato@ntu.edu.sg);
(4) Цзявен Кан, Школа автоматизации, Технологический университет Гуандунга, Китай (kavinkang@gdut.edu.cn);
(5) Zehui Xiong, Столп технологий и дизайна информационных систем, Сингапурский технологический университет и дизайн, Сингапур (zehuixiong@sutd.edu.sg);
(6) Аббас Джамалипур, Школа электротехники и информационной инженерии, Университет Сиднея, Австралия (a.jamalipour@ieee.org);
(7) Сюмин (Шерман) Шен, Департамент электрической и компьютерной инженерии, Университет Ватерлоо, Канада (sshen@uwaterloo.ca).
Эта статья есть
Оригинал