✅✅✅
Технология Taproot
⬇️⬇️⬇️
Технология Taproot, ориентированна на повышенную гибкость смарт-контрактов при сохранении достаточно высокого уровня приватности. Предполагается, что пользователи не смогут отличить простые транзакции даже от самых сложных смарт-контрактов.
Изначально Taproot спроектировал разработчик Bitcoin Core и бывший CTO компании Blockstream Грегори Максвелл. На данный момент идет работа над имплементацией подписей Шнорра, которая включает в себя и технологию Taproot.
Taproot основан на следующем утверждении: любая MAST-конструкция, вне зависимости от уровня сложности, должна включать в себя условие, которое позволит всем участникам согласовать результат и подписать транзакцию вместе.
MAST предполагает генерацию отдельных хешей для каждого условия траты монет с последующем их включением в дерево Меркла, которое и производит единый хеш или так называемый корень Меркла. Последний и «запирает» монеты.
Если А знает, что Б все равно получит доступ к средствам на следующей неделе, он может работать с ней сообща, чтобы подписать транзакцию вместе.
Таким образом Taproot по своей структуре напоминает MAST, но всегда предполагает наличие условия, позволяющего всем участникам работать сообща для осуществления траты: так называемое «совместное закрытие».
Taproot не обеспечивает полную конфиденциальность Биткоина, однако предлагает способ сделать все транзакции в блокчейне одинаковыми для стороннего наблюдателя.
Проблема заключается в том, что Taproot зависит от других технологий, которые также развернуты в Биткоине. Например подписи Шнорра.
Без подписей Шнорра Taproot не сможет работать в полную силу.
#SmartContracts
Технология Taproot
⬇️⬇️⬇️
Технология Taproot, ориентированна на повышенную гибкость смарт-контрактов при сохранении достаточно высокого уровня приватности. Предполагается, что пользователи не смогут отличить простые транзакции даже от самых сложных смарт-контрактов.
Изначально Taproot спроектировал разработчик Bitcoin Core и бывший CTO компании Blockstream Грегори Максвелл. На данный момент идет работа над имплементацией подписей Шнорра, которая включает в себя и технологию Taproot.
Taproot основан на следующем утверждении: любая MAST-конструкция, вне зависимости от уровня сложности, должна включать в себя условие, которое позволит всем участникам согласовать результат и подписать транзакцию вместе.
MAST предполагает генерацию отдельных хешей для каждого условия траты монет с последующем их включением в дерево Меркла, которое и производит единый хеш или так называемый корень Меркла. Последний и «запирает» монеты.
Если А знает, что Б все равно получит доступ к средствам на следующей неделе, он может работать с ней сообща, чтобы подписать транзакцию вместе.
Таким образом Taproot по своей структуре напоминает MAST, но всегда предполагает наличие условия, позволяющего всем участникам работать сообща для осуществления траты: так называемое «совместное закрытие».
Taproot не обеспечивает полную конфиденциальность Биткоина, однако предлагает способ сделать все транзакции в блокчейне одинаковыми для стороннего наблюдателя.
Проблема заключается в том, что Taproot зависит от других технологий, которые также развернуты в Биткоине. Например подписи Шнорра.
Без подписей Шнорра Taproot не сможет работать в полную силу.
#SmartContracts
Telegram
CryptoBotan
✅✅✅
Сегодня про решение MAST
Продолжим изучать инструменты по увеличению гибкости смарт-контрактов, а также масштабируемости и приватности сети Биткоин.
⬇️⬇️⬇️
MAST или Merkelized Abstract Syntax Trees (дословно Мерклизованные абстрактные синтаксические…
Сегодня про решение MAST
Продолжим изучать инструменты по увеличению гибкости смарт-контрактов, а также масштабируемости и приватности сети Биткоин.
⬇️⬇️⬇️
MAST или Merkelized Abstract Syntax Trees (дословно Мерклизованные абстрактные синтаксические…
✅✅✅
Теперь о Graftroot
⬇️⬇️⬇️
Taproot эффективен в случае «совместного закрытия», однако альтернативные варианты предполагают раскрытие ветвей Меркла, что также тянет за собой обработку больших массивов данных.
Технология Graftroot, предложенная Максвеллом, предполагает, что участники смарт-контракта создают «пороговый публичный ключ», но в дальнейшем они его не видоизменяют. Вместо этого они подписывают скрипты (альтернативные условия траты) с целью создания «пороговых подписей» для каждого из них.
Так, пользователь выбирает определенный скрипт, хранит его вместе с соответствующей подписью, которая может подтвердить, что альтернативное условие траты истинное и одобрено всеми участниками делегированное.
Вернемся к ситуации с А и Б, которые могут осуществить трату средств при определенных условиях. У них есть опция «совместного закрытия», то есть А может потратить монеты через неделю или же это может сделать Б, если он задействует секретное число. В этом случае они оба объединяют публичные ключи и создают «пороговый публичный ключ», который позволит им осуществить трату при наличии “пороговой подписи”. Последнюю создадут при непосредственной трате.
Затем оба участника создают и подписывают альтернативные скрипты. А сохраняет «пороговую подпись» для скрипта, который позволит ей осуществить трату через неделю, а Б делает то же для сценария с секретным числом. Отметим при этом, что “пороговых подписей” и соответствующих сценариев для траты недостаточно: они служат лишь подтверждением, что Б и А договорились об условиях. Для осуществления траты необходимо выполнить условия, заложенные в скрипте.
В случае провала «совместного закрытия», участники должны раскрыть альтернативный скрипт и «пороговую подпись». Сторонние пользователи смогут сопоставить «пороговый публичный ключ» с «пороговой подписью», чтобы подтвердить, что условия в скрипте были одобрены всеми сторонами. Таким образом они оба могут потратить средства, а другие пользователи никогда не узнают о наличии альтернативных сценариев.
Проблемой решения Graftroot является его интерактивность. Участники должны контактировать друг с другом для подтверждения альтернативных скриптов до траты. Кроме того, они должны хранить «пороговые подписи» для каждого из этих скриптов, и при их потере, они лишатся запасных вариантов для траты в случае провала «совместного закрытия».
Graftroot скрывает наличие альтернативных версий, однако в каждой транзакции должна указываться используемая версия протокола, которая может показать пользователям, какая именно технология использовалась.
Есть небольшая проблема, связанная с одновременным развертыванием всех этих функций. Каждый раз, когда развертывается новое «изменение консенсуса», оно требует нового формата адресации.
Новые адреса отличаются от старых, и этим выдают тех, кто уже использует новую функцию – тем более, что не каждый внедрит обновление сразу в день его запуска. Это займет время, точно так же, как и прошлые изменения. Это небольшой удар по конфиденциальности, однако одновременное развертывание всех этих обновлений превратилось бы в настоящий хаос.
#SmartContracts
Теперь о Graftroot
⬇️⬇️⬇️
Taproot эффективен в случае «совместного закрытия», однако альтернативные варианты предполагают раскрытие ветвей Меркла, что также тянет за собой обработку больших массивов данных.
Технология Graftroot, предложенная Максвеллом, предполагает, что участники смарт-контракта создают «пороговый публичный ключ», но в дальнейшем они его не видоизменяют. Вместо этого они подписывают скрипты (альтернативные условия траты) с целью создания «пороговых подписей» для каждого из них.
Так, пользователь выбирает определенный скрипт, хранит его вместе с соответствующей подписью, которая может подтвердить, что альтернативное условие траты истинное и одобрено всеми участниками делегированное.
Вернемся к ситуации с А и Б, которые могут осуществить трату средств при определенных условиях. У них есть опция «совместного закрытия», то есть А может потратить монеты через неделю или же это может сделать Б, если он задействует секретное число. В этом случае они оба объединяют публичные ключи и создают «пороговый публичный ключ», который позволит им осуществить трату при наличии “пороговой подписи”. Последнюю создадут при непосредственной трате.
Затем оба участника создают и подписывают альтернативные скрипты. А сохраняет «пороговую подпись» для скрипта, который позволит ей осуществить трату через неделю, а Б делает то же для сценария с секретным числом. Отметим при этом, что “пороговых подписей” и соответствующих сценариев для траты недостаточно: они служат лишь подтверждением, что Б и А договорились об условиях. Для осуществления траты необходимо выполнить условия, заложенные в скрипте.
В случае провала «совместного закрытия», участники должны раскрыть альтернативный скрипт и «пороговую подпись». Сторонние пользователи смогут сопоставить «пороговый публичный ключ» с «пороговой подписью», чтобы подтвердить, что условия в скрипте были одобрены всеми сторонами. Таким образом они оба могут потратить средства, а другие пользователи никогда не узнают о наличии альтернативных сценариев.
Проблемой решения Graftroot является его интерактивность. Участники должны контактировать друг с другом для подтверждения альтернативных скриптов до траты. Кроме того, они должны хранить «пороговые подписи» для каждого из этих скриптов, и при их потере, они лишатся запасных вариантов для траты в случае провала «совместного закрытия».
Graftroot скрывает наличие альтернативных версий, однако в каждой транзакции должна указываться используемая версия протокола, которая может показать пользователям, какая именно технология использовалась.
Есть небольшая проблема, связанная с одновременным развертыванием всех этих функций. Каждый раз, когда развертывается новое «изменение консенсуса», оно требует нового формата адресации.
Новые адреса отличаются от старых, и этим выдают тех, кто уже использует новую функцию – тем более, что не каждый внедрит обновление сразу в день его запуска. Это займет время, точно так же, как и прошлые изменения. Это небольшой удар по конфиденциальности, однако одновременное развертывание всех этих обновлений превратилось бы в настоящий хаос.
#SmartContracts
Telegram
CryptoBotan
✅✅✅
Технология Taproot
⬇️⬇️⬇️
Технология Taproot, ориентированна на повышенную гибкость смарт-контрактов при сохранении достаточно высокого уровня приватности. Предполагается, что пользователи не смогут отличить простые транзакции даже от самых сложных смарт…
Технология Taproot
⬇️⬇️⬇️
Технология Taproot, ориентированна на повышенную гибкость смарт-контрактов при сохранении достаточно высокого уровня приватности. Предполагается, что пользователи не смогут отличить простые транзакции даже от самых сложных смарт…
✅✅✅
Сегодня про решение MAST
Продолжим изучать инструменты по увеличению гибкости смарт-контрактов, а также масштабируемости и приватности сети Биткоин.
⬇️⬇️⬇️
MAST или Merkelized Abstract Syntax Trees (дословно Мерклизованные абстрактные синтаксические деревья)
Решение MAST включает в себя P2S и деревья Меркла
Дерево Меркла – это одна из разновидностей хэш-функций, которые позволяют преобразовывать входящую информацию в битовую строку определенного размера. Проще говоря, порция данных кодируется в цепь цифр, которая и называется хэшем.
Главные функции дерева хэшей:
1) Способность присваивать каждому электронному документу собственный идентификатор (хэш);
2) Проверка целостности документа;
3) Восстановление удаленного файла.
Хэш всегда уникален, он не позволяет восстанавливать информацию, но зато прекрасно используется для проверок: даже при минимальном изменении информации, меняется и хэш тоже. То есть, если у вас есть доступ к исходной информации, то при их хэшировании должен получиться тот же код. Если это не так – то исходные данные не верны.
Дерево Меркла – это схема, хэширующая большое количество информации. При этом данные объединяются в порции, которые структура хэширует, получившиеся хэши также объединяются, потом снова хэшируются и так далее до тех пор, пока не получится один главный хэш, образующий вершину всего дерева. Таким образом, хэшевое дерево позволяет сохранить большое количество данных, ведь процесс преобразования может длиться сколько угодно, а результатом всегда будет один-единственный хэш.
MAST соединяет потенциал P2SH с возможностями, которые несут в себе деревья Меркла. Вместо того, чтобы блокировать биткоины в один скрипт, при использовании MAST те же самые биткоины можно заблокировать в несколько разных скриптов.
Те же самые биткоины можно заблокировать, используя несколько разных и взаимоисключающих условий (например, требование криптографической подписи только от А, или подписей от Б и В, или подписи от одной В по прошествии определенного количества времени, и так далее).
Какое из этих условий выполняется (подтверждается) в транзакции первым, то и определяет, как будут потрачены биткоины.
Так же, как в случае с P2SH, все эти разные скрипты хэшируются. Однако на этот раз они соединяются в дереве Меркла. И в выход транзакции в качестве окончательного блокировщика включается корень Меркла.
Процесс расходования средств также напоминает схему P2SH. Для создания транзакции средства из корня Меркла разблокируются, весь используемый скрипт должен включаться в новую транзакцию вместе с условием разблокировки скрипта (блокировщик и ключ).
Решение MAST улучшает Биткоин в трёх основных направлениях:
1) увеличивает гибкость смарт-контрактов
2) улучшает масштабируемость
3) повышает конфиденциальность.
Для более эффективной реализации решения, с ним поставляется Tapscript и Graftroot
#SmartContracts
Сегодня про решение MAST
Продолжим изучать инструменты по увеличению гибкости смарт-контрактов, а также масштабируемости и приватности сети Биткоин.
⬇️⬇️⬇️
MAST или Merkelized Abstract Syntax Trees (дословно Мерклизованные абстрактные синтаксические деревья)
Решение MAST включает в себя P2S и деревья Меркла
Дерево Меркла – это одна из разновидностей хэш-функций, которые позволяют преобразовывать входящую информацию в битовую строку определенного размера. Проще говоря, порция данных кодируется в цепь цифр, которая и называется хэшем.
Главные функции дерева хэшей:
1) Способность присваивать каждому электронному документу собственный идентификатор (хэш);
2) Проверка целостности документа;
3) Восстановление удаленного файла.
Хэш всегда уникален, он не позволяет восстанавливать информацию, но зато прекрасно используется для проверок: даже при минимальном изменении информации, меняется и хэш тоже. То есть, если у вас есть доступ к исходной информации, то при их хэшировании должен получиться тот же код. Если это не так – то исходные данные не верны.
Дерево Меркла – это схема, хэширующая большое количество информации. При этом данные объединяются в порции, которые структура хэширует, получившиеся хэши также объединяются, потом снова хэшируются и так далее до тех пор, пока не получится один главный хэш, образующий вершину всего дерева. Таким образом, хэшевое дерево позволяет сохранить большое количество данных, ведь процесс преобразования может длиться сколько угодно, а результатом всегда будет один-единственный хэш.
MAST соединяет потенциал P2SH с возможностями, которые несут в себе деревья Меркла. Вместо того, чтобы блокировать биткоины в один скрипт, при использовании MAST те же самые биткоины можно заблокировать в несколько разных скриптов.
Те же самые биткоины можно заблокировать, используя несколько разных и взаимоисключающих условий (например, требование криптографической подписи только от А, или подписей от Б и В, или подписи от одной В по прошествии определенного количества времени, и так далее).
Какое из этих условий выполняется (подтверждается) в транзакции первым, то и определяет, как будут потрачены биткоины.
Так же, как в случае с P2SH, все эти разные скрипты хэшируются. Однако на этот раз они соединяются в дереве Меркла. И в выход транзакции в качестве окончательного блокировщика включается корень Меркла.
Процесс расходования средств также напоминает схему P2SH. Для создания транзакции средства из корня Меркла разблокируются, весь используемый скрипт должен включаться в новую транзакцию вместе с условием разблокировки скрипта (блокировщик и ключ).
Решение MAST улучшает Биткоин в трёх основных направлениях:
1) увеличивает гибкость смарт-контрактов
2) улучшает масштабируемость
3) повышает конфиденциальность.
Для более эффективной реализации решения, с ним поставляется Tapscript и Graftroot
#SmartContracts
✅✅✅
В августе 2019 года разработчик и программист и создатель SegWit, Питер Вюлле представил новый язык программирования смарт-контрактов для Биткоина - Miniscript. Давно хотел рассказать о нем, но руки не доходили более детально разобрать его.
Miniscript - язык программирования для смарт-контрактов Bitcoin.
⬇️⬇️⬇️
Я много писал о смарт-контрактах на Ethereum, да в целом. Для начала о смарт-контрактах чуть подробнее здесь.
Про решение MAST для увеличения гибкости смарт-контрактов, а также масштабируемости и приватности сети Биткоин здесь.
Теперь про новый язык...
В криптопространстве уже существуют смарт-контракты для биткоина. О чем я тоже успел написать ранее😏Сеть биткойн-платформы RootStock для смарт-контрактов .
Почти год он с Эндрю Поэлстра из BlockStream и Санкет Саньялкар?, работали на кодом и решили опубликовать код, так как пришло время привлечь к нему внимание.
Язык биткоина позволяет программировать транзакции “if-then-else”, но он не обладает полнотой по Тьюрингу.
Полная по Тьюрингу - это термин, который подразумевает способность ЭВМ выполнять любые задачи. Одним из примеров «полноты» считается EVM. Полнота по Тьюрингу показывает на присутствие инструментов, требуемых для решения конкретной задачи. Их наличие гарантирует самостоятельную работу системы. Подавляющее большинство существующих сегодня сетей блокчейн (в том числе и криптовалюты Биткоин) не имеют такой способности. Их контракты просты по структуре. По сути, это транзакции, исполнение которых происходит с небольшой задержкой.
Язык Miniscript призван облегчить программистам создание более полноценных смарт-контрактов в Биткоине.
Биткоин упрощает пороговые подписи и мультиподписи, и их использование было заторможено из-за запутанности биткоин-скрипта. Эта технология является языком программирования базового уровня, и она не приспособлена для использования подписей из-за своих простых принципов работы.
Miniscript оптимизирует сценарий и делает его более структурированным, так как код может быть написан для понимания условий траты биткоина. Он создан на базе языка смарт-контрактов Script – языке смарт-контрактов биткоина, который позволяет указать определенные условия, при которых может состояться трата криптовалюты.
Miniscript построен поверх языка Script.
Miniscript не вызывает проблем, так как язык программирования не привнёс в систему ничего нового. Обработка скрипта реструктурирует функциональность, которая уже существовала в коде и делала его более доступным.
Идет работа над расширением структуры Miniscript для поддержки будущих изменений скриптов, которые могут быть включены в кодовую базу биткоина.
Тут сложно, но очень важно...😄
Miniscript, по словам Велле, представляет собой новый способ написания структурированных скриптов, обеспечивающий возможность проведения различных видов статического анализа, создания генерических подписей и модифицируемого набора условий для выполнения смарт-контрактов.
Для полного погружения в суть и перспективу MiniScript есть статья на английском языке. Так как я такой себе кодер и программист мне сложно переводить на технически-русский язык. Оставляю тем, кому интересно здесь.
Сегодня Miniscript доступен в имплементациях для языков C++ и Rust.
#SmartContracts
В августе 2019 года разработчик и программист и создатель SegWit, Питер Вюлле представил новый язык программирования смарт-контрактов для Биткоина - Miniscript. Давно хотел рассказать о нем, но руки не доходили более детально разобрать его.
Miniscript - язык программирования для смарт-контрактов Bitcoin.
⬇️⬇️⬇️
Я много писал о смарт-контрактах на Ethereum, да в целом. Для начала о смарт-контрактах чуть подробнее здесь.
Про решение MAST для увеличения гибкости смарт-контрактов, а также масштабируемости и приватности сети Биткоин здесь.
Теперь про новый язык...
В криптопространстве уже существуют смарт-контракты для биткоина. О чем я тоже успел написать ранее😏Сеть биткойн-платформы RootStock для смарт-контрактов .
Почти год он с Эндрю Поэлстра из BlockStream и Санкет Саньялкар?, работали на кодом и решили опубликовать код, так как пришло время привлечь к нему внимание.
Язык биткоина позволяет программировать транзакции “if-then-else”, но он не обладает полнотой по Тьюрингу.
Полная по Тьюрингу - это термин, который подразумевает способность ЭВМ выполнять любые задачи. Одним из примеров «полноты» считается EVM. Полнота по Тьюрингу показывает на присутствие инструментов, требуемых для решения конкретной задачи. Их наличие гарантирует самостоятельную работу системы. Подавляющее большинство существующих сегодня сетей блокчейн (в том числе и криптовалюты Биткоин) не имеют такой способности. Их контракты просты по структуре. По сути, это транзакции, исполнение которых происходит с небольшой задержкой.
Язык Miniscript призван облегчить программистам создание более полноценных смарт-контрактов в Биткоине.
Биткоин упрощает пороговые подписи и мультиподписи, и их использование было заторможено из-за запутанности биткоин-скрипта. Эта технология является языком программирования базового уровня, и она не приспособлена для использования подписей из-за своих простых принципов работы.
Miniscript оптимизирует сценарий и делает его более структурированным, так как код может быть написан для понимания условий траты биткоина. Он создан на базе языка смарт-контрактов Script – языке смарт-контрактов биткоина, который позволяет указать определенные условия, при которых может состояться трата криптовалюты.
Miniscript построен поверх языка Script.
Miniscript не вызывает проблем, так как язык программирования не привнёс в систему ничего нового. Обработка скрипта реструктурирует функциональность, которая уже существовала в коде и делала его более доступным.
Идет работа над расширением структуры Miniscript для поддержки будущих изменений скриптов, которые могут быть включены в кодовую базу биткоина.
Тут сложно, но очень важно...😄
Miniscript, по словам Велле, представляет собой новый способ написания структурированных скриптов, обеспечивающий возможность проведения различных видов статического анализа, создания генерических подписей и модифицируемого набора условий для выполнения смарт-контрактов.
Для полного погружения в суть и перспективу MiniScript есть статья на английском языке. Так как я такой себе кодер и программист мне сложно переводить на технически-русский язык. Оставляю тем, кому интересно здесь.
Сегодня Miniscript доступен в имплементациях для языков C++ и Rust.
#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
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
✅✅✅
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
✅✅✅
Сегодня про 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
✅✅✅
Bitcoin Hivemind - пиринговый протокол Oracle
Для стека биткоина
⬇️⬇️⬇️
Bitcoin Hivemind ( в прошлом Truthcoin) - это opensource, P2P протокол Oracle, предложенный Paul Sztorc и функционирующий как сайдчейн, который дает возможность вносить в блокчейн точные данные, позволяющие владельцам биткоинов спекулировать на рынке прогнозов. Т.е. он позволяет использовать BTC для создания "PM"- “prediction markets” (рынков прогнозирования) и участия в них.
Рынки прогнозирования - это инструменты для принятия решений определяемых рыночными силами, и в то же время устраняющие большую часть шума и неопределенности, которые мешают процессу принятия решений. Они используют прогнозы пользователей для сбора информации о будущих событиях.
Одна из основных концепций PM заключается в том, что если вы не согласны с тем, что показывает рынок, то вы можете воспользоваться этими маржами и сделать ставку против рынка.
Такие проекты как Augur и Gnosis опираются на понятие “Wisdom of the Crowd” - мудрость толпы - явление, в котором коллективные предсказания группы людей обычно более точны, чем индивидуальные, даже если толпа состоит не из экспертов, а один человек таковым является.
Hivemind является методом краудсорсинга для определения вероятных исходов событий и фокусируется на управлении, решая проблемы с многофакторным принятием решений.
У Hivemind есть пользователи и “employees”. Эти "employees" работают в "филиалах “(каждый филиал напоминает товарооборотную биржу) и голосуют за ”решения“ (результаты выборов или ценовые каналы), которые разрешают ”рынки" (торговые арены, определенные одним или несколькими решениями). Пользователи могут свободно создавать любые решения или рынки, которые им нравятся, несмотря на то, что они экономически конкурируют за ограниченные “слоты принятия решений”.
Hivemind - это сайдчейн, который использует двойную схему токенов с биткойном, функционирующим в качестве пользовательского уровня, и VoteCoins в качестве уровня репутации/“employees”. Ценность биткойна отражает именно то, что он делает — хранилище ценности, — в то время как VoteCoins используются для обозначения репутации пользователя на платформе.
Любой пользователь может создать рынок предсказаний, если он способен заплатить за него BTC.
Все решения добавляются в блокчейн самостоятельно. Авторам впоследствии нужно предоставить стартовый капитал, чтобы обеспечить начальную ликвидность рынка и “сделать рынок"."Авторы получают выгоду от создания рынка и его использования, но также несут ответственность за поддержание рынка и все затраты ресурсов, связанные с его созданием.
Торговая активность должна сходиться к рыночной цене вероятного "состояния" события, но такая точность требует высоколиквидного и активного рынка, что требует времени для развития, особенно когда это PM, построенный на новой технологии, такой как биткойн.
На вопрос чем HiveMind лучше Augur и Gnosis, ответ прост...HiveMind - это P2P-протокол, а значит децентрализован, в отличие от двух других.
WhitePaper
GitHub
#SmartContracts
Bitcoin Hivemind - пиринговый протокол Oracle
Для стека биткоина
⬇️⬇️⬇️
Bitcoin Hivemind ( в прошлом Truthcoin) - это opensource, P2P протокол Oracle, предложенный Paul Sztorc и функционирующий как сайдчейн, который дает возможность вносить в блокчейн точные данные, позволяющие владельцам биткоинов спекулировать на рынке прогнозов. Т.е. он позволяет использовать BTC для создания "PM"- “prediction markets” (рынков прогнозирования) и участия в них.
Рынки прогнозирования - это инструменты для принятия решений определяемых рыночными силами, и в то же время устраняющие большую часть шума и неопределенности, которые мешают процессу принятия решений. Они используют прогнозы пользователей для сбора информации о будущих событиях.
Одна из основных концепций PM заключается в том, что если вы не согласны с тем, что показывает рынок, то вы можете воспользоваться этими маржами и сделать ставку против рынка.
Такие проекты как Augur и Gnosis опираются на понятие “Wisdom of the Crowd” - мудрость толпы - явление, в котором коллективные предсказания группы людей обычно более точны, чем индивидуальные, даже если толпа состоит не из экспертов, а один человек таковым является.
Hivemind является методом краудсорсинга для определения вероятных исходов событий и фокусируется на управлении, решая проблемы с многофакторным принятием решений.
У Hivemind есть пользователи и “employees”. Эти "employees" работают в "филиалах “(каждый филиал напоминает товарооборотную биржу) и голосуют за ”решения“ (результаты выборов или ценовые каналы), которые разрешают ”рынки" (торговые арены, определенные одним или несколькими решениями). Пользователи могут свободно создавать любые решения или рынки, которые им нравятся, несмотря на то, что они экономически конкурируют за ограниченные “слоты принятия решений”.
Hivemind - это сайдчейн, который использует двойную схему токенов с биткойном, функционирующим в качестве пользовательского уровня, и VoteCoins в качестве уровня репутации/“employees”. Ценность биткойна отражает именно то, что он делает — хранилище ценности, — в то время как VoteCoins используются для обозначения репутации пользователя на платформе.
Любой пользователь может создать рынок предсказаний, если он способен заплатить за него BTC.
Все решения добавляются в блокчейн самостоятельно. Авторам впоследствии нужно предоставить стартовый капитал, чтобы обеспечить начальную ликвидность рынка и “сделать рынок"."Авторы получают выгоду от создания рынка и его использования, но также несут ответственность за поддержание рынка и все затраты ресурсов, связанные с его созданием.
Торговая активность должна сходиться к рыночной цене вероятного "состояния" события, но такая точность требует высоколиквидного и активного рынка, что требует времени для развития, особенно когда это PM, построенный на новой технологии, такой как биткойн.
На вопрос чем HiveMind лучше Augur и Gnosis, ответ прост...HiveMind - это P2P-протокол, а значит децентрализован, в отличие от двух других.
WhitePaper
GitHub
#SmartContracts
✅✅✅
OP_CHECKTEMPLATEVERIFY (OP_CTV) (ранее OP_SECURETHEBAG)
Для стека биткоина
Сегодня здесь будет ссылка, а не рукописный пост. Я не халтурю, а хотелось бы...😅
Статья написана автором канала @hypecoinnews и подробно описывает функции и возможности OPCTV.
⬇️⬇️⬇️
https://telegra.ph/Bitkoin-Hraniteli-OP-CHECKTEMPLATEVERIFY-03-01
Добавлю, что существуют способы использования платежных каналов, связанных с OPCTV:
Channel Factories
Non-Interactive Channels
Increased Channel Routes
CoinJoin
Это интересное решение для увеличения пропускной способности сети и уменьшения комиссий, но есть мнения, что новый класс меток Noinput лучше решит поставленную задачу. Но об этом позже...
GitHub OP_CTV
#SmartContracts
OP_CHECKTEMPLATEVERIFY (OP_CTV) (ранее OP_SECURETHEBAG)
Для стека биткоина
Сегодня здесь будет ссылка, а не рукописный пост. Я не халтурю, а хотелось бы...😅
Статья написана автором канала @hypecoinnews и подробно описывает функции и возможности OPCTV.
⬇️⬇️⬇️
https://telegra.ph/Bitkoin-Hraniteli-OP-CHECKTEMPLATEVERIFY-03-01
Добавлю, что существуют способы использования платежных каналов, связанных с OPCTV:
Channel Factories
Non-Interactive Channels
Increased Channel Routes
CoinJoin
Это интересное решение для увеличения пропускной способности сети и уменьшения комиссий, но есть мнения, что новый класс меток Noinput лучше решит поставленную задачу. Но об этом позже...
GitHub OP_CTV
#SmartContracts
✅✅✅
Simplicity - новый язык для блокчейнов, реализующий смарт-контракты в биткоине.
Для стека биткоина
⬇️⬇️⬇️
Я уже писал о других языках способных помочь деду стать более подвижным и удобным. Это обновленный язык Биткойна Tapscript для сценариев Taproot. Это MiniScript на базе языка смарт-контрактов Script.
Скриптовый язык Биткойна очень ограничен дизайном и непригоден для построения сложных смарт-контрактов. Некоторые опкоды (подробнее тут) были отключены еще в самом начале пути Биткойна.
Ethereum имеет полный гибкий и полный по Тьюрингу язык. Но и тут есть проблема...Ethereum не поддерживает статический анализ, который позволяет заранее определить какое количество вычислительных ресурсов потребуется программе. Таким образом можно отфильтровать дорогостоящие контракты и бесконечные циклы.
Simplicity был представлен разработчиком из Blockstream Russell O’Connor. Simplicity предназначен для включения в сайдчейн BlockStream и в дальнейшем, при помощи софтфорка, имплементирование его в Биткойн. Simplicity позволит завершать и расширять возможности сценариев.
Simplicity - это низкоуровневый язык основанный на алгоритме последовательного вычисления для выполнения смарт-контрактов. Это типизированный функциональный язык программирования, использующий комбинаторы. Он может быть использован как основа для других языков, более высокого уровня, так и для улучшения существующих (Bitcoin Script, EVM Ethereum).
Simplicity - это не полный по Тьюрингу, обеспечивающий ограничение рекурсивного вызова и защиту от бесконечных циклов язык. Он позволяет проводить статический анализ кода (эффективно ограничивать объем вычислительных ресурсов, необходимый программе до ее выполнения). Имеет встроенную поддержку мерклизованных абстрактных синтаксических деревьев (MAST)
Разработка пакетов SDK (Software Developer Kit) первый шаг, по развертыванию языка в проекте Elements от Blockstream.
Software Development Kit (комплект программ для разработки) - это набор необходимых программных продуктов (библиотек, скриптов), предназначенный для облегчения процесса разработки и тестирования кода для конкретных программных платформ.
Simplicity в будущем может быть интегрирован с Ivy (язык более высокого уровня, позволяющий писать смарт-контракты для протокола Bitcoin). О нем мы тоже поговорим позже, так как я собираюсь разобрать стек до конца.😇
WhitePaper
Site
#SmartContracts
Simplicity - новый язык для блокчейнов, реализующий смарт-контракты в биткоине.
Для стека биткоина
⬇️⬇️⬇️
Я уже писал о других языках способных помочь деду стать более подвижным и удобным. Это обновленный язык Биткойна Tapscript для сценариев Taproot. Это MiniScript на базе языка смарт-контрактов Script.
Скриптовый язык Биткойна очень ограничен дизайном и непригоден для построения сложных смарт-контрактов. Некоторые опкоды (подробнее тут) были отключены еще в самом начале пути Биткойна.
Ethereum имеет полный гибкий и полный по Тьюрингу язык. Но и тут есть проблема...Ethereum не поддерживает статический анализ, который позволяет заранее определить какое количество вычислительных ресурсов потребуется программе. Таким образом можно отфильтровать дорогостоящие контракты и бесконечные циклы.
Simplicity был представлен разработчиком из Blockstream Russell O’Connor. Simplicity предназначен для включения в сайдчейн BlockStream и в дальнейшем, при помощи софтфорка, имплементирование его в Биткойн. Simplicity позволит завершать и расширять возможности сценариев.
Simplicity - это низкоуровневый язык основанный на алгоритме последовательного вычисления для выполнения смарт-контрактов. Это типизированный функциональный язык программирования, использующий комбинаторы. Он может быть использован как основа для других языков, более высокого уровня, так и для улучшения существующих (Bitcoin Script, EVM Ethereum).
Simplicity - это не полный по Тьюрингу, обеспечивающий ограничение рекурсивного вызова и защиту от бесконечных циклов язык. Он позволяет проводить статический анализ кода (эффективно ограничивать объем вычислительных ресурсов, необходимый программе до ее выполнения). Имеет встроенную поддержку мерклизованных абстрактных синтаксических деревьев (MAST)
Разработка пакетов SDK (Software Developer Kit) первый шаг, по развертыванию языка в проекте Elements от Blockstream.
Software Development Kit (комплект программ для разработки) - это набор необходимых программных продуктов (библиотек, скриптов), предназначенный для облегчения процесса разработки и тестирования кода для конкретных программных платформ.
Simplicity в будущем может быть интегрирован с Ivy (язык более высокого уровня, позволяющий писать смарт-контракты для протокола Bitcoin). О нем мы тоже поговорим позже, так как я собираюсь разобрать стек до конца.😇
WhitePaper
Site
#SmartContracts
