Geheime Technik der DeFi-Arbitrage-Bots. So packen Sie alles in eine einzige Transaktion

Arbitrage-Bots sind komplexe und effektive Instrumente, die Ihnen passives Einkommen generieren können. Mit dem Wachstum des DeFi-Raums wurden sie immer beliebter. Um jedoch profitabel zu sein, sollten Sie Best Practices befolgen und typische Fehler vermeiden. Normalerweise bestehen DeFi-Handelsbots aus diesen Komponenten: Off-Chain-Skript, das Liquiditätspools überwacht und Arbitragemöglichkeiten findet On-Chain-Vertrag - intelligenter Vertrag, der Arbitrage-Logik enthält Hot Wallet - hält Vermögenswerte für Arbitragezwecke und nimmt Gewinne mit

Stellen Sie sich vor, das Off-Chain-Skript hat irgendwo im DeFi-Bereich eine profitable Arbitrage-Möglichkeit gefunden und Sie müssen diese vor Ihren Mitbewerbern nutzen. Die Arbitrage muss innerhalb einer einzigen Transaktion erfolgen, sonst verschwenden Sie viel Zeit und verlieren wahrscheinlich den Kampf gegen andere Bots. Bei typischer Arbitrage handelt es sich um Operationen mit ETH- und ERC-20-Tokens. Die erste Idee, die mir in den Sinn kommt, ist daher, einen Smart-Contract im Einsatz zu haben, der vorab bereitgestellt und mit Tokens finanziert wird, und wann immer die Arbitrage-Möglichkeit gefunden wird, löst das Skript die Transaktion aus spezifische Parameter Dieser Ansatz ist naiv und hat gravierende Nachteile: Sie müssen Ihren Vertrag vorab bereitstellen und Gasgebühren zahlen - aber was ist, wenn sich nie eine Gelegenheit dazu findet - dann verlieren Sie die Gasgebühren, die Sie für die Bereitstellung bezahlt haben - das könnte im Ehtereum-Hauptnetz eine Menge sein Sie müssen Ihre Verträge im Voraus mit ERC-20-Tokens finanzieren und sie eine Zeit lang behalten lassen - das stellt ein Sicherheitsrisiko dar, da Sie Ihren Vertrag sorgfältig prüfen müssen, um sicherzustellen, dass niemand ihn hacken und Ihre Vermögenswerte stehlen kann - viel Es ist einfacher, sich nur um Ihren privaten Schlüssel zu kümmern, wenn Ihr Geld in einer Hot Wallet und nicht in einem Vertrag gesperrt ist Nach der Bereitstellung kann jeder Ihren Vertrag lesen und Ihre Logik stehlen, um sie für eigene Arbitrage-Bots wiederzuverwenden, die mit Ihren konkurrieren

Hier ist eine bessere Strategie Idealerweise möchten Sie ETH- und ERC-20-Token auf Ihrem Hot Wallet behalten und Ihren Smart-Contract-Code außerhalb der Kette halten, bis sich eine Arbitragemöglichkeit ergibt Sobald Ihr Bot eine Arbitrage-Möglichkeit gefunden hat, muss er einen Smart Contract bereitstellen, ihn mit ETH- und ERC-20-Token finanzieren, die Arbitrage durchführen und den Gewinn zurück in die Hot Wallet übertragen Alle diese Aktionen müssen innerhalb einer einzigen Transaktion durchgeführt werden

Denken Sie daran, dass die Bereitstellung eine Transaktion verursacht, was bedeutet, dass die gesamte Logik innerhalb des Konstruktors ausgeführt werden muss. Wir können während der Bereitstellung einen Vertrag mit der ETH finanzieren, aber die Übertragung von ERC-20-Tokens ist ein schwieriger Teil. Es gibt zwei Möglichkeiten, ERC-20s zu übertragen: Übertragen und Genehmigen. Beide Methoden erforderten eine zusätzliche Transaktion zum Token-Vertrag, bei dem der Absender Token-Inhaber ist. Aber wir haben nur eine Transaktion, die bereits für die Bereitstellung verwendet wird, was bedeutet, dass die Tokenübertragung innerhalb des Konstruktors erfolgen muss, um unsere Arbitrage in eine einzelne Transaktion zu integrieren. Wie kann man das also ermöglichen? Die Lösung ist der neue Token-Standard EIP-2616 - er enthält eine Genehmigungsfunktion , die eine digitale Signatur verwendet und eine gaslose Token-Übertragung ermöglicht. Viele Token unterstützen diesen Standard bereits. Als ich zum ersten Mal darauf stieß, als ich einen Tausch an der 1-Zoll- Börse durchführte, war ich überrascht, dass ich eine Unterschriftsanfrage anstelle einer Genehmigungstransaktion sah und fing an, weiter zu stöbern, um die neue Methode der Ausgabengenehmigung zu entdecken. Hier ist ein weiterer Artikel, der erklärt, wie es funktioniert: https://www.quicknode.com/guides/ethereum-development/transactions/how-to-use-erc20-permit-approval/ Mit EIP-2616 können wir die neue Strategie für Token-Transfer und Arbitrage innerhalb einer einzelnen Transaktion nutzen: Hot Wallet bereitet die Signatur für die Genehmigungsfunktion vor - dies erfolgt außerhalb der Kette und erstellt keine Transaktion Die Signatur wird als Argument an den Konstruktor übergeben Innerhalb des Konstruktors ruft der Smart-Contract die Funktion „permit" auf, dann die Funktion „ transferFrom " und erhält den Besitz über die Token Logik für Arbitrage wird ausgeführt Der Gewinn wird zurück in die Hot Wallet übertragen

Hot Wallets müssen also nur eine einzige Transaktion einreichen - Vertragsbereitstellung mit den richtigen Parametern, und sobald es abgebaut ist, wird der Gewinn mitgenommen. Es gibt jedoch ein Problem - werfen wir einen Blick auf die Schnittstelle der Zulassungsfunktion : /**

• @dev Setzt „value" als Zulage des „Spenders" gegenüber den Token des „Eigentümers",

• vorausgesetzt die unterschriebene Genehmigung des „Eigentümers".

• WICHTIG: Die gleichen Probleme, die {IERC20-approve} im Zusammenhang mit der Transaktion *-Bestellung hat, gelten auch hier.

• Gibt ein {Approval}-Ereignis aus.

• Anforderungen:

• – „Spender" darf nicht die Nulladresse sein.

• – „Frist" muss ein Zeitstempel in der Zukunft sein.

• – „v", „r" und „s" müssen eine gültige „secp256k1"-Signatur von „owner"

• über die EIP712-formatierten Funktionsargumente sein.

• – Die Signatur muss die aktuelle Nonce des „Besitzers" verwenden (siehe {Nonces}).

• Weitere Informationen zum Signaturformat finden Sie im Abschnitt

• https://eips.ethereum.org/EIPS/eip-2612#pecification[relevanter EIP *]. */ Funktionserlaubnis ( Adressbesitzer, Adressgeber, uint256 - Wert, uint256-Frist, uint8 v, bytes32 r, bytes32 s ) external

; Wie wir sehen, müssen wir die Adresse eines Spenders angeben - aber in unserem Fall handelt es sich bei dem Spender um einen Vertrag, der noch bereitgestellt werden muss! Woher sollen wir wissen, an welcher Adresse sich der Vertrag nach der Bereitstellung befindet? Glücklicherweise werden Vertragsadressen auf der Grundlage der Adresse des Bereitstellers und der Nonce des Bereitstellers vorab festgelegt. Hier ist ein Thread zu Stackexchange, der erklärt, wie Vertragsadressen in EVM berechnet werden: https://ethereum.stackexchange.com/questions/760/how-is-the-address-of-an-ethereum-contract-computed/761# 761 Hier ist JS-Code, der die Vertragsadresse vor der Bereitstellung basierend auf der Adresse und Nonce des Bereitstellers vorhersagt: const rlp = require ( "rlp" ); const keccak = require ( "keccak" ); asynchrone Funktion PredictContractAddress ( Deployer ) { const nonce = Warten auf Ether. Anbieter . getTransactionCount (Deployer. Adresse ); const sender = Deployer. Adresse ; const input_arr = [sender, nonce]; const rlp_encoded = rlp. kodieren (input_arr); consttract_address_long = keccak( „keccak256" ) . aktualisieren (rlp_encoded) . verdauen ( "hex" ); const Contract_address = Contract_address_long. Teilzeichenfolge ( 24 ); //Die ersten 24 Zeichen kürzen. return vertragsadresse; } Jetzt haben wir alle Daten, um die Signatur für die Ausgabengenehmigung vorzubereiten, und können sie an den Erbauer weitergeben. Hier ist der vollständige Code für das Skript, das auf Hardhat ausgeführt wird: asynchrone Funktion doArbitrage ( Deployer, Wert, TokenBalance, ...params ) { const chainId = ( Warte auf Ethers. Anbieter . getNetwork ()). ChainId ; // setze die Domänenparameter const domain = { name : waiting token. Name (), Version : „1" , ChainId : ChainId, Verifizierungsvertrag : Token. Adresse }; // Setze die Parameter des Permit-Typs consttypes = { Permit : { name }; const PredictedAddress =

Warten auf PredictContractAddress (Bereitsteller); Konsole . log ( "Vorhergesagte Adresse: " + vorhergesagte Adresse); const Deadline = ( Wartezeit abwarten . spätestens ()) + 9999999 ; const- Werte = { Eigentümer : Bereitsteller. Adresse , Spender : vorhergesagte Adresse, Wert : TokenBalance, Nonce : Warten auf Token. Nonces (Deployer. Adresse ), Frist : Frist, }; const Signatur = WartenBereitsteller. _signTypedData (Domäne, Typen, Werte); const sig = Ether. Dienstprogramme . splitSignature (Signatur); const ArbitrageContract = Wait ( Await Ethers. GetContractFactory ( 'Arbitrage' , Deployer)). Deploy (...params, sig. v , sig. r , sig. s , { value }); Konsole . log ( Tatsächliche Adresse: ${arbitrageContract.address} ); } Und der Code des Smart-Contract-Konstruktors: import „@openzeppelin/contracts/interfaces/IERC2612.sol" ; import „@openzeppelin/contracts/utils/Address.sol" ; Vertrag Arbitrage { Verwendung der Adresse für die zahlbare Adresse; Konstruktor ( /* Parameter für Arbitrage */ , Adresse _token, uint256 tokenBalance, uint256 _deadline, uint8 v, bytes32 r, bytes32 s) payable { IERC2612 token = IERC2612 (_token); Zeichen. erlauben ( msg.sender, Adresse (dieses), tokenBalance, _deadline, v, r, s ); Zeichen. transferFrom (msg.sender, Adresse (dies), tokenBalance); // Jetzt hat der Vertrag Token und ETH und Sie können hier Ihre Arbitrage durchführen // ... Token. transfer (msg.sender, token. balanceOf ( address (this))); // Token zurück an Hot Wallet Payable senden (msg.sender). sendValue ( Adresse (dieses).balance); // ETH zurück an Hot Wallet schicken } } Und vergessen Sie nicht, Flashbots RPC anstelle von Infura zu verwenden , um Ihre Arbitrage-Transaktionen vor Front-Running zu schützen

🌟 Eine Initiative, um die Web3-Bildung für die nächste Generation  zugänglicher zu machen. 🌟 🌟 Feel free to check out:  my.bio/blockliv3 Social Media: @blockliv3 E-Mail: [blockliv3.nft@ud.me

Geheime Technik der DeFi-Arbitrage-Bots. So packen Sie alles in eine einzige Transaktion

Arbitrage-Bots sind komplexe und effektive Instrumente, die Ihnen passives Einkommen generieren können. Mit dem Wachstum des DeFi-Raums wurden sie immer beliebter. Um jedoch profitabel zu sein, sollten Sie Best Practices befolgen und typische Fehler vermeiden. Normalerweise bestehen DeFi-Handelsbots aus diesen Komponenten: Off-Chain-Skript, das Liquiditätspools überwacht und Arbitragemöglichkeiten findet On-Chain-Vertrag - intelligenter Vertrag, der Arbitrage-Logik enthält Hot Wallet - hält Vermögenswerte für Arbitragezwecke und nimmt Gewinne mit

Stellen Sie sich vor, das Off-Chain-Skript hat irgendwo im DeFi-Bereich eine profitable Arbitrage-Möglichkeit gefunden und Sie müssen diese vor Ihren Mitbewerbern nutzen. Die Arbitrage muss innerhalb einer einzigen Transaktion erfolgen, sonst verschwenden Sie viel Zeit und verlieren wahrscheinlich den Kampf gegen andere Bots. Bei typischer Arbitrage handelt es sich um Operationen mit ETH- und ERC-20-Tokens. Die erste Idee, die mir in den Sinn kommt, ist daher, einen Smart-Contract im Einsatz zu haben, der vorab bereitgestellt und mit Tokens finanziert wird, und wann immer die Arbitrage-Möglichkeit gefunden wird, löst das Skript die Transaktion aus spezifische Parameter Dieser Ansatz ist naiv und hat gravierende Nachteile: Sie müssen Ihren Vertrag vorab bereitstellen und Gasgebühren zahlen - aber was ist, wenn sich nie eine Gelegenheit dazu findet - dann verlieren Sie die Gasgebühren, die Sie für die Bereitstellung bezahlt haben - das könnte im Ehtereum-Hauptnetz eine Menge sein Sie müssen Ihre Verträge im Voraus mit ERC-20-Tokens finanzieren und sie eine Zeit lang behalten lassen - das stellt ein Sicherheitsrisiko dar, da Sie Ihren Vertrag sorgfältig prüfen müssen, um sicherzustellen, dass niemand ihn hacken und Ihre Vermögenswerte stehlen kann - viel Es ist einfacher, sich nur um Ihren privaten Schlüssel zu kümmern, wenn Ihr Geld in einer Hot Wallet und nicht in einem Vertrag gesperrt ist Nach der Bereitstellung kann jeder Ihren Vertrag lesen und Ihre Logik stehlen, um sie für eigene Arbitrage-Bots wiederzuverwenden, die mit Ihren konkurrieren

Hier ist eine bessere Strategie Idealerweise möchten Sie ETH- und ERC-20-Token auf Ihrem Hot Wallet behalten und Ihren Smart-Contract-Code außerhalb der Kette halten, bis sich eine Arbitragemöglichkeit ergibt Sobald Ihr Bot eine Arbitrage-Möglichkeit gefunden hat, muss er einen Smart Contract bereitstellen, ihn mit ETH- und ERC-20-Token finanzieren, die Arbitrage durchführen und den Gewinn zurück in die Hot Wallet übertragen Alle diese Aktionen müssen innerhalb einer einzigen Transaktion durchgeführt werden

Denken Sie daran, dass die Bereitstellung eine Transaktion verursacht, was bedeutet, dass die gesamte Logik innerhalb des Konstruktors ausgeführt werden muss. Wir können während der Bereitstellung einen Vertrag mit der ETH finanzieren, aber die Übertragung von ERC-20-Tokens ist ein schwieriger Teil. Es gibt zwei Möglichkeiten, ERC-20s zu übertragen: Übertragen und Genehmigen. Beide Methoden erforderten eine zusätzliche Transaktion zum Token-Vertrag, bei dem der Absender Token-Inhaber ist. Aber wir haben nur eine Transaktion, die bereits für die Bereitstellung verwendet wird, was bedeutet, dass die Tokenübertragung innerhalb des Konstruktors erfolgen muss, um unsere Arbitrage in eine einzelne Transaktion zu integrieren. Wie kann man das also ermöglichen? Die Lösung ist der neue Token-Standard EIP-2616 - er enthält eine Genehmigungsfunktion , die eine digitale Signatur verwendet und eine gaslose Token-Übertragung ermöglicht. Viele Token unterstützen diesen Standard bereits. Als ich zum ersten Mal darauf stieß, als ich einen Tausch an der 1-Zoll- Börse durchführte, war ich überrascht, dass ich eine Unterschriftsanfrage anstelle einer Genehmigungstransaktion sah und fing an, weiter zu stöbern, um die neue Methode der Ausgabengenehmigung zu entdecken. Hier ist ein weiterer Artikel, der erklärt, wie es funktioniert: https://www.quicknode.com/guides/ethereum-development/transactions/how-to-use-erc20-permit-approval/ Mit EIP-2616 können wir die neue Strategie für Token-Transfer und Arbitrage innerhalb einer einzelnen Transaktion nutzen: Hot Wallet bereitet die Signatur für die Genehmigungsfunktion vor - dies erfolgt außerhalb der Kette und erstellt keine Transaktion Die Signatur wird als Argument an den Konstruktor übergeben Innerhalb des Konstruktors ruft der Smart-Contract die Funktion „permit" auf, dann die Funktion „ transferFrom " und erhält den Besitz über die Token Logik für Arbitrage wird ausgeführt Der Gewinn wird zurück in die Hot Wallet übertragen

Hot Wallets müssen also nur eine einzige Transaktion einreichen - Vertragsbereitstellung mit den richtigen Parametern, und sobald es abgebaut ist, wird der Gewinn mitgenommen. Es gibt jedoch ein Problem - werfen wir einen Blick auf die Schnittstelle der Zulassungsfunktion : /**

• @dev Setzt „value" als Zulage des „Spenders" gegenüber den Token des „Eigentümers",

• vorausgesetzt die unterschriebene Genehmigung des „Eigentümers".

• WICHTIG: Die gleichen Probleme, die {IERC20-approve} im Zusammenhang mit der Transaktion *-Bestellung hat, gelten auch hier.

• Gibt ein {Approval}-Ereignis aus.

• Anforderungen:

• – „Spender" darf nicht die Nulladresse sein.

• – „Frist" muss ein Zeitstempel in der Zukunft sein.

• – „v", „r" und „s" müssen eine gültige „secp256k1"-Signatur von „owner"

• über die EIP712-formatierten Funktionsargumente sein.

• – Die Signatur muss die aktuelle Nonce des „Besitzers" verwenden (siehe {Nonces}).

• Weitere Informationen zum Signaturformat finden Sie im Abschnitt

• https://eips.ethereum.org/EIPS/eip-2612#pecification[relevanter EIP *]. */ Funktionserlaubnis ( Adressbesitzer, Adressgeber, uint256 - Wert, uint256-Frist, uint8 v, bytes32 r, bytes32 s ) external

; Wie wir sehen, müssen wir die Adresse eines Spenders angeben - aber in unserem Fall handelt es sich bei dem Spender um einen Vertrag, der noch bereitgestellt werden muss! Woher sollen wir wissen, an welcher Adresse sich der Vertrag nach der Bereitstellung befindet? Glücklicherweise werden Vertragsadressen auf der Grundlage der Adresse des Bereitstellers und der Nonce des Bereitstellers vorab festgelegt. Hier ist ein Thread zu Stackexchange, der erklärt, wie Vertragsadressen in EVM berechnet werden: https://ethereum.stackexchange.com/questions/760/how-is-the-address-of-an-ethereum-contract-computed/761# 761 Hier ist JS-Code, der die Vertragsadresse vor der Bereitstellung basierend auf der Adresse und Nonce des Bereitstellers vorhersagt: const rlp = require ( "rlp" ); const keccak = require ( "keccak" ); asynchrone Funktion PredictContractAddress ( Deployer ) { const nonce = Warten auf Ether. Anbieter . getTransactionCount (Deployer. Adresse ); const sender = Deployer. Adresse ; const input_arr = [sender, nonce]; const rlp_encoded = rlp. kodieren (input_arr); consttract_address_long = keccak( „keccak256" ) . aktualisieren (rlp_encoded) . verdauen ( "hex" ); const Contract_address = Contract_address_long. Teilzeichenfolge ( 24 ); //Die ersten 24 Zeichen kürzen. return vertragsadresse; } Jetzt haben wir alle Daten, um die Signatur für die Ausgabengenehmigung vorzubereiten, und können sie an den Erbauer weitergeben. Hier ist der vollständige Code für das Skript, das auf Hardhat ausgeführt wird: asynchrone Funktion doArbitrage ( Deployer, Wert, TokenBalance, ...params ) { const chainId = ( Warte auf Ethers. Anbieter . getNetwork ()). ChainId ; // setze die Domänenparameter const domain = { name : waiting token. Name (), Version : „1" , ChainId : ChainId, Verifizierungsvertrag : Token. Adresse }; // Setze die Parameter des Permit-Typs consttypes = { Permit : { name }; const PredictedAddress =

Warten auf PredictContractAddress (Bereitsteller); Konsole . log ( "Vorhergesagte Adresse: " + vorhergesagte Adresse); const Deadline = ( Wartezeit abwarten . spätestens ()) + 9999999 ; const- Werte = { Eigentümer : Bereitsteller. Adresse , Spender : vorhergesagte Adresse, Wert : TokenBalance, Nonce : Warten auf Token. Nonces (Deployer. Adresse ), Frist : Frist, }; const Signatur = WartenBereitsteller. _signTypedData (Domäne, Typen, Werte); const sig = Ether. Dienstprogramme . splitSignature (Signatur); const ArbitrageContract = Wait ( Await Ethers. GetContractFactory ( 'Arbitrage' , Deployer)). Deploy (...params, sig. v , sig. r , sig. s , { value }); Konsole . log ( Tatsächliche Adresse: ${arbitrageContract.address} ); } Und der Code des Smart-Contract-Konstruktors: import „@openzeppelin/contracts/interfaces/IERC2612.sol" ; import „@openzeppelin/contracts/utils/Address.sol" ; Vertrag Arbitrage { Verwendung der Adresse für die zahlbare Adresse; Konstruktor ( /* Parameter für Arbitrage */ , Adresse _token, uint256 tokenBalance, uint256 _deadline, uint8 v, bytes32 r, bytes32 s) payable { IERC2612 token = IERC2612 (_token); Zeichen. erlauben ( msg.sender, Adresse (dieses), tokenBalance, _deadline, v, r, s ); Zeichen. transferFrom (msg.sender, Adresse (dies), tokenBalance); // Jetzt hat der Vertrag Token und ETH und Sie können hier Ihre Arbitrage durchführen // ... Token. transfer (msg.sender, token. balanceOf ( address (this))); // Token zurück an Hot Wallet Payable senden (msg.sender). sendValue ( Adresse (dieses).balance); // ETH zurück an Hot Wallet schicken } } Und vergessen Sie nicht, Flashbots RPC anstelle von Infura zu verwenden , um Ihre Arbitrage-Transaktionen vor Front-Running zu schützen

🌟 Eine Initiative, um die Web3-Bildung für die nächste Generation  zugänglicher zu machen. 🌟 🌟 Feel free to check out:  my.bio/blockliv3 Social Media: @blockliv3 E-Mail: [blockliv3.nft@ud.me