Обзор платформы Avalanche

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

Архитектура

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

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

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

Модель подсети дает ряд преимуществ:

- Если валидатор не заботится о блокчейнах в данной подсети, он просто не присоединится к этой подсети.

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

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

То есть каждый блокчейн в подсеть проверяется только набором доверенных валидаторов.

- Можно создать подсеть, в которой каждый валидатор имеет определенные свойства.

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

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

Что по ВМ?

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

• Содержимое блока — переход состояния, который происходит, когда блок принят
• API-интерфейсы, предоставляемые блокчейном, и их конечные точки
• Данные, которые сохраняются на диске

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

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

Что такое начальная загрузка?

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

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

Роль начальных узлов DNS заключается в предоставлении полезной информации о наборе активных участников системы. Тот же механизм используется в Bitcoin Core, где Файл src / chainparams.cpp исходного кода содержит список жестко запрограммированных начальных узлов. Разница между BTC и Avalanche заключается в том, что BTC требует только один правильный начальный узел DNS, в то время как Avalanche требует простого большинство якорей верны.

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

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

Состояние сети

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

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

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

Контроль Сибилы и Членство

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

Предыдущие системы исследовали использование механизмов сдерживания Сибиллы, которые включают доказательство работы (PoW), доказательство ставки (PoS), доказательство истекшего времени (POET), доказательство пространства и времени (PoST) и доказательство авторитета (PoA). По своей сути все эти механизмы выполняют идентичную функцию: они требуют, чтобы каждый участник имел некоторая «шкура в игре» в виде некоторого экономического обязательства, которое, в свою очередь, обеспечивает экономическую барьер против плохого поведения со стороны этого участника.

Все они включают форму ставки, будь то в форме майнинговых установок и хэш-мощности (PoW), дискового пространства (PoST), доверенного оборудования (POET) или утвержденной личности (РоА).

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

Однако семейство Snow * можно объединить со многими из этих известных механизмов, без существенных доработок. В конечном итоге, в целях безопасности и обеспечения того, чтобы стимулы участников были согласованы в пользу сеть, $ AVAX выбирает PoS для основного механизма управления Sybil. Некоторые формы ставок по сути своей централизованный: например, производство буровых установок (PoW) по своей сути централизовано в руках нескольких люди с соответствующими ноу-хау и доступом к десяткам патентов, необходимых для конкурентоспособных СБИС производств. Кроме того, PoW-майнинг теряет ценность из-за крупных ежегодных субсидий майнерам. Так же, дисковое пространство больше всего принадлежит операторам крупных центров обработки данных.

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

Среди этих вариантов выбираем доказательство ставки, потому что оно экологичное, доступное и открытое для всех. Отметим, однако, что хотя $ AVAX использует PoS, сеть Avalanche, позволяет запускать подсети с PoW и PoS.

▶️ Website: https://ru.avalabs.org
▶️ Whitepaper: https://ru.avalabs.org/whitepapers
▶️ Twitter: https://twitter.com/avalabsofficial
▶️ Reddit: https://www.reddit.com/r/ava
▶️ Telegram: https://t.me/avacoin_official
▶️ Facebook: https://www.facebook.com/AvaLabsOfficial