Ethereum L2, який приймає нульові підписи, звучить як безпекова проблема, але BB84 робить це навмисно, щоб уникнути квантових атак. Minулого вихідного день її засновник, який публікує під ім’ям Hadamard, опублікував дизайн на Ethereum Research і попросив критичні зауваження. BB84 — це OP Stack rollup на мейннеті, який працює з 30 вересня, де транзакції L2 взагалі не мають ECDSA. Кожен акаунт — це кінець ланцюга хешів keccak-256, побудованого з секрету, за замовчуванням з 1000 кроків. Щоб витратити кошти, ваш гаманець розкриває попереднє значення в ланцюзі, що будь-хто може перевірити одним хешуванням. Усередині L2 єдиним припущенням залишається стійкість до зворотного хешування keccak-256, яку алгоритм Гровера зменшує до приблизно 2^128 операцій. Розкриття секрету робить його публічним, тому протокол додає крок коміту та розкриття, щоб прив’язати кожен преімедж до однієї транзакції. Два нових типи транзакцій у op-geth обробляють це, а перевірка відправника замінює ecrecover. Авторизація споживається навіть у разі відмови виклику, і якщо гаманець пропустить крок оновлення на останньому ланцюжку, ця адреса стає мертвою. У дописі також зазначено вразливість до фронт-раннінгу, яку команда виявила під час написання. Коміти не мають підпису, тому новий коміт раніше міг замінити очікуючий, і зловмисник міг переприв’язати розкритий секрет до власної платіжної операції. Правило, яке вступило в силу 21 жовтня, робить переможцем перший коміт. Обмеження чітко вказані. Депозити та виведення на L1 все ще використовують ECDSA. Ще немає fault proofs, і за власними словами автора, ланцюжок навіть не досягне етапу 0 L2BEAT. Секвенсер управляється командою, а 160-бітні адреси забезпечують приблизно 2^80 квантової стійкості до другого преімеджу. У дописі також ставиться питання: чи можуть облікові записи на основі ланцюга хешів стати EIP-7702 або нативним режимом перевірки абстракції акаунтів для загальних L2.