TODO(Setup): 1. gpu2 feature 2. ZFS for storage 3. RAID 0 of 2xNVME for chain storing 4. Fix GPU 5. Ensure remote connection to main router; configure loopback for remote LotusP2P address; add No/Announce fields for miner 6. Ensure remote to IPMI 7. Disable multithreading~in PC1 8. SSH keep-alive 9. Update BIOS for PC1

Цели (0/7) Оффлайн контакты с людьми Каждый человек с которым вы по обоюдному согласию сконнектились попадает в ваш список контактов Framework для приложений Своеобразный app store, аналогичный китайским приложениям. Нобис - база для воплощения сотен тысяч существующих, и новых идей в децентрализованной манере. Единожды попавший в базу контактов человек, моментально становится доступен на всех приложениях. В игре, в мессенджере или в любом коллаборационом инструменте. Первое наше приложение - поиск знакомств в оффлайне.

Во время глубокого изучения и продумывания описанного жизненного цикла Драйва, возникло множество важных для рассмотрения замечаний в первую очередь касающихся безопасности и стабильности системы. Конкретизируя, найденные сложности касаются каждого основного события в Драйве(Bulk, Download, Verify, Execute), в которых явно прослеживаются общие точки требующие дополнительных синхронизаций и проверок между репликаторами на уровне их протокола. Сам же документ нацелен на подробное описание этих точек. Проверка корректной исполнимости события Проблематика Для рассмотрение проблематики, возьмем за основу Bulk событие. Репликаторы в неопределенной последовательности обнаруживают появления нового Bulk события, запущенного владельцем на определенной высоте сети. По нынешней модели, каждый репликатор без каких либо проверок запускает выкачку изменений с владельца, не удостоверившись в том что другие репликаторы также получили событие с теми же параметрами => запустили выкачку на своей стороне корректно. Отсутствие проверок на старте выполнения событий и является корневой проблемой, которая может привести к неконтролируемым, а главное не обрабатываемым кейсам, уменьшая общее юзабилити. Примеры проблем На том же Bulk событии рассмотрим примеры описанных кейсов. Самым простым примером будет отсутствие подключения к одному или нескольким репликаторам, причем какая-то часть имеет связь с конкретным узлом, а какая-то нет. Подобный случай приводит к неравномерному распространению квитанций между узлам => вероятность прийти к консенсусу относительно квитанций во время следующего Bulk события непредсказуемо уменьшается. Помимо проверки подключений, каждому репликатору есть смысл сверять корректность входных данных с другими репликаторами перед стартом события, дабы не стать заложником недобросовестного валидатора, раз репликаторы в нашей системе не обязаны быть валидаторами. Другой неприятный момент - это неочевидность подобных кейсов, ведь сразу очень тяжело рассмотреть все возможные сложности вызванные проблемами в соединение, или же несоответствия входных данных на каждом узле по любым причинам. Решения под кейс vs обощенное решение

The document provides a detailed analysis of the current SC layer status. It precisely describes observed obstacles for development continuance and suggests a high-level development plan for resolving them. Current Barriers Pervasive Storage Dependence Most parts of current SCs implementation internals are fully dependant on Storage. Considering its ongoing reimplementation to meet likely the final design, it is clearly seen that SCs internals are affected drastically. Still, the Storage and its components are the base and there is simply no sense in touching SCs core components, before finishing it. If most of the Storage components are not ready or at least not pending major changes, then the development of SCs would be redundant work. Unluckily, we already experienced that with the current implementation and a decent part of the existent work will be removed, because SC development was started too early - before Storage reached its final form. Unfinished Design SCs design has undescribed gaps that are necessary to assemble the whole picture for SCs. Filling them through the development process is not obvious and forces us to design solutions ourselves. Also, recently we've had our regular meeting with researchers where they mentioned their awareness of unresolved problems in SCs. We haven't gone into specifics, as we had a different main topic to discuss, but anyway they should confirm SCs incompleteness as well.