Search the Community

Софт-форка против Хард-форка Важно отметить, что и Taproot, и Schnorr могут быть реализованы как программная вилка. Хотя технически возможно реализовать хард-форк в Биткойне, он обычно считается наихудшим из возможных путей обновления по нескольким причинам: координация Обратная совместимость Риск раскола сообщества На данный момент координация между основными экономическими, техническими и общественными игроками практически невозможна из-за децентрализованной природы Биткойна. Использование дня флага или установка крайнего срока, к которому каждый должен перейти на новую версию, является серьезной проблемой. Команды разработчиков программного обеспечения имеют фазы проектирования и итерации, экономические субъекты во всем мире не всегда подключаются к одним и тем же каналам, и охват 100% миллионов отдельных пользователей просто невозможен. Обратная совместимость также является важным конструктивным решением, которое нельзя игнорировать при разработке программного обеспечения. Почти все обновления программного обеспечения, которые сохраняют обратную совместимость, выигрывают в долгосрочной перспективе по сравнению с разработками, которые ломают и оставляют старые версии непригодными для использования. Софт-форки, как правило, обратно совместимы, в то время как хард-форки по определению нет. В заключение, Схемы подписи и мультиподпись Аналог эллиптической кривой алгоритма цифровой подписи (DSA), алгоритма цифровой подписи эллиптической кривой (ECDSA) был принят в 1999 и 2000 годах в качестве стандартов ANSI, IEEE и NIST и предоставил ряд преимуществ по сравнению с широко распространенным алгоритмом RSA, в том числе меньшим размеры ключей и зашифрованные сообщения, более быстрое время вычислений и более низкие требования к памяти и пропускной способности. Биткойн использует эллиптическую кривую secp256k1 с алгоритмом ECDSA ; параметры кривой были специально выбраны неслучайным образом и обеспечивают особенно эффективные вычисления. В частности, открытый и закрытый ключи Биткойна могут использоваться с ECDSA с использованием кривой secp256k1, а также могут использоваться для генерации подписей Шнорра. Во многих случаях для подписи сообщения или транзакций необходима только одна подпись. Однако очевидно, что в определенных обстоятельствах наличие нескольких сообщений или транзакций для подписи ключей (мульти-подпись) может быть особенно полезным и более безопасным. Большинство многосигнальных схем обычно требуют подписей m-of-n от нескольких человек, учреждений или запрограммированных сценариев. Это ограничивает средства от передаваемых до требования о сотрудничестве между н- сторонами, пока оно не будет выполнено. Базовые транзакции в биткойнах (отправка биткойнов на открытый ключ) известны как Pay-to-Public-Key-Hash (P2PKH). В отличие от P2PKH, Pay to Script Hash (P2SH) является расширенным типом транзакции, используемой в биткойнах, и позволяет отправителю переводить средства в хэш произвольного допустимого сценария. P2SH в основном используется для многосигнальных и ненативных транзакций SegWit (P2WPKH-in-P2SH). Изначально изложенная в BIP 16, цель P2SH состоит в том, чтобы «передать ответственность за предоставление условий для выкупа транзакции от отправителя средств к получателю». [1] Вместо того, чтобы заставлять отправителей вставлять длинные сценарии условий расходов в их scriptPubKey, отправители могут помещать хэш своих условий расходов вместо этого, называемого сценарием погашения. Транзакция финансирования P2SH содержит хэш сценария погашения в scriptPubKey. Отправитель может финансировать любой произвольный сценарий погашения без того, чтобы другие знали конкретные условия расходов для сценария - только получатель (и) знают условия дальнейших расходов. Для транзакций с несколькими сигнатурами отправитель может отправлять средства, не зная требуемых открытых ключей адреса с несколькими сигнатурами. Открытые ключи раскрываются только тогда, когда получатель тратит средства. Когда получатель решает потратить средства, он должен раскрыть весь сценарий, а также решение сценария; любой может проверить, что предоставленный скрипт действительно был оригинальным. Однако у P2SH есть недостатки. Все возможные условия, которые могли быть выполнены, включая условия, которые не были выполнены, должны быть раскрыты. Это, естественно, создает потенциальные проблемы с конфиденциальностью, поскольку участники сети могут узнать все возможные способы выполнения условий, какие кошельки были использованы и многое другое. Кроме того, это может быть особенно громоздким, если существует много возможных условий, и в этом случае вычисления и проверка становятся тяжелыми для данных. Другие схемы мульти-подписи включают секретный обмен Шамира (SSS), пороговое значение ECDSA, пороговое значение Ed25519, сигнатуры Бохен-Линн-Шахама (BLS) и сигнатуры Шнорра; Есть много компромиссов между этими схемами, включая, но не ограничиваясь ими, прообразы, надежные настройки, интерактивные обходы, конфиденциальность и эффективность вычислений. Подписи Шнорра Схема подписи Schnorr была запатентована Клаусом Шнорром в 1991 году, а срок действия патента истек в 2008 году. Основное преимущество подписей Schnorr состоит в том, что они делают операции с множеством подписей и единой подписью неразличимыми в блокчейне. Используя подписи Schnorr, несколько подписчиков могут создать агрегированный открытый ключ и затем совместно подписать его одной подписью, а не публиковать каждый открытый ключ и каждую подпись отдельно в блокчейне. Это значительное улучшение масштабируемости и конфиденциальности. Сигнор Schnorr, заменяющий ECDSA, улучшает инфраструктуру цифровой подписи Биткойна несколькими способами с помощью трех ключевых новых функций: Non-тягучесть Линейная проверка Конфиденциальность нескольких сигнатур через агрегацию ключей Непревзойденность - это победа сетей уровня 2, построенных на основе цепочки биткойнов. Одной из основных проблем с ECDSA является тривиальная природа аннулирования хеша транзакции перед ее помещением в блок: небезопасно принимать цепочку неподтвержденных транзакций, поскольку более поздние транзакции зависят от хешей предыдущих транзакций, и поэтому рекомендуется ждать подтверждения транзакции 6 раз. С Schnorr гибкость больше не является проблемой, оптимизируя принятие Уровня 2 и повышая безопасность. Подписи Schnorr приводят к значительной экономии места и экономии времени проверки. Проверка подписи Schnorr является линейной, что означает, что ключ и части подписи на этапе проверки подписи могут быть агрегированы. Эта новая функция, известная как пакетная проверка, означает, что проверка более чем одной подписи за раз может происходить быстрее, чем раньше. Это ускорение, полученное благодаря проверке нескольких подписей за один раз вместо линейной проверки по одной. Естественно, с большими наборами подписей, сбережения увеличиваются, но в конечном итоге уменьшаются. Соотношение времени, необходимого для индивидуальной проверки n подписей и проверки пакета из n подписей, увеличивается логарифмически с увеличением количества подписей; время, необходимое для проверки пакета из 100 подписей, в 1,75 раза быстрее, BIP Schnorr позволяет программному обеспечению кошелька объединять ключи. Выходные данные Schnorr для нескольких подписей выглядят как выходные сигналы для одной подписи (подробнее об этом ниже в Taproot). До Schnorr транзакции с несколькими подписями было легко обнаружить, и их можно было отличить от обычных транзакций в сети. В P2SH сеть знает о существовании многосигнальной транзакции, кто подписывает, и сколько подписчиков там. При использовании Schnorr внешний наблюдатель не может определить разницу, так как подписывающие стороны создают агрегированный открытый ключ с единственной подписью. Это помогает с масштабированием, функциональностью и конфиденциальностью. У Schnorr есть и другие незначительные преимущества. Подписи Шнорра являются фиксированной 64-байтовой сигнатурой, которая меньше существующих сигнатур ECDSA размером 70–72 байта. У Шнорра есть формальное доказательство безопасности; для ECDSA нет. У Schnorr есть адаптивные подписи, что является функцией, которая помогает с атомарными свопами, а также может использоваться для общих каналов оплаты. Taproot & Tapscript Меркелизированное абстрактное синтаксическое дерево (MAST) Первоначально MAST был предложен разработчиком протокола Bitcoin доктором Джонсоном Лау в 2016 году. [2] MAST предлагает новую программу-свидетеля, которая использует дерево Merkle для кодирования взаимоисключающих ветвей в сценарии, тем самым обеспечивая более сложные условия обременения, улучшая конфиденциальность, скрывая неисполненные условия / сценарии, и позволяющие включать несогласованные принудительно данные с очень низкими или без дополнительных затрат. MAST позволяет структурировать несколько условий расходов (как условия с несколькими подписями, так и условия блокировки по времени) внутри дерева Меркля и требует только выявления выполненных условий (в отличие от требования P2SH, чтобы все условия были раскрыты). Если какое-либо из условий выполнено, корень и путь Merkle могут быть использованы для проверки того, что условие находится в дереве Merkle, при этом остальная часть дерева Merkle скрыта. Помимо преимущества конфиденциальности, MAST также может создавать транзакции меньшего размера. Размеры транзакций без MAST линейно увеличиваются в размерах, тогда как размеры транзакций MAST увеличиваются только логарифмически, предлагая значительную эффективность масштабирования для более сложных ситуаций обременения. Это особенно актуально, учитывая жесткие ограничения размера байтов в Биткойне; Базовые сценарии и SegWit имеют ограничение в 10 000 байтов, а транзакции P2SH имеют ограничение в 520 байтов. Количество вложенных сценариев и размер данных обременения с MAST и без источника Стержневой корень Обновление Taproot, конкретная реализация протокола MAST, делает выходные данные и совместные расходы неотличимыми друг от друга. [3, 4] Taproot, как и MAST, использует ветви Merkle, чтобы скрыть неисполненные ветви в скриптах. Это обновление сценариев, известное как Tapscript, означает, что частично выполненные сценарии скрывают оставшуюся часть кода выполнения до тех пор, пока он не будет использован, при этом сохраняя целостность этого кода, когда он впоследствии будет проверен и проверен коллегами. Taproot и Tapscript разработаны с самого начала, чтобы быть обновляемыми и обновляемыми. Их добавление к базе кода не является существенным изменением, в целом, согласованные изменения для реализации Taproot и Tapscript составляют всего около 500 строк кода. Использование специализированного биткойн-скрипта легко идентифицируется и выглядит иначе, чем простая трата с адреса на стороннего наблюдателя. С Taproot все выходы выглядят одинаково. Реальное новшество Taproot заключается в его гибкости для совместных расходов на сохранение конфиденциальности: существуют ситуации, когда доказательство существования дерева Меркле не нужно публиковать, а нужно публиковать только один открытый ключ и одну подпись. Пользователи Биткойна могут использовать их в качестве программируемых денег, не указывая, что они используют их для этой цели, улучшая как конфиденциальность, так и функциональность. Все участники сценария могут договориться о результате, независимо от существующих условий, и просто вместе подписать транзакцию по расходам. Это «кооперативное закрытие» использует «пороговую сигнатуру» Шнорра, так что транзакция выглядит как обычная транзакция - открытые ключи участников объединяются в пороговый открытый ключ и умножаются на хэш сценария (все « некооперативный »закрывается). Для цепочки эта совместная транзакция выглядит как обычная транзакция с традиционным открытым ключом и подписью. Только в случае некооперативных расходов существование дерева Меркле должно быть раскрыто. В расходах, не связанных с кооперацией, исходный открытый ключ порога можно настроить с помощью условного сценария, который выполняется для создания настроенного открытого ключа порога; это доказывает, что средства сценария могут быть потрачены, если выполняются конкретные условия сценария. В качестве альтернативы пороговый открытый ключ можно настроить с помощью корня Merkle структуры MAST всех различных условий для расходования средств сценария. Таким образом, должны быть выявлены только те условия расходов, которые соблюдены, а оставшиеся условия могут оставаться скрытыми, тем самым улучшая конфиденциальность и оптимизируя использование сетевых ресурсов. Будущий путь обновления Подписи Schnorr и Taproot с Tapscript улучшают масштабируемость и конфиденциальность, скрывая скрипты и скрывающие ключи, и ограничивают возможность третьих сторон определять типы происходящих транзакций. Эти улучшения могут существенно улучшить принятие и безопасность транзакций с несколькими подписями. В будущем разработчики Биткойна и его сообщество планируют интегрировать эти улучшения в основной код. Различные дополнения, ориентированные на конфиденциальность, намечены для добавления в код Bitcoin Core и сделают транзакции более безопасными, более частными, а Биткойн - более прибыльным. Рекомендации и заметки [1] https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki [2] https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki [3] https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki [4] https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki