Сокращение затрат на блокчейн с репутацией
26 июня 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 Анализ безопасности
Заключение и ссылки
7.2 Оценка эффективности прокуратуры
Во -первых, мы оцениваем производительность и эффективность ресурсов прокурора. Мы рассматриваем следующие метрики.
• Пропускная способность: Среднее количество транзакций, которые могут быть обработаны за одну секунду. Единица составляет транзакцию в секунду (TPS).
• Стоимость хранения: Размер всей книги блокчейна. Единицы - байты или мегабайты (МБ).
• Задержка подтверждения: Время, когда операция передачи представлена, когда она зарегистрирована в бухгалтерской книге. Устройство является вторым.
Фиг. 7 (a)-(c) Покажите пропускную способность, затраты на хранение и задержку подтверждения блокируемого и прокурора, соответственно. В частности, мы меняем рабочую нагрузку на рынке мобильных AIGC, настраивая скорость впрыска транзакций. Для конфигураций блокчейна интервал генерации блоков составляет пять секунд. Каждая якорная цепь и рулонный блок могут перевозить до 2000 и 500 транзакций соответственно.
1) Пропускная способность: Рис. 7 (а) иллюстрирует, что пропускная способность блокирующих заповедников при 387 ТП после рабочей нагрузки достигает 500 ТП. Чтобы дополнительно изучить верхнюю границу пропускной способности традиционной архитектуры блокчейна, мы позволяем BlockeMulator генерировать один новый блок каждую секунду и использовать внутреннюю сеть без задержки для синхронизации сообщений. Как показано синими стержнями на рис. 7 (а), пропускная способность не может превышать 1740 TP даже в такой идеальной среде. Ограниченная пропускная способность значительно препятствует масштабируемости системы в адаптации к крупномасштабным рынкам AIGC с огромными списками репутации. Однако с помощью репутации все транзакции Mulach_update могут быть сжаты и выгружены из цепочки якоря. Более того, несколько RCO могут работать параллельно, каждый из которых управляет репутацией подмножества MASP. Следовательно, пропускная способность для обработки репутации может линейно увеличиваться с увеличением сетевой шкалы, поддерживая частые обновления репутации, сохраняя при этом ценную мощность цепочки якоря.
2) Затраты на хранение: На рис. 7 (b) показаны затраты на хранение с развертыванием репутации и без нее, когда рабочая нагрузка составляет 100 TPS, 200 TPS и 500 TPS. В BlockEmulator каждый заголовок блока и транзакция занимают 120 и 99 байтов соответственно. В результате размер бухгалтерской бухгалтерской книги увеличивается 34,07 МБ/час, 68,06 МБ/час и 136,03 МБ/час.
Рабочая нагрузка 100 TPS, 200 TPS и 500 TPS. Такие затраты на хранение недоступны для многочисленных мобильных устройств с ограниченной емкостью хранения, таких как смартфоны и ноутбуки. Внесенный в репутацию, прокурор может разгрузить все транзакции vinime_update из якорной цепи, только поддерживая 32-байтовые хэши транзакции. Следовательно, затраты на хранение могут быть снижены не менее чем на 67,5%. Кроме того, RCOS может загружать историческую репутацию в цепочку хранения и, таким образом, еще больше снизить затраты на локальное хранение, если они могут получить интегральную информацию о транзакциях для трассировки репутации.
3) Задержка подтверждения: Рис. 7 (C) иллюстрирует задержку подтверждения блока -членалятора и прокурора с увеличением рабочей нагрузки с 100 TPS до 5000 TPS. Во -первых, синие столбцы показывают теоретическую нижнюю границу, которая составляет пять секунд, то есть интервал генерации блока. Мы можем наблюдать, что блокатор страдает от увеличения задержки, поскольку в пуле транзакций хранится больше транзакций, когда скорость впрыска транзакции превышает максимальную пропускную способность. Такая высокая задержка не позволяет клиентам эффективно использовать мобильные услуги AIGC. В отличие от этого, прокурор помогает в дуплексной передаче, прокурор позволяет каждой паре клиента-массов выполнять передачу владения локально без очередей в пуле транзакций. Следовательно, задержка подтверждения определяется только способностью канала для завершения процедуры, разработанной в разделе 4.3, которая составляет около 3,4 секунды в нашем испытательном стенде.
Авторы:
(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).
Эта статья есть
Оригинал