Около десяти лет назад количество подключенных к интернету устройств превысило количество пользователей сети. Это был поворотный момент в истории человечества — интернет людей превратился в интернет вещей. В этой статье мы рассмотрим основные проблемы этого явления, а также возможности их решения с помощью технологии блокчейн.
Рубрика «децентрализованные сети» - 17
Адаптация блокчейна к интернету вещей: главные проблемы
2018-05-27 в 16:02, admin, рубрики: IoT, блокчейн, децентрализованные сети, Исследования и прогнозы в IT, криптография, Разработка для интернета вещей
Простые и мощные краткосрочные смарт-контракты
2018-05-25 в 13:29, admin, рубрики: Ethereum, solidity, Алгоритмы, Блог компании MixBytes, блокчейн, децентрализованные сети, криптография
В последнее время смарт-контракты широко применяются в сети Ethereum в основном для проведения ICO и управления выпущенными токенами. Такие контракты существуют столько, сколько необходимо для обслуживания проектов, при этом месяцами обеспечивают бесперебойное взаимодействие с тысячами клиентов. Будем называть их долгосрочными смарт-контрактами.
Однако определённые задачи требуют, чтобы контракт выполнялся буквально за минуты, после чего он становится не нужен. Причём для каждого пользователя могут понадобиться особые параметры, реализовывать их в рамках большого контракта нецелесообразно. Такие контракты будем называть краткосрочными. Рассмотрим их более подробно в этой статье.
Что такое смарт-контракты: краткое руководство
2018-05-20 в 15:09, admin, рубрики: блокчейн, децентрализованные сети, криптография, смарт-контракт, финансы в ITИдея смарт-контрактов появилась еще в далеком 1994 году, когда Ник Сабо предложил использовать распределенный глобальный код для хранения информации о сделках. На сегодняшний день они считаются очень перспективной технологией, которая сможет значительно упростить и обезопасить многие сферы жизни. Давайте разберемся, как устроены «умные» контракты и зачем они нужны.
TON: Telegram Open Network. Часть 2: Блокчейны, шардирование
2018-05-10 в 11:32, admin, рубрики: blockchain, cryptocurrency, gram, telegram, telegram open network, TON, Алгоритмы, блокчейн, децентрализованные сети, криптовалюта, криптография, шардинг, шардирование
Данный текст — продолжение серии статей, в которых я рассматриваю структуру (предположительно) готовящейся к выходу в этом году распределенной сети Telegram Open Network (TON). В предыдущей части я описал её самый базовый уровень — способ взаимодействия узлов между собой.
На всякий случай напомню, что к разработке этой сети я отношения не имею и весь материал почёрпнут из открытого (хотя и непроверенного) источника — документа (ещё к нему есть прилагающаяся брошюра, излагающая вкратце основные моменты), появившегося в конце прошлого года. Объем информации в этом документе, на мой взгляд, свидетельствует о его подлинности, хотя никаких официальных подтверждений тому нет.
Сегодня посмотрим на основной компонент TON — блокчейн.
TON: Telegram Open Network. Часть 1: Вступление, сетевой уровень, ADNL, DHT, оверлейные сети
2018-04-27 в 17:10, admin, рубрики: adnl, blockchain, cryptocurrency, DHT, gram, kademlia, telegram, telegram open network, TON, Алгоритмы, блокчейн, децентрализованные сети, криптовалюта, криптография
Уже две недели Рунет шумит про Telegram и ситуацию с его бессмысленной и беспощадной блокировкой Роскомнадзором. Рикошетом задело многих, но всё это — темы для постов на Geektimes. Меня же удивило другое — я до сих пор не видел на Хабре ни одного разбора запланированной к выходу на базе Telegram сети TON — Telegram Open Network. Мне захотелось восполнить этот недостаток, ибо поизучать там есть что — даже несмотря на отсутствие официальных заявлений о нём.
Напомню — ходят слухи о том, что Telegram запустил очень масштабное закрытое ICO, уже собрав в нём невероятные суммы. Предполагается, что уже в этом году будет запущена собственная криптовалюта Gram — и у каждого пользователя Телеграма автоматически появится кошелёк, что само по себе создает немалое преимущество перед остальными криптовалютами.
К сожалению, так как официальных заявлений нет, дальше я могу отталкиваться только от документа неизвестного происхождения, о чём я сразу вас предупреждаю. Конечно, он может оказаться очень искусной подделкой, но не исключено и то, что это — реальный whitepaper будущей системы, написанный Николаем Дуровым (и слитый, вероятно, кем-то из инвесторов). Но даже если это фейк, никто нам не запретит его поизучать и обсудить, верно?
Что же говорится в этом документе? Я попробую пересказать его своими словами, близко к тексту, но по-русски и чуть более человечно (да простит меня Николай со своей склонностью уходить в формальную математику). Имейте в виду, что даже в случае его подлинности, это черновое описание системы и оно, весьма вероятно, изменится к моменту публичного запуска.
Вопрос на миллион
2018-04-23 в 14:33, admin, рубрики: blockchain, Etherium, Raiffeisen, raiffeisenIT, solidity, Блог компании Райффайзенбанк, децентрализованные сети, Криптовалюты, криптография, РайффайзенбанкВозможно, многие из вас задавались вопросом: как изменится поведение смарт-контракта, если его данные будут весить сотни мегабайт и хранить сотни тысяч или миллионы записей? Будут ли дорожать транзакции? Как это повлияет на сеть в целом? Будут ли одни типы переменных в solidity справляться с подобной задачей лучше, чем другие? Мы решили лично узнать ответы на эти вопросы и провести эксперимент в нашей приватной сети Ethereum, смоделировав описанные ситуации. Что из этого получилось читайте дальше в статье.
Реестр пакетов на Ethereum
2018-04-18 в 18:48, admin, рубрики: blockchain, Ethereum, node.js, swarm, децентрализованные сети, децентрализованные системы, Программирование, эфир
Сегодня только ленивый не запускает очередной бесполезный проект на блокчейне, в этом уроке я расскажу как сделать что-то имеющее практическое применение. В качестве примера возьмем реестр пакетов наподобие npm только использующий цифровую подпись, децентрализованное хранилище Swarm и смарт-контракты на основе Ethereum.
Proof-of-Proof-of-Work на пальцах. На пути к разумному блокчейну
2018-04-10 в 22:50, admin, рубрики: Анализ и проектирование систем, биткоин, блокчейн, высокая производительность, децентрализованные сети, криптовалюта, криптография, платежные системыБлокчейн-протоколы должны обеспечивать консенсус среди нод децентрализованной системы. Пожалуй, самым известным алгоритмом консенсуса можно считать «тормозунутый, но надежный, потому что тормознутый» алгоритм Proof-of-Work: каждая нода, имея набор новых транзакций перебирает некоторое число nonce, являющееся полем блока. Блок считается валидным, если валидны все транзакции внутри него и хэш-функция от заголовка блока имеет некоторую общепринятую особенность (например, количество нулей в начале, как в Bitcoin):
Hash( Block{transaction,nonce,…} ) = 000001001...
Как известно, блокчейн — это цепочка блоков. Цепочкой он является потому, что внутри каждого блока записан id (как правило хэш от заголовка) предыдущего блока. Для последующих рассуждений блокчейн в упрощенном виде можно представить так:
Взгляд на Tokio: как устроен этот асинхронный обработчик событий
2018-03-22 в 13:46, admin, рубрики: Bitfury Group, Exonum, Rust, Блог компании Bitfury Group, децентрализованные сети
И для чего он используется в фреймворке для приватных блокчейнов Exonum
Tokio — это фреймворк для разработки сетевых масштабируемых приложений на Rust, использующий компоненты для работы с асинхронным вводом/выводом. Tokio часто служит основой для других библиотек и реализаций высокопроизводительных протоколов. Несмотря на то что он является довольно молодым фреймворком, ему уже удалось стать частью экосистемы межплатформенного программного обеспечения.
И хотя Tokio критикуют за излишнюю сложность в освоении, он уже используется в продакшн-средах, поскольку код, написанный на Tokio, легче поддерживать. Например, его уже интегрировали в hyper, tower-grpc и сonduit. Мы тоже обратились к этому решению при разработке нашей платформы Exonum.
Работа над Exonum началась в 2016 году, когда Tokio еще не существовал, поэтому сперва нами использовалась библиотека Mio v0.5. С появлением Tokio стало ясно, что используемая библиотека Mio устарела, более того, с её помощью было сложно организовывать событийную модель Exonum. Модель включала несколько типов событий (сетевые сообщения, таймауты, сообщения из REST API и др.), а также их сортировки по степени приоритетности.
Каждое событие влечет за собой изменение состояния узла, а значит их необходимо обрабатывать в одном потоке, в определенном порядке и по одному принципу. На Mio схему обработки каждого события приходилось описывать вручную, что при поддержании кода (добавлении/изменении параметров) могло оборачиваться большим количеством ошибок. Tokio позволил упростить этот процесс за счет встроенных функций.
Ниже мы расскажем о компонентах стека Tokio, которые позволяют эффективно организовывать обработку асинхронных задач.
