gakonst

15-20% быстрее обработка блоков Ethereum на Reth v1.5.0.

скоро будет больше!

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

Если вы инженер Reth и работаете с рекрутерами, не стесняйтесь обращаться ко мне напрямую.

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

Можете ли вы создать стейблкоин из производных биткойн-хешрейта?

Пользователи не должны платить газовые сборы, приложения должны.

Пример NextJS для спонсирования сборов в Порто только что появился (ссылка в теме)

Фронтиры от @Paradigm обновление! 6-8 августа, Сан-Франциско.

Второй день выглядит 🔥🔥🔥 .

Не 1, не 2, а 3 доклада о высокой производительности!
- "Гипероптимизация Reth" от @ashekhirin и @Rjected
- "Масштабирование состояния Ethereum" от @brianisbland
- "Масштабирование Ethereum L1" от @adietrichs.

Подайте заявку ниже!

Какой самый быстрый folding / IVC SNARK на данный момент?

Есть ли у него оптимизированная реализация?

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

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

Вещи, которые в конечном итоге не помогут Ethereum победить в Гламстаде: EOF, EVM64, SSZ/pureth, Доступные Атистаты.

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

RE: что должно произойти с EL Эфириума, мое текущее мнение:
- Fusaka получает легкие победы и устанавливает пределы для повышения лимита газа.
- Glamsterdam продолжает увеличивать лимит газа, переоценивая при этом наихудшие сценарии.

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

Фусака состоится в этом году и позволит L2 дальше масштабироваться.

БLOB'ы останутся прежними при запуске, и с заранее запланированными форками только для БЛОБ'ов они, надеюсь, увеличатся до 48 примерно к первому кварталу 2026 года.

Мы будем продолжать измерять и смотреть, насколько высоко мы сможем подняться, инструменты есть, теперь только репетitions.

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

в этом PR мы делимся подсказками, где Claude успешно создал линтер для проверки вызовов EVM низкого уровня для Forge Lint (по умолчанию запускается при сборке forge)

https://github.com/foundry-rs/foundry/pull/10810

Что я считаю важным для победы Ethereum при сохранении глобального набора узлов:

1. отделить валидацию от построения блоков с помощью zk. Это требует упрощения создания zk-доказательств блоков в реальном времени: ePBS или Отложенное Исполнение, мне все равно, что. Миграции trie помогают, но, на мой взгляд, не обязательны, в то время как обеспечение доказательства в начале слота, а не в конце, действительно имеет значение.

2. отделить сопротивление цензуре от самого слабого узла. Если вы сделаете вышеизложенное, введение узлов с низким стейком ETH с FOCIL, которые отвечают только за CR, но не за построение блоков и валидацию на горячем пути, освободит нас от использования Raspberry Pi для масштабирования, но позволит нам продолжать использовать Raspberry Pi для CR.

Что я считаю важным для победы Ethereum при сохранении глобального набора узлов:

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

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

Я все еще в недоумении, что сообщество разработчиков Ethereum Core не приоритизирует решение двух самых упоминаемых проблем разработчиков EVM согласно опросу Solidity Lang, несмотря на наши постоянные усилия:

1. Слишком глубокий стек: да, это немного проблема навыков Solidity, но просто добавьте диапазон операций SWAP/DUP17-32 и закончите с этим. Вы сожжете некоторые операции. Это нормально, они предназначены для использования. У вас будет несовпадение в стиле PUSH0, это тоже нормально, это не идеально, но это нормально.

2. Увеличьте лимит в 24KB. Мне не важно, что вы сделаете, сделайте 32KB, 48KB, 128KB, 256KB, 512KB, сделайте это все сразу, постепенно, оцените это или нет, но сделайте что-то! Сейчас, а не в следующем году!

Если вы масштабируете L1, то обеспечение возможности людям писать контракты без глупых ошибок является приоритетом 0.

Если система не может справиться с дополнительными 8KB на байт-код, что является параметром, установленным 10 лет назад, то у вас нет шансов действительно масштабировать L1.

Исправьте слишком глубокий стек и лимит размера байт-кода! Для разработчиков!

Я все еще в недоумении, что сообщество разработчиков Ethereum Core не придает приоритетного значения исправлению двух самых упоминаемых проблем разработчиков EVM согласно опросу Solidity Lang:

1. Слишком глубокий стек: да, это немного проблема навыков Solidity, но просто добавьте диапазон операций SWAP/DUP17-32 и закончите с этим. Вы сожжете некоторые операции. Это нормально, они предназначены для использования. У вас будет еще одно несоответствие стиля PUSH0, это тоже нормально, это не идеально, но это нормально.

2. Поднимите предел в 24 КБ. Мне не важно, что вы сделаете, сделайте 32 КБ, 48 КБ, 128 КБ, 256 КБ, 512 КБ, сделайте это все сразу, поэтапно, установите цену или нет, но сделайте что-нибудь! Сейчас, а не в следующем году!

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

Если система не может обрабатывать дополнительные 8 КБ на байт-код, который был установлен 10 лет назад, то у вас нет шансов действительно масштабировать L1.

Исправьте слишком глубокий стек и лимит размера байт-кода! Для разработчиков!

Я все еще недоумеваю, что сообщество разработчиков Ethereum Core не приоритизирует решение самой часто упоминаемой проблемы разработчиков EVM согласно опросу Solidity Lang.

1. Слишком глубокий стек: да, это немного проблема навыков Solidity, но просто добавьте диапазон опкодов SWAP/DUP17-32 и закончите с этим. Вы сожжете некоторые опкоды. Это нормально, они предназначены для использования. У вас будет еще одно несоответствие в стиле PUSH0, это тоже нормально, это не идеально, но это нормально.

2. Уберите лимит в 24КБ. Мне не важно, что вы сделаете, сделайте это 32КБ, 48КБ, 128КБ, 256КБ, 512КБ, сделайте все сразу, поэтапно, оцените это или нет, но сделайте что-то! Прямо сейчас, а не в следующем году!

Если вы масштабируете L1, обеспечение возможности писать контракты без глупых ошибок - это P0.

Если система не может обрабатывать дополнительные 8КБ на байт-код, что является параметром, установленным 10 лет назад, то у вас нет шансов действительно масштабировать L1.

Исправьте слишком глубокий стек и лимит размера байт-кода! Для разработчиков!

Каждый элемент криптоинфраструктуры так или иначе будет взаимодействовать с Reth.

Самое важное для его успеха - это, безусловно, сообщество OSS. Подготовленная группа из более чем 500 геораспределенных людей, которые внесли свой вклад в Reth и верят в видение и его долгосрочный успех.

На техническом уровне проект Reth имеет 3 опоры:
- Безопасность: Мы достигаем этого, поддерживая Ethereum L1 в производственных staking-окружениях. Имеем долю в игре.
- Производительность: Мы достигаем этого, продвигая границы на L2 и MEV блокостроении. Terragas.
- Расширяемость: Мы предоставляем отличные API для модификации вашего узла без форкинга. Reth SDK.

Еще так много нужно сделать, но мы действительно гордимся тем, где мы находимся сегодня.