Незважаючи на масштаб пропозиції, в чому причина того, що «велике відновлення сценарію» Расті Рассела може стати шляхом вперед для розвитку Біткойн?
Блок єдиноріг Примітка: Расті Рассел є активним розробником у спільноті Біткойн і користується великою повагою в спільноті. Він багато працював над розробкою ядра Linux і брав участь у багатьох лонг Біткойн основних проектах розробки.
Біткойн спочатку був розроблений як повна мова сценаріїв, призначена для того, щоб охопити та підтримка будь-які потенційні випадки використання безпеки, які користувачі можуть придумати в майбутньому. Як Сатоші Накамото сказав перед тим, як зникнути:
«Суть Біткойн полягає в тому, що після випуску версії 0.1 дизайн ядра визначається для решти життєвого циклу. Тому я хотів розробити його так, щоб підтримка всі можливі типи торгівлі, які тільки міг придумати. Проблема в тому, що все вимагає спеціальних кодів підтримка і полів даних, незалежно від того, використовуються вони чи ні, що призводить до найдовших особливих випадків. Рішенням є сценарій, який узагальнює проблему, щоб обидві сторони могли описати свої транзакції з конкретними умовами, які мережа Нода оцінює або перевіряє на основі цих умов». - Сатоші Накамото, 17 червня 2010
Вся його мета полягає в тому, щоб дати користувачам мову, яка є досить загальною, щоб вони могли організовувати свої типи транзакцій так, як їм заманеться. Тобто шорти, щоб користувачі могли розробляти та експериментувати з тим, як писати власні монети.
Перед тим, як він зник, Сатоші Накамото видалив 15 з цих кодів операцій, повністю відключив їх і додав жорстке обмеження на стек скриптового рушія, яке обмежувало розмір блоків даних, якими можна було маніпулювати (520 байт). Це пов'язано з тим, що він фактично облажався, залишивши позаду багато способів, за допомогою яких складні скрипти можуть бути використані для здійснення DOS атак на всю мережу (надсилання великої кількості спам-запитів, що призводить до виходу мережі з ладу), створюючи величезні та дорогі транзакції, які призводять до краху вузлів.
Ці коди операцій були видалені не тому, що Сатоші Накамото вважали, що функції небезпечні або що люди не повинні використовувати їх для створення чогось, чого можна було б досягти, а просто (принаймні на перший погляд) через ризик, який вони становлять для всієї мережі без обмежень ресурсів, таких як найгірші витрати на перевірку, які вони можуть накласти на мережу без обмежень.
З тих пір кожне оновлення Біткойн закінчувалося функціональною оптимізацією решти функцій, виправленням інших менш серйозних недоліків, які Сатоші Накамото залишили нам, і розширенням функціональності нашої підмножини скриптів, що залишилася.
Чудове відновлення скрипта
На конференції в Остіні Біткойн++ на початку травня розробник core Lighting Network Расті Рассел зробив дуже радикальну пропозицію у своєму першому виступі на конференції, де він, по суті, виступив з ідеєю повторного включення великого Код операції туги, який Сатоші Накамото вимкнув до того, як він зник у 2010 році.
За роки, що минули з моменту активації Taproot у 2021 році (Taproot є серйозним оновленням Біткойн, спрямованим на покращення конфіденційності, безпеки та масштабованості), простір розробки насправді був трохи безцільним. Ми всі знаємо, що Біткойн недостатньо масштабований, щоб по-справжньому надавати самосуверенні послуги будь-якій значній частині населення світу, і, можливо, навіть не зможе забезпечити масштабованість постачальникам послуг, які можуть перевершити дуже великих зберігачів і постачальників послуг, і не можуть по-справжньому звільнитися від обмежень лонг рук урядів, таким чином, щоб мінімізувати довіру або опіку.
Ця стаття вказує на технічний рівень Біткойн, який не є предметом обговорення. Питання, про яке варто посперечатися, полягає в тому, як виправити цей недолік, що є дуже спірною темою. З моменту введення Taproot всі придумують дуже вузькі пропозиції, які спрямовані на вирішення проблем, які можуть бути досягнуті тільки для конкретних випадків використання.
Наприклад, ANYPREVOUT (APO) — це пропозиція, яка дозволяє повторно використовувати підписи в різних транзакціях, лонг також сценарій і введена сума однакові, і ця пропозиція спеціально розроблена для оптимізації Lighting Network та його лонгуючий версій. CHECKTEMPLATEVERIFY (CTV) — це пропозиція, яка вимагає, щоб тверді монети витрачалися лише на транзакції, які точно відповідають заздалегідь визначеним транзакціям, і ця пропозиція покликана розширити функціональність попередньо підписаних ланцюжків транзакцій, зробивши їх повністю недовірливими. OP_VAULT спеціально розроблений для встановлення «тайм-ауту» для рішення для холодного зберігання, щоб користувачі могли «відключити» його від холодного сховища, відправивши його в більш холодні налаштування лонг, щоб запобігти компрометації своїх Секретний ключ.
Є й інші пропозиції, але я думаю, що ви вже зрозуміли суть. За останні кілька років кожна пропозиція була розроблена таким чином, щоб або трохи збільшити масштабованість, або покращити одну невелику функцію, оскільки це вважається бажаним. Це першопричина того, чому ці дискусії не досягли прогресу. Ніхто не був задоволений іншими пропозиціями, тому що вони не відповідали тим сценаріям використання, які вони хотіли бачити.
Ніхто, крім спонсора пропозиції, не вважає, що будь-яка пропозиція є достатньо всеосяжною, щоб вважатися розумним наступним кроком.
Саме така логіка лежить в основі «Great Script Recovery». Просуваючи та аналізуючи повне відновлення скриптів, як Сатоші Накамото було задумано спочатку, ми можемо спробувати дослідити всі потрібні нам короткі функції, замість того, щоб сперечатися та сперечатися про те, які невеликі розширення функцій є достатньо хорошими прямо зараз.
КОДИ ОПЕРАЦІЙ (Код операції)
OP_CAT: Бере два фрагменти даних зі стеку та додає їх разом, щоб сформувати одні дані.
OP_SUBSTR: Прийняти параметр length (у байтах), отримати фрагмент даних зі стека, видалити байти цієї довжини та помістити його назад у стек.
OP_LEFT та OP_RIGHT: приймає параметр length, який бере фрагмент даних зі стека та видаляє байти вказаної довжини з одного чи іншого боку.
OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT та OP_DOWNSHIFT: приймає елемент даних і виконує над ним відповідні бітові операції.
OP_ 2 MUL, OP_2D IV, OP_MUL, OP_DIV та OP_MOD: Математичні оператори для операцій множення, ділення та за модулем (повернення залишку ділення).
На додаток до наведених вище список кодів операцій для відновлення, Расті Рассел пропонує ще три коди операцій, призначені для спрощення комбінації різних кодів операцій:
OP_CTV (або TXHASH/ еквівалент Код операції): дозволяє точне примусове виконання певних частин транзакції, які мають точно відповідати визначеним заздалегідь.
CSFS: дозволяє перевіряти підписи, а не лише для всієї транзакції, що вимагає, щоб певні частини сценарію або використовувані дані були підписані, ордер бути виконані.
OP_TWEAKVERIFY: перевіряє операції на основі Шнорра за участю Відкритий ключ, такі як додавання або віднімання окремих Відкритий ключ від сукупного Відкритий ключ. Це може бути використано для забезпечення того, що коли одна сторона в односторонньому порядку залишає спільний невикористаний результат транзакції (UTXO), кошти всіх інших учасників направляються на агрегований відкритий ключ, який не вимагає підписання сторони, що вибуває, для здійснення спільних витрат.
Чому ми це робимо
Рівень 2 мережі, по суті, є розширеннями базового рівня Біткойн, і вони функціонально обмежені функціями базового рівня. Lighting Network вимагає трьох окремих Софтфорк, перш ніж їх можна буде фактично впровадити: CHECKLOCKTIMEVERIFY (CLTV), checksequenceverify (csv) і SegWit (Segregated Witness).
Без більш гнучкого базового рівня ви не зможете побудувати більш гнучку мережу рівня 2. Єдиний ярлик – довіряти третім сторонам, що дуже просто і зрозуміло, і я сподіваюся, що ми всі прагнемо максимально усунути довірених третіх осіб з усіх аспектів взаємодії з Біткойн.
Ми повинні бути в змозі зробити щось, що зараз неможливо в ордер, щоб безпечно об'єднати більше двох людей в один невикористаний вихід транзакції (UTXO) і мати можливість працювати без довіри на базовому рівні. Біткойн Поточної гнучкості сценарію недостатньо. На самому базовому рівні нам потрібні контракти, і нам потрібні скрипти, які можуть фактично забезпечувати більш детальну інформацію про виконання транзакцій, щоб гарантувати, що безпечний вихід користувача з власної UTXO не наражає на небезпеку кошти інших користувачів.
У вищій перспективі це те, що нам потрібно:
Самоаналіз: Ми повинні бути в змозі фактично перевірити конкретні деталі в стеку про саму транзакцію витрат, наприклад, «ця сума грошей піде на цей публічний ключ якогось результату». Це дозволяє мені самостійно знімати свої кошти за допомогою мого власного Taproot відділення, гарантуючи, що я не зможу зняти чужі кошти. Виконаний скрипт забезпечить відправку коштів інших власників назад на Адреса, що складається з Відкритий ключ інших користувачів, на випадок, якщо інші учасники спричинять втрату коштів.
Пряме перенесення даних: Скажімо, ми беремо концепцію єдиного UTXO, наприклад, з великою кількістю людей, що будь-хто може приходити і йти, як йому заманеться. У цьому випадку нам потрібен спосіб відстежити, у кого більше або менше грошей, зазвичай використовуючи Дерево Меркла та її коріння. Це означає, що коли хтось звільняється, ми повинні обов'язково «записати», хто на що має право в рамках зміни UTXO за кошти всіх інших. По суті, це специфічне використання самоаналізу.
Відкритий ключ Модифікація: Нам потрібно переконатися, що зміни в сукупному Відкритий ключ можуть бути перевірені в стеку. У схемі розподілу невикористаних транзакцій (UTXO) наша мета полягає в тому, щоб сприяти співпраці та ефективному потоку коштів через агрегований Відкритий ключ, який включає всіх учасників. Коли хтось в односторонньому порядку залишає спільну UTXO, нам потрібно видалити його особисті Відкритий ключ із сукупного Відкритий ключ. Якщо всі можливі комбінації не обчислені заздалегідь, єдиним варіантом є перевірка, що віднімання одного відкритого ключа із сукупного відкритого ключа призведе до отримання дійсного відкритого ключа, який складатиметься з решти окремих відкритих ключів.
Як бути в безпеці: VAROPS Як я вже говорив вище, причина відключення всіх цих кодів операцій полягає в тому, щоб усунути атаки DOS (які призводять до збою мережі через надсилання великої кількості запитів на спам), які можуть призвести до збою вузлів, що складають мережу. Одним із способів вирішення цієї проблеми є обмеження кількості ресурсів, які можуть бути використані будь-яким із цих кодів операцій.
Коли справа доходить до перевірки підпису, найдорожчої частини скрипта Біткойн, у нас вже є таке рішення, яке називається бюджетом операції підпису (sigops). Кожне використання перевірки підпису Код операції споживає певний «бюджет», тобто кількість операцій підпису, дозволених для кожного блоку, що встановлює жорсткий ліміт на вартість, яку транзакція може генерувати для перевірки блоку.
Taproot змінює цей спосіб роботи, не лонгуючий використовувати єдиний глобальний ліміт Блок, а замість цього кожна транзакція має свій власний ліміт sigops (операція підпису), пропорційний розміру транзакції. По суті, це дорівнює тому ж глобальному ліміту, але простіше зрозуміти, що кожна транзакція має лонг менше доступних сигопів.
Зміна ліміту Taproot sigops (сигнатурна операція) для обробки кожної транзакції відкриває можливість узагальнюючого підходу, що і запропонував Расті Рассел в термінах лімітів varops. Ідея полягає в тому, щоб призначити вартість кожному повторно активованому Код операції рахунок для найгіршого сценарію, який може створити кожен Код операції, тобто найдорожчих обчислювальних витрат, понесених на момент перевірки. Таким чином, кожен Код операції матиме свій власний ліміт «sigops», що обмежує кількість ресурсів, які він може споживати під час процесу валідації. Це також ґрунтуватиметься на розмірі будь-яких транзакцій, які використовують ці Код операції, тому висновок може бути полегшений, зберігаючи при цьому неявний глобальний ліміт на Блок.
Це вирішило б проблему DOS атаки (шляхом надсилання великої кількості спам-запитів, що призвело до збою мережі) через ці спам-транзакції, і те, що змусило Сатоші Накамото спочатку відключити всі ці коди операцій.
Імпульс для руху вперед
Я впевнений, що більшість з вас довго думатиме: «Це занадто багато змін». Я можу це зрозуміти, але я думаю, що важливим аспектом, який слід розуміти як пропозицію, є те, що нам не потрібно робити все це. Цінність цієї пропозиції не обов'язково полягає в тому, що всі ці функції повністю відновлені, але в тому, що ми збираємося цілісно розглянути величезний набір базових компонентів і запитати себе, чого ми насправді хочемо з точки зору функціональності.
Це було б повним зрушенням у порівнянні з останніми трьома роками суперечок і дискусій, що ми сперечалися лише про невеликі вузькі зміни, які мають лише певні функції. Це як площа, де всі можуть зібратися разом і подивитися на напрямок майбутнього. Можливо, ми врешті-решт відновимо всі ці функції, або, можливо, в кінцевому підсумку активуємо лише деякі з них, тому що Консенсус полягає в тому, що це ті, які, на нашу думку, потрібно ввімкнути.
Незалежно від кінцевого результату, це може бути зміною, яка позитивно вплине на всю розмову про наш майбутній напрямок. Насправді ми можемо скласти карту і отримати повну картину ситуації, замість того, щоб навпомацки обговорювати, який туманний маршрут обрати наступним.
Це аж ніяк не той шлях, яким ми повинні йти, але я думаю, що це найкращий шанс для нас вирішити, яким шляхом ми хочемо піти. Настав час знову почати працювати разом практичним і продуктивним способом.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Чудове відновлення сценарію: шлях Біткойн вперед
ОРИГІНАЛЬНИЙ АВТОР: SHINOBI
Оригінальна збірка: Блок єдиноріг
Незважаючи на масштаб пропозиції, в чому причина того, що «велике відновлення сценарію» Расті Рассела може стати шляхом вперед для розвитку Біткойн?
Блок єдиноріг Примітка: Расті Рассел є активним розробником у спільноті Біткойн і користується великою повагою в спільноті. Він багато працював над розробкою ядра Linux і брав участь у багатьох лонг Біткойн основних проектах розробки.
Біткойн спочатку був розроблений як повна мова сценаріїв, призначена для того, щоб охопити та підтримка будь-які потенційні випадки використання безпеки, які користувачі можуть придумати в майбутньому. Як Сатоші Накамото сказав перед тим, як зникнути:
«Суть Біткойн полягає в тому, що після випуску версії 0.1 дизайн ядра визначається для решти життєвого циклу. Тому я хотів розробити його так, щоб підтримка всі можливі типи торгівлі, які тільки міг придумати. Проблема в тому, що все вимагає спеціальних кодів підтримка і полів даних, незалежно від того, використовуються вони чи ні, що призводить до найдовших особливих випадків. Рішенням є сценарій, який узагальнює проблему, щоб обидві сторони могли описати свої транзакції з конкретними умовами, які мережа Нода оцінює або перевіряє на основі цих умов». - Сатоші Накамото, 17 червня 2010
Вся його мета полягає в тому, щоб дати користувачам мову, яка є досить загальною, щоб вони могли організовувати свої типи транзакцій так, як їм заманеться. Тобто шорти, щоб користувачі могли розробляти та експериментувати з тим, як писати власні монети.
Перед тим, як він зник, Сатоші Накамото видалив 15 з цих кодів операцій, повністю відключив їх і додав жорстке обмеження на стек скриптового рушія, яке обмежувало розмір блоків даних, якими можна було маніпулювати (520 байт). Це пов'язано з тим, що він фактично облажався, залишивши позаду багато способів, за допомогою яких складні скрипти можуть бути використані для здійснення DOS атак на всю мережу (надсилання великої кількості спам-запитів, що призводить до виходу мережі з ладу), створюючи величезні та дорогі транзакції, які призводять до краху вузлів.
Ці коди операцій були видалені не тому, що Сатоші Накамото вважали, що функції небезпечні або що люди не повинні використовувати їх для створення чогось, чого можна було б досягти, а просто (принаймні на перший погляд) через ризик, який вони становлять для всієї мережі без обмежень ресурсів, таких як найгірші витрати на перевірку, які вони можуть накласти на мережу без обмежень.
З тих пір кожне оновлення Біткойн закінчувалося функціональною оптимізацією решти функцій, виправленням інших менш серйозних недоліків, які Сатоші Накамото залишили нам, і розширенням функціональності нашої підмножини скриптів, що залишилася.
Чудове відновлення скрипта
На конференції в Остіні Біткойн++ на початку травня розробник core Lighting Network Расті Рассел зробив дуже радикальну пропозицію у своєму першому виступі на конференції, де він, по суті, виступив з ідеєю повторного включення великого Код операції туги, який Сатоші Накамото вимкнув до того, як він зник у 2010 році.
За роки, що минули з моменту активації Taproot у 2021 році (Taproot є серйозним оновленням Біткойн, спрямованим на покращення конфіденційності, безпеки та масштабованості), простір розробки насправді був трохи безцільним. Ми всі знаємо, що Біткойн недостатньо масштабований, щоб по-справжньому надавати самосуверенні послуги будь-якій значній частині населення світу, і, можливо, навіть не зможе забезпечити масштабованість постачальникам послуг, які можуть перевершити дуже великих зберігачів і постачальників послуг, і не можуть по-справжньому звільнитися від обмежень лонг рук урядів, таким чином, щоб мінімізувати довіру або опіку.
Ця стаття вказує на технічний рівень Біткойн, який не є предметом обговорення. Питання, про яке варто посперечатися, полягає в тому, як виправити цей недолік, що є дуже спірною темою. З моменту введення Taproot всі придумують дуже вузькі пропозиції, які спрямовані на вирішення проблем, які можуть бути досягнуті тільки для конкретних випадків використання.
Наприклад, ANYPREVOUT (APO) — це пропозиція, яка дозволяє повторно використовувати підписи в різних транзакціях, лонг також сценарій і введена сума однакові, і ця пропозиція спеціально розроблена для оптимізації Lighting Network та його лонгуючий версій. CHECKTEMPLATEVERIFY (CTV) — це пропозиція, яка вимагає, щоб тверді монети витрачалися лише на транзакції, які точно відповідають заздалегідь визначеним транзакціям, і ця пропозиція покликана розширити функціональність попередньо підписаних ланцюжків транзакцій, зробивши їх повністю недовірливими. OP_VAULT спеціально розроблений для встановлення «тайм-ауту» для рішення для холодного зберігання, щоб користувачі могли «відключити» його від холодного сховища, відправивши його в більш холодні налаштування лонг, щоб запобігти компрометації своїх Секретний ключ.
Є й інші пропозиції, але я думаю, що ви вже зрозуміли суть. За останні кілька років кожна пропозиція була розроблена таким чином, щоб або трохи збільшити масштабованість, або покращити одну невелику функцію, оскільки це вважається бажаним. Це першопричина того, чому ці дискусії не досягли прогресу. Ніхто не був задоволений іншими пропозиціями, тому що вони не відповідали тим сценаріям використання, які вони хотіли бачити.
Ніхто, крім спонсора пропозиції, не вважає, що будь-яка пропозиція є достатньо всеосяжною, щоб вважатися розумним наступним кроком.
Саме така логіка лежить в основі «Great Script Recovery». Просуваючи та аналізуючи повне відновлення скриптів, як Сатоші Накамото було задумано спочатку, ми можемо спробувати дослідити всі потрібні нам короткі функції, замість того, щоб сперечатися та сперечатися про те, які невеликі розширення функцій є достатньо хорошими прямо зараз.
КОДИ ОПЕРАЦІЙ (Код операції)
На додаток до наведених вище список кодів операцій для відновлення, Расті Рассел пропонує ще три коди операцій, призначені для спрощення комбінації різних кодів операцій:
OP_CTV (або TXHASH/ еквівалент Код операції): дозволяє точне примусове виконання певних частин транзакції, які мають точно відповідати визначеним заздалегідь.
CSFS: дозволяє перевіряти підписи, а не лише для всієї транзакції, що вимагає, щоб певні частини сценарію або використовувані дані були підписані, ордер бути виконані.
OP_TWEAKVERIFY: перевіряє операції на основі Шнорра за участю Відкритий ключ, такі як додавання або віднімання окремих Відкритий ключ від сукупного Відкритий ключ. Це може бути використано для забезпечення того, що коли одна сторона в односторонньому порядку залишає спільний невикористаний результат транзакції (UTXO), кошти всіх інших учасників направляються на агрегований відкритий ключ, який не вимагає підписання сторони, що вибуває, для здійснення спільних витрат.
Чому ми це робимо
Рівень 2 мережі, по суті, є розширеннями базового рівня Біткойн, і вони функціонально обмежені функціями базового рівня. Lighting Network вимагає трьох окремих Софтфорк, перш ніж їх можна буде фактично впровадити: CHECKLOCKTIMEVERIFY (CLTV), checksequenceverify (csv) і SegWit (Segregated Witness).
Без більш гнучкого базового рівня ви не зможете побудувати більш гнучку мережу рівня 2. Єдиний ярлик – довіряти третім сторонам, що дуже просто і зрозуміло, і я сподіваюся, що ми всі прагнемо максимально усунути довірених третіх осіб з усіх аспектів взаємодії з Біткойн.
Ми повинні бути в змозі зробити щось, що зараз неможливо в ордер, щоб безпечно об'єднати більше двох людей в один невикористаний вихід транзакції (UTXO) і мати можливість працювати без довіри на базовому рівні. Біткойн Поточної гнучкості сценарію недостатньо. На самому базовому рівні нам потрібні контракти, і нам потрібні скрипти, які можуть фактично забезпечувати більш детальну інформацію про виконання транзакцій, щоб гарантувати, що безпечний вихід користувача з власної UTXO не наражає на небезпеку кошти інших користувачів.
У вищій перспективі це те, що нам потрібно:
Самоаналіз: Ми повинні бути в змозі фактично перевірити конкретні деталі в стеку про саму транзакцію витрат, наприклад, «ця сума грошей піде на цей публічний ключ якогось результату». Це дозволяє мені самостійно знімати свої кошти за допомогою мого власного Taproot відділення, гарантуючи, що я не зможу зняти чужі кошти. Виконаний скрипт забезпечить відправку коштів інших власників назад на Адреса, що складається з Відкритий ключ інших користувачів, на випадок, якщо інші учасники спричинять втрату коштів.
Пряме перенесення даних: Скажімо, ми беремо концепцію єдиного UTXO, наприклад, з великою кількістю людей, що будь-хто може приходити і йти, як йому заманеться. У цьому випадку нам потрібен спосіб відстежити, у кого більше або менше грошей, зазвичай використовуючи Дерево Меркла та її коріння. Це означає, що коли хтось звільняється, ми повинні обов'язково «записати», хто на що має право в рамках зміни UTXO за кошти всіх інших. По суті, це специфічне використання самоаналізу.
Відкритий ключ Модифікація: Нам потрібно переконатися, що зміни в сукупному Відкритий ключ можуть бути перевірені в стеку. У схемі розподілу невикористаних транзакцій (UTXO) наша мета полягає в тому, щоб сприяти співпраці та ефективному потоку коштів через агрегований Відкритий ключ, який включає всіх учасників. Коли хтось в односторонньому порядку залишає спільну UTXO, нам потрібно видалити його особисті Відкритий ключ із сукупного Відкритий ключ. Якщо всі можливі комбінації не обчислені заздалегідь, єдиним варіантом є перевірка, що віднімання одного відкритого ключа із сукупного відкритого ключа призведе до отримання дійсного відкритого ключа, який складатиметься з решти окремих відкритих ключів.
Як бути в безпеці: VAROPS Як я вже говорив вище, причина відключення всіх цих кодів операцій полягає в тому, щоб усунути атаки DOS (які призводять до збою мережі через надсилання великої кількості запитів на спам), які можуть призвести до збою вузлів, що складають мережу. Одним із способів вирішення цієї проблеми є обмеження кількості ресурсів, які можуть бути використані будь-яким із цих кодів операцій.
Коли справа доходить до перевірки підпису, найдорожчої частини скрипта Біткойн, у нас вже є таке рішення, яке називається бюджетом операції підпису (sigops). Кожне використання перевірки підпису Код операції споживає певний «бюджет», тобто кількість операцій підпису, дозволених для кожного блоку, що встановлює жорсткий ліміт на вартість, яку транзакція може генерувати для перевірки блоку.
Taproot змінює цей спосіб роботи, не лонгуючий використовувати єдиний глобальний ліміт Блок, а замість цього кожна транзакція має свій власний ліміт sigops (операція підпису), пропорційний розміру транзакції. По суті, це дорівнює тому ж глобальному ліміту, але простіше зрозуміти, що кожна транзакція має лонг менше доступних сигопів.
Зміна ліміту Taproot sigops (сигнатурна операція) для обробки кожної транзакції відкриває можливість узагальнюючого підходу, що і запропонував Расті Рассел в термінах лімітів varops. Ідея полягає в тому, щоб призначити вартість кожному повторно активованому Код операції рахунок для найгіршого сценарію, який може створити кожен Код операції, тобто найдорожчих обчислювальних витрат, понесених на момент перевірки. Таким чином, кожен Код операції матиме свій власний ліміт «sigops», що обмежує кількість ресурсів, які він може споживати під час процесу валідації. Це також ґрунтуватиметься на розмірі будь-яких транзакцій, які використовують ці Код операції, тому висновок може бути полегшений, зберігаючи при цьому неявний глобальний ліміт на Блок.
Це вирішило б проблему DOS атаки (шляхом надсилання великої кількості спам-запитів, що призвело до збою мережі) через ці спам-транзакції, і те, що змусило Сатоші Накамото спочатку відключити всі ці коди операцій.
Імпульс для руху вперед
Я впевнений, що більшість з вас довго думатиме: «Це занадто багато змін». Я можу це зрозуміти, але я думаю, що важливим аспектом, який слід розуміти як пропозицію, є те, що нам не потрібно робити все це. Цінність цієї пропозиції не обов'язково полягає в тому, що всі ці функції повністю відновлені, але в тому, що ми збираємося цілісно розглянути величезний набір базових компонентів і запитати себе, чого ми насправді хочемо з точки зору функціональності.
Це було б повним зрушенням у порівнянні з останніми трьома роками суперечок і дискусій, що ми сперечалися лише про невеликі вузькі зміни, які мають лише певні функції. Це як площа, де всі можуть зібратися разом і подивитися на напрямок майбутнього. Можливо, ми врешті-решт відновимо всі ці функції, або, можливо, в кінцевому підсумку активуємо лише деякі з них, тому що Консенсус полягає в тому, що це ті, які, на нашу думку, потрібно ввімкнути.
Незалежно від кінцевого результату, це може бути зміною, яка позитивно вплине на всю розмову про наш майбутній напрямок. Насправді ми можемо скласти карту і отримати повну картину ситуації, замість того, щоб навпомацки обговорювати, який туманний маршрут обрати наступним.
Це аж ніяк не той шлях, яким ми повинні йти, але я думаю, що це найкращий шанс для нас вирішити, яким шляхом ми хочемо піти. Настав час знову почати працювати разом практичним і продуктивним способом.