Transacciones

Las transacciones son instrucciones firmadas criptográficamente desde las cuentas. Una cuenta iniciará una transacción para actualizar el estado de la red Ethereum. La transacción más sencilla es transferir ETH de una cuenta a otra.

Requisitos previos

Para ayudarle a comprender mejor esta página, le recomendamos que lea primero Cuentas y nuestra introducción a Ethereum.

¿Qué es una transacción?

Una transacción de Ethereum hace referencia a una acción iniciada por una cuenta de titularidad externa, en otras palabras, una cuenta administrada por una persona, no un contrato. Por ejemplo, si Bob le envía 1 ETH a Alice, este debe adeudarse de la cuenta de Bob y acreditarse en la cuenta de Alice. Esta acción según la que se modifica el estado de la red tiene lugar en una transacción.

Diagrama adaptado de Ethereum EVM illustratedopens in a new tab

Las transacciones, que modifican el estado de la EVM, se deben transmitir a toda la red. Cualquier nodo puede transmitir una solicitud para que se ejecute una transacción en la EVM; después de que esto suceda, un validador ejecutará la transacción y propagará el cambio de estado resultante al resto de la red.

Las transacciones requieren una tarifa y deben incluirse en un bloque validado. Para simplificar este resumen, abarcaremos las comisiones de gas y el minado por separado.

Una transacción enviada incluye la siguiente información:

from: la dirección del remitente que firmará la transacción. Esta será una cuenta de titularidad externa, ya que las cuentas contractuales no pueden enviar transacciones
to: la dirección de recepción (si es una cuenta de propiedad externa, la transacción transferirá valor. Si se trata de un contrato, la transacción ejecutará el código del contrato).
signature: el identificador del remitente. Se genera cuando la clave privada del remitente firma la transacción y confirma que el remitente ha autorizado esta transacción.
nonce: un contador que se incrementa secuencialmente y que indica el número de transacción de la cuenta.
value: la cantidad de ETH que se transferirá del remitente al destinatario (denominada en WEI, donde 1 ETH equivale a 1e+18 wei).
input data: campo opcional para incluir datos arbitrarios.
gasLimit: la cantidad máxima de unidades de gas que puede consumir la transacción. La EVM especifica las unidades de gas necesarias para cada paso computacional.
maxPriorityFeePerGas: el precio máximo del gas consumido que se incluirá como propina para el validador.
maxFeePerGas: la tarifa máxima por unidad de gas que se está dispuesto a pagar por la transacción (incluye baseFeePerGas y maxPriorityFeePerGas).

El gas es una referencia al cálculo necesario para que el validador procese la transacción. Los usuarios tienen que pagar una tarifa por ese cálculo. El gasLimit y maxPriorityFeePerGas determinan la comisión máxima de la transacción que se paga al validador. Más sobre el gas.

El objeto de la transacción se verá de la siguiente forma:

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

Es necesario firmar este objeto mediante la clave privada del emisor. De esta forma, se demuestra que la transacción solo pudo haberla enviado el emisor y que no se envió de forma fraudulenta.

Un cliente de Ethereum como Geth gestionará el proceso de firma.

Ejemplo de llamada JSON-RPC:

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}
Mostrar todo

Ejemplo de respuesta:

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}
Mostrar todo

raw es la transacción firmada en formato codificado de prefijo de longitud recursiva (RLP).
la propiedad tx es la transacción firmada en formato JSON.

Mediante el hash de la firma, se puede demostrar criptográficamente que la transacción proviene del emisor y que se envió a la red.

El campo de datos

La gran mayoría de las transacciones acceden a un contrato desde una cuenta de titularidad externa. La mayoría de los contratos se escriben en Solidity e interpretan su campo de datos de acuerdo con la .

Los primeros cuatro bytes especifican qué función de llamar, usando el hash del nombre y los argumentos de la función. A veces puede identificar la función desde el selector utilizando esta base de datosopens in a new tab.

El resto de los datos de la llamada (calldata) son los argumentos, codificados como se especifica en las especificaciones de la ABIopens in a new tab.

Por ejemplo, echemos un vistazo a esta transacciónopens in a new tab. Haga clic en Click to see More para ver los datos de la llamada (calldata).

El selector de función es 0xa9059cbb. Hay varias funciones conocidas con esta firmaopens in a new tab. En este caso, el código fuente del contratoopens in a new tab se ha subido a Etherscan, por lo que sabemos que la función es transfer(address,uint256).

El resto de los datos es:

10000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279
2000000000000000000000000000000000000000000000000000000003b0559f4

De acuerdo con las especificaciones ABI, valores enteros (como direcciones, que son enteros de 20 bytes) aparecen en el ABI como palabras de 32 bytes, agregadas con ceros en el frente. Así que sabemos que la dirección to es 4f6742badb049791cd9a37ea913f2bac38d01279opens in a new tab. El value es 0x3b0559f4 = 990206452.

Tipos de transacciones

En Ethereum hay algunos tipos diferentes de transacciones:

Transacciones regulares: una transacción desde una cartera a otra.
Transacciones de despliegue de contratos: una transacción sin la dirección «a», donde el campo de datos se usa para el código de contrato.
Ejecución de un contrato: una transacción que interactúa con un contrato inteligente desplegado. En este caso, la dirección «a» es la dirección de contrato inteligente.

Sobre el gas

Como se ha mencionado, las transacciones cuestan gas para ejecutarse. Las transacciones de transferencia simple requieren 21.000 unidades de gas.

Así que, para que Bob envíe 1 ETH a Alice con una baseFeePerGas de 190 gwei y una maxPriorityFeePerGas de 10 gwei, Bob tendrá que pagar la siguiente comisión:

1(190 + 10) * 21000 = 4,200,000 gwei
2--o--
30,0042 ETH

Se cargará en la cuenta de Bob -1,0042 ETH (1 ETH para Alice + 0,0042 ETH en comisiones de gas).

Se abonará en la cuenta de Alice +1,0 ETH.

La tarifa base se quemará -0,00399 ETH.

El validador se queda con la propina +0,000210 ETH.

Diagrama adaptado de Ethereum EVM illustratedopens in a new tab

Cualquier gas no utilizado en una transacción se reembolsa a la cuenta de usuario.

Interacciones de los contratos inteligentes

Se requiere gas para cualquier transacción que involucre un contrato inteligente.

Los contratos inteligentes también pueden contener funciones conocidas como funciones viewopens in a new tab o pureopens in a new tab, que no alteran el estado del contrato. Como tal, invocar estas funciones desde una EOA no requerirá gas. La llamada RPC subyacente para este escenario es eth_call.

A diferencia de cuando se accede mediante eth_call, estas funciones view o pure también se suelen llamar internamente (es decir, desde el propio contrato o desde otro contrato), lo que sí cuesta gas.

Ciclo de vida de una transacción

Una vez enviada la transacción ocurre lo siguiente:

Un hash de transacción se genera criptográficamente: 0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017
Luego, la transacción se transmite a la red y se añade a un grupo de transacciones que consta de todas las demás transacciones que estan pendientes en la red.
Un validador debe elegir su transacción e incluirla en un bloque para verificarla antes de considerarla «satisfactoria».
A medida que pasa el tiempo, el bloque que contiene su transacción se actualizará a «justificado» y luego a «finalizado». Estas actualizaciones hacen que sea mucho más seguro que su transacción se haya realizado correctamente y que nunca se vaya a alterar. Una vez que un bloque está «finalizado», solo se puede cambiar mediante un ataque a nivel de red que costaría miles de millones de dólares.

Una demostración visual

Observe a Austin mientras le guía por las transacciones, el gas y la minería.

Sobre de transacción con tipo

Inicialmente, Ethereum tenía un formato único para las transacciones. Cada transacción contenía un nonce, un precio de gas, un límite de gas, una dirección, un importe, datos, v, r y s. Estos campos están codificados en RLP y tienen un aspecto similar a este:

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

Ethereum ha evolucionado para admitir múltiples tipos de transacciones, lo que permite que se implementen nuevas características como listas de acceso y EIP-1559opens in a new tab sin afectar a los formatos de transacción heredados.

EIP-2718opens in a new tab es lo que permite este comportamiento. Las transacciones se interpretan como:

Tipo de transacción || Cargaútiltransacción

Donde los campos indican:

TransactionType: un número entre 0 y 0x7f, para un total de 128 tipos de transacción posibles.
TransactionPayload: un array de bytes arbitrario definido por el tipo de transacción.

Según el valor de TransactionType, una transacción se puede clasificar como:

Transacciones de tipo 0 (heredadas): el formato de transacción original utilizado desde el lanzamiento de Ethereum. No incluyen características de EIP-1559opens in a new tab, como cálculos dinámicos de las comisiones de gas o listas de acceso para los contratos inteligentes. Las transacciones heredadas carecen de un prefijo específico que indique su tipo en su forma serializada y empiezan con el byte 0xf8 cuando se utiliza la codificación de prefijo de longitud recursiva (RLP). El valor de TransactionType para estas transacciones es 0x0.
Transacciones de tipo 1: introducidas en el EIP-2930opens in a new tab como parte de la actualización Berlín de Ethereum, estas transacciones incluyen un parámetro accessList. Esta lista especifica las direcciones y las claves de almacenamiento a las que la transacción espera acceder, lo que ayuda a reducir potencialmente los costes de gas para transacciones complejas que involucran contratos inteligentes. Los cambios en el mercado de tarifas de EIP-1559 no se incluyen en las transacciones de Tipo 1. Las transacciones de tipo 1 también incluyen un parámetro yParity, que puede ser 0x0 o 0x1, lo que indica la paridad del valor y de la firma secp256k1. Se identifican porque empiezan con el byte 0x01, y su valor de TransactionType es 0x1.
Las transacciones de tipo 2, comúnmente conocidas como transacciones EIP-1559, son transacciones introducidas en el EIP-1559opens in a new tab, en la actualización London de Ethereum. Se han convertido en el tipo de transacción estándar en la red Ethereum. Estas transacciones introducen un nuevo mecanismo de mercado de tarifas que mejora la previsibilidad separando la tarifa de transacción en una tarifa base y una tarifa prioritaria. Empiezan con el byte 0x02 e incluyen campos como maxPriorityFeePerGas y maxFeePerGas. Las transacciones de Tipo 2 son ahora las predeterminadas debido a su flexibilidad y eficiencia, especialmente favorecidas durante los períodos de alta congestión de la red por su capacidad para ayudar a los usuarios a gestionar las tarifas de transacción de manera más predecible. El valor de TransactionType para estas transacciones es 0x2.
Las transacciones de tipo 3 (blob) se introdujeron en el EIP-4844opens in a new tab como parte de la actualización Dencun de Ethereum. Estas transacciones están diseñadas para manejar datos «blob» (objetos grandes binarios) de manera más eficiente, beneficiando particularmente a los rollups de capa 2 al proporcionar una forma de publicar datos en la red Ethereum a un coste menor. Las transacciones de blob incluyen campos adicionales como blobVersionedHashes, maxFeePerBlobGas y blobGasPrice. Empiezan con el byte 0x03 y su valor de TransactionType es 0x3. Las transacciones de Blob representan una mejora significativa en la disponibilidad de datos y las capacidades de escalabilidad de Ethereum.
Las transacciones de tipo 4 se introdujeron en el EIP-7702opens in a new tab como parte de la actualización Pectra de Ethereum. Estas transacciones están diseñadas para ser compatibles con la abstracción de cuentas. Permiten que las EOA se comporten temporalmente como cuentas de contratos inteligentes sin comprometer su funcionalidad original. Incluyen un parámetro authorization_list, que especifica el contrato inteligente al que la EOA delega su autoridad. Después de la transacción, el campo de código de la EOA tendrá la dirección del contrato inteligente delegado.

Lecturas adicionales

EIP-2718: Sobre de transacción con tipoopens in a new tab

¿Conoce algún recurso de la comunidad que le haya sido de ayuda? ¡Edite esta página y agréguela!