Questionable concept. Some aspects of the platform the project wants app developers to take on. Little specificity and dubious solutions from the development team.

Overview

Mobile ad-hoc blockchains that allow groups of people who are not too far from each other to participate in joint activity without using outside coordination such as a server.

Social Media

Facebook: 24 subscribers

Twitter: 302 followers, 11 tweets

reddit: 34 subscribers, 6 posts

Medium: 83 followers, 7 posts

Telegram: 9003 subscribers (1159 deleted accounts, 6055 Recently, 1305 LastWeek, 484 LastMonth)

YouTube: a whopping 6 subscribers, but no videos yet

All admins have russian roots...

Also, very strange:

Team

The project's team revolves around three people: Martin Arrivets, Kevin Jones, and Giacomo Puri Purini. All three work at Mosaic Networks — the parent company of the MONET project.

Martin Arrivets and Kevin Jones worked at Clearmatics, which builds peer-to-peer infrastructure and decentralized automation. Clearmatics even has Vitalik Buterin himself as an advisor.

Those two people are developing the project's code, mostly Martin Arrivets. Kevin Jones made only a few commits on the Mosaic Network github.

Giacomo Puri Purini is presented as an entrepreneur with a successful exit under his belt. He launched a shoe-production project on Kickstarter (raised 60 000 pounds). A couple of sites list him as a cofounder of a Bitcoin startup in 2012, but we couldn't confirm that.

Advisors

Four advisors, including Mauro Martino - Head of Visual AI Lab at IBM, Mark Stuart Day - professor at MIT and the author of the book "Bits to Bitcoin: How Our Digital Stuff Works," Ronan Lynch - Bitcoin pioneer, Abdi Hersi - founder of Vidette and the Head of IT at Kazimir.

Naturally, none of the advisors mention any ties to this project in their social media accounts.

Whitepaper

Introduction

The WP authors say that the main problem of online services is centralization, which is a result of using the client-server architecture (specifically the server part). Blockchain technology allows services to avoid 3rd parties. However, current solutions do not use the full potential of blockchain technology.

To build a server-less mobile app, they need:

• Distributed Consensus: reaching agreement among a group of peers connected by a trustless network without reverting to a third party.
• Interoperability: enabling information exchange across consensus networks, online or offline.
• Peer-discovery: finding other peers to connect with based on location and activity.

MONET - open network architecture meant to turn all of the above into reality.

They are developing an open-source SDK that will allow developers to add blockchain consensus (Babble) into the app. The Babble blockchain is theoretically compatible with IBC (Inter-Blockchain Communication Protocols).

Their peer-discovery service is completely the responsibility of app developers.

MONET is made up of the MONET Hub (permanent master blockchain) and ad-hoc mobile networks that form local blockchains.

MONET Hub, in turn, is a smart contract platform, where anyone can deploy their programs.

Validators are rewarded for operating nodes and securing the Hub with a fee from transactions, payable in Tenom (the Hub's internal token).

Nodes

Node - any physical device with software installed (app with the Babble module) for participating in MONET. Their revolutionary achievement: they position as their distinctive advantage their support of off-the-shelf mobile devices.

Authors can make an SDK available for all mobile platforms (Android, iOS, and Windows Phone).

In practice, the MONET blockchain can work effectively when there are from 1 to 100 nodes.

Identities

Nodes are identified by their address: the hash of a public key, created with a asymmetric cryptosystem, whose private key is also controlled by the node.

To form or add to an ad-hoc blockchain, you need to know the addresses of its participants. This info is needed to:

• Know the exact number of nodes in the permissioned consensus system.
• Verify messages signed by other members using public key cryptography.

Programming Model

The platform is meant for server-less architecture. All of the network's participants communicate directly with each other via Babble, which distributed messages across the entire network and ensures consensus.

Babble SDK allows the developers to abstract away from unnecessary details and focus on business logic and UI.

SDK allows for storing any configurations in local storage — for example, peers.json, which contains the list of participants of the current blockchain (public key, IP:Port). The app and Babble both have the right to read and write into this file. The app initiates this list's creation, while Babble makes all the subsequent edits based on consensus.

To form a new ad-hoc blockchain, the initiator creates this peers.json file and writes himself into it. He will subsequently be able to receive requests for joining this chain via the app and to distribute this file to new participants.

App developers decide how to find new peers for this chain and how to distribute the file.

Consensus

Babble is a sort of DAG based on the Full Information Protocol (FIP).

They added a linear blockchain to a regular DAG. This allows them to implement any Inter-Blockchain Communication protocol.

Inter-Blockchain Communication

Challenges for Inter-Blockchain Communication:

• Input/Output operations - communication between the chain and the outside world - are non-deterministic and could undermine consensus.
• Data integrity - verifying that what was communicated passed consensus - needs to be preserved.

Ad-hoc chains can offer permanent and immutable information. Even after the chain's last node went offline, the saved blocks still contain data about the network's events. Such evidence is packed into a special format and forms the basis of the IBC protocol.

For Inter-Blockchain Communication, they use the IBC protocol. With its help, one chain verifies a transaction that took place in another chain.

Validators sign the hashes of blocks that are recursively hashed into a simple Merkle tree. It includes such info as:

• state-hash
• validators-hash
• transactions-hash
• previous-block-hash

To verify that a transaction took place in a certain chain, the retrieve block with that transaction is received and proof object is generated - IBC packet with a Merkle proof that this transaction is included into this block. Light-clients recursively check the Merkle proofs all the way to the block hash and make sure that the block obtained a majority of signatures from the validator set registered with the light-client upon initialization.

Light-clients can be implemented in smart contracts and deployed in blockchains. Each such light-client is initialized alongside the public keys of a remote blockchain validator.

For example, if we wanted to verify on chain B that a transaction t happened on chain A, we would implement a light-client for chain A in a smart contract deployed on chain B, initialized with the public keys of chain A validators. We would then submit an IBC packet for t to chain B, which would get gossiped and processed independently by each chain B validator via a call to the light-client. Changes to the remote validator set are communicated through IBC packets themselves.

Network

MONET nodes ae connected via TCP/IP. The three challenges for mobile P2P applications are:

• Peer-discovery: Supporting the discovery of local peers in a network where nodes may come and go.
• Mobility: Maintaining a mapping between identities and public IP addresses as peers roam around and change IP realms.
• NAT traversal: Working effectively even if nodes are located between multiple layers of NAT.

Contemporary P2P apps don't use a server for routing. However, because of the unstable nature of ad-hoc blockchains, MONET can't avoid using a server.

Then the authors talk about the difficulty of рeer-discovery in TCP/IP networks and describe the various types NAT traversal.

And, of course, to preserve MONET's spirit of decentralization, the team wants app developers to figure out the implementation of peer-discovery and NAT traversal for their apps on their own.

Hub

MONET Hub is always on the main chain, which forms the infrastructure of the network's first apps.

The Hub contains a number of independent nodes, controlled by validators. Validation uses PoS.

Each node in the Hub launches Ethereum Virtual Machine (EVM) alongside Babble, where they can create smart contracts.

Each validator also launches STUN and TURN servers to go around NAT and Babble consensus engine alongside EVM-Babble (wrapper for the EVM to work with Babble and their token, Tenom, in the context of MONET).

Anyone can become a validator in the Hub. Moreover, anyone can create their own Hub or use instead their own solution to support their own app. I.e., you can create your own Hub for internal use in your company or building.

Every operation involving a smart contract gets charged a fee to reward the validators.

To support the network, they will create the following smart contracts:

• ID directory (global identification system)
• Peer-Discovery (built-in register that lists the mapping of IDs and network addresses in the app)
• Light-Clients (template for registering Babble light-clients for ad-hoc chains)

Security

Babble consensus is susceptible to attack when 34% of nodes are malicious (like any other Byzantine protocol). It's a huge hit for the security of a network with few nodes.

For example, to hack into an ad-hoc chain with 21 smartphones, you only need 8 malicious ones. They can be infected with a virus or simply collude.

To solve this problem, they offer to significantly raise the threshold for joining the ad-hoc chain. Personal data can be tied to a global ID (MONET address). Users will be able to choose which information to share with each app. And app developers will have to decide which information to request form users for the proper and secure functioning of the app.

The Hub uses a PoS mechanism. Validators will lose their Stack if they commit fraud.

Alternative Networking: Mobile ad hoc Networks

Here they describe mobile device wireless connection modules: Wi-Fi, Bluetooth, LTE (somehow forgot about IrDA and NFC). They discuss the possibility of using these modules to create MONET ad-hoc networks. Unfortunately, none of the implementations they describe fits their project.

Use Cases

They want Uber to switch to their architecture. From what we understand, this would include the phones of all of Uber clients and drivers in a city into one ad-hoc network - and work without any servers.

The MONET made a true breakthrough by having their blockchain save all records and allow the tracing of all movements of funds (even among their many ad-hoc blockchains). therefore, MONET allows the creation of sharded cryptocurrencies. Naturally, they didn't forget about gamers. Game developers can use their framework to create apps.

Questions for the project

Q: In the Introduction section, you mention that MONET is an open network architecture that is meant to implement, among other things, peer-discovery. But you later state that the peer-discovery service is the responsibility of app developers. Why such inconsistency?
A:

Q: In practice, MONET blockchains will perform effectively with anywhere from 1 to 100 nodes. How did you arrive at 100 as the upper limit - did you perform practical tests of maximal upper limit?
A:

Q: Where are the ad-hoc chain blocks stored after the chain's participants go offline?

A:

Q: The peers.json file - seriously? File? No database or something else more than merely a file?

A:

Q: Very strange roadmap: 4 vectors for different projects. Why are Android and iOS library in the Monet Hub vector and not in the Babble SDKs one? Couldn't you make everything follow on vector (and split the responsibility between different parts within the company so the regular reader didn't have to struggle with figuring out what the project aims to do)?

A:

Conclusion

It's just a bare concept with a few demos and so-so code on github. But that's about it so far. The WP contains few technical details about how the system will work. Some aspects we had to think through and perfect ourselves to really understand them. They talk about being serverless, yet use servers to bypass NAT (even though they are launched on the validators in the main chain).

The implementation of peer-discovery and the bypassing of NAT are left to app developers, which will use this platform's SDK. They promise P2P, but de facto the connection will be via TCP/IP. Logically, the programs will be in a P2P network. Reminds us of a decentralized VPN service.

Verdict

Questionable!

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

Overview

Мобильные ad-hoc блокчейны, которые позволяют группам людей, находящимся на небольшом удалении друг от друга, участвовать в совместной деятельности без применения сторонней координации в виде сервера.

Social Media

Facebook 24 подписчика

Twitter 302 читателя, 11 твитов

reddit 34 подписчика, 6 постов

Medium 83 фоловера, 7 постов

Telegram 9003 подписчиков (1159 deleted accounts, 6055 Recently, 1305 LastWeek, 484 LastMonth)

YouTube подписчики есть (целых 6), а вот видео пока нет

Все администраторы с русскими именам и фамилиями...

Ну и это не совсем понятно:

Team

Команда проекта представлена тремя специалистами: Martin Arrivets, Kevin Jones, Giacomo Puri Purini. Все они работают в Mosaic Networks, проектом которого является MONET.

Martin Arrivets и Kevin Jones поработали в Clearmatics, в компании, которая занимается построением peer-to-peer инфраструктур и децентрализованной автоматизацией. Сам Vitalik Buterin числится в адвизорах Clearmatics.

Собственно они и разрабатывают код проекта, а точнее Martin Arrivets, Kevin Jones сделал только пару комитов на гите Mosaic Networks.

Giacomo Puri Purini позиционируется как предприниматель с успешным выходом. Запускал проект на Kickstarter по производству обуви (собрал 60 000 фунтов). На паре ресурсов есть информация, что он был ко-фаундером Bitcoin стартапа в 2012, подтвердить это не удалось.

Advisors

Четыре адвизора, среди которых Mauro Martino - Head of Visual AI Lab в IBM, MARK STUART DAY - лектор в MIT и автор книги "Bits to Bitcoin: How Our Digital Stuff Works", RONAN LYNCH - пионер Bitcoin, ABDI HERSI - основатель Vidette и глава IT в Kazimir.

Адвизоры, конечно же, в соц сетях с проектом себя не ассоциируют.

Whitepaper

Introduction

Авторы говорят о том, что основная проблема онлайн сервисов - централизация, которая является следствием использования клиент-серверной архитектуры, а именно серверной ее части. Технология блокчейн позволяет отказаться от использования 3-й стороны. Однако, в текущей ее реализации, она не раскрывает весь свой потенциал.

Для построения безсерверного мобильного приложения им необходимо:

• Распределенный консенсус: достижение соглашения между группой пиров, находящихся в недоверенной сети, без обращения к третьей стороне.
• Взаимная согласованность: возможность обмена информацией в согласованных сетях, online или offline.
• Peer-discovery: нахождение пиров для соединения, на основе местоположения и активности.

MONET - открытая сетевая архитектура, призванная все это воплотить в жизнь.

Разрабатывается open-source SDK, который позволит добавить в приложения блокчейн консенсус (Babble). Babble блокчейн теоретически совместим с IBC (Inter-Blockchain Communication Protocols).

Peer-discovery сервис целиком и полностью ложится на плечи разработчиков приложений.

MONET состоит из MONET Hub (постоянный мастер блокчейн) и ad-hoc (ситуативных) мобильных сетей, которые образуют локальные блокчейны.

MONET Hub в свою очередь - платформа смарт контрактов, где каждый может деплоить свои программы.

Валидаторы поощряются за оперирование нодами и безопасность Хаба комиссией с транзакций в Tenom (внутренний токен Хаба).

Nodes

Node - любое физическое устройство с установленным софтом (приложение с Babble модулем) для участия в MONET. Революционное достижение: отличительной чертой позиционируется поддержка имеющихся в открытой продаже (off-the-shelf) мобильных устройств.

Авторы могут представить SDK для всех мобильных платформ (Android, iOS and Windows Phone)

На практике, эффективная работа MONET блокчейна осуществляется при количестве нод от 1 до 100.

Identities

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

Для формирования или присоединения к ad-hoc блокчейну необходимо знать адреса его участников. Эта информация необходима по следующим причинам:

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

Programming Model

Платформа рассчитана на безсерверную архитектуру. Все участники сети общаются напрямую через Babble, который распространяет сообщения во всю сеть и обеспечивает консенсус.

Babble SDK позволяет разработчикам абстрагироваться от лишних деталей и сосредоточится на бизнес логике и UI.

SDK позволит хранить в локальном storage любые конфиги. Например peers.json, который содержит список участников текущего блокчейна (публичный ключ, IP:Port). Приложение и Babble оба имеют права на чтение и запись в этот файл. Приложение инициирует создание этого списка, а все дальнейшие изменения вносит Babble основываясь на консенсусе.

Для образования нового ad-hoc блокчейна инициатор создает этот peers.json и записывает в него себя. Далее он может получать запросы на вступление в чейн через приложение и распространять этот файл новым участникам.

Как будут находится новые пиры для этого чейна и как будет распространятся этот файл - решают разработчики приложения.

Consensus

Babble - это такой DAG основанный на Full Information Protocol (FIP).

К обычному DAG они прикрутили линейный блокчейн. Что позволит реализовать любой Inter-Blockchain Communication protocol.

Inter-Blockchain Communication

Челленджи для Inter-Blockchain Communication:

• операции Ввода\Вывода (коммуникации между чейном и внешним миром, не являются детерминированными и подрывают консенсус)
• целостность данных (проверка предмета коммуникации на успешное прохождение консенсуса)

Ad-hoc чейны могут предоставлять неизменную и перманентную информацию. Даже после того, как последняя нода чейна ушла в оффлайн, сохраненные блоки все еще содержат данные о событиях, которые произошли в сети. Такие доказательства упакованные в специальный формат составляют основу IBC протокола.

Для Inter-Blockchain Communication используется соответствующий протокол (IBC протокол). С его помощью в одном чейне верифицируются транзакции, которые произошли в другом чейне.

Валидаторы подписывают хэши блоков, которые рекурсивно захэшированы в дереве Меркла. Здесь хранится такая информация как:

• state-hash
• validators-hash
• transactions-hash
• previous-block-hash

Для подтверждения того что транзакция была произведена в определенном чейне, получается (retrieve) блок с этой транзакцией и генерируется proof object - IBC пакет (с пруфом Меркла, что эта транзакция входит в этот блок). Light-clients рекурсивно проверяют пруфы Меркла вплоть до хэша блока и проверяют, чтобы блок получил большинство подписей от валидатора, зарегистрированного в light-client при инициализации.

Light-clients могут быть реализованы в смарт контрактах и задеплояться в блокчейнах. Каждый такой light-client инициализируется вместе с публичными ключами валидаторов удаленного (remote) блокчейна.

Например для верификации в блокчейне B транзакции t которая произошла в блокчейне A необходимо:

• реализовать light-client для чейна A на смарт контракте, инициализировав с публичными ключами валидаторов чейна A и задеплоить его в чейн B
• отправить IBC пакет для транзакции t в блокчейн B
• этот IBC пакет будет распространятся по чейну B
• валидаторы чейна B будут обрабатывать этот пакет путем обращения к light-client(изменения в наборе верификаторов передаются через IBC пакеты)

Network

Ноды MONET соединяются по TCP/IP. Три челенджа для мобильных p2p приложений:

• Peer-discovery: Поддержка поиска локальных пиров в сетях, где ноды могут добавляться и удаляться.
• Мобильность: Обеспечение соответствия между идентификаторами и динамическими IP адресами пиров.
• NAT traversal: Эффективная работа, даже если ноды закрыты разными NAT.

Современные p2p приложения не используют сервер для маршрутизации, но вот незадача, из-за непостоянной природы ad-hoc блокчейнов MONET, без сервера обойтись не может.

Далее авторы рассказывают про сложность рeer-discovery в TCP/IP сетях и описывают разновидности NAT traversal.

И конечно же, чтобы сохранить дух децентрализации MONET, команда проекта предлагает разработчикам самим разобраться, как им реализовать peer-discovery и NAT traversal для своих приложений.

Hub

MONET Hub постоянно находится на главном чейне, который предоставляет инфраструктуру для первых приложений в сети.

В Hub входят множество независимых нод, управляемых валидаторами. Для валидации используется PoS.

Каждая нода в Hub запускает Ethereum Virtual Machine (EVM) вместе с Babble, где могут быть задеплоены смарт контракты.

Каждый валидатор также запускает STUN и TURN сервера для обхода NAT и Babble consensus engine вместе с EVM-Babble (враппер для EVM, для работы с Babble и их токеном Tenom в контексте MONET).

Любой может стать валидатором в Hub, кроме того, каждый может создать свой собственный Hub или использовать вместо него собственное решение для поддержки своих приложений. Т.е. можно создать отдельный Hub для внутреннего использования внутри своей фирмы или здания.

За все операции со смарт контрактами берется комиссия, вознаграждение для валидаторов

Для поддержания сети будут созданы смарт контракты:

• ID directory (глобальная система для идентификации)
• Peer-Discovery (встроенный реестр, в котором перечислены соответствия ID и сетевых адресов, расположений и приложений)
• Light-Clients (шаблон для регистрации Babble light-clients для ad-hoc чейнов)

Security

Babble consensus подвержен атаке при 34% зловредных нод, как и любой византийский протокол. Это очень большой удар по безопасности в сети, в которой мало нод.

Например для взлома ad-hoc чейна в котором участвуют 21 смартфонов достаточно 8 зловредных. Они могут быть заражены вирусом или же могут просто сговориться.

Для решения этой проблемы они предлагают значительно повысить порог для вступления в ad-hoc чейн. К глобальному ID (адрес MONET), можно будет привязывать персональные данные. Пользователи смогут выбирать какой информацией делиться с различными приложениями. А разработчики приложений должны будут решить какую информацию запрашивать у пользователей, для корректной и безопасной работы приложения.

На Hub используется механизм PoS. Валидаторы будут лишаться своего Stack при фроде.

Alternative Networking: Mobile ad hoc Networks

Здесь описываются модули беспроводного соединения, которые находятся на борту мобильных устройств: Wi-Fi, Bluetooth, LTE (почему-то забыли про IrDA и NFC), и возможность их применения для создания ad hoc сетей MONET. К сожалению не один из описанных методов реализации в этом разделе не подходит для их проекта.

Use Cases

Предлагают Uber заскочить на их архитектуру. Как мы поняли, приложение для Uber смогло бы включать в одну ad-hoc сеть все мобильные устройства клиентов и водителей из одного города или района, и работать без серверов.

Команда MONET совершила настоящий прорыв, их блокчейн хранит все записи и позволяет отследить все денежные передвижения (даже между множеством их ad-hoc блокчйенов). Следовательно, MONET позволяет создавать sharded критвовалюты. Ну и конечно же не обошлось без геймеров. Разработчики игр могут использовать их фреймворк для создания приложений.

Questions for the project

Q: В разделе Introduction вы пишете о том, что MONET - открытая сетевая архитектура, призванная реализовать, в том числе, peer-discovery, а дальше заявляете, что peer-discovery сервис ложиться на разработчиков приложений. Откуда такое несоответствие?

A:

Q: На практике, эффективная работа MONET блокчейна осуществляется при количестве нод от 1 до 100. Почему граничным количеством выбрано 100 нод? Проводились практические испытания?

A:

Q: Где хранятся блоки ad-hoc чейнов после того, когда все участники этого чейна уходят в офлайн?

A:

Q: Файл peers.json - серьезно? файл? ни база данных ни что-либо еще, просто файл?

A:

Q: Роадмап очень странный, 4 ветки для разных проектов. Почему Android,iOS library находятся в Monet Hub ветке а не в Babble SDKs? Неужели нельзя было все сделать под одним роадмапом с одной веткой, а уже внутри компании разделить ответственность, чтобы обычному пользователю было понятно к чему стремится проект?

A:

Conclusion

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

Реализация Peer-discovery и обхода NAT оставлена на совесть разработчикам, которые будут использовать SDK этой платформы. Вроде обещают p2p, а по факту соединение будет по TCP/IP, логически же программы будут находится в p2p сети. Очень похоже на обычный VPN сервис, только децентрализованный.

Verdict

Questionable!

Disclaimer: The above audit is not in any way financial advice or a solicitation to buy - it's merely our collective opinion that we are kind enough to share with you. Don't make us regret that.

The report is prepared in partnership with https://t.me/ico_reports

Our links:

• https://t.me/c1s0r
• https://twitter.com/c1s0r
• https://medium.com/@c1s0r
• https://steemit.com/@c1s0r
• https://golos.io/@c1s0r