Масштабирование блокчейнов с использованием данных вне цепочки

Переиздано Платоном

Читают: 0

Когда хеш стоит миллион слов

К настоящему времени ясно, что многие случаи использования блокчейна не имеют ничего общего с финансовыми транзакциями. Вместо этого цель цепочки состоит в том, чтобы обеспечить децентрализованную агрегацию, упорядочение, временные метки и архивирование любой тип информации, включая структурированные данные, корреспонденцию или документацию. Основная ценность блокчейна заключается в том, что его участники могут согласованно и постоянно договариваться о том, какие именно данные были введены, когда и кем, не полагаясь на доверенного посредника. Например, недавно запущенный SAP блокчейн платформа, которая поддерживает MultiChain и Hyperledger Fabric, предназначена для широкого спектра цепочек поставок и других нефинансовых приложений.

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

Например, MultiChain 1.0 позволяет создавать один или несколько именованных «потоков» в блокчейне, а затем использовать их для хранения и извлечения необработанных данных. Каждый поток имеет свой собственный набор прав записи, и каждый узел может свободно выбирать, на какие потоки подписываться. Если узел подписан на поток, он индексирует содержимое этого потока в режиме реального времени, что позволяет быстро извлекать элементы на основе их порядка, метки времени, номера блока или адреса издателя, а также с помощью «ключа» (или метки) какими элементами можно пометить. MultiChain 2.0 (начиная с alpha 1) расширяет потоки для поддержки текста Unicode или данных JSON, а также нескольких ключей на элемент и нескольких элементов на транзакцию. Также добавлены функции суммирования, такие как «JSON merge», которые полезным образом комбинируют элементы с одним и тем же ключом или издателем.

Конфиденциальность и масштабируемость

Хотя хранение данных непосредственно в блокчейне работает хорошо, оно страдает двумя основными недостатками - конфиденциальностью и масштабируемостью. Начнем с конфиденциальности, содержимое каждого элемента потока видно каждому узлу в цепочке, и это не обязательно является желательным результатом. Во многих случаях фрагмент данных должен быть виден только определенному подмножеству узлов, даже если другие узлы необходимы для его упорядочения, отметки времени и нотариального заверения.

Конфиденциальность - это относительно простая проблема, которая решается шифрованием информации перед ее внедрением в транзакцию. Ключ дешифрования для каждого фрагмента данных предоставляется только тем участникам, которые должны его видеть. Доставка ключа может быть выполнена по цепочке с использованием асимметричной криптографии (как описанные здесь.) или с помощью какого-либо механизма вне цепи, что является предпочтительным. Любой узел, не имеющий ключа для расшифровки элемента, не увидит ничего, кроме бинарного бреда.

Масштабируемость, с другой стороны, является более важной задачей. Допустим, любая приличная платформа блокчейна должна поддерживать пропускную способность сети в 500 транзакций в секунду. Если целью цепочки является хранение информации, то размер каждой транзакции будет зависеть, прежде всего, от того, сколько данных она содержит. Каждой транзакции также потребуется (как минимум) 100 байтов служебной информации для хранения адреса отправителя, цифровой подписи и нескольких других битов.

Если мы возьмем простой случай, когда каждый элемент представляет собой небольшую структуру JSON размером 100 байтов, общая пропускная способность данных составит 100 килобайт в секунду, что рассчитывается из 500 × (100 + 100). Это означает пропускную способность менее 1 мегабита в секунду, что удобно для пропускной способности любого современного подключения к Интернету. Данные будут накапливаться со скоростью около 3 терабайт в год, что немало. Но с 12 терабайтами жестких дисков сейчас широко доступныйкачества RAID Контроллеры, которые объединяют несколько физических дисков в один логический, мы могли бы легко хранить 10-20 лет данных на каждом узле без особых хлопот или затрат.

Однако, если мы храним большие объемы информации, такие как отсканированная документация, все выглядит иначе. Сканирование в формате JPEG листа бумаги формата A4 с приемлемым качеством может иметь размер 500 килобайт. Умножьте это на 500 транзакций в секунду, и мы смотрим на пропускную способность 250 мегабайта в секунду. Это означает пропускную способность 2 гигабит / с, что выше, чем в большинстве локальных сетей, не говоря уже о подключении к Интернету. У Amazon Web Services самый дешевый опубликованная цена 0.05 доллара за гигабайт означает годовой счет за пропускную способность 400,000 8000 долларов за узел. И где каждый узел будет хранить XNUMX терабайт новых данных, генерируемых ежегодно?

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

Решение для перемешивания

Итак, как мы решаем проблему масштабируемости данных? Как мы можем воспользоваться децентрализованным нотариальным заверением данных в блокчейне, не копируя эти данные на каждый узел в цепочке?

Ответ заключается в хитрой технологии, называемой «хэш». Хеш - это длинное число (например, 256 бит или около 80 десятичных цифр), которое однозначно идентифицирует часть данных. Хеш рассчитывается по данным с использованием односторонняя функция который имеет важное криптографическое свойство: для любого фрагмента данных легко и быстро вычислить его хэш. Но, учитывая конкретный хеш, в вычислительном отношении невозможно найти часть данных, которая сгенерирует этот хеш. И когда мы говорим «вычислительно невозможно», мы подразумеваем больше вычислений, чем атомов в известной вселенной.

Хэши играют решающую роль во всех цепочках блоков, однозначно идентифицируя транзакции и блоки. Они также лежат в основе вычислительных задач в системах проверки работоспособности, таких как биткойны. Было разработано много различных хеш-функций с именами gobbledygook, например BLAKE2, MD5 и RIPEMD160. Но для того, чтобы любой хэш-функции можно было доверять, она должна выдержать обширный академический обзор и тестирование. Эти тесты бывают в форме попыток атак, таких как «прообраз» (поиск ввода с заданным хешем), «второй прообраз» (поиск второго ввода с тем же хешем, что и у данного ввода) и «столкновение» (нахождение любого два разных входа с одинаковым хешем). Выжить эту перчатку далеко не легко, с длинной и трагической историей сломанных хеш-функций, доказывающих известную изречение: «Не бросайте свой собственный крипто».

Чтобы вернуться к нашей первоначальной проблеме, мы можем решить масштабируемость данных в цепочках блоков, встраивая хеши больших фрагментов данных в транзакции вместо самих данных. Каждый хэш действует как «обязательство» для своих входных данных, причем сами данные хранятся вне цепочки блоков или «вне цепочки». Например, используя популярную хэш-функцию SHA256, изображение JPEG размером 500 килобайт может быть представлено 32-байтовым числом, сокращение более чем в 15,000 500 раз. Даже со скоростью XNUMX изображений в секунду это удобно возвращает нас обратно к территории возможных требований к пропускной способности и хранилищу с точки зрения данных, хранящихся в самой цепочке.

Конечно, любой участник блокчейна, которому нужно внешнее изображение, не может воспроизвести его из своего хэша. Но если изображение может быть получено каким-либо другим способом, то хэш-цепочка служит для подтверждения того, кто его создал и когда. Как и обычные данные в цепочке, хэш встроен в транзакцию с цифровой подписью, которая была включена в цепочку путем консенсуса. Если файл изображения выпадает из неба, и хеш для этого изображения совпадает с хешем в блокчейне, то происхождение и временная метка этого изображения подтверждаются. Таким образом, блокчейн предоставляет точно такое же значение с точки зрения нотариального заверения, как если бы изображение было непосредственно встроено в цепочку.

Вопрос доставки

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

Как мы доставляем оригинальный контент вне цепочки тем узлам, которые в нем нуждаются, если не через саму цепочку?

На этот вопрос есть несколько возможных ответов, и мы знаем, что пользователи MultiChain применяют их все. Один из основных подходов заключается в создании централизованного репозитория в какой-либо доверенной стороне, где все автономные данные загружаются, а затем извлекаются. Эта система может естественным образом использовать «адресацию содержимого», то есть хеш каждого фрагмента данных служит его идентификатором для поиска. Однако, хотя эта установка может работать для проверки концепции, она не имеет смысла для производства, потому что весь смысл блокчейна заключается в удалении доверенных посредников. Даже если цепочки хэшей не позволяют посреднику фальсифицировать данные, он все равно может удалить данные или не доставить их некоторым участникам из-за технического сбоя или действий мошеннического сотрудника.

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

Требуется сопоставление адресов блокчейна с IP-адресами, чтобы потребитель некоторых данных мог напрямую общаться со своим издателем. Блокчейны, как правило, позволяют избежать статической конфигурации сети этого типа, что может быть проблемой с точки зрения восстановления после сбоя и конфиденциальности.
Если исходный узел издателя вышел из сети или временно не работает, данные не могут быть извлечены кем-либо еще.
Если большое количество узлов интересуются некоторыми данными, то издатель будет перегружен запросами. Это может вызвать серьезную перегрузку сети, замедлить работу системы издателя и привести к длительным задержкам для тех, кто пытается получить эти данные.

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

Для тех, кто имеет опыт работы с одноранговый обмен файлами протоколы, такие как Napster, Gnutella или BitTorrent, все это будет звучать очень знакомо. Действительно, многие из основных принципов одинаковы, но есть два ключевых различия. Во-первых, предполагая, что мы используем нашу цепочку блоков в контексте предприятия, система работает в закрытой группе участников, а не в Интернете в целом. Во-вторых, блокчейн добавляет децентрализованную основу для упорядочения, отметки времени и нотариального заверения, позволяя всем пользователям сохранять достоверно согласованное и устойчивое представление о том, что именно произошло, когда и кем.

Как разработчик приложений с блокчейном может добиться этой децентрализованной доставки контента вне сети? Один из распространенных вариантов - взять существующую одноранговую платформу для обмена файлами, например, с забавным именем. Межпланетная файловая система (IPFS), и используйте его вместе с блокчейном. Каждый участник управляет как блокчейн-узлом, так и IPFS-узлом, а некоторое промежуточное программное обеспечение координирует между ними. При публикации автономных данных это промежуточное ПО сохраняет исходные данные в IPFS, а затем создает транзакцию блокчейна, содержащую хеш этих данных. Чтобы извлечь некоторые данные вне цепочки, промежуточное программное обеспечение извлекает хеш из цепочки блоков, а затем использует этот хеш для извлечения контента из IPFS. Локальный узел IPFS автоматически проверяет найденный контент по хешу, чтобы убедиться, что он не был изменен.

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

Данные вне цепочки в MultiChain 2.0

Сегодня мы рады выпустить третья предварительная версия (альфа 3) MultiChain 2.0, с полностью интегрированным и бесшовным решением для передачи данных вне цепочки. Каждая часть информации, публикуемой в потоке, может быть цепной или автономной по желанию, и MultiChain позаботится обо всем остальном.

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

Публикующий узел MultiChain записывает новые данные в свое локальное хранилище, разбивая большие элементы на куски для облегчения переваривания и доставки.
Транзакция для публикации элементов цепочки вне цепочки создается автоматически, в которой содержатся хэш-значения и размер фрагмента в байтах.
Эта транзакция подписывается и транслируется в сеть, распространяясь между узлами и входя в блокчейн обычным способом.
Когда узел, подписанный на поток, видит ссылку на некоторые данные вне цепочки, он добавляет хеш-блоки для этих данных в свою очередь поиска. (При подписке на старый поток узел также ставит в очередь все ранее опубликованные вне цепочки элементы для поиска.)
В качестве фонового процесса, если в очереди поиска узла есть чанки, запросы отправляются в сеть для определения местоположения этих чанков, что определяется их хешами.
Эти чанк-запросы распространяются на другие узлы в сети одноранговым способом (пока ограничено двумя прыжками - см. Технические подробности ниже).
Любой узел, имеющий данные для чанка, может ответить, и этот ответ ретранслируется абоненту по тому же пути, что и запрос.
Если ни один узел не отвечает на запрос чанка, чанк возвращается в очередь для последующей повторной попытки.
В противном случае подписчик выбирает наиболее многообещающий источник для чанка (на основе прыжков и времени ответа) и отправляет ему запрос данных этого чанка, снова по тому же одноранговому пути, что и предыдущий ответ.
Исходный узел доставляет запрошенные данные, снова используя тот же путь.
Подписчик проверяет размер данных и хэш по исходному запросу.
Если все проверено, подписчик записывает данные в свое локальное хранилище, делая их немедленно доступными для извлечения через потоковые API.
Если запрошенное содержимое не поступило или не соответствует требуемому хешу или размеру, чанк возвращается обратно в очередь для последующего извлечения из другого источника.

Самое главное, все это происходит очень быстро. В сетях с низкой задержкой небольшие фрагменты данных вне цепочки будут доставлены подписчикам в течение доли секунды после транзакции, которая их ссылается. Что касается приложений с высокой нагрузкой, то наше тестирование показывает, что MultiChain 2.0 alpha 3 может поддерживать скорость более 1000 элементов вне цепочки или 25 МБ данных вне цепочки, получаемых в секунду, на сервере среднего уровня (Core i7) с достойной Интернет-соединение. Все отлично работает с внешними элементами размером до 1 ГБ, что намного превышает ограничение 64 МБ для внутренних данных. Конечно, мы надеемся еще больше улучшить эти показатели, поскольку тратим время на оптимизацию MultiChain 2.0 во время его бета-фазы.

При использовании автономных данных вместо потоковых данных в потоках разработчикам приложений MultiChain приходится делать ровно две вещи:

При публикации данных передайте флаг «offchain» соответствующим API.
При использовании API потоковых запросов следует учитывать возможность того, что некоторые данные вне цепочки могут быть еще недоступны, о чем сообщает флаг «Доступно». Несмотря на то, что в нормальных условиях такая ситуация будет редкой, разработчикам приложений важно правильно ее обрабатывать.

Конечно, чтобы каждый узел не мог извлекать каждый элемент вне цепочки, элементы должны быть сгруппированы в потоки соответствующим образом, чтобы каждый узел подписывался на эти потоки, представляющие интерес.

Элементы в цепочке и вне цепочки могут использоваться в одном и том же потоке, а различные функции запроса и суммирования потока одинаково относятся к обоим типам данных. Это позволяет издателям сделать соответствующий выбор для каждого элемента в потоке, не затрагивая остальную часть приложения. Например, поток элементов JSON о деятельности людей может использовать данные вне цепочки для персональной идентификации информации и данные внутри цепочки для остальных. Подписчики могут использовать слияние JSON в MultiChain для объединения обоих типов информации в один JSON для чтения.

Если вы хотите попробовать посторонние потоки, просто следуйте обычным правилам MultiChain. Первые шаги учебник, и не пропустите раздел 5.

Так что же дальше?

Благодаря бесперебойной поддержке автономных данных MultiChain 2.0 предложит большой шаг вперед для приложений с блокчейном, ориентированных на масштабирование временных меток и нотариальное заверение данных. В более долгосрочной перспективе мы уже думаем о тонне возможных улучшений этой функции в будущем для выпусков MultiChain для сообществ и / или предприятий:

Реализация потока читать разрешения с использованием сочетания элементов вне цепочки, соленых хэшей, подписанных запросов чанков и зашифрованной доставки.
Позволяет явно «забыть» данные вне цепочки, как добровольно отдельными узлами, так и всеми узлами в ответ на сообщение в цепочке.
Выборочные потоковые подписки, в которых узлы извлекают данные только для элементов вне цепочки с определенными издателями или ключами.
. Меркл деревья разрешить одному хэшу в цепочке представлять неограниченное количество элементов вне цепочки, что дает еще один огромный скачок в плане масштабируемости.
Сменные механизмы хранения, позволяющие хранить автономные данные в базах данных или внешних файловых системах, а не на локальном диске.
Со временем узлы узнают, где каждый тип данных вне цепочки обычно доступен в сети, и соответствующим образом фокусируют свои запросы на порции.

Мы бы с удовольствием услышать ваш отзыв в списке выше, а также вне цепочки предметов в целом. Поскольку MultiChain 2.0 все еще официально находится в альфа-версии, у вас будет достаточно времени для улучшения этой функции до ее окончательного выпуска.

Тем временем мы уже начали работу над «Умными фильтрами», последней важной функцией, запланированной для сообщества MultiChain 2.0. Интеллектуальный фильтр - это фрагмент кода, встроенный в блокчейн, который реализует пользовательские правила для проверки данных или транзакций. Интеллектуальные фильтры имеют некоторые сходства с «умными контрактами» и могут выполнять много одинаковых функций, но имеют ключевые различия с точки зрения безопасности и производительности. Мы с нетерпением ждем возможности рассказать вам больше в свое время.

Пожалуйста, оставьте любые комментарии на LinkedIn.

Технические детали

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

Политики для каждого потока. При создании потока MultiChain его можно по желанию ограничить, чтобы разрешить только данные в цепочке или вне цепочки. Есть несколько возможных причин сделать это, вместо того, чтобы позволить каждому издателю решать за себя. Например, товары в сети предлагают железную гарантию доступности, тогда как старые товары в сети могут стать невосполнимыми, если их издатель и другие подписчики отключатся от сети. С другой стороны, элементы цепочки не могут быть «забыты» без изменения цепочки блоков, в то время как позиции вне цепочки более гибки. Это может быть важно с точки зрения правил конфиденциальности данных, таких как новые европейские правила GDPR.
Цепные метаданные. Для элементов вне цепочки транзакция внутри цепочки по-прежнему содержит издателя (ей) элемента, ключ (ы), формат (JSON, текст или двоичный код) и общий размер. Все это занимает очень мало места и помогает разработчикам приложений определить, имеет ли значение недоступность отдельного элемента для определенного потока запроса.
Лимит двух прыжков. При передаче запросов чанка по одноранговой сети существует компромисс между достижимостью и производительностью. Хотя было бы хорошо, чтобы каждый запрос распространялся по каждому отдельному пути, это может привести к засорению сети ненужной «болтовней». Таким образом, на данный момент запросы чанка ограничены двумя прыжками, что означает, что узел может извлекать данные вне цепочки с любого однорангового узла своих одноранговых узлов. Мы полагаем, что в небольших сетях с числом узлов менее 1000, которые имеют тенденцию характеризовать корпоративные цепочки блоков, это будет прекрасно работать, но нам легко отрегулировать это ограничение (или предложить его в качестве параметра), если мы окажемся неправильными.
Локальное хранилище. Каждый узел MultiChain хранит данные вне цепочки в каталоге «chunks» своего обычного каталога blockchain, используя эффективный двоичный формат и индекс LevelDB. Отдельный подкаталог используется для элементов в каждом из подписанных потоков, а также для тех, которые опубликованы самим узлом. В каждом из этих подкаталогов повторяющиеся фрагменты (с одинаковым хешем) сохраняются только один раз. Когда узел отменяет подписку на поток, он может выбрать, следует ли удалять удаленные данные, полученные для этого потока.
Бинарный кеш. При публикации больших кусков двоичных данных, будь то в цепочке или вне цепочки, разработчикам приложений может быть нецелесообразно отправлять эти данные в API MultiChain в одном запросе JSON-RPC. Таким образом, MultiChain 2.0 реализует двоичный кеш, который позволяет собирать большие фрагменты данных за несколько вызовов API, а затем публиковать их в кратком заключительном шаге. Каждый элемент в двоичном кеше хранится в виде простого файла в подкаталоге «cache» каталога blockchain, что позволяет напрямую передавать гигабайты данных через файловую систему.
API мониторинга. MultiChain 2.0 alpha 3 добавляет два новых API для мониторинга асинхронного извлечения данных вне цепочки. Первый API описывает текущее состояние очереди, показывая, сколько кусков (и сколько данных) ожидает, запрашивается или извлекается. Второй API предоставляет агрегированную статистику для всех запросов на блоки и запросов, отправленных с момента запуска узла, включая количество различных типов отказов.
Флеш при публикации. При публикации элемента вне цепочки MultiChain гарантирует, что его локальная копия данных будет полностью записана (или «очищена») на физический диск до того, как транзакция, ссылающаяся на эти данные, будет передана в сеть. В противном случае, если узлу не повезло потерять мощность сразу после трансляции транзакции, данные вне цепочки могут быть потеряны навсегда. Это не проблема для самой MultiChain, так как задержки между попытками получения чанка со временем автоматически растут. Но это может вызвать проблемы на уровне приложений, где все знают о существовании некоторых данных, но никто не может их найти.
Издательское представление. За счет сброса данных на диск таким образом MultiChain может понизить производительность, поскольку физические диски работают медленно. Например, жесткий диск со средней скоростью вращения 7200 об / мин может выполнять только около 100 случайных операций записи данных в секунду, ограничивая, в свою очередь, скорость, с которой отдельный узел может публиковать элементы вне цепочки. Есть три возможных решения этой проблемы. Во-первых, и проще всего, узлы могут использовать твердотельный накопитель (SSD) вместо обычного жесткого диска, который поддерживает 10,000 XNUMX операций произвольной записи в секунду. Во-вторых, несколько отдельных элементов можно опубликовать в одной транзакции с помощью API «createrawsendfrom». В этом случае MultiChain записывает все автономные данные, на которые ссылается транзакция, в одной операции на диске. Наконец, MultiChain может быть настроен так, чтобы не сбрасывать данные вне цепочки на диск перед трансляцией транзакции, которая на нее ссылается. Используйте эту опцию с осторожностью.
Интеграция с национальной валютой. Для случаев использования, которые требуют этого, MultiChain всегда предлагал вариант использования собственной валюты в блокчейне для предотвращения спама в транзакциях и / или стимулирования валидаторов блоков («майнеров»). В этих случаях транзакции должны предлагать майнерам минимальную плату, которая пропорциональна их размеру в байтах, для передачи и подтверждения в цепочке. Этот механизм был расширен для предотвращения нежелательного спама, требуя минимальной дополнительной платы за килобайт внешних данных, на которые ссылается транзакция.
Архивные узлы. Если узел желает подписаться на каждый поток и, следовательно, извлекать и сохранять каждый опубликованный элемент вне цепочки, он может быть настроен для этого с использованием параметра времени выполнения «autosubscribe». Любой такой узел будет действовать как резервная копия для всей сети, гарантируя, что отдельные элементы не будут потеряны или недоступны, независимо от того, какие другие узлы исчезнут. Можно представить сторонние компании, предлагающие это в качестве коммерческой услуги.