Transfert Eth

Les transactions ETH sont généralement comprises comme des transactions de transfert, mais cette compréhension est relativement étroite. La transaction mentionnée ici est une transaction au sens large.

Initiateur de la transaction : principalement deux types

1. Node sert, geth contrôle aussi.
2. L'invocation de services de nœud fait principalement référence aux clients pour lesquels geth fournit des interfaces RPC, telles que des portefeuilles.

Classification des transactions : principalement deux types

1. Opération de transfert ETH
2. Autres transactions, y compris les transactions de transfert non limitées au jeton ERC20.

Interface RPC liée aux transactions : eth_sendTransaction et eth_sendRawTransaction

Ces deux fonctions se distinguent par le fait que l'appelant doit signer manuellement le paramètre final

1. eth_sendTransaction : cette fonction n'est utilisée que pour les transferts ETH. La signature finale des paramètres n'a pas besoin d'être effectuée manuellement par l'appelant. Il utilisera la clé privée déverrouillée de l'adresse ETH de l'initiateur du nœud actuel pour signer, donc il doit être appelé à chaque fois.Lorsque la fonction effectue un transfert ETH, l'adresse d'origine doit d'abord être déverrouillée.
2. eth_sendRawTransaction : une fonction de transaction qui demande à l'appelant d'utiliser la clé privée de from pour signer les données de paramètre. Les transactions de transfert de jeton ERC20 actuelles utilisent cette fonction. Cette fonction peut également être utilisée pour le transfert ETH, mais le transfert d'ETH est principalement contrôlé par des paramètres.

Relation entre les transactions et les contrats intelligents

Au départ, il y a une compréhension étroite de la transaction, qui fait référence à la transaction (transfert) du contrat intelligent.
Alors, quelle est la relation entre la transaction généralisée et la transaction étroite ?
Tout d'abord, la transaction de transfert appelle d'abord l'interface RPC eth_sendRawTransaction et transmet les paramètres requis par la transaction de transfert au nœud. Une fois que le nœud a obtenu les données, il extrait chaque champ de données, qui contient le paramètre de données de eth_sendRawTransaction, et les données est une chaîne de caractères hexadécimaux , le contenu qui la compose contient methodId , qui correspond à la valeur nommée de la fonction de transfert.
Ensuite, recherchez le contrat intelligent en fonction du paramètre to, puis recherchez la fonction qui y fait référence en fonction du methodId des données, et enfin exécutez la fonction en fonction des paramètres des données, tels que vers qui transférer et combien transfert.
Une fois la fonction exécutée, quel que soit le succès ou l'échec de l'exécution, une valeur de hachage de transaction (le nom complet est "Transaction Hash", txHash en abrégé) sera renvoyée

Explication des paramètres de transaction

1. De
représente l'adresse à partir de laquelle la transaction est initiée. Si le destinataire de la transaction est uniquement l'adresse du contrat, la variable msg.sender dans le code du contrat représente l'adresse de départ de cette adresse.
2.to
représente l'adresse de réception de la transaction en cours. Notez que l'adresse de réception ne peut pas être comprise comme l'adresse de réception, car il existe trois situations pour la valeur de to :

1. L'adresse du smart contract
   La transaction actuellement envoyée sera remise au smart contract correspondant pour traitement, le principe est le même que le transfert ERC20. Ainsi, lors du transfert de jetons ERC20, doit être l'adresse du contrat intelligent.
2. L'adresse du portefeuille des utilisateurs ETH ordinaires
   est le transfert ETH ordinaire, et to est l'adresse de réception.
3. Si la valeur est vide, la transaction actuelle est une transaction qui crée un contrat intelligent,
   ce qui signifie que la transaction actuelle est une transaction qui déploie un contrat intelligent sur la chaîne.

3.value : valeur de transfert
(1) Lors de l'utilisation de eth_sendRawTransaction pour transférer le jeton ERC20, la valeur doit être 0.
(2) Lors du transfert du jeton ERC20, la valeur à transférer est définie dans le paramètre de données.
(3) Dans Lors de l'utilisation de eth_sendRawTransaction pour transférer de l'argent, la valeur doit avoir une valeur, et cette valeur est $10^{}$Une grande valeur sous la forme${}^1$${}^8$$2\ast 10^{18.}$ Lors de l'utilisation de eth_sendRawTransaction pour les transactions de transfert ETH, il y a 3 points ànoter${}^{:}$

1. devrait être l'adresse du portefeuille destinataire
2. correspond à la valeur de ETH, pas 0.
3. Le paramètre data est une chaîne vide.

4. gas
Ce gaz est gasLimit, mais GasUser est utilisé lorsque la transaction est réussie. Lorsque la transaction est réussie, les frais de gaz supplémentaires seront retournés et la partie retournée est (gasLimit - GasUser)*gasPrice.

5. gasPrice
est le prix unitaire, l'unité est wei, qui est une valeur dynamique.

6. Le
numéro de séquence de transaction nonce est ce qui empêche les doubles dépenses.

7.data
C'est un paramètre relativement important, non seulement utilisé dans l'interface de transaction, mais également utilisé dans eth_call.
Le format des données doit répondre aux exigences :

1. format hexadécimal

0xa9059cbb0000000000000000000000007198ef99ac39c713ea1e333db4dc46c8b4413bf100000000000000000000000000000000000000000000000000000002cb417800

2. Comme ci-dessus, les 10 premiers caractères, y compris 0x, sont methodId. Sa méthode de génération est plus compliquée. Il est obtenu en signant le nom de la fonction de contrat, en chiffrant un nombre spécifique d'octets via Keccak256, puis en le convertissant en hexadécimal. Voici le code pour générer methodId selon la norme de version ETH :

func (method Method) Id() []bety{
    
    
	return crypto.Keccak256([]byte(mothod.Sig()))[:4]
}

Il existe deux methodIds correspondant à des fonctions communes :

• Équilibre de la requête : balanceOf est 0x70a08231
• Transfert : le transfert est 0xa9059cbb

3. Les caractères après les 10 premiers remplissent les conditions suivantes

• Représente les paramètres de la fonction dans le contrat intelligent
• La méthode de tri est organisée dans l'ordre des paramètres du contrat
• sous forme hexadécimale
• 0x n'est pas autorisé, c'est-à-dire qu'il faut d'abord convertir au format hexadécimal, puis supprimer le caractère 0x
• Après avoir supprimé 0x, le nombre de caractères pour chaque paramètre est de 64

举个栗子：
onMethod(arg1,arg2,....)
data的格式应该是
methodId + hex64(arg1) + hex64(arg2) + hex64(arg3) + ....

eth_sendTransaction({
    
    from:"0x...", to:"0x...",value=某数值)
最少三个参数

sendTransaction a été encapsulé par ETH. Il ne peut être utilisé que pour transférer ETH. C'est essentiellement le même que sendRawTranscation. Pour le sendTransaction encapsulé, les données à ce moment sont définies comme informations auxiliaires pour lancer la transaction, semblable à une note.

L'état de la transaction (cycle de vie)

Un total de quatre états

1. Unkonw (état inconnu) : il n'a pas été placé dans le pool de transactions txPool ETH. À l'heure actuelle, selon txHash, il n'y a aucune information à utiliser pour interroger le navigateur de blocs.
2. En attente (état d'attente ou d'attente) : à ce stade, selon txHash, vous pouvez utiliser le navigateur de blocs pour interroger, et vous pouvez interroger une partie des informations de transaction
3. Réussite (statut de réussite) : la transaction est réussie et toute information sur la transaction peut être interrogée à l'aide du navigateur de blocs selon txHash
4. Échec (état de l'échec) : la transaction a échoué, et les informations sur l'échec et la raison de l'échec ont été trouvées en interrogeant le navigateur de blocs selon txHash

En raison de l'influence de la taille du pool ETH, certains ordres ne seront placés que dans le pool de transactions et n'ont pas encore été négociés.Cet état est appelé Unkwon (état de position).
La raison en est que l'algorithme de tri des ordres de négociation du monnayeur dans le pool d'échange est affecté par GasPrice. Les commandes avec un GasPrice élevé évinceront les commandes avec un GasPrice bas, ce qui peut faire en sorte qu'une commande soit en attente tout le temps, et peut être mis en attente pendant plusieurs jours, voire plus. (cette situation a été rencontrée)

conditionnement des transactions

ASTUCE : Lorsque le Minter emballe une transaction, l'étape de "re-vérification de la transaction" comporte une étape de calcul des frais de gaz de transaction à l'intérieur, et le processus de calcul du gaz EVM.