Поради з читання

· Перш ніж читати цю статтю, вам потрібно мати базове розуміння MEV

· Бути ознайомленим з транзакціями Ethereum та розуміти, що містить транзакція та як вона врешті-решт уключена в блок

· Дізнайтеся про дерево Меркла та роль доказу нульового знання

· натисніть, щоб прочитати: MEV (5): Більш справедлива екосистема MEV (Частина 1)

Попередня стаття представила (1) дизайн Flashbot SGX Builder, який забезпечує справедливість блок-будівництва за допомогою надійного обладнання, та (2) дизайн Chainlink FSS, який запобігає MEV шляхом децентралізації ролей упорядкування транзакцій.

Ця стаття буде обговорювати (3) дизайн Зашифрованих Mempool, який спрямований на зменшення або усунення MEV шляхом забезпечення конфіденційності транзакцій за допомогою криптографічних методів.

Зашифровані пули пам'яті

Два цілі: захист MEV та опір цензурі

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

Зашифровані мемпули використовують криптографію для (1) шифрування вмісту транзакції користувача задля захисту їх конфіденційності та (2) перевірки валідності транзакції під час її шифрування, що запобігає нападам, спрямованим на генерацію великої кількості недійсних, але зашифрованих транзакцій. Це завдає перешкоди їм у запуску атаки DoS на ланцюжок, оскільки Пропозер витрачав би місце блоку на включення великої кількості недійсних транзакцій, які виявляються лише у останній момент.

Порада з читання: просте шифрування не може повністю гарантувати опір цензурі, оскільки Пропозиція, яка хоче цензурувати, все ще може відмовлятися приймати будь-які зашифровані транзакції, тому шифрування лише збільшує вартість цензури (Пропозер відмовляється від комісійних за всі зашифровані транзакції). Щоб забезпечити кращий захист від цензури, вам потрібно використовувати список включень, такий як PBS.

Забезпечте можливість розшифрування транзакцій (Гарантоване розшифрування)

Після шифрування транзакції важливо переконатися, що її можна розшифрувати. Невиконання цього може створити вразливість у атаки відмови в обслуговуванні (DoS). У такій атаки зловмисник постійно відправляє зашифровані транзакції, які не можуть бути розшифровані. В результаті вузол повинен зберігати ці транзакції до їхнього закінчення терміну дії, що призводить до накопичення цих непотрібних транзакцій у пулі транзакцій вузла.

Є кілька способів забезпечити можливість розшифрування транзакцій:

1. Чиста довіра (У польоті)

2. Довірний апаратний засіб, Енклейв

3. Поріг Шифрування/Дешифрування

4. Затримка шифрування/розшифрування

5. Шифрування/дешифрування свідків

△ Кілька способів забезпечити розшифрування транзакцій та їх приклади. Складність зростає зліва направо, де чиста довіра є найпростішою, а свідчення про розшифрування - найскладнішою.

Джерело зображення:https://www.youtube.com/watch?v=XRM0CpGY3sw

Зобов'язати-розкрити

Чи може механізм виправдання зобов'язанням також досягти того ж самого? Користувач починає, введенням свого вмісту транзакції в хеш-функцію, отримувати значення хешу, відоме як зобов'язання. Як тільки пропонент гарантує включення зобов'язання користувача до транзакції в блок, користувач продовжує розголошувати повний вміст транзакції.

Порада з читання: Шлях зобов'язання може бути схожим на Пропозера в PBS, який обіцяє, що це буде включено в блок будівельника через підпис. Це гарантоване зобов'язання. Якщо Пропозер порушить обіцянку, його покарають.

△ Пропонент обіцяє отримати Зобов'язання транзакції Еліс

Хоча "Зафіксувати-виявити" та шифрування можуть виконувати ту ж саму функцію приховування вмісту транзакції користувача та запобігання видобутку та цензурі MEV, "Зафіксувати-виявити" не може гарантувати розшифрування, оскільки сила знаходиться в руках користувача. Користувач має можливість не розголошувати вміст, незалежно від того, навмисно він це робить чи ненавмисно.

Потреба в тому, щоб користувачі прикріплювали депозит і втрачали його, якщо вони не розкриються, може погіршити вже погане користувальницьке досвід зобов'язати-виявити.

△ Алісі не потрібно розголошувати свою транзакцію

1. Чиста довіра (у польоті)

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

Підказка при читанні: Ця централізована роль може бути, наприклад, Будівник PBS, Пропозер або Послідовник/Оператор Rollup.

2. Довірний апаратний засіб, Черепиця

Це працює так само, як чиста довіра, але краще, ніж чиста довіра, оскільки користувачі довіряють надійному апаратному забезпеченню та програмному коду, який воно виконує, а не довіряють особі, організації чи компанії.

3. Шифрування/Розшифрування за пороговим принципом

Chainlink FSS також використовує порогове шифрування та дешифрування, але в Chainlink FSS менеджери порогових ключів - це Оракули Chainlink, тоді як в Encrypted Mempools менеджери (званих Keypers) можуть бути Валідаторами L1 або L2 (з урахуванням, що L2 також має В разі децентралізованого Валідатора).

Порігове шифрування/розшифрування має кілька недоліків:

• Сильне чесне припущення більшості: Потрібно припустити, що більш як половина Кіперів є чесними. Якщо вони нечесні, вони можуть розшифрувати та переглядати транзакції користувачів за бажанням, переглядати транзакції або видобувати MEV транзакцій.
• Відсутність відповідальності: Доки достатня кількість учасників Keyper співпрацюють, вони можуть розшифрувати інформацію. Однак, якщо учасники Keyper участь в заговорі, ми не маємо способу знати, хто саме бере участь у змові. Без можливості ідентифікувати злочинних акторів, неможливо розробити механізм покарання для Keyper. Тому нам доводиться покладатися на припущення, що більшість учасників Keyper є чесними.
• Ослаблена живість: Інший великий відсутній Кіпер призведе до недостатньої кількості онлайн Кіперів, що заважатиме розшифруванню та виробленню блоків. Це призведе до зупинки ланцюга. Це суперечить механізму Ethereum PoS, який підкреслює, що ланцюг буде продовжувати виробляти блоки навіть у разі війни, і, в кінцевому підсумку, досягне остаточності. Можна зробити висновок, що ймовірність використання розшифрування з пороговим значенням у Ethereum PoS не висока.

Тому що шифрування та дешифрування порогового значення потребує багато змін, L2 підходить для цього підходу більше, ніж L1.

Ця стаття пропонує дизайн та врахування для впровадження в L1. Проєкти, які тестують цей дизайн, можуть посилатися на Shutter Network. Для отримання додаткової інформації, будь ласка, перевірте:https://ethresear.ch/t/shutterized-beacon-chain/12249

4. Затримка шифрування / дешифрування

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

Концепція запізненого шифрування схожа на функцію перевірки запізнення (VDF), обидві належать до сім'ї криптографії з відкладеним випуском.

VDF дозволяє нам швидко перевірити F(x): результат «часомитного послідовного обчислення». Це схоже на доказ роботи (PoW), але обчислення VDF - послідовний процес, на відміну від PoW, який може бути прискорений за допомогою паралельних обчислень. Розшифровувач VDF може виконувати лише повторні обчислення крок за кроком.

△ За допомогою VDF ви можете перевірити результат обчислення, яке мені знадобилося 10 секунд, за 0,01 секунди, і я не мав змоги паралельно обчислити. Джерело зображення:https://techtelegraph.co.uk/перевірні-функції-затримки-на-bitcoin

Затримане шифрування та дешифрування також є постійними обчисленнями, схожими на VDF, і не можуть бути прискорені за допомогою паралельних операцій. Однак треба враховувати, що хтось прискорить процес дешифрування через оптимізацію апаратного забезпечення. Тому, якщо ви хочете використовувати цю технологію та застосовувати її в реальному публічному середовищі, вам потрібно забезпечити, щоб у нікого не було великої апаратної переваги і не міг завершити дешифрування заздалегідь (і дешифрування виконується в приватності, тому його важко виявити).

Наразі Ethereum Foundation та Protocol Labs вже співпрацюють у дослідженні чіпів VDF ASIC з метою експорту найбільш передового обчислювального обладнання на ринок, щоб ніхто не мав різницевих апаратних переваг і не розшифровувався таємно напередодні. Дізнайтеся більше за посиланням: https://filecoin.io/blog/posts/collaboration-with-the-ethereum-foundation-on-vdfs/

Порада щодо читання: VDF також може бути використаний для збільшення непідкупності випадкових чисел Ethereum.

Перевага відкладеного шифрування та дешифрування у порівнянні з пороговим шифруванням та дешифруванням полягає в тому, що для його роботи не потрібно довіряти або покладатися на нормальне функціонування групи Keypers і він автоматично розшифрується, коли настав час. Однак цей обов'язковий час розшифрування також є недоліком відкладеного розшифрування: зашифровані транзакції повинні бути розшифровані протягом певного часу, що означає наявність фіксованого часового затримки для завантаження транзакцій користувачів на ланцюг. Крім того, конкуренція у сфері апаратних засобів також є ризиком, який не можна ігнорувати в цьому методі. Важко знати, чи хтось розробив швидший чіп для розшифрування.

5. Шифрування/розшифрування свідка

Уявіть, що криптотекст не розшифровується ключем або послідовним обчисленням, а може бути розшифрований лише тоді, коли виконується певна «умова», наприклад, «коли це рівняння вирішено» або «коли це рівняння вирішено». Як тільки криптотекст включено в блок, його можна розшифрувати і так далі.

Підказка для читання: «Знання ключа для розшифрування шифротексту» або «знання результатів постійних обчислень» фактично є умовою.

Через шифрування свідків ми можемо не лише досягти ефектів порогового шифрування та відкладеного шифрування, але також можемо поєднати ці два методи декодування. Наприклад, ми можемо встановити умови як «Умова 1: «Група Кіперів погоджується на декодування цього шифротексту» або Умова 2: «Після п'яти хвилин»»: Якщо всі Кіпери на мережі, ми можемо швидко відповісти на Умову 1 для декодування шифротексту. Однак, якщо Кіперів на мережі недостатньо, ми принаймні можемо забезпечити виконання Умови 2 та декодувати, довівши за допомогою VDF, що «пройшло п'ять хвилин».

△ Достатньо Keypers можна розшифрувати в Інтернеті (вище) або після достатнього часу (нижче)

Якщо умови виявляються виконаними, можливо досягти розшифрування. Доказ можна здійснити за допомогою методів, таких як докази з нульовим відомості, які можуть ефективно перевіряти складні обчислення (з урахуванням того, що операції, необхідні для доведення умов, є складними) або приховувати інформацію (з урахуванням того, що доказуючий не хоче розкрити певну інформацію під час процесу доказу). Однак, навіть якщо шифрування свідків є дуже потужним, поточна технологія недостатня для надання будь-якого практичного використання.

△ Зрілість різних технологій шифрування та дешифрування. Свідчення про шифрування та дешифрування (Свідок) ще не досить зрілі. Джерело зображення:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_591

Маніпулювати та виконувати операції з шифрованим текстом за допомогою гомоморфного шифрування

Попередні абзаци представляли різні способи забезпечення можливості розшифрування транзакцій, але коли транзакції можуть бути розшифровані? Відповідь така: після того, як транзакція включена в блок і встановлено порядок. Але як Блок-будівник складає блок з купи абракадабри, або навіть ефективно складає високовигідний блок? Відповідь така: Гомоморфне шифрування (HE).

△ Приклад гомоморфного шифрування, використаного для голосування: Зміст голосування було зашифровано, але шифртекст все ще може бути підсумований та розшифрований після обчислення результату. Джерело зображення:https://twitter.com/khushii_w/status/1660278622291210242

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

За допомогою гомоморфного шифрування ми можемо виконувати операції з криптотекстом без розшифрування транзакції. Ми можемо застосовувати процес операцій з розташування транзакцій та формування законного блоку до цих зашифрованих транзакцій без розшифрування транзакції та отримувати зашифрований блок транзакцій. Після розшифрування блоку ми отримаємо повний та законний блок, в якому транзакції розшифровані та відсортовані в тому порядку, як перед шифруванням.

△ Через гомоморфне шифрування Block Builder може зібрати повний та законний блок з зашифрованих транзакцій

Порада з читання: Існують рівні гомоморфного шифрування, такі як часткове гомоморфне шифрування (Частково ГШ) та повне гомоморфне шифрування (Повністю ГШ). Часткове гомоморфне шифрування може лише додавати або множити шифротекст, тоді як повне гомоморфне шифрування може додавати та множити шифротекст (в основному, будь-яка операція може бути виконана).

△ Третій стовпчик: Зрілість різних технологій шифрування та дешифрування, що підтримують FHE. За винятком політів та околиці, які не потребують HE та, отже, вважаються підтримуваними, інші ще не доступні. Джерело зображення:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_620

Вищевказане вводить різні механізми шифрування та дешифрування транзакцій. У кожного з них є свої переваги та недоліки, але в кінцевому підсумку все, що вони можуть зробити - це приховати вміст транзакції та забезпечити можливість розшифрування, коли виконуються умови. Якщо вміст транзакції заховано, його можна уникнути розшифрування. Вилучення MEV та ризики цензури.

Проте самі дані транзакції матимуть відповідні метадані, такі як ініціатор транзакції, комісія за транзакцію або підпис, які використовуються для перевірки правомірності транзакції. Крім того, IP-адреса ініціатора також є формою метаданих, а також обсяг даних транзакції. Усі ці метадані мають потенціал витікати конфіденційні дані користувача, тому ми також повинні захищати ці метадані.

Переконайтеся, що метадані не витікають приватність

Нижче наведено різноманітні метадані зашифрованих транзакцій та відповідні заходи захисту, які потребуватимуть криптографічних технік, таких як гомоморфне шифрування та докази знань нуля.

1. IP адреса

2. Підпис угоди

3. Вартість транзакції

4. Ініціатор транзакції та його значення Nonce

5. Розмір транзакції

△ Різні метадані транзакцій можуть витікати особисті дані користувачів. Джерело зображення:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_709

IP-адреса

Мережа, до якої підключається користувач для відправки зашифрованих транзакцій, може розкрити ідентичність користувача на основі його IP-адреси та може бути цензурована. Захист конфіденційності на рівні мережі ґрунтується на технологіях, таких як Tor.

Підпис транзакції, комісія за обробку, ініціатор транзакції та його значення Nonce

Ці метадані використовуються для підтвердження валідності транзакції, але вони розкриють ідентичність користувача, тому вони повинні бути зашифровані. Після шифрування ми повинні використовувати інші інструменти для підтвердження валідності транзакцій без розкриття цієї інформації. В іншому випадку мережа може бути атакована методом DoS і заповнена купою недійсних транзакцій, які виявляються лише після розшифрування.

Коли вузол отримує зашифровану транзакцію, він спочатку повинен (1) підтвердити, що ініціатор транзакції дійсно ініціював транзакцію, тобто перевірити підпис транзакції, а потім (2) підтвердити, що ініціатор має достатньо ETH для оплати транзакції (баланс користувача ≥ вартість газу * ліміт газу), і (3) перевірити значення nonce відправника для уникнення атак повторного відтворення транзакцій.

Доказ з нульовим знанням

Ми можемо використовувати докази з нульовим розголошенням, щоб довести, що транзакції проходять ці перевірки, не розголошуючи цю інформацію. Доказ з нульовим розголошенням складається з публічної інформації (Публічний ввід), приватної інформації (Приватний свідок) та твердження, яке доказ хоче довести (Твердження).

△ Наприклад, публічна інформація (публічний вхід) є зашифрованою транзакцією (шифротекст tx), приватна інформація (приватний свідок) є незашифрованою транзакцією (tx шифротекст), а твердження (zk-твердження), яке має бути доведено цим доказом із нульовим розголошенням, — це «це «Зашифровані транзакції є законними» (tx шифротекст дійсний). Джерело зображення:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_391

Наприклад, якщо Аліса хоче довести Бобу, що в неї є більше 10 ETH, але не хоче розкривати свою адресу, вона може використовувати докази з нульовим розголошенням, щоб довести Бобу, що насправді її адреса має баланс більше 10 ETH.

"Довести, що адреса Еліс має баланс більше 10 ETH" - це заява (заява zk), яку потрібно довести цим доказом в нульовому знанні. Щоб згенерувати цей доказ, Еліс повинна надати свою адресу та доказати, що вона володіє приватним ключем цієї адреси (наприклад, використовуючи приватний ключ, генерує підпис), а також потрібно надати баланс ETH цієї адреси, наприклад, використовуючи доказ Меркла, щоб підтвердити, скільки ETH утримує ця адреса у 1001-му блоку.

Адреса, підпис та доказ Меркла не можуть бути розголошені та є конфіденційною інформацією (приватний свідок).

Коли це докази будуть надані, Боб зможе перевірити цей доказ за допомогою Мерклівського кореня (званого коренем стану) дерева стану блоку 1001. Будь-хто знає Корінь Стану кожного блоку, який є публічною інформацією (публічний ввід).

Єдина інформація, яку знає Боб, - це публічна інформація про корінь стану та результати перевірки. Він не буде знати жодної приватної інформації про Еліс.

△ Еліс надає два приватних входи: доказ Меркла та підпис; Боб надає публічний вхід кореню стану. Заява zk може підтвердити, що у Еліс є адреса, а баланс адреси > 10 ETH

(1) Перевірте підпис транзакції

Перевірка підпису транзакції складається з двох частин: (a) ініціатор транзакції є законним, і (b) підпис транзакції підписаний ініціатором транзакції.

(а) Головним чином для перевірки того, що адреса Ethereum ініціатора транзакції є законною адресою, а не випадковим числом. Це доведе через доказ Меркля, що адреса існує в дереві стану Ethereum.

(b) Перевіряє, що підпис транзакції підписаний приватним ключем ініціатора транзакції.

△ Це підтвердження перевіряє (a) адресу ініціатора транзакції (через доказ Меркла відправника публічного ключа) і (b) легітимність підпису в межах транзакції (підпис буде включено в текст тх). Текст тх - це сирі незашифровані дані транзакції, які є конфіденційною інформацією, наданою ініціатором транзакції.

Джерело зображення:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_736

Порада з читання: червоний текст на зображенні вище вказує на те, що означає цей сертифікат після проходження верифікації (тобто «підпис транзакції є законним»). Це не є частиною zk-заяви. Синій блок містить інформацію, що стосується самої транзакції, включаючи зашифровані (публічні) дані транзакції та незашифровані (приватні) дані транзакції. Зелений блок - це додаткові дані, необхідні для завершення доказу, як публічні, так і приватні.

△ Доведіть, що адреса ініціатора транзакції існує в дереві станів Ethereum і що ініціатор транзакції дійсно має приватний ключ місця

(2) Підтвердіть, що ініціатор транзакції має достатньо ETH для оплати комісії за обробку

Точно так само, як у попередньому прикладі з Алісою та Бобом, що доводить, що баланс > 10 ETH, ініціатор транзакції повинен надати доказ Меркла балансу своєї власної адреси, а твердження, яке потрібно довести, таке: "баланс адреси ≥ комісія за транзакцію." Комісія за транзакцію дорівнює ціні газу, помноженій на ліміт газу. Інформація як про ціну газу, так і про ліміт газу включена в початкові незашифровані дані транзакції (tx plaintext). tx plaintext є конфіденційною інформацією, яку надає ініціатор транзакції.

△ Це доказ підтверджує, що баланс адреси ініціатора транзакції (через доказ балансу відправника Merkle) більший або рівний комісії за транзакцію (інформація про комісію за транзакцію включена в tx звичайний текст). Джерело зображення:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_743

△ Довести баланс адреси ініціатора транзакції > ціну газу

(3) Перевірте значення Nonce ініціатора транзакції

Оскільки Nonce також записаний в стані Ethereum, Merkle Proof також використовується для підтвердження поточного значення Nonce ініціатора транзакції, а потім порівняти його зі значенням Nonce, вказаним у транзакції, щоб підтвердити, що транзакція не була повторно відтворена.

△ Це доказ порівнює значення Nonce адреси ініціатора транзакції (через доказ Merkle Nonce) та значення Nonce, вказане в транзакції (значення Nonce, вказане в транзакції, включене в текст tx). Джерело зображення:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_327

△ Довести nonce адреси ініціатора транзакції = tx nonce

Проте ця перевірка не може запобігти злоякісним нападникам у генерації кількох транзакцій з тим самим значенням Nonce (ці транзакції всі можуть пройти перевірку значення Nonce) для проведення атак DoS, тому нам потрібно додати додаткові перевірки.

Ми вимагаємо, щоб ініціатор транзакції надав ще один Replay Tag, щоб забезпечити, що буде лише одна транзакція з таким же значенням Nonce. Replay Tag - це хеш-значення значення Nonce та приватного ключа ініціатора транзакції: replay tag = H (nonce, приватний ключ), тому різні значення Nonce того ж ініціатора транзакції будуть відповідати унікальному Replay Tag.

Отже, вузли можуть використовувати мітку відтворення, щоб визначити, чи ініціатор транзакції ініціював кілька транзакцій з однаковим значенням Nonce (мітки відтворення цих транзакцій будуть однаковими) і відхилити другу транзакцію з такою самою міткою відтворення.

△ Це доказ дозволить обрахувати теґ повторення та порівняти його з теґом повторення, переданим громадським вводом. Значення Nonce транзакції міститься в tx plaintext, а приватний ключ міститься в приватному свідку.

Джерело зображення: https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_750

△ Доведіть nonce адресата транзакції = tx nonce та тег повторення = H(nonce, ключ)

Або якщо ми вважаємо, що ініціатор транзакції може захотіти замінити транзакцію з тією ж значенням Nonce іншою транзакцією, можливо, тому що він не хоче виконувати початкову транзакцію, або він хоче збільшити ціну газу, щоб транзакцію можна було зібрати швидше.

У цей час ми можемо ввести значення PoS слота в розрахунок Replay Tag: replay tag = H(nonce, private key, slot). Наприклад, Боб відправив транзакцію з Nonce 5 в слоті 1001, але вона ще не була отримана, тому він вирішив подвоїти ціну на газ транзакції, залишивши інші поля незмінними, і відправив оновлену транзакцію в слот 1005. Транзакція, і оскільки слот змінився, тег Replay відрізняється, і ця нова транзакція не буде відхилена, оскільки значення Nonce те саме.

△ Громадський ввід буде передавати додаткові значення слотів для обчислення тегу повторення. Джерело зображення:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_757

5. Розмір транзакції

Деякі методи шифрування зроблять розмір зашифрованих даних транзакції таким самим, як до шифрування. Однак є ще ймовірність виведення деякої інформації через розмір. Наприклад, дані транзакції транзакції, виконаної в Uniswap, повинні бути більшими, ніж дані транзакції простого переказу ETH. Таким чином, розмір транзакції такий самий, як метадані, які можуть витікати приватність.

Інтуїтивний підхід полягає в тому, щоб виконати дію з заповнення даних транзакції перед їх шифруванням, наприклад, заповненням купи нулів до тих пір, поки розмір транзакції не стане степенем двійки, або навіть заповненням його до фіксованого розміру. Це зменшує ймовірність того, що спостерігач визначить транзакцію за її розміром. Block Builder об'єднає заповнені транзакції в блок.

△ Білий є відступом. Сині та помаранчеві угоди однакового розміру, тому немає способу відрізнити їх за розміром. Джерело зображення:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_860

Проте недоліки цього підходу полягають у тому, що (1) він неефективний через те, що багато місця в блоку буде витрачено на додавання проміжків, і (2) він може не забезпечувати достатнього захисту конфіденційності. Наприклад, розмір червоної транзакції на зображенні вище (чотири квадрати) може бути рідкісним, тому його все ще можна вгадати. Якщо всі транзакції будуть додані до фіксованого розміру (наприклад, 64 блоки), конфіденційність покращиться, але це стане відносним витратою місця в блоках.

△ Недолік полягає в неефективності та обмеженій конфіденційності. Джерело зображення: https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_812

Кращим підходом є спочатку заповнення транзакцій до фіксованого розміру, але для вилучення відступів можна використовувати гомоморфне шифрування.

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

△ Використовуйте гомоморфне шифрування для видалення додавання під час об'єднання зашифрованих транзакцій. Джерело зображення:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_908

Порада з читання: Блок-будівельник з чистим довір'ям або довіреним апаратним забезпеченням може досягти того ж ефекту без гомоморфного шифрування (нарешті, всім довіряють).

Як Block Builder будує ефективні блоки

Незважаючи на те, що ми можемо ефективно об'єднувати зашифровані транзакції в блок за допомогою гомоморфного шифрування, все ще є деякі проблеми, які потрібно вирішити, наприклад, (1) різні транзакції можуть читати та записувати один і той самий стан (наприклад, усі вони торгуються на Uniswap) , що може призвести до того, що транзакції з нижчим рейтингом з більшою ймовірністю зазнають невдачі, і (2) Block Builder не може збирати транзакції відповідно до рівня комісії за обробку.

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

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

△ Плата за обробку та Список доступу визначає, які транзакції збираються та в якому порядку вони збираються. Джерело зображення:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1133

Час, коли відбувається транзакція

Якщо ми турбуємося, що час, коли шифровані транзакції відправляються в мережу p2p, може витікати приватність (наприклад, Аліса проводить транзакції о UTC+8 00:00–04:00), ми можемо попросити Валідаторів регулярно відправляти купу зашифрованих фіктивних транзакцій, щоб заплутати спостерігача.

Фіктивна транзакція буде потрібно додати з доказом з нульовим відомостями, щоб довести, що вона була відправлена валідатором та обмежити частоту, щоб запобігти заповненню мережі Фіктивними транзакціями (спостерігачі не будуть знати, що це Фіктивна транзакція, тільки що вона є "законною та валідною").

Під час гомоморфного шифрування групового блоку фіктивна транзакція буде ідентифікована та відкинута.

△ Валідатори регулярно відправляють (сірі) фіктивні транзакції, щоб збентежити спостерігачів, але це збільшує навантаження на мережу та вузли. Джерело зображення:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1210

Зашифровані Mempools проти FSS

У попередній статті також було введено FSS, що FSS також буде шифрувати транзакції спочатку, а потім передавати їх Chainlink Oracle для сортування. Процес шифрування транзакцій FSS та перевірки правильності зашифрованих транзакцій фактично такий самий, як і Encrypted Mempools, за винятком:

• Шифрування транзакцій FSS не згадує про захист метаданих, тоді як зашифровані Mempools приховують метадані та використовують докази з нульовим відомостями для підтвердження валідності транзакції.
• FSS в даний час використовує Шифрування/Дешифрування за порогом та спільно розшифровується Оракулом Chainlink, що означає, що ви повинні довіряти Оракулу Chainlink. Зашифровані Mempools не вказують, як сортувати, а лише акцентують на шифруванні транзакцій та підтвердженні їх валідності за допомогою доказів з нульовим розголосуванням.
• У порівнянні з FSS, яке наголошує лише на "справедливості", Зашифровані пулі пам'яті надають більший акцент на "як ефективно збирати вміст блоку та як дозволити Пропозеру зібрати найбільш вигідний блок замість простого випадкового визначення порядку транзакцій."

У майбутньому FSS також може використовувати технологію в зашифрованих пам'ятках для покращення або заміни шифрування та розшифрування транзакцій.

Боротьба з MEV за допомогою криптографії

Цей доповідь про зашифровані пам'ятки, де автор ділиться, як криптографічні техніки та поліпшення в рівні консенсусу Ethereum можуть допомогти боротися з проблемами, спричиненими MEV. Для отримання деталей перевірте:https://www.youtube.com/watch?v=mpRq-WFihz8

Огляд та основні моменти

1. Мета зашифрованих пулів пам'яті полягає в захисті від MEV та цензури шляхом шифрування транзакцій. Інші можуть знати лише те, що ваші транзакції є валідними, але вони не можуть знати, які дії ви виконуєте в межах своїх транзакцій.

2. Проте, щоб дійсно досягти ефективного опору цензурі, потрібно використовувати механізм, такий як Список включення PBS. В іншому випадку Будівельник все ще може здійснювати цензуру, відмовляючись приймати зашифровані транзакції.

3. Не легко довести, що зашифрована транзакція є дійсною. Щоб довести підпис транзакції, значення Nonce ініціатора транзакції, достатню комісію, тощо, потрібно кілька нульових доказів знань.

4. Крім того, необхідно уникати витоку метаданих, таких як IP-адреса, розмір даних транзакції або час надсилання транзакції, щоб не порушувати конфіденційність транзакції.

5. Наостанок, найважливіше - це забезпечити можливість розшифрування операцій - Гарантоване шифрування. Існує п'ять різних методів: Чиста довіра (у польоті), Довірений апаратний анклав, Порігове шифрування/дешифрування, Затримка шифрування/дешифрування та Шифрування/дешифрування свідків. Кожен метод має свої переваги та недоліки.

Посилання на дані та рекомендована додаткова література

Зашифровані пулі пам'яті

• https://www.youtube.com/watch?v=XRM0CpGY3sw
• https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_639
• Як криптографія допомагає вирішити проблеми, спричинені MEV з рівня застосунків та рівня згоди:https://youtu.be/jLHf6yw7b5Y?t=4139

Особлива подяка Стівену Ву, Кімі Ву, Кевіну Май-Шуан Чіа та Антону Ченгу за перегляд та вдосконалення цього повідомлення.

Disclaimer：

1. Ця стаття переписана з [techflowpost]. Усі авторські права належать оригінальному автору [Will 阿望;Діана Ченґ]. Якщо є заперечення стосовно цього перепублікування, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно займуться цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, що належать автору і не становлять жодної інвестиційної поради.
3. Переклади статей на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.