Система unified accounts: единый аккаунт для кросчейн-операций

Разработка системы 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. Каждый слой решает свою задачу, а вместе они обеспечивают бесшовный кросчейн-опыт.

Детерминированные адреса через 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 (средства остаются на целевой цепи если действие не выполнено).

Сравнение подходов к кросчейн-коммуникации

Что входит в работу над unified account

1. Анализ целевых сетей и требований к синхронизации.
2. Проектирование архитектуры identity и intent слоёв.
3. Развёртывание factory контрактов через keyless deployment.
4. Интеграция bridge-протокола и настройка синхронизации.
5. Реализация intent router с поддержкой gas abstraction.
6. Интеграция frontend SDK.
7. Развёртывание на testnet и проведение аудита.
8. 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 рассчитывается индивидуально. Свяжитесь с нами, предоставьте спецификацию используемых цепей и требования к синхронизации — мы подготовим индивидуальное предложение с точными сроками. Закажите консультацию, чтобы оценить ваш проект и получить профессиональную разработку под ключ.