Shielding Our RPC Users From Data Intrusions and MEV

Kevin Dwyer

Kevin Dwyer

May 5, 2023

8 min read

In Brief

    mev.jpg

    Extracting data and value from users by any means necessary is a less than ideal business model for Web3 service providers, to say the least. After all, rampant data abuse was a contributing factor to Web3’s creation in the first place. However, Web3 service providers sometimes maintain a balance between serving their interests as a business and keeping their users' desires in mind. Ankr’s philosophy on this matter is straightforward – we provide services in a user-first manner in regard to pricing, products, and privacy. Our belief is that customer obsession and abiding by Web3 best practices will lead to superior products and outcomes for Ankr as an organization and Web3 as a whole.

    This article will break down Ankr’s position on protecting our users’ data and never exploiting it in practices such as MEV in our vital role in providing blockchain connections.

    TL;DR

    • Our Privacy Policy outlines our minimalistic, non-invasive approach to your data
    • Ankr collects only pertinent Personally Identifiable Information for paid users and has no method to correlate wallet transactions to IP addresses
    • Unlike some RPC services, Ankr never performs MEV on user transactions submitted through our RPC endpoints
    • Malicious forms of MEV can be damaging to Web3 ecosystems and shouldn’t be performed by trusted providers

    What Is Ankr’s Stance On User Privacy?

    Ankr prides itself on maintaining the highest standards of user privacy and security as a Web3 service provider.

    • Data Privacy: Ankr employs robust security measures and protocols to protect users’ data confidentiality.

    • Service Data Security: Ankr has implemented strong security measures designed to shield users’ Personal Information from unauthorized access, use, alteration, and disclosure. All information you provide to us is stored in a secure format on secure servers behind firewalls, and measures are in place to restrict the number of people who have access to it.

    • Data Retention and Lifecycle: Ankr minimizes the time we hold user data for the sole purpose of optimizing the performance of the service and platform. Ankr’s RPC system automatically deletes any and all Ephemeral Activity Data within 30 days.

    For service delivery purposes, Ankr does need to temporarily record IP addresses to set usage limits and monitor for denial of service attacks against our infrastructure. Though we do look at high-level data around the success rate of transactions made over the blockchain RPC, we do not correlate wallet transactions made over the infrastructure to the IP address making the RPC request. Thus, we do not store, exploit, or share any information regarding Personal Identifiable Information (PII), including wallet addresses. In accordance with our privacy philosophy, we store IP address data only as long as it is useful to fulfill its purpose in ensuring users receive the highest quality service possible. Additionally, unlike other RPC providers in the market, we feel it’s important to clarify that we do not perform any kind of MEV from our RPC service in any way.

    Ankr Never Uses Our RPC Service To Perform MEV

    Some RPC providers monetize your pending transactions by collaborating with bots who front-run and back-run your transactions. This can be a very negative experience for Web3 ecosystems and their stakeholders, as it can lead to widespread manipulation and distrust. We want all existing and potential users to know that Ankr never performs Maximal Extractable Value operations on endpoints.

    What’s MEV?

    The principles of MEV (formerly known as Miner Extractable Value) originated with Proof of Work networks such as bitcoin, hence the “miner” terminology. However, the term has expanded to Maximal Extractable Value as it has been shown to affect Proof of Stake networks just as well. Although PoS operates differently from Proof of Work in terms of block validation and consensus mechanisms, the opportunity for validator and full (RPC) node operators to extract value from transactions still exists.

    In the context of a Web3 RPC service provider, MEV refers to strategically manipulating the order and inclusion of transactions within a blockchain or using information obtained in advance to make or automate trading decisions ahead of time. MEV arises from the fact that miners, validators, or even RPC service providers have the power to determine which transactions are included in a block and the order in which they appear.

    In the case of a Web3 RPC service provider exploiting MEV, they could use their position to manipulate transaction order and inclusion for their benefit or the benefit of preferred clients. This can be done through practices like front-running, where the provider inserts their transaction ahead of others to gain an advantage, or back-running, where they delay certain transactions to ensure a preferred transaction is processed first.

    The Negative Effects of MEV: Rigging the Web3 Experience

    As an analogy, we can look at RPC service providers like dealers in a game of cards. Normally, the dealer should shuffle and distribute cards to players (RPC users, dApps, protocols) fairly and without knowledge of which cards each player will have in their hand. However, if the dealer begins to look at all the cards each player receives and uses that information to their advantage, things can quickly become unfair. For instance, if the dealer began placing bets on outcomes with advanced knowledge of what will happen (front-running), or ordering the cards to suit their interests exactly on time (back-running), the game will become rigged.

    Here are some of the main drawbacks of RPC providers performing MEV:

    • Unfair advantages: Front-running and back-running transactions can give RPC providers (or collaborators) an unfair advantage over everyday users of Web3 and DeFi protocols. They can manipulate the transactions to benefit themselves or their preferred clients, which may result in a loss of trust from the community and could discourage developers and users from participating in the ecosystem.
    • Price manipulation: By front-running and back-running transactions, a Web3 RPC service provider can potentially manipulate the prices of tokens and assets on decentralized exchanges. This could lead to market instability and create an environment in which ordinary users are unable to trust the prices they see on the platform.
    • Reduced security: Front-running and back-running transactions can lead to a less secure network, as they create incentives for miners and validators to collude with the Web3 RPC service provider. This could make it easier for bad actors to attack the network or compromise its integrity.
    • Inefficient service: Allowing a Web3 RPC service provider to front-run and back-run transactions can lead to an inefficient market where prices do not accurately reflect supply and demand. This can result in higher transaction fees, longer confirmation times, and reduced overall efficiency in the ecosystem.
    • Negative reputation: The exploitation of MEV by a Web3 RPC service provider could negatively impact the reputation of the Web3 ecosystem as a whole. It could make potential users question the fairness and security of the platform, which could slow down the adoption of decentralized technologies.

    How Do Some RPC Providers Perform MEV?

    Front-Running

    Front-running is a strategy very similar to the notion of “insider trading” in traditional markets. In this method, transactions are placed ahead of others to exploit upcoming changes. Full node and RPC providers could indirectly exploit front-running by monitoring the transaction pool. Here's how a bot in collaboration with an RPC provider could make a front-running attempt:

    • Monitor the mempool: They watch for profitable opportunities in the mempool, like large orders on decentralized exchanges.
    • Craft front-running transaction: When a profitable transaction is found, they create a new transaction that takes advantage of anticipated changes caused by the original transaction.
    • Set higher gas price: To prioritize their front-running transaction, they increase the gas price, incentivizing miners or validators.
    • Broadcast front-running transaction: They share the front-running transaction, hoping it's included before the original transaction in a block.
    • Sell or profit: After the original transaction executes and the asset price rises, they sell the asset at a higher price, profiting from front-running.

    Back-Running

    Back-running is a strategy where someone places a transaction immediately after another transaction to take advantage of the changes caused by the initial transaction. While full nodes and RPC providers don't have direct control over transaction inclusion and block creation, they can still attempt to exploit back-running opportunities indirectly by monitoring the transaction pool (mempool).

    Here's a step-by-step explanation of how a bot in collaboration with an RPC provider might attempt to back-run transactions:

    • Monitor the mempool: They continuously monitor the mempool to identify transactions that might create profitable opportunities. These could be large trades on a decentralized exchange (DEX), liquidations on lending platforms, or other actions that have a significant impact on asset prices or market dynamics.
    • Craft a back-running transaction: Once they identify a potentially profitable transaction, they craft a new transaction that takes advantage of the anticipated changes caused by the original transaction. For example, if the original transaction involves a large sell order that will push down the price of an asset, the back-running transaction might involve buying the asset at a lower price, expecting a rebound.
    • Set a higher gas price: To increase the likelihood that their back-running transaction is executed immediately after the original transaction, they set a higher gas price for their transaction. This incentivizes miners or validators to prioritize the back-running transaction over other pending transactions.
    • Broadcast the back-running transaction: They broadcast the back-running transaction to the network. Ideally, miners or validators would include both the original transaction and the back-running transaction in the same block or in subsequent blocks.
    • Profit-taking: Once the original transaction executes and the anticipated changes occur in the market, they can take profit from the back-running operation. They might sell the asset at a higher price or take other actions to capitalize on the expected price movement.

    Final Thoughts

    Performing malicious MEV as an RPC service provider is bad for Web3 and antithetical to the collaborative ethos on which Web3 ecosystems are based. Ankr is dedicated to providing a safe and private service to our users while always keeping our community’s best interests at heart.

    Join the Conversation on Ankr’s Channels

    Twitter | Telegram Announcements | Telegram English Chat | Help Desk | Discord | YouTube | LinkedIn | Instagram | Ankr Staking