Разработка системы unified accounts
Сталкивались с ситуацией, когда для работы в разных блокчейнах приходится держать десяток кошельков и вручную перебрасывать ликвидность? Наша команда инженеров решает эту проблему с помощью системы unified accounts — единого аккаунта, который работает на всех сетях. Это не просто удобная абстракция, а архитектурное решение, объединяющее детерминированное развёртывание контрактов, кросчейн-синхронизацию и интент-ориентированное исполнение. Давайте разберём, как это устроено на уровне смарт-контрактов и инфраструктуры. Unified accounts эволюционируют от мультичейн-подхода (много кошельков) к chain-abstracted (один кошелёк, прозрачная мультичейн). Задача нетривиальная: реализовать её правильно означает решить несколько независимых технических проблем одновременно. Опыт нашей команды в кросчейн-разработке — более 10 успешных проектов.
Как unified account решает проблему фрагментации ликвидности?
При работе с несколькими L1/L2 цепями (Ethereum, Polygon, Arbitrum, Optimism, Base) пользователь вынужден держать средства на каждой сети отдельно. Unified account использует CREATE2 для детерминированного адреса и синхронизирует состояние через защищённый bridge. Это позволяет иметь единый логический баланс, который автоматически доступен на всех цепях без ручных переводов. Сравните: в традиционной схеме для stake 100 USDC в протоколе на Arbitrum нужно сначала перевести USDC с Ethereum — это минимум две транзакции и 15 минут ожидания. В unified account пользователь указывает намерение, а система сама маршрутизирует ликвидность через оптимальный bridge за пару кликов. Гарантируем, что экономия на газе и времени достигает 40–60% на типовых операциях.
Что такое unified account на техническом уровне?
Наивная реализация: смарт-контракт на каждой поддерживаемой цепи с одинаковым адресом (через CREATE2), синхронизация состояния через bridge. Это работает, но создаёт сложность: состояние разрознено, синхронизация имеет задержку и стоимость.
Продвинутая реализация разделяет четыре слоя: Identity, Intent, Execution, Settlement. Каждый слой решает свою задачу, а вместе они обеспечивают бесшовный кросчейн-опыт.
| Слой | Задача |
|---|---|
| Identity | Определяет пользователя на всех цепях (один адрес) |
| Intent | Принимает намерение пользователя (что сделать) |
| Execution | Выбирает оптимальную цепь и маршрут исполнения |
| Settlement | Проводит окончательный расчёт и синхронизацию |
Детерминированные адреса через CREATE2
Первый шаг — один и тот же адрес на всех EVM цепях:
// Factory контракт с одинаковым адресом на всех цепях
contract AccountFactory {
function deployAccount(
bytes32 salt,
bytes calldata initCode
) external returns (address account) {
// CREATE2: адрес зависит только от factory address + salt + initCode
// Если factory задеплоен через keyless deployment (один адрес на всех EVM),
// то и Account будет иметь одинаковый адрес
assembly {
account := create2(0, add(initCode, 32), mload(initCode), salt)
}
if (account == address(0)) revert DeploymentFailed();
}
function predictAddress(
bytes32 salt,
bytes32 initCodeHash
) external view returns (address) {
return address(uint160(uint256(keccak256(abi.encodePacked(
bytes1(0xff),
address(this),
salt,
initCodeHash
)))));
}
}
Keyless deployment (через ERC-2470 Singleton Factory или Nick's method) обеспечивает одинаковый адрес factory на всех EVM цепях. Следовательно — один и тот же salt + initCode = один адрес account на всех цепях. ERC-2470: Singleton Factory — это стандартный способ развёртывания контрактов с одинаковым адресом.
Cross-chain state synchronization
Второй шаг — синхронизация данных аккаунта между цепями. Например: пользователь обновляет список owners на Ethereum, это должно отразиться на Polygon.
Паттерн: Primary chain + синхронизация через bridge:
contract UnifiedAccountPrimary {
// Primary state хранится на "home" цепи
mapping(address => bool) public owners;
uint256 public nonce;
// Синхронизация изменений на другие цепи
function addOwnerAndSync(
address newOwner,
uint64[] calldata targetChains,
address[] calldata targetAccounts
) external onlyOwner {
owners[newOwner] = true;
// Отправляем update через bridge (CCIP, Axelar, LayerZero)
for (uint i = 0; i < targetChains.length; i++) {
bytes memory payload = abi.encode(
"ADD_OWNER",
newOwner,
++nonce
);
bridge.sendMessage(targetChains[i], targetAccounts[i], payload);
}
emit OwnerAdded(newOwner);
}
}
contract UnifiedAccountReplica {
// Реплика получает обновления от Primary
uint256 public lastSyncedNonce;
function receiveSync(
bytes calldata payload,
bytes32 originMessageId
) external onlyBridge {
(string memory action, address target, uint256 nonce) =
abi.decode(payload, (string, address, uint256));
// Защита от replay: nonce должен быть следующим
require(nonce == lastSyncedNonce + 1, "Invalid nonce");
lastSyncedNonce = nonce;
if (keccak256(bytes(action)) == keccak256(bytes("ADD_OWNER"))) {
_addOwner(target);
}
}
}
Intent-based execution
Unified account принимает намерения пользователя, не конкретные транзакции. Пользователь говорит «хочу stake 100 USDC в протоколе X» — система сама решает откуда взять USDC и на какой цепи исполнить:
interface UserIntent {
action: "stake" | "swap" | "transfer" | "borrow";
targetProtocol: string;
targetChain?: number; // опционально — если не указана, система выбирает
inputToken: string;
inputAmount: string;
outputToken?: string;
minOutputAmount?: string;
deadline?: number;
}
class IntentRouter {
async resolveIntent(intent: UserIntent, userProfile: UserProfile): Promise<ExecutionPlan> {
// 1. Находим лучшую цепь для исполнения
const targetChain = intent.targetChain ||
await this.findOptimalChain(intent, userProfile);
// 2. Определяем откуда взять средства
const fundingSource = await this.findBestFundingSource(
intent.inputToken,
intent.inputAmount,
userProfile.balances,
targetChain
);
// 3. Строим execution plan
const steps: ExecutionStep[] = [];
if (fundingSource.chainId !== targetChain) {
// Нужен bridge
steps.push({
type: "bridge",
fromChain: fundingSource.chainId,
toChain: targetChain,
token: intent.inputToken,
amount: intent.inputAmount,
bridgeProtocol: await this.selectBridge(fundingSource.chainId, targetChain),
});
}
// Основное действие
steps.push({
type: intent.action,
chainId: targetChain,
protocol: intent.targetProtocol,
...
});
return {
steps,
estimatedGas: await this.estimateTotalGas(steps),
estimatedTime: this.estimateTime(steps),
};
}
}
Gasless cross-chain операции
Для полного UX unified account — пользователь не должен думать о газе. Система абстрагирует это:
// Пользователь платит в USDC, система конвертирует в нативные токены
async function executeGasless(
intent: UserIntent,
feeToken: "USDC" | "USDT" | string
): Promise<string> {
const plan = await intentRouter.resolveIntent(intent, userProfile);
// Рассчитываем общую стоимость в feeToken
const totalCostInFeeToken = await priceOracle.convertGasCost(
plan.estimatedGas,
plan.steps.map(s => s.chainId),
feeToken
);
// Получаем UserOperation со sponsored газом
const userOp = await buildSponsordUserOp(plan, feeToken, totalCostInFeeToken);
// Подписываем один раз на исходной цепи
const signedOp = await userAccount.signUserOperation(userOp);
// Executor relay выполняет все steps
return relayer.submitIntent(signedOp);
}
Account abstraction как фундамент
Unified accounts нативно строятся на ERC-4337: Smart account вместо EOA на каждой цепи, UserOperations как единица intent, Bundler как executor, Paymaster как gas abstraction layer. ZeroDev Kernel, Safe с модулями или кастомная реализации — выбор зависит от требуемой гибкости.
Проблема атомарности
Критический вопрос: что происходит если шаг 1 (bridge) прошёл успешно, а шаг 2 (stake на целевой цепи) завершился ошибкой? Варианты: Optimistic execution (продолжаем, записываем pending state, retry при неудаче), Atomic through escrow (средства в escrow контракте до подтверждения финального шага), Two-phase commit (prepare → commit/rollback). На практике большинство систем используют optimistic с retry механизмом и ручным fallback (средства остаются на целевой цепи если действие не выполнено).
Сравнение подходов к кросчейн-коммуникации
| Протокол | Тип | Задержка | Безопасность |
|---|---|---|---|
| LayerZero | light oracle + relayer | ~1 минута | зависит от оракула |
| Axelar | validator set | ~5 минут | 2/3 валидаторов |
| CCIP (Chainlink) | децентрализованные оракулы | ~10 минут | проверенный аудитом |
Что входит в работу над unified account
- Анализ целевых сетей и требований к синхронизации.
- Проектирование архитектуры identity и intent слоёв.
- Развёртывание factory контрактов через keyless deployment.
- Интеграция bridge-протокола и настройка синхронизации.
- Реализация intent router с поддержкой gas abstraction.
- Интеграция frontend SDK.
- Развёртывание на testnet и проведение аудита.
- Deploy на mainnet и запуск.
Сроки
- Базовая unified identity (CREATE2 одинаковые адреса, базовый sync): 4-6 недель
- Intent routing + cross-chain execution: 6-8 недель
- Gas abstraction + feeToken: 3-4 недели
- Production hardening + security audit: 6-8 недель
- Итого: 4-6 месяцев
Бюджет на разработку unified account рассчитывается индивидуально. Свяжитесь с нами, предоставьте спецификацию используемых цепей и требования к синхронизации — мы подготовим индивидуальное предложение с точными сроками. Закажите консультацию, чтобы оценить ваш проект и получить профессиональную разработку под ключ.