RGB - это масштабируемый и конфиденциальный протокол умных контрактов, применимый к биткоину и сети Lightning, разработанный Ассоциацией стандартов LNP/BP. Он принимает концепции частной и совместной собственности, предлагая тьюринг-полное, доверительное форму распределенных вычислений без необходимости в блокчейне, работающую как система умных контрактов с частичным состоянием, подтверждаемым клиентом.
История протокола RGB
RGB был изначально задуман Джакомо Цукко из BHB Network в 2016 году как "система активов, не основанная на блокчейне". В том же году Питер Тодд представил концепции одноразовых печатей и клиентской проверки. Вдохновленный этими идеями, RGB был предложен в 2018 году. В 2019 году ведущую роль в разработке кода RGB и проектировании основных стандартов взял на себя главный разработчик Максим Орловский. Максим Орловский и Джакомо Цукко основали ассоциацию стандартов LNP/BP.https://www.lnp-bp.org) чтобы перевести RGB от концепции к применению, получив поддержку от Fulgur Ventures, Bitfinex, Hojo Foundation, Pandora Prime и DIBA. После длительной разработки RGB выпустил свою первую стабильную версию, V0.10, в апреле 2023 года. В январе 2024 года основные разработчики RGB объявили, что версия V0.11 будет выпущена в начале первой половины года.
Последние события в протоколе RGB
Новые функции RGB V0.10 были тщательно проанализированы в других отчетах. В то время как V0.11 еще не был официально выпущен, вот некоторые из последних разработок от разработчиков и сообщества:
Предстоящая поддержка L-BTC
Обновления по взаимодействию и мостам между RGB-активами и Жидкими активами
Однако RGB V0.11 будет несовместим с V0.10, что приведет к значительным затратам на миграцию для текущих проектов. Кроме того, из-за медленного прогресса разработки многие проекты в настоящее время ждут выпуска V0.11.
Умные контракты RGB используют клиентскую проверку, что означает, что все данные хранятся за пределами транзакций Bitcoin, то есть на блокчейне Bitcoin или в состоянии каналов Lightning. Это позволяет системе работать поверх Lightning Network без изменений в основной сети BTC или протоколах Lightning Network, положив основу для масштабируемости и конфиденциальности протокола.
RGB использует одноразовые печати, определенные на выходах UTXO Bitcoin, обеспечивая каждому, кто имеет запись истории состояния смарт-контракта, возможность проверить его уникальность. Другими словами, RGB использует скрипты Bitcoin для реализации своей модели безопасности и определения прав собственности и доступа.
RGB - это направленный ациклический граф (DAG) переходов состояний, где контракты полностью изолированы друг от друга, и никто не знает о их существовании, кроме владельцев контрактов (или тех, кому владелец раскрывает информацию о контракте).
Орграф с обратной связью (DAG) - это специальная структура графа, которая может ярко объяснить сложные системы или отношения. В DAG каждое ребро можно рассматривать как улицу с односторонним движением в городе, что представляет собой "направленный" аспект графа. Предположим, в этой сети улиц, как бы вы ни путешествовали, невозможно вернуться к начальной точке и образовать замкнутый контур; это представляет собой "несвязанный" характер графа. В DAG нет последовательности узлов, которая позволяет вам начать с одного узла, пройти через ряд рёбер и вернуться к тому же узлу.
Применяя этот концепт к системе RGB, каждый контракт можно рассматривать как узел в графе, а отношения между контрактами (например, передача собственности) можно рассматривать как направленные ребра. Эта структура обеспечивает четкость и порядок отношений между контрактами, без образования замкнутых циклов, что означает, что контракт не может напрямую или косвенно влиять на себя.
Этот дизайн обеспечивает уникальность и неизменность обязательств в передаче состояния, предотвращая двойные расходы и обеспечивая эффективные и последовательные переходы состояний.
После понимания основных принципов архитектурного дизайна RGB давайте посмотрим на часть контракта. В текущем мире смарт-контрактов создателям требуется самостоятельно организовать или выполнить разработку кода смарт-контракта. Философия дизайна RGB считает эту практику нежелательной, что приводит к более высоким уязвимостям кода контракта и многочисленным хакерским атакам. Поэтому RGB нацелен на снижение риска уязвимостей в разработке и потребности в аудитах путем введения концепции «Схематических шаблонов». «Схематические шаблоны» представляют собой фактический код смарт-контрактов. Издатели могут использовать их в качестве «шаблонов контрактов», не нуждаясь в написании кода или аудите на заказной код, написанный для них каким-то случайным подрядчиком.
Контракты RGB определяются декларативно, а не императивно. Это означает, что логика контракта не определяется серией команд или шагов, а набором правил, описывающих его поведение и переходы состояний, формирующих направленный ациклический граф (DAG) изменений состояний. Ключом к локальным операциям с состоянием является схема. Операции в контрактах RGB локальны, а не глобальны. Каждый узел (или состояние) имеет свои правила и отвечает только за свои переходы состояний. Это отличается от глобальных алгоритмов на платформах, таких как Ethereum, где каждое состояние должно следовать одному и тому же алгоритму. Эта характеристика делает RGB достаточно гибким и масштабируемым, обеспечивая при этом хорошую интероперабельность.
Схема определяет, какие типы глобальных и собственных состояний, печатей и метаданных допускаются при переходе состояний. RGB использует язык Contractum для написания схем RGB и AluVM (виртуальная арифметическая логическая машина), упрощая написание умных контрактов RGB. AluVM основан на регистровом дизайне без случайного доступа к памяти, что делает его очень подходящим для умных контрактов, удаленного выполнения кода, распределенных и краевых вычислений, обеспечивая основу для различных продвинутых случаев использования умных контрактов.
От самого дизайна RGB:
Приватность без глобального вещания: Как упоминалось, клиентская проверка RGB означает, что процесс проверки происходит только между непосредственно затронутыми участниками, а не на всей сети. Данный подход к проверке без глобального вещания повышает уровень конфиденциальности и устойчивость к цензуре, поскольку детали состояния контракта видны только соответствующим участникам, а майнеры не могут видеть детали транзакции.
Конфиденциальность данных в песочнице: с другой стороны, RGB сохраняет все данные операций в куче. Поскольку RGB не основан на блокчейне, хранение не реплицируется на другие узлы пиров. Хранение, контролируемое локально пользователями, снижает риск внешних атак и утечек данных, обеспечивая конфиденциальность данных. RGB - это вычислительная платформа, где каждая программа («умный контракт») изолирована в своей среде песочницы, обеспечивая лучшую масштабируемость и безопасность по сравнению с платформами, основанными на блокчейне. Однако оффчейн-данные также означают риск потери.
Помимо проверки и хранения, система выставления счетов также обеспечивает безопасность и конфиденциальность. Операции с контрактами в RGB осуществляются путем создания счетов, которые могут содержать несколько запросов на операции с контрактом. Позволяя пользователям явно указывать и проверять операции с контрактами, улучшается точность и безопасность операций. В то же время система выставления счетов поддерживает конфиденциальную передачу запросов на операции с контрактом между пользователями, улучшая конфиденциальность транзакций. Переходы состояний, такие как передачи токенов, выполняются через счета и конкретные команды.
Дизайн RGB тесно связан с UTXO. Во взаимодействии с основной сетью BTC пользователи создают контракты вне цепи для выпуска активов RGB и их выделения в UTXO Bitcoin, аналогично Lightning Network. После этого передачи активов, контрактные взаимодействия и проверки выполняются вне цепи, как было представлено выше.
RGB получает выгоду от улучшенных протоколов мультиподписи, протоколов подписи на основе адаптеров и контрактов времени блокировки точки (PTLCs), предоставленных подписями Шнорра, но ее преимущества основаны исключительно на биткоинах (т.е. косвенно). В RGB нет ничего, что требовало бы подписей (поэтому Шнорр не вносит внутренних изменений), ни оно не использует скрипты биткоина (поэтому новый Tapscript бесполезен).
BTC Security Lab, основанная ScaleBit, - это специализированная лаборатория по безопасности BTC, работающая над последними разработками протокола RGB. Ее целью является защита безопасности контрактов, совместное продвижение непрерывного роста и укрепления протокола RGB и инфраструктурного строительства экосистемы BTC.
BiHelix
Веб-сайт: https://www.bihelix.net/
BiHelix - инфраструктура биткойн-экосистемы, оптимизированная для узлов, построенная на собственной цепочке блоков биткойна, включающая протокол RGB и молниеносную сеть. Ее цель - упростить разработку, расширить область применения биткойна и решить проблемы масштабируемости и тьюринг-неполноты, с которыми сталкивается цепочка блоков биткойна. BiHelix стремится создать более справедливый децентрализованный криптографический мир для майнеров, валидаторов, провайдеров услуг узлов, бирж и пользователей. Будучи первой инфраструктурой, построенной на протоколе RGB, BiHelix разработает следующее поколение крупномасштабных сценариев применения биткойна. Проект в настоящее время находится в стадии разработки и еще не открыт для взаимодействия; следите за обновлениями.
Особенности проекта
Порог низкого уровня пользователей: использует протокол SLR (Security-Lightning-RGB), переупаковывая RGB и Lightning Network с инновационными решениями для узлов молнии, чтобы достичь универсальных платежей.
Высокая надежность и масштабируемость: использует зрелую архитектуру облачных служб, полностью используя функции руст-молнии для поддержки функций фабрики каналов, эффективного управления каналами и создания каналов оптом.
Защита безопасности и конфиденциальности: передача и хранение данных состояния вне цепи, использование рекурсивных доказательств нулевого знания среди прочих технологий для рандомизации многопартийных платежей и выбора пути для защиты конфиденциальности.
Удобный для разработчиков : Предоставляет полный набор инструментов разработки, включая документацию с открытым исходным кодом, инструменты и т. д., и представляет механизм социального консенсуса Schema, что облегчает создание приложений разработчикам.
Кошелек Iris
Веб-сайт: https://play.google.com/store/apps/details?id=com.iriswallet.testnet&pli=1
IRIS Wallet, первый кошелек для Android, разработанный командой Bitfinex, посвященный интеграции RGB и инструментам, связанным с RGB, поддерживающий обращаемые и необращаемые активы. Кошелек Iris позволяет осуществлять операции с активами RGB от выпуска до траты и получения, упаковывая все функциональные возможности в знакомом приложении для кошелька, абстрагируясь от максимально возможного количества технических деталей. В настоящее время это экспериментальное приложение, рекомендуемое для небольших сумм биткойнов и активов низкой стоимости.
DIBA
Веб-сайт: https://diba.io/
DIBA - первая биржа NFT на Bitcoin, использующая протокол RGB и Lightning Network. Она нацелена на формирование понимания неохраняемых художественных активов на блокчейне Bitcoin.
Битовая маска
Веб-сайт: https://bitmask.app/
Созданный DIBA, Bitmask - первый кошелек NFT в экосистеме RGB, работает в веб-браузерах и взаимодействует с RGB контрактами, аналогично MetaMask на Ethereum. В настоящее время часто обновляется, ожидая выпуска V0.11.
Pandora Prime Inc
Вебсайт: https://pandoraprime.ch/
Расположенный в Долине Verify, Швейцария, Pandora Prime также является учредителем LNP/BP. Pandora Prime посвятил себя пионерству в Bitcoin Finance с использованием комбинации RGB смарт-контрактов и Lightning Network. Они начинают с программных активов на Bitcoin (RGBTC и CHFN), которые могут масштабировать пропускную способность транзакций до уровня VISA/MasterCard через Lightning Network, предоставляя при этом возможности для простого обмена этими активами. Их продуктами являются MyCitadel (кошелек), RGB Explorer (браузер) и Pandora Network, среди прочего.
MyCitadel
Веб-сайт: https://mycitadel.io/
Бренд Pandora Prime, MyCitadel - первый графический кошелек, поддерживающий RGB, созданный разработчиками RGB в 2021 году. Он предлагает кроссплатформенные настольные кошельки и кошельки для iOS/iPad. Мобильный кошелек может обрабатывать средства RGB.
RGB Explorer
Веб-сайт: https://rgbex.io/
Разработанный компанией Pandora Prime, RGB Explorer является первым браузером, предлагающим регистрацию RGB-активов и смарт-контракты. В настоящее время он поддерживает RGB 20, RGB 21, RGB 25, отображая активы, такие как LNPBP, RGBTC, dCHF и RGBEX.
Лаборатории Bitlight (ранее Cosminmart)
Веб-сайт: https://bitlightlabs.com/
Компания Bitlight Labs разрабатывает инфраструктуру на основе протокола RGB, готовясь к развертыванию нескольких приложений в сети Lightning, включая кошелек Bitlight для утилиты RGB и Bitswap, автоматизированный рыночный создатель для BitcoinFi в сети Lightning и протоколе RGB.
PPRGB
X: @PepeRgb20
PPRGB в настоящее время выпускается в сети Liquid, в ожидании сопоставления с RGB после выпуска RGB V0.11 (V0.11 также разрабатывает функции кода для взаимодействия с Liquid).
Надпись MRGB
Одноразовый пломбир
Seal, это коллекция из 10k PFP, редких UDA и токенов на RGB20 и RGB21, названная в честь концепции Single Use Seal Питера Тодда. В настоящее время ожидается обновление кошельков Bitlight и Bitmask до версии v0.11 RGB, после чего они будут выпущены на них.
Битман
X: @bitmancity
Выпустит 10 тыс. UDA на diba, возможно, через wl+публичную продажу, с миссией "передачи духа BTC". Проект имеет похвальную цель и будет предоставлять wl участникам экосистемы BTC, причем большая часть выручки от публичной продажи будет пожертвована в LNP/BP.
BitVM (Bitcoin Virtual Machine) вводит систему, которая позволяет проверять любые вычисления на блокчейне биткоина без ущерба для его безопасности или изменения сети. Это развитие открывает двери для сложных вычислений, таких как умные контракты полного исполнения Тьюринга, при обработке всех вычислений за пределами цепи, чтобы снизить перегрузку на блокчейне биткоина.
“Простыми словами, BitVM - это вычислительная модель, способная выражать контракты, полностью совместимые с машиной Тьюринга, в сети Bitcoin.” Как и RGB, BitVM не требует модификаций правил консенсуса сети.
9 октября 2023 года Робин Линус, сооснователь разработчика блокчейнов ZeroSync, опубликовал белую книгу BitVM. По сравнению с RGB, BitVM гораздо моложе.
Архитектура
Подобно Оптимистичным Роллапам и предложению Merkelize All The Things (MATT), основанному на доказательствах мошенничества и протоколах вызова-ответа, это не требует изменений в правилах консенсуса Биткоина. BitVM демонстрирует, что Биткоин является полностью универсальным, кодируя доказательства мошенничества внутри больших Taptrees.
Дизайн воротной схемы
Обязательство по значению бита - самый базовый компонент, позволяющий инициатору установить значение конкретного бита на «0» или «1». Любая вычислимая функция может быть представлена в виде булевой цепи, формируя обязательства логических ворот. Составленные с использованием ворот NAND (универсальных логических ворот), каждое ворото имеет свое собственное обязательство. Любая цепь может быть выражена путем объединения обязательств ворот. Каждый шаг выполнения фиксируется в Tapleaf и объединяется в одном и том же адресе Taproot.
BitVM использует обновление Taproot Bitcoin, создавая структуру, аналогичную бинарной схеме (называемой taptree), чтобы достичь своей функциональности. В этой системе условия траты для каждого UTXO, представленные инструкциями в сценарии, формируют основную единицу программы. Эти инструкции генерируют двоичные выходы (0 или 1) в адресе Taproot, тем самым строя всю taptree. Результат taptree можно рассматривать как результат выполнения двоичной схемы, подобно исполняемой программе. Сложность программ, которые может выполнить taptree, зависит от количества и сложности адресов Taproot, составляющих ее. Короче говоря, BitVM реализует возможность запуска более сложных программ в сети Bitcoin, переводя инструкции сценария Bitcoin в двоичные операции.
Участвующими ролями являются две стороны
В настоящее время модель ограничивается двумя сторонами и не может быть расширена для включения большего количества участников. Более того, для правильной работы BitVM требуется большое количество предварительных подписей (вычислений вне цепи), что делает BitVM довольно сложным и потенциально неэффективным.
Доказательства мошенничества и протокол challenge-response
И доказатель и вызывающий внесут равное количество BTC в транзакцию как ставку (в качестве входных данных), и результатом этой транзакции будет логическая схема. Во время установочной фазы предварительно подписывается ряд транзакций для опровержения неверных утверждений. BitVM уподобляется Оптимистичным Rollups, потому что основная часть вычислений производится вне цепи и некоторые из этих вычислений представляются на цепи для разрешения споров в случае их возникновения.
Оптимистичные Rollups - это решение масштабирования второго уровня, которое снижает нагрузку на базовый уровень за счет перемещения вычислений и хранения данных вне цепи. Затем он объединяет несколько транзакций и публикует их в основной цепи. Оптимистичные Rollups предполагают, что все транзакции действительны. Однако, если участники сети замечают нечестное поведение, они могут инициировать доказательство мошенничества. Доказательство мошенничества - это доказательство неточных вычислений кого-то. Они производятся после проверки.
Вычисления вне цепи
Почти вся деятельность на BitVM ведется вне блокчейна. Это включает в себя инициирование вычислительных задач, обмен данными и проверку отправленных заявок. BitVM обычно не выполняет вычисления в блокчейне Биткойна. Вычисления и проверки публикуются в блокчейне только в случае возникновения спора из-за подозрений в мошенничестве. Однако, если возникает спор, небольшая часть процесса спора действительно проходит в блокчейне, и этого достаточно, чтобы определить, какая сторона является нечестной.
Имея вышеперечисленные знания, мы можем лучше понять конкретные принципы взаимодействия двух сторон в BitVM.
Двухсторонняя модель взаимодействия BitVM включает в себя доказывающего и проверяющего. В этой системе доказывающий сначала создает и отправляет смарт-контракт или программу, затем отправляет средства на совместно контролируемый мастер-адрес корневого узла. Эти средства хранятся в 2 из 2 мультисигнатурном распоряжении. Доказывающему также необходимо предоставить достаточно информации проверяющему, чтобы доказать, что их программа может произвести обещанный результат.
Задача верификатора - запустить код доказывающего и проверить, соответствует ли вывод ожиданиям. Если вывод не соответствует, верификатор вызовет доказывающего. Этот процесс взаимодействия вызов-ответ включает обмен данными вне цепи и использование предварительно подписанных транзакций для проверки правильности вычислений.
Если обнаружена вычислительная ошибка, верификатор может публично доказать нечестное поведение доказывающего с помощью доказательства мошенничества на цепи. В системе BitVM, если доказывающий ответ оказывается неверным, он проиграет ставку и утратит средства. Напротив, если все ответы верны, доказывающий сохраняет свои средства. Этот экономический стимулирующий механизм разработан для предотвращения нечестного поведения.
В конечном итоге эта взаимодействие гарантирует, что вычислительная проверка передается на блокчейн Bitcoin только в случае спора, тем самым выполняя подавляющее большинство вычислений вне цепи. Такая конструкция обеспечивает эффективность сети Bitcoin, предоставляя возможность запускать более сложные программы на Bitcoin.
Безопасность BitVM
С точки зрения архитектурного дизайна, безопасность BitVM в основном основана на следующих аспектах:
Доказательства мошенничества
В случае спора валидаторы могут оспаривать неправильные утверждения предложившего через доказательства мошенничества. Этот механизм аналогичен Оптимистичным Rollups и не требует изменения правил консенсуса Биткоина.
Протокол Challenge-Response
BitVM использует протокол «запрос-ответ», в котором инициаторы и валидаторы заранее подписывают ряд транзакций на этапе настройки протокола. Эти транзакции используются для решения вопросов при возникновении спора.
Вычисление вне цепи с верификацией в цепи
BitVM позволяет выполнять сложные вычисления вне цепи, в то время как верификация и разрешение происходят только в цепи в случае спора. Такой подход снижает потребление ресурсов цепи, сохраняя при этом целостность и безопасность блокчейна Bitcoin.
Механизм депозита и штрафов
Если претендент делает неверное заявление, валидаторы могут конфисковать его депозит. Этот механизм гарантирует, что злоумышленники всегда теряют свой депозит за неправомерные действия.
Механизм двусторонних контрактов
Этот механизм обеспечивает лучшую конфиденциальность на БитVM и снижает транзакционные издержки, но по сравнению с многопартийным механизмом EVM его универсальность немного снижается.
Что такое протокол Nostr
Nostr означает "Примечания и другие материалы, передаваемые ретрансляторами", что указывает на то, что это протокол передачи, включающий ретрансляторы, что свидетельствует о том, что это не протокол передачи от равных к равным (P2P). Согласнокод GitHubобновить записи, этот проект был запущен в ноябре 2020 года. Протокол нацелен на создание самого простого открытого протокола для цензуроустойчивой глобальной социальной сети. Это децентрализованный социальный протокол, который позволяет пользователям создавать, публиковать и подписываться на любой тип контента без контроля или вмешательства со стороны каких-либо централизованных платформ или учреждений. Nostr черпает вдохновение из Bitcoin и сети Lightning, используя аналогичные криптографические и консенсус-механизмы, а также структуру данных на основе событий, известную как сеть Nostr.
Пара открытого и закрытого ключа
Пара открытого и закрытого ключей составляет учетную запись Nostr. В отличие от традиционной системы имени пользователя и пароля, учетные записи Nostr используют систему открытого и закрытого ключей, аналогичную криптовалютам. Для простоты открытый ключ можно рассматривать как имя пользователя, а закрытый ключ как пароль. Важно отметить, что потеряв закрытый ключ, его нельзя сбросить, как пароль. Открытые ключи предварительно обозначены как npub1, а закрытые ключи как nsec1. Важно обеспечить безопасное хранение этих ключей, поскольку их нельзя восстановить при потере.
Клиент
Nostr - протокол для отправки информации через интернет, требующий клиентского программного обеспечения для использования. Клиенты могут быть веб-страницами, настольным программным обеспечением или мобильными приложениями. Клиенты читают информацию с ретрансляторов и отправляют вновь сгенерированные данные на ретрансляторы для чтения другими клиентами. Информация включает в себя подписи, чтобы гарантировать, что данные отправлены аутентичным отправителем. Клиент использует закрытый ключ для создания подписей. При использовании настольного или мобильного клиента в первый раз закрытый ключ должен быть в нем сохранен. Публичный ключ можно получить из закрытого ключа. Для веб-клиентов не рекомендуется напрямую сохранять закрытый ключ в них; вместо этого лучше использовать плагин для сохранения закрытого ключа.
Реле
Реле можно понимать как бэкэнд-серверы протокола Nostr. Клиенты Nostr отправляют информацию на реле, которое может (или не может) хранить информацию и транслировать ее всем подключенным клиентам. Важно отметить, что реле не постоянны; они могут значительно измениться со временем. Протокол Nostr полагается на реле для хранения и извлечения данных. Если пользователь испытывает медленные скорости клиента, это может быть вызвано медленной скоростью подключенного реле, и он может рассмотреть возможность добавления других реле.
NIPs
NIP (Nostr Implementation Possibilities) - это стандарты, используемые для регулирования релеев и клиентского программного обеспечения, совместимых с Nostr, определяющие, что должно быть реализовано, что следует реализовать и что можно было бы реализовать. «NIP» относится к справочным документам, описывающим принципы работы протокола Nostr. Nostr - это децентрализованный протокол, не монополизированный какой-либо централизованной сущностью (например, Twitter), что означает, что его направление развития зависит от всех участников. Мы можем предлагать и отстаивать изменения, а также давать обратную связь по поводу идей других. В качестве активных участников сообщества протокола у каждого есть определенное мнение о дальнейшем направлении развития сети Nostr. NIP в основном кодовой базе были утверждены, и новые идеи могут быть добавлены через запросы на включение изменений.
Ключевые NIP включают:
NIP-04: Шифрование сообщений с использованием алгоритма secp256k1 для обмена ключами Диффи-Хеллмана, обеспечивающее конечное шифрование.
NIP-05: Сопоставляет открытые ключи с доменными именами для легкого запоминания, например, сопоставление открытого ключа автора с @NomandJamesдомен.
NIP-06: Мнемонические фразы, аналогичные тем, которые используются в кошельках криптовалют.
NIP-13: Proof of Work. Этот концепт существовал задолго до появления Биткойна и широко используется в слоях консенсуса POW блокчейна и протоколе whisper Ethereum. Он включает в себя завершение вычислительно интенсивного доказательства работы перед отправкой сообщения, которое проверяет сервер ретрансляции получателя. Предоставление этого доказательства означает расход вычислительной мощности, повышая порог для спама ретрансляции мусорными сообщениями.
NIP-22: Метки времени сообщений. Уведомление ретрансляционных серверов о времени создания сообщения, позволяющее ретрансляторам выборочно принимать сообщения. Метки времени могут быть установлены для прошлого или будущего.
NIP-40: Время истечения. Уведомление реле-серверов о том, когда сообщение истекает, чтобы его можно было удалить.
NIP-57: молниеносные сети для чаевых.
NIP-65: Рекомендуемый список сервисов ретрансляции.
События - это единственное Объект
структуру на Nostr. Каждое событие имеет добрый
для указания типа события (какое действие совершил пользователь или какую информацию получил).
Протокол Nostr работает через ретрансляторы. Эти ретрансляторы позволяют пользователям на том же ретрансляторе отправлять друг другу файлы Json.
Чтобы помочь понять это, рассмотрим упрощенную диаграмму:
На диаграмме изображены 3 реле и 3 клиента, каждый клиент использует различную платформу.
На этой схеме:
Боб может видеть все твиты Алисы, но ни один из Мэри (Боб даже не знает о существовании Мэри).
Алиса может видеть все твиты Боба, но ни один из Мэри (Алиса также не знает о существовании Мэри).
Мэри может видеть твиты как от Боба, так и от Алисы, потому что она пишет данные только в Реле 3, но может читать данные из Реле 2 (которое содержит данные Боба и Алисы).
Учитывая протокол Nostr как очень легкий открытый протокол, он предоставляет набор спецификаций протокола для децентрализованных платформ социальных медиа. Давайте проведем простой анализ кода протокола:
Основой протокола является сервер WebSocket (известный как nostr-relay), который обрабатывает и хранит очень простую структуру данных, называемую Событие. Она показана следующим образом:
{ "id": "<32-байт SHA256 сериализованных данных о событии>", "pubkey": "<32-байтный шестнадцатеричный открытый ключ создателя события>", "created_at": "<метка времени UNIX в секундах>", "kind": "<целое число>", "tags": [ ["e", "<32-байтный шестнадцатеричный идентификатор другого события>", "<рекомендуемый URL-адрес ретранслятора>"], ["p", "<32-байтный шестнадцатеричный код ключа>", "<рекомендуемый URL-адрес ретранслятора>"], ... // другие виды тегов могут быть включены позже ], "content": "<произвольная строка>", "sig": "<64-байтная подпись хэша sha256 сериализованных данных события, которая совпадает с полем 'id'>"}
События всегда подписываются (с использованием подписей типа Шнорра) и содержат структурированные данные, которые могут иметь различные семантические значения. Тип XOnlyPubkeys Шнорра, определенный в BIP340 (в настоящее время используется с Bitcoin Taproot), используется как «идентификаторы» на протяжении всего протокола.
Nostr-клиент - это приложение, которое может взаимодействовать с nostr-реле и использовать подписчиков для подписки на любой набор событий.
Фильтры представляют собой набор всех событий Nostr, в которых заинтересован клиент.
Клиентам не нужно регистрироваться или создавать учетные записи, поскольку клиент использует открытый ключ пользователя для идентификации. Каждый раз, когда клиент подключается к ретранслятору, он отправляет фильтр подписки пользователя, и пока они подключены, ретранслятор будет передавать "события интереса" клиенту.
Реле могут кэшировать подписки клиентов, но это не обязательно. Клиенты должны обрабатывать все на «стороне клиента», в то время как реле могут быть тупыми как камень.
Клиенты не общаются друг с другом. Но Реле могут. Это позволяет реле получать данные для клиента, которых у него нет, и клиенты могут подписываться на события вне реле, к которому они подключены.
На первый взгляд это создает впечатление, что Nostr в качестве протокола бесполезен (почему бы просто не подписать и не выкинуть сырой JSON, пусть клиент разбирается?), но более глубокий анализ показывает, что модель «глупый сервер, умный клиент» может обнаружить некоторые значительные преимущества в проектировании децентрализованного протокола.
Nostr служит протокольным уровнем для социальных приложений, передающих Заметки и другие материалы через Ретрансляторы без использования каких-либо централизованных серверов. Полная децентрализация позволяет любому приложению свободно получать доступ через распределенную сеть, обеспечивая открытую и не требующую разрешения социальную платформу. Поэтому Nostr не предлагает прямого потребителю продукт для пользователей, а сосредотачивается на реализации необходимой социальной инфраструктуры на уровне протокола. Возможность продуктивного использования обеспечивается сторонними приложениями, и пользователи различных приложений могут взаимодействовать социально друг с другом.
Преимущество Nostr заключается в том, что он предоставляет по-настоящему свободную и открытую социальную сеть, не подверженную влиянию и угрозе со стороны какой-либо централизованной власти или интересов. Пользователи могут свободно выражать свое мнение и убеждения, не опасаясь цензуры, банов или деплатформинга; Создатели контента могут свободно устанавливать свои модели мотивации, не беспокоясь о том, что их лишат дохода или столкнутся с недобросовестной конкуренцией. Пользователи Nostr также могут свободно выбирать круг общения, не опасаясь манипуляций, дезинформации или нарушения конфиденциальности.
Nostr существенно отличается от традиционных социальных медиа и имеет следующие особенности и преимущества:
Децентрализация: Nostr не полагается на централизованные серверы или платформы, а вместо этого использует сеть Bitcoin для передачи и хранения информации. Это обеспечивает пользователям отсутствие необходимости беспокоиться о краже данных, цензуре или удалении, а также отсутствие подчинения правилам или политике каких-либо третьих сторон.
Автономия: Nostr позволяет пользователям контролировать свои собственные данные и личность. Пользователи могут свободно выбирать, кого они хотят следовать и кому доверять, а также выражать свои взгляды и идеи без страха быть забаненными, заблокированными или пониженными, и без страданий от рекламы или вмешательства рекомендуемого контента. Подтверждаемость определенных пользователей также облегчает идентификацию спама и контента, созданного ботами.
Открытость: Nostr - это открытый протокол, в который может вступить и внести свой вклад любой желающий. Пользователи могут разрабатывать и использовать различные клиенты, а также создавать и запускать собственные узлы (серверы, способные пересылать и хранить информацию Nostr). Пользователи также могут создавать и использовать различные типы и метки, которые являются метаданными, используемыми для дифференциации и категоризации информации Nostr. Просто и гибко.Событие
Формат поддерживает различные типы публикаций: посты в социальных сетях, длинные материалы, мультимедиа, электронную коммерцию и т. д. Более того, интеграция Nostr с Lightning Network облегчила новую модель бизнеса стоимость-за-стоимость, более справедливую.
Управление закрытым ключом
Протокол Nostr использует открытые и закрытые ключи для учетных записей, требуя от пользователей правильно управлять своими закрытыми ключами. Потеряв их, восстановить закрытый ключ невозможно. Это может стать вызовом для большинства пользователей, у которых может не хватать технических знаний и опыта для безопасного управления закрытыми ключами.
Выбор реле
В протоколе Nostr пользователи должны выбирать и проверять ретрансляторы самостоятельно. Выбор ненадежного или злонамеренного ретранслятора может привести к утечке, подмене или удалению их информации.
Распространение информации
В протоколе Nostr информация, отправленная пользователями, не распространяется через несколько реле. Это означает, что если их информация не будет получена и сохранена достаточным количеством реле, она может быть потеряна или остаться незамеченной другими пользователями, усугубляя проблему информационных силосов.
Хранилище дискреционной информации Реле
Реле в протоколе Nostr вольно решают, получать и хранить информацию пользователей или нет. Это может привести к тому, что некоторые реле выберут получать и хранить только ту информацию, которую они считают ценной или соответствующей их интересам, игнорируя или отвергая другую информацию.
Злонамеренные протокольные расширения
В то время как протокол Nostr определяет некоторые основные типы событий и функциональные возможности, он также позволяет клиентам и ретрансляторам выборочно реализовывать дополнительные функции. Это может привести к реализации небезопасных или вредоносных функций некоторыми клиентами и узлами, что повлияет на безопасность и конфиденциальность пользователей.
Обработка информации
Из-за отсутствия уровня консенсуса в протоколе Nostr некоторые ретрансляторы не обрабатывают сообщения с значительной разницей в отметках времени и времени UNIX, что оставляет возможность клиентам эксплуатировать это расхождение для подделки сообщений.
Обзор экосистемы Nostr
Джек Дорси, сооснователь Twitter и крупный сторонник протокола Nostr, пожертвовал 14,17 биткоинов (примерно 245 000 долларов) для поддержки его развития в декабре 2022 года. Его профиль X ярко демонстрирует его личный адрес Nostr, указывая на его привязанность к протоколу.
Damus⚡️: Основные приложения протокола Nostr
X:https://twitter.com/damusapp
Damus - это социальное приложение, которое поддерживает чаевые в Bitcoin через Lightning Network, заменяя обычные «Нравится» или пальцы вверх на чаевые. Низкие комиссии Lightning Network делают чаевые фактически бесплатными. Кроме Damus, приложения протокола Nostr включают инструмент коммуникации Anigma, инструмент обмена текстом Sendtr и онлайн-игру в шахматы Jeste, среди прочего.
Основной медиа-партнер Nostr Protocol: TGFB
TGFB - это христианская платформа образования по Bitcoin, направленная на обучение и подготовку христиан понимать Bitcoin и использовать его для прославления Бога и пользы человечеству. Значительная часть ее контента посвящена продвижению протокола Nostr через подкасты, ведомые Джоном и Джорданом, исследующие последствия протокола с христианской точки зрения. Комбинация христианства, широко известного в США и во всем мире, утвержденного SEC Bitcoin ETF и протокола Nostr, созданного на огромной базе пользователей Lightning Network, предполагается, что значительно способствует принятию и поддержке протокола Nostr.
Активы Nostr + Taproot
Nostr Assets Protocol — это протокол с открытым исходным кодом, который интегрирует активы Taproot и нативные платежи Bitcoin (деноминированные в сатоши) в экосистему Nostr, поддерживая взаимодействие с другими платежными протоколами, включая Lightning Network и активы Taproot.
После введения активов их можно отправлять и получать с использованием открытого и закрытого ключей протокола Nostr, причем расчеты и безопасность все еще зависят от Lightning Network. Протокол активов Nostr, хотя и построен на технологии Nostr, является отдельным протоколом, который облегчает основные транзакционные функции через сообщения Nostr.
Полная кастодиальная услуга протокола Nostr Assets включает в себя вклад пользователей их биткоинов или других активов в кошелек, управляемый протоколом, а затем выполнение инструкций по развёртыванию токенов, чеканке и передаче через сообщения Nostr.
Однако полная кастодиальная услуга вызывает споры из-за потенциальных рисков безопасности. Пользователи не могут полностью контролировать свои активы, и в случае взлома платформы или выхода обманных маневров они могут потерять все свои активы.
Более того, после запуска 30 октября Nostr столкнулся с высоким спросом на вклады в активы, что привело к частой технической обслуживанию и отключениям сайта, вызывая беспокойство относительно опыта команды и надежности проекта. 8 ноября Протокол активов Nostr официально ответил на комментарий на китайском языке в твите, при этом некоторые пользователи по-прежнему сомневаются в надежности проекта. Сообщество Nostr выразило решительное противодействие токену, связанному с этим расширением протокола.
Nostr + Надпись
Noscription - это экспериментальный токен-протокол на основе Nostr, позволяющий пользователям создавать и торговать токенами, похожими на brc-20, отличными от токенов активов Taproot.
BitVM требует чрезвычайно высоких вычислительных возможностей и в настоящее время существует только в теории. В коммерческой реализации RGB имеет значительное преимущество с уже многочисленными применениями в использовании. (Техническая организация за RGB, LNP/BP, имеет немного разработчиков и является некоммерческой, что приводит к медленному прогрессу развития). Nostr, затрудненный общими узкими местами SocialFi, также не смог продвинуть экосистему приложений своего протокола.
Защита конфиденциальности
И RGB, и BitVM выполняют вычисления вне цепи, но протокол RGB гарантирует, что сторонники не могут отслеживать историю активов RGB на блокчейне. Только когда пользователь получает актив, он узнает его историю, что невозможно сделать с помощью BitVM. Протокол Nostr, будучи социальным протоколом, имеет высокую степень неопределенности в передаче информации, что потенциально может привести к утечкам информации, блокировкам, потерям и злонамеренным вмешательствам из-за уязвимостей.
Нативная совместимость с BTC
И RGB, и BitVM не требуют внесения изменений в протокол Bitcoin; Nostr построен на родной сети Lightning Network, предлагая относительно хорошую нативную совместимость и плавный процесс разработки.
Протокол безопасности
Протокол RGB работает вне цепи в песочнице, обеспечивая безопасность данных. Его система выставления счетов также гарантирует безопасность данных с точки зрения дизайна. В контексте взаимодействия с BTC он использует механизм, аналогичный сети Lightning для выпуска активов.
BitVM использует модель Rollup, выполняя данные вне цепи, а также характеристики виртуальной машины, в сочетании с доказательствами мошенничества и моделью вызова-ответа, обеспечивают безопасность BitVM.
Nostr использует модель реле, где гениальная конструкция передачи информации между реле и алгоритмами шифрования обеспечивает безопасность информации в протоколе Nostr.
В индустрии Web3 до создания лаборатории BTC Security Lab не было специализированной лаборатории, занимающейся безопасностью экосистемы биткойна, что позволяет заполнить этот пробел за счет предоставления профессиональной безопасной поддержки и исследований для экосистемы биткойна. ScaleBit и BiHelix нацелены на лидерство в области безопасности экосистемы биткойна, установление стандартов безопасности для отрасли и поощрение здорового развития экосистемы.
Экосистема и Коммерциализация
Как социальный протокол, Nostr превосходит как BitVM, так и RGB по числу пользователей и популярности трафика, что делает его экосистему протокола более всесторонней и приложение более коммерческим, чем у других двух.
Протокол RGB существует уже некоторое время, и многие проекты в настоящее время ожидают выпуска RGB V0.11.
BitVM вышел всего несколько месяцев назад, и его экосистема все еще находится в стадии развития.
Будущее этих трех протоколов ожидается породить многочисленные Dapps в областях SocialFi, GameFi и DeFi, принося новую волну популярности в экосистему BTC.
Особая благодарность Ausdin.eth, 0xLayman, Echo, Venus за их вклад в этот отчет.
RGB - это масштабируемый и конфиденциальный протокол умных контрактов, применимый к биткоину и сети Lightning, разработанный Ассоциацией стандартов LNP/BP. Он принимает концепции частной и совместной собственности, предлагая тьюринг-полное, доверительное форму распределенных вычислений без необходимости в блокчейне, работающую как система умных контрактов с частичным состоянием, подтверждаемым клиентом.
История протокола RGB
RGB был изначально задуман Джакомо Цукко из BHB Network в 2016 году как "система активов, не основанная на блокчейне". В том же году Питер Тодд представил концепции одноразовых печатей и клиентской проверки. Вдохновленный этими идеями, RGB был предложен в 2018 году. В 2019 году ведущую роль в разработке кода RGB и проектировании основных стандартов взял на себя главный разработчик Максим Орловский. Максим Орловский и Джакомо Цукко основали ассоциацию стандартов LNP/BP.https://www.lnp-bp.org) чтобы перевести RGB от концепции к применению, получив поддержку от Fulgur Ventures, Bitfinex, Hojo Foundation, Pandora Prime и DIBA. После длительной разработки RGB выпустил свою первую стабильную версию, V0.10, в апреле 2023 года. В январе 2024 года основные разработчики RGB объявили, что версия V0.11 будет выпущена в начале первой половины года.
Последние события в протоколе RGB
Новые функции RGB V0.10 были тщательно проанализированы в других отчетах. В то время как V0.11 еще не был официально выпущен, вот некоторые из последних разработок от разработчиков и сообщества:
Предстоящая поддержка L-BTC
Обновления по взаимодействию и мостам между RGB-активами и Жидкими активами
Однако RGB V0.11 будет несовместим с V0.10, что приведет к значительным затратам на миграцию для текущих проектов. Кроме того, из-за медленного прогресса разработки многие проекты в настоящее время ждут выпуска V0.11.
Умные контракты RGB используют клиентскую проверку, что означает, что все данные хранятся за пределами транзакций Bitcoin, то есть на блокчейне Bitcoin или в состоянии каналов Lightning. Это позволяет системе работать поверх Lightning Network без изменений в основной сети BTC или протоколах Lightning Network, положив основу для масштабируемости и конфиденциальности протокола.
RGB использует одноразовые печати, определенные на выходах UTXO Bitcoin, обеспечивая каждому, кто имеет запись истории состояния смарт-контракта, возможность проверить его уникальность. Другими словами, RGB использует скрипты Bitcoin для реализации своей модели безопасности и определения прав собственности и доступа.
RGB - это направленный ациклический граф (DAG) переходов состояний, где контракты полностью изолированы друг от друга, и никто не знает о их существовании, кроме владельцев контрактов (или тех, кому владелец раскрывает информацию о контракте).
Орграф с обратной связью (DAG) - это специальная структура графа, которая может ярко объяснить сложные системы или отношения. В DAG каждое ребро можно рассматривать как улицу с односторонним движением в городе, что представляет собой "направленный" аспект графа. Предположим, в этой сети улиц, как бы вы ни путешествовали, невозможно вернуться к начальной точке и образовать замкнутый контур; это представляет собой "несвязанный" характер графа. В DAG нет последовательности узлов, которая позволяет вам начать с одного узла, пройти через ряд рёбер и вернуться к тому же узлу.
Применяя этот концепт к системе RGB, каждый контракт можно рассматривать как узел в графе, а отношения между контрактами (например, передача собственности) можно рассматривать как направленные ребра. Эта структура обеспечивает четкость и порядок отношений между контрактами, без образования замкнутых циклов, что означает, что контракт не может напрямую или косвенно влиять на себя.
Этот дизайн обеспечивает уникальность и неизменность обязательств в передаче состояния, предотвращая двойные расходы и обеспечивая эффективные и последовательные переходы состояний.
После понимания основных принципов архитектурного дизайна RGB давайте посмотрим на часть контракта. В текущем мире смарт-контрактов создателям требуется самостоятельно организовать или выполнить разработку кода смарт-контракта. Философия дизайна RGB считает эту практику нежелательной, что приводит к более высоким уязвимостям кода контракта и многочисленным хакерским атакам. Поэтому RGB нацелен на снижение риска уязвимостей в разработке и потребности в аудитах путем введения концепции «Схематических шаблонов». «Схематические шаблоны» представляют собой фактический код смарт-контрактов. Издатели могут использовать их в качестве «шаблонов контрактов», не нуждаясь в написании кода или аудите на заказной код, написанный для них каким-то случайным подрядчиком.
Контракты RGB определяются декларативно, а не императивно. Это означает, что логика контракта не определяется серией команд или шагов, а набором правил, описывающих его поведение и переходы состояний, формирующих направленный ациклический граф (DAG) изменений состояний. Ключом к локальным операциям с состоянием является схема. Операции в контрактах RGB локальны, а не глобальны. Каждый узел (или состояние) имеет свои правила и отвечает только за свои переходы состояний. Это отличается от глобальных алгоритмов на платформах, таких как Ethereum, где каждое состояние должно следовать одному и тому же алгоритму. Эта характеристика делает RGB достаточно гибким и масштабируемым, обеспечивая при этом хорошую интероперабельность.
Схема определяет, какие типы глобальных и собственных состояний, печатей и метаданных допускаются при переходе состояний. RGB использует язык Contractum для написания схем RGB и AluVM (виртуальная арифметическая логическая машина), упрощая написание умных контрактов RGB. AluVM основан на регистровом дизайне без случайного доступа к памяти, что делает его очень подходящим для умных контрактов, удаленного выполнения кода, распределенных и краевых вычислений, обеспечивая основу для различных продвинутых случаев использования умных контрактов.
От самого дизайна RGB:
Приватность без глобального вещания: Как упоминалось, клиентская проверка RGB означает, что процесс проверки происходит только между непосредственно затронутыми участниками, а не на всей сети. Данный подход к проверке без глобального вещания повышает уровень конфиденциальности и устойчивость к цензуре, поскольку детали состояния контракта видны только соответствующим участникам, а майнеры не могут видеть детали транзакции.
Конфиденциальность данных в песочнице: с другой стороны, RGB сохраняет все данные операций в куче. Поскольку RGB не основан на блокчейне, хранение не реплицируется на другие узлы пиров. Хранение, контролируемое локально пользователями, снижает риск внешних атак и утечек данных, обеспечивая конфиденциальность данных. RGB - это вычислительная платформа, где каждая программа («умный контракт») изолирована в своей среде песочницы, обеспечивая лучшую масштабируемость и безопасность по сравнению с платформами, основанными на блокчейне. Однако оффчейн-данные также означают риск потери.
Помимо проверки и хранения, система выставления счетов также обеспечивает безопасность и конфиденциальность. Операции с контрактами в RGB осуществляются путем создания счетов, которые могут содержать несколько запросов на операции с контрактом. Позволяя пользователям явно указывать и проверять операции с контрактами, улучшается точность и безопасность операций. В то же время система выставления счетов поддерживает конфиденциальную передачу запросов на операции с контрактом между пользователями, улучшая конфиденциальность транзакций. Переходы состояний, такие как передачи токенов, выполняются через счета и конкретные команды.
Дизайн RGB тесно связан с UTXO. Во взаимодействии с основной сетью BTC пользователи создают контракты вне цепи для выпуска активов RGB и их выделения в UTXO Bitcoin, аналогично Lightning Network. После этого передачи активов, контрактные взаимодействия и проверки выполняются вне цепи, как было представлено выше.
RGB получает выгоду от улучшенных протоколов мультиподписи, протоколов подписи на основе адаптеров и контрактов времени блокировки точки (PTLCs), предоставленных подписями Шнорра, но ее преимущества основаны исключительно на биткоинах (т.е. косвенно). В RGB нет ничего, что требовало бы подписей (поэтому Шнорр не вносит внутренних изменений), ни оно не использует скрипты биткоина (поэтому новый Tapscript бесполезен).
BTC Security Lab, основанная ScaleBit, - это специализированная лаборатория по безопасности BTC, работающая над последними разработками протокола RGB. Ее целью является защита безопасности контрактов, совместное продвижение непрерывного роста и укрепления протокола RGB и инфраструктурного строительства экосистемы BTC.
BiHelix
Веб-сайт: https://www.bihelix.net/
BiHelix - инфраструктура биткойн-экосистемы, оптимизированная для узлов, построенная на собственной цепочке блоков биткойна, включающая протокол RGB и молниеносную сеть. Ее цель - упростить разработку, расширить область применения биткойна и решить проблемы масштабируемости и тьюринг-неполноты, с которыми сталкивается цепочка блоков биткойна. BiHelix стремится создать более справедливый децентрализованный криптографический мир для майнеров, валидаторов, провайдеров услуг узлов, бирж и пользователей. Будучи первой инфраструктурой, построенной на протоколе RGB, BiHelix разработает следующее поколение крупномасштабных сценариев применения биткойна. Проект в настоящее время находится в стадии разработки и еще не открыт для взаимодействия; следите за обновлениями.
Особенности проекта
Порог низкого уровня пользователей: использует протокол SLR (Security-Lightning-RGB), переупаковывая RGB и Lightning Network с инновационными решениями для узлов молнии, чтобы достичь универсальных платежей.
Высокая надежность и масштабируемость: использует зрелую архитектуру облачных служб, полностью используя функции руст-молнии для поддержки функций фабрики каналов, эффективного управления каналами и создания каналов оптом.
Защита безопасности и конфиденциальности: передача и хранение данных состояния вне цепи, использование рекурсивных доказательств нулевого знания среди прочих технологий для рандомизации многопартийных платежей и выбора пути для защиты конфиденциальности.
Удобный для разработчиков : Предоставляет полный набор инструментов разработки, включая документацию с открытым исходным кодом, инструменты и т. д., и представляет механизм социального консенсуса Schema, что облегчает создание приложений разработчикам.
Кошелек Iris
Веб-сайт: https://play.google.com/store/apps/details?id=com.iriswallet.testnet&pli=1
IRIS Wallet, первый кошелек для Android, разработанный командой Bitfinex, посвященный интеграции RGB и инструментам, связанным с RGB, поддерживающий обращаемые и необращаемые активы. Кошелек Iris позволяет осуществлять операции с активами RGB от выпуска до траты и получения, упаковывая все функциональные возможности в знакомом приложении для кошелька, абстрагируясь от максимально возможного количества технических деталей. В настоящее время это экспериментальное приложение, рекомендуемое для небольших сумм биткойнов и активов низкой стоимости.
DIBA
Веб-сайт: https://diba.io/
DIBA - первая биржа NFT на Bitcoin, использующая протокол RGB и Lightning Network. Она нацелена на формирование понимания неохраняемых художественных активов на блокчейне Bitcoin.
Битовая маска
Веб-сайт: https://bitmask.app/
Созданный DIBA, Bitmask - первый кошелек NFT в экосистеме RGB, работает в веб-браузерах и взаимодействует с RGB контрактами, аналогично MetaMask на Ethereum. В настоящее время часто обновляется, ожидая выпуска V0.11.
Pandora Prime Inc
Вебсайт: https://pandoraprime.ch/
Расположенный в Долине Verify, Швейцария, Pandora Prime также является учредителем LNP/BP. Pandora Prime посвятил себя пионерству в Bitcoin Finance с использованием комбинации RGB смарт-контрактов и Lightning Network. Они начинают с программных активов на Bitcoin (RGBTC и CHFN), которые могут масштабировать пропускную способность транзакций до уровня VISA/MasterCard через Lightning Network, предоставляя при этом возможности для простого обмена этими активами. Их продуктами являются MyCitadel (кошелек), RGB Explorer (браузер) и Pandora Network, среди прочего.
MyCitadel
Веб-сайт: https://mycitadel.io/
Бренд Pandora Prime, MyCitadel - первый графический кошелек, поддерживающий RGB, созданный разработчиками RGB в 2021 году. Он предлагает кроссплатформенные настольные кошельки и кошельки для iOS/iPad. Мобильный кошелек может обрабатывать средства RGB.
RGB Explorer
Веб-сайт: https://rgbex.io/
Разработанный компанией Pandora Prime, RGB Explorer является первым браузером, предлагающим регистрацию RGB-активов и смарт-контракты. В настоящее время он поддерживает RGB 20, RGB 21, RGB 25, отображая активы, такие как LNPBP, RGBTC, dCHF и RGBEX.
Лаборатории Bitlight (ранее Cosminmart)
Веб-сайт: https://bitlightlabs.com/
Компания Bitlight Labs разрабатывает инфраструктуру на основе протокола RGB, готовясь к развертыванию нескольких приложений в сети Lightning, включая кошелек Bitlight для утилиты RGB и Bitswap, автоматизированный рыночный создатель для BitcoinFi в сети Lightning и протоколе RGB.
PPRGB
X: @PepeRgb20
PPRGB в настоящее время выпускается в сети Liquid, в ожидании сопоставления с RGB после выпуска RGB V0.11 (V0.11 также разрабатывает функции кода для взаимодействия с Liquid).
Надпись MRGB
Одноразовый пломбир
Seal, это коллекция из 10k PFP, редких UDA и токенов на RGB20 и RGB21, названная в честь концепции Single Use Seal Питера Тодда. В настоящее время ожидается обновление кошельков Bitlight и Bitmask до версии v0.11 RGB, после чего они будут выпущены на них.
Битман
X: @bitmancity
Выпустит 10 тыс. UDA на diba, возможно, через wl+публичную продажу, с миссией "передачи духа BTC". Проект имеет похвальную цель и будет предоставлять wl участникам экосистемы BTC, причем большая часть выручки от публичной продажи будет пожертвована в LNP/BP.
BitVM (Bitcoin Virtual Machine) вводит систему, которая позволяет проверять любые вычисления на блокчейне биткоина без ущерба для его безопасности или изменения сети. Это развитие открывает двери для сложных вычислений, таких как умные контракты полного исполнения Тьюринга, при обработке всех вычислений за пределами цепи, чтобы снизить перегрузку на блокчейне биткоина.
“Простыми словами, BitVM - это вычислительная модель, способная выражать контракты, полностью совместимые с машиной Тьюринга, в сети Bitcoin.” Как и RGB, BitVM не требует модификаций правил консенсуса сети.
9 октября 2023 года Робин Линус, сооснователь разработчика блокчейнов ZeroSync, опубликовал белую книгу BitVM. По сравнению с RGB, BitVM гораздо моложе.
Архитектура
Подобно Оптимистичным Роллапам и предложению Merkelize All The Things (MATT), основанному на доказательствах мошенничества и протоколах вызова-ответа, это не требует изменений в правилах консенсуса Биткоина. BitVM демонстрирует, что Биткоин является полностью универсальным, кодируя доказательства мошенничества внутри больших Taptrees.
Дизайн воротной схемы
Обязательство по значению бита - самый базовый компонент, позволяющий инициатору установить значение конкретного бита на «0» или «1». Любая вычислимая функция может быть представлена в виде булевой цепи, формируя обязательства логических ворот. Составленные с использованием ворот NAND (универсальных логических ворот), каждое ворото имеет свое собственное обязательство. Любая цепь может быть выражена путем объединения обязательств ворот. Каждый шаг выполнения фиксируется в Tapleaf и объединяется в одном и том же адресе Taproot.
BitVM использует обновление Taproot Bitcoin, создавая структуру, аналогичную бинарной схеме (называемой taptree), чтобы достичь своей функциональности. В этой системе условия траты для каждого UTXO, представленные инструкциями в сценарии, формируют основную единицу программы. Эти инструкции генерируют двоичные выходы (0 или 1) в адресе Taproot, тем самым строя всю taptree. Результат taptree можно рассматривать как результат выполнения двоичной схемы, подобно исполняемой программе. Сложность программ, которые может выполнить taptree, зависит от количества и сложности адресов Taproot, составляющих ее. Короче говоря, BitVM реализует возможность запуска более сложных программ в сети Bitcoin, переводя инструкции сценария Bitcoin в двоичные операции.
Участвующими ролями являются две стороны
В настоящее время модель ограничивается двумя сторонами и не может быть расширена для включения большего количества участников. Более того, для правильной работы BitVM требуется большое количество предварительных подписей (вычислений вне цепи), что делает BitVM довольно сложным и потенциально неэффективным.
Доказательства мошенничества и протокол challenge-response
И доказатель и вызывающий внесут равное количество BTC в транзакцию как ставку (в качестве входных данных), и результатом этой транзакции будет логическая схема. Во время установочной фазы предварительно подписывается ряд транзакций для опровержения неверных утверждений. BitVM уподобляется Оптимистичным Rollups, потому что основная часть вычислений производится вне цепи и некоторые из этих вычислений представляются на цепи для разрешения споров в случае их возникновения.
Оптимистичные Rollups - это решение масштабирования второго уровня, которое снижает нагрузку на базовый уровень за счет перемещения вычислений и хранения данных вне цепи. Затем он объединяет несколько транзакций и публикует их в основной цепи. Оптимистичные Rollups предполагают, что все транзакции действительны. Однако, если участники сети замечают нечестное поведение, они могут инициировать доказательство мошенничества. Доказательство мошенничества - это доказательство неточных вычислений кого-то. Они производятся после проверки.
Вычисления вне цепи
Почти вся деятельность на BitVM ведется вне блокчейна. Это включает в себя инициирование вычислительных задач, обмен данными и проверку отправленных заявок. BitVM обычно не выполняет вычисления в блокчейне Биткойна. Вычисления и проверки публикуются в блокчейне только в случае возникновения спора из-за подозрений в мошенничестве. Однако, если возникает спор, небольшая часть процесса спора действительно проходит в блокчейне, и этого достаточно, чтобы определить, какая сторона является нечестной.
Имея вышеперечисленные знания, мы можем лучше понять конкретные принципы взаимодействия двух сторон в BitVM.
Двухсторонняя модель взаимодействия BitVM включает в себя доказывающего и проверяющего. В этой системе доказывающий сначала создает и отправляет смарт-контракт или программу, затем отправляет средства на совместно контролируемый мастер-адрес корневого узла. Эти средства хранятся в 2 из 2 мультисигнатурном распоряжении. Доказывающему также необходимо предоставить достаточно информации проверяющему, чтобы доказать, что их программа может произвести обещанный результат.
Задача верификатора - запустить код доказывающего и проверить, соответствует ли вывод ожиданиям. Если вывод не соответствует, верификатор вызовет доказывающего. Этот процесс взаимодействия вызов-ответ включает обмен данными вне цепи и использование предварительно подписанных транзакций для проверки правильности вычислений.
Если обнаружена вычислительная ошибка, верификатор может публично доказать нечестное поведение доказывающего с помощью доказательства мошенничества на цепи. В системе BitVM, если доказывающий ответ оказывается неверным, он проиграет ставку и утратит средства. Напротив, если все ответы верны, доказывающий сохраняет свои средства. Этот экономический стимулирующий механизм разработан для предотвращения нечестного поведения.
В конечном итоге эта взаимодействие гарантирует, что вычислительная проверка передается на блокчейн Bitcoin только в случае спора, тем самым выполняя подавляющее большинство вычислений вне цепи. Такая конструкция обеспечивает эффективность сети Bitcoin, предоставляя возможность запускать более сложные программы на Bitcoin.
Безопасность BitVM
С точки зрения архитектурного дизайна, безопасность BitVM в основном основана на следующих аспектах:
Доказательства мошенничества
В случае спора валидаторы могут оспаривать неправильные утверждения предложившего через доказательства мошенничества. Этот механизм аналогичен Оптимистичным Rollups и не требует изменения правил консенсуса Биткоина.
Протокол Challenge-Response
BitVM использует протокол «запрос-ответ», в котором инициаторы и валидаторы заранее подписывают ряд транзакций на этапе настройки протокола. Эти транзакции используются для решения вопросов при возникновении спора.
Вычисление вне цепи с верификацией в цепи
BitVM позволяет выполнять сложные вычисления вне цепи, в то время как верификация и разрешение происходят только в цепи в случае спора. Такой подход снижает потребление ресурсов цепи, сохраняя при этом целостность и безопасность блокчейна Bitcoin.
Механизм депозита и штрафов
Если претендент делает неверное заявление, валидаторы могут конфисковать его депозит. Этот механизм гарантирует, что злоумышленники всегда теряют свой депозит за неправомерные действия.
Механизм двусторонних контрактов
Этот механизм обеспечивает лучшую конфиденциальность на БитVM и снижает транзакционные издержки, но по сравнению с многопартийным механизмом EVM его универсальность немного снижается.
Что такое протокол Nostr
Nostr означает "Примечания и другие материалы, передаваемые ретрансляторами", что указывает на то, что это протокол передачи, включающий ретрансляторы, что свидетельствует о том, что это не протокол передачи от равных к равным (P2P). Согласнокод GitHubобновить записи, этот проект был запущен в ноябре 2020 года. Протокол нацелен на создание самого простого открытого протокола для цензуроустойчивой глобальной социальной сети. Это децентрализованный социальный протокол, который позволяет пользователям создавать, публиковать и подписываться на любой тип контента без контроля или вмешательства со стороны каких-либо централизованных платформ или учреждений. Nostr черпает вдохновение из Bitcoin и сети Lightning, используя аналогичные криптографические и консенсус-механизмы, а также структуру данных на основе событий, известную как сеть Nostr.
Пара открытого и закрытого ключа
Пара открытого и закрытого ключей составляет учетную запись Nostr. В отличие от традиционной системы имени пользователя и пароля, учетные записи Nostr используют систему открытого и закрытого ключей, аналогичную криптовалютам. Для простоты открытый ключ можно рассматривать как имя пользователя, а закрытый ключ как пароль. Важно отметить, что потеряв закрытый ключ, его нельзя сбросить, как пароль. Открытые ключи предварительно обозначены как npub1, а закрытые ключи как nsec1. Важно обеспечить безопасное хранение этих ключей, поскольку их нельзя восстановить при потере.
Клиент
Nostr - протокол для отправки информации через интернет, требующий клиентского программного обеспечения для использования. Клиенты могут быть веб-страницами, настольным программным обеспечением или мобильными приложениями. Клиенты читают информацию с ретрансляторов и отправляют вновь сгенерированные данные на ретрансляторы для чтения другими клиентами. Информация включает в себя подписи, чтобы гарантировать, что данные отправлены аутентичным отправителем. Клиент использует закрытый ключ для создания подписей. При использовании настольного или мобильного клиента в первый раз закрытый ключ должен быть в нем сохранен. Публичный ключ можно получить из закрытого ключа. Для веб-клиентов не рекомендуется напрямую сохранять закрытый ключ в них; вместо этого лучше использовать плагин для сохранения закрытого ключа.
Реле
Реле можно понимать как бэкэнд-серверы протокола Nostr. Клиенты Nostr отправляют информацию на реле, которое может (или не может) хранить информацию и транслировать ее всем подключенным клиентам. Важно отметить, что реле не постоянны; они могут значительно измениться со временем. Протокол Nostr полагается на реле для хранения и извлечения данных. Если пользователь испытывает медленные скорости клиента, это может быть вызвано медленной скоростью подключенного реле, и он может рассмотреть возможность добавления других реле.
NIPs
NIP (Nostr Implementation Possibilities) - это стандарты, используемые для регулирования релеев и клиентского программного обеспечения, совместимых с Nostr, определяющие, что должно быть реализовано, что следует реализовать и что можно было бы реализовать. «NIP» относится к справочным документам, описывающим принципы работы протокола Nostr. Nostr - это децентрализованный протокол, не монополизированный какой-либо централизованной сущностью (например, Twitter), что означает, что его направление развития зависит от всех участников. Мы можем предлагать и отстаивать изменения, а также давать обратную связь по поводу идей других. В качестве активных участников сообщества протокола у каждого есть определенное мнение о дальнейшем направлении развития сети Nostr. NIP в основном кодовой базе были утверждены, и новые идеи могут быть добавлены через запросы на включение изменений.
Ключевые NIP включают:
NIP-04: Шифрование сообщений с использованием алгоритма secp256k1 для обмена ключами Диффи-Хеллмана, обеспечивающее конечное шифрование.
NIP-05: Сопоставляет открытые ключи с доменными именами для легкого запоминания, например, сопоставление открытого ключа автора с @NomandJamesдомен.
NIP-06: Мнемонические фразы, аналогичные тем, которые используются в кошельках криптовалют.
NIP-13: Proof of Work. Этот концепт существовал задолго до появления Биткойна и широко используется в слоях консенсуса POW блокчейна и протоколе whisper Ethereum. Он включает в себя завершение вычислительно интенсивного доказательства работы перед отправкой сообщения, которое проверяет сервер ретрансляции получателя. Предоставление этого доказательства означает расход вычислительной мощности, повышая порог для спама ретрансляции мусорными сообщениями.
NIP-22: Метки времени сообщений. Уведомление ретрансляционных серверов о времени создания сообщения, позволяющее ретрансляторам выборочно принимать сообщения. Метки времени могут быть установлены для прошлого или будущего.
NIP-40: Время истечения. Уведомление реле-серверов о том, когда сообщение истекает, чтобы его можно было удалить.
NIP-57: молниеносные сети для чаевых.
NIP-65: Рекомендуемый список сервисов ретрансляции.
События - это единственное Объект
структуру на Nostr. Каждое событие имеет добрый
для указания типа события (какое действие совершил пользователь или какую информацию получил).
Протокол Nostr работает через ретрансляторы. Эти ретрансляторы позволяют пользователям на том же ретрансляторе отправлять друг другу файлы Json.
Чтобы помочь понять это, рассмотрим упрощенную диаграмму:
На диаграмме изображены 3 реле и 3 клиента, каждый клиент использует различную платформу.
На этой схеме:
Боб может видеть все твиты Алисы, но ни один из Мэри (Боб даже не знает о существовании Мэри).
Алиса может видеть все твиты Боба, но ни один из Мэри (Алиса также не знает о существовании Мэри).
Мэри может видеть твиты как от Боба, так и от Алисы, потому что она пишет данные только в Реле 3, но может читать данные из Реле 2 (которое содержит данные Боба и Алисы).
Учитывая протокол Nostr как очень легкий открытый протокол, он предоставляет набор спецификаций протокола для децентрализованных платформ социальных медиа. Давайте проведем простой анализ кода протокола:
Основой протокола является сервер WebSocket (известный как nostr-relay), который обрабатывает и хранит очень простую структуру данных, называемую Событие. Она показана следующим образом:
{ "id": "<32-байт SHA256 сериализованных данных о событии>", "pubkey": "<32-байтный шестнадцатеричный открытый ключ создателя события>", "created_at": "<метка времени UNIX в секундах>", "kind": "<целое число>", "tags": [ ["e", "<32-байтный шестнадцатеричный идентификатор другого события>", "<рекомендуемый URL-адрес ретранслятора>"], ["p", "<32-байтный шестнадцатеричный код ключа>", "<рекомендуемый URL-адрес ретранслятора>"], ... // другие виды тегов могут быть включены позже ], "content": "<произвольная строка>", "sig": "<64-байтная подпись хэша sha256 сериализованных данных события, которая совпадает с полем 'id'>"}
События всегда подписываются (с использованием подписей типа Шнорра) и содержат структурированные данные, которые могут иметь различные семантические значения. Тип XOnlyPubkeys Шнорра, определенный в BIP340 (в настоящее время используется с Bitcoin Taproot), используется как «идентификаторы» на протяжении всего протокола.
Nostr-клиент - это приложение, которое может взаимодействовать с nostr-реле и использовать подписчиков для подписки на любой набор событий.
Фильтры представляют собой набор всех событий Nostr, в которых заинтересован клиент.
Клиентам не нужно регистрироваться или создавать учетные записи, поскольку клиент использует открытый ключ пользователя для идентификации. Каждый раз, когда клиент подключается к ретранслятору, он отправляет фильтр подписки пользователя, и пока они подключены, ретранслятор будет передавать "события интереса" клиенту.
Реле могут кэшировать подписки клиентов, но это не обязательно. Клиенты должны обрабатывать все на «стороне клиента», в то время как реле могут быть тупыми как камень.
Клиенты не общаются друг с другом. Но Реле могут. Это позволяет реле получать данные для клиента, которых у него нет, и клиенты могут подписываться на события вне реле, к которому они подключены.
На первый взгляд это создает впечатление, что Nostr в качестве протокола бесполезен (почему бы просто не подписать и не выкинуть сырой JSON, пусть клиент разбирается?), но более глубокий анализ показывает, что модель «глупый сервер, умный клиент» может обнаружить некоторые значительные преимущества в проектировании децентрализованного протокола.
Nostr служит протокольным уровнем для социальных приложений, передающих Заметки и другие материалы через Ретрансляторы без использования каких-либо централизованных серверов. Полная децентрализация позволяет любому приложению свободно получать доступ через распределенную сеть, обеспечивая открытую и не требующую разрешения социальную платформу. Поэтому Nostr не предлагает прямого потребителю продукт для пользователей, а сосредотачивается на реализации необходимой социальной инфраструктуры на уровне протокола. Возможность продуктивного использования обеспечивается сторонними приложениями, и пользователи различных приложений могут взаимодействовать социально друг с другом.
Преимущество Nostr заключается в том, что он предоставляет по-настоящему свободную и открытую социальную сеть, не подверженную влиянию и угрозе со стороны какой-либо централизованной власти или интересов. Пользователи могут свободно выражать свое мнение и убеждения, не опасаясь цензуры, банов или деплатформинга; Создатели контента могут свободно устанавливать свои модели мотивации, не беспокоясь о том, что их лишат дохода или столкнутся с недобросовестной конкуренцией. Пользователи Nostr также могут свободно выбирать круг общения, не опасаясь манипуляций, дезинформации или нарушения конфиденциальности.
Nostr существенно отличается от традиционных социальных медиа и имеет следующие особенности и преимущества:
Децентрализация: Nostr не полагается на централизованные серверы или платформы, а вместо этого использует сеть Bitcoin для передачи и хранения информации. Это обеспечивает пользователям отсутствие необходимости беспокоиться о краже данных, цензуре или удалении, а также отсутствие подчинения правилам или политике каких-либо третьих сторон.
Автономия: Nostr позволяет пользователям контролировать свои собственные данные и личность. Пользователи могут свободно выбирать, кого они хотят следовать и кому доверять, а также выражать свои взгляды и идеи без страха быть забаненными, заблокированными или пониженными, и без страданий от рекламы или вмешательства рекомендуемого контента. Подтверждаемость определенных пользователей также облегчает идентификацию спама и контента, созданного ботами.
Открытость: Nostr - это открытый протокол, в который может вступить и внести свой вклад любой желающий. Пользователи могут разрабатывать и использовать различные клиенты, а также создавать и запускать собственные узлы (серверы, способные пересылать и хранить информацию Nostr). Пользователи также могут создавать и использовать различные типы и метки, которые являются метаданными, используемыми для дифференциации и категоризации информации Nostr. Просто и гибко.Событие
Формат поддерживает различные типы публикаций: посты в социальных сетях, длинные материалы, мультимедиа, электронную коммерцию и т. д. Более того, интеграция Nostr с Lightning Network облегчила новую модель бизнеса стоимость-за-стоимость, более справедливую.
Управление закрытым ключом
Протокол Nostr использует открытые и закрытые ключи для учетных записей, требуя от пользователей правильно управлять своими закрытыми ключами. Потеряв их, восстановить закрытый ключ невозможно. Это может стать вызовом для большинства пользователей, у которых может не хватать технических знаний и опыта для безопасного управления закрытыми ключами.
Выбор реле
В протоколе Nostr пользователи должны выбирать и проверять ретрансляторы самостоятельно. Выбор ненадежного или злонамеренного ретранслятора может привести к утечке, подмене или удалению их информации.
Распространение информации
В протоколе Nostr информация, отправленная пользователями, не распространяется через несколько реле. Это означает, что если их информация не будет получена и сохранена достаточным количеством реле, она может быть потеряна или остаться незамеченной другими пользователями, усугубляя проблему информационных силосов.
Хранилище дискреционной информации Реле
Реле в протоколе Nostr вольно решают, получать и хранить информацию пользователей или нет. Это может привести к тому, что некоторые реле выберут получать и хранить только ту информацию, которую они считают ценной или соответствующей их интересам, игнорируя или отвергая другую информацию.
Злонамеренные протокольные расширения
В то время как протокол Nostr определяет некоторые основные типы событий и функциональные возможности, он также позволяет клиентам и ретрансляторам выборочно реализовывать дополнительные функции. Это может привести к реализации небезопасных или вредоносных функций некоторыми клиентами и узлами, что повлияет на безопасность и конфиденциальность пользователей.
Обработка информации
Из-за отсутствия уровня консенсуса в протоколе Nostr некоторые ретрансляторы не обрабатывают сообщения с значительной разницей в отметках времени и времени UNIX, что оставляет возможность клиентам эксплуатировать это расхождение для подделки сообщений.
Обзор экосистемы Nostr
Джек Дорси, сооснователь Twitter и крупный сторонник протокола Nostr, пожертвовал 14,17 биткоинов (примерно 245 000 долларов) для поддержки его развития в декабре 2022 года. Его профиль X ярко демонстрирует его личный адрес Nostr, указывая на его привязанность к протоколу.
Damus⚡️: Основные приложения протокола Nostr
X:https://twitter.com/damusapp
Damus - это социальное приложение, которое поддерживает чаевые в Bitcoin через Lightning Network, заменяя обычные «Нравится» или пальцы вверх на чаевые. Низкие комиссии Lightning Network делают чаевые фактически бесплатными. Кроме Damus, приложения протокола Nostr включают инструмент коммуникации Anigma, инструмент обмена текстом Sendtr и онлайн-игру в шахматы Jeste, среди прочего.
Основной медиа-партнер Nostr Protocol: TGFB
TGFB - это христианская платформа образования по Bitcoin, направленная на обучение и подготовку христиан понимать Bitcoin и использовать его для прославления Бога и пользы человечеству. Значительная часть ее контента посвящена продвижению протокола Nostr через подкасты, ведомые Джоном и Джорданом, исследующие последствия протокола с христианской точки зрения. Комбинация христианства, широко известного в США и во всем мире, утвержденного SEC Bitcoin ETF и протокола Nostr, созданного на огромной базе пользователей Lightning Network, предполагается, что значительно способствует принятию и поддержке протокола Nostr.
Активы Nostr + Taproot
Nostr Assets Protocol — это протокол с открытым исходным кодом, который интегрирует активы Taproot и нативные платежи Bitcoin (деноминированные в сатоши) в экосистему Nostr, поддерживая взаимодействие с другими платежными протоколами, включая Lightning Network и активы Taproot.
После введения активов их можно отправлять и получать с использованием открытого и закрытого ключей протокола Nostr, причем расчеты и безопасность все еще зависят от Lightning Network. Протокол активов Nostr, хотя и построен на технологии Nostr, является отдельным протоколом, который облегчает основные транзакционные функции через сообщения Nostr.
Полная кастодиальная услуга протокола Nostr Assets включает в себя вклад пользователей их биткоинов или других активов в кошелек, управляемый протоколом, а затем выполнение инструкций по развёртыванию токенов, чеканке и передаче через сообщения Nostr.
Однако полная кастодиальная услуга вызывает споры из-за потенциальных рисков безопасности. Пользователи не могут полностью контролировать свои активы, и в случае взлома платформы или выхода обманных маневров они могут потерять все свои активы.
Более того, после запуска 30 октября Nostr столкнулся с высоким спросом на вклады в активы, что привело к частой технической обслуживанию и отключениям сайта, вызывая беспокойство относительно опыта команды и надежности проекта. 8 ноября Протокол активов Nostr официально ответил на комментарий на китайском языке в твите, при этом некоторые пользователи по-прежнему сомневаются в надежности проекта. Сообщество Nostr выразило решительное противодействие токену, связанному с этим расширением протокола.
Nostr + Надпись
Noscription - это экспериментальный токен-протокол на основе Nostr, позволяющий пользователям создавать и торговать токенами, похожими на brc-20, отличными от токенов активов Taproot.
BitVM требует чрезвычайно высоких вычислительных возможностей и в настоящее время существует только в теории. В коммерческой реализации RGB имеет значительное преимущество с уже многочисленными применениями в использовании. (Техническая организация за RGB, LNP/BP, имеет немного разработчиков и является некоммерческой, что приводит к медленному прогрессу развития). Nostr, затрудненный общими узкими местами SocialFi, также не смог продвинуть экосистему приложений своего протокола.
Защита конфиденциальности
И RGB, и BitVM выполняют вычисления вне цепи, но протокол RGB гарантирует, что сторонники не могут отслеживать историю активов RGB на блокчейне. Только когда пользователь получает актив, он узнает его историю, что невозможно сделать с помощью BitVM. Протокол Nostr, будучи социальным протоколом, имеет высокую степень неопределенности в передаче информации, что потенциально может привести к утечкам информации, блокировкам, потерям и злонамеренным вмешательствам из-за уязвимостей.
Нативная совместимость с BTC
И RGB, и BitVM не требуют внесения изменений в протокол Bitcoin; Nostr построен на родной сети Lightning Network, предлагая относительно хорошую нативную совместимость и плавный процесс разработки.
Протокол безопасности
Протокол RGB работает вне цепи в песочнице, обеспечивая безопасность данных. Его система выставления счетов также гарантирует безопасность данных с точки зрения дизайна. В контексте взаимодействия с BTC он использует механизм, аналогичный сети Lightning для выпуска активов.
BitVM использует модель Rollup, выполняя данные вне цепи, а также характеристики виртуальной машины, в сочетании с доказательствами мошенничества и моделью вызова-ответа, обеспечивают безопасность BitVM.
Nostr использует модель реле, где гениальная конструкция передачи информации между реле и алгоритмами шифрования обеспечивает безопасность информации в протоколе Nostr.
В индустрии Web3 до создания лаборатории BTC Security Lab не было специализированной лаборатории, занимающейся безопасностью экосистемы биткойна, что позволяет заполнить этот пробел за счет предоставления профессиональной безопасной поддержки и исследований для экосистемы биткойна. ScaleBit и BiHelix нацелены на лидерство в области безопасности экосистемы биткойна, установление стандартов безопасности для отрасли и поощрение здорового развития экосистемы.
Экосистема и Коммерциализация
Как социальный протокол, Nostr превосходит как BitVM, так и RGB по числу пользователей и популярности трафика, что делает его экосистему протокола более всесторонней и приложение более коммерческим, чем у других двух.
Протокол RGB существует уже некоторое время, и многие проекты в настоящее время ожидают выпуска RGB V0.11.
BitVM вышел всего несколько месяцев назад, и его экосистема все еще находится в стадии развития.
Будущее этих трех протоколов ожидается породить многочисленные Dapps в областях SocialFi, GameFi и DeFi, принося новую волну популярности в экосистему BTC.
Особая благодарность Ausdin.eth, 0xLayman, Echo, Venus за их вклад в этот отчет.