Це праймер про асинхронне виконання: як ми змусили його працювати в Monad, чому EIP-7702 зламав його та як це виправити Для контексту, асинхронне виконання було в Monad з тих пір, як клієнти консенсусу та виконання були підключені один до одного. Асинхронне виконання дозволяє виконанню відставати від консенсусу на фіксовану кількість блоків з точки зору взаємодії. Більшість блокчейнів мають консенсус. Тобто, виконання відбувається до досягнення консенсусу, що означає вписування виконання в часовий бюджет, який становить невелику частку часу блоку (решта зайнята навколосвітнім обміном повідомленнями, він же консенсус). Це за своєю суттю обмежує витрату газу в секунду системи. L2 обходять це, не маючи консенсусу взагалі. Але нам потрібна поведінка розподіленого, децентралізованого L1, який зберігає високу продуктивність. Асинхронне виконання дозволяє нам обійти цю проблему, переміщуючи виконання з гарячого шляху консенсусу. Натомість консенсус і виконання відбуваються на паралельних доріжках для запливу. Консенсус щодо блоку 2 виникає, коли виконання блоку 1 виконується паралельно. Однак все ще має бути домовленість між консенсусом і виконанням. Зокрема, ця угода полягає в наступному: виконання дозволяється лише з відставанням консенсусу до k блоків, оскільки пропозиції блоків містять відкладений корінь Меркла. Крім того, консенсус - це будівельні блоки з відкладеним переглядом стану (із затримкою на k блоків). Це означає, що існує небезпека того, що консенсус включатиме транзакцію від відправника, який до моменту виконання виявляється, що має порожній баланс. Було б погано, якби протокол дозволив це зробити, тому що це відкрило б вектор відмови в обслуговуванні (DOS). Тому, щоб вирішити цю проблему та безпечно увімкнути асинхронне виконання, клієнт консенсусу Monad розраховує максимальний дебет MON кожної транзакції як MON_spent = gas_bid * gas_limit + значення. Консенсусний клієнт веде поточний список доступних залишків на рахунках для кожного відправника після вирахування MON_spent за кожну відправлену транзакцію. Якщо не брати до уваги цей поточний баланс, консенсусний клієнт включає транзакції лише в тому випадку, якщо він може бути впевнений, що транзакція може бути оплачена. Це песимістичний підхід до побудови блоків, оскільки він не враховує можливість збільшення балансу будь-яких рахунків від переказу в. Поясню, що я маю на увазі на прикладі. Припустимо, на рахунку Аліси є 100 MON. Потім в блок 1000 включаються наступні 3 транзакції: Tx 1: Аліса відправляє Бобу 20 МОН, що коштує 1 MON гонорару Tx 2: Аліса витрачає 70 MON на покупку мемкоїна, вартість якого становить 1 MON комісії...