В понедельник вечером поговорим про Hardhat 3 https://youtube.com/live/fU9AjeRrqDM?feature=share

📟 Прилетело из @dev_in_ruby_colors

ОТ КОШЕЛЬКА ДО БЛОКЧЕЙНА: ВСЕ ЭТАПЫ ETHEREUM ТРАНЗАКЦИИ

https://youtu.be/JiG8xu0sZx8

📟 Прилетело из @code_vartcall

ОТ КОШЕЛЬКА ДО БЛОКЧЕЙНА: ВСЕ ЭТАПЫ ETHEREUM ТРАНЗАКЦИИ

https://youtu.be/JiG8xu0sZx8

📟 Прилетело из @code_vartcall

ОТ КОШЕЛЬКА ДО БЛОКЧЕЙНА: ВСЕ ЭТАПЫ ETHEREUM ТРАНЗАКЦИИ

https://youtu.be/UIK2wXx_Ovg

Приятного просмотра!

📟 Прилетело из @code_vartcall

Этапы Транзакции Ethereum

Часть 1

Обновил превью к последнему видео на эту тему, а сегодня, обсудим этот материал в формате поста!

Как работает Ethereum транзакция под капотом?

План:

1. Формирование транзакции в кошельке
2. Работа с RPC
3. Мемпул
4. Блок-Билдер
5. Реелер
6. Задача Валидатора
7. Блок распространяется по сети и становится частью цепочки

Разберем коротко и по порядку

1. Формирование транзакции в кошельке

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

Кошелёк под капотом собирает полный “паспорт” транзакции:

адрес отправителя и получателя

сумму перевода

данные для контракта (если это свап, депозит и т.п.)

идентификатор сети (chainId), чтобы транзакция не уехала в чужую сеть

nonce - номер транзакции для этого адреса, чтобы не было каши в порядке

лимит газа и параметры комиссий: maxFeePerGas и maxPriorityFeePerGas

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

2. Работа с RPC

Дальше в игру вступают инфраструктурные провайдеры: Infura, Alchemy, QuickNode и другие. Кошелёк отправляет raw-транзакцию на RPC-узел - входная точка в сеть Ethereum.

RPC-узел принимает пакет, раскодирует его обратно в структуру с полями и делает базовые проверки:

корректна ли подпись и действительно ли её поставил владелец адреса

совпадает ли nonce с тем, что узлу известно о счётчике транзакций этого аккаунта

хватает ли баланса на сумму перевода плюс максимальный газ

валиден ли формат транзакции и её параметры газа

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

3. Мемпул

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

Узел добавляет туда транзакцию и рассылает информацию о ней другим узлам по p2p-сети. Те повторяют проверку и тоже кладут её в свои мемпулы. Через несколько секунд большинство узлов в сети знают о твоей транзакции.

В мемпуле транзакция не выполняется, не меняет состояние сети, а просто стоит в очереди

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

Здесь в дело вступает тот, кто решает, какие именно транзакции попадут в следующий блок.

4. Блок-билдер

В современных реалиях Ethereum блоки собирают не валидаторы, а блок-билдеры.

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

блок принёс максимум комиссии

можно было извлечь дополнительную выгоду за счёт порядка операций (MEV)

ничего не ломало состояние сети и не конфликтовало по nonce

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

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

Далее разберем задачи релеера, валидатора и процесс распространения блока по блокчейну, все это во второй части!

Смотреть видео - youtu.be/UIK2wXx_Ovg

VARTCALL

📟 Прилетело из @code_vartcall

Вот и стало мне 29 лет!

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

Но сам день рождения для меня всегда радостный день.
И я не понимаю тех, кто грустит из-за старения. Суть не в старении, а в рождении.

Буду рад подаркам и поздравлениям 😊.

Подарить Рубли или крипту.

Благодарю!

😎 Незрячий web3 программист (подписаться)
Чат | бот

📟 Прилетело из @blind_dev

Этапы Транзакции Ethereum

Часть 2

Предыдущая часть

Реелеры, валидаторы и процесс добавления блока в блокчейн

5. Реелер

Между блок-билдером и валидатором стоит ещё один важный участник - релеер.

Он получает блок-пропозалы от разных билдров, складывает их в очередь и делает две ключевые вещи:

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

сравнивает, какой блок приносит валидатору максимальную прибыль

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

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

Так релеер защищает и билдеров, и валидаторов.

6. Задача Валидатора

Валидатор - участник, который держит залоченный ETH и отвечает за финальное "да" или "нет" для блока.

Получив слепый блок от релеера, валидатор:

проверяет заголовок: слот, ссылку на предыдущий блок, корни данных

убеждается, что блок относится к текущему слоту и не ломает цепочку

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

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

Подпись валидатора - момент, когда сеть официально признаёт этот блок кандидатом для включения в историю.

7. Блок распространяется по сети и становится частью цепочки

Подписанный блок валидатор отправляет в сеть. Узлы начинают принимать его по p2p-протоколу:

проверяют подпись

сверяют заголовок и корни

убеждаются, что блок логично продолжает текущую цепочку

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

С этого момента транзакции внутри блока:

окончательно меняют состояние аккаунтов и контрактов

становятся частью истории Ethereum

могут использоваться как основа для следующих транзакций

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

Упростим до одной строки:

1. нажал Send
2. кошелёк собрал и подписал транзакцию
3. RPC проверил и передал её в мемпул
4. блок-билдеры выбрали её для блока
5. релеер проверил и выбрал лучший блок
6. валидатор подписал
7. блок разошёлся по сети и лёг в цепочку.

Смотреть видео - youtu.be/UIK2wXx_Ovg

VARTCALL

📟 Прилетело из @code_vartcall

Что тут будет происходить?

– Почему AI?
Сравним двух программистов: один из них использует AI, а другой — нет, — и посмотрим на их результаты и эффективность. Думаю, вывод очевиден. А с учётом того, сколько денег вкладывается в развитие AI, страшно представить, что будет через 5–10 лет. В любом случае не хочется, чтобы технология прошла мимо.

– Что тут будет выкладываться?
Когда я погружаюсь в новую тему, я делаю кучу конспектов (которые, как правило, потом даже не открываю). Раньше это были письменные записи, теперь — заметки в Notion (или на какой-либо другой платформе).
Так как это просто конспекты, которые я пишу для себя во время изучения новой темы, они не претендуют на гениальность и идеальность. Это просто структурированная информация для удобного использования.

– Чему будем учиться?
На данный момент нет чёткого плана, так как не хватает насмотренности, поэтому действуем в режиме максимального расфокуса и пробуем всё понемногу. Но цель этого мероприятия — заработать деньги на AI.
И да, постараемся не скатываться в сверхпростые темы, которые каждый может освоить за 1–2 дня — просто потому, что там слишком высокая конкуренция.

– Будет ли платный продукт?
Пока сам с этого не заработаю, курса, подписки или какой-либо иной монетизации не будет.

SemolinaCode | Chat | YouTube | HowToCode | Prop

📟 Прилетело из @semolina_code_python

Погружение в Core Solidity. Часть 1

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

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

А пока, давайте поговорим об обновлении языка Solidity - Core Solidity, о котором я писал не так давно. Разработчики выкатили небольшое описание функций системы, которые мы рассмотрим на этой неделе.

P.S. Далее будет идти перевод статьи от имени разработчиков.

Solidity — это самый широко используемый язык для написания смарт-контрактов. Он надёжен, заслуживает доверия и сегодня обеспечивает сохранность активов на сумму в сотни миллиардов долларов. Мы гордимся этим успехом и безупречной репутацией генерации безопасного кода. Однако пользователи Solidity прекрасно осознают некоторые его ограничения. Система типов зачастую недостаточно выразительна: она не позволяет создавать многократно используемый код библиотек или гарантировать ключевые свойства безопасности. Язык почти не поддерживает вычисления на этапе компиляции. Многие функции реализованы несогласованно или не всегда работают так, как ожидается.

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

Core Solidity — наше решение этой проблемы. Это полная переработка системы типов и фронтенд/мидл-энд компилятора Solidity, которая позволит:

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

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

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

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

Хотя прототип уже работает, он пока не оптимизирован для удобства пользователей. Мы активно продолжаем работу над прототипом, и новые функции будут постепенно появляться в репозитории проекта для обратной связи и экспериментов. Мы с нетерпением ждём ваших комментариев!

📟 Прилетело из @solidityset

Примечание о синтаксисе

Большая часть проделанной на сегодняшний день работы была сосредоточена на проектировании и реализации системы типов и связанного с ней конвейера генерации кода вплоть до Yul. Чтобы не увязнуть в бесконечных спорах о деталях синтаксиса и как можно скорее проверить наши ключевые идеи на рабочей реализации, мы решили использовать временный (провизорный) синтаксис. До релиза можно ожидать значительных изменений. В настоящее время мы стремимся в итоге максимально приблизить синтаксис Core Solidity к синтаксису классического Solidity. Что касается нового синтаксиса, то окончательная его версия, скорее всего, будет ближе к таким языкам, как TypeScript или Rust.

Новые языковые возможности

Core Solidity заимствует идеи из чистых функциональных языков программирования (например, Haskell, Lean), а также из современных системных языков (например, Rust, Zig). Мы расширяем Solidity следующими новыми возможностями:

- Алгебраические типы данных (известные также как суммы и произведения типов) и сопоставление с образцом (pattern matching)
- Обобщения (generics) / параметрический полиморфизм
- Трейты (traits) / классы типов (type classes)
- Вывод типов (type inference)
- Функции высшего порядка и анонимные функции
- Вычисления на этапе компиляции

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

Мы продолжим поддерживать низкоуровневый доступ к EVM, который часто необходим в промышленных реализациях: встроенная ассемблерная вставка (assembly) останется базовой языковой конструкцией, и мы расширим блоки ассемблера возможностью напрямую вызывать функции, определённые на высокоуровневом языке. Пользователи смогут отключать встроенные абстракции (например, автоматическую генерацию диспетчеризации контрактов, декодирование ABI, генерацию стандартной схемы хранения данных), следуя философии «плати только за то, чем пользуешься», характерной для таких языков, как Rust и C++.

Далее поговорим подробнее и с примерами.

#core

📟 Прилетело из @solidityset

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

📟 Прилетело из @dev_in_ruby_colors

1inch запускает Aqua — леер унифицированной ликвидности🏌

Перед тем как выложу обещанную (да-да, очень скоро) статью про стейблы — давайте глянем, что там интересного у 1inch.

1inch выкатывают Aqua — штуку, которая по сути унифицирует ликвидность между разными yield-инструментами, то есть теперь одна и та же ликвидность может работать сразу в нескольких yield стратегиях, повышая эффективность единицы капитала (ровно про это я уже писал в одной из прошлых моих статей)

Чтобы всё это не осталось просто идеей, они собрали:
— тулкит для билдеров (логично — кто-то же должен будет строить yield-инструменты внутри Aqua)
— инцентив программу с приятными бонусами в долларах, если сделать что-то реально годное

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

А пока, вот тут все ссылки для ознакомления
https://1inch.com/aqua
https://x.com/1inch/status/1990389518797557845?s=20

📟 Прилетело из @ortomich_main

gm! В продолжение прошлой темы давайте ретроспективно посмотрим, что вообще происходит в текущей DeFi-мете

С одной стороны — синтетические стейблы с доходностью и непрозрачным коллатералом.

С другой — волты, которые гонят APR за счёт лупинга и заливки ликвы в те самые high risk стейблы.

Кураторы при этом одни и те же, и рассчитывать на «справедливое» разруливание вроде кейса Re7 x MEV Capital, как мы уже увидели, особо не приходится.

При этом главная метрика DeFi-проектов до сих пор — TVL.
Но полноценно использовать этот TVL получается далеко не всегда: в отчётах Ethena хорошо видно, какая часть долларов реально задействована в стратегиях, а какая просто лежит idle. Тем же страдают и AMM-протоколы.

---

Кажется, 1inch решили предложить новую метрику — Total Unlocked Value.
В DeFi-конструкторе появляется новый слой shared liquidity: управляющие капиталом используют его атомарно для исполнения стратегий, а в остальное время средства остаются у пользователей под общим ончейн-учётом.

Ключевая идея Аквы достаточно простая: капитал остаётся в кошельках LP/мейкеров, а не в пуле.
Протокол ведёт виртуальные балансы maker → app → strategy → token, один и тот же капитал может одновременно бэкапить несколько стратегий.

То есть Aqua смещает фокус с «где выше APR и больше TVL» на вопрос «какие стратегии эффективнее используют один и тот же капитал по времени».

Из последнего интервью cp0x с Никитой Овчинниковым мы узнали, что солверы начинают захватывать рынок DEX-ов: у них банально лучше capital efficiency. Сейчас у каждого солвера свой оффчейн-слой управления балансами, и основная прибыль остаётся у них (пользователь видит только чуть более выгодный своп).

Aqua предлагает вынести этот shared-liquidity-слой ончейн и открыть к нему доступ внешним пользователям и LP. Для солверов и маркетмейкеров это потенциальный общий стандарт управления балансами, для девов — новый базовый слой, поверх которого можно строить волты, AMM/PMM и свои RFQ-решения.

---

Будет очень интересно посмотреть, как это поедет, но ощущение такое, что это как раз тот кусок паззла, которого не хватало последние полтора года: новые примитивы в DeFi. Тот же вайб я чувствую от yieldbasis, несмотря на плохой перфоманс rn

Кому интересно покопаться глубже — тут деврелиз и ссылки на SDK / WhitePaper / App Release (1инч, если вы читаете мой канал, вы забыли опубликовать репозиторий, хотя ссылка на него приведена в доке):

https://1inch.com/aqua

📟 Прилетело из @insuline_eth

Запись главных моментов урока - всё про переход на новую версию и написание тестов на Hardhat 3 https://www.youtube.com/watch?v=0BNeWYQk8F0

📟 Прилетело из @dev_in_ruby_colors

RUG RAG

Первой практической штукой, которую мы сделаем, будет RAG система

RAG (Retrieval-Augmented Generation) – это подход, при котором искусственный интеллект сначала находит нужную информацию в базе данных или документах (retrieval), а затем использует её для генерации ответа (generation).

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

RAG-системы применяются в чат-ботах, справочных ассистентах и корпоративных поисках — чтобы AI давал точные, актуальные и обоснованные ответы, цитируя источник, а не "выдумывал" их.

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

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

Читать: AI модели для чайников


SemolinaCode | Chat | YouTube | HowToCode | Prop

📟 Прилетело из @semolina_code_python