In this post we analyse the benefit a cluster will get and how a rational cluster can decrease it's costs by sending the messages to few receivers. Assumptions Clusters are rational actors All clusters will act similarly Each cluster will try to send the messages to only a specified percentage of the receivers Clusters doesn't collude with receivers Receiver set is large enough compared to set size picked to ensure that probability of finding a malicious cluster is always same

This post provides a summary of the cluster based approach we are exploring for Marlin architecture. In this post we summarize the approach, assumptions, analysis and the lessons we learnt, issues we faced from the cluster based approach. Overview In this approach the network is divided into 2 parts The Core network The Fringe network Core Network Core network is the Marlin network that provides the SLA for sending the blocks from producers to consumers. Core network relayers form entities called clusters. A cluster consists of a group of relayers and acts as a single entity. Any misbehaviour or inability to meet SLA due to any of the relayers in the cluster will effect all the relayers in the cluster. Each cluster is also expected to be available and able to provide SLA across all the receivers.

Various approaches to prevent spam have been listed in specs. A more generic question on the same was also posted at https://research.marlin.pro/t/how-is-spam-prevented-in-marlin/42. Marlin splits blocks into erasure-coded chunks to ensure that blocks are propagated through the network despite the presence of malicious actors. As an individual relayer can't detect if a chunk is from a valid block just by looking at a single chunk, a malicious source may publish an invalid block which may spam the network. Staking or producer payments might be insufficient to thwart externally motivated actors. To ensure such malicious sources are penalized/make griefing costly, it is necessary to prove on-chain that the published set of chunks are invalid. A Naive way of solving this problem is to reconstruct the block from erasure-coded chunks on a smart contract and slash the source. This approach is limited by the amount of data smart contracts can handle. Current Gas Limit in Ethereum = 10 million gas Gas per byte of call data (Post EIP 2028) = 16 gas/Byte

As a project dedicated to securely optimizing data trasmission at the network layer, exploring prior work in the area is unsurprisingly of great interest to us. Unfortunately, while there's abundant work from the 2000s in the area of P2P networking and performant overlay networks (with a significant amount of seminal work coming from our colleague Prateesh's lab at MIT - Chord DHT and Resilient overlay networks being amongst a few), there's substantially much less research out there in the context of Byzantine environments. We suspect this to be the case due to the unincentivized nature of P2P systems during the pre-blockchain era. While certain anti-adversarial measures had been incorporated into systems like Bittorrent, there was never a billion dollar risk until Bitcoin and Ethereum came along. Fortunately, a particular area that we have identified, Wanets (Wireless Ad-hoc Networks) and Manets (Mobile Ad-hoc networks), have a close resemblance to incentivized P2P networks. Used for wireless communication in cases where there is poor internet connectivity (battlefields, disaster recovery) or low-latency requirements (vehicle-to-vehicle communication), wireless ad-hoc networks have attack scenarios similar to permissionless blockchains (imagine an oponent army or airplane evesdropping, manipulating or delaying its enemy's communications or a terrorist causing road accidents). We thus think that it would be interesting for the community to learn more about existing solutions to problems that slow down P2P communication or even worse, make them insecure. This series on byzantine-resistant networking protocols will feature some high-quality papers that we feel are relevant. In this post we are going to explore "ODSBR - An on-demand secure Byzantine resilient routing protocol for wireless ad hoc networks" by Baruch Awerbuch et al which appeared in ACM TISSEC, a pretty well regarded publication (above CCS for instance). We will start with a brief overview of ODSBR followed by the threat model, routing strategy and the suggested technique to detect malicious actors. We conclude by examining the guarantees provided and considerations of applying this method to blockchain protocols. What is ODSBR? ODSBR is an on-demand secure Byzantine resilient routing protocol for wireless adhoc networks. First let's break the name down and understand what it means. "On-demand" implies that the route from source to destination is not precalculated but is determined when necessary. This property ensures that the algorithm can work in situations where the network topology is not stable. Though the other side of the coin is that more resources and discovery time are required to find a route for every request.