Привет, Хабр! Меня зовут Иван, я разрабатываю сервис онлайн-голосований WE.Vote на основе блокчейн-платформы Waves Enterprise. Сама идея голосований в онлайне уже давным-давно реализована разными компаниями, но в любых кейсах повышенной ответственности все равно прибегают к старой доброй бумаге. Давайте посмотрим, как электронное голосование сможет посостязаться с ней в максимально строгих условиях.

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

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

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

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

Но что если вам нужно больше?Что если одновременно нужна экономическая эффективность, конфиденциальность принимаемых решений и максимальная теоретическая невозможность для оператора сервиса онлайн-голосований повлиять на их результат? Представьте гипотетическую ситуацию, в которой одна глобальная корпорация Кэппл принимает решения о своей глобальной стратегии развития на инфраструктуре другой глобальной корпорации Тубель.Сколько бы соглашений и договоров нибыло подписано удержится ли Тубель от возможности подсмотреть, о чем там договаривается его прямой или косвенный конкурент? Будет ли менеджмент Кэппла спать спокойно, будучи уверенным, что никто не вмешается в их прорывные планы развития?

Стоит ли, положившись на идеальность нашего мира, отвечать на оба вопроса да? Или мы можем создать техническое решение, отвечающее всем требованиям?Давайте посмотрим.

Чего мы хотим добиться

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

1. Организатор голосования создает повестку и хочет управлять правилами доступа к этой повестке: сделать ли ее публичной или раскрыть только участникам голосования.

2. Организатор голосования создает список его участников и хочет быть уверенным, что в его голосовании примут участие именно они. Сами участники также заинтересованы в этом, так как подразумевается, что они принимают решение по важному для них вопросу и мнение/намерения/выгода третьих лиц не должны на это решение повлиять.

3. Организатор задает правила проведения голосования. Эти правила без раскрытия сути голосования должны быть доступны широкой публике, чтобы организатор, участники голосования и третьи лица (например, регулятор) могли убедиться, что способ принятия решения был выбран корректно и все прошло по заранее известному плану.

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

5. Участник голосования заполняет бюллетень и хочет убедиться, что его голос будет учтен, его голос не будет изменен и никто не сможет определить, как именно он проголосовал (частный случай открытых голосований оставим в стороне).

6. Организатор и участники голосования узнают его результаты. В этот момент все хотятбыть уверены,что никто не вмешивался в ход голосования, не фильтровал бюллетени, не делал вбросов, не подправлял итоги и т.п.. Все включая и оператора онлайн-сервиса голосований.

При чем тут блокчейн

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

Распределенное хранение

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

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

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

• повестка и материалы голосования;

• контактные данные пользователей идентификатор пользователей в реальном мире (e-mail или номер телефона);

• персональные данные пользователей в целом, в системе не требуются, но делают работу удобнее как для организатора голосования, так и для самих участников;

• пара публичного и приватного ключей участника голосования работают как внутрисистемный идентификатор пользователя и дают возможность участвовать вголосовании.

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

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

Пара ключей создается пользователем локально, на его персональном устройстве. Приватный ключ этого устройства не покидает, а публичный сохраняется набэкендекак параметр учетной записи. Организатор голосования работает со списком участников в виде Ф.И.О. и e-mail. При сохранении данных голосования в блокчейне туда же уходит список публичных ключей. Голос подписан ключом пользователя, и если публичный ключ отправителя есть в списке участников, мы принимаем бюллетень. Такая схема позволяет,с одной стороны,не светить персональными данными пользователей, а с другой сделать более прозрачной работу системы.

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

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

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

Подводя промежуточный итог, можно сказать,что:

• Мы решили проблему прозрачности и immutable-хранения исторических данных, используя блокчейн.

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

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

Но, несмотря на то что мы обещали обойтись без магии, она все-таки произошла. Для шифрования бюллетеней нам понадобился открытый ключ голосования, но никто не сказал, откуда он взялся! Очевидно, что это предельно важная часть всего процесса голосования и к нему нельзя отнестись легкомысленно. Еще более интересным кусочком пазла является приватный ключ, соответствующий открытому ключу голосования, так как именно с его помощью мы сможем получить итоги голосования.Настал момент шагнуть в область криптографии (которая для 99.9% людей не сильно отличается от магии).

Криптография

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

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

Несколько болеенадежным вариантом будет техника разделения приватного ключа после генерации хорошо известная схема разделения секрета Шамира. Ключевая пара создается, публичный ключ сохраняется в блокчейне как открытый ключ голосования, а приватный ключ разделяется на несколько частей, которые независимо хранятся доверенными участниками. Чтобы подвести итоги голосования, приватный ключ необходимо собрать и после этого расшифровать бюллетени. Если кто-то из доверенных участников заболел, схема Шамира предполагает возможность сбора приватного ключа меньшим количеством участников. То есть если ключ был разбит на N частей, собрать обратно его можно, используя K частей, где K < N.

Такой вариант выглядит гораздо более надежным и продвинутым, и это действительно так. Но есть нюансы. Во-первых, в промежуток времени между генерацией ключа и его разделением он является очевидной мишенью для злоумышленников и единой точкой отказа системы. Во-вторых, после сбора ключа мы получаем возможность расшифровать каждый индивидуальный бюллетень. Это не позволит нам их отфильтровать, так как они уже находятся в блокчейне и никуда оттуда не денутся. Но это позволит нарушить конфиденциальность голосования. На бэкенде есть связка Ф.И.О. и публичного ключа участника голосования, а в блокчейне связка публичного ключа и теперь уже расшифрованного бюллетеня. Мы знаем, как и кто проголосовал можем взять и, например, лишить премии неугодных.

Конечно, существуют механизмы разрыва первой связки персональных данных и открытого ключа через технику слепой подписи, но это очень своеобразный механизм, который необходимо правильно внедрить. При этом всё равно может сохраниться возможность вычислить по IP голосующего. Он приходит на авторизованный метод получать слепую подпись, а потом стучится на неавторизованный метод отправить голос. Формально во втором случае мы не знаем, кто именно к нам пришел, и опираемся только на проверку слепой подписи. Но у нас есть возможность сопоставить параметры устройства/браузера/соединения и понять, что это тот самый Иванов, который 5 минут назад получал у нас слепую подпись. Или представим похожую атаку на сопоставление по времени получения подписи и отправки голоса. Когда голосующие идут толпой по 500 человек в секунду, такая атака теряет свою эффективность, но при меньшей нагрузке вполне себе работает.

Попробуем сделать лучше?

Распределенная генерация ключа

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

Для формирования общегооткрытогоключа голосования (MainPubliсKey) используется алгоритм DKG (distributed key generation) из статьи TorbenPrydsPedersenA threshold cryptosystem without a trusted party,перенесенный на эллиптические кривые (в оригинальной статье используется мультипликативная группа конечного поля (поля Галуа)GF(p)). При этом есть ограничение:при любой жалобе (не сходится контрольная сумма) одного из участников на другого необходимо перезапустить процесс генерации с самого начала.

В нашей текущей реализации DKG используются стандартные эллиптические кривые seсp256k1 (Bitcoin, Ethereum) и функция хеширования SHA-256. Можно легко добавить, например, Ed25519 или даже российские кривые ТК-26 и хеш Стрибог, если потребуется. Также можно не завязываться на 256-битных кривых, а использовать 512-битные.

Участниками DKG у нас будут несколько экземпляров криптографических сервисов, выполняющих всю криптографическую магию. Чтобы не возникало вопросов о возможности непрозрачного общения между сервисами, единственным их интерфейсом будет взаимодействие с блокчейн-нодой. Один декрипт одна нода. Принципиально такое соотношение 1 к 1 не требуется, декриптов может быть больше или меньше чем нод, но выглядит логичным иметь одинаковый уровень децентрализации как на слое хранения/транспорта данных (см. раздел выше), так и на слое криптографии.

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

Протокол DKG Pedersen 91 на эллиптических кривых

Параметры протокола:

1. Эллиптическая кривая E и генератор (Base) подгруппы этой кривой большого простого порядка q.

2. Другой генератор (BaseCommit) той же подгруппы, для которого число x из соотношения BaseCommit = x * Base неизвестно никому.

3. (k, n), гдеnобщее число развернутых криптографических сервисов (DecryptService), сгенерировавших пары ключей, аkминимальное число сервисов, которое необходимо для восстановления общего секрета. k <= (n+1)/2, то есть еслиk - 1участниковнечестные или у них украли ключи, то это никак не повлияет на безопасность общего секрета (MainPubliсKey).

Шаг 0. Индексы DecryptService

Каждому изnDecryptServiceприсваивается уникальный порядковый номер от 1 доn. Это нужно, потому что от порядкового номераDecryptServiceзависит коэффициент Лагранжа, который потребуется для реализации схемы K из N.

Шаг 1. Создание открытого ключа голосования

Каждый изnDecryptServiceгенерирует пару публичного (Pub_n)и приватного (priv_n) ключей для эллиптической кривой: j-йсервер генерирует пару ключей:priv_j,Pub_j,гдеPub_j = priv_j * Base(точка Base генератор простой подгруппы). И делает Pedersen commitment для публичного ключа:

1. Генерируется случайное число, скалярr_j.

2. Вычисляется точка, коммитС_j = r * BaseCommit + Pub_j.

3. С_jпубликуется в блокчейн.

После того как каждый изnDecryptServiceопубликовал свой коммит ПедерсенаС_j, каждый DecryptService публикует свой скалярr_j. На основе опубликованных в блокчейне скаляров любой сторонний наблюдатель может восстановить публичные ключи каждого DecryptService Pub_j =С_j -r * BaseCommit а затем вычислить общий публичный ключ Pub (MainPublicKey) как сумму отдельныхPub_j.

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

Шаг 2. Генерация полиномов и раздача теней

Каждыйj-йDecryptService случайным образом:

• Генерирует полином степениk - 1:f_j(x) = f_j_0 + f_j_1*x + ... + f_j_k-1* x^(k-1), где коэффициентf_j0 = priv_j, а остальные случайные элементы поляGF(q), гдеq порядок подгруппы точек.

• Считает значения полинома для каждогоi-гоизnзначений:f_j(i) = f_j_0+ f_j_1*i + ... + f_j_k-1* i^(k-1). Значениеf_j(i)называется тенью (shadow).

• Шифруетf_j(i)при помощиPub_iдля всех других серверов и публикует результаты шифрования. Таким образом,значениеf_j(i)может узнать только владелецpriv_i, т.е. DecryptService номерi.

Шаг 3. Проверка коэффициентов полиномов

Чтобы убедиться, что каждый из DecryptService следует протоколу DKG, они проверяют значения теней, полученных друг от друга. Каждый DecryptServiceпубликует каждый коэффициент своего полинома, умноженного на генератор Base: j-й сервер:f_j,0* Base, f_j,1* Base, ... , f_j,k-1* Base, где f_j,k-1 это коэффициент при степениk - 1.

После этого каждыйi-йDecryptServiceпроверяет все расшифрованные тениf_j(i)(гдеjиз множества от 1 доn, исключаяi), которые для него зашифровали другиеn - 1участников DKG. i-йDecryptServiceдля тени от сервераj:

1. Вычисляетf_j(i) * Base

2. Берет экспоненты его коэффициентов:f_j,0* Base, f_j.1* Base, ... , f_j,k-1* Base

3. Домножает каждый на соответствующую степеньi:f_j,0* Base, i * ( f_j,1* Base), ... , i^(k-1) * ( f_j,k-1* Base)

4. Складывает их.

Если результат сложения равенf_j(i) * Base(тень отjдляi, умноженная на генератор), то результат принимается. В противном случае публикуется жалоба на серверj: значение тениf_j(i), и протокол запускается с самого начала шага 0.

Если ни у кого нет жалоб, то каждый сервер вычисляет свой секретный ключs_iкак сумму значенийf_j(i)от всехjсерверов, включая себя.

Если взять любые изkучастников, то сложив ихs_i * Lagrange(k, i), где Lagrange(k, i) коэффициент Лагранжа, который зависит от номеров из выбранной группы (k) и номераi, мы получим приватный ключ, соответствующий общему ключу Pub (MainPublicKey), то есть по сути сумму всехpriv_i.

После того как мы выполнили шаг 3, мы можем быть уверены что у нас есть валидныйобщий открытый ключголосования (MainPublicKey), а также набор соотвествующих ему приватных ключей, хранящихся на независимых криптографических сервисах. После этого мы можемопубликовать открытый ключголосования в блокчейне и использовать его для шифрования бюллетеней.

Мы решили проблему угона приватного ключа до начала голосования. Он не был создан централизовано, и чтобы получить доступ к данным голосования, злоумышленнику необходимо взломать K серверов, а не один. Но остается вопрос: как мы будем проводить расшифровывание. Будем ли мы собирать приватный ключ в этот момент и дадим ли шанс злоумышленнику? Пожалуй, не дадим.

Шаг 4. Распределенное дешифрование

Допустим, мы зашифровываем сообщение M на открытом ключе голосования (MainPublicKey):

1. Генерируем число r и считаем R = r * Base.

2. ВычисляемС = M + r *MainPublicKey.

3. Получившийся шифротекст пара точек (R, C) мы публикуем в блокчейне.

4. Владелец приватного ключаprivвычисляет значение:priv * R.

5. И расшифровываетM:M = С -priv * R.

Таким образом, для расшифровывания (R, C) нужно вычислитьpriv * R.

Если наш приватный ключ распределен (допустим, что (k, n) = (3,6)), каждый криптографический сервис независимо считает значениеs_i * R, используя свою часть приватного ключа, и публикует результат в блокчейне. Назовем это значение частичной расшифровкой. Дальше остается домножить любые 3 из 6 результатовs_i * Rна соответствующий коэффициент Лагранжа, сложить три точки и получить priv * R. А используя это значение, мы расшифровываем сообщение М.

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

Гомоморфное шифрование

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

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

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

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

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

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

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

Зашифрованное сообщение 1: ( R1, С1 ) =( r1 * Base,M1 + r1 *MainPublicKey)

Зашифрованное сообщение 2: ( R2, С2 ) =( r2 * Base,M2 + r2 *MainPublicKey)

Их сумма: ( R1 + R2, C1 + C2 ) = ( ( r1+r2 ) * Base, M1 + M2 + ( r1 + r2 ) *MainPublicKey)

Сумму расшифровываем так же, как отдельные сообщения (помним чтоMainPublicKey= priv * Base):

( M1 + M2 ) = ( C1 + C2 ) priv * ( R1 + R2 ) = M1 + M2 + ( r1 + r2 ) *MainPublicKey priv * ( r1 + r2 ) * Base = M1 + M2

Кто-то скажет магия, кто-то возразит математика.

В результате мы, кажется, сделали все возможное, чтобы защитить участника голосования. Его голос нельзя подделать, его нельзя прочитать, его практически нельзя заблокировать или потерять. Участника голосования нельзя лишить премии за выбор неправильного кандидата.

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

Доказательства с нулевым разглашением (ZKP Zero Knowledge Proofs)

Однако не только организатор или внешний злоумышленник могут иметь мотивацию повлиять на исход выборов. Нарушитель может затесаться и в ряды участников голосования. Поскольку мы используем очень простую механику сложения столбиком и не заглядываем в индивидуальные бюллетени, у участника голосования есть возможность покопаться в клиентском приложении и сформировать бюллетень, где он вместо "1" проставит за своего кандидата значение 100500. Или 100500 за того, кого недолюбливает. Система посчитает итоги, и кандидат нарушителя победит с внушительным преимуществом.

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

Одна из самых наглядных демонстраций работы ZKP (интерактивной разновидности) это Пещера Али-Бабы или Лабиринт:

Участник A обладает ключом, открывающим дверь в лабиринте, и хочет доказать это участнику B, но не хочет показывать ключ. Чтобы В мог убедиться в верности утверждения А, они организуют серию испытаний:

1. А заходит в лабиринт пока В отвернулся. В не знает, в какую сторону пошел А.

2. В дает А указание выйти с какой-либо стороны, например, слева.

3. Если А действительно обладает ключом, он может появиться с любой стороны и выполняет указание В.

Шанс того, что А просто повезло, и он, не имея ключа, изначально пошел налево, составляет 50/50. Поэтому они повторяют испытание еще и еще раз, пока вероятность везения не станет пренебрежимо малой, и В не признает, что А действительно обладает ключом. При этом В не увидит самого ключа, не получит никакой информации, которой обладает А (направление, которое А выбирает в каждом испытании), но в результате серии испытаний он получит достоверное (вероятностное, но с любой необходимой В точностью) доказательство.

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

ZKP на бюллетене

По каждому вопросу мы, помимо заполненных и зашифрованных ячеек с вариантами выбора, к каждой ячейке приложим NIZK, доказывающее, что в этой ячейке зашифровано одно из значений 0 или 1 но не раскрывающее, какое именно. И дополнительно приложим доказательство, что зашифрованная сумма значений всех ячеек по вопросу равна 1. Это означает, что участник голосования может поставить 1 в любую из ячеек и выбрать только один вариант.

При желании (а оно у нас есть) мы можем на базе этой схемы ZKP реализовать более сложные схемы голосований. Например, взвешенное голосование, где каждый участник отдает не один голос, а количество голосов, пропорциональное своей доле акций компании. Для этого мы должны вместо 1 создать ZKP для значения веса голоса участника. Или вариант голосования с множественным выбором, где каждый голосующий может выбрать не один вариант из N, а несколько. Для этого мы по каждой ячейке добавляем ZKP для ряда значений [0, 1, 2, 3]. Суммарный ZKP может быть на значение [3] тогда голосующий должен распределить все свои голоса. Или на ряд значений[1, 2, 3] то есть он может выбрать от 1 до 3 вариантов, но не может не ответить на вопрос.

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

Структура зашифрованного бюллетеня выглядит следующим образом:

(R_1, C_1), Proof_1,

.........................

(R_M, C_M), Proof_M,

Sum_Proof

Система принимает только те бюллетени, все ZKP которых прошли проверку валидности. То есть наш нарушитель из числа участников голосования может испортить свой бюллетень (так же как в случае с бумажным бланком), но не может воспользоваться тем, что мы не подсматриваем в содержимое его голоса мы имеем возможность убедиться в правильном заполнении бюллетеня без его расшифровки.

ZKP на частичных расшифровках

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

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

Второе условие: если расшифровывание нескладывается,и мы подозреваем, что некоторые криптографические сервисы решили саботировать голосование, неплохо бы иметь возможность проверить, какой именно из сервисов сбоит. Для этого при публикации частичных расшифровок каждый криптосервис создает и прикладывает ZK-доказательство расшифровки, используя алгоритмZKP Chaum-Pedersen, который доказывает знание числа x для двух соотношений A = x * B и C = x * D (где A B, C, D точки на одной кривой).

Теперь у любого квалифицированного стороннего наблюдателя есть возможность:

• самостоятельно провести гомоморфное сложение валидных бюллетеней и получить итоговый бюллетень;

• проверить доказательства расшифровки этого суммарного бюллетеня от каждого криптографического сервиса;

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

Для удобства последний шаг мы проведем сами и зафиксируем итоги голосования в блокчейне как массива массивов вида [ [ 2,5,6 ], [ 3,5,5 ], [ 7,6 ], [ 10,3 ] ].

Смарт-контракты

Фух, кажется, мы описали протокол голосования, который, используя распределенные технологии и криптографию, позволяет дать честным участникам и организаторам голосований все необходимые гарантии и защищает процесс коллективного принятия решений от внутреннего и внешнего нарушителя. Очевидно, при условии правильной децентрализации распределении узлов системы между независимыми участниками; без этого мы получаем замороченные Google Forms :)

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

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

А что дальше?

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

Еще одно важное для нас направление развития то, о чем разработчики, увлеченные красивым решением технической проблемы, склонны забывать. А именно UX опыт пользователя :)Прикрутить блокчейн это современно, модно,и в данном случае даже целесообразно, но попробуйте пользователю, который привык к UX современных мобильных и веб-приложений, объяснить, что такое его персональный приватный ключ и что без него он не сможет сделать в системе ровным счетом ничего.Или дать ему одновременно гарантию, что отправленная им транзакция будет принята системой, не заставляя ждать его, пока мы сами в этом убедимся. Нода майнит, прелоадер крутится, пользователь ждет и не понимает чего именно: Ну не знаю, почту я отправляю, все работает мгновенно, а тут чего-то ждать надо?. Поэтому мы активно работаем над тем, чтобы система сохраняла привычные пользовательские свойства, не теряя своих технологических преимуществ.

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

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

Приветствую.

К рекламе никакого отношения нет.
Так как разместить статью в "Я пиарюсь" пока запрещено, то публикую обычную статью, так как время поджимает.

ВВЕДЕНИЕ.

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

Основная задача мероприятия - найти достойных людей для кооперации и взаимодействия, а потом уже само поселение (построить само поселение не так уж и сложно).

Почему основная задача найти достойных людей - потому что "лучше будь один, чем вместе с кем попало."
Нас несколько семей - "маловато будет" - идеальный вариант 50-100 семей - будет меньше - не проблема.
Создание правильной среды для воспитания спиногрызов.
Взаимодействие и кооперация внутри поселения и вне его.
Организованно можно сделать/решить напорядок больше чем по одиночке.
Взаимопомощь, взаимовыручка итд итп.

Даже если поселение не стартанет, то в любом случае будет положено начало знакомству людей друг с другом, а там по нарастающей.

Нет цели создать "поселок программистов" - чем большее многообразие специалистов, тем лучше для всех.
Таким образом можно закрыть все или почти все сегменты внутри поседения:
- вкусная и полезная еда (частично закрыто);
- воспитание и обучение;
- медицина (частично закрыто);
- одежда;
- жилье (частично закрыто);
- итд итп.
В общем чем большей автономности и взаимодействия внутри поселения получится создать, тем лучше.

Создание всей оптимально необходимой инфраструктуры.

Возможно рассмотреть каждый дом как отдельную ноду (децентрализация) итд итп и все такое прочее.
Вопрос целесообразности.
Глобальная задумка - рассмотрение домохозяйств или поселений как своего рода mesh-сеть.

Территориально - планируем в ближнем МО, однако, если большинство будет за другой вариант, то также без проблем - концепция удаленого поселения также подходит.

Исключается взаимодействие со следующими:
- хитрожопые;
- те, кому собственная шкура всегда дороже;
- итд итп.
Практический опыт показал, что вреда от них больше, чем пользы.
Садится в поле с ними такое себе, а в разведку - тем более.

ВАРИАНТ 1

Новорижское шоссе 18км от МКАД.

Вокруг:
- КП "Павлово-2" - администрация точно отбитая, по жителям информации мало (скорее всего адекватных больше);
- СНТ "Березка" - администрация адекватная, большая часть жителей тоже;
- СНТ "Усадьба" - администрация адекватная, половина жителей тоже (со второй половиной не пересекались, но со слов Председателя, вроде ормально).

Аналоги (экология, природа итд итп) в ближнем МО отсутствуют.

Участок ~ 7Га.
Возможно расширение (2-ая, 3-я и 4-ая очереди) что никак не затроент природу вокруг (что есть хорошо).

Так как рядом с Мск, то продажная стоимость за 1 сотку 250-350тр с учетом дисконта.
Исходя из этого большая часть участков по 6 соток, оставшиеся от 6 до 9 соток.
Участки можно объединять.
Итоговая стоимость 1 сотки со всей инфраструктурой будет выходить от 500 до 700тр - зависит от того как много будет этой самой инфраструктуры, какой ландшафт итд итп (вокруг от 600тр до 1800тр).
Также можно рассмотреть вариант поэтапного развития инфраструктуры, тогда стоимость 1 сотки будет ниже.

Электричество на участке - подстанция (надо будет перенести).

Газ по границе, однако стоимость подключения достаточно высокая.
Если готовы к расходам, то почему бы и нет.
В нашем случае газ не принципиален.

Водоснабжение - скважина.

Канализация - септик глубокой очистки (далее или полив участка или полив леса итд)

Вся инфраструктура в 15 минут езды - ТЦ, больницы, школы итд.

До Мск добираться можно как своим ходом, так и на общественном транспорте:
- остановки общественного транспорта;
- далее на автобусе или маршрутке до Нахабино или по Новорижскому шоссе;
- от Нахабино на метро и в Мск или по Новорижскому шоссе.
Также можно запустить свой маршрут как до Нахабино, так и в Мск.

ВАРИАНТ 2

Звенигород и окрестности.

Ближнем МО назвать можно с натяжкой, хотя добираться ненамногим дольше по сравению с вариантом 1.

40км от МКАД

Стоимость 1 сотки 300тр в среднем.
С учетом оптовой покупки можно купить в районе 150-200тр за 1 сотку.

ВАРИАНТ 3

Река Шоша, Река Волга или Иваньковское водохранилище.

Дальнее МО.

100-120км от МКАД

Есть платная дорога - по ней за 1 час до Мск - наиболее целесообразно запустить свой транспорт.
По обычной дороге ближе к 2 часам.

Как раз рассматривались варианты земельных участков под поселения.
Продажная стоимость за 1 сотку варьировалась от 50тр до 150тр.

ПЛАН ДЕЙСТВИЙ

1. Поиск достойных людей (просьба писать в ЛС тем, кто решительно настроен);

2. Знакомство, начало взаимодействия;

3. Разработка проектно-сметной документации (эскизная проектно-сметная документация готова), согласования, получение ТУ, разработка ППТ и получение разрешения на строительство - от 6 до 12 месяцев (зависит от администрации Красногорска);

4. Стройка - займет от 12 до 24 месяцев "с нуля" и "под ключ";

5. Полноценное заселение.

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

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

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

Благодарю.

"Закопай свои монеты в Открытом Море и к утру разбогатеешь" Криптокот Базилио

Гифка за 580 000$, набор пиксельных панков за 7.5mil$ и Kings of Leon выпускающие свой альбом прямо на нем. О дивный новый мир искусства и какого черта в нем вообще происходит?

Аве Кодер!

Сегодня я расскажу вам сказку о невиданной широкой публике зверушкой, а именно про так называемые NFT и разумеется нас будет особенно интересовать техническая сторона вопроса ну и на протяжении всей истории, я конечно же, как винтажный газогенератор, буду удивляться - куда катится мир. <cut/>

Итак NFT или Non-Fungible Token, то есть Незаменимый Токен представляет из себя , по сути, набор цифровых данных на блокчейне.

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

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

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

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

С цифровым искусством все одновременно так и не так. Художник создает свою картину сразу в цифре, то есть в привычном нам графическом формате.

Эта картина, попадая в интернет уже становится легкодоступной кому попало - ее можно легко скачать и та самая картинка в формате джепег, которую я скачал посредством правого клика мыши будет абсолютно такой же как и та же картинка у какого-нибудь Мясистого Джо из Гваделупы, потому что в Гваделупу также завозят мышки с двумя кнопками.

Так вот этот самый NFT токен, привязанный к картинке и дает такое же право собственности, которое дает какой-нибудь аукцион Сотбис обладателю оригинала Дали, разве что вместо картины известного мастера у себя над камином, твой джепег может также продолжать висеть в интернете, я и Мясистый Джо также можем использовать ее как заставку на рабочем столе, только теперь весь мир знает, что на самом деле, принадлежит она только тебе, а у нас всего лишь копии.

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

Дело в том, что такие токены и соответственно право владения цифровой единицей размещаются на публичном Блокчейне. То есть в теоретическом будущем, если технология NFT реализует свой потенциал такие токены будут способны перемещаться по всей экосистеме; если совсем на пальцах, то вы не будете заперты внутри той маленькой экосистемы, в которой вы приобрели свой цифровой продукт, например заходить в игровой обменник, чтобы продать кому-то скин, а сколько было случаев, когда кто-то брал билет у перекупщиков и уже на входе выяснял,что это подделка? Подразумевается, что блокчейн и система токенов навсегда решат проблему с ликвидностью и контрафактами, но пока это только-только зарождается.

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

Затем появляются пиксельные CryptoPunks, коллекция в десять тысяч голов, каждая из которых представляла собой уникальный коллекционный арт объект. И их токены уже гоняли на этом вашем Эфириуме.

И если не все оценили криптопанков, то как насчет котиков? Именно с запуском CryptoKitties в 2017 году по сути и начинается отсчет прихода NFTишек в мейнстрим. Котики делились на поколения, первый кот пришедших вмейнстрим был мейн-кун, шутка! На самом деле их было даже несколько и все они принадлежали к так называемому поколению 0.

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

Все благодаря умному контракту зашитому в самого котика и определяющего его генетический код или как его называли сами создатели - котрибуты.

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

Итак, теперь о технической стороне вопроса. На чем же можно эти токены создавать? Поскольку блокчейн изначально затачивался под Ethereum, то и стандарты самых популярных умных контрактов написаны на Solidity, который очень подозрительно похож на JavaScript.

Стандарт ERC721, популяризированный CryptoKitties позволяет с легкостью сопоставлять уникальные идентификаторы, каждый из которых представляет собой единичный цифровой актив с адресом владельца этого идентификатора, а также позволяет передачу актива посредством метода transferFrom. Также можно пробить и владельца определенного контракта, при помощи метода ownerOf.

Стандарт ERC1155 заточен представлять класс активов. К примеру, один и тот же ID может обозначать сразу сотню цифровых единиц чего либо, скажем класс одинаковых билетов-приглашений на фермерских фестиваль мир гусей и куриц, и предположим, что наш кошелек содержит тысячу таких приглашений, за отображения количества единиц в кошельке отвечает метод balanceOf, а за перемещение активов со счета отвечает метод transferFrom.

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

Тут-то в дело и вступает метадата. Метадата - это что-то вроде данных о данных, небольшая надстройка, описывающая дополнительные атрибуты, очень часто в читаемом для людей виде.

В случае с криптокотами, метадата содержит имя кота, картинку кота и прочие дополнительные котрибуты.

В случае с билетом на мероприятие, метадата может содержать дату проведения, тип билета, возможно имя владельца, место и прочее.

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

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

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

Ну так вот, несмотря на очевидные плюсы хранения метаданных в самом блокчейне, подавляющее большинство проектов предпочитает держать их в сторонних хранилищах. Почему? Из-за очевидного минуса, а именно органичения по месту. Конечно, стандарты растут как грибы и размножаются как они же, поэтому данную неприятность таки решат.

Ну а пока, стандарт ERC721, к примеру, имеет метод tokenURI, который как раз и указывает на места хранения метаданных.

Итак, как же нам создать свой NFT токен? Естесственно можно заморочится, включить свою любимую IDE и освоить Solidity. Если вы владеете JavaScriptom, то для вас это будет что-то вроде освоения Болгарского языка после Русского.

Кстати процесс создания токена называется minting, то есть чеканка. Да, мальчик, mint это не только мята, но и чеканка и первый класс и свежесть и еще много чего.

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

Open Sea, которая является и самой крупнейшей берет порядка 60-ти баксов за открытие счета и 40-ка за минт. Есть оптимистичные новости, что летнее обновление ethereum блокчейн поможет существенно снизить эти затраты, но это, как говорится, только мечты.

И что мы по итогу имеем? Дабы огорчить всех тех, кто придет гадить в комменты с криками: что ты такое говоришь, V, там все совсем по-другому, ты не понимаешь смысл пустошей и прочую ерундистику, вот вам еще одна аналогия.

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

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

Теперь вы сидите такой дома и любуетесь на картинку на коробке из-под пазла.

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

Послесловие

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

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

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

А это был V, до новых встреч!

P.S. то же самое, только моим заунывным голосом и под веселые картинки:

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

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

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

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

• У них ненадежное оборудование и сеть.

• У них неопределённые технические параметры, такие, как вычислительная мощность и доступный объём долговременной памяти.

• Брандмауэры могут блокировать их либо они могут находиться в сетях с NAT.

• Они могут использовать старые версии приложений.

Прежде, чем вы начнёте писать свою первую строку кода, вы можете просто замёрзнуть из-за огромного объёма работы, которая вам предстоит. Даже если вам удастся выпустить первую версию приложения, - насколько легко затем будет что-то изменить без особых разрушений вокруг? Не правда ли, было бы неплохо иметь некую библиотеку, которая облегчила бы нашу задачу?!

Libp2p приходит на помощь!

Libp2p - библиотека, появившаяся в результате работы Protocol Labs над IPFS. Если вы хоть немного следите за нашим блогом, то знаете, что мы их большие поклонники! Когда вы берётесь за написание p2p-приложения производственного уровня с нуля, то понимаете, что создаёте не только приложение, но и его инфраструктуру - и до вас очень быстро доходит, что требуется дополнительно изобрести ещё кучу колёс. Не весело, однако. С другой стороны, libp2p позволяет вам встать на плечи неких не хилых гигантов, дабы уменьшить сложность инфраструктуры - и чтобы вы могли сосредоточиться на бизнес-логике. А вот это уже веселее! Конечно, libp2p - не панацея в борьбе со всеми нашими p2p-чудищами, но она определённо облегчает бремя реализации инфраструктуры взаимодействия.

Основные концепции Libp2p

Сердцевиной libp2p является объект Хост (Host), который представляет наш локальный узел в сети p2p. Общее описание его компонентов:

• Идентификатор, по которому наш узел опознаётся другими узлами.

• Набор локальных адресов, по которым к нам можно обращаться.

• Журналы сведений о других узлах: об их идентификаторах, ключах, адресах и т. д.

• Сетевой интерфейс для управления соединениями с другими узлами.

• Muxer, который позволяет единичному соединению работать с несколькими протоколами (подробнее об этом позже).

Следующая базовая абстракция в libp2p - это Потоки. Поток (Stream) - это канал прямой связи с другим узлом. Важно понимать разницу между Stream и "грубым", "сырым" ("raw") сетевым протоколом, таким как TCP или UDP - ибо здесь открывается вся мощь libp2p: сами по себе сетевые протоколы - лишь средства отправки байтов по сети. Если вам нужна высокая надежность доставки пакетов, вы можете использовать TCP, в других случаях UDP может оказаться предпочтительнее. Короче, сами сетевые протоколы не заботятся о том, какие данные передают; для них это просто байты.

Stream же - это поточный канал связи между двумя одноранговыми узлами, имеющий определенную семантику. Тут уже не просто байты, но байты, соответствующие протоколу (более высокого уровня), определённому разработчиком. Протокол этот помечается идентификатором, например /sumtwointegers/v1.0.0. А сам Stream - диалог в рамках данного протокола. К примеру, одна сторона отправляет два целых числа, а другая отвечает их суммой. Вот что мы подразумеваем под потоком байтов с семантикой.

Потоки работают поверх сетевых протоколов, таких как TCP или UDP - по сути, идея состоит в том, чтобы отделить p2p-коммуникацию от сетевых протоколов (более низкого уровня). Нам нужно думать лишь о прикладном использовании поточного канала - для отправки значимой информации, а гибкость работы на любом сетевом протоколе, доступном между узлами, уже заложена в нём (в Stream). Это действительно здорово и мощно. И это также означает, что мы можем оптимизировать функционал раздельно на каждом уровне стека. Нужна лучшая реализация сетевого протокола? Отлично, оставьте это libp2p. Более выразительный семантически дизайн протокола p2p? Круто, это тоже!

Более того, отделение семантики p2p от базовых сетевых протоколов позволяет libp2p пойти дальше и мультиплексировать Потоки в одном и том же сетевом протоколе. Мы можем использовать одно и то же TCP-соединение для многих Потоков. Мы можем запустить протокол умножения двух целых чисел в том же соединении, в котором работали наши протоколы суммы двух целых чисел. Но Streams не обязаны справляться с этим самостоятельно. В действительности Libp2p полагается на мультиплексоры ("Muxers") для исполнения сей магии. Задача мультиплексора - разделить данные (последовательности байтов) на соответствующие потоки внутри одного потока сетевого протокола более низкого уровня. Вот краткая диаграмма, которая немного поясняет сказанное.

Как мы видели выше, у нашего Хоста есть Muxer, который мультиплексирует (объединяет) множество потоков одного узла в одном и том же соединении. Можно сказать, что Максер предваряет сообщения разных потоков некоторыми идентификаторами, чтобы принимающая сторона могла идентифицировать байты разных потоков. Конечно, используемый "нижележащий" сетевой протокол может ограничивать некоторые аспекты мультиплексирования, например, блокировку заголовка. Или же, напротив, сам транспорт (нижележащий сетевой протокол) может включать в себя полностью реализованный механизм мультиплексирования (как, например, QUIC). Но это уже другой разговор...

Возвращаясь на шаг назад

Давайте попробуем отделить то, о чем мы должны думать при написании приложения, от того, что libp2p делает для нас. Со своей стороны (разработчиков) мы хотим иметь ясное представление обо всех вещах, стараясь как можно больше отделить логику нашего приложения от концепций инфраструктуры. Нам следует думать о взаимодействии узлов, а не об адресах. И затем просто реализовать задуманное взаимодействие на уровне абстракции Stream.

На заднем плане libp2p выполняет тяжелую работу по соединению с удалённым узлом, используя информацию, хранящуюся в адресной книге. Она старается определить, какой сетевой протокол оба узла понимают, чтобы установить сетевое соединение. Ловко, однако!

Она, libp2p, может определить, что соединяться вновь не нужно, если у нас уже есть открытое соединение. Когда мы запускаем новый Поток в общении с неким узлом, мультиплексор выполняет рутинную работу по объединению его с другими существующими Потоками в уже установленном соединении.

Зачем так стремиться к множественному использованию одного соединения? Может статься, что наши p2p-приложения должны будут работать в очень ограниченных сетевых средах, где существуют брандмауэры, NAT и ограничения на количество подключений. Поэтому, после того, как мы установим соединение, мы должны выжать из него максимальную пользу! При переходе на образ мышления p2p, вы можете встретить много неизвестного, поэтому использование libp2p поможет вам сосредоточиться на хорошем дизайне, даже если вы не являетесь экспертом.

Но это ещё не всё!

Libp2p разрабатывалась как модульная библиотека. Такой дизайн упрощает изменения в реализации отдельных компонентов без влияния на остальные. Я думаю, что рациональность такого подхода - помимо хорошей инженерной практики - даёт подтверждение разнообразия сред, в которых будет работать наше приложение. И вы можете держать пари, что так оно и есть в приложениях p2p. Наша программа будет способна работать в самых разных средах выполнения, с разными возможностями или ограничениями сети. Кроме того, развитие вашего приложения при сохранении обратной совместимости со старыми версиями программы не является тривиальным делом.

По этой причине, когда два приложения libp2p впервые общаются друг с другом, большая часть их работы заключается в определении того, какой совместимостью они обладают, дабы достичь успеха в коммуникации. Надо выяснить, каким сетевым транспортом оба собеседника пользуются (TCP, UDP, QUIC, Websockets), какие версии протокола мы можем обрабатывать (/myprotocol/v1.0.0, /myprotocol/v1.1.0), какие реализации мультиплексора можем использовать, надо согласовать параметры безопасности, и т. д. И если этого было недостаточно, libp2p имеет ещё целый ряд встроенных протоколов для решения самых разных повседневных задач p2p-приложений, таких как:

• Обход NAT: это больное место у p2p-приложений

• Обнаружение узлов в сети: действительно, как вы обнаруживаете новые узлы вне централизованной модели?

• Pubsub: наличие механизма публикации-подписки для отправки сообщений в нашем приложении без необходимости знать все существующие узлы и без зафлуживания сети

• И многое, многое другое!

Небольшой бонус на заметку: Libp2p очень быстро растёт, поэтому вы можете ожидать появления новых мощных инструментов, которые можно будет использовать с небольшой добавкой собственного кода. Помните, что приложения p2p предполагают разнообразие, поэтому libp2p будет иметь в разных языковых реализациях свои особенности. Скажем, некоторые реализации мультиплексора могут быть недоступны в JS, но вполне себе - в Go или Rust.

Подведём итоги

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

Ну, пока что всё. Следите за обновлениями в нашем следующем эпизоде, где мы переведем некоторые из этих концепций в код на практическом примере. Кроме того, если вам интересны такие вещи или вы хотите интегрировать p2p-коммуникацию в свое приложение или проект, свяжитесь с нами, и давайте поэкспериментируем вместе! Вы также можете попробовать одну из облегченных библиотек, если вам нужен простой способ использования однорангового узла libp2p в браузере, iOS, Android и/или на рабочем столе. Наконец, если вам нравятся такого типа обзорные статьи, сообщите нам об этом или запросите дополнительные темы ... а тем временем, удачного кодирования!

Автор оригинального текста: Ignacio Hagopian

Перевод: Алексей Силин (StarVer)

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

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

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

Приложение

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

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

• По умолчанию приложение цепляется к свободному TCP-порту.

• Если указан флаг quic, оно также подключится к прослушиваемому порту QUIC, который станет предпочтительным адресом узла для игры в пинг-понг.

• Узел будет использовать службу mDNS для обнаружения новых узлов в локальной сети.

• На каждом вновь обнаруженном узле (скажем, узле A) наше приложение будет запускать собственный протокол sayMyAddr (мы его реализуем), который будет узнавать для нас предпочтительный адрес для игры в пинг-понг этого узла.

• Мы подключаемся к узлу А, используя предпочитаемый им адрес - и запускаем танец Пинг-Понг. Другими словами, мы запустим ещё один наш самопальный протокол, посредством которого отправим сообщение Ping, а узел A ответит нам сообщением Pong. Круть!

Даже для такой простой системы (если мы хотим сделать p2p-приложение) потребуется принять ряд отдельных решений. Для начала, надо будет ответить на следующие вопросы:

• Какой транспортный протокол (TCP, QUIC и т.п.) использовать?

• Какой механизм обнаружения других узлов в сети (например, mDNS) применить - то есть, как мы узнаем о других узлах, использующих наше приложение?

• Как наши собственные протоколы (Streams) будут работать? - то есть, как мы будем поддерживать двунаправленную связь с другими узлами?

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

Ныряем в код!

Рекомендуем вам сразу же начать играться с кодом приложения. Он содержит массу комментариев, чтобы помочь читателю впутешествии понимания!Кроме того, здесь мы набросаем общий обзор, который может стать хорошей преамбулой для подробного прочтения кода. Не стесняйтесь клонировать репо себе на компьютер, дабы и вы могли запачкать руки:

КОД:ВДЕЛИТЬ ВСЁ

git clone git@github.com:textileio/go-libp2p-primer-article.gitcd go-libp2p-primer-articlecode . // Нам нравится VSCode, ну а вы - сами с усами ;)

Далее: начнём сmain.go, где вы можете лицезреть, как создаётся и запускается хост libp2p. Дополнительно здесь мы указываем, какие сетевые транспортные протоколы будет поддерживать наш хост. Заметьте, что если для флага -quic установлено значение true, мы добавляем новую привязку для транспорта QUIC. Добавление в работу транспортных протоколов сводится к простому добавлению параметров в конструктор хоста! Также обратите внимание, что мы регистрируем здесь все обработчики наших собственных протоколов: RegisterSayPreferAddr и RegisterPingPong. Наконец, мы регистрируем встроенную службуmDNS.

Теперь заглянем вdiscovery.go, где у нас находится настройка mDNS. Здесь, по сути, надо определить частоту широковещательной рассылки mDNS и строковый идентификатор, который в нашем случае не требуется и потому пустой. Последний шаг здесь - регистрация обработки уведомленияdiscovery.Notifee, которая будет вызываться всякий раз, когда mDNS запускает обнаружение пиров, предоставляя нам их информацию. Логика у нас тут будеттакая:

1. Если мы уже знаем об этом узле - ничего не делаем; мы уже играли в пинг-понг. Иначе же

2. открываем поток нашего протокола SayPreferAddr, чтобы узнать у обнаруженного узла, по какому адресу (addr) он предпочитает играть в пинг-понг. Ну, и наконец

3. добавляем адрес узла в нашу адресную книгу, закрываем текущее соединение с ним и запускаем наш второй протокол PingPong, который повторно подключится к узлу, используя его предпочитаемый адрес (который мы добавили на предыдущем шаге).

Наконец, вpingpong.goмы можем увидеть упомянутый ранее метод RegisterPingPong, вызываемый из main.go, и еще два метода:

• Handler: этот метод будет вызываться, когда сторонний узел зовёт нас играть в PingPong. Вы можете думать о Handler как об обработчике HTTP REST. В этом обработчике мы получаемStream, реализующий io.ReadWriteCloser, из которого мы можем запускать наш протокол для отправки и получения информации, чтобы делать что-то полезное.

• playPingPong: Это другая сторона медали; клиент запускает новыйStreamдля внешнего узла для запуска протокола PingPong.

Как видите, реализация своих протоколов довольно-таки проста и полностью абстрагирована от других, инфраструктурных задач. Единственное, о чем нам нужно позаботиться, так это о написании полезного для нашего проекта прикладного кода. Заметьте также, что добавление нового протокола, например, вsaymyaddr.go, очень похоже на pingpong.go.

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

Чтобы протестировать нашу демо-программу, можно открыть два терминала и просто запустить: go run * .go , go run * .go -quic или их комбинации. Ниже вы можете видеть иллюстрацию с двумя терминалами, работающими с флагом -quic:

Обратите внимание, как, сразу после запуска, узел в нижнем терминале обнаруживает узел в верхнем, ибо mDNS немедленно находит существующие узлы. Затем "нижний" сразу переходит к игре в пинг-понг. "Верхний" узел тоже, но с определённой задержкой (из-за 5-секундного интервала, который мы установили для нашей службы mDNS) обнаружит "нижний" собственными средствами, что, в свою очередь, вызоветновуюигру в пинг-понг.

Заметим также, что когда каждая из сторон отправляет сообщение PingPong или отвечает на него, она выдает полную информацию о мульти-адресе (multiaddr), на который обращается, где можно увидеть, что используется протокол QUIC. Попробуйте запустить этот примербезфлага -quic для обоих партнеров и посмотрите, как это повлияет на результат!

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

Что дальше?

Важным качеством приложения является его пригодность для дальнейшего развития. В p2p-проектах в основе прикладной логики находится сетевое взаимодействие. Если однажды в будущем мы захотим модернизировать наш протокол PingPong добавлением новых функций или возможностей, мы должны учитывать, что некоторые узлы будут по-прежнему работать со старой версией протокола! Это звучит как ночной кошмар, однако отставить бояться, мы с этим справились. И тут надо приметить следующий фрагмент кода из pingpong.go:

КОД:ВДЕЛИТЬ ВСЁ

const (    protoPingPong = "/pingpong/1.0.0")...func RegisterPingPong(h host.Host) {    pp := &pingPong{host: h}    // Здесь мы регистрируем наш _pingpong_ протокол.    // В будущем, если решите достраивать/исправлять ваш протокол,    // вы можете либо делать текущую версию обратно совместимой,    // либо зарегистрировать новый обработчик,     // с указанием новой главной версии протокола.    // Если хотите, можете также использовать логику semver,    // см. здесь: http://bit.ly/2YaJsJr    h.SetStreamHandler(protoPingPong, pp.Handler)}

Комментарии прекрасно всё объясняют.

Другой важный вопрос связан с механизмом обнаружения других узлов, в нашем случае это mDNS. Этот протокол делает свою работу в локальных сетях, но как насчет обнаружения пиров в Интернете? Позднее вы можете добавить в своё приложениеKademlia DHTили использовать один из механизмовpubsub- также, чтобы находить новые узлы.

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

Заключительные слова

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

Важно: имейте также в виду, если вы используете libp2p с включенными Go-модулями, вам нужно явно указывать тег версии в go get, поскольку иначе вы можете получить не то, что ожидали по умолчанию. Больше информации об этом вы можете найти в секцииUsagereadme-файла go-libp2p.

Надеемся, что вам понравился наш игрушечный проект, и надеемся, что он вселит в вас уверенность в том, что писать p2p-приложения не так сложно, как могло бы показаться! На самом-то деле, это может быть довольно кайфово и вдохновляюще! Если вам по нраву сей материал, присоединяйтесь к нам нанашем канале в Slack, чтобы пообщаться на тему p2p-протоколов, или подписывайтесь на нас вTwitter, чтобы узнавать о самых свежих и славных разработкахTextile. Ну, или хотя бы гляньте некоторыедругие наши статьи и демонстрации, чтобы полнее прочувствовать, что возможно в этом захватывающем мире приложений P2P!

Автор оригинального текста:Ignacio Hagopian

Перевод: Алексей Силин (StarVer)

В прошлой статье я рассказал, какие выкрутасы можно сделать одним только браузером. Нам потребуются эти знания далее

Жаркий август 2020 показал, что базовые меры это слишком мало и неэффективно. Нужно что-то большее

Выбирая решение, я ставил перед собой несколько целей:

1. Решение должно быть открытым

2. Решение должно быть бесплатным только так оно может стать массовым

3. Решение должно быть децентрализованным не должно быть единой точки отказа

4. Бомж-VPN. Хотелось иметь возможность соединиться с любым узлом сети забесплатно

5. Бомж-хостинг. Следствие предыдущего пункта. Возможность выкатить тестовый ресурс забесплатно

VPN отвалился сразу: даже рабочий VPN умер. VPN требует централизованного внешнего сервера единая точка отказа. Наконец, VPN платный не назвал бы лично себя нищебродом, но это точно не массовый вариант

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

Я начал осваивать I2P. Идея мне показалась симпатичной. Особенно интересно, что сеть не просто выдержит резкий рост числа пользователей она от этого станет работать лишь надёжнее (но это не точно). На луркеочень вдохновляющее описание возможностей, а wikiспускает с небес на Землю и даёт понять, что I2P не серебряная пуля, и атаки по деанонимизации реальность. Сложно и дорого, но реально. Для сравнения, без I2P это как по паспорту представиться и приготовиться к обыску

Возможности, ограничения и болячки

Точно так же, как и в сети TOR, в сети I2P есть выходные ноды. Это значит, что через сеть I2P можно пролезть в обычный интернет. Однако следует понимать, что скорость работы оставляет желать лучшего потоковое видео через I2P смотреть так себе идея

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

Следствия туннелей бомж-VPN и бомж-хостинг. Я счастлив я могу выкатить ресурс бесплатно. Я могу соединить 2 машины бесплатно. Любой другой участник сети может сделать всё то же самое бесплатно. Вкусно

Функционировать сеть сможет, даже если шаловливые ручки вновь потянутся к Большому Рубильнику белорусские реалии именно такие, онсуществует

Больным местом является изменение маршрутов (следовательно, dest hash). Но я надеюсь, что проблема решаема существует версия для Android, которая подразумевает переход между сетью оператора и разными точками доступа wifi, а в настройках роутера появился экспериментальный Laptop Mode

Ошибки и заблуждения

Я заметил несколько шаблонов заблуждений

Ой, мне по телевизору сказали, что в этом вашем i2p такое показывают! Это вообще законно?

Больше верьте слухам. Ничего там нет такого, чего нет в обычном интернете. I2P ставит своей целью среду передачи данных. Протоколы TCP и UDP, передают более чем 99% информации в интернете, включая незаконный контент. Давайте бороться с контентом, а не транспортом его доставки

Как интернет отключат обязательно установлю

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

Хорошо, я установил, запустил, что-то потыкал и выключил. Как только интернет выключат ух держите меня семеро! Включу I2P и всё у меня станет расчудесно!

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

Я на минуточку. Туда и назад

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

Ну и совсем кошерная остановка службы I2P это в консоли роутера нажать кнопочку Shutdown / Выключить. Демон I2P остановися сам в худшем случае через 10 минут как только истекут уже установленные соединения с другими участниками сети i2p

Установка на desktop

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

Установка шлюза

Наоффициальном сайте проекта есть список загрузок можно взять оттуда

В этом же списке присутствует секция Пакеты для Debian/Ubuntu

После установки пытаемся открытьhttp://localhost:7657/ web-консоль роутера. Настоятельно рекомендую добавить страницу в закладки или даже закрепить (Pin Tab). Если страница открылась вы всё сделали правильно

Настройка браузера. Лайт

В данном случае мы исходим из предположения, что вы не делаете ничего плохого, и просто желаете получить доступ к информации, которая огорчила ваше правительство. А правительство, словно плаксивая девочка, склонно обижаться на любую информацию. Например, в России заблокирован linkedin. Жутко опасный и экстремистский ресурс, ага

В данном случае нас не пугают утечки информации. Например, сайт в сети i2p может запрашивать какой-нибудь jquery с CDN. Что такого в js-библиотеке, которую запрашивают миллионы, если не миллиарды раз в день?

Для настройки нам потребуется дополнениеSmartProxy. Настройка производится в 2 простых шага необходимо добавить входной шлюз I2P в список proxy-серверов и создать правило проксирования

Настройка браузера. Для любителей пожёстче

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

У меня нет лишнего браузера в системе, чтобы полностью выделить его под I2P. Воспользуюсь уже установленным firefox. Следующий вариант работает в Linux:

FIREFOX_PROFILE="firefox-i2p"FIREFOX_HOME="${HOME}/${FIREFOX_PROFILE}"mkdir -p "$FIREFOX_HOME"env HOME="$FIREFOX_HOME" firefox

То есть идея проста: заставить firefox работать с полностью чистым профилем, который никак не повлияет на основной, и который мы сможем снести при первых же намёках на проблемы, как дедушке яичко. Какие бы мы туда дополнения ни ставили, какие бы настройки там не делали основным профилем можно будет продолжать пользоваться

У меня нет ни одной машины с Windows и MacOS. В комментариях, пожалуйста, расскажите, как сделать похожий финт ушами в Windows. А в MacOS этот фокус должен сработать, но я не тестировал

Установка на Android

Суть ровно та же, но инструменты немного другие

Установка шлюза

На всё той жестранице загрузок есть секция Android

Настройка браузера. Лайт

Рецепты по настройке

Я расскажу про несколько опциональных шагов

DNS-over-HTTPS

Для тех, что не читалпредыдущую статью: необходимо добавитьi2p иonion в исключения. Иначе браузер будет пытаться резолвить эти домены на Cloudflare с предсказуемым результатом

I2P + uBlock Origin

Мы умеем учиться на ошибках, поэтому добавим в исключения зоны i2p и onion, таким образом полностью отключив блокировщик рекламы для всех ресурсов i2p и onion

Стало лучше, чем было, но не идеально теряется контроль над загрузкой стороннего контента (3rd party). Хотелось бы только отключить резолв имён i2p и onion

Дополнительные подписки

В список подписок есть смысл добавить адреса:

1. http://identiguy.i2p/hosts.txt

2. http://inr.i2p/export/alive-hosts.txt

3. http://stats.i2p/cgi-bin/newhosts.txt

Покорми java памятью

Входной шлюз I2P написан на языке java. По умолчанию он стартует с ограничением в 128M. Этого хватит для знакомства и неспешного погружения в дивный новый мир невидимого интернета. Больше всего памяти потребляет компонент NetDB база данных о других хостах сети I2P. Чем их больше известно, тем выше надёжность и тем выше вероятность, что в час Ч, когда интернет снова сдохнет, Вам таки удастся найти лазейку доступный хост из списка известных. Правда, гарантий никаких

В случае Ubuntu/Debian:

sudo dpkg-reconfigure i2p

Как это сделать для Windows я не знаю и очень надеюсь на комментарии

Когда нельзя открыть порт меньше 1024, но очень хочется, то можно

Очень спорный рецепт. В общем случае, так делать не надо. Но если очень хочется, то можно. Я проделал это для прощупывания возможностей I2P. То есть just for fun

Приключения начались с вопроса так где же java?

which java | xargs file --mime-type/usr/bin/java: inode/symlink

Окей

which java | xargs readlink | xargs file --mime-type/etc/alternatives/java: inode/symlink

Больше симлинков богу симлинков!

which java | xargs readlink | xargs readlink | xargs file --mime-type/usr/lib/jvm/java-11-openjdk-amd64/bin/java: application/x-pie-executable

Следует понимать, что конфигурация у меня может не совпадать с конфигурацией у Вас. Идея проста добавлять в середину секцию xargs readlink до наступления просветления пока file не скажет application/x-pie-executable. Как только java нашлась из получившейся команды удаляем 2 последних слова file --mime-type, например, нажав ^W дважды, и вместо этого добавляем setcap 'cap_net_bind_service=+ep':

which java | xargs readlink | xargs readlink | xargs setcap 'cap_net_bind_service=+ep'

Возможно, потребуется добавить также возможность открытия сырого сокета setcap 'cap_net_raw=+ep':

which java | xargs readlink | xargs readlink | xargs setcap 'cap_net_raw=+ep'

Но в следующий раз я просто разверну docker с nginx

А что ещё там есть?

Очень рекомендую почитатьрусскоязычную wiki и полистать спискиidentiguy

А ещё естьтелеграмовские MTProto прокси. Идея сводится к созданию туннелей на указанные i2p-хосты. Инструкция на сайте

Ещё есть торренты и почта. Ничего из этого я ещё не пробовал использовать

Находилфлибусту иebooks.i2p последний выглядит вообще дорого-богато

Вместо заключения

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

Я ни слова не сказал проi2pd. Проект достоин внимания: он производительнее и при меньшем потреблении ресурсов. Пока что у меня нет экспертизы

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

Карта - это не сам динамично меняющийся ландшафт местности, поэтому каждая дорожная карта со временем устареет. Так было с BAT Roadmap 1.0, опубликованным 18 июня 2017 года, вскоре после запуска нашего Basic Attention Token. Предлагаемый вашему вниманию BAT Roadmap версии 2.0 рассчитан на следующий год и до 18 месяцев вперёд.

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

Браузер Brave

Браузер Brave является первым клиентом и испытательной площадкой для экосистемы BAT, причем модуль BAT был впервые запущен в Brave в октябре 2017 года. Аудитория Brave выросла до более 25 миллионов активных пользователей в месяц (MAU) и более 8 миллионов активных пользователей в день (DAU). Мы ожидаем, что к концу года Brave вырастет до 50 миллионов MAU и 17 миллионов DAU. В России живёт около 2% от этой аудитории или примерно 0,5 млн. MAU - прим. Brave/BAT Russia.

Токен BAT

Как подчеркивается в нашем январском пресс-релизе, BAT уже очень полезен. Более 3,8 млн пользователей, совершающих транзакции в месяц, использовали токены BAT на платформе, и на сегодняшний день создано более 13 млн кошельков для получения вознаграждений Brave / BAT.

BAT - один из наиболее широко используемых токенов: более 1 миллиона проверенных площадок и паблишеров принимают BAT от пользователей Brave Rewards. Внедрение Brave Ads в апреле 2019 года было выполнено в соответствии с обещанием вознаграждений BAT за просмотр рекламы и выросло до более 2,5 тысяч рекламных кампаний от более чем 400 рекламодателей из +190 стран.

Токен BAT вышел за рамки Brave Rewards, и BAT стал одним из первых активов, поддерживаемых в качестве обеспечения MakerDAO, Compound и другими ведущими протоколами DeFi (децентрализованные финансы - прим. Brave/BAT Russia).

Общий подход

Используя нашу базу пользователей и успех, достигнутый с внедрением BAT, мы намерены сделать криптовалюту и децентрализованные финансовые сервисы (DeFi) доступными и удобными для всех с помощью следующих усилий.

Кошелек Brave

Основой для массового внедрения и использования криптовалюты и DeFi станет кошелек Brave Wallet, который объединит Brave Rewards, кастодиальные и лучшие в своём классе не кастодиальные аккаунты Brave (то есть пользователь сам владеет своим закрытым ключом, в идеале хранящимся в аппаратном устройстве).

Особенности Brave Wallet включают:

• Новая реализация кошелька Ethereum, заменяющая существующие криптокошельки в Brave.

• Редизайн текущего пользовательского интерфейса с UX, призванный обеспечить бесшовный переход между учетными записями.

• Поддержка десктопных и мобильных устройств.

• API поставщика JavaScript Ethereum (window.ethereum), предоставляемый веб-страницам по умолчанию, без необходимости установки отдельного расширения.

• Индивидуальные возможности для сценариев использования DeFi и NFT.

• Варианты покупки криптовалюты с помощью фиатных способов оплаты, таких как кредитные / дебетовые карты, банковские счета и кошельки для смартфонов.

Запланированные фичи Brave Wallet также включают:

• Использование BAT, заработанных через Brave Rewards, для оплаты комиссий за транзакции.

• Встроенная возможность покупки невзаимозаменяемых токенов (NFT) в Brave.

Агрегатор DEX в Brave: DeFi для всех

Brave представит DeFi всем через новую децентрализованную криптобиржу, чтобы обеспечить обмен токенов с явными преимуществами и высокой добавленной стоимостью для пользователей Brave / BAT, в том числе:

• Скидки при использовании BAT для оплаты комиссий за транзакции.

• Скидки для пользователей, которые держат баланс BAT в своем кошельке.

• Поддержка нескольких цепочек с множеством активов и блокчейнов.

Некоторые из вещей, которые мы планируем исследовать для Brave DeFi, включают:

• Децентрализованная биржа (DEX), где Brave будет стимулировать поставщиков ликвидности к развитию BAT и более широких крипто-экосистем.

• Решения L2 или другие оптимизации, чтобы обеспечить доступ и участие в DeFi для людей, чей доход от BAT составляет всего 1 доллар.

Themis: Масштабирование рекламы Brave / BAT

Themis - это наша исследовательская работа по постепенному перемещению анонимных, но подотчетных операций в цепочку для Brave / BAT Ads, чтобы уменьшить зависимость от протокола отчетов о подтверждении рекламы Brave и перейти к анонимной проверке событий подтверждения просмотра рекламы. В рамках ведущих проектов блокчейнов мы исследуем как решения L2, так и блокчейны L1 в сочетании с Ethereum. Обзор и общий таймлайн по Themis можно найти здесь. Некоторые технические отчеты о Themis, которые мы опубликовали, можно найти здесь и здесь.

Децентрализованный Интернет

BAT - ключевой компонент миссии Brave по созданию децентрализованной сети.

С этой целью мы исследуем следующие возможности:

• Утилита BAT для поисковых систем.

• Использование BAT для электронной коммерции.

• Использование BAT для VPN и различных частных коммуникационных платформ.

• Награды BAT за контент, проверенный на IPNS.

• Возможность использовать BAT для закрепления контента на IPFS (файлообменник).

Работа с сообществом

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

Мы намерены сделать следующее:

• Регулярные обновления о статусе различных инициатив.

• AMA с членами команды.

• Программа BAT Ambassadors.

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

Вместе с этой системой существуют команды для взаимодействия с ней. Их не так уж много, но для создания децентрализованной БД нужно всего два: put и get. Об этом и пойдёт речь далее...

По логике все могут понять. Put - это положить. А Get - это получить. Так вот достоверно положить с помощью команды Put можно до 1000 байт любой информации. И достоверно эта информация будет хранится в DHT около часа. Get - это получить, то что положили. Всё просто.

Команда Put имеет два вида. Первый - это положить без возможности изменения. Второй - положить с возможностью изменения. Т.е. можно мало того, что положить в DHT 1000 байт, так ещё и менять их, как хочется.

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

На этом и можно построить децентрализованную БД

Вариантов много. Это дело вашей фантазии, но можно использовать, например такой.

У всех пользователей = пиров есть публичный и приватный ключ.

Пользователь 1 хочет изменить БД. Он получает содержимое DHT с помощью Get и публичного ключа. В полученных данных, может быть всё что угодно. У нас это будет sha1 ссылка торрента по которой можно скачать торрент. Её размер около 20 байт. По этой ссылке он скачивает торрент в котором находится БД. Изменяет БД. Генерирует торрент (получая sha1 ключ) и раздаёт его. Публикует Putом полученный sha1 ключ по которому уже можно скачать новую, изменённую БД.

Пользователь 2 хочет изменить БД....аналогично...

Для того что бы данные в DHT не пропали нужна регулярная синхронизация пиров. Синхронизация это Get с публичным ключом через udp. Очень малозатратно. И если данные изменились, то скачивание их. Это уже немного более затратно, но тут тоже можно ставить ограничение по скорости скачивания, например.

Если данные в DHT пропали, то пир, который хочет синхронизироваться просто делает Put с последними данными, какие у него есть, либо с чистыми данными.

А теперь немного о том, почему это БД, а не обмен файлами

В 1000 байт можно зашить всё что угодно. А в передаваемую БД бесконечное количество информации. Так как пользователь не знает публичного и приватного ключа, то он не может сам публиковать что-то. Это может только программа. А программа в зависимости от данных в этих 1000 байт может делать всё что угодно. Может получить блокировку пользователя и перевести его только в режим чтения. Получается это БД с правами доступа на изменение определённой информации. Особенно, это будет похожим на БД, если скачиваемые данные шифровать и хранить в одном файле без расширения.

Конечно здесь могут возникнуть определённые проблемы, но все они решаются.

Теперь о недостатках и проблемах

Например, если пользователь 1 опубликовал новый хеш, изменённой БД, но не стал раздавать его. В DHT можно хранить 5 записей sha1 это 100+байт всего и если какой либо из пользователей не смог скачать изменённую версию, то он качает следующую из 5ти и затем перепубликовывает на ту, которая скачивается. Соответственно другие пользователи уже не будут пытаться скачать, то что не качается и получат БД быстрее. Чем больше пользователей, тем лучше и быстрее будет работать БД.

Главная проблема подобной системы это время ожидания. Публикация (Put) занимает от 20 до 60 секунд + время что бы кто-то скачал эти данные. Если пользователь не выключает программу, то это только 20-60 секунд. Зато получение данных так как это торренты - выполняется на максимальной скорости устройства с использованием множества торрент технологий и протоколов. Скачивание только изменённых данных? Думаю можно, но не спрашивайте как.

Вторая не менее важная проблема это то что каждый пользователь имеет программу в которой хранятся публичный ключ и приватный. И если взломать программу, то можно получить эти ключи и с помощью них публиковать свои ложные данные. Тут можно сочинить не мало способов борьбы с этим. Возможно в комментариях подскажут ещё какие-то. Но например: можно хранить ключ в шифрованном виде и расшифровывать его только при использовании. Можно шифровать БД отдельным ключом так что злоумышленнику понадобится вычислить ещё и этот ключ. Можно хранить ключи тоже в DHT и менять их периодически или на сайте. Способов столько на сколько фантазия богата. Поэтому нельзя точно сказать, что это уязвимость.

Технически это возможно сделать на основе любой торрент библиотеки. Например Libtorrent. Она весит после компиляции всего 2,5Мб, написана на с++ и работает максимально быстро. Там есть техническая информация про Put.

Подобная система используется в моём приложении "Торрент плеер", для публикации плейлистов. У меня уже есть даже админка для модерации. Всё успешно работает. Пользуйтесь.

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

Зачем это нужно и кому?

Прошло довольно много времени со дня первой публикации о MANET, мир шагнул в новую реальность, появились и приобрели массовый характер стриминговые видео сервисы, всевозможные сенсоры, дроны, автономные платформы генерирующие большие объемы данных и т.д. Я уже молчу о смартфонах и планшетах - всему этому чуду для нормальной работы нужны широкополосные каналы с низкой задержкой. Понятно, что если есть нормальное покрытие LTE или WiFi, то большинство базовых потребностей связи будет сразу закрыто. Но что если покрытия нет?

Теперь рассмотрим ситуацию когда у вас нет инфраструктуры, а нужно гонять большие объемы данных "на лету". В первую очередь, это требуется военным, т.к. современный солдат обвешан колоссальным количеством сенсоров и включен в единую автоматизированную систему управления боем BMS. Здесь он должен быть всегда онлайн, всегда виден своему командованию и иметь возможность взаимодействовать с другими такими же как он, а в перспективе даже с роботизированными платформами на земле, воде, в воздухе (в космосе - ?), а это и передача видео, файлов, телеметрии, карт и всего другого, вне зависимости от доступной инфраструктуры. Такой себе закрытый Интернет. Вот этот сегмент как раз и закрывают такие радиостанции.

Другим потенциальным "клиентом" таких систем являются спасатели. По информации из СМИ, американские компании TrellisWare Technologies и Persisten Systems активно продвигают свои MANET радиостанций в Федеральное агентство по чрезвычайным ситуациям FEMA для решения задач эффективного управления командами спасателей, поиска людей на больших площадях и т.д. Вполне логичное решение, с учетом того, сколько ущерба инфраструктуре США приносят природные катаклизмы, а время самый дорогой ресурс для спасателя.

Архитектура

Внутренняя архитектура таких девайсов ничем не уступает самым современным смартфонам, а в некоторых аспектах, таких как например диапазон рабочих частот или требования по надежности, значительно превосходит их. Единственное в чем они уступают смартфонам - это внешний вид, в стиле "защищенный кирпич", что обусловлено требованиями стандартов MIL-STD и IEC, предъявляемых к таким устройствам. Но это ерунда - главное, чтобы работало!

Следующим важным фактором является богатая периферия. И это неудивительно, ведь это не рации "walkie-talkie" с одной кнопкой для голоса. Все данные передаются как IP пакеты, для того чтобы максимально быстро и просто подключить клиентское оборудование, в том числе кнопки РТТ для голосовых сеансов. Следовательно, нужно иметь максимум из распространенных интерфейсов и работать как маршрутизатор. Чем по сути эти девайсы и являются.

Любопытно отметить, что практически все производители подобных систем, отказались от экранов. Поскольку подключаемое клиентское оборудование - смартфоны, планшеты, компьютеры - уже имеют экраны, то зачем дублировать функционал. К тому же, вставить нормальный экран в столь компактное решение, а тем более защитить его от механических воздействий и климата (-40...+55 С) по MIL-STD, очень сложно и дорого.

Наконец, батарея. Здесь все упирается в понятие SWaP, т.е. размер, вес и потребление устройства. Как вы понимаете, эти радиостанции практически постоянно в эфире, причем не столько как генераторы трафика от своих периферийных устройств (планшетов, смартфонов и т.д.), но в основном как ретрансляторы трафика других абонентов. И это должно длится сутками! Поэтому требования к батареям предъявляются чрезвычайно высокие. Это не только ёмкость, но и работа при глубоком минусе, до -40 градусов по Цельсию. В итоге, дешевыми такие батарейки точно не назовешь.

Радиочасть

Здесь можно выразиться одной фразой - "чем шире, тем лучше". С повсеместным распространением интегральных SDR трансиверов с цифровой обработкой сигналов в этом сегменте произошла самая настоящая революция. Большие скорости передачи требуют больше полосы, а традиционные радиочастотные цепи, не могут обеспечить более широких полос частот и схем цифровой модуляции без значительного потребления энергии и увеличения в размере и весе. Таким образом, революцией в дизайне MANET радиостанций с малым форм-фактором стали встроенные SDR приемопередатчики, уменьшающие размер и потребление несколькими способами.

Во-первых, радиочастотные и аналоговые устройства могут быть переведены в цифровую область - например, радиочастотные фильтры могут стать цифровыми фильтрами. Цифровые реализации этих блоков более эффективны и лучше программируемы, чем их РЧ аналоги. Во-вторых, цепи на дискретных элементах часто представляют собой гетеродинные архитектуры, которые требуют нескольких уровней преобразования частоты, фильтрации, усиления и цифровой обработки. Интегрированные трансиверы могут использовать архитектуру с нулевой промежуточной частотой (ZIF), которая резко сокращает количество требуемых компонентов в сигнальной цепи, в частности, требуемых этапов фильтрации и усиления. Удаление этих ступеней уменьшает как размер, так и потребляемую мощность [1].

К слову, широкополосные SDR трансиверы требуют соответствующих усилителей. На помощь пришел нитрид галлия (GaN). Транзисторы на этом соединении способны обеспечить необходимую широкополосность и мощность. Такие компании, как Qorvo, Ampleon, Cree в полной мере отвечают всем самым современным требованиям производителей усилителей для SDR, в то время когда основные игроки этого рынка стараются уходить на вверх на гигагерцы. Хотя в последнее время много внимания уделяется когнитивному радио и переиспользованию спектра внизу, на УКВ, перекрывая весь диапазон частот в одном устройстве.

Софт

Поскольку классическая радиотехника закончилась (см. выше), теперь все упирается в софт, а точнее в "форму волны" - waveform. Вот тут и развернулась основная борьба между производителями таких девайсов.

Большинство из них используют технологию MIMO и активно наращивают количество апертур, что в связке с цифровым диаграммообразованием открывает невероятные возможности. Помните 5G? Как там собираются достигать гигабитных скоростей и большой емкости сети? Точно таким же образом - цифровой диаграммой и обработкой сигналов, когда на каждого абонента формируется отдельный луч и с адаптивной модуляцией. Примерно такая же логика и тут.

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

Другим любопытным трендом является управление сетями MANET через SDN. Как и в случае в 5G и MIMO, основным преимуществом SDN для таких радиостанций становится гибкий механизм управления параметрами сети. Причем не только физическим уровнем (адаптивная модуляция, когнитивное радио), но и канальным, и сетевым. Это особенно актуально в случае больших сетей с множеством абонентов, где параметры каналов, требования по задержке, BER, PER, полосе могут меняться динамически от абонента к абоненту. А добавьте сюда аспект безопасности, распределение доступа, управление спектром и т.д. Как этим всем управлять? В данном случае SDN подходит как нельзя лучше. Однако, и тут есть масса чисто научных проблем и организации типа DARPA туда копают очень активно.

Итого, все вышеозначенное реализуется в софте на ПЛИС/DSP и взаимодействует с SDR трансиверами и ОС (например, Linux). Таким образом, у каждого вендора есть свой уникальный waveform - комбинация модуляции, кодирования, фильтрации, управления диаграммой - реализованная как специализированная прошивка для радиостанции.

Перспективы

В заключении, хочется показать несколько самых популярных MANET радиостанций и рассмотреть перспективы этого направления. Сформировалась конкретная потребность, появились необходимые комплектующие, объемы передачи данных растут с каждым годом, поэтому абсолютно очевидно, что у подобных систем большое будущее. Другое дело, что это очень узкоспециализированное оборудование и стоит оно довольно дорого. К тому же, поскольку перекрывается практически весь радиочастотный спектр, то возникают юридические вопросы в плане использования частот гражданскими пользователями. Отсюда проблема с выходом на новые рынки.

e

Резюме: персональный, децентрализованный Интернет все больше набирает популярности). А какие перспективы у MANET радиостанций видите вы?

[1] - https://militaryembedded.com/comms/rf-and-microwave/next-generation-military-communications-challenges

В марте этого года я анонсировал перевод этого обзора. Сегодня публикую результат, получилось 70 страниц.

Традиционная просьба: прошу сообщать о замеченных огрехах, они наверняка есть, так как документ переводился и верстался в одно лицо. Обзор оформлен в виде pdf-документа, линк для скачивания: https://vk.cc/c1BQwV

Всем приятного чтения!

Предисловие

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

Развитие модели ИИ

Вообще нейросеть это модель. Набор файлов, который представляет собой алгоритмы и таблицы, вместе образующие то, что в некотором смысле можно назвать искусственным интеллектом. Развитие происходит по нескольким направлениям разработка более оптимальных алгоритмов и увеличение размеров таблиц. Последние существующие модели имеют такой размер, что не хватит и 1000 лет для обучения этого на одной единственной видеокарте. Тем не менее все модели на сегодняшний день являются централизованными, а именно за их обучение отвечает конкретный человек или организация. Поэтому обучить самые крупные модели сейчас могут позволить себе лишь ТОП игроки вроде амазон, гугл, фейсбук и майкрософт. Обычным людям приходится довольствоваться моделями, которые в среднем в 100-1000 раз меньше, чем топовые модели, доступные этим компаниям.

Концепция децентрализации

В 2008 году появился первый децентрализованный блокчейн. Суть его была в том, что любой пользователь мог получить виртуальные монеты за помощь в поддержании работы виртуальной сети за счёт вычислительных ресурсов своего компьютера. Свойства этой сети так же располагали к передаче этих монет друг другу, что позволило в итоге перерасти этой сети в целую финаносовую систему, основанную на майнинге, децентрализации и шифрованию. Плюсы этого подхода в первую очередь представляют возможность трансграничных нецензурируемых платежей, которые происходят лишь за счёт интернета и вычислительной мощности компьютеров сети. Задумайтесь, всего лишь 2 фактора - интернет и вычислительная мощность компьютера. Все что понадобилось для создания целой новой финансовой системы. И это только первые 10 лет существования интернета.

Децентрализация ИИ

Децентрализация означает отсутствие главного. Главное в децентрализации это консенсус среди наименьших единиц системы. Благодаря этому консенсусу мы можем построить нечто большее, чем новую финансовую систему. Давайте вообразим на минуту, что майнинг может создавать нечто большее, чем просто трата ресурсов на поддержание работы сети в поисках случайного числа. Что, если бы каждый майнер рассчитывал небольшую часть огромной модели искусственного интеллекта на своей рабочей машине, при этом без необходимости обучать всю модель целиком ? Суть этой идеи состоит в том, чтоб эффективно распределить обучение, используя вычислительные ресурсы разных машин от видеокарт до асиков, для получения полностью законченной модели или же даже для постоянного её дообучения на всё новых и новых наборах данных. За обучение модели майнеры бы получали определенные коины, которые в будущем можно было бы истратить на использование вычислительных ресурсов модели-сети. В какой-то момент модель-сеть будет полностью обучена, и, казалось бы, её может бесплатно скачать на компьютер любой желающий, но вот запустить её самому у него никогда не хватило бы ресурсов. Для запуска модели необходим тот же майнинг. Одни люди производят запрос в сеть, сеть выдаёт ответ. Вроде работы с от API gpt-3. Каждый запрос стоил бы пользователю несколько токенов, в зависимости от расценок майнеров. Майнеры эти запросы коллективно децентрализованно обрабатывают и выдают результаты. Моделей может быть огромное множество и все они могли бы существовать в едином блокчейне, в виде смарт-контрактов. А именно, кто-то человек, или группа лиц, создаёт модель-контракт в блокчейне сети, привлекает людей для её обучения, обучают и дальше зарабатывают все вместе на поддержании работы модели.

Последствия

В случае создания подобной системы, самые крупные компании потеряют статус монополии на владение крупнейшими моделями в мире. Очень скоро крупнейшие модели будут существовать именно децентрализованно, и никак иначе. Совместное использование огромного количества вычислительных ресурсов очень скоро будет производить суммарно больше полезной работы, чем отдельные суперкомпьютеры ТОП ИТ компаний. Это и есть следующий шаг в развитии технологий и очередной шаг к полной автономии каждого, а не зависимости от сильнейших.

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

Disclaimer: я не призываю незаконно скачивать контент, пиратство - наказуемо и является преступлением

После ареста серверов Moonwalk жить стало в разы труднее. Лично я уже совсем отвык от торрентов. Нужно что-то качать, ждать, чем-то открывать, куда-то кликать, иногда еще и место на диске кончается. Как можно ждать час пока скачается фильм? За час можно жизнь прожить. Пришлось искать решение, которое позволит смотреть кино также просто, как и раньше. Норматив: от идеи посмотреть что-нибудь и до начала непосредственного просмотра - не более минуты.

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

И вот так он работает:

В среднем это 22-50 секунд и приблизительно 3 клика мышью от желания посмотреть фильм до начала его непосредственного просмотра, при наличии пиров и хорошего канала, при этом без рекламы и с огромным выбором, который вы можете сами сужать и расширять. Ниже о компонентах.

Знакомьтесь, Jackett

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

Jackett можно скачать и запускать на компьютере, но это все усложняет. Лучше захостить его на бесплатном облаке от Oracle, и заходить по адресу. Вам понадобится машина в облаке, linux на ней и docker-compose.yml c приблизительно такими характеристиками:

version: '3.5'services:    jackett:        image: linuxserver/jackett        container_name: jackett        environment:            - PUID=1000            - PGID=1000            - TZ=Europe/Moscow        volumes:            - ./Jackett/config:/config            - ./Jackett/Downloads:/downloads        ports:            - 9117:9117        networks:            - proxy        restart: unless-stoppednetworks:    network:        driver: bridge    proxy:        external:            name: proxy

docker-compose up -d и заходим. Далее нам понадобится добавить все наши трекеры, вбив логины и пароли.

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

Здесь нам приходят на помощь Stremio и Soda player.

Сами по себе это просто потоковые смотрелки торрент файлов. Хорошо, но недостаточно. В комбиации с Jackett они превращаются во что-то совсем невероятное. Soda отлично подойдет для мака, а Stremio, кажется, умеет передавать видео на телевизоры и прочие кофемолки. Про Soda есть статья на reddit, дескать он ворует печеньки. Лично мне плевать, но вас я обязан предупредить.

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

Вместо используемого вBitcoinмеханизма консенсуса "Proof of Work", криптовалюта Chia использует новую модель "Proof of Space", для которого нужно место на жестких дисках.

Вкратце:

• Chia это криптовалюта с новым механизмом консенсуса "Proof of Space and Time".

• Вместо расхода вычислительной мощности, майнинг осуществляется за счет использования пространства жестких дисков.

Содержание:

1. Введение

2. Что такое Chia?

3. Как работает Chia?

4. Что в этом особенного?

5. Что такое токен XCH?

6. Как майнить Chia на жестком диске?

7. Что дальше будет с Chia?

Нажмите на заголовок в оглавлении, чтобы перейти к нужному пункту.

Введение

Назад к оглавлению

Майнингпрочно занял место в заголовках новостей, хотя и не среди самых положительных из них. Все больше внимания уделяется воздействию майнинга криптовалют на окружающую среду, в частности, потребляющему много энергии методу "Proof of Work" (PoW), используемому при майнинге Bitcoin и (в настоящее время) Ethereum.

Криптовалюта Chia должна изменить это за счет применения нового механизма консенсуса "Proof of Space and Time", в котором для защиты сети вместо расходования вычислительной мощности используется память жестких дисков. Создатели этой криптовалюты утверждают, что она более безопасная, более распределенная, и менее расточительная, чем такие криптовалюты на базе метода Proof of Work, как Bitcoin. Новый подход уже продемонстрировал свою популярность среди майнеров, начавших скупать жесткие диски, нужные для построения "фермы" майнинга.

Ниже описывается, как это работает, и как начать заниматься майнингом Chia.

Что такое Chia?

Назад к оглавлению

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

Разработанная создателем BitTorrent Брэмом Коэном (Bram Cohen) криптовалюта Chia была задумана в августе 2017 и запущена в мае 2021, причем награда за майнинг в сети появилась в марте, а криптовалюта будет использовать транзакции, включенные в мае.

Этот проект поддерживается такими крупными участниками, как фонды Andreessen Horowitz и Galaxy Digital, и имеет амбициозные планы создания "настраиваемого международного коммерческого банка, работающего быстрее, чем Bitcoin".

Криптовалюта Chia отличается от других криптовалют своим уникальным механизмом консенсуса, обеспечивающим безопасность блокчейна, и получившим название "Proof of Space and Time".

Как работает Chia? Что представляет из себя Proof of Space and Time?

Назад к оглавлению

Криптовалюта Chia использует уникальный механизм консенсуса (систему, гарантирующую целостность блокчейна). В то время, как Bitcoin для этой цели использует Proof of Work, требующее значительных затрат вычислительной мощности, а такие блокчейны, как Flow и Cosmos используют механизм, названный "Proof of Stake", Chia использует так называемое "Proof of Space and Time".

Вместо применения мощных компьютеров, соревнующихся в решении математических задач, Chia использует пространство на жестких дисках (HDD) и твердотельных накопителях (SSD) в сочетании с механизмом лотереи. Майнеры Chia записывают на свои жесткие диски 100-гигабайтные "шаблоны", которые затем заполняются хэш-кодами. Когда к блокчейну Chia добавляется новый блок, то вычисляется его хэш-код, который сравнивается с хэш-кодами на дисках майнеров. Пользователь с наиболее близким соответствием выигрывает и получает вознаграждение за проверку блока.

В этом заключается "Proof of Space". Но, так как заполнение жестких дисков данными не требует значительной вычислительной мощности, то теоретически, данный блокчейн является уязвимым к grinding-атакам, когда злоумышленник перебирает различные варианты блока для нахождения лучшего.

Для защиты от этого сеть также требует, чтобы между появлением блоков прошло определенное время (Proof of Time). Это означает, что пользователь не может просто бесконечно переписывать шаблоны, чтобы взломать блокчейн.

Что в этом особенного?

Назад к оглавлению

Основное преимущество модели Proof of Space and Time в Chia заключается в том, что оно оказывает меньшее воздействие на окружающую среду, чем Proof of Work, используемое в таких криптовалютах, как Bitcoin.

Поскольку Bitcoin требует, чтобы майнеры вкладывали средства в увеличение вычислительной мощности (и, следовательно, в расход электроэнергии), то это спровоцировало среди майнеров "гонку вооружений". Общее потребление электроэнергии сетью Bitcoin сегодня превышает все потребление электричества в ряде стран. Затопление в апреле 2021 года угольной шахты в Китае и последствия этого события, повлиявшие на майнинг Bitcoin, также продемонстрировали непрерывную зависимость криптовалюты от ископаемого топлива.

Сконцентрировав защиту своей сети на емкости дисковой памяти, а не на вычислительной мощности, Chia потребляет на порядок меньше энергии. Однако, как указывают некоторые критики, это не означает полного отсутствия воздействия на окружающую среду. Поскольку Chia требует для майнинга только жесткие диски, с этой криптовалютой связано воздействие на окружающую среду во время производства этих дисков. Выполнение доказательства пространства и времени в узле сети также требует потребления определенного объема электроэнергии, которое, хотя и значительно меньше, чем нужно для доказательства работы, тем не менее, все еще превышает нулевой уровень то количество электроэнергии, которое бы потреблялось, если бы Chia не существовала.

Также публиковались утверждения о том, что майнинг Chia повреждает диски, особенно имеющие небольшие объемы накопители SSD, используемые майнерами для размещения и заполнения шаблонов. Основатель Chia Брэм Коэн оспаривает предположение о том, что Chia "выжигает" диски, когда майнеры используют HDD или SSD промышленного класса. Но немецкий поставщик облачных услуг, компания Hetzner, запретила майнинг этой криптовалюты на своих серверах, выразив обеспокоенность по поводу того, что майнинг Chia может привести к преждевременному выходу из строя ее дисков.

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

Что такое токен XCH?

Назад к оглавлению

XCH это собственный токен ("монета") сети Chia. Он используется для транзакций и для предоставления вознаграждения в качестве стимула для пользователей.

Как майнить Chia на жестком диске?

Назад к оглавлению

Майнинг Chia заметно отличается от традиционного майнинга криптовалюты. Чтобы начать, вам необходимо обеспечить наличие достаточного пространства на диске.

Обычно майнеры Chia записывают свои шаблоны на обладающие большой емкостью, быстрые твердотельные диски SSD потребительского класса. Такие SSD быстро изнашиваются, а винчестеры HDD, хотя и предлагают больше пространства для хранения информации, работают намного медленнее. Поэтому майнеры переносят заполненные шаблоны на большие HDD. Шаблоны Chia немного превышают 100 ГБ, но при этом требуется 350 гигабайтов для временного использования. Поэтому вам необходимо тщательно оценить свои первоначальные затраты, включая емкость SSD, емкость HDD и стоимость других компонентов, которые потребуются вам, если вы строите свою "ферму" с нуля. А затем нужно сопоставить эти затраты с вероятностью выигрыша в "лотерее", распределяющей награды Chia.

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

После того, как вы соберете вместе все необходимое, вам нужно обратиться квеб-сайту Chia, чтобы установить Chia на свой компьютер. Нажав на кнопку "Install Chia blockchain" ("установить блокчейн Chia"), вы попадете настраницу Githubпроекта, где сможете указать нужную ОС (включая Windows, MacOS и Ubuntu) и загрузить соответствующую программу установки.

Загрузив и запустив программу установки, вы увидите экран, на котором сможете создать новый закрытый ключ или импортировать существующий ключ. Для этого нужно щелкнуть по кнопке "create a new private key" ("создать новый закрытый ключ"). В результате будет сгенерирована мнемоническая фраза из 24 слов, которую следует записать и сохранить в надежном месте (ее не рекомендуется фотографировать или хранить на облачном диске, поскольку облако можно взломать и это позволит кому-то получить доступ к вашим средствам).

После возвращения к основному экрану нужно щелкнуть по кнопкам "Plots"("Шаблоны") и "Add a plot" ("Добавить шаблон"). Именно здесь вы выделяете дисковое пространство для размещения ваших шаблонов Chia.

Находясь в этом экране, вы можете выбрать размер своего шаблона (обычно, он должен несколько превышать 100 гигабайтов), количество шаблонов на вашем диске, и настроить очередь шаблонов для последовательной их обработки. Вам также необходимо задать временный и результирующий каталоги. Временный каталог это место, где сначала создаются шаблоны (обычно его помещают на быстром SSD-диске). Результирующий каталог это место, где шаблоны хранятся при выполнении майнинга, чтобы сравнивать их с предлагаемым блоком (обычно для этого выбираются жесткие диски HDD).

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

Что дальше будет с Chia?

Назад к оглавлению

Запуск Chia был достаточно замечательным. Еще до того, как эта система стала доступной, она, по некоторым сообщениям, вызвала нехватку жестких дисков во всей Юго-восточной Азии. В то время размер сети Chia составлял около 600 петабайтов. К маю 2021 года он уже достиг 10 экзабайтов. Подобно майнерам Ethereum, раскупившим графические процессоры, майнеры Chia поспешили приобрести жесткие диски. Президент Chia Network, Джин Хоффман (Gene Hoffman) даже признал: "Мы, в какой-то мере, нарушили цепочку поставок дисков".

Не высказывает жалоб только одна группа производители жестких дисков, которые увидели неожиданный рост своих акций из-за внезапного роста спроса на их продукцию.

Сама сеть Chia Network более чем удвоила свою капитализацию до 500 миллионов долларов, после привлечения 61 миллиона долларов от инвесторов, среди которых такие компании, как Andreessen Horowitz, Richmond Global Ventures и Breyer Capital. Сам Хоффман назвал финансирование "ракетным топливом" найма и раскрыл планы по IPO и открытое обращение своих акций через планируемое в этом году слияние с компаниями SPAC.

Тем временем, компания планирует развитие своей миссии по достижению институционального принятия своей торговой и платежной системы. "Chia это то, как могла бы выглядеть система Bitcoin, если бы та разрабатывалась с учетом знаний, накопленных за последние 13 лет", заявил в интервью Bloomberg управляющий партнер Richmond Global Ventures Дэвид Фрейзи (David Frazee). Амбиции высоки, но учитывая критику Bitcoin за его воздействие на окружающую среду, вполне возможно появление криптовалюты, которая будет экологически более чистой.

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

О том, как минимизировать юридические риски при разработке смарт-контрактов, расскажу в этом материале.

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

Как работают смарт-контракты

Обязательства участников предоставляются в интеллектуальном контракте в форме если-то (например: если Сторона А переводит средства, тогда Сторона Б автоматически передает права на какой-то объект имущества). На первый взгляд, все примерно так же, как в обычном договоре купли-продажи. Однако смарт-контракты отличаются полной автономией. Например, некое лицо является обладателем цифрового права на бокс с алмазами, имеющий индивидуальный номер. При покупке в информационной системе сделка с таким объектом будет исполнена автоматически, без дополнительных волеизъявлений сторон у продавца будет списано цифровое право, а у покупателя деньги, и оспорить это по общему правилу будет нельзя.

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

Плюсы смарт-контрактов

В первую очередь, это удобство. Обработка документов вручную занимает много времени и растягивает сроки сделки. Смарт-контракты предполагают автоматизированный процесс и в большинстве случаев не требуют личного присутствия сторон, что экономит драгоценное время.

Данные, записанные в компьютерном коде конкретного смарт-контракта, не могут быть изменены в одностороннем порядке. Если одна сторона сделки не выполняет свои обязательства, другая будет защищена условиями интеллектуального договора. Смарт-контракты практически полностью исключают необходимость вмешательства третьих лиц. Гарантия на транзакцию сама программа, которая, в отличие от посредников, не даст основания сомневаться в ее честности.

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

Минусы смарт-контрактов

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

В первую очередь, это невозможность изменения интеллектуального договора. Если стороны достигают более выгодного соглашения или возникают новые, непредвиденные факторы, они фактически не могут внести правки в условия смарт-контракта. В целом смарт-контракты, как отмечают в аналитическом обзоре Банка России, не обладают функциональной гибкостью. При заключении традиционных соглашений у участников есть возможность договориться или скорректировать условия сделки уже в ходе совместной работы. Однако в случае с интеллектуальными договорами все иначе. К примеру, если одна из сторон нарушила зафиксированные условия, то смарт-контракт автоматически инициирует санкционные меры. Трекеры, которые отслеживают соответствующие параметры, передадут информацию, и расчет произойдет с учетом корректирующего коэффициента, заранее определенного в коде программы.

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

Сложнее, если процесс полностью автоматизирован и проходит только в виртуальном мире, а все действия контролирует алгоритм. Порой даже сами разработчики смарт-контрактов не могут повлиять на них. Такая история в 2017 году случилась с блокчейн-кошельком Parity. Из-за неосторожно введенной разработчиками команды на удаление файлов на кошельках пользователей (в основном, стартапов) оказалось заморожено более 150 млн долларов. Создателям Parity не удалось разблокировать счета клиентов даже спустя полгода напряженной работы! К слову, это далеко не первый случай, когда уязвимости в работе Parity приводили к утечкам, взломам и денежным потерям.

Как минимизировать риски

На Западе смарт-контракты уже активно применяются в системе блокчейн, а в России интеллектуальные договоры были легализованы только осенью 2019 года. В целом концепция блокчейна постепенно входит в обиход и российских компаний. Вот почему уже сейчас вопрос минимизации возможных рисков при заключении таких соглашений крайне актуален.

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

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

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

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

Привет! Сто лет сюда не писал, но теперь появился повод.

Когда-то, я рассказывал в России про Firechat. Сегодня, все та-жа команда работает над новым решением распределенной сетью передаче данных. Этот пост приглашение к диалогу.

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

Сеть NewNode состоит из трех типов узлов: инжекторов, пиров и пиров, которые становятся прокси инжекторами. Инжекторы - это доверенная служба, работающая в облаке, в то время как каждый пользователь контента по умолчанию является одноранговым узлом. Узел, который устанавливает соединение с инжектором, становится прокси-сервером инжектора. Каждый инжектор обладает личным ключом инжектора, в то время как каждый одноранговый узел имеет жестко закодированную копию всех открытых ключей инжектора.

Вот как работу сети изобразили авторы, практически на салфетке, в наших лучших традициях:

NewNode обладает уникальной способностью устанавливать CDN в ячеистой сети устройство-устройство (D2D) через локальные соединения, такие как WiFi. Он использует архитектуру приложения FireChat (разработанного инженерами NewNode), которое обеспечивает шифрованную связь, даже когда Интернет не доступен, а устройства не находятся в зоне досягаемости друг друга. Как только контент загружен на одно устройство сетки NewNode, он становится доступным для всех других узлов, даже если ни одно из устройств не подключено к Интернету. NewNode легко переключается между WiFi, 3G, LTE и D2D и самовосстанавливается.

Интеграция проста и эффективна. Этим летом, наше решение неожиданно пригодилось в Беларуси во время глобального отключения интернета. Лежало практически все, а Tut.by, популярный новостной сервис - работал. Благодаря NewNode.

Это, только начало. Коллеги работают над улучшениями и новыми продуктами, нам предстоит много вызовов, не только технологического характера наличие такого решение испортит планы желающих взять под контроль интернет.

Все самое интересное, естественно на GitHub.