Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[AIP-27][Discussion]Sender Aware Transaction Shuffling #109

Closed
thepomeranian opened this issue Apr 20, 2023 · 5 comments
Closed

[AIP-27][Discussion]Sender Aware Transaction Shuffling #109

thepomeranian opened this issue Apr 20, 2023 · 5 comments

Comments

@thepomeranian
Copy link
Collaborator

thepomeranian commented Apr 20, 2023

AIP-27 - Sender Aware Transaction Shuffling

Summary

Sender-aware shuffling enables the shuffling of transactions within a single block so that transactions from the same sender are apart from each other as much as possible. This is done to reduce the number of conflicts and re-execution during parallel execution. Our end-to-end performance benchmark show that sender-aware shuffling can improve the TPS by 25%.

Link to AIP: https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-27.md

@thlfranklin
Copy link

Asking from a research stand point: are there any analyses on how it changes the behavior / game theory and impact on MEV, for example?

@sitalkedia
Copy link
Contributor

@thlfranklin - Since the shuffling is deterministic and tries to preserve order of the transactions if they are not conflicting, it doesn't change any behavior around MEV - it is still possible for validators to submit transactions in a certain order to get the expected output ordering.

@thepomeranian thepomeranian added this to the aptos-node-v1.7 milestone Aug 30, 2023
@alnoki
Copy link
Contributor

alnoki commented Sep 7, 2023

@thepomeranian @sitalkedia

Does the sender have any input onto the shuffling process?

E.g. it sounds like this is a quasi MEV vector that allows a sender to stipulate shuffling in the absence of a validator override

@sitalkedia
Copy link
Contributor

@alnoki - The sender can't directly influence the shuffling process as it doesn't control what other senders will be included in the block. Validators (block proposers) on the other hand can of course propose a block to support MEV - this is true with or without shuffling.

@alnoki
Copy link
Contributor

alnoki commented Sep 8, 2023

The sender can't directly influence the shuffling process as it doesn't control what other senders will be included in the block

Got it, so I understand then that the term "sender aware" just means that shuffling is informed by the sender

Noting in this case for high-profile events like NFT drops, that senders trying to send in a bunch of bids will have unfavorable ordering, while actors who intentionally distribute bids across multiple accounts (e.g. one bot multiple senders) will be advantaged.

So this approach massages the block in order to make Block-STM have fewer collisions, but also introduces a new method for savvy actors to outcompete less savvy actors

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants