A Proposal for a Polygon ‘Fast Lane’ — 3/22/2022
(Last Updated 7/26/2022)
By Alex (AKA ‘Thogard’) / Business Partners Capital Research (‘BPCR’)
Summary:
The ‘Polygon Fast Lane’ (‘PFL’) is a protocol designed to reduce transaction spam, compensate participating validators, and improve network health by monetizing propagation bottlenecks in the p2p (peer-to-peer) layer of the Polygon blockchain. The protocol seeks to achieve this in a way that:
1. Does not censor any transaction.
2. Incurs no transaction delay beyond the limit of what is already possible.
3. Reduces the economic incentive for spam during the sprints of participating validators.
4. Does not facilitate transactions that cause overt harm to Polygon’s users (does not directly encourage ‘sandwich’ attacks or front-running).
5. Potentially reduces validators’ and searchers’ exposure to regulatory risks (relative to other MEV strategies).
6. Does not require validators to run custom code on their validator node (although running a small patch on their sentry (not validator) nodes is strongly recommended).
7. Does not require searchers to submit transactions to a private relay (although one may be provided for convenience in the future).
8. Potentially lowers the data transfer costs for validators and searchers.
9. Financially compensates participating validators.
Background:
Polygon is a Proof of Stake (‘PoS’) blockchain; the transaction inclusion and ordering is determined by special nodes called validators. The validator that will ‘mine’ (IE determine transaction inclusion and sequencing) a block is predetermined by the HEIMDALL layer and based on the ‘stake’ (IE the amount of the native token, MATIC, held in an escrow-like account that is potentially forfeited if misbehavior is detected). The larger the stake, the more blocks a validator will be assigned to mine. Block assignments come in sets of 64 blocks called sprints. The selected validator will mine 64 blocks in a row before another validator takes over.
The p2p (‘peer-to-peer’) layer of the Polygon blockchain is comprised of nodes (IE blockchain clients) that are each connected (IE ‘peered’) to a subset of all of the nodes that comprise the blockchain. While all validators and sentries are nodes, not all nodes are validators or sentries.
Spam is a serious issue on the Polygon blockchain. The origin of this problem can be traced to a line of code in the BOR code base:
https://github.com/maticnetwork/bor/blob/master/eth/handler.go#L623
(Note that this line of code is also present in GETH — this is not a Polygon-specific problem)
To summarize:
When a transaction is created and begins propagating through the p2p layer to reach the validator, at each node the transaction broadcast could follow one of two distinct propagation paths; it is either sent ‘directly’ to P(sqrt(peers) / peers) or it is ‘announced’ to the remaining set of peers. For the purposes of this abstract, it is important to know that ‘direct’ transaction propagation results approximately in a 500ms speed advantage over ‘announced’ transactions (on BOR clients that haven’t been modified). For example, if a searcher sends a transaction to a peer with a peer count of 100, there is a 10% (P(sqrt(100)/100)) chance that the transaction will be propagated directly and a 90% chance that it will be announced and therefore subject to the 500ms delay.
Although transaction priority inside of a block is initially determined by the value of the gasPrice* ** parameter, when a validator receives multiple transactions that have identical gasPrice values the transaction priority is determined chronologically — the first transaction received by the validator is placed first in the set of transactions with identical gasPrice values in a block.
*(Note: After EIP-1559, the parameters are ‘maxPriorityFeePerGas’ and ‘maxFeePerGas.’ For the sake of simplicity, we will use ‘gasPrice’ in their place.)
**(Note: This assumes no other MEV mechanism such as MEV-Bor is being run by the validator. As we discuss later, this is not necessarily a safe assumption.)
On Polygon, the majority of validator nodes are not ‘peered’ (‘peered’ means connected via the p2p protocol for the exchange of information such as transaction data) in the standard format. Rather than peering just any node, validator nodes often have only a few (or one) peers, called ‘sentries.’ These sentries connect to the standard number of peers via the p2p protocol and serve as a buffer between the validator nodes and the broader network. While they are an effective safety mechanism to prevent against DDOS-type attacks, they also act as a bottleneck: there is no route to a validator other than through its sentry. This bottleneck is significant. An example: imagine that Node A has a transaction that Node B does not have. Even if Node A does not directly propagate the transaction to Node B, Node B still has dozens of other peered nodes, each of which also might propagate the transaction directly to it. Validator nodes, however, don’t have other peers from whom they can receive direct transaction propagation. If the validator’s sentry does not propagate the transaction directly to the validator node then the validator node will be forced to receive the transaction via ‘announcement,’ thereby incurring the 500ms delay.
Two of the most profitable types of ‘arbitrage’ (‘arbitrage is a series of trades that generates profit while controlling for risk/delta) on the Polygon blockchain are ‘backruns’ and ‘liquidations.’ Both of these styles of arbitrage can have only one winner per opportunity created, but have multiple searchers (‘searchers’ are operators of MEV bots) competing for them. Furthermore, both of these styles’ opportunities are created by a transaction in the mempool: for backruns the opportunity is usually created by a large trade transaction sent to a DEX (IE decentralized exchange — an exchange on the blockchain itself) router contract, and for liquidations the opportunity is usually created by a price update transaction sent to a price oracle contract. The winner of the opportunity — and therefore the profit — is the searcher whose transaction is placed directly behind the transaction that created the opportunity.
Due to the randomness created by the ‘direct’ vs ‘announced’ propagation styles discussed above, the arbitrage transaction that lands directly behind the opportunity-creating transaction is not always the first one sent. Imagine a validator that has one peered node — its sentry node. That sentry node has 100 peers, one of which is the validator. In this hypothetical scenario, there are 3 nodes (including the validator’s sentry) in between the RPC node that receives the opportunity and the validator that sequences the transactions. Each of these nodes has 100 peers. Therefore, each node represents a 10% chance (P(sqrt(100)/100)) of ‘direct’ propagation and a 90% chance of ‘announced’ propagation and the ensuing 500ms delay. Not only does the searcher want their transaction to land at the validator as fast as possible, they also want their transaction to use the same propagation pattern as the opportunity-creating transaction* — if, while on its route to the validator, the opportunity-creating transaction is propagated directly by the first node, announced by the second, announced by the third, and propagated directly on the final hop from the sentry to the validator, then the optimal type of path for the searcher transaction would be to also have two directly-propagated hops and two announced hops. In other words, if the opportunity-creating transaction is delayed and the searcher’s transaction isn’t, then the searcher’s transaction will arrive too soon and not be profitable, but if the opportunity-creating transaction isn’t delayed and the searcher’s transaction is, then the searcher’s transaction will arrive too late and another searcher will have won the opportunity’s profit.
*(Note: We are aware that we are oversimplifying the statistics of propagation in the p2p layer in order to avoid unnecessary complexity. This is done to aid in understanding the root problem.)
The end result of this randomness is incentivized spam: if an opportunity presents with $1,000 in potential profit and with a transaction cost of only $0.01, and each of the searcher’s transactions has a 1% (hypothetical) chance of matching the propagation pattern of the opportunity-creating transaction, then the rational course of action for a profit-seeking searcher is to send multiple transactions. In fact, as the ratio of the profit to the cost of the transaction increases, the optimal number of searcher transactions also increases. This has led to situations in which over 1000 transactions from a single searcher have been observed for a single liquidation opportunity.
Mechanics Overview:
The ‘Polygon Fast Lane’ protocol will reduce the incentive for spam by removing the randomness from the direct vs announced propagation dynamic during the sprints of participating validators.
- After a set amount of time has passed (the ‘auction interval’), a new auction will take place on the PFL auction contract (on the Polygon blockchain).
- Each participating validator will have its own auction category.
- Inside of each validators’ category, searchers will be bidding on addresses that are known to create arbitrage opportunities, such as AMM/DEX routers or lending protocol oracle aggregators.
(Note: we refer to these pairs as ‘validator/opportunity pairs.’) - For example: there would be an auction for the pair of Validator A and the Quickswap Router*. This would be a distinct from the auction for the pair of Validator B and the Quickswap Router, which would likewise be distinct from the pair of Validator B and the Sushi Router.
(Note: a router is an on-chain smart contract and plays no role in the p2p layer of the blockchain. The router’s code is often used by validators when compiling trades. Detecting a transaction that uses a router’s code is often the first step in detecting an arbitrage opportunity.) - When a PFL sentry receives an opportunity-creating transaction, the node will propagate the transaction directly to the validator. Similarly, when a PFL sentry receives a transaction from the searcher that won that opportunity’s auction (in the current validator’s category) and if the searcher’s transaction’s gasPrice value exactly matches the gasPrice value of the opportunity-creating transaction then the node will also propagate the searcher’s transaction directly directly to the validator.
- All other transactions will be propagated via announcement and therefore have a 500ms delay.
- This will result in less spam on the network due to the ‘randomly direct or announced’ system being replaced with a ‘priority direct, all others announced’ system.
- At the end of each auction interval, the auction proceeds will be sent to each participating validator and a new auction will begin.
Diagram of the BOR p2p layer’s transaction propagation system for validators who participate in the PFL protocol:
Implementation — Validators:
Participating validators will need to reach out to the PFL team and be approved for participation. Once approved, participating validators will need to perform two actions:
1. The validator will need to peer their validator node to at least one PFL sentry node.
2a. The validator will need to modify their own sentry node(s) to block the random chance of directly propagating a transaction to their validator node. This is the removal of roughly 5 lines of code in the BOR code base. A patch (which we call the ‘Slow Lane’ patch) will be provided for them that can be run after updating to the most recent BOR version.
-OR-
2b. If the validator has no sentries of its own or hasn’t patched its sentries with the PFL ‘Slow Lane’ patch then the validator will have to make sure that the validator node’s only peers are PFL sentry nodes. If this is the choice selected by the validator, it is strongly recommended that the validator maintains a ‘stand by’ sentry that remains unpeered by the validator but that can be peered during periods of ‘Fast Lane’ node maintenance
NOTE: WE STRONGLY RECOMMEND 2A OVER 2B.
Upon completion of steps 1 and 2, participating validators will begin to receive proceeds from the ‘Fast Lane’ auctions.
Implementation — Searchers:
Searchers will need to bid and win the auction for the validator / opportunity combination that they wish to arbitrage. The auction will take place on the Polygon blockchain. A front end / website will be released shortly.
Once an auction has been won, no further action is required. Auction winners will submit their transactions to the mempool normally — the transactions will then be picked up and propagated by specially tuned PFL listener nodes. Auction winners who are having trouble propagating their transactions can reach out to the ‘Fast Lane’ team for assistance.
NOTE: We may incorporate a private relay for transaction submission in the future.
FAQ:
Q: Isn’t this just Flashbots on Polygon?
A: No. Although we are certainly inspired by Flashbots and its reduction of spam on the Ethereum blockchain, our mechanism of action is completely different. We handle the win/loss conditions further downstream (at the sentry level in the p2p layer, rather than directly at the validator level in the mining layer) which gives us a few key advantages but also some disadvantages.
Advantages:
1. No centralized bundle submission point.
2. Validators don’t have to run any custom software — no additional dev-ops hurdles other than installing the ‘Slow Lane’ patch on a validator’s sentry nodes.
3. Transactions that can harm users such as sandwiches and frontruns won’t be directly propagated in the ‘Fast Lane’ system due to searcher transactions only being eligible for direct propagation after the ‘Fast Lane’ node receives and directly propagates an opportunity- creating transaction. Furthermore, the ‘Fast Lane’ nodes will only propagate a searcher transaction if it has the same gasPrice as the opportunity-creating transaction. In other words, no searcher transaction with a higher gasPrice than the opportunity-creating transaction will be propagated directly.
(NOTE: There are many searchers who would say this is a disadvantage. Our top priority is Polygon’s users; so with that in mind, we candidly disagree.)
(For more information on this subject, please see the appendix re: sandwiches)
4. Validators and searchers will not be colluding to reorganize or resequence any user transaction and therefore not subject to the same degree of regulatory risk that MEV-Bor validators are exposed to from artificially rearranging the sequence of transactions for their own benefit. The ‘Polygon Fast Lane’ implementation can be viewed as bots paying extra to exclusively ‘co-locate’ on an exchange, whereas the Flashbots / MEV-Bor implementation allows validators to receive bribes for directly resequencing the transactions on the exchange itself.
Disadvantages:
1. Searchers will have risk associated with their bids — they will not know the exact value of the ‘Fast Lane’ access for the auction interval they are bidding because they will not and can not know in advance the exact value of the opportunities that the ‘Fast Lane’ will help them win. Instead, the searchers will have to estimate the value of ‘Fast Lane’ access based on past results, predicted traffic / volume, and other indicators. The PFL (Polygon Fast Lane) team plans to make public its performance tracking tools that should aid in calculating an estimated value per validator. Due to the risk of overbidding that searchers face and the downwards pressure we expect that risk to have on maximum bids, we expect validators to have less total revenue than they would receive from an MEV-Bor implementation.
2. Searchers will have to trust that validators won’t try to double-dip and run an MEV-Bor implementation on top of participating in the ‘Polygon Fast Lane.’ The visibility of a validator’s MEV profit metrics will be crucial for the functioning of an efficient auction so that searchers can accurately determine the value of an appropriate bid.
3. The ‘Polygon Fast Lane’ system will only work for arbitrage opportunities that were created by transactions in the mempool. ‘Top of Block’ opportunities will not be eligible for PFL propagation. It is important to note that although they are ineligible, they are also not a source of ‘spam’ on the network — the extremely high gasPrice values reached during a PGA (priority gas auction) precludes profitability when sending more than one transaction. This may be revisited in the future with a later implementation.
Q: Can PFL be used to censor transactions?
A: No. All transactions will still be received by all validators. We are not changing what the validators receive, we are only altering when they receive it. Furthermore, we are only adjusting the receipt timing inside of the boundaries that already exist in the system. Nothing will be delayed more than was already possible. Think of the ‘Polygon Fast Lane’ as a way to remove randomness, disincentivize spam, increase validator revenue, and reward efficient searchers.
Q: What if I win an auction but my bot takes longer than 500ms to send a transaction?
A: If a propagation issue is preventing you from making use of the ‘Fast Lane’ then we can help, but if your bot’s calculations take longer than 500ms then we suggest not bidding until you can speed up or otherwise alter your code. If your bot runs from just one node in Germany and the validator you’re bidding on is based in Singapore, our advice would be to set up another node of your own in Singapore. All we can offer you is 500ms — how usable/valuable that 500ms is depends on your bot/infra. Because of this, we expect the searchers with the best bots/infra who are already winning many of the current arbitrage opportunities to be able to bid higher than some of their slower competitors and therefore able to outbid.
Q: What if a searcher cheats the system by detecting an opportunity-creating transaction for an address they didn’t win, creates their own ‘bogus’ transaction with an identical gasPrice for an address that they did win, and then submits a backrun targeting the ‘bogus’ opportunity that is allowed through the ‘Polygon Fast Lane’ but is actually targeting the opportunity that they shouldn’t have access for?
A: We have safeguards in place to prevent this from happening, as well as background monitoring to detect it afterwards. That being said, searchers are a clever bunch and we don’t expect to be able to anticipate all of the ways in which they might maximize their own profit by gaming the system. If you see an example of someone winning opportunities that they shouldn’t, please report it to us. We will strive to prevent or block searchers from being able to ‘game’ or ‘cheat’ the system.
Q: How is the ‘Polygon Fast Lane’ funded?
A: To be determined… The infrastructure and maintenance costs will be extensive. Our default strategy will be to take a percentage of the auction proceeds to cover our expenses, but we would also be open to other alternatives such as funding from the Polygon team or other actors who don’t stand to benefit from preferential ‘Fast Lane’ treatment (but who wish to see the spam issue improved).
Q: If a validator wishes to keep its own sentry node peered to the validator node, what code change will it have to make?
A: The specific change is in the bor/eth/handler.go file beginning at line 481:
Existing Code:
for _, tx := range txs {
peers := h.peers.peersWithoutTransaction(tx.Hash())
// Send the tx unconditionally to a subset of our peers
numDirect := int(math.Sqrt(float64(len(peers))))for _, peer := range peers[:numDirect] {
txset[peer] = append(txset[peer], tx.Hash())
}// For the remaining peers, send announcement only
for _, peer := range peers[numDirect:] {
annos[peer] = append(annos[peer], tx.Hash())
}
Modified Code:
for _, tx := range txs {
peers := h.peers.peersWithoutTransaction(tx.Hash())// For all peers, send announcement only
for _, peer := range peers {
annos[peer] = append(annos[peer], tx.Hash())
}
A ‘Slow Lane’ patch will be provided to allow Validators to quickly and easily implement this change after each BOR update/upgrade. The PFL team will not maintain an independent BOR repo — instead, participating validators are encouraged to use the standard BOR repo provided by the Polygon team and to apply the ‘Slow Lane’ patch on top of the official version. Other than initiating the ‘Slow Lane’ patch on peered sentry nodes, the upgrade / dev-ops process for maintaining the validator and sentry nodes will remain unchanged.
*NOTE: If you are an aspiring searcher, for the love of all that is holy PLEASE do not treat this as an alpha leak and send all transactions directly to all your peers in an attempt to speed up your propagation. This will greatly slow you down and put extreme stress on the network.
Q: I’m a validator and I don’t understand any of that — can I still participate?
A: Yes, absolutely. The only prerequisites for participating are being able to install a patch (the ‘Slow Lane’ patch that we will provide for you) on your sentries and having your validator node add a PFL sentry or two as trusted peers. Running a validator node on polygon is extremely difficult relative to other blockchains — we’re confident that if you can keep your node online then implementing the PFL protocol will be a walk in the park for you.
Q: Who runs / controls the PFL sentries? Are they centralized?
A: The nodes are maintained by the PFL team. While the nodes themselves are centralized, the overall implementation of the PFL system is not centralized as long as validators maintain their own sentries running the ‘Slow Lane’ patch mentioned above. As long as that criteria is met, even if the PFL-run sentries were to crash, the network would continue to function just fine. Furthermore, the PFL sentries could not outright ‘censor’ any transaction even if they wanted to — such transactions would still make it to the validator node through the validator’s own ‘Slow Lane’ sentries.
TLDR: it depends on how you define ‘centralized,’ but regardless of which definition you choose we are far less centralized than any of the other MEV-revenue-capturing or spam-decreasing options.
Q: What happens if the PFL auction contract gets hacked?
A: We’ve designed the auction contract in such a way that it rarely holds substantial funds. Each new bid refunds the previous bidder, and at the end of each auction all the proceeds are paid out to the validators (minus the PFL fee to cover infra costs). We will use a proxy address so that if any flaws or vulnerabilities are discovered then we can fix them on the fly. If the contract is exploited then the validators won’t be able to get paid during that auction cycle, which is unfortunate, but we will identify the breach and the validators will be able to collect at the end of the next auction cycle’s proceeds per usual. In other words, in a single exploit nobody will ever lose more than one cycle’s worth of proceeds due to the frequency of the auctions.
NOTE: We do plan to open source our auction contract and include a percentage-based bug bounty equal to PFL’s fee for that auction period for white hats who demonstrate the attack on the blockchain. The bounty would be the same regardless of whether or not the white hat informed us ahead of time.
Q: Where can I see the code for the ‘Polygon Fast Lane’ sentry nodes?
A: At this time, the code is not available for public viewing. We wish to make it as hard as possible for clever searchers to game the system. That being said, if you want to see it, just ask us and we will probably add you to the repo.
(Update: Due to overwhelming feedback, there is a strong chance that we will, in fact, open source the PFL sentry nodes too.)
Q: Is this service similar to BloxRoute?
A: Although there may be some similarities in how we achieve our goals, the goals themselves are completely different. If anything, we are BloxRoute’s opposite in that we seek to achieve transaction differentiation by slowing spam down rather than speeding it up.
Q: Outside of reducing spam, does this have any other positive effects on the network such as reducing the frequency of reorgs?
A: While we cannot say until (lots of) additional testing has been completed, if you accept as valid the premise that mempool bloat (IE too many transactions floating around unprocessed in the mempool) is a contributing factor to reorgs then it stands to reason that increased adoption of the PFL protocol by validators would likely decrease the chance of a reorg occurring.
Q: Is the Polygon team aware of this project? Do they support it?
A: While the Polygon team is aware of this project, at this time they neither endorse nor condemn it — a stance they’ve taken on many MEV-based projects. We hope that at some point in the future they will publicly endorse it, but given their track record of silence on this subject we aren’t necessarily hopeful. If a validator is curious about participation, we advise them to privately reach out to the Polygon team and simply ask them.
Q: What if a searcher wins a bid for Validator B, who is Validator A’s backup, and then Validator A fails to create blocks during Validator A’s sprints? Does priority go to the searcher who won the auction for Validator A or Validator B? (or any other scenario regarding validators and their backups).
A: The PFL sentries will directly propagate your transactions to the validators for whom you won regardless of whose sprint it is. If Searcher A wins the bid for Validator A and searcher B wins the bid for Validator B, and Validator B is acting as backup for Validator A, then we will simultaneously send Searcher A’s transaction directly to Validator A and Searcher B’s transaction directly to Validator B regardless of whether or not Validator A has failed. Furthermore, we will announce Searcher A’s transaction to Validator B, and we will announce Searcher B’s transaction to Validator A. We are acutely aware that the primary / backup dynamic on Polygon can lead to complex outcomes such as reorganizations. To maintain a fair and level playing field, the PFL sentries will operate as if all validators are always producing blocks at all times. The PFL sentries will always directly propagate the appropriate searcher’s transactions to their respective validator regardless of whether or not that validator is actively producing new blocks.
Q: Can a searcher win more than one auction?
A: At this time we have no intention of applying limits on the number of auctions a single searcher can win.
Q: What happens if a searcher doesn’t have the funds they bid with?
A: Then their bid will not go through. We are aware of the OpenSea auction arbitrage strategy and do not wish to repeat it.
Q: What token / currency will the bidding take place in?
A: At this time, we intend for the bidding to take place in WMATIC, but are open to receive feedback and suggestions from validators and searchers.
Q: What happens if the searcher’s transaction arrives at the PFL sentries before the opportunity-creating transaction?
A: We have taken steps to greatly reduce the likelihood of this occurring. If this still happens, please reach out to the ‘Fast Lane’ team and we will work with you on modifications you can make to your own node to prevent it from occurring in the future.
Q: Are there any rules against a validator running MEV-Bor and participating in the PFL program simultaneously?
A: All participating validators must receive approval from the PFL team before searchers can bid on their ‘Fast Lane’ access. If a validator is upfront about usage of MEV-Bor, we will not exclude them from the auction. Our current plan is to include performance and profit metrics on the auction’s front end — these metrics will help identify validators that are running MEV-Bor, their own local bot, or anything else that eats into the value of ‘Fast Lane’ access. We are not necessarily against validators performing these actions — we just want to make sure that searchers are bidding with full information. In other words, as long as validators are honest and transparent about their other MEV strategies and searchers can price this information into their bids then we’re OK with it, too.
Q: Will searchers be able to peer directly with the validators whose auctions they win? Will the searchers know the validator enode / peer ID / IP address?
A: No, the searcher will not be directly peered with the validator nor will they have any way of figuring out the validator’s enode address, ip address, or peer ID.
Q: Well Akshually, this isn’t really MEV! The ‘Miner’ isn’t running any custom code!
A: That wasn’t a question ;) But you aren’t wrong… technically this is ‘SEV’, with the S standing for either ‘Sentry’ or ‘Speed’ — your choice. But we think this does fall into the category of ‘Maximal Extracted Value’
Q: Is there any cost for validators to participate?
A: Not only is there no cost, we expect the monthly data usage of the validator nodes to go down due to two factors: spam being disincentivized and fewer transactions being directly propagated (preventing the direct propagation of duplicate transactions). This is all in addition to the proceeds from the auctions that the validators will receive.
Q: Isn’t the PFL team composed primarily of MEV bot operators? How do we know that they aren’t running their own bot on the PFL sentries?
A: We aren’t, but we understand why searchers will want to verify that. Performance tracking and analysis will be crucial for both ensuring that nobody is taking unfair advantage of the system as well as for determining appropriate bids on each opportunity. In addition to reporting performance metrics on the website, the PFL team will open source its validator-specific profit tracking program so that searchers can independently verify the results. If a profitable opportunity is taken by someone other than the winner then that will show up in the tracking. Outliers will be investigated.
Q: What do participating validators need to do to collect their auction proceeds?
A: Absolutely nothing — at the end of each auction, the auction contract will automatically send the accrued WMATIC to each validator’s staking address (or another address of their choosing).
Q: Can validators participate privately?
A: Not exactly — in order to receive auction proceeds, searchers will have to know that a validator is participating before they can bid on that validator. The PFL team might be able to remove a participating validator’s information from our website, but the validator would still need to find a way to alert searchers that it is available for bidding.
If this is a concern for you, please reach out to the PFL team — we’ve got quite a few ideas on how to handle this and would be very appreciative of any feedback from privacy-focused validators.
Q: What happens if the PFL sentry nodes crash? Can the validators’ own sentry nodes still function even though they’ve been modified with the ‘Slow Lane’ patch?
A: Yes — in the event that the PFL sentry nodes all crash but your own sentry node does not, your validator node will still be able to function just fine. Every transaction that an unmodified sentry node would have received and propagated will still be received and propagated by your modified ‘Slow Lane’ sentry node. In other words, nothing will be censored even if the PFL sentry nodes crash.
Q: Can I have my BloxRoute gateway peered directly to my validator?
A: No, you absolute madman, although you can still have it peered directly to your modified ‘Slow Lane’ sentry.
APPENDIX — SANDWICHES
While ‘sandwich’ attacks will not be facilitated by the ‘Fast Lane’ protocol, they are not inherently blocked, either. Currently, Polygon transactions are subject to far fewer ‘sandwich’ attacks than Ethereum transactions due to a combination of the random transaction propagation on Polygon and the existence of the Flashbots protocol on Ethereum. To understand why this is the case, it’s important to understand an arbitrage concept called ‘leg risk,’ which is the risk created by the potential for net increase in delta exposure if one part (or ‘leg’) of a trade executes and another leg fails to execute*.
*(An example of ‘leg’ risk: you want to buy apples from your friend, Johnny, but Johnny will only trade his apples for oranges. You go to your Sally, who sells oranges, and spend all your money on oranges with the intention of using all of those oranges to buy apples. You then go back to Johnny, but while you were trading with Sally it turns out that Johnny sold his last few apples and now he doesn’t have any apples left to sell you. So you go back to Sally and try to sell the oranges back, but she tells you that oranges have dropped in price and she will buy them for only 50% of what you paid for them. Sally is the only person you know who buys oranges, so you accept the trade. Although you never meant to hold any oranges for any length of time, you were still exposed to the risk of the price of oranges decreasing due to the fact that you were unable to complete the trade and exchange the oranges for apples. That’s ‘leg’ risk.)
‘Sandwich’ attacks have leg risk: if the second transaction in the ‘sandwich’ is not successful then the attacker is exposed to potential loss if another searcher takes advantage of the price discrepancy created by the attacker’s first transaction. On Polygon, due to the randomness of propagation, an attacker cannot be certain that they will ‘win’ the opportunity (IE win the second transaction in the attack) and will therefore be hesitant to expose themselves to the risk assumed when sending the first transaction of the attack. On Ethereum, this risk is minimal; by including both transactions in a bundle and submitting that bundle to a Flashbots relay, the attacker can be confident that if they don’t win the second transaction then the first transaction will never take place.
The ‘Fast Lane’ will alter this dynamic in two ways. First, the ‘Fast Lane’ will allow an attacker to be more confident that they will win the opportunity. This decreases the leg risk the attacker faces and therefore increases the expected profit of a sandwich attack. Second, the ‘Fast Lane’ will chronologically separate the first sandwich transaction from the second by 500ms, which increases the chances of the transactions landing in separate blocks. This increases the leg risk the attacker faces and therefore decreases the expected profit of a sandwich attack.
The ‘Fast Lane’ team is currently considering four solutions to the ‘sandwich’ issue:
1. Do nothing — ‘sandwich’ attacks still have risk associated with them. While the attacks won’t be prevented, they won’t be encouraged either.
2. Attempt to identify attackers and revoke their ‘Fast Lane’ access. This will be made difficult due to the incentive for auction losers to ‘frame’ the winners, thereby leveling the playing field.
3. Identify all potential sandwich transactions at the node level and delay the first transaction in the sandwich until the next block. This will add significant processing delays to the nodes and will reduce the value of ‘Fast Lane’ access for all searchers, and will indirectly reduce validator revenue from auctions.
4. Run an optimistic anti-sandwich bot on all ‘Fast Lane’ nodes. This bot will detect and attempt to preemptively arbitrage against the first transaction in a sandwich prior to the block inclusion of the opportunity-creating transaction and the searcher transaction. While this option would discourage sandwich attacks and eliminate the ‘false flag’ problem from solution #2, it is unlikely this bot would remain profitable and we expect that continuing to run it would increase ‘Fast Lane’ operating expenses and eat into the validator revenue. Furthermore, we are aware that this is the least ‘decentralized’ of all the solutions.
The ‘Fast Lane’ team is open to validator feedback on this issue. No perfect solution exists — each strategy has strengths and weaknesses. Our plan is to educate validators on the options and their trade offs and then implement whichever strategy the validators prefer. If there is another strategy that you would like us to consider then please let us know.