Розробка системи винагород DePIN-учасників

Розробка системи вознаграджень DePIN-учасників

DePIN (Decentralized Physical Infrastructure Networks) — це протоколи, в яких token-incentives привлекають операторів фізичного обладнання: бездротові мережі (Helium), GPU кластери (Akash, io.net), сенсорні мережи (WeatherXM, DIMO), сховища (Filecoin, Arweave). Спільний паттерн: учасник надає ресурс, отримує токени.

Система вознаграджень у DePIN — це не просто «розповсюджувати токени по адресах». Це механізм, що повинен вирішити кілька конкуруючих завдань одночасно: вознаградити реальний внесок, наказати за мошенництво, привернути нових учасників у недостатньо обслуговуванні зони, та при цьому залишатися економічно стійким при падінні ціни токена.

Вимірювання внеску: oracle problem

Фундаментальна DePIN проблема: фізичний світ не має прямого доступу до блокчейну. GPU utilization, радіосигнал, температурні дані — все це off-chain. Система вознаграджень повністю залежить від якості цих даних.

Proof of Coverage (Helium модель)

Helium винайшов елегантне рішення для бездротових мереж: hotspot'и періодично передають beacon сигнали, сусідні hotspot'и їх отримують та публікують cryptographic witness. Це доводить, що обладнання працює та покриває певну географічну зону.

Ключове: witness підписаний ключем hotspot'а, містить packet hash та RSSI (рівень сигналу). Оракули верифікують фізичну реальність через геодезичні розрахунки: два hotspot'и на відстані 1 км не можуть отримати силу сигналу -50 dBm — це фізично неможливо. Такий witness відхиляється як fraud.

Verifiable Computing (GPU/compute мережі)

Для обчислювальних ресурсів доказ внеску будується інакше:

Challenge-response: оркестратор періодично відправляє compute worker контрольне завдання з відомою відповіддю. Worker повинен повернути правильний результат за встановлений час.

Redundant computation: одне завдання відправляється кільком workers незалежно. Розхідність результатів → один нечесен → stake penalty.

ZK proofs: worker генерує proof що обчислення виконано коректно (RISC Zero, SP1). Верифікується on-chain без re-execution. Дорого для складних обчислень, ідеально для proof-of-work типу завдань.

Sensor networks: trusted hardware

WeatherXM, DIMO та подібні мережі покладаються на trusted hardware з вбудованими ключами (secure enclave, TPM). Пристрій підписує дані своїм hardware ключем, зареєстрованим у протоколі при onboarding. Це доводить аутентичність пристрою, не дані — можна нагріти термометр.

Додатковий шар: cross-validation між сусідніми пристроями. Якщо один пристрій показує аномалію, яку не підтверджують сусіди — дані дисконтуються або відхиляються.

Моделі розрахунку вознаграджень

Epoch-based розподіл

Стандартна модель: раз на epoch (день/тиждень) оракули агрегують дані про внесок кожного учасника, розраховують вознаграждення, публікують merkle root. Учасники отримують токени через merkle proof.

contract DePINRewards {
    bytes32 public currentEpochRoot;
    uint256 public currentEpochId;
    uint256 public epochRewardPool; // токени на epoch
    
    mapping(uint256 => mapping(address => bool)) public epochClaimed;
    
    // Оракул публікує результати epoch
    function publishEpochResults(
        uint256 epochId, 
        bytes32 merkleRoot,
        uint256 totalPoints  // сума всіх points для нормалізації
    ) external onlyOracle {
        epochRoots[epochId] = merkleRoot;
        epochTotalPoints[epochId] = totalPoints;
        emit EpochPublished(epochId, merkleRoot, totalPoints);
    }
    
    // Учасник отримує своє вознаграждення
    function claimEpochReward(
        uint256 epochId,
        uint256 contributionPoints,  // очки учасника
        bytes32[] calldata proof
    ) external {
        require(!epochClaimed[epochId][msg.sender], "Already claimed");
        
        bytes32 leaf = keccak256(bytes.concat(
            keccak256(abi.encode(msg.sender, epochId, contributionPoints))
        ));
        require(
            MerkleProof.verify(proof, epochRoots[epochId], leaf),
            "Invalid proof"
        );
        
        uint256 reward = (contributionPoints * epochRewardPool) 
                         / epochTotalPoints[epochId];
        
        epochClaimed[epochId][msg.sender] = true;
        rewardToken.transfer(msg.sender, reward);
        
        emit RewardClaimed(msg.sender, epochId, reward);
    }
}

Points vs. прямий розподіл

Замість прямого розподілу токенів зручніше рахувати в абстрактних «очках», які потім конвертуються в токени за курсом epoch. Це дозволяє:

• Масштабувати reward pool без зміни формули розрахунку
• Легко додавати нові типи внеску з різними вагами
• Застосовувати multipliers (boost за staking, географічний бонус)

Multipliers та boosts

Helium використовує staking multiplier: hotspot з 10,000 HNT у stake отримує 3x вознаграждення. Це утримує токени у протоколі та вознаграджує long-term committed операторів.

function calculateEffectivePoints(
    address operator,
    uint256 basePoints
) public view returns (uint256) {
    uint256 staked = stakingContract.stakedAmount(operator);
    uint256 multiplierBps = _getStakingMultiplier(staked);
    
    // Географічний бонус для недостатньо обслуговуваних зон
    bytes32 locationHash = operatorLocations[operator];
    uint256 geoBonusBps = coverageOracle.getLocationBonus(locationHash);
    
    return basePoints * (multiplierBps + geoBonusBps) / 10000;
}

function _getStakingMultiplier(uint256 staked) internal pure returns (uint256) {
    if (staked >= 100_000e18) return 30000; // 3x
    if (staked >= 10_000e18)  return 20000; // 2x
    if (staked >= 1_000e18)   return 15000; // 1.5x
    return 10000; // 1x baseline
}

Захист від Sybil та fraud

Staking-based Sybil resistance

Реєстрація нового обладнання вимагає stake. При підтвердженому fraud — stake slashing. Робить масове створення фіктивних пристроїв економічно невигідним.

Geographic fraud detection

Для location-based протоколів: два пристрої не можуть фізично бути в одному місці, але реєструватися в різних hexagonal ячейках для подвійного вознаградження. Рішення: H3 геогрід (Uber's Hexagonal Hierarchical Spatial Index), обмеження density per hex.

# Off-chain оракул: перевірка geographic консистенції
import h3

def validate_coverage_claim(device_id: str, lat: float, lng: float, 
                             signal_range_km: float) -> bool:
    # Отримуємо H3 ячейки в радіусі дії пристрою
    center_hex = h3.latlng_to_cell(lat, lng, resolution=8)
    covered_hexes = h3.grid_disk(center_hex, k=int(signal_range_km / 0.5))
    
    # Перевіряємо, чи не перетинається coverage з уже зареєстрованими
    for hex_id in covered_hexes:
        existing_devices = registry.devices_in_hex(hex_id)
        if len(existing_devices) >= MAX_DEVICES_PER_HEX:
            return False  # oversaturation fraud
    
    return True

Decentralized oracle network для верифікації

Централізований оракул — це single point of failure та атаки. Зрілі DePIN протоколи переходять до decentralized oracle networks: множинність незалежних операторів збирають дані, консенсус визначає «істину».

Helium перейшов з централізованого oracle на сеть validators після кількох інцидентів з недостовірними даними. Proof of Coverage тепер верифікується через Helium Oracle Network — набір операторів, що обробляють PoC активність та публікують результати в Solana.

Компоненти інфраструктури

Система вознаграджень DePIN — це не просто смарт-контракт. Це економічний механізм з реальними фізичними учасниками де помилки у дизайні приводять до fraud епідемій або exodus операторів. Правильно спроектована система повинна бути стійкою до раціонально-корисливих учасників — це означає що честна участь повинна бути вигідніше мошенництва при будь-якому співвідношенні вознаграждення та вартості атаки.