POND – technical analys

Crypto, PREMIUM

Binance trade: https://www.binance.com/en/trade/POND_BUSD

TVK official page / hivatalos oldala: https://www.marlin.org/
CoinMarketCap: https://coinmarketcap.com/hu/currencies/marlin/

Entry point / Beszállási pont: 0.0900 – 0.1200

Our point of entry / A mi belépési pontunk: 0.1028
TP 1: 0.04508 (+1608 point)
TP 2: 0.05502 (+2602 point)
TP 3: 0.07774 (+4874 point)

TP 4: 0.12601 (+9701 point)

TP 5: 0.16718 (+13818 point)

The token model

Marlin separates the responsibilities of enacting policies from administering them just like the control and data plane of a software-defined network

POND

POND can be used to delegate to Marlin nodes and be incentivized for operating the relay network correctly

MPOND (or LIN)

You can lock 1 million POND to mint 1 MPOND and you can redeem 1 MPOND for a million POND

The bridge

Conversion from POND to MPOND or vice-versa is regulated by a bridge to ensure MPOND is minted judiciously

Key points

• Every Marlin node requires atleast 1 MPOND in delegations to join the network
• Only MPOND holders may make proposals or vote in the POND governance
• Conversion from POND to MPOND is instantaneous while the reverse involves a delay
• The maximum supply of POND is 10,000,000,000 and MPOND is 10,000
• Staking rewards for validators are paid in POND while FlowMint distributes MPOND
• Reward earned by a node is proportional to its propensity of being in a fast path

What does governance entail?

The DAO determines POND distribution amongst different blockchains

ProposeAnyone with 1 MPOND supply may table new proposals
DeliberateSufficient time allocated for a wholesome debate
VoteChanges require majority votes with ample participation

Flowmint

To ensure layer 1 platform communities have a say on an ubiquitous layer 0 network, a significant supply of POND has been allocated towards ecosystem growth

Bandwidth mining

The most integral actors of any protocol, POND is distributed amongst operators that provide services within the network

StakeDrop

MPOND will be distributed to layer 1 token holders against tokens locked in native staking mechanisms

Adoption

FlowMint incentivizes usage of Marlin by rewarding only those validators and delegators that install Marlin gateways

Design and analysis of a decentralized relay network∗
Marlin Labs†
January 30, 2019
Networks form the backbone of all peer-to-peer systems as hosts communicate with one another
via the Internet. Enterprises have long recognized the importance of networks in improving user
experience and productivity. As a result, a variety of techniques including the use of private lines,
CDNs and SD-WANs have been developed to provide better networking. Blockchains, however, rely
on the public internet which is generally modeled as an asynchronous, best effort communication
system, in which guarantees of reliable communication cannot be established. Since decentralized
systems can’t take advantage of the techniques mentioned earlier due to their centralized nature,
they accept the performance compromise imposed by the public Internet as a given.
In addition, block and transaction propagation in decentralized networks today is incentive incom-
patible as nodes that become aware of the information compete for the same payoffs. Babaioff et
al.[1] were the first to point this out for transaction propagation in Bitcoin. Using the success of
the MIT team in the DARPA Network Challenge as an example, they showed that once mining
rewards diminish, without additional incentives, it would be in the best interest of miners to keep
transactions they learn about private with the hope to eventually mine and claim the fees originat-
ing from them. Abraham et al.[2] pointed out that when a miner shared its mined block with its
neighbour, the neighbour had an incentive to not propagate the block further and take advantage
of the fact that it was amongst the first few miners who had learned about the block and get a
headstart in finding the next block1.
In this work, we present a secure way to enable decentralized systems to benefit from high-
performance relay networks without compromizing decentralization. We illustrate its incentive
compatibility and resistance to multiple attack vectors. Its benefits include higher throughput for
blockchain platforms, lower fees, faster finality and better performing decentralized cloud services.
In addition, several other use cases like its exploitation in decentralized exchanges are not beyond
imagination.
∗This specification is under active development and will be regularly updated.
†Web: www.marlin.pro, Email: info@marlin.pro
1Note that this issue is different from selfish mining where the miner himself has an incentive to keep the block
private.
1
CONTENTS
Contents
1 Motivation 3
1.1 Networking as a scalability bottleneck . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Block rate increase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Block size increase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Networking as a decentralization bottleneck . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Networking as a defense mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Selfish mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Race attack and Finney attack . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 The Marlin Network 8
2.1 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3 Packet propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.4 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Incentivization 12
4 Security 15
4.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Attack scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1 DDoS attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.2 Extortion and cartelization . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.3 Tax evasion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.4 Censorship against a miner . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.5 Eclipse attacks, Routing attacks, Partitioning and Blackholing . . . . . . . 18
4.3.6 Sybil attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.7 Stake reuse attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.8 Parent orphaning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2

MOTIVATION
1 Motivation
Networking forms the backbone of any distributed application. In this section, we look at the
current state of networking in the blockchain space, examine its deficiencies and describe a few
benefits that a high-performance incentivized networking layer can bring.
1.1 Networking as a scalability bottleneck
While various off-chain methods have been developed and are being actively worked upon to scale
blockchains, they face a couple of disadvantages today which include the requirement that parties
remain online to ensure that the other party plays fair (or pay a third-party to monitor the same),
large amounts of locked capital, formation of hubs leading to centralization of routing nodes, few
routes for high value transactions etc. Moreover, off-chain scaling solutions usually rely on on-chain
dispute resolution mechanisms. This means that the dispute resolution mechanism is limited by
on-chain throughput – it can be saturated with disputes thereby necessarily letting some disputes
go unresolved in favour of an attacker. The higher the throughput of the base chain, the tougher
and costlier it is to perform a successful attack of this kind.
Throughput. Throughput in the context of blockchains is the number of transactions per second
a blockchain can support (referred to as tps)2.
T hroughput = #T ransactions/Block × #Blocks/second
We essentially have two pathways to scale on-chain – increase the block size or increase the block
rate.
1.1.1 Block rate increase
Block rate. In Bitcoin, this follows the exponential distribution where the probability of a block
not being found for T minutes or longer is
P (T ) = e −T
tb
The number of blocks expected to be found in a certain time follows the Poisson distribution.
Thus, the probability of finding n blocks in T minutes is given by
P (n, T ) = ( T
tb )n ∗ e −T
tb
n! (1)
Propagation time. It is the time taken for a newly mined block to reach other nodes in the
network (usually represented for high percentiles like 95%).
Forks. Blockchain forks occur when two different but equally valid blocks (also called uncle/orphan
blocks) are produced at the same height. This leads to one of the blocks being eventually discarded
in favour of the other one. A good consensus mechanism incentivizes new blocks to be produced
on top of the most recent block. However, in distributed systems, the “most recent” block may
not be the same across the network leading to a fork.
Forks are bad for a blockchain because of two main reasons:
Wasted effort – Any effort which has gone into a discarded block is wasted and could have
been productively used elsewhere.
Transaction repudiation – Any transaction included in the discarded block is now effectively
rolled back even though it was seen in the blockchain by some participants. This is the
reason why we need to wait for n confirmations – to reduce the chances that the block with
our transaction is eventually discarded.
2Different systems have different concepts as a basis. For example, in Ethereum, it doesn’t make sense to
talk about transactions, rather, gas is a more fundamental quantity. For demonstration and simplicity, we use
transactions in the analysis.
3
MOTIVATION
Relationship between forks and block time. Using Eq (1) above, we get

P (f ork) = P (1, tp) + P (2, tp) + P (3, tp) + …

n=inf∑
n=1
( tp
tb )n ∗ e −T
tb
n!
= 1 − 1
e tp
tb
.
(2)
1 − e−x is a monotonically increasing function for x > 0. Thus, the probability of forks increases as
tb is decreased without correspondingly decreasing the propagation time T = tp. The propagation
time is a bottleneck toward higher block rates.
1.1.2 Block size increase
Decker et al.[3] show that a block size increase leads to higher propagation time. As a spam/DDoS
prevention measure, nodes need to verify any data that they receive before propagating it further.
With an increase in block size, the amount of data that the nodes need to verify increases leading
to higher propagation time.
Using the same analysis as in the previous section, we assert that networking (specifically, propa-
gation time) is a bottleneck to increasing the block size as well. An incentivized networking layer
can prevent spam/DDoS by introducing penalties thereby enabling additional optimizations in the
form of cut-through propagation in place of the current store-and-forward propagation.
1.1.3 Examples
Following is a brief description of some systems that could benefit by leveraging Marlin:
Tendermint. Tendermint’s Byzantine Consensus Algorithm relies on receiving at least 2/3 votes
from fellow validators in its pre-vote and pre-commit stages. These stages are governed by time outs
(assuming partial synchronicity) since in an unreliable network its hard to know whether messages
were lost or are delayed. A low-latency network like Marlin could allow systems like Tendermint
to decrease the value of the timeout parameter by a tenth and also decrease the number of rounds
required before blocks get committed by decreasing round failures due to network losses.
Throughput ∝ #blocks/second
∝ 1
avg time required for committing block
∝ 1
number of rounds per block(n) ∗ time per round
∝ 1
n ∗ timeout limit for pre-vote and pre-commit
Thunder Protocol The fast-path protocol uses an aggregate signature scheme3 to receive sig-
natures from at least 3/4 of the committee members. However, the fallback is a slow chain like
Ethereum. There’s no estimate of how often the fast path might have to fallback to the slow chain
and thus can benefit from a faster slow chain.
Algorand In the Byzantine Agreement consensus algorithm used by Algorand, block propagation
is parallelized with collection of soft-votes by propagating block hashes (which are much smaller
than the block themselves) separately. As a result by the time the block reaches every node in the
network, every honest node receives 2f+1 soft-votes with high probability. However, nodes have to
wait to propagate the cert-votes till they don’t receive the block. Algorand like Bitcoin uses gossip
to propagate blocks with verification carried out at every node to prevent spam. Increasing the
3Schnorr multisig requires 3 rounds with the discrete-log assumption.
4

MOTIVATION
speed of block propagation can thus decrease the duration of every period for every honest node
hence improving the system’s throughput.
Bitcoin/Ethereum Liveness and consistency in the Nakamoto protocol is subject to the mining
hardness being a function of the network’s maximum latency l which requires the block-time to be
significantly more than l. As shown in Eq. (2), to prevent forks tp has to be decreased. However,
the Bitcoin and Ethereum network today use gossip to propagate blocks over public networks
where the block is verified at each hop increasing the network propagation latency. Reducing tp
using a faster relay can lead to a proportional decrease in the value of tb.
Dfinity Dfinity’s consensus algorithm proceeds in rounds where each round involves: beacon nodes
broadcasting the source of randomness (VRF); blockchain layer nodes building and broadcasting
a block proposal from validated transactions via the Probabilistic Slot Protocol driven by the
random beacon output; notary nodes listening to block proposals, signing/notarizing the highest-
ranked block proposal and broadcasting it back to the network. The Marlin network can help in
bringing down the broadcast saturation times for each of the above steps resulting in faster block
times.
1.2 Networking as a decentralization bottleneck
We look at transaction propagation in the absence of a properly incentivized networking
layer.
Tragedy of the commons. Garrett Hardin explained the tragedy of the commons in his essay[4]
in the following way: “Picture a pasture open to all. It is expected that each herdsman will try to
keep as many cattle as possible on this commons. … Therein is the tragedy. Each man is locked
into a system that compels him to increase his herd without limit, in a world that is limited. Ruin
is the destination toward which all men rush, each pursuing his own best interest in a society that
believes in the freedom of the commons.”
Relayer bandwidth is a common resource. Computation, storage and bandwidth are common
resources used in blockchains. While computation has an incentiveized marketplace today, none
exist for bandwidth and storage4. As a result, blockchains today rely on the altruism of miners
and full nodes to relay blocks and transactions.
In the case of blocks, miners have an incentive to relay their blocks and receive the latest blocks in
order to prevent the blocks they mine from being orphaned5. However, they have little incentive to
proactively propagate blocks mined by the other miners. They are in fact incentivised to withhold
the block and propagate it only after they have mined a block on top of it. This not only saves
them from bandwidth costs but also gives them an edge with respect to the other miners.
Free-rider problem. A market failure that occurs when individuals prefer to let others make the
investment and yet have access to the benefits of the investment.
Transaction propagation is not incentivized. Transaction propagation is susceptible to the
free-rider problem where nodes would like to save bandwidth costs by not propagating transactions
and rely on others to do it.
Analysis. Consider a set of n full nodes. Each node i chooses a strategy of forwarding trans-
actions or not, represented by si ∈ Si = {0, 1}. Let S = ∏
i Si be the set of all possible
strategy profiles. Each node has a payoff function fi(s) for every strategy profile s ∈ S. Let
f (s) = (f1(s), f2(s), . . . , fn(s)). Given a game (S, f ) as defined among n full-nodes, we attempt to
analyze the Nash equilibrium, the condition under which it exists and its implications.
Let s−i be the strategy profile of all players except player i, i.e. s = (si, s−i). Let the utility that
node gets out of the blockchain platform be represented by ui(s). A node choosing to forward
transactions can only bring more utility to the blockchain platform, i.e.
ui(0, s−i) ≤ ui(1, s−i)
4Two competing proposals for storage rent exist and are summarized at
https://www.reddit.com/r/ethereum/comments/ab1n2e/eli5_storage_rent
5ignoring selfish mining
5
MOTIVATION
1.3.1 Selfish mining
Attack description. A selfish miner as described by Eyal et al[5] does not broadcast a block
it has mined and continues building on top of it privately until it finds a competing block being
propagated by honest miners. The scenario is parameterized by two variables – α, the percentage
of hash power controlled by the selfish miner and the γ, the percentage of honest miners that mine
on top of the block released by the selfish miner after observing that an honest miner has released
a block that competes with its withheld block.
Eyal et al deduce that for a well connected selfish miner with possibly several sybil non-mining
nodes across the world γ would nearly equal 1 as it could propagate its withheld block to the other
honest miners as soon as a node in its sybil-network received a block produced by a honest miner.
In such a scenario the blockchain system is not incentive compatible even when α is just greater
than 0. On the other hand, if γ is 0, a selfish mining pool requires control over atleast 1/3 of the
total hashing power in order to carry out an attack where it receives a revenue greater than its
relative size.
Countermeasure. Currently when there are two branches of the same height, the block that an
honest miner builds on top of is the one it received first. As a result latency and topology play
a decisive factor which can be exploited by a well-connected miner with sybils spread across the
globe. While the sybil nodes slow down the already slow gossip propagation of the block produced
by honest miners, caching of the block produced by the selfish miner ensures that it can be swiftly
delivered to honest miners across geographies. Marlin’s low-latency relay helps bring γ close to
0 by not relying on gossip to broadcast blocks through the network. A low-latency global relay
ensures that the honest miner’s block reaches different geographies before a sybil node aiding the
selfish miner can signal its private network to release the withheld block.
1.3.2 Race attack and Finney attack
Attack description. An attacker can send a transaction to only the merchant while create a
conflicting transaction that sends the amount to his own account and send it to the network.
It is more likely that the latter transaction gets included in the next block thus reversing the
merchants transaction. This attack only makes sense when the merchant accepts 0-confirmation
transactions. In a Finney attack, the attacker himself constructs a block having the conflicting
transaction and propagates it quickly across the network as soon as the merchant accepts its
original transaction7.
Vector76 attack. A Vector76 attack is like the Finney attack described above except that the
merchant waits for at least one-confirmation. In order to satisfy this requirement, the attacker sends
his privately mined block containing the transaction paying the merchant only to the merchant as
soon as he observes a block being propagated that contains it’s conflicting transaction (to prevent
the merchant from propagating the block containing the legitimate transaction) and quickly tries
to retrieve goods of equal value from the merchant based on the 1-confirmation.
Like before, this attack is especially easy when the merchant is not very well connected. Quoting
Gavin Andreesen – “If mybitcoin was running bitcoin behind Tor, and had just one connection
(through a Tor exit node) to the rest of the bitcoin network, then they’d be particularly susceptible
to this 1-confirmation attack.”8
Countermeasure. The usual precaution to deter such attacks is for the miner to avoid accepting
0-confirmation transactions or to disable incoming connections, choose specific outgoing connec-
tions9 and only connect to well connected nodes. A relay network like Marlin is a collection of
a large set of well-connected nodes. Given that most miners use it to receive and send transac-
tions and blocks, a transaction that wishes to make its way to block would be broadcast via the
Marlin network ensuring that merchants have a high chance of seeing the conflicting transaction.
Moreover, merchants could forbid direct communication and only accept blocks and transactions
7These attacks have been discussed with respect to Dice sites at several forums, for example,
https://bitcointalk.org/index.php?topic=145510.0 and https://bitcointalk.org/index.php?topic=327767.0
8https://bitcointalk.org/index.php?topic=36788.msg463423#msg463423
9https://bitcointalk.org/index.php?topic=79090.msg881283#msg881283
7
THE MARLIN NETWORK
2.2.1 Creation
What’s a relay node? A node that runs the Marlin relay node software can act as a Marlin
node. A good internet connection is sufficient to become a Marlin node. Commodity machines
these days running optimized overlay router software can process packets at a rate of 10 Gbps which
is sufficient for our use case. Nevertheless, optimized hardware for the same is also commercially
available11.
Listing a node in the Marlin Marketplace. The Marketplace is where the nodes and relay
networks advertise their characteristics. Users of the Marlin network can find a relay network of
their choice based on the characteristics, capabilities and price advertised at the Marketplace. A
node makes a AddNodeToMarketplace transaction to list itself in the Marketplace which contains
its IP address, median bandwidth, longitude, latitude and the public key corresponding to the
address with staked LIN.
Creation of a relay network. A node can create a CreateRelayNetwork transaction with details
of its capabilities – the protocols that it would like to serve like Ethereum), maximum number of
nodes it would allow to join, the minimum and maximum number of nodes it would enforce per
geographical region denoted by coordinates, the minimum stake it requires from member nodes,
the minimum configuration of the nodes (like bandwidth, CPU cores) and the minimum SLA it
would require constituent nodes to provide in their geographical location. Relay networks are
automatically listed in the Marlin Marketplace once created albeit with an inactive flag.
2.2.2 Management
Governance policies. The parameters in the CreateRelayNetwork transaction are ultimately
to be followed by all nodes in the relay network. While the node creating the relay network
initializes them, once other nodes join the relay network they ought to have a say in the network
too especially considering that requirements of users and the competitive landscape for the relay
network may change over time. Such changes to the relay network parameters require in-network
governance.
Nodes are allowed to create proposals to change parameters and only the nodes in the concerned
relay network are allowed to vote on it. While figuring the best governance mechanism may require
a few iterations, we would like to point out that the on-chain governance discussed here is not as
serious as the protocol related on-chain governance discussed widely elsewhere (and attacked for
being plutocratic[7, 8]). Minority nodes in this case have the flexibility to leave and create a
competing relay network if they feel that their proposals are more competitive. A competing relay
network is much less threatening to the functioning of the protocol than a forked blockchain.
Entry regulation. There are two ways a node can join a relay network. A relay network after
passing a majority vote (dictated by internal governance policies) can invite a node to join the
relay network through a RelayInvitation transaction which has an expiry period. The node joins
the network by sending a AcceptInvite transaction before the expiry of the invitation.
A node can also make a request to join a relay network through a JoinRequest transaction which
the nodes in the relay network can accept or reject based on a voting round the proposal for which
is created automatically if the specifications of the node meet the membership criteria laid out by
the relay network.
Exit regulation. Permissionless systems are susceptible to high churn rates which may have
disastrous consequences for a relay network as well as its users. Thus, unannounced exits by a
node are heavily punished to encourage graceful exits12. Every relay network sets a notice period

the minimum time a node must give a relay network before it exits. If a node exits unannounced
or before its notice period ends, its stake is repeatedly slashed for not meeting SLAs until its
stake reduces to nothing. Users can take into account the duration of the notice period as well
as the minimum amount of staked tokens mandated by a relay network before choosing to use
them.
11for example, https://netfpga.org/site/#/systems/3netfpga-10g/details/
12Godfrey et al[9] show that simply replacing a dead node by a randomly picked node followed by some advanced
strategies reduce the effects of churn for a P2P multicast overlay
9

THE MARLIN NETWORK
Nodes wishing to leave a relay network make a AnnounceExit transaction. If the relay network
finds a node to replace the node trying to exit, it can make a AllowExit transaction to allow the
node to exit before its notice period ends. In practice, the AllowExit transaction is automatically
made after a voting round on the proposal created by the AnnounceExit transaction. Nodes can
also create a ForceExit transaction against a node in the relay network. If the majority (dictated
by governance policies) believe that the node is misbehaving or should be kicked out for some
reason, the node is removed from the relay network.
2.2.3 Packet propagation
Setup. Miners, wallets and other users that use the Marlin Relay network integrate the Marlin
SDK which is responsible for interaction with Marlin nodes. The Marlin architecture is modu-
lar allowing protocol developers to write plugins to customize pre- and post-processing functions
and execute custom code for packets related to their protocol at Marlin nodes, full nodes or wal-
lets. This includes strategies on how to choose amongst the different relay networks – while some
protocols may choose to use only one relay network (insecure), others may randomly choose be-
tween any relay network available that meets a certain criteria while some others may hardcode
a list of relay networks to choose from using a probability distribution based on price and past
performance.
Block Entry. A verifiable unbiased source of randomness R is used to choose n relay networks
from those advertising the capability to serve the platform that a miner producing the block should
send the block to. R and n can be customized by the protocol designers if required as per their
security considerations. Once configured the Marlin SDK helps maintain connections with closest
entry nodes of the different relay networks.
Once a miner produces a block, he sends it to the relay network(s) chosen using R. He may or
may not have to pay a fee to the entry nodes of the relay network based on the following choice to
be made by protocol designers:
Protocol designers can require that a fee be paid by miners to cover the costs of block
verification at the entry node. This ensures that the griefing factor for DDoS attempts is low
since non-Marlin block producers cover the cost for block verification. However, this entails
an added delay – the time required to verify the block at first hop. Invalid signed blocks can
be used as fraud proofs (which can be optimized using off-chain compute systems) to avoid
stake slashing for not meeting SLA guarantees.
An alternative is to require miners to stake tokens. This allows the platform to eliminate the
step of block verification at the first hop and penalize the block producer if the block turns
out to be spam.
Block Traversal. The nodes in a Marlin relay network form a mesh network with multicast paths
optimized depending on the source. The packet loss rates, bandwidth and latency of the different
paths are constantly monitored to ensure that multicast delivery of blocks can be completed in as
little time as possible.
Details of incentivization techniques used to get nodes to forward packets to other nodes in their
relay network are elaborated in Section 3.
Block Exit. Miners subscribe to closest Marlin relay nodes to receive notifications about new
blocks and transactions. To prevent squatters a small fee is levied when initially subscribing.
A correctly configured Marlin SDK (by the protocol designers) will ensure that nodes do not
subscribe to relay networks from which they don’t hope to receive any further data due to lack of
publishers in that network. As soon as a Marlin node receives a new block it sends its hash to all its
subscribers. Subscribers wishing to receive the block notify the node by sending it a micropayment
which is followed by an exchange of bytes of the block. To avoid the added latency coming from
the Announce and Request model, nodes can directly push to a whitelisted set of miners and take
payments later.
10