Інженерія «Нещасливий шлях»: розуміння архітектури BitVM2 Частина перша: Безпека живе на шляху суперечок Біткоїн L2 живе або гине на своєму нещасливому шляху. У Bitcoin немає режиму «запустити верифікатор у ланцюгу і рухатися далі». Ви отримуєте обмежене середовище виконання, попередньо підписані графи транзакцій і таймлоки, які точно визначають, коли кожна сторона може діяти. BitVM2 — це оптимістичний шаблон застосування для Bitcoin: виконується поза чейном, а потім робить правильність захищеною через протокол спору в блокчейні, побудований на основі попередньо підписаних транзакцій. Це веде до простого інженерного правила: якщо спори дорогі або можуть бути зупинені за рахунок оплати, модель безпеки просто не працює. Системи на базі BitVM працюють так, що дозволяють операторам виконувати поза ланцюгом, а потім дають будь-кому можливість оскаржити onchain і змусити протокол перейти на шлях спору за принципом 1 з n чесності (принаймні один чесний оскаржувач на валідність; принаймні один чесний оператор для живості). Цей шлях до спору є механізмом. Попередньо підписані транзакції та одноразові підписи (вікна викликів, терміни відповіді, фіналізацій) — це «середовище виконання» мосту та його виходів. Тож коли ми говоримо про розвиток на основі BitVM2, північна зірка — це не маркетингові терміни на кшталт «безнадійний». Північна зірка: • спори, які достатньо дешеві для виконання, • контекст ланцюга, достатньо об'єктивний, щоб запобігти виходам «доведи неправильний штат» • потоки транзакцій, які продовжують розвиватися за реальних умов комісій. У цій серії ми розглядаємо, як ми підходили до цих обмежень у дизайні GOAT BitVM2, по одному елементу. Далі у другій частині: практичні блокувальники для впровадження готового до виробництва zkRollup на Bitcoin.