POND – technical analys

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

  1. 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:
  2. Wasted effort – Any effort which has gone into a discarded block is wasted and could have
    been productively used elsewhere.
  3. 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
  4. 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

  1. 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
  2. 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
  3. 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
  1. 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:
  2. 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.
  3. 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

Share:

Facebook
Twitter
Pinterest
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *