Разработка решений на модульном стеке (execution + DA + settlement)

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Разработка решений на модульном стеке (execution + DA + settlement)
Сложный
от 2 недель до 3 месяцев
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1357
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1249
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    954
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1187
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    645
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    926

Разработка системы на модульном стеке (execution + DA + settlement)

Монолитный блокчейн делает всё сам: исполняет транзакции, обеспечивает доступность данных, финализирует состояние. Модульный подход разбивает эти функции между специализированными слоями. Результат — экосистема, где можно выбирать компоненты как модули: Celestia для DA, Ethereum для settlement, OP Stack или Arbitrum Orbit для execution. Это не теория — так построены десятки mainnet L2 и L3. Мы предлагаем разработку таких решений под ключ. Свяжитесь с нами для консультации — оценим ваш проект и поможем выбрать оптимальный стек.

Типичный запрос: «хотим свой appchain с низкими комиссиями и кастомной логикой, но с безопасностью Ethereum». Это правильно сформулированная задача, и модульный стек — правильный ответ. Наша команда имеет опыт в блокчейн-разработке и запущенных mainnet-проектах.

Почему модульный стек дешевле монолитного?

Главный аргумент — экономия на layer DA. Использование Celestia вместо Ethereum для публикации batch-данных снижает стоимость на 90–95%. Для high-volume rollup это экономит тысячи долларов в месяц. Celestia дешевле Ethereum в 20 раз при сопоставимой безопасности для большинства сценариев. Согласно официальной документации Celestia, Data Availability Sampling позволяет лёгким нодам проверять доступность данных без полной загрузки блоков.

Какие слои входят в модульный стек?

Execution Layer

Исполняет транзакции, поддерживает состояние. Это ваш chain — со своими правилами, gas token, precompiles.

OP Stack (Optimism, Base, Zora) — самый зрелый фреймворк для Optimistic Rollup-based L2/L3. EVM-эквивалентность. op-geth + op-node + op-batcher + op-proposer.

Arbitrum Orbit — Arbitrum-based L2/L3. Поддерживает Stylus (WASM смарт-контракты на Rust/C++). Более гибкая кастомизация gas и permission models.

Polygon CDK — ZK-based chain development kit. zkEVM под капотом. Более сложен в эксплуатации, но ZK finality вместо fraud window.

Sovereign rollup через Rollkit — execution layer с любым execution environment, settlement в любой цепи (или без settlement). Максимальная гибкость, минимальная зрелость.

Data Availability Layer

Блоки должны быть доступны для скачивания — иначе fraud proofs и state reconstruction невозможны. DA layer хранит данные транзакций (calldata или blobs).

Ethereum L1 (EIP-4844 blobs) — максимальная security, наивысшая стоимость. После EIP-4844: ~3–6 blobs per block, каждый blob ~128KB, стоимость blob gas отдельна от execution gas. Blobs удаляются через ~18 дней, но commitment (KZG) остаётся навсегда.

Celestia — специализированный DA layer. Data availability sampling (DAS): light nodes проверяют доступность через random sampling, не скачивая весь блок. Стоимость на порядки ниже Ethereum blobs при сопоставимых security guarantees для большинства use cases.

EigenDA — DA layer поверх Ethereum через EigenLayer restaking. Экономическая безопасность от рестейкнутого ETH. Значительно выше throughput чем Ethereum L1 при более высоких security гарантиях (на сегодня).

Avail — DA layer с data availability sampling, forkless upgrades. Хорошая альтернатива Celestia.

Settlement Layer

Финализация: определяет, что является каноническим состоянием rollup. Обрабатывает withdrawals, resolves disputes.

Для большинства проектов — Ethereum mainnet через L1 bridge contract. Альтернатива для L3 — использовать L2 как settlement layer (например, Arbitrum One как settlement для Orbit chain).

Как интегрировать Celestia DA в OP Stack?

Покажу конкретную конфигурацию, которую используют в production. Пошаговая инструкция:

  1. Разверните Celestia light node и получите auth token.
  2. Зарезервируйте уникальный namespace (29 байт).
  3. Реализуйте AltDA provider, реализующий интерфейсы GetInput и SetInput.
  4. Настройте op-batcher на использование Celestia как DA layer.
  5. Деплойте на Ethereum L1 контракты OptimismPortal и L2OutputOracle.

AltDA provider для Celestia

// Реализация AltDA provider для Celestia
type CelestiaAltDA struct {
    da *CelestiaDA
}

func (c *CelestiaAltDA) GetInput(ctx context.Context, commitment []byte) ([]byte, error) {
    height, err := decodeCommitment(commitment)
    if err != nil {
        return nil, err
    }
    return c.da.Retrieve(ctx, height)
}

func (c *CelestiaAltDA) SetInput(ctx context.Context, data []byte) ([]byte, error) {
    height, err := c.da.Submit(ctx, data)
    if err != nil {
        return nil, err
    }
    return encodeCommitment(height), nil
}

Конфигурация op-batcher для Celestia

[da]
type = "celestia"
rpc = "http://celestia-light-node:26658"
auth_token = "${CELESTIA_AUTH_TOKEN}"
namespace = "0x0000000000000000000000000000000000yournamespace"

L1 Settlement контракты

На Ethereum деплоятся два контракта. OptimismPortal — входная/выходная точка для cross-domain сообщений и withdrawals. L2OutputOracle — хранит state roots предложенные proposer'ом.

contract L2OutputOracle {
    struct OutputProposal {
        bytes32 outputRoot;
        uint128 timestamp;
        uint128 l2BlockNumber;
    }
    
    OutputProposal[] public l2Outputs;
    address public proposer;
    uint256 public constant FINALIZATION_PERIOD = 7 days;
    
    function proposeL2Output(
        bytes32 _outputRoot,
        uint256 _l2BlockNumber,
        bytes32 _l1BlockHash,
        uint256 _l1BlockNumber
    ) external payable {
        require(msg.sender == proposer, "Not proposer");
        require(blockhash(_l1BlockNumber) == _l1BlockHash, "Bad L1 block");
        
        l2Outputs.push(OutputProposal({
            outputRoot: _outputRoot,
            timestamp: uint128(block.timestamp),
            l2BlockNumber: uint128(_l2BlockNumber)
        }));
    }
}

Как кастомизировать execution layer?

Custom precompiles

Precompiles — предкомпилированные контракты по фиксированным адресам с нативной реализацией. Например, добавить BLS12-381 операции или кастомный хэш-алгоритм:

var CustomPrecompiles = map[common.Address]vm.PrecompiledContract{
    common.HexToAddress("0x0000000000000000000000000000000000000100"): &blsG1Add{},
    common.HexToAddress("0x0000000000000000000000000000000000000101"): &customHashFunction{},
}

type blsG1Add struct{}

func (c *blsG1Add) RequiredGas(input []byte) uint64 { return 500 }

func (c *blsG1Add) Run(input []byte) ([]byte, error) {
    if len(input) != 128 {
        return nil, errors.New("invalid input length")
    }
    p1 := new(bls12381.G1Affine)
    p2 := new(bls12381.G1Affine)
    p1.Unmarshal(input[:64])
    p2.Unmarshal(input[64:])
    result := new(bls12381.G1Affine).Add(p1, p2)
    return result.Marshal(), nil
}

Gas token кастомизация

OP Stack поддерживает Custom Gas Token — native gas token, отличный от ETH. Это позволяет использовать ваш ERC-20 токен как gas. Ограничение: custom gas token должен быть задеплоен на L1, иметь стандартный ERC-20 интерфейс и не иметь transfer fees (rebasing/fee-on-transfer токены не поддерживаются).

Fee структура и sequencer revenue

User Transaction Fee = (base_fee + priority_fee) * gas_used + L1 data fee
Sequencer Revenue = collected fees - DA costs - L1 costs

При использовании Celestia вместо Ethereum для DA, L1 data fee снижается на 90–95% для большинства транзакций.

Что входит в работу

  • Анализ требований и выбор стека (OP Stack, Celestia, Ethereum) с обоснованием.
  • Разработка и деплой core контрактов (bridge, L2OutputOracle, OptimismPortal).
  • Интеграция кастомного DA provider для Celestia.
  • Настройка execution layer (кастомные precompiles, gas token).
  • Развёртывание тестнета, написание тестов и стресс-тестирование.
  • Аудит смарт-контрактов (bridge, fault proof) и исправление уязвимостей.
  • Помощь в запуске mainnet, мониторинг и поддержка после запуска.
  • Документация по архитектуре, деплою и эксплуатации.

Сравнение DA слоёв

Детальное сравнение
Параметр Ethereum L1 (blobs) Celestia EigenDA
Security Максимальная Высокая (DAS) Экономическая (restaking)
Стоимость Высокая Низкая Средняя
Throughput ~0.5 MB/s ~1 MB/s ~10 MB/s
Время финализации ~15 мин ~30 сек ~10 сек
Зрелость Production Production Beta

Декомпозиция по срокам

Фаза Содержание Срок
Design Выбор стека, namespace, токеномика, bridge design 2–3 нед
Core setup op-stack deployment, L1 contracts, genesis 3–4 нед
DA integration Celestia/EigenDA connector, batcher config 2–3 нед
Testnet Публичный тестнет, bridge testing, stress test 3–4 нед
Security Аудит bridge контрактов, fault proof testing 4–6 нед
Mainnet Деплой, sequencer ops, monitoring 2–3 нед

Критический путь — аудит bridge контрактов. Bridge — это где живут реальные деньги пользователей, и именно здесь большинство L2 находило критические уязвимости. Экономить на аудите bridge нельзя.

Итого: 16–23 недели от старта до mainnet. Команда: 2–3 backend инженера с опытом Go, 1 Solidity разработчик, DevOps/инфраструктурный инженер.

Готовы обсудить ваш проект и предложить оптимальное решение. Получите консультацию — свяжитесь с нами.

Развертывание блокчейн-инфраструктуры: ноды, RPC, индексация

Subgraph упал в 3:47 ночи. К утру пользователи видели устаревшие балансы, транзакции «висели» в UI, поддержка получила 47 тикетов за час. Причина: handler в subgraph упал на транзакции с нестандартным event log — и весь индекс встал. Мы сталкивались с такими ситуациями десятки раз. Наш опыт показывает: блокчейн-инфраструктура не прощает gaps в observability. Гарантировать uptime без многослойного мониторинга и fault‑tolerant архитектуры невозможно. За 8 лет работы с Ethereum, Polygon и Solana мы выработали подход, который позволяет предсказуемо развёртывать инфраструктуру любого масштаба — от одиночной ноды до мультичейн‑сетки с десятками субграфов.

Архитектура RPC-слоя

Каждое взаимодействие dApp с блокчейном идёт через RPC — JSON‑RPC API, которую предоставляет нода. Три варианта:

Managed providers — Alchemy, QuickNode, Infura, Ankr. Минимальные операционные расходы, SLA, встроенный мониторинг. Ограничения: rate limits (Alchemy Free: 300 RU/sec), vendor lock, потенциальные downtime при инцидентах провайдера. Для большинства проектов — правильный выбор на старте.

Собственные ноды — полный контроль, нет rate limits, нет зависимости от третьих сторон. Стоимость: архивная нода Ethereum занимает 2.5–3TB SSD, требует мощный сервер и DevOps‑поддержку. Sync с нуля на Ethereum через Geth/Nethermind — 3–7 дней. Оправдано при высокой нагрузке или требованиях к latency.

Гибрид — собственная нода как primary, managed provider как fallback. Стандарт для протоколов с TVL от $10M. Правильная балансировка может сократить расходы на 20–30% по сравнению с чисто managed‑схемой. При нагрузке 10 млн запросов в месяц гибрид экономит от $1500 до $3000.

Провайдер Сильная сторона Ограничение
Alchemy Supernode, Enhanced APIs, webhooks Дорогой на high-volume
QuickNode Низкая latency, multi-chain Дороже Alchemy на базовом плане
Infura Историческая надёжность Rate limits на бесплатном, один крупный инцидент остановил пол‑DeFi
Ankr Дешёвый, 40+ чейнов Менее стабильный

Как настроить RPC-слой без единой точки отказа?

Минимум два провайдера, DNS round‑robin с health check каждые 5 секунд, автоматическое переключение на fallback при latency >500 мс. На практике это даёт 99.99% доступности при любом сбое провайдера. Для протоколов с TVL от $10M мы рекомендуем собственный HA‑прокси (nginx или Envoy) перед двумя managed‑провайдерами.

Почему гибридная RPC-схема выгоднее чисто managed?

При 50 млн запросов в месяц Alchemy стоит $2000+, QuickNode — $2500+, собственная нода — $400–600 за хостинг + DevOps. Гибрид: primary — своя нода ($500), fallback — QuickNode ($500), итого ~$1000. Экономия 50–60% без потери SLA.

Клиенты нод Ethereum

Execution clients: Geth (наиболее используемый), Nethermind (C#, быстрая sync), Besu (Java, enterprise), Erigon (самый быстрый sync, архивный режим эффективен по диску — ~2TB вместо 3TB).

Consensus clients (post‑Merge): Lighthouse (Rust), Prysm (Go), Teku (Java), Nimbus (Nim). Каждая нода после The Merge требует пары execution + consensus client.

Для DevOps: eth‑docker — Docker Compose конфигурации для всех комбинаций клиентов. Настройка мониторинга через Grafana + Prometheus — обязательна, стандартный дашборд есть в репозитории каждого клиента.

The Graph: индексация событий

The Graph Protocol — decentralized indexing. Subgraph описывает какие события с каких контрактов индексировать и как трансформировать их в GraphQL схему.

Структура subgraph:

  • subgraph.yaml — манифест: адреса контрактов, startBlock, события которые обрабатываются
  • schema.graphql — GraphQL схема entities
  • src/mapping.ts — AssemblyScript обработчики событий
dataSources:
  - kind: ethereum
    name: UniswapV3Pool
    network: mainnet
    source:
      address: "0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640"
      abi: UniswapV3Pool
      startBlock: 12370624
    mapping:
      eventHandlers:
        - event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
          handler: handleSwap

AssemblyScript handlers — не TypeScript. Нет nullable types, нет closures, нет многих стандартных API. Ошибка в handler останавливает индексацию subgraph-а на той транзакции. Важно: добавлять try‑catch на операции которые могут падать (например store.get() для entity которая может не существовать).

Как избежать остановки индексации субграфа?

Лог файлы Graph Node мониторятся в реальном времени, при hasIndexingErrors = true срабатывает алерт и автоматический рестарт ноды (через systemd или Kubernetes). Типичный downtime при ошибке — 150–300 секунд до восстановления. Дополнительно: для production ставим watchdog, который перезапускает Graph Node если subgraph lag превышает 50 блоков.

Выбор между Hosted Service и Decentralized Network

Graph Hosted Service (бесплатный, централизованный) deprecated в пользу Subgraph Studio + Graph Network. Для продакшн: деплой на Graph Network с GRT curation signal — субграф получает indexers пропорционально curation.

Альтернативы The Graph: Ponder (TypeScript, self-hosted, проще дебагать), Envio (ultra‑fast indexer, поддерживает EVM + non‑EVM), Subsquid (TypeScript, своя сеть), Moralis Streams (managed, webhook‑based). Наш опыт показывает: для высоконагруженных проектов с уникальной логикой эффективнее Ponder или Envio — они дают полный контроль над процессом и не требуют токеномики GRT.

Webhooks и real-time нотификации

Alchemy Webhooks и QuickNode Streams позволяют получать события в реальном времени через HTTP webhook или WebSocket. Для мониторинга адресов, новых транзакций, минтов — это быстрее чем polling RPC.

Tenderly — платформа для мониторинга и алертов. Можно настроить alert на конкретный event из контракта, на изменение баланса, на вызов функции с определёнными параметрами. Симуляция транзакций через Tenderly API — бесценно для debugging.

Мониторинг и observability

Минимальный стек мониторинга для протокола:

On‑chain: OpenZeppelin Defender Sentinel — watches contract events, вызывает webhook или Autotask при срабатывании условий. Forta Network — community‑maintained боты детектируют аномалии (большие withdrawals, flash loans, governance attacks).

Infrastructure: Grafana + Prometheus для нод, Datadog или Grafana Cloud для managed метрик. Alert на: нода отстала на 10+ блоков, RPC latency > 500ms, subgraph lag > 100 блоков.

Uptime: Better Uptime или PagerDuty на RPC endpoint и subgraph health endpoint (The Graph предоставляет _meta { hasIndexingErrors, block { number } }).

Почему мониторинг без Tenderly недостаточен?

Tenderly даёт симуляцию транзакций и детальные трейсы — это критично для отладки ошибок в субграфах и смарт‑контрактах. Forta же фокусируется на аномалиях в сети, а не на вашей инфраструктуре. Комбинация Tenderly + собственный дашборд Grafana покрывает 90% сценариев инцидентов.

Мультичейн инфраструктура

Протокол на 5 чейнах = 5 отдельных RPC endpoints, 5 subgraphs, 5 мониторинг‑конфигов. Это управляемо, но нужна автоматизация деплоя.

Для subgraph multi‑network деплой: graph deploy --network mainnet, graph deploy --network arbitrum-one и т.д. с единой кодовой базой и network‑specific адресами в отдельных файлах конфигурации.

Chainlink CCIP и LayerZero для cross‑chain messaging требуют мониторинга состояния обоих чейнов и транзакций на intermediate relayers. Реорг на source chain при уже подтверждённом минте на target chain — классическая проблема мостов. Решение: ждать finality (на Ethereum ~15 минут после Merge для экономической finality) перед подтверждением на target chain.

Процесс настройки инфраструктуры

  1. Аудит текущего стека — определяем чейны, объём запросов, требования к latency и доступности.
  2. Проектирование архитектуры — выбор провайдеров, балансировка, redundancy.
  3. Разработка subgraph — манифест → схема → handlers → тестирование на локальной Graph Node → деплой на testnet → mainnet.
  4. Конфигурация мониторинга — Tenderly alerts, Grafana дашборд, PagerDuty интеграция.
  5. Документация и runbook — что делать при: subgraph fell behind, RPC downtime, нода desync.
  6. Передача в эксплуатацию — обучение команды, передача доступов, поддержка первый месяц.

Что входит в работу

  • Развёртывание managed или self‑hosted нод Ethereum, Polygon, BNB Chain
  • Настройка RPC‑слоя с primary/fallback и load balancing
  • Разработка и деплой subgraph под ваш протокол
  • Подключение мониторинга (Tenderly, Grafana, алерты)
  • Создание runbook и документации по эксплуатации
  • Обучение команды (до 4 часов онлайн)
  • Поддержка в течение 30 дней после сдачи

Сроки

Работа Срок
Настройка RPC и базового мониторинга 1–2 недели
Subgraph для одного протокола 2–4 недели
Self-hosted нода с мониторингом 2–3 недели
Полная инфраструктура (multi-chain, мониторинг, runbooks) 6–10 недель

Все проекты ведутся в репозитории на GitHub/GitLab с CI/CD, код конфигураций остаётся у вас. Закажите развертывание инфраструктуры — расскажем, как сократить расходы на 20–30% без потери надёжности. JSON‑RPC спецификация, документация The Graph. Получите консультацию — покажем, как мы развёртывали инфраструктуру для протокола с TVL $50M+ на Ethereum и Arbitrum.

Свяжитесь с нами.