Inside Satellite: Architecture of a Registry

This is exactly what it will look like when we’re finished (Wikimedia Commons)

Previously we chatted about the basic principles and motivation behind the Melon Satellite subproject, and you were promised a more detailed description. Well, now we’re back to do just that!

By the end of this post you will have an understanding of Satellite’s general architecture, its components, and how they interact together. A quick warning that this piece is more technical than the last, but don’t let that deter you from giving it a read. :)

(Re)introduction to Satellite

Our previous article gives an overview of what Satellite is meant to accomplish. Broadly, the goal is the provide a permissionless registry of Melon modules.

Uplink: Module developer registers their module to Satellite, which acts as distribution; Downlink: Fund manager browses Satellite registry for modules to use in their portfolio

The project will ultimately be a user interface with the ability to register and browse third-party modules, along with auxiliary functions to interact with entries in the registry.

Concretely, the community effect of Satellite would be to ease interactions between module creators and module users (see diagram).

Global architecture

The subproject will have to consider and manage interactions between:

1. The client

2. The server

3. The blockchain

This sort of structure, especially the interplay of client and blockchain, is colloquially known as decentralized application (or DApp) architecture.

Though our application includes a server component, the core functions of the registry are completely independent of it, in the true spirit of decentralization. This means that our server could become the victim of a DDoS attack, but the Satellite registry will continue to work even while the server is offline!

Specifically, the server is more of a convenience component of the application; operations that need not interact with the blockchain are relegated to the server. This includes activities such as indexing the entries and making them searchable.

The diagram immediately below describes one aspect of information flow within the application.

Simplified data flow diagram for Satellite. Client creates entries by interacting with the contract on-chain (e.g. with web3.js). The server collects information about all entries from the contract, again on-chain. The server then provides a convenient index of the entries to the client. Note that the client could also produce this index on its own if it pleases; the server simply makes things easier by computing an index for all clients.

Component — Blockchain

The on-chain piece of Satellite is manifested as a smart-contract which provides functions that allow module entries to be registered, removed, edited and read, much like the CRUD operations of a database.

Satellite contract hosted on the blockchain. More methods may be added than the four described here, for convenience or for added functionality. The module {data} includes a URL and the creator’s address, though this will be expanded. The antenna on top is the interface provided by the compiled contract, which takes the form of an ABI.

The contract’s registry maps a module entry’s name to its associated data, such as a URL to access the module’s code (possibly hosted on IPFS).

Whether all data related to a module should be hosted on the blockchain, or only essential data, is something we are actively discussing. On-chain storage can become expensive and we want to keep the registry costless at scale, if at all possible.

Component — Server

As mentioned above, the server part of the application aims to collect data from the Satellite contract, and to thenredistribute this to clients in a more convenient form via an API. This means that the server needs to store the data it retrieves in a database, to avoid hitting the blockchain every time the client requests something.

The operations that take place on the server collate the Satellite registry data, providing a database that is more friendly for query and search tasks.

Moreover, if there is data that is not essential to the functioning of the registry that takes up a large amount of blockchain storage (e.g. long descriptions, module screenshots, etc.), we might store that on the server rather than within the Satellite contract itself, and the API would provide an access point for this data.

The server consumes data from the “contract ABI” required interface, using web3.js. It then stores the data in a database synced to blockchain events, and performs functions on the data to make it more digestible for a client. Finally, the server provides a REST API for clients to consume.

Component — Client

The client description for Satellite is less rigid than the server and contract, since there is the possibility to have multiple clients.

Client consumes both the contract ABI from the blockchain, and the REST API from the server. Clients can vary in form, but they should all allow the end-user to access the registry via their blockchain account (e.g. with web3.js), and display server-produced registry information on request.

Much as we can interact with the NPM registry through several official channels (npm CLI, and npmjs.com), or multiple unofficial channels (yarn CLI, and yarnpkg.com), we can leave open the possibility for similar alternative user interfaces.
These may be more suitable for specific situations, users, or could be an embedded Satellite client within an existing application.

This being said, we are developing an official client as part of a Meteor application, meaning the end-user will visually interact with the Satellite registry through a web3-enabled browser.

Putting it all together

So here we are at the conclusion. The part of the article where you see everything in one place, and think “wow, I could have just looked at this diagram instead of reading for 7 minutes. Thanks...”

Hopefully you’re not thinking that. Hopefully you now have a better understanding of Satellite; its purpose, its components, and the way they come together to help Melon module developers and fund managers relate.

The contract provides an application binary interface (ABI) to communicate with the web3-enabled server and client. The content of this communication differs between client and server by convention only; the client does not need to rely on the server to interact with the registry’s core functionality. The client consumes the API provided by the server, and decides how to represent the received data to users.

One small thing

Just as an addendum, please note that there is a prototype for a voting and reviewing mechanism within Satellite as well. It has been omitted from the present article, however, since it introduces design concepts that are not finalized, and are thus better left to another article devoted entirely to that subject.

Travis Jacobs — Developer at Melonport