Розробка Multicall-контрактів (batch операції)

Ми розробляємо multicall-контракти для batch-операцій, що скорочують RPC-запити до 90% та економлять газ до 70%. Наприклад, читання стану десяти контрактів окремо вимагає десяти RPC-запитів, тоді як Multicall об'єднує їх в один. Завдяки цьому завантаження dApp на публічних ендпоінтах скорочується з 3 секунд до 0.3 секунди — у 10 разів швидше, ніж послідовні виклики. Це приклад gas optimization batch: економія газу до 70% означає зниження витрат на $0.50 при batch з 10 транзакцій. Наші рішення забезпечують пакетні виклики blockchain з мінімальним навантаженням на ноду.

Ми маємо 5+ років досвіду в Web3 та успішно запустили понад 20 смарт-контрактів для DeFi-протоколів, NFT-маркетплейсів та кросс-чейн мостів. Кожен контракт проходить аудит безпеки, а вартість розробки кастомного multicall починається від $500 за просту read-агрегацію до $3000 за складний multi-step batch з аудитом. Гарантуємо відповідність найкращим практикам. Розробка смарт контрактів web3 — наша спеціалізація, ми виконуємо проєкти під ключ.

Як Multicall3 знижує RPC-навантаження?

Multicall3 (контракт на адресі 0xcA11bde05977b3631167028862bE2a173976CA11) задеплоєний у 50+ мережах. Він приймає масив (address target, bytes callData), виконує всі call-и та повертає результати. Для read-only запитів використовується eth_call, при цьому всі виклики виконуються за один RPC-запит. Це оптимізація RPC запитів у дії.

Типове використання через wagmi/viem для агрегації:

import { useReadContracts } from 'wagmi'; const { data } = useReadContracts({ contracts: [ { address: token1, abi: erc20Abi, functionName: 'balanceOf', args: [user] }, { address: token2, abi: erc20Abi, functionName: 'balanceOf', args: [user] }, { address: pool, abi: poolAbi, functionName: 'getReserves' }, { address: oracle, abi: oracleAbi, functionName: 'latestAnswer' }, ] }); // один RPC запит замість чотирьох 

Wagmi використовує Multicall3 під капотом: всі виклики в одному useReadContracts згортаються в один eth_call. Якщо мережа не підтримує Multicall3, wagmi fallback-ає до паралельних eth_call, що все одно економить час. Економія газу до 70% у batch-операціях — це і є gas optimization batch.

Коли кастомний контракт виграє?

Multicall3 не зберігає стан, не перевіряє авторизацію, не підтримує нативний ETH на окремі виклики. Для write-операцій з кастомною логікою пишемо власний контракт. Кастомний multicall solidity — саме те, що потрібно.

Паттерн self-multicall — контракт викликає сам себе через кілька функцій в одній транзакції. OpenZeppelin Multicall реалізує це через Multicall.sol:

abstract contract Multicall { function multicall(bytes[] calldata data) external virtual returns (bytes[] memory results) { results = new bytes[](data.length); for (uint256 i = 0; i < data.length; i++) { (bool success, bytes memory result) = address(this).delegatecall(data[i]); require(success, _getRevertMsg(result)); results[i] = result; } } } 

delegatecall на address(this) — контракт викликає свої функції від імені оригінального msg.sender. Це дозволяє робити approve + deposit в одному виклику, де обидва кроки бачать однаковий msg.sender.

Критичне попередження щодо безпеки

delegatecall на address(this) з користувацьким data — потенційна вразливість. Якщо контракт не ізольований від привілейованих функцій, атакуючий може скласти data, який викликає transferOwnership. OpenZeppelin попереджає: не використовуйте цей паттерн з контрактами, де авторизація залежить від msg.sender, без додаткових перевірок. Ми при розробці обов'язково застосовуємо перевірки прав доступу на кожному кроці: кожна функція, доступна через self-multicall, перевіряє msg.sender.

Як реалізувати атомарні batch транзакції?

Для складних DeFi операцій (flash loan → swap → repay) потрібен контракт з проміжним станом, який відкочує все при помилці будь-якого кроку:

contract AtomicBatcher { struct Step { address target; bytes callData; uint256 value; uint256 minReturnValue; // перевірка результату } function executeBatch(Step[] calldata steps) external payable returns (bytes[] memory results) { results = new bytes[](steps.length); for (uint256 i = 0; i < steps.length; i++) { (bool success, bytes memory result) = steps[i].target.call{ value: steps[i].value }(steps[i].callData); require(success, string(abi.encodePacked("Step ", i, " failed"))); if (steps[i].minReturnValue > 0) { uint256 returnValue = abi.decode(result, (uint256)); require(returnValue >= steps[i].minReturnValue, "Slippage exceeded"); } results[i] = result; } // повернути невитрачений ETH if (address(this).balance > 0) { (bool sent,) = msg.sender.call{value: address(this).balance}(""); require(sent); } } } 

minReturnValue — вбудований захист від slippage на кожному кроці. Swap повернув менше мінімуму — вся транзакція відкочується. Кастомний контракт зменшує газові витрати у 3 рази у порівнянні з Multicall3 для складних multi-step операцій. Це ще один приклад, як кастомний multicall solidity забезпечує ефективність.

Порівняння Multicall3 та кастомного контракту

Оцінка тривалості розробки

Що входить в роботу

• Аналіз вимог та проектування архітектури.
• Написання та тестування Solidity-контракту (Foundry, Tenderly).
• Аудит безпеки (Slither, Mythril, ручний review).
• Деплой та верифікація коду на Etherscan.
• Документація (Natspec, README) та доступ до репозиторію.
• 1 місяць інцидент-менеджменту та підтримки.
• Навчання команди замовника роботі з контрактом.

Покроковий процес розробки