Написано Робіном Перекладачем Linux: Група перекладів спільноти Denlink
Підсумки
BitVM - це обчислювальна парадигма, яка використовується для вираження повних біткойн-контрактів Тюрінга. Це не вимагає внесення будь-яких змін до правил консенсусу мережі Bitcoin. На відміну від виконання розрахунків на біткойнах, вони просто перевіряються, подібно до оптимістичних роллапів. Ведучий оголошує, що задана функція обчислює певні входи до певного виходу. Якщо твердження неправдиве, то верифікатор може зробити стислий доказ шахрайства та покарати доказів. Використовуючи цей механізм, будь-яка обчислювана функція може бути перевірена на Bitcoin.
Обіцянка великої програми на адресі Taproot вимагає багато офчейн-обчислень і зв'язку, але її слід у ланцюжку невеликий. Поки дві сторони працюють разом, вони можуть виконувати як завгодно складні розрахунки поза мережею, не залишаючи жодних слідів у ланцюжку. Ончейн-примусове виконання вимагається лише у разі виникнення спору.
1 Вступ
За задумом, функціональність смарт-контрактів Bitcoin обмежена базовими операціями, такими як підписи, блокування часу та хешування. BitVM створює новий простір дизайну для більш виразних біткойн-контрактів і офчейн-обчислень. Потенційні програми включають такі ігри, як шахи, го або покер, а також перевірку підтвердження дійсності біткойн-контрактів. Крім того, можна з'єднати Bitcoin із зовнішніми ланцюгами, побудувати ринки передбачень або змоделювати нові коди операцій.
Основним недоліком представленої тут моделі є те, що вона працює лише з двома установками, prover та verifier. Ще одне обмеження полягає в тому, що для доказів і верифікаторів для виконання програми потрібно багато офчейн-обчислень і зв'язку. Однак ці питання видаються багатообіцяючими для вирішення за допомогою подальших досліджень. У цій роботі ми зосередимося лише на ключових компонентах двосторонньої BitVM.
2 Схема
З оптимістичними зведеннями 1[2] [3] і пропозиція MATT (Merkelize All The Things) 2 Аналогічно, наші системи засновані на протоколах доказу шахрайства та реагування на виклики. Однак BitVM не вимагає жодних змін у правилах консенсусу Bitcoin. Примітиви, що лежать в їх основі, відносно прості. В основному він заснований на хеш-замках, тайм-локах і великих стрижневих деревах.
Організатор подає програму крок за кроком у ланцюжок, але перевірка всього, що відбувається в мережі, споживає надмірні обчислювальні ресурси, тому верифікатор виконує серію складних завдань, щоб стисло сфальсифікувати хибні твердження доказу. Разом виконавець і верифікатор заздалегідь підписують низку завдань – реагування на транзакції, щоб потім вирішити будь-які суперечки.
Модель має на меті просто проілюструвати, що цей підхід дозволяє здійснювати універсальні обчислення на Bitcoin. Для практичного застосування слід розглянути більш ефективні моделі.
Протокол простий: спочатку організатор і верифікатор компілюють програму в гігантську двійкову схему. Організатор надсилає схему на адресу Taproot з листовим скриптом для кожного логічного вентиля за цією адресою. Крім того, вони заздалегідь підписують серію транзакцій для підтримки ігор із відповідями на виклики між доказами та верифікаторами. Тепер, коли вони обмінялися всіма необхідними даними, вони можуть переказати свій ончейн-депозит на згенеровану адресу Taproot.
Це активує контракт, і вони можуть почати обмінюватися даними поза мережею, щоб ініціювати зміни стану в схемі. Якщо виконавець робить будь-які неправдиві заяви, верифікатор може забрати його депозит. Це гарантує, що зловмисники завжди втрачатимуть свої депозити.
3 Зобов'язання щодо бітової вартості
Зобов'язання бітової вартості є основним компонентом цієї системи. Він дозволяє програматору встановити значення певного біта на «0» або «1». Зокрема, це дозволяє програматору встановлювати значення змінної між різними скриптами та UTXO. Це має вирішальне значення, оскільки масштабує час виконання виконання, розділяючи час виконання віртуальної машини Bitcoin на кілька транзакцій.
Проміс містить два хеш-значення, hash0 і hash1. У більш пізній момент програматор встановлює значення біта в "0", розкриваючи preimage0 (преобраз hash0) або в "1", розкриваючи preimage1 (преобраз hash1). Якщо в якийсь момент вони виявлять як preimage0, так і preimage1, то валідатор може використовувати їх як доказ шахрайства та забрати депозит доказа. Це називається суперечливим твердженням. Здатність карати за суперечливі твердження – це те, що робить зобов'язання обов'язковим – це «зобов'язання, засноване на стимулах».
Поєднання промісів бітового значення з тимчасовими блокуваннями дозволяє валідаторам змушувати організатора приймати рішення про значення конкретного біта в межах заданого періоду часу.
Рисунок 1: Реалізація зобов'язання бітового значенняРисунок 1: Реалізація 1-бітового зобов'язання. Щоб розблокувати цей скрипт, організатор повинен розкрити один із преобразів hash0 або hash1. У цьому прикладі виконання програматор виявляє hash1 і встановлює значення біта в "1". Ми можемо відтворити цю обіцянку для примусового використання певного значення в різних скриптах.
ДЛЯ СПРОЩЕННЯ, ЗВІДСИ, ПРИПУСТИМО, ЩО ІСНУЄ КОД ОПЕРАЦІЇ ПІД НАЗВОЮ OP BITCOMMITMENT, ЯКИЙ Є СКОРОЧЕННЯМ ДЛЯ НАВЕДЕНОГО ВИЩЕ СКРИПТА. Код операції споживає два хеші та один хешований преобраз. На основі хешу, який збігається з попереднім зображенням, він розміщує бітове значення в стеку.
4 Логічні проміси воріт
Будь-яка обчислювана функція може бути представлена у вигляді булевої схеми. Вентиль NAND є універсальним логічним вентилем, тому з них можна скласти будь-яку булеву функцію. Щоб зробити нашу модель простою, ми покажемо, як наш підхід працює з простими NAND-шлюзами. Крім того, ми покажемо, як поєднувати двері довільно. Все це доводить, що BitVM може представляти будь-яку схему.
Реалізація обіцянки шлюзу NAND проста. Він містить два бітові проміси, що представляють два входи, і одне бітове зобов'язання, що представляє виходи. Скрипт обчислює значення NAND двох входів, щоб переконатися, що воно відповідає обіцяним вихідним бітам.
Рисунок 2: Зобов'язання воріт для операцій NAND Рисунок 2: Зобов'язання воріт для операцій NAND. Виконання цього скрипту має розкрити значення бітових промісів A, B і C такі, що A NAND B = C є істинними.
(Тут, для простоти, припустимо, що існує код операції з ім'ям OP NAND.) НАСПРАВДІ ЙОГО НЕ ІСНУЄ, АЛЕ ЙОГО МОЖНА ЛЕГКО РЕАЛІЗУВАТИ ЗА ДОПОМОГОЮ OP BOOLAND І OP NOT. ）
5 Проміси двійкових схем
У попередньому розділі ми визначили зобов'язання шлюзу NAND. Ми можемо представити будь-яку схему, об'єднавши проміси воріт. Кожен крок виконання здійснюється в Tapleaf. Всі вони об'єднані в одну адресу Taproot, щоб організатор міг виконати будь-який вентиль у схемі. Виконання вентиля вимагає, щоб виконавець відкрив відповідний проміс вентиля і встановив значення для його вхідного і вихідного бітів.
Taptree може стати масивним і мати мільярд скриптів Tapleaf, але його місце в ланцюжку невелике.
Малюнок 3: Випадковий приклад схеми Малюнок 3: Випадковий приклад схеми з 8 різними вентилями NAND і 4 входами A, B, C і D. Використовуючи мільярди вентилів, можна визначити практично будь-яку функцію.
Рисунок 4Рисунок 4: Для кожного воріт адреса Taproot доказу містить листовий скрипт з відповідним промісом воріт. Це дозволяє задавати вхідні значення схеми в будь-який момент часу (тут A, B, C і D).
6 Виклики та відповіді
Недостатньо взяти на себе зобов'язання щодо схеми. Для того, щоб спростувати помилкові твердження, верифікатор повинен мати можливість оскаржити твердження доказа. Цього можна досягти, попередньо підписавши серію транзакцій під час налаштування. Ці транзакції відповідають на → виклики →→ відповідають на →... спосіб пов'язаний. Якщо одна зі сторін припиняє участь, то після закінчення періоду тайм-ауту інша сторона виграє челендж і може забрати депозити обох сторін. Поки обидві сторони працюють разом, вони можуть працювати разом, щоб вирішити будь-який договір за допомогою підпису 2 з 2. Наступні механізми потрібні лише в тому випадку, якщо має місце шахрайство.
Рисунок 5: Серія попередньо підписаних транзакційРисунок 5: Попередньо підписана серія транзакцій для виконання кількох раундів викликів та відповідей. Ця послідовність генерується під час налаштування.
Вікі вирішує завдання — відкрити хеш-замок у стулці кранів. Це відкриє для Пола конкретний Тап і змусить його виконати. Сценарій змушує Пола розкрити обіцянку виклику Вікі. Повторивши цей процес для кількох раундів запитів, ви зможете швидко спростувати будь-які суперечливі твердження.
Якщо виконавець припиняє співпрацю поза мережею з валідатором, валідатору потрібен спосіб змусити його діяти ончейн. Валідатор досягає цього, розблоковуючи хеш-замок: кожен NAND Tapleaf в UTXO доказу може бути витрачений тільки в тому випадку, якщо виконавець знає преобраз, що зберігається у сертифікатора. Таким чином, організатор може довести, що даний Tapleaf працює правильно, розкриваючи його входи та виходи, але лише в тому випадку, якщо верифікатор "розблокує" його, виявивши преобраз хешу, який захищає цей Tapleaf. Застосовуючи двійковий пошук, валідатори можуть швидко виявити помилку доказу лише після кількох раундів викликів і відповідей.
Малюнок 6: Після кожної відповіді Вікі може покарати за неоднозначну поведінку. Якщо Пол виставляє два суперечливих значення змінній, Вікі негайно виграє випробування і йому дозволяють забрати свій депозит. Вікі доводить неоднозначність Пола, розкриваючи будь-який з двох протообразів, обіцяних його бітами.
7 Введення і виведення
Програматор може встановити вхідні дані, відкривши відповідний бітовий проміс. В ідеалі вони розкривають зобов'язання поза мережею, щоб мінімізувати заповнюваність у мережі. У некооперативному випадку валідатори можуть змусити доказів розкрити свої вхідні дані в ланцюжку.
Великі обсяги даних можна обробити, заздалегідь обмінявшись шифруванням. Таким чином, виконавець може розкрити ключ розшифровки в більш пізній момент часу.
Також можливе багатостороннє введення. Двері можуть мати бітові зобов'язання з обох сторін.
8 Обмеження та Outlook
Представляти функції в простих схемах NAND неефективно. Використовуючи більш просунуті коди операцій, програми можуть бути представлені більш ефективно. Наприклад, Bitcoin Script підтримує додавання 32-бітних чисел, тому нам не потрібні двійкові схеми. Ми також можемо мати більші бітові проміси, наприклад, 32 біти в одному хеші. Крім того, розмір скрипта може досягати близько 4 Мб. Таким чином, ми можемо реалізувати набагато більше, ніж одну інструкцію NAND у кожному листовому скрипті.
Представлена тут модель обмежена двома партіями. Однак можна мати двосторонні канали та з'єднати їх разом, щоб сформувати мережу, подібну до мережі Lightning Network. Вивчення обох налаштувань може дати цікаві можливості узагальнення. Наприклад, ми можемо дослідити топологію зірок від 1 до n для мережі. Інше дослідницьке питання полягає в тому, чи можемо ми застосувати нашу модель до установки n-to-n і створити більш складні фабрики каналів. Крім того, ми можемо поєднувати наші системи з різними офчейн-протоколами, такими як Lightning Network або Rollups.
Інші напрямки досліджень включають крос-прикладну пам'ять, як робити заяви про довільні дані, вигравірувані в ланцюжку, або позаланцюгові програмовані схеми, тобто позаланцюгові віртуальні машини. Також можуть бути застосовані більш складні методи відбору проб, подібні до STARK, для дослідження ланцюгів за один хід.
Наступною важливою віхою є завершення конкретного проектування та реалізації BitVM, а також Tree++, мови високого рівня для написання та налагодження біткойн-контрактів.
9 Висновок
Біткойн у певному сенсі є повним Тюрінга, оскільки кодування доказів шахрайства у великих Taptrees перевіряє виконання будь-якої програми. Основним обмеженням цієї моделі є те, що вона працює лише у випадку обох сторін. Є надія, що узагальнення можна буде зробити в подальшій роботі.
Подяки
Окреме спасибі Super Testnet і Сему Паркеру, які завжди вважали, що біткоіни не буде повним Тюрінга.
Список літератури
[1] Дослідження Ethereum. Оптимістичні зведення. 2022.
[2] Сальваторе Інгала. Мерклеїзуйте всі речі. , 2022.
Ресурси
[1] Перекладацька команда:
[2] Оптимістичні зведення 1:
[3] MATT 提案(Merkelize All The Things)2:
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
BitVM: Розраховуйте будь-що на Bitcoin
Написано Робіном Перекладачем Linux: Група перекладів спільноти Denlink
Підсумки
BitVM - це обчислювальна парадигма, яка використовується для вираження повних біткойн-контрактів Тюрінга. Це не вимагає внесення будь-яких змін до правил консенсусу мережі Bitcoin. На відміну від виконання розрахунків на біткойнах, вони просто перевіряються, подібно до оптимістичних роллапів. Ведучий оголошує, що задана функція обчислює певні входи до певного виходу. Якщо твердження неправдиве, то верифікатор може зробити стислий доказ шахрайства та покарати доказів. Використовуючи цей механізм, будь-яка обчислювана функція може бути перевірена на Bitcoin.
Обіцянка великої програми на адресі Taproot вимагає багато офчейн-обчислень і зв'язку, але її слід у ланцюжку невеликий. Поки дві сторони працюють разом, вони можуть виконувати як завгодно складні розрахунки поза мережею, не залишаючи жодних слідів у ланцюжку. Ончейн-примусове виконання вимагається лише у разі виникнення спору.
1 Вступ
За задумом, функціональність смарт-контрактів Bitcoin обмежена базовими операціями, такими як підписи, блокування часу та хешування. BitVM створює новий простір дизайну для більш виразних біткойн-контрактів і офчейн-обчислень. Потенційні програми включають такі ігри, як шахи, го або покер, а також перевірку підтвердження дійсності біткойн-контрактів. Крім того, можна з'єднати Bitcoin із зовнішніми ланцюгами, побудувати ринки передбачень або змоделювати нові коди операцій.
Основним недоліком представленої тут моделі є те, що вона працює лише з двома установками, prover та verifier. Ще одне обмеження полягає в тому, що для доказів і верифікаторів для виконання програми потрібно багато офчейн-обчислень і зв'язку. Однак ці питання видаються багатообіцяючими для вирішення за допомогою подальших досліджень. У цій роботі ми зосередимося лише на ключових компонентах двосторонньої BitVM.
2 Схема
З оптимістичними зведеннями 1[2] [3] і пропозиція MATT (Merkelize All The Things) 2 Аналогічно, наші системи засновані на протоколах доказу шахрайства та реагування на виклики. Однак BitVM не вимагає жодних змін у правилах консенсусу Bitcoin. Примітиви, що лежать в їх основі, відносно прості. В основному він заснований на хеш-замках, тайм-локах і великих стрижневих деревах.
Організатор подає програму крок за кроком у ланцюжок, але перевірка всього, що відбувається в мережі, споживає надмірні обчислювальні ресурси, тому верифікатор виконує серію складних завдань, щоб стисло сфальсифікувати хибні твердження доказу. Разом виконавець і верифікатор заздалегідь підписують низку завдань – реагування на транзакції, щоб потім вирішити будь-які суперечки.
Модель має на меті просто проілюструвати, що цей підхід дозволяє здійснювати універсальні обчислення на Bitcoin. Для практичного застосування слід розглянути більш ефективні моделі.
Протокол простий: спочатку організатор і верифікатор компілюють програму в гігантську двійкову схему. Організатор надсилає схему на адресу Taproot з листовим скриптом для кожного логічного вентиля за цією адресою. Крім того, вони заздалегідь підписують серію транзакцій для підтримки ігор із відповідями на виклики між доказами та верифікаторами. Тепер, коли вони обмінялися всіма необхідними даними, вони можуть переказати свій ончейн-депозит на згенеровану адресу Taproot.
Це активує контракт, і вони можуть почати обмінюватися даними поза мережею, щоб ініціювати зміни стану в схемі. Якщо виконавець робить будь-які неправдиві заяви, верифікатор може забрати його депозит. Це гарантує, що зловмисники завжди втрачатимуть свої депозити.
3 Зобов'язання щодо бітової вартості
Зобов'язання бітової вартості є основним компонентом цієї системи. Він дозволяє програматору встановити значення певного біта на «0» або «1». Зокрема, це дозволяє програматору встановлювати значення змінної між різними скриптами та UTXO. Це має вирішальне значення, оскільки масштабує час виконання виконання, розділяючи час виконання віртуальної машини Bitcoin на кілька транзакцій.
Проміс містить два хеш-значення, hash0 і hash1. У більш пізній момент програматор встановлює значення біта в "0", розкриваючи preimage0 (преобраз hash0) або в "1", розкриваючи preimage1 (преобраз hash1). Якщо в якийсь момент вони виявлять як preimage0, так і preimage1, то валідатор може використовувати їх як доказ шахрайства та забрати депозит доказа. Це називається суперечливим твердженням. Здатність карати за суперечливі твердження – це те, що робить зобов'язання обов'язковим – це «зобов'язання, засноване на стимулах».
Поєднання промісів бітового значення з тимчасовими блокуваннями дозволяє валідаторам змушувати організатора приймати рішення про значення конкретного біта в межах заданого періоду часу.
Рисунок 1: Реалізація зобов'язання бітового значенняРисунок 1: Реалізація 1-бітового зобов'язання. Щоб розблокувати цей скрипт, організатор повинен розкрити один із преобразів hash0 або hash1. У цьому прикладі виконання програматор виявляє hash1 і встановлює значення біта в "1". Ми можемо відтворити цю обіцянку для примусового використання певного значення в різних скриптах.
ДЛЯ СПРОЩЕННЯ, ЗВІДСИ, ПРИПУСТИМО, ЩО ІСНУЄ КОД ОПЕРАЦІЇ ПІД НАЗВОЮ OP BITCOMMITMENT, ЯКИЙ Є СКОРОЧЕННЯМ ДЛЯ НАВЕДЕНОГО ВИЩЕ СКРИПТА. Код операції споживає два хеші та один хешований преобраз. На основі хешу, який збігається з попереднім зображенням, він розміщує бітове значення в стеку.
4 Логічні проміси воріт
Будь-яка обчислювана функція може бути представлена у вигляді булевої схеми. Вентиль NAND є універсальним логічним вентилем, тому з них можна скласти будь-яку булеву функцію. Щоб зробити нашу модель простою, ми покажемо, як наш підхід працює з простими NAND-шлюзами. Крім того, ми покажемо, як поєднувати двері довільно. Все це доводить, що BitVM може представляти будь-яку схему.
Реалізація обіцянки шлюзу NAND проста. Він містить два бітові проміси, що представляють два входи, і одне бітове зобов'язання, що представляє виходи. Скрипт обчислює значення NAND двох входів, щоб переконатися, що воно відповідає обіцяним вихідним бітам.
Рисунок 2: Зобов'язання воріт для операцій NAND Рисунок 2: Зобов'язання воріт для операцій NAND. Виконання цього скрипту має розкрити значення бітових промісів A, B і C такі, що A NAND B = C є істинними.
(Тут, для простоти, припустимо, що існує код операції з ім'ям OP NAND.) НАСПРАВДІ ЙОГО НЕ ІСНУЄ, АЛЕ ЙОГО МОЖНА ЛЕГКО РЕАЛІЗУВАТИ ЗА ДОПОМОГОЮ OP BOOLAND І OP NOT. ）
5 Проміси двійкових схем
У попередньому розділі ми визначили зобов'язання шлюзу NAND. Ми можемо представити будь-яку схему, об'єднавши проміси воріт. Кожен крок виконання здійснюється в Tapleaf. Всі вони об'єднані в одну адресу Taproot, щоб організатор міг виконати будь-який вентиль у схемі. Виконання вентиля вимагає, щоб виконавець відкрив відповідний проміс вентиля і встановив значення для його вхідного і вихідного бітів.
Taptree може стати масивним і мати мільярд скриптів Tapleaf, але його місце в ланцюжку невелике.
Малюнок 3: Випадковий приклад схеми Малюнок 3: Випадковий приклад схеми з 8 різними вентилями NAND і 4 входами A, B, C і D. Використовуючи мільярди вентилів, можна визначити практично будь-яку функцію.
6 Виклики та відповіді
Недостатньо взяти на себе зобов'язання щодо схеми. Для того, щоб спростувати помилкові твердження, верифікатор повинен мати можливість оскаржити твердження доказа. Цього можна досягти, попередньо підписавши серію транзакцій під час налаштування. Ці транзакції відповідають на → виклики →→ відповідають на →... спосіб пов'язаний. Якщо одна зі сторін припиняє участь, то після закінчення періоду тайм-ауту інша сторона виграє челендж і може забрати депозити обох сторін. Поки обидві сторони працюють разом, вони можуть працювати разом, щоб вирішити будь-який договір за допомогою підпису 2 з 2. Наступні механізми потрібні лише в тому випадку, якщо має місце шахрайство.
Вікі вирішує завдання — відкрити хеш-замок у стулці кранів. Це відкриє для Пола конкретний Тап і змусить його виконати. Сценарій змушує Пола розкрити обіцянку виклику Вікі. Повторивши цей процес для кількох раундів запитів, ви зможете швидко спростувати будь-які суперечливі твердження.
Якщо виконавець припиняє співпрацю поза мережею з валідатором, валідатору потрібен спосіб змусити його діяти ончейн. Валідатор досягає цього, розблоковуючи хеш-замок: кожен NAND Tapleaf в UTXO доказу може бути витрачений тільки в тому випадку, якщо виконавець знає преобраз, що зберігається у сертифікатора. Таким чином, організатор може довести, що даний Tapleaf працює правильно, розкриваючи його входи та виходи, але лише в тому випадку, якщо верифікатор "розблокує" його, виявивши преобраз хешу, який захищає цей Tapleaf. Застосовуючи двійковий пошук, валідатори можуть швидко виявити помилку доказу лише після кількох раундів викликів і відповідей.
7 Введення і виведення
Програматор може встановити вхідні дані, відкривши відповідний бітовий проміс. В ідеалі вони розкривають зобов'язання поза мережею, щоб мінімізувати заповнюваність у мережі. У некооперативному випадку валідатори можуть змусити доказів розкрити свої вхідні дані в ланцюжку.
Великі обсяги даних можна обробити, заздалегідь обмінявшись шифруванням. Таким чином, виконавець може розкрити ключ розшифровки в більш пізній момент часу.
Також можливе багатостороннє введення. Двері можуть мати бітові зобов'язання з обох сторін.
8 Обмеження та Outlook
Представляти функції в простих схемах NAND неефективно. Використовуючи більш просунуті коди операцій, програми можуть бути представлені більш ефективно. Наприклад, Bitcoin Script підтримує додавання 32-бітних чисел, тому нам не потрібні двійкові схеми. Ми також можемо мати більші бітові проміси, наприклад, 32 біти в одному хеші. Крім того, розмір скрипта може досягати близько 4 Мб. Таким чином, ми можемо реалізувати набагато більше, ніж одну інструкцію NAND у кожному листовому скрипті.
Представлена тут модель обмежена двома партіями. Однак можна мати двосторонні канали та з'єднати їх разом, щоб сформувати мережу, подібну до мережі Lightning Network. Вивчення обох налаштувань може дати цікаві можливості узагальнення. Наприклад, ми можемо дослідити топологію зірок від 1 до n для мережі. Інше дослідницьке питання полягає в тому, чи можемо ми застосувати нашу модель до установки n-to-n і створити більш складні фабрики каналів. Крім того, ми можемо поєднувати наші системи з різними офчейн-протоколами, такими як Lightning Network або Rollups.
Інші напрямки досліджень включають крос-прикладну пам'ять, як робити заяви про довільні дані, вигравірувані в ланцюжку, або позаланцюгові програмовані схеми, тобто позаланцюгові віртуальні машини. Також можуть бути застосовані більш складні методи відбору проб, подібні до STARK, для дослідження ланцюгів за один хід.
Наступною важливою віхою є завершення конкретного проектування та реалізації BitVM, а також Tree++, мови високого рівня для написання та налагодження біткойн-контрактів.
9 Висновок
Біткойн у певному сенсі є повним Тюрінга, оскільки кодування доказів шахрайства у великих Taptrees перевіряє виконання будь-якої програми. Основним обмеженням цієї моделі є те, що вона працює лише у випадку обох сторін. Є надія, що узагальнення можна буде зробити в подальшій роботі.
Подяки
Окреме спасибі Super Testnet і Сему Паркеру, які завжди вважали, що біткоіни не буде повним Тюрінга.
Список літератури
[1] Дослідження Ethereum. Оптимістичні зведення. 2022.
[2] Сальваторе Інгала. Мерклеїзуйте всі речі. , 2022.
Ресурси
[1] Перекладацька команда:
[2] Оптимістичні зведення 1:
[3] MATT 提案(Merkelize All The Things)2: