Iron Fish (IRON) - частная криптовалюта

Iron Fish (IRON)  - это децентрализованный, защищенный от цензуры и общедоступный блокчейн-проект, основанный на PoW. Он разработан для поддержки надежных гарантий конфиденциальности при каждой транзакции. Подобно тому, как изобретение уровня SSL / TLS в 90-х годах проложило путь к электронной коммерции и принесло пользу бесчисленным отраслям, мы считаем, что конфиденциальность является фундаментальным требованием для защиты пользователя и расширения использования криптовалюты.

Мы разработали Iron Fish как новую криптовалюту с нуля, чтобы обеспечить простые в использовании, полностью частные платежи, внимательно следуя протоколу Sapling. Каждая учетная запись оснащена ключом просмотра, чтобы предоставить ее владельцу разрешение только на чтение сведений об этой учетной записи.

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

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

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

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

Здесь есть огромный неиспользованный потенциал, но только если пользователи чувствуют себя действительно защищенными своей криптовалютой и могут получить к ней доступ. Точно так же, как введение SSL / TLS в 90-х годах открыло шлюзы для электронной коммерции (предшественников https), мы считаем, что доступная монета конфиденциальности приведет к новому классу отраслей безграничных продуктов и компаний.

Сеть Iron Fish (IRON)

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

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

В то время как некоторые другие сетевые уровни требуют, чтобы пользователь настроил переадресацию портов для своего маршрутизатора для решения проблемы NAT, мы разработали нашу реализацию с упором на доступность, используя комбинацию WebRTC и WebSockets для нашего транспортного уровня. Они используют множество методов, чтобы помочь узлам установить прямую связь. Другими словами, реализация узла Iron Fish работает прямо из коробки, либо в среде интерфейса командной строки, либо даже непосредственно в браузере. Это упрощает использование Iron Fish для всех, независимо от технических способностей.

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

Последовательность запуска

При запуске нового узла происходит следующее:

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

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

Жизненный цикл одноранговых подключений

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

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

Сообщения

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

Типы сообщений

Сетевой уровень Iron Fish в настоящее время имеет четыре различных типа внутренних сообщений:

  • Идентичность: сообщение, с помощью которого одноранговый узел может идентифицировать себя другому.
  • Сигнал: сообщение, используемое для сигнализации сеанса связи в реальном времени (RTC) между двумя одноранговыми узлами.
  • Peer List: сообщение, содержащее список одноранговых узлов, к которым в данный момент подключен этот узел.
  • Cannot Satisfy Request: сообщение об ошибке при возникновении проблемы

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

  • Сплетни: эти сообщения достигают каждого узла в сети. Когда узел получает сообщение сплетни, он проверяет сообщение и пересылает его другим подключенным узлам. Это используется для распространения изменений в цепочке блоков на все узлы сети. Подробнее об этом мы поговорим в следующем разделе.
  • Запустить и забыть: эти сообщения направляются определенному подключенному узлу (невозможно отправить сообщение узлу, к которому вы не подключены). От однорангового узла не ожидается ответа или подтверждения получения. Это полезно, когда вам не нужно следить за тем, чтобы данные были получены правильно.
    Прямой RPC: здесь запрос сообщения отправляется определенному подключенному узлу, и система ожидает ответа. Удаленный вызов процедур (RPC), поток состоит из двух потоков: один для запроса и один для ответа. Он используется в качестве слоя поддержки для Global RPC.
  • Глобальный RPC: эти сообщения не адресованы конкретному партнеру. Сетевая библиотека выберет однорангового узла для отправки сообщения и повторит попытку (до указанного ограниченного количества) с другим одноранговым узлом, если он не получит ответа или если ответ недействителен. Алгоритм выбора является случайным и взвешенным, чтобы отдавать предпочтение партнерам, которые, как известно, с большей вероятностью ответят на зарегистрированный тип сообщения.

Протокол сплетен

Протокол Gossip в основном используется для трансляции новых блоков и транзакций всем партнерам в сети Iron Fish. Чтобы помочь визуализировать это: узлы, соединенные вместе, образуют сеть, а блокчейн - это структура данных, с которой они согласны.

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

В следующем разделе подробно рассказывается, как в настоящее время осуществляется трансляция сплетен Iron Fish.

Базовая реализация

Шаг 1

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

Давайте представим, что наша текущая сеть состоит из нового узла A, подключенного к узлам B и C. Сам узел C подключен к узлам D и E. Сам D подключен к F и G. Визуально это будет выглядеть, как на изображении ниже.

Визуализация того, как подключены узлы нашего примера.

Узлы знают только своих непосредственных соседей и соседей своих соседей. Узел A не будет знать Узлы за пределами D и E.

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

Шаг 2

Когда узел A решает передать новое сообщение, он отправит сообщение типа Gossip всем своим подключенным узлам (в этом примере C и B).

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

Оптимизация 

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

Местная история

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

Сосед в ролях

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

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

В приведенном ниже примере узел A подключен к B, C, D, E и хранит список одноранговых подключений на два уровня в глубину.

Когда Узел А рассылает сообщение, его распространение происходит в два этапа:

  1. Узел A передает сообщения узлам B, C, D и E.
  2. Узел B пересылает сообщение к G. Он не пересылает его C и E, потому что знает, что узел A подключен к ним и уже отправил его. Узел C пересылает сообщение к H. Узел D пересылает к I, а узел E к F.

Когда узел F сплетничает сообщение, в этом примере распространение происходит в четыре этапа:

  1. Узел F передает сообщение узлу E.
  2. Узел E пересылает сообщение как A, так и B.
  3. Узел B пересылает на G. Он не пересылает к A, потому что знает, что E подключен к A. Он не пересылает C, потому что знает, что он подключен к A.
  4. Узел C и узел D пересылают сообщение H и I.