Next Pylons Milestone: Scaling with No Gas Fees

Hello, Pylons community! It’s time to talk about the 2022 plan and how Pylons will expand the accessibility of the Cosmos ecosystem and blockchain in general. Let’s talk about spam, liveness, and the concept of gas fees.

Spam mitigation is one of the central challenges of the internet. From toxic comments to DDOS attacks, the world is full of people trying to engage with systems in ways the designers do not want and impact the experience of other users. Sufficient spam can threaten the liveness of the system, in addition to the quality of its data.

Blockchains have traditionally had constraints around spam prevention beyond the spam prevention constraints that web sites have. The increased fidelity of distributed consensus can be damaged if a spam-mitigation system can also be used for censorship. The techniques used on the broader internet, IP filtering, captchas, banning malicious accounts, are all vulnerable to being used in censorship. Part of the history of developing functional blockchains was finding a spam prevention technique that fit. So far, blockchains have been primarily designed to be financial systems. Every user coming into the system already has tokens, so requiring tokens to use the system doesn't add friction to real users. This scenario creates an opportunity to simply charge spammers to spam: gas fees.

Gas fees have a very strong liveness guarantee, meaning that the system continues to process transactions. It’s clear to everyone which transactions are paying the highest fees to be included, and it’s in the interest of miners and validators to include those transactions. A gas fee system is easy to administer without governance because everyone can see what should happen and whether it is happening. But gas fees have no fairness guarantee. In particular, as we see in the Ethereum community right now, rising usage and fees make the system inaccessible to the general public.

Pylons is fully accessible to the general public, so trading fairness for strong liveness is unacceptable. When it comes to mass-market products, a system made inaccessible by gas prices is not much better than a system made inaccessible by spam.

We know that accessible systems are possible. The web is full of accessible mass-market systems that are low-friction for new users, and the blockchain projects that become relevant to the future of the internet will be just as accessible. Throwing the mempool to the highest bidder has worked to an extent so far, but it’s not a long-term strategy. Systems choked with transactions, with spiking gas fees, are live in the sense that the validators are still making money, but they are not live in the sense of providing value to users.

So how do we do liveness better? The gas metaphor is designed to spike the cost to users during an attack, to match the difficulty the chain is having, so that actually taking the chain down takes too much money. Every chain has a limit on the amount of processing it can do, and if the chain charges enough for that processing power, the block space won’t run out. The core idea of gas fees is that by having people bid to get their transactions in, the most important transactions get included because people will bid higher for more important transactions. To actually choke the system, a spammer would have to spend an unreasonable amount of money. In practice, gas fee execution isn’t so clean. Gas prices on Ethereum are very high and unpredictable, driven in large part by people with a lot of ETH who are willing to pay prices that people with less ETH would not consider. The very wealthy can afford to have their transactions go through, and everyone else cannot. This transaction inequality is not a recipe for mass adoption!

In addition, non-financial systems like free-to-play mobile games do not expect users to already have money in the system when they first come to the product. Requiring users to go out and purchase a token before they can get started represents a substantial barrier to adoption.

The problem Pylons is trying to solve is the same problem that Ethereum and others are trying to solve. With a limited budget of processing space in the chain, we need to prioritize transactions so that the chain stays useful to everyone. But there are some things Pylons can do that Ethereum can’t do.

The biggest anti-spam advantage that Pylons has over Ethereum is its Turing-incompleteness. Because Ethereum has a full scripting language, a single transaction might take up the entire block or more, sometimes with an infinite loop. There’s no way to know how expensive a transaction will be without running the actual transaction (this is the Halting Problem). In the Pylons system, every transaction is simple and fast. We don’t have to worry that a few spam transactions could expand and take the system down.

However, we do have to worry about large numbers of useless transactions clogging up the block space. So how does a validator decide which transactions are worth including when most transactions have no fees?

Some transactions do have fees. Pylons is designed around freemium interactions and pays its validators with a percentage of the gross transaction volume of the network. A transaction that is a purchase has an associated fee and is likely to be included quickly in a block. But if a transaction doesn’t involve a payment, and therefore doesn’t get charged a fee, we have to decide how likely it is that the transaction will lead to a paid interaction in the future. What is the net expected value of the user making the transaction?

Has this user spent money before? Has this user interacted with an experience on which people tend to spend money? Is this user likely to be a human? Is this a new account? If so, is it being created associated with a particular experience on the platform? These are some possible prioritization strategies that still allow the system to be accessible to new free-to-play users while still having a robust defense against malicious spam.

Because Pylons is a Cosmos chain, blocks are proposed in a weighted round-robin fashion between active validators, so different validators can have different heuristics for what they propose for inclusion. This block proposal design gives transactions a greater chance to get included within a minute or so (although this time period may not be acceptable as a user experience anyway!) Having a lot of validators able to add transactions also increases the system’s censorship resistance and makes it less likely that the anti-spam systems will become censorship systems.

But these are all just ideas. We need to figure out what works in the real world. So Pylons is announcing the next step of the Pylons network development: an incentivized testnet to develop and test non-gas spam prevention technologies. Validators and developers that meaningfully contribute to the development of the next generation of blockchain spam defenses will be rewarded with ATOM and Bedrock, the Pylons mainnet native staking token. There will be challenges to take the network down and challenges to stay up under certain levels of attack. We’re looking for suggestions as to what other challenges to add. The games will begin in March 2022!

To get ready, join the official Pylons Discord at https://discord.gg/pylons. You can also come work with us, we are hiring devs for both Go and Flutter. You can start building a Pylons-based mobile experience right now using the Pylons SDK that is available at https://github.com/Pylons-tech/pylons_dart_sdk.

OK, that’s it! But here are some things to think about for the challenges:

• Is there a way to get tokenomics involved? Could stakers choose particular apps and experiences to support and increase the priority of transactions from those experiences? Could token holders sponsor new users in some way (this sponsorship would be a lot like fee grant systems.)
• Could we have optional systems to increase the likelihood of an account creation transaction being tied to a real person? Can we do this without leaking info on who the person actually is?
• What is the user experience for a transaction that is not included due to space limitations? Do we ask users to keep trying or retry automatically? Account creation is one of the most likely venues of spam attacks. Could we do a free in-app purchase (IAP) transaction on the app stores just to validate that an app store account exists and is connected?