БЛОКЧЕЙН по-русски
131 subscribers
58 photos
35 links
Сложные темы про Blockchain / MEV на простом языке.
Download Telegram
Мы уже смотрели на устройство транзакций в биткойн-сети, где транзакции состоят из входов и выходов UTXO - (Unspent Transaction Output). В сетях на основе EVM, таких как Ethereum, транзакции изменяют глобальное состояние, взаимодействуя с аккаунтами и смарт-контрактами.

Ethereum транзакция представляет собой сообщение, инициируемое внешним аккаунтом (externally-owned):
- from: Адрес отправителя, который будет подписывать транзакцию.
- to: Адрес получателя или контракт.
- nonce: Уникальный счетчик для каждой транзакции отправителя.
- maxPriorityFeePerGas: Максимальная цена газа, которая может быть добавлена в виде чаевых валидатору.
- maxFeePerGas: Максимальная цена за единицу газа, которую отправитель готов заплатить (включает базовую и приоритетную комиссии).
- chainId: идентификатор сети, важен для защиты от атак повторного воспроизведения в других EVM сетях.
- value: Количество отправляемых ETH.
- input: Поле для передачи данных смарт-контракту.
- v, r, s: Параметры для цифровой подписи.

#продвинутый
🔥3👍1
Что за input в Ethereum транзакциях?

Input data требуется для транзакций, которые взаимодействуют со смарт-контрактами. Это закодированная информация, указывающая, какую функцию контракта нужно вызвать и с какими параметрами. Структура состоит из:
1. Function Selector первые 4 байта (8 символов в hex) — это хеш сигнатуры функции.
2. Аргументы — закодированы так, что каждый занимает 32 байта. Для динамических типов указывается смещение, где хранится фактическое значение.

Рассмотрим пример — функцию transfer в ERC-20:

Первые 4 байта для function selector, вычисленный с помощью Keccak-256. Для функции transfer(address,uint256) будет a9059cbb.

Функция transfer принимает два аргумента:
1. Адрес получателя (address) — это 20-байтовый адрес Ethereum, который помещается в 32-байтный слот, заполняя первые 12 байт нулями (адрес занимает последние 20 байт).
2. Количество токенов для перевода (uint256) — это значение упаковано в формате big-endian, где старшие разряды (слева) заполняются нулями.

#продвинутый
👍2🔥2
Я не упомянул про gasLimit в посте про ethereum транзакци.
Gaslimit— это максимальное количество газа, которое пользователь готов потратить для выполнения транзакции. Оно ограничивает объём вычислений, которые транзакция может выполнить.

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

Стоимость комиссии за транзакцию рассчитывается на основе цены за единицу газа, которая состоит из baseFee, maxFeePerGas и maxPriorityFeePerGas.

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

Итоговая стоимость транзакции = min(maxFeePerGas, baseFee + maxPriorityFeePerGas) × gasUsed

#продвинутый
👍5
Привет, ребята! Канал — не бездушный учебник. Формат текста в 1024 символа может быть непростым, так что не стесняйтесь оставлять комментарии и задавать вопросы, если что-то непонятно или хочется поправить автора 😉
Так будет ясно, в какую сторону углубиться.
Хороших выходных!
🔥7🏆2
В Ethereum стоимость транзакции измеряется в газе, который определяет ресурсы, необходимые для её выполнения и хранения. Рассмотрим основные факторы, влияющие на потребление газа.

- Базовая стоимость транзакции - фиксированная стоимость в 21000 газа для покрытия минимальной нагрузки, включая валидацию и распространение транзакции.
- Стоимость за каждый байт данных (Calldata): Ненулевые байты calldata стоят 16 газа каждый, а нулевые байты — 4 газа.
- Вычислительные операции (Execution) рассчитываются для каждой операции (opcode) в контракте. У каждой операции своя цена газа, которая зависит от её сложности.
- Хранение данных (Storage) — запись в хранилище стоит до 20000 газа, а удаление данных возвращает часть газа.
- Логирование — запись событий в журнал с помощью функции LOG имеет фиксированную стоимость 375 газа, плюс 8 газа за каждый байт данных.
- Access List — оптимизирует доступ к памяти и хранилищу (EIP-2930), снижая затраты на газ за счёт указания адресов и слотов заранее.

#продвинутый
👍41
ERC-1404: Стандарт токенов с ограничениями на передачу.

В отличие от классического ERC-20, он позволяет эмитентам (организациям, выпускающим токены) блокировать переводы между адресами по разным причинам, например, для соблюдения KYC (Know Your Customer – процедура идентификации пользователей). Функция detectTransferRestriction проверяет возможность перевода, а messageForTransferRestriction объясняет пользователю, почему он запрещен.

ERC-1404 уходит от принципов криптовалют и свободы. Ограничения мешают свободному обороту, фактически вводя традиционный централизованный контроль в блокчейн.

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

#defi
👍3🔥21
Rollups

Ethereum
(L1) имеет ограниченную пропускную способность (~15 TPS) и высокие комиссии. Решения второго уровня (L2) помогают масштабировать сеть, снижая нагрузку на основной слой.

Одним из ключевых механизмов L2 являются Rollups — технологии, выполняющие вычисления вне L1 и публикующие минимально необходимые данные в основной сети Ethereum. Они решают проблему трилеммы блокчейна, увеличивая пропускную способность без ущерба для децентрализации и безопасности.

Существует два типа Rollups:

ZK-Rollups
: обрабатывают пакеты транзакций вне цепочки, предоставляя предлагаемые изменения в L1 вместе с криптографическим доказательством их корректности, используя технологию «zero-knowledge» (нулевое разглашение).
Примеры: StarkNet, zkSync.

Оптимистичные Rollups: предполагают, что транзакции, выполняемые на L2, являются действительными по умолчанию. Они позволяют участникам сети оспаривать эти транзакции, предоставляя доказательства мошенничества (fraud proofs).
Примеры: Optimism, Arbitrum.

#продвинутый
👍1👀1
Proof of History (PoH) — механизм, который позволяет создать доказательство последовательности событий.

Это развитие идеи Proof of work, алгоритм которого саморегулируется так, чтобы майнерам потребовалось одинаковое количество времени на построение блока. Например, в Bitcoin – это 10 минут. PoH создает такую же математическую задачу для участников сети, но так, чтобы ее было невозможно решить параллельно. Это сильно снижает необходимые вычислительные мощности.

Корнем PoH является Функция проверяемой задержки (Verifiable Delay Function), основанная на последовательном хешировании с помощью алгоритма SHA-256. Начинается с произвольного начального значения (seed). Это значение хешируется, и каждый полученный хеш служит входом для следующего. Создается последовательная цепочка хешей, где каждый элемент зависит от предыдущего.

Proof-of-History не является механизмом консенсуса, а дополняет Proof-of-Stake, оптимизируя упорядочивание событий и сокращая время подтверждения блоков.

#продвинутый
👍1🔥1
Смарт-контракты — это код, который, как и любая программа, может содержать уязвимости. Однако из-за особенностей работы блокчейна эти уязвимости не всегда очевидны. Одной из самых разрушительных и распространенных атак является атака повторного входа (Reentrancy Attack).

Основной принцип: атакующий контракт многократно вызывает уязвимую функцию контракта-жертвы, пока тот не обанкротится.

Пример:
Контракт-хранилище позволяет пользователям вводить и выводить свои ETH, ведя учет балансов в balances. Однако атакующий находит лазейку:

1. Хакер кладет 1 ETH на свой баланс в уязвимом контракте.
2. Вызывает withdraw для вывода средств.
3. Контракт-жертва отправляет ETH хакерскому контракту с помощью call.
4. Поскольку атакующий контракт не имеет специально определенной функции для получения средств, неявно вызывается его функция fallback.
5. Внутри fallback хакер снова вызывает withdraw, пока предыдущий вызов еще не завершен.
6. Цикл повторяется, пока контракт-жертва не окажется пустым.

#EVM #продвинутый
👍2🔥21
Uniswap v2

Автоматизированные маркет-мейкеры (AMM) описывает базовые принципы пулов ликвидности. Теперь разберем Uniswap v2, одну из первых AMM-моделей.

Основная формула Uniswap v2:
x⋅y=k

где:
x — количество одного токена в пуле,
y — количество второго токена,
k — неизменное произведение.

Рассмотрим своп 2 ETH на USDC в пуле, где 100 ETH и 300 тысяч USDC.
Если Δy = 2 ETH, то получаемый USDC Δx:
Δx = x ⋅ Δy / (y + Δy​)

Однако в Uniswap v2 с каждой сделки взимается комиссия 0.3% (или меньше в форках). Она не выводится из пула, а остается в нем, увеличивая его объем. Это стимулирует поставщиков ликвидности.

С учетом комиссии эффективная формула обмена:
Δx = x ⋅ Δy * (1 - 0.003) / (y + Δy * (1 - 0.003)​)

Так как комиссия остается в пуле, то после каждой сделки k увеличивается.

В примере на картинке вместо 5882.3 USDC из-за комиссий мы получим 5865.05 USDC. Если пересчитать новое значение k , то оно увеличиться на 0.0058 %. Все поставщики ликвидности разбогатели на этот же процент пропорционально их долям в пуле.

#defi
4👍3🔥3
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
👍4🔥3
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
👍3🔥2
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
👍3
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 #технологии
🔥7
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 на простые множители. С маленькими числами это просто, но с числами в сотни цифр - крайне долго.

#технологии
👍4🔥1