SmokeSignal Scaling Plan

Hey High Fryers! Here I want to summarize the strategy we came up with to scale SmokeSignal (i.e. get around those insane Ethereum gas prices!). There’s a short term fix we’ll deploy quickly, and a longer-term strategy.

Short-term: xDai

First we’ll get SmokeSignal to support xDai. xDai is an EVM chain, which means we can very easily port the SmokeSignal contract to it, and the SmokeSignal interface should be able to easily interact with it using the same libraries. We’re still investigating that last ‘maybe’ - the elm-ethereum library we’re using is showing some age and might break down at this particular task. If we’re lucky it won’t be an issue, and we can get this out in as quickly as one week. In the worst case, we’ll have to dig into elm-ethereum and perform a long-needed upgrade, which could push it to around a month (more or less).

After this upgrade, users can choose whether to post to Ethereum or xDai. In comparison, xDai will be orders of magnitude cheaper and faster. But it won’t necessarily have the same security guarantees (can it be censored or attacked?), and it will also require a few more steps for the user to get it set up (setting up Metamask to use xDai as a custom chain, and getting some xDai in the first place).

Long-term: IPFSn Relayers, and the Relayer Swarm

In the longer term, there’s a more detailed and sustainable plan.

Alongside the current behavior of posting directly to an EVM blockchain like Ethereum or xDai, the user can post to a relayer. This will be a centralized server that accumulates SmokeSignal posts, and then regularly posts them as IPFS items and references these items on the blockchain in a final “batch post” of sorts.

Then, the SmokeSignal interface would load posts both from Ethereum event logs (this is the current functionality) as well as see IPFS references and load the posts from there.

By aggregating posts and “tethering” them in batches to the blockchain regularly, the relayer saves immensely on gas, while still essentially “publishing” them to all SmokeSignal interfaces in an uncensorable way.

The obvious downside is that the relayer is centralized, and thus vulnerable to attack. So, the plan is not to just create a single relayer, but treat it more like a prototype, for which a network will form - a relayer swarm. Any given relayer could have a profit model of some sort - perhaps advertising, perhaps charging users, perhaps funded via philanthropy. The idea is that many different relayers, all with different guarantees, reputations, and profit models, would pop up. Maybe some are on the darknet; maybe some are in Singapore; maybe ol’ Musky puts one on a satellite.

With this, we can achieve the best of both worlds: decentralized resilience with scaled costs to users. How is this resilient?

Firstly, an attacker would have to target and take out the entire relayer swarm. Although each relayer is centralized, the swarm is decentralized, and has no central point of failure.

Secondly, the effect of a successful takedown of the whole swarm (this will be a concern for the window of time during which our prototype is the only node in the swarm) is actually pretty limited. All the attack would accomplish is remove the cheapest, most user-friendly way of posting to SmokeSignal. All published posts would remain public, and any user with a burning need to post can still do so via the more expensive, direct Ethereum transactions currently supported.

In other words, we will treat the first relayer as somewhat disposable. It will do its job of listening for SmokeSignal posts tethering them to the blockchain, but one day a meteor might take it out - but the underlying SmokeSignal conversation will boldly remain. And ultimately, the relayer swarm will be too ubiquitous to stop.

It might seem overly hopeful to just trust that such a swarm will appear, but consider what a relayer is at its base: it’s just a device capable of signing transactions to Ethereum and posting things to IPFS.