Джеремі Рубін випустив пропозицію два тижні тому під назвою 'Угоди Un’FE’d' (FE = Функціональне Шифрування). Враховуючи поточні дебати щодо пропозицій угод для Bitcoin за останній рік або два, його пропозиція позначає новий практичний варіант. Усі пропозиції угод до цього часу потребують м'якого форку (фактичні опкоди), розробки та впровадження неперевіреної криптографії (Функціональне Шифрування) або абсурдно високих грошових витрат на використання (ColliderScript).
Пропозиція Джеремі не вимагає м'яких форків і не накладає обтяжливі та непрактичні витрати на користувачів для використання. Компроміс за цю можливість – радикально інша модель безпеки. Використовуючи систему оракулів та облігацій на основі BitVM, здатних до штрафів, угоди можуть бути емульовані на Bitcoin прямо зараз.
Оракули
Перша частина схеми очевидно є оракулами, які забезпечують різні умови угоди. Це відносно просте налаштування і перший будівельний блок, необхідний для пропозиції Джеремі. Оракул має custody коштів у цій схемі і відповідає за виконання умов угоди. Вам потрібно, щоб оракул не мусив локально відслідковувати умови угоди для кожної монети, яку він обслуговує. Це вводить ризик стану, коли, якщо база даних оракула пошкоджена або втрачена, він не знає, як обробити чесне виконання для монет усіх користувачів. Щоб обійти цю проблему, Джеремі використовує Taproot.
Ключі на основі Шнорра можуть бути 'налаштовані' за допомогою хешу даних для модифікації публічного ключа. Це дозволяє налаштувати відповідний приватний ключ, щоб він міг підписувати для модифікованого ключа, а також довести, що будь-які дані, які використовувалися для налаштування публічного ключа, є зобов'язаними цим ключем. Наявність у оракула ключа, а потім налаштування цього ключа користувачем за допомогою їх програми угоди дозволяє зобов'язатися до того, що оракул повинен забезпечити, зберігаючи при цьому обтяження зберігання цієї інформації на користувача.
Оракули також можуть бути федеративними, щоб мінімізувати довіру, необхідну до однієї сторони для виконання умов. Звідси користувачі можуть просто завантажити результативну адресу, і коли вони хочуть застосувати умову, підходити до оракулів із транзакцією витрат, програмою оракула та даними свідка, необхідними для доведення того, що транзакція, надана оракулу, відповідає умовам угоди. Якщо транзакція є дійсною відповідно до правил угоди, оракул її підписує.
Для будь-якої простої угоди, де результати відомі заздалегідь, такі як CHECKTEMPLATEVERIFY (CTV), користувачі можуть негайно попросити оракула попередньо підписати транзакції, що забезпечують угоду, і просто відкласти їх використання до необхідності.
Важливий сценарій, який потрібно врахувати, що вимагає додаткової функціональності, – це угоди на основі стану, такі як rollups, які регулярно прогресують і мають фактичний стан (поточний баланс користувачів), за яким потрібно стежити. У випадку таких угод угоди, які оракул підписує, повинні відповідати поточному стану угоди, використовуючи OP_RETURN, щоб оракул міг ефективно перевірити кожну угоду, що оновлює rollup або іншу систему, не завантажуючи дані свідка для всієї історії. Це потрібно, щоб оракул не зберігав стан локально, що, як зазначалося вище, створює ризики.
У довгостроковій перспективі вимоги до даних оракулів можуть бути оптимізовані за допомогою нульових знань, щоб оракул міг просто перевірити доказ, що угода, яку просять підписати, відповідає правилам угоди, не перевіряючи сирі дані свідка для більших і складніших угод. Знову ж таки, у випадку систем, таких як rollups, слід бути обережними при їх проектуванні, щоб гарантувати, що дані, необхідні для виходу з системи, надаються користувачам, щоб вони мали їх у своєму розпорядженні, якщо їм потрібно зв'язатися з оракулом безпосередньо для повернення своїх коштів.
БітВМ Облігація
На даний момент схема повністю довірена. Ви, по суті, просто даєте комусь іншим свої гроші і сподіваєтеся, що їх можна довіряти, щоб виконати умови довільних угод. Внесення невеликої зміни в наведену вище схему може забезпечити це за допомогою криптоекономічного стимулу замість чистої довіри.
Вищезгадане описує, як OP_RETURN має використовуватися для відстеження стану для станових угод. OP_RETURN також можна використовувати для публікації даних свідка будь-яких угод з угод, щоб довести, що умови були правильно виконані.
Схему BitVM можна побудувати для перевірки, чи транзакція, підписана оракулом, успішно відповідає умовам угоди, яку вона забезпечує. Пам'ятайте, що сам ключ, який генерується, і кошти, надіслані для зобов'язання до умов будь-якої угоди, яка забезпечується. Це означає, що дані, а також транзакція, що витрачається з адреси, можуть бути подані в екземпляр BitVM.
Оракули можуть бути зобов'язані розміщувати заставну облігацію з оператором BitVM (який також повинен розмістити облігацію для оракула, щоб претендувати, якщо їх неправильно звинуватять). Таким чином, поки вартість облігації перевищує вартість, забезпечену в угодах оракулом, система може бути безпечною у використанні. Не буде способу для оракула порушити умови угоди, яку вони забезпечують, не втративши гроші в цілому.
Компроміси
Є очевидні компроміси, які є суттєво гіршими, ніж просто впровадження угод у правилах консенсусу. По-перше, оракул повинен бути онлайн і доступний, щоб використовувати угоди, що забезпечуються оракулом. За винятком попередньо підписаних угод, таких як CTV, якщо оракул офлайн, коли користувачі повинні застосувати угоду, вони не можуть. Оракул повинен бути присутнім для підписання.
По-друге, вимоги до ліквідності для облігацій оракула можуть стати величезними, якщо система коли-небудь буде широко прийнята. Це робить її неймовірно неефективною в порівнянні з рідною реалізацією угод на рівні консенсусу.
Нарешті, додаткові дані, які потрібно опублікувати в ланцюзі для того, щоб схема облігацій BitVM працювала, є значно менш ефективними з використанням блочного простору, ніж рідні реалізації угод.
У цілому, пропозиція не є настільки ж ефективною і безпечною, як рідні угоди. З іншого боку, якщо ми потрапимо в найгірший сценарій передчасної осифікації, це дуже прийнятний спосіб впровадження угод у Bitcoin без залежності від неперевіреної криптографії або абсолютно непрактичних витрат, які накладаються на кінцевих користувачів.
Джеремі дав нам опцію найгіршого сценарію, щоб розширити простір дизайну того, що можна побудувати на Bitcoin.
Джерело: Bitcoin Magazine
Пост 'Остання Резерв: Угоди Un’FE’d для Bitcoin' вперше з'явився на Crypto Breaking News.
