✅✅✅
Tapscript - обновленная версия языка программирования Bitcoin.
Затрагивая стек биткоина, который я разбираю уже второй месяц и прошлый пост про софтфорк, сегодня о tapscript.
⬇️⬇️⬇️
Прежде чем затронуть tapscript, нужно кое с чем разобраться
Биткойн использует скриптовую систему для транзакций.
Script (сценарий) - это, по сути, список инструкций, записанных с каждой транзакцией, которые описывают, как следующий человек, желающий потратить передаваемые биткойны, может получить к ним доступ.
Скриптинг предоставляет возможность гибко изменять параметры, которые определяют правила траты переведенных биткоинов.
Скриптовая система может быть использована для того, чтобы потребовать два закрытых ключа, или комбинацию нескольких ключей, или никаких ключей.
Opcodes (опкоды, команды, функции) - это список всех слов скрипта. Это коды операций на языке Bitcoin Script, которые передают данные или выполняют функции в ScriptPubKey или скрипте подписи.
Что за ScriptPubKey читайте в этом посте
Ссылочка для детального изучения Opcodes.
Кстати, некоторые опкоды были удалены из протокола. Какие-то из-за ненадобности, а какие-то были вредны. Например, так называемы опкоды Сатоши, OP_LSHIFT, OP_RSHIFT, OP_DIV, OP_MUL и другие...
Но да ладно, я отвлекся...
///
Итак, Tapscript - это язык сценариев, используемый для сценариев Taproot. В нем отключены, объединены или модифицированы некоторые из опкодов. Отключенные опкоды отказывают и завершают сценарии сразу же при выполнении, и игнорируются, когда обнаруживаются в неисполненной ветви сценария.
В Script присутствуют такие опкоды как:
OP_CHECKMULTISIG - Сравнивает первую подпись с каждым открытым ключом, пока не найдет соответствие ECDSA. Начиная с последующего открытого ключа, он сравнивает вторую подпись с каждым оставшимся открытым ключом, пока не найдет соответствие ECDSA. Процесс повторяется до тех пор, пока не будут проверены все подписи или не останется достаточного количества открытых ключей для получения успешного результата. Все подписи должны соответствовать открытому ключу.
OP_CHECKMULTISIGVERIFY - То же самое, но выполняется позже.
В Tapscript эти два опкода отключены, а вместо них используется один - OP_CHECK SIG ADD. Он позволяет формировать ту же самую мультиподпись с возможностью пакетной проверки.
///
Опкоды OP_CHECKSIG и OP_CHECKSIGVERIFY ⬇️ модифицированы для работы с открытыми ключами и сигнатурами Шнорр, вместо ECDSA, и добавляется новый код OP_CHECKSIGADD.
OP_CHECKSIG - это код операции сценария, используемый для проверки правильности подписи для ввода tx. Т.е. проверяет подпись на соответствие транзакции.
OP_CHECKSIGVERIFY - То же самое, но позже.
///
Подпись сообщений tapscript также упрощает обработку OP_CODESEPARATOR и делает ее более эффективной.
OP_CODESEPARATOR используется для проверки OP_CHECKSIG
///
Опкод OP_NOP: в библиотеке опкодов красуется надпись "Does nothing". Но, как оказалось, этот опкод позволяет внедрять новые опкоды. В Tapscript он заменен на OP_SUCCESS, который позволяет делать это более "cleanly".
Более подробную информацию можно взять на github: bip-tapscript.mediawiki
Tapscript может быть внедрен с помощью софт-форка. Внедрение Tapscript упростит внедрение опкодов и проведение софтфорков.
#SmartContracts
Tapscript - обновленная версия языка программирования Bitcoin.
Затрагивая стек биткоина, который я разбираю уже второй месяц и прошлый пост про софтфорк, сегодня о tapscript.
⬇️⬇️⬇️
Прежде чем затронуть tapscript, нужно кое с чем разобраться
Биткойн использует скриптовую систему для транзакций.
Script (сценарий) - это, по сути, список инструкций, записанных с каждой транзакцией, которые описывают, как следующий человек, желающий потратить передаваемые биткойны, может получить к ним доступ.
Скриптинг предоставляет возможность гибко изменять параметры, которые определяют правила траты переведенных биткоинов.
Скриптовая система может быть использована для того, чтобы потребовать два закрытых ключа, или комбинацию нескольких ключей, или никаких ключей.
Opcodes (опкоды, команды, функции) - это список всех слов скрипта. Это коды операций на языке Bitcoin Script, которые передают данные или выполняют функции в ScriptPubKey или скрипте подписи.
Что за ScriptPubKey читайте в этом посте
Ссылочка для детального изучения Opcodes.
Кстати, некоторые опкоды были удалены из протокола. Какие-то из-за ненадобности, а какие-то были вредны. Например, так называемы опкоды Сатоши, OP_LSHIFT, OP_RSHIFT, OP_DIV, OP_MUL и другие...
Но да ладно, я отвлекся...
///
Итак, Tapscript - это язык сценариев, используемый для сценариев Taproot. В нем отключены, объединены или модифицированы некоторые из опкодов. Отключенные опкоды отказывают и завершают сценарии сразу же при выполнении, и игнорируются, когда обнаруживаются в неисполненной ветви сценария.
В Script присутствуют такие опкоды как:
OP_CHECKMULTISIG - Сравнивает первую подпись с каждым открытым ключом, пока не найдет соответствие ECDSA. Начиная с последующего открытого ключа, он сравнивает вторую подпись с каждым оставшимся открытым ключом, пока не найдет соответствие ECDSA. Процесс повторяется до тех пор, пока не будут проверены все подписи или не останется достаточного количества открытых ключей для получения успешного результата. Все подписи должны соответствовать открытому ключу.
OP_CHECKMULTISIGVERIFY - То же самое, но выполняется позже.
В Tapscript эти два опкода отключены, а вместо них используется один - OP_CHECK SIG ADD. Он позволяет формировать ту же самую мультиподпись с возможностью пакетной проверки.
///
Опкоды OP_CHECKSIG и OP_CHECKSIGVERIFY ⬇️ модифицированы для работы с открытыми ключами и сигнатурами Шнорр, вместо ECDSA, и добавляется новый код OP_CHECKSIGADD.
OP_CHECKSIG - это код операции сценария, используемый для проверки правильности подписи для ввода tx. Т.е. проверяет подпись на соответствие транзакции.
OP_CHECKSIGVERIFY - То же самое, но позже.
///
Подпись сообщений tapscript также упрощает обработку OP_CODESEPARATOR и делает ее более эффективной.
OP_CODESEPARATOR используется для проверки OP_CHECKSIG
///
Опкод OP_NOP: в библиотеке опкодов красуется надпись "Does nothing". Но, как оказалось, этот опкод позволяет внедрять новые опкоды. В Tapscript он заменен на OP_SUCCESS, который позволяет делать это более "cleanly".
Более подробную информацию можно взять на github: bip-tapscript.mediawiki
Tapscript может быть внедрен с помощью софт-форка. Внедрение Tapscript упростит внедрение опкодов и проведение софтфорков.
#SmartContracts
✅✅✅
Решил написать этот пост, потому что меня поразил сам факт того, как необычно можно использовать технологию LN.
Вы думали, что только микроплатежи???
Компания Tierion объявила о выпуске набора инструментов, разработанного совместно с Lightning Labs, которые помогут включить аутентификацию Bitcoin-native с использованием токенов аутентификации LSATS – Lightning Service.
Я бы отнес это к рубрике "Где еще применить Lightning Network".
⬇️⬇️⬇️
https://www.cryptoninjas.net/2020/01/21/tierion-introduces-set-of-open-source-tools-to-create-trustless-lightning-apps/
Tierion - это универсальная платформа, позволяющая проводить верификацию данных. Tierion создает доказательство привязки данных с транзакциями на блокчейне. Используя это доказательство, любой человек может проверить метку времени и целостность данных без третьих лиц.
LSATs объединяет микроплатежи через Lightning со стандартом 402 Payment Required HTTP status code, macaroons, и authorization headers.
Macaroons (аналог Cookies) - это небольшой кусочек данных, чтобы подтвердить разрешение выполнять действия. Служба ищет идентификатор macaroon и проверяет, что он был изначально подписан корневым ключом сервиса. Однако, в отличие от файла cookie, вы можете делегировать macaroon или создать его версию с более ограниченными возможностями, а затем отправить его кому-то другому для использования.
402 Payment Required HTTP status code - этот код указывает, что запрос не может быть обработан до тех пор, пока клиент не производеит оплату. Это означает, что запрашиваемые данные не будут доступны до тех пор, пока клиент не производит оплату.
Authorization header содержит учетные данные для аутентификации агента пользователя с сервером.
Аутентификация (кто делает запрос) и авторизация (устанавливает разрешения для каждого пользователя) требуются для различных веб-и мобильных приложений.
ПО Boltwall активирует Bitcoin Lightning доступ и идентификацию используя LSATs. Пользователи могут взимать плату за доступ к своему API, не требуя учетных записей пользователей, ключей API, кредитных карт или хранения каких-либо пользовательских данных.
LSAT - это заголовок HTTP, который кодирует macaroons и lightning-счет. Токен LSAT состоит из двух частей: macaroons и подтверждения оплаты. Платежи Lightning обеспечивают криптографически безопасный способ подтверждения платежа.
Now-Boltwall - это утилита командной строки, которая помогает развернуть живой сервер с поддержкой Boltwall.
LSAT-js - служебная библиотека, написанная на машинном языке и совместимая с большинством современных браузеров. Он предоставляет инструменты для построения, анализа и проверки LSAT на стороне сервера или клиента.
LSAT Playground - клиентское веб-приложение, которое демонстрирует все инструменты, доступные в lsat-js.
Boltwall и lsat-js облегчат разработчикам создание приложений, построенных на основе инфраструктуры аутентификации.
GitHub Boltwall
Решил написать этот пост, потому что меня поразил сам факт того, как необычно можно использовать технологию LN.
Вы думали, что только микроплатежи???
Компания Tierion объявила о выпуске набора инструментов, разработанного совместно с Lightning Labs, которые помогут включить аутентификацию Bitcoin-native с использованием токенов аутентификации LSATS – Lightning Service.
Я бы отнес это к рубрике "Где еще применить Lightning Network".
⬇️⬇️⬇️
https://www.cryptoninjas.net/2020/01/21/tierion-introduces-set-of-open-source-tools-to-create-trustless-lightning-apps/
Tierion - это универсальная платформа, позволяющая проводить верификацию данных. Tierion создает доказательство привязки данных с транзакциями на блокчейне. Используя это доказательство, любой человек может проверить метку времени и целостность данных без третьих лиц.
LSATs объединяет микроплатежи через Lightning со стандартом 402 Payment Required HTTP status code, macaroons, и authorization headers.
Macaroons (аналог Cookies) - это небольшой кусочек данных, чтобы подтвердить разрешение выполнять действия. Служба ищет идентификатор macaroon и проверяет, что он был изначально подписан корневым ключом сервиса. Однако, в отличие от файла cookie, вы можете делегировать macaroon или создать его версию с более ограниченными возможностями, а затем отправить его кому-то другому для использования.
402 Payment Required HTTP status code - этот код указывает, что запрос не может быть обработан до тех пор, пока клиент не производеит оплату. Это означает, что запрашиваемые данные не будут доступны до тех пор, пока клиент не производит оплату.
Authorization header содержит учетные данные для аутентификации агента пользователя с сервером.
Аутентификация (кто делает запрос) и авторизация (устанавливает разрешения для каждого пользователя) требуются для различных веб-и мобильных приложений.
ПО Boltwall активирует Bitcoin Lightning доступ и идентификацию используя LSATs. Пользователи могут взимать плату за доступ к своему API, не требуя учетных записей пользователей, ключей API, кредитных карт или хранения каких-либо пользовательских данных.
LSAT - это заголовок HTTP, который кодирует macaroons и lightning-счет. Токен LSAT состоит из двух частей: macaroons и подтверждения оплаты. Платежи Lightning обеспечивают криптографически безопасный способ подтверждения платежа.
Now-Boltwall - это утилита командной строки, которая помогает развернуть живой сервер с поддержкой Boltwall.
LSAT-js - служебная библиотека, написанная на машинном языке и совместимая с большинством современных браузеров. Он предоставляет инструменты для построения, анализа и проверки LSAT на стороне сервера или клиента.
LSAT Playground - клиентское веб-приложение, которое демонстрирует все инструменты, доступные в lsat-js.
Boltwall и lsat-js облегчат разработчикам создание приложений, построенных на основе инфраструктуры аутентификации.
GitHub Boltwall
✅✅✅
Microsoft ION: глобальная децентрализованная идентификация пользователей.
Для описания стека биткоина
⬇️⬇️⬇️
Анонс творения произошел в феврале 2018 года, под названием "Система децентрализованной идентификации - Decentralized identities digital" (DID). В мае 2019 компания рассказала о первых наработках — система получила название ION и в её основе лежит Биткойн-блокчейн.
Microsoft разрабатывает протоколы и стандарты с открытым исходным кодом совместно с консорциумом World Wide Web и ассоциацией Decentralized Identity Foundation, членами которой также являются IBM и Mastercard.
Если коротко, то идея в том, чтобы создать универсальный идентификатор для сервисов, сайтов и приложений по типу Facebook Connect. Но персональные данные будут храниться децентрализованно, а не на серверах Microsoft.
ION - это опенсорс проект, имеющий в себе инструменты для обмена информации между порталами и сетями. Мы уже используем такой подход, когда пытаемся пройти аворизацию, используя почту или FB. Данные просто передаются между сетями.
В случае с ION, обрабатывается децентрализованный идентификатор (DID), который доказывает право на владения ключами. По словам разработчиков, решение обеспечивает куда большую пропускную способность, чем сам блокчейн.
ION работает с протоколами 2 уровня, то есть поверх блокчейна Биткойна, а не по цепочке транзакций, для увеличения масштабируемости сети.
Основные компоненты ION:
Decentralized Identifiers (DID) - это спецификация W3C, определяющая общий формат документа для описания состояния децентрализованного идентификатора.
W3C — это консорциум всемирной сети, такая некоммерческая организация, в рамках которой разрабатывают технологии, на которых работает веб.
Identity Hubs -это зашифрованное хранилище данных идентификации, которое включает ретрансляцию сообщений, обработку аттестации и вычислительные конечные точки для идентификации.
Universal DID Resolver - сервера, что пропускают DID через блокчейн.
Verifiable Credentials - спецификация W3C, которая определяет формат документа для кодирования.
Управляемые ION идентификаторы децентрализованы. После удаления учетной записи, доступ к привязанным к аккаунту сервисам сохранится. Все публикуемые в профиле фотографии будут принадлежать пользователю, а не соцсети.
Для тестирования своего децентрализованного детища, будет добавлена (сроки не указаны) поддержка Microsoft Authenticator, который уже юзают миллионы пользователей.
Microsoft Authenticator сможет выступать в качестве агента пользователя для управления идентификационными данными и криптографическими ключами. Идентификационные данные хранятся в Identity Hubs, зашифрованном с помощью этих криптографических ключей.
Как только появится эта возможность, приложения и службы смогут взаимодействовать с данными пользователя, используя общий канал обмена сообщениями.
И в конце немного закулисных игр.
Microsoft приглашала для тестирования решения и совместной разработки продукта - Facebook. Но те отказались. Интересное мнение на этот счет ниже по ссылочке.
⬇️⬇️⬇️
https://www.coindesk.com/microsoft-launches-decentralized-identity-tool-on-bitcoin-blockchain
#Layer2
Microsoft ION: глобальная децентрализованная идентификация пользователей.
Для описания стека биткоина
⬇️⬇️⬇️
Анонс творения произошел в феврале 2018 года, под названием "Система децентрализованной идентификации - Decentralized identities digital" (DID). В мае 2019 компания рассказала о первых наработках — система получила название ION и в её основе лежит Биткойн-блокчейн.
Microsoft разрабатывает протоколы и стандарты с открытым исходным кодом совместно с консорциумом World Wide Web и ассоциацией Decentralized Identity Foundation, членами которой также являются IBM и Mastercard.
Если коротко, то идея в том, чтобы создать универсальный идентификатор для сервисов, сайтов и приложений по типу Facebook Connect. Но персональные данные будут храниться децентрализованно, а не на серверах Microsoft.
ION - это опенсорс проект, имеющий в себе инструменты для обмена информации между порталами и сетями. Мы уже используем такой подход, когда пытаемся пройти аворизацию, используя почту или FB. Данные просто передаются между сетями.
В случае с ION, обрабатывается децентрализованный идентификатор (DID), который доказывает право на владения ключами. По словам разработчиков, решение обеспечивает куда большую пропускную способность, чем сам блокчейн.
ION работает с протоколами 2 уровня, то есть поверх блокчейна Биткойна, а не по цепочке транзакций, для увеличения масштабируемости сети.
Основные компоненты ION:
Decentralized Identifiers (DID) - это спецификация W3C, определяющая общий формат документа для описания состояния децентрализованного идентификатора.
W3C — это консорциум всемирной сети, такая некоммерческая организация, в рамках которой разрабатывают технологии, на которых работает веб.
Identity Hubs -это зашифрованное хранилище данных идентификации, которое включает ретрансляцию сообщений, обработку аттестации и вычислительные конечные точки для идентификации.
Universal DID Resolver - сервера, что пропускают DID через блокчейн.
Verifiable Credentials - спецификация W3C, которая определяет формат документа для кодирования.
Управляемые ION идентификаторы децентрализованы. После удаления учетной записи, доступ к привязанным к аккаунту сервисам сохранится. Все публикуемые в профиле фотографии будут принадлежать пользователю, а не соцсети.
Для тестирования своего децентрализованного детища, будет добавлена (сроки не указаны) поддержка Microsoft Authenticator, который уже юзают миллионы пользователей.
Microsoft Authenticator сможет выступать в качестве агента пользователя для управления идентификационными данными и криптографическими ключами. Идентификационные данные хранятся в Identity Hubs, зашифрованном с помощью этих криптографических ключей.
Как только появится эта возможность, приложения и службы смогут взаимодействовать с данными пользователя, используя общий канал обмена сообщениями.
И в конце немного закулисных игр.
Microsoft приглашала для тестирования решения и совместной разработки продукта - Facebook. Но те отказались. Интересное мнение на этот счет ниже по ссылочке.
⬇️⬇️⬇️
https://www.coindesk.com/microsoft-launches-decentralized-identity-tool-on-bitcoin-blockchain
#Layer2
✅✅✅
MuSig - схема мультиподписей на базе подписей Шнорра.
Для стека биткоина
⬇️⬇️⬇️
Я уже много раз упоминал свой пост про подписи Шнорра...и вот опять пришлось...Для более ясной картины оставлю ссылку на канал, где ребятушки еще проще описали это решение и рассказали почему о нем так много разговоров.
https://tttttt.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://tttttt.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
Подписи Шнорра - это хорошо. Но есть и альтернатива.
Подписи Боне – Линна – Шахама (BLS)
⬇️⬇️⬇️
https://bitnovosti.com/2019/05/14/bls-podpisi-luchshaya-alternativa-podpisyam-shnorra/
Кстати, стандарт BLS был принят разработчиками Ethereum. BLS-стандарты подписи определят принципы валидации депозита в сети ETH 2.0 поле его переноса из старой цепочки PoW.
Согласование BLS подписей в IETF (Internet Engineering Task Force - Инженерный Совет Интернета) – стандартизирует публичные и секретные ключи Etherеum 2.0 на международном уровне, сделав едиными и понятными принципы перехода на новую версию для всех многочисленных разработчиков и владельцев смарт-контрактов.
Подписи BLS могут комбинироваться друг с другом при помощи простых математических операций, при этом их комбинации остаются валидными ключами и подписями, позволяя легко агрегировать много подписей в одну и много публичных ключей в один.
Подписи Боне – Линна – Шахама (BLS)
⬇️⬇️⬇️
https://bitnovosti.com/2019/05/14/bls-podpisi-luchshaya-alternativa-podpisyam-shnorra/
Кстати, стандарт BLS был принят разработчиками Ethereum. BLS-стандарты подписи определят принципы валидации депозита в сети ETH 2.0 поле его переноса из старой цепочки PoW.
Согласование BLS подписей в IETF (Internet Engineering Task Force - Инженерный Совет Интернета) – стандартизирует публичные и секретные ключи Etherеum 2.0 на международном уровне, сделав едиными и понятными принципы перехода на новую версию для всех многочисленных разработчиков и владельцев смарт-контрактов.
Подписи BLS могут комбинироваться друг с другом при помощи простых математических операций, при этом их комбинации остаются валидными ключами и подписями, позволяя легко агрегировать много подписей в одну и много публичных ключей в один.
Bitnovosti
BLS-подписи: лучшая альтернатива подписям Шнорра |
Релиз Fabric Hyperledger 2.0
⬇️⬇️⬇️
https://www.hyperledger.org/blog/2020/01/30/welcome-hyperledger-fabric-2-0-enterprise-dlt-for-production
О технологии Hyperledger Fabric
⬇️⬇️⬇️
https://tttttt.me/CryptoBotan/844
Что нового?
⬇️⬇️⬇️
Обновление включает в себя децентрализованное управление смарт-контрактами, возможность выборочно делиться конфиденциальными данными с участниками консорциума.
Интегрирован новый механизм настройки и запуска цепного кода. Прежде чем код сможет взаимодействовать с распределенным реестром (DLT), его параметры должны согласовать сразу несколько сторон. Это исключает возможность сохранения записей в реестр без достижения консенсуса по транзакциям.
Появился еще один информационный канал для обмена между участникам консорциума конфиденциальными данными в частном порядке в соответствии с принципом необходимого знания (Need-to-know)
Need-to-know - принцип по которому, человек должен иметь доступ только к той информации, которая ему совершенно необходима для выполнения своих должностных обязанностей.
Добавлены: новый внешний модуль запуска чейнкода, новый тип консенсуса и функции, обеспечивающие общее улучшение производительности.
⬇️⬇️⬇️
https://www.hyperledger.org/blog/2020/01/30/welcome-hyperledger-fabric-2-0-enterprise-dlt-for-production
О технологии Hyperledger Fabric
⬇️⬇️⬇️
https://tttttt.me/CryptoBotan/844
Что нового?
⬇️⬇️⬇️
Обновление включает в себя децентрализованное управление смарт-контрактами, возможность выборочно делиться конфиденциальными данными с участниками консорциума.
Интегрирован новый механизм настройки и запуска цепного кода. Прежде чем код сможет взаимодействовать с распределенным реестром (DLT), его параметры должны согласовать сразу несколько сторон. Это исключает возможность сохранения записей в реестр без достижения консенсуса по транзакциям.
Появился еще один информационный канал для обмена между участникам консорциума конфиденциальными данными в частном порядке в соответствии с принципом необходимого знания (Need-to-know)
Need-to-know - принцип по которому, человек должен иметь доступ только к той информации, которая ему совершенно необходима для выполнения своих должностных обязанностей.
Добавлены: новый внешний модуль запуска чейнкода, новый тип консенсуса и функции, обеспечивающие общее улучшение производительности.
Hyperledger Foundation
Welcome Hyperledger Fabric 2.0: Enterprise DLT for Production – Hyperledger Foundation
As the first project of the Hyperledger greenhouse in 2016, Fabric introduced its v1.0 release in July, 2017. Since then, a number of enhancements and new features have been implemented...
✅✅✅
Хотел написать о Neutrino для стека Bitcoin, но прежде нужно разобраться вот с чем.
Технология SPV "Simplified Payment Verification" (SPV)
⬇️⬇️⬇️
В оригинальном White Paper Bitcoin (раздел 8), Сатоши Накамото описал технологию "Simplified Payment Verification" (SPV) - "Упрощенная проверка платежей".
(Выдержка из White Paper Bitcoin)
Верификация транзакций возможна без запуска полнофункционального узла. Пользователю необходимо лишь хранить заголовки блоков самой длинной цепочки, которую он получил от других узлов, и запрашивать хэш-поддерево для необходимой транзакции. Он не может проверить корректность транзакции самостоятельно, но получив ссылку на блок, в котором она находится, он может убедиться в том, что этот блок и все
последующие приняты и подтверждены сетью.
Узлы SPV, загружают только заголовки блоков и исключают транзакции каждого блока. Таким образом, у них есть цепочка блоков без транзакций, и это позволяет иметь результирующий объем данных, хранящихся локально более чем в тысячу раз меньше по размеру.
Используя SPV необходимо знать только корень Мёркла каждого блока для проверки транзакций. Следовательно появляется возможность хранения 80 байт на блок, а не 1Мб.
SPV выполняет 2 задачи:
1) Гарантирует, что ваши транзакции находятся в блоке.
2) Обеспечивает подтверждение того, что дополнительные блоки были добавлены в блокчейн.
Но не все так гладко.
SPV кошелек не проверяет никакие другие транзакции в блоке, но чисто гипотетически, блок может быть недействителен. Допустим, что сообщество приняло новые правила консенсуса и относительно большая группа узлов, которая не принимает новое правило, забыла обновиться. Несогласные узлы будут быстро отделены от сети, но пока это не произойдет, SPV клиент временно будет введен в заблуждение и будет считать, что не обновленные узлы имеют верную и самую длинную цепочку. Поэтому управление полным узлом обеспечивает «более быструю» систему безопасности – можно проверять все транзакции самостоятельно.
///
В 2013 году BIP0037 был добавлен в ядро биткойна, чтобы сделать SPV жизнеспособным. BIP0037 добавил новую поддержку к протоколу, который позволяет одноранговым узлам уменьшать объем передаваемых данных транзакций (создавались Light-узлы). Light-узлы могли запрашивать доказательства того, что определенная транзакция произошла в определенном блоке.
Одноранговые узлы имеют возможность устанавливать фильтры для каждого соединения. Затем сервер запускает фильтр по всем транзакциям нового блока и сообщает об этих транзакциях вместе с доказательством того, что они находятся в блоке, клиенту. Затем клиент проверяет доказательство и смотрит на транзакции, чтобы увидеть, принадлежат ли они кошельку.
BIP0037 имеет несколько недостатков:
Существуют векторы отказа в обслуживании (из-за необходимости запускать множество фильтров) для использования серверов, которые отвечают на запросы BIP0037.
Фильтры SPV-клиентов имеют абсолютно нулевую конфиденциальность, так как SPV клиенты должны обращаться к полным узлам и запрашивать информацию об определенных адресах и транзакциях. Хотя эту проблему и решает фильтр Блума, но использование узла SPV вместо полного дает пользователю более слабую конфиденциальность и безопасность. Фильтр Блума позволяет запрашивать конкретные транзакции, соответствующие шаблону, а не конкретные данные.
Узлы в сети должны обрабатывать чрезвычайно большой объем данных, чтобы возвращать результаты только для одного однорангового узла, и повторять работу для каждого отдельного однорангового узла, подключенного к приему нового блока.
Чтобы защитить узел SPV от возможности двойной атаки на сам SPV узел, узлы должны случайным образом соединяться с другими различными узлами, чтобы иметь максимальную вероятность получить правильную информацию. Вот почему, чтобы быть полностью уверенным в транзакции, нужно использовать только полный узел.
Хотел написать о Neutrino для стека Bitcoin, но прежде нужно разобраться вот с чем.
Технология SPV "Simplified Payment Verification" (SPV)
⬇️⬇️⬇️
В оригинальном White Paper Bitcoin (раздел 8), Сатоши Накамото описал технологию "Simplified Payment Verification" (SPV) - "Упрощенная проверка платежей".
(Выдержка из White Paper Bitcoin)
Верификация транзакций возможна без запуска полнофункционального узла. Пользователю необходимо лишь хранить заголовки блоков самой длинной цепочки, которую он получил от других узлов, и запрашивать хэш-поддерево для необходимой транзакции. Он не может проверить корректность транзакции самостоятельно, но получив ссылку на блок, в котором она находится, он может убедиться в том, что этот блок и все
последующие приняты и подтверждены сетью.
Узлы SPV, загружают только заголовки блоков и исключают транзакции каждого блока. Таким образом, у них есть цепочка блоков без транзакций, и это позволяет иметь результирующий объем данных, хранящихся локально более чем в тысячу раз меньше по размеру.
Используя SPV необходимо знать только корень Мёркла каждого блока для проверки транзакций. Следовательно появляется возможность хранения 80 байт на блок, а не 1Мб.
SPV выполняет 2 задачи:
1) Гарантирует, что ваши транзакции находятся в блоке.
2) Обеспечивает подтверждение того, что дополнительные блоки были добавлены в блокчейн.
Но не все так гладко.
SPV кошелек не проверяет никакие другие транзакции в блоке, но чисто гипотетически, блок может быть недействителен. Допустим, что сообщество приняло новые правила консенсуса и относительно большая группа узлов, которая не принимает новое правило, забыла обновиться. Несогласные узлы будут быстро отделены от сети, но пока это не произойдет, SPV клиент временно будет введен в заблуждение и будет считать, что не обновленные узлы имеют верную и самую длинную цепочку. Поэтому управление полным узлом обеспечивает «более быструю» систему безопасности – можно проверять все транзакции самостоятельно.
///
В 2013 году BIP0037 был добавлен в ядро биткойна, чтобы сделать SPV жизнеспособным. BIP0037 добавил новую поддержку к протоколу, который позволяет одноранговым узлам уменьшать объем передаваемых данных транзакций (создавались Light-узлы). Light-узлы могли запрашивать доказательства того, что определенная транзакция произошла в определенном блоке.
Одноранговые узлы имеют возможность устанавливать фильтры для каждого соединения. Затем сервер запускает фильтр по всем транзакциям нового блока и сообщает об этих транзакциях вместе с доказательством того, что они находятся в блоке, клиенту. Затем клиент проверяет доказательство и смотрит на транзакции, чтобы увидеть, принадлежат ли они кошельку.
BIP0037 имеет несколько недостатков:
Существуют векторы отказа в обслуживании (из-за необходимости запускать множество фильтров) для использования серверов, которые отвечают на запросы BIP0037.
Фильтры SPV-клиентов имеют абсолютно нулевую конфиденциальность, так как SPV клиенты должны обращаться к полным узлам и запрашивать информацию об определенных адресах и транзакциях. Хотя эту проблему и решает фильтр Блума, но использование узла SPV вместо полного дает пользователю более слабую конфиденциальность и безопасность. Фильтр Блума позволяет запрашивать конкретные транзакции, соответствующие шаблону, а не конкретные данные.
Узлы в сети должны обрабатывать чрезвычайно большой объем данных, чтобы возвращать результаты только для одного однорангового узла, и повторять работу для каждого отдельного однорангового узла, подключенного к приему нового блока.
Чтобы защитить узел SPV от возможности двойной атаки на сам SPV узел, узлы должны случайным образом соединяться с другими различными узлами, чтобы иметь максимальную вероятность получить правильную информацию. Вот почему, чтобы быть полностью уверенным в транзакции, нужно использовать только полный узел.
Forwarded from Goldfoundinshit ТМ
Внимание !
Возможно скоро в крипто ТГ каналах появится реклама какого то расширения, скрытая функция у которого - воровать криптовалюту. В личку поступило вот такое предложение. Так как ни на канал ни на чат это чудо не подписано, то я сделал вывод что оно делает рассылку по админам криптоканалов. Кто то может и согласится.
PS: После отказа и моих слов что я это опубликую - этот гражданин начал угрожать.
(скриншоты)
Возможно скоро в крипто ТГ каналах появится реклама какого то расширения, скрытая функция у которого - воровать криптовалюту. В личку поступило вот такое предложение. Так как ни на канал ни на чат это чудо не подписано, то я сделал вывод что оно делает рассылку по админам криптоканалов. Кто то может и согласится.
PS: После отказа и моих слов что я это опубликую - этот гражданин начал угрожать.
(скриншоты)
✅✅✅
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
Компания RSK, разрабатывающая сайдчейн в сети Биткойна и которая внедряет смарт-контракты для сети, объявила о выпуске моста между сетью BTC и ETH.
⬇️⬇️⬇️
https://cryptobriefing.com/rsk-introduces-interoperability-bridge-bitcoin-ethereum/
Теперь, два блокчейна могут взаимодействовать друг с другом используя сайдчейн BTC на платформе RSK. Мост позволяет токенам проходить между сетями без изменений в поставке токенов.
Как я уже описывал в постах про RootStock, (ссылочки обязательно будут ниже, если ты не в курсе), на платформе RSK можно было тратить BTC в смарт-контрактах, используя двусторонний мост и внутренний токен платформы SBTC. Теперь же функционал расширился и передавать можно любые токены Ethereum ERC-20.
Как работает мост между BTC и ETH?
Когда токен покидает свой родной блокчейн, мост “блокирует” его, выпуская такое же количество токенов на противоположной цепи для поддержания постоянного обеспечения. Токены, перемещающиеся из RSK в Ethereum, чеканятся на основе стандарта ERC-777, в то время как токены, перемещающиеся в противоположном направлении, создаются по стандарту RRC20 RSK.
Ссылочки
⬇️⬇️⬇️
https://tttttt.me/CryptoBotan/811
https://tttttt.me/CryptoBotan/813
⬇️⬇️⬇️
https://cryptobriefing.com/rsk-introduces-interoperability-bridge-bitcoin-ethereum/
Теперь, два блокчейна могут взаимодействовать друг с другом используя сайдчейн BTC на платформе RSK. Мост позволяет токенам проходить между сетями без изменений в поставке токенов.
Как я уже описывал в постах про RootStock, (ссылочки обязательно будут ниже, если ты не в курсе), на платформе RSK можно было тратить BTC в смарт-контрактах, используя двусторонний мост и внутренний токен платформы SBTC. Теперь же функционал расширился и передавать можно любые токены Ethereum ERC-20.
Как работает мост между BTC и ETH?
Когда токен покидает свой родной блокчейн, мост “блокирует” его, выпуская такое же количество токенов на противоположной цепи для поддержания постоянного обеспечения. Токены, перемещающиеся из RSK в Ethereum, чеканятся на основе стандарта ERC-777, в то время как токены, перемещающиеся в противоположном направлении, создаются по стандарту RRC20 RSK.
Ссылочки
⬇️⬇️⬇️
https://tttttt.me/CryptoBotan/811
https://tttttt.me/CryptoBotan/813
Crypto Briefing
RSK Introduces Interoperability Bridge for Bitcoin and Ethereum
Interoperability between the two biggest blockchains is now possible thanks to a bridge launched on the RSK platform, a side chain of Bitcoin.
✅✅✅
Scriptless Scripts ("Скрипты без скриптов")
К стеку биткоина.
⬇️⬇️⬇️
Смарт-контракты в сети BTC существуют и существовали до этого. Например Musig или смарт-контракты Lightning Network.
Но есть проблемка, и при чем не одна:
1) Ресурсы
Чем сложнее смарт-контракт, тем больше требуется ресурсов. Ведь все узлы сети должны исполнить контракт, а не только участники сделки.
2) Конфедициальность
Если все узлы сети испольняют контракт, то и об условиях контракта знает вся сеть.
Вообщем, почему я решил перескочить на решение "скрипты без скриптов". Все дело в том, что нужно опять немножко зацепить подписи Шнорра.
Суть:
Подписи Шнорра меньше, чем ECDSA, и могут быть объединены при помощи агрегации подписей. Это ведет к совместному использованию подписей несколькими входами. А это приводит к повышению конфиденциальности и масштабируемости сети.
Вот мы и у сути повествования:
Andrew Poelstra из BlockStream онаружил, что сами подписи могут быть сконструированы и модифицированы специальными способами для обеспечения выполнения различных соглашений между сторонами. Вводятся условия расходов, которые полностью скрыты от блокчейна. Только вовлеченные стороны знают об условиях договора или о том, что договор вообще существует. Для остальных транзакции выглядят совершенно обычными и неотличимыми от обычных.
Изучая протокол MimbleWimble, где вообще отсутсвуют скрипты, а весь блокчейн функционирует только на подписях и обязательствах, которые представляют собой расходуемые монеты, он выяснил, как при помощи скриптов обеспечить функциональность без необходимости их присутствия в блокчейне. Отсюда и название собственно говоря...
Большая часть контрактов просто перемещается за пределы блокчейна. Вместо исполнения контракта всей сетью, этим займутся только участвующие стороны. А выполнение результатов контракта, производится при требуемых условиях.
Чтобы смарт-контракты применяли только подписи, используются преимущества агрегации подписей Шнорра. Подписи могут добавляться и вычитаться, и результатом является допустимая подпись, соответствующая тому же добавлению или вычитанию открытых ключей.
Как это работает?
pubkey1 + pubkey2 + pubkey3 = pubkey Y
signature1 + signature2 + signature3 = signature Y
Мы привязываем биткоин к pubkey Y, который не является ключом и к которому у кого-либо есть доступ, но на самом деле он представляет собой сумму pubkeys. Подписи от каждого из ключей 1, 2 и 3 можно суммировать, чтобы создать подпись для pubkey Y, и сеть не будет в курсе, что на самом деле было три ключа, участвующих в создании подписи. Она будет выглядеть так же, как обычная подпись из pubkey Y, но сеть будет воспринимать ее как разрешение на расходование.
Сценарии без скриптов масштабируются лучше, чем обычные смарт-контракты, потому что выполнение условий контракта происходит вне цепочки, а следовательно и нет необходимости хранения данных контракта и выполнения его условий.
#SmartContracts
Scriptless Scripts ("Скрипты без скриптов")
К стеку биткоина.
⬇️⬇️⬇️
Смарт-контракты в сети BTC существуют и существовали до этого. Например Musig или смарт-контракты Lightning Network.
Но есть проблемка, и при чем не одна:
1) Ресурсы
Чем сложнее смарт-контракт, тем больше требуется ресурсов. Ведь все узлы сети должны исполнить контракт, а не только участники сделки.
2) Конфедициальность
Если все узлы сети испольняют контракт, то и об условиях контракта знает вся сеть.
Вообщем, почему я решил перескочить на решение "скрипты без скриптов". Все дело в том, что нужно опять немножко зацепить подписи Шнорра.
Суть:
Подписи Шнорра меньше, чем ECDSA, и могут быть объединены при помощи агрегации подписей. Это ведет к совместному использованию подписей несколькими входами. А это приводит к повышению конфиденциальности и масштабируемости сети.
Вот мы и у сути повествования:
Andrew Poelstra из BlockStream онаружил, что сами подписи могут быть сконструированы и модифицированы специальными способами для обеспечения выполнения различных соглашений между сторонами. Вводятся условия расходов, которые полностью скрыты от блокчейна. Только вовлеченные стороны знают об условиях договора или о том, что договор вообще существует. Для остальных транзакции выглядят совершенно обычными и неотличимыми от обычных.
Изучая протокол MimbleWimble, где вообще отсутсвуют скрипты, а весь блокчейн функционирует только на подписях и обязательствах, которые представляют собой расходуемые монеты, он выяснил, как при помощи скриптов обеспечить функциональность без необходимости их присутствия в блокчейне. Отсюда и название собственно говоря...
Большая часть контрактов просто перемещается за пределы блокчейна. Вместо исполнения контракта всей сетью, этим займутся только участвующие стороны. А выполнение результатов контракта, производится при требуемых условиях.
Чтобы смарт-контракты применяли только подписи, используются преимущества агрегации подписей Шнорра. Подписи могут добавляться и вычитаться, и результатом является допустимая подпись, соответствующая тому же добавлению или вычитанию открытых ключей.
Как это работает?
pubkey1 + pubkey2 + pubkey3 = pubkey Y
signature1 + signature2 + signature3 = signature Y
Мы привязываем биткоин к pubkey Y, который не является ключом и к которому у кого-либо есть доступ, но на самом деле он представляет собой сумму pubkeys. Подписи от каждого из ключей 1, 2 и 3 можно суммировать, чтобы создать подпись для pubkey Y, и сеть не будет в курсе, что на самом деле было три ключа, участвующих в создании подписи. Она будет выглядеть так же, как обычная подпись из pubkey Y, но сеть будет воспринимать ее как разрешение на расходование.
Сценарии без скриптов масштабируются лучше, чем обычные смарт-контракты, потому что выполнение условий контракта происходит вне цепочки, а следовательно и нет необходимости хранения данных контракта и выполнения его условий.
#SmartContracts
Lightning Labs выпустила бета-версию Loop.
⬇️⬇️⬇️
https://cryptobriefing.com/bitcoins-lightning-network-boost-lightning-labs/
Немного вводных:
20 марта 2019 года Lightning Labs объявила о своём альфа-релизе Lightning Loop — это новое решение, главной задачей которого является облегчение приема платежей. Для которого используется механизм Loop Out. Он увеличивает пропускную способность приема средств, оставляя каналы открытыми.
При настройке платежных каналов пользователи должны пополнить их, чтобы начать отправку и получение. "Входящая емкость" - это способность получателя требовать определенное количество BTC от отправителя. Например, у А есть платежный канал, установленный с Б, и А финансировала свою сторону на 2 BTC, а Б финансировала свою на 1 BTC, то входящая емкость А составляет 1 BTC, а Б - 2 BTC. Если А хочет получить 2 BTC от Б, то им придется открыть новый канал и финансировать его соответствующей суммой.
При чем, если у отправителя недостаточно BTC для данной транзакции, получатель не сможет получить выставленную сумму через канал. Также если канал переполнен, то получатель не сможет получать средства.
Механизм Loop Out позволяет повысить пропускную способность приема средств. Он оставляет каналы открытыми, а средства можно выгрузить из сети, как только канал достиг предельной емкости. То есть не нужно создавать новый канал и закрывать старый. Средства можно выгрузить на кошелек или биржу.
Механизм Loop In, работает в обратном направлении. Теперь можно пополнить канал из кошельков.
Lightning Loop это первая платная услуга от Lightning Labs.
Loop Out взимает плату 0.05% - 0.5%, а Loop In 0.10% - 1% fee.
⬇️⬇️⬇️
https://cryptobriefing.com/bitcoins-lightning-network-boost-lightning-labs/
Немного вводных:
20 марта 2019 года Lightning Labs объявила о своём альфа-релизе Lightning Loop — это новое решение, главной задачей которого является облегчение приема платежей. Для которого используется механизм Loop Out. Он увеличивает пропускную способность приема средств, оставляя каналы открытыми.
При настройке платежных каналов пользователи должны пополнить их, чтобы начать отправку и получение. "Входящая емкость" - это способность получателя требовать определенное количество BTC от отправителя. Например, у А есть платежный канал, установленный с Б, и А финансировала свою сторону на 2 BTC, а Б финансировала свою на 1 BTC, то входящая емкость А составляет 1 BTC, а Б - 2 BTC. Если А хочет получить 2 BTC от Б, то им придется открыть новый канал и финансировать его соответствующей суммой.
При чем, если у отправителя недостаточно BTC для данной транзакции, получатель не сможет получить выставленную сумму через канал. Также если канал переполнен, то получатель не сможет получать средства.
Механизм Loop Out позволяет повысить пропускную способность приема средств. Он оставляет каналы открытыми, а средства можно выгрузить из сети, как только канал достиг предельной емкости. То есть не нужно создавать новый канал и закрывать старый. Средства можно выгрузить на кошелек или биржу.
Механизм Loop In, работает в обратном направлении. Теперь можно пополнить канал из кошельков.
Lightning Loop это первая платная услуга от Lightning Labs.
Loop Out взимает плату 0.05% - 0.5%, а Loop In 0.10% - 1% fee.
✅✅✅
Решение для масштабирования сети Биткойн - 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
✅✅✅
Пока готовлю пост про tBTC - децентрализованном погашаемом токене ERC-20 с поддержкой BTC, немного новостей на эту тему...
tBTC уже в тестовой сети Ethereum. Пользователи уже могут поработать с tBTC на тестовом dApp, пока контракты проверяются ConsenSys.
Контракты в основной сети, должны будут развернутся в начале марта 2020 год.
⬇️⬇️⬇️
https://cryptobriefing.com/bitcoin-set-join-defi-hype-tbtc-launch/
Пока готовлю пост про tBTC - децентрализованном погашаемом токене ERC-20 с поддержкой BTC, немного новостей на эту тему...
tBTC уже в тестовой сети Ethereum. Пользователи уже могут поработать с tBTC на тестовом dApp, пока контракты проверяются ConsenSys.
Контракты в основной сети, должны будут развернутся в начале марта 2020 год.
⬇️⬇️⬇️
https://cryptobriefing.com/bitcoin-set-join-defi-hype-tbtc-launch/
Crypto Briefing
Bitcoin Set to Join in on DeFi Hype with tBTC Launch | Crypto Briefing
tBTC, a wrapped version of BTC, is live on Ethereum’s Ropsten testnet. If it becomes a standard, Bitcoin could soon ride the DeFi wave.
✅✅✅
Сегодня про tBTC. Биткоин доступный на Ethereum.
Для стека биткоина
⬇️⬇️⬇️
DEX в сети Ethereum имеет существенный недостаток: они позволяют торговать только активами, основанными на Ethereum. tBTC позволит держателям BTC подключаться к (DeFi) Ethereum.
Хотя уже есть подобные решения, но есть нюансы...
1) Например Liquid. Проблема в том, что BTC, запираются на мультивалютном кошельке, подписывают который участники проверенные BlockStream. Они проверяют сайдчейн и голосуют за подписание блоков, плюс и одобряют peg-out транзакции.
2) WBTC - это поддерживаемый BTC токен ERC-20. Консорциум проводит голосование за добавление и удаление хранителей, управляющих BTC - резервами токена. Эти хранители управляют multisig кошельком BTC, контролируют ключи, перемещают их и создают WBTC на Ethereum.
Проблема состоит в том, что нужно доверять свои средства третей стороне.
tBTC - это депозитный токен (TDT) ERC-20 с поддержкой BTC 1:1. Это способ для юзеров вносить свои BTC и создавать биткойн-токены на Ethereum без посредников и KYC.
Это проект, предложенный Cross Chain Group (CCG) и крупный dApp, построенный на Keep Network, автономной сети узлов, считывающих и записывающих данные в сети Ethereum и Bitcoin.
Как это происходит? Я постарался подробно описать принцип работы, но если что, жду фидбэка😉
Небольшая вводная:
tBTC (TDT) - это депозитный токен, который привязан к конкретному депозиту tBTC Bitcoin UTXO. Удержание токена позволяет выкупить этот депозит tBTC за оригинальный биткоин, используемый для его финансирования. Владелец TDT обладает исключительным правом выкупа базового UTXO до истечения срока действия депозита (6 месяцев).
Существует отдельный контракт, называемый торговым автоматом TBTC, который используется для чеканки взаимозаменяемых TBTC в обмен на TDT.
Депонирование BTC для создания TBTC.
Вкладчик размещает облигационный контракт (ETH) и отправляет запрос депозита в смарт-контракт tBTC на Ethereum. Отправка запроса сигнализирует смарт-контракт о том, что вкладчик хочет депонировать BTC и создать TBTC.
Облигационный контракт нужен для защиты от спама, который возвращаются после завершения депонирования.
Создается адрес депозита и система случайным образом выбирает группу подписчиков, которые генерируют BTC-кошелек. Этот кошелек требует M из N подписей для генерации действительных транзакций. Подписавшие должны внести залог в размере 1,5х суммы BTC, депонированного в ETH.
Контракт создает tBTC (токен депозита) и токен ERC-721 (NFT токен -токен получателя) и они отправляются вкладчику. Токен получателя используется для управления депозитом.
BTC отправляются на указанный адрес, после чего отправляется SPV-подтверждение платежа из цепочки BTC в депозитный контракт на цепочке ETH. После чего создается TBTC из контракта и передаются вкладчику.
Для обмена TBTC в BTC есть возможность использовать токен депозита tBTC (TDT) для погашения точного UTXO вашего первоначального депозита, если он находится в пределах установленного 6-месячного периода. Есть несколько способов обмена в BTC:
1) Если есть TDT, то нужно отправить плату подписчикам (0.005 TBTC). Это даст точное UTXO связанное с TDT.
2) Если TDT нет, но нужны BTC для TBTC, то можно заплатить 0.005 TBTC подписавшему, чтобы выкупить BTC из системы
3) Если нет TDT, но есть депозит, который существовал в системе больше 6 месяцев, то он обойдется в 1TBTC, чтобы выкупить его за 1 BTC. В таком случае сборы подписчикам оплачивает текущий владелец депозита tBTC.
Система просит подтвердить запрос BTC на блокчейне Ethereum. Затем выпускаются BTC и подтверждается выпуск по цепочке ETH. Затем отправляется подтверждение транзакции BTC в цепочку ETH, инициируя платеж подписавшего.
///
tBTC полагается на ценовые каналы, облигации и арбитражные возможности, для поддержания честной работы системы. DeFi получит доступ к ликвидности биткойна. Протокол автоматизации инвестиций сможет снизить риски для своих пользователей, которые связаны с хранением и ценами, при помощи интеграции tBTC. Вся подробная информация о tBTC по ссылочке
#SmartContracts
Сегодня про tBTC. Биткоин доступный на Ethereum.
Для стека биткоина
⬇️⬇️⬇️
DEX в сети Ethereum имеет существенный недостаток: они позволяют торговать только активами, основанными на Ethereum. tBTC позволит держателям BTC подключаться к (DeFi) Ethereum.
Хотя уже есть подобные решения, но есть нюансы...
1) Например Liquid. Проблема в том, что BTC, запираются на мультивалютном кошельке, подписывают который участники проверенные BlockStream. Они проверяют сайдчейн и голосуют за подписание блоков, плюс и одобряют peg-out транзакции.
2) WBTC - это поддерживаемый BTC токен ERC-20. Консорциум проводит голосование за добавление и удаление хранителей, управляющих BTC - резервами токена. Эти хранители управляют multisig кошельком BTC, контролируют ключи, перемещают их и создают WBTC на Ethereum.
Проблема состоит в том, что нужно доверять свои средства третей стороне.
tBTC - это депозитный токен (TDT) ERC-20 с поддержкой BTC 1:1. Это способ для юзеров вносить свои BTC и создавать биткойн-токены на Ethereum без посредников и KYC.
Это проект, предложенный Cross Chain Group (CCG) и крупный dApp, построенный на Keep Network, автономной сети узлов, считывающих и записывающих данные в сети Ethereum и Bitcoin.
Как это происходит? Я постарался подробно описать принцип работы, но если что, жду фидбэка😉
Небольшая вводная:
tBTC (TDT) - это депозитный токен, который привязан к конкретному депозиту tBTC Bitcoin UTXO. Удержание токена позволяет выкупить этот депозит tBTC за оригинальный биткоин, используемый для его финансирования. Владелец TDT обладает исключительным правом выкупа базового UTXO до истечения срока действия депозита (6 месяцев).
Существует отдельный контракт, называемый торговым автоматом TBTC, который используется для чеканки взаимозаменяемых TBTC в обмен на TDT.
Депонирование BTC для создания TBTC.
Вкладчик размещает облигационный контракт (ETH) и отправляет запрос депозита в смарт-контракт tBTC на Ethereum. Отправка запроса сигнализирует смарт-контракт о том, что вкладчик хочет депонировать BTC и создать TBTC.
Облигационный контракт нужен для защиты от спама, который возвращаются после завершения депонирования.
Создается адрес депозита и система случайным образом выбирает группу подписчиков, которые генерируют BTC-кошелек. Этот кошелек требует M из N подписей для генерации действительных транзакций. Подписавшие должны внести залог в размере 1,5х суммы BTC, депонированного в ETH.
Контракт создает tBTC (токен депозита) и токен ERC-721 (NFT токен -токен получателя) и они отправляются вкладчику. Токен получателя используется для управления депозитом.
BTC отправляются на указанный адрес, после чего отправляется SPV-подтверждение платежа из цепочки BTC в депозитный контракт на цепочке ETH. После чего создается TBTC из контракта и передаются вкладчику.
Для обмена TBTC в BTC есть возможность использовать токен депозита tBTC (TDT) для погашения точного UTXO вашего первоначального депозита, если он находится в пределах установленного 6-месячного периода. Есть несколько способов обмена в BTC:
1) Если есть TDT, то нужно отправить плату подписчикам (0.005 TBTC). Это даст точное UTXO связанное с TDT.
2) Если TDT нет, но нужны BTC для TBTC, то можно заплатить 0.005 TBTC подписавшему, чтобы выкупить BTC из системы
3) Если нет TDT, но есть депозит, который существовал в системе больше 6 месяцев, то он обойдется в 1TBTC, чтобы выкупить его за 1 BTC. В таком случае сборы подписчикам оплачивает текущий владелец депозита tBTC.
Система просит подтвердить запрос BTC на блокчейне Ethereum. Затем выпускаются BTC и подтверждается выпуск по цепочке ETH. Затем отправляется подтверждение транзакции BTC в цепочку ETH, инициируя платеж подписавшего.
///
tBTC полагается на ценовые каналы, облигации и арбитражные возможности, для поддержания честной работы системы. DeFi получит доступ к ликвидности биткойна. Протокол автоматизации инвестиций сможет снизить риски для своих пользователей, которые связаны с хранением и ценами, при помощи интеграции tBTC. Вся подробная информация о tBTC по ссылочке
#SmartContracts
Глеб Науменко - разработчик в Chaincode Labs, работающий над сетевым уровнем Bitcoin Core про подписи Шнорра, Taproot, Stratum V2 и многом другом.
Наткнулся только сейчас, но если не смотрели, то много интересного из первых уст...
⬇️⬇️⬇️
https://www.youtube.com/watch?v=5SjqMp9KDUE
Наткнулся только сейчас, но если не смотрели, то много интересного из первых уст...
⬇️⬇️⬇️
https://www.youtube.com/watch?v=5SjqMp9KDUE
YouTube
Биткоинизация / Не только халвинг: технологии, которые изменят Биткоин уже в 2020 — Глеб Науменко
В сегодняшнем выпуске рубрики #биткоинизация мы обсудим, как изменится Биткоин в 2020. Забудьте про халвинг (временно), оторвитесь от графиков: сегодня информация о ключевых событиях в развитии технологии из первых рук — у нас в гостях разработчик протоколов…
✅✅✅
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)
Несколько месяцев работы в этом посте. Как итог: визуализация масштабов экосистемы Биткойна и работы над ней.
Добавил от себя некоторые решения. Внутри ссылки на проекты и протоколы, статьи и посты из других…