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 мейннеті на @EFDevcon у наступний вівторок, згідно з розкладом сесій. ось репозиторій - https://t.co/egNbLgAo0J
Ваш термінал тепер може відповідати вам, і дивно те, що він робить це, не викликаючи жодного хмарного API. У суботу Ollama випустила версію 0.40.11 з підтримкою тексту в голос на macOS. Першою мовою для голосу є Phonon — сімейство невеликих TTS-моделей від Gradium. Ви завантажуєте її за допомогою ollama pull phonon і запускаєте, як будь-яку іншу модель. Те, що справді зацікавить розробників — це API. Phonon працює з ендпоінтом /v1/audio/speech, сумісним з OpenAI, на 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 робить це навмисно, щоб уникнути квантових атак. Minулого вихідного день її засновник, який публікує під ім’ям Hadamard, опублікував дизайн на Ethereum Research і попросив критичні зауваження. BB84 — це OP Stack rollup на мейннеті, який працює з 30 вересня, де транзакції L2 взагалі не мають ECDSA. Кожен акаунт — це кінець ланцюга хешів keccak-256, побудованого з секрету, за замовчуванням з 1000 кроків. Щоб витратити кошти, ваш гаманець розкриває попереднє значення в ланцюзі, що будь-хто може перевірити одним хешуванням. Усередині L2 єдиним припущенням залишається стійкість до зворотного хешування keccak-256, яку алгоритм Гровера зменшує до приблизно 2^128 операцій. Розкриття секрету робить його публічним, тому протокол додає крок коміту та розкриття, щоб прив’язати кожен преімедж до однієї транзакції. Два нових типи транзакцій у op-geth обробляють це, а перевірка відправника замінює ecrecover. Авторизація споживається навіть у разі відмови виклику, і якщо гаманець пропустить крок оновлення на останньому ланцюжку, ця адреса стає мертвою. У дописі також зазначено вразливість до фронт-раннінгу, яку команда виявила під час написання. Коміти не мають підпису, тому новий коміт раніше міг замінити очікуючий, і зловмисник міг переприв’язати розкритий секрет до власної платіжної операції. Правило, яке вступило в силу 21 жовтня, робить переможцем перший коміт. Обмеження чітко вказані. Депозити та виведення на L1 все ще використовують ECDSA. Ще немає fault proofs, і за власними словами автора, ланцюжок навіть не досягне етапу 0 L2BEAT. Секвенсер управляється командою, а 160-бітні адреси забезпечують приблизно 2^80 квантової стійкості до другого преімеджу. У дописі також ставиться питання: чи можуть облікові записи на основі ланцюга хешів стати EIP-7702 або нативним режимом перевірки абстракції акаунтів для загальних L2.
OpenZeppelin зробив Chainlink стандартним рішенням для крос-чейн взаємодії та відповідності у своїх інструментах для токенів, і якщо ви позначите чекбокс відповідності, ліцензія вашого токена змінюється. Тиждень тому OpenZeppelin оголосила про стратегічний партнерство з Chainlink. CCIP та ACE — крос-чейн протокол Chainlink та його Automated Compliance Engine — тепер інтегровані у Contracts Wizard, інструменти AI та документацію OpenZeppelin. Генератори ERC20, стейблкоїнів та RWA пропонують обидва варіанти. Вибір опції CCIP дозволяє токену відкривати виклики mint та burn, необхідні для пулу burn-and-mint Chainlink, за межами власних дозволів токена. Також вказується адміністратор для реєстрації CCIP. Ця частина зберігає вашу вибрану ліцензію, оскільки код Chainlink не включається. Опція ACE відрізняється. Вона пересилає перекази, mint та burn до 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. Оптимізатор зберігає інформацію про те, що знаходиться в пам’яті та сховищі. Він використовує цю інформацію, щоб замінити завантаження значенням, яке вже відоме, та пропустити запис, який записує те, що вже є. Щоб визначити, чи можуть два адреси перекриватися, він описує кожну з них як базову змінну плюс зсув. Однакова база, різний зсув — отже, це повинні бути різні слоти. Ці описи кешувалися. Потім хтось змінював базову змінну. Оптимізатор не завжди це помічає. Тепер він порівнює адресу, побудовану зі старого значення, з адресою, побудованою з нового значення, якби вони мали спільну базу. Він вирішує, що вони різні, але під час виконання вони вказують на одне й те саме місце. Результат — застарілий запис. Пізніше завантаження може повернути старе значення. Запис, який вам знадобився, може бути видалений. Keccak256 над цим місцем може хешувати застарілі дані. Піддаються ризику лише коди, скомпільовані з увімкненим оптимізатором. З via-IR — будь-який код може стати жертвою, навіть без вбудованого асемблера. Зі стандартним старим конвеєром — лише деякі вбудовані асемблерні фрагменти та допоміжні функції компілятора. Незоптимізований код безпечний. Команда оцінила це як низький рівень серйозності, і вони зробили те, чого я бажав би від кожної команди компілятора: вони повторно скомпілювали всі підтверджені смартконтракти з бази даних Sourcify з увімкненим та вимкненим виправленням — байт-код у всіх випадках був ідентичним. Отже, це рідкісне явище. Рідкісне — не означає «ніколи», особливо якщо ваш код новий і ще не розгорнуто. Цей баг був виявлений через баг-бант Ethereum Foundation, а другий звіт показав, що його можна спровокувати навіть чистим Solidity-кодом без асемблера.
Чоловіча потреба бути ETH maxi. 🥳
Ethereum — це Ethereum, і завжди таким залишиться. На наступному форку спільнота Ethereum побачить справжнє чарівність протоколу.