[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-9-yazyk-huff-makrosy-metki-opkody":3},{"article":4,"author":59},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":7,"meta_description":16,"focus_keyword":17,"og_image":18,"canonical_url":18,"robots_meta":19,"created_at":15,"updated_at":15,"tags":20,"category_name":38,"related_articles":39},"d0000000-0000-0000-0000-000000000209","a0000000-0000-0000-0000-000000000012","Deep EVM #9: Язык Huff — макросы, метки и сырые опкоды","deep-evm-9-yazyk-huff-makrosy-metki-opkody","Практическое введение в Huff — низкоуровневый язык ассемблера EVM, дающий полный контроль над каждым опкодом, каждым байтом байткода и каждой единицей газа.","## Зачем нужен Huff\n\nSolidity — замечательная абстракция, пока вы не упрётесь в её ограничения. Когда контракт должен уместиться в 100 байт рантайм-байткода, диспатчить функции за O(1) через упакованную jump-таблицу или сэкономить 200 газа на горячем пути, который исполняется миллионы раз в сутки, вам нужно нечто ближе к железу. Это нечто — **Huff**.\n\nHuff — низкоуровневый язык ассемблера EVM с тонкой макросистемой поверх. Нет переменных, нет типов, нет компилятора, который оптимизирует за вашей спиной. Что вы написали — то и окажется on-chain, опкод за опкодом.\n\n## Установка Huff\n\nКаноничный компилятор — `huffc`, написанный на Rust:\n\n```bash\ncurl -L get.huff.sh | bash\nhuffup\nhuffc --version\n```\n\nКоманда устанавливает `huffc` в `~\u002F.huff\u002Fbin`. Добавьте директорию в PATH и проверьте:\n\n```bash\n$ huffc --version\nhuffc 0.3.2\n```\n\nВы также можете использовать Huff внутри Foundry-проектов с помощью `foundry-huff`, который позволяет деплоить `.huff` файлы так же, как `.sol`.\n\n## Hello World: минимальный контракт\n\nНапишем контракт, возвращающий 32-байтное слово `0x01` на любой вызов:\n\n```huff\n#define macro MAIN() = takes(0) returns(0) {\n    0x01            \u002F\u002F [0x01]\n    0x00            \u002F\u002F [0x00, 0x01]\n    mstore          \u002F\u002F []          — memory[0x00..0x20] = 0x01\n    0x20            \u002F\u002F [0x20]\n    0x00            \u002F\u002F [0x00, 0x20]\n    return          \u002F\u002F halt — return memory[0x00..0x20]\n}\n```\n\nКомпиляция:\n\n```bash\nhuffc src\u002FHelloWorld.huff -r\n```\n\nФлаг `-r` выводит рантайм-байткод. Вы увидите что-то вроде `600160005260206000f3` — 10 байт. Контракт на Solidity, возвращающий `1`, компилируется в ~200+ байт рантайм-байткода, потому что solc генерирует полный диспатчер функций, хеш метаданных, инициализацию free memory pointer и ABI-кодировщик.\n\n## Макросы vs функции\n\nHuff имеет два примитива повторного использования: **макросы** и **функции**.\n\n### Макросы (`#define macro`)\n\nМакросы инлайнятся в каждом месте вызова. Нет оверхеда JUMP, нет лишнего газа — компилятор буквально копирует опкоды в вызывающий код. Это выбор по умолчанию для критичного по газу кода.\n\n```huff\n#define macro REQUIRE_NOT_ZERO() = takes(1) returns(0) {\n    \u002F\u002F takes: [value]\n    continue        \u002F\u002F [continue_dest, value]\n    jumpi           \u002F\u002F []  — jump if value != 0\n    0x00 0x00 revert\n    continue:\n}\n```\n\n### Функции (`#define fn`)\n\nФункции генерируют реальную пару JUMP\u002FJUMPDEST. Они экономят размер байткода ценой ~22 лишних газа за вызов (8 за JUMP + 1 за JUMPDEST + манипуляции со стеком). Используйте только когда размер байткода важнее газа.\n\n```huff\n#define fn safe_add() = takes(2) returns(1) {\n    \u002F\u002F takes: [a, b]\n    dup2 dup2       \u002F\u002F [a, b, a, b]\n    add             \u002F\u002F [sum, a, b]\n    dup1            \u002F\u002F [sum, sum, a, b]\n    swap2           \u002F\u002F [a, sum, sum, b]\n    gt              \u002F\u002F [overflow?, sum, b]\n    overflow jumpi\n    swap1 pop       \u002F\u002F [sum]\n    back jump\n    overflow:\n        0x00 0x00 revert\n    back:\n}\n```\n\n## Метки и точки перехода\n\nМетки в Huff — именованные JUMPDEST-локации. Компилятор разрешает их в конкретные смещения байткода во время компиляции.\n\n```huff\n#define macro LOOP_EXAMPLE() = takes(1) returns(1) {\n    \u002F\u002F takes: [n]\n    0x00                \u002F\u002F [acc, n]\n    loop:\n        dup2            \u002F\u002F [n, acc, n]\n        iszero          \u002F\u002F [n==0?, acc, n]\n        done jumpi      \u002F\u002F [acc, n]\n        swap1           \u002F\u002F [n, acc]\n        0x01 swap1 sub  \u002F\u002F [n-1, acc]\n        swap1           \u002F\u002F [acc, n-1]\n        0x01 add        \u002F\u002F [acc+1, n-1]\n        loop jump\n    done:\n        swap1 pop       \u002F\u002F [acc]\n}\n```\n\nКаждая метка компилируется в один байт `JUMPDEST` (`0x5b`). Ссылки (`loop jump`, `done jumpi`) компилируются в `PUSH2 \u003Coffset> JUMP` (или `JUMPI`). Это в точности то, что вы бы написали вручную на сыром ассемблере EVM — Huff просто берёт на себя учёт смещений.\n\n## takes() и returns()\n\nАннотации `takes(n)` и `returns(m)` на макросах и функциях — документация и подсказки компилятору. Они сообщают читателю (и стековому чекеру `huffc`), сколько элементов стека блок ожидает потребить и произвести.\n\n```huff\n#define macro ADD_TWO() = takes(2) returns(1) {\n    add  \u002F\u002F потребляет 2 элемента, производит 1\n}\n```\n\nЕсли реальное поведение стека не совпадает с аннотацией, `huffc` выдаст предупреждение. Рассматривайте аннотации как бедную систему типов — они предотвращают случайное оставление мусора на стеке или underflow.\n\n## Сравнение: Huff vs Solidity байткод\n\nРассмотрим простую view-функцию `getValue()`, возвращающую слот хранилища:\n\n**Solidity:**\n```solidity\nfunction getValue() external view returns (uint256) {\n    return value;\n}\n```\n\nSolc генерирует ~40 байт для диспатчера + ABI-кодирования.\n\n**Huff-эквивалент:**\n```huff\n#define function getValue() view returns (uint256)\n\n#define macro GET_VALUE() = takes(0) returns(0) {\n    [VALUE_SLOT]    \u002F\u002F [slot]\n    sload           \u002F\u002F [value]\n    0x00 mstore     \u002F\u002F []  — store in memory\n    0x20 0x00 return\n}\n```\n\nHuff-версия — 12 байт байткода для тела. Нет оверхеда ABI-кодирования, нет free memory pointer, нет хеша метаданных. Когда вы контролируете вызывающий код (например, MEV-бот вызывает собственный контракт), вы можете убрать всё, что solc считает необходимым.\n\n## Константы и слоты хранилища\n\nКонстанты Huff — значения, вычисляемые во время компиляции, которые инлайнятся как PUSH-инструкции:\n\n```huff\n#define constant VALUE_SLOT = 0x00\n#define constant OWNER_SLOT = 0x01\n#define constant MAX_UINT = 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\n```\n\nИспользование: `[VALUE_SLOT]` кладёт `0x00`, `[MAX_UINT]` — полное 32-байтное значение. Константы улучшают читаемость без затрат газа.\n\n## Инклюды и структура проекта\n\nРеальные Huff-проекты разносят код по нескольким файлам:\n\n```huff\n\u002F\u002F src\u002FMain.huff\n#include \".\u002Futils\u002FSafeMath.huff\"\n#include \".\u002Finterfaces\u002FIERC20.huff\"\n#include \".\u002FDispatcher.huff\"\n\n#define macro MAIN() = takes(0) returns(0) {\n    DISPATCHER()\n}\n```\n\nСистема инклюдов — простое текстовое включение, без модульной области видимости или пространств имён. Тщательно именуйте макросы во избежание коллизий.\n\n## Когда использовать Huff\n\nHuff — не язык общего назначения. Используйте его когда:\n\n1. **Газ — главное ограничение** — MEV-контракты, где 100 газа определяют прибыльность.\n2. **Размер байткода критичен** — контракты, деплоимые другими контрактами (CREATE2-фабрики).\n3. **Нужен кастомный диспатч** — jump-таблицы, бит-упакованные селекторы, нестандартное ABI.\n4. **Вы изучаете EVM** — ничто не учит EVM лучше, чем написание сырых опкодов.\n\nДля всего остального пишите на Solidity и читайте вывод компилятора через `solc --asm`.\n\n## Итоги\n\nHuff даёт прямой доступ к байткоду EVM с минимальной абстракцией. Макросы инлайнят код с нулевым оверхедом. Метки берут на себя учёт смещений. Аннотации `takes`\u002F`returns` ловят стековые ошибки на ранних этапах. В следующей статье мы глубже погрузимся в управление стеком — искусство `dup`, `swap` и синхронизации ментальной модели стека с реальностью.","\u003Ch2 id=\"huff\">Зачем нужен Huff\u003C\u002Fh2>\n\u003Cp>Solidity — замечательная абстракция, пока вы не упрётесь в её ограничения. Когда контракт должен уместиться в 100 байт рантайм-байткода, диспатчить функции за O(1) через упакованную jump-таблицу или сэкономить 200 газа на горячем пути, который исполняется миллионы раз в сутки, вам нужно нечто ближе к железу. Это нечто — \u003Cstrong>Huff\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>Huff — низкоуровневый язык ассемблера EVM с тонкой макросистемой поверх. Нет переменных, нет типов, нет компилятора, который оптимизирует за вашей спиной. Что вы написали — то и окажется on-chain, опкод за опкодом.\u003C\u002Fp>\n\u003Ch2 id=\"huff\">Установка Huff\u003C\u002Fh2>\n\u003Cp>Каноничный компилятор — \u003Ccode>huffc\u003C\u002Fcode>, написанный на Rust:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">curl -L get.huff.sh | bash\nhuffup\nhuffc --version\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Команда устанавливает \u003Ccode>huffc\u003C\u002Fcode> в \u003Ccode>~\u002F.huff\u002Fbin\u003C\u002Fcode>. Добавьте директорию в PATH и проверьте:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">$ huffc --version\nhuffc 0.3.2\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Вы также можете использовать Huff внутри Foundry-проектов с помощью \u003Ccode>foundry-huff\u003C\u002Fcode>, который позволяет деплоить \u003Ccode>.huff\u003C\u002Fcode> файлы так же, как \u003Ccode>.sol\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch2 id=\"hello-world\">Hello World: минимальный контракт\u003C\u002Fh2>\n\u003Cp>Напишем контракт, возвращающий 32-байтное слово \u003Ccode>0x01\u003C\u002Fcode> на любой вызов:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">#define macro MAIN() = takes(0) returns(0) {\n    0x01            \u002F\u002F [0x01]\n    0x00            \u002F\u002F [0x00, 0x01]\n    mstore          \u002F\u002F []          — memory[0x00..0x20] = 0x01\n    0x20            \u002F\u002F [0x20]\n    0x00            \u002F\u002F [0x00, 0x20]\n    return          \u002F\u002F halt — return memory[0x00..0x20]\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Компиляция:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">huffc src\u002FHelloWorld.huff -r\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Флаг \u003Ccode>-r\u003C\u002Fcode> выводит рантайм-байткод. Вы увидите что-то вроде \u003Ccode>600160005260206000f3\u003C\u002Fcode> — 10 байт. Контракт на Solidity, возвращающий \u003Ccode>1\u003C\u002Fcode>, компилируется в ~200+ байт рантайм-байткода, потому что solc генерирует полный диспатчер функций, хеш метаданных, инициализацию free memory pointer и ABI-кодировщик.\u003C\u002Fp>\n\u003Ch2 id=\"vs\">Макросы vs функции\u003C\u002Fh2>\n\u003Cp>Huff имеет два примитива повторного использования: \u003Cstrong>макросы\u003C\u002Fstrong> и \u003Cstrong>функции\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Ch3>Макросы (\u003Ccode>#define macro\u003C\u002Fcode>)\u003C\u002Fh3>\n\u003Cp>Макросы инлайнятся в каждом месте вызова. Нет оверхеда JUMP, нет лишнего газа — компилятор буквально копирует опкоды в вызывающий код. Это выбор по умолчанию для критичного по газу кода.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">#define macro REQUIRE_NOT_ZERO() = takes(1) returns(0) {\n    \u002F\u002F takes: [value]\n    continue        \u002F\u002F [continue_dest, value]\n    jumpi           \u002F\u002F []  — jump if value != 0\n    0x00 0x00 revert\n    continue:\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Функции (\u003Ccode>#define fn\u003C\u002Fcode>)\u003C\u002Fh3>\n\u003Cp>Функции генерируют реальную пару JUMP\u002FJUMPDEST. Они экономят размер байткода ценой ~22 лишних газа за вызов (8 за JUMP + 1 за JUMPDEST + манипуляции со стеком). Используйте только когда размер байткода важнее газа.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">#define fn safe_add() = takes(2) returns(1) {\n    \u002F\u002F takes: [a, b]\n    dup2 dup2       \u002F\u002F [a, b, a, b]\n    add             \u002F\u002F [sum, a, b]\n    dup1            \u002F\u002F [sum, sum, a, b]\n    swap2           \u002F\u002F [a, sum, sum, b]\n    gt              \u002F\u002F [overflow?, sum, b]\n    overflow jumpi\n    swap1 pop       \u002F\u002F [sum]\n    back jump\n    overflow:\n        0x00 0x00 revert\n    back:\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"\">Метки и точки перехода\u003C\u002Fh2>\n\u003Cp>Метки в Huff — именованные JUMPDEST-локации. Компилятор разрешает их в конкретные смещения байткода во время компиляции.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">#define macro LOOP_EXAMPLE() = takes(1) returns(1) {\n    \u002F\u002F takes: [n]\n    0x00                \u002F\u002F [acc, n]\n    loop:\n        dup2            \u002F\u002F [n, acc, n]\n        iszero          \u002F\u002F [n==0?, acc, n]\n        done jumpi      \u002F\u002F [acc, n]\n        swap1           \u002F\u002F [n, acc]\n        0x01 swap1 sub  \u002F\u002F [n-1, acc]\n        swap1           \u002F\u002F [acc, n-1]\n        0x01 add        \u002F\u002F [acc+1, n-1]\n        loop jump\n    done:\n        swap1 pop       \u002F\u002F [acc]\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Каждая метка компилируется в один байт \u003Ccode>JUMPDEST\u003C\u002Fcode> (\u003Ccode>0x5b\u003C\u002Fcode>). Ссылки (\u003Ccode>loop jump\u003C\u002Fcode>, \u003Ccode>done jumpi\u003C\u002Fcode>) компилируются в \u003Ccode>PUSH2 <offset> JUMP\u003C\u002Fcode> (или \u003Ccode>JUMPI\u003C\u002Fcode>). Это в точности то, что вы бы написали вручную на сыром ассемблере EVM — Huff просто берёт на себя учёт смещений.\u003C\u002Fp>\n\u003Ch2 id=\"takes-returns\">takes() и returns()\u003C\u002Fh2>\n\u003Cp>Аннотации \u003Ccode>takes(n)\u003C\u002Fcode> и \u003Ccode>returns(m)\u003C\u002Fcode> на макросах и функциях — документация и подсказки компилятору. Они сообщают читателю (и стековому чекеру \u003Ccode>huffc\u003C\u002Fcode>), сколько элементов стека блок ожидает потребить и произвести.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">#define macro ADD_TWO() = takes(2) returns(1) {\n    add  \u002F\u002F потребляет 2 элемента, производит 1\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Если реальное поведение стека не совпадает с аннотацией, \u003Ccode>huffc\u003C\u002Fcode> выдаст предупреждение. Рассматривайте аннотации как бедную систему типов — они предотвращают случайное оставление мусора на стеке или underflow.\u003C\u002Fp>\n\u003Ch2 id=\"huff-vs-solidity\">Сравнение: Huff vs Solidity байткод\u003C\u002Fh2>\n\u003Cp>Рассмотрим простую view-функцию \u003Ccode>getValue()\u003C\u002Fcode>, возвращающую слот хранилища:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Solidity:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">function getValue() external view returns (uint256) {\n    return value;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Solc генерирует ~40 байт для диспатчера + ABI-кодирования.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Huff-эквивалент:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">#define function getValue() view returns (uint256)\n\n#define macro GET_VALUE() = takes(0) returns(0) {\n    [VALUE_SLOT]    \u002F\u002F [slot]\n    sload           \u002F\u002F [value]\n    0x00 mstore     \u002F\u002F []  — store in memory\n    0x20 0x00 return\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Huff-версия — 12 байт байткода для тела. Нет оверхеда ABI-кодирования, нет free memory pointer, нет хеша метаданных. Когда вы контролируете вызывающий код (например, MEV-бот вызывает собственный контракт), вы можете убрать всё, что solc считает необходимым.\u003C\u002Fp>\n\u003Ch2 id=\"\">Константы и слоты хранилища\u003C\u002Fh2>\n\u003Cp>Константы Huff — значения, вычисляемые во время компиляции, которые инлайнятся как PUSH-инструкции:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">#define constant VALUE_SLOT = 0x00\n#define constant OWNER_SLOT = 0x01\n#define constant MAX_UINT = 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Использование: \u003Ccode>[VALUE_SLOT]\u003C\u002Fcode> кладёт \u003Ccode>0x00\u003C\u002Fcode>, \u003Ccode>[MAX_UINT]\u003C\u002Fcode> — полное 32-байтное значение. Константы улучшают читаемость без затрат газа.\u003C\u002Fp>\n\u003Ch2 id=\"\">Инклюды и структура проекта\u003C\u002Fh2>\n\u003Cp>Реальные Huff-проекты разносят код по нескольким файлам:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">\u002F\u002F src\u002FMain.huff\n#include \".\u002Futils\u002FSafeMath.huff\"\n#include \".\u002Finterfaces\u002FIERC20.huff\"\n#include \".\u002FDispatcher.huff\"\n\n#define macro MAIN() = takes(0) returns(0) {\n    DISPATCHER()\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Система инклюдов — простое текстовое включение, без модульной области видимости или пространств имён. Тщательно именуйте макросы во избежание коллизий.\u003C\u002Fp>\n\u003Ch2 id=\"huff\">Когда использовать Huff\u003C\u002Fh2>\n\u003Cp>Huff — не язык общего назначения. Используйте его когда:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Газ — главное ограничение\u003C\u002Fstrong> — MEV-контракты, где 100 газа определяют прибыльность.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Размер байткода критичен\u003C\u002Fstrong> — контракты, деплоимые другими контрактами (CREATE2-фабрики).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Нужен кастомный диспатч\u003C\u002Fstrong> — jump-таблицы, бит-упакованные селекторы, нестандартное ABI.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Вы изучаете EVM\u003C\u002Fstrong> — ничто не учит EVM лучше, чем написание сырых опкодов.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Для всего остального пишите на Solidity и читайте вывод компилятора через \u003Ccode>solc --asm\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch2 id=\"\">Итоги\u003C\u002Fh2>\n\u003Cp>Huff даёт прямой доступ к байткоду EVM с минимальной абстракцией. Макросы инлайнят код с нулевым оверхедом. Метки берут на себя учёт смещений. Аннотации \u003Ccode>takes\u003C\u002Fcode>\u002F\u003Ccode>returns\u003C\u002Fcode> ловят стековые ошибки на ранних этапах. В следующей статье мы глубже погрузимся в управление стеком — искусство \u003Ccode>dup\u003C\u002Fcode>, \u003Ccode>swap\u003C\u002Fcode> и синхронизации ментальной модели стека с реальностью.\u003C\u002Fp>\n","ru","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:23.619338Z","Введение в Huff — низкоуровневый язык ассемблера EVM. Макросы, метки, takes\u002Freturns и сравнение байткода Huff и Solidity.","huff язык evm",null,"index, follow",[21,26,30,34],{"id":22,"name":23,"slug":24,"created_at":25},"c0000000-0000-0000-0000-000000000016","EVM","evm","2026-03-28T10:44:21.513630Z",{"id":27,"name":28,"slug":29,"created_at":25},"c0000000-0000-0000-0000-000000000020","Gas Optimization","gas-optimization",{"id":31,"name":32,"slug":33,"created_at":25},"c0000000-0000-0000-0000-000000000017","Huff","huff",{"id":35,"name":36,"slug":37,"created_at":25},"c0000000-0000-0000-0000-000000000009","Web3","web3","Блокчейн",[40,46,52],{"id":41,"title":42,"slug":43,"excerpt":44,"locale":12,"category_name":38,"published_at":45},"de000000-0000-0000-0000-000000000013","Уровень интероперабельности Ethereum: как 55+ L2 становятся одной сетью","uroven-interoperabelnosti-ethereum-kak-55-l2-stanovyatsya-odnoj-setyu","У Ethereum 55+ роллапов Layer 2, фрагментирующих ликвидность и пользовательский опыт. Уровень интероперабельности Ethereum — объединяющий кросс-роллап-мессаджинг, общие секвенсоры и based-роллапы — призван объединить их в единую компонуемую сеть.","2026-03-28T10:44:36.068675Z",{"id":47,"title":48,"slug":49,"excerpt":50,"locale":12,"category_name":38,"published_at":51},"de000000-0000-0000-0000-000000000012","ZK-доказательства за пределами роллапов: верифицируемый AI-инференс на Ethereum","zk-dokazatelstva-za-predelami-rollapov-verificiruemyj-ai-inferens-ethereum","Доказательства с нулевым разглашением — это уже не только инструмент масштабирования. В 2026 году zkML обеспечивает верифицируемый AI-инференс в блокчейне, ZK-копроцессоры переносят тяжёлые вычисления оффчейн с ончейн-верификацией, а новые системы доказательств SP1 и Jolt делают это практичным.","2026-03-28T10:44:36.026310Z",{"id":53,"title":54,"slug":55,"excerpt":56,"locale":12,"category_name":57,"published_at":58},"de000000-0000-0000-0000-000000000011","Разработка на TON в 2026: криптоплатежи в Telegram Mini Apps с TON Pay SDK","razrabotka-na-ton-2026-kriptoplatezhi-telegram-mini-apps-ton-pay-sdk","Экосистема TON выросла до 500M+ активных пользователей Mini App ежемесячно, 3600+ приложений и 400M+ кошельков. Это руководство проведёт вас через интеграцию TON Pay SDK для криптоплатежей в Telegram Mini Apps — от аутентификации кошелька до переводов Jetton.","Телеграм","2026-03-28T10:44:35.924705Z",{"id":13,"name":60,"slug":61,"bio":62,"photo_url":18,"linkedin":18,"role":63,"created_at":64,"updated_at":64},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]