Solana 101

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

Почему солана падает

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

Архитектура соланы и пох

Архитектура соланы есть измененный PoS с добавлением времени. Работает следующим образом:

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

У этой системы есть свои проблемы:

Лидер может упасть, тем самым затормозив весь бч
Лидера могут подудосить, а значит вот пинг в 60 сек + и высокое количество недолетевших транз
Раз ты лидер, ты можешь менять порядок транз в блоках (пусть и в течение малого количества блоков (о чем особо никто не говорит)) то есть mev возможен, если вы держите много валидаторов

Эллиптическая кривая

Чтобы быстренько вспомнить/понять что такое ecdsa в общем, вот https://teletype.in/@ortomich/ECDSA_fast

У соланы же она немного отличается и называется ed25519 и выглядит следующим образом и находится она в поле 2^255-19.

Но в итоге выглядит она вот так, ведь работаем мы в целых числах (размеры гораздо больше и точек в разы больше, но это для примера)

Этот вид эллиптической кривой называется видом Монтгомери.

Что такое PDA

Program derived address - Это такие публичные адреса в сети Солана, которые не лежат на эллиптической кривой (Все эти белые места на картинке сверху). Из-за того, что они не лежат на кривой, у них нет приватника, их не получить таким образом.

Генериуется они следующим образом:

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

Зачем они нужны

В солане перевод токенов идет с токен аккаунта на другой токен аккаунта. Они хранят конкретный токен и связаны с основным аккаунтом. При этом все они отдельные публичные ключи, являющиеся pda. Просто у них есть определенная формула генерирования.
[walletAddress.toBuffer(), TOKEN_PROGRAM_ID.toBuffer(), tokenMintAddress.toBuffer()], SPL_ASSOCIATED_TOKEN_ACCOUNT_PROGRAM_ID При этом spl_ssociated_token_account и token_program_id это солановские смарт контракты. А walletAddress есть адрес пользователя, которому создается новый ассосиэйтед, а tokenMintAddress есть сам минт токена.
Для работы в смарт контрактах очень удобно использовать pda, хранящие информацию. Почему? Тебе не нужно мапить данные, хранить на беке, когда ты каждый раз из имеющихся данных можешь сгенерировать новые паблик кей и они всегда будут одинаковые под одинаковые данные и при этом разные для разных (опустим вариант коллизий).

Что такое смарт контракт на солане

Для тех, кто работал с эфиром, очень привычна следующая картина:

Есть куча функций и эвенты и все видно в etherscan.
Куча геттеров (view функций а-ля read в etherscan с помощью которых ты узнаешь разные значения).
Куча openZeppelin и подобных стандартов.
Контракт хранит кучу инфы - маппинги, маппинги маппингов, переменные, массивы.
Можешь подавать кучу данных.
Функции контракта оч похожи на функции в обычном программировании.

У соланы все немного по другому

Эвентов нету (есть подобие эвентов от AnchorLang, но ни у меня, ни у тех с кем я общался, они не отрабатывали нормально). В сол скане контракты не верифицированные.
Поэтому в солскане нет геттеров, не получишь ты стейты по любым адресам, все через сайт проекта.
Нету стандартов, всю реализацию ft и nft берет на себя сама солана, а ты добавляй ей проверок и все будет хорошо.
Контракт не хранит информацию, кроме констант и функций. По сути контракт есть бинарник, iso, который просто тыкают транзакции, пихают ему аккаунты и данные, а он их обрабатывает.
Не можешь подавать кучу данных и есть ограничения по "газу". Во первых у тебя каждая транзакция ограничена 1232 байта, дальше как хочешь. В них нужно поместить аккаунты ( адреса на солане) и данные. Во вторвых есть ограничения по размеру самих вычислений (200к computational units), благо сейчас можно увеличить размер, доплатив коммиссии.
Функции контракта есть смесь: Н-ное количество подаваемых аккаунтов, у каждого из которых своя цель.

Есть те, кто подписывают транзакцию и платят комиссии
Есть те, которые создаются и либо становятся токен аккаунтами или чем-нибудь еще, либо заполняются информацией для вычислений (да, вся информация по каждому юзеру хранится на других аккаунтах)
Есть необходимые аккаунты, по сути являющимися адресами других програм: token_program_id- для проведения транзакций токена, system_program - для проведения транзакций соланой, rent - для создания аккаунтов, associated_token_account - для создания ассосиэйтед аккаунтов, именно их инициализации.

Некоторые фишки Соланы

В солане, как и в эфире, есть апрув, при этом апрув в солане позволяет сделать некоторые вещи над аккаунтами
Ты можешь поменять authority над чужим аккаунтом, если у тебя есть апрув. Что это значит: Есть Вася, у Васи есть нфт и лежит она на ассосиэйтед токен аккаунте (формула генерации была сверху). Он запускает транзу с твоим контрактом, а ты под шумок берешь апрув у него и берешь владение над его аккаунтом. (эх, сладкое время было раньше, когда фантом не показывал даже апрув). Владение, по сути, дает тебе право использовать его аккаунт. Он останется быть ассосиэйтед к тому же минту, но уже ты являешься его по сути владельцем. Но так как адрес его не меняется, то если на аккаунте было 0 и кто-то решил отправить человеку, и не проверять authority на адресе, то нфт или токены получаешь ты) и сразу выводишь себе.
А также, кроме setAuthority, есть еще функция freezeAuthority. Она позволяет заморозить токен аккаунт. Зачем это надо? Например если хочешь оставить нфт на аккаунте у юзера, ведь тогда он остается authority (что есть хорошо для дискорда), при этом она никуда не отправляется (что хорошо для дискорда), при этом при всем юзер ничего с ней сделать не может (даже дважды застейкать или что-то подобное, ведь будет ошибка already frozen).
При этом, если вам нужно, вы можете выпендриться, и создать не associated, а взять приватник, и сделать его своим tokenAccount. Зачем ? это уже другой вопрос.
Так как смарты в солане по сути своей бинарники, их можно сколько угодно обновлять и стоить это будет недорого. Самое дорогое "обновление" вначале и ты заранее бронируешь размер контракта (Если не указываешь, то берется х2 от размера программы в моменте) и платишь в соланах. Зачем? Потому что программа может расширяться, а размер не бесконечен.

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

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

Что такое рент и почему все стоит деняк

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

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