Внутри легкая, проверенная система транзакций Ezchain
30 июня 2025 г.Таблица ссылок
Аннотация и I. Введение
II Связанные работы
Iii. Системные модели
IV Дизайн Ezchain
V. Анализ эффективности, безопасности и децентрализации Эзчейна
VI Эксперименты по моделированию Ezchain
VII. Выводы, подтверждения и ссылки
IV Дизайн Ezchain
A. Основные идеи Ezchain
Этот подраздел направлен на то, чтобы обеспечить интуитивное и неформальное введение в фундаментальные концепции, лежащие в основе дизайна Ezchain, что позволяет читателям получить всесторонний обзор системы Ezchain и дизайна алгоритма. Мы начнем с истории
Основные идеи Ezchain кратко объяснены в предыдущей истории:
Создайте новую структуру данных для каждого значения (то есть монета).
Основная цепочка должна только проверять, консенсус и хранить эти «две магии» - корень дерева и фильтр дерева, наряду с другой необходимой информацией).
Получатель может независимо проверять любые транзакции через основную цепочку и доказательство, предоставленное отправителем.
В то время как подход Ezchain разделяет сходства с доказательствами от неохота и нулевого знания, его сущность отличается. Во-первых, в отличие от решений вне цепочки, любая транзакция, генерируемая в системе Ezchain, будет включена в корень дерева Меркл, обеспечивая безопасность всех транзакций через основную цепь. Во-вторых, в отличие от блокчейнов с нулевым знанием, Эзхейн не полагается на какие-либо предшествующие алгоритмы нулевого знания. Его алгоритм проверки является кратким, что позволяет проводить такие операции, как генерация доказательств и проверка, проводящиеся в течение 10 миллисекундеров, а также обеспечение того, чтобы размер доказательства сходился к постоянному значению.
С точки зрения теории информации, Ezchain позволяет подтвердить легитимность транзакций в децентрализованных сетях со злыми узлами без необходимости передачи и хранения всей глобальной истории. Мы также обнаружили, что относительно небольшое количество информации (с точки зрения передачи и хранения) может полностью поддерживать проверку транзакций в децентрализованной и доверчивой среде [3]. Как показано на рисунке 4, конкретное значение (изображенное как синий грузовой ящик) постоянно обменивается между различными транзакциями (t xn#4 - 6). Получив это значение, учетная запись L может проверить легитимность T XN#6, проверив легитимность этого значения. Эта проверка включает в себя проверку, являются ли все транзакции, которые столкнулись с этим значением до t xn#6, являются законными и является ли сам T XN#6 законным. Важно отметить, что эти проверки не зависят от t xn#1 - 3. Следовательно, при проверке t xn#6 информация, содержащаяся в T xn#1 - 3, не должна передаваться или храниться. Эта концепция формирует фундаментальную идею Ezchain, аналогичную принципу «бритва Оккама» в консенсусе блокчейна. Цель Ezchain состоит в том, чтобы устранить ненужную информацию, которая не имеет отношения к консенсусу и проверке, тем самым достигая оптимизированных процессов передачи, хранения и проверки.
B. Обзор системы Ezchain
Общие идеи исследований и структуры проектирования Эзхейна показаны на рисунке 5. Алгоритм консенсуса Эзхана подтверждает различные консенсусные механизмы, включая доказательство работы (военнослужащих), византиновый толранс (BFT), доказательство кола) и делегированное доказательство ставки (DPOS). С точки зрения консенсусной информации и структур данных, Ezchain использует инновационный механизм, основанный на «стоимости» вместо того, чтобы полагаться на учетную запись или механизм UTXO. Этот механизм в первую очередь фокусируется на записи и проверке всей книги с точки зрения переноса стоимости. В цепочке Ezchain использует чрезвычайно легкую структуру данных, в которой каждый блок занимает приблизительно 0,5 МБ. Однако, теоретически, он может вместить бесконечное количество транзакций, достигая «масштабирования» с точки зрения информации, хранящейся в блоке. Кроме того, проверка информации в ходе цепь является удобной и эффективной, требующей только необходимой подписи и проверки хэша без необходимости возврата и проверки истории транзакций и логики транзакций. Этот подход также решает первоначальную проблему доверия, которая возникает, когда новые узлы присоединяются к системе Ezchain. Конкретная проверка транзакции откладывается на «проверку транзакции P2P». Это означает, что участники транзакций несут ответственность за проверку легитимности их собственных транзакций, которые служат положительным стимулом и децентрализуют давление валидации на консенсусные узлы.
Общая логика проектирования механизма консенсуса Ezchain показана в алгоритмах 1 и 2 соответственно. Можно заметить, что Эзхейн не полагается на основной дизайн выборов лидеров и логики генерации блоков. Следовательно, он может адаптироваться к различным существующим алгоритмам консенсуса. Фактически, мы настоятельно рекомендуем механизм консенсуса Algorand-VRF + BFT [6], благодаря его способности минимизировать вилки, что хорошо соответствует высокоскоростной производительности генерации блоков Ezchain. [4] Конкретные детали структур данных, участвующих в алгоритмах 1 и 2, будут объяснены в последующем подразделе.
Структура данных C. Ezchain
По сравнению с традиционными блокчейнами, Эзхейн подвергается тщательному перепроектированию структуры данных, касающихся блоков, проверки и доказательств, как показано на рисунке 6. Конкретное объяснение заключается в следующем:
- Ранее упомянутое «значение» не совпадает с токеном или UTXO в классическом блокчейне. Его структура данных определяется как значение = (Начать индекс, конечный индекс), и он обладает следующими характеристиками: i) значение, по сути, является целочисленным набором: {x, x ∈ [Начать индекс, конечный индекс] и x является целым числом}, ii) Различные значения не пересекаются, то есть, ∀x и ∀y, x∩y = ∅, iii) значение может быть разделено на более мелкие наборы, а объединение этих подмножества все еще равна исходному набору, iv) количество значений может быть рассчитано на основе индекса начала и конец (т.е.= Конечный индекс - начало индекс + 1)
D. Анализ конкретных случаев транзакций в Ezchain
Этот подраздел обеспечивает подробный анализ участия каждого узла в системе Ezchain на различных этапах транзакции, включая инициацию, подчинение, консенсус и подтверждение. Мы также объясним эксплуатационный процесс системы Ezchain, используя пример, изображенный на рисунке 10.
Вышеупомянутый процесс проверки требует, чтобы B комбинировала информацию из основной цепи и доказательство, предоставленное для совместной проверки легитимности транзакции. Информация о Ezchain в ходе цепь гарантирует, что A не может обеспечить ложную или подделаемую «историю ценности». Следовательно, A может обеспечить только правдивое, полное и проверенное доказательство B.
E. Оптимизированный дизайн ezchain
1) Механизм отбора значений во время транзакции:Во время транзакции предполагая, что этот счет A хочет выплатить целевую сумму x в учетную запись B, то необходимо собирать целевую сумму из значений, которые она содержит. Самый простой способ - итерация через значения с самого начала, пока не найдет значения, совокупное количество которых не удовлетворяет x (как показано на рисунке 11).
Однако узел учетной записи может проанализировать конкретную ситуацию и выбрать набор значений, который наиболее подходит для этой транзакции. Например, A может выбрать набор значений, который требует наименьшего доказательства, или не требует разделения (изменения) и т. Д. (Как показано на рисунке 12), после всестороннего рассмотрения каждая учетная запись может настроить свою собственную стратегию выбора оптимизации в соответствии с его собственной ситуацией.
2) Механизм проверки точек: Требование без разбора запросить все записи о передаче и доказательства для любого данного значения с учетной записи не требуется. Вот простой и интуитивно понятный пример для иллюстрации (как показано на рисунке 13): в блоке α передает определенное число значений (например, 100) на b. В последующем блоке β (β> α) D хочет перенести значение 100 обратно в A. В этом случае D может выбрать значение, которое ранее было передано из A и сообщить, что это значение не нужно переоценивать до блока α, поскольку оно уже было локально подтверждено A. Другими словами, необходимо только проверить законность значения в высоте блока, в диапазоне от α+1 до β. Эта концепция дизайна представляет собой основу механизма контрольного пункта Эзхана. По мере продвижения транзакций учетные записи могут непрерывно обновлять контрольные точки для сохранения значений для сохранения на хранении, коммуникации и затратах на проверку.
Авторы:
(1) Лид Сюэ, Университет науки и техники Китая, Хефей, Китай (xldxld@mail.ustc.edu.cn);
(2) Вэй Ян, Университет науки и технологии Китая, Хефей, Китай (qubit@ustc.edu.cn);
(3) Вэй Ли, Университет науки и техники Китая, Хефей, Китай (wei123@mail.ustc.edu.cn).
Эта статья есть
[3] Однако мы признаем, что текущая конструкция Ezchain все еще может потребовать больше информации, чем минимально необходимая сумма.
[4] Обратите внимание, что основной алгоритм ezchain не использует механизм консенсуса алгорада для объяснения, поскольку механизм консенсуса алгорада более сложный, чем POW. Учитывая читабельность, мы в основном используем версию Ezchain для POW для отображения и объяснения.
[5] Из -за возможности ложных срабатываний в фильтре цветения, что указывает на то, что элементы (адреса учетных записей), не принадлежащие целевому набору, могут быть включены, необходимо предоставить информацию, которая может полностью реконструировать этот фильтр цветения (то есть все элементы целевого набора) в качестве доказательства.
[6] Консенсусные узлы могут неоднократно добавлять адреса и транзакции честных счетов в фильтр цветов и Mtree в блоке Ezchain. В результате Ezchain позволяет честным учетным записям выдавать «проблемы» в консенсус -узле, ответственный за публикацию соответствующего блока. Эти проблемы требуют, чтобы консенсус -узел предоставил соответствующие доказательства, в частности, необходимую информацию, необходимую для реконструкции фильтра или MTREE, для решения этой проблемы. Законные доказательства могут продемонстрировать, что честные узлы счетов либо страдают от ложных срабатываний в фильтре цветения, либо были избыточно представлены консенсусным узлом.
Оригинал