Turbine: Протокол распространения блоков в Solana​

Turbine — подобно протоколу Gossip, используемому в Ethereum, Turbine решает задачу масштабируемости и скорости распространения блоков.​

Механизм работы Turbine:
- Лидер (узел, ответственный за создание блока) разбивает блок на небольшие фрагменты, называемые "шредами" (shreds). Это позволяет передавать данные более эффективно и снижает нагрузку на сеть.​

- Шреды разбиваются с использованием кодов Рида — Соломона. Этот метод обеспечивает восстановление исходных данных даже при потере или повреждении части шредов во время передачи. В Solana обычно применяется FEC (Forward Error Correction) с коэффициентом 32:32, что означает, что из 64 пакетов можно потерять 32 без необходимости повторной передачи. ​

- После кодирования шреды распространяются по предопределенной древовидной структуре, называемой деревом Turbine.

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

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

- Валидаторы распределяются по слоям на основе параметра DATA_PLANE_FANOUT, который означает число узлов на слое 1. (например на картинке оно равно 3). В Solana значение DATA_PLANE_FANOUT установлено на 200, что позволяет большинству валидаторов находиться всего в 2-3 переходах от лидера.

#технологии #solana

ERC-4337: Account Abstraction для Ethereum

В Ethereum существует два основных типа аккаунтов: смарт-контракты (программируемые аккаунты с исполняемым кодом) и EOA (Externally Owned Accounts) – обычные пользовательские аккаунты, управляемые приватными ключами.

Что, если объединить эти два типа аккаунтов в один? Реализация "смарт-аккаунтов" вместо обычных EOA открывает путь к следующим функциям:
- Кастомная логика авторизации (мультисиг, биометрия)
- Безгазовые транзакции (например, за счёт передаваемых токенов)

ERC-4337 – это реализация Account Abstraction без изменений в консенсус-протоколе Ethereum. Вместо этого она использует новый мета-транзакционный уровень, который обрабатывается вне основной цепочки блоков.

Как это работает

UserOperations (Пользовательские операции) — это псевдо-транзакционные объекты, представляющие намерения пользователей. Вместо прямого инициирования транзакций с EOA, пользователи создают UserOperations, которые инкапсулируют желаемые действия. Эти операции содержат информацию, схожую с "классическими" транзакциями: получатель, данные транзакции и детали комиссии за газ.

UserOperations позволяют объединить несколько действий в одной операции, упрощая процесс и снижая затраты на газ.

UserOperations не отправляются в традиционный публичный мемпул, вместо этого они отправляется в UserOperation мемпул — специализированный мемпул, предназначенный исключительно для объектов UserOperation.

Бандлеры (Bundlers) прослушивают мемпул UserOperation и объединяют несколько UserOperation в одну транзакцию, включая её в следующий предлагаемый сети блок. Бандлеры либо сами являются строителями блоков (block builders), либо сотрудничают с ними.

Все действия, описанные в UserOperations, выполняются Account Contract'ом от имени пользователя. Это смарт-контрактный кошелёк, который уже находится в блокчейне, заменяя традиционный EOA и отвечая за валидацию и исполнение операций, описанных в UserOperation.

#EVM

EIP-7702

Обновление Ethereum Pectra включает EIP-7702, продолжающий идею ERC-4337 о наделении EOA (Externally Owned Accounts) аккаунтов свойствами смарт-контрактов. EIP-7702 позволяет EOA временно функционировать как смарт-контракты в рамках одной транзакции, но теперь уже в самом протоколе Ethereum без отдельных надстроек, как в ERC-4337.

Вводится новый тип транзакции (0x04) с полем authorization_list, содержащим авторизации от EOA. Инициатор транзакции может отличаться от авторизующего аккаунта, что позволяет реализовать спонсирование газа.

Каждая авторизация включает следующие поля:
● chain_id — идентификатор цепи, в которой действительна авторизация
● address — адрес контракта-реализации
nonce — должен соответствовать текущему nonce авторизующего аккаунта
● y_parity, r, s — данные подписи авторизующего аккаунта
● Тут нет адреса подписавшего: он выводится из подписи (y_parity, r, s) и полезной нагрузки— keccak256(0x05 ++ rlp[chain_id, address, nonce]).

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

Спонсор, отправляя транзакцию, указывает в поле to адрес EOA пользователя, в поле data — вызов функции реализации, а в authorization_list — авторизацию от пользователя.

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

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

#EVM

Gulf Stream

Я уже упоминал одну из важных технологий в Solana - Turbine. В дополнение к ней, Gulf Stream является еще одним ключевым компонентом архитектуры Solana: если Turbine отвечает за то, как обработанные транзакции покидают лидера, то Gulf Stream определяет, как транзакции достигают лидера.

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

Как работает Gulf Stream:
1. Транзакция создаётся клиентом и отправляется на RPC-узел (Remote Procedure Call) через JSON-RPC интерфейс.
2. RPC-узел пересылает транзакцию валидаторам со стейком, которые затем передают её текущему или будущему лидеру. Если таких валидаторов нет, транзакция направляется напрямую лидеру через QUIC-соединение (протокол быстрой передачи данных).
3. RPC-узлы или валидаторы заранее отправляют транзакции валидаторам, которые по расписанию должны стать лидерами.
4. Роль лидера в сети передается каждые 4 слота (примерно каждые 2 секунды), а расписание лидеров заранее известно всем активным узлам сети.
5. Будущие лидеры получают транзакции еще до начала своего слота и могут начать создание блока немедленно после вступления в роль лидера.

С введением Stake-weighted Quality of Service (SWQoS) в начале 2024 года, лидеры начали отдавать приоритет сообщениям о транзакциях, проксированным через другие застейкавшие валидаторы. Конкретно:
● 80% емкости лидера (2000 соединений) зарезервировано для застейкавших пиров
● Оставшиеся 20% (500 соединений) выделены для сообщений о транзакциях от незастейкавших узлов

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

#solana #технологии

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

В блокчейнах RSA не применяется. Вместо него используется более эффективная схема цифровой подписи — ECDSA (на основе эллиптических кривых). Но на примере RSA будет проще оценить магию асимметричного шифрования.

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

1. Выбираются два различных случайных простых числа p и q.
p=3 и q=11
2. Вычисляется число n, где n = p × q.
n=p×q=33
3. Вычисляется значение функции Эйлера: ϕ(n)=(p−1)×(q−1)
ϕ(n)=(p−1)×(q−1)=20
4. Выбирается целое число e, такое что 1 < e < ϕ(n) и e взаимно просто с ϕ(n).
Допустим, e = 7 (нет общих делителей с 20)
5. Вычисляется целое число d, такое что d × e ≡ 1 mod ϕ(n)
d = 3 проверка: 3 × 7 = 21 ≡ 1 (остаток 1 при делении на 20)
6. В итоге пара (n, e) - это открытый ключ, а пара (n, d) - это закрытый ключ.
Публичный ключ: (n=33, e=7)
Приватный ключ: (n=33, d=3)

Теперь возьмем для примера, что Боб хочет отправить сообщение "5" (для простоты берем число 5, а не текст) Алисе.
1. Алиса создала пару ключей выше.
2. Боб шифрует с помощью публичного ключа Алисы: c = m^e mod n
5^7 = 78125
78125 mod 33 = 14
Зашифрованное сообщение: 14
3. Алиса получила шифртекст "14" и расшифровывает своим приватным ключом:
Расшифровка: m = c^d mod n
14^3 = 2744
2744 mod 33 = 5
Исходное сообщение: 5

Даже зная публичный ключ (33, 7) и шифртекст 14, злоумышленник не может легко найти приватный ключ, поскольку ему нужно разложить n=33 на простые множители. С маленькими числами это просто, но с числами в сотни цифр - крайне долго.

#технологии

Цифровая подпись

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

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

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

Механизм работы
1. Генерация хеша
- Исходное сообщение (файл, транзакция, документ) пропускается через криптографическую хеш-функцию (SHA-256, Keccak и др.).
На выходе получается хеш фиксированной длины.

2. Создание подписи
- На основе хеша и закрытого ключа вычисляется подпись. Результат — цифровая подпись (набор байт).
Только владелец закрытого ключа может её создать.

3. Проверка подписи
- Получатель использует открытый ключ отправителя:
- восстанавливает закодированное сообщение и извлекает из него хеш;
- самостоятельно вычисляет хеш исходного сообщения;
- сравнивает значения. Если они совпадают — сообщение подлинное и не изменялось.

Для примера возьмём RSA-PSS
- m — исходное сообщение (байты)
Возьмем тот же самый приватный и публичный ключ из поста выше.

Публичный ключ: (n=33, e=7)
Приватный ключ: (n=33, d=3)

1. Генерация хеша, криптографически устойчивой к коллизиям функцией. Например, SHA-256.

h = H(m)

Для примера сразу возьмем сообщение, которое уже якобы хеш

m = 123

Но RSA работает по модулю N, поэтому фактически:

m = m mod N
m = 123 mod 33
m = 24

2. Создание подписи.
- EM (encoded message) — закодированное сообщение перед подписью
- s — подпись (целое число)
- mod — остаток от деления.

EM = PSS_Encode(Hash(m), salt)
s = EM^d mod N

Для упрощения возьмем сообщение m сразу как EM, игнорируя PSS, в реальности функция PSS_Encode - содержит случайную соль, маскирование и строгую структуру.

s = 24^3 mod 33
s = 360 mod 33
s = 30

3. Проверка подписи
- EM' — восстановленный закодированный блок

EM' = s^e mod N
EM' == EM ?

EM` = 30^7 mod 33
EM` = 21870000000 mod 33
EM` = 24

EM` = EM - подпись корректна!

#введение