Как стать автором
Обновить
5.4

IPFS *

InterPlanetary File System

Сначала показывать
Порог рейтинга
Уровень сложности

Сможет ли IPFS полностью заменить HTTP?

Время на прочтение 6 мин
Количество просмотров 12K

Меня зовут Виталий Киреев, я руководитель R&D в SpaceWeb. В начале прошлого года мы внедрили IPFS-технологию в работу своего хостинга, и все наши клиенты получили возможность размещать контент в IPFS-сети. Решились на такой шаг не сразу: IPFS — технология пока еще экспериментальная, к ней и у R&D-команды полно вопросов.

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

Читать далее
Всего голосов 29: ↑28 и ↓1 +27
Комментарии 13

Новости

Неограниченный доступ к знаниям: библиотека Стандартных Шаблонных Конструкций

Уровень сложности Средний
Время на прочтение 9 мин
Количество просмотров 21K

Есть много причин почему доступ научным статьям и книгам должен быть свободным:

Во-первых, это прекрасно

Во-вторых...
Всего голосов 54: ↑54 и ↓0 +54
Комментарии 8

Что может тормозить внедрение IPFS

Время на прочтение 3 мин
Количество просмотров 4.7K

Протоколу давно пророчат светлое будущее в качестве замены HTTP. Об этом мы говорили в одном из прошлых материалов. И сегодня решили взглянуть, как обстоят дела с внедрением IPFS и какие факторы замедляют распространение.

Читать далее
Всего голосов 14: ↑9 и ↓5 +4
Комментарии 23

Безопасное хранение данных IoT в частном блокчейне Ethereum. Часть 3

Время на прочтение 10 мин
Количество просмотров 2.5K

Основная задача:

Изучить, как хранить данные 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: ↑2 и ↓1 +1
Комментарии 0

Истории

Безопасное хранение данных IoT в частном блокчейне Ethereum. Часть 2

Время на прочтение 24 мин
Количество просмотров 3K

Напомним про основную задачу:

Изучить, как хранить данные IoT на комбинации on-chain (Ethereum Blockchain) и off-chain хранилищ (IPFS и Ethereum Swarm) в зашифрованном виде и использовать их в модели публикации-подписки в режиме реального времени без использования каких-либо протоколов M2M, таких как MQTT или CoAP. Оценить производительность этой системы с точки зрения количества транзакций, которые могут быть выполнены в секунду и оптимизировать ее работу.

Краткое содержание данной части статьи:

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

В главе 5 мы описываем предложенную систему хранения данных в блокчейн и вне блокчейн для децентрализованного хранения данных с датчиков. Мы также описываем смарт-контракт, используемый для регистрации IoT-устройств и хранения данных.

Читать далее
Всего голосов 4: ↑2 и ↓2 0
Комментарии 0

Безопасное хранение данных IoT в частном блокчейне Ethereum. Часть 1

Время на прочтение 23 мин
Количество просмотров 5.7K

Интернет вещей (IoT) — это набор технологий, которые позволяют подключенным к сети устройствам выполнять действия или обмениваться данными между несколькими подключенными устройствами или с общей базой данных. Действия могут могут быть любыми: от дистанционного включения кондиционера воздуха до включения зажигания автомобиля с помощью команды, поданной из удаленного места, или попросить Alexa или Google Assistant найти информацию о погодных условиях в том или ином районе. IoT доказал свою эффективность во многих отраслях промышленности таких как цепочки поставок, доставка и транспортировка, предоставляя информацию о состоянии грузов в режиме реального времени. Это привело к появлению огромного количества данных, создаваемых множеством таких устройств. которые необходимо обрабатывать в режиме реального времени.

В данной статье мы предлагаем метод сбора информации с датчиков устройств IoT и использования блокчейна для хранения и получения собранных данных для безопасного и децентрализованного хранения и извлечения собранных данных в рамках закрытой системы, подходящей для одного предприятия или группы компаний в таких отраслях как, например, судоходство, где требуется обмен данных друг с другом. Подобно блокчейну, мы представляем себе будущее, в котором устройства IoT смогут подключаться и отключаться к распределенным системам, не вызывая простоя в сборе и хранении данных или не полагаясь на облачные технологии хранения или полагаться на облачную систему хранения для синхронизации данных между устройствами. Мы также рассмотрим производительность некоторых из этих распределенных систем, таких как Inter Planetary File System (IPFS) и Ethereum Swarm на маломощных устройствах, таких как raspberry pi. 

Читать далее
Всего голосов 2: ↑1 и ↓1 0
Комментарии 4

Азбука libp2p от Textile, часть 2

Время на прочтение 7 мин
Количество просмотров 2.3K

Перевод статьи начального уровня в блоге проекта Textile от 12 декабря 2019 г.

В предыдущей статье мы начали с вопроса: «Как подойти к своему первому p2p-приложению?» После недолгих размышлений мы быстро пришли к выводу, что решение не полагаться на централизованный сервер и сосредоточиться на том, чтобы сделать приложение для равноправных узлов, сопряжено с множеством дополнительных сложностей. Две основные группы «проблем» - это состояние приложения и инфраструктурное разнообразие протоколов. К счастью, мы обнаружили, что нам не нужно изобретать велосипед, заново решая груду инфраструктурных задач - вместо того мы можем использовать великолепный сетевой p2p-стек: библиотеку libp2p.

В сегодняшнем посте мы пойдем немного дальше и представим «игрушечное» приложение, чтобы почувствовать, как на самом деле можно что-то разрабатывать с помощью libp2p, и, надеюсь, мотивировать вас создать собственное p2p-приложение. Серьезно, вы удивитесь, насколько это просто!

Приложение

Сразу оговоримся, наша программа нынче будет написана на языке Go, с использованием библиотеки go-libp2p. Если вы ещё не знакомы с этим языком, настоятельно рекомендуем ознакомиться. Он действительно хорош для приложений, имеющих дело с параллелизмом и сетевыми взаимодействиями (такими, как например, обработка множества p2p-соединений). Большинство библиотек IPFS/libp2p имеют свои базовые реализации, написанные на Go. Прекрасным введением в Go является тур на golang.org.

Итак, наша программка будет простым приложением для пинг-понга с некоторыми добавочными настройками, чтобы сделать её более интересной, в отличие от обычных безыскусных примеров. Вот некоторые особенности нашего приложения (не волнуйтесь, мы расскажем подробней об этих пунктах позже):

Читать далее
Всего голосов 6: ↑5 и ↓1 +4
Комментарии 0

Азбука libp2p от Textile (или за что мы её любим)

Время на прочтение 7 мин
Количество просмотров 3.6K

Перевод статьи начального уровня в блоге проекта Textile от 19 ноября 2019 г.

Первые шаги к созданию децентрализованного приложения могут быть трудными. Изменить привычный при разработке централизованных приложений образ мышления не легко, поскольку распределённый дизайн ломает большинство допущений, устоявшихся в наших мозгах (и программных инструментов, которые мы используем). Чтобы проиллюстрировать то, как наша команда представляет себе одноранговую коммуникацию, мы выпускаем серию из двух статей, посвященную стеку протоколов libp2p. В этой первой статье мы размышляем о некоторых сложностях, связанных с созданием децентрализованных приложений, и выясняем, как абстракция уровня сетевого протокола, такая как libp2p, может нам помочь. В следующей статье (которая скоро появится) мы будем использовать эти же концепции для создания простого примера, написанного на языке Go, чтобы понять, как различные компоненты, о которых мы здесь говорим, связаны друг с другом.

Стремительно нарастающая сложность

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

Читать далее
Всего голосов 9: ↑9 и ↓0 +9
Комментарии 2

Распределённое хранение данных в IPFS Cluster

Время на прочтение 4 мин
Количество просмотров 4.1K


Дисклеймер: эта статья рассчитана на понимание основных принципов работы InterPlanetary File System. Если вы не знакомы с IPFS, начните с этой статьи или загляните на ipfs.io.

Самый известный и труднопреодолимый недостаток IPFS в скорости её работы. Так как все данные разбиваются на блоки и распределяются по пирам, скорость загрузки упирается в скорость интернета (и вообще доступность) сразу нескольких машин, которые мы не контролируем. Частично это решается локальным закреплением (pin) нужных хэшей, что поможет в случае отказа отдельных пиров, но не гарантирует загрузку именно с нашего сервера (например, если запрос поступит с другой части планеты). А ещё зашифрованные и разрезанные данные гипотетически невозможно восстановить, не имея хэша, но ведь и его теоретически можно подобрать, так как вся сеть по сути публична…

Всех этих неприятностей можно избежать, запустив собственный кластер IPFS. Новичку легко запутаться и решить что IPFS это децентрализованная сеть, но на самом деле это протокол, обёртка над p2p — и на нём можно поднимать свои приватные подсети, недоступные извне, сохраняя плюсы децентрализации и все фишки основной сети.
Читать дальше →
Всего голосов 14: ↑14 и ↓0 +14
Комментарии 2

CRDT, RON и Сети Данных

Время на прочтение 6 мин
Количество просмотров 6.5K

Эта статья о следующем эволюционном шаге в развитии систем обработки данных. Тема амбициозная, поэтому расскажу сначала немного о себе. Вот уже больше 10 лет я работаю над проектами в области CRDT и синхронизации данных. За это время успел поработать на университеты, стартапы YCombinator и известные международные компании. Мой проект последние три года – Replicated Object Notation, новый формат представления данных, сочетающий возможности объектной нотации (как JSON или YAML), сетевого протокола и оплога/бинлога. Вы могли слышать про другие проекты, работающие в том же направлении, например, Datanet, Automerge и другие. Также вы могли читать Local-first software, это наиболее полный манифест данного направления Computer Science. Авторы - замечательный коллектив Ink&Switch, включая широко нам известного по "Книге с Кабанчиком" М.Клеппманна. Или вы, возможно, слушали мои выступления по этой теме на различных конференциях.

Идеи этой статьи перекликаются с тем, что пишет последние годы Pat Helland: Immutability Changes Everything и др. Они смежны с проектами IPFS и DAT, к которым я имею отношение.

Итак. Классические БД выстроены на линейном логе операций (WAL). От этого лога выстроены транзакции, от него же выстроена репликация master-slave. Теория репликации с линейным логом написана ещё в начале 1980-х с участием небезызвестного Л. Лампорта. В классических legacy системах с одной большой центральной базой данных всё это работает хорошо. Так работают Oracle, Postresql, MySQL, DB2 и прочие классические SQL БД. Так работают и многие key-value БД, например, LevelDB/RocksDB.

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

Читать далее
Всего голосов 24: ↑22 и ↓2 +20
Комментарии 8

Межпланетная файловая система — Простой блог в IPFS при помощи XSLT

Время на прочтение 13 мин
Количество просмотров 5.5K

Существует проблема: У сайта в IPFS нет возможности использовать серверные скрипты для формирования страницы. Если использовать генерацию страниц перед загрузкой то добавив новый пункт меню в каждую страницу мы изменим хеш этих страниц. Так что всю сборку страниц нужно производить силами браузера.


Обычно формируют содержание страниц при помощи JavaScript. Это знакомая технология но у неё есть свои недостатки.


Я буду использовать XSLT. Это древняя технология шаблонов которая давно встроена в браузеры но мало кто ей пользуется. Возможно потому что шаблоны заставляют писать много текста и из за путаницы с пространствами имён и множества ошибок без внятного объяснения. Также не смотря на то что есть уже XSLT 3.0 в браузерах по прежнему доступен только XSLT 1.0.


XSLT работает так:


  1. Пользователь открывает в браузере XML документ.
  2. В заголовке XML документ содержит ссылку на XSLT шаблон.
    <?xml-stylesheet href="xslt/запись.xslt" type="text/xsl" ?>
  3. Шаблон в браузере на основе XML документа и других данных формирует xHTML документ.
  4. Браузер отображает полученный xHTML документ.

Привязав множество страниц к одному шаблону можно менять отображаемый xHTML документ не меняя XML документы. Таким образом при смене дизайна не будет меняться хеш XML документов а значит старые их копии будут источниками для новых в IPFS.


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


image

Читать дальше →
Всего голосов 9: ↑9 и ↓0 +9
Комментарии 8

IPFS без боли (но это не точно)

Время на прочтение 12 мин
Количество просмотров 22K


Не смотря на то, что на Хабре была уже не одна статья про IPFS.

Сразу уточню, что я не являюсь экспертом в этой области, но не раз проявлял интерес к этой технологии, но попытки поиграться с ней часто вызывало некоторую боль. Сегодня я опять взялся за эксперименты и получил кое-какие результаты, которыми хотел бы поделиться. Если коротко, то будет описан процесс установки IPFS и некоторые фишки (все выполнялось на ubuntu, на других платформах не пробовал).
Читать дальше →
Всего голосов 14: ↑14 и ↓0 +14
Комментарии 36

Бессерверный статический сайт с помощью IPFS

Время на прочтение 5 мин
Количество просмотров 26K
TL;DR: IPFS позволяет хостить статические сайты распределённо, доступ к которым можно осуществлять через публичные кеширующие гейты (прозрачные реверс-прокси) в интернете, без необходимости устанавливать программу посетителю. Такие сайты можно раздавать без маршрутизируемого («белого») статического IP-адреса (будет работать за NAT), они остаются работоспособными при кратковременном (несколько часов) отсутствии раздающих, за счет кеша на гейтах. К гейтам по желанию можно привязать свой домен, причём добавить DNS-записи можно на несколько гейтов одновременно, для повышения надёжности и балансировки нагрузки. Сайт могут скачать другие пользователи IPFS и помочь с раздачей.
IPFS отлично подходит для статических блогов, простых сайтов, файловых архивов (в качестве замены Bittorrent), а также просто для единовременной передачи больших файлов без предварительной загрузки их на какой-либо сервис.

Что такое IPFS?

IPFS — децентрализованная пиринговая система передачи файлов, по принципу работы похожая на BitTorrent, но с возможностью доступа через HTTP, для Web. Все скачиваемые пользователем файлы временно кешируются IPFS-демоном и раздаются другим пользователям, запрашивающим их. Важные файлы можно «прикрепить» (pin) к IPFS-демону, тогда они не исчезнут из кеша.
Читать дальше →
Всего голосов 61: ↑61 и ↓0 +61
Комментарии 32

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн
PG Bootcamp 2024
Дата 16 апреля
Время 09:30 – 21:00
Место
Минск Онлайн
EvaConf 2024
Дата 16 апреля
Время 11:00 – 16:00
Место
Москва Онлайн

Межпланетная файловая система — тривиальный хеш (identity), DAG блок и Protocol Buffers

Время на прочтение 7 мин
Количество просмотров 6K

Недавно в IPFS добавили поддержу тривиального (identity) хеша. В своей статье я расскажу о нём и покажу как его можно использовать.


Напомню: InterPlanetary File System — это новая децентрализованная сеть обмена файлами (HTTP-сервер, Content Delivery Network). О ней я начал рассказ в статье "Межпланетная файловая система IPFS".

Обычно при хешировании проходя через хеш-функцию данные необратимо "сжимаются" и в результате получается короткий идентификатор. Этот идентификатор позволяет найти данные в сети и проверить их целостность.


Тривиальный хеш — это сами данные. Данные никак не изменяются и соответственно размер "хеша" равен размеру данных.


Тривиальный хеш выполняет ту же функцию что и Data: URL. Идентификатор контента в этом случае содержит сами данные вместо хеша. Это позволяет вкладывать дочерние блоки в родительский делая их доступными сразу после получения родительского. Также можно включать данные сайта непосредственно в DNS запись.


Для примера закодируем текстовую строку "Привет мир" в идентификатор контета(CID) с тривиальным хешем.
image

Читать дальше →
Всего голосов 21: ↑20 и ↓1 +19
Комментарии 6

Создание децентрализованного музыкального плеера на IPFS

Время на прочтение 8 мин
Количество просмотров 12K


В этой статье описаны результаты двухмесячных экспериментов с IPFS. Главным итогом этих экспериментов стало создание proof-of-concept стримингового аудио плеера, способного формировать фонотеку исключительно на основе информации, публикуемой в распределённой сети IPFS, начиная с метаданных (название альбома, треклист, обложка), заканчивая непосредственно аудио-файлами.


Таким образом, будучи десктопным electron-приложением, плеер не зависит ни от одного централизованного ресурса.

Читать дальше →
Всего голосов 27: ↑27 и ↓0 +27
Комментарии 23

Межпланетная файловая система — Переключаем свой сайт на localhost (локальный шлюз IPFS)

Время на прочтение 5 мин
Количество просмотров 11K

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


Пользователю это даст быстрый доступ к его локальной копии нашего сайта.


Напомню: InterPlanetary File System — это новая децентрализованная сеть обмена файлами (HTTP-сервер, Content Delivery Network). О ней я начал рассказ в статье "Межпланетная файловая система IPFS".


image

Читать дальше →
Всего голосов 12: ↑12 и ↓0 +12
Комментарии 5

Межпланетная файловая система — Локализуем глобальный шлюз или сайты в IPFS

Время на прочтение 4 мин
Количество просмотров 2.2K

Мы научимся переключать на свой локальный шлюз IPFS сайты, которые этого ещё не делают сами автоматически. Создадим им общий SSL сертификат при помощи OpenSSL в комплекте со Stunnel.


Напоминаю: InterPlanetary File System — это новая децентрализованная сеть обмена файлами (HTTP-сервер, Content Delivery Network). О ней я рассказывал в статье "Межпланетная файловая система IPFS".

image

Читать дальше →
Рейтинг 0
Комментарии 1

Межпланетная файловая система — больше нет необходимости копировать в сеть

Время на прочтение 3 мин
Количество просмотров 19K

Всем хороша идея IPFS но вот только был один недостаток у неё. Данные загружаемые в сеть копировались в хранилище блоков удваивая занимаемое ими место. Более того файл резался на блоки которые мало пригодны для повторного использования.


Появилась экспериментальная опция --nocopy, которая избавляет от этого недостатка. Для того чтобы пользоваться ей необходимо выполнить несколько условий.


Также появился новый тип идентификаторов. Его мы тоже разберём.


Напомню: InterPlanetary File System — это новая децентрализованная сеть обмена файлами (HTTP-сервер, Content Delivery Network). О ней я начал рассказ в статье "Межпланетная файловая система IPFS".

image

Читать дальше →
Всего голосов 24: ↑22 и ↓2 +20
Комментарии 15

Интернет на магнитах 5 — Маяки и сообщения (личные, публичные и обновления)

Время на прочтение 8 мин
Количество просмотров 4.2K

Я вспомнил что не рассказал важную часть для обеспечения возможности общения и обновления контента в P2P сетях.


Не все P2P сети имеют возможность отправки и приёма личных сообщений. Также не всегда сообщение можно оставить в оффлайн. Мы исправим этот недостаток используя три возможности P2P сетей: поиск файла, просмотр шары(списка опубликованных файлов) или комментарии к файлу.


Как это работает


Шаблон маяка создаётся однократно и используется для создания маяков для связи с автором.


Общий алгоритм получения


  1. Публикуется шаблон маяка.
  2. Формируется маяк.
  3. Поиск этого маяка и файла с хешем маяка в имени.
  4. Загрузка найденных файлов или просмотр шары источников маяка.

Общий алгоритм отправки такой


  1. Пишем сообщение.
  2. Шифруем открытым ключом адресата.
  3. Формируем маяк по шаблону адресата.
  4. Получаем хеш от маяка и вставляем в имя файла с сообщением.
  5. Публикуем маяк и файл с сообщением в p2p сетях.

Наше сообщение и маяк свободно могут копировать другие участники сети. Так как оно зашифровано они не смогут его прочитать но помогут его держать онлайн пока его не получит адресат.

Читать дальше →
Всего голосов 13: ↑13 и ↓0 +13
Комментарии 0

Википедия неуязвима для цензуры в сети IPFS

Время на прочтение 3 мин
Количество просмотров 35K
24 августа 2015 года Роскомнадзор распорядился заблокировать Википедию на территории России. Вскоре чиновники одумались и отменили решение. Но это может повториться в любой момент.

29 марта 2017 года турецкие власти последовали примеру российских братьев по разуму. Они тоже заблокировали Википедию. Турки пошли до конца — и с 8:00 по местному времени все версии Википедии были заблокированы в Турции в соответствии с административным решением No. 490.05.01.2017-182198 / 5651.

Как сказал в своё время Джон Перри Барлоу, Интернет по своей сути воспринимает цензуру как неисправность и старается обойти её. Есть много стандартных способов обойти обычную блокировку по IP. Два года назад Сеть породила концептуально новый проект IPFS (Inter-Planetary File System), который делает цензуру конкретных IP-адресов в интернете невозможной в принципе. Здесь вместо адресации по местоположению используется адресация по контенту. В пиринговой сети нет единого центра, который можно заблокировать. Копии распространяются от ноды к ноде. Даже если уничтожить все копии контента, кроме одной, информация снова пойдёт по сети.

IPFS — технология, которая работает уже сейчас, и она полностью готова выручить в ситуации, когда чиновники Роскомнадзора блокируют контент, пытаясь запретить гражданам получить какую-то информацию. Пример Турции отлично демонстрирует это.
Читать дальше →
Всего голосов 65: ↑62 и ↓3 +59
Комментарии 136
1

Вклад авторов