ваше сообщение коммита
This commit is contained in:
693
docs/DLE_MANAGEMENT_TASKS.md
Normal file
693
docs/DLE_MANAGEMENT_TASKS.md
Normal file
@@ -0,0 +1,693 @@
|
||||
# Детальный план задач: Управление Digital Legal Entity (DLE)
|
||||
|
||||
## Общие принципы разработки
|
||||
|
||||
### Архитектурные требования
|
||||
- **Single-Chain Governance**: Голосование происходит только в одной выбранной сети
|
||||
- **Мультиподпись токен-холдеров**: Все операции требуют кворума подписей
|
||||
- **Настраиваемые таймлоки**: Инициатор устанавливает задержку для каждого предложения
|
||||
- **Cross-chain исполнение**: Решения выполняются во всех целевых сетях
|
||||
- **Без админских ролей**: Только коллективное управление через токен-холдеров
|
||||
|
||||
### Технический стек
|
||||
- **Frontend**: Vue.js 3 + Composition API
|
||||
- **Web3**: ethers.js или web3.js
|
||||
- **Контракты**: Solidity + OpenZeppelin + ERC-4337
|
||||
- **Стили**: Scoped CSS с переменными
|
||||
|
||||
---
|
||||
|
||||
## 1. БЛОК "ПРЕДЛОЖЕНИЯ" (`/management/proposals`)
|
||||
|
||||
### Задача 1.1: Создание предложений
|
||||
**Описание**: Пользователь создает предложение для выполнения операции в DLE
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Добавить форму создания предложения с полями:
|
||||
- Тип операции (управление токенами, казна, модули, настройки)
|
||||
- Описание операции (текстовое поле)
|
||||
- Выбор governance-сети (выпадающий список)
|
||||
- Выбор целевых сетей для исполнения (мультиселект)
|
||||
- Таймлок задержка в часах (числовое поле)
|
||||
- [ ] Подключить к контракту метод `createProposal(operation, targetChains, timelockDelay)`
|
||||
- [ ] Добавить валидацию: только токен-холдеры могут создавать предложения
|
||||
- [ ] Показывать предварительный расчет газа для создания предложения
|
||||
|
||||
**Время**: 8-12 часов
|
||||
|
||||
### Задача 1.2: Подписание предложений
|
||||
**Описание**: Токен-холдеры подписывают предложения для достижения кворума
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Отображать список активных предложений с прогрессом подписей
|
||||
- [ ] Показывать для каждого предложения:
|
||||
- Текущее количество подписей / требуемый кворум
|
||||
- Список подписавших с их балансами токенов
|
||||
- Время до истечения таймлока
|
||||
- [ ] Добавить кнопку "Подписать" для токен-холдеров
|
||||
- [ ] Подключить к контракту метод `signProposal(proposalId)`
|
||||
- [ ] Проверять баланс токенов при подписании
|
||||
- [ ] Обновлять UI в реальном времени при новых подписях
|
||||
|
||||
**Время**: 10-14 часов
|
||||
|
||||
### Задача 1.3: Исполнение предложений
|
||||
**Описание**: Выполнение предложений после достижения кворума и истечения таймлока
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Отображать статус предложений: "Ожидание", "Кворум достигнут", "Готово к исполнению", "Исполнено"
|
||||
- [ ] Добавить кнопку "Исполнить" для предложений готовых к исполнению
|
||||
- [ ] Подключить к контракту метод `executeProposal(proposalId)`
|
||||
- [ ] Показывать прогресс исполнения в целевых сетях
|
||||
- [ ] Обрабатывать ошибки исполнения и показывать fallback статусы
|
||||
- [ ] Добавить возможность отмены предложений до истечения таймлока
|
||||
|
||||
**Время**: 8-12 часов
|
||||
|
||||
### Задача 1.4: История и фильтрация
|
||||
**Описание**: Просмотр истории предложений с возможностью фильтрации
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Добавить фильтры по:
|
||||
- Статусу предложения
|
||||
- Типу операции
|
||||
- Governance-сети
|
||||
- Периоду времени
|
||||
- [ ] Реализовать поиск по описанию предложения
|
||||
- [ ] Добавить пагинацию для больших списков
|
||||
- [ ] Показывать детали каждого предложения в модальном окне
|
||||
- [ ] Добавить ссылки на блокчейн-эксплореры для транзакций
|
||||
|
||||
**Время**: 6-8 часов
|
||||
|
||||
---
|
||||
|
||||
## 2. БЛОК "ТОКЕНЫ DLE" (`/management/tokens`)
|
||||
|
||||
### Задача 2.1: Информация о токенах
|
||||
**Описание**: Отображение основной информации о токенах DLE
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Показывать общий supply токенов
|
||||
- [ ] Отображать баланс текущего пользователя
|
||||
- [ ] Показывать процент кворума для голосования
|
||||
- [ ] Отображать текущую рыночную стоимость токена (если доступна)
|
||||
- [ ] Подключить к контракту методы `totalSupply()`, `balanceOf(address)`
|
||||
- [ ] Обновлять данные в реальном времени при изменениях
|
||||
|
||||
**Время**: 4-6 часов
|
||||
|
||||
### Задача 2.2: Передача токенов
|
||||
**Описание**: Перевод токенов между участниками через кворум
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать форму перевода с полями:
|
||||
- Адрес получателя
|
||||
- Количество токенов
|
||||
- Описание перевода
|
||||
- [ ] Создавать предложение для перевода токенов
|
||||
- [ ] Показывать статус предложения перевода
|
||||
- [ ] Валидировать баланс отправителя
|
||||
- [ ] Подключать к контракту через систему предложений
|
||||
|
||||
**Время**: 6-8 часов
|
||||
|
||||
### Задача 2.3: Распределение токенов
|
||||
**Описание**: Массовое распределение токенов новым участникам
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать форму распределения с возможностью добавления множественных получателей
|
||||
- [ ] Поля для каждого получателя: адрес, количество токенов
|
||||
- [ ] Кнопки "Добавить получателя" и "Удалить получателя"
|
||||
- [ ] Создавать предложение для распределения
|
||||
- [ ] Показывать общую сумму распределения
|
||||
- [ ] Валидировать общий supply и права на минтинг
|
||||
|
||||
**Время**: 8-10 часов
|
||||
|
||||
### Задача 2.4: Список держателей токенов
|
||||
**Описание**: Отображение всех держателей токенов с их балансами
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Получать список всех держателей токенов
|
||||
- [ ] Отображать для каждого держателя:
|
||||
- Адрес кошелька
|
||||
- Количество токенов
|
||||
- Процент от общего supply
|
||||
- Дата последней активности
|
||||
- [ ] Добавить сортировку по балансу, активности, адресу
|
||||
- [ ] Реализовать поиск по адресу
|
||||
- [ ] Показывать топ-10 держателей отдельно
|
||||
|
||||
**Время**: 6-8 часов
|
||||
|
||||
---
|
||||
|
||||
## 3. БЛОК "КВОРУМ" (`/management/quorum`)
|
||||
|
||||
### Задача 3.1: Текущие настройки кворума
|
||||
**Описание**: Отображение текущих параметров кворума
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Показывать текущий процент кворума для голосования
|
||||
- [ ] Отображать минимальную задержку голосования
|
||||
- [ ] Показывать период голосования
|
||||
- [ ] Отображать порог для создания предложений
|
||||
- [ ] Подключать к контракту для получения актуальных значений
|
||||
- [ ] Показывать когда были изменены последние настройки
|
||||
|
||||
**Время**: 4-6 часов
|
||||
|
||||
### Задача 3.2: Изменение настроек кворума
|
||||
**Описание**: Создание предложения для изменения параметров кворума
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать форму изменения настроек с полями:
|
||||
- Новый процент кворума (1-100%)
|
||||
- Новая задержка голосования (в часах)
|
||||
- Новый период голосования (в днях)
|
||||
- Новый порог для предложений (в токенах)
|
||||
- Причина изменения
|
||||
- [ ] Валидировать значения (кворум не менее 51%, разумные периоды)
|
||||
- [ ] Создавать предложение для изменения настроек
|
||||
- [ ] Показывать предварительный расчет влияния изменений
|
||||
- [ ] Добавить подтверждение критических изменений
|
||||
|
||||
**Время**: 8-10 часов
|
||||
|
||||
### Задача 3.3: История изменений кворума
|
||||
**Описание**: Просмотр истории изменений параметров кворума
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Отображать список всех изменений кворума
|
||||
- [ ] Показывать для каждого изменения:
|
||||
- Старые и новые значения
|
||||
- Кто инициировал изменение
|
||||
- Когда было предложено и когда принято
|
||||
- Причину изменения
|
||||
- [ ] Добавить фильтрацию по периоду и типу изменений
|
||||
- [ ] Показывать статистику изменений (частота, тренды)
|
||||
|
||||
**Время**: 6-8 часов
|
||||
|
||||
---
|
||||
|
||||
## 4. БЛОК "МОДУЛИ DLE" (`/management/modules`)
|
||||
|
||||
### Задача 4.1: Список установленных модулей
|
||||
**Описание**: Отображение всех установленных модулей DLE
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Получать список всех модулей из контракта
|
||||
- [ ] Отображать для каждого модуля:
|
||||
- Название и описание
|
||||
- Адрес контракта модуля
|
||||
- Версию модуля
|
||||
- Статус (активен/неактивен)
|
||||
- Дата установки
|
||||
- [ ] Показывать общую статистику модулей
|
||||
- [ ] Добавить поиск и фильтрацию по модулям
|
||||
|
||||
**Время**: 6-8 часов
|
||||
|
||||
### Задача 4.2: Установка новых модулей
|
||||
**Описание**: Добавление новых модулей через голосование
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать форму установки модуля с полями:
|
||||
- Название модуля
|
||||
- Адрес контракта модуля
|
||||
- Описание функциональности
|
||||
- Параметры инициализации
|
||||
- Причина установки
|
||||
- [ ] Валидировать адрес контракта и совместимость
|
||||
- [ ] Создавать предложение для установки модуля
|
||||
- [ ] Показывать предварительную проверку модуля
|
||||
- [ ] Добавить возможность тестирования модуля перед установкой
|
||||
|
||||
**Время**: 10-12 часов
|
||||
|
||||
### Задача 4.3: Управление модулями
|
||||
**Описание**: Активация, деактивация и удаление модулей
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Добавить кнопки управления для каждого модуля:
|
||||
- Активировать/деактивировать
|
||||
- Обновить версию
|
||||
- Удалить модуль
|
||||
- [ ] Создавать предложения для каждого действия
|
||||
- [ ] Показывать зависимости между модулями
|
||||
- [ ] Предупреждать о критических операциях
|
||||
- [ ] Добавить возможность отката изменений
|
||||
|
||||
**Время**: 8-10 часов
|
||||
|
||||
### Задача 4.4: Интерфейсы модулей
|
||||
**Описание**: Встраивание интерфейсов управления модулями
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать систему встраивания интерфейсов модулей
|
||||
- [ ] Каждый модуль может предоставлять свой UI
|
||||
- [ ] Безопасное взаимодействие между основным приложением и модулями
|
||||
- [ ] Единообразный стиль для всех модулей
|
||||
- [ ] Добавить документацию для разработчиков модулей
|
||||
|
||||
**Время**: 12-16 часов
|
||||
|
||||
---
|
||||
|
||||
## 5. БЛОК "DLE" (Интеграция с другими DLE) (`/management/dle`)
|
||||
|
||||
### Задача 5.1: Список подключенных DLE
|
||||
**Описание**: Отображение DLE, с которыми установлена интеграция
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Показывать карточки всех подключенных DLE
|
||||
- [ ] Для каждого DLE отображать:
|
||||
- Название и описание
|
||||
- Адрес контракта
|
||||
- Количество токенов этого DLE в нашем балансе
|
||||
- Процент голосов, который мы можем использовать
|
||||
- Статус подключения
|
||||
- [ ] Добавить возможность удаления DLE из списка
|
||||
- [ ] Показывать общую статистику интеграций
|
||||
|
||||
**Время**: 6-8 часов
|
||||
|
||||
### Задача 5.2: Добавление новых DLE
|
||||
**Описание**: Подключение новых DLE для участия в их голосованиях
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать форму добавления DLE с полями:
|
||||
- Название DLE
|
||||
- Адрес контракта DLE
|
||||
- Описание и назначение
|
||||
- Причина подключения
|
||||
- [ ] Валидировать адрес и проверять существование контракта
|
||||
- [ ] Проверять баланс токенов этого DLE
|
||||
- [ ] Создавать предложение для добавления DLE
|
||||
- [ ] Показывать предварительную информацию о DLE
|
||||
|
||||
**Время**: 8-10 часов
|
||||
|
||||
### Задача 5.3: Участие в голосованиях других DLE
|
||||
**Описание**: Голосование в предложениях других DLE через наш кворум
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Отображать активные предложения других DLE
|
||||
- [ ] Показывать для каждого предложения:
|
||||
- Описание и тип операции
|
||||
- Наш возможный вес голоса
|
||||
- Текущий статус голосования
|
||||
- Время до истечения
|
||||
- [ ] Создавать внутренние предложения для голосования в других DLE
|
||||
- [ ] Собирать кворум подписей для внешнего голосования
|
||||
- [ ] Отправлять голос в целевое DLE после достижения кворума
|
||||
|
||||
**Время**: 12-16 часов
|
||||
|
||||
### Задача 5.4: Встраивание интерфейсов управления
|
||||
**Описание**: Управление другими DLE через встроенные интерфейсы
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать систему встраивания интерфейсов других DLE
|
||||
- [ ] Безопасное отображение внешних интерфейсов в iframe
|
||||
- [ ] Передача контекста аутентификации
|
||||
- [ ] Обработка событий и обновлений
|
||||
- [ ] Единообразный стиль и навигация
|
||||
- [ ] Добавить возможность открытия в новой вкладке
|
||||
|
||||
**Время**: 16-20 часов
|
||||
|
||||
---
|
||||
|
||||
## 6. БЛОК "КАЗНА" (`/management/treasury`)
|
||||
|
||||
### Задача 6.1: Баланс казны
|
||||
**Описание**: Отображение всех активов казны DLE
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Показывать балансы всех токенов в казне:
|
||||
- Нативные токены (ETH, MATIC, BNB и т.д.)
|
||||
- ERC-20 токены
|
||||
- NFT и другие активы
|
||||
- [ ] Отображать общую стоимость в USD
|
||||
- [ ] Показывать историю изменений баланса
|
||||
- [ ] Добавить графики движения средств
|
||||
- [ ] Подключать к контракту для получения актуальных данных
|
||||
|
||||
**Время**: 8-10 часов
|
||||
|
||||
### Задача 6.2: Операции с казной
|
||||
**Описание**: Выполнение финансовых операций через кворум
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать формы для различных операций:
|
||||
- Отправка средств (нативные токены, ERC-20)
|
||||
- Получение средств
|
||||
- Обмен токенов
|
||||
- Инвестиции в DeFi протоколы
|
||||
- [ ] Создавать предложения для каждой операции
|
||||
- [ ] Валидировать балансы и права доступа
|
||||
- [ ] Показывать предварительный расчет газа и комиссий
|
||||
- [ ] Добавить подтверждение критических операций
|
||||
|
||||
**Время**: 12-16 часов
|
||||
|
||||
### Задача 6.3: Распределение дивидендов
|
||||
**Описание**: Выплата дивидендов токен-холдерам
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать форму распределения дивидендов:
|
||||
- Выбор токена для выплаты
|
||||
- Общая сумма дивидендов
|
||||
- Пропорциональное распределение по балансам
|
||||
- [ ] Показывать предварительный расчет выплат каждому держателю
|
||||
- [ ] Создавать предложение для выплаты дивидендов
|
||||
- [ ] Отслеживать статус выплат
|
||||
- [ ] Показывать историю дивидендных выплат
|
||||
|
||||
**Время**: 10-12 часов
|
||||
|
||||
### Задача 6.4: Бюджетирование и отчеты
|
||||
**Описание**: Планирование и контроль расходов казны
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать систему бюджетирования:
|
||||
- Установка лимитов расходов
|
||||
- Категоризация операций
|
||||
- Планирование расходов
|
||||
- [ ] Генерировать отчеты:
|
||||
- Месячные/квартальные отчеты
|
||||
- Анализ доходов и расходов
|
||||
- Прогнозы движения средств
|
||||
- [ ] Добавить уведомления о превышении лимитов
|
||||
- [ ] Экспорт отчетов в PDF/CSV
|
||||
|
||||
**Время**: 12-16 часов
|
||||
|
||||
---
|
||||
|
||||
## 7. БЛОК "АНАЛИТИКА" (`/management/analytics`)
|
||||
|
||||
### Задача 7.1: Ключевые метрики
|
||||
**Описание**: Отображение основных показателей DLE
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Показывать ключевые метрики:
|
||||
- Общая стоимость активов (TVL)
|
||||
- Количество активных участников
|
||||
- Количество предложений за период
|
||||
- Средняя доходность
|
||||
- [ ] Добавить сравнение с предыдущими периодами
|
||||
- [ ] Показывать тренды и изменения
|
||||
- [ ] Подключать реальные данные из контрактов
|
||||
|
||||
**Время**: 8-10 часов
|
||||
|
||||
### Задача 7.2: Графики и визуализация
|
||||
**Описание**: Создание интерактивных графиков и диаграмм
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Интегрировать библиотеку для графиков (Chart.js, D3.js)
|
||||
- [ ] Создать графики:
|
||||
- Стоимость токенов во времени
|
||||
- Активность участников по дням/неделям
|
||||
- Распределение токенов между держателями
|
||||
- Движение средств в казне
|
||||
- [ ] Добавить интерактивность (зум, фильтры, детализация)
|
||||
- [ ] Реализовать экспорт графиков
|
||||
|
||||
**Время**: 12-16 часов
|
||||
|
||||
### Задача 7.3: Статистика и отчеты
|
||||
**Описание**: Детальная аналитика и отчетность
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать разделы статистики:
|
||||
- Топ держателей токенов
|
||||
- Самые активные участники
|
||||
- История предложений и голосований
|
||||
- Финансовая статистика
|
||||
- [ ] Добавить фильтры по периодам
|
||||
- [ ] Создать настраиваемые дашборды
|
||||
- [ ] Реализовать автоматическую генерацию отчетов
|
||||
|
||||
**Время**: 10-14 часов
|
||||
|
||||
### Задача 7.4: Прогнозирование и тренды
|
||||
**Описание**: Анализ трендов и прогнозирование
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Анализировать исторические данные для выявления трендов
|
||||
- [ ] Создавать прогнозы:
|
||||
- Движение стоимости токенов
|
||||
- Активность участников
|
||||
- Финансовые показатели
|
||||
- [ ] Показывать аномалии и важные события
|
||||
- [ ] Добавить уведомления о значимых изменениях
|
||||
|
||||
**Время**: 14-18 часов
|
||||
|
||||
---
|
||||
|
||||
## 8. БЛОК "ИСТОРИЯ" (`/management/history`)
|
||||
|
||||
### Задача 8.1: Лог всех операций
|
||||
**Описание**: Отображение полной истории операций DLE
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Собирать и отображать все типы операций:
|
||||
- Создание и исполнение предложений
|
||||
- Операции с токенами
|
||||
- Казначейские операции
|
||||
- Изменения настроек
|
||||
- Модульные операции
|
||||
- [ ] Для каждой операции показывать:
|
||||
- Тип и описание
|
||||
- Время выполнения
|
||||
- Участники
|
||||
- Статус выполнения
|
||||
- Ссылки на транзакции
|
||||
|
||||
**Время**: 10-12 часов
|
||||
|
||||
### Задача 8.2: Фильтрация и поиск
|
||||
**Описание**: Удобный поиск и фильтрация истории
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Добавить фильтры по:
|
||||
- Типу операции
|
||||
- Периоду времени
|
||||
- Участникам
|
||||
- Статусу
|
||||
- Сетям
|
||||
- [ ] Реализовать полнотекстовый поиск
|
||||
- [ ] Добавить сохранение фильтров
|
||||
- [ ] Создать быстрые фильтры (сегодня, неделя, месяц)
|
||||
|
||||
**Время**: 8-10 часов
|
||||
|
||||
### Задача 8.3: Детали операций
|
||||
**Описание**: Подробная информация о каждой операции
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать модальные окна с деталями операций
|
||||
- [ ] Показывать полную информацию:
|
||||
- Параметры операции
|
||||
- Участники и их роли
|
||||
- Результат выполнения
|
||||
- Ошибки и предупреждения
|
||||
- [ ] Добавить ссылки на блокчейн-эксплореры
|
||||
- [ ] Показывать связанные операции
|
||||
|
||||
**Время**: 8-10 часов
|
||||
|
||||
### Задача 8.4: Экспорт и отчеты
|
||||
**Описание**: Экспорт истории в различные форматы
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Реализовать экспорт в форматы:
|
||||
- CSV для анализа в Excel
|
||||
- PDF для отчетов
|
||||
- JSON для интеграции
|
||||
- [ ] Добавить настройки экспорта (период, типы операций)
|
||||
- [ ] Создать шаблоны отчетов
|
||||
- [ ] Добавить автоматическую отправку отчетов
|
||||
|
||||
**Время**: 6-8 часов
|
||||
|
||||
---
|
||||
|
||||
## 9. БЛОК "НАСТРОЙКИ" (`/management/settings`)
|
||||
|
||||
### Задача 9.1: Основные настройки DLE
|
||||
**Описание**: Управление основной информацией о DLE
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать форму основных настроек:
|
||||
- Название DLE
|
||||
- Символ токена
|
||||
- Описание и назначение
|
||||
- Местонахождение
|
||||
- Веб-сайт
|
||||
- [ ] Подключать к контракту для сохранения изменений
|
||||
- [ ] Валидировать данные перед сохранением
|
||||
- [ ] Показывать историю изменений
|
||||
|
||||
**Время**: 6-8 часов
|
||||
|
||||
### Задача 9.2: Настройки безопасности
|
||||
**Описание**: Управление параметрами безопасности
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать форму настроек безопасности:
|
||||
- Минимальный кворум для голосования
|
||||
- Максимальная длительность предложений
|
||||
- Порог для экстренных действий
|
||||
- Задержка таймлока по умолчанию
|
||||
- Дополнительные настройки (делегирование, KYC)
|
||||
- [ ] Добавить предупреждения о критических изменениях
|
||||
- [ ] Создавать предложения для изменения настроек
|
||||
- [ ] Показывать влияние изменений на безопасность
|
||||
|
||||
**Время**: 10-12 часов
|
||||
|
||||
### Задача 9.3: Настройки сети
|
||||
**Описание**: Управление сетевыми параметрами
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать форму настроек сети:
|
||||
- Выбор поддерживаемых сетей
|
||||
- Сеть по умолчанию для governance
|
||||
- RPC endpoints для каждой сети
|
||||
- Настройки синхронизации
|
||||
- [ ] Тестировать подключение к сетям
|
||||
- [ ] Показывать статус каждой сети
|
||||
- [ ] Добавить возможность добавления новых сетей
|
||||
|
||||
**Время**: 8-10 часов
|
||||
|
||||
### Задача 9.4: Резервное копирование
|
||||
**Описание**: Экспорт и импорт настроек
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Реализовать экспорт всех настроек в JSON
|
||||
- [ ] Создать импорт настроек из файла
|
||||
- [ ] Валидировать импортируемые данные
|
||||
- [ ] Добавить предварительный просмотр изменений
|
||||
- [ ] Создать автоматическое резервное копирование
|
||||
|
||||
**Время**: 6-8 часов
|
||||
|
||||
### Задача 9.5: Опасная зона
|
||||
**Описание**: Критические операции с DLE
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать раздел опасных операций:
|
||||
- Сброс настроек к значениям по умолчанию
|
||||
- Полное удаление DLE
|
||||
- Экстренная остановка операций
|
||||
- [ ] Добавить множественные подтверждения
|
||||
- [ ] Показывать последствия каждой операции
|
||||
- [ ] Создать логирование критических действий
|
||||
|
||||
**Время**: 8-10 часов
|
||||
|
||||
---
|
||||
|
||||
## ОБЩИЕ ЗАДАЧИ ДЛЯ ВСЕХ БЛОКОВ
|
||||
|
||||
### Задача 0.1: Подготовка инфраструктуры
|
||||
**Описание**: Настройка базовой инфраструктуры для всех блоков
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Настроить web3-провайдеры для всех поддерживаемых сетей
|
||||
- [ ] Создать абстракции для работы с контрактами
|
||||
- [ ] Настроить обработку ошибок и уведомления
|
||||
- [ ] Создать систему кэширования данных
|
||||
- [ ] Настроить мониторинг состояния сетей
|
||||
|
||||
**Время**: 16-20 часов
|
||||
|
||||
### Задача 0.2: Интеграция с контрактами
|
||||
**Описание**: Подключение всех блоков к смарт-контрактам
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать интерфейсы для всех методов контрактов
|
||||
- [ ] Реализовать обработку событий контрактов
|
||||
- [ ] Настроить подписки на изменения состояния
|
||||
- [ ] Добавить обработку ошибок транзакций
|
||||
- [ ] Реализовать retry механизмы для неудачных транзакций
|
||||
|
||||
**Время**: 20-24 часа
|
||||
|
||||
### Задача 0.3: Тестирование и отладка
|
||||
**Описание**: Комплексное тестирование всех функций
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Создать unit-тесты для всех компонентов
|
||||
- [ ] Написать e2e тесты для основных сценариев
|
||||
- [ ] Протестировать работу в разных сетях
|
||||
- [ ] Провести нагрузочное тестирование
|
||||
- [ ] Исправить найденные ошибки
|
||||
|
||||
**Время**: 24-32 часа
|
||||
|
||||
### Задача 0.4: Оптимизация и производительность
|
||||
**Описание**: Улучшение производительности и пользовательского опыта
|
||||
|
||||
**Что нужно сделать**:
|
||||
- [ ] Оптимизировать загрузку данных
|
||||
- [ ] Добавить lazy loading для больших списков
|
||||
- [ ] Реализовать кэширование на клиенте
|
||||
- [ ] Оптимизировать размер бандла
|
||||
- [ ] Добавить прогресс-индикаторы для длительных операций
|
||||
|
||||
**Время**: 16-20 часов
|
||||
|
||||
---
|
||||
|
||||
## ПРИОРИТЕТЫ РАЗРАБОТКИ
|
||||
|
||||
### Высокий приоритет (MVP)
|
||||
1. Предложения - базовая функциональность
|
||||
2. Токены DLE - основные операции
|
||||
3. Кворум - текущие настройки
|
||||
4. Настройки - основные параметры
|
||||
|
||||
### Средний приоритет
|
||||
1. Казна - базовые операции
|
||||
2. История - лог операций
|
||||
3. Аналитика - ключевые метрики
|
||||
4. Модули - список и управление
|
||||
|
||||
### Низкий приоритет
|
||||
1. DLE - интеграция с другими DLE
|
||||
2. Расширенная аналитика
|
||||
3. Сложные отчеты
|
||||
4. Встраивание интерфейсов
|
||||
|
||||
---
|
||||
|
||||
## ОЦЕНКА ВРЕМЕНИ
|
||||
|
||||
### Общее время разработки: 280-380 часов
|
||||
|
||||
**Разбивка по блокам:**
|
||||
- Предложения: 32-46 часов
|
||||
- Токены DLE: 24-32 часа
|
||||
- Кворум: 18-24 часа
|
||||
- Модули DLE: 36-46 часов
|
||||
- DLE (интеграция): 42-54 часа
|
||||
- Казна: 42-54 часа
|
||||
- Аналитика: 44-58 часа
|
||||
- История: 32-40 часов
|
||||
- Настройки: 38-48 часов
|
||||
- Общие задачи: 76-96 часов
|
||||
|
||||
**Рекомендации:**
|
||||
- Начать с MVP (высокий приоритет)
|
||||
- Разрабатывать параллельно несколько блоков
|
||||
- Использовать готовые компоненты где возможно
|
||||
- Регулярно тестировать интеграцию с контрактами
|
||||
240
docs/ENCRYPTION_GUIDE.md
Normal file
240
docs/ENCRYPTION_GUIDE.md
Normal file
@@ -0,0 +1,240 @@
|
||||
# 🔐 Полное шифрование всех таблиц в DLE
|
||||
|
||||
## 📋 Обзор
|
||||
|
||||
Этот подход шифрует **ВСЕ текстовые данные** во **ВСЕХ таблицах** базы данных.
|
||||
|
||||
## 🎯 Что шифруется
|
||||
|
||||
### **✅ ВСЕ текстовые колонки во ВСЕХ таблицах:**
|
||||
- `text` - текстовые поля
|
||||
- `varchar` - строки переменной длины
|
||||
- `character varying` - строки переменной длины
|
||||
- `json` - JSON данные
|
||||
- `jsonb` - бинарные JSON данные
|
||||
|
||||
### **❌ НЕ шифруются:**
|
||||
- `id` - идентификаторы
|
||||
- `created_at`, `updated_at` - временные метки
|
||||
- `integer`, `numeric`, `boolean` - числовые и логические типы
|
||||
- Колонки, уже содержащие `_encrypted` в названии
|
||||
|
||||
## 🚀 Пошаговая инструкция
|
||||
|
||||
### **Шаг 1: Запуск полного шифрования**
|
||||
```bash
|
||||
chmod +x encrypt-all-tables.sh
|
||||
./encrypt-all-tables.sh
|
||||
```
|
||||
|
||||
### **Шаг 2: Проверка шифрования**
|
||||
```bash
|
||||
./decrypt-all-tables.sh
|
||||
```
|
||||
|
||||
### **Шаг 3: Обновление кода приложения**
|
||||
|
||||
#### **A. Использование универсального сервиса**
|
||||
```javascript
|
||||
const encryptedDataService = require('./services/encryptedDataService');
|
||||
|
||||
// Получение данных с автоматической расшифровкой
|
||||
const users = await encryptedDataService.getData('users', { role: 'admin' });
|
||||
|
||||
// Сохранение данных с автоматическим шифрованием
|
||||
const newUser = await encryptedDataService.saveData('users', {
|
||||
name: 'Иван Иванов',
|
||||
email: 'ivan@example.com',
|
||||
preferences: { theme: 'dark' }
|
||||
});
|
||||
|
||||
// Обновление данных
|
||||
const updatedUser = await encryptedDataService.saveData('users',
|
||||
{ name: 'Иван Петров' },
|
||||
{ id: 1 }
|
||||
);
|
||||
|
||||
// Удаление данных
|
||||
await encryptedDataService.deleteData('users', { id: 1 });
|
||||
```
|
||||
|
||||
#### **B. Проверка статуса шифрования**
|
||||
```javascript
|
||||
const status = await encryptedDataService.getEncryptionStatus();
|
||||
console.log('Статус шифрования:', status);
|
||||
// {
|
||||
// hasEncryptionKey: true,
|
||||
// encryptedTables: [
|
||||
// { table_name: 'users', encrypted_columns: '3' },
|
||||
// { table_name: 'messages', encrypted_columns: '2' }
|
||||
// ],
|
||||
// totalEncryptedColumns: 15
|
||||
// }
|
||||
```
|
||||
|
||||
### **Шаг 4: Обновление существующих роутов**
|
||||
|
||||
#### **Пример обновления роута пользователей:**
|
||||
```javascript
|
||||
// Было:
|
||||
router.get('/users', async (req, res) => {
|
||||
const { rows } = await db.getQuery()('SELECT * FROM users');
|
||||
res.json(rows);
|
||||
});
|
||||
|
||||
// Стало:
|
||||
router.get('/users', async (req, res) => {
|
||||
try {
|
||||
const users = await encryptedDataService.getData('users');
|
||||
res.json(users);
|
||||
} catch (error) {
|
||||
res.status(500).json({ error: error.message });
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
#### **Пример обновления роута сообщений:**
|
||||
```javascript
|
||||
// Было:
|
||||
router.post('/messages', async (req, res) => {
|
||||
const { content, user_id } = req.body;
|
||||
const { rows } = await db.getQuery()(
|
||||
'INSERT INTO messages (content, user_id) VALUES ($1, $2) RETURNING *',
|
||||
[content, user_id]
|
||||
);
|
||||
res.json(rows[0]);
|
||||
});
|
||||
|
||||
// Стало:
|
||||
router.post('/messages', async (req, res) => {
|
||||
try {
|
||||
const { content, user_id } = req.body;
|
||||
const message = await encryptedDataService.saveData('messages', {
|
||||
content,
|
||||
user_id
|
||||
});
|
||||
res.json(message);
|
||||
} catch (error) {
|
||||
res.status(500).json({ error: error.message });
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
### **Шаг 5: Тестирование**
|
||||
```bash
|
||||
# Проверить работу зашифрованных данных
|
||||
curl -X GET http://localhost:8000/api/users
|
||||
curl -X POST http://localhost:8000/api/messages -H "Content-Type: application/json" -d '{"content":"Тестовое сообщение","user_id":1}'
|
||||
|
||||
# Проверить расшифровку
|
||||
./decrypt-all-tables.sh
|
||||
```
|
||||
|
||||
### **Шаг 6: Удаление незашифрованных колонок**
|
||||
```bash
|
||||
# ВНИМАНИЕ: Это необратимая операция!
|
||||
./remove-unencrypted-columns.sh
|
||||
```
|
||||
|
||||
## 🔑 Управление ключами
|
||||
|
||||
### **Ключ шифрования**
|
||||
- **Файл**: `./ssl/keys/full_db_encryption.key`
|
||||
- **Размер**: 32 байта (base64)
|
||||
- **Алгоритм**: AES-256-CBC
|
||||
|
||||
### **Безопасность ключа**
|
||||
```bash
|
||||
# Права доступа
|
||||
chmod 600 ./ssl/keys/full_db_encryption.key
|
||||
|
||||
# Резервная копия
|
||||
cp ./ssl/keys/full_db_encryption.key ./ssl/keys/full_db_encryption.key.backup
|
||||
|
||||
# Проверка целостности
|
||||
sha256sum ./ssl/keys/full_db_encryption.key
|
||||
```
|
||||
|
||||
## 🛡️ Дополнительные меры безопасности
|
||||
|
||||
### **1. Шифрование томов Docker**
|
||||
```yaml
|
||||
# docker-compose.yml
|
||||
volumes:
|
||||
postgres_data:
|
||||
driver: local
|
||||
driver_opts:
|
||||
type: none
|
||||
o: bind
|
||||
device: /path/to/encrypted/storage
|
||||
```
|
||||
|
||||
### **2. SSL/TLS для PostgreSQL**
|
||||
```yaml
|
||||
# docker-compose.yml
|
||||
services:
|
||||
postgres:
|
||||
command: >
|
||||
postgres
|
||||
-c ssl=on
|
||||
-c ssl_cert_file=/etc/ssl/certs/server.crt
|
||||
-c ssl_key_file=/etc/ssl/certs/server.key
|
||||
```
|
||||
|
||||
### **3. Шифрование переменных окружения**
|
||||
```bash
|
||||
# Для оставшихся переменных окружения
|
||||
./encrypt-env.sh
|
||||
```
|
||||
|
||||
## 🔍 Мониторинг и аудит
|
||||
|
||||
### **Логирование доступа к зашифрованным данным**
|
||||
```javascript
|
||||
// В сервисе добавить логирование
|
||||
console.log(`🔐 Доступ к зашифрованным данным: ${tableName} в ${new Date().toISOString()}`);
|
||||
```
|
||||
|
||||
### **Проверка целостности**
|
||||
```bash
|
||||
# Скрипт для проверки целостности зашифрованных данных
|
||||
./verify-encryption.sh
|
||||
```
|
||||
|
||||
## ⚠️ Важные замечания
|
||||
|
||||
### **1. Производительность**
|
||||
- Шифрование/расшифровка добавляет задержку
|
||||
- Используйте кэширование для часто используемых данных
|
||||
- Рассмотрите индексы для зашифрованных колонок
|
||||
|
||||
### **2. Резервное копирование**
|
||||
- **Обязательно** делайте бэкап ключа шифрования
|
||||
- **Обязательно** делайте бэкап базы данных
|
||||
- Храните ключ отдельно от данных
|
||||
|
||||
### **3. Восстановление**
|
||||
```bash
|
||||
# Восстановление из бэкапа
|
||||
docker exec dapp-postgres psql -U dapp_user -d dapp_db < backup.sql
|
||||
|
||||
# Восстановление ключа
|
||||
cp ./ssl/keys/full_db_encryption.key.backup ./ssl/keys/full_db_encryption.key
|
||||
```
|
||||
|
||||
### **4. Совместимость**
|
||||
- Приложение работает с зашифрованными и незашифрованными данными
|
||||
- Fallback на незашифрованные данные при отсутствии ключа
|
||||
- Постепенная миграция существующих данных
|
||||
|
||||
## 🎯 Результат
|
||||
|
||||
После применения полного шифрования:
|
||||
- ✅ ВСЕ текстовые данные зашифрованы в БД
|
||||
- ✅ Ключ шифрования хранится отдельно
|
||||
- ✅ Приложение работает с зашифрованными данными
|
||||
- ✅ Fallback на незашифрованные данные при отсутствии ключа
|
||||
- ✅ Универсальный сервис для работы с данными
|
||||
- ✅ Возможность ротации ключей
|
||||
|
||||
**Максимальная безопасность данных достигнута!** 🔒
|
||||
200
docs/MIGRATION_GUIDE.md
Normal file
200
docs/MIGRATION_GUIDE.md
Normal file
@@ -0,0 +1,200 @@
|
||||
# 🔄 Перенос зашифрованных данных между серверами
|
||||
|
||||
## 📋 Обзор
|
||||
|
||||
При переносе зашифрованных данных важно передать **и данные, и ключ шифрования** вместе.
|
||||
|
||||
## 🎯 Способы переноса
|
||||
|
||||
### **1. 🔑 Перенос с ключом шифрования (Рекомендуемый)**
|
||||
|
||||
#### **Создание миграционного пакета:**
|
||||
```bash
|
||||
chmod +x migrate-encrypted-data.sh
|
||||
./migrate-encrypted-data.sh
|
||||
```
|
||||
|
||||
#### **Что включается в пакет:**
|
||||
- ✅ Бэкап базы данных (зашифрованные данные)
|
||||
- ✅ Ключ шифрования (`full_db_encryption.key`)
|
||||
- ✅ Скрипты шифрования/расшифровки
|
||||
- ✅ Сервис для работы с зашифрованными данными
|
||||
|
||||
### **2. 🌐 Перенос через SSH**
|
||||
```bash
|
||||
# На исходном сервере
|
||||
./migrate-encrypted-data.sh
|
||||
# Выберите опцию 2 - SSH
|
||||
|
||||
# Автоматически создастся архив и отправится на целевой сервер
|
||||
```
|
||||
|
||||
### **3. ☁️ Перенос через облачное хранилище**
|
||||
```bash
|
||||
# На исходном сервере
|
||||
./migrate-encrypted-data.sh
|
||||
# Выберите опцию 3 - Облачное хранилище
|
||||
|
||||
# Архив загрузится в S3/другое облачное хранилище
|
||||
# Скачайте на целевой сервер и восстановите
|
||||
```
|
||||
|
||||
### **4. 💾 Перенос через локальный носитель**
|
||||
```bash
|
||||
# На исходном сервере
|
||||
./migrate-encrypted-data.sh
|
||||
# Выберите опцию 4 - Локальный носитель
|
||||
|
||||
# Скопируйте архив на USB/SSD/другой носитель
|
||||
# Перенесите на целевой сервер
|
||||
```
|
||||
|
||||
## 🚀 Пошаговая инструкция
|
||||
|
||||
### **Этап 1: Подготовка исходного сервера**
|
||||
|
||||
#### **A. Создание миграционного пакета:**
|
||||
```bash
|
||||
# Создаём полный бэкап с ключом
|
||||
./migrate-encrypted-data.sh
|
||||
# Выберите опцию 1 - "Создать бэкап с ключом"
|
||||
|
||||
# Результат: migration_package_YYYYMMDD_HHMMSS.tar.gz
|
||||
```
|
||||
|
||||
#### **B. Проверка содержимого:**
|
||||
```bash
|
||||
# Просмотр содержимого архива
|
||||
tar -tzf migration_package_*.tar.gz
|
||||
|
||||
# Должно содержать:
|
||||
# - encrypted_backup_*.sql (бэкап БД)
|
||||
# - ssl/keys/full_db_encryption.key (ключ шифрования)
|
||||
# - encrypt-all-tables.sh (скрипт шифрования)
|
||||
# - decrypt-all-tables.sh (скрипт расшифровки)
|
||||
# - backend/services/encryptedDataService.js (сервис)
|
||||
```
|
||||
|
||||
### **Этап 2: Перенос на целевой сервер**
|
||||
|
||||
#### **A. Копирование архива:**
|
||||
```bash
|
||||
# Способ 1: SCP
|
||||
scp migration_package_*.tar.gz user@target-server:/tmp/
|
||||
|
||||
# Способ 2: USB/локальный носитель
|
||||
# Скопируйте файл на носитель и перенесите физически
|
||||
|
||||
# Способ 3: Облачное хранилище
|
||||
# Скачайте архив из S3/другого хранилища
|
||||
```
|
||||
|
||||
#### **B. Восстановление на целевом сервере:**
|
||||
```bash
|
||||
# 1. Распаковка архива
|
||||
tar -xzf migration_package_*.tar.gz -C /path/to/your/app/
|
||||
|
||||
# 2. Восстановление ключа шифрования
|
||||
chmod 600 ssl/keys/full_db_encryption.key
|
||||
|
||||
# 3. Восстановление базы данных
|
||||
docker exec dapp-postgres psql -U dapp_user dapp_db < encrypted_backup_*.sql
|
||||
|
||||
# 4. Проверка целостности
|
||||
./migrate-encrypted-data.sh
|
||||
# Выберите опцию 5 - "Проверить целостность"
|
||||
```
|
||||
|
||||
### **Этап 3: Проверка работоспособности**
|
||||
|
||||
#### **A. Проверка подключения к БД:**
|
||||
```bash
|
||||
# Проверяем подключение
|
||||
docker exec dapp-postgres pg_isready -U dapp_user -d dapp_db
|
||||
|
||||
# Проверяем зашифрованные данные
|
||||
docker exec dapp-postgres psql -U dapp_user -d dapp_db -c "
|
||||
SELECT
|
||||
table_name,
|
||||
COUNT(*) as encrypted_columns
|
||||
FROM information_schema.columns
|
||||
WHERE table_schema = 'public'
|
||||
AND column_name LIKE '%_encrypted'
|
||||
GROUP BY table_name;"
|
||||
```
|
||||
|
||||
#### **B. Тестирование приложения:**
|
||||
```bash
|
||||
# Запускаем приложение
|
||||
docker-compose up -d
|
||||
|
||||
# Проверяем API
|
||||
curl -X GET http://localhost:8000/api/health
|
||||
curl -X GET http://localhost:8000/api/users
|
||||
```
|
||||
|
||||
## 🔐 Безопасность при переносе
|
||||
|
||||
### **1. Защита ключа шифрования:**
|
||||
```bash
|
||||
# Правильные права доступа
|
||||
chmod 600 ssl/keys/full_db_encryption.key
|
||||
|
||||
# Резервная копия ключа
|
||||
cp ssl/keys/full_db_encryption.key ssl/keys/full_db_encryption.key.backup
|
||||
|
||||
# Проверка целостности
|
||||
sha256sum ssl/keys/full_db_encryption.key
|
||||
```
|
||||
|
||||
### **2. Безопасная передача:**
|
||||
- Используйте SSH для передачи
|
||||
- Шифруйте архив дополнительно
|
||||
- Используйте защищённые каналы связи
|
||||
|
||||
### **3. Очистка после переноса:**
|
||||
```bash
|
||||
# Удаляем временные файлы
|
||||
rm -rf migration_backups/
|
||||
rm -f /tmp/migration_package_*.tar.gz
|
||||
|
||||
# Очищаем историю команд
|
||||
history -c
|
||||
```
|
||||
|
||||
## ⚠️ Важные замечания
|
||||
|
||||
### **1. Совместимость версий:**
|
||||
- Убедитесь, что версии PostgreSQL одинаковые
|
||||
- Проверьте совместимость расширений (pgcrypto)
|
||||
- Убедитесь в совместимости Docker образов
|
||||
|
||||
### **2. Размер данных:**
|
||||
- Зашифрованные данные занимают больше места
|
||||
- Учитывайте размер при планировании переноса
|
||||
- Используйте сжатие для больших баз данных
|
||||
|
||||
### **3. Время простоя:**
|
||||
- Миграция может занять время
|
||||
- Планируйте время простоя
|
||||
- Используйте репликацию для минимизации простоя
|
||||
|
||||
### **4. Восстановление:**
|
||||
```bash
|
||||
# В случае проблем с миграцией
|
||||
# Восстановите из резервной копии
|
||||
docker exec dapp-postgres psql -U dapp_user -d dapp_db < backup.sql
|
||||
|
||||
# Восстановите ключ
|
||||
cp ssl/keys/full_db_encryption.key.backup ssl/keys/full_db_encryption.key
|
||||
```
|
||||
|
||||
## 🎯 Результат
|
||||
|
||||
После успешной миграции:
|
||||
- ✅ Все данные перенесены с шифрованием
|
||||
- ✅ Ключ шифрования восстановлен
|
||||
- ✅ Приложение работает на новом сервере
|
||||
- ✅ Безопасность данных сохранена
|
||||
|
||||
**Миграция зашифрованных данных завершена успешно!** 🔒
|
||||
409
docs/SMART_CONTRACTS.md
Normal file
409
docs/SMART_CONTRACTS.md
Normal file
@@ -0,0 +1,409 @@
|
||||
# Смарт Контракты Digital Legal Entity (DLE)
|
||||
|
||||
## Основной смарт контракт DLE
|
||||
|
||||
### Концепция
|
||||
Адрес смарт контракта одновременно выполняет функции банковского счета и контактных данных (как email/телефонный номер).
|
||||
|
||||
### Требования
|
||||
|
||||
#### 1. Токен управления
|
||||
- Пользователь заполняет форму в приложении для ручного деплоя
|
||||
- Токен дает права голоса держателям
|
||||
токен передается только через кворум мультиподписей
|
||||
|
||||
#### 2. Казначейские функции
|
||||
- Управление финансами через голосование токен-холдеров
|
||||
- Мультиподпись токен-холдеров для выполнения транзакций (проверка баланса)
|
||||
- Функции банковского счета
|
||||
- НЕТ админских ролей - все через коллективное голосование
|
||||
|
||||
#### 3. Система голосования с мультиподписью
|
||||
- Голосование за деплой дополнительных смарт контрактов через мультиподпись
|
||||
- Кворум подписей токен-холдеров для принятия решений (проверка баланса)
|
||||
- Токен-холдеры управляют всеми операциями через систему подписей
|
||||
- Настраиваемые таймлоки для каждого предложения
|
||||
- НЕТ админских ролей - только коллективное управление
|
||||
|
||||
#### 4. Система настраиваемых таймлоков (отдельный модуль)
|
||||
- **Архитектура**: Отдельный контракт TimelockController, создаваемый при деплое DLE
|
||||
- **Настройки при деплое**:
|
||||
- Минимальная задержка таймлока (настраиваемая)
|
||||
- Максимальная задержка таймлока (настраиваемая)
|
||||
- Задержка по умолчанию (настраиваемая)
|
||||
- Возможность настройки индивидуальной задержки для каждого предложения
|
||||
- **Функции модуля**:
|
||||
- Инициатор предложения устанавливает индивидуальную задержку
|
||||
- Динамическое изменение параметров таймлока через голосование
|
||||
- Отмена предложений до истечения таймлока
|
||||
- Выполнение предложений после истечения таймлока
|
||||
- **Пример параметров**: 1 день задержки, 7 дней голосования, 2 дня timelock
|
||||
|
||||
#### 5. Модульная система
|
||||
- Настройка отдельных модулей с формами в приложении
|
||||
- Деплой дополнительных смарт контрактов через голосование
|
||||
- Расширяемость функционала
|
||||
|
||||
#### 6. Коммуникационные функции
|
||||
- Прием сообщений от криптокошельков и смарт контрактов
|
||||
- Прием звонков (аудио/видео) от владельцев кошельков
|
||||
- Адрес контракта = универсальный контакт (как email/телефон)
|
||||
- Кворум мультиподписей токен-холдеров для приема звонков и отправки сообщений
|
||||
- НЕТ админских ролей - все через коллективное голосование
|
||||
|
||||
#### 7. Функции акционерного общества
|
||||
- Права голоса пропорционально токенам
|
||||
- Управление через коллективные решения токен-холдеров
|
||||
- Прозрачность всех операций
|
||||
- НЕТ единичных администраторов - только коллективное управление через кворум подписей
|
||||
|
||||
### Иерархическая система голосования DLE
|
||||
|
||||
#### Концепция
|
||||
DLE может владеть токенами других DLE и участвовать в их голосовании через систему кворума подписей.
|
||||
|
||||
#### Механизм работы
|
||||
1. **DLE A** владеет токенами **DLE B**
|
||||
2. **Голос DLE A** в **DLE B** прямо пропорционален количеству токенов **DLE B** на балансе **DLE A**
|
||||
3. Для участия в голосовании **DLE B** холдеры **DLE A** должны собрать **кворум мультиподписей** внутри **DLE A**
|
||||
4. После достижения кворума подписей **DLE A** может голосовать в **DLE B** как единое целое
|
||||
|
||||
#### Пример
|
||||
- **DLE A** владеет **10% токенов DLE B**
|
||||
- Кворум в **DLE B** = **51%**
|
||||
- Холдеры **DLE A** голосуют за подпись в **DLE B**
|
||||
- **DLE B** получает от **DLE A** подпись на **10% голосов**
|
||||
|
||||
#### Технические требования
|
||||
- Система сбора мультиподписей внутри DLE для внешнего голосования
|
||||
- Проверка кворума подписей перед активацией голоса DLE
|
||||
- Прямо пропорциональный подсчет голосов по количеству токенов
|
||||
- Интерфейсы для взаимодействия между DLE
|
||||
|
||||
### Межприложное взаимодействие DLE
|
||||
|
||||
#### Концепция
|
||||
Каждое DLE имеет свое веб3 приложение с интерфейсом управления. DLE могут взаимодействовать через встраивание интерфейсов.
|
||||
|
||||
#### Архитектура взаимодействия
|
||||
- **DLE A** (домен 1) + **Веб3 приложение A** с интерфейсом
|
||||
- **DLE B** (домен 2) + **Веб3 приложение B** с интерфейсом
|
||||
- **Голосование** происходит через блокчейн между доменами
|
||||
|
||||
#### Вариант реализации (рекомендуемый)
|
||||
**Встраивание интерфейса DLE B в приложение DLE A**
|
||||
|
||||
##### Преимущества:
|
||||
- **Безопасность**: Холдеры DLE A не покидают свое приложение
|
||||
- **Защита от фишинга**: Пользователи всегда в знакомой среде
|
||||
- **Контроль**: DLE A контролирует безопасность интерфейса
|
||||
- **Удобство**: Единый интерфейс для управления всеми DLE
|
||||
- **Аудит**: Все действия отслеживаются в одном месте
|
||||
|
||||
##### Техническая реализация:
|
||||
```javascript
|
||||
// В приложении DLE A
|
||||
function DLEBManagementInterface({ dleBAddress }) {
|
||||
return (
|
||||
<div className="dle-b-management">
|
||||
<h3>Управление DLE B</h3>
|
||||
<VotingInterface targetDLE={dleBAddress} />
|
||||
<ProposalInterface targetDLE={dleBAddress} />
|
||||
<TreasuryInterface targetDLE={dleBAddress} />
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
##### Пример интерфейса:
|
||||
- URL: `http://localhost:5173/dle-management`
|
||||
- Встраивание компонентов управления DLE B
|
||||
- Безопасное подписание транзакций для DLE B
|
||||
- Проверка прав через мультиподпись
|
||||
|
||||
### Технические требования
|
||||
- Один адрес = универсальная точка входа
|
||||
- Безопасность мультиподписи
|
||||
- Масштабируемость через модули
|
||||
- Поддержка аудио/видео коммуникации
|
||||
- Совместимость с существующими стандартами (ERC-20, ERC-721)
|
||||
- Иерархическая система голосования между DLE
|
||||
- Межприложное взаимодействие через встраивание интерфейсов
|
||||
|
||||
## Мульти-чейн архитектура DLE
|
||||
|
||||
### Концепция
|
||||
DLE должен функционировать в нескольких блокчейн-сетях с одинаковым адресом для обеспечения максимального удобства и универсальности.
|
||||
|
||||
### Требования
|
||||
|
||||
#### 1. CREATE2 детерминистический деплой
|
||||
- Использование CREATE2 opcode для предсказуемых адресов
|
||||
- Одинаковый адрес смарт-контракта во всех EVM-совместимых сетях
|
||||
- Factory контракт с одинаковым адресом во всех целевых сетях
|
||||
- Детерминистический salt на основе пользовательских данных
|
||||
|
||||
#### 2. Синхронные токены управления
|
||||
- Одинаковое количество токенов для каждого партнера во всех сетях
|
||||
- Синхронизация операций с токенами между всеми развернутыми сетями
|
||||
- Все операции с токенами только через мультиподпись и кворум
|
||||
- Защита от double-spending и рассинхронизации
|
||||
|
||||
#### 3. Cross-chain система голосования
|
||||
- Возможность выбора сети для инициации голосования
|
||||
- Кворум рассчитывается по токенам в выбранной сети
|
||||
- Результаты голосования синхронизируются во все сети
|
||||
- Выполнение решений может происходить в любой из развернутых сетей
|
||||
|
||||
#### 4. Cross-chain синхронизация операций
|
||||
- Функция связывания операций между сетями
|
||||
- Атомарное выполнение операций во всех целевых сетях
|
||||
- Система откатов при сбоях в одной из сетей
|
||||
- Таймауты и fallback механизмы
|
||||
|
||||
#### 3. Single-Chain Governance система
|
||||
- Инициатор предложения выбирает ОДНУ сеть для голосования
|
||||
- Все токен-холдеры участвуют в мультиподписи только в выбранной сети
|
||||
- Инициатор устанавливает таймлок для предложения
|
||||
- Исполнение решения происходит во всех целевых сетях
|
||||
|
||||
#### 4. Упрощенная cross-chain архитектура
|
||||
- Голосование и кворум ТОЛЬКО в одной governance сети
|
||||
- Проверка балансов токен-холдеров при подписании
|
||||
- Настраиваемый таймлок для каждого предложения
|
||||
- Исполнение во всех выбранных целевых сетях
|
||||
|
||||
#### 5. Мульти-сетевой деплой
|
||||
- Выбор множественных сетей для деплоя из интерфейса
|
||||
- Автоматический расчет стоимости деплоя по всем сетям
|
||||
- Поддержка различных EVM-совместимых сетей
|
||||
- Возможность добавления новых сетей после первоначального деплоя
|
||||
|
||||
### Поддерживаемые сети
|
||||
- деинамическое и только те которые добавлены в таблицу rpc провайдеров
|
||||
|
||||
### Архитектура синхронизации
|
||||
|
||||
#### Cross-Chain операции
|
||||
```solidity
|
||||
contract DLE_CrossChainSync {
|
||||
struct CrossChainOperation {
|
||||
uint256[] targetChains; // Целевые сети для выполнения
|
||||
bytes[] callData; // Данные для выполнения
|
||||
uint256 executedChains; // Количество выполненных сетей
|
||||
bool isCompleted; // Статус завершения
|
||||
uint256 timeout; // Время истечения операции
|
||||
}
|
||||
|
||||
function executeMultiChainOperation(bytes32 operationId, uint256 chainId) external;
|
||||
function syncTokenOperation(address[] holders, uint256[] amounts, uint256[] chains) external;
|
||||
}
|
||||
```
|
||||
|
||||
#### Типы синхронизируемых операций
|
||||
- **Передача токенов** между партнерами
|
||||
- **Минтинг новых токенов** для новых участников
|
||||
- **Сжигание токенов** при выходе участников
|
||||
- **Изменение прав доступа** и ролей
|
||||
- **Выполнение решений голосования**
|
||||
|
||||
### Упрощенная архитектура governance
|
||||
|
||||
#### Single-Chain Governance контракт
|
||||
```solidity
|
||||
contract DLE_Governance {
|
||||
struct Proposal {
|
||||
bytes operation; // Операция для выполнения
|
||||
uint256[] targetChains; // Целевые сети для исполнения
|
||||
uint256 timelock; // Время исполнения (timestamp)
|
||||
uint256 governanceChain; // Сеть где проходит голосование
|
||||
address initiator; // Инициатор предложения
|
||||
bytes[] signatures; // Подписи токен-холдеров
|
||||
bool executed; // Статус исполнения
|
||||
}
|
||||
|
||||
function createProposal(
|
||||
bytes calldata operation,
|
||||
uint256[] calldata targetChains,
|
||||
uint256 timelockDelay
|
||||
) external onlyTokenHolder returns (uint256 proposalId);
|
||||
|
||||
function signProposal(uint256 proposalId) external onlyTokenHolder;
|
||||
|
||||
function executeProposal(uint256 proposalId) external;
|
||||
}
|
||||
```
|
||||
|
||||
#### Типы операций
|
||||
- **Управление токенами** - перевод, минтинг, сжигание
|
||||
- **Финансовые операции** - выплата дивидендов, инвестиции
|
||||
- **Emergency действия** - пауза, разморозка, восстановление
|
||||
- **Модульные операции** - добавление/удаление функциональности
|
||||
|
||||
### Безопасность мульти-чейн операций
|
||||
|
||||
#### Требования к безопасности
|
||||
- Кворум для cross-chain операций не менее 67%
|
||||
- Подтверждение операций в нескольких блоках (минимум 12)
|
||||
- Система откатов при сбоях синхронизации
|
||||
- Мониторинг состояния во всех сетях
|
||||
|
||||
#### Механизмы защиты
|
||||
- **Timelock для критических операций** - задержка выполнения
|
||||
- **Emergency pause** - остановка операций при обнаружении проблем
|
||||
- **Fallback сеть** - резервная сеть при сбоях основной
|
||||
- **Валидация состояния** - проверка консистентности данных
|
||||
|
||||
### Безопасность Single-Chain Governance
|
||||
|
||||
#### Требования к безопасности
|
||||
- Участие только верифицированных токен-холдеров
|
||||
- Проверка балансов токенов на момент подписания
|
||||
- Настраиваемый кворум подписей (минимум 51%)
|
||||
- Настраиваемый таймлок для всех операций (кроме emergency)
|
||||
|
||||
#### Механизмы защиты
|
||||
- **Token-holder verification** - только владельцы токенов участвуют
|
||||
- **Balance verification** - проверка баланса при каждой подписи
|
||||
- **Flexible timelock** - инициатор устанавливает задержку
|
||||
- **Governance chain selection** - инициатор устанавливает сеть для голосования
|
||||
- **Atomic execution** - операция выполняется во всех сетях или не выполняется
|
||||
- **Fallback mechanisms** - исполнение в доступных сетях при сбоях
|
||||
|
||||
### Пользовательский интерфейс
|
||||
|
||||
#### Форма мульти-чейн деплоя
|
||||
- Выбор целевых сетей из выпадающего списка
|
||||
- Предварительный расчет стоимости деплоя
|
||||
- Настройки single-chain governance
|
||||
|
||||
#### Создание предложений
|
||||
- Выбор governance сети для голосования
|
||||
- Установка таймлока инициатором
|
||||
- Выбор целевых сетей для исполнения
|
||||
- Описание операции и параметров
|
||||
|
||||
#### Участие в голосовании
|
||||
- Подписание предложений в governance сети
|
||||
- Проверка баланса токенов при подписи
|
||||
- Отображение прогресса сбора подписей
|
||||
- Статус исполнения в целевых сетях
|
||||
|
||||
### Технические требования мульти-чейн
|
||||
- Детерминистический деплой через CREATE2
|
||||
- Синхронизация состояния между сетями
|
||||
- Защита от MEV-атак при cross-chain операциях
|
||||
- Оптимизация газа для массовых операций
|
||||
- Поддержка различных bridge протоколов
|
||||
|
||||
### Технические требования упрощенной архитектуры
|
||||
- Детерминистический деплой через CREATE2
|
||||
- Single-chain governance для безопасности
|
||||
- Token-holder verification при каждой подписи
|
||||
- Настраиваемые таймлоки для разных типов операций
|
||||
- Атомарное исполнение во всех целевых сетях
|
||||
- Fallback механизмы при недоступности сетей
|
||||
|
||||
## Технические решения
|
||||
|
||||
### ERC-4337 (Account Abstraction) как основа
|
||||
|
||||
#### Концепция
|
||||
ERC-4337 предоставляет стандартную инфраструктуру для смарт-контракт кошельков с универсальностью (один адрес во всех цепочках) и готовыми решениями для оптимизации газа.
|
||||
|
||||
#### Компоненты ERC-4337
|
||||
- **Smart Contract Wallets** - встроенная мультиподпись
|
||||
- **Bundlers** - оптимизация газа через агрегацию транзакций
|
||||
- **Paymasters** - гибкая оплата транзакций
|
||||
- **Account Abstraction** - универсальность и стандартизация
|
||||
|
||||
#### Преимущества использования ERC-4337
|
||||
- ✅ **Универсальность** - один адрес во всех блокчейнах
|
||||
- ✅ **Готовые решения** - проверенная экосистема
|
||||
- ✅ **Безопасность** - прошедший аудит стандарт
|
||||
- ✅ **Оптимизация** - встроенная экономия газа
|
||||
- ✅ **Совместимость** - стандартные интерфейсы
|
||||
|
||||
### Варианты технической реализации
|
||||
|
||||
|
||||
|
||||
#### Вариант 1: Собственный контракт + ERC-4337
|
||||
**Создание собственного DLE контракта с использованием компонентов ERC-4337**
|
||||
|
||||
##### Архитектура:
|
||||
```
|
||||
Собственный DLE контракт
|
||||
├── ERC-4337 компоненты (импорт/наследование)
|
||||
│ ├── Account Abstraction логика
|
||||
│ ├── Bundler совместимость
|
||||
│ └── Paymaster поддержка
|
||||
└── DLE Logic (ваша уникальная логика)
|
||||
├── Governance Token
|
||||
├── Single-Chain Voting System
|
||||
├── Communication
|
||||
├── Treasury
|
||||
└── Multi-Chain Execution
|
||||
```
|
||||
|
||||
|
||||
### Лицензия ERC-4337
|
||||
ERC-4337 распространяется под лицензией **CC0** (Public Domain), что означает полную свободу использования.
|
||||
|
||||
## Готовые компоненты с аудитом
|
||||
|
||||
### 1. **OpenZeppelin** (аудит: ConsenSys Diligence)
|
||||
- ✅ **ERC-20** - токены управления
|
||||
- ✅ **Governance** - система голосования
|
||||
- ✅ **Access Control** - роли и разрешения
|
||||
- ✅ **Multisig** - мультиподпись
|
||||
- ✅ **Timelock** - задержки выполнения
|
||||
|
||||
### 2. **ERC-4337** (аудит: Trail of Bits)
|
||||
- ✅ **Account Abstraction** - универсальность
|
||||
- ✅ **Smart Contract Wallets** - кошельки
|
||||
- ✅ **Bundlers** - оптимизация газа
|
||||
|
||||
### 3. **Проверенные паттерны**
|
||||
- ✅ **Diamond Pattern** (EIP-2535) - модульность
|
||||
- ✅ **Proxy Pattern** - обновляемость
|
||||
- ✅ **Factory Pattern** - создание контрактов
|
||||
|
||||
## Архитектура безопасного контракта DLE
|
||||
|
||||
### **Сборка в один безопасный контракт:**
|
||||
```solidity
|
||||
contract DLE is ERC20, Governor, TimelockController {
|
||||
// Single-chain governance логика
|
||||
// + готовые компоненты с аудитом
|
||||
// + проверенные паттерны
|
||||
}
|
||||
```
|
||||
|
||||
### **Компоненты для интеграции:**
|
||||
- **ERC-20** - токен управления DLE
|
||||
- **Governor** - система голосования с мультиподписью
|
||||
- **TimelockController** - настраиваемые таймлоки
|
||||
- **Account Abstraction** - универсальность адреса
|
||||
|
||||
## Преимущества упрощенного подхода:
|
||||
|
||||
### ✅ **Безопасность**
|
||||
- Все компоненты протестированы и проаудированы
|
||||
- Устранены риски cross-chain мостов
|
||||
- Single-chain governance снижает сложность
|
||||
|
||||
### ✅ **Эффективность**
|
||||
- Использование готовых решений OpenZeppelin
|
||||
- Быстрая разработка с проверенными компонентами
|
||||
- Меньше ошибок благодаря упрощенной архитектуре
|
||||
|
||||
### ✅ **Надежность**
|
||||
- Временем проверенные решения
|
||||
- Простая логика мультиподписи токен-холдеров
|
||||
- Понятные механизмы таймлоков
|
||||
|
||||
### ✅ **Совместимость**
|
||||
- Стандартные интерфейсы Ethereum
|
||||
- Совместимость с существующими кошельками
|
||||
- Легкая интеграция с DeFi протоколами
|
||||
429
docs/TECHNICAL_SPECIFICATION.md
Normal file
429
docs/TECHNICAL_SPECIFICATION.md
Normal file
@@ -0,0 +1,429 @@
|
||||
# Техническое задание: Digital Legal Entity (DLE)
|
||||
|
||||
## 1. Общие сведения
|
||||
|
||||
### 1.1 Назначение системы
|
||||
Создание смарт-контракта DLE (Digital Legal Entity) - универсальной цифровой юридической сущности, которая объединяет функции акционерного общества, банковского счета и контактных данных в одном адресе блокчейна.
|
||||
|
||||
### 1.2 Цель разработки
|
||||
Разработка безопасного, масштабируемого и функционального смарт-контракта для токенизации акционерных обществ с поддержкой иерархического управления и коммуникационных функций.
|
||||
|
||||
### 1.3 Технический подход
|
||||
Использование готовых проаудированных компонентов (OpenZeppelin, ERC-4337) с добавлением уникальной бизнес-логики DLE.
|
||||
|
||||
## 2. Функциональные требования
|
||||
|
||||
### 2.1 Основные функции DLE
|
||||
|
||||
#### 2.1.1 Токен управления
|
||||
- **Описание**: ERC-20 токен для управления DLE
|
||||
- **Функции**:
|
||||
- Минтинг токенов при создании DLE
|
||||
- Распределение токенов между участниками
|
||||
- Делегирование голосов
|
||||
- Проверка баланса токенов
|
||||
|
||||
#### 2.1.2 Система голосования с мультиподписью
|
||||
- **Описание**: Система принятия решений через кворум подписей токен-холдеров
|
||||
- **Функции**:
|
||||
- Создание предложений (любым токен-холдером)
|
||||
- Сбор подписей от токен-холдеров (проверка баланса токенов)
|
||||
- Проверка кворума подписей (% от общего количества токенов)
|
||||
- Выполнение предложений после достижения кворума
|
||||
- Динамический выбор governance сети при создании предложения
|
||||
- Динамическая настройка таймлока для каждого предложения
|
||||
- **Принцип**: НЕТ админских ролей - ВСЕ управление через токен-холдеров
|
||||
|
||||
#### 2.1.3 Настраиваемые таймлоки
|
||||
- **Описание**: Система задержек для каждого предложения через отдельный модуль TimelockController
|
||||
- **Архитектура**: Отдельный контракт TimelockController, создаваемый при деплое DLE
|
||||
- **Параметры**:
|
||||
- Минимальная задержка таймлока (настраиваемая при деплое)
|
||||
- Максимальная задержка таймлока (настраиваемая при деплое)
|
||||
- Задержка по умолчанию (настраиваемая при деплое)
|
||||
- Возможность настройки индивидуальной задержки для каждого предложения
|
||||
- **Функции**:
|
||||
- Инициатор предложения устанавливает индивидуальную задержку
|
||||
- Динамическое изменение параметров таймлока через голосование
|
||||
- Отмена предложений до истечения таймлока
|
||||
- Выполнение предложений после истечения таймлока
|
||||
|
||||
#### 2.1.4 Казначейские функции
|
||||
- **Описание**: Управление финансами DLE
|
||||
- **Функции**:
|
||||
- Прием и отправка криптовалют
|
||||
- Управление токенами
|
||||
- Распределение дивидендов
|
||||
- Бюджетирование
|
||||
|
||||
#### 2.1.5 Коммуникационные функции
|
||||
- **Описание**: Прием сообщений и звонков
|
||||
- **Функции**:
|
||||
- Прием текстовых сообщений
|
||||
- Прием аудио/видео звонков
|
||||
- Кворум для коммуникационных действий
|
||||
- Хранение истории коммуникаций
|
||||
|
||||
#### 2.1.6 Модульная система
|
||||
- **Описание**: Расширяемая архитектура
|
||||
- **Функции**:
|
||||
- Добавление новых модулей
|
||||
- Управление модулями через голосование
|
||||
- Изоляция модулей
|
||||
- Обновление модулей
|
||||
|
||||
### 2.2 Иерархическая система голосования
|
||||
|
||||
#### 2.2.1 Меж-DLE взаимодействие
|
||||
- **Описание**: DLE может владеть токенами других DLE
|
||||
- **Функции**:
|
||||
- Проверка владения токенами других DLE
|
||||
- Сбор кворума подписей для внешнего голосования
|
||||
- Участие в голосовании других DLE
|
||||
- Пропорциональный подсчет голосов
|
||||
|
||||
#### 2.2.2 Кворум подписей
|
||||
- **Описание**: Система сбора подписей для внешнего голосования
|
||||
- **Функции**:
|
||||
- Создание запросов на внешнее голосование
|
||||
- Сбор подписей от токен холдеров
|
||||
- Проверка достижения кворума
|
||||
- Активация голоса в целевой DLE
|
||||
|
||||
### 2.3 Межприложное взаимодействие
|
||||
|
||||
#### 2.3.1 Встраивание интерфейсов
|
||||
- **Описание**: Управление DLE B через приложение DLE A
|
||||
- **Функции**:
|
||||
- Встраивание интерфейса управления
|
||||
- Безопасное подписание транзакций
|
||||
- Проверка прав доступа
|
||||
- Аудит действий
|
||||
|
||||
### 2.4 Мульти-чейн архитектура
|
||||
|
||||
#### 2.4.1 CREATE2 детерминистический деплой
|
||||
- **Описание**: Создание DLE с одинаковым адресом во всех EVM-сетях
|
||||
- **Функции**:
|
||||
- Использование CREATE2 opcode для предсказуемых адресов
|
||||
- Factory контракт с фиксированным адресом во всех сетях
|
||||
- Генерация детерминистического salt на основе пользовательских данных
|
||||
- Предварительное вычисление адреса DLE до деплоя
|
||||
|
||||
#### 2.4.2 Синхронизация токенов управления
|
||||
- **Описание**: Синхронное управление токенами во всех развернутых сетях
|
||||
- **Функции**:
|
||||
- Одинаковое распределение токенов для партнеров во всех сетях
|
||||
- Cross-chain синхронизация операций с токенами
|
||||
- Атомарное выполнение операций во всех целевых сетях
|
||||
- Защита от рассинхронизации и double-spending
|
||||
|
||||
#### 2.4.3 Cross-chain система голосования
|
||||
- **Описание**: Голосование с выбором сети и синхронизацией результатов
|
||||
- **Функции**:
|
||||
- Выбор сети для инициации голосования
|
||||
- Расчет кворума по токенам в выбранной сети
|
||||
- Синхронизация результатов во все развернутые сети
|
||||
- Выполнение решений в любой из целевых сетей
|
||||
|
||||
#### 2.4.3 Single-Chain Governance система
|
||||
- **Описание**: Упрощенная система голосования в одной выбранной сети
|
||||
- **Функции**:
|
||||
- Инициатор выбирает governance сеть для голосования
|
||||
- Все токен-холдеры участвуют только в выбранной сети
|
||||
- Инициатор устанавливает таймлок для предложения
|
||||
- Проверка балансов токенов при каждой подписи
|
||||
- Исполнение решения во всех целевых сетях
|
||||
|
||||
#### 2.4.4 Мульти-сетевой деплой
|
||||
- **Описание**: Одновременный деплой в несколько блокчейн-сетей
|
||||
- **Функции**:
|
||||
- Выбор множественных сетей из интерфейса
|
||||
- Автоматический расчет общей стоимости деплоя
|
||||
- Параллельное развертывание во всех выбранных сетях
|
||||
- Возможность добавления новых сетей после первоначального деплоя
|
||||
|
||||
#### 2.4.5 Упрощенные cross-chain операции
|
||||
- **Описание**: Исполнение решений во всех целевых сетях после single-chain голосования
|
||||
- **Функции**:
|
||||
- Атомарное исполнение во всех выбранных сетях
|
||||
- Fallback исполнение в доступных сетях при сбоях
|
||||
- Мониторинг статуса исполнения операций
|
||||
- Откат операций при критических сбоях
|
||||
|
||||
## 3. Технические требования
|
||||
|
||||
### 3.1 Архитектура смарт-контракта
|
||||
|
||||
#### 3.1.1 Основная структура
|
||||
```solidity
|
||||
contract DLE is ERC20, Governor, TimelockController {
|
||||
// Ваша уникальная логика DLE
|
||||
// + готовые компоненты с аудитом
|
||||
// + проверенные паттерны
|
||||
}
|
||||
```
|
||||
|
||||
#### 3.1.2 Компоненты для интеграции
|
||||
- **ERC-20** - токен управления DLE
|
||||
- **Governor** - система голосования с мультиподписью
|
||||
- **TimelockController** - настраиваемые таймлоки
|
||||
- **Account Abstraction** - универсальность адреса
|
||||
|
||||
#### 3.1.3 Мульти-чейн архитектура
|
||||
```solidity
|
||||
// Factory для детерминистического деплоя
|
||||
contract DLEFactory {
|
||||
function createDLE(
|
||||
bytes32 salt,
|
||||
DLEConfig memory config,
|
||||
uint256[] memory targetChains
|
||||
) external returns (address predictedAddress);
|
||||
|
||||
function predictAddress(bytes32 salt, DLEConfig memory config)
|
||||
external view returns (address);
|
||||
}
|
||||
|
||||
// Single-Chain Governance
|
||||
contract DLE_Governance {
|
||||
struct Proposal {
|
||||
bytes operation;
|
||||
uint256[] targetChains;
|
||||
uint256 timelock;
|
||||
uint256 governanceChain;
|
||||
address initiator;
|
||||
bytes[] signatures;
|
||||
bool executed;
|
||||
}
|
||||
|
||||
function createProposal(bytes calldata operation, uint256[] calldata targetChains, uint256 timelockDelay) external;
|
||||
function signProposal(uint256 proposalId) external onlyTokenHolder;
|
||||
function executeProposal(uint256 proposalId) external;
|
||||
}
|
||||
|
||||
// Основной контракт DLE с упрощенной архитектурой
|
||||
contract DLE is ERC20, Governor, TimelockController {
|
||||
// Single-chain governance
|
||||
mapping(uint256 => bool) public supportedChains;
|
||||
mapping(uint256 => Proposal) public proposals;
|
||||
|
||||
// Проверка токен-холдеров
|
||||
modifier onlyTokenHolder() {
|
||||
require(balanceOf(msg.sender) > 0, "Must hold tokens");
|
||||
_;
|
||||
}
|
||||
|
||||
// Исполнение в целевых сетях
|
||||
function executeInTargetChains(bytes calldata operation, uint256[] calldata chains) external;
|
||||
}
|
||||
```
|
||||
|
||||
#### 3.1.4 Компоненты для интеграции
|
||||
- **ERC-20** - токен управления DLE
|
||||
- **Governor** - система голосования с мультиподписью
|
||||
- **TimelockController** - отдельный модуль настраиваемых таймлоков
|
||||
- **Account Abstraction** - универсальность адреса
|
||||
- **CREATE2 Factory** - детерминистический деплой
|
||||
- **Single-Chain Governance** - упрощенное управление через одну сеть
|
||||
|
||||
### 3.2 Готовые компоненты с аудитом
|
||||
|
||||
#### 3.2.1 OpenZeppelin (аудит: ConsenSys Diligence)
|
||||
- ERC-20 - токены управления
|
||||
- Governance - система голосования
|
||||
- Access Control - роли и разрешения
|
||||
- Multisig - мультиподпись
|
||||
- Timelock - задержки выполнения
|
||||
|
||||
#### 3.2.2 ERC-4337 (аудит: Trail of Bits)
|
||||
- Account Abstraction - универсальность
|
||||
- Smart Contract Wallets - кошельки
|
||||
- Bundlers - оптимизация газа
|
||||
|
||||
#### 3.2.3 Проверенные паттерны
|
||||
- Diamond Pattern (EIP-2535) - модульность
|
||||
- Proxy Pattern - обновляемость
|
||||
- Factory Pattern - создание контрактов
|
||||
|
||||
### 3.3 Безопасность
|
||||
|
||||
#### 3.3.1 Требования к безопасности
|
||||
- Полный аудит смарт-контракта
|
||||
- Тестирование всех функций
|
||||
- Проверка уязвимостей
|
||||
- Соответствие стандартам безопасности
|
||||
|
||||
#### 3.3.2 Меры безопасности
|
||||
- Использование проаудированных компонентов
|
||||
- Проверенные паттерны разработки
|
||||
- Изоляция рисков
|
||||
- Поэтапная разработка с тестированием
|
||||
|
||||
### 3.4 Производительность
|
||||
|
||||
#### 3.4.1 Оптимизация газа
|
||||
- Минимизация стоимости транзакций
|
||||
- Эффективные алгоритмы
|
||||
- Использование bundlers (ERC-4337)
|
||||
- Оптимизация хранения данных
|
||||
|
||||
#### 3.4.2 Масштабируемость
|
||||
- Поддержка большого количества участников
|
||||
- Эффективная обработка голосований
|
||||
- Оптимизация меж-DLE взаимодействий
|
||||
- Модульная архитектура
|
||||
|
||||
## 4. Интерфейсы и интеграции
|
||||
|
||||
### 4.1 Веб3 приложение
|
||||
|
||||
#### 4.1.1 Функции приложения
|
||||
- Создание DLE через форму
|
||||
- Управление DLE
|
||||
- Участие в голосованиях
|
||||
- Просмотр истории транзакций
|
||||
|
||||
#### 4.1.2 Межприложное взаимодействие
|
||||
- Встраивание интерфейсов других DLE
|
||||
- Безопасное подписание транзакций
|
||||
- Проверка прав доступа
|
||||
- Аудит действий
|
||||
|
||||
#### 4.1.3 Мульти-чейн интерфейс с single-chain governance
|
||||
- Выбор целевых сетей для деплоя DLE
|
||||
- Отображение предсказанного адреса DLE
|
||||
- Расчет стоимости деплоя по всем сетям
|
||||
- Мониторинг статуса деплоя во всех сетях
|
||||
- Выбор governance сети для создания предложений
|
||||
- Установка таймлока инициатором предложения
|
||||
- Подписание предложений токен-холдерами в governance сети
|
||||
- Мониторинг исполнения в целевых сетях
|
||||
- История операций и голосований
|
||||
|
||||
### 4.2 API и интеграции
|
||||
|
||||
#### 4.2.1 Внешние интеграции
|
||||
- Оракулы для внешних данных
|
||||
- Интеграция с DeFi протоколами
|
||||
- Поддержка различных блокчейнов
|
||||
- API для внешних приложений
|
||||
|
||||
## 5. Этапы разработки
|
||||
|
||||
### 5.1 Этап 1: Базовая функциональность
|
||||
- Создание основного контракта DLE
|
||||
- Интеграция ERC-20 токенов
|
||||
- Базовая система голосования с настраиваемым кворумом
|
||||
- Простые казначейские функции
|
||||
- CREATE2 Factory для детерминистического деплоя
|
||||
- Настройки времени голосования (период, задержка)
|
||||
|
||||
### 5.2 Этап 2: Расширенная функциональность
|
||||
- Система мультиподписи
|
||||
- Отдельный модуль TimelockController с настраиваемыми параметрами
|
||||
- Коммуникационные функции
|
||||
- Модульная система
|
||||
- Мульти-сетевой деплой в тестовых сетях
|
||||
- Базовая cross-chain синхронизация
|
||||
|
||||
### 5.3 Этап 3: Мульти-чейн архитектура
|
||||
- Полная cross-chain синхронизация токенов
|
||||
- Система голосования с выбором сети
|
||||
- Cross-chain операции с откатами
|
||||
- Мониторинг состояния во всех сетях
|
||||
- Emergency pause и fallback механизмы
|
||||
- Иерархическая система голосования между DLE
|
||||
|
||||
### 5.4 Этап 4: Межприложное взаимодействие
|
||||
- Встраивание интерфейсов других DLE
|
||||
- Безопасное cross-chain подписание
|
||||
- Оптимизация газа для мульти-сетевых операций
|
||||
- Интеграция с bridge протоколами
|
||||
- Расширенное тестирование мульти-чейн функций
|
||||
|
||||
### 5.5 Этап 5: Аудит и запуск
|
||||
- Профессиональный аудит всех компонентов
|
||||
- Аудит мульти-чейн безопасности
|
||||
- Тестирование в различных сетевых условиях
|
||||
- Исправление уязвимостей
|
||||
- Финальное тестирование cross-chain операций
|
||||
- Развертывание в продакшн во всех целевых сетях
|
||||
|
||||
## 6. Требования к тестированию
|
||||
|
||||
### 6.1 Unit тесты
|
||||
- Тестирование всех функций контракта
|
||||
- Проверка граничных случаев
|
||||
- Тестирование безопасности
|
||||
- Проверка производительности
|
||||
|
||||
### 6.2 Integration тесты
|
||||
- Тестирование взаимодействия модулей
|
||||
- Проверка меж-DLE взаимодействий
|
||||
- Тестирование веб3 приложения
|
||||
- Проверка API интеграций
|
||||
|
||||
### 6.3 E2E тесты
|
||||
- Полный цикл создания DLE
|
||||
- Тестирование голосований
|
||||
- Проверка коммуникационных функций
|
||||
- Тестирование межприложного взаимодействия
|
||||
|
||||
## 7. Документация
|
||||
|
||||
### 7.1 Техническая документация
|
||||
- Описание архитектуры
|
||||
- API документация
|
||||
- Руководство по развертыванию
|
||||
- Руководство по безопасности
|
||||
|
||||
### 7.2 Пользовательская документация
|
||||
- Руководство пользователя
|
||||
- FAQ
|
||||
- Видеоуроки
|
||||
- Поддержка
|
||||
|
||||
## 8. Критерии приемки
|
||||
|
||||
### 8.1 Функциональные критерии
|
||||
- Все функции работают согласно требованиям
|
||||
- Система голосования функционирует корректно
|
||||
- Меж-DLE взаимодействие работает
|
||||
- Коммуникационные функции активны
|
||||
- CREATE2 деплой создает одинаковые адреса во всех сетях
|
||||
- Cross-chain синхронизация токенов работает корректно
|
||||
- Голосование с выбором сети функционирует
|
||||
- Мульти-сетевой деплой завершается успешно во всех целевых сетях
|
||||
|
||||
### 8.2 Критерии безопасности
|
||||
- Прохождение профессионального аудита
|
||||
- Отсутствие критических уязвимостей
|
||||
- Соответствие стандартам безопасности
|
||||
- Проверка всех сценариев атак
|
||||
- Безопасность cross-chain операций
|
||||
- Защита от MEV-атак при мульти-чейн операциях
|
||||
- Корректная работа откатов при сбоях синхронизации
|
||||
- Валидация кворума во всех поддерживаемых сетях
|
||||
|
||||
### 8.3 Критерии производительности
|
||||
- Оптимизация газа
|
||||
- Быстрая обработка транзакций
|
||||
- Масштабируемость системы
|
||||
- Стабильная работа под нагрузкой
|
||||
- Эффективная синхронизация между сетями
|
||||
- Минимальные задержки cross-chain операций
|
||||
- Оптимальное использование ресурсов во всех сетях
|
||||
- Быстрое восстановление после сбоев синхронизации
|
||||
|
||||
## 9. Лицензии и правовые аспекты
|
||||
|
||||
### 9.1 Используемые лицензии
|
||||
- OpenZeppelin - MIT лицензия
|
||||
- ERC-4337 - CC0 лицензия
|
||||
- Собственный код - Proprietary
|
||||
|
||||
### 9.2 Патентные аспекты
|
||||
- Низкий патентный риск для концепции DLE
|
||||
- Использование открытых стандартов
|
||||
- Защита уникальных функций
|
||||
- Консультации с юристами при необходимости
|
||||
249
docs/ai-queue-system.md
Normal file
249
docs/ai-queue-system.md
Normal file
@@ -0,0 +1,249 @@
|
||||
# Система очереди AI запросов
|
||||
|
||||
## Обзор
|
||||
|
||||
Система очереди AI запросов предназначена для управления нагрузкой на Ollama и обеспечения стабильной работы AI ассистента. Она предотвращает перегрузку модели, обеспечивает приоритизацию запросов и предоставляет мониторинг производительности.
|
||||
|
||||
## Архитектура
|
||||
|
||||
### Компоненты
|
||||
|
||||
1. **AIQueueService** (`backend/services/ai-queue.js`) - основной сервис очереди
|
||||
2. **AI Queue Routes** (`backend/routes/ai-queue.js`) - API маршруты для управления очередью
|
||||
3. **AIQueueMonitor** (`frontend/src/components/AIQueueMonitor.vue`) - компонент мониторинга
|
||||
4. **Обновленный Chat Route** - поддержка очереди в чате
|
||||
|
||||
### Технологии
|
||||
|
||||
- **better-queue** - библиотека для управления очередью
|
||||
- **Node.js** - серверная часть
|
||||
- **Vue.js** - клиентская часть
|
||||
- **Chart.js** - визуализация статистики
|
||||
|
||||
## Конфигурация очереди
|
||||
|
||||
### Основные параметры
|
||||
|
||||
```javascript
|
||||
{
|
||||
concurrent: 2, // Количество одновременных запросов
|
||||
maxTimeout: 180000, // Максимальное время выполнения (3 мин)
|
||||
afterProcessDelay: 1000, // Задержка между задачами (1 сек)
|
||||
maxRetries: 2, // Максимальное количество повторных попыток
|
||||
retryDelay: 5000 // Задержка между повторными попытками (5 сек)
|
||||
}
|
||||
```
|
||||
|
||||
### Приоритизация
|
||||
|
||||
Система автоматически определяет приоритет задач:
|
||||
|
||||
- **Администраторы**: +10 к приоритету
|
||||
- **Срочные запросы**: +20 к приоритету
|
||||
- **Чат**: +5 к приоритету
|
||||
- **Анализ**: +3 к приоритету
|
||||
- **Генерация**: +1 к приоритету
|
||||
- **Короткие запросы** (<100 символов): +2 к приоритету
|
||||
- **Долгое ожидание** (>30 сек): +5 к приоритету
|
||||
|
||||
## API Endpoints
|
||||
|
||||
### Получение статистики
|
||||
```http
|
||||
GET /api/ai-queue/stats
|
||||
```
|
||||
|
||||
### Добавление задачи в очередь
|
||||
```http
|
||||
POST /api/ai-queue/task
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"message": "Текст сообщения",
|
||||
"language": "ru",
|
||||
"history": [...],
|
||||
"systemPrompt": "...",
|
||||
"rules": {...},
|
||||
"type": "chat"
|
||||
}
|
||||
```
|
||||
|
||||
### Получение статуса задачи
|
||||
```http
|
||||
GET /api/ai-queue/task/:taskId
|
||||
```
|
||||
|
||||
### Управление очередью (только для админов)
|
||||
```http
|
||||
POST /api/ai-queue/control
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"action": "pause|resume|clear"
|
||||
}
|
||||
```
|
||||
|
||||
### Информация о производительности
|
||||
```http
|
||||
GET /api/ai-queue/performance
|
||||
```
|
||||
|
||||
## Использование в чате
|
||||
|
||||
### Обычный режим (без очереди)
|
||||
```http
|
||||
POST /api/chat/message
|
||||
```
|
||||
|
||||
### Режим с очередью
|
||||
```http
|
||||
POST /api/chat/message-queued
|
||||
```
|
||||
|
||||
## Мониторинг
|
||||
|
||||
### Компонент AIQueueMonitor
|
||||
|
||||
Компонент предоставляет:
|
||||
|
||||
- **Статус очереди**: активна, ожидает, пуста, ошибка
|
||||
- **Количество задач**: в очереди и выполняющихся
|
||||
- **Производительность**: успешность, среднее время обработки
|
||||
- **Детальная статистика**: общее количество, ошибки, время
|
||||
- **Управление**: пауза, возобновление, очистка (для админов)
|
||||
- **График производительности**: реальное время
|
||||
|
||||
### Интеграция в интерфейс
|
||||
|
||||
```vue
|
||||
<template>
|
||||
<AIQueueMonitor :isAdmin="userIsAdmin" />
|
||||
</template>
|
||||
|
||||
<script>
|
||||
import AIQueueMonitor from '@/components/AIQueueMonitor.vue'
|
||||
|
||||
export default {
|
||||
components: {
|
||||
AIQueueMonitor
|
||||
}
|
||||
}
|
||||
</script>
|
||||
```
|
||||
|
||||
## Ограничения и защита
|
||||
|
||||
### Rate Limiting
|
||||
|
||||
- **Ограничение по пользователю**: 10 запросов в минуту
|
||||
- **Размер сообщения**: максимум 10,000 символов
|
||||
- **Валидация**: проверка обязательных полей
|
||||
|
||||
### Фильтрация
|
||||
|
||||
- Проверка формата сообщения
|
||||
- Валидация ID запроса
|
||||
- Проверка размера сообщения
|
||||
- Контроль частоты запросов
|
||||
|
||||
### Слияние задач
|
||||
|
||||
- Объединение одинаковых запросов от одного пользователя
|
||||
- Обновление метаданных при повторных запросах
|
||||
|
||||
## Производительность
|
||||
|
||||
### Оптимизации
|
||||
|
||||
1. **Кэширование**: ответы кэшируются на 5 минут
|
||||
2. **Проверка здоровья**: мониторинг состояния модели
|
||||
3. **Ограничение ресурсов**: Docker контейнер с лимитами
|
||||
4. **Таймауты**: защита от зависших запросов
|
||||
|
||||
### Мониторинг
|
||||
|
||||
- Время обработки запросов
|
||||
- Успешность выполнения
|
||||
- Размер очереди
|
||||
- Количество ошибок
|
||||
- Статистика по пользователям
|
||||
|
||||
## Устранение неполадок
|
||||
|
||||
### Частые проблемы
|
||||
|
||||
1. **Медленные ответы**
|
||||
- Проверить размер очереди
|
||||
- Увеличить количество concurrent задач
|
||||
- Проверить ресурсы Ollama
|
||||
|
||||
2. **Ошибки таймаута**
|
||||
- Увеличить maxTimeout
|
||||
- Проверить состояние модели
|
||||
- Очистить очередь
|
||||
|
||||
3. **Высокая нагрузка**
|
||||
- Уменьшить concurrent задачи
|
||||
- Включить rate limiting
|
||||
- Добавить задержки между задачами
|
||||
|
||||
### Логи
|
||||
|
||||
```bash
|
||||
# Просмотр логов очереди
|
||||
docker logs dapp-backend | grep AIQueue
|
||||
|
||||
# Статистика очереди
|
||||
curl http://localhost:8000/api/ai-queue/stats
|
||||
|
||||
# Проверка здоровья
|
||||
curl http://localhost:8000/api/health
|
||||
```
|
||||
|
||||
## Настройка для продакшена
|
||||
|
||||
### Рекомендуемые параметры
|
||||
|
||||
```javascript
|
||||
{
|
||||
concurrent: 1, // Один запрос за раз для стабильности
|
||||
maxTimeout: 300000, // 5 минут таймаут
|
||||
afterProcessDelay: 2000, // 2 секунды между запросами
|
||||
maxRetries: 1, // Одна повторная попытка
|
||||
retryDelay: 10000 // 10 секунд между попытками
|
||||
}
|
||||
```
|
||||
|
||||
### Мониторинг
|
||||
|
||||
- Настройка алертов при высокой нагрузке
|
||||
- Логирование всех операций
|
||||
- Метрики производительности
|
||||
- Автоматическое масштабирование
|
||||
|
||||
### Безопасность
|
||||
|
||||
- Аутентификация для всех endpoints
|
||||
- Авторизация для управления очередью
|
||||
- Валидация всех входных данных
|
||||
- Защита от DDoS атак
|
||||
|
||||
## Разработка
|
||||
|
||||
### Добавление новых типов задач
|
||||
|
||||
1. Обновить функцию `getTaskPriority`
|
||||
2. Добавить обработку в `processTask`
|
||||
3. Обновить документацию
|
||||
|
||||
### Расширение мониторинга
|
||||
|
||||
1. Добавить новые метрики в `getStats`
|
||||
2. Обновить компонент `AIQueueMonitor`
|
||||
3. Добавить новые API endpoints
|
||||
|
||||
### Интеграция с другими сервисами
|
||||
|
||||
1. Подключение к Redis для персистентности
|
||||
2. Интеграция с системами мониторинга
|
||||
3. Подключение к лог-агрегаторам
|
||||
Reference in New Issue
Block a user