Внесення криптовалюти

Документ вимог до функції депозиту криптовалюти (PRD)

1. Огляд проекту
   Мета цієї функції — надати адміністраторам систему для управління кількома адресами депозиту криптовалюти та забезпечити динамічне призначення невикористаних адрес користувачам під час процесу депозиту. Адміністратори можуть завантажувати та керувати кількома адресами депозиту через бекенд. Коли користувач обирає відповідну криптовалюту, система призначить дійсну адресу з бази даних. Термін дії адреси депозиту може бути встановлений адміністратором.

Вимоги до функціональності системи:

• Адміністратори вручну завантажують адреси депозиту та керують кількома гаманцями.

• Коли користувач обирає криптовалюту, система випадковим чином призначить невикористану адресу з пулу дійсних адрес.

• Адреса депозиту буде призначена користувачу, і її термін дії встановить адміністратор. Після успішного депозиту або закінчення часу адреса автоматично звільняється для використання іншими користувачами.

• Після завершення депозиту баланс користувача автоматично оновлюється.

2. Функціональні вимоги

2.1 Завантаження та управління адресами гаманців
Опис вимоги:

• Адміністратори можуть вручну завантажувати кілька адрес депозиту криптовалюти через бекенд, підтримуючи основні криптовалюти та мережі.

• Адреси включають тип криптовалюти, мережу, адресу депозиту та термін дії.

• Адміністратори можуть обирати попередньо визначені криптовалюти та мережі з випадаючого списку, вручну завантажувати адреси та встановлювати їхні терміни дії.

• Термін дії для кожної адреси встановлює адміністратор (наприклад, 10 хвилин, 30 хвилин), щоб запобігти тривалому зберіганню невикористаних адрес.

• Вся інформація про адреси зберігатиметься у базі даних, і адміністратори зможуть переглядати статус та використання кожної адреси.

2.2 Призначення адреси та депозит користувача
Опис вимоги:

• Коли користувач обирає криптовалюту, система випадковим чином призначить дійсну адресу з бази даних для депозиту.

• Термін дії адреси встановлює адміністратор (наприклад, 10 хвилин). В межах цього періоду адресу може використовувати лише один користувач.

• Система визначить, чи отримано депозит на цю адресу, і після підтвердження коштів оновить баланс користувача в USD.

2.3 Правила зайняття адреси
Опис вимоги:

• Кожна адреса може використовуватися лише одним користувачем. Якщо адреса призначена користувачу, вона не може бути використана іншим користувачем протягом терміну дії.

• Система позначить адресу як "зайняту" і запобігатиме її вибору іншими користувачами.

• Якщо термін дії адреси закінчується і вона не використана, система автоматично звільнить її і позначить як "доступну".

2.4 Закінчення терміну дії та звільнення адреси
Опис вимоги:

• Система автоматично звільнить адресу після закінчення її терміну дії. Якщо адреса не використана, вона повернеться до статусу "доступна".

• Звільнені адреси повернуться до пулу адрес для повторного призначення наступному користувачу.

2.5 Моніторинг депозиту та оновлення балансу
Опис вимоги:

• Коли користувач ініціює депозит, система буде моніторити стан у блокчейні, щоб визначити, чи отримано кошти на адресу.

• Після підтвердження депозиту платформа конвертує суму депозиту у USD за поточним обмінним курсом і оновлює баланс користувача.

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

2.6 Запис та управління адресами
Опис вимоги:

• Система буде записувати використання кожної адреси депозиту, включаючи адресу, тип криптовалюти, мережу, статус, призначеного користувача, термін дії, час депозиту тощо.

• Адміністратори можуть переглядати статус кожної адреси (наприклад, зайнята/доступна) та історичні записи депозитів.

• Адміністратори можуть вручну керувати адресами, наприклад, видаляти або змінювати їхній термін дії.

2.7 Функції адміністратора
Опис вимоги:
Адміністратори можуть виконувати наступні операції на бекенд-дашборді:

• Створення адрес гаманців: вручну завантажувати нові адреси депозиту криптовалюти та асоціювати їх із криптовалютою та мережею.

• Встановлення терміну дії: встановлювати термін дії для кожної адреси депозиту та при необхідності динамічно його коригувати.

• Перегляд статусу використання адреси: переглядати статус кожної адреси, включаючи її зайнятість, термін дії та статус депозиту.

• Перегляд історичних записів депозитів: переглядати історію депозитів для кожної адреси для полегшення управління та відстеження.

2.8 Двофакторна автентифікація (2FA) для додавання, зміни та видалення адрес
Опис вимоги:

• Для підвищення безпеки будь-яке додавання, зміна або видалення адреси має проходити через підтвердження двофакторної автентифікації (2FA).

• Коли адміністратори додають, змінюють або видаляють адресу депозиту, система вимагатиме підтвердження 2FA.

• Підтвердження 2FA можна здійснити через SMS, email або додаток (наприклад, Google Authenticator).

• Операція буде виконана лише після успішного підтвердження 2FA. Якщо перевірка не пройдена, операції з адресами (додавання, зміна або видалення) не будуть дозволені.

3. Проектування системи

3.1 Дизайн кешу Redis
Дизайн кешу:

• Коли адресу призначають користувачу, система буде кешувати статус і термін дії цієї адреси.

Ключ кешу:

• Використовувати wallet:<address> як ключ кешу для збереження інформації про статус кожної адреси (наприклад, доступна, зайнята, закінчилася).

Термін дії кешу:

• Час закінчення дії кешу буде встановлений відповідно до терміну дії, визначеного адміністратором (наприклад, 10 хвилин). Після закінчення адреса буде видалена з кешу.

3.2 Моніторинг депозиту та робочий процес системи
Робочий процес моніторингу депозиту:

• Коли користувач обирає криптовалюту і ініціює депозит, система випадковим чином призначить дійсну адресу.

• Система встановить термін дії адреси, і вона може використовуватися лише одним користувачем у цей період.

• Система буде моніторити депозит через механізм прослуховування блокчейну.

• Після отримання коштів система підтвердить, що адреса належить користувачу, конвертує суму депозиту у USD за поточним обмінним курсом і оновить баланс користувача.

Процес звільнення адреси:

• Якщо термін дії адреси закінчується без використання, система автоматично звільнить її і позначить як "доступну".

• Звільнена адреса повернеться до пулу адрес для повторного призначення наступному користувачу.

4. Нефункціональні вимоги

4.1 Вимоги до продуктивності

• Система повинна мати високі можливості обробки одночасних запитів, особливо під час пікових часів депозиту користувачів, забезпечуючи швидке призначення, моніторинг і звільнення адрес.

• Система має забезпечити плавний досвід користувача під час процесу депозиту і уникати затримок, що можуть негативно вплинути на користувача.

4.2 Вимоги до безпеки

• Всі операції, пов’язані з адресами депозиту, повинні проходити через перевірки авторизації, щоб запобігти доступу неавторизованих користувачів до перегляду або зміни гаманців.

• Чутливі операції, такі як використання адрес депозиту та моніторинг депозитів, повинні бути зашифровані для забезпечення безпеки коштів користувачів.

• Процес депозиту, включаючи переміщення коштів і конвертацію курсу, має бути строго перевірений і зашифрований, щоб запобігти втратам коштів або помилковим операціям.

• Додавання, зміна та видалення адрес повинні підтверджуватися через 2FA для забезпечення безпеки управління адресами.

4.3 Масштабованість

• Система повинна підтримувати динамічне розширення, щоб легко додавати більше гаманців криптовалют і пулів адрес депозиту для обслуговування зростаючої бази користувачів.

Примітка:
Цей PRD призначений для допомоги у розумінні вимог. Зміст, наведений тут, є лише для довідкових цілей.