Как масштабировать биткойн-блокчейн

в 7:18, , рубрики: bitfury, Lightning Network, Segregated Witness, биткойн, Блог компании Bitfury Group, блокчейн, платежные системы

В одном из наших предыдущих материалов мы отмечали, что главными преимуществами блокчейна являются открытость, защищенность и безопасность. Однако любая технология всегда имеет определенные недостатки.

Биткойн, как самый крупный, популярный и надежный блокчейн также не лишен таковых, однако сообщество их активно решает. Поэтому в рамках сегодняшнего поста мы затронем следующие вопросы:

  • Какой самый большой недостаток биткойн-блокчейна?
  • Какие решения предлагало мировое сообщество?
  • Какое из них станет частью биткойн-сети?

Как масштабировать биткойн-блокчейн - 1/ изображение Susana Fernandez CC

Сегодня к блокчейну активно присматриваются банки, энергетические компании, участники рынка интернета вещей и государственные организации. Например, Bank of America и Microsoft начали совместную разработку финансовой блокчейн-платформы, а компания Chronicled запустила блокчейн-платформу для интернета вещей, которая создает безопасные и совместимые со множеством других систем цифровые идентификаторы. Однако окружение и условия, в которых работает биткойн, значительно отличаются от тех, какими они были в момент зарождения криптовалюты. Количество пользователей выросло до нескольких десятков миллионов человек (более 13 млн), что вызвало увеличение числа ежедневных транзакций (порядка 400 тыс.).

Количество ресурсов, которые приходится затрачивать на работу программного обеспечения и хранение реестра биткойна со списком проведенных транзакций довольно большое. Вся цепочка транзакций биткойн-блокчейна прослеживается, начиная с самой первой операции, проведенной 12 января 2009 года создателем биткойна Сатоши Накамото. На сегодняшний день размер биткойн-блокчейна составляет порядка 120 ГБ и продолжает расти.

Как масштабировать биткойн-блокчейн - 2

Все эти особенности функционирования системы привели к возникновению проблемы масштабирования биткойна и ограничили его теоретический размер. Блокчейн является последовательностью блоков, каждый из которых представляет собой защищенный криптографическими алгоритмами набор транзакций. При этом Сатоши Накамото (примерно через год после создания биткойна) ограничил размер блока одним мегабайтом. Это было сделано с целью предотвращения вероятных DoS-атак злоумышленников, когда они создают большие (в теории неограниченные) блоки, чтобы парализовать сеть.

Однако такая мера безопасности оказала негативный эффект на пропускную способность сети в целом (в долгосрочной перспективе). На сегодняшний день биткойн может обработать порядка 7 транзакций в секунду (TPS). При этом фактическая нагрузки на сеть биткойна составляет 3,5 TPS. Для сравнения, показатель TPS в системе Visa равен 2 000 (в моменты пиковой активности — 50 000).

Ранние предложения по решению проблемы

Первые предложения по улучшению биткойна были представлены в 2015 году (BIP 100 и BIP 101) разработчиками ядра Джеффом Гарзиком (Jeff Garzik) и Гевином Андресеном (Gavin Andresen). Оба решения предлагали увеличить размер блока, однако являлись хардфорками, то есть не имели обратной совместимости. Это означало, что при их реализации старое программное обеспечение становилось несовместимым с новой сетью. В BIP 100 предлагалось настраивать размер блока по решению майнеров, а в BIP 101 — единовременно увеличить размер блока до 8 мегабайт.

На тот момент увеличение размеров блока являлось наиболее простым решением с технической точки зрения, однако ни одна из схем так и не была реализована. Отказ в реализации оказался связан больше с политическими (в рамках биткойн экосистемы) проблемами, чем с техническими. Наличие больших блоков могло привести к централизации биткойна, поскольку для их хранения и обработки потребовалось бы еще больше вычислительной мощности, а выделить такие объемы ресурсов смогут только крупные компании. Таким образом, возникло бы противоречие с главной идеей биткойн-блокчейна как криптовалюты, управляемой пользователями.

Segregated Witness

В конце 2015 года разработчик Питер Вюлле (Pieter Wuille) презентовал предложение под названием Segregated Witness, увеличивающее пропускную способность сети. Подход изменял не размеры блока, но способ хранения транзакций. Одним из преимуществ решения стала возможность его реализации через софтфорк (то есть обеспечив обратную совместимость). После выхода технического описания Segregated Witness, предлагаемые решения проблемы масштабируемости разделились на две группы: одни стремились увеличить размер блока, а другие — оставить блок без изменений, оптимизируя иные аспекты протокола. Достигнуть консенсуса по этому вопросу никак не удавалось. До недавнего времени.

20 мая ключевые игроки биткоин-индустрии все же смогли найти точки соприкосновения. Участники конференции Hong Kong Bitcoin Roundtable Consensus (в том числе компания BitFury) согласились поддержать несколько апгрейдов протокола биткойна. Один из них —это активация Segregated Witness по достижении уровня поддержки в 80% (мощности майнеров). Второй связан с увеличением размеров блока до 2 МБ. Это решение даже повлияло на стоимость биткойна. Интерес к криптовалюте и новые открывающиеся возможности по масштабированию блокчейна привели к тому, что цена за биткойн перевалила отметку в 2,5 тыс. долларов.

Как масштабировать биткойн-блокчейн - 3

Можно сказать, что транзакции в биткойне состоят из двух компонентов. Первый компонент освобождает биткойны, заблокированные в предыдущих транзакциях, используя так называемые вводы. Вводы включают в себя скрипты (ScriptSigs); каждый такой скрипт содержит набор инструкций по открыванию биткойнов (например, цифровую подпись). Второй компонент транзакции содержит набор выводов (скрипты ScriptPubKeys), которые запирают освобожденные биткойны (или немного меньше). Каждый запирающий скрипт определяет условия, при которых соответствующие биткойны могут быть потрачены (например, при условии знания определенного закрытого ключа). Получается, что биткойны перемещаются от вводов к выводам транзакции и от одной транзакции к другой.

Запирание и отпирание биткойнов осуществляется отправителями транзакций, и транслируется по сети в форме пакетов информации. В выводах, запирающих биткойны, как правило, содержатся инструкции, смысл которых — убедиться, что пользователь знает нужный приватный ключ, соответствующий указанному публичному ключу.

Технология Segregated Witness видоизменяет эту цепочку взаимодействий. Вновь созданные выводы начинают использовать другой тип запирающего скрипта, который получил название «тратит кто угодно» (anyone can spend), поскольку не требует цифровых подписей, и на первый взгляд может быть потрачен кем угодно. Хитрость в том, что запирающий скрипт вида anyone can spend содержит специфическую последовательность байтов, которая привязывает к скрипту «настоящие» условия траты биткойнов.

Похожий прием используется в P2SH (Pay to Script Hash). Как и в случае SegWit, с P2SH биткойны по-прежнему запираются в сценарии, однако в выход транзакции добавляется не сам запирающий сценарий, а его хеш. Для того, чтобы потратить биткойны, запертые таким сценарием, нужно знать не только «настоящий» запирающий сценарий (как может показаться при первом прочтении scriptPubKey), но и отпирающий scriptSig для этого сценария (например, цифровую подпись).

Segregated Witness, по сути, выделяет scriptSig (подписи транзакций) в отдельную структуру данных — witness (доказательство). Таким образом, SegWit является аддоном, который полностью игнорируется старыми узлами, но признается новыми. И старые и новые узлы считают транзакции с SegWit корректными: первые видят скрипты «тратит кто угодно» и считают транзакцию корректной (хотя и странной с точки зрения семантики), а вторые — обращаются к подписи в witness. За счет этого технология позволяет устранить плавкость транзакций (tx malleability), сохранить дисковое пространство и оптимизировать скорость проверки подписей.

Есть, однако, небольшая сложность: если подписи не влияют на хеши транзакций, он уже не может являться доказательством того, что для транзакций, включенных в блок, существуют в природе корректные подписи. Чтобы обойти эту особенность, майнер пишет в определенное место блока хеш, зависящий от всех witness в транзакциях, который вычисляется аналогично хешу транзакций блока, то есть при помощи деревьев Меркла.

Еще одним достоинством SegWit может служить тот факт, что в нем сохраняются байты версий. Они предшествуют скрипту и обозначают его тип. Это дает возможность обозначать требования, необходимые для высвобождения биткойнов. Фактически это позволит запирать биткойны самыми разными способами. Реализовать потенциал этой функции смогут подписи Шнорра, которые более компактны и верифицируются быстрее нынешних ECDSA-подписей, а также более сложные типы мультисигнатурных транзакций и даже смарт-контракты, подобные Ethereum.

На практике запирающие сценарии в SegWit выглядят подобным образом (этот пример взят из реальной транзакции, только не в биткойне, а в другом очень похожем с технической точки зрения блокчейне — лайткойне; на нем SegWit уже активирован):

"scriptPubKey": {
"asm": "0 07389b37ea077e9431a2e64530649f8a61befa54",
"hex": "001407389b37ea077e9431a2e64530649f8a61befa54",
"type": "witness_v0_keyhash"
}

Сценарий состоит из байта версии сценария (0), после которого идут 20 байтов, соответствующих обычному адресу в биткойн-сети (хешу публичного ключа). Если смотреть с точки зрения узла, ничего не знающего о SegWit, этот сценарий может быть потрачен кем угодно, например, пустым отпирающим сценарием scriptSig. В самом деле, scriptPubKey только добавляет данные в стек и никаких проверок данных, помещенных в стек сценарием scriptSig до этого, не производит.

Если же смотреть с точки зрения узла, знающего о SegWit, этот сценарий сигнализирует о том, что в поле witness тратящей транзакции должна содержаться цифровая подпись транзакции вместе с публичным ключом, хеш которого указан в сценарии. Поле scriptSig при этом должно быть пустым.

Как именно стоит проверять SegWit-сценарий, узел определяет на основе байта версии и длины следующего элемента scriptPubKey (в примере выше — 20). Пока в SegWit определены 2 типа сценариев: на основе публичного ключа (наш пример) и более сложный для произвольных проверок (например, мультисигнатур). Во втором случае в scriptPubKey записывается 32-байтовый хеш «настоящего» запирающего сценария. Во время траты средств, этот сценарий, вместе с подходящим отпирающим сценарием, должен быть предоставлен в поле witness. При этом хеш запирающего сценария должен совпадать со значением, указанным в scriptPubKey.

Lightning Network

В рамках этого материала хотелось бы упомянуть технологию масштабирования Lightning Network (LN), которая во многом становится возможной именно за счет SegWit, и в развитии которой компания BitFury принимает активное участие. Lightning Network основана на обычных биткойн-транзакциях, только эти транзакции не передаются в биткойн-сеть (по крайней мере, сразу). Вместо этого они сохраняются локально на узлах сети LN.

Главная особенность Lightning Network — это двунаправленные «бездоверительные» платежные каналы, которые позволяют обмениваться биткойнами напрямую, минуя блокчейн. В блокчейн транслируются только открывающие и закрывающие канал транзакции, даже если между ними были совершены миллионы платежей. Это позволяет серьезно «разгрузить» блокчейн и повысить его пропускную способность, а также проводить микроскопические платежи (например, посекундно оплачивать цифровой контент или интернет-связь). Более того, LN позволяет проводить платежи через одного или более промежуточных узлов сети без риска, что эти узлы смогут похитить средства. За счет этого обеспечивается масштабируемость LN до миллионов узлов. Подробнее о принципах работы LN мы планируем рассказать в последующих материалах.

P.S. Наши вакансии на HH и англоязычный блог на Medium.

P.P.S. Дополнительные материалы по теме:

Автор: Bitfury Group

Источник

Поделиться

* - обязательные к заполнению поля