Forwarded from CryptoBotan
✅✅✅
Итак, что такое SPV "Simplified Payment Verification" разобрались. Это пригодится нам, чтобы рассмотреть еще одно решение в стеке биткоина для Perfomance&Usability - Neutrino.
⬇️⬇️⬇️
В марте 2018 года Lightning Labs объявила о выпуске бета-версии программного клиента Lightning Network Daemon (LND). Этот клиент предназначен для разработчиков и используется для доступа к сети LN.
Lightning Network Daemon (LND) - это комплексная реализация сетевого узла Lightning. У LND есть несколько подключаемых сервисов back-end chain, включая btcd (полный узел), bitcoind (консольный интерфейс) и наш сегодняшний герой, протокол Neutrino (новый экспериментальный клиент-light).
Протокол Neutrino (BIP 157, BIP 158) был предложен Olaoluwa Osuntokun, Alex Akselrod, Jim Posen.
Neutrino - это защищающий конфиденциальность клиент light-wallet, разработанный с упором на использование LN. Он написан на языке Go и использует уплотненные блочные фильтры для улучшения реализации SPV Bloom Filtering (BIP 37) Light-client.
Я писал о BIP 37 и фильтрах Блума в посте о SPV.
Если сказать совсем уж просто, Neutrino придуман для того, чтобы из всего Биткойн-блокчейна быстро доставать те транзакции, которые относятся только к конкретному пользователю, который использует маломощное устройство с ограниченной памятью, пропускной способностью и ненадежной связью. Плюс ко всему контроль над PrivateKey находится в руках пользователя.
Если тебе, мой криптоботанёнок, больше и не нужно знать, то тут можешь остановиться. Дальше я разберу все это, более детально😉
Как работает Neutrino?
Neutrino предназначен для минимизации пропускной способности и хранения данных на стороне клиента при сохранении конфиденциальности на полных узлах, обслуживающих клиентов light.
Это достигается с помощью механизма, в котором фильтры GSC используются для представления адресов, соответствующих определенному блоку, которые представляют собой более сжатую версию блока (около 15Кб), чем исходный (до 4Мб).
Фильтры GCS или Golomb-Coded Set - это метод сжатия данных без потерь, использующий семейство кодов сжатия данных,(Википедия)
Устройства с низкой пропускной способностью (мобильные устройства) могут в дальнейшем определить, имеют ли транзакции внутри недавно созданного блока отношение к кошельку пользователя. Если блок содержит соответствующие транзакции, то клиент Neutrino загружает соответствующий блок, но не весь, а только данные транзакции, а не подписи или данные свидетеля.
Затем клиент может сканировать и обновлять информацию о своих транзакциях с помощью процесса, выполняемого ПО кошелька пользователя, а не удаленным узлом, как в BIP37, что является важным соображением конфиденциальности, так как данные не пересылаются по сети.
Основная проблема, которую решает Neutrino и которую не решала SPV в BIP 37 - это утечка информации с помощью фильтров Блума в узлах SPV, которые могут быть использованы для деанонимизации пользователей.
Клиенты Neutrino требуют значительно меньшей пропускной способности из-за сжатия GSC и уменьшают вычислительную нагрузку на полные узлы, так как фильтры, отправленные клиентам Neutrino, должны быть вычислены только один раз (в BIP37 fullnodes вычисляют результаты для каждого клиента).
На узле Neutrino может храниться несколько десятков Мб данных, что по сравнению с fullnode не такая уж и большая цифра.
Будущие разработки в области Neutrino включают в себя извлечение блочного фильтра из внешней сети Биткойна и потенциальную интеграцию хэша блочного фильтра GSC непосредственно в заголовок блока через софт-форк. В конечном итоге, целью Neutrino является создание фундамента для следующего поколения приложений кошельков, которые будут построены поверх сети.
Интересно, но факт:
Разработчик Bitcoin Advisory-Пьер Рошар-предложил плагин Microsoft Excel для сети Lightning. Плагин использует клиент Neutrino и позволяет пользователям вставлять адреса кошельков и платить другим пользователям в Excel через LN.😕
#PerfomanceAndUsability
Итак, что такое SPV "Simplified Payment Verification" разобрались. Это пригодится нам, чтобы рассмотреть еще одно решение в стеке биткоина для Perfomance&Usability - Neutrino.
⬇️⬇️⬇️
В марте 2018 года Lightning Labs объявила о выпуске бета-версии программного клиента Lightning Network Daemon (LND). Этот клиент предназначен для разработчиков и используется для доступа к сети LN.
Lightning Network Daemon (LND) - это комплексная реализация сетевого узла Lightning. У LND есть несколько подключаемых сервисов back-end chain, включая btcd (полный узел), bitcoind (консольный интерфейс) и наш сегодняшний герой, протокол Neutrino (новый экспериментальный клиент-light).
Протокол Neutrino (BIP 157, BIP 158) был предложен Olaoluwa Osuntokun, Alex Akselrod, Jim Posen.
Neutrino - это защищающий конфиденциальность клиент light-wallet, разработанный с упором на использование LN. Он написан на языке Go и использует уплотненные блочные фильтры для улучшения реализации SPV Bloom Filtering (BIP 37) Light-client.
Я писал о BIP 37 и фильтрах Блума в посте о SPV.
Если сказать совсем уж просто, Neutrino придуман для того, чтобы из всего Биткойн-блокчейна быстро доставать те транзакции, которые относятся только к конкретному пользователю, который использует маломощное устройство с ограниченной памятью, пропускной способностью и ненадежной связью. Плюс ко всему контроль над PrivateKey находится в руках пользователя.
Если тебе, мой криптоботанёнок, больше и не нужно знать, то тут можешь остановиться. Дальше я разберу все это, более детально😉
Как работает Neutrino?
Neutrino предназначен для минимизации пропускной способности и хранения данных на стороне клиента при сохранении конфиденциальности на полных узлах, обслуживающих клиентов light.
Это достигается с помощью механизма, в котором фильтры GSC используются для представления адресов, соответствующих определенному блоку, которые представляют собой более сжатую версию блока (около 15Кб), чем исходный (до 4Мб).
Фильтры GCS или Golomb-Coded Set - это метод сжатия данных без потерь, использующий семейство кодов сжатия данных,(Википедия)
Устройства с низкой пропускной способностью (мобильные устройства) могут в дальнейшем определить, имеют ли транзакции внутри недавно созданного блока отношение к кошельку пользователя. Если блок содержит соответствующие транзакции, то клиент Neutrino загружает соответствующий блок, но не весь, а только данные транзакции, а не подписи или данные свидетеля.
Затем клиент может сканировать и обновлять информацию о своих транзакциях с помощью процесса, выполняемого ПО кошелька пользователя, а не удаленным узлом, как в BIP37, что является важным соображением конфиденциальности, так как данные не пересылаются по сети.
Основная проблема, которую решает Neutrino и которую не решала SPV в BIP 37 - это утечка информации с помощью фильтров Блума в узлах SPV, которые могут быть использованы для деанонимизации пользователей.
Клиенты Neutrino требуют значительно меньшей пропускной способности из-за сжатия GSC и уменьшают вычислительную нагрузку на полные узлы, так как фильтры, отправленные клиентам Neutrino, должны быть вычислены только один раз (в BIP37 fullnodes вычисляют результаты для каждого клиента).
На узле Neutrino может храниться несколько десятков Мб данных, что по сравнению с fullnode не такая уж и большая цифра.
Будущие разработки в области Neutrino включают в себя извлечение блочного фильтра из внешней сети Биткойна и потенциальную интеграцию хэша блочного фильтра GSC непосредственно в заголовок блока через софт-форк. В конечном итоге, целью Neutrino является создание фундамента для следующего поколения приложений кошельков, которые будут построены поверх сети.
Интересно, но факт:
Разработчик Bitcoin Advisory-Пьер Рошар-предложил плагин Microsoft Excel для сети Lightning. Плагин использует клиент Neutrino и позволяет пользователям вставлять адреса кошельков и платить другим пользователям в Excel через LN.😕
#PerfomanceAndUsability
Forwarded from CryptoBotan
✅✅✅
Для стека биткоина.
Решение для масштабирования сети Биткойн - uTreeXo.
Хоть в таблице оно идет совместно с такими решениями как libMiniSketch и Tx Accumulators, я все-таки решил разобрать их по отдельности.
⬇️⬇️⬇️
Решение предложил один из главных разработчиков LN Тадж Драй в июне 2019 года.
uTreeXo - это динамический аккумулятор UTXO (неизрасходованных остатков транзакций). А нужно оно для упрощения управления полными нодами в сети биткоина.
Об UTXO я тоже уже писал и кстати в этом посте я упоминал решение uTreeXo.
Немного разберемся...
Каждый узел в сети Биткойн проверяет и сохраняет состояние сети, а кошельки отслеживают UTXO (Unspent Transaction (TX) Output). Каждый узел, для предотвращения даблспендов, должен отслеживать набор всех UTXO при проверке каждой транзакции каждого блока.
Кстати, если хотите разобраться с тем, как устроены транзакции в сети и что такое UTXO, советую глянуть пост на канале @CryptoLamer.
UTXO сильно упрощает методы учета на блокчейне. Вместо того, чтобы вынужденно отслеживать и хранить каждую транзакцию, система отслеживает только неизрасходованные коины (UTXO).
Растет количество юзеров, а следовательно и количество кошельков и наборов UTXO. Запускать узел напряжно, так как требуется все больше ресурсов. Вместо этого, юзеры используют легкие клиенты и сторонние узлы для отслеживания состояния сети. Эти легкие клиенты не хранят состояния системы и не првоеряют транзакции, но используют упрощенную проверку платежей SPV.
SPV имеет ряд недостатков и потенциальных уязвимостей, которые я описывал ранее. Тут я не буду на этом останавливаться, подробности по ссылочке выше.
Проблема таится в объеме хранимой информации. Ее можно решить при помощи криптографических аккумуляторов (компактное представление множества). Динамический аккумулятор позволяет добавлять и удалять элементы из множества, но он требует наличия общего секрета (Trusted Setup), который при генерации и утечки позволяет создавать фальшивые доказательства существования UTXO.
А теперь проще: полным узлам не нужно хранить все данные блокчейна, вместо этого аккумуляторы предоставят доказательства того, что данные верны.
uTreeXo позволяет создать динамический аккумулятор без общего секрета.
Решение uTreeXo сокращает объем памяти, необходимый для запуска полного узла, что делает фулноды более легкими. Узлам не нужно отслеживать набор всех UTXO при проверке каждой транзакции каждого блока. Достаточно лишь логарифмического представления набора этих UTXO.
При помощи uTreeXo, транзакции не просто указывают уникальный ID UTXO, который они хотят потратить, но также указывают его доказательство. Это позволяет узлам сети как проверять правильность UTXO, так и вносить необходимые изменения в соответствующие деревья Меркла.
Каждая версия uTreeXo должна содержать информацию, которая может быть использована для обновления доказательств, и владелец должен убедиться, что все такие версии применяются к доказательству UTXO, прежде чем попытаться его использовать.
Если разработки приведут к успеху, нам обещают фулноды на мобильных устройствах😅
Кому интересно подробнее, вот ссылочка на публикацию Тадж Драя
#PerfomanceAndUsability
Для стека биткоина.
Решение для масштабирования сети Биткойн - uTreeXo.
Хоть в таблице оно идет совместно с такими решениями как libMiniSketch и Tx Accumulators, я все-таки решил разобрать их по отдельности.
⬇️⬇️⬇️
Решение предложил один из главных разработчиков LN Тадж Драй в июне 2019 года.
uTreeXo - это динамический аккумулятор UTXO (неизрасходованных остатков транзакций). А нужно оно для упрощения управления полными нодами в сети биткоина.
Об UTXO я тоже уже писал и кстати в этом посте я упоминал решение uTreeXo.
Немного разберемся...
Каждый узел в сети Биткойн проверяет и сохраняет состояние сети, а кошельки отслеживают UTXO (Unspent Transaction (TX) Output). Каждый узел, для предотвращения даблспендов, должен отслеживать набор всех UTXO при проверке каждой транзакции каждого блока.
Кстати, если хотите разобраться с тем, как устроены транзакции в сети и что такое UTXO, советую глянуть пост на канале @CryptoLamer.
UTXO сильно упрощает методы учета на блокчейне. Вместо того, чтобы вынужденно отслеживать и хранить каждую транзакцию, система отслеживает только неизрасходованные коины (UTXO).
Растет количество юзеров, а следовательно и количество кошельков и наборов UTXO. Запускать узел напряжно, так как требуется все больше ресурсов. Вместо этого, юзеры используют легкие клиенты и сторонние узлы для отслеживания состояния сети. Эти легкие клиенты не хранят состояния системы и не првоеряют транзакции, но используют упрощенную проверку платежей SPV.
SPV имеет ряд недостатков и потенциальных уязвимостей, которые я описывал ранее. Тут я не буду на этом останавливаться, подробности по ссылочке выше.
Проблема таится в объеме хранимой информации. Ее можно решить при помощи криптографических аккумуляторов (компактное представление множества). Динамический аккумулятор позволяет добавлять и удалять элементы из множества, но он требует наличия общего секрета (Trusted Setup), который при генерации и утечки позволяет создавать фальшивые доказательства существования UTXO.
А теперь проще: полным узлам не нужно хранить все данные блокчейна, вместо этого аккумуляторы предоставят доказательства того, что данные верны.
uTreeXo позволяет создать динамический аккумулятор без общего секрета.
Решение uTreeXo сокращает объем памяти, необходимый для запуска полного узла, что делает фулноды более легкими. Узлам не нужно отслеживать набор всех UTXO при проверке каждой транзакции каждого блока. Достаточно лишь логарифмического представления набора этих UTXO.
При помощи uTreeXo, транзакции не просто указывают уникальный ID UTXO, который они хотят потратить, но также указывают его доказательство. Это позволяет узлам сети как проверять правильность UTXO, так и вносить необходимые изменения в соответствующие деревья Меркла.
Каждая версия uTreeXo должна содержать информацию, которая может быть использована для обновления доказательств, и владелец должен убедиться, что все такие версии применяются к доказательству UTXO, прежде чем попытаться его использовать.
Если разработки приведут к успеху, нам обещают фулноды на мобильных устройствах😅
Кому интересно подробнее, вот ссылочка на публикацию Тадж Драя
#PerfomanceAndUsability
Forwarded from CryptoBotan
✅✅✅
Cross-Input Aggregation - Агрегация перекрестного ввода
Для стека биткоина
⬇️⬇️⬇️
Так, так...нам снова придется вернуться к подписям Шнорра и затронуть MuSig.
Схема Шнорра — это протокол идентификации и метод агрегирования (суммирование) подписей, необходимых для транзакции BTC. Подписи Шнорра позволяют создавать подпись действительную для суммы PublicKeys. Несколько подписывающих лиц в транзакции-multisig, объединяют свои PublicKeys в агрегированный ключ.
Multisig-транзакции не поддерживаются ECDSA и потому реализуются при помощи смарт-контракта P2SH.
1) P2SH требуют знания PublicKeys все подписавшихся участников multisig, что не особо радует. Агрегирование этих ключей позволит обеспечить более эффективную проверку, т.к. придется проверить лишь один ключ, а не n-ключей.
2) Транзакции P2SH требуют адреса начинающихся с числа 3 (см. BIP 13). А это удар по конфиденциальности. Агрегирование ключей позволяет multisig выглядеть как обычная транзакция.
Прежде чем перейти к теме поста, еще затронем MuSig. Это новая схема мультиподписи на основе Шнорр. Агрегация ключей в MuSig позволяет создавать частные смарт-контракты за пределами блокчейна.
Итак, агрегация ключей это крутая плюшка для multisig-транзакций, которые тратят один вход. Но биткойн-транзакции чаще всего имеют больше одного входа?В будущем, подписи Шнорра могут быть использованы для создания интерактивной схемы агрегированной подписи (interactive aggregate signature - IAS).
IAS - расширяют схемы multisig, позволяя каждому подписавшему подписать свое сообщение и вместо подписей для каждого отдельного входа, можно использовать одну подпись, которая проверит все входы.
Теперь одна подпись может использоваться для траты всех входных данных транзакции. Каждый вход также будет иметь свой собственный PublicKey, но его можно будет использовать с помощью IAS Schnorr. Эту новую подпись можно очень легко проверить с помощью OPCHECKDLS, который является новым опкодом и будет введен в схему подписи Schnorr.
Taproot, который предназначается для увеличения гибкости смарт-контрактов, призван облегчить переход от агрегации ключей к агрегации перекрестного ввода (Cross-Input Aggregation).
Для каждой транзакции требуется более одной подписи - по одной на каждый вход. Агрегация подписей с перекрестным вводом обеспечивает экономию, за счет сокращения количества подписей на транзакцию до 1.
Комбинация данных ввода повышает конфиденциальность и освобождает пространство, которое ранее использовалось для размещения всех подписей на множестве разных входов.
Cross-input aggregation может улучшить транзакции CoinJoin. Решение вводит дополнительный механизм запутывания на уровне протокола. С его помощью можно построить основанные на Шнорр CJ-транзакции с n-подписями, которые выглядят как обычные транзакции с одной подписью. Проблемы с конфиденциальностью были разобраны мной в постах под тегом #Privacy.
Как уже писалось в посте про P2EP: "основной принцип анализа блокчейна включает в себя PublicKey которые используются в качестве входных данных для транзакций, контролируемые одним и тем же пользователем. Чтобы утверждение "об общем владении входными данными" было признано недействительным, необходимо, чтобы существовало достаточное количество транзакций которые разделяют входные данные от разных владельцев".
P2EP обратно совместим, и при использовании в сочетании со Schnorr он может обеспечить достаточную конфиденциальность в базовом слое биткойна.
Cross-input aggregation имеет ряд проблем и не может быть внедрен по ряду причин. В любом случае, без внедрения подписей Шнорра, сделать это будет невозможно.
#PerfomanceAndUsability
Cross-Input Aggregation - Агрегация перекрестного ввода
Для стека биткоина
⬇️⬇️⬇️
Так, так...нам снова придется вернуться к подписям Шнорра и затронуть MuSig.
Схема Шнорра — это протокол идентификации и метод агрегирования (суммирование) подписей, необходимых для транзакции BTC. Подписи Шнорра позволяют создавать подпись действительную для суммы PublicKeys. Несколько подписывающих лиц в транзакции-multisig, объединяют свои PublicKeys в агрегированный ключ.
Multisig-транзакции не поддерживаются ECDSA и потому реализуются при помощи смарт-контракта P2SH.
1) P2SH требуют знания PublicKeys все подписавшихся участников multisig, что не особо радует. Агрегирование этих ключей позволит обеспечить более эффективную проверку, т.к. придется проверить лишь один ключ, а не n-ключей.
2) Транзакции P2SH требуют адреса начинающихся с числа 3 (см. BIP 13). А это удар по конфиденциальности. Агрегирование ключей позволяет multisig выглядеть как обычная транзакция.
Прежде чем перейти к теме поста, еще затронем MuSig. Это новая схема мультиподписи на основе Шнорр. Агрегация ключей в MuSig позволяет создавать частные смарт-контракты за пределами блокчейна.
Итак, агрегация ключей это крутая плюшка для multisig-транзакций, которые тратят один вход. Но биткойн-транзакции чаще всего имеют больше одного входа?В будущем, подписи Шнорра могут быть использованы для создания интерактивной схемы агрегированной подписи (interactive aggregate signature - IAS).
IAS - расширяют схемы multisig, позволяя каждому подписавшему подписать свое сообщение и вместо подписей для каждого отдельного входа, можно использовать одну подпись, которая проверит все входы.
Теперь одна подпись может использоваться для траты всех входных данных транзакции. Каждый вход также будет иметь свой собственный PublicKey, но его можно будет использовать с помощью IAS Schnorr. Эту новую подпись можно очень легко проверить с помощью OPCHECKDLS, который является новым опкодом и будет введен в схему подписи Schnorr.
Taproot, который предназначается для увеличения гибкости смарт-контрактов, призван облегчить переход от агрегации ключей к агрегации перекрестного ввода (Cross-Input Aggregation).
Для каждой транзакции требуется более одной подписи - по одной на каждый вход. Агрегация подписей с перекрестным вводом обеспечивает экономию, за счет сокращения количества подписей на транзакцию до 1.
Комбинация данных ввода повышает конфиденциальность и освобождает пространство, которое ранее использовалось для размещения всех подписей на множестве разных входов.
Cross-input aggregation может улучшить транзакции CoinJoin. Решение вводит дополнительный механизм запутывания на уровне протокола. С его помощью можно построить основанные на Шнорр CJ-транзакции с n-подписями, которые выглядят как обычные транзакции с одной подписью. Проблемы с конфиденциальностью были разобраны мной в постах под тегом #Privacy.
Как уже писалось в посте про P2EP: "основной принцип анализа блокчейна включает в себя PublicKey которые используются в качестве входных данных для транзакций, контролируемые одним и тем же пользователем. Чтобы утверждение "об общем владении входными данными" было признано недействительным, необходимо, чтобы существовало достаточное количество транзакций которые разделяют входные данные от разных владельцев".
P2EP обратно совместим, и при использовании в сочетании со Schnorr он может обеспечить достаточную конфиденциальность в базовом слое биткойна.
Cross-input aggregation имеет ряд проблем и не может быть внедрен по ряду причин. В любом случае, без внедрения подписей Шнорра, сделать это будет невозможно.
#PerfomanceAndUsability
Forwarded from CryptoBotan
✅✅✅
Cross-Input Aggregation - Агрегация перекрестного ввода
Для стека биткоина
⬇️⬇️⬇️
Так, так...нам снова придется вернуться к подписям Шнорра и затронуть MuSig.
Схема Шнорра — это протокол идентификации и метод агрегирования (суммирование) подписей, необходимых для транзакции BTC. Подписи Шнорра позволяют создавать подпись действительную для суммы PublicKeys. Несколько подписывающих лиц в транзакции-multisig, объединяют свои PublicKeys в агрегированный ключ.
Multisig-транзакции не поддерживаются ECDSA и потому реализуются при помощи смарт-контракта P2SH.
1) P2SH требуют знания PublicKeys все подписавшихся участников multisig, что не особо радует. Агрегирование этих ключей позволит обеспечить более эффективную проверку, т.к. придется проверить лишь один ключ, а не n-ключей.
2) Транзакции P2SH требуют адреса начинающихся с числа 3 (см. BIP 13). А это удар по конфиденциальности. Агрегирование ключей позволяет multisig выглядеть как обычная транзакция.
Прежде чем перейти к теме поста, еще затронем MuSig. Это новая схема мультиподписи на основе Шнорр. Агрегация ключей в MuSig позволяет создавать частные смарт-контракты за пределами блокчейна.
Итак, агрегация ключей это крутая плюшка для multisig-транзакций, которые тратят один вход. Но биткойн-транзакции чаще всего имеют больше одного входа?В будущем, подписи Шнорра могут быть использованы для создания интерактивной схемы агрегированной подписи (interactive aggregate signature - IAS).
IAS - расширяют схемы multisig, позволяя каждому подписавшему подписать свое сообщение и вместо подписей для каждого отдельного входа, можно использовать одну подпись, которая проверит все входы.
Теперь одна подпись может использоваться для траты всех входных данных транзакции. Каждый вход также будет иметь свой собственный PublicKey, но его можно будет использовать с помощью IAS Schnorr. Эту новую подпись можно очень легко проверить с помощью OPCHECKDLS, который является новым опкодом и будет введен в схему подписи Schnorr.
Taproot, который предназначается для увеличения гибкости смарт-контрактов, призван облегчить переход от агрегации ключей к агрегации перекрестного ввода (Cross-Input Aggregation).
Для каждой транзакции требуется более одной подписи - по одной на каждый вход. Агрегация подписей с перекрестным вводом обеспечивает экономию, за счет сокращения количества подписей на транзакцию до 1.
Комбинация данных ввода повышает конфиденциальность и освобождает пространство, которое ранее использовалось для размещения всех подписей на множестве разных входов.
Cross-input aggregation может улучшить транзакции CoinJoin. Решение вводит дополнительный механизм запутывания на уровне протокола. С его помощью можно построить основанные на Шнорр CJ-транзакции с n-подписями, которые выглядят как обычные транзакции с одной подписью. Проблемы с конфиденциальностью были разобраны мной в постах под тегом #Privacy.
Как уже писалось в посте про P2EP: "основной принцип анализа блокчейна включает в себя PublicKey которые используются в качестве входных данных для транзакций, контролируемые одним и тем же пользователем. Чтобы утверждение "об общем владении входными данными" было признано недействительным, необходимо, чтобы существовало достаточное количество транзакций которые разделяют входные данные от разных владельцев".
P2EP обратно совместим, и при использовании в сочетании со Schnorr он может обеспечить достаточную конфиденциальность в базовом слое биткойна.
Cross-input aggregation имеет ряд проблем и не может быть внедрен по ряду причин. В любом случае, без внедрения подписей Шнорра, сделать это будет невозможно.
#PerfomanceAndUsability
Cross-Input Aggregation - Агрегация перекрестного ввода
Для стека биткоина
⬇️⬇️⬇️
Так, так...нам снова придется вернуться к подписям Шнорра и затронуть MuSig.
Схема Шнорра — это протокол идентификации и метод агрегирования (суммирование) подписей, необходимых для транзакции BTC. Подписи Шнорра позволяют создавать подпись действительную для суммы PublicKeys. Несколько подписывающих лиц в транзакции-multisig, объединяют свои PublicKeys в агрегированный ключ.
Multisig-транзакции не поддерживаются ECDSA и потому реализуются при помощи смарт-контракта P2SH.
1) P2SH требуют знания PublicKeys все подписавшихся участников multisig, что не особо радует. Агрегирование этих ключей позволит обеспечить более эффективную проверку, т.к. придется проверить лишь один ключ, а не n-ключей.
2) Транзакции P2SH требуют адреса начинающихся с числа 3 (см. BIP 13). А это удар по конфиденциальности. Агрегирование ключей позволяет multisig выглядеть как обычная транзакция.
Прежде чем перейти к теме поста, еще затронем MuSig. Это новая схема мультиподписи на основе Шнорр. Агрегация ключей в MuSig позволяет создавать частные смарт-контракты за пределами блокчейна.
Итак, агрегация ключей это крутая плюшка для multisig-транзакций, которые тратят один вход. Но биткойн-транзакции чаще всего имеют больше одного входа?В будущем, подписи Шнорра могут быть использованы для создания интерактивной схемы агрегированной подписи (interactive aggregate signature - IAS).
IAS - расширяют схемы multisig, позволяя каждому подписавшему подписать свое сообщение и вместо подписей для каждого отдельного входа, можно использовать одну подпись, которая проверит все входы.
Теперь одна подпись может использоваться для траты всех входных данных транзакции. Каждый вход также будет иметь свой собственный PublicKey, но его можно будет использовать с помощью IAS Schnorr. Эту новую подпись можно очень легко проверить с помощью OPCHECKDLS, который является новым опкодом и будет введен в схему подписи Schnorr.
Taproot, который предназначается для увеличения гибкости смарт-контрактов, призван облегчить переход от агрегации ключей к агрегации перекрестного ввода (Cross-Input Aggregation).
Для каждой транзакции требуется более одной подписи - по одной на каждый вход. Агрегация подписей с перекрестным вводом обеспечивает экономию, за счет сокращения количества подписей на транзакцию до 1.
Комбинация данных ввода повышает конфиденциальность и освобождает пространство, которое ранее использовалось для размещения всех подписей на множестве разных входов.
Cross-input aggregation может улучшить транзакции CoinJoin. Решение вводит дополнительный механизм запутывания на уровне протокола. С его помощью можно построить основанные на Шнорр CJ-транзакции с n-подписями, которые выглядят как обычные транзакции с одной подписью. Проблемы с конфиденциальностью были разобраны мной в постах под тегом #Privacy.
Как уже писалось в посте про P2EP: "основной принцип анализа блокчейна включает в себя PublicKey которые используются в качестве входных данных для транзакций, контролируемые одним и тем же пользователем. Чтобы утверждение "об общем владении входными данными" было признано недействительным, необходимо, чтобы существовало достаточное количество транзакций которые разделяют входные данные от разных владельцев".
P2EP обратно совместим, и при использовании в сочетании со Schnorr он может обеспечить достаточную конфиденциальность в базовом слое биткойна.
Cross-input aggregation имеет ряд проблем и не может быть внедрен по ряду причин. В любом случае, без внедрения подписей Шнорра, сделать это будет невозможно.
#PerfomanceAndUsability