Максим Орловский, Ассоциация стандартов LNP/BP
В статье мы предлагаем способ обновления биткойн -слоя 1 (блокчейн/TIMECHAIN) без требуемой SoftFork. Обновление использует свойства проверки на стороне клиента, может быть постепенным, имеет опцию развертывания без разрешений (т.е. не требует поддержки большинства или сотрудничества шахтеров) и будет иметь масштабируемость заказа
Слово биткойн приобрел несколько значений, поэтому мы различаем их, используя более конкретные термины. Мы используем биткойн в качестве общего зонтичного термина, обозначающего систему в целом, который может включать несколько слоев (включая какое-то будущее) и общую идею одноранговой электронной денежной системы, происходящей из Сатоши Накамото. В то же время мы используем BTC для обозначения биткойна как цифровой дефицит, денег и валюты. Мы также различаем консенсус Bitcoin POW (правило выбора следующего блок -производителя), консенсус накамото (который включает в себя консенсус POW, усиливается с помощью крипто -экономических средств наказания шахтеров), блокчейн биткойнов (альтернативно названный TimeChain ) в качестве конкретного текущего внедрения уровня биткойна 1 и и биткойн. Протокол биткойнов (BP) в качестве набора стандартов, технологий и инструментов для работы с транзакциями биткойнов в цепочке (в любом возможном уровне 1).
Первоначальная реализация биткойна Сатоши Накамото принесла странную идею, что каждому нужно проверить транзакции для всего мира. Эта идея получила имя блокчейна , или, иногда, TimeChain , которая стала эвфемизмом для бухгалтерской книги с публичным доступом. Введение в книгу создало две проблемы: отсутствие масштабируемости и плохая конфиденциальность; Первый предотвращает принятие и сетевой эффект; Другой противоречит первоначальному духу биткойна Cypherpunk и представляет собой стратегический цивилизационный риск (см. неизбежность Cypherpunk для надлежащей цивилизации и манифеста Cyphernox).
Масштабируемость и, отчасти, проблемы конфиденциальности были позже решены путем введения систем уровня 2, таких как сеть Lightning и другие предлагаемые решения. Среди них наименее плодотворной была идея боковой кости, которая унаследовала большинство (если не все) из исходных ограничений технологии блокчейна, одновременно решая только проблему низкой программируемости, создала песочницу для экспериментов и, отчасти, некоторые аспекты конфиденциальности. Lightning Network - более успешное решение уровня 2, которое уже развернуто и эксплуатируется - имеет свои собственные проблемы масштабируемости из -за необходимости чрезмерной ликвидности, ограничений пропускной способности сплетенного трафика (как приводя к централизации сети), так и снижению безопасности/достоверности в условиях высокого базового слоя [..]. Другие предложенные альтернативы, такие как ARK, требуют нескольких изменений базового уровня (один или два мягких сила), которые представляют проблемы для развертывания. Наконец, ни одно из существующих или предлагаемых решений второго слоя не решает исходные проблемы конфиденциальности базового уровня биткойнов,-и другие решения, ориентированные на конфиденциальность уровня-1 (например, Coinjoin), все еще не защищают от юридических органов и не вводят дополнительные проблемы с восхищением BTC.
Таким образом, можно сделать вывод, что это подход блокчейна на основе бухгалтерских книг для строительного уровня 1, который должен быть полностью переосмыслил, чтобы решить вышеуказанные проблемы. Первые идеи в этом пространстве появились с возвращением Питера Тодда в 2016 и 2017 годах, когда указал, что владельцы какого -либо штата (например, BTC или любой другой контракт с государством) должны проверить лишь часть истории транзакции - та часть, которая является непосредственно связан с их собственностью - и опускает остальные. Он назвал свой подход к проверке на стороне клиента . Giacomo Zucco разработал протокол, способный создавать активы с этим подходом, названный RGB . В моей предыдущей работе в Ассоциации стандартов LNP/BP я смог дальше разработать RGB и преобразовать его в первую общую систему интеллектуальной контакты на стороне клиента с богатым состоянием и ограниченными вычислениями, заполненными Тьюрингом, обеспечивая достаточную функциональность, чтобы запустить что-либо, что будет может быть сделано с помощью интеллектуальных контрактов на основе блокчейна-но без публичной книги/блокчейна, хранящих какие-либо пользовательские данные, непосредственно используя анти-двойные расходы на свойства протокола консенсуса Bitcoin POW. Эта система была опубликована в течение четырех лет и была выпущена в апреле 2023 года.
В текущем предложении мы демонстрируем, что биткойн, если они предоставляются с государственным уровнем, подтвержденным на стороне клиента (например, RGB), может быть обновлен до системы без ограничивающих свойств общественной бухгалтерской книги (блокчейн) и, сохраняя протокол консенсуса POW, Он может быть основан на новом масштабируемом не Blockchain Layer 1 (кодовой Prime ). Этот слой сможет провести теоретически неопределенное количество транзакций (по крайней мере, миллиарды в минуту), поскольку хранение состояния, вычисления и проверка будут перемещены на уровни с клиентом, а также уровень, подтвержденный на стороне клиента, выше. Такая конструкция не требует сети Lightning или других масштабируемости и платежных слоев сверху и масштабируется в наихудшем сценарии, как
Протокол имеет три варианта развертывания (без разрешений, активированный шахтер и мягкий фарк), причем первые два не требуют какой-либо мягкой (или жесткой) вилки. Варианты являются независимыми, но также могут быть развернуты в последующем образом.
Предложение предоставляет несколько преимуществ биткойнам в качестве цифровых денежных средств:
Некоторые относительные недостатки предлагаемой системы:
Предлагаемая система (кодовой Prime ) состоит из четырех основных компонентов:
Эти компоненты совместно эквивалентны своей функциональности с бухгалтерской книгой типа; Однако в нашем дизайне они становятся абстрактными, обеспечивая гораздо большую масштабируемость и конфиденциальность, чем любая другая система блокчейнов.
На своем основании Prime работает служба временной метки, создавая последовательность заголовков, каждый из которых занимается корнем дерева Меркл из внешних данных, проверенных на стороне клиента:
ClassDiagram
Направление LR
`Заголовок n` <|-` Заголовок n+1`
Класс `Заголовок n` {
prev_commitment
merkle_root
merkle_tree_height
временная метка
// Поля POW
tlv_extensions
}
Класс `заголовок n+1` {
prev_commitment
merkle_root
merkle_tree_height
временная метка
// Поля POW
tlv_extensions
}
Каждый заголовок оснащен дополнительным расширением TLV, которое может использоваться для будущих обновлений протоколов; Его размер не зависит от количества транзакций, содержащихся в дереве Меркл данных, проверенных на стороне клиента, и имеет порядок 100 байт (в зависимости от данных TLV).
Prime не обеспечивает никакой защиты от двойного расходов; Он будет предоставлен в центре клиентской части системы. Единственными частями системы временного метки, которые подтверждены (правила консенсуса):
Основные заголовки - единственная информация, которая должна быть доступна публично и во всем мире; Это может быть достигнуто с помощью распределенной сети P2P.
Доказательными деревьями Merkle ( PMT ) являются посредническая и эфемерная структура, связывающая данные на стороне клиента, с заголовками. PMT производятся шахтерами и предоставляются общественности с помощью тех же или каких -либо других средств, что и заголовки; Однако, в отличие от заголовков, они не обязаны сохранять. Каждый пользователь сети отслеживает все новые PMT, извлекает часть информации, которая связана с государством, которым он владеет, сохраняет ее в собственном хранилище данных с клиентами, а также отбрасывает оставшуюся часть PMT.
Из -за эфемерного характера, отсутствия валидации и не нужно знать содержание PMT для добычи следующего заголовка, размер PMT не влияет на масштабируемость системы. Таким образом, PMT может иметь (многократный) размер гигабайта, совершая миллиарды и миллиарды транзакций.
Листья деревьев содержат свидетелей, закрывающих одноразовые замыкания: механизм, подробно описанный в следующем разделе. PMT построены в соответствии с схемой детерминированной обязательства с мультипротоколом LNPBP-4 и используются сегодня в RGB для размещения обязательств в транзакциях биткойнов (как в целовой, так и внутри протоколах отходов, таких как Lightning). Это означает, что каждое одноразовое обстоятельство имеет уникальное предопределенное размещение в PMT, так что одного пути Merkle и листья свидетель данный заголовок. Пользователи отслеживают набор своих одноразовых сетей, которые еще не были закрыты (аналог UTXO Set) и извлекают относительные доказательства из каждого недавно выработанного PMT. Если их печати не были закрыты, то это доказательства не операции (поскольку свидетель демонстрирует, что другой одноразовый обмен закрыт на этом пути).
Доказательства представляют собой зависимую от времени растущую часть истории, подтвержденной на стороне клиента. Требования к памяти для узла будут расти в зависимости от времени
где
Это логарифмично лучше, чем масштабируемость любого узла блокчейна, где требования к памяти растут как
где
где
А
где
Протокол одноразового завода предотвращает атаки двойного расходов на систему.
Одноразовые шишки (или печати ) являются особой формой криптографического обязательства, предложенной Питером Тоддом. Примитив можно сравнить с другими формами криптографических обязательств, которые включают хэш -функции и временное метка:
Более подробная информация о строительстве одноразового использования приведена в стандарте LNPBP-8. Prime использует специально спроектированную форму одноразовых шишек, которая отличается от той, которая используется в существующих протоколах (например, RGB).
Определение одноразового завода состоит из двух компонентов:
unique_id : глобально-юнический идентификатор, сгенерированный пользователем, который может быть определен детерминированным образом из Contract_ID, HASH Operation Hash и вывода операции контракта;spending_conditions_cmt : обязательство (хэш) условий, при которых уплотнение может быть закрыто в будущем (аналогично scriptPubkey в выходе транзакции биткойнов). Уплотнения определяются в системе смарт-контрактов с ценами на стороне клиента (RGB или RGB). Каждая печать может иметь назначенное состояние (как в RGB), например, BTC Balance или любые другие богатые данные. Когда пользователь любит обновлять это состояние-или передавать свое право собственности другому пользователю, должен быть подготовлен переход состояния , определяя новые одноразовые (ы) и новое состояние. Затем строится свидетель , закрывающий этот одноразовый Seal, посвященный данным о переходе состояния и предоставил исходный скрипт, соответствует обязательствам по условиям расходов, и данным, удовлетворяющим этот сценарий/условия. Предложение аннотация из конкретной системы сценариев (это может быть простота, AluvM, как в RGB сегодня, и надеясь не EVM :); Двигатель сценариев может быть указан с использованием поля version , так что новые двигатели или Opcodes могут быть введены с течением времени (см. Раздел модернизации):
ClassDiagram
Направление LR
Определение <|- Свидетель: уникальный_ид
Определение класса {
уникальный_ид
vending_conditions_cmt
}
Свидетель класса {
версия
уникальный_ид
state_transition_cmt
vending_conditions_src
удовлетворение_дата
}
Свидетель помещается в явную форму внутри листа Ptree и предоставляется шахтерам, строя PTREE и заголовки. Лист должен быть установлен внутри Меркл Дерево unique_id
Меркл путь к совпадению листа unique_id вместе с содержанием листьев (предоставление данных свидетелей) позволяет убедиться, что каждая одноразовая шишка была закрыта один раз и только один раз в истории умного контракта-и что он был закрыт, удовлетворяющий сценарий условия. Обратите внимание, что доказательства должны быть накапливаются для каждого одноразового уникального_ unique_id с момента его определения до закрытия-требование о том, что печать не была закрыта между ними. Эти доказательства, до тех пор, пока они демонстрируют различные unique_id , могут опустить чувствительные к конфиденциальности условия расходов исходное код и данные удовлетворенности, предоставляя только их хэш; Таким образом, исторические свидетели могут быть фиксированного размера. Как упоминалось ранее, для целей масштабируемости история доказательств также может быть дополнительно сжата с использованием доказательств с нулевым знанием.
Система, когда развернута с без разрешений, потребует собственного консенсусного протокола. Безопасность протокола не является критической, поскольку она привязана к безопасности биткойнов с помощью выделенного механизма, описанного ниже. Единственное требование для консенсуса-быть устойчивым к цензуре, что означает открытый набор шахтеров/валидаторов без идентичности. Единственными двумя консенсусными протоколами, как известно, удовлетворяют эти свойства, являются криппизиновые варианты POW и Uryoboros консенсусного консенсуса BFT Cryptoeconomally, обеспеченные вознаграждением шахтеров.
Служба временной метки не запускает какую-либо криптовалюту, а шахтеры вознаграждаются платами с дня 1. Выделенный контракт на плату за шахтер предоставляется RGB или другим протоколом смарт-контракта на стороне на стороне клиента, который определяет средства оплаты (BTC. Стабкоин или токенизированные платежи). Шахтеры должны участвовать в бесконечной анонимной сети P2P, где пользователи протоколов публикуют своих свидетелей, оснащенные транзакциями, уплачивающими плату за «Кто бы ни был шахт следующий заголовок». Шахтеры включают эти транзакции в историю, подтвержденную на стороне клиента, и, выполняющие возможность использовать заработанные средства в будущем.
В момент, когда система запустит выделенный выход «любого качества», с большим количеством SAT, созданного на блокчейне биткойнов. Информация об этом UTXO становится частью Genesis и служит определением одноразового обменения . Шахтер, решающий задачу POW, должен потратить этот вывод, а внутри транзакции биткойнов расходов обеспечивает обязательство Tapret для добытого заголовка и новую одноразовую-одноразовую-представляющуюся каждую-предназначенную для следующего майнера. Это прикрепляет созданный заголовок к блокчейну биткойна уникальным образом, так что единственной действительной последовательности заголовка TimeStemped является той, которая следует за этой последовательности одноразовых шил.
Если сторона тратит нынешнего шахтера одноразового использования без создания обязательств-или совершая заголовок без достаточного количества POW, такое закрытие считается недействительным; В этом случае любой стороне разрешено создавать специальную транзакцию биткойнов, предоставляющую общеиллюстрируемую информацию OP_RETURN («Объявление») о новом одноразовом синглом ( сброс протокола ); Только первое объявление OP_RETURN , которое закрыто с надлежащей процедурой, считается действительным в соответствии с правилами консенсуса.
Одноразовое якорное привязки POW представляет собой полный консенсусный протокол, который может управлять системой без какого-либо другого дополнительного консенсуса (POW или BFT). В качестве альтернативы, его можно объединить с вторичным консенсусом с правилом, что, если безопасность второго консенсусного протокола не будет ниже, чем безопасность биткойнов POW, POW биткойн не имеет приоритета - с автоматическим переходом обратно на вторичный консенсус в качестве основного консенсуса, когда это состояние не выполнено.
Мы намеренно не рассматриваем вопрос структуры сети P2P в этом предложении, поскольку несколько альтернативных систем могут сосуществовать и конкурировать на рынке. Вместо этого, поскольку свойства сети важны для целей проекта, мы определяем общие требования для выбора сети P2P:
В настоящее время мы не видим сетевой встречи вышеупомянутых свойств; Тем не менее, мы видим несколько сетей с потенциалом для развития по отношению к ним:
Мы планируем работать над проектом RenoStr, используя нашу предыдущую работу из протокола Storm и используя сквозное шифрование в стиле BIP-324. Другие проекты могут создавать альтернативные решения, и лучший вариант должен быть выбран рынком.
Мы видим три шага - или опции - в том, как предлагаемое решение можно развернуть в биткойнах. Каждый из шагов необязательно; Система может работать без одного или двух из них. Кроме того, каждый вариант имеет свои компромиссы, однако, если они развернуты в качестве последующих шагов, эти компромиссы постепенно решаются.
Система может быть запущена независимо от TimeCain Bitcoin, при этом консенсус, привязанный к безопасности Bitcoin POW через выделенный механизм, основанный на одноразовых истечениях (которые мы описываем в статье). Это не требует каких -либо изменений на стороне майнера или каких -либо биткойн -мягких/жестких сил, однако с помощью этой настройки BTC можно допустительно перенести в новую систему только одним способом, а другой способ потребует федерации.
Биткойн -шахтеры начинают обрабатывать первичные транзакции и привержены приверженности заголовке службы временной метро в биткойн -блокчейн Coinbase - как это делает в случае объединенной майнинга. Это устраняет необходимость в выделенном первостепенном консенсусе, но уязвимо для хранения силовых атак, требуя от великого большинства шахтеров присоединиться к протоколу до его развертывания.
Однако это предложение не требует каких -либо конкретных мягкихформ, поскольку текущие правила консенсуса биткойнов он не может обеспечить достоверный способ перемещения BTC из новой Prime System обратно в блокчейн Биткойн. Хотя мы не рассматриваем это как требование (у Prime слишком много преимуществ по сравнению с блокчейном, так что мы считаем, что блокчейн уже мертвым в долгосрочной перспективе), в краткосрочной перспективе это может представлять проблему для принятия платформы.
Существует множество различных предложений по мягкой борьбе, которые могут обеспечить такую функциональность. Они попадают в две основные категории:
Принятие любого из этих предложений позволит BTC для BTC на Prime Platform. Наши собственные предпочтения следуют за op-кодами с нулевым знанием, поскольку у них есть много других преимуществ и не предоставляют компромиссы, неизбежные в DriveChains.
Обновление системы с клиентой на стороне на стороне очень сильно отличается от обновления сети блокчейна-или P2P (например, Lightning). Это вызвано тем фактом, что блокчейны являются протоколами консенсуса, которые являются полностью реплицированными состояниями, в то время как валидация на стороне клиента использует частичную репликацию. Это, с одной стороны, упрощает обновление системы по частям, связанных с неизвестным состоянием, но с другой стороны, из-за отсутствия некриптоэкономических гарантий в глобально доступном состоянии, предоставленном сетью , гораздо сложнее координировать любое обновление.
Другими словами, обновления на стороне клиента в основном отличаются от блокчейна жестких сил и мягких форм и требуют введения новых концепций и терминов.
Если что-то было недействительным и стало действительным после обновления (мы называем это быстрое изменение ), все существующие пользователи не будут затронуты: они уже владеют и управляют состоянием, которое является действительным. Тем не менее, они могут не иметь возможности взаимодействовать с пользователями, использующими более старые версии программного обеспечения - проблема, решаемая проблема, если их сверстники соглашаются обновлять. Обновление не представляет риска для этих сверстников, поскольку они не будут использовать ни одного состояния, которым они обладают, и обновление не будет касаться исторических данных.
С другой стороны, ситуация, когда что -то было обоснованным - и стало недействительным в соответствии с новыми правилами - очень отличается: пользователи могут потерять свое существующее состояние навсегда и должны как можно больше противостоять обновлению. Мы называем такие обновления отталкивания , и мы видим их приемлемыми, только если была обнаружена критическая ошибка: обновление будет «скоординировано» желанием искренних/не-читинских пользователей избежать проблем, введенных ошибкой.
Если в качестве интеллектуального контрактного компонента используется Smart Contract System, обновления этой части будет использовать еще одну отличительную функцию. RGB изолирует каждую программу («умный контракт») в песочницу; и договор, как только он будет выпущен, не может перейти на новую версию протокола. Единственный способ обновления - это заключить новый контракт, когда эмитент (или стороны, которым он был делегирован эмитентами, включая сообщество) сделает государственный перевод от старого контракта в новый - и каждый из контрактов Владельцы согласятся по этому поводу.
Как побочное преимущество, этот подход позволяет постепенно внедрять новые функции, инструкции и т. Д., Не достижимый в мире блокчейнов: эмитенты новых контрактов не зависят от предыдущих версий протокола и могут предлагать более продвинутые решения без какого -либо дополнительного риска обновления или Координация сообщества.
Автор благодарен Джакомо Зукко, который был человеком, внедряющим идею удаления зависимости от биткойнов от ограниченной блокчейна и рассматривать нормативность на стороне клиента как путь вперед. Многочисленные дискуссии с ним и Питером Тоддом за эти годы помогли разработать многие части системы. Среди прочих автор хотел бы упомянуть Алекса Краветса, Федерико Тенга, Ольги Укаловы, которые были собеседниками, которые потратили много часов на обсуждение вопросов, связанных с справедливостью на стороне клиента, недостатками блокчейна и без блокчейна.
