Прогрес, досягнутий @SuccinctLabs та @RiscZero у доведенні в режимі реального часу, був надзвичайно вражаючим. QT-ing не для того, щоб бути критичним, а тому, що я думаю, що ці питання дійсно цікаві (і я хотів би, щоб RTP вдарив по Ethereum!). 1. Доведення всіх історичних блоків Ethereum протягом 12 секунд недостатньо для покриття найгіршого часу часу. Це важливо, тому що можливі патологічні («докази-вбивці») блоки, де вартість доведення >> вартість газу (вартість доведення є мірою латентності або $). Першим кроком є доведення всіх історичних блоків протягом 12 секунд. Але цього недостатньо. Нам потрібно працювати над виявленням патологічних випадків, які ще не показали на Ethereum. Не впевнений, який графік витрат для SP1, але щось на кшталт цілого блоку, повного extcodehash, може бути дорогим з точки зору затримки. 2. Формальна верифікація також повинна охоплювати компілятор 😱 @argumentxyz мав хорошу статтю про те, з якою частотою виявляються помилки компілятора ( tl; Існує певний клас "помилок неправильної оптимізації", які потенційно можуть бути використані в zkVM для створення проблем зі звуком. Ці жучки зустрічаються досить часто. @drakefjustin стверджував, що ми можемо обійти це за допомогою багатьох реалізацій zkVM. Але це не працює, якщо ці zkVM використовують один і той же ланцюжок інструментів компілятора і вразливі до одних і тих же помилок. 3. Доведення в домашніх умовах не потрібне Думаю, я згоден з тим, що доводити вдома не потрібно. Ми вже покладаємося на позапротокольних акторів, таких як будівельники, для створення блоків. Гарантія, якої ми хочемо, полягає в тому, що *хтось* завжди доступний для створення доказів. Відкладання RTP для сценарію WW3, коли всі докази переходять в автономний режим, здається надмірним. Можливо, в цьому сценарії Ethereum може за замовчуванням повернутися до режиму, коли ліміт газу зменшується, а блоки повторно виконуються, а не перевірені ZKP. 4. 100-кратне перевищення ліміту газу може створити проблеми Розпаралелене доведення безумовно допомагає, але час настільки стислий, що нам потрібно враховувати генерацію свідків (не розпаралелюється в багатьох zkVM) і рекурсію. Накладні витрати на рекурсію повинні масштабуватися логарифмічно, але якщо ліміт газу збільшується в 100 разів, час доведення може перевищувати час блоку. Бонус - я б стверджував, що для Ethereum дійсно важливо скоротити час блокування та час до завершення, щоб допомогти користувачам підключитися до L2s, мосту з CEX тощо. Це збільшує вимоги до затримки доведення. Було б неоптимально, якби ми не змогли перейти на 1 секунду блоку, тому що нижня межа затримки RTP у найгіршому випадку становить 10 секунд.