Краткое содержание предыдущих частей статьи:
Основная задача:
Изучить, как хранить данные 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.
![](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/011/9ac/851/0119ac851bd75e4940b90a3e3654e62c.png)
![](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/a82/304/e76/a82304e765c495e68c5bdb6684270729.png)
6.2 Хранение и извлечение данных из предлагаемой системы
После того как контракт развернут и устройства, использующие систему, зарегистрированы в смарт-контракте, мы можем хранить данные в системе.
На рисунке 6.1 описана реализация предлагаемой системы, которая получает данные датчика от подключенного датчика DHT11, генерирует полезную нагрузку, шифрует ее и затем сохраняет полезную нагрузку в Swarm. Запрос на хранение полезной нагрузки в Swarm возвращает файл-хэш, который передается смарт-контракту для майнинга и хранения в блокчейне.
![Рисунок 6.1: Хранение данных в предлагаемой системе Рисунок 6.1: Хранение данных в предлагаемой системе](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/7af/ff9/296/7afff92960bf39aaae6c6e89a912a32c.png)
На рисунке 6.2 описана реализация предложенной системы, которая извлекает файловый хэш из Ethereum с помощью смарт-контракта, затем получает полезную нагрузку, связанную с этим файловым хэшем, расшифровывает полезную нагрузку и отображает ее на подключенном ЖК-устройстве.
![Рисунок 6.2: Получение данных из предлагаемой системы Рисунок 6.2: Получение данных из предлагаемой системы](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/fc7/57a/2bd/fc757a2bdb9d3f9f66cdfd75b10a1ab6.png)
6.3 Сравнение производительности
Количество транзакций в секунду обычно является плохой метрикой производительности для блокчейн и децентрализованных приложений. Однако мы реализовали решение для хранения данных на основе приватного блокчейна с децентрализованным хранилищем, и поэтому имеет смысл измерить нагрузку на процессор, память, а также время, затраченное на обработку заданного набора транзакций.
6.3.1 Набор данных для тестов
Набор данных, состоящий из 10 000 записей, использовался для тестирования производительности системы и определения того, сколько устройств теоретически могут одновременно читать или записывать данные в систему.
Образец набора данных
![](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/af5/148/6d2/af51486d23e09f989da4b47d631651db.png)
![](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/92d/d13/cc9/92dd13cc91905c79aa042b76d784fb5c.png)
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: Панель показателей Ethereum Рисунок 6.3: Панель показателей Ethereum](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/3bd/38c/d6e/3bd38cd6e96af8735c63426e58368850.png)
![Рисунок 6.4: Хэшрейт сети Ethereum Рисунок 6.4: Хэшрейт сети Ethereum](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/882/b7b/4eb/882b7b4eb917fb1a60d2af3b1e82cad2.png)
![Рисунок 6.5: Майнеры в сети Рисунок 6.5: Майнеры в сети](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/baa/08b/326/baa08b326d238ff032117a5d25834728.png)
6.3.3 Данные, хранящиеся в Swarm
По сравнению с geth и ipfs, Swarm использовал наименьшее количество процессорной мощности и эквивалентный объем оперативной памяти в каждом тесте. Производительность Swarm была очень быстрой, поскольку для получения и отправки данных он зависит только от HTTP POST-запроса. Данные отправляются и извлекаются с устройства, настроенного на роль IoT Producer (Raspberry Pi).
На рисунке 6.6 показано время чтения и записи для 10 000 записей. За исключением нескольких аномалий, время чтения и записи оставалось примерно одинаковым на протяжении всех тестов. Использование данных с шифрованием привело к очень незначительному снижению производительности, как показано на рисунке 6.7.
![Рисунок 6.6: Производительность Swarm при чтении и записи для 10 тыс. записей Рисунок 6.6: Производительность Swarm при чтении и записи для 10 тыс. записей](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/65f/684/72d/65f68472db88d443c1b9d57d6daf9859.png)
![Рисунок 6.7: Производительность Swarm при чтении и записи с шифрованием для 10 тысяч записей Рисунок 6.7: Производительность Swarm при чтении и записи с шифрованием для 10 тысяч записей](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/c08/8bf/229/c088bf22942fad7c8ffc51ad7e7b21b6.png)
6.3.4 Данные, хранящиеся в Ethereum и Swarm
Узел geth для хранения информации от IoTProducer (Raspberry Pi) является легким узлом и зависит от полного узла для получения своей информации. Однако этот узел отвечает за отправку транзакций, генерируемых вызовом функции смарт-контракта для хранения хэшей файлов.
Без шифрования
Полезная нагрузка генерируется и хранится в рое. Возвращенный хэш файла затем хранится в Ethereum с помощью смарт-контракта. На рисунке 6.8 показана разница в производительности между чтением и записью без шифрования.
Рисунок 6.8: Производительность чтения и записи в Ethereum с Swarm для 10 тыс. записей
![](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/7cf/e43/118/7cfe431188e7466d20a3906f0207ca97.png)
С шифрованием
Процесс шифрования полезной нагрузки не оказал негативного влияния на производительность, как предполагалось ранее.
На рисунке 6.9 показана разница в производительности между чтением и записью с шифрованием.
![Рисунок 6.9: Производительность чтения и записи в Ethereum с Swarm для 10 тыс. записей Рисунок 6.9: Производительность чтения и записи в Ethereum с Swarm для 10 тыс. записей](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/762/d05/bd4/762d05bd499f9329ccd1f76775c17b8d.png)
6.3.5 Данные, хранящиеся в IPFS
С самого начала производительность IPFS при записи была значительно хуже, чем у Swarm. Набор данных был уменьшен до 5000 записей и затем протестирован с зашифрованными данными, а также без шифрования. Однако производительность при чтении в IPFS была отличной, хотя и не приблизилась к производительности, наблюдаемой при использовании Swarm.
На рисунке 6.10 показана разница в производительности между чтением и записью в IPFS.
![Рисунок 6.10: Производительность чтения и записи в IPFS для 5k записей Рисунок 6.10: Производительность чтения и записи в IPFS для 5k записей](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/a5b/32d/831/a5b32d831efa0051a5c22c57b6c135a9.png)
На рисунке 6.11 показана разница в производительности между чтением и записью в IPFS с шифрованием
![Рисунок 6.11: Производительность чтения и записи в IPFS с шифрованием для 5k записей Рисунок 6.11: Производительность чтения и записи в IPFS с шифрованием для 5k записей](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/8da/f16/578/8daf16578768ec8665175daa6b85044f.png)
6.3.6 Данные, хранящиеся в Ethereum и IPFS
При сравнении чтения и записи с использованием только IPFS результаты оказались одинаковыми, что подтверждает, что IPFS действительно зажата процессором на raspberry pi.
На рисунке 6.12 показана разница в производительности между чтением и записью при использовании комбинации Ethereum и IPFS. На рисунке 6.13 показана разница в производительности между чтением и записью при использовании комбинации Ethereum и IPFS.
![Рисунок 6.12: Производительность чтения и записи в Ethereum с IPFS для 5 тыс. записей Рисунок 6.12: Производительность чтения и записи в Ethereum с IPFS для 5 тыс. записей](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/927/058/49a/92705849a7965e75cf546a36464a9d43.png)
![Рисунок 6.13: Производительность Ethereum с IPFS при чтении и записи с шифрованием для 5 тыс. записей Рисунок 6.13: Производительность Ethereum с IPFS при чтении и записи с шифрованием для 5 тыс. записей](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/374/be3/43d/374be343d0cd13ce4c67b116552ddaab.png)
6.3.7 Сравнение производительности
Чтение или запись данных в систему линейно масштабируется по времени благодаря тому, что и Swarm, и IPFS используют форму хэширования для хранения данных. В целом, чтение и запись в Swarm или IPFS занимали примерно одинаковое время. Как правило, скорость записи ниже, чем скорость чтения. Эти тесты проводились по сети, и задержки при чтении и записи по сети затмили любую разницу между фактическим чтением и записью в эти системы хранения.
В этом разделе мы сравним время чтения и записи для различных типов систем хранения, которые мы использовали, включая системы с шифрованием, дешифрованием и проверкой подписи и без них.
В таблице 6.1 показаны различные метрики, полученные в ходе тестов на запись для 5000 транзакций в предлагаемой системе, работающей на IoT Producer (Raspberry Pi). Затраченное время измеряется в секундах, а стоимость - в эфирах.
![Таблица 6.1: Результаты тестов на запись для 5000 txns Таблица 6.1: Результаты тестов на запись для 5000 txns](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/cca/58d/4c5/cca58d4c5c4e3ddf436cb3d3f01fb500.png)
В таблице 6.2 показаны различные метрики, полученные в ходе тестов Read для 5000 транзакций на предложенной системе, работающей на IoT Producer (Raspberry Pi).
![Таблица 6.2: Результаты тестов на чтение для 5000 транзакций Таблица 6.2: Результаты тестов на чтение для 5000 транзакций](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/131/1fb/a6a/1311fba6a9d9073b0ea09f7c0eaee42c.png)
Разница в производительности между 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.3: Результаты для чтения и записи на Raspberry Pi и Mining Machine Таблица 6.3: Результаты для чтения и записи на Raspberry Pi и Mining Machine](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/aff/ccd/b4e/affccdb4e4638bb63b2ec29bf2f36a6b.png)
В таблицах 6.16 и 6.14 мы включаем затраты, понесенные на транзакции в Ethereum. Однако эта метрика не имеет прямого значения, поскольку мы используем частную сеть Ethereum, не имеющую внутренней денежной стоимости. Однако эти метрики помогают нам косвенно. Во-первых, поскольку в данной работе мы не используем массивы, ни статические, ни динамические, понесенные затраты не увеличиваются со временем и остаются неизменными на протяжении всего тестирования. Во-вторых, мы можем использовать показатели стоимости, чтобы легко определить, выполняются ли в сети несанкционированные транзакции.
Стоимость производительности при записи
Хранение только данных Swarm было очень быстрым по сравнению с использованием как блокчейна Ethereum, так и Swarm. Добавление шифрования не сильно повлияло на производительность.
На рисунке 6.14 показана стоимость производительности при использовании только Swarm, IPFS, Ethereum и Swarm и Ethereum и IPFS для хранения тестового набора данных.
![Рисунок 6.14: Стоимость производительности при записи с использованием различных методов Рисунок 6.14: Стоимость производительности при записи с использованием различных методов](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/6dc/1ef/778/6dc1ef7781755c40181b52e5ac40a8f1.png)
Медленный процессор и ограниченная оперативная память на raspberry pi оказали значительное влияние на производительность предложенной системы. Машина для майнинга используется в качестве эталона для проверки разницы в производительности записи между IoT-устройством и полностью заряженной машиной на рисунке 6.15. Производительность записи, как упоминалось ранее, значительно зависит от процессора на Raspberry Pi при работе с комбинацией Ethereum и IPFS.
![Рисунок 6.15: Стоимость производительности для записи на RPI по сравнению с эталонной машиной Рисунок 6.15: Стоимость производительности для записи на RPI по сравнению с эталонной машиной](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/1dd/5f3/0d4/1dd5f30d48e0b958b1842669e5adc322.png)
Стоимость производительности при чтении
Чтение только данных Swarm было очень быстрым по сравнению с использованием комбинации блокчейна Ethereum и метода Swarm. Добавление шифрования снизило производительность на небольшую величину, поскольку подпись должна быть сгенерирована и проверена на принимающей стороне. Однако при использовании Ethereum Blockchain и IPFS производительность снижается гораздо сильнее. На рисунке 6.16 показана стоимость производительности при использовании только Swarm, IPFS, Ethereum и Swarm и Ethereum и IPFS для чтения тестового набора данных.
Машина Mining используется в качестве эталона для проверки разницы в производительности Read между IoT-устройством и полностью заряженной машиной на рисунке 6.17. При работе на RPI и эталонной машине чтение выполнялось одинаково и было сопоставимо.
![Рисунок 6.16: Стоимость производительности для чтения с использованием различных методов Рисунок 6.16: Стоимость производительности для чтения с использованием различных методов](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/53f/846/e3f/53f846e3f111a5b99b82f49ba8a96dcb.png)
![Рисунок 6.17: Стоимость производительности для записи на RPI по сравнению с эталонной машиной Рисунок 6.17: Стоимость производительности для записи на RPI по сравнению с эталонной машиной](https://webcf.waybackmachine.org/web/20220421213351/https://habrastorage.org/getpro/habr/upload_files/296/771/822/296771822904ffbd6aef6fd7d228a79c.png)
Заключение и будущая работа
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, предназначены для маломощных граничных узлов и постепенно набирают обороты. Первые тесты этого алгоритма были многообещающими с точки зрения использования ресурсов и скорости.
Блокчейн Адвокат — пишем про блокчейн, криптотех, Web3 и ИИ.
Присоединяйтесь к нашему каналу в Телеграм.