Транзакції

Транзакції — це криптографічно підписані інструкції з рахунків. Акаунт буде ініціювати транзакцію для оновлення стану мережі Ethereum. Найпростіша транзакція це переведення ETH з одного акаунту на інший.

Передумови

Щоб краще зрозуміти цю сторінку, радимо спочатку прочитати статті Облікові записи та Вступ до Ethereum.

Що таке транзакція?

Транзакція Ethereum - це дія, яка здійснюється на зовнішньому акаунті, іншими словами, акаунт керується людиною, а не контрактом. Наприклад, якщо Боб надсилає Алісі 1 ETH, з акаунту Боба він списується, на Алісин акаунт - нараховується. Така дія, пов'язана зі зміною стану, відбувається в рамках транзакції.

Схема адаптована з Ethereum EVM illustrated (opens in a new tab)

Транзакції, які змінюють стан EVM повинні транслюватись по всій мережі. Будь-який вузол може транслювати запит на виконання транзакції на EVM; після цього валідатор виконає транзакцію і поширить отриману зміну стану на решту мережі.

Транзакції вимагають комісії і повинні бути включені в підтверджений блок. Щоб зробити цей огляд простішим, ми розглянемо плату за газ та валідацію в іншому місці.

Подана транзакція містить таку інформацію:

from — адреса відправника, що підписуватиме транзакцію. Це буде зовнішній рахунок, оскільки контрактні рахунки не можуть надсилати транзакції
to — адреса одержувача (якщо це обліковий запис зовнішнього власника, транзакція передасть вартість. У випадку контрактного акаунту, транзакція буде виконувати код реалізації контракту)
signature — ідентифікатор відправника. Він генерується, коли приватний ключ відправника підписує транзакцію і підтверджує, що відправник авторизував цю транзакцію
nonce — лічильник, що послідовно збільшується та вказує номер транзакції з облікового запису
value — сума ETH для переказу від відправника до одержувача (номінована у WEI, де 1 ETH дорівнює 1e+18wei)
input data — необов’язкове поле для включення довільних даних
gasLimit — максимальна кількість одиниць газу, які може спожити транзакція. EVM визначає кількість одиниць газу, необхідну для кожного обчислювального кроку
maxPriorityFeePerGas — максимальна ціна спожитого газу, що включається як чайові для валідатора
maxFeePerGas — максимальна комісія за одиницю газу, яку ви готові сплатити за транзакцію (включаючи baseFeePerGas та maxPriorityFeePerGas)

Gas - це посилання на обчислення, необхідні для обробки транзакції валідатором. Користувачі повинні сплачувати збір за це обчислення. gasLimit і maxPriorityFeePerGas визначають максимальну комісію за транзакцію, що сплачується валідатору. Докладніше про газ.

Об'єкт транзакції буде виглядати приблизно так:

1{
2  from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
3  to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
4  gasLimit: "21000",
5  maxFeePerGas: "300",
6  maxPriorityFeePerGas: "10",
7  nonce: "0",
8  value: "10000000000"
9}
Показати все

Об'єкт транзакції повинен увійти, використовуючи секретний ключ відправника. Це доводить, що транзакція могла бути ініційована відправником та не була шахрайством.

Клієнт Ethereum, до прикладу, Geth буде обробляти процес входу.

Приклад виклику 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}
Показати все

Приклад відповіді:

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}
Показати все

raw — це підписана транзакція в закодованій формі Recursive Length Prefix (RLP).
tx — це підписана транзакція у форматі JSON.

За допомогою хешу підпису транзакція може бути криптографічно доведена, що вона відправлена від відправника в мережу.

Поле даних

Переважна більшість транзакцій отримує доступ до контракту з зовнішнього облікового запису. Більшість контрактів написані мовою Solidity й інтерпретують своє поле даних відповідно до .

Перші чотири байти вказують, яку функцію викликати, використовуючи хеш імені функції та аргументів. Іноді ви можете ідентифікувати функцію за селектором за допомогою цієї бази даних (opens in a new tab).

Решта calldata — це аргументи, закодовані відповідно до специфікацій ABI (opens in a new tab).

Наприклад, погляньмо на цю транзакцію (opens in a new tab). Натисніть Click to see More, щоб побачити дані виклику (calldata).

Селектор функції — 0xa9059cbb. Існує кілька відомих функцій із таким підписом (opens in a new tab). У цьому випадку вихідний код контракту (opens in a new tab) було завантажено на Etherscan, тому ми знаємо, що функція має вигляд transfer(address,uint256).

Решта даних є:

10000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279
2000000000000000000000000000000000000000000000000000000003b0559f4

Відповідно до специфікацій ABI, цілі значення (наприклад, адреси, які є 20-байтовими цілими числами) з'являються в ABI у вигляді 32-байтових слів, доповнених нулями спереду. Отже, ми знаємо, що адреса to — 4f6742badb049791cd9a37ea913f2bac38d01279 (opens in a new tab). Значення value — 0x3b0559f4 = 990206452.

Типи транзакцій

В Ethereum є декілька різних видів транзакцій:

Регулярні транзакції: транзакція з одного рахунку на інший.
Договірне розгортання транзакцій: транзакція без "кому" адреси, де поле даних використовується для контрактного коду.
Виконання контракту: транзакція, яка взаємодіє з розгорнутим смарт-контрактом. У цьому випадку адреса "to" - це адреса смарт-контракту.

Про газ

Як уже згадувалося, для виконання транзакцій потрібен газ. Проста транзакція потребує 21000 одиниць газу.

Отже, щоб Боб надіслав Алісі 1 ETH за baseFeePerGas 190 gwei та maxPriorityFeePerGas 10 gwei, Бобу потрібно буде сплатити таку комісію:

1(190 + 10) * 21000 = 4,200,000 gwei
2--або--
30.0042 ETH

З облікового запису Боба буде списано -1,0042 ETH (1 ETH для Аліси + 0,0042 ETH як комісія за газ).

На обліковий запис Аліси буде зараховано +1,0 ETH.

Базову комісію буде спалено: -0,00399 ETH.

Валідатор отримує чайові: +0,000210 ETH.

Схема адаптована з Ethereum EVM illustrated (opens in a new tab)

Будь-який газ, що не використовується під час транзакції повертається на рахунок користувача.

Взаємодії зі смарт-контрактами

Газ потрібен для будь-якої транзакції, що стосується смарт-контракту.

Смарт-контракти також можуть містити функції, відомі як функції view (opens in a new tab) або pure (opens in a new tab), які не змінюють стан контракту. Таким чином, виклик цих функцій з EOA не потребуватиме газу. Базовим RPC-викликом для цього сценарію є eth_call.

На відміну від доступу за допомогою eth_call, ці функції view або pure також часто викликаються внутрішньо (тобто з самого контракту або з іншого контракту), що потребує газу.

Життєвий цикл транзакції

Після того, як транзакція була надіслана, відбувається наступне:

Хеш транзакції генерується криптографічно: 0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017
Потім транзакція транслюється в мережу і додається до пулу транзакцій, що складається з усіх інших очікуваних мережевих транзакцій.
Валідатор повинен вибрати вашу транзакцію і включити її в блок, щоб перевірити транзакцію і вважати її "успішною".
З часом блок, що містить вашу транзакцію, буде змінено на "виправданий", а потім на "завершений". Ці оновлення значно підвищують упевненість у тому, що ваша транзакція була успішною й ніколи не буде змінена. Щойно блок буде «фіналізовано», його можна буде змінити лише за допомогою атаки на рівні мережі, яка коштуватиме багато мільярдів доларів.

Наочна демонстрація

Дивись, Austin, що проведе тебе через транзакції, газ та майнінг.

Типізований конверт транзакції

Спочатку Ethereum мав один формат транзакцій. Кожна транзакція містила нонс, ціну газу, газовий ліміт, адресу "кому", вартість, дані v, r, та s. Ці поля кодуються за допомогою RLP, і мають приблизно такий вигляд:

RLP([нонс, ціна газу, ліміт, кому, вартість, дані, v, r, s])

Ethereum розвинувся для підтримки кількох типів транзакцій, щоб дозволити впроваджувати нові функції, як-от списки доступу та EIP-1559 (opens in a new tab), не впливаючи на застарілі формати транзакцій.

EIP-2718 (opens in a new tab) — це те, що уможливлює таку поведінку. Транзакції інтерпретуються як:

TransactionType || TransactionPayload

Де поля визначені як:

TransactionType — число від 0 до 0x7f, що дає загалом 128 можливих типів транзакцій.
TransactionPayload — довільний масив байтів, що визначається типом транзакції.

На основі значення TransactionType транзакцію можна класифікувати як:

Транзакції типу 0 (застарілі): оригінальний формат транзакцій, що використовується з моменту запуску Ethereum. Вони не включають функції з EIP-1559 (opens in a new tab), як-от динамічний розрахунок комісії за газ або списки доступу для смарт-контрактів. Застарілі транзакції не мають певного префікса, що вказує на їхній тип у серіалізованій формі, починаючись із байта 0xf8 під час використання кодування Recursive Length Prefix (RLP). Значення TransactionType для цих транзакцій становить 0x0.
Транзакції типу 1: введені в EIP-2930 (opens in a new tab) як частина оновлення Berlin мережі Ethereum, ці транзакції включають параметр accessList. Цей список визначає адреси та ключі сховища, до яких транзакція має отримати доступ, що потенційно допомагає зменшити витрати на газ для складних транзакцій за участю смарт-контрактів. Зміни ринку комісій EIP-1559 не включені в транзакції типу 1. Транзакції типу 1 також включають параметр yParity, який може бути 0x0 або 0x1, що вказує на парність значення y підпису secp256k1. Вони ідентифікуються за початковим байтом 0x01, а їхнє значення TransactionType становить 0x1.
Транзакції типу 2, які часто називають транзакціями EIP-1559, — це транзакції, представлені в EIP-1559 (opens in a new tab) в оновленні London мережі Ethereum. Вони стали стандартним типом транзакцій у мережі Ethereum. Ці транзакції запроваджують новий механізм ринку комісій, який покращує передбачуваність шляхом розділення комісії за транзакцію на базову комісію та пріоритетну комісію. Вони починаються з байта 0x02 і включають такі поля, як maxPriorityFeePerGas і maxFeePerGas. Транзакції типу 2 тепер є стандартними завдяки своїй гнучкості та ефективності, особливо в періоди високого навантаження на мережу, оскільки вони допомагають користувачам більш передбачувано керувати комісіями за транзакції. Значення TransactionType для цих транзакцій становить 0x2.
Транзакції типу 3 (з BLOB-об'єктами) були введені в EIP-4844 (opens in a new tab) як частина оновлення Dencun мережі Ethereum. Ці транзакції призначені для більш ефективної обробки даних-«блобів» (великих двійкових об’єктів, BLOBs), що особливо вигідно для ролапів другого рівня (Layer 2), оскільки надає спосіб публікувати дані в мережі Ethereum за нижчою ціною. Транзакції з BLOB-об'єктами включають додаткові поля, як-от blobVersionedHashes, maxFeePerBlobGas і blobGasPrice. Вони починаються з байта 0x03, а їхнє значення TransactionType становить 0x3. Транзакції з BLOB-об'єктами є значним покращенням доступності даних і можливостей масштабування Ethereum.
Транзакції типу 4 були введені в EIP-7702 (opens in a new tab) як частина оновлення Pectra мережі Ethereum. Ці транзакції розроблені для прямої сумісності з абстракцією облікових записів. Вони дозволяють EOA тимчасово поводитися як облікові записи смарт-контрактів, не порушуючи їхньої початкової функціональності. Вони включають параметр authorization_list, який визначає смарт-контракт, якому EOA делегує свої повноваження. Після транзакції поле коду EOA міститиме адресу делегованого смарт-контракту.

Для подальшого читання

EIP-2718: Типізований конверт транзакції (opens in a new tab)

Знайшли ресурс, який допоміг з цією темою? Відредагуйте цю сторінку і додайте його!