..давно не смотрел свой bip кошелёк.сегодня зайдя вижу,что баланс не меняется..
и это что значит?
Теперь давайте ответим на вопрос - есть ли MEV в сети Cosmos.
Часто приходится слышать, что MEV в сети Cosmos невозможен благодаря порядку обработки транзакций по принципу first-in-firs-serve. Этот принцип подразумевает формирование последовательности транзакций в блоке строго в порядке их поступления в мемпул. Отчасти утверждение выше не лишено правды и называный подход надежно защищает блокчейн от фронтраннинга и сэндвичинга со стороны рядовых сёрчеров, однако препятствий для бэкраннинга нет. Как показали skip_protocol/announcing-mev-satellite-the-first-cosmos-ecosystem-mev-dashboard-9c1445e29e22">исследования, MEV в сети Cosmos существует и достаточно прибылен.
С учетом особенностей архитектуры сети, вместо газовых аукционов боты вынуждены соревноваться в скорости и количестве отправляемых транзакций. Когда открывается возможность для извлечения прибыли, они стремятся отправить в сеть максимальное количество транзакций с минимально возможной задержкой. Эта схема получила название speed-and-spam и она налагает на сёрчера дополнительные ограничения. Чтобы побеждать в speed-and-spam необходимо располагать свою инфраструктуру физически как можно ближе к нодам валидаторов, в идеале в одном и том же дата центре и иметь сеть с низкой задержкой и высокой пропускной способностью. Не каждый сёрчер может себе позволить затраты на такую инфраструктуру, поэтому одной из интересных особенностей сети Cosmos является то, что практически всю MEV получают буквально несколько сёрчеров.
Видимым негативным для всей сети последствием реализации схемы speed-and-spam является впустую потраченное блочное пространство и газ. Время от времени, особенно после особо удачных возможностей арбитража, можно встретить блоки, значимую часть которых составляют неудавшиеся MEV транзакции. И эта проблема будет расти пропорционально развитию сети Cosmos. В будущем при масштабировании схема speed-and-spam теоретически может повысить риск замедления или остановки сети.
Как мы говорили ранее, единственная возможность извлечения MEV для простых сёрчеров сети Cosmos это бэкраннинг. Однако валидатор не является обычным пользователем сети и спектр его возможностей довольно широк. В частности, валидатор имеет техническую возможность для перетасовки транзакций в блоке, что теоретически, при наличии умысла, открывает возможности для фронтраннинга и сэндвичинга. Понятно, что это отнюдь не распространенная практика, так как подобное поведение валидатора быстро станет замеченным и повлечет за собой репутационные издержки, однако следует держать в голове эту возможность, как и вероятность наличия сговора между валидатором и сёрчером.
В момент, когда ликвидация или арбитраж найден, каждый бот стремится воспользоваться возможностью для заработка и отправляет соответствующую транзакцию в мемпул как можно скорее. Поскольку все конкуренты действуют схожим образом, возникает ситуация, что мемпул наводняется кучей однотипных транзакций ожидающих включения в формирующийся блок. Из-за того, что извлечь прибыль из арбитража или ликвидации можно лишь единожды, каждый бот начинает продвигать свою транзакцию в топ блока предлагая все больший и больший размер комиссии. По большому счёту, этот газовый аукцион может продолжаться до тех пор, пока потенциальная прибыль хоть сколь-нибудь больше, чем комиссия за транзакцию. В результате, победивший в соревновании бот получает некую ненулевую прибыль, валидатор получает огромную дополнительную плату за комиссию, а простой пользователь, совершавший рутинную транзакцию, получает внезапно выросшие комиссии за исполнение. Пожалуй, непредсказуемый рост стоимости транзакций для рядовых пользователей является единственным негативным последствием этого вида MEV, хотя в целом данное явление рассматривается как положительное, снижающее общую неэффективность рынка.
Теперь давайте поговорим о видах MEV, которые не несут пользы как для рынка и потенциально наносят вред экосистеме в которой они существуют.
Некоторые хитрые сёрчеры решили, что искать собственными силами возможности для заработка слишком трудоемко и настроили своих ботов на поиск в мемпуле чужих потенциально выгодных транзакций. Допустим, какой-то арбитражный бот нашел возможность для заработка и отправил транзакцию в мемпул. Её тут же находит другой бот, пристально следящий за мем пулом и целенаправленно выискивающий арбитражные транзакции. Проведя быструю оценку, он понимает всю потенциальную выгоду от осуществления этой транзакции, полностью её копирует и отправляет в мемпул, при этом указав для своей транзакции большую комиссию, чем было у оригинальной. Этот прием называется фронтраннинг. Помимо провоциоруемого газового аукциона, очевидным негативным результатом является то, что честный сёрчер остаётся “ограбленым”, его усилия по поиску и осуществлению арбитража или ликвидации остаются невознагражденными.
Иногда принести выгоду может выполнение MEV транзакции после некой особенной транзакции из мемпула. Этот прием называется бэкраннинг. Например, мемпул изучается на наличие объёмной транзакции, которая после исполнения очевидно сдвинет баланс в пуле ликвидности DEX и вызовет проскальзывание цены. Сразу после её осуществления, бэкраннинг бот закупает в этом же пуле ликвидности "просевший" актива по заниженной стоимости. Спустя какое то время, актив продаётся уже по рыночной стоимости а курсовая разница составляет прибыль. Так же бэкраннинг боты могут мониторить DEX и ловить пулы ликвидности в момент создания. Затем "вычерпывать" ликвидность одного токена из пары, что задирает его цену резко вверх. Другие игроки видя стремительный рост стоимости пытаются сыграть на этом, что поднимает цену еще выше. Далее бот продаёт изначально купленные токены на высокой отметке, получая прибыль и оставляя мелких игроков с пустыми карманами.
Наиболее вредоносный тип MEV для рядового пользователя сети это сэндвичинг, представляющий собой комбинацию фронтраннинга и бэкраннинга. Тут всё просто - бот видит в мемпуле объемную транзакцию на покупку токена, устанавливает ордер на покупку того же токена и за счет более высокой комиссии добивается приоритетного исполнения. Это вызывает первоначальный рост цены на актив, далее последующее исполнение ордера изначального покупателя задирает цену еще выше, после чего бот следующей транзакцией выгодно “разгружается” зарабатывая курсовую разницу созданную, по сути им же самим. Проблема в том, что изначальный покупатель получает меньше монет и по совсем другой цене, чем рассчитывал и становится ему это известно только после исполнения транзакции.
Говоря очень простыми словами, MEV - это возможность получения валидатором дополнительного дохода путем манипулирования порядком транзакций в блоке. Чаще всего, речь идет о дополнительных комиссиях за транзакции, взимаемых с сёрчеров, извлекающих прибыль из возможностей арбитража или ликвидации, и желающих, чтобы их транзакции были выполнены в первую очередь. Реже, прибыль извлекается путем эксплуатации уязвимостей и несовершенства некоторых смарт-контрактов. Очень часто, при объяснении принципов работы смарт-контракта, приводят аналогию с вендинговым автоматом. Это сравнение подходит и для иллюстрации того факта, что люди часто пытаются обмануть машину, чтобы получить парочку банок колы бесплатно. Прибегая к чрезмерному упрощению, относительно вендингового аппарата эти две банки тоже в некотором роде MEV.
Читать полностью…Друзья! Мы создали и будем развивать комьюнити Stakeflow, посвященное Proof-of-Stake, где планируем на регулярной основе публиковать материалы о текущих событиях в сфере блокчейна а так же полезные разборы имеющихся технологий. Присоединяйтесь к нашему русскоязычному и англоязычному телеграм каналам, подписывайтесь на твиттер и медиум.
Читать полностью…Теперь, когда мы разобрались с основными понятиями давайте внимательно рассмотрим одну
из стандартных конфигураций которую рекомендуют Strangelove Ventures для запуска валидатора с помощью технологии Horcrux. Схема представляет из себя 3 ноды-сентри и 3 ноды-сайнера, из которых 2 достаточно для формирования валидной подписи. Обратите внимание, что все ноды-сайнеры должны быть связаны друг с другом. Каждый новый рабочий цикл лидер нода-сайнер выбирается случайным образом и она должна иметь возможность связываться со всеми остальными. Количество нод-сайнеров равно количеству нод-сентри и каждая нода-сентри связана с каждой нодой-сайнером. В принципе, ничего не мешает создать схему в которой каждая конкретная нода-сайнер будет связана только с непосредственно одной нодой-сентри но это менее рационально с точки зрения обеспечения отказоустойчивости системы. В целом данная схема позиционируется создателями как оптимальная по соотношению затрат к получаемым преимуществам.
Безопасность приватного ключа в данном случае обеспечивается во-первых за счет того, что ноды-сайнеры “спрятаны” от внешнего интернета за нодами-сентри. А это значит, что IP-адреса серверов, хранящих фрагменты приватного ключа, не транслируются в общий доступ, что усложняет любые попытки злонамеренного доступа на них. Во-вторых для того чтобы скомпрометировать приватный ключ, злоумышленнику потребуется получить доступ как минимум к двум фрагментам. В любом случае весьма предусмотрительно будет надежно хранить резервную копию приватного ключа, чтобы в случае потери по какой-либо причине одного или нескольких фрагментов оперативно восстановить работу валидатора. Тем более, каждый раз horcrux разбивает приватный ключ по-разному, что сводит к минимуму угрозы если, например, злоумышленник получил доступ к одному из фрагментов.
Как мы писали ранее, угрозы для работоспособности валидатора сети PoS можно условно разделить на два типа: связанные с неправильным использованием приватного ключа и связанные с отказоустойчивостью серверной инфраструктуры. Зачастую, попытки устранить один тип угроз, приводят к возрастанию рисков в другой части. В более общем виде задача оператора ноды сводится к нахождению баланса между безопасностью, работоспособностью и стоимостью обслуживания.
Сегодня давайте поговорим о технологии Horcrux, которая позволяет обеспечить защиту приватного ключа при хороших показателях работоспособности и доступности системы.
Horcrux - это решение от команды Strangelove Ventures. Суть его заключается в том, что файл priv_validator_key, в котором ключ хранится в незашифрованном виде можно разбить на произвольное количество зашифрованных фрагментов, и использовать их комбинации для создания валидной подписи блока. Подробнее о том, что такое приватный ключ валидатора и методах его защиты мы писали ранее.
При разбиении ключа выбираются два определяющих параметра: на сколько частей будет разбиваться
приватный ключ и сколько из этих частей достаточно для формирования валидной подписи блока. Разработчики рекомендуют делить приватный ключ на три или пять частей, чтобы для формирования легитимной подписи было достаточно двух или трех из них соответственно. Однако конечное решение в любом случае остается на усмотрение оператора ноды, поскольку каждый работает со своим перечнем задач и индивидуальным набором ограничений.
Друзья! Мы создали и будем развивать комьюнити Stakeflow, посвященное Proof-of-Stake, где планируем на регулярной основе публиковать материалы о текущих событиях в сфере блокчейна а так же полезные разборы имеющихся технологий. Присоединяйтесь к нашему русскоязычному и англоязычному телеграм каналам, подписывайтесь на твиттер и медиум.
Читать полностью…Следующий вариант - хранить приватный ключ удаленно. Например, валидатор может организовать физический сервер в месте, куда он имеет простой и свободный доступ, и хранить ключ на нем. При этом для подписания блока нода каждый раз будет обращаться к данному серверу. Более надежным и очень сходным образом будет выглядеть хранение приватного ключа с помощью аппаратных модулей безопасности, таких как YubiHSM 2 или аппаратных кошельков типа Ledger и Trezor. Разница будет состоять в том, что в данном случае приватный ключ не покидает пределы устройства ни в каком виде - процесс подписи осуществляется внутри модуля, устройство возвращает на ноду уже подписанный блок. Более того, аппаратные кошельки специально созданы для работы с криптовалютой и на них могут запускаться кастомные приложения, оснащенные дополнительной логикой, например чтобы избегать двойной подписи. Дополнительным удобством является то, что все три вышеперечисленных способа хранения можно организовать с помощью Key Management System разработанной специально для Tendermint сетей.
Читать полностью…Используя технологию Interchain Account можно создать аккаунт в сторонней сети (host chain) и контролировать его с помощью аккаунта на вашей основной сети (controller chain). Это позволяет выполнять транзакции в сторонней сети от вашего имени без необходимости пользователю физически участвовать в этом процессе. В этом случае открывается возможность создать децентрализованное приложение в котором наша задача по стейкингу будет сводиться для пользователя только к последнему шагу, в то время как все рутинные операции за него будет делать смарт-контракт:
1. Создание ICA на бирже Osmosis;
2. Перевод Атомов на ICA на бирже Osmosis;
3. Обмен Атомов на Juno;
4. Создание ICA в сети Juno;
5. Перевод с биржи Osmosis на адрес в сети Juno;
6. Стейкинг токенов в сети Juno.
Безусловно для реализации такого алгоритма потребуется надежный источник обратной связи, чтобы понимать что каждая стадия выполнилась корректно. Этой цели служит модуль Interchain Query.
Раньше проблема заключалась в том, что ты не можешь просто взять и получить состояние одного блокчейна, находясь в другом, потому что это разные сети с разными бинарниками и отличающимися валидаторами. Однако используя ICQ теперь это сделать можно. ICQ модуль запрашивающий сети формирует пакет с запросами и отправляет его по IBC каналу в ICQ модуль запрашиваемой цепи. Тот, в свою очередь, распаковывает запросы, выполняет их, а результат возвращает таким же образом, как и получил запрос. Таким образом теперь блокчейны экосистемы Cosmos могут свободно считывать состояние друг друга не прибегая к помощи сторонних оракулов.
Подводя итог, хочется сказать, что данные инструменты открывают широкие возможности для создания децентрализованных приложений и смарт-контрактов в сети Cosmos, особенно в свете приближающегося запуска протокола Interchain Security.
Друзья! Мы создали и будем развивать комьюнити Stakeflow, посвященное Proof-of-Stake, где планируем на регулярной основе публиковать материалы о текущих событиях в сфере блокчейна а так же полезные разборы имеющихся технологий. Присоединяйтесь к нашему русскоязычному и англоязычному телеграм каналам, подписывайтесь на твиттер и медиум.
Читать полностью…Принимая во внимание все вышесказанное, хочется выразить обеспокоенность по следующим техническим вопросам:
1️⃣ Индивидуально настраиваемые ончейн параметры консьюмер чейна могут существенно отличаться от параметров основной сети. Например, в ходе тестнета, консьюмер чейн сети Crescent слешил валидатора за 50% пропущенных блоков внутри окна в 100 блоков, в то время как в основной сети допускается пропускать менее 50% блоков внутри окна в 8640. Для многих валидаторов такая значительная разница может оказаться неожиданностью, поэтому нам хотелось бы видеть параметры слешинга в интерфейсе голосования, так как это является теперь немаловажным фактором при исследовании запускаемого проекта.
2️⃣ Как было сказано выше, слегинш в констюмер чейне автоматически влечет за собой слешинг и в основной сети. Это открывает заманчивые возможности для злонамеренных действий: может легко возникнуть соблазн задать в консьюмер чейне непреодолимые параметры слешинга, что отправит в джейл весь сета валидаторов, и как результат остановит основную сети Cosmos Hub.
К техническим моментам хочется добавить обеспокоенность со стороны валидаторов:
1️⃣ Дело в том, что не каждый валидатор хочет работать с каждым конкретным консьюмер чейном, однако в настоящий момент политика Cosmos Hub такова, что ты обязан это делать, если проект успешно прошел стадию голосования, а ты являешься активным валидатором.
2️⃣ Угрозы безопасности для Cosmos Hub, а так же индивидуальные риски для валидаторов и их стейков, связанные со слэшингом в консьюмер чейнах, накладывает на валидаторов дополнительную ответственность. Это значит, что им придется тратить дополнительные ресурсы на тщательное исследование каждого проекта, начиная от общей оценки и заканчивая аудитом кода и бинарников, и эта не та работа, к которой большинство валидаторов привыкло.
Skip Protokol предлагает решение для MEV в сети Cosmos и других проектов на основе Tendermint, таких как Osmosis, Juno и Evmos. Команда разработчиков рассматривает арбитраж и ликвидацию как “хороший” MEV и их цель - эффективно встроить механики для его реализации в экосистему. Генерируемую при этом дополнительную прибыль предполагается пропорционально разделять между сёрчером, валидаторами и их стейкерами, и, возможно, казначейством проекта.
Skip Protocol предоставляет инфраструктуру для сёрчеров, через которую они могут отправлять свои MEV транзакции в Skip Sentinel, предлагая при этом произвольный размер комиссии за их исполнение. Skip Sentinel в свою очередь изучает весь пул входящих транзакций и при наличии конфликтующих, передает в обработку только те, за которые назначены большие комиссии. Также все передающиеся в обработку транзакции проходят проверку на наличие токсичного MEV, такого как фронтраннинг и сэндвичинг. После этого Skip Sentinel передаёт прошедшие отбор транзакции валидаторам, сотрудничающим со Skip Protocol. Если один из них является ответственным за формирование текущего блока, транзакции гарантированно попадут в топ блока и будут исполнены. Очевидной проблемой является то, что если валидатор, ответственный за формирование текущего блока, не сотрудничает со Skip, то вся схема рушится. Однако чем больше валидаторов вовлечется в процесс, тем выше будет его результативность. Дополнительные комиссии за исполнение MEV транзакции перечисляются валидатору, который в свою очередь имеет возможность решить в какой пропорции распределять их между стейкерами.
Также стоит отметить, что Skip Protocol позволяет рядовым пользователям отправлять транзакции через свои эндпоинты для повышения конфиденциальности операций. При отправке транзакций таким способом они избегают попадания в публичный мемпул и не могут быть “подслушаны” злоумышленниками. Вместо этого транзакция попадает в отдельный пул, называемый сайдкар, где она дожидается пока один из валидаторов, участвующих в Skip Protocol не будет ответственнен за формирование нового блока. Далее транзакция направляется в блок напрямую через валидатора, избегая публичного мемпула.
В ходе всего описанного выше процесса транзакция взаимодействует только с инфрастуктурой Skip Protocol и сетом доверенных валидаторов. В свою очередь Skip Protocol тщательно следит за добросовестностью участников и закрывает доступ как валидаторам, пойманных на попытках самовольно перетасовывать транзакции, так и сёрчерам повергавшим Skip Sentinel DDoS-атакам.
Подводя итог вышесказанному, Skip Protocol определенно является перспективной технологией для экосистемы Cosmos. С помощью неё валидаторы могут зарабатывать больше с каждого блока и делиться этим доходом со своими делегаторами. Сёрчеры получают возможность конкурировать в равных условиях, а вся экосистема получает защиту от speed-and-spam и токсичных форм MEV.
Мы рассмотрели несколько типов MEV связанных с изменением порядка транзакций в только создающемся блоке. Однако, недобросовестный валидатор иногда может заметить, что если перераспределить порядок транзакций в уже добытом блоке, то можно извлечь дополнительно прибыль кратно превышающую награду за производство блока. В таком случае, он может попытаться перемайнить данный и все последующие блоки заново. Данное действие, безусловно, потребует некого сговора между несколькими валидаторами. Этот тип MEV называется тайм-бэндит атака и он не несет угроз для крупных блокчейнов с высокой степенью децентрализации, однако остаётся опасным для небольших проектов.
Подведём промежуточный итог: арбитраж и ликвидация в целом считаются "хорошим" MEV, так как используют неэффективность рынка, тем самым помогая ему прийти в равновесие. Тем не менее они могут нести негативные эффекты для обычных пользователей блокчейна, так как соревнование между ботами за место в топе блока влечет увеличение комиссии за проведение транзакций. Фронтраннинг, бэкраннинг, сэндвичинг, тайм-бэндит атаки однозначно рассматриваются как "плохой" MEV, который не приносит пользы никому, кроме владельцев ботов. Однако эти приёмы не нарушают никаких правил и существуют как бы в серой зоне, эксплуатируя несовершенства и уязвимости архитектуры блокчейна.
В современных практиках есть тенденция к попыткам защитить блокчейн от "плохого" MEV, чтобы он не портил для простых юзеров опыт использования сети. "Хороший" же MEV стараются встроить в структуру проекта, таким образом, чтобы извлекаемая дополнительная прибыль отходила не только отдельным сёрчерам и валидаторам, но и их стейкерам и блокчейну в целом, ведь благодаря их деятельности и существует сама возможность извлечения MEV.
MEV является аббревиатурой от Maximum Extractable Value, однако ещё встречаются статьи, где данное сокращение раскрывается как Miner Extractable Value. Разница состоит в том, что второй вариант на данный момент является устаревшим, он был употребим в сети Ethereum до обновления The Merge, когда проблема MEV и возникла впервые. После перехода сети Ethereum на протокол proof-of-stake и замены майнеров на валидаторов, проблема никуда не исчезла и термин пришлось актуализировать.
Тема MEV достаточно сложная и комплексная. Чтобы в ней разобраться в общих чертах давайте посмотрим на данное явление с различных сторон. Поскольку, оно зародилась и приобрело известность в сети Ethereum, для начала стоит разобраться в том что в настоящее время существует там.
В первую очередь давайте ответим на вопрос - откуда вообще берется возможность для извлечения MEV. Здесь нужно понимать три ключевых момента. Во-первых, в сети Ethereum все транзакции до момента включения в блок попадают в публичный мем-пул и это значит что их могут видеть все. Во-вторых, валидатор имеет возможность располагать транзакции в добываемом блоке в любом порядке на свое усмотрение. В-третьих, в первую очередь валидаторы будут стремиться включить в блок транзакции за которые им предлагаются наибольшие комиссии. Исходя из всего вышеперечисленного получается, что валидатор может самостоятельно манипулировать порядком транзакций для получения дополнительного дохода или его можно стимулировать провести какую-либо одну или несколько транзакций в первую очередь задав повышенную комиссию за исполнение.
Теперь стоит упомянуть два инструмента заработка возникших еще в традиционной биржевой торговле и успешно встроившихся в блокчейн. Речь идет об арбитраже и ликвидации.
Арбитраж - это использование неэффективности рынка в части различия цен на один и тот же актив на различных площадках или даже между различными пулами ликвидности внутри одной площадки. Проще говоря - покупаем в одном месте дешевле, в другом продаем дороже, получаем прибыль.
Ликвидация - это принудительное закрытие позиций на лендинговых сервисах при маржинальной торговле. В случае, когда потери заемщика начинают нести угрозу залоговой сумме, в сфере традиционных финансов перед ликвидацией заёмщику обязательно бы поступил margin call от брокера с предложением увеличить сумму залога. В De-Fi секторе, живущем исключительно за счёт исполнения смарт-контрактов, ликвидация производится автоматически. При этом лендинговая платформа делиться частью залога с ликвидатором, что и является его прибылью.
Поскольку возможности для арбитража открываются постоянно и в больших количествах, их поиск и реализация являются монотонной и рутинной работой, которую принято автоматизировать с помощью ботов. Стоит понимать, что это очень конкурентная среда, поэтому множество ботов одновременно находятся в поиске возможностнй для извлечения прибыли и пытаются их реализовать.
Привет всем, кто заинтересован, нам нужен потенциальный эксперт по кибербезопасности, пожалуйста, отправьте входящее сообщение, если вы аналитик кибербезопасности
Читать полностью…Отказоустойчивость валидатора обеспечивается избыточностью фрагментов приватного ключа и количества нод-сентри, а также распределением серверов по разным регионам. Сервера могут выходить из строя по разным причинам - в результате DDoS-атак, перебоев с электричеством, поломок аппаратной части - физическое расположение их в разных дата-центрах значительно снижает риск одновременного выхода из строя всей инфраструктуры. При описанной выше комбинации допустимо одномоментно потерять одну ноду-сайнера и две ноды-сентри и при этом сохранить работоспособность валидатора.
Очевидными плюсами Horcrux является значимое повышение безопасности и отказоустойчивости валидатора, однако за это приходится заплатить усложнением настройки и повышенными расходами на содержание серверной инфраструктуры.
Поскольку каждый фрагмент приватного ключа должен храниться на отдельном сервере, то чем меньше
количество частей необходимых для формирования легитимной подписи, по сравнению с общим количеством, тем выше отказоустойчивость системы. Обусловлено это тем, что при выходе из строя даже нескольких серверов, работа валидатора нарушена не будет.
С другой стороны, это количество должно быть строго больше половины от общего числа фрагментов,
чтобы не возникло ситуации, когда одновременно сформируются два кластера, которые параллельно подпишут один и тот же блок, что повлечет за собой двойную подпись.
Поскольку приватный ключ разбит и рассредоточен, при использовании технологии Horcrux отсутствует в целом такое понятие как нода валидатор. При организации серверной архитектуры используются два типа
нод:
- Signer node - нода, которая хранит один из нескольких зашифрованных фрагментов приватного ключа. Системные требования для ноды-сайнера не высоки: 1 CPU, 1 GB RAM, 20 GB SSD, что позволяет использовать для нее самый простой VPS, однако оператор может выбрать и другие варианты на свое усмотрение.
- Sentry node - нода, которая является связующим звеном между Signer нодами и блокчейном. Через неё осуществляется передача приватного ключа для подписи блока. Фактически она преставляет собой обычную полную ноду и при выборе сервера для размещения рекомендуется следовать системным требованиям разработчика. Например, для тендерминт сетей это обычно 4 CPU, 16GB RAM, 500GB SSD.
Чтобы формирование валидной подписи не осуществлялось хаотично и во избежание double sign в кластере нод-сайнеров выбирается случайным образом одна, которая получает роль лидера (Raft
leader). Её задачей является агрегирование на себе фрагментов приватного ключа, формирование из них подписи и передача её на блокчейн.
Основная задача кластера нод-сентри - передавать информацию между лидером нодой-сайнером и блокчейном. Разработчики рекомендуют создавать ноды-сентри в количестве равном количеству нод-сайнеров для повышения отказоустойчивости. Однако, в любом случае это решение принимает
оператор, основываясь на своих задачах. Например, в ходе тестнета Quark-1 от Neutron для оптимизации затрат мы успешно реализовали схему с одной нодой-сентри и тремя нодами-сайнерами.
Еще одним достаточно надежным способом защиты является разбитие приватного ключа на несколько зашифрованных фрагментов, хранение их на разных серверах и использование их комбинации для подписывания блоков. Сделать это позволяет технология Horcrux от Strangelove Ventures. В целом, это довольно комплексное решение, нацеленное не только на защиту приватного ключа, но и на повышение отказоустойчивости валидатора, однако в рамках этой статьи мы не будем рассматривать его очень подробно. При разбиении ключа выбираются два ключевых параметра: на сколько частей будет разбиваться приватный ключ и сколько из этих частей достаточно для формирования валидной подписи блока. Например, мы можем разделить приватный ключ на пять частей, и для формирования легитимной подписи будет достаточно трех из них. Количество фрагментов необходимых для формирования легитимной подписи очень важно. С одной стороны, чем оно меньше, по сравнению с общим количеством частей, тем выше отказоустойчивость системы. С другой стороны, оно должно быть строго больше половины от общего количества фрагментов, чтобы не возникло ситуации, когда одновременно сформируются два кластера, которые параллельно подпишут один и тот же блок, что повлечет за собой двойную подпись.
В целом, задача валидатора по обеспечению безопасности приватного ключа заключается в том, чтобы сделать его максимально защищенным от кражи злоумышленником или случайной утраты, в то же время обеспечив его доступность для подписания блоков и, желательно, при этом сохранив затраты на техническое обеспечение на приемлемом уровне. С точки зрения делегатора, защищенность приватного ключа - весомый фактор при выборе валидатора для стейкинга, потому что стратегия безопасности валидатора напрямую влияет на риск потерять токены в результате слэшинга.
Угрозы для работоспособности валидатора сети PoS можно условно разделить на два типа: связанные с неправильным использованием приватного ключа и связанные с отказоустойчивостью серверной инфраструктуры. Сегодня давайте поговорим о приватном ключе валидатора.
Самое дорогое и ценное, что есть у валидатора в сети Tendermint - это текстовый незашифрованный файл priv_validator_key.json. В этом документе находится приватный ключ валидатора, благодаря которому устанавливается его идентичность в процессе подписания блоков.
Ошибки и неправильное обращения с этим файлом могут привести либо к утрате валидатором способности подписывать блоки, либо к двойной подписи блока.
Двойная подпись - это ситуация, когда один и тот же блок два раза подписан одним и тем же валидатором. Случается это если в сети запущены две валидатора с одинаковым приватным ключом. Причиной тому могут быть невнимательность оператора ноды или же целенаправленные действия злоумышленника. В любом случае последствия двойной подписи очень тяжелые - валидатор больше не сможет работать в данной сети, а все делегаторы потеряют процент от своих застейканных токенов и будут вынуждены ределегировать свои стейки другому валидатору.
В случае простой потери файла, например случайного удаления при каких-либо рутинных операциях с нодой, валидатор просто перестанет подписывать блоки и в определенный момент попадет в джейл, из которого, можно выйти, если резервная копия файла была сохранена.
На самом базовом уровне, при установке Tendermint ноды priv_validator_key.json хранится на сервере в незашифрованном виде. Но даже в этом случае обеспечивается минимально необходимый уровень безопасности, если команда ответственно хранит пароли, закрывает все незадействованные порты файерволом, заходит на сервер только по ssh-ключу и имеет надежно хранимую копию приватного ключа.
Друзья! Мы создали и будем развивать комьюнити Stakeflow, посвященное Proof-of-Stake, где планируем на регулярной основе публиковать материалы о текущих событиях в сфере блокчейна а так же полезные разборы имеющихся технологий. Присоединяйтесь к нашему русскоязычному и англоязычному телеграм каналам, подписывайтесь на твиттер и медиум.
Читать полностью…В рамках тестнета Quark-1 от Neutron нам удалось поработать с относительно новыми фишками Cosmos Hub - Interchain Accounts (межсетевые аккаунты) и Interchain Queries (межсетевые запросы) в первый раз. Данные инструменты не только значительно расширяют возможности разработчиков в сети Cosmos, но и лежат в основе концепции Атом 2.0.
Для того, чтобы понять спектр возможностей, открываемых с помощью Interchain Accounts (ICA) и Interchain Queries (ICQ) давайте для начала посмотрим какие возможности по межсетевым взаимодействиям имеются в экосистеме Cosmos сейчас.
В настоящий момент пользователь может владеть множеством аккаунтов в различных сетях Cosmos и имеет возможность переводить средства между ними с помощью IBC протокола. Данные аккаунты могут быть созданы автоматически во всех активных сетях, например при использовании кошелька Keplr, но они все равно являются разными аккаунтами. В случае, если, допустим, у пользователя есть несколько Атомов на кошельке в Cosmos Hub и он хочет застейкать их какому-нибудь валидатору в сети Juno, от него потребуется:
1. Перевести Атомы на биржу Osmosis;
2. Поменять Атомы на Juno;
3. Перевести с биржи на адрес в сети Juno;
4. Выбрать валидатора и застейкать ему токены.
На первый взгляд вроде ничего сложного, однако стоит учитывать, что каждая операция по переводу средств будет сопровождаться процедурой ввода адреса кошелька, которая в результате малейшей опечатки может завершиться в лучшем случае ошибкой, а в худшем потерей средств.
Для того чтобы ответить на технические вызовы, команда Cosmos Hub внедрила на последней стадии тестнета два улучшения: ограничитель максимально допустимо слэшинга в час (Circuit Breaker) и инструмент, позволяющий валидатору создавать для каждого консьюмер чейна отдельный приватный ключ. Ну и конечно, в случае если непосредственно перед датой запуска в успешно прошедшем голосование проекте вдруг обнаружится нечто подозрительное или опасное, валидаторы просто имеют возможность не запускать ноды, ведь чейн не заработает, если 67% нод не включится.
С желанием валидаторов работать по новым правилам сделать что-то будет сложнее, ведь здесь не обойтись мелкими техническими улучшениями. В любом случае решение о внедрении ICS в основную сеть будет приниматься как и полагается на голосовании, где каждый валидатор сможет выразить свою позицию.
Со своей стороны, мне внесли небольшие улучшения в наш Stakeflow эксплорер для отображения экосистемы консьюмер чейнов, чтобы было удобно отслеживать на какой стадии находится каждый проект.
В завершение хочется отметить, что Interchain Security - это безусловно интересная и перспективная технология, которая теоретически может дать невероятный толчок к развитию все экосистемы Cosmos. Мы полагаем, что все текущие проблемы будут так или иначе преодолены и список проектов, которые уже изъявляют желание присоединиться к основной сети Cosmos в качестве консьюмер чейнов (Neutron, Generic Asset Issuance Chain, Duality, Stride, FairBlock Network, и Simply Staking) показывает в целом позитивный настрой.
Сегодня заканчивается Тестнет Game of Chains от Cosmos Hub и мы с чистой совестью уже можем обобщить новую информацию, полученную на нем, и поделиться назревшими вопросами.
Для начала, давайте вкратце вспомним, что в рамках Game of Chains тестировалась новая технология - Interchain Security (ICS), которая позволяет сету валидаторов Cosmos Hub предоставлять безопасность стороннему проекту в экосистеме Cosmos за процент от комиссий и наград за стейкинг. В данном контексте сеть, которая предоставляет безопасность, называется провайдер чейн, а проект, пользующийся её услугами, консьюмер чейн.
Ранее мы писали об общей концепции ICS, а сейчас мы ещё сильнее углубились в тему и готовы поделиться подробностями.
Процедура запуск консьюмер чейна является двухстадийным процессом. На первом этапе, решение о том запускать данный блокчейн или нет принимается путем голосования в основной сети Cosmos Hub. В течение отведенного периода валидаторы отдают свои голоса в зависимости от их заинтересованности в проекте. Результаты подсчитываются по общей процедуре, установленной в Cosmos Hub, и если предложение о запуске блокчейна проходит, то процесс переходит на следующую стадию.
На втором этапе все валидаторы Cosmos Hub должны подготовить ноды и запустить их в обозначенное время запуска сети. Здесь очень важно быть внимательным и ни в коем случае не пропустить запуск сети, потому что если этого не сделать, то скорее всего валидатор будет заслешен, а слешинг в консьюмер чейне влечет за собой автоматический слешинг и в провайдер чейне.