сервис для частных обменных шлюзов viz-exchange: структура папок и файлов

Здравствуйте. Если не читали предыдущие посты, советую это сделать:
Часть 1, Часть 2

Этот пост больше напоминает документацию, но она тоже важна.

Структура файлов и папок, а также о коде в файлах проекта

1. В корневой папке находится основной файл exchange.js. Здесь подключаются модуль обновления информации об аккаунте update_accounts, модуль получения блоков blocks-generator и helpers – модуль с методами-помощниками (например, sleep приостанавливает выполнение на определённое время).
   Также здесь подключается methods – модуль с методами api и broadcast блокчейнов, trxdb – модуль, работающий с базой данных транзакций, conf – подключение config.json.
   Кроме того, на базе содержимого config файла составляется массив со списком блокчейнов; прописывается функция вызова метода, получающего блоки, в цикле блокчейнов – это позволяет работать с блоками всех добавленных блокчейнов.
   Функция workingTrx работает с транзакциями, добавленными в базу данных, и проверяет их наличие каждые 1,5 минуты.
   Ниже вызывается метод обновления аккаунтов из модуля update_accounts каждые 3 секунды.
   
2. package.json и package-lock.json – два файла, в которых прописаны используемые npm модули.
3. 500_ops_test.js – файл, в котором тестируется отправка 500 переводов в одной транзакции.
   Для его работоспособности необходимо изменить значения параметров login и wif (активный ключ) соответственно с name и 5k на свои значения.
   Код:
   

   
   var golos = require('golos-js');
   let login = 'name';
   let wif = '5k';
   let op = [];
   for (i = 0; i < 500; i++) {
   op.push(['transfer', {from:login,to:'denis-skripnik',amount:'0.002 GOLOS',memo:'viz:denis-skripnik'}]);
   }

golos.broadcast.send({
extensions: [],
operations: op}, [wif], console.log);

4. В папке databases после запуска шлюза находятся 5 баз данных: Golos_block.db, Steem_block.db, VIZ_block.db, Whaleshares_block.db и trxs.db. Первые 4 содержат последний/ие блоки соответствующих блокчейнов, а последняя – транзакции с переводом, которые необходимо проверить.
Структура баз данных блоков – это объекты, содержащие last_block со значением в виде номера блока и _id – уникальный идентификатор объекта в базе. База с транзакциями содержит номер транзакции, аккаунты отправителя и получателе перевода, сумму с токеном (например, "1,000 Golos") и memo.
5. Папка js_modules:
Покажу тут скриншоты основных файлов.
5.1. blocksdb.js – это файл, работающий с базой данных блоков. Здесь прописаны метод получения последнего блока (аргументами являются название блокчейна и номер последнего необратимого блока; если ответ будет пустым, происходит возврат), который называется getBlock, а также метод обновления объекта, содержащего последний блок (updateBlock).
5.2. Файл blocks-generator.js – сама генерация блоков.
Здесь подключается модуль x2y, в котором производится просмотр операций блока, а также работа с ними, если они являются переводами, и в memo нет определённых текстов, которые прописаны в условии; helpers – различные помощники (например, приостановка работы скрипта); methods – методы блокчейнов, bdb – файл работы с базой данных блоков.
Также прописаны константы LONG_DELAY и SHORT_DELAY, которые содержат значения 12000 и 3000. Они отвечают за длительность паузы в случае ошибки.
Ниже расположена функция generate с именем блокчейна в аргументах. Здесь происходит получение последнего необратимого блока, получение блока из базы chain_blocks.db (где chain – имя блокчейна), а также запускается цикл прохождения по блокам. Если в базе нет блока, цикл запускается от последнего необратимого, а если есть – от находящегося в БД.
Если во время цикла блок > необратимого, происходит приостановка на delay секунд и повторно вызывается получение параметров блокчейна. Если bn < необратимого, происходит проверка: если 0 < количества успешных операций, delay = 3000 мс, а иначе – delay = 12000. Также в этом случае номер блока увеличивается на 1, и происходит обновление в базе данных.
Весь код цикла обёрнут в try/catch. Если обнаружена ошибка (catch), она выводится на экран, и происходит приостановка цикла на 1 секунду.

5.3. helpers.js – модуль с методами-помощниками: unixTime (получение текущего времени в unixtime формате), sleep (приостановка), nowDateTime (получение текущей даты и времени в понятном строковом формате).
5.4. methods.js: вызывается config файл и происходит добавление библиотек блокчейнов по циклу. Кроме того, получается из config файла и устанавливается адрес паблик-Нод.
getOpsInBlock – получает операции в блоке, требует указания названия блокчейна и номера блока.
getAccount – для getAccounts. Принимает название блокчейна и один (не несколько) логин.
getProps – getDynamicGlobalProperties. Требуется указать только название блокчейна.
accountUpdate – обновление информации. Принимает название блокчейна, логин, активный ключ, memo (публичный ключ) и строку с сообщением информации об аккаунте.
transfer – перевод с использованием подписи транзакции и отправки при помощи api.broadcastTransactionSyncrenise. Требуется указать название блокчейна, активный ключ, логин (от кого), кому, сумму и memo.
getBlockHeader – используется для получения даты последнего необратимого блока без данных блока. Принимает название блокчейна, block_num.
getTransaction – получение транзакции: блокчейн, id транзакции.

5.5. transactionsdb.js – файл работы с базой транзакций. Содержит методы добавления транзакции, удаления, обновления и получения транзакции старше определённого времени. По поводу последнего: берётся текущее время, вычитается 90 секунд, указывается в методе получения списка транзакций старше этого времени.
5.6. update_accounts.js – модуль обновления информации в аккаунтах. Здесь подключаются модули helpers для вывода текущей даты и времени в нормальном виде, а также methods и config файл.
Единственный метод тут – это updateAccounts.
Перед ним формируется массив msg_strings, который содержит старые варианты строк (необходимо для сравнения с новым).
Далее происходит цикл в цикле – в первом и во втором происходит проход по блокчейнам, при этом второй цикл выполняется при каждой итерации первого.
В первом проверяется активный статус блокчейна, указывается токен, а также начала строк вывода информации о количестве токенов на балансе аккаунта и курсах обмена.
Во втором проверяется активность блокчейна, а также то, что он не совпадает с блокчейном из первого цикла.
Далее отображается курс токена блокчейна из первого цикла к токену блокчейна из второго цикла, название токена текущего блокчейна. Отображается информация об аккаунте шлюза блокчейна из второго цикла и записывается в переменную баланс этого аккаунта. Также записывается в специальную переменную значение комиссии, рассчитывается её величина в токенах, после чего эта сумма вычитается из баланса аккаунта. Затем итоговая сумма округляется до 3 знаков после запятой.
Также во втором цикле указывается строка для количества токенов на балансе аккаунтов с конкретными данными по текущему блокчейну, а также строка с курсом токена первого цикла к токену второго. Обе заканчиваются запятой (последняя убирается после дочернего цикла).
На этом второй цикл заканчивается, и происходит проверка на совпадения старой строки с новой. Если они отличаются, происходит формирование новой строки и её отправка в блокчейн.
В конце происходит очистка msg_strings с последующим добавлением текущих значений. Всё.

5.7. x2y.js – модуль, в котором происходит обработка блока:
Просмотр операций (функция processBlock). В ней происходит проход по циклу операций; если это перевод, проводится проверка, что имя получателя равно аккаунту шлюза, и что memo не содержит запрещённых строк (например, "return:", "токен не поддерживвается" и т.п.). Также перед циклом операций устанавливается счётчик ok_ops_count со значением 0. Он указывает на количество успешных операций и прописывается в return.
Если ошибок не выявлено, вызывается метод processTransfer, аргументами которого являются название блокчейна и содержимое перевода. Он возвращает 1, если операция успешна и 0, если нет. Это позволило вызвать функцию в значении счётчика ok_ops_count (ok_ops_count += processTransfer(x, opbody)).
В самом методе происходит работа с операцией: получение названия токена блокчейна-отправителя, назначение memo переменной и перевод memo в нижний регистр, после чего происходит создание массива, содержащего информацию до двоеточия и после него. Далее происходит проверка, совпадает ли первая часть (до двоеточия) с названием одного из блокчейнов в массиве chains, который формируется на базе config файла. Если да, производится дальнейшая работа над переводом, если нет – сумма возвращается отправителю с сообщением, что указанный им блокчейн не существует.
При совпадении первой части с названием блокчейна в списке происходит его указание в переменной y, а также получение из config файла названия токена этого блокчейна и установка значением переменной to логина получателя средств (вторая часть memo).
Далее производится расчёт курса токена блокчейна-отправителя к блокчейну-получателю, расчёт комиссии и происходит расчёт итоговой суммы.
После создания переменной let receive_approve, которая указывает на статус, происходит получение данных аккаунта, куда планируется отправить токены. Если массив с данными аккаунта не пуст и нет ошибки, устанавливается статус "ok", если он пуст – receive_approve равен "noAccount", если ошибка (catch) – "noConnection".
Далее происходит получение данных аккаунта шлюза, который будет отправлять токены, и проверяется баланс: если он меньше суммы, которую должен получить пользователь, receive_approve = "noBalance", если catch – "noConnection".
Далее проверяется, что блокчейн отправителя – это Golos или Steem. Если так, происходит проверка токена: SBD/GBG – возврат средств с сообщением о том, что токен не поддерживается (статус 'noSupportedToken').
Далее происходит проверка в условии статуса. Если ok, к сумме перевода добавляется название токена блокчейна-получателя, указывается memo об успешном переводе с указанием аккаунта шлюза, курса и комиссии.
Если статус "noBalance", "noSupportedToken", "noConnection" или undefined, "noAccount", происходит возврат средств с соответствующими им memo.
Также в каждом условии статуса происходит возврат числа успешных переводов (1 или 0). Это реализовано при помощи указания return перед методом sendTransfer.
Сам метод принимает блокчейн, активный ключ, логины отправителя, получателя, сумму и заметку (memo). Он находится выше и выполняет перевод, после чего проверяет, что возвратил метод трансфера. Если значение не 0, он получает текущее время в unixtime, добавляет в базу транзакций и возвращает 1. Если 0 – возвращает 0.
Статус того или иного перевода (ok, nobalance и т.п.), а также количество успешных операций выводятся в консоль.


## Всё.
Github: https://github.com/denis-skripnik/viz-exchange

Далее - о заявке в комитет и её обосновании.