Экспертное мнение Джеймсона Лоппа, профессионального шифропанка, создателя satoshi.info и тех. директора Casa, о бесцеремонном вмешательстве Facebook в криптосферу. Лопп внимательно изучил, помимо прочей доступной информации по теме, 26-страничный технический документ (с впечатляющими 53 авторами!), описывающий протокол, который будет использоваться в качестве платформы для койна Libra от Facebook. Ниже приведён подробный разбор этого документа.
(Примечание редактора: курсивом выделены цитаты из документа.)
Краткий обзор
Протокол Libra позволяет набору реплик, называемых валидаторами и контролируемых различными полномочными сторонами, совместно поддерживать базу данных программируемых ресурсов.
Здесь нет никакого искажения – система будет контролироваться «вертикально» группой уполномоченных на то сторон. При этом обратите внимание, что база данных предназначена для «программируемых ресурсов», а не просто для цифровой валюты.
Эти ресурсы принадлежат различным пользовательским аккаунтам/счетам, аутентифицированным при помощи криптографии с открытым ключом, и подчиняются пользовательским правилам, определённым разработчиками этих ресурсов.
Использование такого обобщения, как «ресурсы», наводит на мысль о том, что речь идёт о чём-то значительно большем, нежели просто очередной стейблкойн.
Транзакции основываются на заранее заданных и, в будущих версиях, на создаваемых пользователями смарт-контрактах, написанных на новом языке программирования под названием Move. Мы используем язык Move для определения работы основных рабочих механизмов блокчейна, таких как валюта и членство валидаторов.
Вот это уже интереснее. Использование нового специального языка для написания смарт-контрактов приведёт к возникновению множества вопросов о том, насколько многофункциональным является этот язык и насколько устойчива система к антагонистическим, конкурирующим контрактам. Будут возникать также вопросы в отношении удобства для разработчиков и защиты от случайных ошибок.
Эти основные механизмы позволяют создать уникальный механизм управления, первоначально опирающийся на стабильность и репутацию существующих организаций, но с течением времени перерастающий в совершенно открытую систему.
Похоже, что Libra Association будет представлять собой федерацию, которая может эволюционировать с помощью системы голосования, с некой системой изначально присвоенной репутации.
1. Введение
Эта экосистема предложит новую глобальную валюту, койн Libra, которая будет полностью обеспечена корзиной из банковских депозитов и казначейских векселей лучших центральных банков.
Libra – это настраиваемый протокол криптоактивов, и первым активом станет стейблкойн.
Со временем структура прав на членство будет изменяться, пока оно не станет полностью открытым и основанным только на количестве удерживаемых пользователем койнов Libra.
Звучит до боли похоже на proof-of-stake. Очевидно, план заключается в том, чтобы сделать членство открытым через пять лет, и я надеюсь, что за это время авторы протокола хорошенько изучат особенности proof-of-stake. Хотя подозреваю, что в итоге они столкнутся с теми же проблемами, что и Ethereum.
Ассоциация опубликовала отчёты с изложением … дорожной карты перехода к открытой системе без уровней доступа.
Я уверен, что это будет первый случай перехода распределённой сети от закрытой системы с ограниченным доступом к открытой системе. Возможно, сеть в целом сможет переключиться на proof-of-stake, но для поддержания привязки курса и обеспечения стейблкойна, некоторые субъекты должны сохранять мостик к традиционной финансовой системе открытым. И это будет оставаться постоянной точкой централизованного контроля, организованного через Libra Association.
Валидаторы по очереди управляют процессом утверждения транзакций. Когда валидатор выступает в роли лидера, он предлагает как те транзакции, что представлены ему непосредственно клиентами, так и те транзакции, что представлены косвенно – другим валидаторам через других валидаторов. Все валидаторы исполняют транзакции и формируют структуру проверенных данных, содержащую новую историю реестра. Валидаторы выбирают голосованием аутентификатора для этой структуры данных как часть протокола консенсуса.
Это звучит как Practical Byzantine Fault Tolerance – хорошо изученный за последние 20 лет алгоритм – хотя они, вероятно, изменили некоторые параметры. Из раздела 5 белой книги мы узнаём, что алгоритм получил название LibraBFT и представляет собой версию протокола консенсуса HotStuff.
Как часть совершения транзакции T i в версии i, протокол консенсуса выводит подпись на полное состояние базы данных в версии i, включая всю её историю, для аутентификации ответов на запросы от клиентов.
Это примечательно прежде всего потому, что означает возможность для валидаторов присоединиться к сети и быстро синхронизироваться без необходимости воспроизводить всю историю блокчейна. При этом предполагается, что они доверяют существующим валидаторам.
2. Логическая модель данных
Протокол Libra использует для кодирования состояния реестра модель данных на основе счетов.
С точки зрения структуры данных, Libra больше похожа на Ethereum или Ripple, чем на Bitcoin. У UTXO-модели есть свои преимущества и недостатки – такие как лучшая конфиденциальность и более надёжная история транзакций (благодаря простоте истории, основанной на выходах транзакций) – но работать со сложными смарт-контрактами в рамках такой модели может оказаться сложнее. Следовательно, основанная на счетах модель имеет смысл, потому что Facebook едва ли будет беспокоиться о конфиденциальности пользователей, притом что платформа как будто заинтересована в поддержке смарт-контрактов.
Протокол Libra не связывает счета с личностью пользователя. Пользователь может создавать несколько счетов, сгенерировав несколько пар ключей. Счета, управляемые одним пользователем, не являются непременно связанными друг с другом. Эта схема следует примеру Биткойна и Эфириума, обеспечивая псевдонимность пользователей.
Это звучит на удивление хорошо, но мне интересно, относится ли это также к Libra-койну, активу. Будет интересно понаблюдать, насколько открытой будет эта система для разработчиков, желающих строить приложения для более серьёзной защиты конфиденциальности пользователей.
Каждый ресурс имеет тип, выражаемый в модуле. Типы ресурсов – это номинальные типы, состоящие из имени типа, а также имени и адреса декларирующего модуля ресурса.
Похоже на то, что вы можете генерировать адрес, и этот адрес может иметь произвольное количество приписанных к нему активов при условии, что каждый актив имеет уникальное имя.
Исполнение транзакции T i создаёт новое состояние S i реестра, а также код статуса исполнения, расход газа и список событий.
Что ж, теперь мы знаем, как система защищена от атак истощения ресурсов – предположительно, за счёт использования системы стоимости этих ресурсов, подобной той, что применяется в Ethereum.
В истории реестра нет понятия блока транзакций.
Интересно. В протоколе Libra отсутствует блокчейн-структура данных – блоки представляют собой скорее виртуальную логическую конструкцию, которая используется валидаторами для координирования подтверждённых снимков состояния системы. Возвращаясь назад, теперь первое предложение раздела имеет больше смысла:
Все данные в блокчейне Libra хранятся в одноверсионной базе данных. Номер версии – это 64-разрядное число без знака, которое соответствует количеству транзакций, исполненных системой.
Все известные мне сети криптоактивов, в общих чертах, работают одинаково: есть состояние системы, затем выполняется транзакция, являющаяся фактически функцией изменения состояния системы, после чего система переходит в новое состояние.
Состояние системы —> Транзакция —> Новое состояние системы Транзакции объединяются в блоки с целью их упорядочения и присвоения временных меток. Это очень важно для открытых сетей, в которых данные аутентифицируются групповыми подписями с динамическим количеством участников группы (dynamic multiparty membership signatures, DMMS). Поскольку Libra будет закрытой системой, в ней можно использовать более эффективный алгоритм консенсуса, который не нуждается в объединении транзакций в блоки в виду намного меньшей вероятности переписывания истории транзакций.
В начальной версии протокола Libra пользователям доступно лишь ограниченное количество функций Move. Хотя Move используется для определения основных концепций системы, таких как валюта Libra, пользователи не могут публиковать индивидуальные модули, декларирующие собственные типы ресурсов. Такой подход обеспечивает возможность совершенствования языка и набора инструментов Move на основе опыта имплементации основных компонентов системы до того, как эти инструменты будут открыты для пользователей. Этот подход позволяет также решить проблемы масштабируемости при выполнении транзакций и хранении данных, которые присущи универсальной платформе для смарт-контрактов.
Это очень напоминает уже упоминавшиеся ранее планы об «открытом членстве валидаторов». Похоже, что Facebook пока ещё не решил ни одной из серьёзнейших проблем, над которыми Ethereum бьётся последние годы.
Для управления спросом на вычислительные мощности протокол Libra взимает комиссии за выполнение транзакций, деноминированные в монетах Libra.
Монеты Libra являются собственными рыночными единицами протокола так же, как ETH представляют собой нативные рыночные единицы протокола Ethereum. Это подводит нас к ещё одному вопросу о псевдонимной природе Libra: могут ли пользователи приобретать эти койны без обязательной идентификации через процедуры AML/KYC? Если нет, то, похоже, ни одной из функций системы нельзя будет воспользоваться анонимно. Из доступных материалов о кошельке Calibra ясно, что он будет требовать от пользователей прохождения процедур AML/KYC. Так что у меня возникают сомнения в том, что Libra в конечном итоге перерастёт в не контролируемую жёстким и централизованным образом систему.
Система разработана таким образом, чтобы комиссии при нормальном функционировании, с достаточным количеством доступных вычислительных мощностей, оставались низкими.
Это звучит крайне расплывчато и вызывает множество вопросов: Что значит низкие комиссии? Что такое нормальное функционирование? Какая вычислительная мощность считается достаточной?
3. Выполнение транзакций
Многие составляющие основной логики блокчейна определяются с помощью Move, включая вычет комиссии за газ. Во избежание зацикливания процессов, виртуальная машина (VM) отключает учёт газа во время исполнения этих основных компонентов.
Это звучит довольно опасно, но авторы документа отмечают, что основные компоненты должны быть написаны с учётом возможных DoS-атак и предотвращать их проведение.
Ключевой особенностью Move является способность определять пользовательские типы ресурсов … система типов Move обеспечивает для ресурсов особые гарантии безопасности. Ресурс не может быть скопирован, но только перемещён. Эти гарантии выполняются статически Move VM. Это позволяет нам представлять монеты Libra как тип ресурсов в языке Move.
Это проливает чуть больше света на то, являются ли монеты Libra нативным активом для сети, как ETH или BTC. Я ожидаю, что эти монеты будут просто типом ресурсов по умолчанию либо единственным допустимым в системе сразу после запуска, а поддержка других типов ресурсов будет введена позже.
Стековый байт-код Move имеет меньше инструкций, чем исходный язык более высокого уровня. Кроме того, каждая инструкция имеет простую семантику, которая может быть выражена с помощью ещё меньшего количества элементарных шагов. Это уменьшает размер спецификации протокола Libra и облегчает поиск ошибок при имплементации.
Это звучит хорошо и продуманно. Надеюсь, что безопасность их скриптового языка будет продумана лучше, чем это было сделано в Ethereum.
4. Структуры и хранение проверенных данных
В протоколе Libra для обеспечения структуры аутентифицированных данных для истории реестра используется одиночное дерево Меркла … в частности, в истории реестра для формирования дерева Меркла используется метод аккумулирования, обеспечивающий также эффективные операции добавления.
И снова мы видим, что «блокчейн Libra» на самом деле блокчейном не является. Действительно странно, что при всей кажущейся проработанности этого протокола, они всё же продолжают называть его блокчейном, притом что структура данных в истории реестра представляет собой набор подписанных состояний реестра. Валидаторы берут на себя обязательства за каждое состояние реестра и все исторические состояния реестра также привязаны к деревьям Меркла, но я пока не увидел, чтобы какие-либо листы данных с обратной связью формировали цепочку, не говоря уже о цепочке блоков.
Аутентификатором счёта является хеш этого сериализованного представления.
Обратите внимание, что это представление требует повторного вычисления аутентификатора по всему счёту после любой модификации счёта. Стоимость этой операции – O(n), где n – это длина байтового представления полного счёта.
Хммм. Если нет ограничений на количество данных, хранимых одним счётом, то это звучит как открытость к DoS-атакам.
Мы ожидаем, что, по мере использования системы, рост объёма хранимых данных, связанных со счетами, в конечном счёте может стать проблемой. Так же, как газ поощряет ответственное использование вычислительных ресурсов, мы ожидаем, что аналогичный механизм аренды может потребоваться и для хранения данных. Мы рассматриваем широкий спектр возможных подходов к созданию основанного на ренте механизма, который лучше всего подойдёт экосистеме.
Ещё одна нерешённая проблема. Можно ожидать волну мемов по поводу «слишком высокой ренты».
Право на участие в голосовании должно оставаться честным как во время эпохи, так и в течение периода после её окончания, чтобы клиенты могли синхронизироваться с новой конфигурацией. Клиентам, которые находятся в автономном режиме дольше этого периода, для получения контрольной точки, которой они смогут доверять, понадобится синхронизироваться повторно с использованием внешнего источника истины.
Ой. Не очень понятна продолжительность этого «периода», но если эпоха длится меньше дня, то, надо полагать, что и указанный «период» – тоже. Похоже, что этот протокол консенсуса не настолько прочен, чтобы участники могли выходить из сети и снова к ней присоединяться по своему усмотрению.
5. Устойчивый к византийской ошибке консенсус
LibraBFT подразумевает, что набор голосов 3f + 1 распределяется между группой валидаторов, которые могут быть добросовестными, или византийскими. LibraBFT остаётся безопасной, препятствуя атакам двойной траты и форкам, до тех пор, пока большинство f-голосов контролируется византийскими валидаторами.
Как и PBFT, этот алгоритм консенсуса может выдержать до 33% недобросовестных валидаторов. Модификации HotStuff звучат разумно:
6. Сетевое взаимодействие
Каждый валидатор в протоколе Libra имеет полную информацию о членах системы и по необходимости подключается напрямую к любому валидатору. Предполагается, что валидатор, который не может установить прямой связи, попадает в квоту византийских ошибок, допускаемых системой.
Потребуется проделать большую работу, чтобы масштабировать систему за пределы нескольких сотен валидаторов.
7. Имплементация Libra Core
Безопасность блокчейна Libra основывается на корректной имплементации системы валидаторов, программ Move и Move VM. Решение этих вопросов в Libra Core находится в стадии разработки.
Эти слова в значительной степени подводят итог разделу. Хотя можно отметить, что они написали имплементацию на Rust, и это представляется хорошим выбором с точки зрения производительности и безопасности.
8. Производительность
Мы ожидаем, что при начальном запуске протокол Libra будет поддерживать 1000 платёжных операций в секунду, с 10-секундным интервалом между отправлением и завершением транзакции.
Если учесть, что валидаторов будет всего около 100, и все они будут напрямую связаны друг с другом, 10-секундный интервал между блоками звучит реалистично.
Минимальные требования к узлам:
- скорость интернет-соединения 40 Мбит/с
- 1 серийно выпускаемый CPU
- 16 ТБ SSD
Раньше уже были упоминания о сохранении возможности для валидаторов выполнять начальную синхронизацию с нуля, без необходимости доверять состояниям, подписанным другими валидаторами. Я ожидаю, что, если Libra получит широкое распространение и будет активно использоваться, то очень скоро выполнение такой синхронизации станет непрактичным, и модель безопасности узлов как таковая будет в высокой степени полагаться на доверие валидаторам.
9. Реализация политик экосистемы Libra с Move
Резерв монет Libra является основным механизмом для достижения сохранения стоимости. Через резерв каждая монета полностью обеспечивается набором из стабильных и ликвидных активов. Контракт Libra-койна позволяет ассоциации выпускать новые монеты, когда спрос на них возрастает, и уничтожать их, когда спрос сокращается. Ассоциация не устанавливает монетарную политику, она может только издавать и сжигать койны в ответ на запрос от авторизованных торговых посредников. Пользователям не нужно беспокоиться о том, что ассоциация будет разгонять инфляцию или, наоборот, обесценивать валюту: для выпуска новых монет необходимо наличие соответствующего фиатного депозита в резерве.
Хорошо, но теперь мы говорим о событиях, которые являются внешними по отношению к сети. Как указывалось в whitepaper до того, сеть не может выполнять скрипты, использующие входы данных, которые являются внешними по отношению к состоянию сети. Таким образом, модификаторы «может» и «должен» в приведённом выше фрагменте, безусловно, относятся к политикам Libra Association либо договорным обязательствам, о которых сеть не знает.
Алгоритм консенсуса основан на модуле управления валидаторами Move для поддержания текущего набора валидаторов и управления распределением голосов между валидаторами. Первоначально блокчейн Libra предоставляет право голоса только учредителям.
Предположим, что валидаторы проголосуют за изменения в составе валидаторов. Похоже, что это должно привести к проблеме, аналогичной той, что мы видим в proof-of-stake-системах, – атакам дальнего действия (long range attack). Скомпрометировав достаточное количество секретных ключей учредителей, сможет ли злоумышленник написать новую историю реестра с нуля? И если да, то примут ли её другие узлы? Неясно, позволяет ли протокол консенсуса переписывать старые состояния или только создавать новые.
Мы планируем постепенно перейти на алгоритм proof-of-stake.
Если им удастся решить нерешённые пока проблемы.
Вопросы без ответов
Как осуществляется управление?
Мы можем видеть, что Libra Association представляет собой совет из участников и для внесения изменений требуется согласие 2/3 его участников. Они единственные, кто может выпускать или уничтожать монеты Libra, но, обладая достаточным большинством, они, предположительно, могут и произвести любые другие изменения по своему усмотрению.
Требуется ли прохождение процедур AML/KYC?
Очевидно, этого не требуется на уровне протокола, но, согласно заявлению о кошельке Calibra, все его пользователи будут верифицироваться по выданным государством идентификационным документам. Похоже также, что Calibra по крайней мере некоторое время будет единственным доступным кошельком, поэтому пока неясно, смогут ли разработчики и пользователи запускать в сети Libra приложения, не соответствующие всем тем же стандартам, что и Calibra.
Что значит низкие комиссии? Что такое нормальное функционирование? Какая вычислительная мощность считается достаточной?
В разделе часто задаваемых вопросов на сайте Calibra есть обещание низких комиссий, однако оно может вступать в конфликт с поддержанием работоспособности базового протокола в периоды высокой нагрузки.
Комиссии за транзакции будут небольшими и прозрачными, особенно если вы совершаете международные переводы. Calibra сократит комиссии, чтобы помочь пользователям сохранить свои деньги.
Будет ли Libra действительно открыта для разработчиков?
План постепенного движения к состоянию открытого протокола консенсуса гласит:
Блокчейн Libra будет открыт для каждого – любой пользователь, разработчик или компания смогут пользоваться сетью Libra, строить продукты на её основе и создавать добавленную стоимость через предоставление своих услуг. Открытость доступа снижает барьеры для входа на рынок и создание инновационных продуктов и поощряет здоровую конкуренцию, от которой в конечном счёте выигрывают потребители.
Я скептически отношусь к обещанию о том, что разработчики смогут запустить на этой платформе любое технически допустимое приложение, какое только захотят. Ничто из того, о чём я прочёл, не убеждает меня в том, что эта система будет устойчива к цензуре. Впрочем, со всей определённостью это покажет только время.
Подписывайтесь на BitNovosti в Telegram!
Делитесь вашим мнением об этой статье в комментариях ниже.
