Розробка AVS (Actively Validated Service) на EigenLayer

Розробка EigenLayer AVS (Actively Validated Service)

AVS — протокол, який використовує економічну безпеку Ethereum через EigenLayer. Замість побудови власного набору валідаторів з нуля, AVS "знімає в оренду" безпеку від тисяч валідаторів Ethereum, які переставили свій ETH. Це значно зменшує вартість запуску нового протоколу.

Що можна будувати як AVS

Будь-який протокол, що вимагає децентралізованого набору валідаторів для чесного виконання:

• Шар доступності даних (як EigenDA — перший офіційний AVS)
• Oracle мережа (як Chainlink, але на безпеці Ethereum)
• Кросс-ланцюговий міст — валідатори підписують кросс-ланцюгові повідомлення
• Пороговое шифрування — розшифрування при умові виконання
• ZK proof генерація — децентралізована мережа доказувача
• Shared sequencer — для rollup мереж

Архітектура AVS

AVS складається з двох частин:

On-chain контракти

ServiceManager: центральний контракт AVS. Реєструє операторів, управляє завданнями, викликає слешинг при порушеннях.

contract YourAVSServiceManager is ServiceManagerBase {
    struct Task {
        bytes32 dataRoot;
        uint32 taskCreatedBlock;
        bytes quorumNumbers;
        uint32 quorumThresholdPercentage;
    }
    
    mapping(uint32 => Task) public allTaskHashes;
    uint32 public latestTaskNum;
    
    function createNewTask(bytes32 dataRoot) external {
        Task memory newTask = Task({
            dataRoot: dataRoot,
            taskCreatedBlock: uint32(block.number),
            quorumNumbers: hex"00",
            quorumThresholdPercentage: 66  // 66% кворум
        });
        allTaskHashes[latestTaskNum] = newTask;
        emit NewTaskCreated(latestTaskNum, newTask);
        latestTaskNum++;
    }
    
    function respondToTask(
        Task calldata task,
        uint32 referenceTaskIndex,
        bytes calldata signature
    ) external {
        // Перевірити агреговану BLS підпис від операторів
        // Якщо кворум досягнутий — завдання виконане
    }
}

BLSSignatureChecker: верифікація агрегованих BLS підписів від групи операторів. Ця бібліотека від EigenLayer робить важку роботу.

RegistryCoordinator: управління реєстром операторів, їх stake та членством у кворумі.

Off-chain node software

Програма, яку запускають оператори. Вона:

1. Стежить за подіями NewTaskCreated на контракті AVS
2. Виконує роботу (напр., завантажує дані, обчислює хеш)
3. Підписує результат BLS ключем
4. Відправляє підпис до aggregator

Aggregator: off-chain сервіс, який збирає підписи операторів, агрегує BLS підписи, публікує on-chain при досягненні кворуму.

// Спрощений оператор вузла
func (o *Operator) ProcessTask(task Task) {
    // Виконати роботу
    result := o.computeTaskResult(task)
    
    // Підписати BLS ключем
    sig := o.blsKeyPair.SignMessage(result.Hash())
    
    // Відправити до aggregator
    o.aggregatorRpcClient.SendSignedTaskResponse(&SignedTaskResponse{
        TaskResponse: result,
        BlsSignature: sig,
        OperatorId:   o.operatorId,
    })
}

Механізм слешингу

Критичний компонент AVS — fraud proof та слешинг.

Об'єктивні умови слешингу: умови повинні бути об'єктивно верифіковані on-chain. Не можна карати за суб'єктивні причини.

Fraud proof: при виявленні порушення (двійне підписання, підписання неправильного результату) — постачальник надає fraud proof контракту.

Слешинг виклик: контракт AVS викликає механізм слешингу EigenLayer, який зменшує shares оператора порушника.

Veto комітет: EigenLayer має security council, який може vetо слешингам. Захист від неправильних або злонамірних слешингів.

Економіка AVS

Оператори беруть участь у AVS, тому що отримують AVS винагороди. Моделі:

• Фіксована винагорода в ETH або AVS ERC-20 токені за виконане завдання
• APY поверх базової винагороди ETH стейкингу
• Токени керування AVS

AVS повинен бути достатньо привабливим за yield для операторів, щоб взяти на себе додатковий ризик слешингу.

Розробка MVP AVS — 3-6 місяців для досвідченої команди. Production-ready з security audits та mainnet запуском — 9-12 місяців.