[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-11-jump-tablitsy-huff-dispatch-bez-overkheda":3},{"article":4,"author":55},{"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":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":35,"related_articles":36},"d0000000-0000-0000-0000-000000000211","a0000000-0000-0000-0000-000000000012","Deep EVM #11: Jump-таблицы в Huff — O(1) диспатч без оверхеда Solidity","deep-evm-11-jump-tablitsy-huff-dispatch-bez-overkheda","Построение O(1) диспатчера функций в Huff с помощью упакованных jump-таблиц. Сравнение if-else цепочки Solidity с вручную написанной таблицей, экономящей тысячи газа.","## Проблема диспатчера Solidity\n\nКогда вы вызываете контракт на Solidity, первое, что исполняет EVM — диспатчер функций. Solidity генерирует линейную if-else цепочку, сравнивающую первые 4 байта calldata (селектор функции) с каждым известным селектором:\n\n```\nCALLDATALOAD 0x00\nSHR 224\nDUP1\nPUSH4 0x70a08231    \u002F\u002F balanceOf(address)\nEQ\nPUSH2 dest1\nJUMPI\nDUP1\nPUSH4 0xa9059cbb    \u002F\u002F transfer(address,uint256)\nEQ\nPUSH2 dest2\nJUMPI\n...\n```\n\nДля контракта с N функциями это O(N) — в худшем случае проверяются все N селекторов. Каждое сравнение стоит ~22 газа (DUP1 + PUSH4 + EQ + PUSH2 + JUMPI). Контракт с 20 функциями тратит до 440 газа только на диспатч. Компилятор Solidity (с версии 0.8.22) иногда использует бинарное дерево поиска для больших интерфейсов, доводя до O(log N), но это всё ещё субоптимально.\n\nДля MEV-бота, вызываемого миллионы раз, эти 400+ газа за вызов складываются в реальный ETH.\n\n## Подход jump-таблиц: O(1)\n\nJump-таблица отображает селектор функции непосредственно в смещение кода с помощью арифметики, а не сравнений. Идея заимствована из архитектуры процессоров — вычисляемые GOTO используются в системном программировании с 1960-х.\n\nКонцепция:\n\n1. Извлечь селектор функции из calldata (4 байта).\n2. Арифметически вычислить адрес перехода из селектора.\n3. JUMP непосредственно к этому адресу.\n\nНикаких сравнений, никаких ветвлений, константное время независимо от числа функций.\n\n### Подход 1: минимальное кодирование селекторов\n\nЕсли контракт имеет мало функций (1-8), можно назначить селекторы вручную, намайнив vanity-селекторы, где первый байт или два кодируют уникальное малое целое:\n\n```huff\n#define macro DISPATCHER() = takes(0) returns(0) {\n    0x00 calldataload       \u002F\u002F [calldata_word]\n    0xe0 shr                \u002F\u002F [selector]\n\n    \u002F\u002F Извлекаем маршрутизирующий байт — первый байт селектора\n    0x18 shr                \u002F\u002F [first_byte]\n\n    \u002F\u002F Каждая запись в таблице — 2 байта (PUSH2 offset)\n    0x02 mul                \u002F\u002F [offset_in_table]\n    __tablestart(JumpTable) \u002F\u002F [table_start, offset_in_table]\n    add                     \u002F\u002F [entry_address]\n    \n    0x00 codecopy\n    0x00 mload\n    0xf0 shr\n    jump\n}\n\n#define jumptable JumpTable {\n    swap_exact\n    add_liq\n    remove_liq\n    flash_loan\n}\n```\n\n### Подход 2: упакованная таблица в коде\n\nДля максимальной плотности можно упаковать jump-таблицу прямо в байткод, используя `__tablestart` и `__tablesize`. Huff нативно поддерживает jump-таблицы как первоклассную конструкцию:\n\n```huff\n#define jumptable__packed SELECTOR_TABLE {\n    fn_swap\n    fn_transfer\n    fn_approve\n    fn_balance\n}\n\n#define macro MAIN() = takes(0) returns(0) {\n    0x00 calldataload 0xe0 shr  \u002F\u002F [selector]\n\n    \u002F\u002F Отображаем селектор в индекс (0-3)\n    0x18 shr                    \u002F\u002F [index]\n\n    \u002F\u002F Проверка границ\n    dup1 0x04 lt\n    valid jumpi\n    0x00 0x00 revert\n\n    valid:\n    __tablestart(SELECTOR_TABLE)\n    swap1 0x02 mul add\n    0x1e mload\n    jump\n\n    fn_swap:\n        SWAP_IMPL()\n    fn_transfer:\n        TRANSFER_IMPL()\n    fn_approve:\n        APPROVE_IMPL()\n    fn_balance:\n        BALANCE_IMPL()\n}\n```\n\n## Извлечение селектора из calldata\n\nСтандартное извлечение селектора:\n\n```huff\n0x00 calldataload   \u002F\u002F загружает 32 байта из calldata позиции 0\n0xe0 shr            \u002F\u002F сдвиг вправо 224 бита (256 - 32) для изоляции верхних 4 байт\n```\n\nСтоимость: PUSH1 (3) + CALLDATALOAD (3) + PUSH1 (3) + SHR (3) = 12 газа.\n\nБолее дешёвая альтернатива, когда нужен только 1-2 байта селектора:\n\n```huff\n0x00 calldataload   \u002F\u002F [calldata_word]\n0xf8 shr            \u002F\u002F [first_byte] — сдвиг вправо 248 бит для получения байта 0\n```\n\nТот же газ, но маршрутизирующий ключ — 1 байт (256 возможных значений). Если контракт имеет \u003C= 256 функций, одного байта достаточно.\n\n## Сравнение газа\n\nБенчмарк стоимости диспатча для разного числа функций:\n\n| Функций | Solidity (if-else) | Solidity (бинарный) | Huff Jump Table |\n|---------|-------------------|---------------------|------------------|\n| 2       | 22-44 газа        | 22-44 газа          | 15 газа          |\n| 4       | 22-88 газа        | 22-66 газа          | 15 газа          |\n| 8       | 22-176 газа       | 22-88 газа          | 15 газа          |\n| 16      | 22-352 газа       | 22-110 газа         | 15 газа          |\n| 32      | 22-704 газа       | 22-132 газа         | 15 газа          |\n\nСтоимость jump-таблицы константна: CALLDATALOAD (3) + SHR (3) + арифметика (3-6) + JUMP (8) = ~15-18 газа. Не меняется независимо от числа функций.\n\n## Майнинг vanity-селекторов\n\nДля работы jump-таблиц нужны селекторы с предсказуемыми маршрутизирующими байтами:\n\n```python\nimport hashlib\nimport itertools\n\ntarget_byte = 0x00\nbase_name = \"swap\"\n\nfor suffix in itertools.count():\n    name = f\"{base_name}{suffix}(uint256,address)\"\n    selector = hashlib.sha3_256(name.encode()).digest()[:4]\n    if selector[0] == target_byte:\n        print(f\"Found: {name} -> 0x{selector.hex()}\")\n        break\n```\n\nНа практике мы используем `cast sig` из Foundry или Rust-утилиту для перебора имён функций. Для контракта с 8 функциями майнинг 8 совместимых селекторов занимает миллисекунды.\n\n## Влияние на размер байткода\n\nРазмер байткода напрямую влияет на стоимость деплоя (200 газа за байт через CREATE):\n\n| Подход | Рантайм-байткод | Газ деплоя |\n|--------|-----------------|------------|\n| Solidity (8 функций) | ~800 байт | 160 000 газа |\n| Huff jump table (8 функций) | ~200 байт | 40 000 газа |\n| Huff минимальный (2 функции) | ~61 байт | 12 200 газа |\n\nДля MEV-ботов, часто передеплоивающих контракты (ротация адресов через CREATE2), меньший байткод = меньшие операционные расходы.\n\n## Ограничения\n\n1. **Нестандартный ABI** — внешние инструменты (Etherscan, кошельки) не смогут декодировать calldata без кастомных ABI-определений.\n2. **Майнинг селекторов** — требует предварительной работы и ограничивает именование функций.\n3. **Стоимость обслуживания** — Huff сложнее аудитить и модифицировать, чем Solidity.\n4. **Упакованные таблицы** — встроенные `__tablestart` и `__tablesize` имеют граничные случаи; тщательно тестируйте.\n\n## Итоги\n\nJump-таблицы заменяют O(N) диспатч-цепочку Solidity на O(1) вычисленные переходы. Экономия газа накапливается за миллионы вызовов — значимое преимущество для высокочастотных контрактов вроде MEV-ботов и DEX-роутеров. В следующей статье мы исследуем продвинутые паттерны Huff: адаптивное исполнение и on-chain вычисления.","\u003Ch2 id=\"solidity\">Проблема диспатчера Solidity\u003C\u002Fh2>\n\u003Cp>Когда вы вызываете контракт на Solidity, первое, что исполняет EVM — диспатчер функций. Solidity генерирует линейную if-else цепочку, сравнивающую первые 4 байта calldata (селектор функции) с каждым известным селектором:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>CALLDATALOAD 0x00\nSHR 224\nDUP1\nPUSH4 0x70a08231    \u002F\u002F balanceOf(address)\nEQ\nPUSH2 dest1\nJUMPI\nDUP1\nPUSH4 0xa9059cbb    \u002F\u002F transfer(address,uint256)\nEQ\nPUSH2 dest2\nJUMPI\n...\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Для контракта с N функциями это O(N) — в худшем случае проверяются все N селекторов. Каждое сравнение стоит ~22 газа (DUP1 + PUSH4 + EQ + PUSH2 + JUMPI). Контракт с 20 функциями тратит до 440 газа только на диспатч. Компилятор Solidity (с версии 0.8.22) иногда использует бинарное дерево поиска для больших интерфейсов, доводя до O(log N), но это всё ещё субоптимально.\u003C\u002Fp>\n\u003Cp>Для MEV-бота, вызываемого миллионы раз, эти 400+ газа за вызов складываются в реальный ETH.\u003C\u002Fp>\n\u003Ch2 id=\"jump-o-1\">Подход jump-таблиц: O(1)\u003C\u002Fh2>\n\u003Cp>Jump-таблица отображает селектор функции непосредственно в смещение кода с помощью арифметики, а не сравнений. Идея заимствована из архитектуры процессоров — вычисляемые GOTO используются в системном программировании с 1960-х.\u003C\u002Fp>\n\u003Cp>Концепция:\u003C\u002Fp>\n\u003Col>\n\u003Cli>Извлечь селектор функции из calldata (4 байта).\u003C\u002Fli>\n\u003Cli>Арифметически вычислить адрес перехода из селектора.\u003C\u002Fli>\n\u003Cli>JUMP непосредственно к этому адресу.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Никаких сравнений, никаких ветвлений, константное время независимо от числа функций.\u003C\u002Fp>\n\u003Ch3>Подход 1: минимальное кодирование селекторов\u003C\u002Fh3>\n\u003Cp>Если контракт имеет мало функций (1-8), можно назначить селекторы вручную, намайнив vanity-селекторы, где первый байт или два кодируют уникальное малое целое:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">#define macro DISPATCHER() = takes(0) returns(0) {\n    0x00 calldataload       \u002F\u002F [calldata_word]\n    0xe0 shr                \u002F\u002F [selector]\n\n    \u002F\u002F Извлекаем маршрутизирующий байт — первый байт селектора\n    0x18 shr                \u002F\u002F [first_byte]\n\n    \u002F\u002F Каждая запись в таблице — 2 байта (PUSH2 offset)\n    0x02 mul                \u002F\u002F [offset_in_table]\n    __tablestart(JumpTable) \u002F\u002F [table_start, offset_in_table]\n    add                     \u002F\u002F [entry_address]\n    \n    0x00 codecopy\n    0x00 mload\n    0xf0 shr\n    jump\n}\n\n#define jumptable JumpTable {\n    swap_exact\n    add_liq\n    remove_liq\n    flash_loan\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Подход 2: упакованная таблица в коде\u003C\u002Fh3>\n\u003Cp>Для максимальной плотности можно упаковать jump-таблицу прямо в байткод, используя \u003Ccode>__tablestart\u003C\u002Fcode> и \u003Ccode>__tablesize\u003C\u002Fcode>. Huff нативно поддерживает jump-таблицы как первоклассную конструкцию:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">#define jumptable__packed SELECTOR_TABLE {\n    fn_swap\n    fn_transfer\n    fn_approve\n    fn_balance\n}\n\n#define macro MAIN() = takes(0) returns(0) {\n    0x00 calldataload 0xe0 shr  \u002F\u002F [selector]\n\n    \u002F\u002F Отображаем селектор в индекс (0-3)\n    0x18 shr                    \u002F\u002F [index]\n\n    \u002F\u002F Проверка границ\n    dup1 0x04 lt\n    valid jumpi\n    0x00 0x00 revert\n\n    valid:\n    __tablestart(SELECTOR_TABLE)\n    swap1 0x02 mul add\n    0x1e mload\n    jump\n\n    fn_swap:\n        SWAP_IMPL()\n    fn_transfer:\n        TRANSFER_IMPL()\n    fn_approve:\n        APPROVE_IMPL()\n    fn_balance:\n        BALANCE_IMPL()\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"calldata\">Извлечение селектора из calldata\u003C\u002Fh2>\n\u003Cp>Стандартное извлечение селектора:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">0x00 calldataload   \u002F\u002F загружает 32 байта из calldata позиции 0\n0xe0 shr            \u002F\u002F сдвиг вправо 224 бита (256 - 32) для изоляции верхних 4 байт\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Стоимость: PUSH1 (3) + CALLDATALOAD (3) + PUSH1 (3) + SHR (3) = 12 газа.\u003C\u002Fp>\n\u003Cp>Более дешёвая альтернатива, когда нужен только 1-2 байта селектора:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-huff\">0x00 calldataload   \u002F\u002F [calldata_word]\n0xf8 shr            \u002F\u002F [first_byte] — сдвиг вправо 248 бит для получения байта 0\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Тот же газ, но маршрутизирующий ключ — 1 байт (256 возможных значений). Если контракт имеет <= 256 функций, одного байта достаточно.\u003C\u002Fp>\n\u003Ch2 id=\"\">Сравнение газа\u003C\u002Fh2>\n\u003Cp>Бенчмарк стоимости диспатча для разного числа функций:\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Функций\u003C\u002Fth>\u003Cth>Solidity (if-else)\u003C\u002Fth>\u003Cth>Solidity (бинарный)\u003C\u002Fth>\u003Cth>Huff Jump Table\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>2\u003C\u002Ftd>\u003Ctd>22-44 газа\u003C\u002Ftd>\u003Ctd>22-44 газа\u003C\u002Ftd>\u003Ctd>15 газа\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>4\u003C\u002Ftd>\u003Ctd>22-88 газа\u003C\u002Ftd>\u003Ctd>22-66 газа\u003C\u002Ftd>\u003Ctd>15 газа\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>8\u003C\u002Ftd>\u003Ctd>22-176 газа\u003C\u002Ftd>\u003Ctd>22-88 газа\u003C\u002Ftd>\u003Ctd>15 газа\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>16\u003C\u002Ftd>\u003Ctd>22-352 газа\u003C\u002Ftd>\u003Ctd>22-110 газа\u003C\u002Ftd>\u003Ctd>15 газа\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>32\u003C\u002Ftd>\u003Ctd>22-704 газа\u003C\u002Ftd>\u003Ctd>22-132 газа\u003C\u002Ftd>\u003Ctd>15 газа\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>Стоимость jump-таблицы константна: CALLDATALOAD (3) + SHR (3) + арифметика (3-6) + JUMP (8) = ~15-18 газа. Не меняется независимо от числа функций.\u003C\u002Fp>\n\u003Ch2 id=\"vanity\">Майнинг vanity-селекторов\u003C\u002Fh2>\n\u003Cp>Для работы jump-таблиц нужны селекторы с предсказуемыми маршрутизирующими байтами:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-python\">import hashlib\nimport itertools\n\ntarget_byte = 0x00\nbase_name = \"swap\"\n\nfor suffix in itertools.count():\n    name = f\"{base_name}{suffix}(uint256,address)\"\n    selector = hashlib.sha3_256(name.encode()).digest()[:4]\n    if selector[0] == target_byte:\n        print(f\"Found: {name} -> 0x{selector.hex()}\")\n        break\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>На практике мы используем \u003Ccode>cast sig\u003C\u002Fcode> из Foundry или Rust-утилиту для перебора имён функций. Для контракта с 8 функциями майнинг 8 совместимых селекторов занимает миллисекунды.\u003C\u002Fp>\n\u003Ch2 id=\"\">Влияние на размер байткода\u003C\u002Fh2>\n\u003Cp>Размер байткода напрямую влияет на стоимость деплоя (200 газа за байт через CREATE):\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Подход\u003C\u002Fth>\u003Cth>Рантайм-байткод\u003C\u002Fth>\u003Cth>Газ деплоя\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Solidity (8 функций)\u003C\u002Ftd>\u003Ctd>~800 байт\u003C\u002Ftd>\u003Ctd>160 000 газа\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Huff jump table (8 функций)\u003C\u002Ftd>\u003Ctd>~200 байт\u003C\u002Ftd>\u003Ctd>40 000 газа\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Huff минимальный (2 функции)\u003C\u002Ftd>\u003Ctd>~61 байт\u003C\u002Ftd>\u003Ctd>12 200 газа\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>Для MEV-ботов, часто передеплоивающих контракты (ротация адресов через CREATE2), меньший байткод = меньшие операционные расходы.\u003C\u002Fp>\n\u003Ch2 id=\"\">Ограничения\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>Нестандартный ABI\u003C\u002Fstrong> — внешние инструменты (Etherscan, кошельки) не смогут декодировать calldata без кастомных ABI-определений.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Майнинг селекторов\u003C\u002Fstrong> — требует предварительной работы и ограничивает именование функций.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Стоимость обслуживания\u003C\u002Fstrong> — Huff сложнее аудитить и модифицировать, чем Solidity.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Упакованные таблицы\u003C\u002Fstrong> — встроенные \u003Ccode>__tablestart\u003C\u002Fcode> и \u003Ccode>__tablesize\u003C\u002Fcode> имеют граничные случаи; тщательно тестируйте.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"\">Итоги\u003C\u002Fh2>\n\u003Cp>Jump-таблицы заменяют O(N) диспатч-цепочку Solidity на O(1) вычисленные переходы. Экономия газа накапливается за миллионы вызовов — значимое преимущество для высокочастотных контрактов вроде MEV-ботов и DEX-роутеров. В следующей статье мы исследуем продвинутые паттерны Huff: адаптивное исполнение и on-chain вычисления.\u003C\u002Fp>\n","ru","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:23.648937Z","Deep EVM #11: Jump-таблицы в Huff — O(1) диспатч функций","Построение O(1) диспатчера функций в Huff с помощью jump-таблиц. Сравнение с if-else цепочкой Solidity, майнинг vanity-селекторов.","huff jump таблицы evm",null,"index, follow",[22,27,31],{"id":23,"name":24,"slug":25,"created_at":26},"c0000000-0000-0000-0000-000000000016","EVM","evm","2026-03-28T10:44:21.513630Z",{"id":28,"name":29,"slug":30,"created_at":26},"c0000000-0000-0000-0000-000000000020","Gas Optimization","gas-optimization",{"id":32,"name":33,"slug":34,"created_at":26},"c0000000-0000-0000-0000-000000000017","Huff","huff","Блокчейн",[37,43,49],{"id":38,"title":39,"slug":40,"excerpt":41,"locale":12,"category_name":35,"published_at":42},"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":44,"title":45,"slug":46,"excerpt":47,"locale":12,"category_name":35,"published_at":48},"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":50,"title":51,"slug":52,"excerpt":53,"locale":12,"category_name":35,"published_at":54},"dd000000-0000-0000-0000-000000000013","EIP-7702 на практике: создание потоков смарт-аккаунтов после Pectra","eip-7702-na-praktike-sozdanie-potokov-smart-akkauntov-posle-pectra","EIP-7702 позволяет любому EOA Ethereum временно действовать как смарт-контракт в рамках одной транзакции. Вот как реализовать пакетные транзакции, спонсирование газа и социальное восстановление с помощью нового примитива абстракции аккаунтов.","2026-03-28T10:44:35.357227Z",{"id":13,"name":56,"slug":57,"bio":58,"photo_url":19,"linkedin":19,"role":59,"created_at":60,"updated_at":60},"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"]