Як представник маршруту розширення Rollup у L2, після аірдропу Arbitrum буде запущено zkSync Era. Що стоїть за безкінечними новими дизайнами та дорожніми картами, що є основною лінією Rollup і яке еволюційне мислення? Давайте подивимося сьогодні.
Основні моменти цієї статті:
Ідея розширення L1, написана для третього класу
Створіть зведене рішення з нуля
Як використовувати підтвердження нульового знання, щоб знову розвивати Rollup
Починаючи з аналогії
Щодо біткойнів та Ethereum, з моменту їх народження, є дві найбільші критики з боку простих користувачів:
Повільно: спочатку смуга вузька, і якщо машин забагато, вона буде заблокована.
Дорогий: Плата за проїзд на плоских вершинах недешева. Якщо ви хочете швидко проїхати в період піку, вам потрібно використовувати «грошову здатність», щоб додати гроші, і дозволити шахтарям керувати гелікоптерами, щоб дістатися до вас.
Ці дві критики випливають з двох факторів у дизайні блокчейна:
Місткість блоку: аналогічно смузі, чим більша місткість блоку, тим більше автомобілів він може вмістити, і тим менша ймовірність його блокування.
Механізм заохочення: незалежно від того, наскільки великий під’їзд, є ймовірність бути заблокованим. У цьому випадку кому дозволено пройти першим? Це залежить від того, хто поспішає, але ви не можете просто слухати слова людей , це залежить від готовності платити, наприклад виклик швидкої. Це буде кілька сотень.
Якщо блокчейн справді може бути схожим на під’їзну доріжку, тоді фундаментальним рішенням є, природно, розширити під’їзну доріжку та в той же час співпрацювати з ціновими засобами, щоб визначити час, щоб вийти, і не виходьте, якщо ви не в поспішати.
Однак, незважаючи на те, що розширення смуг і збільшення пропускної здатності блоку є привабливим рішенням для підвищення ефективності трафіку, це крайній засіб у дизайні блокчейна. Оскільки чим більший розмір блоку, тим вищі вимоги до обладнання для майнерів і тим менше майнерів можуть відповідати вимогам; згідно з цією ідеєю, якщо ви хочете обробляти тисячі транзакцій за секунду, як Visa, ви лише зробите іншу централізована система Visa суперечить основній меті недовіри блокчейну.
Чи є якесь інше рішення? Так, окрім орієнтування за часом, ми також можемо оптимізувати простір, включаючи, але не обмежуючись:
Відкрийте різні смуги, одну для великих вантажівок, одну для легкових автомобілів і одну для автобусів, не заважаючи одна одній — виходячи з цієї ідеї, ми можемо прийти до деяких основних ланцюгів, бічних ланцюгів або плазми з їхніми власними перевагами.
Оптимізуйте дизайн маршруту, перенаправте трафік належним чином, не їдьте в місто, щоб щось робити, вам потрібно їхати цією головною дорогою, вам потрібно пройти через контрольно-пропускний пункт тут —— Виходячи з цієї ідеї, ми можемо шардувати.
Чому ти маєш виходити? Ще не пізно провести віддалену зустріч і домовитися, і не пізно підписати угоду офлайн——Виходячи з цієї ідеї, ми можемо мати державний канал (Державний канал).
Вам не обов’язково їхати самостійно, коли ви виходите на вулицю, ви також можете спільним використанням автомобіля або громадським транспортом —— Виходячи з цієї ідеї, у нас є головний герой цієї статті, Rollup.
Як шина в блокчейні, ключем до Rollup є економія місця та бензину (газ, каламбур):
Економте простір, тому нелегко застрягти, а плата, яку ділить кожна особа, набагато менша, ніж їздити самостійно;
Економиться бензин, тому ціна квитка наближена до людей, і кожен може собі це дозволити.
Таким чином, два слоти «повільний» і «дорогий» вирішуються Rollup.
Давайте повернемося до блокчейну і подивимося на конкретний план Rollup.
Створіть зведене рішення з нуля
Замість того, щоб підглядати за стандартною відповіддю (не кажучи вже про те, що її немає), краще поміркувати й уявити, що ви будете робити, коли вам доручать розробити Rollup для Ethereum.
Ми також могли б почати з двох точок зору: зменшення витрат на обчислення (економія бензину) і зменшення витрат на зберігання (економія місця), і спочатку запропонувати більш радикальне рішення під назвою Rollup 1.0.
Зведення 1.0
Зведений пакет 1.0 складається з 3 основних пунктів:
Існує постачальник послуг (Оператор), який збирає всі транзакції «спільного використання» (Transaction) і «надсилає замовлення», коли спільне використання автомобілів заповнене чи ні, але узгоджений час минув, беручи до уваги ціну та своєчасність;
Усі розрахунки, пов’язані з транзакціями, поданими всіма, виконуються цим постачальником послуг поза ланцюгом, оскільки розрахунки поза ланцюгом є швидшими, ніж у ланцюзі, і розрахунки часто складають основну частину витрат у ланцюзі, що може значно заощадити гроші;
Після розрахунку отримайте оновлений статус (наприклад, останній баланс у вашому обліковому записі) і збережіть його в ланцюжку, щоб вартість зберігання була набагато нижчою.
Простіше кажучи, це регулярний і кількісний збір запитів на транзакції кожного, і після обчислень поза ланцюгом лише результати розрахунків затверджуються в ланцюжку.
Це рішення ідеально вирішує дві головні проблеми: «повільно» та «дорого», але, здається, створює нові проблеми:
Стимул: хто надаватиме послугу «спільне використання автомобілів» і які переваги.
Проблема перегляду (цензура): Постачальник послуг навмисно не обробляє моє замовлення (або кладе трубку, чи виходить), що мені робити;
Проблема шахрайства (Шахрайство): що мені робити, якщо постачальник послуг обманює та змінює результати розрахунків, змушуючи мене переказувати гроші іншим особам, а він привласнює гроші.
Для цих трьох нових проблем ми можемо повторити версію плану.
Зведення 2.0
Найкраще вирішується проблема мотивації, а проблеми, які можна вирішити за допомогою грошей, не є проблемами. Постачальник послуг може порівну розподілити витрати на «спільне використання автомобілів» і стягувати трохи додаткових «чайових». Незважаючи на це, це все одно безпрограшна ситуація для особи, яка «користується спільним використанням».
Проблема перегляду є трохи складнішою, але рішення дуже поширене в області блокчейну, і це децентралізація. Група людей є постачальниками послуг, що краще, ніж лише один постачальник послуг; кожен може бути постачальником послуг, що краще, ніж фіксована група людей. В останньому варіанті гри, якщо всі постачальники послуг погані, ви також можете бути постачальником послуг самостійно або безпосередньо перейти до L1, щоб ініціювати арбітраж.
Шахрайство трохи складніше. Його можна розділити на два питання: одне — як виявити шахрайство, а інше — як йому запобігти.
По-перше, щоб виявити шахрайство, нам потрібно знати дані кожної транзакції (Transaction), стан до транзакції (State), щоб обчислити новий стан (State') після транзакції та використовувати його для зберігання це в ланцюжку постачальника послуг. У порівнянні з новим станом, якщо він такий самий, це означає, що постачальник послуг чесний, інакше це означає, що він збрехав. Однак ми не знаємо даних про транзакції, оскільки вони не в мережі. У результаті ми можемо бути лише скептичними та нездатними судити про те, чесним є постачальник послуг чи ні.
Далі, щоб запобігти шахрайству, найкращий спосіб – зробити шахрайство неможливим, що є складнішим, якщо розрахунок постачальника послуг не перевіряється щоразу в ланцюжку, але в цьому випадку немає переваг " спільне використання автомобілів" вгору. Тож ми можемо лише зробити крок назад і зробити ціну шахрайства дуже високою, щоб постачальники послуг мали можливість взяти участь у грі, наприклад, сплатити депозит (Stake), який буде конфісковано, якщо шахрайство буде виявлено. (Цей метод називається соціальним консенсусом, який відноситься до ігрової безпеки, і також згадувався в «Щотижневику №3».)
Зведення 3.0
Rollup 2.0 непоганий, але проблему виявлення шахрайства не вирішує.
Відповідно до попереднього висновку, щоб ідентифікувати шахрайство, ми повинні знати дані транзакції, тому ця частина даних має бути в тому ж ланцюжку, що й дані про стан.
Хто дізнається, що вони шахраї? Очевидно, що це навряд чи буде звичайний користувач, адже стежити за кожним кроком постачальника послуг 7х24 години неможливо, тому це може бути лише професійний «мисливець за головами» (Validator). Якщо «мисливець за головами» повідомить про шахрайство протягом 7 днів після того, як постачальник послуг «надішле замовлення» та переконається, що це правда, транзакцію буде відмінено, а постачальника послуг буде покарано. Звичайно, таким же чином «мисливцям за головами» також потрібні стимули. Наприклад, після виявлення шахрайства частина депозиту постачальника послуг буде передана «мисливцю за головами» (тільки частина, щоб уникнути змови між постачальник послуг і мисливець за головами).
Зведене оновлення 4.0
На стадії Rollup 3.0 все рішення працювало безперебійно, але з’явилися нові витрати. Поки що витрати включають:
Плата постачальникам послуг (включаючи витрати та «чайові»);
Вартість зберігання транзакцій і даних про стан у мережі;
Коли «Мисливець за головами» вважає, що постачальник послуг є шахраєм, обчислювальна вартість перевірки правдивості його сказаного в ланцюжку.
Давайте розберемося, які витрати можна оптимізувати.
дані транзакції
У певний спосіб кілька транзакцій об’єднуються разом, і займаний простір може бути меншим, ніж сума простору, зайнятого кожною транзакцією.
Беручи за приклад найпростішу транзакцію переказу ETH, ми розбираємо склад вмісту кожної транзакції, і бачимо, що простір для підписів становить найбільшу частку. Ми можемо об’єднати підписи всіх транзакцій в одну (агрегація ключів), що заощаджує багато накладних витрат на зберігання (подібно до Шнорра в біткойнах). Крім того, ми також можемо оптимізувати інші частини, як-от позбутися Nonce і вибрати якомога більше «товстий і худий» під час «спільного використання автомобіля», а також «особу для спільного використання», яка ідеально підходить для максимального використання «автомобіля». "простір.
джерело:
Лише три чи два рази розмір кожної транзакції переказу ETH було зменшено зі 112 байт до 12 байт, що майже на одну десяту від попереднього; звичайно, існують інші засоби для подальшого стиснення даних транзакції.
У реальній роботі ми можемо вставити такий метод у контракт, розгорнутий у ланцюжку:
функція storeTxData(bytes calldata data) external {// Нічого не потрібно}
Потім кожного разу, коли «спільне використання» є успішним, об’єднані та стиснуті дані транзакції передаються в цей метод як calldata. Calldata не потрібно зберігати постійно, і після Періоду виклику суспільного консенсусу (Challenge Period) не матиме значення, якщо їх обрізати (Prune); сама ціна дуже низька, і це буде дешевше з впровадженням EIP, такі як Danksharding і Data Blob, ця форма застосування L1 до розподілу сховищ даних (Доступність даних) також буде більш формальною.
дані про статус
Тепер, коли дані транзакцій завантажено в ланцюжок, будь-хто може обчислити оновлений стан за допомогою даних транзакцій, а дані стану не є такими необхідними. Ми можемо лише зберегти Merkel Root державних даних, які використовуються, щоб дозволити звичайним користувачам ("користувачам спільного використання") подавати заявки на зняття коштів безпосередньо в L1, коли постачальник послуг не співпрацює, і покладатися на Merkel Proof, щоб довести, що вони мають гроші на своїх рахунках.
АРБІТРАЖНІ ВИТРАТИ ЩОДО ШАХРАЙСТВА
Коли «мисливець за головами» повідомляє про шахрайство постачальнику послуг, розрахунок контракту в ланцюжку (Replay) виконується один раз і результати статусу порівнюються. Це теоретично можливо. Однак вартість цього не є низькою (хоча це вже добре), а по-друге, сума газу транзакцій, включених до «списку спільного використання», може перевищувати ліміт газу Ethereum, що унеможливлює перевірити.
Таким чином, арбітраж повинен зменшити тягар, і спосіб зменшити цей тягар, природно, полягає в тому, щоб виключити непотрібні розрахункові операції. Одне з рішень називається Interactive Proving. Загальний процес такий:
«Мисливець за головами» сплачує депозит, потім звітує та розбиває весь процес розрахунку на n сегментів по порядку, вказуючи, що постачальник послуг має шахрайство в сегменті k (1≤k≤n);
Постачальник послуг деталював і розібрав сегмент k на сегмент k і вказав, який сегмент «мисливця за головами» був неправильним;
Переходячи вперед і назад таким чином, знаючи, що обчислювальні операції більше не можна деталізувати та демонтувати, наприклад, коли демонтовано, «мисливець за головами» думає, що 1+1=2, а постачальник послуг думає, що 1+1=3;
У цей час втручається контракт у ланцюжку, розраховує 1+1 і отримує 2, таким чином визначаючи, що постачальник послуг є шахраєм, конфіскуючи його депозит і винагороджуючи його частину «мисливцю за головами».
(Протягом усього процесу, якщо одна сторона не відповість протягом тайм-ауту, ця сторона зазнає невдачі.)
Таким чином, арбітражна вартість у всьому ланцюжку є дуже, дуже низькою.
Сказавши це, ми повністю створили зведене рішення. Оскільки ця схема передбачає, що постачальник послуг є чесним за замовчуванням, якщо немає звіту «мисливця за головами», ця фракція називається зведенням оптимістів, так званим Optimistic Rollup.
Отже, чи є наш Rollup 4.0 найкращим рішенням?
Повторна еволюція зведеного пакета
Після багатьох ітерацій Rollup 4.0 все ще має деякі недоліки:
Шахрайство має бути виявлено «мисливцями за головами», але якщо шахрайства не буде протягом тривалого часу, «мисливці за головами» можуть припинити роботу, оскільки вони нерентабельні, тож виникне розрив (хоча малоймовірний, через Зацікавлені сторони зведеного ланцюга, такі як постачальники програм, швидше за все, діятимуть як «мисливці за головами»);
Щоб бути впевненим у відсутності шахрайства, виходячи з соціального консенсусу, вам потрібно почекати кілька днів, що вплине на такі операції, як зняття коштів;
Даних по ланцюжку багато, а вартість залишається;
Наразі, спираючись на рівень розширення Rollup, пропускна здатність може бути збільшена в 10 разів. Чи можливо бути вищою?
Чи існує рішення, яке може взагалі унеможливити шахрайство, зробити кінцевість (Finality) швидшою, зменшити потребу в завантаженні даних у ланцюг і зробити розширення на порядок більшим? Багато чого не хочеться, але є таке рішення, яке може задовольнити практично всі уяви — Zero Knowledge Rollup (скорочено ZK-Rollup).
ZK-Rollup — це ідея Rollup, яка використовує підтвердження нульового знання (ZKP). Так звана ZKP відноситься до технології, яка переконує іншу сторону, що ви знаєте цю інформацію, не розкриваючи жодної конфіденційної інформації. Щоб пояснити ZKP, є два мої улюблені приклади:
*Уявіть собі, що в середньовічному європейському місті я маю карту скарбів із позначеним на ній скарбом. Щоб довести тобі, що у мене є карта скарбів, але не повідомляючи тобі про точне місцезнаходження скарбу, я зав’язую тобі очі, затягну в карету і півгодини катаю містом, щоб переконатися, що ти втратите відчуття орієнтування. Нарешті прибудете в пункт призначення, вийдіть з машини та покажіть вам скарб, а потім відвезіть вас назад. Це наївна форма ЗКП.
Більш поширеною є інша аналогія. Припустимо, що є головоломка судоку, я знаю відповідь, але ви ні, але ви не вірите, що я знаю; я хочу довести вам, що я знаю, але я не хочу, щоб ви знали відповідь. що робити? Я можу покласти судоку на стіл із картками, а потім покласти відкриті числа вгору та числа, які потрібно заповнити, униз, а ви зможете перевірити мою відповідь у рядку чи стовпчику. Якщо це по рядках, я згрупую числа в кожному рядку, розділю їх і покажу вам, що в кожному рядку від 1 до 9. Можна повторити кілька разів, щоб ви могли повірити, що я справді знаю відповідь із високою ймовірністю. Це один із інтерактивних методів доказу ZKP (оскільки важко досягти взаємодії в ланцюжку в реальному часі в блокчейні, зазвичай використовується неінтерактивний доказ, а випадкові виклики генеруються функцією Hash).
У менш суворих термінах основна ідея ZKP полягає в тому, що перевіряльник (Prover) спочатку приховує секретні знання, «фіксує» (Commit), а потім верифікатор (Verifier) ініціює випадковий виклик (Challenge). якщо він зможе успішно пройти виклик, то велика ймовірність того, що він володіє відповідними секретними знаннями.
ЗКП має відповідати 3 вимогам:
Якщо прувер бреше, існує висока ймовірність провалити виклик (Достовірність);
Якщо перевіряючий володіє знаннями, він зможе пройти виклик (Повнота);
Під час взаємодії між двома сторонами перевіряльник не розкриватиме жодної корисної інформації (нульовий рівень знань).
Щоб задовольнити ці три вимоги, ZKP використовує різноманітні задачі NP, включаючи найпростіший розклад простих чисел, дискретні логарифми (наприклад, Шнорра) тощо.
ZKP не є технологією, створеною для блокчейну, але її можна використовувати для розширення L2, головним чином тому, що хороший ZKP має такі корисні характеристики:
Довідник (постачальник послуг) може швидко надати підтвердження, щоб переконатися, що ефективність обчислення в ланцюжку дуже висока і не стане вузьким місцем;
Розмір доказу невеликий або, принаймні, пропорційний кількості обчислень, які потрібно підтвердити, а вплив обсягу даних є якомога меншим, щоб вартість зберігання в ланцюжку була низькою;
Верифікатор (контракт L1) може швидко перевірити, чи є доказ дійсним, тому витрати на обчислення в ланцюжку є низькими.
Використовуючи ці функції, наше зведене рішення може:
Немає потреби в «мисливці за головами», контракт L1 може сам виявити шахрайство на місці;
Поки верифікація ZKP дійсна, зняття коштів можна здійснювати негайно, а остаточність скорочується з днів до хвилин;
У ланцюжку потрібна лише різниця між станами, простір дуже малий, а вартість зберігання дуже низька (додатковий бонус — конфіденційність також покращена);
Завдяки налаштованому програмному та апаратному забезпеченню оптимізації процесу перевірки та верифікації можливость розширення може бути збільшена на інший порядок.
Звичайно, будь-який механізм безпеки матиме потенційні передумови, і ZKP не є панацеєю для блокчейну. Наразі ЗКП має багато обмежень, які потрібно долати крок за кроком, наприклад:
Візьміть як приклад zk-SNARK, який найчастіше використовується в блокчейні. Для багатьох схем спочатку необхідно представити якомога більше престижних людей або компаній і виконати довірене налаштування, щоб створити справжнє випадкове число та гарантувати, що процес генерації можна перевірити, але не повністю публічно (як у церемонії «Сила Тау», якщо одній стороні можна довіряти, але це все одно вважається недоліком). Звичайно, деякі нові схеми zk-SNARK і пізніше вдосконалені zk-STARK можуть вирішити цю проблему, але іноді виникають нові проблеми.
Багато проблем важко узагальнити як проблеми ZKP, що призвело до того, що програмованість не була добре вирішена протягом тривалого часу. Важко реалізувати ZKP, який був би повністю сумісний з EVM на Ethereum, або навіть якщо він може бути досягнуто, але це вплине на інші аспекти (такі як ефективність перевірки).
джерело:
Ось чому в ZK-Rollup, орієнтованій на майбутнє галузі розширення, кожен прогрес гідний похвали та задоволення.
джерело:
напишіть в кінці
Що стосується майбутнього розширення ємності, автор вважає, що в порівнянні з власним розширенням ємності L1 багаторівнева конструкція, що включає Rollup, є більш надійною ідеєю. Модуляція, кожен рівень вирішує проблеми кожного рівня, що менш ризиковано, ніж безперервне стекування на вже «монолітному» L1; крім того, децентралізація базового L1 через розширення ємності теоретично малоймовірна. Верхній рівень знаходить це та робить це вгору. Крім того, ця ідея багаторівневого дизайну має, здавалося б, успішне застосування в інших сферах, окрім блокчейну. Точка зору не обов'язково правильна, але це поточне пізнання автора.
У цій статті зроблено спробу з’ясувати причини мислення та дизайну рішення розширення Rollup у тоні, що не залежить від проекту. Через обмежений рівень деякі місця все ще трохи тупі, що може не тільки не пояснити це на місці, але й ускладнити розуміння; оскільки вертикальне поле, яке змінюється з кожним днем, автор може не знати і вчасно враховувати багато нових подій. Щиро вітаю друзів до виправлення та спілкування.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
У цій статті обговорюються ідеї розвитку та причини розробки рішення розширення Rollup
Автор оригіналу: ORFEO
Проект L2 знову в центрі уваги.
Як представник маршруту розширення Rollup у L2, після аірдропу Arbitrum буде запущено zkSync Era. Що стоїть за безкінечними новими дизайнами та дорожніми картами, що є основною лінією Rollup і яке еволюційне мислення? Давайте подивимося сьогодні.
Основні моменти цієї статті:
Починаючи з аналогії
Щодо біткойнів та Ethereum, з моменту їх народження, є дві найбільші критики з боку простих користувачів:
Ці дві критики випливають з двох факторів у дизайні блокчейна:
Якщо блокчейн справді може бути схожим на під’їзну доріжку, тоді фундаментальним рішенням є, природно, розширити під’їзну доріжку та в той же час співпрацювати з ціновими засобами, щоб визначити час, щоб вийти, і не виходьте, якщо ви не в поспішати.
Однак, незважаючи на те, що розширення смуг і збільшення пропускної здатності блоку є привабливим рішенням для підвищення ефективності трафіку, це крайній засіб у дизайні блокчейна. Оскільки чим більший розмір блоку, тим вищі вимоги до обладнання для майнерів і тим менше майнерів можуть відповідати вимогам; згідно з цією ідеєю, якщо ви хочете обробляти тисячі транзакцій за секунду, як Visa, ви лише зробите іншу централізована система Visa суперечить основній меті недовіри блокчейну.
Чи є якесь інше рішення? Так, окрім орієнтування за часом, ми також можемо оптимізувати простір, включаючи, але не обмежуючись:
Як шина в блокчейні, ключем до Rollup є економія місця та бензину (газ, каламбур):
Таким чином, два слоти «повільний» і «дорогий» вирішуються Rollup.
Давайте повернемося до блокчейну і подивимося на конкретний план Rollup.
Створіть зведене рішення з нуля
Замість того, щоб підглядати за стандартною відповіддю (не кажучи вже про те, що її немає), краще поміркувати й уявити, що ви будете робити, коли вам доручать розробити Rollup для Ethereum.
Ми також могли б почати з двох точок зору: зменшення витрат на обчислення (економія бензину) і зменшення витрат на зберігання (економія місця), і спочатку запропонувати більш радикальне рішення під назвою Rollup 1.0.
Зведення 1.0
Зведений пакет 1.0 складається з 3 основних пунктів:
Простіше кажучи, це регулярний і кількісний збір запитів на транзакції кожного, і після обчислень поза ланцюгом лише результати розрахунків затверджуються в ланцюжку.
Це рішення ідеально вирішує дві головні проблеми: «повільно» та «дорого», але, здається, створює нові проблеми:
Для цих трьох нових проблем ми можемо повторити версію плану.
Зведення 2.0
Найкраще вирішується проблема мотивації, а проблеми, які можна вирішити за допомогою грошей, не є проблемами. Постачальник послуг може порівну розподілити витрати на «спільне використання автомобілів» і стягувати трохи додаткових «чайових». Незважаючи на це, це все одно безпрограшна ситуація для особи, яка «користується спільним використанням».
Проблема перегляду є трохи складнішою, але рішення дуже поширене в області блокчейну, і це децентралізація. Група людей є постачальниками послуг, що краще, ніж лише один постачальник послуг; кожен може бути постачальником послуг, що краще, ніж фіксована група людей. В останньому варіанті гри, якщо всі постачальники послуг погані, ви також можете бути постачальником послуг самостійно або безпосередньо перейти до L1, щоб ініціювати арбітраж.
Шахрайство трохи складніше. Його можна розділити на два питання: одне — як виявити шахрайство, а інше — як йому запобігти.
По-перше, щоб виявити шахрайство, нам потрібно знати дані кожної транзакції (Transaction), стан до транзакції (State), щоб обчислити новий стан (State') після транзакції та використовувати його для зберігання це в ланцюжку постачальника послуг. У порівнянні з новим станом, якщо він такий самий, це означає, що постачальник послуг чесний, інакше це означає, що він збрехав. Однак ми не знаємо даних про транзакції, оскільки вони не в мережі. У результаті ми можемо бути лише скептичними та нездатними судити про те, чесним є постачальник послуг чи ні.
Далі, щоб запобігти шахрайству, найкращий спосіб – зробити шахрайство неможливим, що є складнішим, якщо розрахунок постачальника послуг не перевіряється щоразу в ланцюжку, але в цьому випадку немає переваг " спільне використання автомобілів" вгору. Тож ми можемо лише зробити крок назад і зробити ціну шахрайства дуже високою, щоб постачальники послуг мали можливість взяти участь у грі, наприклад, сплатити депозит (Stake), який буде конфісковано, якщо шахрайство буде виявлено. (Цей метод називається соціальним консенсусом, який відноситься до ігрової безпеки, і також згадувався в «Щотижневику №3».)
Зведення 3.0
Rollup 2.0 непоганий, але проблему виявлення шахрайства не вирішує.
Відповідно до попереднього висновку, щоб ідентифікувати шахрайство, ми повинні знати дані транзакції, тому ця частина даних має бути в тому ж ланцюжку, що й дані про стан.
Хто дізнається, що вони шахраї? Очевидно, що це навряд чи буде звичайний користувач, адже стежити за кожним кроком постачальника послуг 7х24 години неможливо, тому це може бути лише професійний «мисливець за головами» (Validator). Якщо «мисливець за головами» повідомить про шахрайство протягом 7 днів після того, як постачальник послуг «надішле замовлення» та переконається, що це правда, транзакцію буде відмінено, а постачальника послуг буде покарано. Звичайно, таким же чином «мисливцям за головами» також потрібні стимули. Наприклад, після виявлення шахрайства частина депозиту постачальника послуг буде передана «мисливцю за головами» (тільки частина, щоб уникнути змови між постачальник послуг і мисливець за головами).
Зведене оновлення 4.0
На стадії Rollup 3.0 все рішення працювало безперебійно, але з’явилися нові витрати. Поки що витрати включають:
Давайте розберемося, які витрати можна оптимізувати.
дані транзакції
У певний спосіб кілька транзакцій об’єднуються разом, і займаний простір може бути меншим, ніж сума простору, зайнятого кожною транзакцією.
Беручи за приклад найпростішу транзакцію переказу ETH, ми розбираємо склад вмісту кожної транзакції, і бачимо, що простір для підписів становить найбільшу частку. Ми можемо об’єднати підписи всіх транзакцій в одну (агрегація ключів), що заощаджує багато накладних витрат на зберігання (подібно до Шнорра в біткойнах). Крім того, ми також можемо оптимізувати інші частини, як-от позбутися Nonce і вибрати якомога більше «товстий і худий» під час «спільного використання автомобіля», а також «особу для спільного використання», яка ідеально підходить для максимального використання «автомобіля». "простір.
джерело:
Лише три чи два рази розмір кожної транзакції переказу ETH було зменшено зі 112 байт до 12 байт, що майже на одну десяту від попереднього; звичайно, існують інші засоби для подальшого стиснення даних транзакції.
У реальній роботі ми можемо вставити такий метод у контракт, розгорнутий у ланцюжку:
функція storeTxData(bytes calldata data) external {// Нічого не потрібно}
Потім кожного разу, коли «спільне використання» є успішним, об’єднані та стиснуті дані транзакції передаються в цей метод як calldata. Calldata не потрібно зберігати постійно, і після Періоду виклику суспільного консенсусу (Challenge Period) не матиме значення, якщо їх обрізати (Prune); сама ціна дуже низька, і це буде дешевше з впровадженням EIP, такі як Danksharding і Data Blob, ця форма застосування L1 до розподілу сховищ даних (Доступність даних) також буде більш формальною.
дані про статус
Тепер, коли дані транзакцій завантажено в ланцюжок, будь-хто може обчислити оновлений стан за допомогою даних транзакцій, а дані стану не є такими необхідними. Ми можемо лише зберегти Merkel Root державних даних, які використовуються, щоб дозволити звичайним користувачам ("користувачам спільного використання") подавати заявки на зняття коштів безпосередньо в L1, коли постачальник послуг не співпрацює, і покладатися на Merkel Proof, щоб довести, що вони мають гроші на своїх рахунках.
АРБІТРАЖНІ ВИТРАТИ ЩОДО ШАХРАЙСТВА
Коли «мисливець за головами» повідомляє про шахрайство постачальнику послуг, розрахунок контракту в ланцюжку (Replay) виконується один раз і результати статусу порівнюються. Це теоретично можливо. Однак вартість цього не є низькою (хоча це вже добре), а по-друге, сума газу транзакцій, включених до «списку спільного використання», може перевищувати ліміт газу Ethereum, що унеможливлює перевірити.
Таким чином, арбітраж повинен зменшити тягар, і спосіб зменшити цей тягар, природно, полягає в тому, щоб виключити непотрібні розрахункові операції. Одне з рішень називається Interactive Proving. Загальний процес такий:
(Протягом усього процесу, якщо одна сторона не відповість протягом тайм-ауту, ця сторона зазнає невдачі.)
Таким чином, арбітражна вартість у всьому ланцюжку є дуже, дуже низькою.
Сказавши це, ми повністю створили зведене рішення. Оскільки ця схема передбачає, що постачальник послуг є чесним за замовчуванням, якщо немає звіту «мисливця за головами», ця фракція називається зведенням оптимістів, так званим Optimistic Rollup.
Отже, чи є наш Rollup 4.0 найкращим рішенням?
Повторна еволюція зведеного пакета
Після багатьох ітерацій Rollup 4.0 все ще має деякі недоліки:
Чи існує рішення, яке може взагалі унеможливити шахрайство, зробити кінцевість (Finality) швидшою, зменшити потребу в завантаженні даних у ланцюг і зробити розширення на порядок більшим? Багато чого не хочеться, але є таке рішення, яке може задовольнити практично всі уяви — Zero Knowledge Rollup (скорочено ZK-Rollup).
ZK-Rollup — це ідея Rollup, яка використовує підтвердження нульового знання (ZKP). Так звана ZKP відноситься до технології, яка переконує іншу сторону, що ви знаєте цю інформацію, не розкриваючи жодної конфіденційної інформації. Щоб пояснити ZKP, є два мої улюблені приклади:
*Уявіть собі, що в середньовічному європейському місті я маю карту скарбів із позначеним на ній скарбом. Щоб довести тобі, що у мене є карта скарбів, але не повідомляючи тобі про точне місцезнаходження скарбу, я зав’язую тобі очі, затягну в карету і півгодини катаю містом, щоб переконатися, що ти втратите відчуття орієнтування. Нарешті прибудете в пункт призначення, вийдіть з машини та покажіть вам скарб, а потім відвезіть вас назад. Це наївна форма ЗКП.
У менш суворих термінах основна ідея ZKP полягає в тому, що перевіряльник (Prover) спочатку приховує секретні знання, «фіксує» (Commit), а потім верифікатор (Verifier) ініціює випадковий виклик (Challenge). якщо він зможе успішно пройти виклик, то велика ймовірність того, що він володіє відповідними секретними знаннями.
ЗКП має відповідати 3 вимогам:
Щоб задовольнити ці три вимоги, ZKP використовує різноманітні задачі NP, включаючи найпростіший розклад простих чисел, дискретні логарифми (наприклад, Шнорра) тощо.
ZKP не є технологією, створеною для блокчейну, але її можна використовувати для розширення L2, головним чином тому, що хороший ZKP має такі корисні характеристики:
Використовуючи ці функції, наше зведене рішення може:
Звичайно, будь-який механізм безпеки матиме потенційні передумови, і ZKP не є панацеєю для блокчейну. Наразі ЗКП має багато обмежень, які потрібно долати крок за кроком, наприклад:
джерело:
Ось чому в ZK-Rollup, орієнтованій на майбутнє галузі розширення, кожен прогрес гідний похвали та задоволення.
джерело:
напишіть в кінці
Що стосується майбутнього розширення ємності, автор вважає, що в порівнянні з власним розширенням ємності L1 багаторівнева конструкція, що включає Rollup, є більш надійною ідеєю. Модуляція, кожен рівень вирішує проблеми кожного рівня, що менш ризиковано, ніж безперервне стекування на вже «монолітному» L1; крім того, децентралізація базового L1 через розширення ємності теоретично малоймовірна. Верхній рівень знаходить це та робить це вгору. Крім того, ця ідея багаторівневого дизайну має, здавалося б, успішне застосування в інших сферах, окрім блокчейну. Точка зору не обов'язково правильна, але це поточне пізнання автора.
У цій статті зроблено спробу з’ясувати причини мислення та дизайну рішення розширення Rollup у тоні, що не залежить від проекту. Через обмежений рівень деякі місця все ще трохи тупі, що може не тільки не пояснити це на місці, але й ускладнити розуміння; оскільки вертикальне поле, яке змінюється з кожним днем, автор може не знати і вчасно враховувати багато нових подій. Щиро вітаю друзів до виправлення та спілкування.