работа. достиг 328,19 гб

• Название: достиг 328,19 гб
• Дата: 07.10.2022
• Размер: 0.66 Mb.
• Имя файла: работа.docx
• Тип: Протокол; #719983
• страница: 2 из 4

Схемы систем хранения блокчейн

Блокчейн — это, по сути, распределенная база данных, в которой масштабируемость является ключевым барьером, и она широко используется в реальных бизнес-средах. Масштабируемость систем Blockchain включает в себя три вопроса: пропускная способность, емкость хранилища и сетевое взаимодействие [ 19 , 20 , 21 , 22 , 23 ]. В этой статье основное внимание уделяется масштабируемости систем хранения Blockchain. Полная избыточность данных блокчейна призвана гарантировать характеристику децентрализации, но создает большую нагрузку на узлы и вызывает проблему масштабируемости систем хранения блокчейна, что наносит ущерб децентрализации, как мы обсуждали в разделе 2.1. 1. Масштабируемая система хранения Blockchain должна правильно справляться с противоречием между избыточностью данных и характеристикой децентрализации. В связи с этим мы разделяем существующие схемы систем хранения Blockchain на три типа, а именно, совместное хранение нескольких узлов, сокращение данных и сегментирование, исходя из их подхода к уменьшению избыточности данных и всесторонне оцениваем их в разделах. 3.1 – 3.3 , с акцентом на подходы, степень децентрализации и надежность данных.

Схемы хранения с несколькими узлами совместного хранения

Проблема масштабируемости систем хранения Blockchain возникает из-за использования полных узлов, а использование неполных узлов просто для уменьшения избыточности данных. Были предложены схемы хранения, состоящие из нескольких типов узлов.

SSFL: схема хранения с полными узлами и облегченными узлами

Когда Сатоши Накамото впервые предложил новый термин «Блокчейн», он уже понимал, что постоянно увеличивающийся объем данных Блокчейн вызовет проблему масштабируемости хранилища. Чтобы решить эту проблему, он предложил тип узла, который хранит только заголовок блока для экономии ресурсов хранилища. Этот тип узлов называется легкими узлами, которым требуется всего 80 байт дискового пространства для каждого блока. Поскольку транзакций, хранящихся локально, нет, функция проверки транзакций находится под вопросом. Облегченные узлы предназначены для проверки платежей, которые являются транзакциями с участием самого узла, путем получения хэша платежа, корня Меркла и соответствующего пути дерева Меркла из полных узлов, а затем выполнения вычисления хэша. Этот метод проверки известен как упрощенная проверка платежа (SPV) [9 ] для биткойнов. Эфириум, эквивалентный SPV, называется протоколом легкого клиента [ 10 ].

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

SSFL приносит новые проблемы. (1) В блокчейне есть два типа узлов: полные узлы и облегченные узлы, что приводит к неэквивалентности узлов. (2) Можно предвидеть, что большое количество полных узлов с ограниченными ресурсами хранения будет вынуждено быть облегченным узлом, чтобы участвовать в системах Блокчейн, что увеличит время поиска, а также значительные накладные расходы на связь во время платежа. процесс проверки.

SSFE: схема хранения с полными узлами и расширенными облегченными узлами.

Недостатком легковесных узлов является то, что они могут только проверять платежи, а это крошечная часть всех транзакций для узла. Усовершенствованный облегченный узел (расширенный узел SPV) или узел ESPV [ 24 ] предлагается, чтобы позволить узлу хранить небольшую часть данных блокчейна, при этом имея возможность проверять большинство транзакций. Схема хранения, состоящая из полных узлов и расширенных облегченных узлов, называется SSFE. В соответствии со временем генерации блока ESPV делит блоки на новые блоки и старые блоки, сохраняет все новые блоки в течение заданного временного окна для расширения основных функций, частичные старые блоки в соответствии со стратегией сегментирования [ 25 ] для обеспечения надежности данных и уменьшения требования к хранению. Аналогично, группа виртуальных блоков (VBG) [ 26] хранит частичные данные блокчейна на каждом узле, гарантируя безопасность и надежность данных, а индекс хранения VBG разработан для повышения эффективности запросов. В то время как масштабируемая модель хранения для блокчейна на основе учетных записей (SSMAB) [ 27 ] сохраняет данные состояния полностью избыточным способом, чтобы гарантировать функцию проверки транзакций, хранит блочные данные в сегментном хранилище для уменьшения избыточности и использует механизм экономических стимулов для обеспечения доступности данных. при снижении потребления памяти.

SSFE снижает нагрузку на узлы при хранении, наделяет узлы ESPV базовыми функциями и повышает степень децентрализации по сравнению с SSFL. По мере того, как все больше и больше узлов ESPV присоединяются к системе Blockchain и хранят как можно больше старых данных Blockchain, SSFE может в конечном итоге превратиться в идеальные масштабируемые системы хранения Blockchain, которые имеют только один тип узла. Таким образом, может быть реализована функциональная эквивалентность узлов и децентрализация систем Блокчейн. Таким образом, разработка эффективного механизма стимулирования хранения для регулирования объема данных, хранящихся на узлах ESPV, является будущим направлением исследований.

SSCD: схема хранения с архитектурой облачной росы

Dewblock [ 28 ] — еще одна схема, пытающаяся наделить узлы, развернутые на устройствах с ограниченными ресурсами, базовыми функциями за счет использования росистых вычислений [ 29 ] и архитектуры облачной росы [ 30 ].]. Росистые вычисления — это парадигма организации программного и аппаратного обеспечения локального компьютера в среде облачных вычислений, где локальный компьютер обеспечивает функциональность, независимую от облачных служб, а также взаимодействует с облачными службами. Цель росистых вычислений — полностью реализовать потенциал локальных компьютеров и облачных сервисов. Dewblock состоит из облачного сервера и росистого сервера, где облачный сервер можно рассматривать как полный узел, развернутый в общедоступной или частной облачной службе, а росистый сервер может работать в одном из двух режимов: росистый режим и полный режим. . Когда сервер росы находится в режиме росы, он ведет себя как облегченный узел, известный как клиент росы. Облачный сервер и клиент росы составляют единый узел Dewblock. Когда сервер росы находится в полном режиме, он ведет себя так же с полным узлом, и мы называем сервер росы полноценным клиентом. В этом режиме сам сервер росы представляет собой полный узел Dewblock, а облачный сервер в работе не участвует.

По сути, SSCD состоит из полных узлов (облачных серверов), работающих в облаке, и облегченных узлов (серверов росы). Противоречие между избыточностью данных и характеристикой децентрализации, а также проблема достоверности данных на SSFL все еще существует. Чтобы убедиться, что учетная запись на сервере росы соответствует учетной записи на облачном сервере, сервер росы будет периодически отправлять информацию своей учетной записи на облачный сервер для проверки, что влечет за собой накладные расходы на связь.

ESS: эластичная схема хранения

Разница между SSFE и SSCD заключается в том, что они используют разные подходы к наделению узла с ограниченными ресурсами хранения базовыми функциями. SSFE использует совместное хранилище, а SSCD использует росистые вычисления. Эластичная цепь [ 31] также использует подход к совместному хранению, но имеет гораздо более сложный механизм. Узлы хранения хранят части полной цепочки в соответствии с предпосылкой обеспечения безопасности данных блокчейна с помощью алгоритма регулирования коэффициента дублирования. Чем раньше генерируется блок, тем меньше копий сохраняется, и наоборот. Узлы проверки периодически проверяют надежность узлов хранения и записывают их в цепочку доказательств надежности (POR), чтобы гарантировать, что осколки всегда хранятся на узлах хранения с хорошей стабильностью, а местоположения дубликатов данных организованы как цепочка позиций (P), хранящаяся на пользовательских узлах. Когда пользовательский узел запрашивает данные блокчейна, он сначала обращается к цепочке P на локальном диске, чтобы получить место хранения данных. Затем, согласно информации о местонахождении, пользовательский узел находит соответствующие узлы хранения и запрашивает их вернуть данные зашифрованного текста пользовательскому узлу. Наконец, он восстанавливает зашифрованный текст на основе ключа, который сохраняется локально и генерируется методом POR, а затем получает исходные данные.

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

Несмотря на то, что ESS снижает нагрузку на хранилище на полных узлах, все еще существуют следующие проблемы. (1) ESS включает в себя три типа узлов-пользователей, узлы хранения и узлы проверки, а также два типа цепочек — цепочку POR и цепочку P. По сравнению с другими схемами хранения ESS более сложна, а неэквивалентность узлов более серьезна. (2) Из приведенных выше рассуждений следует, что процесс запроса данных сложен и требует больших затрат на связь.

CCSS: кластерная схема совместного хранения

Совместное хранилище в SSFE и ESS находится на системном уровне. CCSS распределяет блоки между узлами с помощью Distributed Hash Table (DHT) [ 32 ] и позволяет совместное хранение на уровне кластера. Узлы в кластере DHT могут вести себя как полные узлы, не удерживая всю цепочку блоков. Каждый узел в кластере содержит частичные данные блокчейна, назначенные в соответствии с алгоритмом DHT. При проверке новых транзакций и блоков узел запрашивает блоки в своем кластере DHT. Другими словами, каждый узел может проверять новые транзакции и блоки, сотрудничая с другими узлами в своем кластере. Для снижения нагрузки хранилища на узлы и задержки распространения сети используется метод балансировки нагрузки на основе кластера DHT [ 33 ].] предлагается, где DHT реализуется Kademlia. Эта схема хранения состоит из двух типов узлов, а именно узлов майнинга и узлов данных, где узлы майнинга выполняют работу распределенного соглашения по PoW (доказательство работы), узлы данных проверяют транзакции и блоки. Процедура обработки состоит из двух этапов: этапа сбора транзакций и этапа генерации и проверки блока.

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

Однако, согласно своему принципу, когда новый узел присоединяется к кластеру, CCSS автоматически корректирует данные, хранящиеся на исходном узле, и перераспределяет данные на новый узел, который занимает полосу пропускания связи в кластере и увеличивает коммуникационные издержки.

Сжатие данных

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

Сжатие блоков использует методы кодирования для сжатия данных блокчейна.

Хранилище кода стирания [ 34 ] вводит новый тип узла, называемый узлом с низким уровнем хранения на основе кода стирания, с целью предложить альтернативу между легкими узлами и полными узлами. Этот тип узла использует коды стирания, чтобы пользователи с ограниченной емкостью хранилища могли вносить свой вклад в блокчейн, не сохраняя при этом весь блокчейн. Кодирование стирания [ 35] разбивает данные Blockchain на несколько фрагментов, строит линейные комбинации среди этих фрагментов, а затем сохраняет эти закодированные фрагменты в узлах. Чтобы сгенерировать его закодированные фрагменты, разобьем исходный блок на фрагменты. Когда узлу необходимо запросить определенный блок, он получает соответствующую линейную комбинацию и выполняет обратную операцию для восстановления блока. По сравнению с хранением несжатых данных Blockchain на полном узле, этот подход может уменьшить количество резервных копий и требования к хранилищу при тех же показателях доступности данных. Коды стирания включают в себя линейную комбинацию и обратную операцию и несут дополнительные вычислительные затраты. Схема хранения применима к холодным данным, и экономия на хранении ограничена. Точно так же Дай и соавт. [ 36] предложить распределенное хранилище на основе сетевого кодирования (NC-DS) для блокчейна, чтобы решить проблему масштабируемости хранилища. Его основная идея состоит в том, чтобы разделить данные блокчейна на k пакетов одинаковой длины, закодировать их в n пакетов и сохранить каждый из них в узле. Метод кодирования гарантирует, что произвольные k из n пакетов смогут восстановить исходные данные. Однако существуют недостатки. (1) Учитывая характеристики блокчейна, что количество участников нельзя оценить заранее, трудно получить соответствующие значения параметров метода кодирования. (2) Манипуляции с данными блокчейна должны иметь дело с целостностью и безопасностью данных, поскольку разные узлы хранят разные закодированные пакеты.

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

Основываясь на выборочном сокращении транзакций в блокчейне, Palm et al. [ 37 ] представляет подход, который позволяет узлу независимо выбирать и удалять любые уже примененные транзакции, чтобы уменьшить размер реестра. В отличие от существующих подходов к стиранию, пытающихся стереть данные глобально со всех узлов, Florian et al. [ 38 ] предлагают прагматичное решение для локального стирания, которое позволяет операторам узлов удалять проблемные транзакции из локального хранилища с минимальным влиянием на их способность поддерживать сеть и автономно проверять дальнейшие транзакции для блокчейна на основе UTXO. Кроме того, Mini-Blockchain [ 39 ], Rollerchain [ 40 ] и протокол Blockchain на основе сегментирования [ 41 ].] также используйте стратегию обрезки для экономии ресурсов хранилища.

Ethereum использует подсчет ссылок [ 42 ] для отслеживания листовых узлов в дереве состояний, обрабатывает данные без ссылок в последних 5000 блоков как недопустимые данные и безвозвратно удаляет их из базы данных. Точно так же Monero [ 43 ] удаляет ненужную информацию, включая адреса учетных записей, кольцевые подписи и другие данные блокчейна, чтобы сохранить ресурсы хранения в соответствии с заранее определенным правилом, исходя из предпосылки обеспечения безопасности данных блокчейна. Джидар [ 44], новый метод упрощения данных для Биткойн, предлагает, чтобы узлы хранили только интересующие транзакции и связанные с ними ветки Merkle. Когда отправитель транзакции проверяет транзакцию, он должен предоставить ветви Merkle, связанные с вводом транзакции в сеть, вместе с информацией о транзакции, чтобы обеспечить функцию проверки транзакции узлов. Если узлы должны получить полный блок, им необходимо полагаться на механизм стимулирования для запроса данных от других узлов и интеграции всех фрагментов.

Чтобы снизить нагрузку на узлы, связанные с хранилищем, Биткойн предлагает сокращение блочных файлов [ 45 ]. Узлы сохраняют только индекс UTXO и последние 288 блоков после синхронизации с последними данными блокчейна. Как только в сети или в локальных данных блокчейна возникают ошибки, узлы должны повторно синхронизировать все данные блокчейна для построения индекса UTXO. Риск повторной синхронизации увеличивается с ростом объема данных Blockchain. Неэквивалентность узлов все еще существует, а децентрализация будет ослаблена.

Подводя итог, можно сказать, что приведенные выше схемы хранения, связанные с отсечением блокчейна, основаны на удалении бессмысленных или незначительных исторических данных для снижения нагрузки на узлы при хранении. Однако эти схемы хранения не соответствуют требованиям масштабируемых систем хранения Blockchain. (1) Сокращение блокчейна в настоящее время применимо к публичному блокчейну. По сравнению с общедоступным блокчейном области применения разрешенного блокчейна более разнообразны, типы данных более сложны, и сложнее определить, являются ли исторические данные недействительными. (2) Неэквивалентность узлов существует. (3) Подлинность проверки транзакции вызывает сомнения, поскольку информация о транзакции зависит от отправителя транзакции. (4) Полные узлы должны иметь возможность поддерживать полные данные блокчейна, и, следовательно, схемы хранения могут лишь незначительно снизить давление при хранении. (5) Трудно определить важность исторических данных без практического применения. Таким образом, удаление данных вслепую для экономии места для хранения не способствует поддержанию надежности данных систем Blockchain, что также противоречит автономии Blockchain.

Разделение

Основная идея сегментирования [ 25 ] — это стратегия «разделяй и властвуй», которая разделяет узлы на несколько блоков для параллельной обработки транзакций или поддержания разрозненных регистров блокчейна. Первый называется сегментированием транзакций [ 46 , 47 ], а последнее называется шардингом состояния [ 48 , 49 ]. Разделение транзакций реализует параллельную обработку транзакций и обеспечивает почти линейное увеличение пропускной способности транзакций. Однако каждый узел по-прежнему должен хранить полные данные блокчейна. Разделение состояния хранит часть блочных данных сегмента, чтобы уменьшить нагрузку на хранилище и вычисления.

Схемы серверного хранения [ 24 , 26 , 27 , 31 , 32 , 33 ], обсуждаемые в разд. 3.1 и 3.2 в качестве вспомогательного метода используют сегментацию состояния. Основная идея заключается в том, что узлы хранят частичные данные [ 24 , 26 , 27 , 31 ] или все узлы кластера взаимодействуют для хранения полных данных блокчейна [ 32 , 33 ]. По сравнению с общим шардингом [ 46 , 47 , 48 , 49], эти схемы хранения не меняют механизм консенсуса и сохраняют надежность и безопасность исходной системы Blockchain.

В заключение, хотя общие стратегии сегментирования снижают нагрузку на хранилище в системах Blockchain, у них есть три ограничения. (1) Частые накладные расходы на межсегментную связь увеличат нагрузку на полосу пропускания, продлят время подтверждения транзакции и, в конечном итоге, снизят доступность данных и постоянство систем Blockchain. (2) Основная проблема с сегментированием заключается в обеспечении согласованности между несколькими сегментами, особенно в случае межсегментных транзакций, которые требуют больших коммуникационных издержек. (3) Также очень сложно выбрать подходящий размер осколка; большой размер сегмента может повлиять на производительность византийских алгоритмов консенсуса, в то время как маленький размер сегмента не только плохо влияет на масштабируемость из-за большого количества транзакций между сегментами, но и угрожает безопасности систем Blockchain.