Στο σκοτεινό δάσος: Μηχανική Εργασία DeFi Διαιτησία

1 Εισαγωγή -Μέσα στο σκοτεινό δάσος

Αργά ένα βράδυ, ο Dan Robinson, ερευνητής στην εταιρεία επενδύσεων Paradigm, είδε μια κλήση έκτακτης ανάγκης στο κανάλι Uniswap Discord.Δύοάλλος χρήστης, αλλά στο ίδιο το συμβόλαιο Uniswap, όπου φαινόταν ανεπανόρθωτα χαμένο.

Ο Ρόμπινσον, ωστόσο, είδε μια λάμψη ελπίδας. συνειδητοποίησε ότι ο καθένας θα μπορούσε να προκαλέσειburnλειτουργεί στο συμβόλαιο, μια δημόσια εντολή που θα ανάγκαζε το συμβόλαιο να απελευθερώσει τα παγιδευμένα tokens στο πρόσωπο που το κάλεσε.

Αναγνωρίζοντας μια ευκαιρία να είναι ένας ήρωας με λευκό καπέλο, ο Robinson προετοίμασε τη συναλλαγή διάσωσης. Αλλά ήξερε ότι δεν ήταν ο μόνος. Το mempool του Ethereum - το δημόσιο δωμάτιο αναμονής για αναμενόμενες συναλλαγές - είναι ένα κυνηγετικό έδαφος για εξελιγμένα bots γνωστά ως "γενικευμένοι frontrunners".

Για να τους ξεπεράσει, ο Ρόμπινσον σχεδίασε μια έξυπνη συναλλαγή δύο τμημάτων, ελπίζοντας να εξορύξει και τα δύο μέρη ταυτόχρονα, αφήνοντας κανένα παράθυρο για αναχαίτιση. Δεν λειτούργησε. Τη στιγμή που εμφανίστηκε η πρώτη συναλλαγή του, ένα bot το ανίχνευσε, αναπαρήγαγε ολόκληρη τη στρατηγική και λεηλάτησε τα 12.000 δολάρια πριν ακόμη επιβεβαιωθεί η δεύτερη συναλλαγή του Ρόμπινσον.

Σε ένα τώρα διάσημο δοκίμιο για το περιστατικό, ο Robinson έδωσε ένα όνομα σε αυτό το εχθρικό, αόρατο οικοσύστημα.Ethereum is a Dark Forest.

Σε αυτό το άρθρο, θα εμβαθύνουμε στο σχεδιασμό ενός συστήματος ικανού να διαβάζει πράξεις σε πραγματικό χρόνο και δεδομένα από συναλλαγές blockchain, με στόχο την εκτέλεση διαιτησίας.mathematical models underlying AMM pricingΒυθίστε το στοalgorithms for opportunity detection and optimal price entryΟρίζει τοarchitectural componentsαπό τη Βουλή μας και να συζητήσουμεcritical strategiesαπαιτείται για την επιτυχή και ασφαλή εκτέλεση της διαιτησίας σε αυτό το περιβάλλον υψηλού επιπέδου.

Το τοπίο του DeFi: AMMs, ρευστότητα και ευκαιρίες διαιτησίας

Το «σκοτεινό δάσος» που περιγράφεται στην εισαγωγή μας δεν είναι μόνο ένα εχθρικό περιβάλλον, είναι ένα ζωντανό οικοσύστημα χτισμένο πάνω σε ένα νέο χρηματοπιστωτικό πρότυπο: Αποκεντρωμένη Χρηματοδότηση (DeFi). Στην καρδιά του, το DeFi στοχεύει στην αναδημιουργία παραδοσιακών χρηματοπιστωτικών υπηρεσιών σε δίκτυα blockchain, εξαλείφοντας την ανάγκη για μεσάζοντες μέσω της χρήσης αυτοεκτελούμενων έξυπνων συμβάσεων.

Αυτοματοποιημένοι κατασκευαστές αγοράς (AMMs): Η ραχοκοκαλιά της αποκεντρωμένης ανταλλαγής

Οι παραδοσιακές ανταλλαγές βασίζονται σε βιβλία παραγγελιών, όπου οι αγοραστές και οι πωλητές υποβάλλουν προσφορές και ζητούν, και μια κεντρική μηχανή αντιστοίχισης διευκολύνει τις συναλλαγές. Το DeFi εισάγει ένα ριζικά διαφορετικό μοντέλο: το Automated Market Maker (AMM). Αντί να ταιριάζει τους αγοραστές και τους πωλητές άμεσα, οι AMMs εκμεταλλεύονται πισίνες ρευστότητας - έξυπνες συμβάσεις που κατέχουν αποθέματα δύο ή περισσότερων tokens - για να διευκολύνουν τις συναλλαγές.

Η τιμή των περιουσιακών στοιχείων μέσα σε μια πισίνα AMM καθορίζεται αλγοριθμικά από έναconstant product formula, πρωτοπόρος από την Uniswap:

Εδώ, x και y αντιπροσωπεύουν τις ποσότητες των δύο tokens στην πισίνα ρευστότητας, και k είναι μια σταθερή. Όταν ένας χρήστης διαπραγματεύεται ένα token για ένα άλλο, οι ποσότητες των x και y στην πισίνα αλλάζουν, αλλά το προϊόν τους k πρέπει να παραμείνει σταθερό. Αυτός ο μηχανισμός προσαρμόζει δυναμικά την τιμή: η αγορά περισσότερων από το token A θα μειώσει την ποσότητα του στην πισίνα, αυξάνοντας έτσι την τιμή του σε σχέση με το token B, και αντίστροφα.bonding curve, το οποίο υπαγορεύει τα διαθέσιμα σημεία τιμών για συναλλαγές.

Από αυτό το μοντέλο, είναι δυνατόν να υπολογιστεί καθοριστικά το ποσό εξόδου (dy) από ένα swap, δεδομένου του ποσού εισόδου (dx) και των αποθεμάτων προ-swap των δύο tokens (x και y):

Key characteristics of AMMs:

• Πάντα σε ρευστότητα: Σε αντίθεση με τα βιβλία παραγγελιών που μπορεί να γίνει λεπτή, AMMs προσφέρουν πάντα ρευστότητα, εφ 'όσον υπάρχουν tokens στην πισίνα.
• Χωρίς άδεια: Ο καθένας μπορεί να γίνει πάροχος ρευστότητας ή να συναλλάσσεται σε ένα AMM χωρίς να χρειάζεται έγκριση.
• Ανακάλυψη τιμών: Οι τιμές καθορίζονται από την αναλογία των περιουσιακών στοιχείων εντός της πισίνας, προσαρμόζοντας με κάθε συναλλαγή.
• Slippage: Οι μεγάλες συναλλαγές μπορούν να μετακινήσουν σημαντικά την τιμή μέσα σε μια πισίνα, οδηγώντας σε ένα φαινόμενο γνωστό ως slippage, όπου η εκτελεσθείσα τιμή είναι χειρότερη από την τιμολογημένη τιμή.

Ενώ το μοντέλο x⋅y=k (συχνά αναφέρεται ως Uniswap V2) έθεσε τα θεμέλια, τα AMMs έχουν εξελιχθεί. Το Uniswap V3, για παράδειγμα, εισήγαγε «συγκεντρωμένη ρευστότητα» (CLAMM), επιτρέποντας στους LPs να κατανέμουν το κεφάλαιό τους εντός συγκεκριμένων τιμών. Αυτό βελτίωσε σημαντικά την αποδοτικότητα του κεφαλαίου, αλλά και αύξησε την πολυπλοκότητα για τους LPs και, κατά συνέπεια, για τους διαιτητές που χρειάζονται να παρακολουθούν τη ρευστότητα σε διάφορα επίπεδα.we will primarily focus on AMMsχρησιμοποιώντας τη σταθερή φόρμουλα προϊόντος (όπως οι πισίνες στυλ Uniswap V2), καθώς παρέχουν μια θεμελιώδη κατανόηση πριν από την αντιμετώπιση πιο πολύπλοκων μοντέλων.

The Essence of Arbitrage in DeFi

Η διαιτησία, στην καθαρότερη μορφή της, είναι η ταυτόχρονη αγορά και πώληση ενός περιουσιακού στοιχείου σε διαφορετικές αγορές για να επωφεληθεί από μια διαφορά στην τιμή του. Στο DeFi, αυτό μεταφράζεται στην εκμετάλλευση των διαφορών τιμών μεταξύ διαφορετικών ομάδων AMM, ή μεταξύ ενός AMM και μιας Κεντρικής Ανταλλαγής (CEX), για το ίδιο ζεύγος token. Η έμφυτη απαράδεκτη φύση του DeFi και η κατακερματισμένη ρευστότητα σε διάφορα πρωτόκολλα δημιουργούν ένα εύφορο έδαφος για αυτές τις ευκαιρίες. Η υψηλή μεταβλητότητα και η έλλειψη ρύθμισης σε αυτόν τον αναδυόμενο χρηματοπιστωτικό χώρο συχνά οδηγούν σε σημαντικές αποκλίσεις

Τύποι ευκαιριών διαιτησίας στο DeFi

• Απλή Διαιτησία (Two-Leg): Αυτή είναι η πιο απλή μορφή, η οποία περιλαμβάνει δύο διαφορετικούς χώρους. Για παράδειγμα, αν 1 ETH συναλλάσσεται για 2000 DAI σε Uniswap A, αλλά 1 ETH συναλλάσσεται για 2010 DAI σε Uniswap B, ένας διαιτητής μπορεί να αγοράσει ETH σε Uniswap A με DAI και να πουλήσει αμέσως αυτό το ETH για DAI σε Uniswap B, τσέπη τη διαφορά 10 DAI (μείον τα τέλη φυσικού αερίου και το slippage).
• Τριγωνική Διαιτησία (Multi-Leg): Αυτός ο τύπος διαιτησίας περιλαμβάνει τρία ή περισσότερα περιουσιακά στοιχεία εντός της ίδιας ανταλλαγής (ή σε πολλαπλές ανταλλαγές) για να σχηματίσει έναν κερδοφόρο κύκλο. Για παράδειγμα, ένας διαιτητής μπορεί να ξεκινήσει με το Token A, να το ανταλλάξει για το Token B, στη συνέχεια το Token B για το Token C και τελικά το Token C να επιστρέψει στο Token A, καταλήγοντας με περισσότερα από τα Token A από ό, τι ξεκίνησαν με. Ένα κοινό παράδειγμα για το Uniswap θα μπορούσε να είναι: WETH -> DAI -> USDC -> WETH.
• Flash Loan Arbitrage: Μια ισχυρή και μοναδική πτυχή του DeFi, τα flash δάνεια επιτρέπουν στους χρήστες να δανειστούν μη εξυπηρετούμενα περιουσιακά στοιχεία, να τα χρησιμοποιήσουν για μια σειρά συναλλαγών (όπως μια διαιτησία) και να αποπληρώσουν το δάνειο - όλα μέσα σε μια ενιαία συναλλαγή blockchain. Εάν η όλη ακολουθία των συναλλαγών (δάνειο, εμπόριο, αποπληρωμή) δεν μπορεί να ολοκληρωθεί με επιτυχία μέσα σε αυτή τη ενιαία συναλλαγή, η όλη συναλλαγή επιστρέφεται, σαν να μην είχε συμβεί ποτέ. Αυτό εξαλείφει την ανάγκη για σημαντικά κεφάλαια εκ των προτέρων και μειώνει σημαντικά το εμπόδιο για την είσοδο σε μεγάλη κλίμακα διαιτη

Ο αγώνας για το κέρδος: προκλήσεις και ανταγωνισμός

Το τοπίο του DeFi είναι μια πολύ αποτελεσματική αγορά. Οι διαφορές τιμών είναι φευγαλέες, συχνά υπάρχουν για μόνο χιλιοστά δευτερολέπτου πριν εκμεταλλευτούνται από εξελιγμένα bots.

• Gas Fees: Every interaction with a smart contract incurs a transaction fee (gas), which can vary significantly based on network congestion. A profitable arbitrage opportunity must yield enough profit to cover these costs.

• Slippage: The larger the trade relative to the pool’s liquidity, the greater the slippage, eroding potential profits. Accurately modeling slippage is crucial for calculating true profitability.

• Latency: The speed at which an arbitrage bot can detect an opportunity, calculate the optimal trade, construct a transaction, and submit it to the network is paramount. Even milliseconds can make the difference between profit and loss.

• Frontrunning and MEV: As discussed in the introduction, the “Dark Forest” is dominated by generalized frontrunners. These bots actively monitor the mempool for pending profitable transactions, replicate them, and submit their own transaction with a higher gas price to ensure their transaction is included in a block before the original one. This phenomenon falls under the umbrella of Maximal Extractable Value (MEV), representing the total value that can be extracted from block production in excess of the standard block reward and gas fees by arbitraging, liquidating, or reordering transactions within a block. Successfully navigating this environment often requires advanced strategies like leveraging MEV-Boost relays or private transaction pools. To mitigate the risk of being intercepted in public mempools, our implementation will primarily operate on Base, an EVM-compatible Layer 2 (L2) blockchain. Base’s architecture, which currently does not expose a public mempool in the same manner as Ethereum’s Layer 1, offers a different environment for transaction submission, potentially reducing traditional frontrunning risks.

• Complexity of AMMs: As AMMs evolve (e.g., Uniswap V3’s concentrated liquidity), the mathematical modeling and state tracking required for accurate arbitrage calculations become significantly more complex.

  Understanding these foundational elements of DeFi, from the mechanics of AMMs to the cut-throat nature of arbitrage competition, sets the stage for designing a robust and effective arbitrage bot. In the next chapter, we will begin to lay out the architectural blueprint for such a system.

Αρχιτεκτονικός Σχεδιασμός: Κατασκευή της Υποδομής Arbitrage Bot

Η οικοδόμηση ενός κερδοφόρου bot διαιτησίας στο «Σκοτεινό Δάσος» του DeFi απαιτεί μια αρχιτεκτονική που δίνει προτεραιότητα στην ταχύτητα, την αξιοπιστία και την ακρίβεια. Κάθε χιλιοστό δευτερόλεπτο μετράει και η ικανότητα επεξεργασίας δεδομένων σε πραγματικό χρόνο, εντοπισμού ευκαιριών και εκτέλεσης συναλλαγών γρήγορα είναι πρωταρχικής σημασίας.

Το Go επιλέχθηκε ως η κύρια γλώσσα ανάπτυξης λόγω των εξαιρετικών επιδόσεών του, των ισχυρών πρωτόγονων ανταγωνισμού (goroutines και κανάλια) και του ισχυρού οικοσυστήματος για τον προγραμματισμό δικτύου και τις αλληλεπιδράσεις συστήματος χαμηλού επιπέδου. Αυτά τα χαρακτηριστικά είναι κρίσιμα για τη διαχείριση της υψηλής ροής δεδομένων blockchain και την ανάγκη παράλληλης επεξεργασίας σε ένα σύστημα διαιτησίας σε πραγματικό χρόνο.go-ethereumΟ κύριος πελάτης του Ethereum.

Η αρχιτεκτονική του bot είναι δομημένη ως έναevent-driven systemαποτελούνται από αρκετές ανεξάρτητες υπηρεσίες (μονάδες), κάθε μία εκτελούμενη σε παράλληλες διαδικασίες (goroutines). Αυτές οι υπηρεσίες επικοινωνούν ασύγχρονα στέλνοντας μηνύματα μέσω καναλιών Go, εξασφαλίζοντας ένα χαλαρά συνδεδεμένο και ιδιαίτερα ανταποκρινόμενο σχεδιασμό.

Συνολική αρχιτεκτονική συστήματος

Η υποδομή του bot διαιτησίας μπορεί να απεικονιστεί ως αγωγός, όπου τα δεδομένα ρέουν από το blockchain, υποβάλλονται σε επεξεργασία και αναλύονται και κορυφώνονται στην εκτέλεση κερδοφόρων συναλλαγών.

• Blockchain Data Reader Service: Responsible for real-time ingestion of blockchain events data.

• Market Graph Service: Maintains an in-memory representation of the DeFi market and identifies arbitrage paths.

• Arbitrage Strategy Service: Evaluates detected opportunities for profitability and prepares trade instructions.

• Transaction Builder Service: Constructs and dispatches blockchain transactions.

• Honeywall Service: A post-execution checker that enhances security and maintains market integrity by identifying and blacklisting malicious pools.

  This modularity allows each service to focus on a specific task, minimizing dependencies and optimizing performance for its particular workload. Communication between services is strictly asynchronous, leveraging Go’s channels for message passing, which naturally facilitates a non-blocking and highly concurrent operation.

Blockchain Data Reader Service: Τα μάτια και τα αυτιά του bot μας στο ρεύμα δεδομένων

Αυτή η υπηρεσία λειτουργεί ως η κύρια διεπαφή του bot με τα ακατέργαστα δεδομένα σε πραγματικό χρόνο που ρέουν μέσω του blockchain.Στο "Dark Forest", οι πληροφορίες είναι νόμισμα και η ικανότητά μας να τα καταναλώνουμε γρήγορα και με ακρίβεια είναι πρωταρχικής σημασίας.extract crucial financial data pointsΑυτό θα τροφοδοτήσει τη μηχανή λήψης αποφάσεων διαιτησίας μας.

• Συνδεσιμότητα και εισαγωγή δεδομένων: Ο αναγνώστης συνδέεται με έναν κόμβο blockchain μέσω WebSockets. Αυτή η επίμονη, αμφίδρομη σύνδεση επιτρέπει την άμεση λήψη νέων κεφαλίδων μπλοκ και, το πιο σημαντικό, ημερολογίων συμβάντων που εκδίδονται από έξυπνες συμβάσεις. Η υπηρεσία έχει διαμορφωθεί για να ακούει ειδικά τα συμβάντα Swap, Mint, Burn και Sync από τις έξυπνες συμβάσεις Decentralized Exchange (DEX). Αυτά τα συμβάντα είναι κρίσιμα καθώς υποδεικνύουν αλλαγές στα αποθέματα των αποθεμάτων ρευστότητας, επηρεάζοντας άμεσα τις τιμές των tokens.
• Νέες επικεφαλίδες μπλοκ: Με την εγγραφή σε νέες επικεφαλίδες μπλοκ, λαμβάνουμε άμεση ειδοποίηση για αλλαγές κατάστασης. κάθε νέο μπλοκ αντιπροσωπεύει μια επιβεβαιωμένη στιγμιότυπο της τρέχουσας πραγματικότητας του blockchain, συμπεριλαμβανομένων των νέων συναλλαγών, των ενημερωμένων ισοζυγίων και των νέων καταστάσεων πιστώσεων ρευστότητας.

func (er *EthereumReader) SubscribePairs() error {

	parsedABI := constants.PairAbi

	// Set up the filter
	query := ethereum.FilterQuery{
		Topics: [][]common.Hash{
			{
				parsedABI.Events["Swap"].ID,
				parsedABI.Events["Mint"].ID,
				parsedABI.Events["Burn"].ID,
				parsedABI.Events["Sync"].ID,
			},
		},
	}

	logs := make(chan types.Log)

	sub, err := er.ethClient.SubscribeFilterLogs(context.Background(), query, logs)
	if err != nil {
		return err
	}

	// Start Routine to read swaps events
	log.Println("[READING SWAPS...]")
	go func() {
		for {
			select {
			case err = <-sub.Err():
				log.Println("[RESET CONNECTION...] Subscription error: ", err)
				pairInfo := GraphMessage{
					Ok: false,
				}
				*er.pairChan <- pairInfo

				time.Sleep(5 * time.Minute)
				er.ethClient = clients.ResetConnection()
				er.SubscribePairs()

				return
			case vLog := <-logs:
				start := time.Now()

				pairAddress := vLog.Address
				if er.filter.IsPairBlackListed(pairAddress.Hex()) {
					continue
				}

				blockNumber := vLog.BlockNumber
				if blockNumber > er.currentBlockNumber {
					// New block detected, reset cache
					er.lastUpdatedBlock = nil
					er.lastUpdatedBlock = make(map[common.Address]uint64)
					er.currentBlockNumber = blockNumber
				}

				// Check if already updated for this pair in current block
				if _, exists := er.lastUpdatedBlock[pairAddress]; exists {
					continue
				}

				t0, t1, f, r0, r1, err := er.getPairDataFromHelper(pairAddress)
				if err != nil {
					continue
				}

				dex := f.String()
				router, err := constants.GetRouterAddressFromFactory(dex)
				if err != nil {
					continue
				}

				// Update cache
				er.lastUpdatedBlock[pairAddress] = blockNumber
				elapsed := time.Until(start)

				pairInfo := GraphMessage{
					Ok:       true,
					DexCheck: true,
					Pair:     pairAddress.Hex(),
					Token0:   Token{Address: t0.Hex()},
					Token1:   Token{Address: t1.Hex()},
					Reserve0: r0,
					Reserve1: r1,
					Dex:      router,
					GetTime:  elapsed,
				}

				*er.pairChan <- pairInfo
			}
		}
	}()

	return nil
}

• Προσαρμοσμένη Έξυπνη Σύμβαση για Συγκέντρωση Δεδομένων και Προ-Φιλτράρισμα: Για τη βελτιστοποίηση της αποδοτικότητας και τη μείωση των περιττών κλήσεων στην αλυσίδα, το Reader χρησιμοποιεί μια προσαρμοσμένη έξυπνη σύμβαση, γραμμένη ειδικά για το σκοπό αυτό. Αυτή η σύμβαση χρησιμεύει ως συσσωρευτής, παρέχοντας μια ενιαία, βελτιστοποιημένη κλήση για την ανάκτηση των αποθεματικών και άλλων συγκεντρωτικών πληροφοριών για πολλαπλά ζεύγη ρευστότητας. Μια βασική λειτουργικότητα αυτής της προσαρμοσμένης σύμβασης είναι ο ενσωματωμένος προ-έλεγχος για κοινά χαρακτηριστικά απάτης ή υπερβολικούς φόρους συναλλαγών
• Η βασική λογική βρίσκεται στη μέθοδο checkPair, η οποία αξιολογεί την ασφάλεια ενός ζεύγους token και επιστρέφει συγκεντρωτικά δεδομένα.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract ArbHelperMap {
    mapping(address => address) public factoryToRouter;
    address public owner;
    
    modifier onlyOwner() {
        require(msg.sender == owner, "Not owner");
        _;
    }
    
    constructor() {
        owner = msg.sender;
        // Pre-populate known mappings
        factoryToRouter[0x8909Dc15e40173Ff4699343b6eB8132c65e18eC6] = 0x4752ba5DBc23f44D87826276BF6Fd6b1C372aD24;
        factoryToRouter[0x02a84c1b3BBD7401a5f7fa98a384EBC70bB5749E] = 0x8cFe327CEc66d1C090Dd72bd0FF11d690C33a2Eb;
        factoryToRouter[0xFDa619b6d20975be80A10332cD39b9a4b0FAa8BB] = 0x327Df1E6de05895d2ab08513aaDD9313Fe505d86;
        factoryToRouter[0x71524B4f93c58fcbF659783284E38825f0622859] = 0x6BDED42c6DA8FBf0d2bA55B2fa120C5e0c8D7891;
        factoryToRouter[0x3E84D913803b02A4a7f027165E8cA42C14C0FdE7] = 0x8c1A3cF8f83074169FE5D7aD50B978e1cD6b37c7;
        factoryToRouter[0x9A9A171c69cC811dc6B59bB2f9990E34a22Fc971] = 0x1b7655aa64b7BD54077dE56B64a0f92BCba05b85;
    }
    
    function addFactoryRouter(address factory, address router) external onlyOwner {
        require(factory != address(0) && router != address(0), "Zero address");
        factoryToRouter[factory] = router;
    }
    
    struct Result {
        bool success;
        address token0;
        address token1;
        address factory;
        uint112 reserve0;
        uint112 reserve1;
    }
    
    // Helper function to get pair data
    function _getPairData(address pairAddress) private view returns (
        bool success,
        address token0,
        address token1,
        address factory,
        uint112 reserve0,
        uint112 reserve1,
        address router
    ) {
        success = false;
        
        try IPair(pairAddress).token0() returns (address _token0) {
            token0 = _token0;
            
            try IPair(pairAddress).token1() returns (address _token1) {
                token1 = _token1;
                
                try IPair(pairAddress).factory() returns (address _factory) {
                    factory = _factory;
                    
                    try IPair(pairAddress).getReserves() returns (uint112 r0, uint112 r1, uint32) {
                        reserve0 = r0;
                        reserve1 = r1;
                        
                        router = factoryToRouter[factory];
                        if (router != address(0)) {
                            success = true;
                        }
                    } catch {}
                } catch {}
            } catch {}
        } catch {}
    }
    
    // Helper function to check if pair passes tax limit
    function _checkTaxLimit(
        address router,
        address token0,
        address token1,
        uint amountIn,
        uint maxTaxPermille
    ) private view returns (bool) {
        address[] memory path = new address[](2);
        path[0] = token0;
        path[1] = token1;
        
        try IRouter(router).getAmountsOut(amountIn, path) returns (uint[] memory buyOuts) {
            if (buyOuts.length < 2) return false;
            
            address[] memory reversePath = new address[](2);
            reversePath[0] = token1;
            reversePath[1] = token0;
            
            try IRouter(router).getAmountsOut(buyOuts[1], reversePath) returns (uint[] memory sellOuts) {
                if (sellOuts.length < 2) return false;
                
                uint minReturn = amountIn - (amountIn * maxTaxPermille / 1000);
                return sellOuts[1] >= minReturn;
            } catch {
                return false;
            }
        } catch {
            return false;
        }
    }
    
    function checkPair(address pairAddress, uint amountIn, uint maxTaxPermille) external view returns (Result memory r) {        
        // Initialize result with default values
        r.success = false;
        
        // Skip processing if pair address is zero
        if (pairAddress == address(0)) return r;
        
        // Get pair data
        bool success;
        address token0;
        address token1;
        address factory;
        uint112 reserve0;
        uint112 reserve1;
        address router;
        
        (success, token0, token1, factory, reserve0, reserve1, router) = _getPairData(pairAddress);
        
        // If we couldn't get pair data or there's no router, return early
        if (!success) return r;
        
        // Check tax limits
        bool passedTaxCheck = _checkTaxLimit(router, token0, token1, amountIn, maxTaxPermille);
        
        // Populate result if tax check passed
        if (passedTaxCheck) {
            r.success = true;
            r.token0 = token0;
            r.token1 = token1;
            r.factory = factory;
            r.reserve0 = reserve0;
            r.reserve1 = reserve1;
        }
        
        return r;
    }
}

• Επικοινωνία που βασίζεται σε συμβάντα: Μετά τη λήψη και επεξεργασία αυτών των συμβάντων, το Reader ομαλοποιεί τα δεδομένα και στέλνει ενημερώσεις (π.χ. νέες τιμές αποθήκευσης για μια συγκεκριμένη πισίνα) ως μηνύματα μέσω ενός καναλιού Go στην υπηρεσία Market Graph.

Market Graph Service: Χαρτογράφηση της αγοράς DeFi

Η Market Graph Service είναι η κεντρική μονάδα πληροφοριών, η οποία διατηρεί μια αντιπροσώπευση της αγοράς DeFi σε πραγματικό χρόνο και στη μνήμη.directed graphκαι πού:

• Οζίδια: Αντιπροσωπεύουν μεμονωμένα κρυπτονομίσματα (π.χ. WETH, USDC, DAI).
• Edge: Αντιπροσωπεύουν πισίνες ρευστότητας σε διάφορα DEXes (π.χ. Uniswap V2 ETH/DAI pool, SushiSwap USDC/WETH pool).
• Δομή δεδομένων και ενημερώσεις: Αυτή η υπηρεσία λαμβάνει ενημερώσεις από την υπηρεσία Blockchain Data Reader μέσω καναλιών. Μετά τη λήψη νέων αποθεματικών δεδομένων για μια πισίνα, ενημερώνει την αντίστοιχη άκρη στο γράφημα.
• Ακριβότητα με το BigInt: Όλοι οι υπολογισμοί που αφορούν τα ποσά των tokens και τις συναλλαγματικές ισοτιμίες χρησιμοποιούν το μαθηματικό/μεγάλο πακέτο του Go (BigInt ή BigFloat). Αυτό είναι ζωτικής σημασίας για τη διατήρηση αυθαίρετης ακρίβειας, αποτρέποντας τις ανακρίβειες των πλωτών σημείων που θα μπορούσαν να οδηγήσουν σε χαμένες ευκαιρίες ή λανθασμένους υπολογισμούς κέρδους.
• Ανίχνευση διαδρομής διαιτησίας: Αλγόριθμος Bellman-Ford: Στην καρδιά αυτής της υπηρεσίας είναι η λειτουργία FindArbitrage, η οποία χρησιμοποιεί έναν αλγόριθμο διέλευσης γραφήματος, ειδικά Bellman-Ford. Αυτός ο αλγόριθμος είναι μοναδικά ικανός να βρει αρνητικούς κύκλους μέσα σε ένα γράφημα, το οποίο είναι ακριβώς αυτό που αντιστοιχεί σε μια ευκαιρία διαιτησίας στο μοντέλο της αγοράς μας (όπου οι λογαριθμικές συναλλαγματικές ισοτιμίες χρησιμοποιούνται ως άκρες). Σε αντίθεση με πολλούς άλλους αλγόριθμους θεωρίας γραφήματος που επικεντρώνονται στην εύρεση της πιο αποτελεσματικής διαδρομής, η ικανότητα του Bellman-Ford να ανιχνεύει αρνη

Υπηρεσία Στρατηγικής Διαιτησίας: Προσδιορισμός και βελτιστοποίηση των κερδών

Συμμετοχή στις ενημερωμένες εκδηλώσεις από τηνMarket Graph ServiceΗ Υπηρεσία Στρατηγικής Διαιτησίας παρακολουθεί συνεχώς το γράφημα της αγοράς για τις νέες διαδρομές διαιτησίας.

• Αξιολόγηση ευκαιριών: Κάθε φορά που το γράφημα ενημερώνεται ή εντοπίζεται μια πιθανή διαιτητική διαδρομή από το FindArbitrage, αυτή η υπηρεσία μπαίνει σε δράση.
• Βέλτιστος υπολογισμός ποσού εισόδου (Convex Optimization): Ένα κρίσιμο βήμα είναι ο προσδιορισμός του βέλτιστου ποσού εισόδου (dx) για την αλληλουχία διαιτησίας. Αυτό είναι ένα μη τριπλό πρόβλημα, καθώς η κερδοφορία είναι μια μη γραμμική λειτουργία του ποσού εισόδου, όπως αποδεικνύεται στο έγγραφο «Ανάλυση αγορών Uniswap». Αυτό επηρεάζεται από το ξεφλούδισμα και τα τέλη σε πολλαπλές ανταλλαγές. Η υπηρεσία το επιλύει ως πρόβλημα κωνοειδούς βελτιστοποίησης, χρησιμοποιώντας το πακέτο Go’s gonum/optimize. Αυτό εξασφαλίζει ότι το επιλεγμένο ποσό εισόδου μεγιστοποιεί το καθαρό κέρδος μετά τη λογιστική για όλες
• Προσομοίωση ανταλλαγών: Πριν από την ανάληψη μιας συναλλαγής, η υπηρεσία εκτελεί μια προσομοίωση εκτέλεσης όλων των ανταλλαγών εντός της ανιχνευόμενης διαιτητικής οδού χρησιμοποιώντας τον σταθερό τύπο προϊόντος και το υπολογιζόμενο βέλτιστο ποσό εισόδου. Κατά τη διάρκεια αυτής της προσομοίωσης, τα ελάχιστα ποσά εξόδου καθορίζονται επίσης για κάθε βήμα ενδιάμεσης ανταλλαγής. Αυτό εξασφαλίζει ότι σε περίπτωση απροσδόκητα χαμηλών πραγματικών εξόδων (π.χ. λόγω ξαφνικών διακυμάνσεων των τιμών ή υψηλής κλίσης στην αλυσίδα), η συναλλαγή θα επιστρέψει με ελάχιστη απώλεια αερίου, αντί να προχωρήσει σε μια μη κερδοφόρα ή
• Όλα τα τέλη: Συμπεριλαμβανομένων των τελών συναλλαγών DEX (π.χ., 0,3% για το Uniswap V2).
• Slippage: Με ακρίβεια μοντελοποίηση της επίδρασης της τιμής κάθε συναλλαγής εντός της ακολουθίας.
• Κόστος φυσικού αερίου: Μια εκτίμηση των χρεώσεων φυσικού αερίου που απαιτούνται για ολόκληρη τη συναλλαγή, λαμβάνοντας υπόψη την αλυσίδα (Βάση) και τις τρέχουσες συνθήκες δικτύου.
• Κατώτατο όριο κέρδους: Μόνο εάν το υπολογιζόμενο καθαρό κέρδος είναι τουλάχιστον 0,5% του αρχικού ποσού εισόδου (ή ένα ρυθμιζόμενο όριο) η ευκαιρία θεωρείται βιώσιμη.
• Ειδοποίηση για Εκτέλεση: Εάν μια κερδοφόρα ευκαιρία πληροί τα κριτήρια, η Υπηρεσία Στρατηγικής Διαιτησίας συγκεντρώνει όλες τις απαραίτητες λεπτομέρειες - την τακτοποιημένη ακολουθία των ανταλλαγών (εκτάσεις), το βέλτιστο ποσό εισόδου και τυχόν άλλες σχετικές παραμέτρους - και στέλνει μια ειδοποίηση μέσω ενός καναλιού Go στην Υπηρεσία Κατασκευής συναλλαγών.

Υπηρεσία κατασκευής συναλλαγών: Swift Execution

Η υπηρεσία Transaction Builder είναι ο βραχίονας εκτέλεσης του bot, ο οποίος έχει ως αποστολή την ταχεία κατασκευή και υποβολή της συναλλαγής διαιτησίας στο blockchain. η ταχύτητα είναι πρωταρχική εδώ, καθώς οι ευκαιρίες είναι εξαιρετικά χρονικά ευαίσθητες.

• Κατασκευή συναλλαγών: Μόλις λάβετε μια ευκαιρία από την Υπηρεσία Στρατηγικής Διαιτησίας, αυτή η υπηρεσία αρχίζει αμέσως την κατασκευή της συναλλαγής ατομικού blockchain.
• Smart Contract Interaction (Atomic Swaps): Αυτή η υπηρεσία αλληλεπιδρά με μια προσαρμοσμένη έξυπνη σύμβαση ειδικά σχεδιασμένη για την εκτέλεση όλων των πράξεων διαιτησίας (πολλαπλές ανταλλαγές) μέσα σε μια ενιαία, ατομική συναλλαγή.
• Εδώ είναι η λειτουργία Solidity που χειρίζεται μια εκτέλεση διαιτησίας χωρίς δάνειο flash, απαιτώντας από τον ιδιοκτήτη (το bot) να χρηματοδοτήσει το αρχικό ποσόIn:

struct SwapStep {
      address router;
      address[] path;
      uint minOut;
}

function executeArb(
    address inputToken,
    uint amountIn,
    SwapStep[] calldata steps,
    uint minFinalOut
) external onlyOwner returns (uint finalAmountOut) {
    require(steps.length > 0, "No steps");

    // Transfer tokens from msg.sender to contract
    require(IERC20(inputToken).transferFrom(msg.sender, address(this), amountIn), "Transfer in failed");

    address currentToken = inputToken;
    uint currentAmount = amountIn;

    for (uint i = 0; i < steps.length; i++) {
        SwapStep calldata step = steps[i];
        require(step.path[0] == currentToken, "Path mismatch");

        address outputToken = step.path[step.path.length - 1];

        // Save balance before swap
        uint balanceBefore = IERC20(outputToken).balanceOf(address(this));

        // Safe approve
        require(IERC20(currentToken).approve(step.router, 0), "Reset approve failed");
        require(IERC20(currentToken).approve(step.router, currentAmount), "Approve failed");

        IUniswapV2Router(step.router).swapExactTokensForTokens(
            currentAmount,
            step.minOut,
            step.path,
            address(this),
            block.timestamp
        );

        uint balanceAfter = IERC20(outputToken).balanceOf(address(this));
        uint received = balanceAfter - balanceBefore;

        require(received >= step.minOut, "Slippage too high");

        currentToken = outputToken;
        currentAmount = received;
    }

    require(currentAmount >= minFinalOut, "Final output too low");

    require(IERC20(currentToken).transfer(owner, currentAmount), "Final transfer failed");

    return currentAmount;
}

• Ενοποίηση Flash Loan: Εάν το βέλτιστο ποσό για τη διαιτησία απαιτεί ένα δάνειο flash, ο κατασκευαστής ενσωματώνει τη λογική flash δανείου (δάνειο → εκτέλεση ανταλλαγών → αποπληρωμή) σε μια ενιαία, αδιαίρετη συναλλαγή, χρησιμοποιώντας μια προσαρμοσμένη σύμβαση που διευκολύνει αυτή την ατομική λειτουργία μέσω της διεπαφής FlashLoanSimple της Aave. Αυτό επιτρέπει στο bot να εκτελεί πολύ μεγάλες διαιτησίες χωρίς να χρειάζεται να κρατήσει σημαντικό κεφάλαιο εκ των προτέρων.
• Εδώ είναι η λειτουργία σύμβασης Solidity εκτελέστεΕργασία (μέρος μιας μεγαλύτερης σύμβασης FlashLoanReceiver) που καλείται από την Aave Pool και περιέχει τη λογική διαιτησίας χρησιμοποιώντας τα δανεισμένα κεφάλαια:

function startArbitrage(
      address token,
      uint256 amount,
      SwapStep[] calldata steps,
      uint256 minFinalOut
) external onlyOwner {
    bytes memory params = abi.encode(steps, minFinalOut);
    POOL.flashLoanSimple(address(this), token, amount, params, 0);
}

function executeOperation(
    address asset,
    uint256 amount,
    uint256 premium,
    address initiator,
    bytes calldata params
) external override returns (bool) {
    require(msg.sender == address(POOL), "Untrusted lender");
    require(initiator == address(this), "Unauthorized initiator");

    (SwapStep[] memory steps, uint256 minFinalOut) = abi.decode(params, (SwapStep[], uint256));

    // Execute the arbitrage
    address currentToken = asset;
    uint currentAmount = amount;

    for (uint i = 0; i < steps.length; i++) {
        SwapStep memory step = steps[i];
        require(step.path[0] == currentToken, "Path mismatch");

        address outputToken = step.path[step.path.length - 1];

        // Save balance before swap
        uint balanceBefore = IERC20(outputToken).balanceOf(address(this));

        // Safe approve
        require(IERC20(currentToken).approve(step.router, 0), "Reset approve failed");
        require(IERC20(currentToken).approve(step.router, currentAmount), "Approve failed");

        IUniswapV2Router(step.router).swapExactTokensForTokens(
            currentAmount,
            step.minOut,
            step.path,
            address(this),
            block.timestamp
        );

        uint balanceAfter = IERC20(outputToken).balanceOf(address(this));
        uint received = balanceAfter - balanceBefore;

        require(received >= step.minOut, "Slippage too high");

        currentToken = outputToken;
        currentAmount = received;
    }

    require(currentAmount >= amount + premium, "Insufficient profit");
    require(currentAmount >= minFinalOut, "Final output too low");

    // Repay the loan
    require(IERC20(asset).approve(address(POOL), amount + premium), "Approval failed");
    
    // Transfer profits to owner
    uint profit = IERC20(asset).balanceOf(address(this)) - (amount + premium);
    if (profit > 0) {
        require(IERC20(asset).transfer(owner, profit), "Profit transfer failed");
    }

    return true;
}

• Εκτίμηση και τιμή φυσικού αερίου: Υπολογίζει δυναμικά το απαιτούμενο αέριο για τη συναλλαγή και καθορίζει μια κατάλληλη τιμή φυσικού αερίου (ή προτεραιότητα για L2s όπως η βάση) για να εξασφαλίσει την έγκαιρη ένταξη σε ένα μπλοκ.
• Αποστολή συναλλαγών: Μόλις κατασκευαστεί, η υπογεγραμμένη συναλλαγή αποστέλλεται στον κόμβο blockchain της βάσης. Η επιλογή της βάσης είναι στρατηγική: σε αντίθεση με το Ethereum L1, η τρέχουσα αρχιτεκτονική της βάσης δεν διαθέτει μια δημόσια ορατή mempool με την παραδοσιακή έννοια. Αυτό σημαίνει ότι οι συναλλαγές είναι λιγότερο επιρρεπείς στην άμεση γενικευμένη frontrunning από bots που σαρώνουν το mempool. Ενώ η μέγιστη εκχυλιστή αξία (MEV) εξακολουθεί να υπάρχει σε L2, οι μηχανισμοί εξόρυξης διαφέρουν από το L1, και η άμεση sniping mempool μειώνεται σημαντικά, προσφέροντας ένα πιο προβλέψιμο περιβάλλον εκτέλεσης για τους
• Ασύγχρονη Ανατροφοδότηση: Μετά την αποστολή της συναλλαγής, η υπηρεσία στέλνει μια ειδοποίηση στην Υπηρεσία Honeywall για να σηματοδοτήσει ότι μια συναλλαγή έχει ξεκινήσει και απαιτεί παρακολούθηση.

Honeywall Service: Post-Execution Validation and Security

Η υπηρεσία Honeywall λειτουργεί ως ένας κρίσιμος έλεγχος μετά την εκτέλεση και ένα ισχυρό στρώμα ασφαλείας για το bot διαιτησίας.

• Παρακολούθηση αποτελεσμάτων συναλλαγών: Μετά την αποστολή μιας συναλλαγής από τον Κατασκευαστή συναλλαγών, η Υπηρεσία Honeywall παρακολουθεί την ένταξή της σε ένα μπλοκ και το αποτέλεσμα της.
• Καταγραφή κερδών: Εάν η συναλλαγή είναι επιτυχής και αποφέρει κέρδος (όπως αναμένεται από την προσομοίωση), οι λεπτομέρειες των κερδών καταγράφονται για την παρακολούθηση της απόδοσης και την ανάλυση.
• Ανάλυση αποτυχίας: Σε περίπτωση αποτυχίας μιας συναλλαγής, το Honeywall αναλύει τον λόγο της αντιστροφής.
• Ανίχνευση Honeypot / Scam και μαύρη λίστα: Ένα βασικό χαρακτηριστικό ασφαλείας είναι η ικανότητά του να εντοπίζει τα tokens "honeypot" ή τις πισίνες που εφαρμόζουν παραπλανητική λογική (π.χ., επιτρέποντας αγορές αλλά αποτρέποντας τις πωλήσεις ή επιβάλλοντας υπερβολικούς κρυφούς φόρους στις πωλήσεις).
• Ενοποίηση εξωτερικών προμηθευτών: Ενσωματώνει με έναν εξωτερικό προμηθευτή ή μια βάση δεδομένων γνωστών συμβάσεων honeypot για να διασταυρώσει τα ζεύγη που χρησιμοποιούνται σε αποτυχημένες συναλλαγές, εντοπίζοντας έτσι πιθανές απάτες.
• Δυναμική μαύρη λίστα: Εάν ένα συγκεκριμένο ζευγάρι ή μια πισίνα αναγνωριστεί ως μέλι ή προβληματικό λόγω απροσδόκητων υψηλών φόρων, προστίθεται αμέσως σε μια μαύρη λίστα που υποστηρίζεται από τη βάση δεδομένων.
• Bloom Filter Integration: Αυτή η μαύρη λίστα διαχειρίζεται αποτελεσματικά μέσω ενός μηχανισμού φίλτρου Bloom. Αυτό επιτρέπει στην υπηρεσία αναγνώστη δεδομένων Blockchain να ελέγχει γρήγορα τα νεοεμφανιζόμενα ζεύγη έναντι της μαύρης λίστας πριν ακόμη και να ανακτήσει τα αποθέματά τους ή να τα προσθέσει στο γράφημα της αγοράς.

Συμπέρασμα Αρχιτεκτονικού Σχεδιασμού

Η αρθρωτή, εκδηλωτική αρχιτεκτονική που εφαρμόζεται στο Go, σε συνδυασμό με εξειδικευμένες υπηρεσίες για την κατάποση δεδομένων, τη μοντελοποίηση της αγοράς, τη βελτιστοποίηση ευκαιριών, την ταχεία εκτέλεση και την ισχυρή ασφάλεια, αποτελεί τη ραχοκοκαλιά του υψηλής απόδοσης bot διαιτησίας μας.

Ανίχνευση ευκαιριών και βέλτιστη εκτέλεση: Ο εγκέφαλος του bot

Η πραγματική ευφυΐα ενός bot διαιτησίας έγκειται στην ικανότητά του να εντοπίζει γρήγορα και με ακρίβεια κερδοφόρες ευκαιρίες σε μια συνεχώς μεταβαλλόμενη αγορά και στη συνέχεια να βελτιστοποιεί την εκτέλεση για μέγιστη απόδοση.

Μοντελοποίηση της αγοράς DeFi ως γραφήματος

Όπως παρουσιάστηκε στην αρχιτεκτονική επισκόπηση, η υπηρεσία Market Graph μας αντιπροσωπεύει το τοπίο του DeFi ως ένα κατευθυνόμενο γράφημα.nodes, ενώ οι πισίνες ρευστότητας σε διάφορα Αποκεντρωμένα Χρηματιστήρια (DEX) ενεργούν ωςedgesΤο βάρος κάθε άκρας αντιπροσωπεύει το κόστος συναλλαγών μέσω αυτής της πισίνας.

Για να ανιχνεύσουμε αποτελεσματικά τις ευκαιρίες διαιτησίας, οι οποίες εκδηλώνονται ως κερδοφόροι κύκλοι, μετατρέπουμε το πρόβλημα της εύρεσης μιας κερδοφόρας ακολουθίας συναλλαγών σε εύρεση ενόςnegative cycleΑυτή η μετατροπή επιτυγχάνεται με την εφαρμογή μιας λογαριθμικής συνάρτησης στις συναλλαγματικές ισοτιμίες.

The Necessity of Logarithms for Cycle Detection

The core idea behind arbitrage is to multiply a starting amount by a series of exchange rates to end up with more of the original asset. For example, if we start with A units of TokenXκαι το εμπόριο γιαTokenYΣτη συνέχειαTokenYΓιαTokenZΚαι τέλοςTokenZΠίσω στοTokenXΤο τελικό μας ποσό θα ήταν:

Μια κοινή τεχνική στην υπολογιστική χρηματοδότηση για να μετατρέψετε πολλαπλασιαστικά προβλήματα σε προσθετικά είναι να εφαρμόσετε ένα λογάριθμο.

Για έναν κερδοφόρο κύκλο, χρειαζόμαστεγιος γιος γιος γιος, το οποίο σημαίνειln(RateX→Y) + ln(RateY→Z) + ln(RateZ→X) > 0Ωστόσο, οι τυπικοί αλγόριθμοι συντομότερης διαδρομής (όπως ο Bellman-Ford, τον οποίο χρησιμοποιούμε) έχουν σχεδιαστεί για να βρίσκουν διαδρομές με ελάχισταΣΟΥΜΑΓια να κάνουμε έναν κερδοφόρο κύκλο να εμφανίζεται ως «αρνητικός κύκλος» στο γράφημά μας, απλώς αρνούμαστε τα λογαριθμικά ποσοστά:

Με αυτόν τον μετασχηματισμό, ένα άθροισμα αρνητικών βαρών που οδηγεί σε αρνητική αξία (δηλαδή, ένας αρνητικός κύκλος) υποδεικνύει άμεσα μια κερδοφόρα ευκαιρία διαιτησίας.

Η ακρίβεια μεBigInt

Οι ποσότητες των tokens στο DeFi μπορεί να ποικίλλουν άγρια, από μικρά κλάσματα (π.χ. για τα tokens ERC-20 με 18 δεκαδικά σημεία) σε πολύ μεγάλους αριθμούς (π.χ. stablecoins). Αυτή η ακραία ετερογένεια στο μέγεθος, που καλύπτει έως και 18 σημαντικούς αριθμούς, καθιστά την τυπική αριθμητική πλωτών σημείων εξαιρετικά ευαίσθητη σε σφάλματα ακρίβειας.

Για να ξεπεραστεί αυτό, η υπηρεσία μας Market Graph, και πράγματι όλοι οι υπολογισμοί που αφορούν τα ποσά των token και τις συναλλαγματικές ισοτιμίες εντός του bot, χρησιμοποιούν το Go'smath/bigΣυγκεκριμένα το πακέτοBigIntΑριθμητικά Αριθμητικά καιBigFloatγια λειτουργίες πλωτού σημείου όπου είναι απαραίτητο. ενώBigFloatπροσφέρει αυθαίρετη ακρίβεια, εφαρμόζονταςlogΔύοBigIntήBigFloatαπαιτεί προσεκτική διαχείριση, ως πρότυποmath.Logλειτουργίες που λειτουργούν σε nativefloat64Προσαρμοσμένες εφαρμογές ή εξωτερικές βιβλιοθήκες ικανές για λογαρίθμους αυθαίρετης ακρίβειας είναι απαραίτητες εδώ.

func getLogRate(reserve0, reserve1 *big.Int) *big.Float {
	const prec = 1024
	resIn := new(big.Float).SetPrec(prec).SetInt(reserve0)
	resOut := new(big.Float).SetPrec(prec).SetInt(reserve1)

	// Effective Rate
	rate := new(big.Float).SetPrec(prec).Quo(resOut, resIn)
	logRate := bigfloat.Log(rate)

	return logRate.Neg(logRate)
}

Ο αλγόριθμος Bellman-Ford

Μόλις η αγορά DeFi μοντελοποιηθεί με ακρίβεια ως γράφημα με λογαριθμικά αρνητικά περιθώρια βάρους, το έργο της εύρεσης ευκαιριών διαιτησίας μειώνεται στον προσδιορισμόnegative cyclesΓια το σκοπό αυτό, χρησιμοποιούμε τοBellman-Ford algorithm.

Ονομάστηκε μετά από τον Richard Bellman και τον Lester Ford Jr., ο Bellman-Ford είναι ένας ευέλικτος αλγόριθμος βραχύτερης διαδρομής ικανός να χειρίζεται γραφήματα με αρνητικά περιθώρια βάρους. Σε αντίθεση με τον αλγόριθμο του Dijkstra, ο οποίος αποτυγχάνει παρουσία αρνητικών κύκλων, ο Bellman-Ford έχει σχεδιαστεί ειδικά για να τα ανιχνεύσει. η ιστορική του σημασία εκτείνεται πέρα από τη θεωρητική επιστήμη των υπολογιστών. έχει βρει εφαρμογές σε διάφορους τομείς, συμπεριλαμβανομένης της δρομολόγησης δικτύου (όπου βοηθά στην εύρεση των φθηνότερων διαδρομών με ποικίλα έξοδα) και, κρίσιμα, στην ποσοτική χρηματοδότηση

Ο αλγόριθμος λειτουργεί με επαναλαμβανόμενη χαλάρωση των άκρων, βρίσκοντας προοδευτικά μικρότερες διαδρομές σε όλους τους κόμβους από μια πηγή. Εάν, μετά από επαναλήψεις Β−1 (όπου Β είναι ο αριθμός των κορυφών), μια πρόσθετη N-η επαναλήψεις βρίσκει μια διαδρομή που μπορεί ακόμα να είναι «χαλαρωμένη» (δηλαδή, μια μικρότερη διαδρομή μπορεί να βρεθεί), υποδηλώνει την παρουσία ενός αρνητικού κύκλου. Αυτή η ιδιότητα το καθιστά τέλειο για την περίπτωσή μας: ένας αρνητικός κύκλος συνεπάγεται μια ακολουθία συναλλαγών που οδηγεί σε καθαρό κέρδος, ακριβώς αυτό που επιδιώκει ένα bot διαιτησίας.

type Edge struct {
	Pair     string
	From     Token
	To       Token
	LogRate  *big.Float
	Reserve0 *big.Int
	Reserve1 *big.Int
	Dex      string
	MinOut   *big.Int
}

type Graph struct {
	nodes         map[string]Token
	Edges         map[string][]*Edge
	pairChan      *chan GraphMessage
	dexCheckChan  *chan DexDexMessage
	subscriptions []*chan time.Duration
	mu            sync.RWMutex
}

// Bellman-Ford algorithm to find arbitrage cycles
func (g *Graph) FindArbitrage(source Token) ([]*Edge, bool) {
	sourceKey := source.Address

	g.mu.RLock()
	defer g.mu.RUnlock()

	distance := make(map[string]*big.Float)
	predecessor := make(map[string]*Edge)

	// 1. Init
	for token := range g.nodes {
		distance[token] = new(big.Float).SetInf(false)
	}
	distance[sourceKey] = new(big.Float).SetFloat64(0)

	// 2. Relax edges V-1 times
	for i := 0; i < len(g.nodes)-1; i++ {
		for _, edgeList := range g.Edges {
			for _, e := range edgeList {
				from := e.From.Address
				to := e.To.Address

				if !distance[from].IsInf() && new(big.Float).Add(distance[from], e.LogRate).Cmp(distance[to]) < 0 {
					distance[to].Add(distance[from], e.LogRate)
					predecessor[to] = e
				}
			}
		}
	}

	// 3. Negative cycle detection
	var cycleStartToken string
	for _, edgeList := range g.Edges {
		for _, e := range edgeList {
			from := e.From.Address
			to := e.To.Address
			if !distance[from].IsInf() && new(big.Float).Add(distance[from], e.LogRate).Cmp(distance[to]) < 0 {
				cycleStartToken = to
				break
			}
		}
		if cycleStartToken != "" {
			break
		}
	}

	if cycleStartToken == "" {
		return nil, false // No Arbitrage
	}

	// 4. detect first cycle node
	visited := make(map[string]bool)
	current := cycleStartToken
	for !visited[current] {
		visited[current] = true
		edge := predecessor[current]
		if edge == nil {
			return nil, false // missing edge
		}
		current = edge.From.Address
	}

	// 5. Complete cycle
	cycleStart := current
	cycle := []*Edge{}
	for {
		edge := predecessor[current]
		if edge == nil {
			return nil, false // missing edge
		}
		cycle = append(cycle, edge)
		current = edge.From.Address
		if current == cycleStart {
			break
		}
	}

	// 6. Invert cycle
	for i, j := 0, len(cycle)-1; i < j; i, j = i+1, j-1 {
		cycle[i], cycle[j] = cycle[j], cycle[i]
	}

	return cycle, true
}

Καλύτερος υπολογισμός εισροών: μεγιστοποίηση του κέρδους

Μόλις εντοπιστεί ένας αρνητικός κύκλος (δυνατότητα διαιτησίας), το επόμενο κρίσιμο βήμα είναι να προσδιοριστεί ηoptimal input amountΑυτό δεν είναι αυθαίρετο. η κερδοφορία μιας ευκαιρίας διαιτησίας είναι μια μη γραμμική λειτουργία του μεγέθους της συναλλαγής λόγω της έμφυτης ολίσθησης και των τελών που σχετίζονται με τις ανταλλαγές AMM.

Όπως περιγράφεται λεπτομερώς στην «Ανάλυση των αγορών Uniswap», η σταθερή φόρμουλα του προϊόντος συνεπάγεται εγγενώς μια σύγκλιση στη σχέση μεταξύ των ποσών εισόδου και εξόδου. Συγκεκριμένα, καθώς το μέγεθος της συναλλαγής αυξάνεται, η αποτελεσματική συναλλαγματική ισοτιμία επιδεινώνεται λόγω της αμετάβλητης ποσότητας της πισίνας.

Το πρόβλημα της μεγιστοποίησης του κέρδους είναι έναconvex optimization problemΓια μια σειρά από ανταλλαγές N σε μια διαδρομή διαιτησίας, το τελικό ποσό εξόδου (και ως εκ τούτου το κέρδος) μπορεί να εκφραστεί ως λειτουργία του αρχικού ποσού εισόδου (dx ). Ενώ η ακριβής αναλυτική λύση για την διαιτησία πολλαπλών ποδιών μπορεί να είναι περίπλοκη, ειδικά με διαφορετικές δομές τελών και καμπύλες μετατόπισης σε διαφορετικά AMMs, η λειτουργία που αντιπροσωπεύει το κέρδος μείον το κόστος (συμπεριλαμβανομένου του αερίου) είναι γενικά κωνική.

Η Υπηρεσία Στρατηγικής Διαιτησίας μας αντιμετωπίζει αυτό χρησιμοποιώντας έναν λύτη βελτιστοποίησης από την Go's.gonum/optimizeΑυτός ο λύστης παίρνει μια λειτουργία που αντιπροσωπεύει το καθαρό κέρδος (το κέρδος από τις ανταλλαγές μείον τις εκτιμώμενες χρεώσεις για το φυσικό αέριο και τυχόν προμήθειες δάνειο flash) και βρίσκει το ποσό εισόδου που μεγιστοποιεί αυτή την τιμή.amountOutφόρμουλαdy = (x + dx) / (dx⋅ y)για κάθε βήμα στη διαδρομή διαιτησίας, λογιστικοποίηση των ενδιάμεσων αποθεματικών, των τελών και της διαρροής σε κάθε στάδιο.

func getOptimalAmoutIn(edges []*Edge, decimals int) (*float64, error) {
	factor := math.Pow10(decimals)
	intMax, _ := constants.GetRouterReserveFromToken(edges[0].From.Address)

	maxCapital := new(big.Float).Mul(new(big.Float).SetInt64(intMax), big.NewFloat(factor))
	fee := big.NewFloat(0.997)

	problem := optimize.Problem{
		Func: func(x []float64) float64 {
			delta := big.NewFloat(x[0])
			if delta.Cmp(big.NewFloat(0)) < 0 || delta.Cmp(maxCapital) > 0 {
				return math.Inf(1)
			}

			delta_i := new(big.Float).Set(delta)
			for _, edge := range edges {
				effectiveIn := new(big.Float).Mul(delta_i, fee)
				reserveIn := new(big.Float).SetInt(edge.Reserve0)
				reserveOut := new(big.Float).SetInt(edge.Reserve1)

				num := new(big.Float).Mul(reserveOut, effectiveIn)
				denom := new(big.Float).Add(reserveIn, effectiveIn)
				delta_i = new(big.Float).Quo(num, denom)
			}

			profit := new(big.Float).Sub(delta_i, delta)
			result, _ := profit.Float64()
			return -result
		},
	}

	result, err := optimize.Minimize(problem, []float64{1.0}, nil, nil)
	if err != nil {
		return nil, err
	}

	return &result.X[0], nil
}

Προσομοίωση των swaps και αξιολόγηση της κερδοφορίας

Πριν από οποιαδήποτε συναλλαγή αποστέλλεται, η Υπηρεσία Στρατηγικής Διαιτησίας εκτελεί μια λεπτομερήsimulated executionΑυτό το βήμα είναι ζωτικής σημασίας για την επαλήθευση της πραγματικής κερδοφορίας, δεδομένων των συνθηκών της αγοράς σε πραγματικό χρόνο και των ακριβών παραμέτρων της προτεινόμενης συναλλαγής.

Η προσομοίωση χρησιμοποιεί τα τρέχοντα αποθέματα των εμπλεκόμενων πιστωτικών στοιχείων ρευστότητας και το υπολογιζόμενο βέλτιστο ποσό εισόδου.Για κάθε βήμα στο μονοπάτι πολλαπλών ποδιών, εφαρμόζει τον συγκεκριμένο τύπο AMM (π.χ. τον τύπο του σταθερού προϊόντος για τις πισίνες που μοιάζουν με Uniswap V2) για τον υπολογισμό της αναμενόμενης παραγωγής:

func (ab *ArbitrageBuilderV2) calculateProfitabilityWithSlippage(edges []*Edge, decimals int) (*big.Float, *big.Float, error) {
	opt, err := getOptimalAmoutIn(edges, decimals)
	if err != nil {
		return nil, nil, err
	}
	optBig := new(big.Float).SetFloat64(*opt)
	amount := new(big.Float).Set(optBig)

	fee := big.NewFloat(0.997)

	for _, edge := range edges {
		if edge.Reserve0 == nil || edge.Reserve1 == nil ||
			edge.Reserve0.Cmp(big.NewInt(0)) == 0 || edge.Reserve1.Cmp(big.NewInt(0)) == 0 {
			return nil, nil, errors.New("edge has invalid reserves")
		}

		reserveIn := new(big.Float).SetInt(edge.Reserve0)
		reserveOut := new(big.Float).SetInt(edge.Reserve1)

		amountInWithFee := new(big.Float).Mul(amount, fee)
		if amountInWithFee.Cmp(reserveIn) >= 0 {
			return big.NewFloat(-1.0), nil, errors.New("amount exceeds available reserves")
		}

		// "x * y = k"
		numerator := new(big.Float).Mul(reserveOut, amountInWithFee)
		denominator := new(big.Float).Add(reserveIn, amountInWithFee)
		amountOut := new(big.Float).Quo(numerator, denominator)

		amount = amountOut
	}

	profit := new(big.Float).Sub(amount, optBig)
	profit.Sub(profit, ab.EstimateGasCost(len(edges)))
	profit.Sub(profit, new(big.Float).Mul(optBig, big.NewFloat(0.005)))

	normalizedProfit := new(big.Float).Quo(profit, new(big.Float).SetFloat64(math.Pow10(decimals)))
	return normalizedProfit, optBig, nil
}

Επιπλέον, η προσομοίωση περιλαμβάνειminimum output amount (minOut)Ελέγξτε το κάθε βήμα, αυτόminOutΟι τιμές προέρχονται από τις προσομοιωμένες αναμενόμενες εκροές και καθορίζονται ως παράμετροι στην πραγματική συναλλαγή στην αλυσίδα.Εάν, λόγω καθυστέρησης δικτύου, εμπρόσθιας κυκλοφορίας ή απρόσμενων συνθηκών αγοράς, μια πραγματική ανταλλαγή στην αλυσίδα αποδίδει λιγότερο από το καθορισμένοminOutΑυτός ο μηχανισμός είναι μια ζωτική διασφάλιση, εμποδίζοντας το bot να ολοκληρώσει μια μη κερδοφόρα ακολουθία συναλλαγών και περιορίζοντας τις απώλειες μόνο στο αέριο που δαπανάται για την αντιστρεφόμενη συναλλαγή.

Μόνο εάν το τελικό καθαρό κέρδος, μετά από όλες τις αμοιβές, τις διαρροές, τα έξοδα φυσικού αερίου και τα ασφάλιστρα flash δανείων, υπερβαίνει ένα προκαθορισμένο ποσό.profit threshold(π.χ., 0,5% του αρχικού ποσού εισόδου) είναι η ευκαιρία που θεωρείται βιώσιμη και μεταφέρεται στην Υπηρεσία Κατασκευαστή Συναλλαγών για εκτέλεση.

Μηχανική συναλλαγών: γρήγορη εκτέλεση στο σκοτεινό δάσος

Ο προσδιορισμός μιας κερδοφόρας ευκαιρίας διαιτησίας είναι μόνο το ήμισυ της μάχης. το άλλο, ίσως πιο κρίσιμο, το ήμισυ έγκειται στην ικανότητα εκτέλεσης της συναλλαγής με ασυναγώνιστη ταχύτητα και αξιοπιστία.Στο υπερ-ανταγωνιστικό «Σκοτεινό Δάσος» του DeFi, όπου οι ευκαιρίες είναι περαστικές και εξελιγμένα bots ζουν για κάθε χιλιοστό δευτερόλεπτο, η μηχανική συναλλαγών γίνεται μια μορφή τέχνης.Transaction Builder ServiceΣχεδιασμένο για γρήγορη και ασφαλή εκτέλεση.

Η επιτακτική ανάγκη της ταχύτητας

Το παράθυρο κερδοφορίας για ευκαιρίες διαιτησίας σε αποκεντρωμένες ανταλλαγές μετριέται συχνά σε χιλιοστά δευτερολέπτου. Οι διαφορές τιμών ανιχνεύονται γρήγορα και εκμεταλλεύονται από πολυάριθμα αυτοματοποιημένα συστήματα, δημιουργώντας έναν έντονο αγώνα για να είναι ο πρώτος που θα συμπεριλάβει μια κερδοφόρα συναλλαγή σε ένα νέο μπλοκ. Οποιαδήποτε καθυστέρηση, όσο μικρή κι αν είναι, μπορεί να οδηγήσει στην κατάληψη της ευκαιρίας από έναν ανταγωνιστή, οδηγώντας σε αποτυχημένη συναλλαγή και δαπανηρές χρεώσεις φυσικού αερίου. Ως εκ τούτου, κάθε απόφαση σχεδιασμού στην υπηρεσία Transaction Builder στοχεύει στην ελαχιστοποίηση της καθυστέρησης σε κάθε

Βελτιστοποίηση μνήμης για άμεση δημιουργία συναλλαγών

Για να επιτύχουμε την απαιτούμενη ταχύτητα, το σύστημά μας δίνει προτεραιότητα στο να έχουν όλα τα βασικά στοιχεία συναλλαγών άμεσα διαθέσιμα στη μνήμη, εξαλείφοντας δαπανηρές λειτουργίες I/O ή κλήσεις στην αλυσίδα κατά τη διάρκεια της κρίσιμης φάσης κατασκευής συναλλαγών.

• Pre-Parted and Packed ABIs: Smart Contract Application Binary Interfaces (ABIs) καθορίζουν τον τρόπο αλληλεπίδρασης με τις συμβάσεις. Αντί να ανιχνεύουμε τους ορισμούς ABI και τις κλήσεις λειτουργίας κωδικοποίησης για κάθε συναλλαγή, το σύστημά μας προ-Partes και συσκευάζει τις απαραίτητες δομές δεδομένων ABI και τους επιλέκτες λειτουργιών σε σειρές ακατέργαστων bytes[]. Αυτές οι προ-υπολογισμένες ακολουθίες byte για κοινές συμβατικές αλληλεπιδράσεις (π.χ. swapExactTokensForTokens, flashLoanSimple, transferFrom) αποθηκεύονται στη μνήμη. Όταν εντοπίζεται μια ευκαιρία διαιτησίας, ο Transaction Builder μπορεί
• Κρυπτογραφημένα δεδομένα σε αλυσίδα για πεδία συναλλαγών: Για να αποφευχθούν οι περιττές κλήσεις σε αλυσίδα για μεταδεδομένα συναλλαγών, μια ειδική δομή βοηθητικών υπηρεσιών μέσα στο bot διατηρεί κρίσιμες, συχνά ενημερωμένες τιμές στη μνήμη:
• Λογαριασμός Nonce: Η nonce (αριθμός συναλλαγών που αποστέλλονται από μια διεύθυνση) είναι ζωτικής σημασίας για την πρόληψη των επιθέσεων επαναπαραγωγής και την εξασφάλιση της παραγγελίας συναλλαγών.
• Βέλτιστες παραμέτρους φυσικού αερίου: Αντί να αναζητά το δίκτυο για τις τιμές φυσικού αερίου (ή βασικές χρεώσεις / χρεώσεις προτεραιότητας στις αλυσίδες EIP-1559) για κάθε συναλλαγή, το bot συλλέγει περιοδικά τις βέλτιστες παραμέτρους φυσικού αερίου.
• Πληροφορίες υπογραφής: Το ιδιωτικό κλειδί του πορτοφολιού του bot και το συσχετισμένο αντικείμενο υπογραφής (που χρησιμοποιείται για την κρυπτογραφική υπογραφή συναλλαγών) φορτώνονται στη μνήμη κατά την εκκίνηση. Αυτό εμποδίζει οποιαδήποτε εισαγωγή δίσκου ή προέλευση κλειδιού κατά τη διάρκεια της κρίσιμης φάσης εκτέλεσης, εξασφαλίζοντας ότι οι συναλλαγές μπορούν να υπογραφούν σχεδόν αμέσως.

Διατηρώντας αυτά τα ζωτικά συστατικά στη μνήμη, η υπηρεσία Transaction Builder μπορεί να κατασκευάσει και να υπογράψει μια πλήρη συναλλαγή blockchain σε μικροδευτερόλεπτα, έτοιμη για άμεση αποστολή.

Δυναμική επιλογή έξυπνων συμβάσεων: Flash Loans vs. Direct Swaps

Η Υπηρεσία Στρατηγικής Διαιτησίας διαβιβάζει μια βελτιστοποιημένη διαδρομή διαιτησίας και το υπολογισμένο βέλτιστο ποσό εισόδου στον Κατασκευαστή συναλλαγών.amountInκαι αν υπερβαίνει ένα προκαθορισμένο κατώτατο όριο κεφαλαίου (ή αν η στρατηγική το απαιτεί ρητά), ο οικοδόμος συναλλαγών επιλέγει δυναμικά μεταξύ δύο κύριων έξυπνων συμβάσεων για εκτέλεση:

• Σύμβαση εκτέλεσης άμεσης ανταλλαγής: Για ευκαιρίες που μπορούν να χρηματοδοτηθούν άμεσα από το κεφάλαιο που ανήκει στο bot, ο κατασκευαστής χρησιμοποιεί τη λειτουργία executeArb (ή παρόμοια) σε μια προσαρμοσμένη σύμβαση διαμεσολαβητή πολλαπλών ανταλλαγών. Όπως φαίνεται στο Κεφάλαιο 3, αυτή η σύμβαση παίρνει τα tokens εισόδου από το πορτοφόλι του bot και εκτελεί ολόκληρη τη σειρά ανταλλαγών μέσα σε μια ενιαία, ατομική συναλλαγή.
• Ολοκληρωμένη σύμβαση Flash Loan: Όταν το υπολογισμένο βέλτιστο ποσόIn για μια διαιτησία είναι σημαντικά μεγαλύτερο από το διαθέσιμο κεφάλαιο του bot, ο κατασκευαστής στοχεύει σε μια ξεχωριστή, προσαρμοσμένη έξυπνη σύμβαση σχεδιασμένη για την έναρξη και τη διαχείριση των flash δανείων. Η λειτουργία startArbitrage αυτού του συμβολαίου (όπως περιγράφεται λεπτομερώς στο κεφάλαιο 3) ζητά ένα flash δάνειο από ένα πρωτόκολλο όπως το Aave, το οποίο στη συνέχεια καλεί πίσω την εκτέλεση της σύμβασηςΟικονομική λειτουργία. Μέσα από την εκτέλεσηΕπιχείρηση, η όλη ακολουθία διαιτησίας εκτελείται χρησιμοποιώντας τα δανεισμένα κεφάλαια και το flash

Αυτή η δυναμική επιλογή εξασφαλίζει αποτελεσματική κατανομή κεφαλαίου και βέλτιστη εκτέλεση στρατηγικής με βάση τις ιδιαιτερότητες κάθε εντοπισμένης ευκαιρίας.

Mempool Dynamics: Πλοήγηση Ethereum L1 vs Layer 2 αλυσίδες

Μια κρίσιμη πτυχή της εκτέλεσης της διαιτησίας είναι η κατανόηση του μηχανισμού διάδοσης των συναλλαγών του blockchain, ιδίωςmempool.

• Ethereum L1 Mempool: On Ethereum’s Layer 1, the mempool is a public, transparent waiting room for all pending transactions. Transactions broadcasted by users or bots are relayed to various nodes across the network, becoming visible to anyone monitoring the mempool. This transparency is the breeding ground for generalized frontrunning bots (often referred to as “searchers” or “MEV bots”). These sophisticated entities continuously scan the mempool for profitable transactions (e.g., large swaps that cause significant price impact, liquidations, or other arbitrage attempts). Upon detecting such a transaction, they quickly construct an identical or similar transaction, replace the original recipient address with their own, and submit it with a higher gas price (or higher priority fee in EIP-1559) to ensure their transaction is included in the block before the original, thereby stealing the profit. This competitive landscape makes direct arbitrage on L1 highly challenging without leveraging specialized MEV relays.

• Layer 2 (L2) Chains and Reduced Mempool Visibility (e.g., Base): Our bot strategically operates on Base, an EVM-compatible Layer 2 blockchain. The architecture of many L2s, including Base, fundamentally alters the traditional L1 mempool dynamic. Base does not currently expose a publicly visible mempool in the same manner as Ethereum Layer 1. Instead, transactions are typically sent directly to a centralized sequencer or a private mempool before being batched and committed to the L1.

  This architectural difference significantly reduces the direct threat of generalized frontrunning. While MEV still exists on L2s (e.g., through sequencer-controlled ordering or other means), the immediate, public visibility of pending transactions that enables L1 frontrunning is largely absent. This provides a more predictable and secure execution environment for our arbitrage transactions, as the bot’s crafted atomic operations are less likely to be “sniped” before they even reach a block producer. This improved execution predictability contributes directly to higher success rates for profitable arbitrages.

Ταχύτητα και ασφάλεια κόμβων: Τα θεμέλια της αξιόπιστης εκτέλεσης

Η σύνδεση με τον κόμβο blockchain είναι το ενιαίο σημείο εισόδου και εξόδου για όλα τα δεδομένα και τις συναλλαγές.

• Υψηλής απόδοσης σύνδεση κόμβου: Η υπηρεσία Transaction Builder συνδέεται με έναν εξειδικευμένο πάροχο κόμβου υψηλής απόδοσης (π.χ. Alchemy, Infura ή ένα αυτο-hosted κόμβο). Μια σύνδεση γρήγορης και χαμηλής καθυστέρησης είναι απαραίτητη για να ελαχιστοποιηθεί ο χρόνος μεταξύ της υπογραφής μιας συναλλαγής και της εξάπλωσής της στο δίκτυο. Οποιαδήποτε καθυστέρηση του δικτύου εδώ μεταφράζεται άμεσα σε χαμένες ευκαιρίες διαιτησίας.
• Ασφάλεια και ακεραιότητα κόμβου: Η ασφάλεια του συνδεδεμένου κόμβου είναι εξίσου σημαντική. Η χρήση αξιόπιστων παρόχων κόμβου ή η εξασφάλιση ενός υψηλής ασφάλειας αυτοεξυπηρετούμενου κόμβου είναι ζωτικής σημασίας για την πρόληψη ανθρώπινων επιθέσεων ή παραβίασης δεδομένων. Ένας υπονομευμένος κόμβος θα μπορούσε ενδεχομένως να διαρρεύσει ιδιωτικά κλειδιά, να εισάγει κακόβουλες συναλλαγές ή να χειραγωγήσει δεδομένα, οδηγώντας σε καταστροφικές απώλειες. Η εξάρτηση του συστήματός μας από ιδιωτικά τερματικά σημεία RPC (αν είναι διαθέσιμα από παρόχους) και ασφαλή κανάλια επικοινωνίας (https για HTTP, wss για

Με τη λεπτομερή βελτιστοποίηση για ταχύτητα σε κάθε στρώμα, από τις δομές δεδομένων εντός μνήμης και την προ-υπολογιστική έως τη στρατηγική επιλογή αλυσίδας και την ανθεκτική υποδομή κόμβων, το arbitrage bot μας έχει σχεδιαστεί για να ξεπεράσει τους ανταγωνιστές και να αξιοποιήσει με ασφάλεια τις μεταβαλλόμενες ευκαιρίες στο τοπίο του DeFi.

Πλοήγηση στο σκοτεινό δάσος: προκλήσεις, ηθική και μελλοντικές προοπτικές

Η κατασκευή και η λειτουργία ενός bot διαιτησίας στο DeFi “Dark Forest” είναι μια απόδειξη της δύναμης των αποκεντρωμένων τεχνολογιών, αλλά φέρνει επίσης στο φως σημαντικές προκλήσεις και ηθικές εκτιμήσεις.

Η συνεχής μάχη ενάντια στους κακόβουλους ηθοποιούς: Ο ρόλος του Bloom

Η αρχική αισιοδοξία γύρω από την απαράδεκτη φύση του DeFi έχει δυστυχώς μετριαστεί από την εξάπλωση των κακόβουλων παραγόντων.Honeywall ServiceΛειτουργεί ως μια ζωτική τελευταία γραμμή άμυνας, αλλά η εφευρετικότητα αυτών των κακών παικτών απαιτεί συνεχώς εξελισσόμενα αντίμετρα.

Βασικό στοιχείο αυτής της άμυνας είναι ηBloom filterΈνα φίλτρο Bloom είναι μια δομή δεδομένων πιθανότητας που μπορεί να δοκιμάσει γρήγορα και αποτελεσματικά αν ένα στοιχείο είναι μέλος ενός συνόλου. Είναι εξαιρετικά αποδοτικό στο χώρο, αλλά φέρει μια μικρή πιθανότητα "ψευδών θετικών" (που δείχνει ότι ένα στοιχείο είναι στο σύνολο όταν δεν είναι), αν και ποτέ "ψευδών αρνητικών". Στο πλαίσιο μας, το φίλτρο Bloom χρησιμοποιείται για να προ-φιλτράρει εισερχόμενα δεδομένα συμβάντων από την υπηρεσία Blockchain Data Reader. Περιέχει hashes γνωστών κακόβουλων ή υψηλών φορολογικών ζευγαριών διευθύνσεων. Πριν από οποιαδήποτε λεπτομερή επεξεργασία ή ανάκτηση αποθεμάτων, ένας γρήγορος έλεγχος κατά του φίλτρου Bloom μπορεί να απορρίψει αμέσως γνω

Παρά τους εξελιγμένους προ-ελέγχους που εφαρμόζονται στο έθιμό μαςArbHelperMapΈξυπνο συμβόλαιο (ιδίως το_checkTaxLimit logic that simulates a round-trip swap to assess taxes), some malicious pairs still manage to bypass these initial on-chain validations. They achieve this by manipulating the getAmountsOutλειτουργία (που χρησιμοποιείται για τις ερωτήσεις τιμών) για να επιστρέψει φαινομενικά φυσιολογικές, χαμηλής φορολογίας εξόδους. Ωστόσο, η πραγματική λογική "honeypot" είναι ενσωματωμένη βαθύτερα μέσα στην πραγματικήswapExactTokensForTokensΗ υποκείμενηtransferΑυτές οι λειτουργίες ενδέχεται να επιβάλλουν υπερβολικούς κρυφούς φόρους (π.χ. 99%) στις πωλήσεις ή ακόμη και να περιορίζουν εντελώς τις πωλήσεις, παγιδεύοντας αποτελεσματικά τα κεφάλαια.

Κατά τη διάρκεια της φάσης δοκιμών μας, συναντήσαμε έναν σημαντικό αριθμό τέτοιων απατηλών ζευγαριών. έχω προσωπικά συλλέξει μερικά ζεύγη διευθύνσεων που πέρασαν με επιτυχία την αρχικήgetAmountsOutελέγχει, αλλά αποκάλυψε κρυμμένους φόρους ή περιορισμούς πώλησης μόνο κατά τη διάρκεια μιας πραγματικής (προσομοιωμένης ή αντιστρεφόμενης) συναλλαγής σε μια τοπική βάση δεδομένων. Αυτό το db αρχείο θα γίνει διαθέσιμο στο κοινό στο αποθετήριο GitHub του έργου, χρησιμεύοντας ως πόρος της κοινότητας για να βοηθήσει άλλους να αποφύγουν αυτές τις παγίδες.

Ηθικές επιπτώσεις και η σκιά του σκοτεινού δάσους

Η αναλογία του «Σκοτεινού Δάσους» είναι κατάλληλη όχι μόνο για τον ανταγωνισμό μεταξύ των bots, αλλά και για το ευρύτερο ηθικό τοπίο του DeFi. Η αποτελεσματικότητα της διαιτησίας, ενώ είναι κρίσιμη για την υγεία της αγοράς και την ανακάλυψη των τιμών, έρχεται με μια σκληρή πραγματικότητα: τα κέρδη που δημιουργούνται από τους διαιτητές συχνά αντιπροσωπεύουν αξία που προέρχεται από λιγότερο εξελιγμένους συμμετέχοντες στην αγορά.

Ο διαδεδομένος πολιτισμός τηςFOMO (Fear Of Missing Out), σε συνδυασμό με μια γενική έλλειψη κατανόησης των υποκείμενων μηχανισμών blockchain και χρηματοπιστωτικών μέσων, καθιστά πολλούς χρήστες λιανικής εύκολο να θύμα σε αυτό το περιβάλλον. εισέρχονται σε ιδιαίτερα μεταβλητές αγορές, αλληλεπιδρούν με νέα πρωτόκολλα και εκτελούν συναλλαγές χωρίς πλήρη επίγνωση των εννοιών όπως το slippage, MEV ή κρυφό φόρο σύμβασης.

Αυτή η δυναμική, αν και οικονομικά λογική για όσους διαθέτουν προηγμένα εργαλεία, ρίχνει μια σκιά στη φήμη των αποκεντρωμένων τεχνολογιών. Η αφήγηση μπορεί γρήγορα να μετατοπιστεί από την «χρηματοοικονομική ενδυνάμωση» σε «ληστρική συμπεριφορά», υπονομεύοντας την εμπιστοσύνη σε ένα χώρο που διαφορετικά κρατά τεράστια υπόσχεση. Το DeFi, στον πυρήνα του, στοχεύει στη δημοκρατικοποίηση της χρηματοδότησης, προσφέροντας μη εξουσιοδοτημένη πρόσβαση και διαφάνεια. Ωστόσο, η εξελιγμένη φύση του MEV και η επικράτηση των απάτων μπορούν ακούσια να υπονομεύσουν αυτά τα ιδανικά, δημιουργώντας ένα σύστημα δύο επιπέδων όπου μόνο οι τεχνολογ

Συμπέρασμα: Ακόμα πλοηγώντας στο σκοτεινό δάσος

Παρά τις εγγενείς πολυπλοκότητες και τις επίμονες προκλήσεις του τοπίου DeFi, το ταξίδι της μηχανικής αυτού του bot διαιτησίας ήταν μια αξιοσημείωτη επικύρωση των θεωρητικών αρχών που ανταποκρίνονται στην πρακτική εφαρμογή.speed, precision, and data-driven insights, ικανή να ανιχνεύσει και να εκτελέσει ευκαιρίες διαιτησίας πολλαπλών ποδιών.

Αρχικά, μια κοινή προσδοκία εντός του «Σκοτεινού Δάσους» ήταν ότι η συντριπτική πλειοψηφία της αξίας διαιτησίας θα αναχαιτιζόταν αμέσως από μεγάλους, καλά εξοπλισμένους παίκτες, αξιοποιώντας αυτο-διαχειριζόμενους κόμβους και άμεση πρόσβαση σε παραγωγούς μπλοκ.

Ενώ η κερδοφόρα διαιτησία σε παλαιότερα μοντέλα AMM όπως η Uniswap V2 (η οποία βασίζεται κυρίως σε σταθερές πισίνες προϊόντων) μπορεί να είναι δύσκολη για να διατηρηθεί μακροπρόθεσμα λόγω της κλιμάκωσης του κόστους του φυσικού αερίου και του αυξημένου ανταγωνισμού, το «σκοτεινό δάσος» συνεχίζει να εξελίσσεται. Οι νεότερες εφαρμογές, όπως οι Concentrated Liquidity AMMs (CLAMMs) της Uniswap V3, εισάγουν νέους φορείς διαιτησίας που απαιτούν πιο εξελιγμένα μοντέλα αλλά συχνά αποφέρουν υψηλότερες αποδόσεις λόγω αυξημένης αποδοτικότητας του κεφαλαίου. Επιπλέον, ο αναπτυσσόμενος τομέας της διαιτη

Έτσι, ενώ είμαι ακόμα φτωχός, μπορώ με σιγουριά να πω ότι έχω γίνει ένας εξαιρετικός δασικός ναυτικός.My compass is sharper, my map more detailed, and I understand the whispers of the canopy.

Αποθήκευση Προγράμματος

Για όσους επιθυμούν να βουτήξουν βαθύτερα στην πρακτική εφαρμογή και τα πολύ πραγματικά δεδομένα πίσω από μερικές από τις «παγίδες» που συζητήσαμε, μια εξυγίανση έκδοση της βάσης κώδικα μας και μια βάση δεδομένων γεμάτη με γνωστά ζεύγη κακόβουλων token είναι διαθέσιμα στο δικό μου.Αποθήκευση GitHubΑυτά τα 85 συγκεκριμένα ζεύγη, αν και αριθμητικά μικρά, δημιουργούν έναν δυσανάλογα σημαντικό όγκο συναλλαγών καθώς συνεχώς προσπαθούν να δελεάσουν αφελείς bots σε μη κερδοφόρες συναλλαγές.

Αναφορές

• Dan Robinson, Georgios Konstantopoulos: «Το Αιθέριο είναι ένα σκοτεινό δάσος».
• Guillermo Angeris, Hsien-Tang Kao, Rei Chiang, Charlie Noyes και Tarun Chitra. «Μια ανάλυση των αγορών Uniswap», Cryptoeconomic Systems.
• Claudio Gebbia, «Ανάλυση και εφαρμογή των bots διαιτησίας στην κεντρική και αποκεντρωμένη χρηματοδότηση», Πανεπιστήμιο της Ζυρίχης.
• Y. Zhang, Z. Li, T. Yan, Q. Liu, N. Vallarano και C. J. Tessone, «Μεγιστοποίηση του κέρδους σε κύκλους διαιτησίας».