Краткое содержание предыдущих частей статьи:
Основная задача
Изучить, как хранить данные IoT на комбинации on-chain (Ethereum Blockchain) и off-chain хранилищ (IPFS и Ethereum Swarm) в зашифрованном виде и использовать их в модели публикации-подписки в режиме реального времени без использования каких-либо протоколов M2M, таких как MQTT или CoAP. Оценить производительность этой системы с точки зрения количества транзакций, которые могут быть выполнены в секунду и оптимизировать ее работу.
Предыдущие части статьи:
Безопасное хранение данных IoT в частном блокчейне Ethereum. Часть 1
Безопасное хранение данных IoT в частном блокчейне Ethereum. Часть 2
В этой части статьи в главе 6 мы проводим эксперименты по хранению данных с использованием традиционных баз данных, а также предложенной системы с использованием Ethereum Blockchain, IPFS и Swarm. Чтобы понять стоимость безопасности IoT, мы проводим эксперименты по оценке производительности предложенной системы.
В главе 7 мы попытаемся обобщить выводы, сделанные в данной статье, и завершим ее ретроспективным обзором 2 измерений производительности этих систем хранения данных вместе с блокчейном.
Часть 3
Глава 6
Анализ производительности и затрат (Внимание! Данные от 2019 года)
Мы протестируем как затраты, понесенные счетом, передающим транзакции, так и время, затраченное на загрузку и чтение этих записей с шифрованием и без него.
6.1 Затраты, понесенные при развертывании смарт-контрактов
Затраты, понесенные смарт-контрактами, зависят от ряда факторов. Существует фиксированная плата, и необходимо оплачивать как вычисления, так и хранение. Плата за развертывание в определенной степени зависит от проведенной оптимизации.
Truffle требует развертывания двух контрактов, миграционного контракта и собственно SensorContract. Миграционный контракт определяет владельца развертываемого смарт-контракта и временную метку последнего успешного развертывания. SensorContract состоит из кода, связанного с регистрацией, записью и чтением данных из блокчейна.
За развертывание смарт-контракта в частных блокчейнах необходимо заплатить 20 гвеев за единицу потраченного газа. Эта стоимость проверяется только на случай, если мы захотим развернуть тот же контракт в основной сети Ethereum. Общая стоимость развертывания смарт-контрактов составила 0,0232 Eth. На момент написания статьи курс конвертации Eth в доллары составлял 182,37, что соответствует приблизительным долларовым затратам в размере $4,2.
6.2 Хранение и извлечение данных из предлагаемой системы
После того как контракт развернут и устройства, использующие систему, зарегистрированы в смарт-контракте, мы можем хранить данные в системе.
На рисунке 6.1 описана реализация предлагаемой системы, которая получает данные датчика от подключенного датчика DHT11, генерирует полезную нагрузку, шифрует ее и затем сохраняет полезную нагрузку в Swarm. Запрос на хранение полезной нагрузки в Swarm возвращает файл-хэш, который передается смарт-контракту для майнинга и хранения в блокчейне.
На рисунке 6.2 описана реализация предложенной системы, которая извлекает файловый хэш из Ethereum с помощью смарт-контракта, затем получает полезную нагрузку, связанную с этим файловым хэшем, расшифровывает полезную нагрузку и отображает ее на подключенном ЖК-устройстве.
6.3 Сравнение производительности
Количество транзакций в секунду обычно является плохой метрикой производительности для блокчейн и децентрализованных приложений. Однако мы реализовали решение для хранения данных на основе приватного блокчейна с децентрализованным хранилищем, и поэтому имеет смысл измерить нагрузку на процессор, память, а также время, затраченное на обработку заданного набора транзакций.
6.3.1 Набор данных для тестов
Набор данных, состоящий из 10 000 записей, использовался для тестирования производительности системы и определения того, сколько устройств теоретически могут одновременно читать или записывать данные в систему.
Образец набора данных
6.3.2 Решение для Ethereum
Новый блок генерировался в среднем каждые 4,5 секунды, и на каждый блок подавалась только 1 транзакция для майнинга. Скорость майнинга (Network Hash Rate) составляла около 31 KH/s (Kilo Hash per second), когда работал только майнер1, и примерно 51,4 KH/s, когда работали и майнер1, и майнер2 по 1 потоку каждый. Используя только Ethereum для хранения текстовых данных, на майнинговой машине был достигнут TPS 13,5 (5000/368), а на загрузку 5000 записей было потрачено 1,13 Ether. Средняя скорость хэширования сети была улучшена до 132 KH/s путем увеличения количества потоков на всех майнерах до 4.
На рисунках 6.3, 6.4 и 6.5 показаны различные метрики, рассчитанные для майнеров в сети Ethereum
6.3.3 Данные, хранящиеся в Swarm
По сравнению с geth и ipfs, Swarm использовал наименьшее количество процессорной мощности и эквивалентный объем оперативной памяти в каждом тесте. Производительность Swarm была очень быстрой, поскольку для получения и отправки данных он зависит только от HTTP POST-запроса. Данные отправляются и извлекаются с устройства, настроенного на роль IoT Producer (Raspberry Pi).
На рисунке 6.6 показано время чтения и записи для 10 000 записей. За исключением нескольких аномалий, время чтения и записи оставалось примерно одинаковым на протяжении всех тестов. Использование данных с шифрованием привело к очень незначительному снижению производительности, как показано на рисунке 6.7.
6.3.4 Данные, хранящиеся в Ethereum и Swarm
Узел geth для хранения информации от IoTProducer (Raspberry Pi) является легким узлом и зависит от полного узла для получения своей информации. Однако этот узел отвечает за отправку транзакций, генерируемых вызовом функции смарт-контракта для хранения хэшей файлов.
Без шифрования
Полезная нагрузка генерируется и хранится в рое. Возвращенный хэш файла затем хранится в Ethereum с помощью смарт-контракта. На рисунке 6.8 показана разница в производительности между чтением и записью без шифрования.
Рисунок 6.8: Производительность чтения и записи в Ethereum с Swarm для 10 тыс. записей
С шифрованием
Процесс шифрования полезной нагрузки не оказал негативного влияния на производительность, как предполагалось ранее.
На рисунке 6.9 показана разница в производительности между чтением и записью с шифрованием.
6.3.5 Данные, хранящиеся в IPFS
С самого начала производительность IPFS при записи была значительно хуже, чем у Swarm. Набор данных был уменьшен до 5000 записей и затем протестирован с зашифрованными данными, а также без шифрования. Однако производительность при чтении в IPFS была отличной, хотя и не приблизилась к производительности, наблюдаемой при использовании Swarm.
На рисунке 6.10 показана разница в производительности между чтением и записью в IPFS.
На рисунке 6.11 показана разница в производительности между чтением и записью в IPFS с шифрованием
6.3.6 Данные, хранящиеся в Ethereum и IPFS
При сравнении чтения и записи с использованием только IPFS результаты оказались одинаковыми, что подтверждает, что IPFS действительно зажата процессором на raspberry pi.
На рисунке 6.12 показана разница в производительности между чтением и записью при использовании комбинации Ethereum и IPFS. На рисунке 6.13 показана разница в производительности между чтением и записью при использовании комбинации Ethereum и IPFS.
6.3.7 Сравнение производительности
Чтение или запись данных в систему линейно масштабируется по времени благодаря тому, что и Swarm, и IPFS используют форму хэширования для хранения данных. В целом, чтение и запись в Swarm или IPFS занимали примерно одинаковое время. Как правило, скорость записи ниже, чем скорость чтения. Эти тесты проводились по сети, и задержки при чтении и записи по сети затмили любую разницу между фактическим чтением и записью в эти системы хранения.
В этом разделе мы сравним время чтения и записи для различных типов систем хранения, которые мы использовали, включая системы с шифрованием, дешифрованием и проверкой подписи и без них.
В таблице 6.1 показаны различные метрики, полученные в ходе тестов на запись для 5000 транзакций в предлагаемой системе, работающей на IoT Producer (Raspberry Pi). Затраченное время измеряется в секундах, а стоимость - в эфирах.
В таблице 6.2 показаны различные метрики, полученные в ходе тестов Read для 5000 транзакций на предложенной системе, работающей на IoT Producer (Raspberry Pi).
Разница в производительности между Swarm и IPFS
Используя полную версию предложенной нами системы (Ethereum + Swarm), мы достигли примерно 5 транзакций в секунду (TPS) для теста на запись и 9 для теста на чтение. Это вполне достижимо для нашего предполагаемого использования - 1 транзакция в минуту на устройство. Мы сможем комфортно использовать эту систему в системах, где транзакции отправляются с низкой или средней частотой.
Использование IPFS вместо Swarm привело к значительному снижению производительности из-за того, что использование процессора IPFS на raspberry pi во время теста на запись было невероятно высоким по сравнению с Swarm. Когда те же 75 тестов были выполнены на эталонной машине (Mining machine), мы получили TPS 16 (5000/306) для записи и 71 (5000/70) для чтения.
В таблице 6.3 показано сравнение TPS для Ethereum, Swarm и IPFS на IoT Producer (Raspberry Pi) и эталонной машине (Mining Machine).
В таблицах 6.16 и 6.14 мы включаем затраты, понесенные на транзакции в Ethereum. Однако эта метрика не имеет прямого значения, поскольку мы используем частную сеть Ethereum, не имеющую внутренней денежной стоимости. Однако эти метрики помогают нам косвенно. Во-первых, поскольку в данной работе мы не используем массивы, ни статические, ни динамические, понесенные затраты не увеличиваются со временем и остаются неизменными на протяжении всего тестирования. Во-вторых, мы можем использовать показатели стоимости, чтобы легко определить, выполняются ли в сети несанкционированные транзакции.
Стоимость производительности при записи
Хранение только данных Swarm было очень быстрым по сравнению с использованием как блокчейна Ethereum, так и Swarm. Добавление шифрования не сильно повлияло на производительность.
На рисунке 6.14 показана стоимость производительности при использовании только Swarm, IPFS, Ethereum и Swarm и Ethereum и IPFS для хранения тестового набора данных.
Медленный процессор и ограниченная оперативная память на raspberry pi оказали значительное влияние на производительность предложенной системы. Машина для майнинга используется в качестве эталона для проверки разницы в производительности записи между IoT-устройством и полностью заряженной машиной на рисунке 6.15. Производительность записи, как упоминалось ранее, значительно зависит от процессора на Raspberry Pi при работе с комбинацией Ethereum и IPFS.
Стоимость производительности при чтении
Чтение только данных Swarm было очень быстрым по сравнению с использованием комбинации блокчейна Ethereum и метода Swarm. Добавление шифрования снизило производительность на небольшую величину, поскольку подпись должна быть сгенерирована и проверена на принимающей стороне. Однако при использовании Ethereum Blockchain и IPFS производительность снижается гораздо сильнее. На рисунке 6.16 показана стоимость производительности при использовании только Swarm, IPFS, Ethereum и Swarm и Ethereum и IPFS для чтения тестового набора данных.
Машина Mining используется в качестве эталона для проверки разницы в производительности Read между IoT-устройством и полностью заряженной машиной на рисунке 6.17. При работе на RPI и эталонной машине чтение выполнялось одинаково и было сопоставимо.
Заключение и будущая работа
7.1 Заключение
Мы успешно создали систему, в которой Ethereum используется для регистрации устройств и хранения ссылок на данные, хранящиеся в IPFS или Swarm. Поскольку Ethereum требует регистрации перед сохранением данных, а данные Swarm/IPFS хранятся в зашифрованном формате, нам даже не нужна частная сеть для хранения данных, вместо этого мы можем использовать основные сети Ethereum, IPFS или Swarm.
С точки зрения производительности, сочетание Ethereum (для поддержания последовательности записей) и Swarm (для фактического хранения) показало наилучшую производительность по сравнению с IPFS. В обоих случаях производительность можно увеличить, если использовать Raspberry pis только для сбора данных и вместо этого использовать мощную машину для фактической отправки транзакций для записи данных. Конечные точки Geth, swarm и ipfs могут быть защищены с помощью частной PKI, которую мы настроили ранее в разделе 5.2.2.
Этот же метод хранения данных можно распространить на многие случаи использования, например, на хранение записей в таких областях, как правительство, образование, здравоохранение и т. д., а также увеличить емкость хранилища по мере необходимости, не останавливая службы даже на время для обслуживания.
Однако в настоящее время Swarm и IPFS еще не готовы к использованию в реальном времени и все еще находятся в процессе разработки соответствующих уровней стимулирования, как Ethereum. Кроме того, в настоящее время изучаются методы реализации шифрования данных, хранящихся в соответствующих системах, что сделает процесс их настройки и использования простым и безопасным. В Swarm еще не реализован метод мониторинга для просмотра сетевого трафика, статуса пиров и т.д., в то время как Ethereum и IPFS имеют хорошие службы мониторинга для отслеживания производительности сети.
7.2 Будущая работа
Следующими направлениями работы будут улучшение качества и типов хранимых и извлекаемых сенсорных данных, дальнейшая защита IoT-устройств и разработка более быстрого алгоритма Proof of Work для подтверждения транзакций на блокчейне Ethereum.
Одним из основных направлений усовершенствования является предоставление возможности нескольким производителям отправлять данные с датчиков на единый канал Swarm с временной меткой между временными интервалами. Это позволило бы значительно упростить обработку данных, собранных из разных источников.
Еще одна область улучшения с точки зрения блокчейна - использование блокчейна с правами доступа, такого как Quorum, вместо открытого блокчейна, такого как Ethereum, работающего в приватном режиме. Это позволяет гораздо лучше контролировать доступ и давать разрешения пользователям.
Быстрый алгоритм Proof of Work может быть разработан с явной целью разработки алгоритма для достижения консенсуса, более подходящего для данных IoT, чем тот, который используется в настоящее время для утверждения криптовалютных транзакций. Такая оптимизация сделает алгоритм намного быстрее и повысит скорость транзакций. Помимо использования Quorum, тесты могут быть повторены на самой Ethereum, когда протокол Proof of Stake начнет работать с протоколом Casper.
IoT-устройства обычно имеют низкую мощность из-за ограничений на энергопотребление. Использование таких ресурсоемких методов шифрования, как RSA и AES (даже с аппаратным ускорением), на этих устройствах противоречит идее использования маломощных устройств, предназначенных для измерения и сбора данных. Современные методы шифрования, такие как Adiantum, предназначены для маломощных граничных узлов и постепенно набирают обороты. Первые тесты этого алгоритма были многообещающими с точки зрения использования ресурсов и скорости.
