Блокчейн-индустрия переживает период беспрецедентного роста. Общая стоимость заблокированных активов (total value locked, TVL) в децентрализованных финансовых протоколах превышала 200 млрд долларов по состоянию на 2024 год [1]. Увеличение объемов капитала в экосистеме неизбежно делает DeFi-протоколы привлекательной целью для злоумышленников. В результате вместе с развитием рынка увеличивается и количество инцидентов безопасности, связанных с уязвимостями в смарт-контрактах. Как следствие, индустрия терпит колоссальные убытки. Согласно отчету Chainalysis, только в 2023 году потери от хакерских атак на DeFi-протоколы составили более 3,7 млрд долларов [2].

Я Радда Юрьева, работаю в команде AppSec и вместе с коллегами из отдела Web3 исследую вопросы безопасности смарт-контрактов. В этой статье хочу поделиться нашим опытом анализа уязвимостей Solidity-кода и рассказать, какие подходы помогают находить и предотвращать ошибки на ранних этапах разработки Solidity-контрактов.

Поводом для исследования послужило внедрение в наш анализатор защищенности веб-приложений (PT Application Inspector) средств формального SAST для смарт-контрактов. Мы принялись изучать возможность детектирования дефектов и уязвимостей, которые не укладываются или плохо укладываются в традиционные модели синтаксического и taint-анализа. Речь о классах вроде reentrancy (SWC-107), логических/бизнес-ошибок (нарушение инвариантов между функциями, некорректные проверки прав доступа), манипуляций с ценовыми оракулами, нарушений шаблона checks-effects-interactions (внешний вызов до обновления состояния), зависимости от времени/параметров блока, а также тонких ошибок порядка операций и обновления состояния при внешних вызовах. Такой пласт проблем часто ускользает от классических правил и требует семантического понимания кода и контекста исполнения.

История блокчейн-индустрии изобилует громкими случаями эксплуатации уязвимостей смарт-контрактов. Атака на The DAO в 2016 году привела к потере 50 млн долларов и форку сети Ethereum [3] — разделению блокчейна на две независимые ветки (Ethereum и Ethereum Classic). Инцидент с кошельком Parity в 2017 году заморозил 513,774 ETH на сумму более 280 млн долларов [4]. Более поздние случаи, такие как взлом Poly Network в 2021 году [5] и атака на Ronin Bridge в 2022 году [6], демонстрируют, что проблема безопасности смарт-контрактов остается критически важной.

Традиционные подходы к анализу безопасности смарт-контрактов включают использование статических анализаторов, таких как Slither [5], Mythril [6] и Securify [7], а также методов формальной верификации. Однако эти инструменты имеют существенные ограничения. Статические анализаторы часто генерируют большое количество ложных срабатываний и могут пропускать сложные логические уязвимости, которые проявляются только при определенных условиях выполнения. Формальная верификация, хотя и обеспечивает математические гарантии корректности, требует значительных временных затрат и сильной экспертизы, что делает ее неприменимой для большинства проектов.

Революция в области больших языковых моделей открыла новые возможности для анализа кода и обнаружения уязвимостей. Модели, такие как GPT-4 [8], Claude [9], и специализированные решения для анализа кода, включая CodeT5 [10], GraphCodeBERT [11] и CodeBERT [12], продемонстрировали впечатляющие результаты в понимании семантики программного кода. Эти модели способны выявлять паттерны, которые могут быть неочевидными для традиционных статических анализаторов, и предоставлять объяснения своих решений на естественном языке.

В этой статье представлю гибридную архитектуру, которая интегрирует три ключевых компонента: графовый модуль для структурного анализа потоков управления и данных, семантический модуль на основе адаптированной модели CodeT5 для понимания логики кода и лексический модуль с использованием Pygments для обогащения синтаксической информации. Проанализирую дополнительный RAG-компонент, который обеспечивает доступ к внешним базам знаний об уязвимостях и паттернах атак. Наш подход направлен на решение ключевых проблем современных методов анализа безопасности, а именно на снижение количества ложных срабатываний, повышение точности обнаружения сложных логических уязвимостей и обеспечение объяснимости результатов анализа.

Мультимодальные архитектуры в контексте анализа кода означают использование различных представлений одного и того же кода — текстового представления, графового, синтаксического дерева и метаданных. Каждое из них захватывает определенные аспекты кода, которые могут быть важны для обнаружения различных типов уязвимостей. Например, графовое представление эффективно для обнаружения проблем с потоками данных и контролем доступа, в то время как текстовое представление подходит для анализа бизнес-логики и сложных условий. Синтаксическое дерево дает информацию о структуре кода, которая может быть полезна для обнаружения паттернов, характерных для определенных типов уязвимостей. Особый интерес представляют архитектуры с attention-механизмами между различными модальностями. Такие системы могут динамически фокусироваться на наиболее релевантных аспектах кода в зависимости от типа анализируемой уязвимости. Например, при анализе reentrancy-атак (злоумышленник вызывает функцию смарт-контракта повторно до того, как завершилось ее предыдущее выполнение и обновились внутренние данные контракта) система может уделять больше внимания графу вызовов функций, а при обнаружении проблем с integer overflow — арифметическим операциям в коде. Общие языковые модели, обученные на широком корпусе текстов, не всегда хорошо адаптированы к специфике отдельных языков программирования или узких доменов. Для Solidity это особенно заметно, поскольку язык имеет уникальные особенности, характерные для блокчейн-разработки: необходимость оптимизации расхода газа, строгое управление размещением данных в хранилище (storage layout) и специфические паттерны взаимодействия между контрактами.

Retrieval-augmented generation (RAG) представляет особенно перспективное направление для анализа безопасности. Эта техника позволяет языковым моделям во время генерации ответов обращаться к внешним и внутренним базам знаний, разработанным экспертами. Например, в нашей задаче в контексте анализа безопасности смарт-контрактов RAG может использовать базы данных известных уязвимостей, такие как SWC Registry, документацию по безопасности и примеры атак для более точной классификации потенциальных проблем.

Общая концепция и философия подхода

Наша гибридная архитектура основана на фундаментальном принципе мультимодального представления кода, при котором каждый компонент системы специализируется на извлечении определенного типа информации из исходного кода Solidity. Философия подхода заключается в том, что различные аспекты безопасности кода лучше всего анализируются с использованием соответствующих методов: структурные уязвимости требуют графового анализа, семантические проблемы — понимания естественного языка, а синтаксические паттерны — лексического анализа.

Архитектура состоит из трех основных модулей обработки, каждый из которых генерирует собственное представление входного кода:

1. Графовый модуль извлекает структурную информацию через построение графов потоков управления (сontrol-flow graph, CFG) и потоков данных (data-flow graph, DFG). GraphCodeBERT представляет инновационный подход, объединяющий преимущества трансформерных архитектур со структурной информацией о коде [12]. Модель использует графы потоков данных для обогащения представления кода структурной информацией. Это позволяет модели лучше понимать зависимости между переменными и функциями, что критически важно для анализа безопасности.

2. Семантический модуль использует адаптированную языковую модель CodeT5 для понимания логики и бизнес-правил кода. CodeT5, разработанная Salesforce Research — научно-исследовательским подразделением компании Salesforce, которое создает передовые решения в области машинного обучения и искусственного интеллекта, — представляет собой специализированную модель для задач, связанных с кодом. Основанная на архитектуре T5 (Text-to-Text Transfer Transformer), эта модель была предварительно обучена на большом корпусе кода на различных языках программирования. CodeT5 демонстрирует превосходные результаты в задачах генерации кода, суммаризации (автоматического создания кратких описаний функций и методов на естественном языке), перевода между языками программирования и обнаружения дефектов.

3. Лексический модуль применяет Pygments для обогащения представления синтаксической информацией.

   Дополнительно система включает RAG-компонент, который обеспечивает доступ к внешним базам знаний об уязвимостях и паттернах атак. Ключевым преимуществом такого подхода является комплементарность различных представлений. Например, графовый анализ эффективно обнаруживает проблемы с потоками данных, но может пропустить логические ошибки в бизнес-правилах. Семантический анализ хорошо справляется с пониманием сложной логики, но может не заметить тонкие структурные проблемы. Лексический анализ дает детальную информацию о синтаксических конструкциях, которая может быть особенно важна для обнаружения определенных паттернов уязвимостей.

Графовый модуль. Структурный анализ кода

Графовый модуль — фундамент нашей архитектуры для анализа структурных аспектов безопасности смарт-контрактов. Модуль использует два типа графов для представления различных аспектов структуры кода: CFG для анализа потоков управления и DFG для отслеживания потоков данных.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

/**
 * @title Example
 * @dev Basic deposit/withdrawal contract
 */
contract Example {
    /// @dev Stores ETH balances per address
    mapping(address => uint256) public balances;

    /**
     * @dev Deposit ETH into contract
     * @notice Increases sender's balance by msg.value
     */
    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    /**
     * @dev Withdraw entire balance
     * @notice Transfers ETH balance back to sender
     * @custom:warning Vulnerable to reentrancy attacks
     */
    function withdraw() public {
        uint256 amount = balances[msg.sender];
        require(amount > 0, "Insufficient balance");

        (bool sent, ) = msg.sender.call{value: amount}("");
        require(sent, "Transfer failed");

        balances[msg.sender] = 0;
    }
}

Control-flow graph строится путем анализа всех возможных путей выполнения в функциях смарт-контракта. Каждый узел графа представляет базовый блок кода —последовательность инструкций без ветвлений, а ребра отображают возможные переходы между блоками. Для языка Solidity особое внимание уделяется обработке модификаторов функций, обработчиков исключений и внешних вызовов, которые могут создавать сложные паттерны потоков управления.

[START]
   ↓
[1] amount = balances[msg.sender]
   ↓
[2] require(amount > 0)
   ↓
[3] sent = call{value: amount}()
   ↓
[4] require(sent)
   ↓
[5] balances[msg.sender] = 0
   ↓
[END]

Каждый блок здесь — это базовая единица исполнения. Например, require(...) — отдельный блок, потому что выполнение может завершиться ошибкой.

Data-flow graph фокусируется на отслеживании того, как данные перемещаются через программу. Узлы DFG представляют переменные и операции, а ребра показывают зависимости между ними. Для смарт-контрактов Solidity критически важно отслеживать потоки данных между storage-переменными, memory-операциями и external calls, поскольку многие уязвимости связаны именно с неправильным управлением состоянием.

[msg.sender] ──┐
              ↓
     [balances[msg.sender]] → [amount]
                                     ↓
                               [call{value: amount}()]
                                     ↓
                                [sent] → [require(sent)]

[balances[msg.sender]] ← [0]  ← balances[msg.sender] = 0

Выше видно, что переменная amount зависит от balances[msg.sender], которая потом снова используется при обнулении. DFG помогает понять, где происходит чтение и запись данных, важные для анализа reentrancy и state manipulation.

После извлечения графов они обрабатываются с использованием адаптированной модели GraphCodeBERT. Эта модель была специально разработана для работы с графовыми представлениями кода и использует graph attention networks для обучения эмбеддингов узлов и ребер. Мы дообучаем GraphCodeBERT на корпусе смарт-контрактов Solidity, что позволяет модели лучше понимать специфические паттерны и конструкции этого языка.

Процесс обработки включает несколько этапов:

1. Извлечение графов — использование Slither/Aderyn для построения CFG и DFG.

2. Нормализация — приведение графов к единому формату и удаление избыточной информации.

3. Обогащение — добавление метаданных о типах переменных, модификаторах доступа и gas costs.

4. Эмбеддинг — генерация векторных представлений с использованием GraphCodeBERT (в дальнейшем мы используем выходные результаты данного шага в проверке гипотезы об эффективности использования логистической регрессии для классификации Solidity-контрактов).

5. Агрегация — объединение эмбеддингов CFG и DFG в единое представление.
   
   Особое внимание уделяется обработке сложных конструкций Solidity, таких как наследование контрактов, делегированные вызовы и proxy patterns. Эти конструкции создают дополнительные уровни сложности в графах, которые должны быть правильно представлены для эффективного анализа безопасности.

Семантический модуль T5 для понимания логики кода

Семантический модуль основан на адаптированной версии модели CodeT5 и отвечает за понимание логики и бизнес-правил смарт-контрактов. В отличие от графового модуля, который фокусируется на структурных аспектах, семантический модуль анализирует код как последовательность токенов, способную выражать сложные логические отношения и бизнес-правила.

Для адаптации к специфике анализа безопасности Solidity мы применяем две техники:

• Domain-adaptive pre-training. Здесь модель дообучается на корпусе кода Solidity. Этот этап позволяет модели изучить специфическую лексику и паттерны языка Solidity.

• Vocabulary extension. Стандартный токенизатор CodeT5 расширяется специальными токенами для ключевых конструкций Solidity, таких как modifier, payable, view, pure, а также для распространенных паттернов безопасности. Это достигается с использованием метода tokenizer.add_tokens(), после чего модель дообучается для корректной обработки новых токенов.

Архитектура семантического модуля включает несколько компонентов:

1. Расширенный токенизатор T5 с поддержкой Solidity-специфичных конструкций. Особое внимание уделяется обработке длинных последовательностей, характерных для больших смарт-контрактов. Мы используем технику sliding window с перекрытием для обработки контрактов, превышающих максимальную длину контекста модели.

2. Трансформерный энкодер обрабатывает токенизированный код и генерирует контекстуальные эмбеддинги.

3. Декодер генерирует классификационные метки.

Особое внимание уделяется обработке контекстных зависимостей в коде Solidity. Например, безопасность функции может зависеть от модификаторов, состояния контракта и внешних вызовов. Семантический модуль обучается учитывать эти зависимости при анализе отдельных фрагментов кода.

Рассмотрим пример с кодом ниже.

Несмотря на корректную компиляцию, функция transferOwnership уязвима из-за отсутствия подтверждения от нового владельца и возможности задать критически важную переменную pendingOwner в одностороннем порядке.

Семантический модуль способен выявить такие паттерны, анализируя зависимости между действиями и параметрами и сравнивая их с безопасными шаблонами управления правами. Это позволяет обнаруживать уязвимости, невидимые при поверхностном (лексическом) анализе.

function transferOwnership(address newOwner) public {
    require(msg.sender == owner, "Only owner");
    
    require(newOwner != address(0), "Invalid address");
    if (pendingOwner != address(0)) {
        emit OwnershipRevoked(pendingOwner);
    }
    pendingOwner = newOwner;
    emit OwnershipProposed(owner, newOwner);
}

Дополнительно к основным модулям гибридной архитектуры мы исследовали эффективность базовой модели — логистической регрессии, обученной на эмбеддингах. Несмотря на свою простоту, эта модель продемонстрировала выдающиеся результаты за счет качества входных признаков.

Ранее упоминалось, что для каждого фрагмента Solidity-кода были получены эмбеддинги, построенные на основе графов управления потоком выполнения (CFG). Визуализация показывает проекцию высокоразмерных эмбеддингов кода на двумерное пространство с использованием метода главных компонент (principal component analysis, PCA). Несмотря на редукцию размерности, видно отчетливое разделение между безопасным (LABEL_0) и уязвимым (LABEL_1) кодом, что подтверждает способность модели улавливать значимые семантические различия между типами контрактов.

Этапы построения графового модуля включали:

1. Извлечение CFG-графов с помощью инструмента Slither.

2. Построение графового представления кода с учетом модификаторов, условий и вызовов.

3. Получение эмбеддингов.

4. Агрегация эмбеддингов в единый вектор признаков для классификации.

Почему это сработало?

• Семантическое изобилие: эмбеддинги, извлеченные из CFG, отражают логику исполнения, порядок операций и структурные зависимости внутри кода.

• Линейная разделимость: визуализация распределения признаков (PCA) показала отчетливое разделение между безопасными и уязвимыми функциями.

• Простота модели: логистическая регрессия не требует большого количества параметров или вычислительных ресурсов, но способна эффективно использовать богатые признаки.

Единственное, хочется отметить, что логистической регрессии не стоит доверять на новых типах уязвимостей и новых библиотеках.

Лексический модуль. Синтаксическое обогащение с Pygments

Лексический модуль представляет третий уровень анализа в нашей гибридной архитектуре и отвечает за извлечение и обогащение синтаксической информации о коде. Этот модуль основан на библиотеке Pygments — инструменте для лексического анализа и подсветки синтаксиса, который поддерживает более 500 языков программирования, включая Solidity.

Основная идея лексического модуля заключается в том, что различные типы токенов в коде несут разную семантическую нагрузку с точки зрения безопасности. Например, ключевые слова, связанные с внешними вызовами (call, delegatecall, send), имеют более высокий риск безопасности по сравнению с обычными арифметическими операторами. Аналогично литералы адресов и числовые константы могут указывать на hardcoded-значения, которые часто являются источником уязвимостей.

Pygments классифицирует токены кода по следующим основным категориям:

• keywords — ключевые слова языка (function, modifier, require, assert);

• names — идентификаторы переменных, функций и контрактов;

• literals — строковые, числовые и булевы литералы;

• operators — арифметические операторы, логические и операторы сравнения;

• punctuation — cкобки, точки с запятой и другие разделители;

• comments — комментарии и документация.

Для каждой категории токенов мы определяем весовые коэффициенты, отражающие их потенциальную важность для анализа безопасности. Эти веса были определены на основе анализа корпуса известных уязвимостей.

Лексический анализ исходного кода включает последовательное выполнение следующих нескольких этапов.

На рисунке видно, что уязвимые фрагменты кода (LABEL_1) чаще содержат операторы и литералы, тогда как безопасный код (LABEL_0) характеризуется большим количеством ключевых слов и идентификаторов. Эти паттерны подчеркивают различия в структуре между уязвимыми и безопасными контрактами и позволяют лексическому модулю эффективно извлекать сигналы для классификации.

Диаграмма ниже демонстрирует высокую устойчивость лексического модуля: почти 98% контрактов проходят через стадии risk_score_valid и tokens_found. Однако около 25% не содержат явно опасных конструкций (security_construct_found), что связано либо с их отсутствием, либо с особенностями реализации. Итоговая успешность (passed) достигает 98%, что подтверждает надежность пайплайна.

Эта уточненная визуализация показывает долю прохождения каждой стадии внутренней проверки модуля, включая определение risk score (0,98), оценки риска, которая отражает вероятность того, что данный фрагмент кода уязвим или связан с высоким риском, и определение наличия security construct (0,78), то есть наличия специальных конструкций безопасности в коде.

Особое внимание уделяется ряду конструкций, напрямую влияющих на безопасность смарт-контрактов:

1. External calls. Токены, связанные с внешними вызовами (call, delegatecall, staticcall), получают повышенные веса или специальные метки, поскольку такие вызовы часто становятся источником reentrancy-уязвимостей и других атак.

2. State variables. Обращения к переменным состояния (state variables) анализируются отдельно, выявляются паттерны чтения-записи, способные указывать на data races или другие проблемы.

3. Modifiers and access control. Модификаторы доступа и логика управления разрешениями выделяются для дополнительного анализа: ошибки здесь приводят к уязвимостям контроля доступа.

4. Gas-related operations. Операции, влияющие на расход газа, анализируются для поиска DoS-уязвимостей, связанных с чрезмерным потреблением газа.

Интеграция лексического модуля с остальной архитектурой осуществляется через механизм attention, который позволяет системе динамически фокусироваться на наиболее релевантных лексических особенностях в зависимости от типа анализируемой уязвимости.

RAG-компонент и интеграция внешних знаний

Основная идея RAG заключается в том, что языковая модель может обращаться к релевантной информации из внешних баз данных во время генерации ответов, что значительно расширяет ее возможности по сравнению с использованием только параметрических знаний. В контексте анализа безопасности смарт-контрактов RAG-компонент обеспечивает доступ к нескольким типам внешних знаний:

1. База данных уязвимостей: структурированная коллекция известных уязвимостей Solidity, включающая описания, примеры кода, методы эксплуатации и способы исправления. Основой служит SWC Registry (Smart Contract Weakness Classification), дополненная данными из базы CVE, отчетов аудиторских компаний и академических исследований.

2. Паттерны атак: коллекция известных паттернов атак на смарт-контракты (reentrancy, flash loan attacks и другие). Каждый паттерн содержит детальное описание механизма атаки, примеры реального кода и индикаторы, по которым можно обнаружить уязвимость.

3. Best practices: база знаний о лучших практиках безопасной разработки смарт-контрактов, включающая рекомендации ведущих аудиторских компаний, стандарты OpenZeppelin и руководства Ethereum Foundation.

4. Исторические инциденты: детальные описания реальных атак на смарт-контракты с анализом причин, последствий и уроков, которые можно извлечь для предотвращения подобных инцидентов в будущем.

В модуле анализа кода RAG используется для обогащения понимания модели извлеченными знаниями из внешней базы (например, по CVE, SWC, audit-паттернам). Если модель видит подозрительную конструкцию, она запрашивает пояснение — и, если найдено, использует его для объяснения или классификации. В примере с функцией withdraw (см. ниже) модель фиксирует потенциально опасную последовательность — внешний вызов до обновления состояния.

contract Fund {
    mapping(address => uint256) public balances;
    function withdraw() public {
        uint256 amount = balances[msg.sender];
        require(amount > 0, "Zero balance");

        (bool sent, ) = msg.sender.call{value: amount}("");
        require(sent, "Transfer failed");

        balances[msg.sender] = 0;
    }
    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }
}

RAG-компонент возвращает описание паттерна SWC-107 — Reentrancy, что усиливает уверенность модели в метке LABEL_1 и позволяет не только классифицировать, но и объяснить источник риска. Такой подход объединяет обучение и поиск, повышая точность и интерпретируемость.

[SWC-107 - Reentrancy]
Reentrancy allows an external contract to call back into the calling contract before the first invocation is complete.
Fix: Use checks-effects-interactions pattern. Avoid external calls before updating state.

Коротко про датасет

Для обучения и тестирования используются 27 073 смарт-контракта Solidity (21 658 в обучающей выборке, 5415 в тестовой), собранные с Ethereum, GitHub и от аудиторов. Дубликаты, прокси и некорректные контракты удаляются, а аннотации уязвимостей проходят автоматическую и экспертную проверку с категоризацией по SWC. Классовый дисбаланс: 79% — уязвимые, 21% — безопасные. Подробно останавливаться на борьбе с дисбалансом и обработкой данных мы не будем, но если вдруг интересно, пишите в комментариях — расскажу ;)

Обучение гибридной архитектуры проводится поэтапно, что позволяет оптимизировать отдельные модули и затем интегрировать их в единую систему. Каждый модуль отдельно дообучается на аннотированном датасете для классификации уязвимостей, применяется curriculum learning — сначала простые, затем сложные примеры.

Выводы

Мы провели комплексную оценку архитектуры модульной системы анализа уязвимостей в Solidity-контрактах. Система включает лексический, семантический и RAG-модули. Каждый модуль продемонстрировал вклад в общее качество выявления уязвимостей. Ниже представлены ключевые результаты по каждому компоненту.

Лексический модуль использует токенизированное представление кода для классификации уязвимостей на основе поверхностных признаков. Были получены следующие результаты:

• Выявлены характерные токен-паттерны, такие как call{value:} и delegatecall, коррелирующие с метками SWC-107, SWC-112.

• С помощью визуализации распределений токенов в различных классах было установлено, что определенные лексемы (например, msg.sender, tx.origin) чаще встречаются в уязвимых функциях.

• Однако лексический анализ оказался недостаточным в случаях, когда уязвимость зависит от порядка операций, отсутствия модификаторов или логики доступа — таких как withdraw() с reentrancy.

Семантический модуль на основе предобученной модели (в нашем случае CodeT5) способен учитывать структурные и контекстуальные зависимости между элементами кода:

• Были выявлены типовые семантические паттерны, например использование msg.sender без проверки, изменение критически значимых переменных без модификаторов, нарушение шаблона Checks-Effects-Interactions.

• Модель успешно отличала корректные реализации от уязвимых при наличии одинаковых токенов — благодаря учету порядка вызовов и логических блоков.

• Проведенный анализ показал, что семантическая компонента является критически важной для обнаружения скрытых зависимостей в коде, невидимых на уровне лексем.

Для оценки качества эмбеддингов, сформированных семантической моделью, была выполнена проекция в пространство меньшей размерности с помощью PCA:

• Разделение по меткам (LABEL) в пространстве 2D подтверждает, что модель кодирует семантически осмысленную информацию.

• Группировка эмбеддингов в зависимости от типа уязвимости указывает на наличие скрытой структуры в представлении кода.

• Это может быть использовано как для диагностики, так и для интерпретации моделей на этапе аудита.

RAG-компонент играет роль внешнего усилителя, извлекая релевантные фрагменты знаний (например, SWC-описания) и передавая их в семантическую модель:

• Более чем в 20% случаев RAG-компонент находил релевантную информацию для выявленных паттернов (например, SWC-107 — Reentrancy).

• Интеграция retrieved-данных повышала точность и интерпретируемость модели, особенно в граничных случаях.

• RAG-компонент оказался полезным не только при обогащении данных, но и как механизм обеспечения объяснимости выводов модели.

Модульная архитектура, сочетающая лексический анализ, семантическое кодирование и внешнее обогащение (RAG), демонстрирует высокую эффективность в задаче классификации уязвимостей в смарт-контрактах. Особенно важным оказался вклад семантического уровня и перспективы retrieval-компоненты, что подчеркивает необходимость учитывать контекст, структуру и внешние знания при анализе безопасности исходного кода.