Может ли блокчейн эффективно? Симуляции Эзчейна говорят да
30 июня 2025 г.Таблица ссылок
Аннотация и I. Введение
II Связанные работы
Iii. Системные модели
IV Дизайн Ezchain
V. Анализ эффективности, безопасности и децентрализации Эзчейна
VI Эксперименты по моделированию Ezchain
VII. Выводы, подтверждения и ссылки
VI Эксперименты по моделированию Ezchain
В этом разделе мы оцениваем производительность, внедряя прототип моделирования EZCHAIN (включая сетевой транспортный уровень) и концентрируя в первую очередь на последующих аспектах: i) средняя пропускная способность системы EZCHAIN; ii) время потребления и проверки хранения для консенсусных узлов Ezchain; iii) Задержка потребления хранения и подтверждения транзакций для узлов учетной записи Ezchain.
A. Экспериментальная установка Ezchain
1) Экспериментальное оборудование: В этом эксперименте мы использовали аппаратную платформу, оснащенную процессором Core Core (R) 11-го поколения (R) I7-1165G7 (2,80 ГГц, восьми ядра) и 16,0 ГБ памяти для проведения моделирования для Ezchain. Экспериментальная установка варьировалась по количеству узлов, причем самая большая конфигурация содержит 100 консенсусных узлов и 180 узлов учетной записи. Максимальное количество раундов моделирования устанавливается на 1200, что позволяет провести всестороннюю оценку эффективности Эзчейна при крупномасштабном развертывании узлов и расширенных операционных продолжительности. Симулятор, написанный на Python, можно получить на GitHub [9].
2) Настройка системы моделирования: Количество консенсусных узлов и узлов учетных записей может быть гибко настроена. Учитывая ограничения памяти устройства, параметры для этого эксперимента варьируются от 3 до 160 узлов. Все узлы Ezchain случайным образом устанавливают соединения P2P, причем каждый узел имеет максимум 30 соседних узлов, а полоса пропускания равномерно установлена на
1 Mbits/s. Задержка связи между консенсусными узлами (ссылаясь здесь на задержки в очереди, исключая время передачи и аналогично ниже), падает в пределах 1 с как случайная переменная. Задержка связи между консенсусными узлами и узлами учетной записи фиксируется на уровне 1,5 с, в то время как задержка между узлами учетной записи также составляет 1,5 с. Блок Genesis записывает владение всеми начальными значениями. В каждом раунде моделирования (генерация блоков) узлы учетных записей спонтанно участвуют в случайных транзакциях, причем суммы транзакции регулируются на основе эксперимента.
B. Проверка пропускной способности системы Ezchain
Из -за ограничений оборудования и максимизации проверки пределов пропускной способности Ezchain мы уменьшаем раунды выполнения и увеличиваем удлинительные узлы при увеличении шкалы транзакций. Кроме того, учитывая квадратичную взаимосвязь между узлами учетных записей и введенными транзакциями в раунд [10], мы настраиваем 100 консенсусных узлов и 3-160 узлов учетной записи, при этом результаты теста на пропускную способность показаны на рисунке 17. Красная точечная линия представляет собой пропускную способность классического блокчейна с 100% использование ресурсов полосы пропускания, а желтая полоса указывает на плавающую диапазон результатов тестирования. Результаты демонстрируют, что Ezchain может достигать более 10000 транзакций в секунду (TPS), при этом каждый блок легко выполняет приблизительно 15 000 транзакций. Пропускная способность системы может превышать лимит полосы пропускания для соответствия «масштабируемым».
Ультра-высокая пропускная способность не влияет на другие выступления. При более чем 10000 ТП требования к хранению для каждой блоки менее 0,5 МБ, которые ниже размера блока в биткойнах, несмотря на тысячи с более высокой пропускной способностью по сравнению с биткойнами. Для времени проверки проверка блока блока узлов Ezchain происходит в основном в порядке 1 миллисекунды, в то время как задержка подтверждения транзакции узел узел также приближается к 10 секунд.
C. Стоимость хранения и проверки узла Ezchain Consensus
Учитывая ограничения устройства, и для тестирования накладных расходов на консенсус-узлы и валидации мы требуем расширенных экспериментальных раундов (время выполнения системы) для наблюдения за долгосрочными затратами. Следовательно, в этом эксперименте используются 3 консенсусных узла и 3 узла счетов в 1200 раундах (блоки) для оценки тенденций затрат на консенсусные узлы Ezchain. Результаты на рисунке 18 требования к хранению приблизительно 150 МБ в 1200 блоках с линейной тенденцией роста. Как показано на рисунке 19, время проверки на блок остается полностью независимым от пропускной способности системы, количества транзакций и времени выполнения, сохраняющихся ниже 1 миллисекунды.
D. Стоимость хранения и проверки узла учетной записи Ezchain
В этом эксперименте мы устанавливаем 3 консенсусных узла и 3 узла учетных записей, выполняя 1200 раундов (блоки), чтобы контролировать тенденции потребления стоимости хранения узла Ezchain. Результаты изображены на рисунке 20, где красная линия представляет сглаженную стоимость (среднее значение принимается каждые 50 раундов), а черная линия представляет количество информации, которую необходимо хранить узел учетной записи для хранения под
Та же централизованная архитектура. Средние тенденции указывают на то, что стоимость хранения узлов учетной записи не демонстрирует существенного увеличения по мере роста количества системных раундов. Кроме того, стоимость хранения не демонстрирует разницу в порядке по сравнению с стоимостью централизованных узлов счета.
Что касается задержки подтверждения транзакций, результаты, как показано на рисунке 21, демонстрируют, что задержка подтверждения транзакции для узлов счетов преимущественно падает в течение 10 секунд. Кроме того, эта задержка не меняется с пропускной способностью системы или системой, работающими с раундами.
Для затрат на передачу и проверку узлов учетной записи мы предполагаем, что узлы учетных записей случайным образом проводят транзакции на частоте с фиксированным ожиданием. Это позволяет нам удобно настроить конкретные эксперименты и отражать затраты на передачу и проверку, отслеживая количество держателей, которое значение проходит при каждой передаче. Результаты, как показано на рисунке 22, демонстрируют, что по ходу транзакций объем информации, необходимой для передачи и проверки с помощью узлов учетной записи, сходится к фиксированному значению. Интуитивно, этот вывод показывает, что длина VPB (ширина красной пунктирной коробки) на рисунке 10 будет сходиться
к фиксированному значению, которое решительно поддерживает масштабирование Эзхана с точки зрения узла учетной записи.
Кроме того, основываясь на результатах этого эксперимента, мы можем официально доказать важный вывод:
Заключение 1.Для узла учетной записи Ezchain Acc:
Когда все вышеуказанные условия имеют постоянные верхние границы, стоимость хранения ACC будет иметь фиксированную постоянную верхнюю границу, которая остается неизменной в отношении времени выполнения системы, совокупных транзакций, размера сети и других факторов.
E. Сравнение производительности между Ezchain и другими решениями
Сравнительный анализ концентрируется на Ezchain по сравнению с другими растворами Layer-1. Хотя большинство решений Layer-2 демонстрируют замечательную производительность, они функционируют независимо от базового блокчейна и требуют более надежных допущений безопасности для транзакций. Сравнительные результаты, показанные в таблице I, подчеркивают наши основные соображения: пропускная способность системы, задержка подтверждения транзакций и затраты на хранение узлов. Данные, относящиеся к другим решениям, в основном происходят из соответствующих экспериментальных источников, с определенными данными, подверженными разумным корректировкам масштабирования, для облегчения улучшенных сравнений.
Ezchain демонстрирует вторую высокую пропускную способность, используя минимальный размер сети и самые низкие ресурсы полосы пропускания. Примечательно, что S-HS требует в 100 раз больше ресурсов полосы пропускания по сравнению с Ezchain, но в то же время достигает лишь удвоения пропускной способности. Более того, подраздел VI-B подтверждает способность Эзхейна соответствовать масштабированию в пределах ограниченных ограничений полосы пропускания. Существуют убедительные признаки того, что при расширенной экспериментальной инфраструктуре (такой как значительно увеличение ресурсов памяти), Ezchain может потенциально превзойти S-HS. Примечательно, что Ezchain неизменно обеспечивает латентность подтверждения на практических уровнях, подходящих для применений потребительского уровня.
При рассмотрении затрат на хранение консенсусные узлы Ezchain демонстрируют значительно более низкое потребление хранения, по крайней мере, на порядок меньше по сравнению с оптимальным решением по шардингу, как подробно описано в предоставленной таблице. Несмотря на то, что стоимость хранения узлов счетов относительно высока, вывод 1 свидетельствует о том, что эта стоимость сходится к фиксированному значению, в отличие от других решений, где она растет на неопределенный срок с увеличением объема транзакции.
Авторы:
(1) Лид Сюэ, Университет науки и техники Китая, Хефей, Китай (xldxld@mail.ustc.edu.cn);
(2) Вэй Ян, Университет науки и технологии Китая, Хефей, Китай (qubit@ustc.edu.cn);
(3) Вэй Ли, Университет науки и техники Китая, Хефей, Китай (wei123@mail.ustc.edu.cn).
Эта статья есть
[9] https://github.com/re20cboy/ezchain-py
Оригинал