Снэпшоты что это такое в крипте

Snapshots — «фото на память (дисковую;)»

Всегда странно представлять себе времена, когда чего-то не было. Сложно сегодня представить себе, как мы жили без персональных компьютеров, без интернета, без торрентов, mp3, или без электрокопировальных аппаратов, в просторечии «ксероксов». Тем не менее всегда были времена, когда что-то привычное нам еще не существовало. Также обстояло дело и с понятием «снэпшота данных». Но сперва — что же такое «снэпшот»?

«Снэпшот» (дословно — «фотография», «моментальный снимок», здесь и далее под этим словом мы будем понимать конкретно, не уточняя, «снэпшот данных») это моментальная копия состояния данных в системе хранения, или программе, зафиксированная на определенный момент времени. Это может быть моментальное состояние содержимого файла, базы данных, или файловой системы (как частного случая «базы данных»).
В применении к системам хранения данных этот термин появился вместе с первыми системами хранения NetApp и был, на тот момент первой и главной их «фичей».

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

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

Inode, напомню, это блок данных, определяющий содержимое файла. Он может ссылаться либо прямо на конкретные блоки, либо, для больших файлов, на промежуточные inodes, образуя «дерево» от «корня», единственного на всю файловую систему тома, так называемого «корневого» inode.
Таким образом, создав копию ровно одного блока, корневого inode данной файловой системы, мы получим, обратившись к нему, вместо текущего «корня», «псевдо-файловую систему», хранящую без изменений (read-only) все данные на момент времени, когда мы скопировали этот inode. Ведь, как вы помните, однажды записанные блоки данных файлов в дальнейшем не изменяются.

Каким же образом это выглядит на практике?
Для упрощения рассказа я буду рассматривать NAS-вариант работы NetApp, хотя, как вы знаете, аналогичным образом тот же самый сторадж может работать и как SAN-устройство.

Каждый том на системе хранения NetApp является отдельной файловой системой. На каждой файловой системе можно создать до 254 снэпшотов ее состояния, по методике, описанной выше.
Все созданные снэпшоты автоматически доступны через директорию /.snapshot (или /~snapshot) в корне тома. Зайдя туда, мы увидим имена созданных снэпшотов (они могут носить либо «собственное имя», например «/lets_fix_this_small_bug…oh_shit. «, будучи созданными вручную, либо, если создаются по расписанию, будут располагаться в поддиректориях hourly.0(1,2,3…), daily.0(1,2,3) и так далее.

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

Причем это даже выглядит несколько странно, на первый взгляд.
Допустим, что у вас есть том, размером 1TB, на котором лежит файл базы данных, размером 750GB. Для этого тома вы создаете снэпшоты каждый час по расписанию. Войдя в /.snapshot вы увидите в ней поддиректории /hourly.0, /hourly.1, и так далее, причем в каждой из них будет лежать «файл размером 750GB». При этом на собственно томе, емкостью 1TB, на котором как бы и лежат эти 24 (каждый час) копии базы по 750 гиг размером каждая, еще будет гигабайт 200 свободного места.
При этом любой из этих 24 «файлов» мы можем скопировать в резервную копию на внешнее хранилище, смонтировать как независимый read-only и использовать (читать) эти данные, как если бы это была реальная база данных, восстановить из нее данные, скопировав ее на место «активной», например в случае «все сломали, надо откатится на состояние час назад», и так далее.

Где же все это хранится?
Дело в том, что все эти «файлы», это просто ссылки на одни и те же блоки неизмененных данных. Место же на диске занимают только изменения, между снятыми снэпшотами. Допустим, что за сутки мы наменяли в этой базе блоков на 50 гигабайт. Тогда занятое место на дисках, в томе размером 1TB, на котором лежит файл базы на 750GB, и снэпшоты каждый час, будет 1TB — 750GB файл — 50GB изменений = 200GB свободно.
Если изменений за час между двумя снэпшотами (hourly.0 и hourly.1) получилось на 1% объема базы, то hourly.1 займет 7,5GB места на диске, указывая своими inodes на измененные, по сравнению с предыдущим снэпшотом, блоки. Все же остальные inodes по прежнему будут ссылаться на прежние, неизмененные блоки.

Чем удобно использование снэпшотов?
Простейший пример я уже привел. Допустим мы, или наши пользователи, «все сломали». Это может быть база данных, или же, допустим, экселевский файл, в котором, случайно, грохнули не те данные, успели записать, а потом обнаружили это, а восстановить надо срочно, «или нас всех убьют». Но мы знаем, что час (два, три, сутки, неделю, месяц назад, все зависит от частоты и регулярности снэпшотов) нужный нам файл был исправен.
Мы (это может сделать, кстати, даже сам пользователь) просто заходим в папку /.snapshots и вытаскиваем оттуда простым копированием нужный нам файл, на нужный момент времени, час, два, сутки, и так далее назад.
Либо, если у нас есть специальная лицензия SnapRestore, одной командой из консоли стораджа, «откатываем» состояние тома на нужный момент времени целиком (что удобно, если нужно восстановить не отдельный одиночный файл, а содержимое всего тома, в целом).

Таким образом, снэпшоты это, для пользователя, очень оперативная резервная копия, доступная тут же, на этом же сторадже. Кстати, в случае использования Windows XP или 7, вы будете видеть файлы в снэпшоте в панели «Previous versions» свойства файла или папки, NetApp интегрируется в этот механизм Windows как VSS-provider.

Теперь рассмотрим более сложный вариант. Допустим, мы эксплуатируем большую, ответственную, mission-critical SQL-базу данных предприятия.
Разумеется, каждый вечер, эта база данных бэкапится на ленту, для создания резервной копии.
База большая, и резервная копия копируется на ленту примерно час.
«Ничто не предвещало беды», но однажды, посреди рабочего дня, допустим в 3 часа дня, база необратимо портится.

Какие действия предпринимает сисадмин, для того, чтобы базу восстановить?
Мы считываем резервную копию по состоянию на конец прошлого рабочего дня (читаться она будет, допустим, столько же, сколько писалась — час), а затем нам следует «накатить» на нее redo-log-и, от момента создания бэкапа, вечером, и до момента, предшествующего сбою, то есть до 3 часов следующего дня. Этот «накат» часто довольно объемен, и также занимает какое-то время, ведь операции в SQL происходят не мгновенно. Допустим, через 30 минут, после окончания считывания бэкапа, база восстановлена в рабочем состоянии на момент предшествующий сбою, и мы готовы продолжать работу. Итого — 1:30.

В случае использования снэпшотов дела будут происходить следующим образом. У нас также делается ежедневная копия на ленту для обеспечения безопасности хранения, например на случай полного выхода из строя системы хранения, но у нас хранилище живо, повреждены только данные на нем. Мы знаем, что час назад база была жива и здорова. Мы восстанавливаем базу по состоянию на 2 часа дня, и так как снэпшот создается и восстанавливается практически мгновенно, то это занимает не час, а всего несколько секунд, и накатываем на нее redo-logs, но не со вчерашнего вечера, как в предыдущем случае, а всего за один час, с 2 часов, то есть момента создания снэпшота, до момента аварии, в 3 часа дня. Это занимает также не полчаса, а всего несколько минут.
Итог: спустя несколько минут, а не полтора часа, как обычно, наша база вновь в рабочем состоянии.

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

В чем же принципиальное отличие «настоящих снэпшотов» (Название Snapshots ™ для систем хранения это зарегистрированная торговая марка NetApp) от всех остальных, «контрафактных копий». 😉

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

Эта технология носит название Copy-on-Write (COW), и широко применяется в системах хранения других производителей, в их реализации снэпшотов.
Как вы видите из описания выше, даже само наличие включенного механизма снэпшотов для тома превращает одну операцию записи для системы хранения в три (чтение исходного содержимого, запись исходного содержимого на новое место, запись измененного содержимого на старое место).
Результат не заставляет себя ждать. Использование COW-snapshots резко ухудшает производительность системы хранения его использующего. Это разительный контраст с системами NetApp, в которых снэпшоты вообще никак не влияют на производительность, ведь никакого копирования при записи в них не происходит, все данные остаются на своих местах.
(демонстрация результатов производительности на тесте SPC-1)

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

Кроме этого, часто (по той же причине) общее количество снэпшотов на таких системах ограничено всего парой десятков максимум, отмечу, для контраста, что на системах NetApp можно использовать до 254 снэпшотов на каждый том, что, при общем количестве томов, допустимых систему, равного 500, достигает теоретического максимума в 127 тысяч.
Это позволяет, при использовании классической «ротации» резервных копий, хранить в 254 снэпшотах резервные копии данных тома до года включительно.

Также немаловажной является возможность создавать «по настоящему мгновенные» копии данных, причем независимо от размера «копируемых» данных. Хоть базу на 100MB, хоть на 100TB, снэпшот с нее будет всегда создан мгновенно. Например, мы можем создать «резервную копию» не «за час», а «за секунду», а затем, уже не нагружая нашей задачей реальную боевую базу, потихоньку копировать на резервное хранилище содержимое такого снэпшота.

Практика показывает, что люди, попробовавшие простоту и удобство использования снэпшотов, очень скоро уже просто не представляют себе жизни без них, считая это «само собой разумеющейся» возможностью любой системы хранения. Попробуйте и вы.
Напомню, что взять на тестирование систему хранения NetApp можно у любого партнера, список которых можно посмотреть на российской странице вебсайта NetApp.
www.netapp.com/ru/how-to-buy/resellers/distributor-ru.html
www.netapp.com/ru/how-to-buy/resellers/platinum-ru.html
www.netapp.com/ru/how-to-buy/resellers/gold-ru.html

PS: На традиционном «фото для привлечения внимания» в заголовке — задняя часть контроллера самой младшей модели NetApp — FAS2020. Самой младшей, но, тем не менее, обладающей всеми возможностями хранилищ NetApp, в том числе и работой со снэпшотами.
На фото, слева направо — два порта FC 4Gb/s, порт последовательной консоли, порт out-of-band микроконтроллера удаленного администрирования, и два порта Gigabit Ethernet.

PPS: А еще можно было бы написать на этой неделе про 5 место NetApp в Fortune’s list Best Plaсes to Work, вон Intel стррашно гордится аж 51-м местом (из ста), но мне показалось, что все эти радости пиар-отдела Хабру не очень интересны, поэтому упомяну об этом «бегущей строкой» в самом конце. Да, пятое место в сотне лучших работодателей США, и пятнадцатое (выше Google (30) и Apple (20), кстати) по списку сайта Glassdoor, оценивающего компании не «снаружи», как Fortune, а изнутри, анонимными голосами самих работников. «Пустячок, а приятно».

Как зарабатывать на активностях в новых блокчейн-сетях. Ретродропы и тестнеты

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

1. Что такое ретродропы и снепшот?
2. Откуда появилась мода на ретродропы? Почему проекты раздают токены?
3. Где находить ретродропы?
4. Как анализировать проект на возможный дроп?
5. Как участвовать в ретродропах? Какие действия необходимо совершать, чтобы увеличить шанс на его получение?
6. Риски
7. Выводы. Ретродропы — это выгодно?

1. Что такое ретродропы и снепшот?

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

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

Снэпшот — это моментальное фиксирование состояния кошельков владельцев токенов на определенном блоке в блокчейне. С помощью снэпшота можно определить, какие пользователи имеют право на получение бонуса, основываясь на определенных критериях, таких как длительность владения токенами, объем и количество транзакций. Отслеживаются все кошельки, принимающие участие в тестировании сети с помощью компаний ончейн-аудиторов (у Arbitrum, например, парнёрка с Nansen).

2. Откуда появилась мода на ретродропы? Почему проекты раздают токены?

Перед проектом до выхода на рынок стоят две задачи — привлечь средства и собрать пользовательскую базу. Как делали раньше? Проводили токенсейл. ICO, IDO, IEO и как их только не модифицировали, суть одна — это первичная продажа токенов проекта пользователям через вайтлисты и аллокации. Подробней об этом писали в нашем Telegram-канале.

Токенсейл позволяет и привлечь пользователей, и привлечь средства для развития проекта. Но тут на сцену выходит регулятор — SEC (Комиссия по ценным бумагам, США) и заявляет: и приватная, и публичная продажа токенов являются прямым свойством ценной бумаги. На этом момент следует немного отвлечься и чуть подробней остановится на регуляции, это важно как для получения дропов, так и в целом для любой деятельности в крипте.

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

На эту тему уже высказался Брайан Армстронг CEO Coinbase:

“До нас доходят слухи о том, что SEC хотела бы избавиться от криптостейкинга в США для розничных клиентов. Я надеюсь, что это не так, поскольку я считаю, что это был бы ужасный путь для США, если бы этому было позволено произойти.

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

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

Регулирование путем правоприменения не работает. Это поощряет компании работать в оффшорах, что и произошло с FTX”

Для определения, является ли токен ценной бумагой SEC (Комиссия по ценным бумагам США) использует тест Хоуи:

Тест Хоуи (Howey Test) – тест, разработанный Верховным судом США для определения, могут ли определённые транзакции быть квалифицированы как «инвестиционный контракт». Если тест даёт положительный результат, эти транзакции подпадают под требования закона «О ценных бумагах» от 1933 года и закона «Об обмене ценных бумаг» от 1934 года, считаются ценными бумагами и должны выполняться с соблюдением определённых требований к раскрытию информации и регистрации.

Согласно тесту Хоуи, токен является ценной бумагой, если:

1. Транзакции с ним совершаются с целью инвестирования денег.

2. Инвестиция в него делается в ожидании извлечения прибыли.

3. Инвестиция делается в совместное предприятие.

4. Любая прибыль является результатом деятельности лица, предлагающего контракт, или третьего лица.

Любой стейкинг подходит как минимум под 4 пункт. Прибыль от него — это результат совершения и обработки транзакций третьими лицами. Поэтому потенциально у всех блокчейнов, предоставляющих стейкинг будут проблемы. По моему мнению, именно проекты с алгоритмом консенсуса Proof-of-Stake смогут доказать SEC, что стейкинг — это неотъемлемая часть их блокчейна, обеспечивающая децентрализацию. В процессе разбора технологии, регулятор может с этим согласиться. Тут надо рассматривать каждую ситуацию отдельно, но в любом случае, понимать, что крипта рано или поздно будет зарегулирована, и согласитесь, вам станет обидно за то, что потратили год на участие в возможном ретродропе, а проект прикрыл SEC и его токен так и не выйдет. Поэтому всегда стоит следить за развитием законодательной базы, риторикой регуляторов и выходом новых законов.

Помимо стейкинга и проведения любых приватных (Private Sale) и публичных сейлов (IDO, ICO, IEO) красной тряпкой для SEC могут стать различные механизмы сжигания монет. Со сжиганием тоже интересная история. Проект “что-то там” делает со свои токеном (сжигает), и его цена из-за этого увеличивается. Согласитесь, для регулятора это странно. В чем механизм? Вы просто берете и по своему желанию уменьшаете эмиссию? Это обеспечивает дефляционную модель поведения ценности, но является ли неотъемлемой частью технологии? На эти вопросы нам ответит SEC, CFTC или европейские регуляторы, которые в течении этого года будет представят миру законопроект MiCa (Markets in Crypto Assets — Регламент ЕС по регулированию рынка криптоактивов). Кстати, после его выхода многие неразрешенные в правовом поле вопросы, связанные не только с криптой, но и с другими областями блокчейн отрасли, будут решены.

Но пока четкой регуляции нет, что криптопроекты стараются делать все аккуратно, чтобы избежать юридических рисков в будушем. Вспомните ситуацию с Дуровым, Tornado Cash и другие. В случае проигранных регулятору разбирательств, на проект повесят огромные штрафы или вовсе запретят деятельность на территории штатов. Здесь для будущей аналитики делаем пометочку, что проекты, имеющие огромный оборот и запас кэша (тот же Binance), смогут эти штрафы оплатить, а для проектов, капитализация которых, условно, $500 млн., штрафы в $300-$400 млн. могут стать похоронными.

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

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

3. Где находить ретродропы?

Если вы находитесь внутри инфополя, мониторите новости крипторынка, подписаны на адекватные Telegram-каналы, то будете всегда в курсе новых дропов. Крупные проекты в том или ином виде в криптосообществе всегда обсуждаются заранее. Если же вы хотите знать о дропах раньше нас, что тоже вполне реально), то необходимо следить за twitter-аккаунтами топовых проектов (да-да, именно он является основным местом для анонсов в крипте), представителей блокчейн-индустрии (я сейчас имею в виду не простых инфлюенсеров, а активных действующих участников рынка. Тот же Виталик Бутерин очень много рассказывал о Layer 2 проектах, которые сейчас и выживают с рынка недавних «Убийц Эфириума» Solana, Aptos и NEAR), крупных бирж (это анонсы листингов и партнерств), официальных криптовых СМИ и дегенов (на ваш вкус и цвет).

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

Но найти проект мало. Его нужно как следует проанализировать (отресерчить) и понять, есть ли у него потенциал к дропу. Про комплексный ресерч проектов мы рассказывали тут, ну а сейчас сконцентрируемся на том, как его оценить именно в разрезе получения сочного ретродропа.

4. Как анализировать проект на возможный дроп?

В первую очередь, смотря на список отобранных вами проектов, задайте себе вопросы:

Что это за проект? Что он из себя представляет? Актуален ли для него тестнет?

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

Технология

Определите перспективы технологии, заложенной в проект. Если это очередной аналог аналогов, запуск которого форсят на хайпе, пусть и с хорошим шансом на ретродроп, лучше его обойти стороной. Технология должна быть применима в блокчейн пространстве и полезна экосистеме и, как следствие, пользователям. Например, те же оптимизационные решения для Эфириума (zk и optimistic rollup) или кроссчейн-решения.

Деньги

Один из важнейших этапов анализа проекта на возможный успешный эйрдроп — это наличие на него средств. Стоп. Каких средств? Ведь проект просто насыпает нам токенов, которые ничего не стоят! — скажите вы. И будете правы, до листинга они ничего не стоят. Но. Что происходит с выданными дропхантерам (охотникам за дропами, нам с вами) токенами? Правильно. Их продают. Тестеры поучаствовали, потратили силы, деньги на комиссии, они хотят получить профит. Поэтому большая часть пользователей, получивших дроп, продаёт токены сразу на листинге. И этих токенов немало (Arbitrum, например, раздал 11% эмиссии). Логично, что цена при этом идет вниз. Как раз здесь и понадобятся личные свободные средства проекта, чтобы все это дело откупить. В противном случае может получится так:

Вы классно поучаствовали в тестировании, получили свою тысячу токенов, ждете листинга для продажи, листинг начинается, вы выставляете токены на продажу и…ничего не происходит, ведь стакан ордеров на покупку пуст �� обновляете страницу, а цена токена уже $0.000001 (или меньше).

Что касается суммы инвестиций, которые должен получить проект, чтобы взять хорошего маркет-мейкера и иметь капитал для откупа, это дело субъективное. Все зависит от кол-ва пользователей проекта, их лояльности и будущей перспективы токена (я лично знаю тестеров, которые до сих пор держат свои ARB в пулах ликвидности и не продают). Но чисто вам для аналитики — Arbitrum привлек на всех этапах чуть менее $200 млн. И у них хватило сил откупить такой мощный слив (напомню, в ARB раздали около $1 млрд.). Субъективно, инвестиции более, чем $200 млн. можно считать зеленым флажком при анализе проекта на потенциальный ретродроп.

5. Как участвовать в ретродропах? Какие действия необходимо совершать, чтобы увеличить шанс на его получение?

Мы рассмотрим все активности. Если проект — это блокчейн сеть, то есть возможность выполнять все действия, указанные ниже, если же это DeFi-сервис, то уже конкретные действия для него. Глобально, вознаграждения начисляются за любое взаимодействие со смарт-контрактами:

Мосты. Через них оборачиваете токены в сеть проекта.

Предоставление ликвидности. Предоставляете свои средства в пулы ликвидности в новой сети.

DEX и лендинг протоколы. Там можно поторговать токенами в новой сети. Чем больше объем наторгуете, тем лучше.

NFT-маркетплейсы. Можно заминтить бесплатных NFT или что-то даже прикупить.

Как увеличить свой шанс на получение дропа?

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

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

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

Объем транзакций. Это тоже очень важный момент. Arbitrum сделал планки (о которых, конечно, заранее не было известно) — $10k, $50k, $250k. Не пугайтесь, это общая сумма транзакций. Вы можете перегонять туда-сюда и $100, благо комиссии в новых проектах мизерные. Кошельки с балансами меньше 0,005 ETH также отсекаются.

Но как делать много аккаунтов, если у меня бюджет всего $100? Если я буду перекидывать их с кошелька на кошелек, то СБ проекта это обнаружит и забанит все акки.

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

Решение. Субаккаунты на биржах. Такие есть и на Binance. Вы завели средства на биржу — все, они внутри. Дальше перекидываете их на субаккаунт и выводите на другой кошелек. Хоть вы и пополняете с одного биржевого аккаунта, в блокчейне это выглядит как-будто вы пополняете каждый такой кошелек с разных (и они не взаимосвязаны).

6. Риски

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

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

Также базовым риском остается то, что проект может закрыться, простыми словами — соскамиться. Единицей измерения страхования данного риска является глубина вашего анализа проекта, с котором участвуете. Если в него инвестировали топовые фонды, вроде a16z или Sequoia Capital, сотни млн. долларов, то вряд ли фаундерам позволят просто так взять и исчезнуть. После кейсов с Terra Luna и FTX регуляция станет гораздо жестче. Об этом говорит и предложение Байдена, поддержанное Главой SEC Гэрри Гэнслером о том, что на борьбу с криптовалютами необходимо выделить $2,4 млрд. И да, не стоит переживать по поводу таких формулировок, они созданы, чтобы нас запугать, фактически, эти деньги будут использоваться для создания законодательной базы и общей регулирующей экосистемы. В планах у SEC нанять 170 новых сотрудников в отделы правоприменения и экспертизы. Гэри Генслер считает, что это необходимо для пресечения «неправомерных действий» в криптовалютной индустрии.

7. Выводы. Ретродропы — стоит на это тратить время?

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

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

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

У меня лично есть знакомые, которым удалось сделать с дропа ARB $50k и выше. И это не эфириум киты. Это обычные ребята. Айтишники со набором самых базовых знаний. По моему, опять же субъективному, мнению доходность в $50k на дистанции в год, два, а для кого-то даже в 5 — это хорошие цифры. Тем, кто только входит в крипту, лучше начать с чего-то другого и участвовать в дропах на первых парах с одного основного аккаунта, набивать руку, как раз поучиться пользоваться кошельками, мостами, лендинговыми протоколами и другими инструментами. А уже после — задумываться о проф. дропхантинге.

Мы составили подборку проектов, которые могут насыпать достаточно щедрые реварды, и положили её в своем Telegram-канале. Если вам интересна тем дроп хантинга — пользуйтесь!

Спасибо за прочтение!

• тестнет
• тестирование приложений
• тестирование
• криптовалюты
• криптография
• layer2

Snapshot: что это? Голосование на блокчейне с использованием криптовалюты

Snapshot — это инструмент для голосования, основанный на децентрализованной системе хранения IPFS, который используется многими криптопроектами для опроса своих пользовательских баз.

Услуги / Товары:
Голосование на блокчейне при помощи криптовалюты

Snapshot — это инструмент для голосования, основанный на децентрализованной системе хранения IPFS, который используется многими криптопроектами для опроса своих пользовательских баз.

• Snapshot — это децентрализованная система голосования.
• Его используют несколько компаний в сфере DeFi, чтобы помочь опросить пользователей.
• В проекте используются методы подписи вне сети, чтобы снизить плату за голосование.

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

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

Что такое Snapshot?

Snapshot — это место, где проекты могут создавать предложения для голосования с использованием криптовалюты. В отрасли этот процесс называется «сигнализация голосования».

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

Но в Snapshot этого не происходит благодаря грамотному использованию децентрализованной сети хранения под названием IPFS.

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

На Snapshot размещено более 1000 проектных предложений.

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

Как пользоваться Snapshot?

Компаниям, желающим использовать Snapshot, необходимо иметь существующий профиль в Ethereal Naming Service или ENS. Получив его, они добавляют запись в ENS, чтобы голоса можно было просматривать по этому адресу.

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

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

Что делает Snapshot особенным?

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

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

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

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

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

Краткая история Snapshot

Snapshot Labs, создатели Snapshot, вышли из скрытого режима разработки в августе 2020 года.

В настоящее время не так много информации о том, кто стоит за Snapshot, но, судя по различным форумам, он появился из Balancer Labs, отдела исследований и разработок автоматического менеджера портфелей и торговой платформы Balancer.

Кто пользуется Snapshot?

В сфере децентрализованных финансов (DeFi) существует множество компаний, которые воспользовались преимуществами уникальной системы опроса Snapshot. К ним относятся:

• Uniswap
• Balancer
• Yearn
• Bancor
• The Graph
• Aragon
• и другие.

Что можно делать с Snapshot?

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

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

В другом опросе они спрашивали пользователей, что им делать со своими средствами.

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

Хотите самым первым получать уникальную и важную информацию?
Добавляйте нас в закладки!
Подписывайтесь на наши проекты!

Снапшоты в Kubernetes: что это и как ими пользоваться

С появлением snapshot-controller в Kubernetes появилась возможность создавать снапшоты для совместимых с ними CSI-драйверов и облачных провайдеров.

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

Введение

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

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

Для того, чтобы возможность создания снапшотов заработала, в Kubernetes-кластере должен быть установлен snapshot-controller (общий компонент для всех CSI-драйверов), а также соответствующие CRD:

• VolumeSnapshotClass – аналог StorageClass для снапшотов;
• VolumeSnapshotContent – аналог PV для снапшотов;
• VolumeSnapshot – аналог PVC для снапшотов.

Помимо этого, наш CSI-драйвер должен иметь соответствующий контроллер csi-snapshotter и поддерживать создание снапшотов.

Как работают снапшоты в Kuberbetes?

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

При создании снапшота VolumeSnapshot необходимо указать PersistentVolumeClaim , для которого этот снапшот будет создаваться.

Когда CSI-драйвер успешно выполняет процедуру создания снапшота, он создаёт в кластере ресурс, который называется VolumeSnapshotContent и указывает данные созданного снапшота в нём (как правило, его ID).

После этого, как в случае с PV и PVC , происходит процедура Bound, когда snapshot-controller связывает наш VolumeSnapshot с VolumeSnapshotContent .

При создании нового PersistentVolume можно указать созданный VolumeSnapshot в dataSource , и тогда в нём появятся данные из нашего снапшота.

Конфигурация

Параметры для создания снапшотов описываются в VolumeSnashotClass . Туда передается имя CSI-драйвера и дополнительные параметры в зависимости от вашей СХД и облачного провайдера. Приведу несколько примеров:

После того, как создан VolumeSnapshotClass , можно приступать к использованию снапшотов. Рассмотрим несколько кейсов.

Кейс 1: Темплейты PVC

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

• быстрое создание development-окружений с данными;
• эффективная обработка данных сразу несколькими Pod’ами на разных узлах.

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

--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-worker1 spec: storageClassName: linstor-ssd-lvmthin-r2 dataSource: name: pvc-template kind: PersistentVolumeClaim accessModes: - ReadWriteOnce resources: requests: storage: 10Gi

Все примеры манифестов можно найти в репозитории.

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

Кейс 2: Снапшоты для тестирования

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

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

Когда всё протестировано, можем выкатывать в production. Но на всякий случай сначала создадим снапшот mypvc-before-upgrade , чтобы всегда была возможность вернуться к состоянию до обновления. Снапшоты создаются с помощью сущности VolumeSnapshots , где просто указывается PVC, для которого будем делать снапшот:

apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: mypvc-before-upgrade spec: volumeSnapshotClassName: linstor source: persistentVolumeClaimName: mypvc

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

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mypvc spec: storageClassName: linstor-ssd-lvmthin-r2 dataSource: name: mypvc-before-upgrade kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 10Gi

Кейс 3: Снапшоты для консистентного бэкапа

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

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

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

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

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

--- kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1 metadata: name: linstor-minio driver: linstor.csi.linbit.com deletionPolicy: Retain parameters: snap.linstor.csi.linbit.com/type: S3 snap.linstor.csi.linbit.com/remote-name: minio snap.linstor.csi.linbit.com/allow-incremental: "false" snap.linstor.csi.linbit.com/s3-bucket: foo snap.linstor.csi.linbit.com/s3-endpoint: XX.XXX.XX.XXX.nip.io snap.linstor.csi.linbit.com/s3-signing-region: minio snap.linstor.csi.linbit.com/s3-use-path-style: "true" csi.storage.k8s.io/snapshotter-secret-name: linstor-minio csi.storage.k8s.io/snapshotter-secret-namespace: minio --- kind: Secret apiVersion: v1 metadata: name: linstor-minio namespace: minio immutable: true type: linstor.csi.linbit.com/s3-credentials.v1 stringData: access-key: minio secret-key: minio123

Теперь при создании снапшота он будет отправлен на удалённый S3-сервер:

--- apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: mydb-backup1 spec: volumeSnapshotClassName: linstor-minio source: persistentVolumeClaimName: db-data

Что примечательно, восстановить мы его можем даже в другом Kubernetes-кластере. Но для этого, помимо VolumeSnapshotClass , понадобится определить еще VolumeSnapshotContent и VolumeSnapshot для снапшота:

--- apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshotContent metadata: name: example-backup-from-s3 spec: deletionPolicy: Delete driver: linstor.csi.linbit.com source: snapshotHandle: snapshot-0a829b3f-9e4a-4c4e-849b-2a22c4a3449a volumeSnapshotClassName: linstor-minio volumeSnapshotRef: apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot name: example-backup-from-s3 namespace: new-cluster --- apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: example-backup-from-s3 spec: source: volumeSnapshotContentName: example-backup-from-s3 volumeSnapshotClassName: linstor-minio

При создании VolumeSnapshotContent нам необходимо указать ID снапшота в системе хранения, передав его в параметре snapshotHandle .

Теперь можно создать новый PVC из бэкапа:

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: restored-data namespace: new-cluster spec: storageClassName: linstor-ssd-lvmthin-r2 dataSource: name: example-backup-from-s3 kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 10Gi

Модуль снапшотов в Deckhouse

Недавно мы внедрили модуль снапшотов для совместимых CSI-драйверов в нашу Kubernetes-платформу Deckhouse. Начиная с релиза v1.33 он включается автоматически для всех поддерживаемых облачных провайдеров и систем хранения, не требуя настройки.

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

Заключение

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

Спасибо за внимание — надеюсь, со снапшотами ваша жизнь станет проще и лучше! 🙂

Читайте также в нашем блоге:

• «В Kubernetes-платформе Deckhouse v1.32 появились модули ceph-csi и snapshot-controller»;
• «Наш опыт разработки CSI-драйвера в Kubernetes для Яндекс.Облака»;
• «Плагины томов для хранилищ в Kubernetes: от Flexvolume к CSI».