The Marlin Development Trajectory

As a layer-0 protocol, Marlin strives to be simple to analyze while also flexible to meet the demands of different kinds of P2P applications. Due to the early phase of experimentation such applications are in, the requirements of and opportunities available to a base layer protocol gradually evolve over time. For example, while decentralized cloud services failed to gain traction in 2017, they saw an unexpected surge in interest this year expanding the domain of use-cases addressable by Marlin.

Nonetheless, an increasing set of requirements, be it due to an ever-expanding addressable market or higher security and performance demands shouldn’t be a hindrance for the usage of what’s already available. In fact, real-world deployments provide feedback that are unachievable via simulations. This article roughly outlines the launch and expected course of evolution of the Marlin network.

The spawn-net (completed)

At this stage of development, validators simply joined the network without any explicit promise of incentives. This provided us valuable feedback on incomplete documentation required to set up nodes, missing scripts required for installation, compiler version and OS specific errors. They also tested a simple Marlin integration with an Ethereum full node. Some even went ahead and developed custom tooling or extended support for new architectures (Raspberry Pi/ARM). 

As a whole, the network was pretty dumb doing nothing more than being a large-scale testbed for the clients software. It prompted us to develop a simple CLI tool to setup and manage relays. Setting up an ETH relay node for a Marlin node operator is now as simple as executing marlin relay create eth while validators can simply execute marlin gateway create eth to run a gateway. No longer do validators need to figure if there are one or more executables or if there’s a bridge etc. We expect to keep adding support for new chains, making the command tree more robust and exposing a HTTP API to make a configurable control plane over time.

The eggnet (completed)

The eggnet is an extension of the spawn-net where we sought introductions to experienced validators. This stage saw an influx of node-operators validating on several popular chains. In this stage, validators either run a cluster which is a set of 5-7 geographically dispersed nodes all by themselves or join an existing cluster as a relay node. A cluster, as expected, is considered to be a single trust unit which helps seed the network with good and honest connections for use later.

Given the eggnet continues to lack any crypto-economics or incentives while still expecting validators to put in quite a bit of effort to run a cluster, validators were explicitly informed about the existence of off-protocol rewards to join the network at this stage.

The spawn-net along with the eggnet gave us vital information about the choice of locations validators prefer to run nodes, the latency between such nodes and also the amount of effort validators are interested to put in. A network crawler, telemetry software and an explorer were developed to facilitate this process. 

The incentive structure

We’ve been subtly hinting about incentives in the previous two sections but haven’t elaborated on what they translate to. Since the next phase moves on to the introduction of crypto-economics in the system, it is worth taking a short detour to outline the incentive structure in the different phases and the thought process behind it.

The upcoming phase marks the introduction of tokens in the Marlin network. It allows existing token purchasers to interact with the system by using their tokens while also allowing those who do not have any tokens yet to earn them via active participation. However, the larvanet is still an experimental network. In order to test Marlin with a functioning token economy without putting undue risk on token purchasers, we propose the following incentive structure for the larvanet: 

1. Reward identifiable participants in the spawn-net and eggnet with around 5% of the total token supply. These tokens having been awarded for free do not impose financial costs amongst participants. On the other hand, due to their eventual fungibility with purchased tokens for use in the network, they are just as valuable.
2. Distribute tokens amongst validators and communities of different chains to give enthusiasts who weren’t a part of the spawn-net or eggnet an opportunity to participate in the network. We announced FlowMint as a step in that direction.
3. Sandbox existing token holders who purchased tokens by attempting to protect them from malicious attacks while still providing them an opportunity to participate in the network.

More details on the token design will be published in a later blog post with a goal to incentivize participation, distribute tokens amongst users and service providers in the ecosystem, ensuring sufficient economic security for the network to be useful and enabling rapid iterations on a real-world testbed while attempting to isolate token purchasers from any protocol-level flaws.

The larvanet (ongoing)

The larvanet marks the transition to an incentivized network. Clusters will be required to stake tokens to be able to join the network while being rewarded by both fees and inflationary tokens. This phase shall put our pot-based payment distribution scheme to the test which rewards clusters based on performance by assigning rewards from a central pot consisting of subscription fees paid by users and the staking reward allocation of Marlin tokens via a receipt based mechanism. The Cobb-Douglas utility function and stake-weighted cluster selection will be put to the battle.

Additionally, a significant portion of this stage will be focussed on building and testing integrations with different chains and applications. Consequently, different subscription mechanisms, utilities and tooling will be utilized. Simultaneously, FlowMint would incentivize validators of different chains to interact with the Marlin network. As a result, various staking utilities and toolings are also expected to mature at this stage.

Separate from the systems components, the governance portal will be live at this stage. Token holders will be able to tweak system parameters via governance proposals. Three kinds of proposals of particular interest, in our opinion, would be: 

1. Modifications to the staking reward schedule
2. Addition/removal of chains eligible for FlowMint and reward proportions thereof
3. Changes in sandboxing rules for existing token purchasers

The frynet

The frynet is geared towards stronger delivery guarantees and penalties against malice. Attestations proving the validity of blocks and transactions and slashing for spam is introduced in the frynet. Erasure coding along with multiple redundancy thresholds is also available for higher reliability. The network is also augmented to feature other use cases such as support for oracles, cache updates and other data streams. 

Development of purely decentralized slashing mechanisms against spam requires deployment of light clients of the various blockchains on Ethereum where Marlin’s smart contracts are. We are already working on one for Polkadot, are following Althea’s efforts in Cosmos and are excited on using the Rainbow Bridge in NEAR. We look forward to using these learnings to figure efficient solutions for other chains we would like to support that don’t have this on their roadmap (a list that’s fortunately shrinking with time).

The smoltnet

The smoltnet is focussed on reducing the barrier for node operators to run nodes and hence increase decentralization. It features in-cluster payments and introduces crypto-economics within the cluster to eliminate the existence of trust between the nodes in a cluster making them open and trustless. Trusted connections formed since the eggnet help secure this transition. The topology of clusters is more optimized in this phase thanks to data collected from the previous phases. 

The whalenet

Once the network is relatively decentralized, stable and performant, the whalenet emphasizes on adding support for multiple languages and async backends along with compatibility with different P2P protocols.  Moreover, incentive models for unicast are introduced with every node running a MarlinVM. Routing tables can be deployed dynamically on the VM to design networks with custom properties. The launch of MarlinVM takes the Marlin network to its zenith by allowing not just multicast relay networks but any kind of bespoke overlay network to be deployed on the Marlin network.

But, when’s the mainnet?

A fair question to ask! Marlin takes an approach of a progressive network deployment with new features added and system parameters updated with time, subject to governance. We think such an approach* makes most sense for a pioneering protocol within a fledgling ecosystem. Roughly speaking, the larvanet is when token holders and users can actively start participating in the network. We hope you are as excited as us and look forward to seeing you participate in the Marlin network!

Follow our official social media channels to get the latest updates as and when they come out! 

Twitter | Telegram Announcements | Telegram Chat | Discord | Website

* The approach suggested in this article is different than the usual incentivized testnet followed by a mainnet approach popularized by Cosmos. When incentivized testnet tokens guarantee a certain share in the mainnet and are traded in the form of IOUs, they become equivalent to the MPOND-POND barrier described in this article. We think this route (also seen in Livepeer) has certain advantages in terms of making the network live sooner, providing better control on economic security (like in Nexus Mutual) and encouraging early token purchasers to be active participants in the network. We hope this experiment would provide valuable inputs to other projects thinking about alternative rollout plans.