Как будет работать Sharding в блокчейне Ethereum?
Шардинг (иногда шардирование) — это техника масштабирования при работе с данными. Суть его в разделении (партиционирование) базы данных на отдельные части так, чтобы каждую из них можно было вынести на отдельный сервер.
Существует два вида шардинга:
Таблицу users Вы оставляете на одном сервере, а таблицы photos и albums переносите на другой. В таком случае в приложении Вам необходимо будет использовать соответствующее соединение для работы с каждой таблицей.
В отличие от репликации, мы используем разные соединения для любых операций, но с определенными таблицами.
Есть два пути к распределению баз данных: репликация и сегментирование.
Горизонтальный шардинг – это разделение одной таблицы на разные сервера. Работает по следующему принципу:
На нескольких серверах создается одна и та же таблица (только структура, без данных);
Перед каждым обращением к таблице происходит выбор нужного соединения.
Допустим, наше приложение работает с огромной таблицей, которая хранит фотографии пользователей. Мы подготовили два сервера (обычно они называются шардами) для этой таблицы. Для нечетных пользователей мы будем работать с первым сервером, а для четных — со вторым. Таким образом, на каждом из серверов будет только часть всех данных о фотографиях пользователей.
При использовании шардинга сеть будет масштабироваться линейно при добавлении новых узлов;
Преимущество шардинга в уменьшении количества строк в каждой таблице (это уменьшает размер индекса. Тем самым повышает производительность поиска). Если сегмент данных разделен (Американские клиенты и Европейские), тогда можно легко и автоматически определить соответствующее членство в сегменте и запросить только нужный сегмент данных.
Периодически система будет проверять зарегистрированных валидаторов и ставить в очередь тех, кто сжег ETH в контракте;
Проверка требуется для смешивания всех валидаторов, чтобы обеспечить псевдослучайную случайность;
На каждом осколке будут узлы, которые смогут создавать новый / следующий шард;
Новый шард должен соответствовать определенным параметрам: 1. Предыдущий шард был номер 9, значит этот шард будет номер 10;
2. Получить информацию о текущем состоянии шарда перед получением новых транзакций;3. Информация о том, каким будет состояние шарда после получения всех транзакций;
4. Подписи (2/3) все валидаторов должны подтвердить транзакцию; (Число подписывающих валидаторов – 111);
Например, схема сегментирования на Ethereum может поместить все адреса, начинающиеся с 0x00 в один шард, все адреса, начинающиеся с 0x01 в другой шард, и т.д. В простейшей форме сегментирования каждый сегмент также имеет свою собственную историю транзакций.
Куда можно масштабироваться дальше?
Далее идет сверхквадратичная схема шардов (шард, который находится в другом шарде).
В протоколе будет работать главная сеть PoS, которая хранит и управляет текущим набором активных валидаторов PoS. Чтобы стать валидатором, требуется отправить транзакцию по сети PoW размером в 32 ETH. После этого действия, сразу после того, как в сети PoS запишется блок, вы станете в очередь на возможность стать активным валидатором, пока вы сами не перестанете быть валидатором, либо пока вас не удалят из сети за нарушение правил.
Каждый шард (например, всего может быть 1024 шарда) сам по себе является сетью PoS, а сеть шардов – то место, где будут храниться транзакции и балансы. Crosslinks (связь между шардами) служат для «подтверждения» сегментов, а также являются способом, с помощью которого разные шарды могут общаться друг с другом.
Что такое технология шардинг (sharding) для криптовалюты и блокчейна Ethereum?
Представьте себя в большой аудитории с 500 студентов, сдающими экзамен. Предположим, что наблюдает за процессом и оценивает работы группа из 50 преподавателей. Каждый должен проверить все работы, а конечный балл студента определяется среднеарифметическим оценок всех преподавателей. При таком подходе на проверку всех работ уйдет много времени. Очевидно, он совершенно неразумен и усложняется по мере увеличения числа студентов, сдающих экзамен.
Теперь представьте, что преподаватели поделят между собой всю работу. Каждый проверит ответы всего 10 студентов, и его оценка будет окончательной. Если он не уверен в своем анализе той или иной работы, он может обратиться за помощью к другим преподавателям.
Проблема масштабируемости и скорости транзакций
В настоящее время блокчейн Ethereum требует, чтобы все узлы в сети хранили и обрабатывали все происходящие транзакции. Такими образом, главная проблема блокчейна Ethereum связана с требованием полноты узлов. В то же время она обеспечивает повышенную безопасность, поскольку каждая транзакция проверяется всеми узлами. Это весьма напряженный и немасштабируемый процесс, и сообщество разработчиков Ethereum старается найти ему замену.
Чем больше число полных узлов, тем медленнее блокчейн. Разработчикам Ethereum приходится выбирать, какие из следующих трех требований удовлетворять в первую очередь:
В нынешнем состоянии технология полностью удовлетворяет первому и третьему требованию, однако страдает второе (масштабируемость). Раньше подобное положение вещей всех устраивало, однако времена изменились, и теперь низкая масштабируемость мешает массовому распространению криптовалюты. Разработчики Ethereum решили, что в таких условиях допустимо немного пожертвовать безопасностью, увеличить пропускную способность блокчейна и повысить скорость транзакций.
Решение проблемы
Представьте, что весь Ethereum разбит на тысячи островков. Каждый остров отвечает за конкретную область работы. У каждого острова свои уникальные функции, и все, что к нему относится (счета), могут взаимодействовать друг с другом и свободно пользоваться его функциями. Чтобы связаться с другими островами, придется воспользоваться неким протоколом.
В классическом смысле шардинг (sharding) — тип разбиения, который делит огромные базы данных на небольшие и быстрые кусочки, называемые шардами. По определению шард — это небольшая часть чего-то целого.
Интеграция этой концепции в блокчейн Ethereum — дело весьма запутанное и технически непростое. В этой статье описание процесса значительно упрощено (подробнее о нем можно узнать здесь). Сеть разбивается на множество частей, называемых шардами, каждый шард содержит определенную часть данных о транзакциях. С помощью этой технологии сообщество Ethereum пытается отказаться от требования полноты узлов. Шардинг будет проходить исключительно на уровне протокола.
После внедрения технологии каждый узел будет хранить подмножество данных и отвечать за проверку определенного набора транзакций, а не всех операций, последовательно выполняемых в блокчейне из-за непараллелизуемого характера виртуальной машины Ethereum.
Когда некоторому узлу потребуется информация, отсутствующая в его блоке, он найдет другой узел с нужными данными. Это исходное условие для взаимодействия между шардами.
В настоящее время блокчейн Ethereum позволяет проводить до 8 транзакций в секунду. После внедрения шардинга его пропускная способность возрастет до тысяч транзакций в секунду и позволит значительно уменьшить общий размер узла. Однако процесс нельзя назвать бездоверительным, а узлы — независимыми. Таким образом, чтобы повысить масштабируемость, приходится пожертвовать частью безопасности.
Proof-of-Stake критически важен для шардинга
В случае всего блокчейна, основанного на PoW, подобная атака практически невозможна из-за необходимой огромной вычислительной мощности. Чтобы ее получить, злоумышленникам придется потратить миллиарды долларов, и атака лишится экономического смысла.
В случае PoW-блокчейна с шардингом атака 51% вполне возможна и представляет реальную угрозу для безопасности сети. Злоумышленники могут сосредоточить силу на одном шарде и полностью поставить его под контроль. Затем с помощью протокола взаимодействия между шардами они могут атаковать другие части сети.
Для обеспечения безопасности, децентрализации и масштабируемости виртуальной машины Ethereum необходим переход на алгоритм Proof-of-Stake. PoS не даст хакерам сконцентрироваться на атаке одного шарда благодаря эффективному использованию случайной выборки. Система на основе Proof-of-Stake устранит опасность атаки 51%, которая останется, если Ethereum продолжит работать на алгоритме Proof-of-Work.
В случае блокчейна с шардингом, основанного на PoS, потенциальные злоумышленники не смогут выбрать определенный шард и заранее узнать, с каким участком сети будут работать. Подобный подход позволит устранить риски, связанные с внедрением шардинга.
Шардинг, от которого невозможно отказаться
А не пора ли нам шардить коллекции?
Не-е-е:
В принципе, для большинства проектов вcё оправдано. Это может быть еще прототип или круг пользователей ограничен… Да и не факт, что проект вообще выстрелит.
Откладывать можно сколько угодно, но если проект не просто жив, а еще и растет, то до шардинга он доберется. Одна беда, обычно, бизнес логика не готова к таким «внезапным» вызовам.
А вы закладывали возможность шардинга при проектировании коллекций?
Эта статья для продвинутых разработчиков.
Для тех, кто планирует шардинг своего кластера.
Для тех, кто уже шардировал кластер ранее, но админы все еще плачут.
Для тех, кто руками перемещал jumbo-чанки.
Сначала, мы будем учится жить со слонами.
Потом, мы их победим, но не сможем вернуться назад.
Всем привет, от команды разработки Smartcat и наших счастливых админов!
Мы разберём распространенный сценарий, который обычно мешает нам равномерно распределять данные. И опишем способ ослабления требований к ключу шардирования, который при этом не приведет к деградации производительности нашего кластера.
Зачем нам шардинг
Шардинг — штатная возможность горизонтального масштабирования в MongoDB. Но, чтобы стоимость нашего шардинга была линейной, нам надо чтобы балансировщик MongoDB мог:
Конечно, мало толку будет от нового шарда, если на него переместится только пара процентов данных или не дойдет нагрузка на CPU или update-трафик.
Особенности шардинга в MongoDB
Как мы знаем балансировщик MongoDB при отсутствии ограничений (превышение размера данных на шард, нарушение границ зон) выравнивает только количество чанков на шард. Это простой, надежный и сходящийся алгоритм.
Есть документация про лимиты количества чанков и про порядок выбора размещения чанка.
Этот алгоритм и определяет главные ограничения на балансируемые данные:
Самое значимое ограничение — гранулярность ключа шардирования.
Или, если сформулировать отталкиваясь от данных, на одно значение ключа должно приходиться мало данных. Где «мало» — это предельный размер чанка (от 1Mb до 1Gb) и количество документов не превышает вот эту вот величину.
К сожалению, в реальной жизни, не всегда удается подогнать модель данных под эти требования.
Бизнес логика требует слонов
Теперь давайте посмотрим, с чем мы будем сталкиваться при проектировании бизнес логики.
Я рассмотрю только самый чувствительный для шардирования случай, который заставляет наши данные группироваться в неравномерные объемы.
Рассмотрим следующий сценарий:
С другой стороны, если оставить в ключе только первое поле, то у нас «идеальное» линейное разделение нагрузки. Т.е. каждый запрос с полем projectId будет сразу отправлен на единственный шард. Поэтому имеет смысл остановиться на этом выборе.
Какие риски есть у этого выбора:
Оба этих случая несколько искажают KPI штатного балансировщика. В первом случае чанк вообще не перемещается. Во втором, он перемещается, но это не приводит к смещению данных. С течением времени, мы можем получить ситуацию когда число пустых чанков превышает число чанков с данными, а еще часть чанков не перемещаемые.
В общем, мы можем посмотреть текущее распределение данных или просто прикинуть развитие проекта и допустить, что хоть jumbo-чанки и будут появляться, но их должно быть не много.
Проблемы с масштабированием
Итак, мы, вопреки ожиданиям, набрали достаточно неперемещаемых чанков, чтобы это стало заметно. То есть буквально, случай из практики. Вы заказываете админам новый шард за X$ в месяц. По логам видим равномерное распределение чанков, но занимаемое место на диске не превышает половины. С одной стороны весьма странное расходование средств было бы, а с другой стороны возникает вопрос: мы что же, не можем прогнозировать совершенно рутинную операцию по добавлению шарда? Нам совсем не нужно участие разработчика или DBA в этот момент.
Что интересно, на этапе проектирования схемы данных, у нас и нет особого выбора. Мы не можем предсказать характер использования на годы вперед. А владельцы продукта очень не охотно формулируют строгие ограничения при проектировании. Даже оглядываясь назад, не всегда понятно, как можно было бы перепроектироваться, чтобы успеть все сделать тогда. Так что продолжаем работать с тем шардированием, которое заложили.
Ну, самое топорное решение — просто назначить зоны размещения коллекции на новые сервера, чтобы на старых остались только неперемещаемые чанки. Конечно, о предсказуемости занимаемого места речи не идет.
Еще можно увеличить максимальный размер чанка, но это глобальный параметр для всего кластера.
Можно попытаться перемещать чанки в ручную, но это может привести к блокировке данных на длительное время и все равно нет гарантии переноса.
Надеюсь, тут все уже запуганы и потеряли надежду. 😉
Решение
Попробуем сначала поправить основную боль администрирования.
Конечно, не хочется заново писать балансировку данных, нам надо просто «попросить» существующий балансировщик перекинуть часть чанков туда, где есть неиспользуемое место. Вариантов у нас два.
1-й воспользоваться командой moveChunk — прямое указание балансировщику о перемещении конкретного чанка.
2-й воспользоваться командой addTagRange — привязка диапазона значений ключа шардирования к некоторому шарду и их группе.
В обоих случаях потребуется также точное знание размера чанка. Это можно сделать командой dataSize, которая возвращает некоторую статистику по объектам в коллекции на заданном интервале ключей.
Предварительное прототипирование 1-го варианта выявило дополнительные особенности.
Команды moveChunk не отменяют работы штатного балансировщика. Он вполне может принять решение об обратном переносе. Тут надо блокировать работу штатного балансировщика. Или кроме перемещения больших чанков на недогруженный шард, надо искать на нем маленькие чанки и синхронно перемещать их на перегруженный шард.
Данные dataSize вычисляются «долго», и при этом устаревают. На практике получается, что надо просканировать некоторое количество чанков, прежде чем найдешь чанк больше среднего. В идеале, надо искать самые большие перемещаемые чанки, т.е. некоторые варианты распределения данных в коллекции могут нам значительно замедлить сканирование.
Массовые сканирования dataSize ухудшают отзывчивость сервера на боевых запросах.
Ну и остается тупиковая ситуация, когда все чанки кроме jumbo просто равны по размеру. В этом случае перемещать просто нечего, или опять же придется блокировать работу штатного балансировщика.
По совокупности проблем с прямой балансировкой, я решил развивать балансировку через привязку диапазона значений ключа шардирования.
Основная идея проста.
Давайте подберем такие диапазоны ключей на каждам шарде, чтобы в итоге части коллекции занимали одинаковый размер на шардах.
Диапазоны ключей привязываются к тегу, а не к шарду. А сам шард может содержать несколько тегов. Поэтому для упрощения дальнейшего описания и работы условимся, что на каждый шард мы добавляем по одному тегу с названием этого шарда. Это позволит привязывать диапазон ключей на конкретный шард.
Процесс выравнивания разделим на 2 основных этапа:
Первый этап — это предварительное разбиение. Оно по сути дефрагментирует данные на непрерывные отрезки на каждый шард.
Второй этап — коррекция границ ключей. Этот этап можно повторять периодически, ориентируясь по фактическому занимаемому месту на диске.
Группировка данных
Данные в шардированной коллекции разбиваются на чанки — интервалы значений ключа шардирования. При штатной работе, балансировщик распределяет чанки по шардам по мере разделения данных без учета их соседства.
Нам же, наоборот, нужно сгруппировать чанки по шардам так, чтобы на одном шарде все чанки принадлежали одному интервалу ключа шардирования. Это позволит разделять такие интервалы минимальным числом границ.
Итак, коллекция уже шардирована.
Первые 34 чанка будем размещать на sh0
Следующие 33 чанка разместим на sh1
Последние 33 чанка разместим на sh2
У каждого чанка есть поля min и max. По этим полям мы выставим границы.
Балансировщик начнёт перемещать чанки в указанные диапазоны.
А мы просто ждем окончания работы балансировщика. Т.е. когда все чанки займут свое место назначения. Ну за исключением jumbo-чанков конечно.
Коррекция размера
Продолжим пример выше и возьмем конкретные значения ключей. Первоначальная настройка будет выглядеть так:
Вот так будет выглядеть размещение чанков:
Командой db.demo.coll.stats() можно получить объем данных, которые хранятся на каждом шарде. По всем шардам можно вычислить среднее значение, к которому мы хотели бы привести каждый шард.
Вот так будет выглядеть смещение границы на один чанк
Вот пример команд для фиксации нового состояния границ в конфигурации кластера.
Мы сначала удаляем пару интервалов со старыми значениями границ, потом заводим новые интервалы с актуальными значениями границ.
После применения команд балансировщик самостоятельно переместит 34-й чанк на нужный нам шард. Конечно, нет необходимости менять границы после каждого сканирования чанка. Мы можем учесть полученный эффект, продолжить сканирование и сформировать уже итоговый пакет изменений границ. Таким образом, мы можем выровнять размер коллекции по шардам с точностью до максимального размера чанка.
Конечно, в процессе сканирования нам будут попадаться jumbo-чанки. Но ничего страшного, мы их просто игнорируем и переносим границу через него без учета эффекта от перемещения.
В общем случае, мы можем планировать произвольное распределений данных таких коллекций на шардах кластера.
Выгодные особенности этого подхода:
Дополнительные возможности
Вообще, на практике требуется выравнивание используемого объема диска на шардах, а не только части шардированных коллекции. Частенько, нет времени или возможности проектировать шардирование вообще всех БД и коллекций. Эти данных лежат на своих primary-shard. Если их объем мал, то его легко учесть при коррекции размера и просто часть данных оттащить на другие шарды.
С течением времени, особенно после частых удалений, будут образовываться пустые чанки. Не то чтобы они теперь сильно мешают, но их может быть сильно больше чанков с данными. Чтобы они не заставляли страдать роутер, было бы хорошо их прибрать. Раньше (до дефрагментации) их надо было найти, переместить к другому чанку-соседу на один шард, потом запустить команду mergeChunks. Перемещение нужно, т.к. команда объединяет только соседние чанки на одном шарде.
Есть даже скрипты для автоматизации, но они долго работают, и есть один тикет с печально низким приоритетом.
Теперь все значительно проще. Соседние чанки и так на одном шарде. Можно объединять хоть весь интервал целиком. Если он конечно без jumbo-чанков, их надо исключить. Есть на интервале пустые чанки или нет, это уже не важно. Балансировщик заново сделает разбиение по мере добавления или изменения данных.
Почти итог
Итак, проблема решена.
Хорошо, что не пришлось заменять или сильно вмешиваться в работу штатного балансировщика. Он продолжает рулить другими коллекциями или диапазонами данных. А в наших настроенных диапазонах он выполняет разделение чанков и таскает чанки между серверами как мы попросим.
Но это было бы слишком скучно… Время победить слонов и не вернуться!
Победа над слонами!
Как мы уже отмечали, единственная причина неперемещаемых чанков — недостаточная селективность ключа шардирования. Мы сами снижали селективность ключа для привязки запроса к шарду. Но мы уже сгруппировали данные, а теперь мы можем этим коварно воспользоваться!
Вспомним пример модели:
Ранее мы выбрали ключ шардирования
А если вы пользуетесь MongoDB версии 4.4 и выше, то там есть удобная функция — уточнение ключа шардирования на существующих данных.
Данные дефрагментированы, а это дает нам гарантии того, что основной объем документов работ с одинаковым projectId будет находиться на одном шарде. Как это выглядит на практике?
Вот иллюстрация примеров размещения работ по чанкам. В случае, если мы выбрали ключ шардирования
Планировщик запросов MongoDB отлично справляется с исключением из плана запроса тех шардов, на которых точно нет нужных данных.
Например, поиск по условию
Т.е. мы берем условия исходной задачи, и практически полностью убираем все недостатки решения с составным ключом шардирования.
Теперь переформулируем для более общего случая.
У нас есть составной ключ шардирования. По первому полю нам требуется группировка, но оно слабоселективное. Второе поле, нужно просто чтобы увеличить общую селективность ключа.
С помощью дефрагментации, мы добиваемся следующих свойств:
Больше одно шардовых запросов, меньше лишней нагрузки на чтение, меньше дополнительных реплик!
Мало нам было бы радости, но с таких сильно селективным ключом мы и от jumbo-чанков избавляемся.
И вот теперь, от дефрагментации данных нам уже никуда не деться.
Точно итог
Изначально мы хотели просто выровнять коллекций по шардам.
По пути избавились от jumbo-чанков.
В итоге, мы можем поднять долю одно шардовых запросов, при этом не добавляя в условия запросов дополнительных полей.
Теперь уже можно оценить достижения и потери.
Достижения:
Осталось спроектировать весь процесс дефрагментации, расчета поправок и коррекции границ… Ждите!
Что такое шардинг?
Что такое шардинг?
Шардинг — метод разделения и хранения единого логического набора данных в виде множества баз данных. Другое определение шардинга — горизонтальное разделение данных.
Когда и кто изобрел шардинг?
Концепция шардинга применялась в управлении традиционными централизованными базами данных с конца 1990-х годов. Термин «шард» (фрагмент) получил распространение благодаря одной из первых многопользовательских ролевых онлайн-игр, Ultima Online, в которой разработчики распределили игроков по различным серверам (разным «мирам» в игре), чтобы справиться с трафиком.
Популярный сценарий применения шардинга в бизнесе — разделение базы данных пользователей по географическим локациям. Пользователи, относящиеся к одной географической локации, объединяются в одну группу и размещаются на уникальном сервере.
Что такое шардинг в контексте блокчейна?
Блокчейн — это база данных с нодами, представляющими индивидуальные серверы. Применительно к блокчейну, шардинг подразумевает разделение сети блокчейна на индивидуальные сегменты (шарды). Каждый шард содержит уникальный набор смарт-контрактов и балансов счетов.
За каждым шардом закрепляется нода, верифицирующая транзакции и операции, в отличие от схемы, в которой каждая нода отвечает за верификацию каждой транзакции во всей сети.
Разделение блокчейна на более управляемые сегменты позволяет увеличить пропускную способность транзакций и тем самым решить проблему масштабируемости, с которой сталкивается большинство современных блокчейнов.
Как работает шардинг?
Объяснение на примере Ethereum:
Блокчейн Ethereum состоит из тысяч компьютеров или нод, каждая из которых «одалживает» сети определенный объем хешрейта. Именно этот хешрейт позволяет Ethereum Virtual Machine (EVM) функционировать — выполнять смарт-контракты и управлять децентрализованными приложениями (DApps).
В настоящее время Ethereum работает на основе последовательного выполнения, в котором каждая из нод должна рассчитывать каждую операцию и обрабатывать каждую транзакцию. Поэтому прохождение транзакцией верификационного процесса требует значительного времени: Ethereum осуществляет приблизительно 10 транзакций в секунду, тогда как у Visa, например, этот показатель в районе 24 000.
Добавление к сети компьютеров не обязательно повышает эффективность, поскольку весь реестр хранится на каждом устройстве, и цепь верификации просто становится длиннее.
Идея шардинга состоит в том, чтобы отказаться от модели, в которой каждая нода должна вычислять каждую операцию, в пользу модели параллельного выполнения, в которой ноды обрабатывают только определенные вычисления. Это позволяет параллельно обрабатывать множество транзакций.
Блокчейн разделяется на отдельные шарды (поддомены или сегменты). Ноды управляют только той частью реестра, к которой они прикреплены (выполняют процессы и подтверждают транзакции), а не поддерживают весь реестр.
Какие проблемы решает шардинг?
Шардинг — потенциальное решение проблемы масштабирования.
Чем популярнее становится блокчейн, тем больше пользователей инициируют транзакции, запуск децентрализованных приложений и другие процессы в сети. В результате, скорость транзакций падает, что препятствует расширению блокчейна в долгосрочной перспективе. Рост транзакционной активности требует от нод интенсифицировать процесс верификации транзакций. Существует угроза того, что эти блокчейны могут «закупориться», как это произошло с Ethereum в период бума CryptoKitties, когда на долю игры приходилось 11% транзакций сети.
Если группы нод отвечают за индивидуальные сегменты, то каждой ноде не нужно поддерживать весь реестр для выполнения каждой операции. Поэтому валидация транзакций может осуществляться параллельным, а не линейным образом, что повышает скорость сети. Таким образом решается проблема масштабирования.
Каковы недостатки шардинга?
Основные проблемы шардинга — коммуникация и безопасность. Если разделить блокчейн на изолированные сегменты, то каждый шард станет отдельной сетью. Пользователи и приложения одного поддомена не смогут коммуницировать с пользователями и приложениями другого поддомена, не применяя особый механизм коммуникации.
В сегментированном блокчейне также возникает проблема безопасности, поскольку хакерам легче захватить один шард — по причине меньшего хешрейта, требуемого для контроля индивидуальных сегментов (так называемая атака 1%).
После захвата сегмента атакующие могут направить недействительные транзакции в основную сеть. Также данные в этом конкретном сегменте могут стать недействительными и оказаться безвозвратно утрачены. Ethereum предлагает решение в виде рандомизированной выборки — протоколы шарда случайным образом назначаются в различные секции для подтверждения аутентификации блоков.
Каковы альтернативы шардингу?
Разработчики предложили два решения, позволяющих повысить производительность и скорость транзакций в блокчейнах.
Первое решение — увеличение размера блока. Ключевая идея — чем больше размер блока, тем больше транзакций можно поместить в него и, следовательно, тем больше число транзакций в секунду.
Однако чем больше блок, тем больше вычислительной мощности необходимо для его верификации. Если размер блока увеличить значительно, то лишь наиболее мощные компьютеры смогут управлять вычислительной мощностью, необходимой для деятельности в качестве нод.
Высокая стоимость такого компьютерного оборудования означает, что пулы нод неизбежно станут меньшего размера и более централизованными, что повышает риск атаки 51%. Увеличение размера блока также требует хардфорка, который грозит расколом сообщества: если не все пользователи примут обновление, то возникнут две разные цепи, использующие разные монеты. Увеличение размера блока не может быть долгосрочным решением.
Второе предложение — использовать альткоины с тем, чтобы различные функции и приложения были реализованы на собственных сетях с собственными монетами.
Такая модель повысит производительность, поскольку единый блокчейн не будет перегружен, но также увеличит риски безопасности, поскольку вычислительная мощность будет распределена по нескольким блокчейнам. Опять же, риск взлома сети возрастет и потому, что вычислительная мощность, необходимая для осуществления атаки 51%, будет гораздо меньше.
Кто использует шардинг?
Zilliqa — первая платформа, внедрившая шардинг. На стадии тестнета она сумела достичь показателя в 2828 транзакций в секунду.
Экосистема блокчейна Near позволяет разработчикам создавать и применять децентрализованные приложения. Near называет себя «шардированным блокчейном на PoS» и утверждает, что его технология шардинга позволяет нодам оставаться достаточно небольшими для того, чтобы функционировать на устройствах невысокой производительности — потенциально даже на мобильных телефонах.
Ethereum предлагает экосистему блокчейна для внедрения DApps на основе смарт-контрактов. Ethereum Foundation планирует включить шардинг в обновленную версию протокола Ethereum 2.0.
Среди прочих работающих с шардингом проектов: Cardano, QuarkChain и PChain.
Каково будущее шардинга?
Технология шардинга фигурирует в white paper цифровой валюты Libra. В преддверии запуска компания Facebook приобрела компанию Chainspace, чья команда разработчиков специализируется на шардинге. Конкретные детали пока неизвестны, но можно предположить, что в блокчейн Libra внедрят разновидность шардинга.
Шардинг теоретически может стать решением так называемой трилеммы блокчейна.
Трилемма блокчейна, как пояснил Виталик Бутерин, состоит в том, что одновременно можно сохранять только две из трех ключевых особенностей блокчейна — безопасности, децентрализации и масштабируемости. Если преодолеть сложности, с которыми сталкивается шардинг, то можно будет масштабировать распределенные сети, не жертвуя децентрализацией или безопасностью.
Подписывайтесь на новости Forklog в Facebook!
