--- title: "Транзакції" description: "Огляд транзакцій Етеріуму — як вони працюють, їхня структура даних та як їх надсилати через застосунок." lang: uk --- Транзакції — це криптографічно підписані інструкції від акаунтів. Акаунт ініціює транзакцію для оновлення стану мережі [Етеріум](/). Найпростіша транзакція — це переказ ETH з одного акаунта на інший. ## Передумови {#prerequisites} Щоб краще зрозуміти цю сторінку, ми рекомендуємо спочатку прочитати про [Акаунти](/developers/docs/accounts/) та наш [вступ до Етеріуму](/developers/docs/intro-to-ethereum/). ## Що таке транзакція? {#whats-a-transaction} Транзакція в Етеріумі — це дія, ініційована зовнішнім акаунтом (externally-owned account, EOA), іншими словами, акаунтом, яким керує людина, а не контракт. Наприклад, якщо Боб надсилає Алісі 1 ETH, з акаунта Боба має бути списано кошти, а на акаунт Аліси — зараховано. Ця дія, що змінює стан, відбувається в межах транзакції. ![Diagram showing a transaction cause state change](./tx.png) _Діаграму адаптовано з [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ Транзакції, які змінюють стан EVM, мають бути трансльовані на всю мережу. Будь-який вузол може транслювати запит на виконання транзакції у віртуальній машині Етеріуму (EVM); після цього валідатор виконає транзакцію та поширить отриману зміну стану на решту мережі. Транзакції вимагають комісії та мають бути включені у валідований блок. Щоб зробити цей огляд простішим, ми розглянемо комісії за газ та валідацію в іншому місці. Надіслана транзакція містить таку інформацію: - `from` — адреса відправника, який підписуватиме транзакцію. Це буде зовнішній акаунт, оскільки акаунти контрактів не можуть надсилати транзакції - `to` — адреса отримувача (якщо це зовнішній акаунт, транзакція перекаже цінність. Якщо це акаунт контракту, транзакція виконає код контракту) - `signature` — ідентифікатор відправника. Він генерується, коли приватний ключ відправника підписує транзакцію та підтверджує, що відправник авторизував цю транзакцію - `nonce` — лічильник, що послідовно збільшується та вказує номер транзакції з акаунта (нонс) - `value` — сума ETH для переказу від відправника до отримувача (номінована у Wei, де 1 ETH дорівнює 1e+18 Wei) - `input data` — необов'язкове поле для включення довільних даних - `gasLimit` — максимальна кількість одиниць газу, яка може бути спожита транзакцією (ліміт газу). [EVM](/developers/docs/evm/opcodes) визначає одиниці газу, необхідні для кожного обчислювального кроку - `maxPriorityFeePerGas` — максимальна ціна спожитого газу, яка буде включена як пріоритетна комісія валідатору - `maxFeePerGas` — максимальна комісія за одиницю газу, яку готові сплатити за транзакцію (включно з `baseFeePerGas` та `maxPriorityFeePerGas`) Газ — це посилання на обчислення, необхідні для обробки транзакції валідатором. Користувачі повинні сплачувати комісію за ці обчислення. `gasLimit` та `maxPriorityFeePerGas` визначають максимальну комісію за транзакцію, що сплачується валідатору. [Детальніше про газ](/developers/docs/gas/). Об'єкт транзакції виглядатиме приблизно так: ```js { from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8", to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a", gasLimit: "21000", maxFeePerGas: "300", maxPriorityFeePerGas: "10", nonce: "0", value: "10000000000" } ``` Але об'єкт транзакції має бути підписаний за допомогою приватного ключа відправника. Це доводить, що транзакція могла надійти лише від відправника і не була надіслана шахрайським шляхом. Клієнт Етеріуму, такий як Geth, оброблятиме цей процес підписання. Приклад виклику [JSON-RPC](/developers/docs/apis/json-rpc): ```json { "id": 2, "jsonrpc": "2.0", "method": "account_signTransaction", "params": [ { "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db", "gas": "0x55555", "maxFeePerGas": "0x1234", "maxPriorityFeePerGas": "0x1234", "input": "0xabcd", "nonce": "0x0", "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0", "value": "0x1234" } ] } ``` Приклад відповіді: ```json { "jsonrpc": "2.0", "id": 2, "result": { "raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663", "tx": { "nonce": "0x0", "maxFeePerGas": "0x1234", "maxPriorityFeePerGas": "0x1234", "gas": "0x55555", "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0", "value": "0x1234", "input": "0xabcd", "v": "0x26", "r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e", "s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663", "hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e" } } } ``` - `raw` — це підписана транзакція у закодованій формі [Recursive Length Prefix (RLP)](/developers/docs/data-structures-and-encoding/rlp) - `tx` — це підписана транзакція у форматі JSON За допомогою хешу підпису можна криптографічно довести, що транзакція надійшла від відправника та була надіслана в мережу. ### Поле даних {#the-data-field} Переважна більшість транзакцій звертається до контракту із зовнішнього акаунта. Більшість контрактів написані на Solidity та інтерпретують своє поле даних відповідно до [двійкового інтерфейсу застосунку (ABI)](/glossary/#abi). Перші чотири байти вказують, яку функцію викликати, використовуючи хеш імені функції та її аргументів. Іноді ви можете ідентифікувати функцію за селектором, використовуючи [цю базу даних](https://www.4byte.directory/signatures/). Решта даних виклику — це аргументи, [закодовані відповідно до специфікацій ABI](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding). Наприклад, розглянемо [цю транзакцію](https://etherscan.io/tx/0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1). Використайте **Click to see More**, щоб побачити дані виклику. Селектор функції — `0xa9059cbb`. Існує кілька [відомих функцій із цим підписом](https://www.4byte.directory/signatures/?bytes4_signature=0xa9059cbb). У цьому випадку [вихідний код контракту](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code) було завантажено на Etherscan, тому ми знаємо, що це функція `transfer(address,uint256)`. Решта даних: ``` 0000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279 000000000000000000000000000000000000000000000000000000003b0559f4 ``` Відповідно до специфікацій ABI, цілочисельні значення (наприклад, адреси, які є 20-байтовими цілими числами) з'являються в ABI як 32-байтові слова, доповнені нулями спереду. Отже, ми знаємо, що адреса `to` — це [`4f6742badb049791cd9a37ea913f2bac38d01279`](https://etherscan.io/address/0x4f6742badb049791cd9a37ea913f2bac38d01279). `value` дорівнює 0x3b0559f4 = 990206452. ### Дескриптори транзакцій {#transaction-descriptors} Оскільки поле даних містить непрозорі шістнадцяткові байти, може бути вкрай важко перевірити, яку саме дію насправді виконає транзакція. Ця вразливість «сліпого підписання» вирішується за допомогою **[прозорого підписання (Clear Signing)](https://clearsigning.org/)** через використання [дескрипторів транзакцій](https://eips.ethereum.org/EIPS/eip-7730) (визначених у ERC-7730). Специфікація ERC-7730 використовує дескриптори транзакцій (часто структуровані як файли JSON) для збагачення даних, що містяться в ABI та структурованих повідомленнях, таких як дані виклику транзакцій EVM, повідомлення EIP-712 та операції користувача EIP-4337. Розробники використовують ці дескриптори для відображення конкретних змінних транзакції безпосередньо в шаблони форматування, гарантуючи, що базові дані залишаються машинозчитуваними для застосунків. На фронтенді гаманці використовують цей контекст форматування для перекладу непрозорого байт-коду в зрозумілу, зручну для читання людиною інформацію. Завдяки автоматичному перетворенню значень, таких як адреси токенів, у розпізнані тикери, або сум у десяткові дроби, користувачам надається зрозумілий опис точного наміру транзакції (наприклад, «Обмін 1000 USDC на щонайменше 0.25 WETH») перед тим, як вони її підпишуть. ## Типи транзакцій {#types-of-transactions} В Етеріумі існує кілька різних типів транзакцій: - Звичайні транзакції: транзакція з одного акаунта на інший. - Транзакції розгортання контракту: транзакція без адреси «to» (кому), де поле даних використовується для коду контракту. - Виконання контракту: транзакція, яка взаємодіє з розгорнутим смарт-контрактом. У цьому випадку адреса «to» — це адреса смарт-контракту. ### Про газ {#on-gas} Як уже згадувалося, виконання транзакцій коштує [газу](/developers/docs/gas/). Прості транзакції переказу вимагають 21000 одиниць газу. Отже, щоб Боб надіслав Алісі 1 ETH за `baseFeePerGas` (базової комісії) 190 Gwei та `maxPriorityFeePerGas` (пріоритетної комісії) 10 Gwei, Бобу доведеться сплатити таку комісію: ``` (190 + 10) * 21000 = 4,200,000 Gwei --або-- 0.0042 ETH ``` З акаунта Боба буде списано **-1.0042 ETH** (1 ETH для Аліси + 0.0042 ETH комісії за газ) На акаунт Аліси буде зараховано **+1.0 ETH** Базова комісія буде спалена **-0.00399 ETH** Валідатор залишає собі пріоритетну комісію **+0.000210 ETH** ![Diagram showing how unused gas is refunded](./gas-tx.png) _Діаграму адаптовано з [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ Будь-який газ, не використаний у транзакції, повертається на акаунт користувача. ### Взаємодія зі смарт-контрактами {#smart-contract-interactions} Газ потрібен для будь-якої транзакції, яка залучає смарт-контракт. Смарт-контракти також можуть містити функції, відомі як [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) або [`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions), які не змінюють стан контракту. Таким чином, виклик цих функцій із зовнішнього акаунта (EOA) не вимагатиме газу. Базовим викликом RPC для цього сценарію є [`eth_call`](/developers/docs/apis/json-rpc#eth_call). На відміну від доступу за допомогою `eth_call`, ці функції `view` або `pure` також часто викликаються внутрішньо (тобто з самого контракту або з іншого контракту), що вимагає витрат газу. ## Життєвий цикл транзакції {#transaction-lifecycle} Після надсилання транзакції відбувається таке: 1. Криптографічно генерується хеш транзакції: `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017` 2. Потім транзакція транслюється в мережу та додається до пулу транзакцій, що складається з усіх інших мережевих транзакцій, які очікують на виконання. 3. Валідатор має вибрати вашу транзакцію та включити її в блок, щоб перевірити транзакцію та вважати її «успішною». 4. З часом блок, що містить вашу транзакцію, буде оновлено до статусу «обґрунтований», а потім — «фіналізований». Ці оновлення дають набагато більшу впевненість у тому, що ваша транзакція була успішною і ніколи не буде змінена. Щойно блок стає «фіналізованим», його можна змінити лише за допомогою атаки на рівні мережі, яка коштуватиме багато мільярдів доларів. ## Візуальна демонстрація {#a-visual-demo} Подивіться, як Остін розповідає про транзакції, газ та майнінг. ## Типізований конверт транзакції {#typed-transaction-envelope} Спочатку Етеріум мав один формат для транзакцій. Кожна транзакція містила нонс, ціну газу, ліміт газу, адресу отримувача (to), суму (value), дані (data), v, r та s. Ці поля [кодуються за допомогою RLP](/developers/docs/data-structures-and-encoding/rlp/) і виглядають приблизно так: `RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])` Етеріум еволюціонував для підтримки кількох типів транзакцій, щоб дозволити впровадження нових функцій, таких як списки доступу та [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), без впливу на застарілі формати транзакцій. [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) — це те, що уможливлює таку поведінку. Транзакції інтерпретуються як: `TransactionType || TransactionPayload` Де поля визначаються як: - `TransactionType` — число від 0 до 0x7f, загалом 128 можливих типів транзакцій. - `TransactionPayload` — довільний масив байтів, визначений типом транзакції. На основі значення `TransactionType` транзакцію можна класифікувати як: 1. **Транзакції типу 0 (застарілі):** Оригінальний формат транзакцій, що використовується з моменту запуску Етеріуму. Вони не включають функції з [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), такі як динамічні розрахунки комісії за газ або списки доступу для смарт-контрактів. Застарілі транзакції не мають спеціального префікса, що вказує на їхній тип у серіалізованій формі, і починаються з байта `0xf8` при використанні кодування [Recursive Length Prefix (RLP)](/developers/docs/data-structures-and-encoding/rlp). Значення TransactionType для цих транзакцій — `0x0`. 2. **Транзакції типу 1:** Представлені в [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) як частина оновлення [Берлін](/ethereum-forks/#berlin) в Етеріумі, ці транзакції включають параметр `accessList`. Цей список визначає адреси та ключі сховища, до яких транзакція очікує отримати доступ, допомагаючи потенційно зменшити витрати [газу](/developers/docs/gas/) для складних транзакцій за участю смарт-контрактів. Зміни ринку комісій EIP-1559 не включені в транзакції типу 1. Транзакції типу 1 також включають параметр `yParity`, який може бути `0x0` або `0x1`, що вказує на парність значення y підпису secp256k1. Вони ідентифікуються тим, що починаються з байта `0x01`, а їхнє значення TransactionType — `0x1`. 3. **Транзакції типу 2**, які часто називають транзакціями EIP-1559, — це транзакції, представлені в [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) під час оновлення [Лондон](/ethereum-forks/#london) в Етеріумі. Вони стали стандартним типом транзакцій у мережі Етеріум. Ці транзакції запроваджують новий механізм ринку комісій, який покращує передбачуваність шляхом поділу комісії за транзакцію на базову комісію та пріоритетну комісію. Вони починаються з байта `0x02` і включають такі поля, як `maxPriorityFeePerGas` та `maxFeePerGas`. Транзакції типу 2 тепер використовуються за замовчуванням завдяки їхній гнучкості та ефективності, і їм особливо віддають перевагу в періоди високого перевантаження мережі за їхню здатність допомагати користувачам більш передбачувано керувати комісіями за транзакції. Значення TransactionType для цих транзакцій — `0x2`. 4. **Транзакції типу 3 (блоб-транзакції)** були представлені в [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) як частина [оновлення Денкун](/ethereum-forks/#dencun) в Етеріумі. Ці транзакції призначені для більш ефективної обробки даних «блобів» (великих двійкових об'єктів), що особливо корисно для ролапів рівня 2 (l2), оскільки забезпечує спосіб публікації даних у мережі Етеріум за нижчою ціною. Блоб-транзакції включають додаткові поля, такі як `blobVersionedHashes`, `maxFeePerBlobGas` та `blobGasPrice`. Вони починаються з байта `0x03`, а їхнє значення TransactionType — `0x3`. Блоб-транзакції є значним покращенням доступності даних та можливостей масштабування Етеріуму. 5. **Транзакції типу 4** були представлені в [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) як частина оновлення [Пектра](/roadmap/pectra/) в Етеріумі. Ці транзакції розроблені для забезпечення прямої сумісності з абстракцією облікового запису. Вони дозволяють зовнішнім акаунтам (EOA) тимчасово поводитися як акаунти контрактів без шкоди для їхньої початкової функціональності. Вони включають параметр `authorization_list`, який визначає смарт-контракт, якому EOA делегує свої повноваження. Після транзакції поле коду EOA міститиме адресу делегованого смарт-контракту. ## Додаткові матеріали {#further-reading} - [EIP-2718: Типізований конверт транзакції](https://eips.ethereum.org/EIPS/eip-2718) _Знаєте ресурс спільноти, який вам допоміг? Відредагуйте цю сторінку та додайте його!_ ## Пов'язані теми {#related-topics} - [Акаунти](/developers/docs/accounts/) - [Віртуальна машина Етеріуму (EVM)](/developers/docs/evm/) - [Газ](/developers/docs/gas/)