ethereum
Контракт, который продолжает выполнение после неудачного вызова, сегодня не имеет надежного способа определить, был ли откат вызванного контракта намеренным или просто вызван нехваткой газа, выбранной отправителем. Этот пробел является корнем атаки «недостаточного газа», и новое предварительное предложение пытается устранить его на уровне EVM. EIP-8456, открытое для обсуждения на Ethereum Magicians в понедельник, добавляет инструкцию под названием CALLSTATUS, предварительно с opcode 0xA5 за 2 газа. Она помещает статус завершения последнего вызова или создания операции в текущем фрейме в виде трех битов. Бит 0 означает откат, бит 1 — исключительную остановку, например, нехватку газа, а бит 2 — остановку в каком-либо фрейме ниже. Автор отмечает, что единственным доказательством сегодня является арифметика gasleft() после вызова, и каждый форк переоценки газа нарушал эти пороги. Предлагаемая двухмерная система газа EIP-8037 сделает эту арифметику еще слабее, поскольку ее резервуар недоступен через opcode GAS. Так почему же третий бит? Большинство реальных вызовов проходят через посредников, таких как прокси, обертка functionCall от OpenZeppelin, Multicall3 или проверщики подписей ERC-1271. Если бы сообщался только конечный статус прямого вызванного контракта, обертка, перехватывающая остановку из-за нехватки газа и выполняющая откат с причиной, выглядела бы как намеренный откат. Черновик сохраняет «липкий» флаг, который передается вверх по каждому фрейму, так что отправитель, контролирующий только газ, никогда не сможет заставить вызывающий контракт прочитать простой откат. Он сообщает результаты, а не причины, и вызванный контракт все еще может намеренно вызвать остановку с помощью INVALID. Он защищает только код, написанный после его внедрения, поскольку развернутые контракты его не будут читать. Пока нет внешних обзоров, номер opcode остается открытым, а прототип и тесты для 58 указанных случаев все еще ожидают реализации. Ссылка - https://t.co/KnByUBgWrY
Большинство кошельков Ethereum по-прежнему показывают всю вашу финансовую историю любому, кто имеет ваш адрес, и Фонд Ethereum теперь рассматривает это как уязвимость в безопасности, а не как дополнительное удобство в области конфиденциальности. В понедельник Фонд опубликовал, что атаки и эксплуатации за прошлую неделю сделали для них одним очевидным выводом: конфиденциальность и безопасность нельзя рассматривать как отдельные цели. Их позиция заключается в том, что вы можете меньше беспокоиться о том, что злоумышленник будет использовать вашу цепочечную историю против вас, если конфиденциальность будет стандартом по умолчанию. В посте приводится обновление по Kohaku — проекту инструментов для кошельков с приоритетом конфиденциальности от Фонда. Репозиторий на JavaScript разделён на пакеты, которые команда кошелька может подключать по одному. Существуют библиотеки для Privacy Pools и Tornado Cash, а также библиотека Railgun, которую в README текущим образом помечено как находящуюся в обслуживании. Пакет плагинов определяет стандартный интерфейс для протоколов защищённых пулов, чтобы кошелёк мог взаимодействовать со всеми ними одинаково. Пакет провайдера абстрагирует работу с ethers, viem, Helios и Colibri. Репозиторий также включает аккаунт ERC-4337, устойчивый к квантовым атакам. Rust-крейты находятся в отдельном смежном репозитории. Мне нравится, что это представлено как SDK, а не как ещё один кошелёк с конфиденциальностью, требующий от пользователей перемещения средств. Идея в том, чтобы существующие кошельки добавляли защищённые потоки, не переписывая каждый раз три протокола. В README честно указано текущее состояние проекта: Некоторые части помечены как непригодные для продакшена, а пакеты содержат неаудитированный код. Джордан Энев из Ambire заявил в прошлую пятницу, что команда тратила месяцы на тестирование интеграций, но публичная дата запуска пока не объявлена. Согласно расписанию сессий, Виталик и Никола Консьини проведут демонстрацию Kohaku с Ambire на Ethereum mainnet во вторник на @EFDevcon. Вот репозиторий — https://t.co/egNbLgAo0J
Ваш терминал теперь может отвечать вам, и забавно то, что он делает это без вызова каких-либо облачных API. В субботу Ollama выпустила версию 0.40.11 с функцией преобразования текста в речь на macOS. Первая модель речи — Phonon, семейство небольших TTS-моделей от Gradium. Её можно загрузить с помощью команды ollama pull phonon и запустить, как любую другую модель. То, что действительно заинтересует разработчиков — это API. Phonon работает с совместимым с OpenAI endpoint’ом /v1/audio/speech на localhost. Если ваш код уже использует OpenAI SDK для речи, в документации говорится, что вам нужно только изменить базовый URL. Ответ потоково передаётся во время генерации аудио, поэтому воспроизведение может начаться ещё до завершения генерации всего текста. Вы даже можете напрямую передать ответ чат-модели в Phonon — и она начнёт говорить сразу после первой фразы. Выходной формат — 24 кГц моно, по умолчанию в формате WAV или сырые 16-битные PCM, если вы запросите их. В документации перечислены некоторые ограничения, которые легко превысить. Каждый запрос может содержать до 4 096 символов, хотя ollama run автоматически разбивает более длинный текст. Цены, символы, электронные адреса и URL-адреса произносятся по буквам, а числовые даты читаются так, как они написаны, поэтому в документации рекомендуется писать даты словами. Неподдерживаемые параметры, такие как скорость или инструкции, возвращают ошибку 400, а не игнорируются молча. Лицензирование требует внимательного прочтения перед выпуском чего-либо. По умолчанию английская модель Phonon распространяется по лицензии Apache 2.0. Версии на французском, немецком, испанском, португальском и мультиязыковые версии объёмом 40 МБ распространяются по лицензии CC BY-NC 4.0, что исключает коммерческое использование. Ollama также сообщает, что на MacBook Pro с M5 Max модель работала на 35 % быстрее, чем собственный рантайм Gradium — это их собственный бенчмарк, а не независимый тест. На данный момент речь поддерживается только на Apple Silicon; поддержка Windows и Linux указана как предстоящая.
Ethereum L2, принимающий нулевые подписи, звучит как уязвимость безопасности, но BB84 делает это намеренно, чтобы избежать квантовых атак. В прошлые выходные его основатель, публикующийся как Hadamard, опубликовал дизайн на Ethereum Research и попросил критическую обратную связь. BB84 — это OP Stack rollup на мейннете, работающий с 30 сентября, где транзакции L2 вообще не содержат ECDSA. Каждый аккаунт — это конец цепочки хешей keccak-256, построенной из секрета, по умолчанию из 1000 шагов. Чтобы потратить средства, ваш кошелек раскрывает предыдущее значение в цепочке, которое любой может проверить, выполнив одно хеширование. Внутри L2 единственным допущением остаётся устойчивость keccak-256 к обратному преобразованию, которую алгоритм Гровера снижает примерно до 2^128 операций. Раскрытие секрета делает его публичным, поэтому протокол добавляет шаги commit и reveal, чтобы привязать каждое предизображение к одной транзакции. Два новых типа транзакций в op-geth обрабатывают это, а проверка отправителя заменяет ecrecover. Авторизация расходуется даже при откате вызова, и если кошелек пропускает шаг обновления на последней ссылке, этот адрес становится мёртвым. В посте также описан недостаток подмены транзакций, который команда обнаружила при его написании. Коммиты не содержат подписей, поэтому новый коммит раньше мог заменить ожидающий, и злоумышленник мог перепривязать раскрытое предизображение к своей собственной оплате. Правило, вступившее в силу 21 октября, делает победителем первый коммит. Ограничения изложены прямо. Депозиты и выводы на L1 по-прежнему используют ECDSA. Пока нет fault proofs, и по собственному признанию автора, цепочка даже не достигла Stage 0 на L2BEAT. Секвенсер запущен командой, а 160-битные адреса обеспечивают примерно 2^80 квантовой устойчивости ко второму прообразу. В посте также спрашивается, могут ли аккаунты на основе цепочки хешей стать EIP-7702 или нативным режимом валидации абстракции аккаунтов для общих L2.
OpenZeppelin сделала Chainlink стандартом для межцепочечных операций и соответствия в своем инструментарии токенов, и если вы отметите флажок соответствия, лицензия вашего токена изменится. Неделю назад OpenZeppelin объявила о стратегическом партнерстве с Chainlink. CCIP и ACE — межцепочечный протокол Chainlink и его Automated Compliance Engine — теперь встроены в Contracts Wizard, инструментарий OpenZeppelin на базе ИИ, и в его документацию. Генераторы ERC20, стейблкоинов и RWA предлагают оба варианта. Выбор опции CCIP позволяет токену открывать вызовы mint и burn, необходимые пулу сжигания и выпуска Chainlink, через собственные разрешения токена. Также указывается администратор для регистрации CCIP. Эта часть сохраняет выбранную вами лицензию, поскольку код Chainlink не встраивается. Опция ACE отличается. Она перенаправляет переводы, выпуски и сжигания на Policy Engine, который вы развертываете и настраиваете. Собственные документы OpenZeppelin указывают, что токены, использующие ACE, попадают под лицензию BUSL-1.1, а использование в продакшене должно соответствовать лицензии ACE и дополнительным разрешениям на использование. В течение многих лет сгенерированный токен OpenZeppelin носил ту лицензию, которую вы выбирали — обычно MIT. Теперь один флажок меняет это, и младший разработчик в спешке может этого не заметить. Генератор не регистрирует ваш пул, не настраивает разрешения и не пишет ваши политики. Подключение Policy Engine не настраивает никакую политику, и вы остаетесь ответственными за соблюдение всех применимых правил. В объявлении также упоминается путь миграции с OpenZeppelin Defender на Runtime Environment Chainlink. Все это не скрыто, и для команды RWA, которая уже хочет использовать Chainlink, это экономит реальную работу по интеграции. Я просто хочу, чтобы разработчики выбирали это осознанно, а не потому, что мастер его предложил.
Смарт-контрактные мэксисы, Ваш компилятор Solidity мог тихо удалить запись, которая вам была нужна, и вы никогда не увидите этого в исходном коде. Solidity 0.8.38 вышла в прошлый четверг. Она исправляет ошибку в оптимизаторе Yul, присутствовавшую во всех версиях с 0.8.19 по 0.8.37. Оптимизатор ведёт учёт того, что находится в памяти и хранилище. Он использует эти данные, чтобы заменить загрузку значением, которое уже известно, и пропустить запись, которая сохраняет то, что уже есть. Чтобы определить, могут ли два адреса перекрываться, он описывает каждый из них как базовую переменную плюс смещение. Одинаковая база, разное смещение — значит, это разные слоты. Эти описания кэшировались. Затем кто-то переassign-ит базовую переменную. Оптимизатор не всегда это замечает. Теперь он сравнивает адрес, построенный по старому значению, с адресом, построенным по новому значению, как будто они имеют общую базу. Он решает, что они разные, но во время выполнения они указывают на одно и то же место. Результат — устаревшая запись. Поздняя загрузка может вернуть старое значение. Запись, которая вам была нужна, может быть удалена. Keccak256 над этим местом может хешировать устаревшие данные. Подвержены только коды, скомпилированные с включённым оптимизатором. С via-IR — любой код может столкнуться с этой ошибкой, даже без встроенной сборки. Со стандартной устаревшей цепочкой — только некоторые встроенные сборки и вспомогательные функции, генерируемые компилятором. Сборки без оптимизации безопасны. Команда оценивает её как низкую степень серьёзности, и они сделали то, чего я хотел бы видеть от каждой команды компиляторов: они повторно скомпилировали каждый подтверждённый контракт из базы данных Sourcify с исправлением и без него — байт-код у всех остался идентичным. Так что это редко. Редко — не значит никогда, особенно если ваш код свежий и ещё не развернут. Ошибка была обнаружена через баг-бонти Ethereum Foundation, и второй отчёт показал, что обычный Solidity без сборки тоже может её вызвать.
Мужской импульс стать макси ETH. 🥳
Ethereum — это Ethereum, и всегда так будет. На следующем форке сообщество Ethereum увидит настоящую магию протокола.