Binius: Революційна оптимізація двійкових полів STARKs

Аналіз принципів Binius STARKs та їх оптимізація

1 Вступ

Основною причиною низької ефективності STARKs є те, що більшість чисел у реальних програмах є досить малими, такими як індекси у циклах for, булеві значення, лічильники тощо. Однак, щоб забезпечити безпеку доказів на основі дерева Меркла, під час розширення даних за допомогою кодування Ріда-Соломона багато додаткових надмірних значень займають весь простір, навіть якщо самі початкові значення дуже малі. Щоб вирішити цю проблему, зменшення розміру простору стало ключовою стратегією.

Як показано в таблиці 1, ширина кодування STARKs першого покоління становить 252 біти, ширина кодування STARKs другого покоління становить 64 біти, а ширина кодування STARKs третього покоління становить 32 біти, але ширина кодування 32 біти все ще має багато непотрібного простору. У порівнянні з цим, двійкове поле дозволяє безпосередньо виконувати операції з бітами, кодування є компактним і ефективним без жодного непотрібного простору, тобто STARKs четвертого покоління.

Таблиця 1: Шлях еволюції STARKs

| Алгебра | Ширина кодування | Приклад | |------|----------|------| | 1-ше покоління | 252bit | Ethereum STARKs | | Друге покоління | 64bit | Plonky2 | | 3-й покоління | 32 біт | BabyBear | | 4-е покоління | 1 біт | Binius |

В порівнянні з Goldilocks, BabyBear, Mersenne31 та іншими новими дослідженнями за останні кілька років, дослідження бінарних полів сягає 80-х років минулого століття. Наразі бінарні поля широко застосовуються в криптографії, типовими прикладами є:

  • Стандарт високої криптографії (AES), оснований на полі F28
  • Galois повідомлення автентифікації ( GMAC ), базується на полі F2128
  • QR-код, що використовує кодування Ріда-Соломона на основі F28
  • Оригінальний протокол FRI та zk-STARK, а також хеш-функція Grøstl, яка пройшла до фіналу SHA-3, заснована на полі F28, є дуже підходящим хеш-алгоритмом для рекурсії.

Коли використовуються менші поля, операції розширення поля стають все більш важливими для забезпечення безпеки. А двійкове поле, що використовується в Binius, повністю покладається на розширення поля для забезпечення своєї безпеки та фактичної придатності. Більшість поліномів, що беруть участь у обчисленнях Prover, не потребують переходу в розширене поле, а лише працюють у базовому полі, що забезпечує високу ефективність у малих полях. Однак випадкові перевірки точок і обчислення FRI все ще потребують глибшого занурення в більш велике розширене поле, щоб забезпечити необхідний рівень безпеки.

При побудові системи доказів на основі бінарного поля існує 2 реальні проблеми: під час обчислення представлення трас у STARKs, розмір використаного поля має бути більшим за степінь полінома; під час зобов'язання Merkle tree у STARKs необхідно виконати кодування Ріда-Соломона, розмір використаного поля має бути більшим за розмір після розширення коду.

Binius запропонував інноваційне рішення, яке окремо обробляє ці дві проблеми та реалізує їх шляхом представлення однакових даних двома різними способами: по-перше, використанням багатозмінного (, а саме багатолінійного ) многочлена замість однозмінного многочлена, шляхом відображення його значень на "гіперкубах" (; по-друге, оскільки довжина кожного виміру гіперкуба дорівнює 2, стандартне розширення Ріда-Соломона, як у STARKs, неможливе, але гіперкуб можна розглядати як квадрат ), на основі якого можна виконати розширення Ріда-Соломона. Цей підхід значно підвищує ефективність кодування та обчислювальну продуктивність, забезпечуючи при цьому безпеку.

2 Аналіз принципу

Поточна більшість систем SNARKs зазвичай складається з двох частин:

  • Інформаційна теорія поліноміальних інтерактивних оркулів доказів ( Information-Theoretic Polynomial Interactive Oracle Proof, PIOP ): PIOP як основа системи доказів перетворює вхідні обчислювальні відносини на верифіковані поліноміальні рівняння. Різні протоколи PIOP дозволяють доказувачу поступово надсилати поліноми через взаємодію з верифікатором, що дозволяє верифікатору перевіряти, чи є обчислення правильними, запитуючи невелику кількість оцінок поліномів. Існуючі протоколи PIOP включають: PLONK PIOP, Spartan PIOP та HyperPlonk PIOP, кожен з яких має різний підхід до обробки поліноміальних виразів, що впливає на продуктивність та ефективність усієї системи SNARK.

  • Поліноміальна схема зобов'язання ( Polynomial Commitment Scheme, PCS ): Поліноміальна схема зобов'язання використовується для доведення того, чи є істинним поліноміальне рівняння, згенероване PIOP. PCS є криптографічним інструментом, за допомогою якого доводчик може зобов'язатися до певного полінома та пізніше перевірити результати оцінювання цього полінома, приховуючи при цьому іншу інформацію про поліном. Звичайні схеми зобов'язання поліномів включають KZG, Bulletproofs, FRI ( Fast Reed-Solomon IOPP ) та Brakedown. Різні PCS мають різні характеристики, безпеку та сфери застосування.

Залежно від конкретних вимог, виберіть різні PIOP і PCS, а також поєднайте їх з відповідними скінченними полями або еліптичними кривими, можна побудувати системи доказів з різними властивостями. Наприклад:

• Halo2: поєднує PLONK PIOP та Bulletproofs PCS, базується на кривій Pasta. При проектуванні Halo2 акцент робився на масштабованості та усуненні довіреного налаштування з протоколу ZCash.

• Plonky2: поєднує PLONK PIOP та FRI PCS, базуючись на області Goldilocks. Plonky2 розроблено для досягнення ефективної рекурсії. При проектуванні цих систем вибрані PIOP та PCS повинні відповідати використаній скінченній області або еліптичній кривій, щоб забезпечити правильність, продуктивність і безпеку системи. Цей вибір комбінацій впливає не лише на розмір доказів SNARK та ефективність перевірки, а й визначає, чи може система досягти прозорості без надійних налаштувань, чи може вона підтримувати розширені функції, такі як рекурсивні докази або агреговані докази.

Binius: HyperPlonk PIOP + Brakedown PCS + бінарні поля. Конкретно, Binius включає п'ять ключових технологій для досягнення своєї ефективності та безпеки. По-перше, базова арифметична структура на основі веж бінарних полів (towers of binary fields) становить основу його обчислень, що дозволяє реалізовувати спрощені обчислення у бінарних полях. По-друге, Binius адаптував HyperPlonk перевірку на добуток і перестановку в своєму інтерактивному Oracle доказовому протоколі (PIOP), що забезпечує безпечну та ефективну перевірку консистентності між змінними та їх перестановками. По-третє, протокол вводить нове багатоелементне зсувне доказування, що оптимізує ефективність перевірки багатоелементних зв'язків на малих полях. По-четверте, Binius використовує покращене Lasso доказування пошуку, яке забезпечує гнучкість і потужну безпеку для механізму пошуку. Нарешті, протокол використовує схему зобов'язань на малих поліномах (Small-Field PCS), що дозволяє йому реалізувати ефективну систему доказів у бінарних полях і зменшити витрати, що зазвичай пов'язані з великими полями.

( 2.1 Обмежене поле: арифметика на основі веж бінарних полів

Тау-структура бінарних полів є ключем до реалізації швидких перевіряємих обчислень, що зумовлено двома основними аспектами: ефективними обчисленнями та ефективною арифметикою. Бінарні поля за своєю сутністю підтримують високоефективні арифметичні операції, що робить їх ідеальним вибором для криптографічних застосувань, чутливих до продуктивності. Крім того, структура бінарних полів підтримує спрощений арифметичний процес, тобто операції, виконувані в бінарному полі, можуть бути представлені у компактній та легко перевіряємій алгебраїчній формі. Ці характеристики, разом з можливістю повністю використовувати їх ієрархічні особливості через тау-структуру, роблять бінарні поля особливо придатними для масштабованих систем доказів, таких як Binius.

Термін "canonical" означає унікальний і прямий спосіб представлення елементів у двійковій області. Наприклад, у найосновнішій двійковій області F2 будь-який рядок з k бітів може бути безпосередньо відображений на елемент з k бітів двійкової області. Це відрізняється від просторової області, яка не може надати таке стандартне представлення в межах заданої кількості бітів. Хоча простора область з 32 бітами може бути вміщена в 32 біт, не кожен рядок з 32 бітів може унікально відповідати елементу області, тоді як двійкова область має цю зручність однозначного відображення. У просторовій області Fp звичайні методи редукції включають редукцію Барретта, редукцію Монтгомері, а також спеціальні методи редукції для певних скінченних полів, таких як Mersenne-31 або Goldilocks-64. У двійковій області F2k звичайні методи редукції включають спеціальну редукцію ), як це використовують у AES, редукцію Монтгомері ###, як це використовують у POLYVAL, та рекурсивну редукцію (, як у Tower ). У статті "Exploring the Design Space of Prime Field vs. Binary Field ECC-Hardware Implementations" зазначається, що у двійковій області для виконання додавання та множення не потрібно вводити перенесення, і що квадратування у двійковій області є дуже ефективним, оскільки дотримується спрощеного правила (X + Y )2 = X2 + Y 2.

Як показано на малюнку 1, 128-бітний рядок: цей рядок може бути проінтерпретований кількома способами в контексті бінарного поля. Його можна розглядати як унікальний елемент в 128-бітному бінарному полі або розглядати як два елементи поля з 64 біт, чотири елементи поля з 32 біти, 16 елементів поля з 8 біт або 128 елементів поля F2. Гнучкість такого представлення не вимагає жодних обчислювальних витрат, просто типове перетворення рядка бітів (typecast) є дуже цікавим і корисним атрибутом. Водночас елементи малих полів можуть бути упаковані в більші елементи полів без додаткових обчислювальних витрат. Протокол Binius використовує цю особливість для підвищення обчислювальної ефективності. Крім того, стаття "On Efficient Inversion in Tower Fields of Characteristic Two" досліджує обчислювальну складність множення, піднесення до квадрату та знаходження обернених елементів у n-бітних стовпчастих бінарних полях, розкладених на m-бітні підполя (.

![Bitlayer Research: Аналіз принципів Binius STARKs та його оптимізаційні роздуми])https://img-cdn.gateio.im/webp-social/moments-5775a629f494c4e01e2b74d864fa4100.webp(

) 2.2 PIOP: адаптована версія HyperPlonk Product та PermutationCheck------підходить для бінарного поля

Дизайн PIOP в протоколі Binius запозичив HyperPlonk, використовуючи ряд основних механізмів перевірки для верифікації правильності поліномів і множин з кількома змінними. Ці основні перевірки включають:

  1. GateCheck: перевірка конфіденційного свідчення ω та публічного введення x на відповідність обчислювальному зв'язку C(x,ω)=0, щоб забезпечити правильну роботу схеми.

  2. PermutationCheck: перевірка, чи результати обчислення двох багатозмінних поліномів f і g на булевому гіперкубі є відношенням перестановки f(x) = f###π(x)(, щоб забезпечити узгодженість перестановок між змінними поліномів.

  3. LookupCheck: перевірка значення многочлена наявності в заданій таблиці пошуку, тобто f)Bµ( ⊆ T(Bµ), забезпечуючи, що певні значення знаходяться в заданому діапазоні.

  4. MultisetCheck: перевірка на рівність двох мультимножин, тобто {)x1,i,x2,(}i∈H={)y1,i,y2,(}i∈H, забезпечуючи узгодженість між кількома множинами.

  5. ProductCheck: Перевірка, чи дорівнює значення раціонального многочлена на булевому гіперкубі певному заявленому значенню ∏x∈Hµ f)x( = s, щоб забезпечити правильність добутку многочлена.

  6. ZeroCheck: перевірити, чи є значення багатозмінного полінома у будь-якій точці на булевому гіперкубі нулем ∏x∈Hµ f)x( = 0, ∀x ∈ Bµ, щоб забезпечити розподіл нулів полінома.

  7. SumCheck: Перевірка того, чи дорівнює сума значень багатовимірного многочлена заявленому значенню ∑x∈Hµ f)x( = s. Зменшує обчислювальну складність для перевіряючої сторони, перетворюючи задачу оцінки багатовимірного многочлена на задачу оцінки одномірного многочлена. Крім того, SumCheck також дозволяє обробку пакетів, вводячи випадкові числа для побудови лінійних комбінацій, що реалізують обробку кількох прикладів перевірки суми.

  8. BatchCheck: на основі SumCheck, перевірка правильності оцінок кількох багатозмінних поліномів для підвищення ефективності протоколу.

Незважаючи на те, що Binius має багато спільного з HyperPlonk в дизайні протоколу, Binius вдосконалює в наступних 3 аспектах:

  • ProductCheck оптимізація: у HyperPlonk ProductCheck вимагає, щоб знаменник U був ненульовим на всьому гіперкубі, і добуток повинен дорівнювати певному значенню; Binius спростив цей процес перевірки, спеціалізуючи це значення на 1, що зменшує обчислювальну складність.

  • Обробка проблеми ділення на нуль: HyperPlonk не зміг належним чином обробити ситуації ділення на нуль, що призвело до неможливості стверджувати, що U є ненульовим на гіперкубі; Binius правильно обробив цю проблему, навіть у випадку, коли знаменник дорівнює нулю, ProductCheck Binius також може продовжувати обробку, що дозволяє узагальнити на будь-яке значення добутку.

  • Пермутаційна перевірка між стовпцями: HyperPlonk не має цієї функції; Binius підтримує Пермутаційну перевірку між кількома стовпцями, що дозволяє Binius обробляти більш складні випадки перестановки многочленів.

Отже, Binius покращив існуючий механізм PIOPSumCheck, підвищивши гнучкість і ефективність протоколу, особливо при обробці більш складних багатозмінних поліноміальних перевірок, надаючи більш потужну функціональну підтримку. Ці покращення не лише вирішили обмеження HyperPlonk, але й заклали основу для майбутніх систем доказів на основі двійкових полів.

) 2.3 PIOP: новий багатократний зсувний аргумент------підходить для булевого гіперкуба

У протоколі Binius віртуальні багаторазові

Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 3
  • Поділіться
Прокоментувати
0/400
ETHReserveBankvip
· 22год тому
у блокчейні вартість зменшилася, хто не радий цьому?
Переглянути оригіналвідповісти на0
ChainChefvip
· 07-31 16:01
готуючи деяку свіжу альфу тут... binius виглядає як ідеально зменшений соус в порівнянні з тими роздутими 252-бітними рецептами, чесно кажучи
Переглянути оригіналвідповісти на0
DegenWhisperervip
· 07-31 15:38
А це оптимізація справді погана
Переглянути оригіналвідповісти на0
  • Закріпити