Как Celestia решает проблему доступности данных
Когда мы начинали работать с проектом Celestia, то обратили внимание, что чрезвычайно сложно найти в интернете материал, который на общем уровне простыми словами рассказывает о проблеме доступности данных и о том, как Celestia пытается её решить. Информация, представленная в открытом доступе, либо разрознена, либо представляет собой техническую документацию, которая во многом непонятна для новичка или даже среднестатистического члена криптосообщества. Поэтому мы решили создать такой материал. Let's go!
Как мы все знаем, технология блокчейн изначально противопоставлялась традиционной банковской системе, а именно двум её качествам — централизации и необходимости доверять банковским институтам. Другими словами, все базы данных банка находятся в одном месте, а клиент напрямую не может удостовериться, что они ведутся надлежащим образом, и вынужден доверять банку и надеяться, что банк относится к своим обязанностям добросовестно. Технология блокчейн подразумевает децентрализованное хранение данных в общем доступе. Это значит, что каждый участник, установивший ноду, хранит полный реестр транзакций, произошедших в сети, и в любой момент может удостовериться в их подлинности. Тот факт, что участников могут быть сотни или тысячи, обеспечивает децентрализацию, а явный способ хранения предоставляет возможность любому участнику сети в любой момент времени убедиться, что записи о транзакциях существуют и верны.
Например, любой человек может проделать это, установив на свой ноутбук ноду Bitcoin — она достаточно нетребовательна к железу. Bitcoin представляет собой изначальное воплощение идеи криптовалют, в него заложена очень простая логика, а размеры блоков ограничены, поэтому даже сейчас нода биткоина весит относительно немного. Однако это работает далеко не для всех блокчейнов. По мере того как различные проекты пытались решать все новые и новые задачи, добавляя в свои сети возможность исполнять смарт-контракты, увеличивая пропускную способность сети и скорость осуществления транзакций, размер данных для хранения нодой постоянно увеличивался.
В настоящий момент никого не удивишь тем, что для запуска полной ноды или ноды валидатора требуется выделенный мощный сервер с приличным запасом памяти. Очевидно, что пользователь, обращающийся к блокчейну с домашнего компьютера или мобильного телефона, не может позволить себе иметь полную ноду. Как же быть в таком случае? Казалось бы, очевидным ответом было бы обращаться к блокчейну опосредованно через тех пользователей (например, валидаторов), кто гарантированно имеет полную ноду. Но на самом деле это плохое решение, потому что оно нарушает один из двух главных принципов блокчейна, а именно — теперь рядовой пользователь вынужден доверять операторам полных нод. Естественно, для сферы криптовалют такая ситуация является недопустимой.
Как мы знаем, каждый блок в цепи состоит из двух частей: block header и transaction data. В block header представлены метаданные блока, базовые сведения о нем, а также древо Меркла (хэшей). Transaction data занимает большую часть блока и состоит из транзакций, заключенных в данном блоке. Огромная разница в памяти, которую занимают block header и transaction data, породила идею, что можно реализовать два типа нод: полные ноды и легкие клиенты. Полные ноды загружают блок целиком и проверяют достоверность каждой транзакции в нем. С одной стороны, для этого требуется много ресурсов и сотни гигабайт дискового пространства, однако это самые безопасные узлы, так как их невозможно обманом заставить принять блоки с недействительными транзакциями. Легкий клиент не загружает и не проверяет транзакции. Вместо этого он загружает только block header и предполагает, что блок содержит только действительные транзакции. Кажется уже лучше, однако не идеально, потому что легкий клиент все еще предполагает, что блок содержит только действительные транзакции.
Неполную осведомленность легкого клиента можно использовать для data withholding attacks. Атаки с сокрытием данных могут осуществлять злонамеренные валидаторы, которые голосуют за добавление в цепочку блока, содержащего недействительные или отсутствующие транзакции. В то время как полные ноды сразу видят, что блок содержит ошибку, легкие клиенты могут быть обмануты, поскольку они смотрят только на заголовки блока, которые частично написаны валидаторами.
Безусловно, чтобы устранить данную уязвимость, легкие клиенты могут загрузить полную информацию о блоке и проверить его валидность, однако это автоматически превратит их в полный клиент, что противоречит самой идее их существования. И вот в этот момент вступает в игру решение, которое предлагает проект Celestia.
Что такое доступность данных и чем доступность данных отличается от их наличия? Давайте проведем простую аналогию с банком и деньгами. Наличие данных (data storage) будет похоже на ситуацию, когда вы всегда носите с собой все имеющиеся накопления. С одной стороны, это удобно — в любой момент вы можете взять свои деньги в руки, пересчитать и убедиться, что с ними все в порядке. Если накоплений у вас немного, то такой подход работает неплохо. А что если для их переноски уже нужна спортивная сумка или небольшой грузовик? Тогда разумным будет поместить деньги в банк, чтобы вам не пришлось носить их с собой. В этом случае с помощью приложения банка или выписки со счета вы в любой момент можете убедиться, что ваши деньги а) существуют и б) вы можете их получить в любой момент, что уже близко к концепции доступности данных (data availability). Примерно тот же самый подход осуществляет Celestia при хранении данных блокчейна, за тем лишь исключением, что она не только дает ответ на вопрос о существовании и доступности данных, но также предоставляет механизм, который позволяет даже легкому клиенту достоверно убедиться в их наличии. По аналогии с банком, если бы каждый раз, когда вы запрашиваете свой баланс, вам бы также показывали ваши деньги.
Давайте теперь разберемся, как именно Celestia позволяет убедиться в наличии и целостности данных. На самом деле здесь вовлечен анализ вероятностей, однако на самом базовом уровне нам опять же поможет простая аналогия. Исходя из того факта, что на вопрос о доступности данных мы можем получить всего два ответа — да и нет, мы можем сравнить подобный запрос с подбрасыванием монеты, так как у этого события тоже два возможных исхода — монета может упасть либо орлом, либо решкой.
Предположим, что у нас есть две монеты — одна обычная, а вторая падает только орлом вверх. Изначально мы не знаем точно, какая монета выпадает только орлом, и нам нужно это определить. Возникает вопрос — если мы подбрасываем монету и она выпадает только орлом, сколько раз мы должны это сделать, чтобы быть твердо уверенными, что перед нами лежит монета, которая выпадает только орлом?
Ответ дает базовая теория вероятности. Мы знаем, что для обычной монеты вероятность упасть орлом вверх составляет 50% или 1/2. Каждый бросок монеты — независимое событие, поэтому вероятность того, что монета выпадет орлом два раза подряд — 1/2 * 1/2, три раза подряд — 1/2 * 1/2 * 1/2, и так далее. В общем случае можно записать эту формулу как 1/2 ^ n, где n — число подбрасываний. Нетрудно убедиться, что вероятность того, что обычная монета 20 раз подряд упадет орлом вверх, практически равна нулю — в результате вычислений получается очень маленькое число, 9.54e-07. Соответственно, если мы подбросили монету 20 раз и она упала орлом вверх, с вероятностью практически 100% мы держим в руках монету, которая всегда падает орлом вверх.
Здесь следует вспомнить, что мы минимизируем вероятность атаки с сокрытием данных (data withholding attacks). Для понимания на общем уровне следует знать, что технология Celestia подразумевает обработку блока специальным образом перед его добавлением в сеть. В первую очередь, используя стирающий код (erasure code), размер блока увеличивается в 2 раза. Это не проблема, ведь его хранением будут заняты полные ноды, зато появляется возможность при утрате даже 50% информации из блока восстановить его полностью из оставшейся половины. Подобная технология применяется, например, в CD-дисках и позволяет их считывать, даже если поверхность поцарапана. На следующем этапе каждый блок разбивается на определенное количество сэмплов. Помните, мы не хотели, чтобы легкие клиенты загружали данные целого блока для того, чтобы убедиться, что они существуют и корректны? Давайте дадим им возможность загружать сэмплы. Используя эту возможность, а также вероятностный подход, описанный выше в эксперименте с монеткой, можно загрузив определенное количество сэмплов и убедившись, что с ними все в порядке, сделать вывод с вероятностью около 100% о том, что информация, находящаяся в остальном блоке, корректна.
Технология Celestia в текущем виде позволяет убедиться с вероятностью 99% в том, что данные доступны, загрузив всего 15 сэмплов, которые суммарно составляют всего 0,4% от размера всего блока. Загрузив еще 5 сэмплов и доведя общее количество до 20, можно быть уверенным в корректности всего блока с вероятностью практически 100%.
Таким образом, Celestia достигает первоначальную цель: легкие клиенты не должны доверять полным нодам, а могут самостоятельно убедиться в целостности и доступности данных, а опасность атак с сокрытием данных (data withholding attacks) уменьшается. С другой стороны, они все же должны загружать некоторое количество данных, однако весьма крошечное по сравнению с размером всего блока, что выглядит как компромисс, на который можно пойти.