Рубрика «децентрализованные сети» - 20

Перевод статьи Thomas Bertani из блога компании Oraclize
Этот пост дискуссия о том, чем на самом деле являются оракулы, так же мы расскажем о некоторых распространенных заблуждениях по этому вопросу.
Оракул — это третья сторона, вы общаетесь с оракулом когда вам нужны данные, которые вы не хотите (или не можете) извлекать самостоятельно. Причин для этого может быть много.
С одной стороны, вы можете не доверять отдельному объекту при подписании multi-signature транзакции Bitcoin. Например, вы хотите чтобы некоторые средства были перемещены только при определенных условиях. Вместо того, чтобы делать это самостоятельно (что не дает никаких гарантий внешним сторонам) или делегировать это третьей стороне (которой вы не хотите доверять, поскольку она может вести себя некорректно), вы разделяете процесс подтверждения транзакции различным сторонам (оракулам) через multi-signature транзакцию.
Путь с использованием N-of-M multi-signature транзакций заключается в том, что каждый оракул имеет только один закрытый ключ, и может поставить только одну подпись в тот момент когда он сочтет это нужным, но сама транзакция будет действительна одна и N-of-M оракулы будут иметь консенсус относительно того, какая транзакция должна пройти. Это намного правильней, чем доверять одной из внешних сторон, поскольку выбранные оракулы могут конкурировать и вы получаете низкую вероятность мошенничества. Читать полностью »

Прошлый, 2016 год оказался богат на новости, связанные с технологией блокчейн и кейсами ее применения в реальной жизни. Barclays провел первую в мире реальную торговую сделку между ирландским производителем молочной продукции Ornua и сейшельской торговой компанией, австралийский финансовый конгломерат Commonwealth Bank of Australia, американская финансовая компания Wells Fargo и компания Brighann Cotton Marketing Australia впервые в мире оформили сделку по продаже и доставке хлопка из США в Китай, а авиакомпания S7 и Альфа-Банк провели первую в России сделку-аккредитив. В связи с этим может показаться, что область применения блокчейна ограничивается исключительно финансовым сектором, однако блокчейн затронул и область защиты данных.

Как с помощью блокчейна защитить свои данные - 1
Читать полностью »

Почему подключаться под атакой к сервису нейтрализации DDoS уже слишком поздно - 1

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

Предварительное планирование крайне важно, если вы собираетесь создавать популярный и конкурентный сервис где-то в интернете — внимание на него могут обратить не только злоумышленники, но и конкуренты. В конечном счёте, неожиданный и большой наплыв пользователей по сути ничем не отличается от распределённой атаки.

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

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

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

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

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

image

Читать полностью »

В этой статье поднят вопрос удручающей ситуации с доступностью данных в Интернете, злоупотреблением цензурой и тотальной слежкой. Власти ли или корпорации в этом виноваты? Что поделать? Создавать собственные соцсети, участвовать в сетях анонимизации, строить mesh-сети и store-and-forward решения. Демонстрация NNCP утилит для создания этих store-and-forward friend-to-friend решений.

Читать полностью »

Интернет на магнитах 5 — Маяки и сообщения (личные, публичные и обновления) - 1Я вспомнил что не рассказал важную часть для обеспечения возможности общения и обновления контента в P2P сетях.

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

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

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

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

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

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

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

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

Читать полностью »

Всем привет!

У всех нас есть данные, которые хочется держать под контролем. Мы не хотим потерять к ним доступ и не хотим, чтобы доступ был у кого-то ещё. Где хранить такие данные? Я считаю, что Sia может стать идеальным местом для этого и расскажу, почему.

SiaЧитать полностью »

Коллеги, внимание!
По нашей инициативе о внедрении механизма автоматической защиты от возникновения «утечек маршрутов» (route leaks) в протоколе BGP был объявлен adoption call.

Это значит, что начиная с 21 мая 2017 года, в течение двух недель в списке рассылки IETF (подписаться на неё можно здесь: www.ietf.org/mailman/listinfo/idr) будут обсуждаться все «за» и «против» принятия предлагаемых авторами черновика предложений в рабочую группу. В зависимости от результатов голосования, работа над этим документом будет продолжена до получения статуса стандарта (RFC) или заморожена.

Мы просим всех, кому небезразлично состояние BGP-проблематики выразить собственные аргументы на английском языке, в треде писем под заголовком «draft-ymbk-idr-bgp-open-policy-03». Помните, что выражая мнение, вы должны выражать именно свое мнение, как инженера, а не мнение вашего работодателя. Крайне желательно, чтобы ваше мнение было аргументировано — для этого мы рекомендуем ещё раз ознакомиться с нашими предложениями (ссылка на черновик: tools.ietf.org/html/draft-ymbk-idr-bgp-open-policy-03, initiatives.qrator.net/details/route-leak-mitigation).

Напоминаем, что любой может выразить своё мнение в списке рассылки IETF — ценз отсутствует.

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

Спасибо.

Здравствуйте! Меня зовут Александр Азимов, я представляю компанию Qrator Labs. Сегодня я предоставлю вам некоторый апдейт на тему утечек маршрутов. Тему утечек маршрутов нельзя назвать новой, пару раз здесь эта проблема уже поднималась, в том числе мной. Тем не менее, если в зале присутствуют новички, а я надеюсь, что это так — я начну с определения утечки маршрута и возможных последствий.
Читать полностью »

Почему постоянная фильтрация трафика — необходимость - 1
Схема фильтрации шифрованного трафика без раскрытия ключей шифрования.

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

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

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

Одна из ключевых причин заключается в том, что современные атаки развиваются очень быстро — эволюционируют и усложняются в реальном времени. Эволюционирует и сам сервис — сайт и приложение развиваются, поэтому может оказаться, что «нормальное» поведение пользователей во время предыдущей атаки уже не является актуальным.
Читать полностью »

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js