Naar hoofdinhoud gaan
Change page

Transacties

Laatst bewerkt: @UNOFFICIALbgd(opens in a new tab), 16 juli 2024

Transacties zijn cryptografisch ondertekende instructies van accounts. Een account zal een transactie starten om de status van het Ethereum-netwerk bij te werken. De eenvoudigste transactie is het overmaken van ETH van het ene account naar het andere.

Randvoorwaarden

Om u te helpen om deze pagina beter te begrijpen, raden we u aan om eerst onze Accounts en onze inleiding tot Ethereum te lezen.

Wat is een transactie?

Een Ethereum-transactie verwijst naar een actie die gestart wordt door een account in externe eigendom, met andere woorden een account dat beheerd wordt door een mens, en niet door een contract. Als Bob bijvoorbeeld 1 ETH naar Alice stuurt, moet het account van Bob gedebiteerd worden en dat van Alice gecrediteerd. Deze actie waarbij de status wordt gewijzigd, vindt plaats binnen een transactie.

Diagram die een transactie toont die een statuswijziging veroorzaakt Aangepast diagram van Ethereum-EVM geïllustreerd(opens in a new tab)

Transacties die de toestand van de EVM veranderen, moeten naar het hele netwerk worden uitgezonden. Elke node kan een verzoek uitzenden om een transactie uit te voeren op de EVM; nadat dit is gebeurd, zal een validator de transactie uitvoeren en de resulterende statuswijziging verspreiden naar de rest van het netwerk.

Transacties vragen om een kost en moeten worden opgenomen in een gevalideerde block. Om dit overzicht eenvoudiger te maken, behandelen we de gaskosten en validatie ergens anders.

Een ingediende transactie bevat de volgende informatie:

  • from: het adres van de afzender die de transactie zal ondertekenen. Dit is een account in externe eigendom, aangezien contractaccounts geen transacties kunnen verzenden.
  • to: het ontvangende adres (als het een account in externe eigendom is, zal de transactie de waarde overdragen. Als het een contractaccount is, zal de transactie de contractcode uitvoeren)
  • signature: de identificator van de afzender. Dit wordt gegenereerd wanneer de persoonlijke sleutel van de afzender de transactie ondertekent en bevestigt dat de afzender deze transactie heeft geautoriseerd
  • nonce: een sequentieel oplopende teller die het transactienummer van het account aangeeft
  • value: hoeveelheid ETH over te dragen van afzender naar ontvanger (uitgedrukt in WEI, waarbij 1ETH gelijk is aan 1e+18wei)
  • input data: optioneel veld om willekeurige gegevens in te plaatsen
  • gasLimit: de maximale hoeveelheid gaseenheden die door de transactie kan worden verbruikt. De EVM specificeert de benodigde gaseenheden voor elke rekenstap
  • maxPriorityFeePerGas: de maximumprijs van het verbruikte gas dat als fooi aan de validator wordt gegeven
  • maxFeePerGas - de maximale kost per eenheid gas bereid te betalen voor de transactie (inclusief baseFeePerGas en maxPriorityFeePerGas)

Gas is een verwijzing naar de berekening die nodig is om de transactie te verwerken door een validator. Gebruikers moeten een kost betalen voor deze berekening. De gasLimit en maxPriorityFeePerGas bepalen de maximale transactiekost die aan de validator wordt betaald. Meer over gas.

Het transactie-object zal er ongeveer zo uitzien:

1{
2 from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
3 to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
4 gasLimit: "21000",
5 maxFeePerGas: "300",
6 maxPriorityFeePerGas: "10",
7 nonce: "0",
8 value: "10000000000"
9}
Toon alle
Kopiëren

Maar een transactie-object moet worden ondertekend met de persoonlijke sleutel van de afzender. Dit bewijst dat de transactie alleen van de afzender afkomstig kan zijn en niet frauduleus is verzonden.

Een Ethereum client zoals Geth zal dit ondertekeningsproces afhandelen.

Voorbeeld JSON-RPC call:

1{
2 "id": 2,
3 "jsonrpc": "2.0",
4 "method": "account_signTransaction",
5 "params": [
6 {
7 "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
8 "gas": "0x55555",
9 "maxFeePerGas": "0x1234",
10 "maxPriorityFeePerGas": "0x1234",
11 "input": "0xabcd",
12 "nonce": "0x0",
13 "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
14 "value": "0x1234"
15 }
16 ]
17}
Toon alle
Kopiëren

Voorbeeldreactie:

1{
2 "jsonrpc": "2.0",
3 "id": 2,
4 "result": {
5 "raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
6 "tx": {
7 "nonce": "0x0",
8 "maxFeePerGas": "0x1234",
9 "maxPriorityFeePerGas": "0x1234",
10 "gas": "0x55555",
11 "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
12 "value": "0x1234",
13 "input": "0xabcd",
14 "v": "0x26",
15 "r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e",
16 "s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
17 "hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e"
18 }
19 }
20}
Toon alle
Kopiëren
  • de raw is de ondertekende transactie in Recursive Length Prefix (RLP)-gecodeerde vorm
  • de tx is de ondertekende transactie in JSON-vorm

Met de hash van de handtekening kan cryptografisch bewezen worden dat de transactie afkomstig is van de afzender en ingediend is bij het netwerk.

Het dataveld

De overgrote meerderheid van de transacties heeft toegang tot een contract vanaf een account in externe eigendom. De meeste contracten zijn geschreven in Solidity en interpreteren hun gegevensveld in overeenstemming met de .

De eerste vier bytes geven aan welke functie moet worden opgeroepen, met behulp van de hash van de naam en argumenten van de functie. Soms kunt u de functie uit de selector identificeren met behulp van deze database(opens in a new tab).

De rest van de calldata zijn de argumenten, gecodeerd zoals aangegeven in de ABI-specificaties(opens in a new tab).

Laten we bijvoorbeeld eens kijken naar deze transactie(opens in a new tab). Gebruik Klik om meer te zien om de calldata te bekijken.

De functieselector is 0xa9059cbb. Er zijn verschillende bekende functies met deze handtekening(opens in a new tab). In dit geval is de contractbroncode(opens in a new tab) geüpload naar Etherscan, dus we weten dat de functie transfer(address,uint256) is.

De rest van de gegevens zijn:

10000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279
2000000000000000000000000000000000000000000000000000000003b0559f4

Volgens de ABI-specificaties verschijnen gehele waarden (zoals adressen, die gehele getallen van 20 bytes zijn) in de ABI als woorden van 32 bytes, opgevuld met nullen vooraan. We weten dus dat het to-adres 4f6742badb049791cd9a37ea913f2bac38d01279(opens in a new tab) is. De value is 0x3b0559f4 = 990206452.

Types transacties

Op Ethereum zijn er verschillende soorten transacties:

  • Reguliere transacties: een transactie van het ene account naar het andere.
  • Contractimplementatietransacties: een transactie zonder een 'to'-adres, waarbij het gegevensveld wordt gebruikt voor de contractcode.
  • Uitvoering van een contract: een transactie die interactie heeft met een ingezet smart contract. In dit geval is het 'to'-adres het smart contract-adres.

Over gas

Zoals gezegd, kosten transacties gas om uit te voeren. Eenvoudige overschrijvingstransacties vereisen 21.000 eenheden gas.

Dus als Bob 1 ETH zou sturen naar Alice met een baseFeePerGas van 190 gwei en een maxPriorityFeePerGas van 10 gwei, zal Bob de volgende kosten moeten betalen:

1(190 + 10) * 21000 = 4.200.000 gwei
2--of-
30,0042 ETH

Bob's account zal worden gedebiteerd met -1,0042 ETH (1 ETH voor Alice + 0,0042 ETH aan gaskosten)

Alice's account zal worden gecrediteerd met +1,0 ETH

De basiskost van -0,00399 ETH wordt verbrand

Validator houdt de fooi van +0,000210 ETH zelf bij

Schema dat toont hoe ongebruikt gas wordt terugbetaald Aangepast diagram van Ethereum-EVM geïllustreerd(opens in a new tab)

Gas dat niet wordt gebruikt in een transactie, wordt terugbetaald op het gebruikersaccount.

Smart contract-interactions

Gas is vereist voor elke transactie waar een smart contract bij betrokken is.

Smart contracts kunnen ook functies bevatten die bekend staan als view(opens in a new tab)- of pure(opens in a new tab) functies, die de status van het contract niet veranderen. Voor het aanroepen van deze functies vanuit een EOA is dus geen gas nodig. De onderliggende RPC-aanroep voor dit scenario is eth_call

In tegenstelling tot wanneer eth_call wordt gebruikt, worden deze view- of pure-functies ook vaak intern aangeroepen (d.w.z. vanuit het contract zelf of vanuit een ander contract), wat gas kost.

Transactielevenscyclus

Zodra de transactie is ingediend, gebeurt het volgende:

  1. Een transactie-hash wordt cryptografisch gegenereerd: 0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017
  2. De transactie wordt vervolgens uitgezonden naar het netwerk en toegevoegd aan een transactiepool die bestaat uit alle andere netwerktransacties die in behandeling zijn.
  3. Een validator moet uw transactie kiezen en in een block opnemen om de transactie te verifiëren en als “succesvol” te beschouwen.
  4. Na verloop van tijd wordt de block die uw transactie bevat geüpgraded naar “gerechtvaardigd” en vervolgens naar “gefinaliseerd”. Deze upgrades maken het veel zekerder dat uw transactie succesvol was en nooit zal worden gewijzigd. Als een block eenmaal “gefinaliseerd” is, kan het alleen worden veranderd door een aanval op netwerkniveau die vele miljarden dollars zou kosten.

Een visuele demo

Austin leidt u door transacties, gas en mining.

Getypte transactie-envelop

Ethereum had oorspronkelijk één formaat voor transacties. Elke transactie bevatte een nonce, gasprijs, gaslimiet, to-adres, waarde, gegevens, v, r en s. Deze velden zijn RLP-gecodeerd, om er ongeveer zo uit te zien:

RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])

Ethereum heeft zich ontwikkeld om meerdere soorten transacties te ondersteunen om nieuwe functies, zoals toegangslijsten en EIP-1559(opens in a new tab) te kunnen implementeren, zonder oudere transactieformaten te beïnvloeden.

EIP-2718(opens in a new tab) maakt dit gedrag mogelijk. Transacties worden geïnterpreteerd als:

TransactionType || TransactionPayload

Waar de velden worden gedefinieerd als:

  • TransactionType: een getal tussen 0 en 0x7f, voor een totaal van 128 mogelijke transactietypes.
  • TransactionPayload: een willekeurige byte array gedefinieerd door het transactietype.

Op basis van de waarde TransactionType kan een transactie worden geclassificeerd als

  1. Type 0 (oudere) transacties: het oorspronkelijke transactieformaat dat sinds de lancering van Ethereum wordt gebruikt. Ze bevatten geen functies uit EIP-1559(opens in a new tab) zoals dynamische berekeningen van gaskosten of toegangslijsten voor smart contracts. Oudere transacties hebben geen specifieke prefix die hun type aangeeft in hun seriële vorm, beginnend met de byte 0xf8 bij gebruik van Recursive Length Prefix (RLP)-codering. De TransactionType-waarde voor deze transacties is 0x0.

  2. Transacties van type 1: Sinds EIP-2930(opens in a new tab) geïntroduceerd als onderdeel van de Berlin-upgrade van Ethereum, bevatten deze transacties een accessList-parameter. Deze lijst geeft adressen en opslagsleutels aan waartoe de transactie toegang verwacht te krijgen, wat helpt om mogelijk de gaskosten te verminderen voor complexe transacties waarbij smart contracts betrokken zijn. De marktwijzigingen voor EIP-1559-kosten zijn niet opgenomen in transacties van type 1. Transacties van type 1 bevatten ook een yParity-parameter, die 0x0 of 0x1 kan zijn, waarmee de pariteit van de y-waarde van de secp256k1-handtekening wordt aangegeven. Ze worden geïdentificeerd door te beginnen met de byte 0x01, en hun TransactionType-waarde is 0x1.

  3. Transacties van type 2, ook wel EIP-1559-transacties genoemd, zijn transacties geïntroduceerd in EIP-1559(opens in a new tab), in de London-upgrade van Ethereum. Ze zijn het standaard transactietype geworden op het Ethereum-netwerk. Deze transacties introduceren een nieuw kostenmarktmechanisme waardoor de voorspelbaarheid wordt verbeterd door de transactiekosten te splitsen in een basiskost en een prioriteitskost. Ze beginnen met de byte 0x02 en bevatten velden zoals maxPriorityFeePerGas en maxFeePerGas. Transacties van type 2 zijn nu standaard dankzij hun flexibiliteit en efficiëntie, en zijn vooral interessant tijdens periodes van hoge netwerkcongestie omdat ze gebruikers helpen om transactiekosten voorspelbaarder te beheren. De TransactionType-waarde voor deze transacties is 0x2.

Verder lezen

Weet je van een community resource die je heeft geholpen? Bewerk deze pagina en voeg het toe!

  • Accounts
  • Ethereum virtuele machine (EVM)
  • Brandstof

Was dit artikel nuttig?