Когда в Solana появились confidential transfers в Token-2022, стало возможным прятать балансы и суммы. Но пользоваться этим сложно: доступен только EOA-кошелёк, нет DeFi и UX'а нет для обычного юзера(кошельки не поддерживают, баги есть, нахрен надо?).

Про это уже писалось в отдельной статье: https://teletype.in/@valpaq/confidential_balances

Arcium — вторая половина истории: Solana остаётся быстрым L1, рядом вешается зашифрованный «процессор», который считает над зашифрованными данными и отдает результат обратно обычным программам.

Что такое Arcium

• Solana отвечает за:
• очередь задач (ончейн-мемпул вычислений),
• оплату, стейкинг, слэшинг,
• вызовы из программ и обратно.
• Arcium - это сеть Arx нод:
• получают зашифрованные входы,
• внутри MPC-кластера считают функцию (добавляют рандом и подобное),
• шлют результат обратно в Солану (через Arcium Program или ваш callback-сервер).
• MXE (Multi-Party Execution Environment) - контейнер под конкретное приложение:
• ваша Solana-программа,
• набор «конфиденциальных инструкций»,
• метаданные, какой MPC-кластер использовать и т.п.
• Arcis - слой над Anchor для написания конфиденциальных инструкций.
• arcium CLI - обертка над Anchor,
• TS-клиент, который шифрует данные на устройстве и отправляет в MXE.

В программе на Solana появляется вызов условной [confidential]-функции. Она не считает сама: собирает описание вычисления и кидает его в Arcium Program. Тот кладёт задачу в ончейн-мемпул, выбирает свободный MPC-кластер и через callback возвращает результат.

Cerberus и Manticore: два режима MPC

У Arcium два MPC-протокола: Cerberus и Manticore.

Cerberus - permissionless

• Модель безопасности.
  Dishonest majority / N-1 honest - достаточно, чтобы хотя бы одна нода в кластере была честной.
• Без trusted dealer’а.
  Нет единого генератора секретов, в которого надо верить; все распределяется протоколом.
• MAC-проверки.
  Каждая часть секрета обвешана MAC’ами; как только кто-то начинает подсовывать левое значение, вычисление останавливается, ноду можно выкинуть из кластера.
• Арифметика в шифртекстах.
  Сложение/умножение над зашифрованными данными делается без дешифровки.

Кейсы: приватные ордера, предикшн-маркеты, конфиденциальные балансы.

Manticore - permissioned

• Модель.
  Honest-but-curious / honest majority - участники следуют протоколу, но могут пытаться вытащить лишнюю инфу из своих шеров.
• Trusted dealer.
  Есть отдельный участник, который готовит криптографические материалы (preprocessing, секреты и т.п.). Это ускоряет протокол, но требует доверия к сетапу.
• Заточен под ML.
  Исходный ресерч по Manticore - как раз про эффективный MPC для вещественной и булевой арифметики (ML/AI, аналитика, матрицы и прочая беда).

Как это выглядит для разработчика

Жизненный цикл вычислений

1. Definition.
   В Arcis описываешь computation: какие аргументы, какая функция, какой кластер.
2. Commissioning.
   Solana-программа дёргает этот definition с конкретными аргументами и окном по времени.
3. Mempool.
   Задача падает в ончейн-мемпул Arcium Program.
4. Execution.
   Кластер Arx-нод забирает задачу, крутит Cerberus/Manticore, на выходе - зашифрованный результат.
5. Callback.
   Результат заворачивается в callback-транзу (или в ваш HTTP-callback, если не влезает) и прилетает обратно в программу на Солане.

Весь MPC живёт в сети Arx-нод. Солана видит только описание вычисления, факт исполнения и кусок данных. Дальше уже сами решаете, что с этим делать.

DSL/Arcis

Arcis — язык под схемы, которые крутятся на Arcium. Рамки жёсткие:

• в Cerberus/Manticore вы не залезете - протоколы спрятаны под капот.
• топологию кластера вы не настроите, только выберете, куда слать (и то летом ни о какой Manticore речи не было).
• с отдельными нодами не пообщаетесь, всё идёт через Arcium Program / клиент.
• Все детерминированно заранее, никаких циклов от размера массива и т.д.

Это не «соберу свой MPC», а «описал функцию - Arcium посчитал и отдал результат, взамен сказал ему спасибо(заплатил монету)».

Технические ограничения

• Размер выхода.
  Результат одной конфиденциальной инструкции должен влезать в одну Solana-транзу (callback). Если нет - нужно поднимать свой HTTP-callback-сервер, принимать весь остаток там и самому уже управлять результатом.
• Асинхронность.
  Вычисление живет отдельно от Solana-транзакции по времени. Есть valid_after / valid_before окна; если не успели - задача протухла.

• Сетевой слой от вас независим.
  Вы не управляете тем, какой конкретно узел считает вашу задачу; это переключаемые кластеры, какой именно узел считает - не контролируете.

• Mainnet.
  Еще нет, этой весной обещали в q4/2025, возможно q1/2026.

Arcium SPL

Ранее мы уже смотрели на Token-2022 SPL CT:

• twisted ElGamal поверх публичного ключа
• range/validity/equality ZK-пруфы
• разделение pending/available
• опциональный аудитор, AES-баланс

Arcium Confidential SPL Token (C-SPL) - надстройка над этим всем. Задуман как единый слой поверх разных стандартов токенов.

1. Программная работа с конфиденциальными аккаунтами.
   Token-2022 CT разрешает владеть конфиденциальным балансом только EOA-кошелькам, что убивает DeFi - программы не могут работать с зашифрованными балансами.
   C-SPL добавляет адаптер, который через Arcium позволяет программам владеть и двигать эти балансы внутри MPC, не открывая их.
2. Аккаунты за других людей.
   В CT получатель должен заранее завести конфиденциальный аккаунт для каждого минта. В C-SPL есть Confidential ATA-програм, которая через Arcium создает временный защищенный аккаунт на получателя, а он потом его «забирает» и подшивает свои ключи. UX похож на обычный SPL~.
3. Канонические конфиденциальные обертки.
   Через token-wrap можно сделать единый C-SPL-mint для любого обычного SPL-токена и дать исходному минту роль аудитора.
4. Отдельный Encrypted SPL Token.
   Для программных (не EOA) use-case’ов они делают отдельный, более легкий стандарт, заточенный под Cerberus и прямое вычисление над ciphertext’ами в MPC.

Umbra: приватный слой поверх Arcium

У Umbra вся архитектура делится на три крупных блока:

• Umbra Addresses - «stealth-адреса» на Solana;
• Anonymity Layer (shielded pool) - слой, который рвёт линк депозит ↔ вывод;
• Encrypted Balances - хранение балансов как ciphertext’ов в PDA + MPC-обновления.

Umbra Addresses

Umbra Address - это обычный Ed25519-ключ, ничем не отличимый от стандартного адреса Solana. Важен не формат, а процесс генерации:

• берётся подпись статического сообщения основным кошельком;
• эта подпись идёт в PRF, из неё детерминированно вываливается последовательность сидов;
• по каждому сиду генерится отдельный Ed25519-keypair - это и есть Umbra-адрес (как в SPL-CT, только шире).

Свойства: легко восстановить, сложно привязать к автору и друг к другу.

На уровне протокола Umbra отделяет «публичные» балансы на этих адресах от приватных, живущих внутри shielded pool.

Anonymity Layer: shielded-пул с ZK-claim’ами и релейерами

• Shielded Pool.
  Контракт, который держит кучу токенов разных пользователей; приватность одной транзы зависит от размера множества депозитов.
• Deposit.
  Ты кладёшь токены в пул, а данные (сумма, целевой Umbra-адрес и т.п.) зашиваются в commitment / «записку», которая попадает в общий список.
• Claim.
  Получатель доказывает через ZK-пруф, что он владеет одной из этих записок, не раскрывая какой именно. Контракт проверяет proof, смотрит, не был ли nullifier уже потрачен, и выдаёт токены Umbra-адресу получателя.
• Relayer Network.
  Чтобы не светить, кто платит газ и с какого адреса идёт claim, используется сеть релейеров: они платят комиссию и получают компенсацию из выводимой суммы.

Encrypted Balances: PDAs + X25519 + Rescue + MPC

Umbra хранит приватные балансы как ciphertext в PDA на Solana, а все обновления делает через Arcium.

Две пары ключей на кошелёк:

• Ed25519 - обычный spending key, подписывает транзы;
• X25519 - encryption key, по нему считается ECDH с MPC-сетью, от него зависят PDA.

Структура on-chain:

• PDA-аккаунт пользователя;
• PDA под каждый токен: внутри (ciphertext, nonce), где
• ciphertext - зашифрованный баланс через Rescue cipher;
• nonce - уникальная «соль» на каждое обновление.

Дешифровка:

• кошелёк дёргает PDA, вытаскивает (ciphertext, nonce);
• делает ECDH(X25519_user, PK_MPC) → shared secret;
• из секрета + nonce инициализирует Rescue и расшифровывает баланс - всё локально на девайсе.

Обновление баланса:

• кошелёк шлёт в MPC-кластер инструкцию +10 USDC в зашифрованном виде;
• MPC-ноды подтягивают текущий ciphertext из PDA, делают гомоморфное обновление над шифртекстом, генерят новый ciphertext + nonce, пишут обратно.
• При этом никто из нод не видит ни старого, ни нового баланса, ни дельту.

Stealf

Stealf - нео-банк на стейблкоинах, у которого два уровня кошелька: публичный и приватный.

Публичный:

• KYC;
• карта;
• SEPA;
• полностью прозрачный трейс - всё как в обычном банке.

Приватный:

• Arcium-движок;
• полностью шифрованные балансы;
• анонимные P2P-переводы без KYC.

Технически:

• двойная архитектура кошелька: один слой под «официальный» флоу, второй - под крипто-приватность;
• Arcium + PDAs: приватный кошелёк использует PDA как прокси-адреса, реальные суммы хранятся в зашифрованном виде и обновляются через MPC;
• relayers: чтобы не светить реальные адреса/суммы, транзы подписывают и отправляют релейеры, а сумма на цепочке показывается минимальной, реальная зашита в данных транзы, уходит в MPC и там уже добавляется к балансу.

Melee: viral prediction markets

Melee - «viral prediction markets» на Solana: смесь Pump.fun и Polymarket.

• Любой крейтор может завести рынок про что угодно: выборы, мемы, монеты, поп-культуру;
• Нет отдельной касты «админов, которые решают, какие рынки можно»;
• Прайсинг поверх бондинг-кривой: ранние заходы награждаются сильнее - классическая «зашёл первым, оказался прав - забрал львиную долю».

Флоу:

• Создание рынка.
  On-chain маркет создаётся permissionless, параметры и ставки видны всем.
• Разрешение исхода.
  Вместо одного централизованного оракула или DAO, который руками резолвит рынок, собирается кворум валидаторов/участников. Они голосуют зашифрованно через Arcium, голоса не видны до конца периода, нет эффекта «подстроиться под большинство».
• MPC-резолв.
  Arcium считает итоги и проверяет, кто голосовал против факта; неправильно проголосовавших можно слэшить. Результат (какой исход победил) возвращается на Solana, и уже там идёт обычный расчёт по рынку.

Другие направления поверх Arcium

Кроме Umbra / Stealf / Melee там уже намечается зоопарк:

• Encrypted DeFi / даркпулы.
  Orca и co смотрят в сторону рынков, где объёмы, цены и контрагенты уходят в MPC, а на цепи остаётся только сетлмент и минимум метаданных.
• Платежи и кастоди.
  Squads, Sphere, Iron и подобные - конфиденциальные мультисиги/трезори, лимиты и балансы которых не торчат в эксплорере, плюс MPC-key-менеджмент.
• AI / аналитика.
  Nosana, CrunchDAO и прочие AI-ребята - совместный тренинг/инференс по шифрованным данным, когда каждый боится показывать датасет соседу.

В Colosseum сейчас реально каждый второй питч - «мы делаем X, но поверх Arcium».

Ограничения

Латентность.

Помимо самой Solana добавляются:

• очередь в мемпуле Arcium;
• несколько раундов MPC;
• callback-транза назад.

Для кошелька/разового перевода ок. Для чего-то, что должно реагировать быстро, задержка уже заметна. На летнем тестнете между «отправил» и «получил результат» у меня было примерно 7 блоков. Их dark pool demo при этом не работал с балансами и ценой - просто кидал и мэтчил ордера с бидами/асками (и не было очереди из других протоколов).

Размер результата.

Выход одной encrypted-инструкции должен помещаться в одну транзу. Всё, что выше - поднимаешь HTTP-callback, принимаешь хвост там, проверяешь хеш на цепи и сам раскладываешь по стейту.

Кластеры и доверие.

Cerberus на бумаге живёт в модели N-1 honest. На практике всё упрётся в то, кто именно крутит Arx-ноды и как у них устроен стейкинг/слэшинг.
Manticore честно говорит «есть trusted dealer» - это история для permissioned-сетапов, а не для любого контракта на Solana.

Стадия сети.

Mainnet Alpha только выкатывают, часть нод под командой и «индустриальными» валидаторами, "множество"(тоже encrypted, я их не видел) проектов в закрытых когортах еще с весны. Янник при общении рассказывает многое (вплоть до почти атомарных флоу в одну транзу (и encrypted everything)), но пока это планы.

Еще давно в солане появился Token 2022 - стандарт spl токена, с расширяемой логикой(extensions). Там есть такие же функции на передачу, минт, заморозку, разморозку, сжигание, но в них можешь добавлять еще действия: комиссию (как это сделали в something.cool), проверку на вайтлист, интерест модель, нон трансферабл токенсы, и множество других штук (https://solana.com/ru/docs/tokens/extensions). Недавно запустили расширение с confidential transactions.

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

Математика внутри

Для начала пойдем в то как оно работает. Чтобы скрыть балансы и переводы и все остальное, используется шифрование public key (по сути своей как и работают все блокчейны с публичным и приватным ключом).

Есть алгоритм ElGamal, и в базовой версии он работает следующим образом - зашифрованные числа можно умножать, при этом после расшифровки финального числа оно равно обычному перемножению. a*b = c = decrypt(enc(a) * enc(b)). Основная защита данного алгоритма в дискретном логарифме.

В Solana же используется Twisted ElGamal, позволяющий складывать зашифрованные числа. a+b = c = decrypt( enc(a) * enc(b))

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

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

Доказательство валидного перевода

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

1. Range proof - доказываем, что числа (после трансфера и сам трансфер) находятся в 0<=x<=2^48 (отсюда и информация в дешифрование twisted ElGamal что эти числа легко перебрать(относительно))
2. Validity proof - здесь мы доказываем, что числа (для сложения и вычитания) зашифрованы валидно. При этом не раскрывается ни сама сумма, ни оставшийся баланс.
3. Equality proof - Пруф того что все зашифрованные числа равны (в незашифрованном виде)

Генерация ключей

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

1. Они генерируются на базе твоего приватного ключа под твой аккаунт, не под каждый минт. Результат подписи с сидом "ElGamalSecretKey" идет как сид в генератор случайных чисел и на базе него мы получаем приватный ключ (а от него и публичный). Полностью детерминированная система.
2. Единственная сложность шифра twisted ElGamal состоит в том что при дешифровке числа, ты получаешь не само число, а g^private_number (поэтому он и называется скрученный, и позволяющий делать операцию сложения) а значит, каждый раз проводить вычисления чтобы посмотреть баланс. Каждый раз вычислять его неудобно и долго, поэтому было добавлено еще одно число в сам аккаунт, но уже зашифрованное AES (шифр nist). Данный шифр позволяет хранить числа зашифрованными, и всегда легко и быстро понимать чему они равны и только юзер сможет это прочитать (и изменить). Для этого нужно знать ключ от данного AES шифра, и ключ генерируется аналогично как для twisted ElGamal, только тут сидом является "AeKey".

"Аудитор" в токене

1. Так как сама по себе солана есть компания из us, она не может сделать одностороннюю зашифрованную систему. Аудитор, в рамках spl ct, это такой наблюдатель со стороны, который может посмотреть баланс юзеров (зашифрованный публичным ключом аудитора). На этом его возможности заканчиваются.
2. Принцип работы следующий: при каждом обновлении баланса(трансфере, минте, берне), кроме того чтобы обновить свой зашифрованный баланс своим публичным ключом и чужой(если трансфер), также ты обновляешь свой и чужой баланс, зашифрованный уже публичным ключом аудитора. Используется одно число для двух балансов, так как шифруется публичным ключом аудитора,
3. А уже сам аудитор может расшифровать, но это опция, а не необходимость, и далеко не на каждый токен такое нужно(но для любого большого, а-ля shielded usdt, думаю нужно, иначе вопросы возникнут).

Гарантия консистентности

Так как используются zero-knowledge proofs, то получается, что пока ты создаешь пруфы, отправляешь транзу, и она попадает в блок, тебя могут кто-то обогнать и увеличить твой баланс. А твоя транзакция этого не учитывает и пруфы упадут.

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

Что в итоге:

1. Spl token 2022 расширение с confidential transfers. В рамках данного расширения, балансы скрываются гомоморфным шифрованием twisted ElGamal, позволяющим складывать скрытые числа.
2. Для проверки данных чисел в момент транзакций используется zero knowledge proofs (validity proof(легитимность транзакции), range proof(легитимность размера трансфера), equality proof(проверка на одинаковое шифрование)).
3. Есть публичный ключ "аудитора", хранящийся в токене, с помощью которого "аудитор" может посмотреть чужие балансы, но не влиять на них.
4. Чтобы гарантировать консистентность балансов при действиях, используется разделение балансов на доступные (на которые влияет сам пользователь) и ожидающие(куда перечисляют токены другие адреса).
5. Для упрощения вычислять скрытый баланс аккаунта используются AES шифрованные балансы, которые не позволяют гомоморфно складывать шифр тексты, но позволяют хранить и быстро шифровать и расшифровывать для быстрого доступа к балансу.
6. Все ключи, используемые в twisted ElGamal и AES, привязываются к приватному ключу аккаунта, а не к токену(минту) и вычисляются детерминированно. По 1 связке на каждый аккаунт.

Наевшись ZK во всех его имплементациях, подняв и попилив могучую кучу денег и придя в итоге к зкпсиху и старку, начинаешь смотреть что происходит еще в криптографии в блокчейне. И тут, оказывается, существует еще mpc и оно, наконец, начинает хоть как-то появляться в инфополе, пусть пока и единичных экземплярах (renegade https://renegade.fi/) (даже в кунилисте был Nillion). Так что же это такое этот Nillion? Немного вводных данных вначале

Безопасное хранение HVD

HVD (High value data) - это данные, которые важны юзерам и которые не особо хотят распространять: разные веса для моделек в ML, ордера, левередж позиций, медицинские данные. Эти данные нужно хранить и аккуратно с ними работать, по возможности не раскрывая всем. Для этого существуют разные подходы:

1. MPC - мы храним секреты в разных местах, и если нам нужно их посчитать, то мы будем делать определенное количество операций между нодами (хранящими данные), например сложение умножение, между самими нодами так, что данные ноды не узнают никакой информации друг у друга, но смогут совместно посчитать то что нужно. Например то с чего начался mpc - проблема миллионеров, которые хотят узнать кто из них богаче, не разглашая никому свои балансы (ни третьей стороне, ни друг другу), просто кто богаче. Более приземленные варианты это
1. Аукционы и ордера на покупку, чтобы выбрать самый высокий но чтобы никто не видел кто какой выставил и выбор был произведен абсолютно чисто
2. Совместные обучения машинок (например Tesla и Waymo) обучают свои машинки отдельно, но могут получить что-то совместное, не делясь датасетом на котором машинки будут обучаться
2. ZK - мы проведем вычисления у себя, проверим валидность данных вычислений и скажем результат, но мы есть третья кристально чистая сторона и нам нужно верить (это вот многие не любят). Если нету доверия то схема рушится, ну и сторона эта нужна. Из вариантов подходит
1. Система идентификации и подтверждения, что ты не показываешь паспорт на кассе со всеми сопутствующими данными левыми, а условно через приложуху, которой обязан доверять магазин, можешь доказать что тебе уже 18 лет и ты достоин
3. FHE - мы зашифруем твои данные и они будут зашифрованными в системе. А уже поверх них мы будем делать сложения и умножения. Они останутся в системе, но мы можем считать разные статистики, складывать умножать, главное что все поверх зашифрованных данных. Если нам нужно получить результат (например 1+2), и наши 1 и 2 зашифрованы, то мы складываем сами зашифрованные данные и в результате получим какое-то третье зашифрованное число, которые при расшифровке будет равно 3.

Вот три существующих подхода по решению данных задач, которые можно или скоро будет можно ( с FHE еще не все так гладко (люди из октры/fhenix/zama со мной не согласны офк)) увидеть в бч.

В чем основные сложности MPC

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

1. Если мы раскинем все по плохим нодам, они могут договориться и собрать сами то что ты разослал и какие данные хранишь.
2. Или эти плохие ноды могут давать не те свои данные или не так их разбивать и в итоге получится не совсем то что надо.
3. Для множественного взаимодействия нужно достаточно много итераций (которые занимают время). На 10 нод будет 100 итераций (условно), на 1000 нод обмен информацией будет невероятно долгим.

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

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

Что же придумал Ниллион

Архитектура

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

Существует множество Dealer нод, хранящих информацию. На вход функции поступают еще какие-то инпуты (Какие данные из каких нод, какие еще добавляются), собирают данные с нод с учетом данных инпутов, после отдают это все на вычисления в NMC ноды, которых гораздо меньше, уже на них проводят вычисления локально и после эти, скажем так полуфинальные данные, отдаются в Result nodes, которые меняют то что хранится внутри dealer nodes.

Raw-perprocessed-finish to network

основная идея в:

1. что мы не будем везде делать полную медленную децентрализацию как оно идет в smpc, и как изначально проектируется во всех криптографических протоколах основных, в итоге сильно сокращая количество действий и проблемы со множеством раундов, итераций.
2. сами вычисления nmc нод, получающих какие-то части для вычислений, проводятся локально, на супер быстрой скорости, кои после будут отдаваться в result ноды, а не вся сеть общается друг с другом.
3. Бывают вещи в идентификации и еще чем-то, когда эти данные хранятся на одной ноде (не распределены) и тогда не нужно множество дилер нод, а одна, которая делает рассылку на nmc ноды, сильно меньше коммуникаций. Ну и отправка всех скрывающих общие данные частей на все nmc ноды происходит параллельно, по времени +- как одна отправка на одну ноду, что, по их словам, дает скорость как в обычном блокчейне.

Nillio дают такие "оптимистичные" картинки, о чем они сами говорят (что это желаемое время)

Что это дает по сравнению со стандартным smpc:

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

На вопрос про экзекьюшн они дают ответ что используют byzantine подход, что если хотя бы 2/3 нод не будут "плохими", то к консенсусу придем. Сам консенсус при 50+% будет достигнут.

Хранение данных

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

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

Токен

У проекта будет токен, erc20 тип NIL, который будет идти на оплату газа, на доходы для нод, инцентивы и DAO. ничего интересного и нового, все стандартно.

Что делают сейчас

Предоставление своего execution layer под evm. Юзер пишет контракт на solidity, отправляет им в систему и использует у них. Идея в том что можно отойти от подхода зкп с хранением данных и экзекьюшна, и сделать его более децентрализованным и безопасным. Также писали про вариации с л2/сайдчейнами (мы пипец чо можем только скажите, технология вау), но это под вопросом. Были слова про https://nillion.com/news/982/ коннект с Арбитрумом, очень много всего связано с near и полным переносом всех их штук под экзекьюшн на ниллионе https://nillion.com/news/1107/, но пока не меиннет и не полная реализация то сидим ждем.

Язык Nada

Так как вид самих программ будет сильно отличаться, не евм стиль, то нужен свой язык. Он является dsl(domain specific language) и по сути сильно похож на питон:

1. строго типизирован
2. компилируем
3. с проверками на корректность (раст стиль короче)

Также они перенесли уже numpy (одна из главных мат либ на питоне) и добавили либу nada ai(позволяет делать регрессии и всякие другие машин штуки) (https://docs.nillion.com/nada-by-example), но все равно если глубоко залезть в язык, и как сами они пишут, язык еще не полный и не финальная версия его (поэтому и пока не полностью готовы к меиннету). Но активно развивают, так как уже есть н-ное количество проектов, готовых делать сложные вещи. Одним из таких является chooseK. https://medium.com/@Nillion_Network/nillion-partners-with-choose-k-to-build-the-future-of-encrypted-rrder-books-eaebfdfa37af

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

1. ончейн дарк ордербук. У нас есть ордера которые являются приватными данными, так пусть они матчатся друг с другом и проводят свои обмены, все в плюсе.
2. Есть подтверждения разных данных, так пусть оно остается по возможности анонимным (по сути идея зк), просто в реализации mpc.
3. Аукционы и всякие выборы ончейн, пусть оно будет тоже скрытым дабы исключить "плохое" поведение, связанное с абузом.
4. И дальше ...

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

Является ли это интересной штукой, которая может изменить многое в бч?

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

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

По сути это типа мультисига, где у вас есть k/n, всего n частей и k достаточно чтобы подписать (или узнать в нашем случае) секретную информацию.

Пример для маленьких

Допустим, у нас есть секретное слово solana (не очень хорошее, но такая фантазия больная). Можем сделать простейшее разделение на 6 слов и разделить между 6 людьми:

s?*, ?o*, ??l*, ???a*, ????n*, ?????a*

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

Можно добавить усложнение, пусть там все эти символы представлены в виде цифирок ascii и существует HE (Homomorphic encryption). Так уже схема чуток лучше, но 6 цифр и примерное понимание больной фантазии автора дают возможность подобрать.

Shamir's Secret Sharing Scheme

И тут на сцену выходит невероятно продуктивный Шамир, отец кучи всего в криптографии, и в 1979 году выдает SSS со следующими параметрами:

1. Разбивая информацию на n частей, вам будет достаточно лишь k чтобы восстановить ее
2. Если данных недостаточно (Не k известно, а k-1), то не восстановить
3. Другие недостающие параметры не подобрать просто так (если конечно там не слова из словаря с пробелами между ними, тогда есть шансы), только изначальный владелец знает

Принцип работы Вундер Вафли

Основа основ множества криптографических алгоритмов есть Lagrange Interpolation. Что это такое:

Есть у нас 1 точка, ладно.

Есть две точки, построим прямую (y = ax + b).

Есть три точки, построим параболу (y = ax^2 + bx + c)

Есть три точки, есть четыре точки и т.д.

Идея в том, что мы можем построить многочлен минимальной степени (из двух точек можно и 3-4 сделать степень, но точности не добавит), принимающий заданные значения в заданном наборе точек.

Для примера:

Есть у нас две точки: (0,0), (1,1). Можно по формулам геометрии 8 класса посчитать и построить прямую, а можно увидеть что y=x. Вот наша "кривая" прямая линия с максимальной степенью 1. А также можно увидеть, что сюда подходит y=x^2, y=x^3, .. y=x^n, а также вот эти все и их в итоге можно построить сколько угодно, но начиная со 2 максимальной степени. С минимальной = 1 только один, y=x.

Пока звучит легко, да? Но не сильно связано с нашей секретной задачей спрятать по всему миру нашу seed-phrase с 0.01 битком, согласен.

Основная идея

Пусть у нас есть какая-то кривая, допустим y=x^2+x+1 (называется парабола)

1. Чтобы нам ее построить, нам нужно иметь как минимум любые три точки, которые на ней лежат
2. Если у нас есть 4 точки, то мы все равно получим ту же самую кривую
3. Но если у нас их недостаточно, то мы не построим ее и не получим секрет

Алгоритм

Допустим у наш секретный ключ - 4, 5 ключей генерируем, и для расшифровки достаточно любых 3.

1. Создаем полином y = a0 + a1*x + a2*x^2 (из k точек строится k-1 степень полином)
2. Пусть a0 - наш секрет = 4, a1 - случайное - 2, a2 - случайное - 1
3. Генерируем из него 5 точек (1, 7), (2, 12), (3, 19), (4, 28), (5, 39).
4. Поздравляю, вы чудесны, вы получили какие-то рандомные точки, которые можете кому-то разослать (желательно чтобы эти люди не сразу же восстановили ваш секрет).

Как же по ним восстановить?

Можно через лагранжа считать тут формулки, но тогда слишком много текста, порисуем картиночки

https://www.desmos.com/calculator/kqi9wezbvx тут все рисуночки

Имея 3 точки, мы получаем следующую кривую

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

наше скрытое число
Но что будет, если у нас есть только две точки? (Все варианты перебирать не стал, оставил один)
https://www.desmos.com/calculator/imggo3qwgi

Теперь вообще другая точка.

А если хоть одна будет лишняя, будет вообще другая кривая.

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

Для тех, кто вдруг решил захотеть потыкать ручками, вот есть код на расте (не бейте если там не фулл тру rustacean)
https://github.com/valpaq/sss

Оказывается, криптография развивается не только в шифровании (синхронном и асинхронном), хэшах и zkp(все более известном). С 1980 годов развивается smpc и сейчас (также как и zkp) скорость и распространение просто ауф.

Что это такое и зачем?

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

1. Tesla и Waymo хотят обучить свои нейроночки на совместных данных, дабы машинки летали по дорогам, при этом не делясь ими друг с другом
2. Электронное (честное и интимное) голосование, где все хотят за кого-то проголосовать и не раскрывать друг с другом
3. Электронные аукционы
4. Хранение и работа с данными, которые достаточно сенситив (например длина члена)

При этом все начиналось достаточно с простой задачи.

Есть три миллионера, как им посчитать средний доход, не раскрывая никому полностью свои цифры?

...Ладно, задача достаточно простая, в реальности она другая, но нужно сначала разобраться с этой.

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

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

Выглядит громоздко, да, можно упростить решение:

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

Теперь как звучала изначально задача:

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

Так как задача является базовой, то имеет огромное количество решений, с самой разной сложностью. Есть как криптографические с PHE, так и для детишек. Сначала разберем для детишек.

1. Пусть Alice получает 40 млн, а Bob 30
2. Тогда Alice купит коробки с замком и дыркой как у копилки, нарисует поверх каждой цифры в млн (10, 20, 30, 40, 50,.. 25 там, главное в диапазоне).
3. И выкинет ключи ото всех коробок, кроме той, где указано его количество денег. (В принципе может продемонстрировать Bob'у, что ключ один (главное чтобы по нему нельзя было коробку идентифицировать)).
4. Bob же сделает следующее: Пройдет по всем коробкам и опустит листики, внутри которых написано Да или Нет, в зависимости от того, сколько он получает и сколько на коробке.
5. После этого, он уходит, подходит Alice и проверяет свою коробку (ведь больше никакие не может). И там либо Да, либо Нет, а значит либо они получают одинаково, либо нет, но непонятно кто больше и насколько.

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

Один из сотни криптографических способов (выбрал из-за простоты понимания):

Но для начала нужно объяснить вкратце еще одно популярное направление Homomorphic encryption. По сути, это Layer для чисел (шифрование), позволяющий делать такие же операции, как и с обычными числами, без нарушения их свойств или формата. Но при этом если a>b, то не обязательно будет f(a) >f(b), иначе смысла в схеме не будет особого.

Зачем же она нужна нам тут? Она позволяет проводить следующие операции
(под f^(-1) я подразумеваю расшифрование, под f шифрование)

1. Мы можем зашифровать и расшифровать чиселку: a = f^(-1) (f(a))
2. Мы можем складывать в ней и получим идентичные значения при дешифровании (важное условие):
   a - b = f^(-1) (f(a) - f(b)
3. Но также мы можем сделать следующую важную штуку:
   f(a) + f(b) = f(a+b)
   Тогда по сути a + b = f^(-1) (f(a) + f(b)) = f^(-1) (f(a+b))

Тогда сама схема выглядит следующим образом:

1. Есть Алиса и число a, есть Боб и число b
2. Пусть у Боба есть эта схема, он знает как зашифровать и расшифровать. Боб считает f(a) и отправляет Алисе, вместе со схемой.
3. Алиса придумывает случайное число r и считает V = (f(a) - f(b)) (+) f(r)
   (+) это Xor. Функция делает побайтовое следующие действия:
1. Если битик а и битик б равны, то bit_a (+) bit_b = 0
2. Иначе bit_a (+) bit_b = 1
4. Боб расшифрует, получает (a-b) (+) r и отправляет самый левый битик. Этот битик хранит информацию о знаке (a-b) (+) r.
5. Алиса проводит еще разок Xor битика, полученного от боба и самого левого битика от r и если 0, то a>b, иначе наоборот.

Ничу непонятно, разберем схему с 3 пункта

• Если Алиса просто отдаст Бобу f(a) - f(b), то он сможет посчитать это у себя, ведь f(a) - f(b) = f(a-b), а значит f^(-1) (f(a-b)) = a-b и понять сколько зарабатывает Алиса, ничего не сказав ей.
• Зачем нужен xor? чтобы полностью поменять число. Не прибавить, не умножить. Покажу на примере
  Пусть есть a = 13 и a в битовом формате будет выглядеть так
  001101 (нулей может быть больше слева, в зависимости от формата)
  и пусть если число b = 23
  010111
  тогда a (+) b (идем слева направо)
• 0 (+) 0 = 0
• 0 (+) 1 = 1
• 1 (+) 0 = 1
• 1 (+) 1 = 0
• 0 (+) 1 = 1
• 1 (+) 1 = 0
• Получим число 26
• Зачем нужны левые битики? в компьютере они представляют собой знаки чисел, и по ним мы ориентируемся.
• Почему же Боб просто не поймет битик? а он не знает наше случайное число, вдруг у него тоже 1 стоит там, тем самым схема безопасна.

Если вдруг кто-то заинтересовался кодом, то вот он. https://github.com/valpaq/yao-s-milltionare-phe

Если вдруг кто-то заинтересовался, почему же FHE такой клевый, раз туда сюда чиселки можно и все секурно, то вот ответ почему.
Да, это опенсорс штука, не те размеры чисел которые интересуют, но

197 секунд заняла настройка изначальных параметров на моем компуктере, для чисел u16
а также все вычисления крайне долгие и мощностей пока не хватает под них в нашем мире)
Keep building...

Писать про Zero knowledge proof всегда тяжело, ведь какой нибудь plonk из крипты понять не каждый сможет, тем более описать простым языком. При этом сам zkp есть идея, имеющая определенные необходимые условия, при этом оставляющая реализацию на выбор.

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

Вот тут есть неплохой вводный материал для понимания идеи zkp https://teletype.in/@chpotl/zkp, мы же постараемся погрузиться чуть глубже.

Secure remote password

Проблема работы с паролями известна давно: компании как хотят хранят ваши пароли, довольно часто в plaintext - обычном тексте, не хешируя. Те же, кто хранят в хэше, часто передают по небезопасному протоколу данные вида (логин, пароль) и существует определенная атака под название MITM - man in the middle.

MAN IN THE MIDDLE

Смысл атаки «Человек посередине (от англ. Man-in-the-middle, MITM) заключается в том, что злоумышленник «пропускает» веб-трафик жертвы (возможно, путем изменения параметров DNS-сервера или файла hosts на машине жертвы) «через себя». В то время пока жертва считает, что работает напрямую, к примеру, с веб-сайтом своего банка, трафик проходит через промежуточный узел злоумышленника, который таким образом получает все отправляемые пользователем данные (логин, пароль, ПИН-код и т. п.).

Определение взято отсюда - https://encyclopedia.kaspersky.ru/glossary/man-in-the-middle-attack/

У данной проблемы существует давно решение, которое почти никто не использует - secure remote password.

Суть метода в том, что сервер не хранит пароль в отдельном хеше, а еще с определенными модификациями поверх, позволяющими скрыть пароль в момент передачи, делая его недоступным для "человека между". А также две итерации происходит, никаких non-interactive proofs. При этом метод достаточно простой и даже не нужны эллиптические кривые. Почему никто не использует - это другой вопрос.

Алгоритм srp

Обозначения

Соль - случайная строка, нужна для добавления сложности в перебор паролей

Хэш функция - криптографическая хэш функция, а-ля всем известные sha256, keccak и т.д.

SRP группа - состоит из одного простого очень большого числа и генератора - конечное поле.

Verifier - Сгенерированное число в SRP группе, которое будет хранить сервер и в котором спрятан пароль.

Регистрация

1. Клиент генерирует случайную строку - соль. Нужна она для того, чтобы было сложнее перебрать пароли по хэшу, используется как приставка.
2. Клиент передает логин, пароль и соль в хэш функцию чтобы получить х - временное поле.
3. Потом генерирует кое-что, называемое verifier, используя полученный сверху x и SRP группу.
4. После отправляет verifier, соль и srp группу с юзернеймом на сервер и сервер будет хранить эти данные (username, verifier, salt).

Аутентификация

1. Клиент
1. Отправляет запрос на соль и SRP группу под определенный логин.
2. Создает случайное а - приватное, и на основе него A - публичное, уже в SRP группе. Хранит у себя в памяти a, A - отправляет на сервер.
2. Сервер
1. Генерирует случайное число b- приватное, а на его основе B публичное, уже в SRP группе (Аналогично с клиентом). Отправляет Соль, SRP группу и B клиенту.
3. Что происходит
1. Пароль не был обменян
2. Обменялись публичными ключами А и B.
3. Теперь используя разные вычисление (На чем строится весь zk) они должны прийти к одним значениям (в основе которых и используется пароль)

Верификация вычислений

1. Клиент проводит вычисления поверх хэша от пароля с солью, используя общий ключ (хэш от A и B) и отправляет результат на сервер
2. Сервер проверяет результат и верифицирует его. Если не проходит проверку, то отменяет аутентификацию.
3. Если же все успешно, то отправляет клиенту другие вычисления поверх пароля и уже с полученным результатом от клиента.
4. Клиент проверяет полученные данные и может удостовериться, что это тот сервер.

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

Вот тут есть реализации на вики https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol#Implementations

Вот тут моя на Rust, склоненная от другого проекта https://github.com/valpaq/srp6-rs

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

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

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

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

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

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

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

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

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

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

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

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

Что такое PDA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бинарное возведение в степень, которому все учат

У нас есть число, допустим 7. Нам его нужно возвести в степень 19, по модулю 1024, к примеру. Как оно обстоит:

1. У нас изначально есть переменная, хранящая такое же значение, как и база для возведения в степень, и отдельная переменная, изначально равная 1.
2. Идем по битам сначала степени.
3. Если в бите стоит 1, то мы умножаем финальное число на переменную. Если 0, то пропускаем.
4. После условия мы умножаем базовое число само на себя, убираем последний бит у степени (мы его использовали только что) и начинаем новую итерацию.

Выглядит оно следующим образом

def binpow(base, power, mod) :
    res = 1
    base = base % mod
    while power ! = 0 :
        if power & 1:
            res = res * base % mod
        base = base * base % mod
        power >> = 1
    
    return res;

В чем удобство данного алгоритма? Он достаточно быстрый. Для возведения в степень 19 - 10011, мы проделаем всего 5 итераций циrла, O(LogN).

Максимально простое представление:

7 ^ 19 mod 1024 = 7^1 * 7^2 *7^16 - в сумме степени дают 19, и это как раз что нам надо.

В чем же проблема данного алгоритма? Если мы будем смотреть по тактам, то легко можем понять что происходит внутри. Из-за наличия условия, где происходят самые большие вычисления, алгоритм не является безопасным на аппаратном уровне: либо два умножения (одно из которых гораздо сложнее другого) и сдвиг, либо одно простое и сдвиг.

И тут появляется Монтгомери и предлагает свою лесенку

Лестница Монтгомери

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

Как выглядит код:

def mont_ladder(base, power, mod):
    power_bin = format(power, 'b')

    first = 1
    second = base % mod

    for i in power_bin:
        if i == "0":
            second = (first * second) % mod
            first = pow(first, 2, mod)
        else:
            first = (first * second) % mod
            second = pow(second, 2, mod)

   return first
}

Думаю проще будет показать на примере вычислений:

1. base = 7, power = 19, mod = 1024
2. x = 1, y = 7
3. pow_bin = 10011
4. заходим в цикл
1. i == 1
   x = 1 *7 mod 1024 = 7
   y = 7 * 7 = 49
2. i == 0
   y = 7*49 mod 1024=343
   x = 7 * 7 = 49
3. i == 0
   y = 343*49 mod 1024 = 423
   x = 49 * 49 = 353
4. i == 1
   x = 353*423 mod 1024 = 839
   y = 423*423 mod 1024 = 753
5. i == 1
   x = 839*753 mod 1024 = 983
   y = 753*753 mod 1024 = 737

Получили x = 983, это и есть ответ.

7^19 = 11 398 895 185 373 143 % 1024 = 983.

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

Это все хорошо, но зачем оно нам?

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