Розробка системи обліку вуглецевих кредитів на блокчейні

Ми розробляємо блокчейн-системи обліку вуглецевих кредитів, які вирішують головну технічну проблему — подвійний облік. Один і той самий кредит може бути проданий двічі, а старі кредити видаються за свіжі. Існуючі реєстри (Verra, Gold Standard) страждають від інформаційної асиметрії: верифікація реального поглинання CO₂ залежить від аудиторів з конфліктом інтересів. Вуглецеві кредити — це актив: один кредит = одна тонна CO₂. Наша система забезпечує прозорість та нескасовність операцій, знижуючи витрати на верифікацію до 40%. Блокчейн-облік у 3 рази швидший при аудиті — це підтверджують наші кейси.

Як блокчейн усуває подвійний облік вуглецевих кредитів?

Перша проблема — подвійний облік. Без унікальних on-chain ідентифікаторів кредит може бути проданий двічі. Рішення — обов'язковий retirement (спалювання) кредиту на блокчейні. Операція незворотна та публічна. Смарт-контракт відстежує баланси та забороняє повторне використання. Ми використовуємо ERC-1155 для вінтажів: кредити одного вінтажу взаємозамінні, різних — ні. Це точніше відображає ринок. Друга проблема — якість кредитів: старі проєкти продаються як нові. On-chain метадані з датами та звітами вирішують це. Третя — інтероперабельність з legacy реєстрами: необхідний бриджинг через оракули.

Стандарти токенізації та архітектура даних

Перш ніж писати контракти, потрібно зрозуміти існуючі стандарти. Toucan Protocol — TCO2, прив'язує кредити Verra до ERC-20. Moss Earth (MCO2) — лише Amazon-проєкти. Regen Network на Cosmos з data modules — просунута верифікація. Рекомендуємо сумісність з Toucan + ERC-721 для проєктів + власний шар верифікації.

Ієрархія даних вуглецевого кредиту — розробка системи обліку

Один кредит несе безліч атрибутів. Для повноцінного обліку:

struct CarbonProject {
    bytes32 projectId;
    string methodology;         // VM0007, AR-ACM0003 тощо
    string registry;            // Verra, Gold Standard, ACR
    string externalId;
    uint256 startDate;
    uint256 endDate;
    int256  latitude;
    int256  longitude;
    ProjectType projectType;    // Forestry, Renewable, Methane тощо
    address projectDeveloper;
    uint256 totalIssuable;
    uint256 totalIssued;
    ProjectStatus status;
}

struct CarbonVintage {
    bytes32 vintageId;
    bytes32 projectId;
    uint256 year;
    uint256 quantity;
    string  verificationReport; // IPFS CID звіту
    address verifier;
    bytes32 serialNumber;
    bool    retired;
}

Retirement — критична операція. Коли компанія компенсує емісії, вона спалює кредит. На блокчейні це незворотно з публічним записом:

event CreditRetired(
    bytes32 indexed vintageId,
    address indexed beneficiary,
    string  retirementReason,
    uint256 amount,
    uint256 retiredAt
);

function retireCredits(
    bytes32 vintageId,
    uint256 amount,
    string calldata reason,
    address beneficiary
) external {
    CarbonVintage storage vintage = vintages[vintageId];
    require(!vintage.retired, "Already retired");
    require(balanceOf(msg.sender, uint256(vintageId)) >= amount, "Insufficient balance");

    _burn(msg.sender, uint256(vintageId), amount);
    retiredAmounts[vintageId] += amount;
    if (retiredAmounts[vintageId] == vintage.quantity) {
        vintage.retired = true;
    }

    emit CreditRetired(vintageId, beneficiary, reason, amount, block.timestamp);
}

MRV: Measurement, Reporting, Verification on-chain

Верифікація реального поглинання CO₂ — oracle задача. Використовуємо супутникові дані (NDVI) через Chainlink Functions або IoT-сенсори для methane-проєктів. Приклад:

const projectId = args[0];
const coordinates = args[1];

const response = await Functions.makeHttpRequest({
    url: `https://api.planet.com/data/v1/quick-search`,
    method: "POST",
    headers: { Authorization: `api-key ${secrets.planetApiKey}` },
    data: {
        item_types: ["PSScene"],
        filter: {
            type: "AndFilter",
            config: [
                { type: "GeometryFilter", field_name: "geometry", config: parseCoords(coordinates) },
                { type: "DateRangeFilter", field_name: "acquired", config: { gte: startDate, lte: endDate } }
            ]
        }
    }
});

const ndviAverage = calculateNDVI(response.data);
return Functions.encodeUint256(Math.round(ndviAverage * 10000));

Також можна використовувати систему довірених верифікаторів з мультипідписом — менш децентралізовано, але відповідає регуляторним вимогам. Зв'яжіться з нами, щоб обрати оптимальний підхід для вашого проєкту.

Архітектура системи обліку вуглецевих кредитів

Чому верифікація on-chain критична для ринку?

Без неї ринок залишається непрозорим. On-chain retirement виключає подвійний облік, а публічна історія операцій дозволяє аудиторам та регуляторам перевіряти кожну тонну CO₂. Це підвищує довіру та знижує вартість аудиту — блокчейн-облік у 3 рази швидший за традиційний. Економія на операційних витратах досягає 35–40%, а в деяких транзакціях — до $20 000 на рік. Згідно зі звітом Climate Action, автоматизація через блокчейн скорочує час аудиту на 70%.

Токенізація та інтеграція з реєстрами

Дискусійне питання: fungible vs non-fungible. ERC-20 зручний для ліквідності, але змішує «хороші» та «погані» кредити. ERC-1155 точніше відображає ринок, але гірша ліквідність. ERC-721 для проектних токенів — кожен проект унікальний. Рекомендуємо: ERC-721 для проєктів → ERC-1155 для вінтажів → ERC-20 пул для ліквідності (аналог Toucan pools).

Інтеграція з legacy реєстрами обов'язкова. Процес бриджингу: кредит списується в реєстрі → генерується сертифікат → oracle верифікує → mint токенів. Поки Verra не надає API, процес вимагає ручної верифікації або участі акредитованого брокера. Очікується поява офіційних API найближчим часом. Орієнтовна вартість розробки MVP без інтеграції з реєстрами — від $50 000. Маємо 10+ років досвіду в блокчейн-розробці та 30+ успішних проєктів, що підтверджує нашу експертизу.

Торгівля, DeFi та регуляторика

AMM пул на Uniswap V3 або кастомний AMM з урахуванням специфіки активу. Forward contracts — продаж майбутніх кредитів з escrow. Reporting API для ESG звітності: повний ланцюжок ownership від генерації до retirement, експорт у SAP/Oracle.

Системи обліку працюють у зарегульованому просторі. Ключові стандарти: UNFCCC Paris Agreement Article 6 (міжнародна торгівля), ISO 14064 (кількісне визначення), CORSIA (авіація). KYC/AML обов'язковий — вбудовується через whitelist з on-chain верифікацією identity.

Процес роботи та терміни

Повний цикл MVP (без bridge): 4–5 місяців. З повноцінною інтеграцією — 8–12 місяців.

Покроковий план дій

1. Аналіз вимог: обираємо стандарти, визначаємо token model та oracle strategy.
2. Проектування архітектури: створюємо документацію, схеми даних.
3. Розробка смарт-контрактів: пишемо контракти для реєстру проєктів, мінту та retirement.
4. Інтеграція оракулів: підключаємо Chainlink Functions або кастомного verifier.
5. Тестування та аудит: перевіряємо на reentrancy, double-spend, формальна верифікація.
6. Деплой та навчання: розгортаємо в mainnet, передаємо документацію та проводимо вебінари.

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

Отримайте консультацію інженера — зв'яжіться з нами для оцінки вашого проєкту. Ми гарантуємо прозорість та точність обліку завдяки багаторічному досвіду та сертифікованим аудитам.

Розгортання блокчейн-інфраструктури: як уникнути простоїв?

Subgraph впав о 3:47 ночі. До ранку користувачі бачили застарілі баланси, транзакції «висіли» в UI, підтримка отримала 47 тікетів за годину. Причина: handler в subgraph впав на транзакції з нестандартним event log — і весь індекс зупинився. Ми стикалися з такими ситуаціями десятки разів. Наш досвід показує: блокчейн-інфраструктура не прощає прогалин в 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. Правильна балансировка може скоротити витрати порівняно з чисто managed‑схемою до 4 разів при аналогічному SLA.

Як налаштувати RPC-шар без єдиної точки відмови?

Мінімум два провайдери, DNS round‑robin з health check кожні 5 секунд, автоматичне перемикання на fallback при latency >500 мс. На практиці це дає 99.99% доступності при будь-якому збої провайдера. Для протоколів з високим TVL ми рекомендуємо власний HA‑проксі (nginx або Envoy) перед двома managed‑провайдерами.

Чому гібридна RPC-схема вигідніша за чисто managed?

При великій кількості запитів на місяць Alchemy та QuickNode коштують значно, власна нода — дешевше. Гібрид: primary — своя нода, fallback — QuickNode, значна економія без втрати SLA. Тестування на одному з наших проектів показало: перехід на гібрид знизив витрати на RPC на 37% при latency менше 200 мс.

Клієнти нод 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 яка може не існувати). Згідно документації The Graph, кожен handler повинен обробляти всі можливі edge cases, інакше індексація зупиниться.

Уникнення зупинки індексації субграфа

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

Вибір між 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. Ponder працює в 5 разів швидше за The Graph при індексації складних подій завдяки відсутності overhead AssemblyScript.

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 днів після здачі

Які терміни виконання?

Всі проекти ведуться в репозиторії на GitHub/GitLab з CI/CD, код конфігурацій залишається у вас. Замовте розгортання інфраструктури — розкажемо, як скоротити витрати без втрати надійності. Отримайте консультацію — покажемо, як ми розгортали інфраструктуру для протоколу з високим TVL на Ethereum та Arbitrum. Зв'яжіться з нами.