✅✅✅
Что такое схема Шнорра в BTC?
Часть. 1
⬇️⬇️⬇️
Схема Шнорра — это протокол идентификации. Надежность алгоритма основывается на сложности вычисления дискретного логарифма. Данный алгоритм позволяет проводить предварительные вычисления, что удобно при малых вычислительных ресурсах.
Немного сложновато, поэтому подробнее и проще.
Схема Шнорра, или подпись, — это метод улучшения пропускной способности сети посредством агрегирования подписей, необходимых для транзакции BTC.
Подписи — это метод доказательства того, что пользователь действительно является владельцем приватных ключей, связанных с адресом BTC, и, таким образом, может легитимно тратить свои балансы.
Подпись требуется для каждого входа (ввода, инпута).
Вход — это просто ссылка на вывод из предыдущей транзакции биткоина, и поскольку транзакция может иметь несколько входов, это означает, что каждая из них потребует свою собственную подпись.
Итак, на примере.
Мы хотим отправить 100 BTC. Транзакция может состоять из суммы моих балансов, которые собраны из вводов на счет. Такая транзакция может иметь 4 ввода по 25 BTC. Все вместе они будут равны 100 BTC, каждый из них должен иметь свою собственную подпись.
Поскольку каждый вход требует своей собственной подписи, они увеличивают размер транзакции, следовательно, транзакция раздувается и занимает дополнительное пространство в блоке
И именно подпись Schnorr работает на объединение всех этих подписей, поэтому для транзакции требуется только одна, общая.
Часть.2 - Использование и преимущества подписей Шнорра
#PerfomanceAndUsability
Что такое схема Шнорра в BTC?
Часть. 1
⬇️⬇️⬇️
Схема Шнорра — это протокол идентификации. Надежность алгоритма основывается на сложности вычисления дискретного логарифма. Данный алгоритм позволяет проводить предварительные вычисления, что удобно при малых вычислительных ресурсах.
Немного сложновато, поэтому подробнее и проще.
Схема Шнорра, или подпись, — это метод улучшения пропускной способности сети посредством агрегирования подписей, необходимых для транзакции BTC.
Подписи — это метод доказательства того, что пользователь действительно является владельцем приватных ключей, связанных с адресом BTC, и, таким образом, может легитимно тратить свои балансы.
Подпись требуется для каждого входа (ввода, инпута).
Вход — это просто ссылка на вывод из предыдущей транзакции биткоина, и поскольку транзакция может иметь несколько входов, это означает, что каждая из них потребует свою собственную подпись.
Итак, на примере.
Мы хотим отправить 100 BTC. Транзакция может состоять из суммы моих балансов, которые собраны из вводов на счет. Такая транзакция может иметь 4 ввода по 25 BTC. Все вместе они будут равны 100 BTC, каждый из них должен иметь свою собственную подпись.
Поскольку каждый вход требует своей собственной подписи, они увеличивают размер транзакции, следовательно, транзакция раздувается и занимает дополнительное пространство в блоке
И именно подпись Schnorr работает на объединение всех этих подписей, поэтому для транзакции требуется только одна, общая.
Часть.2 - Использование и преимущества подписей Шнорра
#PerfomanceAndUsability
Telegram
CryptoBotan
Что такое схема Шнорра в BTC?
Описание и принцип действия
⬇️⬇️⬇️
1 Часть
Использование и преимущества подписей Шнорра
⬇️⬇️⬇️
2 часть
Внедрение схемы Шнорра в каждой транзакции Bitcoin увеличивает пропускную способность сети Bitcoin не менее чем на 25%.…
Описание и принцип действия
⬇️⬇️⬇️
1 Часть
Использование и преимущества подписей Шнорра
⬇️⬇️⬇️
2 часть
Внедрение схемы Шнорра в каждой транзакции Bitcoin увеличивает пропускную способность сети Bitcoin не менее чем на 25%.…
✅✅✅
MuSig - схема мультиподписей на базе подписей Шнорра.
Для стека биткоина
⬇️⬇️⬇️
Я уже много раз упоминал свой пост про подписи Шнорра...и вот опять пришлось...Для более ясной картины оставлю ссылку на канал, где ребятушки еще проще описали это решение и рассказали почему о нем так много разговоров.
https://t.me/blockndev/23
Если обратится к схеме стека, то подписи Шнорра являются основой для построения двух решений: MuSig и Cross-Input-Aggregation (о котором в другой раз)
MuSig - это новая схема подписи для биткоина, которая призвана увеличить масштабируемость сети и конфедициальность транзакций.
MuSig - это многофункциональная схема цифровой подписи совместимая с BIP-Shnorr.
BIP-Shnorr описывает спецификации и технические особенности потенциальной реализации Schnorr, которая будет иметь следующие преимущества по сравнению с ECDSA:
1) Доказательство безопасности - В бипе было что-то про дискретный логарифм эллиптической кривой😐, но я скажу так: "То доказательство, которое есть в подписях Шнорр, нет в ECDSA".🙈
2) Подписи Шнорра дают возможность нескольким сторонам совместно создавать подписи, которые действительны для суммы их открытых ключей. Это основа для построения конструкций более высокого уровня, которые повышают эффективность и конфиденциальность мульти-подписей и смарт-контрактов.
MuSig дает Бате вот какие плюшки:
1) Позволяет агрегировать несколько открытых ключей (PublicKey) в один открытый ключ. Если еще проще, позволяет группе подписывающих лиц (каждый со своим собственным закрытым/открытым ключом) совместно подписывать одно сообщение, в результате чего получается одна подпись. Эта единственная подпись может быть затем проверена любым, кто также знает сообщение и открытые ключи подписывающих лиц.
Свойство объединения PublicKey называется агрегированием.
2) Схемы мультиподписей, дающих агрегацию подписей Шнорра, уже имеются на "рынке" решений. Но их недостаток в том, что эти схемы требуют проверки наличия PrivateKey, соответствующего PublicKey. MuSig таких требований не предъявляет. Все что нужно - это PublicKey.
В схеме мультиподписей, поддерживающих агрегацию ключей, мультиподпись выглядит как подпись с одним ключом. Верификаторам не требуются знания открытых ключей исходных участников. Им будет достаточно только агрегированного ключа. MuSig фактически является ключевой схемой агрегирования подписей Шнорра.
Схема агрегирования ключей также позволяет сократить число PublicKey на вход транзакции до одного.
Но ясное дело, что без проблем не обошлось.
Подписи MuSig, так же как подписи Schnorr или ECDSA, используют в своей конструкции поле “nonce”, которое должно быть неповторяемым.
Буду честен, я не смог до конца разобраться в описании этой уязвимости. Математика тут сильнее меня☺️ Для тех кому интересно, оставляю ссылочку (англ.)
А это статья разработчика BlockStream о MuSig...Ну чтобы подробнее разобраться (англ.)😉
GitHub MuSig
#PerfomanceAndUsability
MuSig - схема мультиподписей на базе подписей Шнорра.
Для стека биткоина
⬇️⬇️⬇️
Я уже много раз упоминал свой пост про подписи Шнорра...и вот опять пришлось...Для более ясной картины оставлю ссылку на канал, где ребятушки еще проще описали это решение и рассказали почему о нем так много разговоров.
https://t.me/blockndev/23
Если обратится к схеме стека, то подписи Шнорра являются основой для построения двух решений: MuSig и Cross-Input-Aggregation (о котором в другой раз)
MuSig - это новая схема подписи для биткоина, которая призвана увеличить масштабируемость сети и конфедициальность транзакций.
MuSig - это многофункциональная схема цифровой подписи совместимая с BIP-Shnorr.
BIP-Shnorr описывает спецификации и технические особенности потенциальной реализации Schnorr, которая будет иметь следующие преимущества по сравнению с ECDSA:
1) Доказательство безопасности - В бипе было что-то про дискретный логарифм эллиптической кривой😐, но я скажу так: "То доказательство, которое есть в подписях Шнорр, нет в ECDSA".🙈
2) Подписи Шнорра дают возможность нескольким сторонам совместно создавать подписи, которые действительны для суммы их открытых ключей. Это основа для построения конструкций более высокого уровня, которые повышают эффективность и конфиденциальность мульти-подписей и смарт-контрактов.
MuSig дает Бате вот какие плюшки:
1) Позволяет агрегировать несколько открытых ключей (PublicKey) в один открытый ключ. Если еще проще, позволяет группе подписывающих лиц (каждый со своим собственным закрытым/открытым ключом) совместно подписывать одно сообщение, в результате чего получается одна подпись. Эта единственная подпись может быть затем проверена любым, кто также знает сообщение и открытые ключи подписывающих лиц.
Свойство объединения PublicKey называется агрегированием.
2) Схемы мультиподписей, дающих агрегацию подписей Шнорра, уже имеются на "рынке" решений. Но их недостаток в том, что эти схемы требуют проверки наличия PrivateKey, соответствующего PublicKey. MuSig таких требований не предъявляет. Все что нужно - это PublicKey.
В схеме мультиподписей, поддерживающих агрегацию ключей, мультиподпись выглядит как подпись с одним ключом. Верификаторам не требуются знания открытых ключей исходных участников. Им будет достаточно только агрегированного ключа. MuSig фактически является ключевой схемой агрегирования подписей Шнорра.
Схема агрегирования ключей также позволяет сократить число PublicKey на вход транзакции до одного.
Но ясное дело, что без проблем не обошлось.
Подписи MuSig, так же как подписи Schnorr или ECDSA, используют в своей конструкции поле “nonce”, которое должно быть неповторяемым.
Буду честен, я не смог до конца разобраться в описании этой уязвимости. Математика тут сильнее меня☺️ Для тех кому интересно, оставляю ссылочку (англ.)
А это статья разработчика BlockStream о MuSig...Ну чтобы подробнее разобраться (англ.)😉
GitHub MuSig
#PerfomanceAndUsability
✅✅✅
Neutrino
Итак, что такое 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
Neutrino
Итак, что такое 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
✅✅✅
Решение для масштабирования сети Биткойн - 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
✅✅✅
Erlay - новый протокол выполнения транзакций.
Для стека биткоина
⬇️⬇️⬇️
Протокол был представлен в рассылке для разработчиков BTC 28 мая 2019 года. Разработчиками решения являются: Грегори Максвелл, Питер Велле и Глеб Науменко.
Как известно, новая транзакция, при трансляции в сеть, отправляется на все узлы в сети.
Как это происходит:
После получения транзакции, узел отправляет id транзакции всем узлам, с которыми он связан (кроме того, от которого он получил транзакцию). Все эти узлы проверяют этот id, дабы удостовериться, получили ли они эту транзакцию от другого узла. Если не получили, то они запрашивают всю транзакцию от узла, который отправил id этой транзакции. Затем процесс повторяется снова...
Так как узлы совместно используют id транзакций с узлами, которые уже отправили транзакцию, образуется множество ненужных сообщений используемых в сети BTC. Эти сообщения "жрут" пропускную способность сети. 50% пропускной способности, необходимой для запуска узла используется для объявления транзакций. 45% - для ретрансляции данных о транзакции. Согласно разработчикам, 44% всего трафика - это избыточные сообщения.
Протокол Erlay сделает так, что в обработке транзакций будет участвовать только 8 узлов (в дальнейшем 32). Т.е. узлы, как и сейчас, будут использовать новые id транзакций со своими связанными узлами, но они будут отправлять id транзакции только 8-ми случайным узлам, даже если связей с другими узлами больше. Затем, связанные узлы запросят "Sketch", который содержит id для всех транзакций, принятых узлом, в компактной форме.
Ретрансляция данных о транзакциях будет происходить путем периодического запуска протокола сверки по каждому соединению. При помощи библиотеки MiniScetch - транзакции можно будет согласовать с другими узлами.
Этот протокол сверки уже разработан, но пока не разобран мной для стека, но не все сразу😅
Такой подход совершения транзакций позволит более эффективно передавать id транзакций, сокращая количество сообщений, передаваемых между узлами, при сохранении поддержки передачи новых транзакций всем узлам.
Erlay может существенно сократить объем пропускной способности (на ≈40%), необходимой для поддержания текущего уровня подключения между биткойн-узлами.
Дополнительной плюшкой решения Erlay является улучшение конфиденциальности. Так как id транзакций не являются общими для всех узлов, то труднее отслеживать появление конкретных транзакций. Также, Erlay делает сеть более устойчивой к ряду нескольких атак, таких как: атака по времени и атака Eclipse
#PerfomanceAndUsability
Erlay - новый протокол выполнения транзакций.
Для стека биткоина
⬇️⬇️⬇️
Протокол был представлен в рассылке для разработчиков BTC 28 мая 2019 года. Разработчиками решения являются: Грегори Максвелл, Питер Велле и Глеб Науменко.
Как известно, новая транзакция, при трансляции в сеть, отправляется на все узлы в сети.
Как это происходит:
После получения транзакции, узел отправляет id транзакции всем узлам, с которыми он связан (кроме того, от которого он получил транзакцию). Все эти узлы проверяют этот id, дабы удостовериться, получили ли они эту транзакцию от другого узла. Если не получили, то они запрашивают всю транзакцию от узла, который отправил id этой транзакции. Затем процесс повторяется снова...
Так как узлы совместно используют id транзакций с узлами, которые уже отправили транзакцию, образуется множество ненужных сообщений используемых в сети BTC. Эти сообщения "жрут" пропускную способность сети. 50% пропускной способности, необходимой для запуска узла используется для объявления транзакций. 45% - для ретрансляции данных о транзакции. Согласно разработчикам, 44% всего трафика - это избыточные сообщения.
Протокол Erlay сделает так, что в обработке транзакций будет участвовать только 8 узлов (в дальнейшем 32). Т.е. узлы, как и сейчас, будут использовать новые id транзакций со своими связанными узлами, но они будут отправлять id транзакции только 8-ми случайным узлам, даже если связей с другими узлами больше. Затем, связанные узлы запросят "Sketch", который содержит id для всех транзакций, принятых узлом, в компактной форме.
Ретрансляция данных о транзакциях будет происходить путем периодического запуска протокола сверки по каждому соединению. При помощи библиотеки MiniScetch - транзакции можно будет согласовать с другими узлами.
Этот протокол сверки уже разработан, но пока не разобран мной для стека, но не все сразу😅
Такой подход совершения транзакций позволит более эффективно передавать id транзакций, сокращая количество сообщений, передаваемых между узлами, при сохранении поддержки передачи новых транзакций всем узлам.
Erlay может существенно сократить объем пропускной способности (на ≈40%), необходимой для поддержания текущего уровня подключения между биткойн-узлами.
Дополнительной плюшкой решения Erlay является улучшение конфиденциальности. Так как id транзакций не являются общими для всех узлов, то труднее отслеживать появление конкретных транзакций. Также, Erlay делает сеть более устойчивой к ряду нескольких атак, таких как: атака по времени и атака Eclipse
#PerfomanceAndUsability
✅✅✅
libMiniScetch - библиотека для согласования наборов.
Для стека биткоина
⬇️⬇️⬇️
libMiniSketch - это автономная библиотека API для построения и декодирования эскизов наборов, использующаяся для согласования компактных наборов.
В посте про Erlay, я упоминал, что MiniSketch используется для сверки и согласования транзакций.
Minisketch создает библиотеку данных, которая будет использоваться для построения эскизов наборов (наборов данных транзакций). Узлы и майнеры могут затем использовать эти наборы для сверки компактных наборов.
MiniSketch использует коды исправления ошибок для передачи набора транзакций одноранговому узлу с неизвестным, но похожим набором, используя пропускную способность, равную только размеру разницы, а не размеру самих наборов. Т.е. почти половина пропускной способности, которую потребляет узел, можно сэкономить.
Узлы пытаются выяснить, каковы различия между двумя наборами, хранящимися на разных компьютерах, минимизируя при этом, количество данных которое должно быть обменено между ними.
Эскизы имеют заданную емкость, и когда количество элементов в наборе не превышает эту емкость, libminisketch всегда будет восстанавливать весь набор из эскиза.
Суть эскизов (Sketch) в том, чтобы иметь пакет данных, содержащий id для всех транзакций, которые узел принял (после последней выверки), но в компактной форме. Используя эскизы, узел может вычислить, какие транзакции у него есть, по сравнению с другими узлами. После этого он может запросить только те транзакции у тех одноранговых узлов, которые не отображаются в их эскизе.
Если у А и Б есть набор элементов, и они подозревают, что наборы в значительной степени, но не полностью перекрываются, они могут использовать протокол, чтобы позволить обеим сторонам изучить все элементы.
Мне понравилось вот такое описание решения :
Операторам узлов нужно сравнивать заметки о транзакционных данных. Это позволит им набрасывать (создавать) наборы (списки) транзакций, и программа будет перепроверять эти наборы, чтобы увидеть, какие данные встречаются в одном, но не в обоих наборах. И вместо того, чтобы тратить время и энергию на раскрытие всех этих данных друг другу, узлам с minisketch нужно знать только разницу между их наборами транзакций, чтобы создать полный набор.
У меня есть множество 3, 5, 7, 11, а у вас 3, 5, 7, 9, 11. Очевидно, что разница 9. Мы оба вычисляем сумму наших элементов:
3+5+7+11=26 - у меня
3+5+7+9+11=35 - у вас
Я посылаю вам свою сумму 26 и вы вычитаете ее из своей суммы. Разница равна 9.
Все описанное выше говорит об одном и том же, но с разной подачей...Надеюсь суть мне удалось донести😉
GitHub
#PerfomanceAndUsability
libMiniScetch - библиотека для согласования наборов.
Для стека биткоина
⬇️⬇️⬇️
libMiniSketch - это автономная библиотека API для построения и декодирования эскизов наборов, использующаяся для согласования компактных наборов.
В посте про Erlay, я упоминал, что MiniSketch используется для сверки и согласования транзакций.
Minisketch создает библиотеку данных, которая будет использоваться для построения эскизов наборов (наборов данных транзакций). Узлы и майнеры могут затем использовать эти наборы для сверки компактных наборов.
MiniSketch использует коды исправления ошибок для передачи набора транзакций одноранговому узлу с неизвестным, но похожим набором, используя пропускную способность, равную только размеру разницы, а не размеру самих наборов. Т.е. почти половина пропускной способности, которую потребляет узел, можно сэкономить.
Узлы пытаются выяснить, каковы различия между двумя наборами, хранящимися на разных компьютерах, минимизируя при этом, количество данных которое должно быть обменено между ними.
Эскизы имеют заданную емкость, и когда количество элементов в наборе не превышает эту емкость, libminisketch всегда будет восстанавливать весь набор из эскиза.
Суть эскизов (Sketch) в том, чтобы иметь пакет данных, содержащий id для всех транзакций, которые узел принял (после последней выверки), но в компактной форме. Используя эскизы, узел может вычислить, какие транзакции у него есть, по сравнению с другими узлами. После этого он может запросить только те транзакции у тех одноранговых узлов, которые не отображаются в их эскизе.
Если у А и Б есть набор элементов, и они подозревают, что наборы в значительной степени, но не полностью перекрываются, они могут использовать протокол, чтобы позволить обеим сторонам изучить все элементы.
Мне понравилось вот такое описание решения :
Операторам узлов нужно сравнивать заметки о транзакционных данных. Это позволит им набрасывать (создавать) наборы (списки) транзакций, и программа будет перепроверять эти наборы, чтобы увидеть, какие данные встречаются в одном, но не в обоих наборах. И вместо того, чтобы тратить время и энергию на раскрытие всех этих данных друг другу, узлам с minisketch нужно знать только разницу между их наборами транзакций, чтобы создать полный набор.
У меня есть множество 3, 5, 7, 11, а у вас 3, 5, 7, 9, 11. Очевидно, что разница 9. Мы оба вычисляем сумму наших элементов:
3+5+7+11=26 - у меня
3+5+7+9+11=35 - у вас
Я посылаю вам свою сумму 26 и вы вычитаете ее из своей суммы. Разница равна 9.
Все описанное выше говорит об одном и том же, но с разной подачей...Надеюсь суть мне удалось донести😉
GitHub
#PerfomanceAndUsability
Telegram
CryptoBotan
✅✅✅
Технологический стек биткоина (Update)
Несколько месяцев работы в этом посте. Как итог: визуализация масштабов экосистемы Биткойна и работы над ней.
Добавил от себя некоторые решения. Внутри ссылки на проекты и протоколы, статьи и посты из других…
Технологический стек биткоина (Update)
Несколько месяцев работы в этом посте. Как итог: визуализация масштабов экосистемы Биткойна и работы над ней.
Добавил от себя некоторые решения. Внутри ссылки на проекты и протоколы, статьи и посты из других…
✅✅✅
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
