From bad31928e6dc93a5bdb1dda54120a663433b950e Mon Sep 17 00:00:00 2001 From: "DESKTOP-AI3KLJL\\Alex Colba" Date: Tue, 14 Jan 2025 22:44:15 +0200 Subject: [PATCH] Prettier issues fix --- docs/locales/uk/advanced/actions.md | 626 ++++++++++++------ docs/locales/uk/advanced/confirmation.md | 337 +++++++--- docs/locales/uk/advanced/lookup-tables.md | 91 ++- docs/locales/uk/advanced/retry.md | 115 +++- docs/locales/uk/advanced/state-compression.md | 166 +++-- docs/locales/uk/advanced/versions.md | 54 +- .../uk/clients/javascript-reference.md | 130 +++- docs/locales/uk/clients/javascript.md | 117 +++- docs/locales/uk/clients/rust.md | 24 +- docs/locales/uk/core/accounts.md | 160 +++-- docs/locales/uk/core/clusters.md | 45 +- docs/locales/uk/core/cpi.md | 39 +- docs/locales/uk/core/fees.md | 411 +++++++++--- docs/locales/uk/core/index.md | 84 ++- docs/locales/uk/core/pda.md | 125 ++-- docs/locales/uk/core/programs.md | 104 +-- docs/locales/uk/core/tokens.md | 308 +++++---- docs/locales/uk/core/transactions.md | 193 ++++-- docs/locales/uk/economics/index.md | 43 +- .../inflation/_adjusted_staking_yield.md | 45 +- .../economics/inflation/inflation-schedule.md | 69 +- .../uk/economics/inflation/terminology.md | 76 ++- docs/locales/uk/economics/staking/index.md | 103 +-- .../uk/economics/staking/stake-accounts.md | 57 +- .../uk/economics/staking/stake-programming.md | 24 +- docs/locales/uk/index.md | 88 ++- docs/locales/uk/intro/dev.md | 150 +++-- docs/locales/uk/intro/installation.md | 201 ++++-- .../quick-start/cross-program-invocation.md | 153 +++-- .../intro/quick-start/deploying-programs.md | 115 ++-- docs/locales/uk/intro/quick-start/index.md | 61 +- .../quick-start/program-derived-address.md | 227 ++++--- .../intro/quick-start/reading-from-network.md | 153 +++-- .../intro/quick-start/writing-to-network.md | 59 +- docs/locales/uk/intro/wallets.md | 53 +- docs/locales/uk/more/exchange.md | 586 ++++++++++++---- .../uk/programs/anchor/client-typescript.md | 112 ++-- docs/locales/uk/programs/anchor/cpi.md | 149 +++-- docs/locales/uk/programs/anchor/idl.md | 82 ++- docs/locales/uk/programs/anchor/index.md | 104 +-- docs/locales/uk/programs/anchor/pda.md | 88 ++- .../uk/programs/anchor/program-structure.md | 94 ++- docs/locales/uk/programs/deploying.md | 188 +++--- docs/locales/uk/programs/examples.md | 146 ++-- docs/locales/uk/programs/faq.md | 157 +++-- docs/locales/uk/programs/limitations.md | 62 +- docs/locales/uk/programs/rust/index.md | 102 +-- .../uk/programs/rust/program-structure.md | 186 +++--- docs/locales/uk/programs/testing.md | 90 ++- docs/locales/uk/rpc.md | 6 +- docs/locales/uk/terminology.md | 291 +++++--- 51 files changed, 4875 insertions(+), 2374 deletions(-) diff --git a/docs/locales/uk/advanced/actions.md b/docs/locales/uk/advanced/actions.md index 0debc4c69..22a93fa1f 100644 --- a/docs/locales/uk/advanced/actions.md +++ b/docs/locales/uk/advanced/actions.md @@ -4,8 +4,8 @@ title: "Дії та Блінки" seoTitle: "Дії та Блінки" description: "Дії Solana — це API, які повертають транзакції для попереднього перегляду і - підпису користувачами. Посилання на блокчейн — або блінки — перетворюють дії - в зручні, багаті на метадані посилання для спільного використання." + підпису користувачами. Посилання на блокчейн — або блінки — перетворюють дії в + зручні, багаті на метадані посилання для спільного використання." altRoutes: - /docs/actions - /docs/blinks @@ -16,16 +16,16 @@ altRoutes: транзакції в блокчейні Solana для попереднього перегляду, підпису та відправки. Вони можуть використовуватися в різних контекстах, таких як QR-коди, кнопки, віджети та вебсайти. Дії дозволяють розробникам легко інтегрувати функціонал -екосистеми Solana у свій додаток, дозволяючи виконувати блокчейн-транзакції -без необхідності переходу на інші сторінки або додатки. +екосистеми Solana у свій додаток, дозволяючи виконувати блокчейн-транзакції без +необхідності переходу на інші сторінки або додатки. [Посилання на блокчейн](#blinks) — або блінки — перетворюють будь-яку дію Solana в зручне посилання, багате метаданими. Блінки дозволяють клієнтам, які підтримують їх, (таким як гаманці або боти) відображати додаткові функціональні можливості. Наприклад, на вебсайті блінк може негайно відкрити попередній перегляд транзакції у гаманці, а в Discord бот може перетворити блінк на -інтерактивні кнопки. Це забезпечує взаємодію з блокчейном на будь-якій платформі, -що підтримує URL. +інтерактивні кнопки. Це забезпечує взаємодію з блокчейном на будь-якій +платформі, що підтримує URL. ## Початок роботи @@ -35,15 +35,16 @@ altRoutes: npm install @solana/actions ``` -- встановіть [Solana Actions SDK](https://www.npmjs.com/package/@solana/actions) у вашому додатку +- встановіть [Solana Actions SDK](https://www.npmjs.com/package/@solana/actions) + у вашому додатку - створіть API-ендпойнт для [GET-запиту](#get-request), який повертає метадані про вашу дію - створіть API-ендпойнт для [POST-запиту](#post-request), який повертає транзакцію для підпису користувачем > Перегляньте цей відеоурок про -> [створення дії Solana](https://www.youtube.com/watch?v=kCht01Ycif0) за допомогою -> `@solana/actions` SDK. +> [створення дії Solana](https://www.youtube.com/watch?v=kCht01Ycif0) за +> допомогою `@solana/actions` SDK. > > Ви також можете знайти > [вихідний код дії](https://github.com/solana-developers/solana-actions/blob/main/examples/next-js/src/app/api/actions/transfer-sol/route.ts), @@ -68,22 +69,21 @@ npm install @solana/actions ## Дії Специфікація дій Solana використовує набір стандартних API для передачі -транзакцій (та, зрештою, повідомлень) для підпису безпосередньо користувачам. -Ці API доступні за публічними URL, які можуть взаємодіяти з будь-якими клієнтами. +транзакцій (та, зрештою, повідомлень) для підпису безпосередньо користувачам. Ці +API доступні за публічними URL, які можуть взаємодіяти з будь-якими клієнтами. -> Дії можна уявити як API-ендпойнт, який повертає метадані та об'єкт для -> підпису користувачем (транзакцію або повідомлення для аутентифікації) за -> допомогою їх блокчейн-гаманця. +> Дії можна уявити як API-ендпойнт, який повертає метадані та об'єкт для підпису +> користувачем (транзакцію або повідомлення для аутентифікації) за допомогою їх +> блокчейн-гаманця. API дій складається з простих `GET` і `POST` запитів до URL-ендпойнтів дій та обробки відповідей, які відповідають інтерфейсу дій. -1. [GET-запит](#get-request) повертає метадані, які надають клієнту - інформацію про доступні дії за цим URL, а також список пов’язаних дій (за - бажанням). -2. [POST-запит](#post-request) повертає транзакцію або повідомлення для - підпису, які клієнт відображає в гаманці користувача для підпису та виконання - у блокчейні або іншому офчейн-сервісі. +1. [GET-запит](#get-request) повертає метадані, які надають клієнту інформацію + про доступні дії за цим URL, а також список пов’язаних дій (за бажанням). +2. [POST-запит](#post-request) повертає транзакцію або повідомлення для підпису, + які клієнт відображає в гаманці користувача для підпису та виконання у + блокчейні або іншому офчейн-сервісі. ### Виконання дії та життєвий цикл @@ -116,16 +116,16 @@ API дій складається з простих `GET` і `POST` запиті ## Блінки -Блінки (посилання на блокчейн) — це клієнтські програми, які аналізують API -дій і створюють інтерфейси користувача для взаємодії з діями та їх виконання. +Блінки (посилання на блокчейн) — це клієнтські програми, які аналізують API дій +і створюють інтерфейси користувача для взаємодії з діями та їх виконання. Клієнтські програми, що підтримують блінки, виявляють URL, сумісні з діями, аналізують їх і дозволяють користувачам взаємодіяти з ними у стандартизованих інтерфейсах. > Будь-яка клієнтська програма, яка повністю аналізує API дій для створення -> повноцінного інтерфейсу, є _блінком_. Отже, не всі клієнти, які -> використовують API дій, є блінками. +> повноцінного інтерфейсу, є _блінком_. Отже, не всі клієнти, які використовують +> API дій, є блінками. ### Специфікація URL блінків @@ -141,7 +141,8 @@ https://example.domain/?action= - URL блінка повинен містити параметр запиту `action`, значення якого має бути [URL-кодованим](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent) - [URL дії](#url-scheme). Це значення має бути закодоване, щоб уникнути конфліктів з іншими параметрами протоколу. + [URL дії](#url-scheme). Це значення має бути закодоване, щоб уникнути + конфліктів з іншими параметрами протоколу. - Клієнтська програма повинна [декодувати URL](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/decodeURIComponent) @@ -149,8 +150,9 @@ https://example.domain/?action= [Схему URL дії](#url-scheme)). - Клієнт повинен відобразити багатий інтерфейс користувача, який дозволяє - завершити повний [життєвий цикл виконання дії](#action-execution-and-lifecycle), - включаючи підписання у гаманці. + завершити повний + [життєвий цикл виконання дії](#action-execution-and-lifecycle), включаючи + підписання у гаманці. > Не всі клієнтські програми-блінки (наприклад, вебсайти або децентралізовані > додатки) підтримуватимуть усі дії. Розробники додатків можуть обирати, які дії @@ -167,8 +169,7 @@ https://example.domain/?action=solana-action%3Ahttps%3A%2F%2Factions.alice.com%2 Блінки можуть бути пов’язані з діями щонайменше трьома способами: -1. Поширення явного URL дії: - `solana-action:https://actions.alice.com/donate` +1. Поширення явного URL дії: `solana-action:https://actions.alice.com/donate` У цьому випадку лише клієнти, які підтримують блінки, можуть відобразити блінк. Не буде доступного попереднього перегляду посилання або сайту, який @@ -178,9 +179,9 @@ https://example.domain/?action=solana-action%3Ahttps%3A%2F%2Factions.alice.com%2 [`actions.json`](#actionsjson) у кореневій директорії домену вебсайту. Наприклад, `https://alice.com/actions.json` зіставляє - `https://alice.com/donate`, URL вебсайту, на якому користувачі можуть - зробити пожертву для Alice, з API URL `https://actions.alice.com/donate`, на - якому хостяться дії для пожертвування Alice. + `https://alice.com/donate`, URL вебсайту, на якому користувачі можуть зробити + пожертву для Alice, з API URL `https://actions.alice.com/donate`, на якому + хостяться дії для пожертвування Alice. 3. Вбудовування URL дії у "перехідний" URL сайту, який розуміє, як аналізувати дії. @@ -211,8 +212,8 @@ https://example.domain/?action=solana-action%3Ahttps%3A%2F%2Factions.alice.com%2 > всі введення для кожної з ваших пов'язаних дій. Кожен клієнтський додаток або гаманець може мати різні вимоги щодо того, які -ендпойнти дій будуть автоматично розгортатися й негайно відображатися користувачам -на платформах соціальних мереж. +ендпойнти дій будуть автоматично розгортатися й негайно відображатися +користувачам на платформах соціальних мереж. Наприклад, деякі клієнти можуть працювати за підходом "список дозволених" і вимагати верифікації перед розгортанням дії для користувачів, як це робить @@ -223,16 +224,16 @@ https://example.domain/?action=solana-action%3Ahttps%3A%2F%2Factions.alice.com%2 ### Реєстр дій Dialect -Як загальне благо для екосистеми Solana, [Dialect](https://dialect.to) -підтримує публічний реєстр — разом із допомогою Solana Foundation та інших -членів спільноти — для посилань на блокчейн, які попередньо перевірені й -походять із відомих джерел. На момент запуску лише дії, зареєстровані в реєстрі -Dialect, будуть автоматично розгортатися у Twitter, коли їх публікують. +Як загальне благо для екосистеми Solana, [Dialect](https://dialect.to) підтримує +публічний реєстр — разом із допомогою Solana Foundation та інших членів +спільноти — для посилань на блокчейн, які попередньо перевірені й походять із +відомих джерел. На момент запуску лише дії, зареєстровані в реєстрі Dialect, +будуть автоматично розгортатися у Twitter, коли їх публікують. Клієнтські програми та гаманці можуть вільно використовувати цей публічний -реєстр або інші рішення, щоб забезпечити безпеку користувачів. Якщо посилання -на блокчейн не верифіковане через реєстр Dialect, воно не оброблятиметься -клієнтом блінків і буде відображатися як звичайне URL. +реєстр або інші рішення, щоб забезпечити безпеку користувачів. Якщо посилання на +блокчейн не верифіковане через реєстр Dialect, воно не оброблятиметься клієнтом +блінків і буде відображатися як звичайне URL. Розробники можуть подати заявку на верифікацію у Dialect тут: [dial.to/register](https://dial.to/register) @@ -243,16 +244,17 @@ Dialect, будуть автоматично розгортатися у Twitter процесу взаємодії запит/відповідь: - Схема URL [Solana Action](#url-scheme), яка надає URL дії -- [OPTIONS-відповідь](#options-response) на URL дії для відповідності вимогам CORS +- [OPTIONS-відповідь](#options-response) на URL дії для відповідності вимогам + CORS - [GET-запит](#get-request) до URL дії - [GET-відповідь](#get-response) із сервера - [POST-запит](#post-request) до URL дії - [POST-відповідь](#post-response) із сервера -Кожен із цих запитів надсилається _клієнтом дій_ (наприклад, гаманець, розширення -для браузера, децентралізований додаток, вебсайт тощо) для збору специфічних -метаданих для багатого інтерфейсу користувача та забезпечення вводу користувачем -до API дій. +Кожен із цих запитів надсилається _клієнтом дій_ (наприклад, гаманець, +розширення для браузера, децентралізований додаток, вебсайт тощо) для збору +специфічних метаданих для багатого інтерфейсу користувача та забезпечення вводу +користувачем до API дій. Кожна з відповідей створюється додатком (наприклад, вебсайтом, серверним додатком тощо) і повертається _клієнту дій_. Зрештою, це забезпечує транзакцію @@ -263,7 +265,8 @@ Dialect, будуть автоматично розгортатися у Twitter > полегшення читання. > > Для кращої безпеки типів і покращеного досвіду розробників пакет -> `@solana/actions-spec` містить більш складні визначення типів. Ви можете знайти +> `@solana/actions-spec` містить більш складні визначення типів. Ви можете +> знайти > [вихідний код тут](https://github.com/solana-developers/solana-actions/blob/main/packages/actions-spec/index.d.ts). ### Схема URL @@ -299,8 +302,8 @@ solana-action: ### OPTIONS-відповідь Для забезпечення крос-доменного доступу (CORS) у клієнтах дій (включаючи -блінки), усі ендпойнти дій повинні відповідати на HTTP-запити методу `OPTIONS` -з дійсними заголовками, які дозволять клієнтам проходити CORS-перевірки для всіх +блінки), усі ендпойнти дій повинні відповідати на HTTP-запити методу `OPTIONS` з +дійсними заголовками, які дозволять клієнтам проходити CORS-перевірки для всіх подальших запитів із їхнього домену. Клієнт дій може виконувати @@ -347,7 +350,8 @@ HTTP `GET` JSON-запит до URL-ендпойнта дії. ### GET-відповідь URL-ендпойнт дії (наприклад, додаток або серверний бекенд) повинен відповідати -HTTP `OK` JSON-відповіддю (з дійсним вмістом у тілі) або відповідною помилкою HTTP. +HTTP `OK` JSON-відповіддю (з дійсним вмістом у тілі) або відповідною помилкою +HTTP. - Клієнт повинен обробляти HTTP [помилки клієнта](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses), @@ -401,28 +405,56 @@ export interface Action { } ``` -- `type` - Тип дії, що надається користувачеві. За замовчуванням встановлено значення `action`. Початковий `ActionGetResponse` повинен мати тип `action`. - - - `action` - Стандартна дія, яка дозволяє користувачеві взаємодіяти з будь-якими `LinkedActions`. - - `completed` - Використовується для позначення стану "завершено" у ланцюжку дій. - -- `icon` - Значення має бути абсолютним HTTP або HTTPS URL іконки. Файл повинен бути формату SVG, PNG або WebP, інакше клієнт/гаманець повинен відхилити його як **пошкоджений**. - -- `title` - Значення має бути рядком UTF-8, що представляє джерело запиту дії. Наприклад, це може бути назва бренду, магазину, програми або особи, яка робить запит. - -- `description` - Значення має бути рядком UTF-8, що надає інформацію про дію. Опис повинен бути відображений користувачеві. - -- `label` - Значення має бути рядком UTF-8, який буде відображено на кнопці для натискання користувачем. Усі мітки не повинні перевищувати 5 слів і повинні починатися з дієслова, щоб закріпити дію, яку ви хочете, щоб користувач виконав. Наприклад, "Mint NFT", "Vote Yes" або "Stake 1 SOL". - -- `disabled` - Значення має бути логічним (boolean), щоб представляти стан вимкнення кнопки (яка відображає рядок `label`). Якщо значення не надано, `disabled` має за замовчуванням бути `false` (тобто увімкнено). Наприклад, якщо кінцева точка дії використовується для голосування, яке вже закрите, встановіть `disabled=true`, а мітка може бути "Vote Closed". - -- `error` - Необов'язковий індикатор помилки для нефатальних помилок. Якщо присутній, клієнт повинен відобразити це користувачеві. Якщо встановлено, це не повинно заважати клієнту інтерпретувати дію або відображати її користувачеві (див. [Помилки дій](#action-errors)). Наприклад, помилка може використовуватися разом із `disabled`, щоб показати причину, як-от бізнес-обмеження, авторизація, стан або помилка зовнішнього ресурсу. - -- `links.actions` - Необов'язковий масив пов'язаних дій для кінцевої точки. Користувачам повинен бути відображений інтерфейс для кожної зі вказаних дій, і очікується, що вони виконають лише одну. Наприклад, кінцева точка дії для голосування в управлінні DAO може повернути три варіанти для користувача: "Vote Yes", "Vote No" і "Abstain from Vote". - - - Якщо `links.actions` не надано, клієнт повинен відобразити одну кнопку, використовуючи кореневий рядок `label`, і виконати POST-запит до тієї самої кінцевої точки URL дії, що й початковий GET-запит. - - - Якщо будь-які `links.actions` надані, клієнт повинен відображати лише кнопки та поля введення на основі елементів, перелічених у полі `links.actions`. Клієнт не повинен відображати кнопку для вмісту кореневого `label`. +- `type` - Тип дії, що надається користувачеві. За замовчуванням встановлено + значення `action`. Початковий `ActionGetResponse` повинен мати тип `action`. + + - `action` - Стандартна дія, яка дозволяє користувачеві взаємодіяти з + будь-якими `LinkedActions`. + - `completed` - Використовується для позначення стану "завершено" у ланцюжку + дій. + +- `icon` - Значення має бути абсолютним HTTP або HTTPS URL іконки. Файл повинен + бути формату SVG, PNG або WebP, інакше клієнт/гаманець повинен відхилити його + як **пошкоджений**. + +- `title` - Значення має бути рядком UTF-8, що представляє джерело запиту дії. + Наприклад, це може бути назва бренду, магазину, програми або особи, яка робить + запит. + +- `description` - Значення має бути рядком UTF-8, що надає інформацію про дію. + Опис повинен бути відображений користувачеві. + +- `label` - Значення має бути рядком UTF-8, який буде відображено на кнопці для + натискання користувачем. Усі мітки не повинні перевищувати 5 слів і повинні + починатися з дієслова, щоб закріпити дію, яку ви хочете, щоб користувач + виконав. Наприклад, "Mint NFT", "Vote Yes" або "Stake 1 SOL". + +- `disabled` - Значення має бути логічним (boolean), щоб представляти стан + вимкнення кнопки (яка відображає рядок `label`). Якщо значення не надано, + `disabled` має за замовчуванням бути `false` (тобто увімкнено). Наприклад, + якщо кінцева точка дії використовується для голосування, яке вже закрите, + встановіть `disabled=true`, а мітка може бути "Vote Closed". + +- `error` - Необов'язковий індикатор помилки для нефатальних помилок. Якщо + присутній, клієнт повинен відобразити це користувачеві. Якщо встановлено, це + не повинно заважати клієнту інтерпретувати дію або відображати її + користувачеві (див. [Помилки дій](#action-errors)). Наприклад, помилка може + використовуватися разом із `disabled`, щоб показати причину, як-от + бізнес-обмеження, авторизація, стан або помилка зовнішнього ресурсу. + +- `links.actions` - Необов'язковий масив пов'язаних дій для кінцевої точки. + Користувачам повинен бути відображений інтерфейс для кожної зі вказаних дій, і + очікується, що вони виконають лише одну. Наприклад, кінцева точка дії для + голосування в управлінні DAO може повернути три варіанти для користувача: + "Vote Yes", "Vote No" і "Abstain from Vote". + + - Якщо `links.actions` не надано, клієнт повинен відобразити одну кнопку, + використовуючи кореневий рядок `label`, і виконати POST-запит до тієї самої + кінцевої точки URL дії, що й початковий GET-запит. + + - Якщо будь-які `links.actions` надані, клієнт повинен відображати лише кнопки + та поля введення на основі елементів, перелічених у полі `links.actions`. + Клієнт не повинен відображати кнопку для вмісту кореневого `label`. ```ts filename="LinkedAction" export interface LinkedAction { @@ -439,7 +471,8 @@ export interface LinkedAction { } ``` -`ActionParameter` дозволяє визначити, яке саме введення API дій запитує у користувача: +`ActionParameter` дозволяє визначити, яке саме введення API дій запитує у +користувача: ```ts filename="ActionParameter" /** @@ -466,15 +499,30 @@ export interface ActionParameter { } ``` -`pattern` повинен бути рядком, еквівалентним дійсному регулярному виразу. Цей регулярний вираз має використовуватися клієнтами-блінками для перевірки введення користувача перед виконанням POST-запиту. Якщо `pattern` не є дійсним регулярним виразом, клієнт повинен його ігнорувати. - -`patternDescription` — це опис, зрозумілий для людини, який пояснює очікуване введення користувача. Якщо надано `pattern`, то `patternDescription` також обов’язково має бути надано. - -Значення `min` та `max` дозволяють встановити нижню та/або верхню межу введення, запитуваного у користувача (наприклад, мінімальне/максимальне число або мінімальну/максимальну довжину рядка). Вони повинні використовуватися для клієнтської валідації. Для типів введення `date` або `datetime-local` ці значення мають бути рядками, що представляють дати. Для інших типів введення на основі рядків значення повинні бути числами, що представляють їх мінімальну/максимальну довжину символів. - -Якщо введене значення користувача не відповідає `pattern`, користувач має отримати повідомлення про помилку на стороні клієнта, що вказує на недійсність поля введення, і відображати рядок `patternDescription`. - -Поле `type` дозволяє API дій визначати більш конкретні поля введення користувача, забезпечуючи кращу валідацію на стороні клієнта та покращуючи користувацький досвід. У багатьох випадках цей тип буде подібний до стандартного +`pattern` повинен бути рядком, еквівалентним дійсному регулярному виразу. Цей +регулярний вираз має використовуватися клієнтами-блінками для перевірки введення +користувача перед виконанням POST-запиту. Якщо `pattern` не є дійсним регулярним +виразом, клієнт повинен його ігнорувати. + +`patternDescription` — це опис, зрозумілий для людини, який пояснює очікуване +введення користувача. Якщо надано `pattern`, то `patternDescription` також +обов’язково має бути надано. + +Значення `min` та `max` дозволяють встановити нижню та/або верхню межу введення, +запитуваного у користувача (наприклад, мінімальне/максимальне число або +мінімальну/максимальну довжину рядка). Вони повинні використовуватися для +клієнтської валідації. Для типів введення `date` або `datetime-local` ці +значення мають бути рядками, що представляють дати. Для інших типів введення на +основі рядків значення повинні бути числами, що представляють їх +мінімальну/максимальну довжину символів. + +Якщо введене значення користувача не відповідає `pattern`, користувач має +отримати повідомлення про помилку на стороні клієнта, що вказує на недійсність +поля введення, і відображати рядок `patternDescription`. + +Поле `type` дозволяє API дій визначати більш конкретні поля введення +користувача, забезпечуючи кращу валідацію на стороні клієнта та покращуючи +користувацький досвід. У багатьох випадках цей тип буде подібний до стандартного [елемента введення HTML](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input). Тип `ActionParameterType` можна спростити до такого формату: @@ -497,7 +545,10 @@ export type ActionParameterType = | "select"; ``` -Кожне зі значень `type` зазвичай має відповідати полю введення користувача, яке нагадує стандартний HTML-елемент `input` відповідного типу (наприклад, ``), щоб забезпечити кращу валідацію на стороні клієнта та покращити користувацький досвід: +Кожне зі значень `type` зазвичай має відповідати полю введення користувача, яке +нагадує стандартний HTML-елемент `input` відповідного типу (наприклад, +``), щоб забезпечити кращу валідацію на стороні клієнта та +покращити користувацький досвід: - `text` - еквівалент HTML [елемента введення типу "text"](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/text) @@ -513,22 +564,31 @@ export type ActionParameterType = [елемента введення типу "datetime-local"](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local) - `checkbox` - еквівалент групи стандартних HTML [елементів введення типу "checkbox"](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/checkbox). - API дій має повертати `options`, як описано нижче. Користувач повинен мати змогу вибрати кілька запропонованих варіантів. + API дій має повертати `options`, як описано нижче. Користувач повинен мати + змогу вибрати кілька запропонованих варіантів. - `radio` - еквівалент групи стандартних HTML [елементів введення типу "radio"](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/radio). - API дій має повертати `options`, як описано нижче. Користувач повинен мати змогу вибрати лише один із запропонованих варіантів. -- Інші еквіваленти HTML-типів введення, не зазначені вище (`hidden`, `button`, `submit`, `file` тощо), наразі не підтримуються. + API дій має повертати `options`, як описано нижче. Користувач повинен мати + змогу вибрати лише один із запропонованих варіантів. +- Інші еквіваленти HTML-типів введення, не зазначені вище (`hidden`, `button`, + `submit`, `file` тощо), наразі не підтримуються. -Окрім елементів, схожих на HTML-типи введення, також підтримуються наступні елементи введення користувача: +Окрім елементів, схожих на HTML-типи введення, також підтримуються наступні +елементи введення користувача: - `textarea` - еквівалент HTML [елемента "textarea"](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea), що дозволяє користувачеві вводити багаторядковий текст. - `select` - еквівалент HTML [елемента "select"](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select), - що надає користувачеві досвід вибору з випадаючого списку. API дій має повертати `options`, як описано нижче. + що надає користувачеві досвід вибору з випадаючого списку. API дій має + повертати `options`, як описано нижче. -Коли `type` встановлено як `select`, `checkbox` або `radio`, API дій має включати масив `options`, кожен із яких надає `label` та `value` принаймні. Кожна опція також може мати значення `selected`, яке інформує клієнт-блінк, яка опція має бути обрана за замовчуванням для користувача (див. відмінності для `checkbox` і `radio`). +Коли `type` встановлено як `select`, `checkbox` або `radio`, API дій має +включати масив `options`, кожен із яких надає `label` та `value` принаймні. +Кожна опція також може мати значення `selected`, яке інформує клієнт-блінк, яка +опція має бути обрана за замовчуванням для користувача (див. відмінності для +`checkbox` і `radio`). Цей `ActionParameterSelectable` можна спростити до такого визначення типу: @@ -548,15 +608,23 @@ interface ActionParameterSelectable extends ActionParameter { } ``` -Якщо `type` не встановлено або задано невідоме/непідтримуване значення, клієнти-блінки мають за замовчуванням використовувати `text` і відображати просте текстове поле введення. +Якщо `type` не встановлено або задано невідоме/непідтримуване значення, +клієнти-блінки мають за замовчуванням використовувати `text` і відображати +просте текстове поле введення. -API дій все одно відповідає за валідацію та санітизацію всіх даних, отриманих від параметрів введення користувача, забезпечуючи виконання всіх обов’язкових ("required") полів введення за необхідності. +API дій все одно відповідає за валідацію та санітизацію всіх даних, отриманих +від параметрів введення користувача, забезпечуючи виконання всіх обов’язкових +("required") полів введення за необхідності. -Для платформ, які не базуються на HTML/веб (наприклад, для нативних мобільних додатків), слід використовувати еквівалентні нативні компоненти введення, щоб забезпечити аналогічний досвід та валідацію на стороні клієнта, як описано для HTML/веб. +Для платформ, які не базуються на HTML/веб (наприклад, для нативних мобільних +додатків), слід використовувати еквівалентні нативні компоненти введення, щоб +забезпечити аналогічний досвід та валідацію на стороні клієнта, як описано для +HTML/веб. #### Приклад відповіді на GET-запит -Наступний приклад відповіді забезпечує єдину "кореневу" дію, яка очікує, що користувачеві буде представлена одна кнопка з міткою "Отримати токен доступу": +Наступний приклад відповіді забезпечує єдину "кореневу" дію, яка очікує, що +користувачеві буде представлена одна кнопка з міткою "Отримати токен доступу": ```json { @@ -567,7 +635,9 @@ API дій все одно відповідає за валідацію та с } ``` -Наступний приклад відповіді забезпечує 3 пов’язані посилання на дії, що дозволяють користувачеві натиснути одну з трьох кнопок для голосування за пропозицію DAO: +Наступний приклад відповіді забезпечує 3 пов’язані посилання на дії, що +дозволяють користувачеві натиснути одну з трьох кнопок для голосування за +пропозицію DAO: ```json { @@ -596,9 +666,14 @@ API дій все одно відповідає за валідацію та с #### Приклад відповіді на GET-запит з параметрами -Наступні приклади відповіді демонструють, як приймати текстове введення від користувача (через `parameters`) і включати це введення у кінцеву кінцеву точку запиту `POST` (через поле `href` у `LinkedAction`): +Наступні приклади відповіді демонструють, як приймати текстове введення від +користувача (через `parameters`) і включати це введення у кінцеву кінцеву точку +запиту `POST` (через поле `href` у `LinkedAction`): -Наступний приклад відповіді забезпечує користувачеві 3 пов’язані дії для стейкінгу SOL: кнопку з міткою "Stake 1 SOL", іншу кнопку з міткою "Stake 5 SOL" та текстове поле введення, яке дозволяє користувачеві ввести конкретне значення "amount", що буде надіслано до API дій: +Наступний приклад відповіді забезпечує користувачеві 3 пов’язані дії для +стейкінгу SOL: кнопку з міткою "Stake 1 SOL", іншу кнопку з міткою "Stake 5 SOL" +та текстове поле введення, яке дозволяє користувачеві ввести конкретне значення +"amount", що буде надіслано до API дій: ```json { @@ -633,7 +708,9 @@ API дій все одно відповідає за валідацію та с } ``` -Наступний приклад відповіді забезпечує одне поле введення для користувача, щоб ввести `amount`, яке буде надіслано з запитом `POST` (може бути використано як параметр запиту або як підшлях): +Наступний приклад відповіді забезпечує одне поле введення для користувача, щоб +ввести `amount`, яке буде надіслано з запитом `POST` (може бути використано як +параметр запиту або як підшлях): ```json { @@ -661,7 +738,9 @@ API дій все одно відповідає за валідацію та с ### POST Запит -Наступний приклад відповіді забезпечує одне поле введення для користувача, щоб ввести `amount`, яке буде надіслано з запитом `POST` (може бути використано як параметр запиту або як підшлях): +Наступний приклад відповіді забезпечує одне поле введення для користувача, щоб +ввести `amount`, яке буде надіслано з запитом `POST` (може бути використано як +параметр запиту або як підшлях): ```json { @@ -669,35 +748,42 @@ API дій все одно відповідає за валідацію та с } ``` -- `account` - Значення повинно бути відкритим ключем облікового запису у форматі base58, який може підписувати транзакцію. +- `account` - Значення повинно бути відкритим ключем облікового запису у форматі + base58, який може підписувати транзакцію. -Клієнт має виконати запит із заголовком -[Accept-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding), -а застосунок може відповісти заголовком -[Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding) +Клієнт має виконати запит із заголовком +[Accept-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding), +а застосунок може відповісти заголовком +[Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding) для HTTP-компресії. -Клієнт повинен відобразити домен URL дії під час виконання запиту. Якщо був виконаний `GET`-запит, клієнт також повинен відобразити `title` та відрендерити зображення `icon` з відповіді GET. +Клієнт повинен відобразити домен URL дії під час виконання запиту. Якщо був +виконаний `GET`-запит, клієнт також повинен відобразити `title` та відрендерити +зображення `icon` з відповіді GET. ### Відповідь на POST-запит -Кінцева точка `POST` для дії повинна відповідати HTTP-відповіддю `OK` у форматі JSON (з дійсним тілом відповіді) або відповідною HTTP-помилкою. +Кінцева точка `POST` для дії повинна відповідати HTTP-відповіддю `OK` у форматі +JSON (з дійсним тілом відповіді) або відповідною HTTP-помилкою. -- Клієнт повинен обробляти +- Клієнт повинен обробляти [помилки клієнта](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses), - [помилки сервера](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#server_error_responses), - та + [помилки сервера](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#server_error_responses), + та [відповіді-перенаправлення](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#redirection_messages). -- Кінцева точка повинна відповідати з - заголовком [`Content-Type`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) +- Кінцева точка повинна відповідати з заголовком + [`Content-Type`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type) значенням `application/json`. -Помилкові відповіді (тобто HTTP-коди стану 4xx і 5xx) повинні повертати JSON-відповідь, що відповідає структурі `ActionError`, для відображення корисного повідомлення про помилку користувачам. Див. [Помилки дій](#action-errors). +Помилкові відповіді (тобто HTTP-коди стану 4xx і 5xx) повинні повертати +JSON-відповідь, що відповідає структурі `ActionError`, для відображення +корисного повідомлення про помилку користувачам. Див. +[Помилки дій](#action-errors). #### Тіло відповіді на POST-запит -Відповідь `POST` з HTTP-відповіддю `OK` у форматі JSON повинна включати тіло відповіді наступного вигляду: - +Відповідь `POST` з HTTP-відповіддю `OK` у форматі JSON повинна включати тіло +відповіді наступного вигляду: ```ts filename="ActionPostResponse" /** @@ -717,23 +803,25 @@ export interface ActionPostResponse { }; } ``` -- `transaction` - Значення повинно бути серіалізованою транзакцією, закодованою в base64 + +- `transaction` - Значення повинно бути серіалізованою транзакцією, закодованою + в base64 ([документація](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Transaction.html#serialize)). Клієнт повинен декодувати транзакцію з base64 і [десеріалізувати її](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Transaction.html#from). -- `message` - Значення повинно бути рядком у форматі UTF-8, який описує суть транзакції, - включеної у відповідь. Клієнт повинен відобразити це значення користувачу. - Наприклад, це може бути назва товару, який купується, застосована знижка, - або подяка. +- `message` - Значення повинно бути рядком у форматі UTF-8, який описує суть + транзакції, включеної у відповідь. Клієнт повинен відобразити це значення + користувачу. Наприклад, це може бути назва товару, який купується, застосована + знижка, або подяка. -- `links.next` - Необов'язкове значення, яке використовується для "зчеплення" кількох дій - у послідовності. Після підтвердження включеної `transaction` у блокчейні - клієнт може отримати та відобразити наступну дію. Дивіться +- `links.next` - Необов'язкове значення, яке використовується для "зчеплення" + кількох дій у послідовності. Після підтвердження включеної `transaction` у + блокчейні клієнт може отримати та відобразити наступну дію. Дивіться [Зчеплення дій](#action-chaining) для отримання додаткової інформації. -- Клієнт та застосунок повинні дозволяти додаткові поля у тілі запиту - та відповіді, які можуть бути додані у майбутніх оновленнях специфікацій. +- Клієнт та застосунок повинні дозволяти додаткові поля у тілі запиту та + відповіді, які можуть бути додані у майбутніх оновленнях специфікацій. > Застосунок може відповідати частково або повністю підписаною транзакцією. > Клієнт та гаманець повинні перевіряти транзакцію як **ненадійну**. @@ -751,8 +839,9 @@ export interface ActionPostResponse { [`recentBlockhash`](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Transaction.html#recentBlockhash) у транзакції та встановити `recentBlockhash` на [останній blockhash](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Connection.html#getLatestBlockhash). -- Клієнт повинен серіалізувати та десеріалізувати транзакцію перед її підписанням. - Це забезпечує послідовний порядок ключів облікових записів як рішення для +- Клієнт повинен серіалізувати та десеріалізувати транзакцію перед її + підписанням. Це забезпечує послідовний порядок ключів облікових записів як + рішення для [цієї проблеми](https://github.com/solana-labs/solana/issues/21722). Якщо транзакція вже частково підписана: @@ -765,18 +854,17 @@ export interface ActionPostResponse { - Клієнт повинен перевірити існуючі підписи, і якщо будь-який з них недійсний, клієнт повинен відхилити транзакцію як **пошкоджену**. -Клієнт повинен підписати транзакцію лише за допомогою `account`, зазначеного у запиті, -і зробити це лише у випадку, якщо очікується підпис для цього `account`. +Клієнт повинен підписати транзакцію лише за допомогою `account`, зазначеного у +запиті, і зробити це лише у випадку, якщо очікується підпис для цього `account`. -Якщо очікується будь-який підпис, окрім підпису для `account` у запиті, -клієнт повинен відхилити транзакцію як **шкідливу**. +Якщо очікується будь-який підпис, окрім підпису для `account` у запиті, клієнт +повинен відхилити транзакцію як **шкідливу**. ### Помилки дій API для дій повинні повертати помилки у форматі `ActionError`, щоб надати -корисні повідомлення про помилки для користувачів. Залежно від контексту, ця помилка -може бути фатальною або нефатальною. - +корисні повідомлення про помилки для користувачів. Залежно від контексту, ця +помилка може бути фатальною або нефатальною. ```ts filename="ActionError" export interface ActionError { @@ -784,26 +872,43 @@ export interface ActionError { message: string; } ``` -Коли API для дій відповідає HTTP-кодом помилки (тобто 4xx і 5xx), тіло відповіді має бути JSON-навантаженням, яке відповідає формату `ActionError`. Помилка вважається фатальною, і повідомлення, яке міститься в ній, має бути представлене користувачеві. -Для відповідей API, які підтримують необов'язковий атрибут `error` (наприклад, [`ActionGetResponse`](#get-response)), помилка вважається нефатальною, і повідомлення, яке міститься в ній, також має бути представлене користувачеві. +Коли API для дій відповідає HTTP-кодом помилки (тобто 4xx і 5xx), тіло відповіді +має бути JSON-навантаженням, яке відповідає формату `ActionError`. Помилка +вважається фатальною, і повідомлення, яке міститься в ній, має бути представлене +користувачеві. + +Для відповідей API, які підтримують необов'язковий атрибут `error` (наприклад, +[`ActionGetResponse`](#get-response)), помилка вважається нефатальною, і +повідомлення, яке міститься в ній, також має бути представлене користувачеві. ## Зчеплення дій -Дії Solana можуть бути "зчеплені" разом у послідовну серію. Після підтвердження транзакції дії у блокчейні можна отримати наступну дію та представити її користувачеві. +Дії Solana можуть бути "зчеплені" разом у послідовну серію. Після підтвердження +транзакції дії у блокчейні можна отримати наступну дію та представити її +користувачеві. -Зчеплення дій дозволяє розробникам створювати більш складний і динамічний досвід у рамках blinks, включаючи: +Зчеплення дій дозволяє розробникам створювати більш складний і динамічний досвід +у рамках blinks, включаючи: -- надання декількох транзакцій (і в майбутньому повідомлень для підпису) користувачу; +- надання декількох транзакцій (і в майбутньому повідомлень для підпису) + користувачу; - налаштування метаданих дії залежно від адреси гаманця користувача; - оновлення метаданих blink після успішної транзакції; -- отримання API-зворотного виклику з підписом транзакції для додаткової перевірки та логіки на сервері API для дій; -- налаштовані повідомлення про успіх, шляхом оновлення відображуваних метаданих (наприклад, нове зображення або опис). +- отримання API-зворотного виклику з підписом транзакції для додаткової + перевірки та логіки на сервері API для дій; +- налаштовані повідомлення про успіх, шляхом оновлення відображуваних метаданих + (наприклад, нове зображення або опис). -Для зчеплення кількох дій разом, у будь-якому `ActionPostResponse` включіть `links.next` одного з наступних типів: +Для зчеплення кількох дій разом, у будь-якому `ActionPostResponse` включіть +`links.next` одного з наступних типів: -- `PostNextActionLink` — Посилання POST-запиту з URL зворотного виклику того самого походження для отримання `signature` і `account` користувача у тілі. Цей URL зворотного виклику повинен відповідати `NextAction`. -- `InlineNextActionLink` — Вбудовані метадані для наступної дії, які мають бути представлені користувачеві негайно після підтвердження транзакції. Ніякий зворотний виклик не буде виконано. +- `PostNextActionLink` — Посилання POST-запиту з URL зворотного виклику того + самого походження для отримання `signature` і `account` користувача у тілі. + Цей URL зворотного виклику повинен відповідати `NextAction`. +- `InlineNextActionLink` — Вбудовані метадані для наступної дії, які мають бути + представлені користувачеві негайно після підтвердження транзакції. Ніякий + зворотний виклик не буде виконано. ```ts export type NextActionLink = PostNextActionLink | InlineNextActionLink; @@ -826,15 +931,20 @@ export interface InlineNextActionLink { action: NextAction; } ``` -### NextAction -Після того як транзакція, включена в `ActionPostResponse`, підписана користувачем і підтверджена у блокчейні, blink-клієнт повинен або: +### NextAction -- виконати запит зворотного виклику, щоб отримати і відобразити `NextAction`, або -- якщо `NextAction` вже надана через `links.next`, blink-клієнт повинен оновити відображувані метадані і не робити запит зворотного виклику. +Після того як транзакція, включена в `ActionPostResponse`, підписана +користувачем і підтверджена у блокчейні, blink-клієнт повинен або: -Якщо URL зворотного виклику не має того ж походження, що і початковий POST-запит, запит зворотного виклику не повинен виконуватися. Blink-клієнти повинні відобразити помилку, що повідомляє користувача. +- виконати запит зворотного виклику, щоб отримати і відобразити `NextAction`, + або +- якщо `NextAction` вже надана через `links.next`, blink-клієнт повинен оновити + відображувані метадані і не робити запит зворотного виклику. +Якщо URL зворотного виклику не має того ж походження, що і початковий +POST-запит, запит зворотного виклику не повинен виконуватися. Blink-клієнти +повинні відобразити помилку, що повідомляє користувача. ```ts filename="NextAction" /** The next action to be performed */ @@ -846,31 +956,47 @@ export type CompletedAction = Omit, "links">; ### Відповідно до `type`, наступна дія повинна бути представлена користувачеві через blink-клієнти одним із наступних способів: -- `action` - (за замовчуванням) Стандартна дія, яка дозволяє користувачеві переглядати включені метадані Action, взаємодіяти з наданими `LinkedActions` і продовжувати виконувати будь-які наступні дії в ланцюжку. +- `action` - (за замовчуванням) Стандартна дія, яка дозволяє користувачеві + переглядати включені метадані Action, взаємодіяти з наданими `LinkedActions` і + продовжувати виконувати будь-які наступні дії в ланцюжку. -- `completed` - Завершальний стан ланцюжка дій, який може оновлювати інтерфейс blink із включеними метаданими Action, але не дозволяє користувачеві виконувати подальші дії. +- `completed` - Завершальний стан ланцюжка дій, який може оновлювати інтерфейс + blink із включеними метаданими Action, але не дозволяє користувачеві + виконувати подальші дії. -Якщо `links.next` не надано, blink-клієнти повинні припустити, що поточна дія є фінальною у ланцюжку, і представити свій інтерфейс "завершеної" дії після підтвердження транзакції. +Якщо `links.next` не надано, blink-клієнти повинні припустити, що поточна дія є +фінальною у ланцюжку, і представити свій інтерфейс "завершеної" дії після +підтвердження транзакції. ## actions.json -Файл [`actions.json`](#actionsjson) використовується для того, щоб додаток міг інструктувати клієнтів про те, які URL-адреси вебсайту підтримують Solana Actions, і надавати мапінг, який може бути використаний для виконання [GET запитів](#get-request) до серверу API дій. +Файл [`actions.json`](#actionsjson) використовується для того, щоб додаток міг +інструктувати клієнтів про те, які URL-адреси вебсайту підтримують Solana +Actions, і надавати мапінг, який може бути використаний для виконання +[GET запитів](#get-request) до серверу API дій. -Відповідь файлу `actions.json` також повинна повертати дійсні заголовки Cross-Origin для запитів `GET` і `OPTIONS`, зокрема заголовок `Access-Control-Allow-Origin` із значенням `*`. +Відповідь файлу `actions.json` також повинна повертати дійсні заголовки +Cross-Origin для запитів `GET` і `OPTIONS`, зокрема заголовок +`Access-Control-Allow-Origin` із значенням `*`. Детальніше див. у розділі [OPTIONS response](#options-response) вище. -Файл `actions.json` повинен бути збережений і загальнодоступний у кореневій директорії домену. +Файл `actions.json` повинен бути збережений і загальнодоступний у кореневій +директорії домену. -Наприклад, якщо ваш вебдодаток розгорнуто на `my-site.com`, тоді файл `actions.json` має бути доступний за адресою `https://my-site.com/actions.json`. Цей файл також має бути доступний через будь-який браузер за допомогою заголовка `Access-Control-Allow-Origin` із значенням `*`. +Наприклад, якщо ваш вебдодаток розгорнуто на `my-site.com`, тоді файл +`actions.json` має бути доступний за адресою `https://my-site.com/actions.json`. +Цей файл також має бути доступний через будь-який браузер за допомогою заголовка +`Access-Control-Allow-Origin` із значенням `*`. ### Правила -Поле `rules` дозволяє додатку мапувати набір відносних маршрутів вебсайту на інші шляхи. +Поле `rules` дозволяє додатку мапувати набір відносних маршрутів вебсайту на +інші шляхи. **Тип:** `Array` з `ActionRuleObject`. @@ -882,28 +1008,39 @@ interface ActionRuleObject { apiPath: string; } ``` -- [`pathPattern`](#rules-pathpattern) - Шаблон, який відповідає кожному вхідному шляху. -- [`apiPath`](#rules-apipath) - Місце призначення, визначене як абсолютний шлях або зовнішній URL. +- [`pathPattern`](#rules-pathpattern) - Шаблон, який відповідає кожному вхідному + шляху. + +- [`apiPath`](#rules-apipath) - Місце призначення, визначене як абсолютний шлях + або зовнішній URL. #### Правила - pathPattern -Шаблон, який відповідає кожному вхідному шляху. Це може бути абсолютний або відносний шлях, який підтримує наступні формати: +Шаблон, який відповідає кожному вхідному шляху. Це може бути абсолютний або +відносний шлях, який підтримує наступні формати: - **Точне співпадіння**: Відповідає точному URL-шляху. - Приклад: `/exact-path` - Приклад: `https://website.com/exact-path` -- **Співпадіння з використанням шаблону**: Використовує символи підстановки для відповідності будь-якій послідовності символів у шляху URL. Це може відповідати одному (за допомогою `*`) або кільком сегментам (за допомогою `**`). (Див. [Path Matching](#rules-path-matching) нижче). +- **Співпадіння з використанням шаблону**: Використовує символи підстановки для + відповідності будь-якій послідовності символів у шляху URL. Це може + відповідати одному (за допомогою `*`) або кільком сегментам (за допомогою + `**`). (Див. [Path Matching](#rules-path-matching) нижче). - - Приклад: `/trade/*` відповідатиме `/trade/123` і `/trade/abc`, захоплюючи лише перший сегмент після `/trade/`. - - Приклад: `/category/*/item/**` відповідатиме `/category/123/item/456` і `/category/abc/item/def`. - - Приклад: `/api/actions/trade/*/confirm` відповідатиме `/api/actions/trade/123/confirm`. + - Приклад: `/trade/*` відповідатиме `/trade/123` і `/trade/abc`, захоплюючи + лише перший сегмент після `/trade/`. + - Приклад: `/category/*/item/**` відповідатиме `/category/123/item/456` і + `/category/abc/item/def`. + - Приклад: `/api/actions/trade/*/confirm` відповідатиме + `/api/actions/trade/123/confirm`. #### Правила - apiPath -Шлях призначення для запиту дії. Він може бути визначений як абсолютний шлях або зовнішній URL. +Шлях призначення для запиту дії. Він може бути визначений як абсолютний шлях або +зовнішній URL. - Приклад: `/api/exact-path` - Приклад: `https://api.example.com/v1/donate/*` @@ -912,21 +1049,24 @@ interface ActionRuleObject { #### Правила - Query Parameters -Параметри запиту з оригінального URL завжди зберігаються та додаються до мапованого URL. +Параметри запиту з оригінального URL завжди зберігаються та додаються до +мапованого URL. #### Правила - Path Matching Наступна таблиця описує синтаксис для шаблонів відповідності шляхів: -| Оператор | Відповідає | -| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `*` | Один сегмент шляху, що не включає оточуючі символи розділювача шляху `/`. | +| Оператор | Відповідає | +| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `*` | Один сегмент шляху, що не включає оточуючі символи розділювача шляху `/`. | | `**` | Відповідає нулю або більшій кількості символів, включаючи будь-які символи розділювача шляху `/` між декількома сегментами шляху. Якщо включені інші оператори, оператор `**` повинен бути останнім. | -| `?` | Непідтримуваний шаблон. | +| `?` | Непідтримуваний шаблон. | ### Приклади Правил -Наступний приклад демонструє правило точного співпадіння для мапування запитів до `/buy` з кореня вашого сайту на точний шлях `/api/buy`, відносно кореня вашого сайту: +Наступний приклад демонструє правило точного співпадіння для мапування запитів +до `/buy` з кореня вашого сайту на точний шлях `/api/buy`, відносно кореня +вашого сайту: ```json filename="actions.json" { @@ -939,7 +1079,10 @@ interface ActionRuleObject { } ``` -Наступний приклад використовує шаблонне співставлення шляху для відображення запитів до будь-якого шляху (за винятком підкаталогів) під `/actions/` від кореня вашого сайту до відповідного шляху під `/api/actions/`, відносно кореня вашого сайту: +Наступний приклад використовує шаблонне співставлення шляху для відображення +запитів до будь-якого шляху (за винятком підкаталогів) під `/actions/` від +кореня вашого сайту до відповідного шляху під `/api/actions/`, відносно кореня +вашого сайту: ```json filename="actions.json" { @@ -952,7 +1095,10 @@ interface ActionRuleObject { } ``` -Наступний приклад використовує зіставлення шляхів із використанням символів підстановки для перенаправлення запитів до будь-якого шляху (за винятком підкаталогів) під `/donate/` у кореневій директорії вашого сайту до відповідного абсолютного шляху `https://api.dialect.com/api/v1/donate/` на зовнішньому сайті: +Наступний приклад використовує зіставлення шляхів із використанням символів +підстановки для перенаправлення запитів до будь-якого шляху (за винятком +підкаталогів) під `/donate/` у кореневій директорії вашого сайту до відповідного +абсолютного шляху `https://api.dialect.com/api/v1/donate/` на зовнішньому сайті: ```json filename="actions.json" { @@ -965,9 +1111,13 @@ interface ActionRuleObject { } ``` -Наступний приклад використовує зіставлення шляхів із використанням символів підстановки для ідемпотентного правила, щоб перенаправляти запити до будь-якого шляху (включаючи підкаталоги) під `/api/actions/` у кореневій директорії вашого сайту до самого себе: +Наступний приклад використовує зіставлення шляхів із використанням символів +підстановки для ідемпотентного правила, щоб перенаправляти запити до будь-якого +шляху (включаючи підкаталоги) під `/api/actions/` у кореневій директорії вашого +сайту до самого себе: -> Ідемпотентні правила дозволяють клієнтам blink легше визначати, чи підтримує даний шлях запити API дій, без необхідності: +> Ідемпотентні правила дозволяють клієнтам blink легше визначати, чи підтримує +> даний шлях запити API дій, без необхідності: > > - додавання префіксу `solana-action:` URI, > - виконання додаткового тестування відповіді, @@ -986,53 +1136,107 @@ interface ActionRuleObject { ## Ідентифікація Дії (Action Identity) -Кінцеві точки дій (Action endpoints) можуть включати _Ідентифікацію Дії_ у транзакціях, які повертаються у [POST-відповіді](#post-response) для підпису користувачем. Це дозволяє індексаторам та аналітичним платформам легко та достовірно приписувати активність у блокчейні конкретному провайдеру дій (тобто сервісу). - -[Ідентифікація Дії](#action-identity) — це пара ключів (keypair), яка використовується для підпису спеціально форматованого повідомлення, що включається до транзакції за допомогою інструкції Memo. Це _Повідомлення Ідентифікатора_ (_Identifier Message_) може бути достовірно приписане до конкретної Ідентифікації Дії, а отже, до конкретного провайдера дій. - -Пара ключів не вимагається для підписання самої транзакції. Це дозволяє гаманцям та додаткам покращити доставку транзакції, якщо у транзакції, поверненій користувачу, немає інших підписів (див. [POST-відповідь транзакції](#post-response-transaction)). - -Якщо сценарій використання провайдера дій вимагає, щоб їх бекенд-сервіси попередньо підписували транзакцію перед тим, як це зробить користувач, вони мають використовувати цю пару ключів як Ідентифікацію Дії. Це дозволить зменшити кількість облікових записів у транзакції, скоротивши її загальний розмір на 32 байти. +Кінцеві точки дій (Action endpoints) можуть включати _Ідентифікацію Дії_ у +транзакціях, які повертаються у [POST-відповіді](#post-response) для підпису +користувачем. Це дозволяє індексаторам та аналітичним платформам легко та +достовірно приписувати активність у блокчейні конкретному провайдеру дій (тобто +сервісу). + +[Ідентифікація Дії](#action-identity) — це пара ключів (keypair), яка +використовується для підпису спеціально форматованого повідомлення, що +включається до транзакції за допомогою інструкції Memo. Це _Повідомлення +Ідентифікатора_ (_Identifier Message_) може бути достовірно приписане до +конкретної Ідентифікації Дії, а отже, до конкретного провайдера дій. + +Пара ключів не вимагається для підписання самої транзакції. Це дозволяє гаманцям +та додаткам покращити доставку транзакції, якщо у транзакції, поверненій +користувачу, немає інших підписів (див. +[POST-відповідь транзакції](#post-response-transaction)). + +Якщо сценарій використання провайдера дій вимагає, щоб їх бекенд-сервіси +попередньо підписували транзакцію перед тим, як це зробить користувач, вони +мають використовувати цю пару ключів як Ідентифікацію Дії. Це дозволить зменшити +кількість облікових записів у транзакції, скоротивши її загальний розмір на 32 +байти. ### Повідомлення Ідентифікатора Дії (Action Identifier Message) -Повідомлення Ідентифікатора Дії — це UTF-8 рядок, розділений двокрапками, який включається до транзакції за допомогою однієї [інструкції SPL Memo](https://spl.solana.com/memo). +Повідомлення Ідентифікатора Дії — це UTF-8 рядок, розділений двокрапками, який +включається до транзакції за допомогою однієї +[інструкції SPL Memo](https://spl.solana.com/memo). ```shell protocol:identity:reference:signature ``` -- `protocol` - Значення протоколу, який використовується (встановлено як `solana-action` відповідно до [URL-схеми](#url-scheme) вище). -- `identity` - Значення має бути публічним ключем у форматі base58, який відповідає парі ключів Ідентифікації Дії. -- `reference` - Значення має бути масивом байтів довжиною 32 у форматі base58. Це можуть бути як публічні ключі, так і інші дані, які можуть або не можуть відповідати обліковим записам у Solana. -- `signature` - Підпис у форматі base58, створений парою ключів Ідентифікації Дії, що підписує лише значення `reference`. - -Значення `reference` має використовуватися тільки один раз і в одній транзакції. Для приписування транзакцій провайдеру дій, лише перше використання значення `reference` вважається дійсним. -Транзакції можуть містити кілька інструкцій Memo. Під час виконання [`getSignaturesForAddress`](https://solana.com/docs/rpc/http/getsignaturesforaddress) поле `memo` у результатах повертає повідомлення кожної інструкції Memo як єдиний рядок, розділений крапкою з комою. - -Жодні інші дані не повинні включатися до інструкції Memo Повідомлення Ідентифікатора. - -Облікові записи `identity` та `reference` повинні бути включені як доступні тільки для читання, але без можливості підпису ([ключі](https://solana-labs.github.io/solana-web3.js/v1.x/classes/TransactionInstruction.html#keys)) у транзакції в інструкції, яка не є Інструкцією Memo Повідомлення Ідентифікатора. - -Інструкція Memo Повідомлення Ідентифікатора не повинна містити жодних облікових записів. Якщо облікові записи надаються, програма Memo вимагає, щоб ці облікові записи були дійсними підписувачами. Це обмежує гнучкість і може погіршити досвід користувача, тому це вважається антипатерном і має бути уникнуто. +- `protocol` - Значення протоколу, який використовується (встановлено як + `solana-action` відповідно до [URL-схеми](#url-scheme) вище). +- `identity` - Значення має бути публічним ключем у форматі base58, який + відповідає парі ключів Ідентифікації Дії. +- `reference` - Значення має бути масивом байтів довжиною 32 у форматі base58. + Це можуть бути як публічні ключі, так і інші дані, які можуть або не можуть + відповідати обліковим записам у Solana. +- `signature` - Підпис у форматі base58, створений парою ключів Ідентифікації + Дії, що підписує лише значення `reference`. + +Значення `reference` має використовуватися тільки один раз і в одній транзакції. +Для приписування транзакцій провайдеру дій, лише перше використання значення +`reference` вважається дійсним. + +Транзакції можуть містити кілька інструкцій Memo. Під час виконання +[`getSignaturesForAddress`](https://solana.com/docs/rpc/http/getsignaturesforaddress) +поле `memo` у результатах повертає повідомлення кожної інструкції Memo як єдиний +рядок, розділений крапкою з комою. + +Жодні інші дані не повинні включатися до інструкції Memo Повідомлення +Ідентифікатора. + +Облікові записи `identity` та `reference` повинні бути включені як доступні +тільки для читання, але без можливості підпису +([ключі](https://solana-labs.github.io/solana-web3.js/v1.x/classes/TransactionInstruction.html#keys)) +у транзакції в інструкції, яка не є Інструкцією Memo Повідомлення +Ідентифікатора. + +Інструкція Memo Повідомлення Ідентифікатора не повинна містити жодних облікових +записів. Якщо облікові записи надаються, програма Memo вимагає, щоб ці облікові +записи були дійсними підписувачами. Це обмежує гнучкість і може погіршити досвід +користувача, тому це вважається антипатерном і має бути уникнуто. ### Перевірка Ідентифікації Дії (Action Identity Verification) -Будь-яка транзакція, що включає обліковий запис `identity`, може бути достовірно пов'язана з провайдером дій за допомогою багатоступінчастого процесу: +Будь-яка транзакція, що включає обліковий запис `identity`, може бути достовірно +пов'язана з провайдером дій за допомогою багатоступінчастого процесу: 1. Отримайте всі транзакції для заданого `identity`. -2. Розберіть і перевірте рядок memo кожної транзакції, переконавшись, що підпис `signature` дійсний для збереженого значення `reference`. -3. Перевірте, чи є ця транзакція першим випадком використання `reference` у блокчейні: - - Якщо ця транзакція є першим випадком, вона вважається підтвердженою і може бути достовірно приписана провайдеру дій. - - Якщо ця транзакція НЕ є першим випадком, вона вважається недійсною і, відповідно, не може бути приписана провайдеру дій. - -Оскільки валідатори Solana індексують транзакції за обліковими записами, метод RPC [`getSignaturesForAddress`](https://solana.com/docs/rpc/http/getsignaturesforaddress) може бути використаний для визначення всіх транзакцій, що включають обліковий запис `identity`. - -Відповідь цього методу RPC включає всі дані Memo у полі `memo`. Якщо в транзакції було використано кілька інструкцій Memo, кожне повідомлення Memo буде включено в це поле `memo` і має бути відповідним чином розібране перевіряючою стороною для отримання _Повідомлення Ідентифікації_. - -Ці транзакції спочатку мають вважатися **НЕПЕРЕВІРЕНИМИ**. Це пов'язано з тим, що `identity` не вимагається для підписання транзакції, що дозволяє будь-якій транзакції включати цей обліковий запис як не-підписувач. Це потенційно може штучно збільшити статистику приписування та використання. - -Повідомлення Ідентифікації має бути перевірене для забезпечення того, що `signature` було створено `identity`, підписуючи `reference`. Якщо ця перевірка підпису не вдається, транзакція вважається недійсною. - -Якщо перевірка підпису успішна, перевіряюча сторона має забезпечити, що ця транзакція є першим випадком використання `reference`. Якщо це не так, транзакція вважається недійсною. - +2. Розберіть і перевірте рядок memo кожної транзакції, переконавшись, що підпис + `signature` дійсний для збереженого значення `reference`. +3. Перевірте, чи є ця транзакція першим випадком використання `reference` у + блокчейні: + - Якщо ця транзакція є першим випадком, вона вважається підтвердженою і може + бути достовірно приписана провайдеру дій. + - Якщо ця транзакція НЕ є першим випадком, вона вважається недійсною і, + відповідно, не може бути приписана провайдеру дій. + +Оскільки валідатори Solana індексують транзакції за обліковими записами, метод +RPC +[`getSignaturesForAddress`](https://solana.com/docs/rpc/http/getsignaturesforaddress) +може бути використаний для визначення всіх транзакцій, що включають обліковий +запис `identity`. + +Відповідь цього методу RPC включає всі дані Memo у полі `memo`. Якщо в +транзакції було використано кілька інструкцій Memo, кожне повідомлення Memo буде +включено в це поле `memo` і має бути відповідним чином розібране перевіряючою +стороною для отримання _Повідомлення Ідентифікації_. + +Ці транзакції спочатку мають вважатися **НЕПЕРЕВІРЕНИМИ**. Це пов'язано з тим, +що `identity` не вимагається для підписання транзакції, що дозволяє будь-якій +транзакції включати цей обліковий запис як не-підписувач. Це потенційно може +штучно збільшити статистику приписування та використання. + +Повідомлення Ідентифікації має бути перевірене для забезпечення того, що +`signature` було створено `identity`, підписуючи `reference`. Якщо ця перевірка +підпису не вдається, транзакція вважається недійсною. + +Якщо перевірка підпису успішна, перевіряюча сторона має забезпечити, що ця +транзакція є першим випадком використання `reference`. Якщо це не так, +транзакція вважається недійсною. diff --git a/docs/locales/uk/advanced/confirmation.md b/docs/locales/uk/advanced/confirmation.md index 7134d5313..08621dfb1 100644 --- a/docs/locales/uk/advanced/confirmation.md +++ b/docs/locales/uk/advanced/confirmation.md @@ -4,96 +4,126 @@ sidebarLabel: "Підтвердження та закінчення строку title: "Підтвердження транзакції та закінчення строку дії" seoTitle: "Підтвердження транзакції та закінчення строку дії" description: - "Дізнайтеся, як працює підтвердження транзакцій у Solana і коли транзакція завершує дію - (включаючи перевірку останніх blockhash)." + "Дізнайтеся, як працює підтвердження транзакцій у Solana і коли транзакція + завершує дію (включаючи перевірку останніх blockhash)." altRoutes: - /docs/uk/advanced - /docs/uk/core/transactions/confirmation --- -Проблеми, пов'язані з -[підтвердженням транзакції](/docs/uk/terminology.md#transaction-confirmations), -є поширеними серед нових розробників під час створення застосунків. Ця стаття має на меті підвищити загальне розуміння механізму підтвердження, який використовується в блокчейні Solana, включаючи деякі рекомендовані найкращі практики. +Проблеми, пов'язані з +[підтвердженням транзакції](/docs/uk/terminology.md#transaction-confirmations), +є поширеними серед нових розробників під час створення застосунків. Ця стаття +має на меті підвищити загальне розуміння механізму підтвердження, який +використовується в блокчейні Solana, включаючи деякі рекомендовані найкращі +практики. ## Короткий вступ до транзакцій -Перед тим як розглянути, як працює підтвердження та закінчення строку дії транзакцій у Solana, давайте коротко розглянемо кілька основ: +Перед тим як розглянути, як працює підтвердження та закінчення строку дії +транзакцій у Solana, давайте коротко розглянемо кілька основ: - що таке транзакція, - життєвий цикл транзакції, - що таке blockhash, -- і коротке ознайомлення з Proof of History (PoH) і тим, як це стосується blockhash. +- і коротке ознайомлення з Proof of History (PoH) і тим, як це стосується + blockhash. ### Що таке транзакція? -Транзакції складаються з двох компонентів: -[повідомлення](/docs/uk/terminology.md#message) -і -[списку підписів](/docs/uk/terminology.md#signature). -Повідомлення транзакції містить основну інформацію та складається з чотирьох компонентів: +Транзакції складаються з двох компонентів: +[повідомлення](/docs/uk/terminology.md#message) і +[списку підписів](/docs/uk/terminology.md#signature). Повідомлення транзакції +містить основну інформацію та складається з чотирьох компонентів: - **заголовок** з метаданими про транзакцію, - **список інструкцій** для виконання, - **список акаунтів**, які потрібно завантажити, - та **“недавній blockhash”**. -У цій статті ми зосередимося на -[недавньому blockhash](/docs/uk/terminology.md#blockhash), -оскільки він відіграє важливу роль у підтвердженні транзакції. +У цій статті ми зосередимося на +[недавньому blockhash](/docs/uk/terminology.md#blockhash), оскільки він відіграє +важливу роль у підтвердженні транзакції. ### Життєвий цикл транзакції -Нижче наведено основні етапи життєвого циклу транзакції. У цій статті розглядаються всі етапи, крім 1 і 4. +Нижче наведено основні етапи життєвого циклу транзакції. У цій статті +розглядаються всі етапи, крім 1 і 4. -1. Створення заголовка та списку інструкцій разом із переліком акаунтів, які потрібно прочитати або записати. -2. Отримання недавнього blockhash та його використання для підготовки повідомлення транзакції. +1. Створення заголовка та списку інструкцій разом із переліком акаунтів, які + потрібно прочитати або записати. +2. Отримання недавнього blockhash та його використання для підготовки + повідомлення транзакції. 3. Симуляція транзакції, щоб переконатися, що вона поводиться очікувано. -4. Запит користувача на підписання підготовленого повідомлення транзакції за допомогою його приватного ключа. -5. Відправка транзакції до RPC-вузла, який намагається передати її поточному виробнику блоків. +4. Запит користувача на підписання підготовленого повідомлення транзакції за + допомогою його приватного ключа. +5. Відправка транзакції до RPC-вузла, який намагається передати її поточному + виробнику блоків. 6. Очікування, що виробник блоку перевірить і додасть транзакцію до свого блоку. -7. Підтвердження того, що транзакція або була включена в блок, або закінчився її термін дії. +7. Підтвердження того, що транзакція або була включена в блок, або закінчився її + термін дії. ### Що таке Blockhash? -[“Blockhash”](/docs/uk/terminology.md#blockhash) -означає останній Proof of History (PoH) хеш для -[“слота”](/docs/uk/terminology.md#slot) -(опис нижче). Оскільки Solana використовує PoH як довірений годинник, недавній blockhash транзакції можна розглядати як **мітку часу**. +[“Blockhash”](/docs/uk/terminology.md#blockhash) означає останній Proof of +History (PoH) хеш для [“слота”](/docs/uk/terminology.md#slot) (опис нижче). +Оскільки Solana використовує PoH як довірений годинник, недавній blockhash +транзакції можна розглядати як **мітку часу**. ### Коротке нагадування про Proof of History -Механізм Proof of History у Solana використовує довгий ланцюг рекурсивних хешів SHA-256 для створення довіреного годинника. Назва “історія” походить від того, що виробники блоків додають хеш ідентифікаторів транзакцій у потік, щоб зафіксувати, які транзакції були оброблені в їхньому блоці. +Механізм Proof of History у Solana використовує довгий ланцюг рекурсивних хешів +SHA-256 для створення довіреного годинника. Назва “історія” походить від того, +що виробники блоків додають хеш ідентифікаторів транзакцій у потік, щоб +зафіксувати, які транзакції були оброблені в їхньому блоці. -[Обчислення PoH-хешу](https://github.com/anza-xyz/agave/blob/aa0922d6845e119ba466f88497e8209d1c82febc/entry/src/poh.rs#L79): +[Обчислення PoH-хешу](https://github.com/anza-xyz/agave/blob/aa0922d6845e119ba466f88497e8209d1c82febc/entry/src/poh.rs#L79): `next_hash = hash(prev_hash, hash(transaction_ids))`. -PoH може використовуватися як довірений годинник, оскільки кожен хеш має бути створений послідовно. Кожен згенерований блок містить blockhash і список контрольних точок хешів, званих “ticks,” які дозволяють валідаторам перевіряти весь ланцюг хешів паралельно та доводити, що певний час дійсно минув. +PoH може використовуватися як довірений годинник, оскільки кожен хеш має бути +створений послідовно. Кожен згенерований блок містить blockhash і список +контрольних точок хешів, званих “ticks,” які дозволяють валідаторам перевіряти +весь ланцюг хешів паралельно та доводити, що певний час дійсно минув. ## Закінчення строку дії транзакції -За замовчуванням усі транзакції Solana закінчують строк дії, якщо їх не включено в блок протягом певного періоду часу. **Переважна більшість** проблем із підтвердженням транзакцій пов'язана з тим, як RPC-вузли та валідатори виявляють і обробляють **прострочені** транзакції. Чітке розуміння механізму закінчення строку дії транзакції допоможе вам діагностувати більшість проблем із підтвердженням транзакцій. +За замовчуванням усі транзакції Solana закінчують строк дії, якщо їх не включено +в блок протягом певного періоду часу. **Переважна більшість** проблем із +підтвердженням транзакцій пов'язана з тим, як RPC-вузли та валідатори виявляють +і обробляють **прострочені** транзакції. Чітке розуміння механізму закінчення +строку дії транзакції допоможе вам діагностувати більшість проблем із +підтвердженням транзакцій. ### Як працює закінчення строку дії транзакції? -Кожна транзакція містить “недавній blockhash,” який використовується як часовий штамп PoH і закінчується, коли цей blockhash більше не вважається “достатньо недавнім.” - -Коли кожен блок завершується (тобто досягається максимальна висота тиків, -[визначена](https://github.com/anza-xyz/agave/blob/0588ecc6121ba026c65600d117066dbdfaf63444/runtime/src/bank.rs#L3269-L3271), -до "кордону блоку"), фінальний хеш блоку додається до `BlockhashQueue`, яка зберігає максимум -[300 найновіших blockhash](https://github.com/anza-xyz/agave/blob/e0b0bcc80380da34bb63364cc393801af1e1057f/sdk/program/src/clock.rs#L123-L126). -Під час обробки транзакцій валідатори Solana перевіряють, чи зберігається недавній blockhash транзакції серед останніх 151 записаних хешів (так званий "максимальний вік обробки"). Якщо недавній blockhash транзакції -[старший за цей вік](https://github.com/anza-xyz/agave/blob/cb2fd2b632f16a43eff0c27af7458e4e97512e31/runtime/src/bank.rs#L3570-L3571), +Кожна транзакція містить “недавній blockhash,” який використовується як часовий +штамп PoH і закінчується, коли цей blockhash більше не вважається “достатньо +недавнім.” + +Коли кожен блок завершується (тобто досягається максимальна висота тиків, +[визначена](https://github.com/anza-xyz/agave/blob/0588ecc6121ba026c65600d117066dbdfaf63444/runtime/src/bank.rs#L3269-L3271), +до "кордону блоку"), фінальний хеш блоку додається до `BlockhashQueue`, яка +зберігає максимум +[300 найновіших blockhash](https://github.com/anza-xyz/agave/blob/e0b0bcc80380da34bb63364cc393801af1e1057f/sdk/program/src/clock.rs#L123-L126). +Під час обробки транзакцій валідатори Solana перевіряють, чи зберігається +недавній blockhash транзакції серед останніх 151 записаних хешів (так званий +"максимальний вік обробки"). Якщо недавній blockhash транзакції +[старший за цей вік](https://github.com/anza-xyz/agave/blob/cb2fd2b632f16a43eff0c27af7458e4e97512e31/runtime/src/bank.rs#L3570-L3571), транзакція не обробляється. -> Завдяки поточному -> [максимальному віку обробки, що становить 150](https://github.com/anza-xyz/agave/blob/cb2fd2b632f16a43eff0c27af7458e4e97512e31/sdk/program/src/clock.rs#L129-L131) -> і тому, що "вік" blockhash у черзі є -> [нульовим індексом](https://github.com/anza-xyz/agave/blob/992a398fe8ea29ec4f04d081ceef7664960206f4/accounts-db/src/blockhash_queue.rs#L248-L274), -> фактично є 151 blockhash, які вважаються "достатньо недавніми" і дійсними для обробки. +> Завдяки поточному +> [максимальному віку обробки, що становить 150](https://github.com/anza-xyz/agave/blob/cb2fd2b632f16a43eff0c27af7458e4e97512e31/sdk/program/src/clock.rs#L129-L131) +> і тому, що "вік" blockhash у черзі є +> [нульовим індексом](https://github.com/anza-xyz/agave/blob/992a398fe8ea29ec4f04d081ceef7664960206f4/accounts-db/src/blockhash_queue.rs#L248-L274), +> фактично є 151 blockhash, які вважаються "достатньо недавніми" і дійсними для +> обробки. -Оскільки [слоти](/docs/uk/terminology.md#slot) (тобто періоди часу, протягом яких валідатор може створити блок) налаштовані на тривалість близько -[400 мс](https://github.com/anza-xyz/agave/blob/cb2fd2b632f16a43eff0c27af7458e4e97512e31/sdk/program/src/clock.rs#L107-L109), -але можуть коливатися між 400 мс і 600 мс, певний blockhash можна використовувати в транзакціях приблизно протягом 60–90 секунд, перш ніж він вважатиметься простроченим у середовищі виконання. +Оскільки [слоти](/docs/uk/terminology.md#slot) (тобто періоди часу, протягом +яких валідатор може створити блок) налаштовані на тривалість близько +[400 мс](https://github.com/anza-xyz/agave/blob/cb2fd2b632f16a43eff0c27af7458e4e97512e31/sdk/program/src/clock.rs#L107-L109), +але можуть коливатися між 400 мс і 600 мс, певний blockhash можна +використовувати в транзакціях приблизно протягом 60–90 секунд, перш ніж він +вважатиметься простроченим у середовищі виконання. ### Приклад закінчення строку дії транзакції @@ -101,16 +131,26 @@ PoH може використовуватися як довірений годи 1. Валідатор активно створює новий блок для поточного слота. 2. Валідатор отримує транзакцію від користувача з недавнім blockhash `abcd...`. -3. Валідатор перевіряє цей blockhash `abcd...` у списку недавніх blockhash у `BlockhashQueue` і виявляє, що він був створений 151 блок тому. -4. Оскільки йому рівно 151 блок, транзакція ще не прострочена та може бути оброблена. -5. Але зачекайте: перед обробкою транзакції валідатор завершує створення наступного блоку та додає його до `BlockhashQueue`. Потім валідатор починає створювати блок для наступного слота (валідатори можуть створювати блоки протягом 4 послідовних слотів). -6. Валідатор перевіряє ту ж транзакцію ще раз і виявляє, що їй тепер 152 блоки. Вона відхиляється, оскільки занадто стара. :( +3. Валідатор перевіряє цей blockhash `abcd...` у списку недавніх blockhash у + `BlockhashQueue` і виявляє, що він був створений 151 блок тому. +4. Оскільки йому рівно 151 блок, транзакція ще не прострочена та може бути + оброблена. +5. Але зачекайте: перед обробкою транзакції валідатор завершує створення + наступного блоку та додає його до `BlockhashQueue`. Потім валідатор починає + створювати блок для наступного слота (валідатори можуть створювати блоки + протягом 4 послідовних слотів). +6. Валідатор перевіряє ту ж транзакцію ще раз і виявляє, що їй тепер 152 блоки. + Вона відхиляється, оскільки занадто стара. :( ## Чому транзакції закінчують строк дії? -Це робиться для того, щоб валідатори могли уникнути повторної обробки тієї ж транзакції. +Це робиться для того, щоб валідатори могли уникнути повторної обробки тієї ж +транзакції. -Наївний підхід для запобігання повторній обробці полягав би в перевірці кожної нової транзакції з усією історією транзакцій блокчейна. Але завдяки тому, що транзакції закінчують строк дії за короткий період часу, валідаторам потрібно перевіряти лише відносно невеликий набір **недавніх** транзакцій. +Наївний підхід для запобігання повторній обробці полягав би в перевірці кожної +нової транзакції з усією історією транзакцій блокчейна. Але завдяки тому, що +транзакції закінчують строк дії за короткий період часу, валідаторам потрібно +перевіряти лише відносно невеликий набір **недавніх** транзакцій. ### Other blockchains @@ -126,124 +166,229 @@ processing. ### Інші блокчейни -Підхід Solana до запобігання повторній обробці транзакцій значно відрізняється від інших блокчейнів. Наприклад, Ethereum використовує лічильник (nonce) для кожного відправника транзакцій і обробляє лише транзакції, які використовують наступний дійсний nonce. +Підхід Solana до запобігання повторній обробці транзакцій значно відрізняється +від інших блокчейнів. Наприклад, Ethereum використовує лічильник (nonce) для +кожного відправника транзакцій і обробляє лише транзакції, які використовують +наступний дійсний nonce. -Підхід Ethereum є простим для реалізації валідаторами, але може викликати проблеми для користувачів. Багато хто стикався із ситуаціями, коли їхні транзакції Ethereum залишалися в стані **очікування** протягом тривалого часу, а всі подальші транзакції з більшими значеннями nonce блокувалися. +Підхід Ethereum є простим для реалізації валідаторами, але може викликати +проблеми для користувачів. Багато хто стикався із ситуаціями, коли їхні +транзакції Ethereum залишалися в стані **очікування** протягом тривалого часу, а +всі подальші транзакції з більшими значеннями nonce блокувалися. ### Переваги на Solana Solana має кілька переваг у цьому підході: -1. Один платник комісії може надсилати кілька транзакцій одночасно, які можуть оброблятися в будь-якому порядку. Це може статися, якщо ви використовуєте кілька додатків одночасно. -2. Якщо транзакція не була додана до блоку та закінчила строк дії, користувачі можуть спробувати знову, знаючи, що їхня попередня транзакція **ніколи** не буде оброблена. +1. Один платник комісії може надсилати кілька транзакцій одночасно, які можуть + оброблятися в будь-якому порядку. Це може статися, якщо ви використовуєте + кілька додатків одночасно. +2. Якщо транзакція не була додана до блоку та закінчила строк дії, користувачі + можуть спробувати знову, знаючи, що їхня попередня транзакція **ніколи** не + буде оброблена. -Відсутність використання лічильників робить досвід роботи з Solana більш зрозумілим для користувачів, оскільки вони швидше отримують результат — успіх, невдачу або закінчення строку дії — та уникають тривалого стану очікування. +Відсутність використання лічильників робить досвід роботи з Solana більш +зрозумілим для користувачів, оскільки вони швидше отримують результат — успіх, +невдачу або закінчення строку дії — та уникають тривалого стану очікування. ### Недоліки на Solana Звісно, є й недоліки: -1. Валідатори повинні активно відстежувати набір усіх оброблених ідентифікаторів транзакцій, щоб запобігти їх повторній обробці. -2. Якщо час закінчення строку дії надто короткий, користувачі можуть не встигнути надіслати свої транзакції до того, як вони стануть недійсними. +1. Валідатори повинні активно відстежувати набір усіх оброблених ідентифікаторів + транзакцій, щоб запобігти їх повторній обробці. +2. Якщо час закінчення строку дії надто короткий, користувачі можуть не + встигнути надіслати свої транзакції до того, як вони стануть недійсними. -Ці недоліки показують компроміс у тому, як налаштовано строк дії транзакцій. Якщо збільшити час закінчення строку дії, валідаторам доведеться використовувати більше пам’яті для відстеження транзакцій. Якщо ж скоротити строк дії, користувачам буде важче встигнути надіслати свої транзакції. +Ці недоліки показують компроміс у тому, як налаштовано строк дії транзакцій. +Якщо збільшити час закінчення строку дії, валідаторам доведеться використовувати +більше пам’яті для відстеження транзакцій. Якщо ж скоротити строк дії, +користувачам буде важче встигнути надіслати свої транзакції. -Наразі кластери Solana вимагають, щоб транзакції використовували blockhash, який не старший за 151 блок. +Наразі кластери Solana вимагають, щоб транзакції використовували blockhash, який +не старший за 151 блок. -> У цьому [питанні GitHub](https://github.com/solana-labs/solana/issues/23582) надані розрахунки, які оцінюють, що валідаторам mainnet-beta потрібно близько 150 МБ пам’яті для відстеження транзакцій. У майбутньому це можна оптимізувати, не скорочуючи строк дії транзакцій, як зазначено в цьому обговоренні. +> У цьому [питанні GitHub](https://github.com/solana-labs/solana/issues/23582) +> надані розрахунки, які оцінюють, що валідаторам mainnet-beta потрібно близько +> 150 МБ пам’яті для відстеження транзакцій. У майбутньому це можна +> оптимізувати, не скорочуючи строк дії транзакцій, як зазначено в цьому +> обговоренні. ## Поради щодо підтвердження транзакцій -Як зазначалося раніше, blockhash закінчують строк дії через період, який може тривати всього **одну хвилину**, коли слоти обробляються з цільовим часом 400 мс. +Як зазначалося раніше, blockhash закінчують строк дії через період, який може +тривати всього **одну хвилину**, коли слоти обробляються з цільовим часом 400 +мс. -Одна хвилина — це не багато, враховуючи, що клієнту потрібно отримати недавній blockhash, дочекатися підписання транзакції користувачем, а потім сподіватися, що надіслана транзакція досягне лідера, який погодиться її обробити. Розглянемо кілька порад, які допоможуть уникнути невдач підтвердження через закінчення строку дії транзакцій. +Одна хвилина — це не багато, враховуючи, що клієнту потрібно отримати недавній +blockhash, дочекатися підписання транзакції користувачем, а потім сподіватися, +що надіслана транзакція досягне лідера, який погодиться її обробити. Розглянемо +кілька порад, які допоможуть уникнути невдач підтвердження через закінчення +строку дії транзакцій. ### Отримуйте blockhash із відповідним рівнем підтвердження -З огляду на короткий період закінчення строку дії, клієнти та додатки повинні допомагати користувачам створювати транзакції з blockhash, який є максимально недавнім. +З огляду на короткий період закінчення строку дії, клієнти та додатки повинні +допомагати користувачам створювати транзакції з blockhash, який є максимально +недавнім. -Коли ви отримуєте blockhash, рекомендованим RPC API є [`getLatestBlockhash`](/docs/uk/rpc/http/getLatestBlockhash.mdx). За замовчуванням цей API використовує рівень підтвердження `finalized`, щоб повернути blockhash останнього фіналізованого блоку. Проте ви можете змінити цю поведінку, встановивши параметр `commitment` на інший рівень підтвердження. +Коли ви отримуєте blockhash, рекомендованим RPC API є +[`getLatestBlockhash`](/docs/uk/rpc/http/getLatestBlockhash.mdx). За +замовчуванням цей API використовує рівень підтвердження `finalized`, щоб +повернути blockhash останнього фіналізованого блоку. Проте ви можете змінити цю +поведінку, встановивши параметр `commitment` на інший рівень підтвердження. **Рекомендація** -Рівень підтвердження `confirmed` майже завжди слід використовувати для запитів RPC, оскільки він зазвичай лише на кілька слотів відстає від рівня `processed` і має дуже низьку ймовірність належати до відхиленого [форку](https://docs.anza.xyz/consensus/fork-generation). +Рівень підтвердження `confirmed` майже завжди слід використовувати для запитів +RPC, оскільки він зазвичай лише на кілька слотів відстає від рівня `processed` і +має дуже низьку ймовірність належати до відхиленого +[форку](https://docs.anza.xyz/consensus/fork-generation). Але ви також можете розглянути інші варіанти: -- Вибір `processed` дозволяє отримати найбільш недавній blockhash порівняно з іншими рівнями підтвердження, що дає більше часу на підготовку і обробку транзакції. Однак через поширеність форків у блокчейні Solana близько 5% блоків не потрапляють у фіналізований кластер, що створює ризик того, що ваша транзакція використовує blockhash, що належить до відкинутого форку. Транзакції з такими blockhash ніколи не будуть вважатися недавніми у фіналізованому блокчейні. -- Використання [рівня підтвердження за замовчуванням](/docs/uk/rpc#default-commitment) `finalized` виключає ризик того, що вибраний blockhash належатиме до відкинутого форку. Однак це має компроміс: зазвичай є щонайменше 32 слоти різниці між найбільш недавнім підтвердженим блоком і найбільш недавнім фіналізованим блоком. Це значно зменшує строк дії ваших транзакцій приблизно на 13 секунд, що може бути ще більш суттєвим за нестабільних умов кластеру. +- Вибір `processed` дозволяє отримати найбільш недавній blockhash порівняно з + іншими рівнями підтвердження, що дає більше часу на підготовку і обробку + транзакції. Однак через поширеність форків у блокчейні Solana близько 5% + блоків не потрапляють у фіналізований кластер, що створює ризик того, що ваша + транзакція використовує blockhash, що належить до відкинутого форку. + Транзакції з такими blockhash ніколи не будуть вважатися недавніми у + фіналізованому блокчейні. +- Використання + [рівня підтвердження за замовчуванням](/docs/uk/rpc#default-commitment) + `finalized` виключає ризик того, що вибраний blockhash належатиме до + відкинутого форку. Однак це має компроміс: зазвичай є щонайменше 32 слоти + різниці між найбільш недавнім підтвердженим блоком і найбільш недавнім + фіналізованим блоком. Це значно зменшує строк дії ваших транзакцій приблизно + на 13 секунд, що може бути ще більш суттєвим за нестабільних умов кластеру. ### Використовуйте відповідний рівень підтвердження для preflight -Якщо ваша транзакція використовує blockhash, отриманий з одного RPC-вузла, але надсилається або симулюється на іншому, можуть виникнути проблеми через затримку одного з вузлів. +Якщо ваша транзакція використовує blockhash, отриманий з одного RPC-вузла, але +надсилається або симулюється на іншому, можуть виникнути проблеми через затримку +одного з вузлів. -Коли RPC-вузли отримують запит `sendTransaction`, вони намагаються визначити строк дії транзакції, використовуючи найбільш недавній фіналізований блок або блок, вибраний параметром `preflightCommitment`. **Дуже поширена проблема** виникає, якщо blockhash транзакції створений після блоку, який використовується для обчислення строку дії. У такому випадку RPC-вузол лише один раз пересилає транзакцію, а потім **видаляє** її. +Коли RPC-вузли отримують запит `sendTransaction`, вони намагаються визначити +строк дії транзакції, використовуючи найбільш недавній фіналізований блок або +блок, вибраний параметром `preflightCommitment`. **Дуже поширена проблема** +виникає, якщо blockhash транзакції створений після блоку, який використовується +для обчислення строку дії. У такому випадку RPC-вузол лише один раз пересилає +транзакцію, а потім **видаляє** її. -Аналогічно, при отриманні запиту `simulateTransaction` RPC-вузли симулюють транзакцію, використовуючи найбільш недавній фіналізований блок або блок, вибраний параметром `preflightCommitment`. Якщо вибраний блок для симуляції старіший за blockhash транзакції, симуляція завершиться помилкою “blockhash not found”. +Аналогічно, при отриманні запиту `simulateTransaction` RPC-вузли симулюють +транзакцію, використовуючи найбільш недавній фіналізований блок або блок, +вибраний параметром `preflightCommitment`. Якщо вибраний блок для симуляції +старіший за blockhash транзакції, симуляція завершиться помилкою “blockhash not +found”. **Рекомендація** -Навіть якщо ви використовуєте `skipPreflight`, **завжди** встановлюйте параметр `preflightCommitment` на той самий рівень підтвердження, який використовувався для отримання blockhash транзакції, як для запитів `sendTransaction`, так і `simulateTransaction`. +Навіть якщо ви використовуєте `skipPreflight`, **завжди** встановлюйте параметр +`preflightCommitment` на той самий рівень підтвердження, який використовувався +для отримання blockhash транзакції, як для запитів `sendTransaction`, так і +`simulateTransaction`. ### Уникайте відставання RPC-вузлів під час надсилання транзакцій -Якщо ваш додаток використовує сервіс пулу RPC або якщо кінцева точка RPC відрізняється між створенням транзакції та її надсиланням, будьте обережні зі сценаріями, коли один RPC-вузол відстає від іншого. Наприклад, якщо blockhash транзакції отримано з одного RPC-вузла, а транзакція надсилається на інший для обробки або симуляції, другий RPC-вузол може відставати. +Якщо ваш додаток використовує сервіс пулу RPC або якщо кінцева точка RPC +відрізняється між створенням транзакції та її надсиланням, будьте обережні зі +сценаріями, коли один RPC-вузол відстає від іншого. Наприклад, якщо blockhash +транзакції отримано з одного RPC-вузла, а транзакція надсилається на інший для +обробки або симуляції, другий RPC-вузол може відставати. **Рекомендація** -Для запитів `sendTransaction` клієнти повинні повторно надсилати транзакцію до RPC-вузла на частих інтервалах, щоб у випадку, якщо RPC-вузол трохи відстає від кластеру, він врешті-решт виявив транзакцію та її строк дії. +Для запитів `sendTransaction` клієнти повинні повторно надсилати транзакцію до +RPC-вузла на частих інтервалах, щоб у випадку, якщо RPC-вузол трохи відстає від +кластеру, він врешті-решт виявив транзакцію та її строк дії. -Для запитів `simulateTransaction` клієнти повинні використовувати параметр -[`replaceRecentBlockhash`](/docs/uk/rpc/http/simulateTransaction.mdx), щоб інструктувати RPC-вузол замінювати blockhash симульованої транзакції на blockhash, який завжди буде дійсним для симуляції. +Для запитів `simulateTransaction` клієнти повинні використовувати параметр +[`replaceRecentBlockhash`](/docs/uk/rpc/http/simulateTransaction.mdx), щоб +інструктувати RPC-вузол замінювати blockhash симульованої транзакції на +blockhash, який завжди буде дійсним для симуляції. ### Уникайте повторного використання застарілих blockhash -Навіть якщо ваш додаток отримав дуже недавній blockhash, переконайтеся, що ви не використовуєте його надто довго. Ідеальний сценарій — отримати свіжий blockhash безпосередньо перед підписанням транзакції. +Навіть якщо ваш додаток отримав дуже недавній blockhash, переконайтеся, що ви не +використовуєте його надто довго. Ідеальний сценарій — отримати свіжий blockhash +безпосередньо перед підписанням транзакції. **Рекомендація для додатків** -Часто запитуйте нові blockhash, щоб забезпечити готовність вашого додатка до створення транзакції, коли користувач виконує дію. +Часто запитуйте нові blockhash, щоб забезпечити готовність вашого додатка до +створення транзакції, коли користувач виконує дію. **Рекомендація для гаманців** -Часто запитуйте нові blockhash та оновлюйте blockhash транзакції перед підписанням, щоб забезпечити її актуальність. +Часто запитуйте нові blockhash та оновлюйте blockhash транзакції перед +підписанням, щоб забезпечити її актуальність. ### Використовуйте надійні RPC-вузли для отримання blockhash -RPC-вузли можуть відставати від кластеру через навантаження або інші причини, повертаючи blockhash, який майже вичерпав строк дії. +RPC-вузли можуть відставати від кластеру через навантаження або інші причини, +повертаючи blockhash, який майже вичерпав строк дії. **Рекомендація** Моніторте стан RPC-вузлів, використовуючи такі методи: -1. Викликайте API - [`getSlot`](/docs/uk/rpc/http/getSlot.mdx) з рівнем підтвердження `processed` для отримання останнього обробленого слота вузла та порівняйте його з - [`getMaxShredInsertSlot`](/docs/uk/rpc/http/getMaxShredInsertSlot.mdx), щоб оцінити відставання вузла. -2. Використовуйте RPC API `getLatestBlockhash` з рівнем підтвердження `confirmed` на кількох різних RPC-вузлах та обирайте blockhash від вузла, який повертає найвищий слот для свого [контекстного слоту](/docs/uk/rpc/index.mdx#rpcresponse-structure). +1. Викликайте API [`getSlot`](/docs/uk/rpc/http/getSlot.mdx) з рівнем + підтвердження `processed` для отримання останнього обробленого слота вузла та + порівняйте його з + [`getMaxShredInsertSlot`](/docs/uk/rpc/http/getMaxShredInsertSlot.mdx), щоб + оцінити відставання вузла. +2. Використовуйте RPC API `getLatestBlockhash` з рівнем підтвердження + `confirmed` на кількох різних RPC-вузлах та обирайте blockhash від вузла, + який повертає найвищий слот для свого + [контекстного слоту](/docs/uk/rpc/index.mdx#rpcresponse-structure). ### Зачекайте достатньо довго перед закінченням терміну дії **Рекомендація** -При виклику RPC API [`getLatestBlockhash`](/docs/uk/rpc/http/getLatestBlockhash.mdx) для отримання останнього blockhash вашої транзакції зверніть увагу на `lastValidBlockHeight` у відповіді. +При виклику RPC API +[`getLatestBlockhash`](/docs/uk/rpc/http/getLatestBlockhash.mdx) для отримання +останнього blockhash вашої транзакції зверніть увагу на `lastValidBlockHeight` у +відповіді. -Потім викликайте RPC API [`getBlockHeight`](/docs/uk/rpc/http/getBlockHeight.mdx) з рівнем підтвердження `confirmed`, поки він не поверне висоту блоку, більшу за попередньо отриманий `lastValidBlockHeight`. +Потім викликайте RPC API +[`getBlockHeight`](/docs/uk/rpc/http/getBlockHeight.mdx) з рівнем підтвердження +`confirmed`, поки він не поверне висоту блоку, більшу за попередньо отриманий +`lastValidBlockHeight`. ### Розгляньте використання "довготривалих" транзакцій -Іноді уникнути проблем із закінченням терміну дії транзакції дуже важко (наприклад, при офлайн-підписанні або нестабільності кластера). Якщо попередні поради не підходять для вашого випадку використання, ви можете перейти на використання довготривалих транзакцій (вони вимагають трохи налаштувань). +Іноді уникнути проблем із закінченням терміну дії транзакції дуже важко +(наприклад, при офлайн-підписанні або нестабільності кластера). Якщо попередні +поради не підходять для вашого випадку використання, ви можете перейти на +використання довготривалих транзакцій (вони вимагають трохи налаштувань). -Щоб почати використовувати довготривалі транзакції, користувач спочатку повинен подати транзакцію, яка -[викликає інструкції для створення спеціального "nonce" облікового запису на блокчейні](https://docs.rs/solana-program/latest/solana_program/system_instruction/fn.create_nonce_account.html) і зберігає в ньому "довготривалий blockhash". У будь-який момент у майбутньому (доки nonce-аккаунт ще не використаний) користувач може створити довготривалу транзакцію, дотримуючись двох правил: +Щоб почати використовувати довготривалі транзакції, користувач спочатку повинен +подати транзакцію, яка +[викликає інструкції для створення спеціального "nonce" облікового запису на блокчейні](https://docs.rs/solana-program/latest/solana_program/system_instruction/fn.create_nonce_account.html) +і зберігає в ньому "довготривалий blockhash". У будь-який момент у майбутньому +(доки nonce-аккаунт ще не використаний) користувач може створити довготривалу +транзакцію, дотримуючись двох правил: -1. Список інструкцій повинен починатися з [системної інструкції "advance nonce"](https://docs.rs/solana-program/latest/solana_program/system_instruction/fn.advance_nonce_account.html), яка завантажує їх nonce-аккаунт. -2. Blockhash транзакції повинен дорівнювати довготривалому blockhash, збереженому nonce-аккаунтом на блокчейні. +1. Список інструкцій повинен починатися з + [системної інструкції "advance nonce"](https://docs.rs/solana-program/latest/solana_program/system_instruction/fn.advance_nonce_account.html), + яка завантажує їх nonce-аккаунт. +2. Blockhash транзакції повинен дорівнювати довготривалому blockhash, + збереженому nonce-аккаунтом на блокчейні. Ось як Solana обробляє ці довготривалі транзакції: -1. Якщо blockhash транзакції більше не є "недавнім", система перевіряє, чи починається список інструкцій транзакції з інструкції "advance nonce". +1. Якщо blockhash транзакції більше не є "недавнім", система перевіряє, чи + починається список інструкцій транзакції з інструкції "advance nonce". 2. Якщо так, система завантажує nonce-аккаунт, вказаний у цій інструкції. -3. Потім перевіряє, чи збережений довготривалий blockhash відповідає blockhash транзакції. -4. Нарешті, система оновлює blockhash nonce-аккаунту до останнього недавнього blockhash, щоб гарантувати, що ця ж транзакція не може бути оброблена повторно. - -Детальніше про роботу цих довготривалих транзакцій ви можете дізнатися з [оригінальної пропозиції](https://docs.anza.xyz/implemented-proposals/durable-tx-nonces) та [ознайомитися з прикладом](/content/guides/advanced/introduction-to-durable-nonces.md) у документації Solana. +3. Потім перевіряє, чи збережений довготривалий blockhash відповідає blockhash + транзакції. +4. Нарешті, система оновлює blockhash nonce-аккаунту до останнього недавнього + blockhash, щоб гарантувати, що ця ж транзакція не може бути оброблена + повторно. + +Детальніше про роботу цих довготривалих транзакцій ви можете дізнатися з +[оригінальної пропозиції](https://docs.anza.xyz/implemented-proposals/durable-tx-nonces) +та +[ознайомитися з прикладом](/content/guides/advanced/introduction-to-durable-nonces.md) +у документації Solana. diff --git a/docs/locales/uk/advanced/lookup-tables.md b/docs/locales/uk/advanced/lookup-tables.md index 360f13a6a..3bedf440d 100644 --- a/docs/locales/uk/advanced/lookup-tables.md +++ b/docs/locales/uk/advanced/lookup-tables.md @@ -2,28 +2,45 @@ sidebarSortOrder: 4 title: Таблиці пошуку адрес description: - Дізнайтеся, як використовувати таблиці пошуку адрес Solana (ALTs) для ефективної обробки до 64 адрес у кожній транзакції. Створюйте, розширюйте та використовуйте таблиці пошуку за допомогою web3.js. + Дізнайтеся, як використовувати таблиці пошуку адрес Solana (ALTs) для + ефективної обробки до 64 адрес у кожній транзакції. Створюйте, розширюйте та + використовуйте таблиці пошуку за допомогою web3.js. --- -Таблиці пошуку адрес, зазвичай відомі як "_lookup tables_" або скорочено "_ALTs_", дозволяють розробникам створювати колекції пов’язаних адрес для ефективного завантаження більшої кількості адрес в одній транзакції. +Таблиці пошуку адрес, зазвичай відомі як "_lookup tables_" або скорочено +"_ALTs_", дозволяють розробникам створювати колекції пов’язаних адрес для +ефективного завантаження більшої кількості адрес в одній транзакції. -Оскільки кожна транзакція в блокчейні Solana вимагає переліку всіх адрес, з якими вона взаємодіє, цей перелік фактично обмежується 32 адресами на транзакцію. Завдяки [Таблицям пошуку адрес](/docs/uk/advanced/lookup-tables.md) це обмеження можна збільшити до 64 адрес у кожній транзакції. +Оскільки кожна транзакція в блокчейні Solana вимагає переліку всіх адрес, з +якими вона взаємодіє, цей перелік фактично обмежується 32 адресами на +транзакцію. Завдяки [Таблицям пошуку адрес](/docs/uk/advanced/lookup-tables.md) +це обмеження можна збільшити до 64 адрес у кожній транзакції. ## Стиснення адрес на блокчейні -Після того, як усі необхідні адреси були збережені на блокчейні у Таблиці пошуку адрес, кожну адресу можна посилатися в транзакції за її 1-байтовим індексом у таблиці (замість повної 32-байтової адреси). Цей метод пошуку ефективно "_стискає_" 32-байтову адресу до 1-байтового значення індексу. +Після того, як усі необхідні адреси були збережені на блокчейні у Таблиці пошуку +адрес, кожну адресу можна посилатися в транзакції за її 1-байтовим індексом у +таблиці (замість повної 32-байтової адреси). Цей метод пошуку ефективно +"_стискає_" 32-байтову адресу до 1-байтового значення індексу. -Таке "_стиснення_" дозволяє зберігати до 256 адрес у одній таблиці пошуку для використання у будь-якій транзакції. +Таке "_стиснення_" дозволяє зберігати до 256 адрес у одній таблиці пошуку для +використання у будь-якій транзакції. ## Версійні транзакції -Щоб використовувати Таблицю пошуку адрес у транзакції, розробники повинні застосовувати транзакції версії v0, які були запроваджені з новим форматом [Версійних транзакцій](/docs/uk/advanced/versions.md). +Щоб використовувати Таблицю пошуку адрес у транзакції, розробники повинні +застосовувати транзакції версії v0, які були запроваджені з новим форматом +[Версійних транзакцій](/docs/uk/advanced/versions.md). ## Як створити таблицю пошуку адрес -Створення нової таблиці пошуку за допомогою бібліотеки `@solana/web3.js` подібне до старішого формату `legacy` транзакцій, але має певні відмінності. +Створення нової таблиці пошуку за допомогою бібліотеки `@solana/web3.js` подібне +до старішого формату `legacy` транзакцій, але має певні відмінності. -Використовуючи бібліотеку `@solana/web3.js`, ви можете скористатися функцією [`createLookupTable`](https://solana-labs.github.io/solana-web3.js/v1.x/classes/AddressLookupTableProgram.html#createLookupTable) для створення інструкції, необхідної для створення нової таблиці пошуку, а також для визначення її адреси. +Використовуючи бібліотеку `@solana/web3.js`, ви можете скористатися функцією +[`createLookupTable`](https://solana-labs.github.io/solana-web3.js/v1.x/classes/AddressLookupTableProgram.html#createLookupTable) +для створення інструкції, необхідної для створення нової таблиці пошуку, а також +для визначення її адреси. ```js const web3 = require("@solana/web3.js"); @@ -48,11 +65,18 @@ console.log("lookup table address:", lookupTableAddress.toBase58()); // send the `lookupTableInst` instruction in a transaction ``` -> ПРИМІТКА: Таблиці пошуку адрес можуть бути **створені** за допомогою як транзакцій `v0`, так і `legacy`. Але виконуюче середовище Solana може отримувати та обробляти додаткові адреси в таблиці пошуку лише під час використання [Версійних транзакцій v0](/docs/uk/advanced/versions.md#current-transaction-versions). +> ПРИМІТКА: Таблиці пошуку адрес можуть бути **створені** за допомогою як +> транзакцій `v0`, так і `legacy`. Але виконуюче середовище Solana може +> отримувати та обробляти додаткові адреси в таблиці пошуку лише під час +> використання +> [Версійних транзакцій v0](/docs/uk/advanced/versions.md#current-transaction-versions). ## Додавання адрес до таблиці пошуку -Додавання адрес до таблиці пошуку відоме як "_розширення_" ("_extending_"). Використовуючи бібліотеку `@solana/web3.js`, ви можете створити нову інструкцію для _розширення_ за допомогою методу [`extendLookupTable`](https://solana-labs.github.io/solana-web3.js/v1.x/classes/AddressLookupTableProgram.html#extendLookupTable): +Додавання адрес до таблиці пошуку відоме як "_розширення_" ("_extending_"). +Використовуючи бібліотеку `@solana/web3.js`, ви можете створити нову інструкцію +для _розширення_ за допомогою методу +[`extendLookupTable`](https://solana-labs.github.io/solana-web3.js/v1.x/classes/AddressLookupTableProgram.html#extendLookupTable): ```js // add addresses to the `lookupTableAddress` table via an `extend` instruction @@ -71,13 +95,22 @@ const extendInstruction = web3.AddressLookupTableProgram.extendLookupTable({ // to insert the listing of `addresses` into your lookup table with address `lookupTableAddress` ``` -> ПРИМІТКА: Через ті самі обмеження пам'яті транзакцій `legacy`, будь-яка транзакція, яка використовується для _розширення_ таблиці пошуку адрес, також обмежена в кількості адрес, які можна додати одночасно. Через це вам потрібно буде використовувати кілька транзакцій, щоб _розширити_ будь-яку таблицю більшою кількістю адрес (приблизно 20), ніж це дозволяють обмеження пам'яті однієї транзакції. +> ПРИМІТКА: Через ті самі обмеження пам'яті транзакцій `legacy`, будь-яка +> транзакція, яка використовується для _розширення_ таблиці пошуку адрес, також +> обмежена в кількості адрес, які можна додати одночасно. Через це вам потрібно +> буде використовувати кілька транзакцій, щоб _розширити_ будь-яку таблицю +> більшою кількістю адрес (приблизно 20), ніж це дозволяють обмеження пам'яті +> однієї транзакції. -Після того як ці адреси були вставлені в таблицю та збережені в блокчейні, ви зможете використовувати таблицю пошуку адрес у майбутніх транзакціях. Це дозволяє включити до 64 адрес у цих транзакціях. +Після того як ці адреси були вставлені в таблицю та збережені в блокчейні, ви +зможете використовувати таблицю пошуку адрес у майбутніх транзакціях. Це +дозволяє включити до 64 адрес у цих транзакціях. ## Отримання таблиці пошуку адрес -Аналогічно запиту іншого облікового запису (або PDA) з кластера, ви можете отримати повну таблицю пошуку адрес за допомогою методу [`getAddressLookupTable`](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Connection.html#getAddressLookupTable): +Аналогічно запиту іншого облікового запису (або PDA) з кластера, ви можете +отримати повну таблицю пошуку адрес за допомогою методу +[`getAddressLookupTable`](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Connection.html#getAddressLookupTable): ```js // define the `PublicKey` of the lookup table to fetch @@ -93,7 +126,9 @@ const lookupTableAccount = ( console.log("Table address from cluster:", lookupTableAccount.key.toBase58()); ``` -Змінна `lookupTableAccount` тепер буде об'єктом типу `AddressLookupTableAccount`, який можна проаналізувати для читання списку всіх адрес, збережених у таблиці пошуку в блокчейні: +Змінна `lookupTableAccount` тепер буде об'єктом типу +`AddressLookupTableAccount`, який можна проаналізувати для читання списку всіх +адрес, збережених у таблиці пошуку в блокчейні: ```js // loop through and parse all the addresses stored in the table @@ -102,16 +137,23 @@ for (let i = 0; i < lookupTableAccount.state.addresses.length; i++) { console.log(i, address.toBase58()); } ``` + ## Як використовувати таблицю пошуку адрес у транзакції -Після того як ви створили таблицю пошуку і зберегли необхідні адреси в блокчейні (через розширення таблиці пошуку), ви можете створити транзакцію `v0`, щоб скористатися можливостями пошуку адрес в блокчейні. +Після того як ви створили таблицю пошуку і зберегли необхідні адреси в блокчейні +(через розширення таблиці пошуку), ви можете створити транзакцію `v0`, щоб +скористатися можливостями пошуку адрес в блокчейні. -Так само, як і для старих транзакцій `legacy`, ви можете створити всі -[інструкції](/docs/uk/terminology.md#instruction), які ваша транзакція виконуватиме в блокчейні. Потім ви можете передати масив цих інструкцій у -[Message](/docs/uk/terminology.md#message), що використовується в транзакції `v0`. +Так само, як і для старих транзакцій `legacy`, ви можете створити всі +[інструкції](/docs/uk/terminology.md#instruction), які ваша транзакція +виконуватиме в блокчейні. Потім ви можете передати масив цих інструкцій у +[Message](/docs/uk/terminology.md#message), що використовується в транзакції +`v0`. -> **Примітка:** Інструкції, що використовуються в транзакції `v0`, можна створювати за допомогою тих самих методів і функцій, які використовувалися раніше для створення інструкцій. -> Немає необхідності змінювати інструкції, пов'язані з використанням таблиці пошуку адрес. +> **Примітка:** Інструкції, що використовуються в транзакції `v0`, можна +> створювати за допомогою тих самих методів і функцій, які використовувалися +> раніше для створення інструкцій. Немає необхідності змінювати інструкції, +> пов'язані з використанням таблиці пошуку адрес. ```js // Assumptions: @@ -140,10 +182,13 @@ console.log( ); ``` -> **Примітка:** Під час відправлення `VersionedTransaction` до кластеру, вона має бути підписана **ДО** виклику методу `sendAndConfirmTransaction`. Якщо передати масив `Signer` (як у транзакціях `legacy`), метод викличе помилку! +> **Примітка:** Під час відправлення `VersionedTransaction` до кластеру, вона +> має бути підписана **ДО** виклику методу `sendAndConfirmTransaction`. Якщо +> передати масив `Signer` (як у транзакціях `legacy`), метод викличе помилку! ## Додаткові ресурси -- Ознайомтеся з [пропозицією](https://docs.anza.xyz/proposals/versioned-transactions) щодо таблиць пошуку адрес і версійованих транзакцій +- Ознайомтеся з + [пропозицією](https://docs.anza.xyz/proposals/versioned-transactions) щодо + таблиць пошуку адрес і версійованих транзакцій - [Приклад програми на Rust, яка використовує таблиці пошуку адрес](https://github.com/TeamRaccoons/address-lookup-table-multi-swap) - diff --git a/docs/locales/uk/advanced/retry.md b/docs/locales/uk/advanced/retry.md index 42d1ee4c8..9a5af666f 100644 --- a/docs/locales/uk/advanced/retry.md +++ b/docs/locales/uk/advanced/retry.md @@ -5,55 +5,90 @@ altRoutes: - /docs/core/transactions/retry description: Дізнайтеся, як обробляти втрачені транзакції та впроваджувати користувацьку - логіку повторної відправки у Solana. Цей посібник охоплює повторне - передавання транзакцій, перевірки перед виконанням (preflight) і найкращі - практики для забезпечення надійної обробки транзакцій у блокчейні Solana. + логіку повторної відправки у Solana. Цей посібник охоплює повторне передавання + транзакцій, перевірки перед виконанням (preflight) і найкращі практики для + забезпечення надійної обробки транзакцій у блокчейні Solana. --- # Повторна відправка транзакцій -Іноді здається, що дійсна транзакція може бути втрачена до її включення в блок. Це зазвичай трапляється під час завантаженості мережі, коли RPC-вузол не може повторно передати транзакцію до [лідера](/docs/uk/terminology.md#leader). Для кінцевого користувача це може виглядати так, ніби транзакція повністю зникає. Хоча RPC-вузли мають універсальний алгоритм повторного передавання, розробники додатків також можуть створювати власну логіку повторної передачі. +Іноді здається, що дійсна транзакція може бути втрачена до її включення в блок. +Це зазвичай трапляється під час завантаженості мережі, коли RPC-вузол не може +повторно передати транзакцію до [лідера](/docs/uk/terminology.md#leader). Для +кінцевого користувача це може виглядати так, ніби транзакція повністю зникає. +Хоча RPC-вузли мають універсальний алгоритм повторного передавання, розробники +додатків також можуть створювати власну логіку повторної передачі. ## Коротко: -- RPC-вузли намагатимуться повторно передати транзакції за допомогою універсального алгоритму. +- RPC-вузли намагатимуться повторно передати транзакції за допомогою + універсального алгоритму. - Розробники додатків можуть впроваджувати власну логіку повторного передавання. -- Розробникам слід використовувати параметр `maxRetries` у методі JSON-RPC `sendTransaction`. -- Розробникам слід вмикати перевірки перед виконанням (preflight), щоб виявляти помилки до відправки транзакцій. -- Перед повторним підписанням будь-якої транзакції важливо переконатися, що термін дії blockhash вихідної транзакції минув. +- Розробникам слід використовувати параметр `maxRetries` у методі JSON-RPC + `sendTransaction`. +- Розробникам слід вмикати перевірки перед виконанням (preflight), щоб виявляти + помилки до відправки транзакцій. +- Перед повторним підписанням будь-якої транзакції важливо переконатися, що + термін дії blockhash вихідної транзакції минув. ## Шлях транзакції ### Як клієнти відправляють транзакції -У Solana немає концепції мемпулу. Усі транзакції, незалежно від того, чи ініційовані вони програмно або користувачем, ефективно маршрутизуються до лідерів для обробки в блоках. Є два основні способи надсилання транзакцій до лідерів: +У Solana немає концепції мемпулу. Усі транзакції, незалежно від того, чи +ініційовані вони програмно або користувачем, ефективно маршрутизуються до +лідерів для обробки в блоках. Є два основні способи надсилання транзакцій до +лідерів: -1. Через RPC-сервер за допомогою методу JSON-RPC [sendTransaction](/docs/uk/rpc/http/sendTransaction.mdx). -2. Безпосередньо до лідерів через [TPU Client](https://docs.rs/solana-client/latest/solana_client/tpu_client/index.html). +1. Через RPC-сервер за допомогою методу JSON-RPC + [sendTransaction](/docs/uk/rpc/http/sendTransaction.mdx). +2. Безпосередньо до лідерів через + [TPU Client](https://docs.rs/solana-client/latest/solana_client/tpu_client/index.html). -Більшість користувачів відправляють транзакції через RPC-сервер. Коли клієнт надсилає транзакцію, RPC-вузол намагається передати її поточному та наступному лідерам. Поки транзакція не буде оброблена лідером, вона існує лише у вигляді запису в клієнта або проміжних RPC-вузлів. У випадку використання TPU клієнтом, передавання та маршрутизація обробляються програмним забезпеченням клієнта. +Більшість користувачів відправляють транзакції через RPC-сервер. Коли клієнт +надсилає транзакцію, RPC-вузол намагається передати її поточному та наступному +лідерам. Поки транзакція не буде оброблена лідером, вона існує лише у вигляді +запису в клієнта або проміжних RPC-вузлів. У випадку використання TPU клієнтом, +передавання та маршрутизація обробляються програмним забезпеченням клієнта. ![Огляд шляху транзакції, від клієнта до лідера](/assets/docs/rt-tx-journey.png) ### Як RPC-вузли передають транзакції -Після отримання транзакції через `sendTransaction`, RPC-вузол перетворює транзакцію в [UDP](https://uk.wikipedia.org/wiki/UDP) пакет і передає його відповідним лідерам. UDP дозволяє вузлам швидко обмінюватися даними, але не гарантує доставки пакетів. +Після отримання транзакції через `sendTransaction`, RPC-вузол перетворює +транзакцію в [UDP](https://uk.wikipedia.org/wiki/UDP) пакет і передає його +відповідним лідерам. UDP дозволяє вузлам швидко обмінюватися даними, але не +гарантує доставки пакетів. -Оскільки розклад лідерів Solana відомий заздалегідь для кожного [епоха](/docs/uk/terminology.md#epoch) (~2 дні), RPC-вузол передає транзакції безпосередньо до поточного та наступного лідерів. За замовчуванням RPC-вузли намагаються повторно передавати транзакції кожні дві секунди, доки транзакція не буде завершена або доки термін дії її blockhash не закінчиться (~1 хвилина 19 секунд). Якщо черга для повторної передачі перевищує [10,000 транзакцій](https://github.com/solana-labs/solana/blob/bfbbc53dac93b3a5c6be9b4b65f679fdb13e41d9/send-transaction-service/src/send_transaction_service.rs#L20), нові транзакції скидаються. +Оскільки розклад лідерів Solana відомий заздалегідь для кожного +[епоха](/docs/uk/terminology.md#epoch) (~2 дні), RPC-вузол передає транзакції +безпосередньо до поточного та наступного лідерів. За замовчуванням RPC-вузли +намагаються повторно передавати транзакції кожні дві секунди, доки транзакція не +буде завершена або доки термін дії її blockhash не закінчиться (~1 хвилина 19 +секунд). Якщо черга для повторної передачі перевищує +[10,000 транзакцій](https://github.com/solana-labs/solana/blob/bfbbc53dac93b3a5c6be9b4b65f679fdb13e41d9/send-transaction-service/src/send_transaction_service.rs#L20), +нові транзакції скидаються. ![Процес обробки транзакцій TPU](/assets/docs/rt-tpu-jito-labs.png) ## Як транзакції скидаються -Транзакції можуть бути скинуті через кілька причин, таких як перевантаження мережі, втрати пакетів UDP або конфлікти через різні статуси вузлів у пулі RPC. +Транзакції можуть бути скинуті через кілька причин, таких як перевантаження +мережі, втрати пакетів UDP або конфлікти через різні статуси вузлів у пулі RPC. ## Обробка скинутих транзакцій -Розробники можуть використовувати параметр `maxRetries` методу `sendTransaction` для створення власної логіки повторного передавання, зокрема перевірки `lastValidBlockHeight` і опитування стану мережі. +Розробники можуть використовувати параметр `maxRetries` методу `sendTransaction` +для створення власної логіки повторного передавання, зокрема перевірки +`lastValidBlockHeight` і опитування стану мережі. ## Налаштування власної логіки -Впровадження алгоритмів, таких як [експоненціальне збільшення інтервалів](https://uk.wikipedia.org/wiki/Експоненційне_зростання), або постійне повторне передавання, як у [Mango](https://github.com/blockworks-foundation/mango-ui/blob/b6abfc6c13b71fc17ebbe766f50b8215fa1ec54f/src/utils/send.tsx#L713), може допомогти впоратися із завантаженістю мережі. +Впровадження алгоритмів, таких як +[експоненціальне збільшення інтервалів](https://uk.wikipedia.org/wiki/Експоненційне_зростання), +або постійне повторне передавання, як у +[Mango](https://github.com/blockworks-foundation/mango-ui/blob/b6abfc6c13b71fc17ebbe766f50b8215fa1ec54f/src/utils/send.tsx#L713), +може допомогти впоратися із завантаженістю мережі. ```ts import { @@ -112,26 +147,48 @@ const sleep = async (ms: number) => { })(); ``` -При опитуванні через `getLatestBlockhash` додатки повинні вказувати бажаний рівень [зобов'язань (commitment)](/docs/uk/rpc/index.mdx#configuring-state-commitment). Встановлюючи зобов'язання на рівень `confirmed` (підтверджений) або `finalized` (~30 блоків після `confirmed`), додаток може уникнути опитування blockhash із меншості вузлів. - -Якщо додаток має доступ до RPC-вузлів за балансувальником навантаження, він також може розподіляти своє навантаження між конкретними вузлами. RPC-вузли, які обслуговують ресурсоємні запити, такі як -[getProgramAccounts](/content/guides/javascript/get-program-accounts.md), можуть відставати і бути менш ефективними для пересилання транзакцій. Для додатків, що обробляють транзакції в реальному часі, може бути розумним використовувати спеціалізовані вузли, які обслуговують лише `sendTransaction`. +При опитуванні через `getLatestBlockhash` додатки повинні вказувати бажаний +рівень +[зобов'язань (commitment)](/docs/uk/rpc/index.mdx#configuring-state-commitment). +Встановлюючи зобов'язання на рівень `confirmed` (підтверджений) або `finalized` +(~30 блоків після `confirmed`), додаток може уникнути опитування blockhash із +меншості вузлів. + +Якщо додаток має доступ до RPC-вузлів за балансувальником навантаження, він +також може розподіляти своє навантаження між конкретними вузлами. RPC-вузли, які +обслуговують ресурсоємні запити, такі як +[getProgramAccounts](/content/guides/javascript/get-program-accounts.md), можуть +відставати і бути менш ефективними для пересилання транзакцій. Для додатків, що +обробляють транзакції в реальному часі, може бути розумним використовувати +спеціалізовані вузли, які обслуговують лише `sendTransaction`. ### Вартість пропуску перевірки перед виконанням -За замовчуванням `sendTransaction` виконує три перевірки перед відправкою транзакції. Зокрема, `sendTransaction`: +За замовчуванням `sendTransaction` виконує три перевірки перед відправкою +транзакції. Зокрема, `sendTransaction`: - Перевіряє, що всі підписи є дійсними. - Перевіряє, що вказаний blockhash знаходиться в межах останніх 150 блоків. - Симулює транзакцію на основі слоту банку, зазначеного у `preflightCommitment`. -У разі, якщо одна з цих перевірок не пройде, `sendTransaction` видасть помилку до відправки транзакції. Перевірки перед виконанням можуть стати вирішальним фактором між втратою транзакції та можливістю клієнта обробити помилку. Щоб гарантувати врахування цих поширених помилок, рекомендується залишати `skipPreflight` встановленим у значення `false`. +У разі, якщо одна з цих перевірок не пройде, `sendTransaction` видасть помилку +до відправки транзакції. Перевірки перед виконанням можуть стати вирішальним +фактором між втратою транзакції та можливістю клієнта обробити помилку. Щоб +гарантувати врахування цих поширених помилок, рекомендується залишати +`skipPreflight` встановленим у значення `false`. ### Коли потрібно повторно підписувати транзакції -Попри всі спроби повторного передавання, іноді клієнт може бути змушений повторно підписати транзакцію. Перед повторним підписанням будь-якої транзакції **дуже важливо** переконатися, що термін дії blockhash вихідної транзакції закінчився. Якщо початковий blockhash все ще дійсний, обидві транзакції можуть бути прийняті мережею. Для кінцевого користувача це виглядатиме як ненавмисне повторне відправлення однієї і тієї ж транзакції. - -У Solana втрачену транзакцію можна безпечно відхилити, якщо blockhash, на який вона посилається, старший за `lastValidBlockHeight`, отриманий із -`getLatestBlockhash`. Розробникам слід відстежувати цей `lastValidBlockHeight`, опитуючи -[`getEpochInfo`](/docs/uk/rpc/http/getEpochInfo.mdx) і порівнюючи з `blockHeight` у відповіді. Після того, як blockhash стане недійсним, клієнти можуть повторно підписати транзакцію з новозапитаним blockhash. - +Попри всі спроби повторного передавання, іноді клієнт може бути змушений +повторно підписати транзакцію. Перед повторним підписанням будь-якої транзакції +**дуже важливо** переконатися, що термін дії blockhash вихідної транзакції +закінчився. Якщо початковий blockhash все ще дійсний, обидві транзакції можуть +бути прийняті мережею. Для кінцевого користувача це виглядатиме як ненавмисне +повторне відправлення однієї і тієї ж транзакції. + +У Solana втрачену транзакцію можна безпечно відхилити, якщо blockhash, на який +вона посилається, старший за `lastValidBlockHeight`, отриманий із +`getLatestBlockhash`. Розробникам слід відстежувати цей `lastValidBlockHeight`, +опитуючи [`getEpochInfo`](/docs/uk/rpc/http/getEpochInfo.mdx) і порівнюючи з +`blockHeight` у відповіді. Після того, як blockhash стане недійсним, клієнти +можуть повторно підписати транзакцію з новозапитаним blockhash. diff --git a/docs/locales/uk/advanced/state-compression.md b/docs/locales/uk/advanced/state-compression.md index c094491db..b2df0fdc9 100644 --- a/docs/locales/uk/advanced/state-compression.md +++ b/docs/locales/uk/advanced/state-compression.md @@ -2,20 +2,31 @@ sidebarSortOrder: 4 title: Стиснення стану (State Compression) description: - 'Стиснення стану - це метод дешевого та безпечного збереження - "відбитків" даних поза мережею в реєстрі Solana замість дорогих облікових записів.' + 'Стиснення стану - це метод дешевого та безпечного збереження "відбитків" + даних поза мережею в реєстрі Solana замість дорогих облікових записів.' --- -У Solana [стиснення стану](/docs/uk/advanced/state-compression.md) є методом створення "відбитку" (або гешу) даних поза мережею та збереження цього відбитку в мережі для безпечної перевірки. Цей процес використовує безпеку реєстру Solana для гарантування цілісності даних поза мережею, забезпечуючи їх незмінність. +У Solana [стиснення стану](/docs/uk/advanced/state-compression.md) є методом +створення "відбитку" (або гешу) даних поза мережею та збереження цього відбитку +в мережі для безпечної перевірки. Цей процес використовує безпеку реєстру Solana +для гарантування цілісності даних поза мережею, забезпечуючи їх незмінність. -Цей метод "стиснення" дозволяє програмам та децентралізованим додаткам (dApps) використовувати дешевий простір у [реєстрі](/docs/uk/terminology.md#ledger) блокчейну, замість більш дорогого простору [облікових записів](/docs/uk/terminology.md#account), для безпечного зберігання даних. +Цей метод "стиснення" дозволяє програмам та децентралізованим додаткам (dApps) +використовувати дешевий простір у [реєстрі](/docs/uk/terminology.md#ledger) +блокчейну, замість більш дорогого простору +[облікових записів](/docs/uk/terminology.md#account), для безпечного зберігання +даних. -Це досягається за допомогою спеціальної структури двійкового дерева, відомого як -[конкурентне мерклеве дерево](#what-is-a-concurrent-merkle-tree), яке створює геш кожного фрагмента даних (названого `листком`), об'єднує ці геші і зберігає тільки фінальний геш у мережі. +Це досягається за допомогою спеціальної структури двійкового дерева, відомого як +[конкурентне мерклеве дерево](#what-is-a-concurrent-merkle-tree), яке створює +геш кожного фрагмента даних (названого `листком`), об'єднує ці геші і зберігає +тільки фінальний геш у мережі. ## Що таке стиснення стану? -Простіше кажучи, стиснення стану використовує структури "**_дерев_**" для криптографічного хешування даних поза мережею детермінованим способом, щоб обчислити один кінцевий геш, який зберігається у мережі. +Простіше кажучи, стиснення стану використовує структури "**_дерев_**" для +криптографічного хешування даних поза мережею детермінованим способом, щоб +обчислити один кінцевий геш, який зберігається у мережі. Ці _дерева_ створюються таким "_детермінованим_" процесом: @@ -26,35 +37,63 @@ description: - Кожна `гілка` також хешується разом. - Процес повторюється, поки не буде обчислено фінальний `кореневий геш`. -Цей `кореневий геш` зберігається в мережі як верифіковане **_підтвердження_** для всіх даних у кожному листку. Це дозволяє криптографічно перевіряти всі дані поза мережею, використовуючи мінімальну кількість даних у мережі. Таким чином, значно знижуються витрати на зберігання/перевірку великих обсягів даних завдяки "стисненню стану". +Цей `кореневий геш` зберігається в мережі як верифіковане **_підтвердження_** +для всіх даних у кожному листку. Це дозволяє криптографічно перевіряти всі дані +поза мережею, використовуючи мінімальну кількість даних у мережі. Таким чином, +значно знижуються витрати на зберігання/перевірку великих обсягів даних завдяки +"стисненню стану". ## Мерклеві дерева та конкурентні мерклеві дерева -Стиснення стану у Solana використовує спеціальний тип -[мерклевого дерева](#what-is-a-merkle-tree), який дозволяє виконувати кілька змін у дереві, зберігаючи його цілісність і валідність. +Стиснення стану у Solana використовує спеціальний тип +[мерклевого дерева](#what-is-a-merkle-tree), який дозволяє виконувати кілька +змін у дереві, зберігаючи його цілісність і валідність. -Це спеціальне дерево, відоме як -"[конкурентне мерклеве дерево](#what-is-a-concurrent-merkle-tree)", зберігає "журнал змін" дерева в мережі. Це дозволяє виконувати кілька змін до дерева (наприклад, у межах одного блоку), не порушуючи підтвердження. +Це спеціальне дерево, відоме як +"[конкурентне мерклеве дерево](#what-is-a-concurrent-merkle-tree)", зберігає +"журнал змін" дерева в мережі. Це дозволяє виконувати кілька змін до дерева +(наприклад, у межах одного блоку), не порушуючи підтвердження. ### Що таке мерклеве дерево? -[Мерклеве дерево](https://uk.wikipedia.org/wiki/Мерклеве_дерево), або "дерево гешів", — це двійкова структура, у якій кожен `листок` є криптографічним гешем даних. Всі вузли, які **не** є листками, називаються `гілками` і є гешами їхніх дочірніх листків. +[Мерклеве дерево](https://uk.wikipedia.org/wiki/Мерклеве_дерево), або "дерево +гешів", — це двійкова структура, у якій кожен `листок` є криптографічним гешем +даних. Всі вузли, які **не** є листками, називаються `гілками` і є гешами їхніх +дочірніх листків. -Кожна гілка також хешується разом, поступово піднімаючись вгору, поки не залишиться один геш. Цей фінальний геш, званий `кореневим гешем`, можна використовувати разом із "шляхом підтвердження" для перевірки будь-яких даних, збережених у листковому вузлі. +Кожна гілка також хешується разом, поступово піднімаючись вгору, поки не +залишиться один геш. Цей фінальний геш, званий `кореневим гешем`, можна +використовувати разом із "шляхом підтвердження" для перевірки будь-яких даних, +збережених у листковому вузлі. ### Що таке Конкурентне Мерклеве дерево? -У високопродуктивних застосунках, таких як [середовище виконання Solana](/docs/uk/core/fees.md), запити на зміну ончейн _традиційного мерклевого дерева_ можуть надходити до валідаторів досить швидко (наприклад, у межах одного слота). У таких випадках кожна зміна даних у листках повинна виконуватися послідовно. Це призводить до невдачі наступних запитів на зміну, оскільки кореневий геш і підтвердження стають недійсними після попередньої зміни в слоті. +У високопродуктивних застосунках, таких як +[середовище виконання Solana](/docs/uk/core/fees.md), запити на зміну ончейн +_традиційного мерклевого дерева_ можуть надходити до валідаторів досить швидко +(наприклад, у межах одного слота). У таких випадках кожна зміна даних у листках +повинна виконуватися послідовно. Це призводить до невдачі наступних запитів на +зміну, оскільки кореневий геш і підтвердження стають недійсними після +попередньої зміни в слоті. Рішенням цієї проблеми є Конкурентні Мерклеві дерева. -**Конкурентне Мерклеве дерево** зберігає **захищений журнал змін**, який містить останні зміни, їх кореневий геш і підтвердження для його обчислення. Цей буфер змін ("changelog buffer") зберігається ончейн у спеціальному акаунті для кожного дерева, з обмеженням на максимальну кількість записів у журналі змін (`maxBufferSize`). +**Конкурентне Мерклеве дерево** зберігає **захищений журнал змін**, який містить +останні зміни, їх кореневий геш і підтвердження для його обчислення. Цей буфер +змін ("changelog buffer") зберігається ончейн у спеціальному акаунті для кожного +дерева, з обмеженням на максимальну кількість записів у журналі змін +(`maxBufferSize`). -Коли валідатори отримують кілька запитів на зміну даних у листках у межах одного слота, ончейн _конкурентне мерклеве дерево_ може використовувати цей буфер змін як джерело правдивої інформації для більш прийнятних підтверджень. Це дозволяє виконувати до `maxBufferSize` змін для одного дерева в межах одного слота, що значно підвищує пропускну здатність. +Коли валідатори отримують кілька запитів на зміну даних у листках у межах одного +слота, ончейн _конкурентне мерклеве дерево_ може використовувати цей буфер змін +як джерело правдивої інформації для більш прийнятних підтверджень. Це дозволяє +виконувати до `maxBufferSize` змін для одного дерева в межах одного слота, що +значно підвищує пропускну здатність. ## Розмір Конкурентного Мерклевого дерева -При створенні такого ончейн дерева існує 3 параметри, які визначають розмір дерева, вартість його створення і кількість одночасних змін: +При створенні такого ончейн дерева існує 3 параметри, які визначають розмір +дерева, вартість його створення і кількість одночасних змін: 1. Максимальна глибина (max depth) 2. Розмір буфера змін (max buffer size) @@ -62,20 +101,29 @@ description: ### Максимальна глибина -"Максимальна глибина" дерева — це **максимальна кількість** переходів від будь-якого `листка` даних до `кореня` дерева. +"Максимальна глибина" дерева — це **максимальна кількість** переходів від +будь-якого `листка` даних до `кореня` дерева. -Оскільки мерклеві дерева є двійковими, кожен листок з'єднаний лише з **одним** іншим листком; вони утворюють `пару листків`. +Оскільки мерклеві дерева є двійковими, кожен листок з'єднаний лише з **одним** +іншим листком; вони утворюють `пару листків`. -Таким чином, `maxDepth` дерева використовується для визначення максимальної кількості вузлів (тобто елементів даних або `листків`), які можна зберігати у дереві, за допомогою простої формули: +Таким чином, `maxDepth` дерева використовується для визначення максимальної +кількості вузлів (тобто елементів даних або `листків`), які можна зберігати у +дереві, за допомогою простої формули: ```text nodes_count = 2 ^ maxDepth ``` -Оскільки глибину дерева потрібно встановити під час його створення, ви повинні визначити, скільки елементів даних ви хочете зберігати у своєму дереві. Потім, використовуючи просту формулу вище, ви можете визначити найменше значення `maxDepth`, яке дозволить зберігати ваші дані. + +Оскільки глибину дерева потрібно встановити під час його створення, ви повинні +визначити, скільки елементів даних ви хочете зберігати у своєму дереві. Потім, +використовуючи просту формулу вище, ви можете визначити найменше значення +`maxDepth`, яке дозволить зберігати ваші дані. #### Приклад 1: Мінтинг 100 NFT -Якщо ви хочете створити дерево для зберігання 100 стиснутих NFT, вам знадобиться щонайменше "100 листків" або "100 вузлів". +Якщо ви хочете створити дерево для зберігання 100 стиснутих NFT, вам знадобиться +щонайменше "100 листків" або "100 вузлів". ```text // maxDepth=6 -> 64 nodes @@ -84,11 +132,14 @@ nodes_count = 2 ^ maxDepth // maxDepth=7 -> 128 nodes 2^7 = 128 ``` -Ми повинні використовувати значення `maxDepth` рівне `7`, щоб забезпечити можливість зберігати всі наші дані. + +Ми повинні використовувати значення `maxDepth` рівне `7`, щоб забезпечити +можливість зберігати всі наші дані. #### Приклад 2: Мінтинг 15000 NFT -Якщо ви хочете створити дерево для зберігання 15000 стиснутих NFT, вам знадобиться щонайменше "15000 листків" або "15000 вузлів". +Якщо ви хочете створити дерево для зберігання 15000 стиснутих NFT, вам +знадобиться щонайменше "15000 листків" або "15000 вузлів". ```text // maxDepth=13 -> 8192 nodes @@ -97,33 +148,51 @@ nodes_count = 2 ^ maxDepth // maxDepth=14 -> 16384 nodes 2^14 = 16384 ``` -Ми повинні використовувати `maxDepth` рівне `14`, щоб забезпечити можливість зберігати всі наші дані. + +Ми повинні використовувати `maxDepth` рівне `14`, щоб забезпечити можливість +зберігати всі наші дані. #### Чим більша максимальна глибина, тим вища вартість -Значення `maxDepth` є одним із основних чинників вартості під час створення дерева, оскільки ви оплачуєте цю вартість наперед при створенні дерева. Чим більша глибина дерева, тим більше даних (відбитків або хешів) можна зберігати, але тим вища вартість. +Значення `maxDepth` є одним із основних чинників вартості під час створення +дерева, оскільки ви оплачуєте цю вартість наперед при створенні дерева. Чим +більша глибина дерева, тим більше даних (відбитків або хешів) можна зберігати, +але тим вища вартість. --- ### Максимальний розмір буфера (maxBufferSize) -"Максимальний розмір буфера" — це максимальна кількість змін, які можуть бути внесені до дерева, доки кореневий хеш (`root hash`) залишається дійсним. +"Максимальний розмір буфера" — це максимальна кількість змін, які можуть бути +внесені до дерева, доки кореневий хеш (`root hash`) залишається дійсним. -Оскільки кореневий хеш є єдиним хешем для всіх даних листків, зміна будь-якого окремого листка інвалідовує proof, потрібний для всіх наступних спроб змінити будь-який інший листок у звичайному дереві. +Оскільки кореневий хеш є єдиним хешем для всіх даних листків, зміна будь-якого +окремого листка інвалідовує proof, потрібний для всіх наступних спроб змінити +будь-який інший листок у звичайному дереві. -У випадку [Concurrent Tree](#що-таке-concurrent-merkle-tree), існує журнал змін для цих proof, який задається під час створення дерева через параметр `maxBufferSize`. +У випадку [Concurrent Tree](#що-таке-concurrent-merkle-tree), існує журнал змін +для цих proof, який задається під час створення дерева через параметр +`maxBufferSize`. --- ### Глибина козирка (canopyDepth) -"Глибина козирка" або "розмір козирка" визначає кількість рівнів proof, які кешуються або зберігаються on-chain для даного proof-шляху. +"Глибина козирка" або "розмір козирка" визначає кількість рівнів proof, які +кешуються або зберігаються on-chain для даного proof-шляху. -Коли виконується дія оновлення для `leaf` (наприклад, передача права власності), **повний** proof-шлях повинен бути використаний для верифікації початкового права власності на листок. Це здійснюється шляхом обчислення поточного `root hash`. +Коли виконується дія оновлення для `leaf` (наприклад, передача права власності), +**повний** proof-шлях повинен бути використаний для верифікації початкового +права власності на листок. Це здійснюється шляхом обчислення поточного +`root hash`. -Для великих дерев потрібно більше proof-вузлів, щоб виконати цю перевірку. Наприклад, якщо `maxDepth` дорівнює `14`, потрібно `14` proof-вузлів. З використанням козирка частина цих вузлів зберігається on-chain, зменшуючи кількість proof-вузлів, які потрібно включити в транзакції. +Для великих дерев потрібно більше proof-вузлів, щоб виконати цю перевірку. +Наприклад, якщо `maxDepth` дорівнює `14`, потрібно `14` proof-вузлів. З +використанням козирка частина цих вузлів зберігається on-chain, зменшуючи +кількість proof-вузлів, які потрібно включити в транзакції. -Наприклад, дерево з `maxDepth` рівне `14` із козирком розміром `10` потребуватиме лише `4` proof-вузли на транзакцію. +Наприклад, дерево з `maxDepth` рівне `14` із козирком розміром `10` +потребуватиме лише `4` proof-вузли на транзакцію. ![Глибина козирка 1 для Concurrent Merkle Tree з максимальною глибиною 3](/assets/docs/compression/canopy-depth-1.png) @@ -131,19 +200,26 @@ nodes_count = 2 ^ maxDepth #### Чим більша глибина козирка, тим вища вартість -Значення `canopyDepth` також є одним із основних чинників вартості створення дерева. Чим більше proof-вузлів зберігається on-chain, тим вища вартість. +Значення `canopyDepth` також є одним із основних чинників вартості створення +дерева. Чим більше proof-вузлів зберігається on-chain, тим вища вартість. #### Низький козирок обмежує композитність -Низьке значення `canopyDepth` вимагає більше proof-вузлів у кожній транзакції оновлення. Це обмежує можливості для інтеграції вашого дерева з іншими Solana-програмами або dApps. +Низьке значення `canopyDepth` вимагає більше proof-вузлів у кожній транзакції +оновлення. Це обмежує можливості для інтеграції вашого дерева з іншими +Solana-програмами або dApps. -Наприклад, дерево, яке використовується для стиснутих NFT з низьким `canopyDepth`, може дозволяти лише базові дії, як-от передача, але не підтримувати розширені функції, такі як система ставок. +Наприклад, дерево, яке використовується для стиснутих NFT з низьким +`canopyDepth`, може дозволяти лише базові дії, як-от передача, але не +підтримувати розширені функції, такі як система ставок. --- ## Вартість створення дерева -Вартість створення Concurrent Merkle Tree залежить від його параметрів: `maxDepth`, `maxBufferSize`, і `canopyDepth`. Ці параметри визначають необхідний простір (у байтах) для дерева. +Вартість створення Concurrent Merkle Tree залежить від його параметрів: +`maxDepth`, `maxBufferSize`, і `canopyDepth`. Ці параметри визначають необхідний +простір (у байтах) для дерева. Використовуючи метод [`getMinimumBalanceForRentExemption`](/docs/uk/rpc/http/getminimumbalanceforrentexemption), @@ -161,7 +237,8 @@ nodes_count = 2 ^ maxDepth Далі, за допомогою функції [`getMinimumBalanceForRentExemption`](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Connection.html#getMinimumBalanceForRentExemption), -можна визначити остаточну вартість (у лампортах) для створення дерева, подібно до будь-якого іншого акаунта. +можна визначити остаточну вартість (у лампортах) для створення дерева, подібно +до будь-якого іншого акаунта. ```ts // calculate the space required for the tree @@ -178,7 +255,8 @@ const storageCost = ### Приклади вартості -Нижче наведено кілька прикладів вартості для дерев різного розміру, включаючи кількість можливих листків: +Нижче наведено кілька прикладів вартості для дерев різного розміру, включаючи +кількість можливих листків: **Приклад №1: 16,384 вузлів, вартість 0.222 SOL** @@ -208,7 +286,11 @@ const storageCost = ## Стиснуті NFT -Стиснуті NFT є одним із найпопулярніших варіантів використання стиснення стану на Solana. Завдяки стисненню колекцію з одного мільйона NFT можна створити за `~50 SOL`, у порівнянні з `~12,000 SOL` для її нестиснутої еквівалентної колекції. +Стиснуті NFT є одним із найпопулярніших варіантів використання стиснення стану +на Solana. Завдяки стисненню колекцію з одного мільйона NFT можна створити за +`~50 SOL`, у порівнянні з `~12,000 SOL` для її нестиснутої еквівалентної +колекції. -Якщо ви зацікавлені в створенні стиснутих NFT, ознайомтеся з нашим посібником для розробників: +Якщо ви зацікавлені в створенні стиснутих NFT, ознайомтеся з нашим посібником +для розробників: [створення та передача стиснутих NFT](/content/guides/javascript/compressed-nfts.md). diff --git a/docs/locales/uk/advanced/versions.md b/docs/locales/uk/advanced/versions.md index b3f5c5aaf..998915a05 100644 --- a/docs/locales/uk/advanced/versions.md +++ b/docs/locales/uk/advanced/versions.md @@ -2,15 +2,19 @@ sidebarSortOrder: 3 title: "Версійні Транзакції" description: - "Дослідіть основні концепції Solana: транзакції, версійні транзакції, розширення функціональності в Solana Runtime, таблиці пошуку адрес та інше." + "Дослідіть основні концепції Solana: транзакції, версійні транзакції, + розширення функціональності в Solana Runtime, таблиці пошуку адрес та інше." altRoutes: - /docs/uk/core/transactions/versions --- -Версійні Транзакції - це новий формат транзакцій, який дозволяє додаткову функціональність у Solana Runtime, включаючи +Версійні Транзакції - це новий формат транзакцій, який дозволяє додаткову +функціональність у Solana Runtime, включаючи [Таблиці пошуку адрес](/docs/uk/advanced/lookup-tables.md). -Хоча зміни в ончейн-програмах **НЕ** потрібні для підтримки нової функціональності версійних транзакцій (або для зворотної сумісності), розробники **ПОВИННІ** оновити клієнтський код, щоб уникнути +Хоча зміни в ончейн-програмах **НЕ** потрібні для підтримки нової +функціональності версійних транзакцій (або для зворотної сумісності), розробники +**ПОВИННІ** оновити клієнтський код, щоб уникнути [помилок через різні версії транзакцій](#max-supported-transaction-version). ## Поточні версії транзакцій @@ -23,26 +27,32 @@ Solana Runtime підтримує дві версії транзакцій: ## Максимально підтримувана версія транзакцій -Усі RPC-запити, які повертають транзакцію, **_повинні_** вказувати найвищу версію транзакцій, яку вони підтримують у своїй програмі, використовуючи параметр -`maxSupportedTransactionVersion`, включаючи +Усі RPC-запити, які повертають транзакцію, **_повинні_** вказувати найвищу +версію транзакцій, яку вони підтримують у своїй програмі, використовуючи +параметр `maxSupportedTransactionVersion`, включаючи [`getBlock`](/docs/uk/rpc/http/getBlock.mdx) та [`getTransaction`](/docs/uk/rpc/http/getTransaction.mdx). -RPC-запит завершиться невдачею, якщо буде повернута версійна транзакція, яка має версію вище встановленої `maxSupportedTransactionVersion`. (наприклад, якщо повертається транзакція версії `0`, а встановлено `legacy`) +RPC-запит завершиться невдачею, якщо буде повернута версійна транзакція, яка має +версію вище встановленої `maxSupportedTransactionVersion`. (наприклад, якщо +повертається транзакція версії `0`, а встановлено `legacy`) -> УВАГА: Якщо значення `maxSupportedTransactionVersion` не встановлено, тоді лише транзакції `legacy` будуть дозволені у відповіді RPC. Таким чином, ваші RPC-запити **ПРИЗВЕДУТЬ ДО ПОМИЛКИ**, якщо буде повернута будь-яка транзакція версії `0`. +> УВАГА: Якщо значення `maxSupportedTransactionVersion` не встановлено, тоді +> лише транзакції `legacy` будуть дозволені у відповіді RPC. Таким чином, ваші +> RPC-запити **ПРИЗВЕДУТЬ ДО ПОМИЛКИ**, якщо буде повернута будь-яка транзакція +> версії `0`. ## Як встановити максимально підтримувану версію Ви можете встановити `maxSupportedTransactionVersion`, використовуючи бібліотеку -[`@solana/web3.js`](https://solana-labs.github.io/solana-web3.js/v1.x/) -або шляхом прямого надсилання JSON-запитів до RPC-ендпоінту. +[`@solana/web3.js`](https://solana-labs.github.io/solana-web3.js/v1.x/) або +шляхом прямого надсилання JSON-запитів до RPC-ендпоінту. ### Використання web3.js Використовуючи бібліотеку -[`@solana/web3.js`](https://solana-labs.github.io/solana-web3.js/v1.x/), -ви можете отримати останній блок або конкретну транзакцію: +[`@solana/web3.js`](https://solana-labs.github.io/solana-web3.js/v1.x/), ви +можете отримати останній блок або конкретну транзакцію: ```js // підключення до кластера `devnet` та отримання поточного `slot` @@ -80,7 +90,8 @@ curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" - ## Як створити версійну транзакцію -Версійні транзакції можна створити подібно до старого методу створення транзакцій. Є відмінності у використанні певних бібліотек, які слід враховувати. +Версійні транзакції можна створити подібно до старого методу створення +транзакцій. Є відмінності у використанні певних бібліотек, які слід враховувати. Нижче наведено приклад створення версійної транзакції з використанням бібліотеки `@solana/web3.js` для передачі SOL між двома рахунками. @@ -90,9 +101,11 @@ curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" - - `payer` - це дійсний гаманець `Keypair`, наповнений SOL - `toAccount` - дійсний `Keypair` -Спочатку імпортуйте бібліотеку web3.js та створіть `connection` до бажаного кластера. +Спочатку імпортуйте бібліотеку web3.js та створіть `connection` до бажаного +кластера. -Далі визначте останній `blockhash` і `minRent`, які будуть потрібні для вашої транзакції та рахунку: +Далі визначте останній `blockhash` і `minRent`, які будуть потрібні для вашої +транзакції та рахунку: ```js const web3 = require("@solana/web3.js"); @@ -105,7 +118,8 @@ let blockhash = await connection .then(res => res.blockhash); ``` -Створіть `array` усіх `instructions`, які ви хочете відправити у вашій транзакції. У прикладі нижче ми створюємо просту інструкцію передачі SOL: +Створіть `array` усіх `instructions`, які ви хочете відправити у вашій +транзакції. У прикладі нижче ми створюємо просту інструкцію передачі SOL: ```js // створення масиву з вашими інструкціями @@ -138,7 +152,8 @@ const transaction = new web3.VersionedTransaction(messageV0); transaction.sign([payer]); ``` -Після того, як ваша `VersionedTransaction` підписана всіма необхідними рахунками, ви можете відправити її до кластера та отримати відповідь: +Після того, як ваша `VersionedTransaction` підписана всіма необхідними +рахунками, ви можете відправити її до кластера та отримати відповідь: ```js // відправка нашої транзакції v0 до кластера @@ -146,8 +161,10 @@ const txId = await connection.sendTransaction(transaction); console.log(`https://explorer.solana.com/tx/${txId}?cluster=devnet`); ``` -> УВАГА: На відміну від `legacy` транзакцій, відправка `VersionedTransaction` через -> `sendTransaction` **НЕ** підтримує підпис транзакцій через передачу масиву `Signers` як другого параметра. Ви повинні підписати транзакцію перед викликом `connection.sendTransaction()`. +> УВАГА: На відміну від `legacy` транзакцій, відправка `VersionedTransaction` +> через `sendTransaction` **НЕ** підтримує підпис транзакцій через передачу +> масиву `Signers` як другого параметра. Ви повинні підписати транзакцію перед +> викликом `connection.sendTransaction()`. ## Додаткові ресурси @@ -159,4 +176,3 @@ console.log(`https://explorer.solana.com/tx/${txId}?cluster=devnet`); - Читання [ухваленої пропозиції](https://docs.anza.xyz/proposals/versioned-transactions) для версійних транзакцій та таблиць пошуку адрес - diff --git a/docs/locales/uk/clients/javascript-reference.md b/docs/locales/uk/clients/javascript-reference.md index c8631101a..1ea13ade9 100644 --- a/docs/locales/uk/clients/javascript-reference.md +++ b/docs/locales/uk/clients/javascript-reference.md @@ -1,8 +1,8 @@ --- title: Web3.js API Приклади description: - Дізнайтеся, як взаємодіяти з блокчейном Solana за допомогою бібліотеки @solana/web3.js - через практичні приклади коду та пояснення. + Дізнайтеся, як взаємодіяти з блокчейном Solana за допомогою бібліотеки + @solana/web3.js через практичні приклади коду та пояснення. --- ## Довідник по Web3 API @@ -19,9 +19,13 @@ description: [Документація](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Connection.html) -Об'єкт `Connection` використовується для взаємодії з [Solana JSON RPC](/docs/uk/rpc). Ви можете використовувати Connection для підтвердження транзакцій, отримання інформації про облікові записи тощо. +Об'єкт `Connection` використовується для взаємодії з +[Solana JSON RPC](/docs/uk/rpc). Ви можете використовувати Connection для +підтвердження транзакцій, отримання інформації про облікові записи тощо. -Створення підключення здійснюється шляхом вказання URL-адреси RPC-кластера та бажаного рівня зобов'язань. Після цього ви можете використовувати цей об'єкт підключення для взаємодії з будь-яким із API JSON RPC Solana. +Створення підключення здійснюється шляхом вказання URL-адреси RPC-кластера та +бажаного рівня зобов'язань. Після цього ви можете використовувати цей об'єкт +підключення для взаємодії з будь-яким із API JSON RPC Solana. #### Приклад використання @@ -58,14 +62,20 @@ console.log(slotLeader); //49AqLYbpJYc2DrzGUAH1fhWJy62yxBxpLEkfJwjKy2jr ``` -Наведений вище приклад показує лише кілька методів класу Connection. Повний список можна знайти у +Наведений вище приклад показує лише кілька методів класу Connection. Повний +список можна знайти у [генерованій документації](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Connection.html). ### Транзакція [Документація](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Transaction.html) -Транзакція використовується для взаємодії з програмами на блокчейні Solana. Ці транзакції створюються за допомогою TransactionInstructions, які містять усі можливі облікові записи для взаємодії, а також необхідні дані або адреси програм. Кожна TransactionInstruction складається з ключів, даних і programId. Ви можете виконувати кілька інструкцій в одній транзакції, взаємодіючи з кількома програмами одночасно. +Транзакція використовується для взаємодії з програмами на блокчейні Solana. Ці +транзакції створюються за допомогою TransactionInstructions, які містять усі +можливі облікові записи для взаємодії, а також необхідні дані або адреси +програм. Кожна TransactionInstruction складається з ключів, даних і programId. +Ви можете виконувати кілька інструкцій в одній транзакції, взаємодіючи з +кількома програмами одночасно. #### Приклад використання @@ -135,7 +145,9 @@ await web3.sendAndConfirmRawTransaction(connection, rawTransaction); [Документація](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Keypair.html) -Keypair використовується для створення облікового запису з публічним і секретним ключами в Solana. Ви можете згенерувати Keypair, створити його з seed або секретного ключа. +Keypair використовується для створення облікового запису з публічним і секретним +ключами в Solana. Ви можете згенерувати Keypair, створити його з seed або +секретного ключа. #### Приклад використання @@ -170,20 +182,34 @@ console.log(accountFromSecret.secretKey); // Uint8Array(64) [...] ``` -Використання `generate` генерує випадкову Keypair для облікового запису на Solana. Використання `fromSeed` дозволяє створити Keypair з детермінованим конструктором. `fromSecret` створює Keypair із секретного масиву Uint8Array. Ви можете побачити, що publicKey для Keypair, створеної за допомогою `generate`, і `fromSecret` однакові, оскільки секретний ключ однаковий. +Використання `generate` генерує випадкову Keypair для облікового запису на +Solana. Використання `fromSeed` дозволяє створити Keypair з детермінованим +конструктором. `fromSecret` створює Keypair із секретного масиву Uint8Array. Ви +можете побачити, що publicKey для Keypair, створеної за допомогою `generate`, і +`fromSecret` однакові, оскільки секретний ключ однаковий. + ### Використання `generate` створює випадкову пару ключів для використання як обліковий запис у Solana. -Використання `fromSeed` дозволяє створити пару ключів за допомогою детермінованого конструктора. -`fromSecret` створює пару ключів із секретного масиву Uint8Array. Ви можете побачити, що publicKey для пари ключів `generate` і `fromSecret` є однаковими, оскільки секрет від пари ключів `generate` використовується в `fromSecret`. -**Попередження**: Не використовуйте `fromSeed`, якщо ви не створюєте seed із високою ентропією. Не розголошуйте ваш seed. Ставтеся до seed так само, як до приватного ключа. +Використання `fromSeed` дозволяє створити пару ключів за допомогою +детермінованого конструктора. `fromSecret` створює пару ключів із секретного +масиву Uint8Array. Ви можете побачити, що publicKey для пари ключів `generate` і +`fromSecret` є однаковими, оскільки секрет від пари ключів `generate` +використовується в `fromSecret`. + +**Попередження**: Не використовуйте `fromSeed`, якщо ви не створюєте seed із +високою ентропією. Не розголошуйте ваш seed. Ставтеся до seed так само, як до +приватного ключа. ### PublicKey [Джерело документації](https://solana-labs.github.io/solana-web3.js/v1.x/classes/PublicKey.html) -`PublicKey` використовується в `@solana/web3.js` для транзакцій, пар ключів і програм. Вам потрібен publicKey при зазначенні кожного облікового запису в транзакції, а також як загальний ідентифікатор у Solana. +`PublicKey` використовується в `@solana/web3.js` для транзакцій, пар ключів і +програм. Вам потрібен publicKey при зазначенні кожного облікового запису в +транзакції, а також як загальний ідентифікатор у Solana. -`PublicKey` можна створити за допомогою base58-строки, буфера, Uint8Array, числа або масиву чисел. +`PublicKey` можна створити за допомогою base58-строки, буфера, Uint8Array, числа +або масиву чисел. #### Приклад використання @@ -206,7 +232,9 @@ let programAddressFromKey = await web3.PublicKey.createProgramAddress( [highEntropyBuffer.slice(0, 31)], base58publicKey, ); -console.log(`Згенерована програмна адреса: ${programAddressFromKey.toBase58()}`); +console.log( + `Згенерована програмна адреса: ${programAddressFromKey.toBase58()}`, +); // Згенерована програмна адреса: 3thxPEEz4EDWHNxo1LpEpsAxZryPAHyvNVXJEJWgBgwJ @@ -224,7 +252,10 @@ console.log(`Дійсна програмна адреса: ${validProgramAddress [Джерело документації](https://solana-labs.github.io/solana-web3.js/v1.x/classes/SystemProgram.html) -`SystemProgram` дозволяє створювати облікові записи, виділяти дані облікових записів, призначати облікові записи програмам, працювати з nonce-обліковими записами та переводити лампорти. Ви можете використовувати клас `SystemInstruction` для декодування та читання окремих інструкцій. +`SystemProgram` дозволяє створювати облікові записи, виділяти дані облікових +записів, призначати облікові записи програмам, працювати з nonce-обліковими +записами та переводити лампорти. Ви можете використовувати клас +`SystemInstruction` для декодування та читання окремих інструкцій. #### Приклад використання @@ -313,13 +344,14 @@ await web3.sendAndConfirmTransaction(connection, assignTransaction, [ payer, assignedAccount, ]); - ``` + ### Secp256k1Program [Документація Джерела](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Secp256k1Program.html) -`Secp256k1Program` використовується для перевірки підписів `Secp256k1`, які використовуються як у Bitcoin, так і в Ethereum. +`Secp256k1Program` використовується для перевірки підписів `Secp256k1`, які +використовуються як у Bitcoin, так і в Ethereum. #### Приклад Використання @@ -381,7 +413,11 @@ await web3.sendAndConfirmTransaction(connection, transaction, [fromPublicKey]); [Документація Джерела](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Message.html) -`Message` використовується як альтернативний спосіб створення транзакцій. Ви можете створити повідомлення за допомогою облікових записів, заголовка, інструкцій та недавнього блочного хеша, які є частиною транзакції. [Transaction](/docs/uk/clients/javascript.md#Transaction) є `Message` плюс список необхідних підписів для виконання транзакції. +`Message` використовується як альтернативний спосіб створення транзакцій. Ви +можете створити повідомлення за допомогою облікових записів, заголовка, +інструкцій та недавнього блочного хеша, які є частиною транзакції. +[Transaction](/docs/uk/clients/javascript.md#Transaction) є `Message` плюс +список необхідних підписів для виконання транзакції. #### Приклад Використання @@ -443,7 +479,9 @@ await web3.sendAndConfirmTransaction(connection, transaction, [fromPublicKey]); [Документація Джерела](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Struct.html) -Клас `Struct` використовується для створення структур, сумісних із Rust, у JavaScript. Цей клас сумісний лише з Rust-структурами, закодованими за допомогою Borsh. +Клас `Struct` використовується для створення структур, сумісних із Rust, у +JavaScript. Цей клас сумісний лише з Rust-структурами, закодованими за допомогою +Borsh. #### Приклад Використання @@ -472,7 +510,11 @@ export class Fee extends Struct { [Документація Джерела](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Enum.html) -Клас `Enum` використовується для представлення сумісного з Rust енумератора у JavaScript. Енумератор буде представлений як строка при логуванні, але може бути правильно закодований/декодований при використанні разом з [Struct](/docs/uk/clients/javascript.md#Struct). Цей клас сумісний лише з Rust-енумераторами, закодованими за допомогою Borsh. +Клас `Enum` використовується для представлення сумісного з Rust енумератора у +JavaScript. Енумератор буде представлений як строка при логуванні, але може бути +правильно закодований/декодований при використанні разом з +[Struct](/docs/uk/clients/javascript.md#Struct). Цей клас сумісний лише з +Rust-енумераторами, закодованими за допомогою Borsh. #### Приклад Використання @@ -498,9 +540,15 @@ export class AccountType extends Enum {} [Документація Джерела](https://solana-labs.github.io/solana-web3.js/v1.x/classes/NonceAccount.html) -Зазвичай транзакція відхиляється, якщо поле `recentBlockhash` транзакції є застарілим. Для забезпечення певних кастодіальних послуг використовуються облікові записи `NonceAccount`. Транзакції, які використовують `recentBlockhash`, зафіксовані на блокчейні обліковим записом `NonceAccount`, не старіють доти, доки цей обліковий запис не буде оновлено. +Зазвичай транзакція відхиляється, якщо поле `recentBlockhash` транзакції є +застарілим. Для забезпечення певних кастодіальних послуг використовуються +облікові записи `NonceAccount`. Транзакції, які використовують +`recentBlockhash`, зафіксовані на блокчейні обліковим записом `NonceAccount`, не +старіють доти, доки цей обліковий запис не буде оновлено. -Ви можете створити `NonceAccount`, спочатку створивши звичайний обліковий запис, а потім використовуючи `SystemProgram`, щоб зробити цей обліковий запис `NonceAccount`. +Ви можете створити `NonceAccount`, спочатку створивши звичайний обліковий запис, +а потім використовуючи `SystemProgram`, щоб зробити цей обліковий запис +`NonceAccount`. #### Приклад Використання @@ -575,13 +623,17 @@ console.log(nonceAccountFromInfo); // } ``` -Наведений вище приклад показує як створити `NonceAccount` за допомогою `SystemProgram.createNonceAccount`, а також як отримати `NonceAccount` з accountInfo. Використовуючи nonce, ви можете створювати транзакції офлайн з nonce замість `recentBlockhash`. +Наведений вище приклад показує як створити `NonceAccount` за допомогою +`SystemProgram.createNonceAccount`, а також як отримати `NonceAccount` з +accountInfo. Використовуючи nonce, ви можете створювати транзакції офлайн з +nonce замість `recentBlockhash`. ### VoteAccount [Документація Джерела](https://solana-labs.github.io/solana-web3.js/v1.x/classes/VoteAccount.html) -`VoteAccount` — це об'єкт, який дозволяє декодувати облікові записи для голосування з використанням нативної програми голосування в мережі. +`VoteAccount` — це об'єкт, який дозволяє декодувати облікові записи для +голосування з використанням нативної програми голосування в мережі. #### Приклад Використання @@ -653,7 +705,12 @@ VoteAccount { [Документація Джерела](https://solana-labs.github.io/solana-web3.js/v1.x/classes/StakeProgram.html) -`StakeProgram` полегшує процес стейкінгу SOL і делегування їх будь-яким валідаторам у мережі. Ви можете використовувати `StakeProgram`, щоб створити стейк-обліковий запис, застейкати SOL, авторизувати облікові записи для виведення стейка, деактивувати стейк і вивести кошти. Клас `StakeInstruction` використовується для декодування та читання додаткових інструкцій з транзакцій, що викликають `StakeProgram`. +`StakeProgram` полегшує процес стейкінгу SOL і делегування їх будь-яким +валідаторам у мережі. Ви можете використовувати `StakeProgram`, щоб створити +стейк-обліковий запис, застейкати SOL, авторизувати облікові записи для +виведення стейка, деактивувати стейк і вивести кошти. Клас `StakeInstruction` +використовується для декодування та читання додаткових інструкцій з транзакцій, +що викликають `StakeProgram`. #### Приклад Використання @@ -749,15 +806,23 @@ await web3.sendAndConfirmTransaction(connection, withdrawTransaction, [ [Документація Джерела](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Authorized.html) -`Authorized` — це об'єкт, який використовується під час створення авторизованого облікового запису для стейкінгу в Solana. Ви можете окремо призначити `staker` і `withdrawer`, що дозволяє іншому обліковому запису виводити кошти, ніж той, що виконує стейкінг. +`Authorized` — це об'єкт, який використовується під час створення авторизованого +облікового запису для стейкінгу в Solana. Ви можете окремо призначити `staker` і +`withdrawer`, що дозволяє іншому обліковому запису виводити кошти, ніж той, що +виконує стейкінг. -Більше прикладів використання об'єкта `Authorized` ви можете знайти в розділі [`StakeProgram`](/docs/uk/clients/javascript.md#StakeProgram). +Більше прикладів використання об'єкта `Authorized` ви можете знайти в розділі +[`StakeProgram`](/docs/uk/clients/javascript.md#StakeProgram). ### Lockup [Документація Джерела](https://solana-labs.github.io/solana-web3.js/v1.x/classes/Lockup.html) -`Lockup` використовується разом із [StakeProgram](/docs/uk/clients/javascript.md#StakeProgram) для створення облікового запису. `Lockup` визначає, як довго стейк буде заблокований або недоступний для вилучення. Якщо `Lockup` встановлений на 0 як для епохи, так і для мітки часу Unix, блокування для облікового запису буде відключено. +`Lockup` використовується разом із +[StakeProgram](/docs/uk/clients/javascript.md#StakeProgram) для створення +облікового запису. `Lockup` визначає, як довго стейк буде заблокований або +недоступний для вилучення. Якщо `Lockup` встановлений на 0 як для епохи, так і +для мітки часу Unix, блокування для облікового запису буде відключено. #### Приклад Використання @@ -783,7 +848,10 @@ let createStakeAccountInstruction = StakeProgram.createAccount({ }); ``` -Наведений вище код створює `createStakeAccountInstruction`, який використовується для створення облікового запису за допомогою `StakeProgram`. Блокування встановлено на 0 як для епохи, так і для мітки часу Unix, що відключає блокування для облікового запису. - -Детальніше див. у розділі [StakeProgram](/docs/uk/clients/javascript.md#StakeProgram). +Наведений вище код створює `createStakeAccountInstruction`, який +використовується для створення облікового запису за допомогою `StakeProgram`. +Блокування встановлено на 0 як для епохи, так і для мітки часу Unix, що +відключає блокування для облікового запису. +Детальніше див. у розділі +[StakeProgram](/docs/uk/clients/javascript.md#StakeProgram). diff --git a/docs/locales/uk/clients/javascript.md b/docs/locales/uk/clients/javascript.md index 790d6f6ef..482da4c62 100644 --- a/docs/locales/uk/clients/javascript.md +++ b/docs/locales/uk/clients/javascript.md @@ -4,7 +4,9 @@ title: JavaScript Клієнт для Solana sidebarSortOrder: 2 description: Дізнайтеся, як взаємодіяти з Solana за допомогою клієнтської бібліотеки - JavaScript/TypeScript (@solana/web3.js). У цьому посібнику розглядаються підключення гаманця, транзакції та взаємодія з власними програмами з прикладами коду. + JavaScript/TypeScript (@solana/web3.js). У цьому посібнику розглядаються + підключення гаманця, транзакції та взаємодія з власними програмами з + прикладами коду. --- ## Що таке Solana-Web3.js? @@ -17,11 +19,11 @@ description: ## Загальна термінологія -| Термін | Визначення | -| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Програма | Безстанова виконувана програма, написана для інтерпретації інструкцій. Програми можуть виконувати дії на основі наданих інструкцій. | -| Інструкція | Найменша одиниця програми, яку клієнт може включити в транзакцію. Під час виконання коду інструкція може містити одну або кілька міжпрограмних викликів. | -| Транзакція | Одна або кілька інструкцій, підписаних клієнтом за допомогою одного або кількох Keypair, і виконуються атомарно з двома можливими результатами: успіх або невдача. | +| Термін | Визначення | +| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Програма | Безстанова виконувана програма, написана для інтерпретації інструкцій. Програми можуть виконувати дії на основі наданих інструкцій. | +| Інструкція | Найменша одиниця програми, яку клієнт може включити в транзакцію. Під час виконання коду інструкція може містити одну або кілька міжпрограмних викликів. | +| Транзакція | Одна або кілька інструкцій, підписаних клієнтом за допомогою одного або кількох Keypair, і виконуються атомарно з двома можливими результатами: успіх або невдача. | Для повного списку термінів дивіться [Термінологія Solana](/docs/terminology.md#cross-program-invocation-cpi) @@ -79,7 +81,9 @@ console.log(solanaWeb3); ### Підключення до гаманця -Щоб користувачі могли використовувати ваш dApp або додаток у Solana, їм потрібно отримати доступ до свого Keypair. Keypair - це приватний ключ з відповідним відкритим ключем, який використовується для підпису транзакцій. +Щоб користувачі могли використовувати ваш dApp або додаток у Solana, їм потрібно +отримати доступ до свого Keypair. Keypair - це приватний ключ з відповідним +відкритим ключем, який використовується для підпису транзакцій. Є два способи отримати Keypair: @@ -94,9 +98,11 @@ const { Keypair } = require("@solana/web3.js"); let keypair = Keypair.generate(); ``` -Це згенерує новий Keypair для користувача, який можна використовувати у вашому додатку. +Це згенерує новий Keypair для користувача, який можна використовувати у вашому +додатку. -Ви можете дозволити введення secretKey через текстове поле та отримати Keypair за допомогою `Keypair.fromSecretKey(secretKey)`. +Ви можете дозволити введення secretKey через текстове поле та отримати Keypair +за допомогою `Keypair.fromSecretKey(secretKey)`. ```javascript const { Keypair } = require("@solana/web3.js"); @@ -111,14 +117,23 @@ let secretKey = Uint8Array.from([ let keypair = Keypair.fromSecretKey(secretKey); ``` -Багато гаманців сьогодні дозволяють користувачам імпортувати свій Keypair за допомогою різних розширень або веб-гаманців. Загальна рекомендація - використовувати гаманці, а не Keypair, для підпису транзакцій. Гаманець створює шар розділення між dApp та Keypair, забезпечуючи, що dApp ніколи не має доступу до секретного ключа. Ви можете знайти способи підключення до зовнішніх гаманців за допомогою бібліотеки [wallet-adapter](https://github.com/solana-labs/wallet-adapter). +Багато гаманців сьогодні дозволяють користувачам імпортувати свій Keypair за +допомогою різних розширень або веб-гаманців. Загальна рекомендація - +використовувати гаманці, а не Keypair, для підпису транзакцій. Гаманець створює +шар розділення між dApp та Keypair, забезпечуючи, що dApp ніколи не має доступу +до секретного ключа. Ви можете знайти способи підключення до зовнішніх гаманців +за допомогою бібліотеки +[wallet-adapter](https://github.com/solana-labs/wallet-adapter). ### Створення та відправка транзакцій -Щоб взаємодіяти з програмами на Solana, ви створюєте, підписуєте та відправляєте транзакції до мережі. Транзакції - це колекції інструкцій з підписами. Порядок, в якому інструкції існують у транзакції, визначає порядок їх виконання. +Щоб взаємодіяти з програмами на Solana, ви створюєте, підписуєте та відправляєте +транзакції до мережі. Транзакції - це колекції інструкцій з підписами. Порядок, +в якому інструкції існують у транзакції, визначає порядок їх виконання. -Транзакція в Solana-Web3.js створюється за допомогою -об'єкта [`Transaction`](/docs/clients/javascript.md#Transaction) і додавання бажаних повідомлень, адрес або інструкцій. +Транзакція в Solana-Web3.js створюється за допомогою об'єкта +[`Transaction`](/docs/clients/javascript.md#Transaction) і додавання бажаних +повідомлень, адрес або інструкцій. Приклад транзакції передачі: @@ -143,9 +158,15 @@ transaction.add( ); ``` -Вищенаведений код створює транзакцію, готову до підпису та передачі в мережу. Інструкція `SystemProgram.transfer` була додана до транзакції, що містить суму lamports для відправки, а також публічні ключі `to` і `from`. +Вищенаведений код створює транзакцію, готову до підпису та передачі в мережу. +Інструкція `SystemProgram.transfer` була додана до транзакції, що містить суму +lamports для відправки, а також публічні ключі `to` і `from`. -Все, що залишилося зробити - підписати транзакцію за допомогою Keypair і відправити її через мережу. Ви можете виконати відправку транзакції за допомогою `sendAndConfirmTransaction`, якщо хочете сповістити користувача або зробити щось після завершення транзакції, або використовувати `sendTransaction`, якщо не потрібно чекати підтвердження транзакції. +Все, що залишилося зробити - підписати транзакцію за допомогою Keypair і +відправити її через мережу. Ви можете виконати відправку транзакції за допомогою +`sendAndConfirmTransaction`, якщо хочете сповістити користувача або зробити щось +після завершення транзакції, або використовувати `sendTransaction`, якщо не +потрібно чекати підтвердження транзакції. ```javascript const { @@ -160,13 +181,20 @@ let connection = new Connection(clusterApiUrl("testnet")); sendAndConfirmTransaction(connection, transaction, [keypair]); ``` -Вищенаведений код приймає `TransactionInstruction` за допомогою `SystemProgram`, створює `Transaction` і відправляє її через мережу. Ви використовуєте `Connection`, щоб визначити, до якої мережі Solana ви підключаєтесь, а саме `mainnet-beta`, `testnet` або `devnet`. +Вищенаведений код приймає `TransactionInstruction` за допомогою `SystemProgram`, +створює `Transaction` і відправляє її через мережу. Ви використовуєте +`Connection`, щоб визначити, до якої мережі Solana ви підключаєтесь, а саме +`mainnet-beta`, `testnet` або `devnet`. ### Взаємодія з власними програмами -Попередній розділ розглядає відправлення базових транзакцій. У Solana все, що ви робите, взаємодіє з різними програмами, включаючи транзакцію передачі в попередньому розділі. На момент написання програми на Solana пишуться на Rust або C. +Попередній розділ розглядає відправлення базових транзакцій. У Solana все, що ви +робите, взаємодіє з різними програмами, включаючи транзакцію передачі в +попередньому розділі. На момент написання програми на Solana пишуться на Rust +або C. -Розглянемо `SystemProgram`. Сигнатура методу для виділення простору в вашому обліковому записі в Solana на Rust виглядає так: +Розглянемо `SystemProgram`. Сигнатура методу для виділення простору в вашому +обліковому записі в Solana на Rust виглядає так: ```rust pub fn allocate( @@ -175,11 +203,19 @@ pub fn allocate( ) -> Instruction ``` -У Solana, коли ви хочете взаємодіяти з програмою, ви повинні спочатку знати всі облікові записи, з якими програма буде взаємодіяти. +У Solana, коли ви хочете взаємодіяти з програмою, ви повинні спочатку знати всі +облікові записи, з якими програма буде взаємодіяти. -Ви завжди повинні надавати кожен обліковий запис, з яким програма буде взаємодіяти в інструкції. Крім того, ви повинні вказати, чи є обліковий запис `isSigner` або `isWritable`. +Ви завжди повинні надавати кожен обліковий запис, з яким програма буде +взаємодіяти в інструкції. Крім того, ви повинні вказати, чи є обліковий запис +`isSigner` або `isWritable`. -У методі `allocate` вище потрібен один обліковий запис `pubkey`, а також кількість `space` для виділення. Ми знаємо, що метод `allocate` записує в обліковий запис, виділяючи в ньому простір, роблячи `pubkey` обов'язковим `isWritable`. `isSigner` потрібен, коли ви вказуєте обліковий запис, який виконує інструкцію. У цьому випадку підписувач - це обліковий запис, який викликає виділення простору в собі. +У методі `allocate` вище потрібен один обліковий запис `pubkey`, а також +кількість `space` для виділення. Ми знаємо, що метод `allocate` записує в +обліковий запис, виділяючи в ньому простір, роблячи `pubkey` обов'язковим +`isWritable`. `isSigner` потрібен, коли ви вказуєте обліковий запис, який +виконує інструкцію. У цьому випадку підписувач - це обліковий запис, який +викликає виділення простору в собі. Давайте подивимося, як викликати цю інструкцію за допомогою solana-web3.js: @@ -196,7 +232,9 @@ let airdropSignature = await connection.requestAirdrop( await connection.confirmTransaction({ signature: airdropSignature }); ``` -Спочатку ми налаштовуємо Keypair і підключення, щоб у нас був обліковий запис для виділення на тестовій мережі. Ми також створюємо Keypair для платника і додаємо трохи SOL, щоб оплатити транзакцію виділення. +Спочатку ми налаштовуємо Keypair і підключення, щоб у нас був обліковий запис +для виділення на тестовій мережі. Ми також створюємо Keypair для платника і +додаємо трохи SOL, щоб оплатити транзакцію виділення. ```javascript let allocateTransaction = new web3.Transaction({ @@ -206,7 +244,13 @@ let keys = [{ pubkey: keypair.publicKey, isSigner: true, isWritable: true }]; let params = { space: 100 }; ``` -Ми створюємо транзакцію `allocateTransaction`, об'єкти keys та params. Поле `feePayer` є необов'язковим при створенні транзакції, воно вказує, хто оплачує транзакцію, за замовчуванням використовується pubkey першого підписувача в транзакції. `keys` представляє всі облікові записи, з якими функція програми `allocate` буде взаємодіяти. Оскільки функція `allocate` також вимагає простору, ми створили `params`, щоб його використати пізніше при виклику функції `allocate`. +Ми створюємо транзакцію `allocateTransaction`, об'єкти keys та params. Поле +`feePayer` є необов'язковим при створенні транзакції, воно вказує, хто оплачує +транзакцію, за замовчуванням використовується pubkey першого підписувача в +транзакції. `keys` представляє всі облікові записи, з якими функція програми +`allocate` буде взаємодіяти. Оскільки функція `allocate` також вимагає простору, +ми створили `params`, щоб його використати пізніше при виклику функції +`allocate`. ```javascript let allocateStruct = { @@ -215,7 +259,11 @@ let allocateStruct = { }; ``` -Це створено за допомогою `u32` і `ns64` з `@solana/buffer-layout` для створення payload. Функція `allocate` приймає параметр `space`. Щоб взаємодіяти з функцією, ми повинні надати дані у форматі Buffer. Бібліотека `buffer-layout` допомагає з виділенням буфера та його правильним кодуванням для інтерпретації програмами на Rust в Solana. +Це створено за допомогою `u32` і `ns64` з `@solana/buffer-layout` для створення +payload. Функція `allocate` приймає параметр `space`. Щоб взаємодіяти з +функцією, ми повинні надати дані у форматі Buffer. Бібліотека `buffer-layout` +допомагає з виділенням буфера та його правильним кодуванням для інтерпретації +програмами на Rust в Solana. Давайте розглянемо цю структуру детальніше. @@ -229,7 +277,8 @@ let allocateStruct = { } ``` -`index` встановлений у 8, тому що функція `allocate` знаходиться на 8-й позиції у enum інструкцій для `SystemProgram`. +`index` встановлений у 8, тому що функція `allocate` знаходиться на 8-й позиції +у enum інструкцій для `SystemProgram`. ```rust /* https://github.com/solana-labs/solana/blob/21bc43ed58c63c827ba4db30426965ef3e807180/sdk/program/src/system_instruction.rs#L142-L305 */ @@ -262,8 +311,8 @@ pub enum SystemInstruction { } ``` -`layout` у структурі allocate завжди має мати `u32('instruction')` першим -при використанні для виклику інструкції. +`layout` у структурі allocate завжди має мати `u32('instruction')` першим при +використанні для виклику інструкції. ```javascript { @@ -275,7 +324,11 @@ pub enum SystemInstruction { } ``` -`ns64('space')` - це аргумент для функції `allocate`. Ви можете бачити, що в оригінальній функції `allocate` на Rust, space мав тип `u64`. `u64` є 64-бітовим unsigned integer. У Javascript за замовчуванням підтримуються тільки 53-бітові числа. `ns64` з `@solana/buffer-layout` допомагає з конвертацією типів між Rust і Javascript. Ви можете знайти більше конвертацій типів між Rust і Javascript на +`ns64('space')` - це аргумент для функції `allocate`. Ви можете бачити, що в +оригінальній функції `allocate` на Rust, space мав тип `u64`. `u64` є 64-бітовим +unsigned integer. У Javascript за замовчуванням підтримуються тільки 53-бітові +числа. `ns64` з `@solana/buffer-layout` допомагає з конвертацією типів між Rust +і Javascript. Ви можете знайти більше конвертацій типів між Rust і Javascript на [solana-labs/buffer-layout](https://github.com/solana-labs/buffer-layout). ```javascript @@ -284,7 +337,10 @@ let layoutFields = Object.assign({ instruction: allocateStruct.index }, params); allocateStruct.layout.encode(layoutFields, data); ``` -Використовуючи створений раніше bufferLayout, ми можемо виділити буфер даних. Потім ми присвоюємо наші params `{ space: 100 }`, щоб вони правильно відповідали макету, і кодуємо їх у буфер даних. Тепер дані готові для відправлення до програми. +Використовуючи створений раніше bufferLayout, ми можемо виділити буфер даних. +Потім ми присвоюємо наші params `{ space: 100 }`, щоб вони правильно відповідали +макету, і кодуємо їх у буфер даних. Тепер дані готові для відправлення до +програми. ```javascript allocateTransaction.add( @@ -301,7 +357,8 @@ await web3.sendAndConfirmTransaction(connection, allocateTransaction, [ ]); ``` -Нарешті, ми додаємо інструкцію транзакції з усіма ключами облікових записів, платником, даними та programId і передаємо транзакцію до мережі. +Нарешті, ми додаємо інструкцію транзакції з усіма ключами облікових записів, +платником, даними та programId і передаємо транзакцію до мережі. Повний код можна знайти нижче. diff --git a/docs/locales/uk/clients/rust.md b/docs/locales/uk/clients/rust.md index d058363e7..b9037668c 100644 --- a/docs/locales/uk/clients/rust.md +++ b/docs/locales/uk/clients/rust.md @@ -16,29 +16,33 @@ Rust пакети для Solana - [Створіть і розгорніть вашу першу програму Solana, використовуючи тільки ваш браузер](/content/guides/getstarted/hello-world-in-your-browser.md). Інсталяція не потрібна. -- [Налаштуйте ваше локальне середовище](/docs/uk/intro/installation) і використовуйте локальний тестовий валідатор. +- [Налаштуйте ваше локальне середовище](/docs/uk/intro/installation) і + використовуйте локальний тестовий валідатор. ## Rust Пакети -Нижче наведено найважливіші та найчастіше використовувані Rust пакети для розробки в Solana: +Нижче наведено найважливіші та найчастіше використовувані Rust пакети для +розробки в Solana: -- [`solana-program`] — Імпортується програмами, що працюють у Solana, і компілюється до - SBF. Цей пакет містить багато фундаментальних типів даних і реекспортується з - [`solana-sdk`], який не можна імпортувати у програму Solana. +- [`solana-program`] — Імпортується програмами, що працюють у Solana, і + компілюється до SBF. Цей пакет містить багато фундаментальних типів даних і + реекспортується з [`solana-sdk`], який не можна імпортувати у програму Solana. - [`solana-sdk`] — Базовий SDK для роботи поза мережею, реекспортує - [`solana-program`] і додає більше API на додаток до цього. Більшість програм Solana, - що не працюють у мережі, імпортують цей пакет. + [`solana-program`] і додає більше API на додаток до цього. Більшість програм + Solana, що не працюють у мережі, імпортують цей пакет. - [`solana-client`] — Для взаємодії з вузлом Solana через [JSON RPC API](/docs/uk/rpc). -- [`solana-cli-config`] — Завантаження та збереження конфігураційного файлу Solana CLI. +- [`solana-cli-config`] — Завантаження та збереження конфігураційного + файлу Solana CLI. -- [`solana-clap-utils`] — Рутини для налаштування CLI, використовуючи [`clap`], як у - основному CLI Solana. Включає функції для завантаження всіх типів підписантів, підтримуваних CLI. +- [`solana-clap-utils`] — Рутини для налаштування CLI, використовуючи + [`clap`], як у основному CLI Solana. Включає функції для завантаження всіх + типів підписантів, підтримуваних CLI. [`solana-program`]: https://docs.rs/solana-program [`solana-sdk`]: https://docs.rs/solana-sdk diff --git a/docs/locales/uk/core/accounts.md b/docs/locales/uk/core/accounts.md index f45f08df5..ab7f7bd41 100644 --- a/docs/locales/uk/core/accounts.md +++ b/docs/locales/uk/core/accounts.md @@ -3,10 +3,10 @@ sidebarSortOrder: 1 sidebarLabel: Модель облікових записів Solana title: Модель облікових записів Solana description: - Дізнайтеся про модель облікових записів Solana, включаючи те, як облікові записи зберігають дані - і програми, механіку оренди, власність облікових записів і взаємозв'язок між - програмами та обліковими записами даних. Зрозумійте основні концепції системи - зберігання ключ-значення Solana. + Дізнайтеся про модель облікових записів Solana, включаючи те, як облікові + записи зберігають дані і програми, механіку оренди, власність облікових + записів і взаємозв'язок між програмами та обліковими записами даних. + Зрозумійте основні концепції системи зберігання ключ-значення Solana. --- У Solana всі дані зберігаються в так званих "облікових записах". Спосіб @@ -18,73 +18,84 @@ description: ## Основні моменти -- Облікові записи можуть зберігати до 10 МБ даних, які можуть складатися з виконуваного - коду програми або стану програми. +- Облікові записи можуть зберігати до 10 МБ даних, які можуть складатися з + виконуваного коду програми або стану програми. -- Облікові записи потребують застави в SOL, пропорційної обсягу збережених даних, - яка повністю повертається при закритті облікового запису. +- Облікові записи потребують застави в SOL, пропорційної обсягу збережених + даних, яка повністю повертається при закритті облікового запису. -- Кожен обліковий запис має "власника" програми. Тільки програма, яка володіє обліковим записом, може - змінювати його дані або знімати баланс лампортів. Однак будь-хто може - збільшити баланс. +- Кожен обліковий запис має "власника" програми. Тільки програма, яка володіє + обліковим записом, може змінювати його дані або знімати баланс лампортів. + Однак будь-хто може збільшити баланс. -- Програми (смартконтракти) є безстанними обліковими записами, які зберігають виконуваний код. +- Програми (смартконтракти) є безстанними обліковими записами, які зберігають + виконуваний код. -- Облікові записи даних створюються програмами для зберігання і керування станом програми. +- Облікові записи даних створюються програмами для зберігання і керування станом + програми. -- Вбудовані програми - це вбудовані програми, які включені у середовище виконання Solana. +- Вбудовані програми - це вбудовані програми, які включені у середовище + виконання Solana. -- Системні облікові записи - це спеціальні облікові записи, які зберігають стан кластера мережі. +- Системні облікові записи - це спеціальні облікові записи, які зберігають стан + кластера мережі. ## Обліковий запис -Кожен обліковий запис ідентифікується його унікальною адресою, представленою у форматі 32 байт -як [Ed25519](https://ed25519.cr.yp.to/) `PublicKey`. Ви можете вважати -адресу унікальним ідентифікатором облікового запису. +Кожен обліковий запис ідентифікується його унікальною адресою, представленою у +форматі 32 байт як [Ed25519](https://ed25519.cr.yp.to/) `PublicKey`. Ви можете +вважати адресу унікальним ідентифікатором облікового запису. ![Адреса облікового запису](/assets/docs/core/accounts/account-address.svg) -Цей зв'язок між обліковим записом та його адресою можна розглядати як -пару ключ-значення, де адреса є ключем для пошуку відповідних -даних облікового запису в ланцюжку. +Цей зв'язок між обліковим записом та його адресою можна розглядати як пару +ключ-значення, де адреса є ключем для пошуку відповідних даних облікового запису +в ланцюжку. ### AccountInfo Облікові записи мають [максимальний розмір у 10 МБ](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/system_instruction.rs#L85) -(10 мегабайт), а дані, що зберігаються в кожному обліковому записі Solana, мають наступну -структуру, відому як +(10 мегабайт), а дані, що зберігаються в кожному обліковому записі Solana, мають +наступну структуру, відому як [AccountInfo](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/account_info.rs#L19). ![AccountInfo](/assets/docs/core/accounts/accountinfo.svg) `AccountInfo` для кожного облікового запису включає наступні поля: -- `data`: Масив байтів, який зберігає стан облікового запису. Якщо обліковий запис є - програмою (смартконтрактом), це поле зберігає виконуваний код програми. Це поле часто - називають "даними облікового запису". +- `data`: Масив байтів, який зберігає стан облікового запису. Якщо обліковий + запис є програмою (смартконтрактом), це поле зберігає виконуваний код + програми. Це поле часто називають "даними облікового запису". - `executable`: Булевий прапорець, який вказує, чи є обліковий запис програмою. - `lamports`: Числове представлення балансу облікового запису в [лампортах](/docs/terminology.md#lamport), найменшій одиниці SOL (1 SOL = 1 мільярд лампортів). -- `owner`: Вказує публічний ключ (Program ID) програми, яка володіє обліковим записом. +- `owner`: Вказує публічний ключ (Program ID) програми, яка володіє обліковим + записом. -Як ключова частина моделі облікових записів Solana, кожен обліковий запис у Solana має -визначеного "власника", а саме програму. Тільки програма, зазначена як власник облікового запису, може -змінювати дані, що зберігаються в обліковому записі, або знімати баланс лампортів. Важливо зазначити, що, хоча тільки власник може знімати баланс, будь-хто може збільшити баланс. +Як ключова частина моделі облікових записів Solana, кожен обліковий запис у +Solana має визначеного "власника", а саме програму. Тільки програма, зазначена +як власник облікового запису, може змінювати дані, що зберігаються в обліковому +записі, або знімати баланс лампортів. Важливо зазначити, що, хоча тільки власник +може знімати баланс, будь-хто може збільшити баланс. > Для зберігання даних у ланцюжку потрібно передати певну кількість SOL до -> облікового запису. Кількість, що передається, пропорційна розміру даних, що зберігаються в обліковому записі. Ця концепція зазвичай називається "орендою". Однак, ви можете розглядати "оренду" швидше як "депозит", оскільки SOL, виділені для облікового запису, можуть бути повністю відновлені при закритті облікового запису. +> облікового запису. Кількість, що передається, пропорційна розміру даних, що +> зберігаються в обліковому записі. Ця концепція зазвичай називається "орендою". +> Однак, ви можете розглядати "оренду" швидше як "депозит", оскільки SOL, +> виділені для облікового запису, можуть бути повністю відновлені при закритті +> облікового запису. ## Вбудовані програми -Solana містить невелику кількість вбудованих програм, які є частиною -реалізації валідатора і забезпечують різні основні функціональності для -мережі. Ви можете знайти повний список вбудованих програм +Solana містить невелику кількість вбудованих програм, які є частиною реалізації +валідатора і забезпечують різні основні функціональності для мережі. Ви можете +знайти повний список вбудованих програм [тут](https://docs.anza.xyz/runtime/programs). -При розробці користувацьких програм на Solana ви часто будете взаємодіяти з двома -вбудованими програмами: Системною Програмою і Завантажувачем BPF. +При розробці користувацьких програм на Solana ви часто будете взаємодіяти з +двома вбудованими програмами: Системною Програмою і Завантажувачем BPF. ### Системна Програма @@ -97,34 +108,40 @@ Solana містить невелику кількість вбудованих - [Виділення простору](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/system/src/system_processor.rs#L70): Встановлює обсяг пам'яті для поля даних кожного облікового запису. - [Призначення власника програми](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/system/src/system_processor.rs#L112): - Після створення облікового запису Системною Програмою вона може перепризначити власника - програми іншому обліковому запису програми. Це спосіб, за яким користувацькі програми беруть - у власність нові облікові записи, створені Системною Програмою. + Після створення облікового запису Системною Програмою вона може перепризначити + власника програми іншому обліковому запису програми. Це спосіб, за яким + користувацькі програми беруть у власність нові облікові записи, створені + Системною Програмою. -У Solana "гаманець" просто є обліковим записом, який належить Системній Програмі. Баланс лампортів у гаманці є кількістю SOL, що належать обліковому запису. +У Solana "гаманець" просто є обліковим записом, який належить Системній +Програмі. Баланс лампортів у гаманці є кількістю SOL, що належать обліковому +запису. ![Системний Обліковий Запис](/assets/docs/core/accounts/system-account.svg) -> Тільки облікові записи, що належать Системній Програмі, можуть використовуватися як платники комісій за транзакції. +> Тільки облікові записи, що належать Системній Програмі, можуть +> використовуватися як платники комісій за транзакції. ### Завантажувач BPF [Завантажувач BPF](https://github.com/solana-labs/solana/tree/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/bpf_loader/src) -є програмою, яка призначена як "власник" усіх інших програм у мережі, -крім Вбудованих Програм. Він відповідає за розгортання, оновлення та виконання користувацьких програм. +є програмою, яка призначена як "власник" усіх інших програм у мережі, крім +Вбудованих Програм. Він відповідає за розгортання, оновлення та виконання +користувацьких програм. ## Системні Облікові Записи -Системні облікові записи - це спеціальні облікові записи, розташовані за попередньо визначеними адресами, які -надають доступ до даних про стан кластера мережі. Ці облікові записи динамічно оновлюються -даними про кластер мережі. Ви можете знайти повний список Системних Облікових Записів +Системні облікові записи - це спеціальні облікові записи, розташовані за +попередньо визначеними адресами, які надають доступ до даних про стан кластера +мережі. Ці облікові записи динамічно оновлюються даними про кластер мережі. Ви +можете знайти повний список Системних Облікових Записів [тут](https://docs.anza.xyz/runtime/sysvars). ## Користувацькі Програми -У Solana "смартконтракти" називаються -[програмами](/docs/core/programs.md). Програма є обліковим записом, який містить -виконуваний код, і позначається прапорцем "виконуваний", який встановлено в значення "true". +У Solana "смартконтракти" називаються [програмами](/docs/core/programs.md). +Програма є обліковим записом, який містить виконуваний код, і позначається +прапорцем "виконуваний", який встановлено в значення "true". Для детального пояснення процесу розгортання програми, зверніться до сторінки [Розгортання Програм](/docs/programs/deploying.md) цієї документації. @@ -135,16 +152,16 @@ Solana містить невелику кількість вбудованих [розгортаються](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/bpf_loader/src/lib.rs#L498) на Solana, технічно створюються три окремі облікові записи: -- **Обліковий Запис Програми**: Основний обліковий запис, який представляє програму в ланцюжку. Цей - обліковий запис зберігає адресу виконуваного облікового запису даних (який зберігає - зкомпільований код програми) і право на оновлення програми (адреса, яка - має дозвіл на внесення змін до програми). -- **Виконуваний Обліковий Запис Програми**: Обліковий запис, який містить виконуваний - байт-код програми. -- **Буферний Обліковий Запис**: Тимчасовий обліковий запис, який зберігає байт-код під час - активного розгортання або оновлення програми. Після завершення процесу дані - передаються до Виконуваного Облікового Запису Програми, а буферний обліковий запис - закривається. +- **Обліковий Запис Програми**: Основний обліковий запис, який представляє + програму в ланцюжку. Цей обліковий запис зберігає адресу виконуваного + облікового запису даних (який зберігає зкомпільований код програми) і право на + оновлення програми (адреса, яка має дозвіл на внесення змін до програми). +- **Виконуваний Обліковий Запис Програми**: Обліковий запис, який містить + виконуваний байт-код програми. +- **Буферний Обліковий Запис**: Тимчасовий обліковий запис, який зберігає + байт-код під час активного розгортання або оновлення програми. Після + завершення процесу дані передаються до Виконуваного Облікового Запису + Програми, а буферний обліковий запис закривається. Наприклад, ось посилання на Solana Explorer для Програмного Розширення Токенів [Обліковий Запис Програми](https://explorer.solana.com/address/TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb) @@ -157,28 +174,33 @@ Solana містить невелику кількість вбудованих ![Обліковий Запис Програми](/assets/docs/core/accounts/program-account-simple.svg) -> Адреса "Облікового Запису Програми" зазвичай називається "ID Програми", який використовується для виклику програми. +> Адреса "Облікового Запису Програми" зазвичай називається "ID Програми", який +> використовується для виклику програми. ### Обліковий Запис Даних Програми Solana є "безстанними", тобто облікові записи програм містять лише -виконуваний байт-код програми. Для зберігання та модифікації додаткових даних необхідно створювати нові -облікові записи. Ці облікові записи зазвичай називаються "обліковими записами даних". +виконуваний байт-код програми. Для зберігання та модифікації додаткових даних +необхідно створювати нові облікові записи. Ці облікові записи зазвичай +називаються "обліковими записами даних". -Облікові записи даних можуть зберігати будь-які довільні дані, визначені в коді програми-власника. +Облікові записи даних можуть зберігати будь-які довільні дані, визначені в коді +програми-власника. ![Обліковий Запис Даних](/assets/docs/core/accounts/data-account.svg) -Зверніть увагу, що тільки [Системна Програма](/docs/core/accounts.md#system-program) може -створювати нові облікові записи. Після створення облікового запису Системною Програмою вона може потім -передати власність нового облікового запису іншій програмі. +Зверніть увагу, що тільки +[Системна Програма](/docs/core/accounts.md#system-program) може створювати нові +облікові записи. Після створення облікового запису Системною Програмою вона може +потім передати власність нового облікового запису іншій програмі. -Іншими словами, створення облікового запису даних для користувацької програми вимагає двох кроків: +Іншими словами, створення облікового запису даних для користувацької програми +вимагає двох кроків: 1. Виклик Системної Програми для створення облікового запису, яка потім передає власність користувацькій програмі 2. Виклик користувацької програми, яка тепер володіє обліковим записом, для ініціалізації даних облікового запису, як це визначено в коді програми -Цей процес створення облікового запису даних часто абстрагується як єдиний крок, але -корисно розуміти підлеглий процес. +Цей процес створення облікового запису даних часто абстрагується як єдиний крок, +але корисно розуміти підлеглий процес. diff --git a/docs/locales/uk/core/clusters.md b/docs/locales/uk/core/clusters.md index abf086ecf..b2a5944fe 100644 --- a/docs/locales/uk/core/clusters.md +++ b/docs/locales/uk/core/clusters.md @@ -5,8 +5,8 @@ sidebarSortOrder: 8 description: Дізнайтеся про кластери мережі Solana (Devnet, Testnet і Mainnet Beta), їхні публічні точки доступу RPC, обмеження швидкості та випадки використання. - Дізнайтеся, як підключатися до різних мереж Solana для розробки, тестування - та виробничого середовища. + Дізнайтеся, як підключатися до різних мереж Solana для розробки, тестування та + виробничого середовища. --- Блокчейн Solana має кілька різних груп валідаторів, відомих як @@ -43,18 +43,19 @@ description: ## Основні відомості - Mainnet: Живе виробниче середовище для розгорнутих додатків. -- Devnet: Тестування з публічним доступом для розробників, які експериментують зі - своїми додатками. +- Devnet: Тестування з публічним доступом для розробників, які експериментують + зі своїми додатками. - Testnet: Стрес-тестування для оновлень мережі та продуктивності валідаторів. -**Приклади використання**: Можливо, ви захочете налагодити нову програму на Devnet -або перевірити метрики продуктивності на Testnet перед розгортанням на Mainnet. +**Приклади використання**: Можливо, ви захочете налагодити нову програму на +Devnet або перевірити метрики продуктивності на Testnet перед розгортанням на +Mainnet. -| **Кластер** | **Точка доступу** | **Призначення** | **Примітки** | -| ----------- | ---------------------------------------- | ------------------------------- | ------------------------------ | -| Mainnet | `https://api.mainnet-beta.solana.com` | Живе виробниче середовище | Потребує SOL для транзакцій | -| Devnet | `https://api.devnet.solana.com` | Публічне тестування та розробка | Безкоштовний SOL для тестування| -| Testnet | `https://api.testnet.solana.com` | Тестування валідаторів | Може мати періодичні простої | +| **Кластер** | **Точка доступу** | **Призначення** | **Примітки** | +| ----------- | ------------------------------------- | ------------------------------- | ------------------------------- | +| Mainnet | `https://api.mainnet-beta.solana.com` | Живе виробниче середовище | Потребує SOL для транзакцій | +| Devnet | `https://api.devnet.solana.com` | Публічне тестування та розробка | Безкоштовний SOL для тестування | +| Testnet | `https://api.testnet.solana.com` | Тестування валідаторів | Може мати періодичні простої | ## Devnet @@ -73,8 +74,8 @@ Devnet слугує тестовим майданчиком для будь-ко ### Точка доступу Devnet -- `https://api.devnet.solana.com` - єдиний вузол API, розміщений Solana Labs; - з обмеженнями швидкості +- `https://api.devnet.solana.com` - єдиний вузол API, розміщений Solana Labs; з + обмеженнями швидкості #### Приклад конфігурації командного рядка `solana` @@ -101,14 +102,14 @@ Testnet - це місце, де основні учасники Solana стре - Токени Testnet **не реальні**. - Testnet може піддаватися скиданням журналу. - Testnet включає крани для отримання токенів для тестування додатків. -- Testnet зазвичай працює на новішій гілці випуску програмного забезпечення, - ніж Devnet і Mainnet Beta. +- Testnet зазвичай працює на новішій гілці випуску програмного забезпечення, ніж + Devnet і Mainnet Beta. - Точка доступу Gossip для Testnet: `entrypoint.testnet.solana.com:8001` ### Точка доступу Testnet -- `https://api.testnet.solana.com` - єдиний вузол API, розміщений Solana Labs; - з обмеженнями швидкості +- `https://api.testnet.solana.com` - єдиний вузол API, розміщений Solana Labs; з + обмеженнями швидкості #### Приклад конфігурації командного рядка `solana` @@ -132,7 +133,8 @@ solana config set --url https://api.testnet.solana.com валідаторів та власників токенів. - Токени, випущені на Mainnet Beta, є **реальними** SOL. -- Точка доступу Gossip для Mainnet Beta: `entrypoint.mainnet-beta.solana.com:8001` +- Точка доступу Gossip для Mainnet Beta: + `entrypoint.mainnet-beta.solana.com:8001` ### Точка доступу Mainnet beta @@ -163,9 +165,10 @@ solana config set --url https://api.mainnet-beta.solana.com ## Загальні HTTP-коди помилок -- 403 -- Ваша IP-адреса або вебсайт було заблоковано. Настав час запустити власні - сервери RPC або знайти приватний сервіс. -- 429 -- Ваша IP-адреса перевищує обмеження швидкості. Зменшіть швидкість! Використовуйте +- 403 -- Ваша IP-адреса або вебсайт було заблоковано. Настав час запустити + власні сервери RPC або знайти приватний сервіс. +- 429 -- Ваша IP-адреса перевищує обмеження швидкості. Зменшіть швидкість! + Використовуйте [Retry-After](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After) HTTP-заголовок відповіді, щоб визначити, як довго потрібно чекати перед повторною спробою. diff --git a/docs/locales/uk/core/cpi.md b/docs/locales/uk/core/cpi.md index cec59477d..a15da2bb8 100644 --- a/docs/locales/uk/core/cpi.md +++ b/docs/locales/uk/core/cpi.md @@ -8,8 +8,8 @@ description: функціональність у мережі Solana. --- -Виклик між програмами (CPI) відбувається, коли одна програма викликає -інструкції іншої програми. Цей механізм дозволяє складати програми Solana. +Виклик між програмами (CPI) відбувається, коли одна програма викликає інструкції +іншої програми. Цей механізм дозволяє складати програми Solana. Інструкції можна уявити як API-методи, які програма надає мережі, а CPI - це виклик одного API-методу іншим API-методом. @@ -22,17 +22,17 @@ description: розширюються на програму-отримувача (B). - Програма-отримувач (B) може здійснювати подальші CPI до інших програм до максимального рівня глибини 4 (наприклад, B->C, C->D). -- Програми можуть "підписувати" від імені [PDA](/docs/core/pda.md), що - створені з їхнього ID програми. +- Програми можуть "підписувати" від імені [PDA](/docs/core/pda.md), що створені + з їхнього ID програми. > У середовищі виконання програм Solana визначено константу під назвою > [`max_invoke_stack_height`](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/program-runtime/src/compute_budget.rs#L31-L35), > яка має значення > [5](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/program-runtime/src/compute_budget.rs#L138). -> Це обмеження встановлює максимальну висоту стеку викликів інструкцій -> програми. Висота стеку починається з 1 для інструкцій транзакції, збільшується -> на 1 кожного разу, коли програма викликає іншу інструкцію. Це ефективно -> обмежує глибину викликів для CPI до 4. +> Це обмеження встановлює максимальну висоту стеку викликів інструкцій програми. +> Висота стеку починається з 1 для інструкцій транзакції, збільшується на 1 +> кожного разу, коли програма викликає іншу інструкцію. Це ефективно обмежує +> глибину викликів для CPI до 4. ## Основні моменти @@ -41,8 +41,8 @@ description: - Привілеї підпису від програми-виклику розширюються на програму-отримувача. -- Під час здійснення CPI програми можуть "підписувати" від імені PDA, - створених із їхнього власного ID програми. +- Під час здійснення CPI програми можуть "підписувати" від імені PDA, створених + із їхнього власного ID програми. - Програма-отримувач може здійснювати додаткові CPI до інших програм до максимальної глибини 4. @@ -50,8 +50,8 @@ description: ## Як написати CPI Написання інструкції для CPI слідує тій самій схемі, що й побудова -[інструкції](/docs/core/transactions.md#instruction) для додавання до транзакції. -Кожна інструкція CPI повинна зазначати таку інформацію: +[інструкції](/docs/core/transactions.md#instruction) для додавання до +транзакції. Кожна інструкція CPI повинна зазначати таку інформацію: - **Адреса програми**: Вказує програму, яка викликається - **Облікові записи**: Перераховує кожен обліковий запис, з якого інструкція @@ -71,9 +71,9 @@ description: Функція [`invoke`](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/program.rs#L132) -використовується під час здійснення CPI, який не потребує підписантів PDA. Під час -здійснення CPI підписанти, надані програмі-виклику, автоматично розширюються на -програму-отримувача. +використовується під час здійснення CPI, який не потребує підписантів PDA. Під +час здійснення CPI підписанти, надані програмі-виклику, автоматично розширюються +на програму-отримувача. ```rust pub fn invoke( @@ -117,11 +117,10 @@ pub fn invoke_signed( інструкцію, яка також містить цього підписанта та/або обліковий запис із правом запису. -Хоча PDA не мають -[приватних ключів](/docs/core/pda.md#what-is-a-pda), вони все одно можуть діяти -як підписант в інструкції через CPI. Щоб підтвердити, що PDA створений із -програми, що викликає, необхідно включити насіння, використане для створення -PDA, як `signers_seeds`. +Хоча PDA не мають [приватних ключів](/docs/core/pda.md#what-is-a-pda), вони все +одно можуть діяти як підписант в інструкції через CPI. Щоб підтвердити, що PDA +створений із програми, що викликає, необхідно включити насіння, використане для +створення PDA, як `signers_seeds`. Коли CPI обробляється, середовище виконання Solana [викликає внутрішньо `create_program_address`](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/bpf_loader/src/syscalls/cpi.rs#L550) diff --git a/docs/locales/uk/core/fees.md b/docs/locales/uk/core/fees.md index 69689f7d0..87f200807 100644 --- a/docs/locales/uk/core/fees.md +++ b/docs/locales/uk/core/fees.md @@ -20,91 +20,165 @@ altRoutes: - /docs/uk/core/runtime --- -Блокчейн Solana має кілька типів плати та витрат, які виникають під час використання мережі без дозволу. Вони поділяються на кілька специфічних типів: +Блокчейн Solana має кілька типів плати та витрат, які виникають під час +використання мережі без дозволу. Вони поділяються на кілька специфічних типів: - **Транзакційні збори** — плата за обробку транзакцій/інструкцій валідаторами. -- **Пріоритизаційні збори** — додаткова плата для підвищення порядку обробки транзакцій. +- **Пріоритизаційні збори** — додаткова плата для підвищення порядку обробки + транзакцій. - **Оренда** — утримуваний баланс для збереження даних в ончейні. ## Транзакційні збори -Мала плата, яка сплачується за обробку логіки (інструкції) у програмі в ончейні на блокчейні Solana, називається "_транзакційною платою_". +Мала плата, яка сплачується за обробку логіки (інструкції) у програмі в ончейні +на блокчейні Solana, називається "_транзакційною платою_". -Кожна [транзакція](/docs/uk/core/transactions.md#transaction), яка містить одну або більше [інструкцій](/docs/uk/core/transactions.md#instruction), надсилається через мережу, де її обробляє поточний лідер-валідатор. Після підтвердження як глобальної транзакції ця "транзакційна плата" сплачується мережі для підтримки економічної моделі блокчейна Solana. +Кожна [транзакція](/docs/uk/core/transactions.md#transaction), яка містить одну +або більше [інструкцій](/docs/uk/core/transactions.md#instruction), надсилається +через мережу, де її обробляє поточний лідер-валідатор. Після підтвердження як +глобальної транзакції ця "транзакційна плата" сплачується мережі для підтримки +економічної моделі блокчейна Solana. -> Транзакційні збори відрізняються від плати за збереження даних в обліковому записі, відомої як [оренда](#rent). Транзакційні збори сплачуються за обробку інструкцій у мережі Solana, а депозит оренди утримується в обліковому записі для збереження даних в блокчейні та може бути повернутий. +> Транзакційні збори відрізняються від плати за збереження даних в обліковому +> записі, відомої як [оренда](#rent). Транзакційні збори сплачуються за обробку +> інструкцій у мережі Solana, а депозит оренди утримується в обліковому записі +> для збереження даних в блокчейні та може бути повернутий. -На даний момент базова транзакційна плата в Solana встановлена на рівні 5000 лампортів за підпис. На додаток до цієї базової плати, можуть бути додані додаткові [пріоритизаційні збори](#prioritization-fee). +На даний момент базова транзакційна плата в Solana встановлена на рівні 5000 +лампортів за підпис. На додаток до цієї базової плати, можуть бути додані +додаткові [пріоритизаційні збори](#prioritization-fee). ### Навіщо сплачувати транзакційні збори? -Транзакційні збори пропонують багато переваг у економічній моделі Solana, зокрема вони: +Транзакційні збори пропонують багато переваг у економічній моделі Solana, +зокрема вони: -- Забезпечують компенсацію мережі валідаторів за витрачені ресурси CPU/GPU для обробки транзакцій. +- Забезпечують компенсацію мережі валідаторів за витрачені ресурси CPU/GPU для + обробки транзакцій. - Зменшують спам у мережі, запроваджуючи реальну вартість транзакцій. -- Забезпечують довгострокову економічну стабільність мережі через протокольно захоплену мінімальну плату за транзакцію. +- Забезпечують довгострокову економічну стабільність мережі через протокольно + захоплену мінімальну плату за транзакцію. ### Основи економічної моделі -Багато блокчейн-мереж (включаючи Bitcoin та Ethereum) покладаються на інфляційні "протокольні нагороди" для короткострокової підтримки безпеки мережі. У довгостроковій перспективі ці мережі все більше покладаються на "транзакційні збори" для підтримки безпеки. +Багато блокчейн-мереж (включаючи Bitcoin та Ethereum) покладаються на інфляційні +"протокольні нагороди" для короткострокової підтримки безпеки мережі. У +довгостроковій перспективі ці мережі все більше покладаються на "транзакційні +збори" для підтримки безпеки. Те саме стосується Solana. Зокрема: -- Фіксована частка (спочатку 50%) кожної транзакційної плати "спалюється" (знищується), решта надходить до поточного [лідера](/docs/uk/terminology.md#leader), який обробляє транзакцію. -- Запланована глобальна інфляційна ставка забезпечує джерело [нагород](https://docs.anza.xyz/implemented-proposals/staking-rewards), які розподіляються серед [валідаторів Solana](https://docs.anza.xyz/operations). +- Фіксована частка (спочатку 50%) кожної транзакційної плати "спалюється" + (знищується), решта надходить до поточного + [лідера](/docs/uk/terminology.md#leader), який обробляє транзакцію. +- Запланована глобальна інфляційна ставка забезпечує джерело + [нагород](https://docs.anza.xyz/implemented-proposals/staking-rewards), які + розподіляються серед [валідаторів Solana](https://docs.anza.xyz/operations). ### Збір плати -Транзакції повинні мати щонайменше один обліковий запис, який підписав транзакцію та може бути змінений. Ці "записувані підписуючі облікові записи" серіалізуються першими у списку облікових записів, і перший з них завжди використовується як "платник плати". +Транзакції повинні мати щонайменше один обліковий запис, який підписав +транзакцію та може бути змінений. Ці "записувані підписуючі облікові записи" +серіалізуються першими у списку облікових записів, і перший з них завжди +використовується як "платник плати". -Перед обробкою будь-яких інструкцій транзакції баланс облікового запису платника плати [вираховується](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/runtime/src/bank.rs#L4045-L4064) для оплати транзакційних зборів. Якщо баланс платника плати недостатній для покриття зборів, обробка транзакції припиняється і вона визнається невдалою. +Перед обробкою будь-яких інструкцій транзакції баланс облікового запису платника +плати +[вираховується](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/runtime/src/bank.rs#L4045-L4064) +для оплати транзакційних зборів. Якщо баланс платника плати недостатній для +покриття зборів, обробка транзакції припиняється і вона визнається невдалою. -Якщо баланс був достатнім, плата буде вирахувана, і виконання інструкцій транзакції почнеться. Якщо будь-яка з інструкцій призведе до помилки, обробка транзакції буде припинена, і зрештою вона буде записана як невдала транзакція в книзі Solana. Плата все одно буде зібрана за ці невдалі транзакції. +Якщо баланс був достатнім, плата буде вирахувана, і виконання інструкцій +транзакції почнеться. Якщо будь-яка з інструкцій призведе до помилки, обробка +транзакції буде припинена, і зрештою вона буде записана як невдала транзакція в +книзі Solana. Плата все одно буде зібрана за ці невдалі транзакції. -Якщо будь-яка з інструкцій повертає помилку або порушує обмеження часу виконання, всі зміни облікових записів **_крім_** вирахування транзакційної плати будуть скасовані. Це тому, що мережа валідаторів вже витратила обчислювальні ресурси для збору транзакцій та початку їх обробки. +Якщо будь-яка з інструкцій повертає помилку або порушує обмеження часу +виконання, всі зміни облікових записів **_крім_** вирахування транзакційної +плати будуть скасовані. Це тому, що мережа валідаторів вже витратила +обчислювальні ресурси для збору транзакцій та початку їх обробки. ### Розподіл плати -Транзакційні збори [частково спалюються](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/runtime/src/bank/fee_distribution.rs#L55-L64), а решта зборів збираються валідатором, який створив блок, у якому включені відповідні транзакції. Зокрема, [50% спалюються](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/sdk/program/src/fee_calculator.rs#L79), а [50% розподіляються](https://github.com/anza-xyz/agave/blob/e621336acad4f5d6e5b860eaa1b074b01c99253c/runtime/src/bank/fee_distribution.rs#L58-L62) валідатору, який створив блок. +Транзакційні збори +[частково спалюються](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/runtime/src/bank/fee_distribution.rs#L55-L64), +а решта зборів збираються валідатором, який створив блок, у якому включені +відповідні транзакції. Зокрема, +[50% спалюються](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/sdk/program/src/fee_calculator.rs#L79), +а +[50% розподіляються](https://github.com/anza-xyz/agave/blob/e621336acad4f5d6e5b860eaa1b074b01c99253c/runtime/src/bank/fee_distribution.rs#L58-L62) +валідатору, який створив блок. ### Чому спалюються частина зборів? -Як згадано вище, фіксована частка кожної транзакційної плати "спалюється" (знищується). Це зроблено для зміцнення економічної цінності SOL і підтримки безпеки мережі. На відміну від системи, де всі транзакційні збори повністю спалюються, лідери все ще мають стимул включати якомога більше транзакцій у свої слоти (можливість створити блок). +Як згадано вище, фіксована частка кожної транзакційної плати "спалюється" +(знищується). Це зроблено для зміцнення економічної цінності SOL і підтримки +безпеки мережі. На відміну від системи, де всі транзакційні збори повністю +спалюються, лідери все ще мають стимул включати якомога більше транзакцій у свої +слоти (можливість створити блок). -Спалені збори також можуть допомогти запобігти зловмисним валідаторам у цензуруванні транзакцій через врахування в [виборі форку](/docs/uk/terminology.md#fork). +Спалені збори також можуть допомогти запобігти зловмисним валідаторам у +цензуруванні транзакцій через врахування в +[виборі форку](/docs/uk/terminology.md#fork). #### Приклад атаки: -У випадку [форку Proof of History (PoH)](/docs/uk/terminology.md#proof-of-history-poh) з лідером, що займається цензурою або зловживанням: +У випадку +[форку Proof of History (PoH)](/docs/uk/terminology.md#proof-of-history-poh) з +лідером, що займається цензурою або зловживанням: -- через втрати зборів, що виникають через цензуру, очікується, що загальні збори, які будуть спалені, будуть **_меншими_**, ніж у порівнянному чесному форку; -- якщо лідер, який займається цензурою, хоче компенсувати ці втрачені протокольні збори, він повинен буде самостійно замінити спалені збори на своєму форку; +- через втрати зборів, що виникають через цензуру, очікується, що загальні + збори, які будуть спалені, будуть **_меншими_**, ніж у порівнянному чесному + форку; +- якщо лідер, який займається цензурою, хоче компенсувати ці втрачені + протокольні збори, він повинен буде самостійно замінити спалені збори на + своєму форку; - таким чином, потенційно зменшуючи стимул до цензури в першу чергу. ### Обчислення транзакційних зборів -Повна плата за конкретну транзакцію розраховується на основі двох основних частин: +Повна плата за конкретну транзакцію розраховується на основі двох основних +частин: - Статично встановлена базова плата за підпис, і -- Обчислювальні ресурси, використані під час транзакції, виміряні у "[обчислювальних одиницях](/docs/uk/terminology.md#compute-units)". +- Обчислювальні ресурси, використані під час транзакції, виміряні у + "[обчислювальних одиницях](/docs/uk/terminology.md#compute-units)". -Оскільки кожна транзакція може вимагати різної кількості обчислювальних ресурсів, кожній транзакції виділяється максимальна кількість _обчислювальних одиниць_ у рамках "обчислювального бюджету". +Оскільки кожна транзакція може вимагати різної кількості обчислювальних +ресурсів, кожній транзакції виділяється максимальна кількість _обчислювальних +одиниць_ у рамках "обчислювального бюджету". ## Обчислювальний бюджет -Щоб запобігти зловживанню обчислювальними ресурсами, кожній транзакції виділяється "обчислювальний бюджет". Цей бюджет визначає: +Щоб запобігти зловживанню обчислювальними ресурсами, кожній транзакції +виділяється "обчислювальний бюджет". Цей бюджет визначає: -- обчислювальні витрати, пов'язані з різними типами операцій, які може виконувати транзакція (обчислювальні одиниці, спожиті на операцію), -- максимальну кількість обчислювальних одиниць, які може спожити транзакція (ліміт обчислювальних одиниць), -- та операційні межі, яких має дотримуватися транзакція (наприклад, ліміти розміру даних облікового запису). +- обчислювальні витрати, пов'язані з різними типами операцій, які може + виконувати транзакція (обчислювальні одиниці, спожиті на операцію), +- максимальну кількість обчислювальних одиниць, які може спожити транзакція + (ліміт обчислювальних одиниць), +- та операційні межі, яких має дотримуватися транзакція (наприклад, ліміти + розміру даних облікового запису). -Коли транзакція вичерпує свій обчислювальний бюджет (вичерпання обчислювального бюджету) або перевищує межі, наприклад, намагається перевищити [максимальну глибину стеку викликів](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget.rs#L138) або [максимальний розмір завантажених даних облікового запису](#accounts-data-size-limit), виконання транзакції припиняється, і повертається помилка. Це призводить до невдалої транзакції та жодних змін стану (окрім збору плати за транзакцію). +Коли транзакція вичерпує свій обчислювальний бюджет (вичерпання обчислювального +бюджету) або перевищує межі, наприклад, намагається перевищити +[максимальну глибину стеку викликів](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget.rs#L138) +або +[максимальний розмір завантажених даних облікового запису](#accounts-data-size-limit), +виконання транзакції припиняється, і повертається помилка. Це призводить до +невдалої транзакції та жодних змін стану (окрім збору плати за транзакцію). ### Ліміт розміру даних облікового запису -Транзакція може встановлювати максимальну кількість байтів даних облікового запису, які їй дозволено завантажувати, включивши інструкцію `SetLoadedAccountsDataSizeLimit` (не перевищуючи абсолютний максимум часу виконання). Якщо `SetLoadedAccountsDataSizeLimit` не надано, транзакція за замовчуванням використовує значення часу виконання [`MAX_LOADED_ACCOUNTS_DATA_SIZE_BYTES`](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget_processor.rs#L137-L139). +Транзакція може встановлювати максимальну кількість байтів даних облікового +запису, які їй дозволено завантажувати, включивши інструкцію +`SetLoadedAccountsDataSizeLimit` (не перевищуючи абсолютний максимум часу +виконання). Якщо `SetLoadedAccountsDataSizeLimit` не надано, транзакція за +замовчуванням використовує значення часу виконання +[`MAX_LOADED_ACCOUNTS_DATA_SIZE_BYTES`](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget_processor.rs#L137-L139). -Функцію `ComputeBudgetInstruction::set_loaded_accounts_data_size_limit` можна використовувати для створення цієї інструкції. +Функцію `ComputeBudgetInstruction::set_loaded_accounts_data_size_limit` можна +використовувати для створення цієї інструкції. ```rust let instruction = ComputeBudgetInstruction::set_loaded_accounts_data_size_limit(100_000); @@ -112,13 +186,28 @@ let instruction = ComputeBudgetInstruction::set_loaded_accounts_data_size_limit( ### Обчислювальні одиниці -Усі операції, виконані ончейн у рамках транзакції, вимагають різного обсягу обчислювальних ресурсів, які витрачаються валідаторами під час обробки (обчислювальна вартість). Найменшою одиницею виміру цих ресурсів є _"обчислювальна одиниця"_. - -Під час обробки транзакції обчислювальні одиниці поступово споживаються кожною з її інструкцій, виконуваних ончейн (вичерпуючи бюджет). Оскільки кожна інструкція виконує різну логіку (запис у облікові записи, CPI, виконання системних викликів тощо), кожна може споживати [різну кількість](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget.rs#L133-L178) обчислювальних одиниць. - -> Програма може записувати деталі про використання своїх обчислювальних ресурсів, включаючи залишок у виділеному обчислювальному бюджеті. Більше інформації ви можете знайти в цьому посібнику з [оптимізації використання обчислювальних ресурсів](/content/guides/advanced/how-to-optimize-compute.md). - -Кожній транзакції виділяється [ліміт обчислювальних одиниць](#compute-unit-limit), або за замовчуванням встановлений часом виконання, або шляхом явного запиту на вищий ліміт. Якщо транзакція перевищує свій ліміт обчислювальних одиниць, її обробка зупиняється, що призводить до невдалої транзакції. +Усі операції, виконані ончейн у рамках транзакції, вимагають різного обсягу +обчислювальних ресурсів, які витрачаються валідаторами під час обробки +(обчислювальна вартість). Найменшою одиницею виміру цих ресурсів є +_"обчислювальна одиниця"_. + +Під час обробки транзакції обчислювальні одиниці поступово споживаються кожною з +її інструкцій, виконуваних ончейн (вичерпуючи бюджет). Оскільки кожна інструкція +виконує різну логіку (запис у облікові записи, CPI, виконання системних викликів +тощо), кожна може споживати +[різну кількість](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget.rs#L133-L178) +обчислювальних одиниць. + +> Програма може записувати деталі про використання своїх обчислювальних +> ресурсів, включаючи залишок у виділеному обчислювальному бюджеті. Більше +> інформації ви можете знайти в цьому посібнику з +> [оптимізації використання обчислювальних ресурсів](/content/guides/advanced/how-to-optimize-compute.md). + +Кожній транзакції виділяється +[ліміт обчислювальних одиниць](#compute-unit-limit), або за замовчуванням +встановлений часом виконання, або шляхом явного запиту на вищий ліміт. Якщо +транзакція перевищує свій ліміт обчислювальних одиниць, її обробка зупиняється, +що призводить до невдалої транзакції. Нижче наведено кілька поширених операцій, які мають обчислювальну вартість: @@ -132,60 +221,116 @@ let instruction = ComputeBudgetInstruction::set_loaded_accounts_data_size_limit( - міжпрограмні виклики (CPI) - криптографічні операції -> Для [міжпрограмних викликів](/docs/uk/core/cpi.md) викликана інструкція успадковує обчислювальний бюджет і ліміти свого батька. Якщо викликана інструкція споживає залишок бюджету транзакції або перевищує ліміт, весь ланцюжок викликів і обробка транзакції верхнього рівня зупиняються. +> Для [міжпрограмних викликів](/docs/uk/core/cpi.md) викликана інструкція +> успадковує обчислювальний бюджет і ліміти свого батька. Якщо викликана +> інструкція споживає залишок бюджету транзакції або перевищує ліміт, весь +> ланцюжок викликів і обробка транзакції верхнього рівня зупиняються. -Детальнішу інформацію про всі операції, які споживають обчислювальні одиниці, ви можете знайти в [ComputeBudget](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget.rs#L19-L123) в часі виконання Solana. +Детальнішу інформацію про всі операції, які споживають обчислювальні одиниці, ви +можете знайти в +[ComputeBudget](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget.rs#L19-L123) +в часі виконання Solana. ### Ліміт обчислювальних одиниць -Кожна транзакція має максимальну кількість обчислювальних одиниць (CU), які вона може спожити, що називається _"лімітом обчислювальних одиниць"_. У часі виконання Solana встановлено абсолютний максимальний ліміт [1,4 мільйона CU](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget_processor.rs#L19) на транзакцію та за замовчуванням [200 тисяч CU на інструкцію](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget_processor.rs#L18). - -Транзакція може запитувати більш конкретний і оптимальний ліміт обчислювальних одиниць, включивши одну інструкцію `SetComputeUnitLimit`. Це може бути як вищий, так і нижчий ліміт. Але він ніколи не може перевищувати абсолютний максимальний ліміт на транзакцію. - -Хоча ліміт обчислювальних одиниць за замовчуванням підходить для простих транзакцій, він часто є менш оптимальним (як для часу виконання, так і для користувача). Для складніших транзакцій, наприклад, виклику програм, що виконують декілька CPI, може знадобитися запит вищого ліміту обчислювальних одиниць для транзакції. - -Запит оптимальних лімітів обчислювальних одиниць для вашої транзакції є важливим для зменшення витрат на транзакцію та кращого планування вашої транзакції в мережі. Гаманці, dApps та інші сервіси повинні переконатися, що їхні запити на обчислювальні одиниці є оптимальними, щоб забезпечити найкращий досвід для своїх користувачів. - -> Для отримання додаткової інформації та найкращих практик прочитайте цей посібник про [запит оптимальних лімітів обчислювальних ресурсів](/content/guides/advanced/how-to-request-optimal-compute.md). +Кожна транзакція має максимальну кількість обчислювальних одиниць (CU), які вона +може спожити, що називається _"лімітом обчислювальних одиниць"_. У часі +виконання Solana встановлено абсолютний максимальний ліміт +[1,4 мільйона CU](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget_processor.rs#L19) +на транзакцію та за замовчуванням +[200 тисяч CU на інструкцію](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget_processor.rs#L18). + +Транзакція може запитувати більш конкретний і оптимальний ліміт обчислювальних +одиниць, включивши одну інструкцію `SetComputeUnitLimit`. Це може бути як вищий, +так і нижчий ліміт. Але він ніколи не може перевищувати абсолютний максимальний +ліміт на транзакцію. + +Хоча ліміт обчислювальних одиниць за замовчуванням підходить для простих +транзакцій, він часто є менш оптимальним (як для часу виконання, так і для +користувача). Для складніших транзакцій, наприклад, виклику програм, що +виконують декілька CPI, може знадобитися запит вищого ліміту обчислювальних +одиниць для транзакції. + +Запит оптимальних лімітів обчислювальних одиниць для вашої транзакції є важливим +для зменшення витрат на транзакцію та кращого планування вашої транзакції в +мережі. Гаманці, dApps та інші сервіси повинні переконатися, що їхні запити на +обчислювальні одиниці є оптимальними, щоб забезпечити найкращий досвід для своїх +користувачів. + +> Для отримання додаткової інформації та найкращих практик прочитайте цей +> посібник про +> [запит оптимальних лімітів обчислювальних ресурсів](/content/guides/advanced/how-to-request-optimal-compute.md). ### Ціна обчислювальної одиниці -Якщо транзакція бажає сплатити вищу плату, щоб підвищити пріоритетність її обробки, вона може встановити _"ціну обчислювальної одиниці"_. Ця ціна, у поєднанні з [лімітом обчислювальних одиниць](#compute-unit-limit), буде використовуватися для визначення плати за пріоритизацію транзакції. +Якщо транзакція бажає сплатити вищу плату, щоб підвищити пріоритетність її +обробки, вона може встановити _"ціну обчислювальної одиниці"_. Ця ціна, у +поєднанні з [лімітом обчислювальних одиниць](#compute-unit-limit), буде +використовуватися для визначення плати за пріоритизацію транзакції. -За замовчуванням [ціна обчислювальної одиниці не встановлена](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget_processor.rs#L38), що призводить до відсутності додаткової плати за пріоритизацію. +За замовчуванням +[ціна обчислювальної одиниці не встановлена](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget_processor.rs#L38), +що призводить до відсутності додаткової плати за пріоритизацію. ## Пріоритизаційні збори -Як частина [Compute Budget](#compute-budget), час виконання підтримує транзакції, що сплачують **опціональну** плату, відому як _"плата за пріоритизацію"_. Сплата цієї додаткової плати допомагає підвищити пріоритетність транзакції у порівнянні з іншими під час обробки, що призводить до швидшого виконання. +Як частина [Compute Budget](#compute-budget), час виконання підтримує +транзакції, що сплачують **опціональну** плату, відому як _"плата за +пріоритизацію"_. Сплата цієї додаткової плати допомагає підвищити пріоритетність +транзакції у порівнянні з іншими під час обробки, що призводить до швидшого +виконання. ### Як розраховується плата за пріоритизацію -Плата за пріоритизацію транзакції розраховується шляхом множення її **_ліміту обчислювальних одиниць_** на **_ціну обчислювальної одиниці_** (вимірюється в _мікролампортах_). Ці значення можна встановити один раз на транзакцію, включивши такі інструкції Compute Budget: +Плата за пріоритизацію транзакції розраховується шляхом множення її **_ліміту +обчислювальних одиниць_** на **_ціну обчислювальної одиниці_** (вимірюється в +_мікролампортах_). Ці значення можна встановити один раз на транзакцію, +включивши такі інструкції Compute Budget: -- [`SetComputeUnitLimit`](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/sdk/src/compute_budget.rs#L47-L50) — встановлення максимальної кількості обчислювальних одиниць, які може спожити транзакція. -- [`SetComputeUnitPrice`](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/sdk/src/compute_budget.rs#L52-L55) — встановлення бажаної додаткової плати, яку транзакція готова сплатити для підвищення пріоритетності. +- [`SetComputeUnitLimit`](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/sdk/src/compute_budget.rs#L47-L50) + — встановлення максимальної кількості обчислювальних одиниць, які може спожити + транзакція. +- [`SetComputeUnitPrice`](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/sdk/src/compute_budget.rs#L52-L55) + — встановлення бажаної додаткової плати, яку транзакція готова сплатити для + підвищення пріоритетності. -Якщо інструкція `SetComputeUnitLimit` не надана, буде використовуватися [ліміт обчислювальних одиниць за замовчуванням](#compute-unit-limit). +Якщо інструкція `SetComputeUnitLimit` не надана, буде використовуватися +[ліміт обчислювальних одиниць за замовчуванням](#compute-unit-limit). -Якщо інструкція `SetComputeUnitPrice` не надана, транзакція за замовчуванням матиме найнижчий пріоритет (тобто відсутність пріоритизаційної плати). +Якщо інструкція `SetComputeUnitPrice` не надана, транзакція за замовчуванням +матиме найнижчий пріоритет (тобто відсутність пріоритизаційної плати). ### Як встановити плату за пріоритизацію -Плата за пріоритизацію транзакції встановлюється шляхом включення інструкції `SetComputeUnitPrice` та, за бажанням, інструкції `SetComputeUnitLimit`. Час виконання використовуватиме ці значення для розрахунку плати за пріоритизацію, яка буде використовуватися для пріоритизації даної транзакції у блоці. +Плата за пріоритизацію транзакції встановлюється шляхом включення інструкції +`SetComputeUnitPrice` та, за бажанням, інструкції `SetComputeUnitLimit`. Час +виконання використовуватиме ці значення для розрахунку плати за пріоритизацію, +яка буде використовуватися для пріоритизації даної транзакції у блоці. -Ви можете створити кожну з цих інструкцій за допомогою функцій Rust або `@solana/web3.js`. Потім кожну інструкцію можна включити в транзакцію та надіслати до кластера як звичайно. Дивіться також [найкращі практики](#prioritization-fee-best-practices) нижче. +Ви можете створити кожну з цих інструкцій за допомогою функцій Rust або +`@solana/web3.js`. Потім кожну інструкцію можна включити в транзакцію та +надіслати до кластера як звичайно. Дивіться також +[найкращі практики](#prioritization-fee-best-practices) нижче. -На відміну від інших інструкцій усередині транзакції Solana, інструкції Compute Budget **НЕ** вимагають жодних облікових записів. Транзакція з кількома інструкціями одного типу завершиться невдачею. +На відміну від інших інструкцій усередині транзакції Solana, інструкції Compute +Budget **НЕ** вимагають жодних облікових записів. Транзакція з кількома +інструкціями одного типу завершиться невдачею. -Транзакції можуть містити лише **одну інструкцію кожного типу** інструкцій обчислювального бюджету. Дублікати інструкцій призведуть до помилки [`TransactionError::DuplicateInstruction`](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/sdk/src/transaction/error.rs#L143-L145) і, зрештою, до невдачі транзакції. +Транзакції можуть містити лише **одну інструкцію кожного типу** інструкцій +обчислювального бюджету. Дублікати інструкцій призведуть до помилки +[`TransactionError::DuplicateInstruction`](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/sdk/src/transaction/error.rs#L143-L145) +і, зрештою, до невдачі транзакції. #### Rust -Бібліотека `solana-sdk` включає функції в рамках [`ComputeBudgetInstruction`](https://docs.rs/solana-sdk/latest/solana_sdk/compute_budget/enum.ComputeBudgetInstruction.html) для створення інструкцій для встановлення _ліміту обчислювальних одиниць_ та _ціни обчислювальної одиниці_. +Бібліотека `solana-sdk` включає функції в рамках +[`ComputeBudgetInstruction`](https://docs.rs/solana-sdk/latest/solana_sdk/compute_budget/enum.ComputeBudgetInstruction.html) +для створення інструкцій для встановлення _ліміту обчислювальних одиниць_ та +_ціни обчислювальної одиниці_. ```rust let instruction = ComputeBudgetInstruction::set_compute_unit_limit(300_000); @@ -194,9 +339,13 @@ let instruction = ComputeBudgetInstruction::set_compute_unit_limit(300_000); ```rust let instruction = ComputeBudgetInstruction::set_compute_unit_price(1); ``` + #### Javascript -Бібліотека `@solana/web3.js` включає функції в класі [`ComputeBudgetProgram`](https://solana-labs.github.io/solana-web3.js/v1.x/classes/ComputeBudgetProgram.html) для створення інструкцій для встановлення _ліміту обчислювальних одиниць_ та _ціни обчислювальної одиниці_. +Бібліотека `@solana/web3.js` включає функції в класі +[`ComputeBudgetProgram`](https://solana-labs.github.io/solana-web3.js/v1.x/classes/ComputeBudgetProgram.html) +для створення інструкцій для встановлення _ліміту обчислювальних одиниць_ та +_ціни обчислювальної одиниці_. ```js const instruction = ComputeBudgetProgram.setComputeUnitLimit({ @@ -212,54 +361,109 @@ const instruction = ComputeBudgetProgram.setComputeUnitPrice({ ### Найкращі практики для плати за пріоритизацію -Нижче наведено загальну інформацію про найкращі практики для пріоритизаційних зборів. Більш детальну інформацію можна знайти в цьому посібнику про [запит оптимального використання обчислювальних ресурсів](/content/guides/advanced/how-to-request-optimal-compute.md), включаючи симуляцію транзакції для визначення її приблизного використання обчислювальних ресурсів. +Нижче наведено загальну інформацію про найкращі практики для пріоритизаційних +зборів. Більш детальну інформацію можна знайти в цьому посібнику про +[запит оптимального використання обчислювальних ресурсів](/content/guides/advanced/how-to-request-optimal-compute.md), +включаючи симуляцію транзакції для визначення її приблизного використання +обчислювальних ресурсів. #### Запитуйте мінімальну кількість обчислювальних одиниць -Транзакції повинні запитувати мінімальну кількість обчислювальних одиниць, необхідну для виконання, щоб мінімізувати збори. Також зауважте, що збори не коригуються, якщо кількість запитаних обчислювальних одиниць перевищує фактично спожиту кількість у виконаній транзакції. +Транзакції повинні запитувати мінімальну кількість обчислювальних одиниць, +необхідну для виконання, щоб мінімізувати збори. Також зауважте, що збори не +коригуються, якщо кількість запитаних обчислювальних одиниць перевищує фактично +спожиту кількість у виконаній транзакції. #### Отримуйте останні пріоритизаційні збори -Перед надсиланням транзакції до кластеру ви можете скористатися методом RPC [`getRecentPrioritizationFees`](/docs/uk/rpc/http/getRecentPrioritizationFees.mdx), щоб отримати список останніх сплачених пріоритизаційних зборів у нещодавно оброблених блоках вузла. +Перед надсиланням транзакції до кластеру ви можете скористатися методом RPC +[`getRecentPrioritizationFees`](/docs/uk/rpc/http/getRecentPrioritizationFees.mdx), +щоб отримати список останніх сплачених пріоритизаційних зборів у нещодавно +оброблених блоках вузла. -Ви можете використовувати ці дані для оцінки відповідної плати за пріоритизацію для вашої транзакції, щоб: +Ви можете використовувати ці дані для оцінки відповідної плати за пріоритизацію +для вашої транзакції, щоб: -(a) підвищити ймовірність її обробки кластером та -(b) мінімізувати сплачені збори. +(a) підвищити ймовірність її обробки кластером та (b) мінімізувати сплачені +збори. ## Оренда -Плата, що депонується на кожен [Обліковий запис Solana](/docs/uk/core/accounts.md) для збереження його пов'язаних даних в ончейні, називається "_орендою_". Ця плата утримується у звичайному балансі лампортів на кожному обліковому записі та може бути повернута під час закриття облікового запису. - -> Оренда відрізняється від [транзакційних зборів](#transaction-fees). Оренда "сплачується" (утримується в Обліковому записі) для збереження даних на блокчейні Solana та може бути повернута. У той час як транзакційні збори сплачуються за обробку [інструкцій](/docs/uk/core/transactions.md#instructions) у мережі. - -Усі облікові записи повинні підтримувати достатньо високий баланс лампортів (відносно їх виділеного простору), щоб стати [звільненими від оренди](#rent-exempt) і залишатися на блокчейні Solana. Будь-яка транзакція, що намагається зменшити баланс облікового запису нижче його відповідного мінімального балансу для звільнення від оренди, завершиться невдачею (якщо тільки баланс не зменшується до нуля). - -Коли власник облікового запису більше не бажає зберігати ці дані в ончейні та доступними в глобальному стані, він може закрити обліковий запис і повернути орендний депозит. - -Це здійснюється шляхом виведення (переказу) усього балансу лампортів облікового запису на інший обліковий запис (наприклад, ваш гаманець). Зменшивши баланс облікового запису до рівно `0`, час виконання видалить обліковий запис і його пов'язані дані з мережі в процесі _"[збирання сміття](#garbage-collection)"_. +Плата, що депонується на кожен +[Обліковий запис Solana](/docs/uk/core/accounts.md) для збереження його +пов'язаних даних в ончейні, називається "_орендою_". Ця плата утримується у +звичайному балансі лампортів на кожному обліковому записі та може бути повернута +під час закриття облікового запису. + +> Оренда відрізняється від [транзакційних зборів](#transaction-fees). Оренда +> "сплачується" (утримується в Обліковому записі) для збереження даних на +> блокчейні Solana та може бути повернута. У той час як транзакційні збори +> сплачуються за обробку +> [інструкцій](/docs/uk/core/transactions.md#instructions) у мережі. + +Усі облікові записи повинні підтримувати достатньо високий баланс лампортів +(відносно їх виділеного простору), щоб стати +[звільненими від оренди](#rent-exempt) і залишатися на блокчейні Solana. +Будь-яка транзакція, що намагається зменшити баланс облікового запису нижче його +відповідного мінімального балансу для звільнення від оренди, завершиться +невдачею (якщо тільки баланс не зменшується до нуля). + +Коли власник облікового запису більше не бажає зберігати ці дані в ончейні та +доступними в глобальному стані, він може закрити обліковий запис і повернути +орендний депозит. + +Це здійснюється шляхом виведення (переказу) усього балансу лампортів облікового +запису на інший обліковий запис (наприклад, ваш гаманець). Зменшивши баланс +облікового запису до рівно `0`, час виконання видалить обліковий запис і його +пов'язані дані з мережі в процесі _"[збирання сміття](#garbage-collection)"_. ### Ставка оренди -Ставка оренди Solana встановлюється на рівні всієї мережі, головним чином базуючись на часі виконання -"[лампорти _за_ байт _за_ рік](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/sdk/program/src/rent.rs#L27-L34)". Наразі ставка оренди є статичною величиною та зберігається в +Ставка оренди Solana встановлюється на рівні всієї мережі, головним чином +базуючись на часі виконання +"[лампорти _за_ байт _за_ рік](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/sdk/program/src/rent.rs#L27-L34)". +Наразі ставка оренди є статичною величиною та зберігається в [системній змінній Rent](https://docs.anza.xyz/runtime/sysvars#rent). -Ця ставка оренди використовується для розрахунку точної суми оренди, яка повинна бути утримана в обліковому записі для виділеного простору облікового запису (тобто кількість даних, які можуть бути збережені в обліковому записі). Чим більше простору виділяє обліковий запис, тим вищим буде утриманий орендний депозит. +Ця ставка оренди використовується для розрахунку точної суми оренди, яка повинна +бути утримана в обліковому записі для виділеного простору облікового запису +(тобто кількість даних, які можуть бути збережені в обліковому записі). Чим +більше простору виділяє обліковий запис, тим вищим буде утриманий орендний +депозит. ### Звільнення від оренди -Облікові записи повинні підтримувати баланс лампортів, що перевищує мінімум, необхідний для зберігання відповідних даних в ончейні. Це називається "_звільненням від оренди_", а цей баланс називається "_мінімальним балансом для звільнення від оренди_". - -> Нові облікові записи (та програми) на Solana **ЗОБОВ'ЯЗАНІ** бути ініціалізовані з достатньою кількістю лампортів, щоб стати _звільненими від оренди_. Так було не завжди. Раніше час виконання періодично та автоматично стягував плату з кожного облікового запису, що мав баланс нижче мінімуму для звільнення від оренди. Зрештою, такі облікові записи знижувалися до нульового балансу та видалялися з глобального стану (якщо їх не поповнювали вручну). - -У процесі створення нового облікового запису необхідно переконатися, що ви депонуєте достатньо лампортів, щоб перевищити цей мінімальний баланс. Все, що нижче цього мінімального порогу, призведе до невдачі транзакції. - -Кожного разу, коли баланс облікового запису зменшується, час виконання перевіряє, чи залишиться баланс цього облікового запису вище мінімального балансу для звільнення від оренди. Якщо тільки баланс не знижується до рівно `0` (закриття облікового запису), транзакції, які спричиняють падіння балансу облікового запису нижче порогу звільнення від оренди, завершаться невдачею. - -Специфічний мінімальний баланс для облікового запису, щоб стати звільненим від оренди, залежить від поточної [ставки оренди](#rent-rate) блокчейну та бажаного обсягу простору, який обліковий запис хоче виділити (розмір облікового запису). Тому рекомендується використовувати RPC-метод [`getMinimumBalanceForRentExemption`](/docs/uk/rpc/http/getMinimumBalanceForRentExemption.mdx) для розрахунку конкретного балансу для заданого розміру облікового запису. - -Суму необхідного орендного депозиту також можна оцінити за допомогою підкоманди CLI [`solana rent`](https://docs.anza.xyz/cli/usage#solana-rent). +Облікові записи повинні підтримувати баланс лампортів, що перевищує мінімум, +необхідний для зберігання відповідних даних в ончейні. Це називається +"_звільненням від оренди_", а цей баланс називається "_мінімальним балансом для +звільнення від оренди_". + +> Нові облікові записи (та програми) на Solana **ЗОБОВ'ЯЗАНІ** бути +> ініціалізовані з достатньою кількістю лампортів, щоб стати _звільненими від +> оренди_. Так було не завжди. Раніше час виконання періодично та автоматично +> стягував плату з кожного облікового запису, що мав баланс нижче мінімуму для +> звільнення від оренди. Зрештою, такі облікові записи знижувалися до нульового +> балансу та видалялися з глобального стану (якщо їх не поповнювали вручну). + +У процесі створення нового облікового запису необхідно переконатися, що ви +депонуєте достатньо лампортів, щоб перевищити цей мінімальний баланс. Все, що +нижче цього мінімального порогу, призведе до невдачі транзакції. + +Кожного разу, коли баланс облікового запису зменшується, час виконання +перевіряє, чи залишиться баланс цього облікового запису вище мінімального +балансу для звільнення від оренди. Якщо тільки баланс не знижується до рівно `0` +(закриття облікового запису), транзакції, які спричиняють падіння балансу +облікового запису нижче порогу звільнення від оренди, завершаться невдачею. + +Специфічний мінімальний баланс для облікового запису, щоб стати звільненим від +оренди, залежить від поточної [ставки оренди](#rent-rate) блокчейну та бажаного +обсягу простору, який обліковий запис хоче виділити (розмір облікового запису). +Тому рекомендується використовувати RPC-метод +[`getMinimumBalanceForRentExemption`](/docs/uk/rpc/http/getMinimumBalanceForRentExemption.mdx) +для розрахунку конкретного балансу для заданого розміру облікового запису. + +Суму необхідного орендного депозиту також можна оцінити за допомогою підкоманди +CLI [`solana rent`](https://docs.anza.xyz/cli/usage#solana-rent). ```shell solana rent 15000 @@ -269,16 +473,29 @@ Rent per byte-year: 0.00000348 SOL Rent per epoch: 0.000288276 SOL Rent-exempt minimum: 0.10529088 SOL ``` + ### Збирання сміття -Облікові записи, які не підтримують баланс лампортів більше нуля, видаляються з мережі в процесі, відомому як _збирання сміття_. Цей процес виконується, щоб зменшити загальну кількість збережених у мережі даних, які більше не використовуються або не підтримуються. +Облікові записи, які не підтримують баланс лампортів більше нуля, видаляються з +мережі в процесі, відомому як _збирання сміття_. Цей процес виконується, щоб +зменшити загальну кількість збережених у мережі даних, які більше не +використовуються або не підтримуються. -Після успішного зменшення балансу облікового запису до рівно `0` транзакцією, збирання сміття виконується автоматично часом виконання. Будь-яка транзакція, яка намагається зменшити баланс облікового запису нижче його мінімального балансу для звільнення від оренди (що не дорівнює нулю), завершиться невдачею. +Після успішного зменшення балансу облікового запису до рівно `0` транзакцією, +збирання сміття виконується автоматично часом виконання. Будь-яка транзакція, +яка намагається зменшити баланс облікового запису нижче його мінімального +балансу для звільнення від оренди (що не дорівнює нулю), завершиться невдачею. Важливо зазначити, що збирання сміття відбувається **після** завершення виконання транзакції. Якщо є інструкція "закрити" обліковий запис, зменшивши баланс облікового запису до нуля, обліковий запис може бути "повторно відкритий" у тій самій транзакції за допомогою наступної інструкції. Якщо стан облікового запису не було очищено в інструкції "закрити", наступна інструкція "повторного відкриття" матиме той самий стан облікового запису. Це є проблемою безпеки, тому важливо знати точний момент, коли збирання сміття набирає чинності. -Навіть після того, як обліковий запис було видалено з мережі (через збирання сміття), він все ще може мати транзакції, пов'язані з його адресою (або в історії, або в майбутньому). Незважаючи на те, що блокчейн-експлорер Solana може відображати повідомлення типу "обліковий запис не знайдено", ви все одно можете переглядати історію транзакцій, пов'язаних із цим обліковим записом. +Навіть після того, як обліковий запис було видалено з мережі (через збирання +сміття), він все ще може мати транзакції, пов'язані з його адресою (або в +історії, або в майбутньому). Незважаючи на те, що блокчейн-експлорер Solana може +відображати повідомлення типу "обліковий запис не знайдено", ви все одно можете +переглядати історію транзакцій, пов'язаних із цим обліковим записом. -Ви можете прочитати [запропоновану реалізацію](https://docs.anza.xyz/implemented-proposals/persistent-account-storage#garbage-collection) для збирання сміття, щоб дізнатися більше. \ No newline at end of file +Ви можете прочитати +[запропоновану реалізацію](https://docs.anza.xyz/implemented-proposals/persistent-account-storage#garbage-collection) +для збирання сміття, щоб дізнатися більше. diff --git a/docs/locales/uk/core/index.md b/docs/locales/uk/core/index.md index b084e320e..8743b8699 100644 --- a/docs/locales/uk/core/index.md +++ b/docs/locales/uk/core/index.md @@ -2,78 +2,116 @@ title: Основні концепції sidebarSortOrder: 2 description: - Дізнайтеся про основні концепції блокчейну Solana, включаючи облікові записи, транзакції, програми, адреси, отримані від програм, міжпрограмні виклики та як працюють токени на Solana. + Дізнайтеся про основні концепції блокчейну Solana, включаючи облікові записи, + транзакції, програми, адреси, отримані від програм, міжпрограмні виклики та як + працюють токени на Solana. --- -Розвивайте глибоке розуміння основних концепцій, які роблять Solana унікальним серед інших блокчейнів. Розуміння "моделі програмування Solana" через ці ключові концепції дуже важливе для максимального успіху як розробника блокчейну Solana. +Розвивайте глибоке розуміння основних концепцій, які роблять Solana унікальним +серед інших блокчейнів. Розуміння "моделі програмування Solana" через ці ключові +концепції дуже важливе для максимального успіху як розробника блокчейну Solana. ## Модель облікових записів Solana -У Solana всі дані зберігаються в тому, що називається "обліковими записами". Організація даних у блокчейні Solana нагадує [сховище ключів і значень](https://uk.wikipedia.org/wiki/Key%E2%80%93value_%D0%B1%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%B8%D1%85), де кожен запис у базі даних називається "обліковим записом". +У Solana всі дані зберігаються в тому, що називається "обліковими записами". +Організація даних у блокчейні Solana нагадує +[сховище ключів і значень](https://uk.wikipedia.org/wiki/Key%E2%80%93value_%D0%B1%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%B8%D1%85), +де кожен запис у базі даних називається "обліковим записом". Дізнайтеся більше про [Облікові записи](/docs/core/accounts.md) тут. ## Транзакції та інструкції -У Solana ми надсилаємо [транзакції](/docs/core/transactions#transaction), щоб взаємодіяти з мережею. Транзакції включають одну або більше [інструкцій](/docs/core/transactions#instruction), кожна з яких представляє конкретну операцію для обробки. Логіка виконання інструкцій зберігається в [програмах](/docs/core/programs), розгорнутих у мережі Solana, де кожна програма має свій власний набір інструкцій. +У Solana ми надсилаємо [транзакції](/docs/core/transactions#transaction), щоб +взаємодіяти з мережею. Транзакції включають одну або більше +[інструкцій](/docs/core/transactions#instruction), кожна з яких представляє +конкретну операцію для обробки. Логіка виконання інструкцій зберігається в +[програмах](/docs/core/programs), розгорнутих у мережі Solana, де кожна програма +має свій власний набір інструкцій. -Дізнайтеся більше про [Транзакції](/docs/core/transactions.md) та [Інструкції](/docs/core/transactions.md#instruction) тут. +Дізнайтеся більше про [Транзакції](/docs/core/transactions.md) та +[Інструкції](/docs/core/transactions.md#instruction) тут. ## Плата на Solana -Блокчейн Solana має кілька типів зборів та витрат, які виникають при використанні мережі без дозволу. Вони поділяються на кілька основних типів: +Блокчейн Solana має кілька типів зборів та витрат, які виникають при +використанні мережі без дозволу. Вони поділяються на кілька основних типів: -- [Транзакційні збори](/docs/core/fees.md#transaction-fees) — плата за обробку транзакцій/інструкцій валідаторами. -- [Пріоритизаційні збори](/docs/core/fees.md#prioritization-fees) — опціональна плата для підвищення порядку обробки транзакцій. -- [Оренда](/docs/core/fees.md#rent) — утримуваний баланс для збереження даних в ончейні. +- [Транзакційні збори](/docs/core/fees.md#transaction-fees) — плата за обробку + транзакцій/інструкцій валідаторами. +- [Пріоритизаційні збори](/docs/core/fees.md#prioritization-fees) — опціональна + плата для підвищення порядку обробки транзакцій. +- [Оренда](/docs/core/fees.md#rent) — утримуваний баланс для збереження даних в + ончейні. Дізнайтеся більше про [Плату на Solana](/docs/core/fees.md) тут. ## Програми на Solana -У екосистемі Solana "смарт-контракти" називаються програмами. Кожна програма є ончейн-обліковим записом, що зберігає виконувану логіку, організовану у функції, що називаються _інструкціями_, і викликаються через функції обробників інструкцій у відповідній розгорнутій програмі. +У екосистемі Solana "смарт-контракти" називаються програмами. Кожна програма є +ончейн-обліковим записом, що зберігає виконувану логіку, організовану у функції, +що називаються _інструкціями_, і викликаються через функції обробників +інструкцій у відповідній розгорнутій програмі. Дізнайтеся більше про [Програми на Solana](/docs/core/programs.md) тут. ## Адреси, отримані від програм -Адреси, отримані від програм (Program Derived Addresses, PDAs), надають розробникам Solana дві основні можливості: +Адреси, отримані від програм (Program Derived Addresses, PDAs), надають +розробникам Solana дві основні можливості: -- **Детерміновані адреси облікових записів**: PDAs забезпечують механізм детермінованого отримання адреси за допомогою комбінації опціональних "насіння" (заданих вхідних даних) і конкретного ідентифікатора програми. -- **Дозволити підписання програмою**: Час виконання Solana дозволяє програмам "підписувати" PDAs, які отримані від їх ідентифікатора програми. +- **Детерміновані адреси облікових записів**: PDAs забезпечують механізм + детермінованого отримання адреси за допомогою комбінації опціональних + "насіння" (заданих вхідних даних) і конкретного ідентифікатора програми. +- **Дозволити підписання програмою**: Час виконання Solana дозволяє програмам + "підписувати" PDAs, які отримані від їх ідентифікатора програми. -Можна уявити PDAs як спосіб створення ончейн-структур, схожих на хеш-таблиці, з набору заданих вхідних даних (наприклад, рядків, чисел та інших адрес облікових записів). +Можна уявити PDAs як спосіб створення ончейн-структур, схожих на хеш-таблиці, з +набору заданих вхідних даних (наприклад, рядків, чисел та інших адрес облікових +записів). Дізнайтеся більше про [Адреси, отримані від програм](/docs/core/pda.md) тут. ## Міжпрограмні виклики -Міжпрограмний виклик (Cross Program Invocation, CPI) означає, що одна програма викликає інструкції іншої програми. Цей механізм дозволяє програмам Solana бути композитивними. +Міжпрограмний виклик (Cross Program Invocation, CPI) означає, що одна програма +викликає інструкції іншої програми. Цей механізм дозволяє програмам Solana бути +композитивними. -Можна уявити інструкції як API-ендпоінти, які програма надає мережі, а CPI як один API, що викликає інший API внутрішньо. +Можна уявити інструкції як API-ендпоінти, які програма надає мережі, а CPI як +один API, що викликає інший API внутрішньо. Дізнайтеся більше про [Міжпрограмні виклики](/docs/core/cpi.md) тут. ## Токени на Solana -Токени — це цифрові активи, які представляють право власності на різні категорії активів. Токенізація дозволяє оцифровувати права власності, виступаючи фундаментальним компонентом для управління як взаємозамінними, так і невзаємозамінними активами. +Токени — це цифрові активи, які представляють право власності на різні категорії +активів. Токенізація дозволяє оцифровувати права власності, виступаючи +фундаментальним компонентом для управління як взаємозамінними, так і +невзаємозамінними активами. -- Взаємозамінні токени представляють взаємозамінні та подільні активи одного типу і вартості (наприклад, USDC). -- Невзаємозамінні токени (NFT) представляють право власності на неподільні активи (наприклад, твори мистецтва). +- Взаємозамінні токени представляють взаємозамінні та подільні активи одного + типу і вартості (наприклад, USDC). +- Невзаємозамінні токени (NFT) представляють право власності на неподільні + активи (наприклад, твори мистецтва). Дізнайтеся більше про [Токени на Solana](/docs/core/tokens.md) тут. ## Кластери та кінцеві точки -Блокчейн Solana має кілька різних груп валідаторів, відомих як [Кластери](/docs/core/clusters.md). Кожна з них виконує різні завдання в екосистемі та має спеціалізовані вузли API для виконання запитів [JSON-RPC](/docs/rpc/index.mdx) для свого кластеру. +Блокчейн Solana має кілька різних груп валідаторів, відомих як +[Кластери](/docs/core/clusters.md). Кожна з них виконує різні завдання в +екосистемі та має спеціалізовані вузли API для виконання запитів +[JSON-RPC](/docs/rpc/index.mdx) для свого кластеру. -Індивідуальні вузли в кластері належать і управляються третіми сторонами, причому для кожного з них доступна публічна кінцева точка. +Індивідуальні вузли в кластері належать і управляються третіми сторонами, +причому для кожного з них доступна публічна кінцева точка. -Є три основні кластери в мережі Solana, кожен з яких має свою публічну кінцеву точку: +Є три основні кластери в мережі Solana, кожен з яких має свою публічну кінцеву +точку: - Mainnet - `https://api.mainnet-beta.solana.com` - Devnet - `https://api.devnet.solana.com` - Testnet - `https://api.testnet.solana.com` Дізнайтеся більше про [Кластери та кінцеві точки](/docs/core/clusters.md) тут. - diff --git a/docs/locales/uk/core/pda.md b/docs/locales/uk/core/pda.md index 3221b2f8f..b3451e66e 100644 --- a/docs/locales/uk/core/pda.md +++ b/docs/locales/uk/core/pda.md @@ -3,16 +3,19 @@ title: Програмно Виведені Адреси (PDA) sidebarLabel: Програмно Виведені Адреси sidebarSortOrder: 5 description: - Дізнайтеся про Програмно Виведені Адреси (PDA) в Solana — детерміновані - адреси облікових записів, які забезпечують безпечне підписання програмами. - Розберіться у виведенні PDA, канонічних бампах і створенні облікових записів PDA. + Дізнайтеся про Програмно Виведені Адреси (PDA) в Solana — детерміновані адреси + облікових записів, які забезпечують безпечне підписання програмами. + Розберіться у виведенні PDA, канонічних бампах і створенні облікових записів + PDA. --- -Програмно Виведені Адреси (PDA) надають розробникам у Solana два основних варіанти використання: +Програмно Виведені Адреси (PDA) надають розробникам у Solana два основних +варіанти використання: - **Детерміновані адреси облікових записів**: PDA надають механізм для детермінованого виведення адреси за допомогою комбінації необов’язкових - "сідів" (заздалегідь визначених вхідних даних) та певного ідентифікатора програми. + "сідів" (заздалегідь визначених вхідних даних) та певного ідентифікатора + програми. - **Забезпечення підписання програмами**: Рантайм Solana дозволяє програмам "підписуватися" від імені PDA, які виведені з їхнього ідентифікатора програми. @@ -27,14 +30,14 @@ description: ![Програмно Виведена Адреса](/assets/docs/core/pda/pda.svg) Важливо розуміти, що просте виведення Програмно Виведеної Адреси (PDA) не -автоматично створює обліковий запис у блокчейні за цією адресою. Облікові -записи з PDA як адресою в блокчейні повинні бути явно створені через програму, -яка використовувалась для виведення адреси. Можна уявити виведення PDA як -пошук адреси на карті. Мати адресу — це ще не означає, що за цією адресою -щось побудовано. - -> У цьому розділі буде розглянуто деталі виведення PDA. Деталі того, як -> програми використовують PDA для підписання, будуть розглянуті в розділі +автоматично створює обліковий запис у блокчейні за цією адресою. Облікові записи +з PDA як адресою в блокчейні повинні бути явно створені через програму, яка +використовувалась для виведення адреси. Можна уявити виведення PDA як пошук +адреси на карті. Мати адресу — це ще не означає, що за цією адресою щось +побудовано. + +> У цьому розділі буде розглянуто деталі виведення PDA. Деталі того, як програми +> використовують PDA для підписання, будуть розглянуті в розділі > [Взаємодія між програмами (CPI)](/docs/uk/core/cpi.md), оскільки це потребує > контексту для обох концепцій. @@ -58,11 +61,12 @@ description: PDA — це адреси, які виводяться детерміновано та виглядають як стандартні публічні ключі, але не мають асоційованих приватних ключів. Це означає, що жоден -зовнішній користувач не може згенерувати дійсний підпис для цієї адреси. -Однак, рантайм Solana дозволяє програмам програмно "підписуватися" від імені -PDA без необхідності у приватному ключі. +зовнішній користувач не може згенерувати дійсний підпис для цієї адреси. Однак, +рантайм Solana дозволяє програмам програмно "підписуватися" від імені PDA без +необхідності у приватному ключі. -Для контексту, [Keypairs](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/src/signer/keypair.rs#L25) +Для контексту, +[Keypairs](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/src/signer/keypair.rs#L25) у Solana є точками на кривій Ed25519 (еліптична криптографія), які мають публічний ключ і відповідний приватний ключ. Ми часто використовуємо публічні ключі як унікальні ідентифікатори для нових облікових записів у блокчейні, а @@ -86,13 +90,13 @@ PDA може бути використана як адреса (унікальн Виведення PDA вимагає 3 вхідних даних. - **Необов’язкові сіди**: Заздалегідь визначені вхідні дані (наприклад, рядок, - число, інші адреси облікових записів), які використовуються для виведення - PDA. Ці вхідні дані конвертуються в буфер байтів. + число, інші адреси облікових записів), які використовуються для виведення PDA. + Ці вхідні дані конвертуються в буфер байтів. - **Бамп сід**: Додатковий вхідний параметр (зі значенням між 255-0), який використовується для забезпечення того, що згенерований PDA знаходиться поза кривою Ed25519. Цей бамп сід (починаючи з 255) додається до необов’язкових - сідів під час генерації PDA, щоб "виштовхнути" точку за межі кривої - Ed25519. Бамп сід іноді називають "нонсом". + сідів під час генерації PDA, щоб "виштовхнути" точку за межі кривої Ed25519. + Бамп сід іноді називають "нонсом". - **Ідентифікатор програми**: Адреса програми, з якої виведений PDA. Ця ж програма може "підписуватися" від імені PDA. @@ -130,14 +134,16 @@ const [PDA, bump] = PublicKey.findProgramAddressSync([], programId); console.log(`PDA: ${PDA}`); console.log(`Bump: ${bump}`); ``` + Ви можете запустити цей приклад на -[Solana Playground](https://beta.solpg.io/66031e5acffcf4b13384cfef). Виведення PDA та -бамп сіда завжди буде однаковим: +[Solana Playground](https://beta.solpg.io/66031e5acffcf4b13384cfef). Виведення +PDA та бамп сіда завжди буде однаковим: ``` PDA: Cu7NwqCXSmsR5vgGA3Vw9uYVViPi3kQvkbKByVQ8nPY9 Bump: 255 ``` + У наступному прикладі додається необов’язковий сід "helloWorld". ```ts /string/ @@ -154,9 +160,10 @@ const [PDA, bump] = PublicKey.findProgramAddressSync( console.log(`PDA: ${PDA}`); console.log(`Bump: ${bump}`); ``` + Ви також можете запустити цей приклад на -[Solana Playground](https://beta.solpg.io/66031ee5cffcf4b13384cff0). Виведення PDA та -бамп сіда завжди буде однаковим: +[Solana Playground](https://beta.solpg.io/66031ee5cffcf4b13384cff0). Виведення +PDA та бамп сіда завжди буде однаковим: ``` PDA: 46GZzzetjCURsdFPb7rcnspbEMnCBXe9kpjrsZAkKb6X @@ -182,8 +189,8 @@ Bump: 254 Значення бамп сіда починається з 255 і зменшується на 1, доки не буде знайдено дійсний PDA (поза кривою). -Ви можете відтворити попередній приклад, використовуючи `createProgramAddressSync` -та явно передавши бамп сід зі значенням 254. +Ви можете відтворити попередній приклад, використовуючи +`createProgramAddressSync` та явно передавши бамп сід зі значенням 254. ```ts /bump/ import { PublicKey } from "@solana/web3.js"; @@ -199,6 +206,7 @@ const PDA = PublicKey.createProgramAddressSync( console.log(`PDA: ${PDA}`); ``` + Запустіть цей приклад вище на [Solana Playground](https://beta.solpg.io/66031f8ecffcf4b13384cff1). За однакових сідів та ідентифікатора програми, виведення PDA буде відповідати @@ -211,11 +219,11 @@ PDA: 46GZzzetjCURsdFPb7rcnspbEMnCBXe9kpjrsZAkKb6X ### Канонічний бамп "Канонічний бамп" відноситься до першого значення бамп сіда (починаючи з 255 і -зменшуючи на 1), яке виводить дійсний PDA. З метою безпеки програм -рекомендовано використовувати лише PDA, виведені з канонічного бампа. +зменшуючи на 1), яке виводить дійсний PDA. З метою безпеки програм рекомендовано +використовувати лише PDA, виведені з канонічного бампа. -Використовуючи попередній приклад як орієнтир, приклад нижче намагається -вивести PDA, використовуючи всі значення бамп сіда від 255 до 0. +Використовуючи попередній приклад як орієнтир, приклад нижче намагається вивести +PDA, використовуючи всі значення бамп сіда від 255 до 0. ```ts import { PublicKey } from "@solana/web3.js"; @@ -236,7 +244,8 @@ for (let bump = 255; bump >= 0; bump--) { } } ``` -Запустіть приклад на + +Запустіть приклад на [Solana Playground](https://beta.solpg.io/66032009cffcf4b13384cff2), і ви повинні побачити наступний результат: @@ -250,12 +259,13 @@ bump 250: Error: Invalid seeds, address must fall off the curve ... // remaining bump outputs ``` -Як і очікувалось, бамп сід 255 викликає помилку, а перший бамп сід, який виводить -дійсний PDA, дорівнює 254. + +Як і очікувалось, бамп сід 255 викликає помилку, а перший бамп сід, який +виводить дійсний PDA, дорівнює 254. Однак зверніть увагу, що бамп сіди 253-251 також виводять дійсні PDA з різними -адресами. Це означає, що для заданих необов’язкових сідів та `programId` бамп сід -з іншим значенням все ще може вивести дійсний PDA. +адресами. Це означає, що для заданих необов’язкових сідів та `programId` бамп +сід з іншим значенням все ще може вивести дійсний PDA. При створенні програм на Solana рекомендовано додавати перевірки безпеки, @@ -271,10 +281,10 @@ bump 250: Error: Invalid seeds, address must fall off the curve показує, як створити обліковий запис, використовуючи PDA як адресу нового облікового запису. Програма написана з використанням фреймворку Anchor. -У файлі `lib.rs` ви знайдете наступну програму, яка включає єдину інструкцію -для створення нового облікового запису з використанням PDA як адреси -облікового запису. Новий обліковий запис зберігає адресу `user` та `bump` сід, -який використовувався для виведення PDA. +У файлі `lib.rs` ви знайдете наступну програму, яка включає єдину інструкцію для +створення нового облікового запису з використанням PDA як адреси облікового +запису. Новий обліковий запис зберігає адресу `user` та `bump` сід, який +використовувався для виведення PDA. ```rust filename="lib.rs" {11-14,26-29} use anchor_lang::prelude::*; @@ -321,9 +331,10 @@ pub struct DataAccount { pub bump: u8, } ``` -Сіди, які використовуються для виведення PDA, включають зафіксований рядок `data` -та адресу облікового запису `user`, передану в інструкції. Фреймворк Anchor -автоматично виводить канонічний `bump` сід. + +Сіди, які використовуються для виведення PDA, включають зафіксований рядок +`data` та адресу облікового запису `user`, передану в інструкції. Фреймворк +Anchor автоматично виводить канонічний `bump` сід. ```rust /data/ /user.key()/ /bump/ #[account( @@ -335,8 +346,9 @@ pub struct DataAccount { )] pub pda_account: Account<'info, DataAccount>, ``` -Обмеження `init` вказує Anchor викликати Системну Програму для створення нового -облікового запису з використанням PDA як адреси. Це виконується за допомогою + +Обмеження `init` вказує Anchor викликати Системну Програму для створення нового +облікового запису з використанням PDA як адреси. Це виконується за допомогою [Взаємодії між програмами (CPI)](/docs/uk/core/cpi.md). ```rust /init/ @@ -349,10 +361,10 @@ pub pda_account: Account<'info, DataAccount>, )] pub pda_account: Account<'info, DataAccount>, ``` -У тестовому файлі (`pda-account.test.ts`), розташованому за посиланням на -Solana Playground, наданим вище, ви знайдете еквівалентний код на Javascript -для виведення PDA. +У тестовому файлі (`pda-account.test.ts`), розташованому за посиланням на Solana +Playground, наданим вище, ви знайдете еквівалентний код на Javascript для +виведення PDA. ```ts /data/ /user.publicKey/ const [PDA] = PublicKey.findProgramAddressSync( @@ -360,10 +372,11 @@ const [PDA] = PublicKey.findProgramAddressSync( program.programId, ); ``` -Далі надсилається транзакція для виклику інструкції `initialize`, щоб створити -новий обліковий запис у блокчейні з використанням PDA як адреси. Після надсилання -транзакції PDA використовується для отримання облікового запису в блокчейні, -який був створений за цією адресою. + +Далі надсилається транзакція для виклику інструкції `initialize`, щоб створити +новий обліковий запис у блокчейні з використанням PDA як адреси. Після +надсилання транзакції PDA використовується для отримання облікового запису в +блокчейні, який був створений за цією адресою. ```ts /initialize()/ /PDA/ {14} it("Is initialized!", async () => { @@ -383,6 +396,8 @@ it("Fetch Account", async () => { console.log(JSON.stringify(pdaAccount, null, 2)); }); ``` -Зверніть увагу, що якщо ви викликаєте інструкцію `initialize` більше одного разу, -використовуючи ту саму адресу `user` як сід, транзакція завершиться помилкою. -Це відбувається тому, що обліковий запис вже існує за виведеною адресою. + +Зверніть увагу, що якщо ви викликаєте інструкцію `initialize` більше одного +разу, використовуючи ту саму адресу `user` як сід, транзакція завершиться +помилкою. Це відбувається тому, що обліковий запис вже існує за виведеною +адресою. diff --git a/docs/locales/uk/core/programs.md b/docs/locales/uk/core/programs.md index fc4d35564..0c796f12f 100644 --- a/docs/locales/uk/core/programs.md +++ b/docs/locales/uk/core/programs.md @@ -8,85 +8,89 @@ description: та перевірки програм у мережі Solana. --- -У екосистемі Solana "смарт-контракти" називаються програмами. Кожна -[програма](/docs/uk/core/accounts.md#program-account) є обліковим записом у блокчейні, -який зберігає виконувану логіку, організовану у вигляді конкретних функцій, які -називаються [інструкціями](/docs/uk/core/transactions.md#instruction). +У екосистемі Solana "смарт-контракти" називаються програмами. Кожна +[програма](/docs/uk/core/accounts.md#program-account) є обліковим записом у +блокчейні, який зберігає виконувану логіку, організовану у вигляді конкретних +функцій, які називаються +[інструкціями](/docs/uk/core/transactions.md#instruction). ## Основні моменти -- Програми — це облікові записи у блокчейні, які містять виконуваний код. Цей код - організований у вигляді окремих функцій, відомих як інструкції. +- Програми — це облікові записи у блокчейні, які містять виконуваний код. Цей + код організований у вигляді окремих функцій, відомих як інструкції. -- Програми не зберігають стану, але можуть включати інструкції для створення нових - облікових записів, які використовуються для зберігання та управління станом програми. +- Програми не зберігають стану, але можуть включати інструкції для створення + нових облікових записів, які використовуються для зберігання та управління + станом програми. -- Програми можуть оновлюватися за допомогою "авторитету оновлення". Програма стає - незмінною, коли авторитет оновлення встановлюється у значення null. +- Програми можуть оновлюватися за допомогою "авторитету оновлення". Програма + стає незмінною, коли авторитет оновлення встановлюється у значення null. -- Перевірювані збірки дозволяють користувачам переконатися, що програми у блокчейні - відповідають доступному публічно вихідному коду. +- Перевірювані збірки дозволяють користувачам переконатися, що програми у + блокчейні відповідають доступному публічно вихідному коду. ## Написання програм Solana -Програми Solana зазвичай пишуться мовою програмування +Програми Solana зазвичай пишуться мовою програмування [Rust](https://doc.rust-lang.org/book/) з використанням двох підходів: -- [Anchor](/docs/uk/programs/anchor): Фреймворк, створений для розробки програм Solana. - Він забезпечує швидший і простіший спосіб написання програм, використовуючи макроси - Rust для значного зменшення обсягу шаблонного коду. Для початківців рекомендується - починати з фреймворку Anchor. +- [Anchor](/docs/uk/programs/anchor): Фреймворк, створений для розробки програм + Solana. Він забезпечує швидший і простіший спосіб написання програм, + використовуючи макроси Rust для значного зменшення обсягу шаблонного коду. Для + початківців рекомендується починати з фреймворку Anchor. -- [Нативний Rust](/content/guides/getstarted/intro-to-native-rust.md): Цей підхід - передбачає написання програм Solana на Rust без використання фреймворків. Він - надає більше гнучкості, але супроводжується підвищеною складністю. +- [Нативний Rust](/content/guides/getstarted/intro-to-native-rust.md): Цей + підхід передбачає написання програм Solana на Rust без використання + фреймворків. Він надає більше гнучкості, але супроводжується підвищеною + складністю. ## Оновлення програм Solana -Програми у блокчейні можуть бути -[безпосередньо змінені](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/bpf_loader/src/lib.rs#L675) -обліковим записом, призначеним як "авторитет оновлення", зазвичай це обліковий +Програми у блокчейні можуть бути +[безпосередньо змінені](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/bpf_loader/src/lib.rs#L675) +обліковим записом, призначеним як "авторитет оновлення", зазвичай це обліковий запис, який початково розгорнув програму. -Якщо -[авторитет оновлення](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/bpf_loader/src/lib.rs#L865) -скасований і встановлений у `None`, програма стає незмінною і більше не може бути оновлена. +Якщо +[авторитет оновлення](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/bpf_loader/src/lib.rs#L865) +скасований і встановлений у `None`, програма стає незмінною і більше не може +бути оновлена. ## Перевірювані програми -Забезпечення цілісності та перевірюваності коду у блокчейні є важливим. -Перевірювана збірка гарантує, що виконуваний код, розгорнутий у блокчейні, може -бути незалежно перевірений на відповідність його публічному вихідному коду -будь-якою третьою стороною. Цей процес підвищує прозорість і довіру, дозволяючи +Забезпечення цілісності та перевірюваності коду у блокчейні є важливим. +Перевірювана збірка гарантує, що виконуваний код, розгорнутий у блокчейні, може +бути незалежно перевірений на відповідність його публічному вихідному коду +будь-якою третьою стороною. Цей процес підвищує прозорість і довіру, дозволяючи виявляти розбіжності між вихідним кодом і розгорнутою програмою. -Спільнота розробників Solana створила інструменти для підтримки перевірюваних -збірок, які дозволяють як розробникам, так і користувачам переконатися, що +Спільнота розробників Solana створила інструменти для підтримки перевірюваних +збірок, які дозволяють як розробникам, так і користувачам переконатися, що програми у блокчейні точно відображають їхній публічний вихідний код. -- **Пошук перевірених програм**: Для швидкої перевірки програм користувачі можуть - знайти адресу програми у [SolanaFM](https://solana.fm/) Explorer і перейти на - вкладку "Verification". Приклад перевіреної програми можна побачити +- **Пошук перевірених програм**: Для швидкої перевірки програм користувачі + можуть знайти адресу програми у [SolanaFM](https://solana.fm/) Explorer і + перейти на вкладку "Verification". Приклад перевіреної програми можна побачити [тут](https://solana.fm/address/PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY). -- **Інструменти перевірки**: CLI - [Solana Verifiable Build](https://github.com/Ellipsis-Labs/solana-verifiable-build) - від Ellipsis Labs дозволяє незалежно перевірити програми у блокчейні на відповідність - опублікованому вихідному коду. +- **Інструменти перевірки**: CLI + [Solana Verifiable Build](https://github.com/Ellipsis-Labs/solana-verifiable-build) + від Ellipsis Labs дозволяє незалежно перевірити програми у блокчейні на + відповідність опублікованому вихідному коду. -- **Підтримка перевірюваних збірок в Anchor**: Anchor має вбудовану підтримку - перевірюваних збірок. Деталі можна знайти у +- **Підтримка перевірюваних збірок в Anchor**: Anchor має вбудовану підтримку + перевірюваних збірок. Деталі можна знайти у [документації Anchor](https://www.anchor-lang.com/docs/verifiable-builds). ## Berkeley Packet Filter (BPF) -Solana використовує [інфраструктуру компілятора LLVM](https://llvm.org/) для -компіляції програм у файли формату -[Executable and Linkable Format (ELF)](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format). -Ці файли включають модифіковану версію байт-коду -[Berkeley Packet Filter (eBPF)](https://en.wikipedia.org/wiki/EBPF) для програм Solana, -відомого як "Solana Bytecode Format" (sBPF). +Solana використовує [інфраструктуру компілятора LLVM](https://llvm.org/) для +компіляції програм у файли формату +[Executable and Linkable Format (ELF)](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format). +Ці файли включають модифіковану версію байт-коду +[Berkeley Packet Filter (eBPF)](https://en.wikipedia.org/wiki/EBPF) для програм +Solana, відомого як "Solana Bytecode Format" (sBPF). -Використання LLVM дозволяє Solana підтримувати будь-яку мову програмування, яка -може компілюватися у BPF-бекенд LLVM. Це значно підвищує гнучкість Solana як платформи -для розробки. +Використання LLVM дозволяє Solana підтримувати будь-яку мову програмування, яка +може компілюватися у BPF-бекенд LLVM. Це значно підвищує гнучкість Solana як +платформи для розробки. diff --git a/docs/locales/uk/core/tokens.md b/docs/locales/uk/core/tokens.md index 62700b186..c9cd3812a 100644 --- a/docs/locales/uk/core/tokens.md +++ b/docs/locales/uk/core/tokens.md @@ -3,9 +3,9 @@ title: "Токени на Solana" sidebarSortOrder: 7 description: Дізнайтеся про токени Solana (SPL Tokens), включаючи взаємозамінні та - невзаємозамінні токени, Програму Токенів, Програму Розширень Токенів, - облікові записи випуску токенів, токен-облікові записи, а також практичні - приклади створення і управління токенами на Solana. + невзаємозамінні токени, Програму Токенів, Програму Розширень Токенів, облікові + записи випуску токенів, токен-облікові записи, а також практичні приклади + створення і управління токенами на Solana. --- Токени — це цифрові активи, які представляють право власності на різні категорії @@ -19,11 +19,11 @@ description: активи (наприклад, витвори мистецтва). У цьому розділі буде розглянуто основи представлення токенів у Solana. Ці токени -називаються SPL +називаються SPL ([Solana Program Library](https://github.com/solana-labs/solana-program-library)). -- [Програма Токенів](#token-program) містить всю логіку інструкцій для - взаємодії з токенами в мережі (як взаємозамінними, так і невзаємозамінними). +- [Програма Токенів](#token-program) містить всю логіку інструкцій для взаємодії + з токенами в мережі (як взаємозамінними, так і невзаємозамінними). - [Обліковий запис випуску токенів](#mint-account) представляє певний тип токена і зберігає глобальні метадані, такі як загальна кількість токенів і авторитет @@ -32,10 +32,10 @@ description: - [Токен-обліковий запис](#token-account) відстежує індивідуальну власність на певну кількість токенів конкретного типу (облікового запису випуску токенів). -> Наразі існує дві версії Програми Токенів: оригінальна +> Наразі існує дві версії Програми Токенів: оригінальна > [Програма Токенів](https://github.com/solana-labs/solana-program-library/tree/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program) -> і -> [Програма Розширень Токенів](https://github.com/solana-labs/solana-program-library/tree/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program-2022) +> і +> [Програма Розширень Токенів](https://github.com/solana-labs/solana-program-library/tree/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program-2022) > (Token2022). Програма Розширень Токенів працює так само, як і оригінальна > Програма Токенів, але з додатковими функціями і покращеннями. Для створення > нових токенів рекомендовано використовувати Програму Розширень Токенів. @@ -57,16 +57,18 @@ description: облікового запису випуску токенів. - Асоційований Токен-обліковий запис — це токен-обліковий запис, створений із - адреси, отриманої із адреси власника та адреси облікового запису випуску токенів. + адреси, отриманої із адреси власника та адреси облікового запису випуску + токенів. ## Програма Токенів -[Програма Токенів](https://github.com/solana-labs/solana-program-library/tree/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program) +[Програма Токенів](https://github.com/solana-labs/solana-program-library/tree/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program) містить всю логіку інструкцій для взаємодії з токенами в мережі (як -взаємозамінними, так і невзаємозамінними). Усі токени на Solana фактично є -[даними облікових записів](/docs/uk/core/accounts.md#data-account), якими володіє Програма Токенів. +взаємозамінними, так і невзаємозамінними). Усі токени на Solana фактично є +[даними облікових записів](/docs/uk/core/accounts.md#data-account), якими +володіє Програма Токенів. -Повний список інструкцій Програми Токенів можна знайти +Повний список інструкцій Програми Токенів можна знайти [тут](https://github.com/solana-labs/solana-program-library/blob/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program/src/instruction.rs). ![Програма Токенів](/assets/docs/core/tokens/token-program.svg) @@ -74,33 +76,37 @@ description: Кілька найчастіше використовуваних інструкцій включають: - [`InitializeMint`](https://github.com/solana-labs/solana-program-library/blob/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program/src/processor.rs#L29): - Створення нового облікового запису випуску токенів для представлення нового типу токена. + Створення нового облікового запису випуску токенів для представлення нового + типу токена. - [`InitializeAccount`](https://github.com/solana-labs/solana-program-library/blob/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program/src/processor.rs#L84): - Створення нового токен-облікового запису для зберігання одиниць певного типу токенів (випуску). + Створення нового токен-облікового запису для зберігання одиниць певного типу + токенів (випуску). - [`MintTo`](https://github.com/solana-labs/solana-program-library/blob/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program/src/processor.rs#L522): - Створення нових одиниць певного типу токенів і додавання їх до токен-облікового запису. - Це збільшує кількість токенів і може виконуватися лише авторитетом випуску - облікового запису випуску токенів. + Створення нових одиниць певного типу токенів і додавання їх до + токен-облікового запису. Це збільшує кількість токенів і може виконуватися + лише авторитетом випуску облікового запису випуску токенів. - [`Transfer`](https://github.com/solana-labs/solana-program-library/blob/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program/src/processor.rs#L228): - Передача одиниць певного типу токенів із одного токен-облікового запису в інший. + Передача одиниць певного типу токенів із одного токен-облікового запису в + інший. ### Обліковий запис випуску токенів -Токени на Solana унікально ідентифікуються за адресою -[Облікового запису випуску токенів](https://github.com/solana-labs/solana-program-library/blob/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program/src/state.rs#L18-L32), -яким володіє Програма Токенів. Цей обліковий запис фактично є глобальним лічильником -для певного токена і зберігає дані, такі як: +Токени на Solana унікально ідентифікуються за адресою +[Облікового запису випуску токенів](https://github.com/solana-labs/solana-program-library/blob/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program/src/state.rs#L18-L32), +яким володіє Програма Токенів. Цей обліковий запис фактично є глобальним +лічильником для певного токена і зберігає дані, такі як: - Загальна кількість: Загальна кількість токенів. - Десяткові знаки: Точність токена у десяткових знаках. - Авторитет випуску: Обліковий запис, уповноважений створювати нові одиниці токенів, таким чином збільшуючи кількість. -- Авторитет замороження: Обліковий запис, уповноважений заморожувати токени, - щоб їх не можна було передати із "токен-облікових записів". +- Авторитет замороження: Обліковий запис, уповноважений заморожувати токени, щоб + їх не можна було передати із "токен-облікових записів". ![Обліковий запис випуску токенів](/assets/docs/core/tokens/mint-account.svg) -Повна інформація, яка зберігається в кожному обліковому записі випуску токенів, включає: +Повна інформація, яка зберігається в кожному обліковому записі випуску токенів, +включає: ```rust pub struct Mint { @@ -119,21 +125,26 @@ pub struct Mint { pub freeze_authority: COption, } ``` -Для довідки, ось посилання на Solana Explorer для + +Для довідки, ось посилання на Solana Explorer для [Облікового запису випуску USDC](https://explorer.solana.com/address/EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v). ### Токен-обліковий запис -Для відстеження індивідуальної власності на кожну одиницю певного токена має бути -створений інший тип облікового запису даних, яким володіє Програма Токенів. Цей -обліковий запис називається +Для відстеження індивідуальної власності на кожну одиницю певного токена має +бути створений інший тип облікового запису даних, яким володіє Програма Токенів. +Цей обліковий запис називається [Токен-обліковий запис](https://github.com/solana-labs/solana-program-library/blob/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program/src/state.rs#L89-L110). -Найчастіше згадувані дані, які зберігаються в Токен-обліковому записі, включають: +Найчастіше згадувані дані, які зберігаються в Токен-обліковому записі, +включають: -- **Випуск (Mint)**: Тип токена, одиниці якого зберігаються в Токен-обліковому записі. -- **Власник (Owner)**: Обліковий запис, уповноважений передавати токени з Токен-облікового запису. -- **Кількість (Amount)**: Кількість одиниць токена, які наразі зберігаються в Токен-обліковому записі. +- **Випуск (Mint)**: Тип токена, одиниці якого зберігаються в Токен-обліковому + записі. +- **Власник (Owner)**: Обліковий запис, уповноважений передавати токени з + Токен-облікового запису. +- **Кількість (Amount)**: Кількість одиниць токена, які наразі зберігаються в + Токен-обліковому записі. ![Токен-обліковий запис](/assets/docs/core/tokens/token-account.svg) @@ -163,19 +174,21 @@ pub struct Account { pub close_authority: COption, } ``` -Щоб гаманець міг володіти одиницями певного токена, потрібно створити токен-обліковий -запис для конкретного типу токена (випуску), який призначає гаманець власником -цього токен-облікового запису. Гаманець може створювати кілька токен-облікових -записів для одного і того ж типу токена, але кожен токен-обліковий запис може -належати лише одному гаманцю і зберігати одиниці лише одного типу токена. + +Щоб гаманець міг володіти одиницями певного токена, потрібно створити +токен-обліковий запис для конкретного типу токена (випуску), який призначає +гаманець власником цього токен-облікового запису. Гаманець може створювати +кілька токен-облікових записів для одного і того ж типу токена, але кожен +токен-обліковий запис може належати лише одному гаманцю і зберігати одиниці лише +одного типу токена. ![Взаємозв'язок облікових записів](/assets/docs/core/tokens/token-account-relationship.svg) -> Зверніть увагу, що дані кожного Токен-облікового запису містять поле `owner`, яке -> використовується для визначення того, хто має авторитет над цим Токен-обліковим записом. -> Це окремо від власника програми, зазначеного у -> [AccountInfo](/docs/uk/core/accounts.md#accountinfo), яким є Програма Токенів для всіх -> Токен-облікових записів. +> Зверніть увагу, що дані кожного Токен-облікового запису містять поле `owner`, +> яке використовується для визначення того, хто має авторитет над цим +> Токен-обліковим записом. Це окремо від власника програми, зазначеного у +> [AccountInfo](/docs/uk/core/accounts.md#accountinfo), яким є Програма Токенів +> для всіх Токен-облікових записів. ### Асоційований токен-обліковий запис @@ -195,11 +208,13 @@ pub struct Account { Це вводить ключове поняття в розробці Solana: [Програмно Виведена Адреса (PDA)](/docs/uk/core/pda.md). Концептуально PDA надає детермінований спосіб генерації адреси з використанням заздалегідь визначених -вхідних даних. Це дозволяє нам легко знайти адресу облікового запису в майбутньому. +вхідних даних. Це дозволяє нам легко знайти адресу облікового запису в +майбутньому. -Ось [приклад на Solana Playground](https://beta.solpg.io/656a2dd0fb53fa325bfd0c41), +Ось +[приклад на Solana Playground](https://beta.solpg.io/656a2dd0fb53fa325bfd0c41), який виводить адресу і власника Асоційованого токен-облікового запису USDC. Він -завжди генерує +завжди генерує [одну й ту саму адресу](https://explorer.solana.com/address/4kokFKCFMxpCpG41yLYkLEqXW8g1WPfCt2NC9KGivY6N) для одного і того ж випуску і власника. @@ -211,9 +226,10 @@ const associatedTokenAccountAddress = getAssociatedTokenAddressSync( OWNER_ADDRESS, ); ``` -Зокрема, адреса для Асоційованого токен-облікового запису виводиться за допомогою -наступних вхідних даних. Ось -[приклад на Solana Playground](https://beta.solpg.io/656a31d0fb53fa325bfd0c42), + +Зокрема, адреса для Асоційованого токен-облікового запису виводиться за +допомогою наступних вхідних даних. Ось +[приклад на Solana Playground](https://beta.solpg.io/656a31d0fb53fa325bfd0c42), який генерує ту саму адресу, що й у попередньому прикладі. ```ts @@ -228,25 +244,26 @@ const [PDA, bump] = PublicKey.findProgramAddressSync( ASSOCIATED_TOKEN_PROGRAM_ID, ); ``` + Щоб два гаманці могли зберігати одиниці одного і того ж типу токена, кожен -гаманець потребує свого токен-облікового запису для конкретного облікового запису -випуску токенів. Зображення нижче демонструє, як виглядає ця структура взаємозв'язку облікових записів. +гаманець потребує свого токен-облікового запису для конкретного облікового +запису випуску токенів. Зображення нижче демонструє, як виглядає ця структура +взаємозв'язку облікових записів. ![Розширений взаємозв'язок облікових записів](/assets/docs/core/tokens/token-account-relationship-ata.svg) ## Приклади роботи з токенами -CLI [`spl-token`](https://docs.anza.xyz/cli) можна використовувати для експериментів -з SPL токенами. У прикладах нижче ми використовуватимемо -[Solana Playground](https://beta.solpg.io/) для виконання CLI-команд прямо в +CLI [`spl-token`](https://docs.anza.xyz/cli) можна використовувати для +експериментів з SPL токенами. У прикладах нижче ми використовуватимемо +[Solana Playground](https://beta.solpg.io/) для виконання CLI-команд прямо в браузері без необхідності встановлення CLI локально. -Створення токенів і облікових записів вимагає SOL для депозитів за оренду -облікових записів та оплати транзакційних комісій. Якщо ви вперше використовуєте -Solana Playground, створіть гаманець у Playground і виконайте команду -`solana airdrop` у терміналі Playground. Ви також можете отримати SOL для -devnet, використовуючи публічний -[веб-фасет](https://faucet.solana.com/). +Створення токенів і облікових записів вимагає SOL для депозитів за оренду +облікових записів та оплати транзакційних комісій. Якщо ви вперше використовуєте +Solana Playground, створіть гаманець у Playground і виконайте команду +`solana airdrop` у терміналі Playground. Ви також можете отримати SOL для +devnet, використовуючи публічний [веб-фасет](https://faucet.solana.com/). ```sh solana airdrop 2 @@ -257,28 +274,29 @@ Run `spl-token --help` for a full description of available commands. ```sh spl-token --help ``` -Крім того, ви можете встановити CLI `spl-token` локально, використовуючи наступну -команду. Для цього спочатку потрібно + +Крім того, ви можете встановити CLI `spl-token` локально, використовуючи +наступну команду. Для цього спочатку потрібно [встановити Rust](https://rustup.rs/). > У наступних розділах адреси облікових записів, які відображаються під час -> виконання CLI-команд, можуть відрізнятися від прикладів, наведених нижче. Будь ласка, -> використовуйте адреси, які відображаються у вашому терміналі Playground, під час -> виконання команд. Наприклад, адреса, отримана в результаті виконання `create-token`, -> є обліковим записом випуску токенів, де ваш гаманець Playground призначений -> авторитетом випуску. +> виконання CLI-команд, можуть відрізнятися від прикладів, наведених нижче. Будь +> ласка, використовуйте адреси, які відображаються у вашому терміналі +> Playground, під час виконання команд. Наприклад, адреса, отримана в результаті +> виконання `create-token`, є обліковим записом випуску токенів, де ваш гаманець +> Playground призначений авторитетом випуску. ### Створення нового токена -Щоб створити новий токен -([обліковий запис випуску токенів](#mint-account)), виконайте наступну команду -в терміналі Solana Playground. +Щоб створити новий токен ([обліковий запис випуску токенів](#mint-account)), +виконайте наступну команду в терміналі Solana Playground. ```sh spl-token create-token ``` -Ви повинні побачити результат, подібний до наведеного нижче. Ви можете переглянути -деталі як токена, так і транзакції у + +Ви повинні побачити результат, подібний до наведеного нижче. Ви можете +переглянути деталі як токена, так і транзакції у [Solana Explorer](https://explorer.solana.com/?cluster=devnet), використовуючи `Address` (адресу) та `Signature` (підпис). @@ -293,19 +311,22 @@ Decimals: 9 Signature: 44fvKfT1ezBUwdzrCys3fvCdFxbLMnNvBstds76QZyE6cXag5NupBprSXwxPTzzjrC3cA6nvUZaLFTvmcKyzxrm1 ``` + Нові токени спочатку мають нульовий запас. Ви можете перевірити поточний запас токена, використовуючи наступну команду: ```sh spl-token supply ``` + Запуск команди `supply` для новоствореного токена поверне значення `0`: ```sh /99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg/ spl-token supply 99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg ``` + У своїй основі створення нового облікового запису випуску токенів (Mint Account) -вимагає надсилання транзакції з двома інструкціями. Ось приклад на Javascript у +вимагає надсилання транзакції з двома інструкціями. Ось приклад на Javascript у [Solana Playground](https://beta.solpg.io/660ce32ecffcf4b13384d00f). 1. Виклик Системної Програми для створення нового облікового запису з достатнім @@ -317,28 +338,30 @@ spl-token supply 99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg ### Створення Токен-облікового запису -Щоб зберігати одиниці певного токена, вам потрібно спочатку створити +Щоб зберігати одиниці певного токена, вам потрібно спочатку створити [токен-обліковий запис](#token-account). Для створення нового токен-облікового запису скористайтеся наступною командою: ```sh spl-token create-account [OPTIONS] ``` + Наприклад, виконання наступної команди в терміналі Solana Playground: -```sh /99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg/ +````sh /99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg/ spl-token create-account 99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg ```: Виведе наступний результат -- `AfB7uwBEsGtrrBqPTVqEgzWed5XdYfM1psPNLmf7EeX9`це адреса токен-облікового запису, створеного для зберігання одиниць токена, +- `AfB7uwBEsGtrrBqPTVqEgzWed5XdYfM1psPNLmf7EeX9`це адреса токен-облікового запису, створеного для зберігання одиниць токена, вказаного в команді `create-account`. ```shell filename="Terminal Output" /AfB7uwBEsGtrrBqPTVqEgzWed5XdYfM1psPNLmf7EeX9/ Creating account AfB7uwBEsGtrrBqPTVqEgzWed5XdYfM1psPNLmf7EeX9 Signature: 2BtrynuCLX9CNofFiaw6Yzbx6hit66pup9Sk7aFjwU2NEbFz7NCHD9w9sWhrCfEd73XveAGK1DxFpJoQZPXU9tS1 -``` -За замовчуванням команда `create-account` створює +```` + +За замовчуванням команда `create-account` створює [асоційований токен-обліковий запис](#associated-token-account) з адресою вашого гаманця як власника токен-облікового запису. @@ -348,33 +371,37 @@ Signature: 2BtrynuCLX9CNofFiaw6Yzbx6hit66pup9Sk7aFjwU2NEbFz7NCHD9w9sWhrCfEd73Xve ```sh spl-token create-account --owner ``` -Наприклад, виконання наступної команди: + +Наприклад, виконання наступної команди: + ```sh /2i3KvjDCZWxBsqcxBHpdEaZYQwQSYE6LXUMx5VjY5XrR/ spl-token create-account --owner 2i3KvjDCZWxBsqcxBHpdEaZYQwQSYE6LXUMx5VjY5XrR 99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg ``` Виведе наступний результат: -- `Hmyk3FSw4cfsuAes7sanp2oxSkE9ivaH6pMzDzbacqmt` — це адреса токен-облікового запису, - створеного для зберігання одиниць токена, вказаного в команді `create-account` - (`99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg`), і який належить адресі, - вказаній після прапора `--owner` - (`2i3KvjDCZWxBsqcxBHpdEaZYQwQSYE6LXUMx5VjY5XrR`). Це корисно, коли вам потрібно - створити токен-обліковий запис для іншого користувача. +- `Hmyk3FSw4cfsuAes7sanp2oxSkE9ivaH6pMzDzbacqmt` — це адреса токен-облікового + запису, створеного для зберігання одиниць токена, вказаного в команді + `create-account` (`99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg`), і який + належить адресі, вказаній після прапора `--owner` + (`2i3KvjDCZWxBsqcxBHpdEaZYQwQSYE6LXUMx5VjY5XrR`). Це корисно, коли вам + потрібно створити токен-обліковий запис для іншого користувача. ```shell filename="Terminal Output" /Hmyk3FSw4cfsuAes7sanp2oxSkE9ivaH6pMzDzbacqmt/ Creating account Hmyk3FSw4cfsuAes7sanp2oxSkE9ivaH6pMzDzbacqmt Signature: 44vqKdfzspT592REDPY4goaRJH3uJ3Ce13G4BCuUHg35dVUbHuGTHvqn4ZjYF9BGe9QrjMfe9GmuLkQhSZCBQuEt ``` + За лаштунками створення Асоційованого токен-облікового запису потребує однієї інструкції, яка викликає [Програму Асоційованих Токенів](https://github.com/solana-labs/solana-program-library/tree/b1c44c171bc95e6ee74af12365cb9cbab68be76c/associated-token-account/program/src). -Ось приклад на Javascript у +Ось приклад на Javascript у [Solana Playground](https://beta.solpg.io/660ce868cffcf4b13384d011). -Програма Асоційованих Токенів використовує -[Перехресні Виклики Програм (CPI)](/docs/uk/core/cpi.md) для виконання наступного: +Програма Асоційованих Токенів використовує +[Перехресні Виклики Програм (CPI)](/docs/uk/core/cpi.md) для виконання +наступного: - [Виклик Системної Програми](https://github.com/solana-labs/solana-program-library/blob/b1c44c171bc95e6ee74af12365cb9cbab68be76c/associated-token-account/program/src/tools/account.rs#L19) для створення нового облікового запису, використовуючи надану PDA як адресу @@ -402,18 +429,21 @@ Signature: 44vqKdfzspT592REDPY4goaRJH3uJ3Ce13G4BCuUHg35dVUbHuGTHvqn4ZjYF9BGe9Qrj spl-token mint [OPTIONS] [--] [RECIPIENT_TOKEN_ACCOUNT_ADDRESS] ``` -Наприклад, виконання наступної команди: +Наприклад, виконання наступної команди: ```sh spl-token mint 99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg 100 ``` Виведе наступний результат: -- `99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg` — це адреса облікового запису - випуску токенів, для якого випускаються токени (збільшуючи загальну кількість). -- `AfB7uwBEsGtrrBqPTVqEgzWed5XdYfM1psPNLmf7EeX9` — це адреса токен-облікового запису - вашого гаманця, до якого випускаються одиниці токена (збільшуючи кількість). +- `99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg` — це адреса облікового запису + випуску токенів, для якого випускаються токени (збільшуючи загальну + кількість). + +- `AfB7uwBEsGtrrBqPTVqEgzWed5XdYfM1psPNLmf7EeX9` — це адреса токен-облікового + запису вашого гаманця, до якого випускаються одиниці токена (збільшуючи + кількість). ```shell filename="Terminal Output" /99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg/ /AfB7uwBEsGtrrBqPTVqEgzWed5XdYfM1psPNLmf7EeX9/ Minting 100 tokens @@ -422,19 +452,24 @@ Minting 100 tokens Signature: 2NJ1m7qCraPSBAVxbr2ssmWZmBU9Jc8pDtJAnyZsZJRcaYCYMqq1oRY1gqA4ddQno3g3xcnny5fzr1dvsnFKMEqG ``` -Щоб випустити токени до іншого токен-облікового запису, вкажіть адресу -потрібного облікового запису одержувача токенів. + +Щоб випустити токени до іншого токен-облікового запису, вкажіть адресу +потрібного облікового запису одержувача токенів. Наприклад, виконання наступної команди: ```sh /Hmyk3FSw4cfsuAes7sanp2oxSkE9ivaH6pMzDzbacqmt/ spl-token mint 99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg 100 -- Hmyk3FSw4cfsuAes7sanp2oxSkE9ivaH6pMzDzbacqmt ``` + Повертає наступний результат: - - 99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg — це адреса облікового запису випуску токенів, для якого випускаються токени (збільшуючи загальну кількість). +- 99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg — це адреса облікового запису + випуску токенів, для якого випускаються токени (збільшуючи загальну + кількість). - - Hmyk3FSw4cfsuAes7sanp2oxSkE9ivaH6pMzDzbacqmt — це адреса токен-облікового запису, до якого випускаються одиниці токена (збільшуючи кількість). +- Hmyk3FSw4cfsuAes7sanp2oxSkE9ivaH6pMzDzbacqmt — це адреса токен-облікового + запису, до якого випускаються одиниці токена (збільшуючи кількість). ```shell filename="Terminal Output" /99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg/ /Hmyk3FSw4cfsuAes7sanp2oxSkE9ivaH6pMzDzbacqmt/ Minting 100 tokens @@ -443,10 +478,12 @@ Minting 100 tokens Signature: 3SQvNM3o9DsTiLwcEkSPT1Edr14RgE2wC54TEjonEP2swyVCp2jPWYWdD6RwXUGpvDNUkKWzVBZVFShn5yntxVd7 ``` -За лаштунками створення нових одиниць токена потребує виклику інструкції `MintTo` -у Програмі Токенів. Ця інструкція повинна бути підписана авторитетом випуску. -Інструкція випускає нові одиниці токена до Токен-облікового запису та збільшує -загальну кількість у Обліковому записі випуску токенів. Ось приклад на Javascript у + +За лаштунками створення нових одиниць токена потребує виклику інструкції +`MintTo` у Програмі Токенів. Ця інструкція повинна бути підписана авторитетом +випуску. Інструкція випускає нові одиниці токена до Токен-облікового запису та +збільшує загальну кількість у Обліковому записі випуску токенів. Ось приклад на +Javascript у [Solana Playground](https://beta.solpg.io/660cea45cffcf4b13384d012). ### Передача токенів @@ -458,17 +495,21 @@ Signature: 3SQvNM3o9DsTiLwcEkSPT1Edr14RgE2wC54TEjonEP2swyVCp2jPWYWdD6RwXUGpvDNUk spl-token transfer [OPTIONS] ``` + Наприклад, виконання наступної команди: + ```sh spl-token transfer 99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg 100 Hmyk3FSw4cfsuAes7sanp2oxSkE9ivaH6pMzDzbacqmt ``` + Повертає наступний результат: -- `AfB7uwBEsGtrrBqPTVqEgzWed5XdYfM1psPNLmf7EeX9` — це адреса токен-облікового запису, - з якого передаються токени. Це буде адреса вашого токен-облікового запису для - вказаного токена, який передається. -- `Hmyk3FSw4cfsuAes7sanp2oxSkE9ivaH6pMzDzbacqmt` — це адреса токен-облікового запису, - до якого передаються токени. +- `AfB7uwBEsGtrrBqPTVqEgzWed5XdYfM1psPNLmf7EeX9` — це адреса токен-облікового + запису, з якого передаються токени. Це буде адреса вашого токен-облікового + запису для вказаного токена, який передається. + +- `Hmyk3FSw4cfsuAes7sanp2oxSkE9ivaH6pMzDzbacqmt` — це адреса токен-облікового + запису, до якого передаються токени. ```shell filename="Terminal Output" /AfB7uwBEsGtrrBqPTVqEgzWed5XdYfM1psPNLmf7EeX9/ /Hmyk3FSw4cfsuAes7sanp2oxSkE9ivaH6pMzDzbacqmt/ Transfer 100 tokens @@ -477,21 +518,23 @@ Transfer 100 tokens Signature: 5y6HVwV8V2hHGLTVmTmdySRiEUCZnWmkasAvJ7J6m7JR46obbGKCBqUFgLpZu5zQGwM4Xy6GZ4M5LKd1h6Padx3o ``` -За лаштунками, передача токенів потребує виклику інструкції `Transfer` у Програмі Токенів. -Ця інструкція повинна бути підписана власником токен-облікового запису відправника. -Інструкція передає одиниці токена з одного Токен-облікового запису до іншого. -Ось приклад на Javascript у + +За лаштунками, передача токенів потребує виклику інструкції `Transfer` у +Програмі Токенів. Ця інструкція повинна бути підписана власником +токен-облікового запису відправника. Інструкція передає одиниці токена з одного +Токен-облікового запису до іншого. Ось приклад на Javascript у [Solana Playground](https://beta.solpg.io/660ced84cffcf4b13384d013). -Важливо розуміти, що як у відправника, так і у одержувача повинні існувати токен-облікові -записи для конкретного типу токена, який передається. Відправник може додати додаткові -інструкції до транзакції для створення токен-облікового запису одержувача, який, як правило, -є Асоційованим Токен-обліковим записом. +Важливо розуміти, що як у відправника, так і у одержувача повинні існувати +токен-облікові записи для конкретного типу токена, який передається. Відправник +може додати додаткові інструкції до транзакції для створення токен-облікового +запису одержувача, який, як правило, є Асоційованим Токен-обліковим записом. ### Створення метаданих токенів -Програма Розширень Токенів дозволяє додавати настроювані метадані (наприклад, назву, -символ, посилання на зображення) безпосередньо до Облікового запису випуску токенів. +Програма Розширень Токенів дозволяє додавати настроювані метадані (наприклад, +назву, символ, посилання на зображення) безпосередньо до Облікового запису +випуску токенів. Щоб використовувати параметри CLI для розширень токенів, переконайтеся, що ви маєте @@ -500,15 +543,17 @@ Signature: 5y6HVwV8V2hHGLTVmTmdySRiEUCZnWmkasAvJ7J6m7JR46obbGKCBqUFgLpZu5zQGwM4X `cargo install --version 3.4.0 spl-token-cli` -Щоб створити новий токен із увімкненим розширенням метаданих, скористайтеся наступною командою: +Щоб створити новий токен із увімкненим розширенням метаданих, скористайтеся +наступною командою: ```sh spl-token create-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb --enable-metadata ``` + Команда повертає наступний результат: -- `BdhzpzhTD1MFqBiwNdrRy4jFo2FHFufw3n9e8sVjJczP` — це адреса нового токена, +- `BdhzpzhTD1MFqBiwNdrRy4jFo2FHFufw3n9e8sVjJczP` — це адреса нового токена, створеного з увімкненим розширенням метаданих. ```shell filename="Terminal Output" /BdhzpzhTD1MFqBiwNdrRy4jFo2FHFufw3n9e8sVjJczP/ @@ -520,7 +565,8 @@ Decimals: 9 Signature: 5iQofFeXdYhMi9uTzZghcq8stAaa6CY6saUwcdnELST13eNSifiuLbvR5DnRt311frkCTUh5oecj8YEvZSB3wfai ``` -Після створення нового токена з увімкненим розширенням метаданих використовуйте + +Після створення нового токена з увімкненим розширенням метаданих використовуйте наступну команду для ініціалізації метаданих: ```sh @@ -528,24 +574,24 @@ spl-token initialize-metadata ``` -Токен URI зазвичай є посиланням на позаблокові метадані, які ви хочете -асоціювати з токеном. Приклад формату JSON можна знайти +Токен URI зазвичай є посиланням на позаблокові метадані, які ви хочете +асоціювати з токеном. Приклад формату JSON можна знайти [тут](https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/DeveloperPortal/metadata.json). -Наприклад, виконання наступної команди дозволить зберегти додаткові метадані +Наприклад, виконання наступної команди дозволить зберегти додаткові метадані безпосередньо в зазначеному обліковому записі випуску токенів: ```sh /BdhzpzhTD1MFqBiwNdrRy4jFo2FHFufw3n9e8sVjJczP/ spl-token initialize-metadata BdhzpzhTD1MFqBiwNdrRy4jFo2FHFufw3n9e8sVjJczP "TokenName" "TokenSymbol" "https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/DeveloperPortal/metadata.json" ``` -Ви можете знайти адресу облікового запису випуску токенів у експлорері, щоб -переглянути метадані. Наприклад, ось токен, створений із увімкненим розширенням -метаданих, у експлорері +Ви можете знайти адресу облікового запису випуску токенів у експлорері, щоб +переглянути метадані. Наприклад, ось токен, створений із увімкненим розширенням +метаданих, у експлорері [SolanaFm](https://solana.fm/address/BdhzpzhTD1MFqBiwNdrRy4jFo2FHFufw3n9e8sVjJczP?cluster=devnet-solana). -Дізнатися більше можна у -[Посібнику з Розширення Метаданих](https://solana.com/developers/guides/token-extensions/metadata-pointer). -Деталі щодо різних Розширень Токенів ви знайдете у -[Посібнику Початківця з Розширень Токенів](https://solana.com/developers/guides/token-extensions/getting-started) +Дізнатися більше можна у +[Посібнику з Розширення Метаданих](https://solana.com/developers/guides/token-extensions/metadata-pointer). +Деталі щодо різних Розширень Токенів ви знайдете у +[Посібнику Початківця з Розширень Токенів](https://solana.com/developers/guides/token-extensions/getting-started) та [документації SPL](https://spl.solana.com/token-2022/extensions). diff --git a/docs/locales/uk/core/transactions.md b/docs/locales/uk/core/transactions.md index 610c168fd..400dfe83b 100644 --- a/docs/locales/uk/core/transactions.md +++ b/docs/locales/uk/core/transactions.md @@ -10,9 +10,9 @@ description: У Solana ми надсилаємо [транзакції](/docs/uk/core/transactions#transaction), щоб взаємодіяти з мережею. Транзакції включають одну або більше [інструкцій](/docs/uk/core/transactions#instruction), кожна з яких представляє -конкретну операцію, що має бути оброблена. Логіка виконання інструкцій зберігається -в [програмах](/docs/uk/core/programs), розгорнутих у мережі Solana, і кожна програма -зберігає свій набір інструкцій. +конкретну операцію, що має бути оброблена. Логіка виконання інструкцій +зберігається в [програмах](/docs/uk/core/programs), розгорнутих у мережі Solana, +і кожна програма зберігає свій набір інструкцій. Нижче наведено основні деталі щодо виконання транзакцій: @@ -75,8 +75,9 @@ description: ### Простий переказ SOL -Ось приклад із [Solana Playground](https://beta.solpg.io/656a0ea7fb53fa325bfd0c3e), -який демонструє, як створити інструкцію переказу SOL за допомогою методу +Ось приклад із +[Solana Playground](https://beta.solpg.io/656a0ea7fb53fa325bfd0c3e), який +демонструє, як створити інструкцію переказу SOL за допомогою методу `SystemProgram.transfer`: ```typescript @@ -93,11 +94,13 @@ const transferInstruction = SystemProgram.transfer({ // Додавання інструкції переказу до нової транзакції const transaction = new Transaction().add(transferInstruction); ``` -Запустіть скрипт і перевірте деталі транзакції, що виводяться в консоль. У наступних розділах ми розглянемо, що відбувається "під капотом". + +Запустіть скрипт і перевірте деталі транзакції, що виводяться в консоль. У +наступних розділах ми розглянемо, що відбувається "під капотом". ## Транзакція -Транзакція Solana +Транзакція Solana [transaction](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/src/transaction/mod.rs#L173) складається з: @@ -110,30 +113,43 @@ const transaction = new Transaction().add(transferInstruction); Структура повідомлення транзакції складається з: -- [Заголовка повідомлення](/docs/uk/core/transactions#message-header): Вказує кількість підписантів та облікових записів тільки для читання. -- [Масиву адрес облікових записів](/docs/uk/core/transactions#array-of-account-addresses): Масив адрес облікових записів, необхідних для інструкцій у транзакції. -- [Недавнього блоку хешу](/docs/uk/core/transactions#recent-blockhash): Використовується як мітка часу для транзакції. -- [Масиву інструкцій](/docs/uk/core/transactions#array-of-instructions): Масив інструкцій, які слід виконати. +- [Заголовка повідомлення](/docs/uk/core/transactions#message-header): Вказує + кількість підписантів та облікових записів тільки для читання. +- [Масиву адрес облікових записів](/docs/uk/core/transactions#array-of-account-addresses): + Масив адрес облікових записів, необхідних для інструкцій у транзакції. +- [Недавнього блоку хешу](/docs/uk/core/transactions#recent-blockhash): + Використовується як мітка часу для транзакції. +- [Масиву інструкцій](/docs/uk/core/transactions#array-of-instructions): Масив + інструкцій, які слід виконати. ![Повідомлення транзакції](/assets/docs/core/transactions/legacy_message.png) ### Розмір транзакції -Мережа Solana дотримується максимального розміру пакета (MTU) у 1280 байт, що відповідає -[MTU IPv6](https://en.wikipedia.org/wiki/IPv6_packet). Це забезпечує швидку та надійну передачу інформації у кластері через UDP. Після врахування необхідних заголовків (40 байт для IPv6 та 8 байт для заголовка фрагмента), -[1232 байти залишаються для даних пакета](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/src/packet.rs#L16-L21), таких як серіалізовані транзакції. +Мережа Solana дотримується максимального розміру пакета (MTU) у 1280 байт, що +відповідає [MTU IPv6](https://en.wikipedia.org/wiki/IPv6_packet). Це забезпечує +швидку та надійну передачу інформації у кластері через UDP. Після врахування +необхідних заголовків (40 байт для IPv6 та 8 байт для заголовка фрагмента), +[1232 байти залишаються для даних пакета](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/src/packet.rs#L16-L21), +таких як серіалізовані транзакції. -Це означає, що загальний розмір транзакції Solana обмежений 1232 байтами. Підписи та повідомлення у комбінації не можуть перевищувати цей ліміт. +Це означає, що загальний розмір транзакції Solana обмежений 1232 байтами. +Підписи та повідомлення у комбінації не можуть перевищувати цей ліміт. -- Підписи: Кожен підпис займає 64 байти. Кількість підписів може варіювати залежно від вимог транзакції. -- Повідомлення: Повідомлення включає інструкції, облікові записи та додаткові метадані. Кожен обліковий запис займає 32 байти. Загальний розмір облікових записів плюс метадані може варіювати залежно від інструкцій у транзакції. +- Підписи: Кожен підпис займає 64 байти. Кількість підписів може варіювати + залежно від вимог транзакції. +- Повідомлення: Повідомлення включає інструкції, облікові записи та додаткові + метадані. Кожен обліковий запис займає 32 байти. Загальний розмір облікових + записів плюс метадані може варіювати залежно від інструкцій у транзакції. ![Формат транзакції](/assets/docs/core/transactions/issues_with_legacy_txs.png) ### Заголовок повідомлення [Заголовок повідомлення](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/message/mod.rs#L96) -вказує на привілеї облікових записів, включених у масив адрес транзакції. Він складається з трьох байтів, кожен з яких містить ціле число типу u8, що колективно вказує: +вказує на привілеї облікових записів, включених у масив адрес транзакції. Він +складається з трьох байтів, кожен з яких містить ціле число типу u8, що +колективно вказує: 1. Кількість необхідних підписів для транзакції. 2. Кількість облікових записів тільки для читання, які потребують підписів. @@ -143,7 +159,8 @@ const transaction = new Transaction().add(transferInstruction); ### Формат компактного масиву -Компактний масив у контексті повідомлення транзакції посилається на масив, серіалізований у наступному форматі: +Компактний масив у контексті повідомлення транзакції посилається на масив, +серіалізований у наступному форматі: 1. Довжина масиву, закодована як [compact-u16](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/short_vec.rs). @@ -151,18 +168,22 @@ const transaction = new Transaction().add(transferInstruction); ![Формат компактного масиву](/assets/docs/core/transactions/compact_array_format.png) -Цей метод кодування використовується для вказівки довжин як -[масиву адрес облікових записів](/docs/uk/core/transactions#array-of-account-addresses), так і -[масиву інструкцій](/docs/uk/core/transactions#array-of-instructions) у повідомленні транзакції. +Цей метод кодування використовується для вказівки довжин як +[масиву адрес облікових записів](/docs/uk/core/transactions#array-of-account-addresses), +так і [масиву інструкцій](/docs/uk/core/transactions#array-of-instructions) у +повідомленні транзакції. ### Масив адрес облікових записів -Повідомлення транзакції включає масив, що містить усі +Повідомлення транзакції включає масив, що містить усі [адреси облікових записів](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/message/legacy.rs#L119), необхідні для інструкцій у транзакції. -Цей масив починається з кодування -[compact-u16](/docs/uk/core/transactions#compact-array-format) довжини масиву, після чого йдуть адреси, впорядковані за привілеями облікових записів. Метадані в заголовку повідомлення використовуються для визначення кількості облікових записів у кожному розділі. +Цей масив починається з кодування +[compact-u16](/docs/uk/core/transactions#compact-array-format) довжини масиву, +після чого йдуть адреси, впорядковані за привілеями облікових записів. Метадані +в заголовку повідомлення використовуються для визначення кількості облікових +записів у кожному розділі. - Облікові записи, що є змінюваними та підписантами. - Облікові записи тільки для читання, що є підписантами. @@ -173,42 +194,66 @@ const transaction = new Transaction().add(transferInstruction); ### Недавній блок-хеш -Усі транзакції включають +Усі транзакції включають [недавній блок-хеш](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/message/legacy.rs#L122), -який використовується як мітка часу для транзакції. Блок-хеш запобігає дублюванню транзакцій і виключає застарілі транзакції. - -Максимальний вік блок-хеша для транзакції становить 150 блоків (~1 хвилина, якщо час блоку складає 400 мс). Якщо блок-хеш транзакції старіший за 150 блоків від останнього блок-хеша, вона вважається протермінованою. Це означає, що транзакції, які не були оброблені вчасно, ніколи не будуть виконані. - -Ви можете скористатися RPC-методом -[`getLatestBlockhash`](/docs/uk/rpc/http/getlatestblockhash), -щоб отримати поточний блок-хеш і останню висоту блоку, на якій блок-хеш залишатиметься дійсним. Ось приклад у +який використовується як мітка часу для транзакції. Блок-хеш запобігає +дублюванню транзакцій і виключає застарілі транзакції. + +Максимальний вік блок-хеша для транзакції становить 150 блоків (~1 хвилина, якщо +час блоку складає 400 мс). Якщо блок-хеш транзакції старіший за 150 блоків від +останнього блок-хеша, вона вважається протермінованою. Це означає, що +транзакції, які не були оброблені вчасно, ніколи не будуть виконані. + +Ви можете скористатися RPC-методом +[`getLatestBlockhash`](/docs/uk/rpc/http/getlatestblockhash), щоб отримати +поточний блок-хеш і останню висоту блоку, на якій блок-хеш залишатиметься +дійсним. Ось приклад у [Solana Playground](https://beta.solpg.io/661a06e1cffcf4b13384d046). + ### Масив інструкцій -Повідомлення транзакції включає масив усіх +Повідомлення транзакції включає масив усіх [інструкцій](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/message/legacy.rs#L128), які запитуються для обробки. Інструкції у повідомленні транзакції мають формат [CompiledInstruction](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/instruction.rs#L633). -Подібно до масиву адрес облікових записів, цей компактний масив починається з кодування -[compact-u16](/docs/uk/core/transactions#compact-array-format) кількості інструкцій, після чого йде масив інструкцій. Кожна інструкція в масиві вказує наступну інформацію: - -1. **Program ID**: Ідентифікатор програми в мережі, яка оброблятиме інструкцію. Це представлено у вигляді індексу типу u8, що вказує на адресу програми у масиві адрес облікових записів. -2. **Компактний масив індексів адрес облікових записів**: Масив індексів типу u8, що вказує на масив адрес облікових записів для кожного облікового запису, потрібного для інструкції. -3. **Компактний масив байтів даних**: Масив байтів типу u8, специфічний для викликаної програми. Ці дані вказують, яку інструкцію викликати у програмі, разом із будь-якими додатковими даними, потрібними для виконання інструкції (наприклад, аргументами функції). +Подібно до масиву адрес облікових записів, цей компактний масив починається з +кодування [compact-u16](/docs/uk/core/transactions#compact-array-format) +кількості інструкцій, після чого йде масив інструкцій. Кожна інструкція в масиві +вказує наступну інформацію: + +1. **Program ID**: Ідентифікатор програми в мережі, яка оброблятиме інструкцію. + Це представлено у вигляді індексу типу u8, що вказує на адресу програми у + масиві адрес облікових записів. +2. **Компактний масив індексів адрес облікових записів**: Масив індексів типу + u8, що вказує на масив адрес облікових записів для кожного облікового запису, + потрібного для інструкції. +3. **Компактний масив байтів даних**: Масив байтів типу u8, специфічний для + викликаної програми. Ці дані вказують, яку інструкцію викликати у програмі, + разом із будь-якими додатковими даними, потрібними для виконання інструкції + (наприклад, аргументами функції). ![Компактний масив інструкцій](/assets/docs/core/transactions/compact_array_of_ixs.png) ### Приклад структури транзакції -Нижче наведено приклад структури транзакції, яка включає одну інструкцію для -[передачі SOL](/docs/uk/core/transactions#basic-example). Тут показано деталі повідомлення, включаючи заголовок, ключі облікових записів, блок-хеш та інструкції, разом із підписом для транзакції. +Нижче наведено приклад структури транзакції, яка включає одну інструкцію для +[передачі SOL](/docs/uk/core/transactions#basic-example). Тут показано деталі +повідомлення, включаючи заголовок, ключі облікових записів, блок-хеш та +інструкції, разом із підписом для транзакції. -- `header`: Містить дані, які використовуються для вказання привілеїв читання/запису та підписання у масиві `accountKeys`. -- `accountKeys`: Масив, що включає адреси облікових записів для всіх інструкцій у транзакції. +- `header`: Містить дані, які використовуються для вказання привілеїв + читання/запису та підписання у масиві `accountKeys`. +- `accountKeys`: Масив, що включає адреси облікових записів для всіх інструкцій + у транзакції. - `recentBlockhash`: Блок-хеш, включений у транзакцію під час її створення. -- `instructions`: Масив, що включає всі інструкції у транзакції. Кожен `account` та `programIdIndex` в інструкції посилаються на масив `accountKeys` за індексом. -- `signatures`: Масив, що включає підписи для всіх облікових записів, потрібних як підписанти для інструкцій у транзакції. Підпис створюється шляхом підписання повідомлення транзакції за допомогою відповідного приватного ключа для облікового запису. +- `instructions`: Масив, що включає всі інструкції у транзакції. Кожен `account` + та `programIdIndex` в інструкції посилаються на масив `accountKeys` за + індексом. +- `signatures`: Масив, що включає підписи для всіх облікових записів, потрібних + як підписанти для інструкцій у транзакції. Підпис створюється шляхом + підписання повідомлення транзакції за допомогою відповідного приватного ключа + для облікового запису. ```json "transaction": { @@ -242,45 +287,58 @@ const transaction = new Transaction().add(transferInstruction); ] } ``` + ## Інструкція [Інструкція](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/instruction.rs#L329) -— це запит на виконання конкретної дії в мережі. Це найменша неподільна одиниця логіки виконання у -[програмі](/docs/uk/core/accounts#program-account). +— це запит на виконання конкретної дії в мережі. Це найменша неподільна одиниця +логіки виконання у [програмі](/docs/uk/core/accounts#program-account). -При створенні інструкції для додавання до транзакції кожна інструкція повинна включати наступну інформацію: +При створенні інструкції для додавання до транзакції кожна інструкція повинна +включати наступну інформацію: - **Адреса програми**: Вказує програму, яку буде викликано. -- **Облікові записи**: Перелік кожного облікового запису, з якого інструкція читає або до якого пише, включаючи інші програми, за допомогою структури `AccountMeta`. -- **Дані інструкції**: Масив байтів, що вказує, який - [обробник інструкцій](/docs/uk/terminology#instruction-handler) викликати у програмі, а також будь-які додаткові дані, необхідні обробнику інструкцій (аргументи функції). +- **Облікові записи**: Перелік кожного облікового запису, з якого інструкція + читає або до якого пише, включаючи інші програми, за допомогою структури + `AccountMeta`. +- **Дані інструкції**: Масив байтів, що вказує, який + [обробник інструкцій](/docs/uk/terminology#instruction-handler) викликати у + програмі, а також будь-які додаткові дані, необхідні обробнику інструкцій + (аргументи функції). ![Інструкція транзакції](/assets/docs/core/transactions/instruction.svg) ### AccountMeta -Для кожного облікового запису, необхідного для інструкції, потрібно вказати наступну інформацію: +Для кожного облікового запису, необхідного для інструкції, потрібно вказати +наступну інформацію: - `pubkey`: Адреса облікового запису в мережі. - `is_signer`: Вказує, чи є обліковий запис підписантом у транзакції. - `is_writable`: Вказує, чи будуть змінені дані облікового запису. -Ця інформація називається +Ця інформація називається [AccountMeta](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/instruction.rs#L539). ![AccountMeta](/assets/docs/core/transactions/accountmeta.svg) -Завдяки вказанню всіх облікових записів, необхідних для інструкції, і зазначенню, які з них можуть бути змінені, транзакції можуть виконуватися паралельно. +Завдяки вказанню всіх облікових записів, необхідних для інструкції, і +зазначенню, які з них можуть бути змінені, транзакції можуть виконуватися +паралельно. -Наприклад, дві транзакції, які не включають жодних облікових записів, що записують в той самий стан, можуть виконуватися одночасно. +Наприклад, дві транзакції, які не включають жодних облікових записів, що +записують в той самий стан, можуть виконуватися одночасно. ### Приклад структури інструкції -Нижче наведено приклад структури інструкції для -[передачі SOL](/docs/uk/core/transactions#basic-examples), яка деталізує ключі облікових записів, ідентифікатор програми та дані, необхідні для інструкції. +Нижче наведено приклад структури інструкції для +[передачі SOL](/docs/uk/core/transactions#basic-examples), яка деталізує ключі +облікових записів, ідентифікатор програми та дані, необхідні для інструкції. -- `keys`: Містить `AccountMeta` для кожного облікового запису, необхідного для інструкції. -- `programId`: Адреса програми, яка містить логіку виконання для викликаної інструкції. +- `keys`: Містить `AccountMeta` для кожного облікового запису, необхідного для + інструкції. +- `programId`: Адреса програми, яка містить логіку виконання для викликаної + інструкції. - `data`: Дані інструкції у вигляді буфера байтів. ``` @@ -301,13 +359,18 @@ const transaction = new Transaction().add(transferInstruction); "data": [2,0,0,0,128,150,152,0,0,0,0,0] } ``` + ## Розширений приклад -Деталі створення програмних інструкцій часто приховуються клієнтськими бібліотеками. Проте, якщо такої бібліотеки немає, завжди можна вручну створити інструкцію. +Деталі створення програмних інструкцій часто приховуються клієнтськими +бібліотеками. Проте, якщо такої бібліотеки немає, завжди можна вручну створити +інструкцію. ### Ручна передача SOL -Ось приклад на [Solana Playground](https://beta.solpg.io/656a102efb53fa325bfd0c3f), який демонструє, як вручну створити інструкцію для передачі SOL: +Ось приклад на +[Solana Playground](https://beta.solpg.io/656a102efb53fa325bfd0c3f), який +демонструє, як вручну створити інструкцію для передачі SOL: ```typescript // Define the amount to transfer @@ -336,5 +399,9 @@ const transferInstruction = new TransactionInstruction({ // Add the transfer instruction to a new transaction const transaction = new Transaction().add(transferInstruction); ``` -Під капотом [простий приклад](/docs/uk/core/transactions#simple-sol-transfer) з використанням методу `SystemProgram.transfer` функціонально еквівалентний більш детальному прикладу вище. Метод `SystemProgram.transfer` просто приховує деталі створення буфера даних інструкції та `AccountMeta` для кожного облікового запису, необхідного для інструкції. +Під капотом [простий приклад](/docs/uk/core/transactions#simple-sol-transfer) з +використанням методу `SystemProgram.transfer` функціонально еквівалентний більш +детальному прикладу вище. Метод `SystemProgram.transfer` просто приховує деталі +створення буфера даних інструкції та `AccountMeta` для кожного облікового +запису, необхідного для інструкції. diff --git a/docs/locales/uk/economics/index.md b/docs/locales/uk/economics/index.md index ecfa6d94f..512f698e6 100644 --- a/docs/locales/uk/economics/index.md +++ b/docs/locales/uk/economics/index.md @@ -8,14 +8,45 @@ sidebarSortOrder: 5 **Може бути змінено.** -Криптоекономічна система Solana розроблена для сприяння здоровій, довгостроковій самопідтримуваній економіці, в якій стимули учасників узгоджуються із забезпеченням безпеки та децентралізації мережі. Основними учасниками цієї економіки є валідаційні клієнти. Їхній внесок у мережу, перевірка стану та відповідні механізми стимулювання розглядаються нижче. +Криптоекономічна система Solana розроблена для сприяння здоровій, довгостроковій +самопідтримуваній економіці, в якій стимули учасників узгоджуються із +забезпеченням безпеки та децентралізації мережі. Основними учасниками цієї +економіки є валідаційні клієнти. Їхній внесок у мережу, перевірка стану та +відповідні механізми стимулювання розглядаються нижче. -Основними каналами винагород для учасників є винагороди, засновані на протоколі, та транзакційні комісії. Винагороди, засновані на протоколі, генеруються за рахунок інфляційного випуску згідно з визначеним протоколом графіком інфляції. Ці винагороди становитимуть загальну винагороду на основі протоколу, яка буде надаватися валідаційним клієнтам, решта забезпечується за рахунок транзакційних комісій. У перші дні роботи мережі ймовірно, що винагороди, засновані на протоколі, розподілені згідно з попередньо визначеним графіком випуску, стануть основним стимулом для учасників мережі. +Основними каналами винагород для учасників є винагороди, засновані на протоколі, +та транзакційні комісії. Винагороди, засновані на протоколі, генеруються за +рахунок інфляційного випуску згідно з визначеним протоколом графіком інфляції. +Ці винагороди становитимуть загальну винагороду на основі протоколу, яка буде +надаватися валідаційним клієнтам, решта забезпечується за рахунок транзакційних +комісій. У перші дні роботи мережі ймовірно, що винагороди, засновані на +протоколі, розподілені згідно з попередньо визначеним графіком випуску, стануть +основним стимулом для учасників мережі. -Ці винагороди розраховуються за кожну епоху і розподіляються серед активного делегованого стейку та набору валідаторів (з урахуванням комісії валідаторів). Як описано нижче, річний рівень інфляції ґрунтується на визначеному дисінфляційному графіку. Це забезпечує мережі передбачуваність поставок, що підтримує довгострокову економічну стабільність та безпеку. +Ці винагороди розраховуються за кожну епоху і розподіляються серед активного +делегованого стейку та набору валідаторів (з урахуванням комісії валідаторів). +Як описано нижче, річний рівень інфляції ґрунтується на визначеному +дисінфляційному графіку. Це забезпечує мережі передбачуваність поставок, що +підтримує довгострокову економічну стабільність та безпеку. -Транзакційні комісії є переказами між учасниками, що додаються до взаємодії з мережею як стимул та компенсація за включення і виконання запропонованої транзакції. Також обговорюється механізм довгострокової економічної стабільності та захисту від розгалужень через часткове спалювання кожної транзакційної комісії. +Транзакційні комісії є переказами між учасниками, що додаються до взаємодії з +мережею як стимул та компенсація за включення і виконання запропонованої +транзакції. Також обговорюється механізм довгострокової економічної стабільності +та захисту від розгалужень через часткове спалювання кожної транзакційної +комісії. -Спочатку подано огляд дизайну інфляції. Цей розділ починається з визначення та уточнення [Термінології](/docs/uk/economics/inflation/terminology.md), що часто використовується у подальшому обговоренні інфляції та пов'язаних компонентів. Далі ми окреслюємо запропонований [Графік Інфляції](/docs/uk/economics/inflation/inflation_schedule.md) Solana, тобто конкретні параметри, які унікально визначають інфляційний випуск, керований протоколом, з плином часу. Наступним є короткий розділ про [Скориговану Доходність Стейкінгу](/docs/uk/economics/inflation/_adjusted_staking_yield.md) і те, як розбавлення токенів може вплинути на поведінку стейкінгу. +Спочатку подано огляд дизайну інфляції. Цей розділ починається з визначення та +уточнення [Термінології](/docs/uk/economics/inflation/terminology.md), що часто +використовується у подальшому обговоренні інфляції та пов'язаних компонентів. +Далі ми окреслюємо запропонований +[Графік Інфляції](/docs/uk/economics/inflation/inflation_schedule.md) Solana, +тобто конкретні параметри, які унікально визначають інфляційний випуск, +керований протоколом, з плином часу. Наступним є короткий розділ про +[Скориговану Доходність Стейкінгу](/docs/uk/economics/inflation/_adjusted_staking_yield.md) +і те, як розбавлення токенів може вплинути на поведінку стейкінгу. -Огляд [Транзакційних Комісій](/docs/uk/core/fees.md#transaction-fees) у Solana супроводжується обговоренням [Економіки Оренди для Зберігання](/docs/uk/core/fees.md#rent), у якому описується реалізація орендної плати за зберігання для обліку зовнішніх витрат на підтримання активного стану реєстру. +Огляд [Транзакційних Комісій](/docs/uk/core/fees.md#transaction-fees) у Solana +супроводжується обговоренням +[Економіки Оренди для Зберігання](/docs/uk/core/fees.md#rent), у якому +описується реалізація орендної плати за зберігання для обліку зовнішніх витрат +на підтримання активного стану реєстру. diff --git a/docs/locales/uk/economics/inflation/_adjusted_staking_yield.md b/docs/locales/uk/economics/inflation/_adjusted_staking_yield.md index a515b96f7..566f3676d 100644 --- a/docs/locales/uk/economics/inflation/_adjusted_staking_yield.md +++ b/docs/locales/uk/economics/inflation/_adjusted_staking_yield.md @@ -4,19 +4,33 @@ title: Скоригована Дохідність Стейкінгу ### Дилюція Токенів -Подібним чином ми можемо розглянути очікувану _Дилюцію Стейкінгу_ (тобто _Скориговану Дохідність Стейкінгу_) та _Дилюцію Нестейкінгованих Токенів_, як було визначено раніше. У цьому контексті _дилюція_ означає зміну фракційного представлення (тобто частки власності) набору токенів у рамках більшого пулу. У цьому сенсі дилюція може бути позитивною (збільшення частки власності, стейкінгова дилюція / _Скоригована Дохідність Стейкінгу_) або негативною (зменшення частки власності, нестейкінгова дилюція). - -Нас цікавить відносна зміна власності стейкінгованих і нестейкінгованих токенів у міру збільшення загального пулу токенів через інфляційний випуск. Як було зазначено, цей випуск розподіляється лише серед власників стейкінгованих токенів, збільшуючи їх частку у _Загальному Поточному Обсязі_. - -Продовжуючи з тими ж параметрами _Графіку Інфляції_, що й раніше, ми бачимо зростання частки стейкінгового пулу, як показано нижче. +Подібним чином ми можемо розглянути очікувану _Дилюцію Стейкінгу_ (тобто +_Скориговану Дохідність Стейкінгу_) та _Дилюцію Нестейкінгованих Токенів_, як +було визначено раніше. У цьому контексті _дилюція_ означає зміну фракційного +представлення (тобто частки власності) набору токенів у рамках більшого пулу. У +цьому сенсі дилюція може бути позитивною (збільшення частки власності, +стейкінгова дилюція / _Скоригована Дохідність Стейкінгу_) або негативною +(зменшення частки власності, нестейкінгова дилюція). + +Нас цікавить відносна зміна власності стейкінгованих і нестейкінгованих токенів +у міру збільшення загального пулу токенів через інфляційний випуск. Як було +зазначено, цей випуск розподіляється лише серед власників стейкінгованих +токенів, збільшуючи їх частку у _Загальному Поточному Обсязі_. + +Продовжуючи з тими ж параметрами _Графіку Інфляції_, що й раніше, ми бачимо +зростання частки стейкінгового пулу, як показано нижче. ![Графік зростання частки стейкінгового пулу](/assets/docs/economics/example_staked_supply_w_range_initial_stake.png) -Через цю відносну зміну у представництві частка стейкінгу будь-якого власника токенів також змінюється як функція _Графіку Інфляції_ та частки стейкінгованих токенів. +Через цю відносну зміну у представництві частка стейкінгу будь-якого власника +токенів також змінюється як функція _Графіку Інфляції_ та частки стейкінгованих +токенів. ### Розрахунок Дилюції Нестейкінгованих Токенів -Особливий інтерес викликає _Дилюція Нестейкінгованих Токенів_, або $D_{us}$. У випадку нестейкінгованих токенів дилюція залежить лише від _Графіку Інфляції_, оскільки кількість нестейкінгованих токенів не змінюється з часом. +Особливий інтерес викликає _Дилюція Нестейкінгованих Токенів_, або $D_{us}$. У +випадку нестейкінгованих токенів дилюція залежить лише від _Графіку Інфляції_, +оскільки кількість нестейкінгованих токенів не змінюється з часом. $$ \begin{aligned} @@ -25,7 +39,8 @@ $$ \end{aligned} $$ -Оскільки випуск інфляції лише збільшує загальну кількість токенів, а нестейкінгована кількість залишається незмінною: +Оскільки випуск інфляції лише збільшує загальну кількість токенів, а +нестейкінгована кількість залишається незмінною: $$ \begin{aligned} @@ -41,7 +56,8 @@ $$ ### Оцінка Скоригованої Дохідності Стейкінгу -Ми також можемо розрахувати _Скориговану Дохідність Стейкінгу_ $Y_{adj}$ як зміну частки стейкінгованих токенів у пулі: +Ми також можемо розрахувати _Скориговану Дохідність Стейкінгу_ $Y_{adj}$ як +зміну частки стейкінгованих токенів у пулі: $$ Y_{adj} = \frac{P_s(t_2) - P_s(t_1)}{P_s(t_1)} @@ -55,12 +71,17 @@ $$ ### Відносна Дилюція -Відношення $D_{us}/Y_{adj}$ дозволяє зрозуміти, наскільки сильніше нестейкінговані токени піддаються дилюції у порівнянні зі стейкінгованими: +Відношення $D_{us}/Y_{adj}$ дозволяє зрозуміти, наскільки сильніше +нестейкінговані токени піддаються дилюції у порівнянні зі стейкінгованими: $$ \frac{D_{us}}{Y_{adj}} = \frac{ P_s }{ 1 - P_s } $$ -На основі цього видно, що збільшення частки стейкінгованих токенів значно збільшує дилюцію нестейкінгованих токенів. Наприклад, якщо $80\%$ токенів мережі стейкінговано, власник нестейкінгованих токенів зіткнеться з дилюцією у $400\%$ більшою, ніж стейкінгований власник. +На основі цього видно, що збільшення частки стейкінгованих токенів значно +збільшує дилюцію нестейкінгованих токенів. Наприклад, якщо $80\%$ токенів мережі +стейкінговано, власник нестейкінгованих токенів зіткнеться з дилюцією у $400\%$ +більшою, ніж стейкінгований власник. -Це підкреслює стимул для власників токенів до стейкінгу, щоб отримати _Дохідність Стейкінгу_ та уникнути _Дилюції Нестейкінгованих Токенів_. +Це підкреслює стимул для власників токенів до стейкінгу, щоб отримати +_Дохідність Стейкінгу_ та уникнути _Дилюції Нестейкінгованих Токенів_. diff --git a/docs/locales/uk/economics/inflation/inflation-schedule.md b/docs/locales/uk/economics/inflation/inflation-schedule.md index f9d69885d..dab4750e1 100644 --- a/docs/locales/uk/economics/inflation/inflation-schedule.md +++ b/docs/locales/uk/economics/inflation/inflation-schedule.md @@ -6,37 +6,78 @@ altRoutes: - /docs/uk/intro/economics --- -Як було зазначено вище, _Графік Інфляції_ мережі унікально описується трьома параметрами: _Початкова Ставка Інфляції_, _Ставка Дезінфляції_ та _Довгострокова Ставка Інфляції_. При розгляді цих значень слід враховувати багато факторів: +Як було зазначено вище, _Графік Інфляції_ мережі унікально описується трьома +параметрами: _Початкова Ставка Інфляції_, _Ставка Дезінфляції_ та _Довгострокова +Ставка Інфляції_. При розгляді цих значень слід враховувати багато факторів: -- Значна частина SOL, випущених через інфляцію, буде розподілена між власниками стейкінгу пропорційно до кількості стейкінгованих SOL. Ми хочемо переконатися, що дизайн _Графіку Інфляції_ забезпечує розумну _Дохідність Стейкінгу_ для власників токенів, які делегують SOL, та провайдерів послуг валідації (через комісії, які беруться з _Дохідності Стейкінгу_). -- Основний драйвер _Дохідності Стейкінгу_ — це кількість SOL у стейкінгу, поділена на загальну кількість SOL (% від загальної кількості SOL у стейкінгу). Таким чином, розподіл і делегування токенів серед валідаторів є важливими факторами при визначенні початкових параметрів інфляції. -- Обмеження дохідності — це поточна область досліджень, яка може вплинути на _Дохідність Стейкінгу_. Це не враховано у цій дискусії чи в моделюванні нижче. -- Загальний випуск токенів — тобто якою ми очікуємо _Поточну Загальну Пропозицію_ через 10 чи 20 років? -- Довгострокова, стабільна інфляція є важливим фактором не тільки для сталого підтримання екосистеми валідаторів і грантових програм Фонду Solana, але також має бути налаштована з урахуванням очікуваних втрат і спалювання токенів з часом. -- Темпи очікуваного зростання використання мережі як фактор для розгляду ставки дезінфляції. З часом ми плануємо зниження інфляції та очікуємо зростання використання. +- Значна частина SOL, випущених через інфляцію, буде розподілена між власниками + стейкінгу пропорційно до кількості стейкінгованих SOL. Ми хочемо переконатися, + що дизайн _Графіку Інфляції_ забезпечує розумну _Дохідність Стейкінгу_ для + власників токенів, які делегують SOL, та провайдерів послуг валідації (через + комісії, які беруться з _Дохідності Стейкінгу_). +- Основний драйвер _Дохідності Стейкінгу_ — це кількість SOL у стейкінгу, + поділена на загальну кількість SOL (% від загальної кількості SOL у + стейкінгу). Таким чином, розподіл і делегування токенів серед валідаторів є + важливими факторами при визначенні початкових параметрів інфляції. +- Обмеження дохідності — це поточна область досліджень, яка може вплинути на + _Дохідність Стейкінгу_. Це не враховано у цій дискусії чи в моделюванні нижче. +- Загальний випуск токенів — тобто якою ми очікуємо _Поточну Загальну + Пропозицію_ через 10 чи 20 років? +- Довгострокова, стабільна інфляція є важливим фактором не тільки для сталого + підтримання екосистеми валідаторів і грантових програм Фонду Solana, але також + має бути налаштована з урахуванням очікуваних втрат і спалювання токенів з + часом. +- Темпи очікуваного зростання використання мережі як фактор для розгляду ставки + дезінфляції. З часом ми плануємо зниження інфляції та очікуємо зростання + використання. -Виходячи з цих міркувань і обговорень у спільноті після початкового дизайну, Фонд Solana пропонує наступні параметри _Графіку Інфляції_: +Виходячи з цих міркувань і обговорень у спільноті після початкового дизайну, +Фонд Solana пропонує наступні параметри _Графіку Інфляції_: - Початкова Ставка Інфляції: 8% - Ставка Дезінфляції: -15% - Довгострокова Ставка Інфляції: 1.5% -Ці параметри визначають запропонований _Графік Інфляції_. Нижче показано наслідки цих параметрів. Ці графіки лише показують вплив інфляційного випуску, заданого _Графіком Інфляції_, як параметризовано вище. Вони _не враховують_ інші фактори, які можуть вплинути на _Загальну Пропозицію_, такі як спалювання комісій/рент, штрафи чи інші непередбачувані події знищення токенів у майбутньому. Тому тут представлено **верхню межу** кількості SOL, випущених через інфляцію. +Ці параметри визначають запропонований _Графік Інфляції_. Нижче показано +наслідки цих параметрів. Ці графіки лише показують вплив інфляційного випуску, +заданого _Графіком Інфляції_, як параметризовано вище. Вони _не враховують_ інші +фактори, які можуть вплинути на _Загальну Пропозицію_, такі як спалювання +комісій/рент, штрафи чи інші непередбачувані події знищення токенів у +майбутньому. Тому тут представлено **верхню межу** кількості SOL, випущених +через інфляцію. ![Графік прикладу запропонованого графіку інфляції](/assets/docs/economics/proposed_inflation_schedule.png) -На графіку вище показано відсоток річної ставки інфляції з часом, виходячи з запропонованих параметрів інфляції. +На графіку вище показано відсоток річної ставки інфляції з часом, виходячи з +запропонованих параметрів інфляції. ![Графік прикладу загальної пропозиції](/assets/docs/economics/proposed_total_supply.png) -Подібним чином, тут показано _Поточну Загальну Пропозицію_ SOL [млн] з часом, за умови початкової _Поточна Загальна Пропозиція_ `488,587,349 SOL` (тобто, у цьому прикладі, взято _Поточну Загальну Пропозицію_ станом на `2020-01-25` і моделюється інфляція, починаючи з цього дня). +Подібним чином, тут показано _Поточну Загальну Пропозицію_ SOL [млн] з часом, за +умови початкової _Поточна Загальна Пропозиція_ `488,587,349 SOL` (тобто, у цьому +прикладі, взято _Поточну Загальну Пропозицію_ станом на `2020-01-25` і +моделюється інфляція, починаючи з цього дня). -Відставляючи осторонь доступність валідаторів і комісії, очікувані показники _Дохідності Стейкінгу_ та _Скоригованої Дохідності Стейкінгу_ є в першу чергу функцією % від загального SOL у стейкінгу. Тому ми можемо моделювати _Дохідність Стейкінгу_, якщо введемо додатковий параметр _% Стейкінгованих SOL_: +Відставляючи осторонь доступність валідаторів і комісії, очікувані показники +_Дохідності Стейкінгу_ та _Скоригованої Дохідності Стейкінгу_ є в першу чергу +функцією % від загального SOL у стейкінгу. Тому ми можемо моделювати _Дохідність +Стейкінгу_, якщо введемо додатковий параметр _% Стейкінгованих SOL_: -Цей параметр має бути оцінений, оскільки це динамічна властивість власників токенів і стимулів стейкінгу. Значення _% Стейкінгованих SOL_, представлені тут, варіюються від 60% до 90%, що, на нашу думку, охоплює ймовірний діапазон, який ми очікуємо, базуючись на зворотному зв’язку від спільнот інвесторів і валідаторів, а також спостереженнях на порівнянних протоколах Proof-of-Stake. +Цей параметр має бути оцінений, оскільки це динамічна властивість власників +токенів і стимулів стейкінгу. Значення _% Стейкінгованих SOL_, представлені тут, +варіюються від 60% до 90%, що, на нашу думку, охоплює ймовірний діапазон, який +ми очікуємо, базуючись на зворотному зв’язку від спільнот інвесторів і +валідаторів, а також спостереженнях на порівнянних протоколах Proof-of-Stake. ![Графік прикладу дохідності стейкінгу](/assets/docs/economics/example_staked_yields.png) -На графіку вище показано приклад _Дохідності Стейкінгу_, яку може очікувати учасник стейкінгу з часом у мережі Solana з вказаним _Графіком Інфляції_. Це ідеалізована _Дохідність Стейкінгу_, оскільки вона не враховує вплив доступності валідаторів на винагороди, комісії валідаторів, можливе обмеження дохідності та можливі інциденти зі штрафами. Вона також ігнорує, що _% Стейкінгованих SOL_ є динамічним за своєю суттю — економічні стимули, створені цим _Графіком Інфляції_, стають більш зрозумілими, коли враховується _Дилюція Токенів_ (див. розділ **Скоригована Дохідність Стейкінгу** нижче). +На графіку вище показано приклад _Дохідності Стейкінгу_, яку може очікувати +учасник стейкінгу з часом у мережі Solana з вказаним _Графіком Інфляції_. Це +ідеалізована _Дохідність Стейкінгу_, оскільки вона не враховує вплив доступності +валідаторів на винагороди, комісії валідаторів, можливе обмеження дохідності та +можливі інциденти зі штрафами. Вона також ігнорує, що _% Стейкінгованих SOL_ є +динамічним за своєю суттю — економічні стимули, створені цим _Графіком +Інфляції_, стають більш зрозумілими, коли враховується _Дилюція Токенів_ (див. +розділ **Скоригована Дохідність Стейкінгу** нижче). diff --git a/docs/locales/uk/economics/inflation/terminology.md b/docs/locales/uk/economics/inflation/terminology.md index bdd0cbe94..23debb50c 100644 --- a/docs/locales/uk/economics/inflation/terminology.md +++ b/docs/locales/uk/economics/inflation/terminology.md @@ -3,44 +3,86 @@ sidebarLabel: Терміни, Пов’язані з Інфляцією title: Терміни, Пов’язані з Інфляцією --- -При обговоренні інфляції та пов’язаних компонентів (наприклад, винагород/дохідності/відсотків) використовується багато термінів. Тут ми намагаємося визначити та уточнити деякі загальновживані поняття: +При обговоренні інфляції та пов’язаних компонентів (наприклад, +винагород/дохідності/відсотків) використовується багато термінів. Тут ми +намагаємося визначити та уточнити деякі загальновживані поняття: ### Поточна Загальна Пропозиція [SOL] -Загальна кількість токенів (заблокованих або незаблокованих), які були створені (через генезисний блок або інфляцію протоколу) мінус будь-які токени, які були спалені (через комісії за транзакції або інші механізми) чи списані. Під час запуску мережі було створено 500,000,000 SOL у генезисному блоці. З того часу Поточна Загальна Пропозиція зменшилася через спалювання комісій за транзакції та заплановану подію зменшення кількості токенів. _Поточну Загальну Пропозицію_ Solana можна знайти за адресою: https://explorer.solana.com/supply +Загальна кількість токенів (заблокованих або незаблокованих), які були створені +(через генезисний блок або інфляцію протоколу) мінус будь-які токени, які були +спалені (через комісії за транзакції або інші механізми) чи списані. Під час +запуску мережі було створено 500,000,000 SOL у генезисному блоці. З того часу +Поточна Загальна Пропозиція зменшилася через спалювання комісій за транзакції та +заплановану подію зменшення кількості токенів. _Поточну Загальну Пропозицію_ +Solana можна знайти за адресою: https://explorer.solana.com/supply ### Ставка Інфляції [%] -Протокол Solana автоматично створює нові токени за заздалегідь визначеним графіком інфляції (обговорено нижче). _Ставка Інфляції [%]_ — це річний темп зростання _Поточна Загальна Пропозиція_ на будь-який момент часу. +Протокол Solana автоматично створює нові токени за заздалегідь визначеним +графіком інфляції (обговорено нижче). _Ставка Інфляції [%]_ — це річний темп +зростання _Поточна Загальна Пропозиція_ на будь-який момент часу. ### Графік Інфляції -Детерміноване описання випуску токенів з часом. Фонд Solana пропонує дезінфляційний _Графік Інфляції_. Тобто інфляція починається з найвищого значення, а її темп зменшується з часом, доки не стабілізується на заздалегідь визначеному довгостроковому рівні (див. обговорення нижче). Цей графік повністю та унікально параметризується трьома числами: +Детерміноване описання випуску токенів з часом. Фонд Solana пропонує +дезінфляційний _Графік Інфляції_. Тобто інфляція починається з найвищого +значення, а її темп зменшується з часом, доки не стабілізується на заздалегідь +визначеному довгостроковому рівні (див. обговорення нижче). Цей графік повністю +та унікально параметризується трьома числами: -- **Початкова Ставка Інфляції [%]**: Початкова _Ставка Інфляції_ для моменту активації інфляції. Темп випуску токенів може тільки знижуватися з цього моменту. +- **Початкова Ставка Інфляції [%]**: Початкова _Ставка Інфляції_ для моменту + активації інфляції. Темп випуску токенів може тільки знижуватися з цього + моменту. - **Ставка Дезінфляції [%]**: Темп, з яким зменшується _Ставка Інфляції_. -- **Довгострокова Ставка Інфляції [%]**: Стабільна, довгострокова _Ставка Інфляції_. +- **Довгострокова Ставка Інфляції [%]**: Стабільна, довгострокова _Ставка + Інфляції_. ### Ефективна Ставка Інфляції [%] -Фактична ставка інфляції, що спостерігається в мережі Solana, після врахування інших факторів, які можуть зменшити _Поточну Загальну Пропозицію_. Зазначимо, що створення токенів поза описаним _Графіком Інфляції_ неможливе. +Фактична ставка інфляції, що спостерігається в мережі Solana, після врахування +інших факторів, які можуть зменшити _Поточну Загальну Пропозицію_. Зазначимо, що +створення токенів поза описаним _Графіком Інфляції_ неможливе. -- Хоча _Графік Інфляції_ визначає, як протокол випускає SOL, він не враховує одночасного знищення токенів через різні фактори. Основний механізм спалювання токенів — це спалювання частини кожної комісії за транзакцію. 50% кожної комісії за транзакцію спалюється, решта залишається валідатору, який обробив транзакцію. -- Додаткові фактори, такі як втрата приватних ключів і списання токенів, також слід враховувати в комплексному аналізі _Ефективної Ставки Інфляції_. Наприклад, оцінюється, що 10–20% всіх BTC втрачені та недоступні, і мережі можуть зазнавати подібних щорічних втрат на рівні 1–2%. +- Хоча _Графік Інфляції_ визначає, як протокол випускає SOL, він не враховує + одночасного знищення токенів через різні фактори. Основний механізм спалювання + токенів — це спалювання частини кожної комісії за транзакцію. 50% кожної + комісії за транзакцію спалюється, решта залишається валідатору, який обробив + транзакцію. +- Додаткові фактори, такі як втрата приватних ключів і списання токенів, також + слід враховувати в комплексному аналізі _Ефективної Ставки Інфляції_. + Наприклад, оцінюється, що 10–20% всіх BTC втрачені та недоступні, і мережі + можуть зазнавати подібних щорічних втрат на рівні 1–2%. ### Дохідність Стейкінгу [%] -Темп повернення (також відомий як _відсоток_), який отримується за SOL, поставлені на стейкінг у мережі. Зазвичай він зазначається як річний темп (наприклад, "дохідність стейкінгу в мережі наразі становить 10% на рік"). - -- _Дохідність стейкінгу_ дуже цікавить валідаторів і власників токенів, які бажають делегувати свої токени, щоб уникнути розмивання токенів через інфляцію (масштаб якої обговорено нижче). -- 100% інфляційних випусків розподіляються між власниками стейкінгованих токенів пропорційно до їхнього стейкінгованого SOL, а також валідаторами, які стягують комісію з винагороди, отриманої за делегований SOL. - - Може бути враховано майбутнє розділення інфляційних випусків із введенням _Архіваторів_ у економіку. _Архіватори_ — це учасники мережі, які надають децентралізовані послуги зберігання, і їх також слід стимулювати розподілом токенів з інфляційних випусків за цю послугу. -- _Дохідність Стейкінгу_ можна розрахувати за _Графіком Інфляції_ разом із часткою _Поточна Загальна Пропозиція_, що перебуває в стейкінгу. +Темп повернення (також відомий як _відсоток_), який отримується за SOL, +поставлені на стейкінг у мережі. Зазвичай він зазначається як річний темп +(наприклад, "дохідність стейкінгу в мережі наразі становить 10% на рік"). + +- _Дохідність стейкінгу_ дуже цікавить валідаторів і власників токенів, які + бажають делегувати свої токени, щоб уникнути розмивання токенів через інфляцію + (масштаб якої обговорено нижче). +- 100% інфляційних випусків розподіляються між власниками стейкінгованих токенів + пропорційно до їхнього стейкінгованого SOL, а також валідаторами, які стягують + комісію з винагороди, отриманої за делегований SOL. + - Може бути враховано майбутнє розділення інфляційних випусків із введенням + _Архіваторів_ у економіку. _Архіватори_ — це учасники мережі, які надають + децентралізовані послуги зберігання, і їх також слід стимулювати розподілом + токенів з інфляційних випусків за цю послугу. +- _Дохідність Стейкінгу_ можна розрахувати за _Графіком Інфляції_ разом із + часткою _Поточна Загальна Пропозиція_, що перебуває в стейкінгу. ### Дилюція Токенів [%] -Розмивання визначається тут як зміна пропорційного представлення набору токенів у більшому наборі через введення нових токенів. У практичному сенсі ми обговорюємо розмивання стейкінгованих або нестейкінгованих токенів через введення та розподіл інфляційних випусків по мережі. +Розмивання визначається тут як зміна пропорційного представлення набору токенів +у більшому наборі через введення нових токенів. У практичному сенсі ми +обговорюємо розмивання стейкінгованих або нестейкінгованих токенів через +введення та розподіл інфляційних випусків по мережі. ### Скоригована Дохідність Стейкінгу [%] -Повна оцінка потенціалу заробітку від стейкінгу токенів повинна враховувати стейкінговану _Дилюцію Токенів_ та її вплив на _Дохідність Стейкінгу_. Для цього ми визначаємо _Скориговану Дохідність Стейкінгу_ як зміну фракційної власності токенів у стейкінгу через розподіл інфляційних випусків. +Повна оцінка потенціалу заробітку від стейкінгу токенів повинна враховувати +стейкінговану _Дилюцію Токенів_ та її вплив на _Дохідність Стейкінгу_. Для цього +ми визначаємо _Скориговану Дохідність Стейкінгу_ як зміну фракційної власності +токенів у стейкінгу через розподіл інфляційних випусків. diff --git a/docs/locales/uk/economics/staking/index.md b/docs/locales/uk/economics/staking/index.md index 09160d228..7f9a56564 100644 --- a/docs/locales/uk/economics/staking/index.md +++ b/docs/locales/uk/economics/staking/index.md @@ -3,86 +3,97 @@ sidebarLabel: Стейкінг title: Стейкінг у Solana --- -_Примітка перед читанням: Усі згадки про збільшення значень стосуються абсолютних -показників балансу SOL. Цей документ не містить жодних припущень щодо +_Примітка перед читанням: Усі згадки про збільшення значень стосуються +абсолютних показників балансу SOL. Цей документ не містить жодних припущень щодо грошової вартості SOL у будь-який час._ Стейкуючи ваші токени SOL, ви допомагаєте забезпечувати безпеку мережі та [отримувати винагороди](https://docs.anza.xyz/implemented-proposals/staking-rewards) у процесі цього. -Ви можете здійснювати стейкінг, делегуючи ваші токени валідаторам, які обробляють транзакції -та забезпечують роботу мережі. - -Делегування стейкінгу — це фінансова модель з розподіленим ризиком і винагородою, яка може -забезпечити дохід для власників токенів, делегованих на тривалий період. Це досягається -шляхом узгодження фінансових інтересів власників токенів (делегаторів) та валідаторів, -яким вони делегують токени. - -Чим більше стейку делеговано валідатору, тим частіше цей валідатор обирається для запису -нових транзакцій до реєстру. Чим більше транзакцій записує валідатор, тим більше винагород -отримують валідатор і його делегатори. Валідатори, які налаштовують свої системи для обробки -більшої кількості транзакцій, заробляють пропорційно більше винагород і допомагають -підтримувати мережу якомога швидшою та стабільнішою. - -Валідатори несуть витрати на обслуговування та підтримку своїх систем, і ці витрати передаються -делегаторам у формі комісії, яка стягується як відсоток від зароблених винагород. Ця комісія -називається _комісією валідатора_. Оскільки валідатори отримують більше винагород за більше -делегованого стейку, вони можуть конкурувати між собою, пропонуючи найнижчу комісію за свої послуги. - -Хоча це не реалізовано в протоколі Solana сьогодні, у майбутньому делегатори можуть ризикувати -втратити токени через процес, відомий як _слешинг_. Слешинг передбачає вилучення та знищення частини -SOL валідатора у відповідь на навмисну зловмисну поведінку, наприклад, створення недійсних транзакцій -або цензурування певних типів транзакцій чи учасників мережі. - -На даний момент у протоколі Solana немає реалізації слешингу. Для отримання додаткової інформації -про слешинг перегляньте +Ви можете здійснювати стейкінг, делегуючи ваші токени валідаторам, які +обробляють транзакції та забезпечують роботу мережі. + +Делегування стейкінгу — це фінансова модель з розподіленим ризиком і +винагородою, яка може забезпечити дохід для власників токенів, делегованих на +тривалий період. Це досягається шляхом узгодження фінансових інтересів власників +токенів (делегаторів) та валідаторів, яким вони делегують токени. + +Чим більше стейку делеговано валідатору, тим частіше цей валідатор обирається +для запису нових транзакцій до реєстру. Чим більше транзакцій записує валідатор, +тим більше винагород отримують валідатор і його делегатори. Валідатори, які +налаштовують свої системи для обробки більшої кількості транзакцій, заробляють +пропорційно більше винагород і допомагають підтримувати мережу якомога швидшою +та стабільнішою. + +Валідатори несуть витрати на обслуговування та підтримку своїх систем, і ці +витрати передаються делегаторам у формі комісії, яка стягується як відсоток від +зароблених винагород. Ця комісія називається _комісією валідатора_. Оскільки +валідатори отримують більше винагород за більше делегованого стейку, вони можуть +конкурувати між собою, пропонуючи найнижчу комісію за свої послуги. + +Хоча це не реалізовано в протоколі Solana сьогодні, у майбутньому делегатори +можуть ризикувати втратити токени через процес, відомий як _слешинг_. Слешинг +передбачає вилучення та знищення частини SOL валідатора у відповідь на навмисну +зловмисну поведінку, наприклад, створення недійсних транзакцій або цензурування +певних типів транзакцій чи учасників мережі. + +На даний момент у протоколі Solana немає реалізації слешингу. Для отримання +додаткової інформації про слешинг перегляньте [дорожню карту слешингу](https://docs.anza.xyz/proposals/optimistic-confirmation-and-slashing#slashing-roadmap). ## Як здійснити стейкінг моїх токенів SOL? -Ви можете здійснити стейкінг SOL, перемістивши свої токени в гаманець, який підтримує стейкінг. Гаманець -надасть інструкції для створення облікового запису стейкінгу та делегування. +Ви можете здійснити стейкінг SOL, перемістивши свої токени в гаманець, який +підтримує стейкінг. Гаманець надасть інструкції для створення облікового запису +стейкінгу та делегування. #### Підтримувані Гаманці -Багато веб- та мобільних гаманців підтримують операції стейкінгу Solana. Будь ласка, перевірте -статус підтримки у розробників вашого улюбленого гаманця. +Багато веб- та мобільних гаманців підтримують операції стейкінгу Solana. Будь +ласка, перевірте статус підтримки у розробників вашого улюбленого гаманця. #### Інструменти командного рядка Solana -- Інструменти командного рядка Solana дозволяють виконувати всі операції стейкінгу в поєднанні з - гаманцем у вигляді файлу ключів, паперовим гаманцем або підключеним Ledger Nano. +- Інструменти командного рядка Solana дозволяють виконувати всі операції + стейкінгу в поєднанні з гаманцем у вигляді файлу ключів, паперовим гаманцем + або підключеним Ledger Nano. [Команди для стейкінгу за допомогою інструментів командного рядка Solana](https://docs.anza.xyz/cli/examples/delegate-stake). #### Створення Облікового Запису Стейкінгу -Виконуйте інструкції гаманця для створення облікового запису стейкінгу. Цей обліковий запис -відрізняється від облікових записів, які використовуються для відправлення та отримання токенів. +Виконуйте інструкції гаманця для створення облікового запису стейкінгу. Цей +обліковий запис відрізняється від облікових записів, які використовуються для +відправлення та отримання токенів. #### Вибір Валідатора -Дотримуйтесь інструкцій гаманця для вибору валідатора. Ви можете отримати інформацію про потенційно -ефективних валідаторів за посиланнями нижче. Фонд Solana не рекомендує конкретних валідаторів. +Дотримуйтесь інструкцій гаманця для вибору валідатора. Ви можете отримати +інформацію про потенційно ефективних валідаторів за посиланнями нижче. Фонд +Solana не рекомендує конкретних валідаторів. -Сайт solanabeach.io створений і підтримується одним з наших валідаторів, -Staking Facilities. Він надає графічну інформацію про мережу в цілому, а також -список кожного валідатора з деякими останніми статистиками їхньої продуктивності. +Сайт solanabeach.io створений і підтримується одним з наших валідаторів, Staking +Facilities. Він надає графічну інформацію про мережу в цілому, а також список +кожного валідатора з деякими останніми статистиками їхньої продуктивності. - https://solanabeach.io -Для перегляду статистики виробництва блоків використовуйте інструменти командного рядка Solana: +Для перегляду статистики виробництва блоків використовуйте інструменти +командного рядка Solana: - `solana validators` - `solana block-production` -Команда Solana не надає рекомендацій щодо інтерпретації цієї інформації. Виконуйте власне дослідження. +Команда Solana не надає рекомендацій щодо інтерпретації цієї інформації. +Виконуйте власне дослідження. #### Делегування Стейку -Виконуйте інструкції гаманця для делегування вашого стейку обраному вами валідатору. +Виконуйте інструкції гаманця для делегування вашого стейку обраному вами +валідатору. ## Деталі Облікового Запису Стейкінгу -Для отримання додаткової інформації про операції та дозволи, пов’язані з обліковим записом стейкінгу, -дивіться [Облікові Записи Стейкінгу](/docs/uk/economics/staking/stake-accounts.md) +Для отримання додаткової інформації про операції та дозволи, пов’язані з +обліковим записом стейкінгу, дивіться +[Облікові Записи Стейкінгу](/docs/uk/economics/staking/stake-accounts.md) diff --git a/docs/locales/uk/economics/staking/stake-accounts.md b/docs/locales/uk/economics/staking/stake-accounts.md index 9eb222c24..683a6d5a2 100644 --- a/docs/locales/uk/economics/staking/stake-accounts.md +++ b/docs/locales/uk/economics/staking/stake-accounts.md @@ -3,23 +3,46 @@ sidebarLabel: Облікові Записи Стейкінгу title: Облікові Записи Стейкінгу --- -Обліковий запис стейкінгу на Solana може використовуватися для делегування токенів валідаторам у мережі з можливістю отримання винагород для власника облікового запису стейкінгу. Облікові записи стейкінгу створюються та керуються інакше, ніж традиційні адреси гаманців, відомі як _системні облікові записи_. Системний обліковий запис здатний лише надсилати та отримувати SOL від інших облікових записів у мережі, тоді як обліковий запис стейкінгу підтримує складніші операції, необхідні для управління делегуванням токенів. - -Облікові записи стейкінгу на Solana також працюють інакше, ніж у інших блокчейн-мережах Proof-of-Stake, з якими ви могли бути знайомі. У цьому документі описується загальна структура та функції облікового запису стейкінгу Solana. +Обліковий запис стейкінгу на Solana може використовуватися для делегування +токенів валідаторам у мережі з можливістю отримання винагород для власника +облікового запису стейкінгу. Облікові записи стейкінгу створюються та керуються +інакше, ніж традиційні адреси гаманців, відомі як _системні облікові записи_. +Системний обліковий запис здатний лише надсилати та отримувати SOL від інших +облікових записів у мережі, тоді як обліковий запис стейкінгу підтримує +складніші операції, необхідні для управління делегуванням токенів. + +Облікові записи стейкінгу на Solana також працюють інакше, ніж у інших +блокчейн-мережах Proof-of-Stake, з якими ви могли бути знайомі. У цьому +документі описується загальна структура та функції облікового запису стейкінгу +Solana. #### Адреса Облікового Запису -Кожен обліковий запис стейкінгу має унікальну адресу, яка може використовуватися для перегляду інформації про обліковий запис через командний рядок або будь-які інструменти дослідження мережі. Однак, на відміну від адреси гаманця, власник ключової пари адреси не обов'язково має контроль над обліковим записом. Насправді, для адреси облікового запису стейкінгу може навіть не існувати ключова пара чи приватний ключ. +Кожен обліковий запис стейкінгу має унікальну адресу, яка може використовуватися +для перегляду інформації про обліковий запис через командний рядок або будь-які +інструменти дослідження мережі. Однак, на відміну від адреси гаманця, власник +ключової пари адреси не обов'язково має контроль над обліковим записом. +Насправді, для адреси облікового запису стейкінгу може навіть не існувати +ключова пара чи приватний ключ. -Ключова пара створюється лише під час [створення облікового запису стейкінгу за допомогою інструментів командного рядка](https://docs.anza.xyz/cli/examples/delegate-stake#create-a-stake-account). Нова ключова пара створюється виключно для забезпечення унікальності адреси облікового запису стейкінгу. +Ключова пара створюється лише під час +[створення облікового запису стейкінгу за допомогою інструментів командного рядка](https://docs.anza.xyz/cli/examples/delegate-stake#create-a-stake-account). +Нова ключова пара створюється виключно для забезпечення унікальності адреси +облікового запису стейкінгу. #### Розуміння Авторитетів Облікового Запису -Деякі типи облікових записів можуть мати один або більше _авторитетів підпису_, пов’язаних з обліковим записом. Авторитет облікового запису використовується для підпису певних транзакцій для облікового запису, яким він керує. Це відрізняється від інших блокчейнів, де власник ключової пари контролює всі дії облікового запису. +Деякі типи облікових записів можуть мати один або більше _авторитетів підпису_, +пов’язаних з обліковим записом. Авторитет облікового запису використовується для +підпису певних транзакцій для облікового запису, яким він керує. Це +відрізняється від інших блокчейнів, де власник ключової пари контролює всі дії +облікового запису. -Кожен обліковий запис стейкінгу має два авторитети підпису, які вказані їхніми відповідними адресами: +Кожен обліковий запис стейкінгу має два авторитети підпису, які вказані їхніми +відповідними адресами: - _Авторитет стейкінгу_ використовується для підпису транзакцій, пов’язаних із: + - Делегуванням стейку - Деактивацією делегування стейку - Розділенням облікового запису на два окремі @@ -33,24 +56,32 @@ title: Облікові Записи Стейкінгу #### Множинне Делегування -Один обліковий запис стейкінгу може бути делегований лише одному валідатору. Усі токени в обліковому записі є або делегованими, або неделегованими. Щоб делегувати частину токенів кільком валідаторам, потрібно створити кілька облікових записів стейкінгу. +Один обліковий запис стейкінгу може бути делегований лише одному валідатору. Усі +токени в обліковому записі є або делегованими, або неделегованими. Щоб +делегувати частину токенів кільком валідаторам, потрібно створити кілька +облікових записів стейкінгу. #### Об'єднання Облікових Записів -Два облікові записи стейкінгу з однаковими авторитетами та параметрами блокування можуть бути об’єднані в один. +Два облікові записи стейкінгу з однаковими авторитетами та параметрами +блокування можуть бути об’єднані в один. #### Розігрів та Охолодження Делегування -Процес делегування або деактивації делегування не є миттєвим і може займати кілька [епох](/docs/terminology.md#epoch). +Процес делегування або деактивації делегування не є миттєвим і може займати +кілька [епох](/docs/terminology.md#epoch). #### Блокування -Облікові записи стейкінгу можуть мати блокування, яке забороняє виведення токенів до досягнення певної дати або епохи. +Облікові записи стейкінгу можуть мати блокування, яке забороняє виведення +токенів до досягнення певної дати або епохи. #### Видалення Облікового Запису -Обліковий запис стейкінгу, баланс якого дорівнює 0 SOL, автоматично припиняє існувати. +Обліковий запис стейкінгу, баланс якого дорівнює 0 SOL, автоматично припиняє +існувати. #### Перегляд Облікових Записів Стейкінгу -Інформацію про обліковий запис стейкінгу можна переглянути через [Solana Explorer](http://explorer.solana.com/accounts). +Інформацію про обліковий запис стейкінгу можна переглянути через +[Solana Explorer](http://explorer.solana.com/accounts). diff --git a/docs/locales/uk/economics/staking/stake-programming.md b/docs/locales/uk/economics/staking/stake-programming.md index f914000a2..ce5511476 100644 --- a/docs/locales/uk/economics/staking/stake-programming.md +++ b/docs/locales/uk/economics/staking/stake-programming.md @@ -2,14 +2,30 @@ title: Програмування Стейкінгу --- -Для максимізації розподілу стейку, децентралізації та стійкості до цензури в мережі Solana, стейкінг може виконуватись програмно. Команда та спільнота розробили кілька програм для роботи як на ланцюгу, так і поза ним, щоб зробити управління стейками простішим. +Для максимізації розподілу стейку, децентралізації та стійкості до цензури в +мережі Solana, стейкінг може виконуватись програмно. Команда та спільнота +розробили кілька програм для роботи як на ланцюгу, так і поза ним, щоб зробити +управління стейками простішим. #### Stake-o-matic, також відомий як боти автоделегування -Ця позаланцюгова програма управляє великою кількістю валідаторів, яким делегує стейк центральний орган. Фонд Solana використовує бота автоделегування для регулярного делегування свого стейку "неспійманим" валідаторам, які відповідають визначеним вимогам продуктивності. +Ця позаланцюгова програма управляє великою кількістю валідаторів, яким делегує +стейк центральний орган. Фонд Solana використовує бота автоделегування для +регулярного делегування свого стейку "неспійманим" валідаторам, які відповідають +визначеним вимогам продуктивності. #### Stake Pools -Ця програма на ланцюгу об'єднує SOL для стейкінгу, яким управляє менеджер, дозволяючи власникам SOL здійснювати стейкінг та отримувати винагороди без необхідності управляти стейками. Користувачі депонують SOL в обмін на SPL-токени (похідні стейкінгу), які представляють їхню частку в пулі стейкінгу. Менеджер пулу здійснює стейкінг внесених SOL відповідно до своєї стратегії, можливо, використовуючи варіант бота автоделегування, описаного вище. Коли стейки отримують винагороди, вартість пулу та токенів пулу пропорційно зростає. Нарешті, власники токенів пулу можуть повернути SPL-токени назад у пул стейкінгу для викупу SOL, тим самим беручи участь у децентралізації з мінімальними зусиллями. +Ця програма на ланцюгу об'єднує SOL для стейкінгу, яким управляє менеджер, +дозволяючи власникам SOL здійснювати стейкінг та отримувати винагороди без +необхідності управляти стейками. Користувачі депонують SOL в обмін на SPL-токени +(похідні стейкінгу), які представляють їхню частку в пулі стейкінгу. Менеджер +пулу здійснює стейкінг внесених SOL відповідно до своєї стратегії, можливо, +використовуючи варіант бота автоделегування, описаного вище. Коли стейки +отримують винагороди, вартість пулу та токенів пулу пропорційно зростає. +Нарешті, власники токенів пулу можуть повернути SPL-токени назад у пул стейкінгу +для викупу SOL, тим самим беручи участь у децентралізації з мінімальними +зусиллями. -Детальнішу інформацію можна знайти в [документації SPL Stake Pool](https://spl.solana.com/stake-pool). +Детальнішу інформацію можна знайти в +[документації SPL Stake Pool](https://spl.solana.com/stake-pool). diff --git a/docs/locales/uk/index.md b/docs/locales/uk/index.md index 10ac0c1ec..94f35a425 100644 --- a/docs/locales/uk/index.md +++ b/docs/locales/uk/index.md @@ -4,8 +4,8 @@ title: Документація Solana seoTitle: Дізнайтеся, як працює блокчейн Solana description: "Solana — це високопродуктивний блокчейн, створений для масового впровадження. - Дізнайтеся, чому Solana є найкращим вибором для розробників, які прагнуть створювати - масштабовані блокчейн-додатки." + Дізнайтеся, чому Solana є найкращим вибором для розробників, які прагнуть + створювати масштабовані блокчейн-додатки." altRoutes: - /docs/intro/history - /docs/intro @@ -13,61 +13,93 @@ altRoutes: isHiddenInNavSidebar: true --- -Solana — це блокчейн, створений для масового використання. Це високопродуктивна мережа, яка використовується для різних сфер, включаючи фінанси, NFT, платежі та ігри. Solana працює як єдина глобальна станова машина, є відкритою, інтероперабельною та децентралізованою. +Solana — це блокчейн, створений для масового використання. Це високопродуктивна +мережа, яка використовується для різних сфер, включаючи фінанси, NFT, платежі та +ігри. Solana працює як єдина глобальна станова машина, є відкритою, +інтероперабельною та децентралізованою. ## Початок роботи -Пориньте у світ Solana, щоб почати створювати або налаштовувати своє локальне середовище. +Пориньте у світ Solana, щоб почати створювати або налаштовувати своє локальне +середовище. -- [Швидкий старт](/docs/intro/quick-start) — Створіть і розгорніть свою першу програму на Solana прямо у браузері за допомогою Solana Playground -- [Налаштування локального середовища](/docs/intro/installation) — Встановіть CLI Solana для налаштування локального середовища розробки +- [Швидкий старт](/docs/intro/quick-start) — Створіть і розгорніть свою першу + програму на Solana прямо у браузері за допомогою Solana Playground +- [Налаштування локального середовища](/docs/intro/installation) — Встановіть + CLI Solana для налаштування локального середовища розробки ## Почніть навчання -Поглиблено вивчіть основні концепції, які роблять Solana унікальною серед інших блокчейнів. +Поглиблено вивчіть основні концепції, які роблять Solana унікальною серед інших +блокчейнів. - [Акаунти](/docs/core/accounts) — Механізм зберігання даних і стану для Solana -- [Комісії в Solana](/docs/core/fees) — Різні витрати, пов’язані з використанням мережі -- [Транзакції](/docs/core/transactions) — Набір інструкцій для виконання блокчейном -- [Програми](/docs/core/programs) — Виконуваний код для виконання дій у блокчейні -- [Програмно похідні адреси](/docs/core/pda) — Детерміновано створені адреси, які дозволяють програмам Solana програмно "підписувати" транзакції -- [Виклики між програмами](/docs/core/cpi) — Основний механізм "композованості" Solana, який дозволяє програмам "викликати" одна одну +- [Комісії в Solana](/docs/core/fees) — Різні витрати, пов’язані з використанням + мережі +- [Транзакції](/docs/core/transactions) — Набір інструкцій для виконання + блокчейном +- [Програми](/docs/core/programs) — Виконуваний код для виконання дій у + блокчейні +- [Програмно похідні адреси](/docs/core/pda) — Детерміновано створені адреси, + які дозволяють програмам Solana програмно "підписувати" транзакції +- [Виклики між програмами](/docs/core/cpi) — Основний механізм "композованості" + Solana, який дозволяє програмам "викликати" одна одну ## Розуміння архітектури Дізнайтеся, як працює блокчейн Proof-of-Stake у основі Solana. -- [Валідатори](https://docs.anza.xyz/validator/anatomy) — окремі вузли, які є основою мережі -- [Кластери](/docs/core/clusters) — група валідаторів, що працюють разом для досягнення консенсусу +- [Валідатори](https://docs.anza.xyz/validator/anatomy) — окремі вузли, які є + основою мережі +- [Кластери](/docs/core/clusters) — група валідаторів, що працюють разом для + досягнення консенсусу ## Запуск валідатора -Дізнайтеся, що потрібно для роботи валідатора Solana та забезпечення безпеки мережі. +Дізнайтеся, що потрібно для роботи валідатора Solana та забезпечення безпеки +мережі. -- [Системні вимоги](https://docs.anza.xyz/operations/requirements) — Рекомендовані апаратні вимоги та очікувана кількість SOL, необхідна для запуску валідатора -- [Швидкий старт](https://docs.anza.xyz/operations/setup-a-validator) — Налаштуйте валідатор і підключіться до кластера вперше +- [Системні вимоги](https://docs.anza.xyz/operations/requirements) — + Рекомендовані апаратні вимоги та очікувана кількість SOL, необхідна для + запуску валідатора +- [Швидкий старт](https://docs.anza.xyz/operations/setup-a-validator) — + Налаштуйте валідатор і підключіться до кластера вперше ## Чому Solana? -Створена для масштабування, Solana призначена для того, щоб блокчейн-додатки могли досягати мільйонів користувачів. Замість оптимізації під блокчейн-рівень розробники можуть зосередитися на створенні додатків, які досягнуть відповідності ринку. Мережа не тільки може масштабуватися для поточних потреб блокчейн-додатків, але й постійно оптимізується з урахуванням досвіду користувачів. +Створена для масштабування, Solana призначена для того, щоб блокчейн-додатки +могли досягати мільйонів користувачів. Замість оптимізації під блокчейн-рівень +розробники можуть зосередитися на створенні додатків, які досягнуть +відповідності ринку. Мережа не тільки може масштабуватися для поточних потреб +блокчейн-додатків, але й постійно оптимізується з урахуванням досвіду +користувачів. -Створення найкращого користувацького досвіду є головним пріоритетом для розробників. У блокчейнах користувацький досвід часто обмежений базовими технологіями, що спричиняє повільний час відгуку та високі комісії. Низькі комісії Solana та час підтвердження в 400 мс дозволяють розробникам створювати зручні для користувачів додатки, доступні кожному. +Створення найкращого користувацького досвіду є головним пріоритетом для +розробників. У блокчейнах користувацький досвід часто обмежений базовими +технологіями, що спричиняє повільний час відгуку та високі комісії. Низькі +комісії Solana та час підтвердження в 400 мс дозволяють розробникам створювати +зручні для користувачів додатки, доступні кожному. ## Особливості Solana -| Функція | Опис | -| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Розробка програм на блокчейні | Можливість розробляти та розгортати програми на блокчейні. Користувачі можуть взаємодіяти з цими програмами без дозволу, усуваючи потребу у посередниках для створення додатків. | -| 400 мс для блоків | Кожна транзакція користувачів у Solana підтверджується в блоці. З цільовим часом 400 мс для кожного блоку, взаємодія користувачів є швидкою, забезпечуючи найкращий у своєму класі досвід. | -| Низькі комісії | Комісії в Solana відомі своєю низькістю. Середня комісія становить 0.00064 SOL за транзакцію, що дозволяє створювати додатки для користувачів з усього світу, незалежно від їх походження. | -| Висока пропускна здатність | Масштабування до тисяч транзакцій за секунду, Solana створена для масштабування відповідно до потреб користувачів вашого додатку. | +| Функція | Опис | +| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Розробка програм на блокчейні | Можливість розробляти та розгортати програми на блокчейні. Користувачі можуть взаємодіяти з цими програмами без дозволу, усуваючи потребу у посередниках для створення додатків. | +| 400 мс для блоків | Кожна транзакція користувачів у Solana підтверджується в блоці. З цільовим часом 400 мс для кожного блоку, взаємодія користувачів є швидкою, забезпечуючи найкращий у своєму класі досвід. | +| Низькі комісії | Комісії в Solana відомі своєю низькістю. Середня комісія становить 0.00064 SOL за транзакцію, що дозволяє створювати додатки для користувачів з усього світу, незалежно від їх походження. | +| Висока пропускна здатність | Масштабування до тисяч транзакцій за секунду, Solana створена для масштабування відповідно до потреб користувачів вашого додатку. | ## Як користуватися цими документами -Зліва ви знайдете бічну панель документації. Вона містить документацію у порядку від базової до більш просунутої інформації. Якщо ви новачок у Solana, рекомендуємо почати з самого верху і рухатися вниз. Однак ви можете читати їх у будь-якому порядку, який вам подобається. +Зліва ви знайдете бічну панель документації. Вона містить документацію у порядку +від базової до більш просунутої інформації. Якщо ви новачок у Solana, +рекомендуємо почати з самого верху і рухатися вниз. Однак ви можете читати їх у +будь-якому порядку, який вам подобається. -Коли будете готові почати створення, ознайомтеся з посібником [Швидкий старт](/docs/intro/quick-start). +Коли будете готові почати створення, ознайомтеся з посібником +[Швидкий старт](/docs/intro/quick-start). ## Потрібна допомога? -Отримайте допомогу від спільноти Solana на [Solana StackExchange](https://solana.stackexchange.com). +Отримайте допомогу від спільноти Solana на +[Solana StackExchange](https://solana.stackexchange.com). diff --git a/docs/locales/uk/intro/dev.md b/docs/locales/uk/intro/dev.md index ac56bb2d1..725c8aeb0 100644 --- a/docs/locales/uk/intro/dev.md +++ b/docs/locales/uk/intro/dev.md @@ -13,32 +13,61 @@ keywords: Ласкаво просимо до документації для розробників Solana! -На цій сторінці зібрано все, що вам потрібно знати для початку розробки на Solana, включаючи основні вимоги, принципи роботи та інструменти, необхідні для старту. +На цій сторінці зібрано все, що вам потрібно знати для початку розробки на +Solana, включаючи основні вимоги, принципи роботи та інструменти, необхідні для +старту. ## Огляд Розробки на Високому Рівні Розробку на Solana можна розділити на дві основні частини: -1. **Розробка Програм на Блокчейні**: Тут ви створюєте та розгортаєте користувацькі програми безпосередньо у блокчейні. Після розгортання будь-хто, хто знає, як із ними працювати, може їх використовувати. Ці програми можна писати на Rust, C або C++. Rust наразі має найбільшу підтримку для розробки програм на блокчейні. -2. **Клієнтська Розробка**: Це створення програмного забезпечення (децентралізованих додатків або dApps), яке взаємодіє з програмами на блокчейні. Ваші додатки можуть надсилати транзакції для виконання дій у блокчейні. Клієнтську розробку можна виконувати на будь-якій мові програмування. - -"Зв'язок" між клієнтською та блокчейн-частиною забезпечується [Solana JSON RPC API](https://solana.com/docs/rpc). Клієнтська частина надсилає запити RPC до мережі Solana для взаємодії з програмами на блокчейні. Це дуже схоже на звичайний процес розробки між frontend і backend. Головна відмінність у роботі з Solana — це те, що backend є глобальним блокчейном без дозволів. Це означає, що будь-хто може взаємодіяти з вашою програмою на блокчейні без необхідності видачі API-ключів або будь-яких інших форм дозволів. +1. **Розробка Програм на Блокчейні**: Тут ви створюєте та розгортаєте + користувацькі програми безпосередньо у блокчейні. Після розгортання будь-хто, + хто знає, як із ними працювати, може їх використовувати. Ці програми можна + писати на Rust, C або C++. Rust наразі має найбільшу підтримку для розробки + програм на блокчейні. +2. **Клієнтська Розробка**: Це створення програмного забезпечення + (децентралізованих додатків або dApps), яке взаємодіє з програмами на + блокчейні. Ваші додатки можуть надсилати транзакції для виконання дій у + блокчейні. Клієнтську розробку можна виконувати на будь-якій мові + програмування. + +"Зв'язок" між клієнтською та блокчейн-частиною забезпечується +[Solana JSON RPC API](https://solana.com/docs/rpc). Клієнтська частина надсилає +запити RPC до мережі Solana для взаємодії з програмами на блокчейні. Це дуже +схоже на звичайний процес розробки між frontend і backend. Головна відмінність у +роботі з Solana — це те, що backend є глобальним блокчейном без дозволів. Це +означає, що будь-хто може взаємодіяти з вашою програмою на блокчейні без +необхідності видачі API-ключів або будь-яких інших форм дозволів. ![Як клієнти працюють із блокчейном Solana](/assets/docs/intro/developer_flow.png) -Розробка на Solana відрізняється від інших блокчейнів завдяки своїм високо-композитним програмам на блокчейні. Це означає, що ви можете будувати на базі вже існуючих програм, часто без необхідності створення власних. Наприклад, якщо ви хочете працювати з токенами, ви можете використовувати [Token Program](/docs/uk/core/tokens.md), який вже розгорнутий у мережі. Уся розробка вашого додатка буде клієнтською, на обраній вами мові програмування. +Розробка на Solana відрізняється від інших блокчейнів завдяки своїм +високо-композитним програмам на блокчейні. Це означає, що ви можете будувати на +базі вже існуючих програм, часто без необхідності створення власних. Наприклад, +якщо ви хочете працювати з токенами, ви можете використовувати +[Token Program](/docs/uk/core/tokens.md), який вже розгорнутий у мережі. Уся +розробка вашого додатка буде клієнтською, на обраній вами мові програмування. -Розробники, які хочуть будувати на Solana, знайдуть, що стек розробки дуже схожий на інші. Основна відмінність у тому, що ви працюєте з блокчейном і повинні враховувати, як користувачі взаємодіють із вашим додатком на блокчейні, а не тільки у frontend. Розробка на Solana все ще включає CI/CD, тестування, інструменти для налагодження, frontend і backend, як і будь-який звичайний процес розробки. +Розробники, які хочуть будувати на Solana, знайдуть, що стек розробки дуже +схожий на інші. Основна відмінність у тому, що ви працюєте з блокчейном і +повинні враховувати, як користувачі взаємодіють із вашим додатком на блокчейні, +а не тільки у frontend. Розробка на Solana все ще включає CI/CD, тестування, +інструменти для налагодження, frontend і backend, як і будь-який звичайний +процес розробки. ## Що Вам Потрібно для Початку -Для початку розробки на Solana вам знадобляться різні інструменти залежно від того, чи ви розробляєте клієнтські додатки, програми на блокчейні або обидва. +Для початку розробки на Solana вам знадобляться різні інструменти залежно від +того, чи ви розробляєте клієнтські додатки, програми на блокчейні або обидва. ### Клієнтська Розробка Якщо ви розробляєте програми на блокчейні, вам потрібно знати Rust. -Якщо ж ви розробляєте клієнтські додатки, ви можете працювати на будь-якій мові програмування, з якою вам зручно. Solana має SDK, створені спільнотою, щоб допомогти розробникам взаємодіяти з мережею Solana на більшості популярних мов: +Якщо ж ви розробляєте клієнтські додатки, ви можете працювати на будь-якій мові +програмування, з якою вам зручно. Solana має SDK, створені спільнотою, щоб +допомогти розробникам взаємодіяти з мережею Solana на більшості популярних мов: | Мова | SDK | | ---------- | -------------------------------------------------------------------------------------------------------- | @@ -53,71 +82,116 @@ keywords: | C# | [solnet](https://github.com/bmresearch/Solnet) | | GdScript | [godot](https://github.com/Virus-Axel/godot-solana-sdk/) | -Вам також знадобиться підключення до RPC для взаємодії з мережею. Ви можете скористатися [провайдером RPC](https://solana.com/rpc) або [запустити власний RPC-вузол](https://docs.anza.xyz/operations/setup-an-rpc-node). +Вам також знадобиться підключення до RPC для взаємодії з мережею. Ви можете +скористатися [провайдером RPC](https://solana.com/rpc) або +[запустити власний RPC-вузол](https://docs.anza.xyz/operations/setup-an-rpc-node). -Щоб швидко розпочати роботу з фронтендом для вашого додатка, ви можете згенерувати налаштовуваний каркас Solana, ввівши наступну команду у ваш CLI: +Щоб швидко розпочати роботу з фронтендом для вашого додатка, ви можете +згенерувати налаштовуваний каркас Solana, ввівши наступну команду у ваш CLI: ```bash npx create-solana-dapp ``` -Ця команда створить новий проєкт із усіма необхідними файлами та базовою конфігурацією для початку розробки на Solana. Каркас включатиме як приклад фронтенда, так і шаблон програми на блокчейні (якщо ви його обрали). Ви можете ознайомитися з [документацією `create-solana-dapp`](https://github.com/solana-developers/create-solana-dapp?tab=readme-ov-file#create-solana-dapp), щоб дізнатися більше. +Ця команда створить новий проєкт із усіма необхідними файлами та базовою +конфігурацією для початку розробки на Solana. Каркас включатиме як приклад +фронтенда, так і шаблон програми на блокчейні (якщо ви його обрали). Ви можете +ознайомитися з +[документацією `create-solana-dapp`](https://github.com/solana-developers/create-solana-dapp?tab=readme-ov-file#create-solana-dapp), +щоб дізнатися більше. ### Розробка Програм на Блокчейні -Розробка програм на блокчейні включає написання програм на Rust, C або C++. Спочатку переконайтеся, що у вас встановлений Rust. Ви можете зробити це за допомогою наступної команди: +Розробка програм на блокчейні включає написання програм на Rust, C або C++. +Спочатку переконайтеся, що у вас встановлений Rust. Ви можете зробити це за +допомогою наступної команди: ```bash curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh ``` -Вам також потрібно встановити [Solana CLI](/docs/uk/intro/installation.md), щоб компілювати та розгортати ваші програми. Ви можете встановити Solana CLI, виконавши наступну команду: - +Вам також потрібно встановити [Solana CLI](/docs/uk/intro/installation.md), щоб +компілювати та розгортати ваші програми. Ви можете встановити Solana CLI, +виконавши наступну команду: ```bash sh -c "$(curl -sSfL https://release.anza.xyz/stable/install)" ``` -Використовуючи Solana CLI, рекомендується запускати локальний валідатор для тестування вашої програми. Щоб запустити локальний валідатор після встановлення Solana CLI, виконайте наступну команду: - +Використовуючи Solana CLI, рекомендується запускати локальний валідатор для +тестування вашої програми. Щоб запустити локальний валідатор після встановлення +Solana CLI, виконайте наступну команду: ```bash solana-test-validator ``` -Це запустить локальний валідатор на вашій машині, який ви можете використовувати для тестування ваших програм. Ви можете [докладніше прочитати про локальну розробку в цьому посібнику](/docs/uk/intro/installation.md). - -Під час розробки програм на блокчейні ви можете вибрати між написанням програм на чистому Rust (без фреймворку) або використанням фреймворку Anchor. Anchor спрощує розробку на Solana, надаючи високорівневий API для розробників. Подумайте про Anchor як про використання React для створення вебсайтів замість чистого Javascript і HTML. Хоча Javascript і HTML дають вам більше контролю, React прискорює розробку та робить її простішою. Докладніше про [Anchor](https://www.anchor-lang.com/) можна дізнатися на їхньому сайті. - -Вам знадобиться спосіб тестування вашої програми. Ось кілька способів тестування залежно від ваших уподобань щодо мови програмування: - -- [solana-program-test](https://docs.rs/solana-program-test/latest/solana_program_test/) — фреймворк для тестування, написаний на Rust. -- [solana-bankrun](https://kevinheavey.github.io/solana-bankrun/) — фреймворк для тестування, написаний для тестів на Typescript. -- [bankrun](https://kevinheavey.github.io/solders/tutorials/bankrun.html) — фреймворк для тестування, написаний для тестів на Python. - -Якщо ви не хочете розробляти програми локально, існує також [онлайн IDE Solana Playground](https://beta.solpg.io). Solana Playground дозволяє писати, тестувати та розгортати програми на Solana. Ви можете розпочати роботу з Solana Playground, [слідувавши нашому посібнику швидкого старту](/docs/uk/intro/quick-start). +Це запустить локальний валідатор на вашій машині, який ви можете використовувати +для тестування ваших програм. Ви можете +[докладніше прочитати про локальну розробку в цьому посібнику](/docs/uk/intro/installation.md). + +Під час розробки програм на блокчейні ви можете вибрати між написанням програм +на чистому Rust (без фреймворку) або використанням фреймворку Anchor. Anchor +спрощує розробку на Solana, надаючи високорівневий API для розробників. +Подумайте про Anchor як про використання React для створення вебсайтів замість +чистого Javascript і HTML. Хоча Javascript і HTML дають вам більше контролю, +React прискорює розробку та робить її простішою. Докладніше про +[Anchor](https://www.anchor-lang.com/) можна дізнатися на їхньому сайті. + +Вам знадобиться спосіб тестування вашої програми. Ось кілька способів тестування +залежно від ваших уподобань щодо мови програмування: + +- [solana-program-test](https://docs.rs/solana-program-test/latest/solana_program_test/) + — фреймворк для тестування, написаний на Rust. +- [solana-bankrun](https://kevinheavey.github.io/solana-bankrun/) — фреймворк + для тестування, написаний для тестів на Typescript. +- [bankrun](https://kevinheavey.github.io/solders/tutorials/bankrun.html) — + фреймворк для тестування, написаний для тестів на Python. + +Якщо ви не хочете розробляти програми локально, існує також +[онлайн IDE Solana Playground](https://beta.solpg.io). Solana Playground +дозволяє писати, тестувати та розгортати програми на Solana. Ви можете розпочати +роботу з Solana Playground, +[слідувавши нашому посібнику швидкого старту](/docs/uk/intro/quick-start). ### Середовища Розробки -Вибір правильного середовища залежно від вашої роботи дуже важливий. У Solana є кілька середовищ (кластерів) для забезпечення якісного тестування та CI/CD практик: +Вибір правильного середовища залежно від вашої роботи дуже важливий. У Solana є +кілька середовищ (кластерів) для забезпечення якісного тестування та CI/CD +практик: -- **Mainnet Beta**: Продуктивна мережа, де відбувається вся дія. Транзакції тут коштують реальних грошей. -- **Devnet**: Мережа для забезпечення якості, де ви розгортаєте ваші програми для тестування перед розгортанням у продуктивне середовище. Це як "середовище для постановки". -- **Local**: Локальна мережа, яку ви запускаєте на своїй машині за допомогою `solana-test-validator` для тестування ваших програм. Це має бути вашим першим вибором під час розробки. +- **Mainnet Beta**: Продуктивна мережа, де відбувається вся дія. Транзакції тут + коштують реальних грошей. +- **Devnet**: Мережа для забезпечення якості, де ви розгортаєте ваші програми + для тестування перед розгортанням у продуктивне середовище. Це як "середовище + для постановки". +- **Local**: Локальна мережа, яку ви запускаєте на своїй машині за допомогою + `solana-test-validator` для тестування ваших програм. Це має бути вашим першим + вибором під час розробки. ## Побудова на Основі Прикладів -Під час початку розробки на Solana є кілька ресурсів, які допоможуть прискорити ваш шлях: +Під час початку розробки на Solana є кілька ресурсів, які допоможуть прискорити +ваш шлях: -- [Solana Cookbook](https://solana.com/developers/cookbook): Збірка довідників і фрагментів коду для допомоги у розробці на Solana. -- [Приклади Програм Solana](https://github.com/solana-developers/program-examples): Репозиторій прикладів програм, що надають будівельні блоки для різних дій у ваших програмах. -- [Посібники](https://solana.com/developers/guides): Посібники та інструкції, які проведуть вас через процес розробки на Solana. +- [Solana Cookbook](https://solana.com/developers/cookbook): Збірка довідників і + фрагментів коду для допомоги у розробці на Solana. +- [Приклади Програм Solana](https://github.com/solana-developers/program-examples): + Репозиторій прикладів програм, що надають будівельні блоки для різних дій у + ваших програмах. +- [Посібники](https://solana.com/developers/guides): Посібники та інструкції, + які проведуть вас через процес розробки на Solana. ## Отримання Підтримки -Найкращу підтримку ви можете знайти на [Solana StackExchange](https://solana.stackexchange.com/). Спочатку пошукайте своє питання там — є велика ймовірність, що вже існує схоже питання з відповіддю. Якщо його там немає, додайте нове питання! Не забудьте включити якомога більше деталей у ваше питання, і, будь ласка, використовуйте текст (а не скріншоти) для відображення повідомлень про помилки, щоб інші люди з такою ж проблемою могли знайти ваше питання! +Найкращу підтримку ви можете знайти на +[Solana StackExchange](https://solana.stackexchange.com/). Спочатку пошукайте +своє питання там — є велика ймовірність, що вже існує схоже питання з +відповіддю. Якщо його там немає, додайте нове питання! Не забудьте включити +якомога більше деталей у ваше питання, і, будь ласка, використовуйте текст (а не +скріншоти) для відображення повідомлень про помилки, щоб інші люди з такою ж +проблемою могли знайти ваше питання! ## Наступні кроки [Тепер ви готові почати створювати на Solana!](/docs/uk/intro/quick-start) - diff --git a/docs/locales/uk/intro/installation.md b/docs/locales/uk/intro/installation.md index fb7dce6fc..117c101dd 100644 --- a/docs/locales/uk/intro/installation.md +++ b/docs/locales/uk/intro/installation.md @@ -14,50 +14,64 @@ altRoutes: - /setup --- -Цей розділ охоплює етапи налаштування локального середовища для розробки на Solana. +Цей розділ охоплює етапи налаштування локального середовища для розробки на +Solana. ## Встановлення Залежностей -- Користувачі Windows повинні спочатку встановити WSL (Windows Subsystem for Linux), а потім встановити залежності, зазначені в розділі Linux нижче. -- Користувачі Linux повинні спочатку встановити залежності, зазначені в розділі Linux нижче. +- Користувачі Windows повинні спочатку встановити WSL (Windows Subsystem for + Linux), а потім встановити залежності, зазначені в розділі Linux нижче. +- Користувачі Linux повинні спочатку встановити залежності, зазначені в розділі + Linux нижче. - Користувачі Mac повинні почати з інструкцій з установки Rust нижче. Для розробки програм Solana на Windows **необхідно використовувати -[WSL](https://learn.microsoft.com/en-us/windows/wsl/install)** (Windows Subsystem for Linux). Усі додаткові залежності необхідно встановлювати через термінал Linux. +[WSL](https://learn.microsoft.com/en-us/windows/wsl/install)** (Windows +Subsystem for Linux). Усі додаткові залежності необхідно встановлювати через +термінал Linux. -Після встановлення WSL встановіть залежності, зазначені в розділі Linux нижче, перш ніж переходити до установки Rust, Solana CLI та Anchor CLI. +Після встановлення WSL встановіть залежності, зазначені в розділі Linux нижче, +перш ніж переходити до установки Rust, Solana CLI та Anchor CLI. Щоб встановити WSL, виконайте наступну команду у Windows PowerShell: - ```shell wsl --install ``` -Процес встановлення запропонує вам створити обліковий запис користувача за замовчуванням. +Процес встановлення запропонує вам створити обліковий запис користувача за +замовчуванням. ![WSL Install](/assets/docs/intro/installation/wsl-install.png) -За замовчуванням WSL встановлює Ubuntu. Ви можете відкрити термінал Linux, ввівши "Ubuntu" у пошуковому рядку. +За замовчуванням WSL встановлює Ubuntu. Ви можете відкрити термінал Linux, +ввівши "Ubuntu" у пошуковому рядку. ![WSL Ubuntu](/assets/docs/intro/installation/wsl-ubuntu-search.png) -Якщо ваш термінал Ubuntu виглядає так, як на зображенні нижче, ви можете зіткнутися з проблемою, коли комбінація `ctrl + v` (вставити) не працює у терміналі. +Якщо ваш термінал Ubuntu виглядає так, як на зображенні нижче, ви можете +зіткнутися з проблемою, коли комбінація `ctrl + v` (вставити) не працює у +терміналі. ![Ubuntu Terminal](/assets/docs/intro/installation/wsl-ubuntu-terminal-1.png) -Якщо виникла ця проблема, відкрийте Windows Terminal, ввівши "Terminal" у пошуковому рядку. +Якщо виникла ця проблема, відкрийте Windows Terminal, ввівши "Terminal" у +пошуковому рядку. ![Windows Terminal](/assets/docs/intro/installation/wsl-windows-terminal.png) -Далі закрийте Windows Terminal і знову відкрийте термінал Linux, ввівши "Ubuntu" у пошуку. Тепер термінал має виглядати так, як на зображенні нижче, і комбінація `ctrl + v` (вставити) має працювати. +Далі закрийте Windows Terminal і знову відкрийте термінал Linux, ввівши "Ubuntu" +у пошуку. Тепер термінал має виглядати так, як на зображенні нижче, і комбінація +`ctrl + v` (вставити) має працювати. ![Ubuntu Terminal](/assets/docs/intro/installation/wsl-ubuntu-terminal-2.png) -Якщо ви використовуєте VS Code, розширення [WSL extension](https://code.visualstudio.com/docs/remote/wsl-tutorial) дозволяє використовувати WSL та VS Code разом. +Якщо ви використовуєте VS Code, розширення +[WSL extension](https://code.visualstudio.com/docs/remote/wsl-tutorial) дозволяє +використовувати WSL та VS Code разом. ![WSL Setup in VS Code](/assets/docs/intro/installation/wsl-vscode.png) @@ -65,7 +79,9 @@ wsl --install ![WSL: Ubuntu](/assets/docs/intro/installation/wsl-vscode-ubuntu.png) -Після налаштування WSL всі додаткові залежності потрібно встановлювати через термінал Linux. Встановіть залежності, зазначені в розділі Linux нижче, перш ніж переходити до встановлення Rust, Solana CLI та Anchor CLI. +Після налаштування WSL всі додаткові залежності потрібно встановлювати через +термінал Linux. Встановіть залежності, зазначені в розділі Linux нижче, перш ніж +переходити до встановлення Rust, Solana CLI та Anchor CLI. @@ -77,8 +93,8 @@ wsl --install ```shell sudo apt-get update ``` -Далі встановіть наступні залежності: +Далі встановіть наступні залежності: ```shell sudo apt-get install -y \ @@ -87,7 +103,9 @@ sudo apt-get install -y \ libudev-dev llvm libclang-dev \ protobuf-compiler libssl-dev ``` -Якщо під час встановлення `protobuf-compiler` ви зіткнетеся з такою помилкою, спочатку переконайтеся, що виконали команду `sudo apt-get update`: + +Якщо під час встановлення `protobuf-compiler` ви зіткнетеся з такою помилкою, +спочатку переконайтеся, що виконали команду `sudo apt-get update`: ``` Package protobuf-compiler is not available, but is referred to by another package. @@ -102,9 +120,11 @@ is only available from another source ### Встановлення Rust -Програми Solana пишуться на [мові програмування Rust](https://www.rust-lang.org/). +Програми Solana пишуться на +[мові програмування Rust](https://www.rust-lang.org/). -Рекомендований метод встановлення Rust — це [rustup](https://www.rust-lang.org/tools/install). +Рекомендований метод встановлення Rust — це +[rustup](https://www.rust-lang.org/tools/install). Виконайте наступну команду для встановлення Rust: @@ -135,7 +155,8 @@ source "$HOME/.cargo/env.fish" # For fish -Виконайте наступну команду, щоб оновити змінну середовища PATH і включити директорію `bin` Cargo: +Виконайте наступну команду, щоб оновити змінну середовища PATH і включити +директорію `bin` Cargo: ```shell . "$HOME/.cargo/env" @@ -155,17 +176,22 @@ rustc 1.80.1 (3f5fd8dd4 2024-08-06) ### Встановлення Solana CLI -Solana CLI надає всі необхідні інструменти для створення та розгортання програм Solana. +Solana CLI надає всі необхідні інструменти для створення та розгортання програм +Solana. -Встановіть набір інструментів Solana CLI за допомогою офіційної команди встановлення: +Встановіть набір інструментів Solana CLI за допомогою офіційної команди +встановлення: ```shell sh -c "$(curl -sSfL https://release.anza.xyz/stable/install)" ``` -Ви можете замінити `stable` на тег релізу, який відповідає версії програмного забезпечення потрібного релізу (наприклад, `v2.0.3`), або використовувати один із трьох символічних назв каналів: `stable`, `beta` або `edge`. +Ви можете замінити `stable` на тег релізу, який відповідає версії програмного +забезпечення потрібного релізу (наприклад, `v2.0.3`), або використовувати один +із трьох символічних назв каналів: `stable`, `beta` або `edge`. -Якщо ви встановлюєте Solana CLI вперше, ви можете побачити таке повідомлення із запитом на додавання змінної середовища PATH: +Якщо ви встановлюєте Solana CLI вперше, ви можете побачити таке повідомлення із +запитом на додавання змінної середовища PATH: ``` Close and reopen your terminal to apply the PATH changes or run the following in your existing shell: @@ -176,7 +202,9 @@ export PATH="/Users/test/.local/share/solana/install/active_release/bin:$PATH" -Якщо ви використовуєте термінал Linux або WSL, ви можете додати змінну середовища PATH у файл конфігурації вашої оболонки, виконавши команду, зазначену під час встановлення, або перезапустивши термінал. +Якщо ви використовуєте термінал Linux або WSL, ви можете додати змінну +середовища PATH у файл конфігурації вашої оболонки, виконавши команду, зазначену +під час встановлення, або перезапустивши термінал. ```shell export PATH="$HOME/.local/share/solana/install/active_release/bin:$PATH" @@ -185,16 +213,19 @@ export PATH="$HOME/.local/share/solana/install/active_release/bin:$PATH" -Якщо ви використовуєте Mac із оболонкою `zsh`, виконання стандартної команди `export PATH`, зазначеної під час встановлення, не зберігається після закриття термінала. +Якщо ви використовуєте Mac із оболонкою `zsh`, виконання стандартної команди +`export PATH`, зазначеної під час встановлення, не зберігається після закриття +термінала. -Замість цього ви можете додати PATH у файл конфігурації оболонки, виконавши наступну команду: +Замість цього ви можете додати PATH у файл конфігурації оболонки, виконавши +наступну команду: ```shell echo 'export PATH="$HOME/.local/share/solana/install/active_release/bin:$PATH"' >> ~/.zshrc ``` -Далі виконайте наступну команду, щоб оновити сесію термінала, або перезапустіть термінал. - +Далі виконайте наступну команду, щоб оновити сесію термінала, або перезапустіть +термінал. ```shell source ~/.zshrc @@ -205,27 +236,28 @@ source ~/.zshrc Щоб перевірити, чи встановлення було успішним, перевірте версію Solana CLI: - ```shell solana --version ``` -Ви повинні побачити результат, схожий на наступний: +Ви повинні побачити результат, схожий на наступний: ``` solana-cli 1.18.22 (src:9efdd74b; feat:4215500110, client:Agave) ``` -Ви можете переглянути всі доступні версії у [репозиторії Agave на Github](https://github.com/anza-xyz/agave/releases). +Ви можете переглянути всі доступні версії у +[репозиторії Agave на Github](https://github.com/anza-xyz/agave/releases). -Agave — це клієнт валідатора від [Anza](https://www.anza.xyz/), раніше відомий як клієнт валідатора Solana Labs. +Agave — це клієнт валідатора від [Anza](https://www.anza.xyz/), раніше відомий +як клієнт валідатора Solana Labs. -Щоб оновити Solana CLI до останньої версії, ви можете використати наступну команду: - +Щоб оновити Solana CLI до останньої версії, ви можете використати наступну +команду: ```shell agave-install update @@ -233,38 +265,43 @@ agave-install update ### Встановлення Anchor CLI -[Anchor](https://www.anchor-lang.com/) — це фреймворк для розробки програм на Solana. Anchor використовує макроси Rust, щоб спростити процес написання програм на Solana. +[Anchor](https://www.anchor-lang.com/) — це фреймворк для розробки програм на +Solana. Anchor використовує макроси Rust, щоб спростити процес написання програм +на Solana. Існує два способи встановлення Anchor CLI та інструментів: -1. За допомогою Anchor Version Manager (AVM) — **рекомендований спосіб встановлення**, оскільки він спрощує оновлення версій Anchor у майбутньому. -2. Без AVM — вимагає більш ручного процесу для оновлення версій Anchor у майбутньому. +1. За допомогою Anchor Version Manager (AVM) — **рекомендований спосіб + встановлення**, оскільки він спрощує оновлення версій Anchor у майбутньому. +2. Без AVM — вимагає більш ручного процесу для оновлення версій Anchor у + майбутньому. -Менеджер версій Anchor (AVM) дозволяє встановлювати та керувати різними версіями Anchor на вашій системі, включаючи зручне оновлення версій у майбутньому. +Менеджер версій Anchor (AVM) дозволяє встановлювати та керувати різними версіями +Anchor на вашій системі, включаючи зручне оновлення версій у майбутньому. Встановіть AVM за допомогою наступної команди: ```shell cargo install --git https://github.com/coral-xyz/anchor avm --force ``` -Перевірте, щоб переконатися, що AVM було встановлено та він доступний: +Перевірте, щоб переконатися, що AVM було встановлено та він доступний: ```shell avm --version ``` -Встановіть останню версію Anchor CLI за допомогою AVM: +Встановіть останню версію Anchor CLI за допомогою AVM: ```shell avm install latest avm use latest ``` -Або встановіть конкретну версію Anchor CLI, вказавши бажану версію: +Або встановіть конкретну версію Anchor CLI, вказавши бажану версію: ```shell avm install 0.30.1 @@ -290,7 +327,8 @@ cargo install --git https://github.com/coral-xyz/anchor --tag v0.30.1 anchor-cli -Під час встановлення ви можете побачити таке попередження. Однак це не впливає на процес встановлення. +Під час встановлення ви можете побачити таке попередження. Однак це не впливає +на процес встановлення. @@ -329,7 +367,8 @@ anchor --version anchor-cli 0.30.1 ``` -Під час встановлення Anchor CLI на Linux або WSL ви можете зіткнутися з такою помилкою: +Під час встановлення Anchor CLI на Linux або WSL ви можете зіткнутися з такою +помилкою: ``` error: could not exec the linker cc = note: Permission denied (os error 13) @@ -342,12 +381,15 @@ error: could not exec the linker cc = note: Permission denied (os error 13) #### Node.js та Yarn -Node.js та Yarn необхідні для запуску тестового файлу (TypeScript), створеного за допомогою команди `anchor init`. (Шаблон тестів на Rust також доступний за допомогою `anchor init --test-template rust`) +Node.js та Yarn необхідні для запуску тестового файлу (TypeScript), створеного +за допомогою команди `anchor init`. (Шаблон тестів на Rust також доступний за +допомогою `anchor init --test-template rust`) -Рекомендований спосіб встановлення Node — використання [Node Version Manager (nvm)](https://github.com/nvm-sh/nvm). +Рекомендований спосіб встановлення Node — використання +[Node Version Manager (nvm)](https://github.com/nvm-sh/nvm). Встановіть nvm за допомогою наступної команди: @@ -387,11 +429,13 @@ v22.7.0 ```shell npm install --global yarn ``` + Щоб перевірити, чи встановлення було успішним, перевірте версію Yarn: ``` yarn --version ``` + Ви повинні побачити наступний результат: ``` @@ -409,6 +453,7 @@ yarn --version ``` error: not a directory: '.../solana-release/bin/sdk/sbf/dependencies/platform-tools/rust/lib' ``` + Спробуйте ці рішення: 1. Примусове встановлення за допомогою наступної команди: @@ -433,16 +478,19 @@ rm -rf ~/.cache/solana/* version = 3 ``` -Дивіться [це обговорення](https://github.com/coral-xyz/anchor/issues/3392) для отримання додаткової інформації. - +Дивіться [це обговорення](https://github.com/coral-xyz/anchor/issues/3392) для +отримання додаткової інформації. -Після застосування будь-якого з рішень спробуйте знову виконати команду `anchor build`. +Після застосування будь-якого з рішень спробуйте знову виконати команду +`anchor build`. -Якщо ви використовуєте Linux або WSL і стикаєтеся з такими помилками під час виконання команди `anchor test` після створення нового проєкту Anchor, це може бути через відсутність Node.js або Yarn: +Якщо ви використовуєте Linux або WSL і стикаєтеся з такими помилками під час +виконання команди `anchor test` після створення нового проєкту Anchor, це може +бути через відсутність Node.js або Yarn: ``` Permission denied (os error 13) @@ -456,7 +504,8 @@ No such file or directory (os error 2) ## Основи Solana CLI -Цей розділ ознайомить вас із деякими поширеними командами Solana CLI для початку роботи. +Цей розділ ознайомить вас із деякими поширеними командами Solana CLI для початку +роботи. @@ -464,7 +513,6 @@ No such file or directory (os error 2) Щоб переглянути вашу поточну конфігурацію: - ```shell solana config get ``` @@ -479,7 +527,8 @@ Keypair Path: /Users/test/.config/solana/id.json Commitment: confirmed ``` -RPC URL та Websocket URL вказують кластер Solana, до якого CLI надсилатиме запити. За замовчуванням це буде mainnet-beta. +RPC URL та Websocket URL вказують кластер Solana, до якого CLI надсилатиме +запити. За замовчуванням це буде mainnet-beta. Ви можете оновити кластер Solana CLI за допомогою наступних команд: @@ -489,6 +538,7 @@ solana config set --url devnet solana config set --url localhost solana config set --url testnet ``` + Ви також можете використовувати наступні скорочені опції: ``` @@ -498,14 +548,19 @@ solana config set -ul # For localhost solana config set -ut # For testnet ``` -Шлях до ключової пари (Keypair Path) вказує розташування гаманця за замовчуванням, який використовується Solana CLI (для оплати комісій за транзакції та розгортання програм). Шлях за замовчуванням: `~/.config/solana/id.json`. У наступному кроці описано, як створити ключову пару за цим шляхом. +Шлях до ключової пари (Keypair Path) вказує розташування гаманця за +замовчуванням, який використовується Solana CLI (для оплати комісій за +транзакції та розгортання програм). Шлях за замовчуванням: +`~/.config/solana/id.json`. У наступному кроці описано, як створити ключову пару +за цим шляхом. ### Створення Гаманця -Для взаємодії з мережею Solana за допомогою Solana CLI вам потрібен гаманець Solana, поповнений SOL. - -Щоб створити ключову пару за замовчуванням у Keypair Path, виконайте наступну команду: +Для взаємодії з мережею Solana за допомогою Solana CLI вам потрібен гаманець +Solana, поповнений SOL. +Щоб створити ключову пару за замовчуванням у Keypair Path, виконайте наступну +команду: ```shell solana-keygen new @@ -534,11 +589,14 @@ cream bleak tortoise ocean nasty game gift forget fancy salon mimic amazing -Якщо у вас вже є гаманець у файловій системі, збережений у місці за замовчуванням, ця команда **НЕ** перезапише його, якщо ви явно не використаєте прапорець `--force`. +Якщо у вас вже є гаманець у файловій системі, збережений у місці за +замовчуванням, ця команда **НЕ** перезапише його, якщо ви явно не використаєте +прапорець `--force`. -Після створення ключової пари ви можете отримати адресу (публічний ключ) цієї пари за допомогою наступної команди: +Після створення ключової пари ви можете отримати адресу (публічний ключ) цієї +пари за допомогою наступної команди: ```shell solana address @@ -546,43 +604,47 @@ solana address ### Airdrop SOL -Після налаштування локального гаманця запросіть airdrop SOL для поповнення вашого гаманця. SOL потрібні для оплати комісій за транзакції та розгортання програм. +Після налаштування локального гаманця запросіть airdrop SOL для поповнення +вашого гаманця. SOL потрібні для оплати комісій за транзакції та розгортання +програм. Встановіть ваш кластер на devnet: - ```shell solana config set -ud ``` Далі запросіть airdrop SOL у devnet: - ```shell solana airdrop 2 ``` Щоб перевірити баланс SOL вашого гаманця, виконайте наступну команду: - ```shell solana balance ``` -Команда `solana airdrop` наразі обмежена 5 SOL за запит у devnet. Помилки можуть виникати через обмеження частоти запитів. +Команда `solana airdrop` наразі обмежена 5 SOL за запит у devnet. Помилки можуть +виникати через обмеження частоти запитів. -Як альтернативу, ви можете отримати SOL у devnet за допомогою [Solana Web Faucet](https://faucet.solana.com). +Як альтернативу, ви можете отримати SOL у devnet за допомогою +[Solana Web Faucet](https://faucet.solana.com). ### Запуск Локального Валідатора -Solana CLI постачається з вбудованим [тестовим валідатором](https://docs.anza.xyz/cli/examples/test-validator). Запуск локального валідатора дозволить вам розгортати та тестувати програми локально. - -У окремому терміналі виконайте наступну команду, щоб запустити локальний валідатор: +Solana CLI постачається з вбудованим +[тестовим валідатором](https://docs.anza.xyz/cli/examples/test-validator). +Запуск локального валідатора дозволить вам розгортати та тестувати програми +локально. +У окремому терміналі виконайте наступну команду, щоб запустити локальний +валідатор: ```shell solana-test-validator @@ -590,8 +652,8 @@ solana-test-validator -У WSL вам може знадобитися спочатку перейти до папки, де у вас є права запису за замовчуванням: - +У WSL вам може знадобитися спочатку перейти до папки, де у вас є права запису за +замовчуванням: ```shell cd ~ @@ -602,7 +664,8 @@ solana-test-validator -Переконайтеся, що оновили конфігурацію Solana CLI до `localhost` перед виконанням команд: +Переконайтеся, що оновили конфігурацію Solana CLI до `localhost` перед +виконанням команд: ```shell solana config set -ul diff --git a/docs/locales/uk/intro/quick-start/cross-program-invocation.md b/docs/locales/uk/intro/quick-start/cross-program-invocation.md index 58f36f10d..efc88ee2b 100644 --- a/docs/locales/uk/intro/quick-start/cross-program-invocation.md +++ b/docs/locales/uk/intro/quick-start/cross-program-invocation.md @@ -3,30 +3,30 @@ sidebarLabel: Крос-програмні виклики title: Крос-програмні виклики sidebarSortOrder: 5 description: - Дізнайтеся, як реалізувати крос-програмні виклики (CPIs) у програмах Solana - за допомогою фреймворку Anchor. У цьому підручнику демонструється, як - здійснювати переказ SOL між акаунтами, взаємодіяти з Системною програмою та - працювати з адресами, отриманими від програми (PDAs), у CPIs. Ідеально - підходить для розробників, які хочуть створювати інтегровані програми Solana. + Дізнайтеся, як реалізувати крос-програмні виклики (CPIs) у програмах Solana за + допомогою фреймворку Anchor. У цьому підручнику демонструється, як здійснювати + переказ SOL між акаунтами, взаємодіяти з Системною програмою та працювати з + адресами, отриманими від програми (PDAs), у CPIs. Ідеально підходить для + розробників, які хочуть створювати інтегровані програми Solana. --- У цьому розділі ми оновимо програму CRUD з попереднього розділу про PDA, щоб -додати крос-програмні виклики (CPIs). Ми модифікуємо програму, щоб -забезпечити переказ SOL між акаунтами в інструкціях `update` та `delete`, -демонструючи, як взаємодіяти з іншими програмами (у цьому випадку з -Системною програмою) зсередини нашої програми. +додати крос-програмні виклики (CPIs). Ми модифікуємо програму, щоб забезпечити +переказ SOL між акаунтами в інструкціях `update` та `delete`, демонструючи, як +взаємодіяти з іншими програмами (у цьому випадку з Системною програмою) +зсередини нашої програми. Метою цього розділу є покрокове пояснення процесу реалізації CPIs у програмі Solana за допомогою фреймворку Anchor, спираючись на концепції PDA, які ми -розглядали в попередньому розділі. Для отримання додаткової інформації -перейдіть на сторінку [Крос-програмні виклики](/docs/uk/core/cpi). +розглядали в попередньому розділі. Для отримання додаткової інформації перейдіть +на сторінку [Крос-програмні виклики](/docs/uk/core/cpi). ### Модифікація інструкції Update -Спочатку ми реалізуємо простий механізм "оплати за оновлення" шляхом -модифікації структури `Update` та функції `update`. +Спочатку ми реалізуємо простий механізм "оплати за оновлення" шляхом модифікації +структури `Update` та функції `update`. Розпочнемо з оновлення файлу `lib.rs`, щоб включити до області видимості елементи з модуля `system_program`. @@ -46,7 +46,9 @@ use anchor_lang::system_program::{transfer, Transfer}; -Далі оновіть структуру Update, щоб включити додатковий акаунт під назвою `vault_account`. Цей акаунт, який контролюється нашою програмою, отримуватиме SOL від користувача, коли той оновлює свій акаунт повідомлень. +Далі оновіть структуру Update, щоб включити додатковий акаунт під назвою +`vault_account`. Цей акаунт, який контролюється нашою програмою, отримуватиме +SOL від користувача, коли той оновлює свій акаунт повідомлень. ```rs filename="lib.rs" #[account( @@ -90,7 +92,9 @@ pub struct Update<'info> { Ми додаємо новий акаунт під назвою `vault_account` до нашої структури `Update`. Цей акаунт служить програмно-контрольованим "сейфом", який буде отримувати SOL від користувачів, коли вони оновлюють свої повідомлення. -Використовуючи PDA (Program Derived Address) для сейфа, ми створюємо програмно-контрольований акаунт, унікальний для кожного користувача, що дозволяє нам управляти коштами користувачів у межах логіки нашої програми. +Використовуючи PDA (Program Derived Address) для сейфа, ми створюємо +програмно-контрольований акаунт, унікальний для кожного користувача, що дозволяє +нам управляти коштами користувачів у межах логіки нашої програми. --- @@ -100,26 +104,31 @@ pub struct Update<'info> { Адреса акаунта є PDA, що отримується за допомогою сідів: `[b"vault", user.key().as_ref()]` - **Відсутність приватного ключа**: - Оскільки це PDA, він не має приватного ключа, тому лише наша програма може "підписуватися" за цю адресу під час виконання CPIs. + Оскільки це PDA, він не має приватного ключа, тому лише наша програма може + "підписуватися" за цю адресу під час виконання CPIs. - **Тип акаунта**: - Це акаунт типу `SystemAccount`, який належить до Системної програми, як і звичайні гаманці. + Це акаунт типу `SystemAccount`, який належить до Системної програми, як і + звичайні гаманці. --- Ця структура дозволяє нашій програмі: - Генерувати унікальні, детерміновані адреси для кожного "сейфа" користувача. -- Контролювати кошти без необхідності використання приватного ключа для підписання транзакцій. +- Контролювати кошти без необхідності використання приватного ключа для + підписання транзакцій. --- -У інструкції `delete` ми покажемо, як наша програма може "підписуватися" за цей PDA під час CPI. +У інструкції `delete` ми покажемо, як наша програма може "підписуватися" за цей +PDA під час CPI. --- Далі: реалізуйте логіку CPI в інструкції `update` -Реалізуйте логіку CPI для переказу **0.001 SOL** з акаунта користувача на акаунт сейфа. +Реалізуйте логіку CPI для переказу **0.001 SOL** з акаунта користувача на акаунт +сейфа. ```rs filename="lib.rs" let transfer_accounts = Transfer { @@ -158,9 +167,12 @@ transfer(cpi_context, 1_000_000)?; -В інструкції `update` ми реалізуємо виклик між програмами (CPI), щоб викликати інструкцію `transfer` Системної програми. Це демонструє, як виконати CPI у межах нашої програми, забезпечуючи композиційність програм у Solana. +В інструкції `update` ми реалізуємо виклик між програмами (CPI), щоб викликати +інструкцію `transfer` Системної програми. Це демонструє, як виконати CPI у межах +нашої програми, забезпечуючи композиційність програм у Solana. -Структура `Transfer` визначає необхідні акаунти для інструкції `transfer` Системної програми: +Структура `Transfer` визначає необхідні акаунти для інструкції `transfer` +Системної програми: - `from` - Акаунт користувача (джерело коштів) - `to` - Акаунт сейфа (ціль для переказу коштів) @@ -171,7 +183,8 @@ transfer(cpi_context, 1_000_000)?; to: ctx.accounts.vault_account.to_account_info(), }; ``` -`CpiContext` визначає: + + `CpiContext` визначає: - Програму, яку потрібно викликати (Системна програма) - Акаунти, необхідні для CPI (визначені у структурі `Transfer`) @@ -188,13 +201,16 @@ transfer(cpi_context, 1_000_000)?; - `cpi_context` (програму та акаунти) - Суму для переказу (1,000,000 лампортів, що еквівалентно 0.001 SOL) - ```rs filename="lib.rs" transfer(cpi_context, 1_000_000)?; ``` --- -Налаштування для CPI відповідає тому, як створюються інструкції на стороні клієнта, де ми вказуємо програму, акаунти та дані інструкції для виклику конкретної інструкції. Коли викликається інструкція `update` нашої програми, вона внутрішньо викликає інструкцію переказу Системної програми. + +Налаштування для CPI відповідає тому, як створюються інструкції на стороні +клієнта, де ми вказуємо програму, акаунти та дані інструкції для виклику +конкретної інструкції. Коли викликається інструкція `update` нашої програми, +вона внутрішньо викликає інструкцію переказу Системної програми. @@ -204,11 +220,15 @@ transfer(cpi_context, 1_000_000)?; ```shell filename="Terminal" build ``` + ### Змініть Інструкцію Delete -Ми реалізуємо механізм "повернення коштів при видаленні", змінивши структуру `Delete` та функцію `delete`. +Ми реалізуємо механізм "повернення коштів при видаленні", змінивши структуру +`Delete` та функцію `delete`. -Спершу оновіть структуру `Delete`, додавши до неї `vault_account`. Це дозволить нам переказати всі SOL із сейфа назад користувачеві, коли він закриває свій акаунт повідомлення. +Спершу оновіть структуру `Delete`, додавши до неї `vault_account`. Це дозволить +нам переказати всі SOL із сейфа назад користувачеві, коли він закриває свій +акаунт повідомлення. ```rs filename="lib.rs" #[account( @@ -219,7 +239,8 @@ build pub vault_account: SystemAccount<'info>, ``` -Також додайте `system_program`, оскільки CPI для переказу вимагає виклику Системної програми. +Також додайте `system_program`, оскільки CPI для переказу вимагає виклику +Системної програми. ```rs filename="lib.rs" pub system_program: Program<'info, System>, @@ -256,12 +277,15 @@ pub struct Delete<'info> { Акаунт `vault_account` використовує той самий PDA, що і в структурі `Update`. -Додавання `vault_account` до структури `Delete` дозволяє нашій програмі отримати доступ до сейфа користувача під час виконання інструкції видалення, щоб переказати накопичені SOL назад користувачеві. +Додавання `vault_account` до структури `Delete` дозволяє нашій програмі отримати +доступ до сейфа користувача під час виконання інструкції видалення, щоб +переказати накопичені SOL назад користувачеві. -Далі реалізуйте логіку CPI в інструкції `delete`, щоб переказати SOL із сейфа назад на акаунт користувача. +Далі реалізуйте логіку CPI в інструкції `delete`, щоб переказати SOL із сейфа +назад на акаунт користувача. ```rs filename="lib.rs" let user_key = ctx.accounts.user.key(); @@ -279,7 +303,8 @@ let cpi_context = CpiContext::new( transfer(cpi_context, ctx.accounts.vault_account.lamports())?; ``` -Зверніть увагу, що ми оновили `_ctx: Context` до `ctx: Context`, оскільки будемо використовувати контекст у тілі функції. +Зверніть увагу, що ми оновили `_ctx: Context` до `ctx: Context`, +оскільки будемо використовувати контекст у тілі функції. @@ -318,19 +343,21 @@ let user_key = ctx.accounts.user.key(); let signer_seeds: &[&[&[u8]]] = &[&[b"vault", user_key.as_ref(), &[ctx.bumps.vault_account]]]; ``` -Структура `Transfer` визначає необхідні акаунти для інструкції переказу Системної програми: + +Структура `Transfer` визначає необхідні акаунти для інструкції переказу +Системної програми: - `from`: Акаунт сейфа (джерело коштів) - `to`: Акаунт користувача (ціль для переказу коштів) - ```rs filename="lib.rs" let transfer_accounts = Transfer { from: ctx.accounts.vault_account.to_account_info(), to: ctx.accounts.user.to_account_info(), }; ``` -`CpiContext` визначає: + + `CpiContext` визначає: - Програму, яку потрібно викликати (Системна програма) - Акаунти, задіяні у переказі (визначені у структурі `Transfer`) @@ -342,7 +369,9 @@ let signer_seeds: &[&[&[u8]]] = transfer_accounts, ).with_signer(signer_seeds); ``` -Функція `transfer` викликає інструкцію переказу в Системній програмі, передаючи: + + Функція `transfer` викликає інструкцію переказу в Системній програмі, + передаючи: - `cpi_context` (програму, акаунти та підписувач на основі PDA) - Суму для переказу (весь баланс акаунта сейфа) @@ -350,7 +379,11 @@ let signer_seeds: &[&[&[u8]]] = ```rs filename="lib.rs" transfer(cpi_context, ctx.accounts.vault_account.lamports())?; ``` -Ця реалізація CPI демонструє, як програми можуть використовувати PDA для управління коштами. Коли викликається інструкція `delete` нашої програми, вона внутрішньо викликає інструкцію переказу Системної програми, підписуючи за PDA, щоб авторизувати переказ усіх коштів із сейфа назад користувачеві. + + Ця реалізація CPI демонструє, як програми можуть використовувати PDA для + управління коштами. Коли викликається інструкція `delete` нашої програми, вона + внутрішньо викликає інструкцію переказу Системної програми, підписуючи за PDA, + щоб авторизувати переказ усіх коштів із сейфа назад користувачеві. @@ -363,7 +396,10 @@ build ### Розгортання Програми -Після внесення цих змін нам потрібно повторно розгорнути оновлену програму. Це забезпечує доступність модифікованої програми для тестування. У Solana оновлення програми вимагає лише розгортання скомпільованої програми за тим самим ідентифікатором програми (program ID). +Після внесення цих змін нам потрібно повторно розгорнути оновлену програму. Це +забезпечує доступність модифікованої програми для тестування. У Solana оновлення +програми вимагає лише розгортання скомпільованої програми за тим самим +ідентифікатором програми (program ID). ```shell filename="Terminal" deploy @@ -381,22 +417,28 @@ Deployment successful. Completed in 17s. -Лише орган влади оновлення (upgrade authority) програми може її оновити. Орган влади оновлення встановлюється під час розгортання програми, і це єдиний акаунт, який має дозвіл модифікувати або закривати програму. Якщо орган влади оновлення відкликається, програма стає незмінною і її ніколи не можна буде закрити або оновити. +Лише орган влади оновлення (upgrade authority) програми може її оновити. Орган +влади оновлення встановлюється під час розгортання програми, і це єдиний акаунт, +який має дозвіл модифікувати або закривати програму. Якщо орган влади оновлення +відкликається, програма стає незмінною і її ніколи не можна буде закрити або +оновити. -Під час розгортання програм у Solana Playground гаманцем Playground є орган влади оновлення для всіх ваших програм. +Під час розгортання програм у Solana Playground гаманцем Playground є орган +влади оновлення для всіх ваших програм. ### Оновлення Файлу Тестів -Далі ми оновимо наш файл `anchor.test.ts`, щоб включити новий акаунт сейфа у наші інструкції. Це вимагає отримання PDA сейфа та його включення до викликів інструкцій `update` і `delete`. +Далі ми оновимо наш файл `anchor.test.ts`, щоб включити новий акаунт сейфа у +наші інструкції. Це вимагає отримання PDA сейфа та його включення до викликів +інструкцій `update` і `delete`. #### Отримання PDA Сейфа Спершу додайте код для отримання PDA сейфа: - ```ts filename="anchor.test.ts" const [vaultPda, vaultBump] = PublicKey.findProgramAddressSync( [Buffer.from("vault"), wallet.publicKey.toBuffer()], @@ -489,7 +531,8 @@ const transactionSignature = await program.methods ### Перезапуск Тестів -Після внесення цих змін запустіть тести, щоб переконатися, що все працює, як очікувалося: +Після внесення цих змін запустіть тести, щоб переконатися, що все працює, як +очікувалося: ```shell filename="Terminal" test @@ -531,22 +574,34 @@ Running tests... ![Delete CPI](/assets/docs/intro/quickstart/cpi-delete.png) -Якщо ви зіткнулися з помилками, ви можете переглянути [фінальний код](https://beta.solpg.io/668304cfcffcf4b13384d20a). +Якщо ви зіткнулися з помилками, ви можете переглянути +[фінальний код](https://beta.solpg.io/668304cfcffcf4b13384d20a). ## Наступні Кроки -Ви завершили посібник з швидкого старту Solana! Ви дізналися про акаунти, транзакції, PDA, CPI та розгорнули власні програми. +Ви завершили посібник з швидкого старту Solana! Ви дізналися про акаунти, +транзакції, PDA, CPI та розгорнули власні програми. -Відвідайте сторінки [Основні Концепції](/docs/uk/core/accounts) для більш детального пояснення тем, розглянутих у цьому посібнику. +Відвідайте сторінки [Основні Концепції](/docs/uk/core/accounts) для більш +детального пояснення тем, розглянутих у цьому посібнику. -Додаткові навчальні матеріали доступні на сторінці [Ресурси для Розробників](/developers). +Додаткові навчальні матеріали доступні на сторінці +[Ресурси для Розробників](/developers). ### Досліджуйте Більше Прикладів -Якщо ви віддаєте перевагу навчанню через приклади, перегляньте [Репозиторій з Прикладами Програм](https://github.com/solana-developers/program-examples) для різноманітних прикладів програм. +Якщо ви віддаєте перевагу навчанню через приклади, перегляньте +[Репозиторій з Прикладами Програм](https://github.com/solana-developers/program-examples) +для різноманітних прикладів програм. -Solana Playground пропонує зручну функцію, яка дозволяє імпортувати або переглядати проєкти за їх посиланнями на GitHub. Наприклад, відкрийте це [посилання Solana Playground](https://beta.solpg.io/https://github.com/solana-developers/program-examples/tree/main/basics/hello-solana/anchor), щоб переглянути Anchor-проєкт із цього [репозиторію GitHub](https://github.com/solana-developers/program-examples/tree/main/basics/hello-solana/anchor). +Solana Playground пропонує зручну функцію, яка дозволяє імпортувати або +переглядати проєкти за їх посиланнями на GitHub. Наприклад, відкрийте це +[посилання Solana Playground](https://beta.solpg.io/https://github.com/solana-developers/program-examples/tree/main/basics/hello-solana/anchor), +щоб переглянути Anchor-проєкт із цього +[репозиторію GitHub](https://github.com/solana-developers/program-examples/tree/main/basics/hello-solana/anchor). -Натисніть кнопку `Import` і введіть ім'я проєкту, щоб додати його до свого списку проєктів у Solana Playground. Після імпорту проєкту всі зміни автоматично зберігаються та залишаються у середовищі Playground. +Натисніть кнопку `Import` і введіть ім'я проєкту, щоб додати його до свого +списку проєктів у Solana Playground. Після імпорту проєкту всі зміни автоматично +зберігаються та залишаються у середовищі Playground. diff --git a/docs/locales/uk/intro/quick-start/deploying-programs.md b/docs/locales/uk/intro/quick-start/deploying-programs.md index ddcbbc83a..f81745580 100644 --- a/docs/locales/uk/intro/quick-start/deploying-programs.md +++ b/docs/locales/uk/intro/quick-start/deploying-programs.md @@ -3,14 +3,19 @@ sidebarLabel: Розгортання Програм title: Розгортання Вашої Першої Програми Solana sidebarSortOrder: 3 description: - Дізнайтеся, як створити, розгорнути та протестувати вашу першу програму Solana за допомогою - фреймворку Anchor та Solana Playground. Цей посібник для початківців демонструє, як створити просту програму, - розгорнути її на devnet, виконати тести та закрити програму. + Дізнайтеся, як створити, розгорнути та протестувати вашу першу програму Solana + за допомогою фреймворку Anchor та Solana Playground. Цей посібник для + початківців демонструє, як створити просту програму, розгорнути її на devnet, + виконати тести та закрити програму. --- -У цьому розділі ми створимо, розгорнемо та протестуємо просту програму Solana за допомогою фреймворку Anchor. Наприкінці ви розгорнете свою першу програму у блокчейні Solana! +У цьому розділі ми створимо, розгорнемо та протестуємо просту програму Solana за +допомогою фреймворку Anchor. Наприкінці ви розгорнете свою першу програму у +блокчейні Solana! -Мета цього розділу — ознайомити вас із Solana Playground. Ми розглянемо більш детальний приклад у розділах про PDA та CPI. Для отримання додаткової інформації відвідайте сторінку [Програми на Solana](/docs/core/programs). +Мета цього розділу — ознайомити вас із Solana Playground. Ми розглянемо більш +детальний приклад у розділах про PDA та CPI. Для отримання додаткової інформації +відвідайте сторінку [Програми на Solana](/docs/core/programs). @@ -20,7 +25,8 @@ description: - Натисніть кнопку "Create a new project" у лівій панелі. -- Введіть назву проєкту, виберіть Anchor як фреймворк, потім натисніть кнопку "Create". +- Введіть назву проєкту, виберіть Anchor як фреймворк, потім натисніть кнопку + "Create". ![Новий Проєкт](/assets/docs/intro/quickstart/pg-new-project.gif) @@ -66,12 +72,15 @@ pub struct NewAccount { На даний момент ми розглянемо лише загальний огляд коду програми: -- Макрос `declare_id!` визначає адресy вашої програми у блокчейні. Ця адреса буде автоматично оновлена, коли ми скомпілюємо програму на наступному етапі. +- Макрос `declare_id!` визначає адресy вашої програми у блокчейні. Ця адреса + буде автоматично оновлена, коли ми скомпілюємо програму на наступному етапі. ```rs declare_id!("11111111111111111111111111111111"); ``` -- Макрос `#[program]` позначає модуль, який містить функції, що представляють інструкції програми. + +- Макрос `#[program]` позначає модуль, який містить функції, що представляють + інструкції програми. ```rs #[program] @@ -84,28 +93,38 @@ pub struct NewAccount { } } ``` -У цьому прикладі інструкція `initialize` приймає два параметри: -1. `ctx: Context` — надає доступ до акаунтів, необхідних для цієї інструкції, як це зазначено у структурі `Initialize`. -2. `data: u64` — параметр інструкції, який передається під час виклику інструкції. + У цьому прикладі інструкція `initialize` приймає два параметри: -Тіло функції встановлює значення поля `data` для `new_account` відповідно до переданого аргументу `data`, а потім виводить повідомлення до журналу програми. +1. `ctx: Context` — надає доступ до акаунтів, необхідних для цієї + інструкції, як це зазначено у структурі `Initialize`. +2. `data: u64` — параметр інструкції, який передається під час виклику + інструкції. -- Макрос `#[derive(Accounts)]` використовується для визначення структури, яка задає акаунти, необхідні для певної інструкції, де кожне поле представляє окремий акаунт. +Тіло функції встановлює значення поля `data` для `new_account` відповідно до +переданого аргументу `data`, а потім виводить повідомлення до журналу програми. -Типи полів (наприклад, `Signer<'info>`) і обмеження (наприклад, `#[account(mut)]`) використовуються Anchor для автоматичного виконання стандартних перевірок безпеки, пов'язаних із валідацією акаунтів. +- Макрос `#[derive(Accounts)]` використовується для визначення структури, яка + задає акаунти, необхідні для певної інструкції, де кожне поле представляє + окремий акаунт. - ```rs - #[derive(Accounts)] - pub struct Initialize<'info> { - #[account(init, payer = signer, space = 8 + 8)] - pub new_account: Account<'info, NewAccount>, - #[account(mut)] - pub signer: Signer<'info>, - pub system_program: Program<'info, System>, - } - ``` -- Макрос `#[account]` використовується для визначення структури, яка представляє структуру даних акаунта, створеного та керованого програмою. +Типи полів (наприклад, `Signer<'info>`) і обмеження (наприклад, +`#[account(mut)]`) використовуються Anchor для автоматичного виконання +стандартних перевірок безпеки, пов'язаних із валідацією акаунтів. + +```rs +#[derive(Accounts)] +pub struct Initialize<'info> { + #[account(init, payer = signer, space = 8 + 8)] + pub new_account: Account<'info, NewAccount>, + #[account(mut)] + pub signer: Signer<'info>, + pub system_program: Program<'info, System>, +} +``` + +- Макрос `#[account]` використовується для визначення структури, яка представляє + структуру даних акаунта, створеного та керованого програмою. ```rs #[account] @@ -124,7 +143,9 @@ pub struct NewAccount { ```shell filename="Terminal" build ``` -Зверніть увагу, що адреса у `declare_id!()` була оновлена. Це адреса вашої програми у блокчейні. + +Зверніть увагу, що адреса у `declare_id!()` була оновлена. Це адреса вашої +програми у блокчейні. @@ -139,7 +160,9 @@ Build successful. Completed in 1.46s. Після компіляції програми виконайте команду `deploy` у терміналі, щоб розгорнути програму в мережі (за замовчуванням devnet). Для розгортання програми необхідно виділити SOL для акаунта у блокчейні, який зберігатиме програму. -Перед розгортанням переконайтеся, що у вас достатньо SOL. Ви можете отримати devnet SOL, виконавши команду `solana airdrop 5` у терміналі Playground або скориставшись [веб-фонтаном](https://faucet.solana.com/). +Перед розгортанням переконайтеся, що у вас достатньо SOL. Ви можете отримати +devnet SOL, виконавши команду `solana airdrop 5` у терміналі Playground або +скориставшись [веб-фонтаном](https://faucet.solana.com/). ```shell filename="Terminal" deploy @@ -158,7 +181,8 @@ Deployment successful. Completed in 19s. -Альтернативно, ви також можете скористатися кнопками `Build` і `Deploy` на лівій панелі. +Альтернативно, ви також можете скористатися кнопками `Build` і `Deploy` на лівій +панелі. ![Build and Deploy](/assets/docs/intro/quickstart/pg-build-deploy.png) @@ -166,7 +190,9 @@ Deployment successful. Completed in 19s. ### Тестування Програми -Разом із стартовим кодом включений тестовий файл, який знаходиться у `tests/anchor.test.ts`. У цьому файлі показано, як викликати інструкцію `initialize` у стартовій програмі з клієнта. +Разом із стартовим кодом включений тестовий файл, який знаходиться у +`tests/anchor.test.ts`. У цьому файлі показано, як викликати інструкцію +`initialize` у стартовій програмі з клієнта. ```ts filename="anchor.test.ts" // No imports needed: web3, anchor, pg and more are globally available @@ -204,11 +230,14 @@ describe("Test", () => { }); }); ``` -Щоб запустити тестовий файл після розгортання програми, виконайте команду `test` у терміналі. + +Щоб запустити тестовий файл після розгортання програми, виконайте команду `test` +у терміналі. ```shell filename="Terminal" test ``` + Ви повинні побачити результат, який вказує, що тест пройшов успішно. @@ -231,7 +260,8 @@ Running tests... ![Run Test](/assets/docs/intro/quickstart/pg-test.png) -Потім ви можете переглянути журнали транзакцій, виконавши команду `solana confirm -v` та вказавши хеш транзакції (підпис) із результатів тесту: +Потім ви можете переглянути журнали транзакцій, виконавши команду +`solana confirm -v` та вказавши хеш транзакції (підпис) із результатів тесту: ```shell filename="Terminal" solana confirm -v [TxHash] @@ -289,7 +319,10 @@ Confirmed -Альтернативно, ви можете переглянути деталі транзакції на [SolanaFM](https://solana.fm/) або [Solana Explorer](https://explorer.solana.com/?cluster=devnet), здійснивши пошук за підписом (хешем) транзакції. +Альтернативно, ви можете переглянути деталі транзакції на +[SolanaFM](https://solana.fm/) або +[Solana Explorer](https://explorer.solana.com/?cluster=devnet), здійснивши пошук +за підписом (хешем) транзакції. Нагадуємо, що потрібно оновити підключення до кластеру (мережі) у вибраному Explorer, щоб воно відповідало кластеру Solana Playground. За замовчуванням у Solana Playground використовується кластер devnet. @@ -297,9 +330,11 @@ Confirmed ### Закриття Програми -Нарешті, SOL, виділений для програми у блокчейні, може бути повністю повернутий шляхом закриття програми. +Нарешті, SOL, виділений для програми у блокчейні, може бути повністю повернутий +шляхом закриття програми. -Ви можете закрити програму, виконавши наступну команду та вказавши адресу програми, яка знаходиться у `declare_id!()`: +Ви можете закрити програму, виконавши наступну команду та вказавши адресу +програми, яка знаходиться у `declare_id!()`: ```shell filename="Terminal" solana program close [ProgramID] @@ -322,14 +357,18 @@ Closed Program Id 2VvQ11q8xrn5tkPNyeraRsPaATdiPx8weLAD8aD4dn2r, 2.79511512 SOL r -Тільки орган влади оновлення програми може її закрити. Орган влади оновлення встановлюється під час розгортання програми, і це єдиний акаунт, який має дозвіл модифікувати або закривати програму. Якщо орган влади оновлення відкликається, програма стає незмінною і її ніколи не можна буде закрити або оновити. +Тільки орган влади оновлення програми може її закрити. Орган влади оновлення +встановлюється під час розгортання програми, і це єдиний акаунт, який має дозвіл +модифікувати або закривати програму. Якщо орган влади оновлення відкликається, +програма стає незмінною і її ніколи не можна буде закрити або оновити. -Під час розгортання програм у Solana Playground гаманцем Playground є орган влади оновлення для всіх ваших програм. +Під час розгортання програм у Solana Playground гаманцем Playground є орган +влади оновлення для всіх ваших програм. -Вітаємо! Ви щойно створили та розгорнули свою першу програму Solana за допомогою фреймворку Anchor! +Вітаємо! Ви щойно створили та розгорнули свою першу програму Solana за допомогою +фреймворку Anchor! - diff --git a/docs/locales/uk/intro/quick-start/index.md b/docs/locales/uk/intro/quick-start/index.md index 1a164ae56..3d22ddc46 100644 --- a/docs/locales/uk/intro/quick-start/index.md +++ b/docs/locales/uk/intro/quick-start/index.md @@ -8,33 +8,48 @@ description: Solana Playground – без необхідності встановлення. --- -Ласкаво просимо до посібника з швидкого старту Solana! Цей практичний посібник ознайомить вас із ключовими концепціями створення програм на Solana, незалежно від вашого попереднього досвіду. Після завершення цього уроку у вас буде базове розуміння розробки на Solana, і ви зможете досліджувати більш складні теми. +Ласкаво просимо до посібника з швидкого старту Solana! Цей практичний посібник +ознайомить вас із ключовими концепціями створення програм на Solana, незалежно +від вашого попереднього досвіду. Після завершення цього уроку у вас буде базове +розуміння розробки на Solana, і ви зможете досліджувати більш складні теми. ## Чого Ви Навчитеся У цьому уроці ви дізнаєтеся про: - **Розуміння акаунтів**: Дослідження зберігання даних у мережі Solana. -- **Надсилання транзакцій**: Взаємодія з мережею Solana шляхом надсилання транзакцій. -- **Створення та розгортання програм**: Створіть свою першу програму Solana та розгорніть її в мережі. -- **Program Derived Addresses (PDA)**: Як використовувати PDA для створення детермінованих адрес акаунтів. -- **Cross-Program Invocations (CPI)**: Як зробити так, щоб ваші програми взаємодіяли з іншими програмами на Solana. - -Найкраще те, що вам нічого не потрібно встановлювати! Ми будемо використовувати Solana Playground, браузерне середовище розробки, для всіх наших прикладів. Це означає, що ви можете слідувати урокам, копіювати та вставляти код і одразу бачити результати прямо у вашому браузері. Базові знання програмування бажані, але не обов’язкові. +- **Надсилання транзакцій**: Взаємодія з мережею Solana шляхом надсилання + транзакцій. +- **Створення та розгортання програм**: Створіть свою першу програму Solana та + розгорніть її в мережі. +- **Program Derived Addresses (PDA)**: Як використовувати PDA для створення + детермінованих адрес акаунтів. +- **Cross-Program Invocations (CPI)**: Як зробити так, щоб ваші програми + взаємодіяли з іншими програмами на Solana. + +Найкраще те, що вам нічого не потрібно встановлювати! Ми будемо використовувати +Solana Playground, браузерне середовище розробки, для всіх наших прикладів. Це +означає, що ви можете слідувати урокам, копіювати та вставляти код і одразу +бачити результати прямо у вашому браузері. Базові знання програмування бажані, +але не обов’язкові. Давайте почнемо будувати на Solana! ## Solana Playground -Solana Playground (Solpg) – це браузерне середовище розробки, яке дозволяє швидко розробляти, розгортати та тестувати програми Solana! +Solana Playground (Solpg) – це браузерне середовище розробки, яке дозволяє +швидко розробляти, розгортати та тестувати програми Solana! -Відкрийте нову вкладку у своєму браузері та перейдіть на [https://beta.solpg.io/](https://beta.solpg.io/). +Відкрийте нову вкладку у своєму браузері та перейдіть на +[https://beta.solpg.io/](https://beta.solpg.io/). ### Створення Гаманця Playground -Якщо ви новачок у Solana Playground, першим кроком буде створення гаманця Playground. Цей гаманець дозволить вам взаємодіяти з мережею Solana безпосередньо з вашого браузера. +Якщо ви новачок у Solana Playground, першим кроком буде створення гаманця +Playground. Цей гаманець дозволить вам взаємодіяти з мережею Solana +безпосередньо з вашого браузера. #### Крок 1. Підключіться до Playground @@ -44,11 +59,13 @@ Solana Playground (Solpg) – це браузерне середовище ро #### Крок 2. Створіть Свій Гаманець -Вам буде запропоновано зберегти ключову пару вашого гаманця. За бажанням збережіть ключову пару для резервної копії, а потім натисніть "Continue". +Вам буде запропоновано зберегти ключову пару вашого гаманця. За бажанням +збережіть ключову пару для резервної копії, а потім натисніть "Continue". ![Create Playground Wallet](/assets/docs/intro/quickstart/pg-create-wallet.png) -Тепер ви повинні побачити адресу вашого гаманця, баланс SOL і підключений кластер (за замовчуванням devnet) у нижній частині вікна. +Тепер ви повинні побачити адресу вашого гаманця, баланс SOL і підключений +кластер (за замовчуванням devnet) у нижній частині вікна. ![Connected](/assets/docs/intro/quickstart/pg-connected.png) @@ -58,8 +75,14 @@ Solana Playground (Solpg) – це браузерне середовище ро Декілька корисних визначень: -- **_адреса гаманця_**: Унікальний ідентифікатор цифрового гаманця, який використовується для надсилання або отримання криптоактивів у блокчейні. Це схоже на електронну адресу чи номер банківського рахунку – щоб хтось надіслав вам криптовалюту, йому потрібна ваша адреса гаманця. -- **_підключений кластер_**: Набір вузлів мережі, які працюють разом, щоб підтримувати синхронізовану копію блокчейна. Кластери важливі для надання децентралізованого розподіленого реєстру, перевірки транзакцій, забезпечення безпеки ланцюга та виконання програм (смарт-контрактів). +- **_адреса гаманця_**: Унікальний ідентифікатор цифрового гаманця, який + використовується для надсилання або отримання криптоактивів у блокчейні. Це + схоже на електронну адресу чи номер банківського рахунку – щоб хтось надіслав + вам криптовалюту, йому потрібна ваша адреса гаманця. +- **_підключений кластер_**: Набір вузлів мережі, які працюють разом, щоб + підтримувати синхронізовану копію блокчейна. Кластери важливі для надання + децентралізованого розподіленого реєстру, перевірки транзакцій, забезпечення + безпеки ланцюга та виконання програм (смарт-контрактів). ### Отримання Devnet SOL @@ -74,8 +97,8 @@ Solana Playground (Solpg) – це браузерне середовище ро #### Варіант 1: Використання Терміналу Playground -Щоб поповнити ваш гаманець Playground devnet SOL, виконайте у терміналі Playground команду: - +Щоб поповнити ваш гаманець Playground devnet SOL, виконайте у терміналі +Playground команду: ```shell filename="Terminal" solana airdrop 5 @@ -83,9 +106,11 @@ solana airdrop 5 #### Варіант 2: Використання Devnet Faucet -Якщо команда airdrop не працює (через обмеження або помилки), скористайтеся [Web Faucet](https://faucet.solana.com/). +Якщо команда airdrop не працює (через обмеження або помилки), скористайтеся +[Web Faucet](https://faucet.solana.com/). -- Введіть адресу свого гаманця (знаходиться в нижній частині екрана Playground) і виберіть суму +- Введіть адресу свого гаманця (знаходиться в нижній частині екрана Playground) + і виберіть суму - Натисніть "Confirm Airdrop", щоб отримати ваш devnet SOL ![Faucet Airdrop](/assets/docs/intro/quickstart/faucet-airdrop.gif) diff --git a/docs/locales/uk/intro/quick-start/program-derived-address.md b/docs/locales/uk/intro/quick-start/program-derived-address.md index e025756e1..e259518a8 100644 --- a/docs/locales/uk/intro/quick-start/program-derived-address.md +++ b/docs/locales/uk/intro/quick-start/program-derived-address.md @@ -11,21 +11,31 @@ description: використовувати PDAs у програмах Solana. --- -У цьому розділі ми розглянемо, як створити базову CRUD (Create, Read, Update, Delete) програму. Програма зберігатиме повідомлення користувача, використовуючи Program Derived Address (PDA) як адресу акаунта. +У цьому розділі ми розглянемо, як створити базову CRUD (Create, Read, Update, +Delete) програму. Програма зберігатиме повідомлення користувача, використовуючи +Program Derived Address (PDA) як адресу акаунта. -Мета цього розділу – провести вас через етапи створення і тестування програми Solana, використовуючи фреймворк Anchor, і показати, як використовувати PDA у програмі. Для отримання додаткової інформації відвідайте сторінку [Programs Derived Address](/docs/uk/core/pda). +Мета цього розділу – провести вас через етапи створення і тестування програми +Solana, використовуючи фреймворк Anchor, і показати, як використовувати PDA у +програмі. Для отримання додаткової інформації відвідайте сторінку +[Programs Derived Address](/docs/uk/core/pda). -Для довідки ось [фінальний код](https://beta.solpg.io/668304cfcffcf4b13384d20a), завершений після розгляду розділів PDA і CPI. +Для довідки ось [фінальний код](https://beta.solpg.io/668304cfcffcf4b13384d20a), +завершений після розгляду розділів PDA і CPI. ### Стартовий Код -Почніть, відкривши це [посилання на Solana Playground](https://beta.solpg.io/66734b7bcffcf4b13384d1ad) зі стартовим кодом. Потім натисніть кнопку "Import", щоб додати програму до вашого списку проєктів у Solana Playground. +Почніть, відкривши це +[посилання на Solana Playground](https://beta.solpg.io/66734b7bcffcf4b13384d1ad) +зі стартовим кодом. Потім натисніть кнопку "Import", щоб додати програму до +вашого списку проєктів у Solana Playground. ![Import](/assets/docs/intro/quickstart/pg-import.png) -У файлі `lib.rs` ви знайдете шаблон програми з інструкціями `create`, `update` і `delete`, які ми реалізуємо на наступних етапах. +У файлі `lib.rs` ви знайдете шаблон програми з інструкціями `create`, `update` і +`delete`, які ми реалізуємо на наступних етапах. ```rs filename="lib.rs" use anchor_lang::prelude::*; @@ -61,7 +71,9 @@ pub struct Delete {} #[account] pub struct MessageAccount {} ``` -Перед початком виконайте команду `build` у терміналі Playground, щоб переконатися, що стартова програма успішно компілюється. + +Перед початком виконайте команду `build` у терміналі Playground, щоб +переконатися, що стартова програма успішно компілюється. ```shell filename="Terminal" build @@ -81,7 +93,8 @@ Build successful. Completed in 3.50s. ### Визначення Типу Акаунта Повідомлення -Спочатку визначимо структуру акаунта повідомлення, який створюватиме наша програма. Це дані, які ми зберігатимемо в акаунті, створеному програмою. +Спочатку визначимо структуру акаунта повідомлення, який створюватиме наша +програма. Це дані, які ми зберігатимемо в акаунті, створеному програмою. У файлі `lib.rs` оновіть структуру `MessageAccount` наступним кодом: @@ -112,17 +125,27 @@ pub struct MessageAccount { -Макрос `#[account]` у програмі Anchor використовується для позначення структур, які представляють дані акаунта (тип даних, що зберігається у полі даних `AccountInfo`). +Макрос `#[account]` у програмі Anchor використовується для позначення структур, +які представляють дані акаунта (тип даних, що зберігається у полі даних +`AccountInfo`). -У цьому прикладі ми визначаємо структуру `MessageAccount` для зберігання повідомлення, створеного користувачами, яка містить три поля: +У цьому прикладі ми визначаємо структуру `MessageAccount` для зберігання +повідомлення, створеного користувачами, яка містить три поля: -- `user` — `Pubkey`, який представляє користувача, що створив акаунт повідомлення. +- `user` — `Pubkey`, який представляє користувача, що створив акаунт + повідомлення. - `message` — `String`, який містить повідомлення користувача. -- `bump` — `u8`, що зберігає ["bump" seed](/docs/uk/core/pda#canonical-bump), використаний для отримання адреси, створеної програмою (PDA). Зберігання цього значення економить обчислювальні ресурси, оскільки усуває необхідність повторного обчислення для кожного використання в наступних інструкціях. +- `bump` — `u8`, що зберігає ["bump" seed](/docs/uk/core/pda#canonical-bump), + використаний для отримання адреси, створеної програмою (PDA). Зберігання цього + значення економить обчислювальні ресурси, оскільки усуває необхідність + повторного обчислення для кожного використання в наступних інструкціях. -Коли акаунт створюється, дані `MessageAccount` будуть серіалізовані та збережені у полі даних нового акаунта. +Коли акаунт створюється, дані `MessageAccount` будуть серіалізовані та збережені +у полі даних нового акаунта. -Пізніше, під час читання з акаунта, ці дані можна буде десеріалізувати назад у тип даних `MessageAccount`. Процес створення та читання даних акаунта буде продемонстровано у розділі тестування. +Пізніше, під час читання з акаунта, ці дані можна буде десеріалізувати назад у +тип даних `MessageAccount`. Процес створення та читання даних акаунта буде +продемонстровано у розділі тестування. @@ -132,13 +155,17 @@ pub struct MessageAccount { ```shell filename="Terminal" build ``` -Ми визначили, як виглядатиме наш акаунт повідомлення. Далі ми реалізуємо інструкції програми. + +Ми визначили, як виглядатиме наш акаунт повідомлення. Далі ми реалізуємо +інструкції програми. ### Реалізація Інструкції Create -Тепер реалізуємо інструкцію `create` для створення та ініціалізації `MessageAccount`. +Тепер реалізуємо інструкцію `create` для створення та ініціалізації +`MessageAccount`. -Почніть із визначення акаунтів, необхідних для цієї інструкції, оновивши структуру `Create` наступним кодом: +Почніть із визначення акаунтів, необхідних для цієї інструкції, оновивши +структуру `Create` наступним кодом: ```rs filename="lib.rs" #[derive(Accounts)] @@ -188,9 +215,13 @@ pub struct Create<'info> { Макрос `#[derive(Accounts)]` у програмі Anchor використовується для позначення структур, які представляють список акаунтів, необхідних для інструкції, де кожне поле в структурі є акаунтом. -Кожен акаунт (поле) у структурі позначається типом акаунта (наприклад, `Signer<'info>`) і може бути додатково позначений обмеженнями (наприклад, `#[account(mut)]`). Тип акаунта разом із обмеженнями акаунта використовуються для виконання перевірок безпеки акаунтів, переданих до інструкції. +Кожен акаунт (поле) у структурі позначається типом акаунта (наприклад, +`Signer<'info>`) і може бути додатково позначений обмеженнями (наприклад, +`#[account(mut)]`). Тип акаунта разом із обмеженнями акаунта використовуються +для виконання перевірок безпеки акаунтів, переданих до інструкції. -Назви кожного поля використовуються лише для нашого розуміння і не впливають на валідацію акаунтів, однак рекомендується використовувати описові імена акаунтів. +Назви кожного поля використовуються лише для нашого розуміння і не впливають на +валідацію акаунтів, однак рекомендується використовувати описові імена акаунтів. --- @@ -199,48 +230,60 @@ pub struct Create<'info> { 1. `user: Signer<'info>` - Представляє користувача, який створює акаунт повідомлення. - - Позначений як змінний (`#[account(mut)]`), оскільки оплачує створення нового акаунта. - - Повинен бути підписувачем, щоб підтвердити транзакцію, оскільки лампорти будуть списані з акаунта. + - Позначений як змінний (`#[account(mut)]`), оскільки оплачує створення + нового акаунта. + - Повинен бути підписувачем, щоб підтвердити транзакцію, оскільки лампорти + будуть списані з акаунта. 2. `message_account: Account<'info, MessageAccount>` - Новий акаунт, створений для зберігання повідомлення користувача. - Обмеження `init` вказує, що акаунт буде створено в інструкції. - - Обмеження `seeds` і `bump` вказують, що адреса акаунта є Program Derived Address (PDA). + - Обмеження `seeds` і `bump` вказують, що адреса акаунта є Program Derived + Address (PDA). - `payer = user` вказує акаунт, який оплачує створення нового акаунта. - `space` вказує кількість байтів, виділених для поля даних нового акаунта. 3. `system_program: Program<'info, System>` - Необхідна для створення нових акаунтів. - - На рівні механіки обмеження `init` викликає Системну програму для створення нового акаунта з виділенням вказаного `space` та переназначає власника програми на поточну програму. + - На рівні механіки обмеження `init` викликає Системну програму для створення + нового акаунта з виділенням вказаного `space` та переназначає власника + програми на поточну програму. --- -Анотація `#[instruction(message: String)]` дозволяє структурі `Create` отримувати доступ до параметра `message` з інструкції `create`. +Анотація `#[instruction(message: String)]` дозволяє структурі `Create` +отримувати доступ до параметра `message` з інструкції `create`. --- -Обмеження `seeds` і `bump` використовуються разом для вказівки, що адреса акаунта є Program Derived Address (PDA). +Обмеження `seeds` і `bump` використовуються разом для вказівки, що адреса +акаунта є Program Derived Address (PDA). ```rs filename="lib.rs" seeds = [b"message", user.key().as_ref()], bump, ``` -Обмеження `seeds` визначає необов’язкові вхідні значення, які використовуються для отримання PDA: + +Обмеження `seeds` визначає необов’язкові вхідні значення, які використовуються +для отримання PDA: - `b"message"` — Жорстко закодований рядок як перше значення seed. - `user.key().as_ref()` — Публічний ключ акаунта `user` як друге значення seed. -Обмеження `bump` вказує Anchor автоматично знайти та використовувати правильний bump seed. Anchor використовує `seeds` і `bump` для отримання PDA. +Обмеження `bump` вказує Anchor автоматично знайти та використовувати правильний +bump seed. Anchor використовує `seeds` і `bump` для отримання PDA. --- -Розрахунок `space` (8 + 32 + 4 + message.len() + 1) виділяє простір для даних типу `MessageAccount`: +Розрахунок `space` (8 + 32 + 4 + message.len() + 1) виділяє простір для даних +типу `MessageAccount`: - Дискримінатор акаунта Anchor (ідентифікатор): 8 байтів - Адреса користувача (Pubkey): 32 байти -- Повідомлення користувача (String): 4 байти для довжини + змінна довжина повідомлення +- Повідомлення користувача (String): 4 байти для довжини + змінна довжина + повідомлення - Bump seed для PDA (u8): 1 байт ```rs filename="lib.rs" @@ -251,14 +294,19 @@ pub struct MessageAccount { pub bump: u8, } ``` -Усі акаунти, створені за допомогою програми Anchor, вимагають 8 байтів для дискримінатора акаунта, який є ідентифікатором типу акаунта і генерується автоматично під час створення акаунта. -Тип `String` вимагає 4 байти для зберігання довжини рядка, а решта — це фактичні дані. +Усі акаунти, створені за допомогою програми Anchor, вимагають 8 байтів для +дискримінатора акаунта, який є ідентифікатором типу акаунта і генерується +автоматично під час створення акаунта. + +Тип `String` вимагає 4 байти для зберігання довжини рядка, а решта — це фактичні +дані. -Далі реалізуйте бізнес-логіку для інструкції `create`, оновивши функцію `create` наступним кодом: +Далі реалізуйте бізнес-логіку для інструкції `create`, оновивши функцію `create` +наступним кодом: ```rs filename="lib.rs" pub fn create(ctx: Context, message: String) -> Result<()> { @@ -292,9 +340,11 @@ pub fn create(ctx: Context, message: String) -> Result<()> { -Функція `create` реалізує логіку для ініціалізації даних нового акаунта повідомлення. Вона приймає два параметри: +Функція `create` реалізує логіку для ініціалізації даних нового акаунта +повідомлення. Вона приймає два параметри: -1. `ctx: Context` — Надає доступ до акаунтів, зазначених у структурі `Create`. +1. `ctx: Context` — Надає доступ до акаунтів, зазначених у структурі + `Create`. 2. `message: String` — Повідомлення користувача, яке буде збережено. Тіло функції виконує наступну логіку: @@ -304,15 +354,17 @@ pub fn create(ctx: Context, message: String) -> Result<()> { ```rs msg!("Create Message: {}", message); ``` + 2. Ініціалізація Даних Акаунта: - Отримує доступ до `message_account` з контексту. - + ```rs let account_data = &mut ctx.accounts.message_account; ``` + - Встановлює поле `user` як публічний ключ акаунта `user`. - + ```rs account_data.user = ctx.accounts.user.key(); ``` @@ -322,7 +374,9 @@ pub fn create(ctx: Context, message: String) -> Result<()> { ```rs account_data.message = message; ``` - - Встановлює значення `bump`, використане для отримання PDA, отримане з `ctx.bumps.message_account`. + + - Встановлює значення `bump`, використане для отримання PDA, отримане з + `ctx.bumps.message_account`. ```rs account_data.bump = ctx.bumps.message_account; @@ -336,11 +390,14 @@ pub fn create(ctx: Context, message: String) -> Result<()> { ```shell filename="Terminal" build ``` + ### Реалізація Інструкції Update -Далі реалізуйте інструкцію `update` для оновлення `MessageAccount` новим повідомленням. +Далі реалізуйте інструкцію `update` для оновлення `MessageAccount` новим +повідомленням. -Як і раніше, першим кроком є визначення акаунтів, необхідних для інструкції `update`. +Як і раніше, першим кроком є визначення акаунтів, необхідних для інструкції +`update`. Оновіть структуру `Update` наступним кодом: @@ -397,7 +454,8 @@ pub struct Update<'info> { 1. `user: Signer<'info>` - Представляє користувача, який оновлює акаунт повідомлення. - - Позначений як змінний (`#[account(mut)]`), оскільки може оплачувати додатковий простір для `message_account`, якщо це необхідно. + - Позначений як змінний (`#[account(mut)]`), оскільки може оплачувати + додатковий простір для `message_account`, якщо це необхідно. - Повинен бути підписувачем для підтвердження транзакції. 2. `message_account: Account<'info, MessageAccount>` @@ -410,15 +468,19 @@ pub struct Update<'info> { 3. `system_program: Program<'info, System>` - Необхідна для можливої зміни розміру простору акаунта. - - Обмеження `realloc` викликає Системну програму для налаштування розміру даних акаунта. + - Обмеження `realloc` викликає Системну програму для налаштування розміру + даних акаунта. --- -Зверніть увагу, що обмеження `bump = message_account.bump` використовує bump seed, який зберігається в `message_account`, замість того, щоб Anchor обчислював його знову. +Зверніть увагу, що обмеження `bump = message_account.bump` використовує bump +seed, який зберігається в `message_account`, замість того, щоб Anchor обчислював +його знову. --- -Анотація `#[instruction(message: String)]` дозволяє структурі `Update` отримувати доступ до параметра `message` з інструкції `update`. +Анотація `#[instruction(message: String)]` дозволяє структурі `Update` +отримувати доступ до параметра `message` з інструкції `update`. @@ -454,7 +516,8 @@ pub fn update(ctx: Context, message: String) -> Result<()> { Функція `update` реалізує логіку для модифікації існуючого акаунта повідомлення. Вона приймає два параметри: -1. `ctx: Context` — Надає доступ до акаунтів, зазначених у структурі `Update`. +1. `ctx: Context` — Надає доступ до акаунтів, зазначених у структурі + `Update`. 2. `message: String` — Нове повідомлення, яке замінить існуюче. Тіло функції виконує такі дії: @@ -473,6 +536,7 @@ pub fn update(ctx: Context, message: String) -> Result<()> { ```shell filename="Terminal" build ``` + ### Реалізація Інструкції Delete Далі реалізуйте інструкцію `delete` для закриття `MessageAccount`. @@ -525,15 +589,18 @@ pub struct Delete<'info> { 1. `user: Signer<'info>` - Представляє користувача, який закриває акаунт повідомлення. - - Позначений як змінний (`#[account(mut)]`), оскільки він отримуватиме лампорти з закритого акаунта. - - Повинен бути підписувачем, щоб гарантувати, що тільки відповідний користувач може закрити свій акаунт повідомлення. + - Позначений як змінний (`#[account(mut)]`), оскільки він отримуватиме + лампорти з закритого акаунта. + - Повинен бути підписувачем, щоб гарантувати, що тільки відповідний + користувач може закрити свій акаунт повідомлення. 2. `message_account: Account<'info, MessageAccount>` - Акаунт, який буде закритий. - Обмеження `mut` вказує, що цей акаунт буде змінено. - Обмеження `seeds` і `bump` гарантують, що акаунт є правильним PDA. - - Обмеження `close = user` вказує, що цей акаунт буде закритий, а його лампорти передані в акаунт `user`. + - Обмеження `close = user` вказує, що цей акаунт буде закритий, а його + лампорти передані в акаунт `user`. @@ -566,9 +633,13 @@ pub fn delete(_ctx: Context) -> Result<()> { Функція `delete` приймає один параметр: -1. `_ctx: Context` — Надає доступ до акаунтів, зазначених у структурі `Delete`. Використання `_ctx` вказує, що контекст не буде використовуватися в тілі функції. +1. `_ctx: Context` — Надає доступ до акаунтів, зазначених у структурі + `Delete`. Використання `_ctx` вказує, що контекст не буде використовуватися в + тілі функції. -Тіло функції лише виводить повідомлення у журнали програми за допомогою макроса `msg!()`. Додаткова логіка не потрібна, оскільки фактичне закриття акаунта виконується за допомогою обмеження `close` у структурі `Delete`. +Тіло функції лише виводить повідомлення у журнали програми за допомогою макроса +`msg!()`. Додаткова логіка не потрібна, оскільки фактичне закриття акаунта +виконується за допомогою обмеження `close` у структурі `Delete`. @@ -581,7 +652,8 @@ build ### Розгортання Програми -Базова CRUD-програма завершена. Розгорніть програму, виконавши команду `deploy` у терміналі Playground. +Базова CRUD-програма завершена. Розгорніть програму, виконавши команду `deploy` +у терміналі Playground. ```shell filename="Terminal" deploy @@ -614,6 +686,7 @@ describe("pda", () => { it("Delete Message Account", async () => {}); }); ``` + Додайте наведений нижче код всередину блоку `describe`, але перед секціями `it`. ```ts filename="anchor.test.ts" @@ -654,15 +727,17 @@ const [messagePda, messageBump] = PublicKey.findProgramAddressSync( У цьому розділі ми просто налаштовуємо тестовий файл. -Solana Playground спрощує початкову підготовку: `pg.program` дозволяє отримати доступ до клієнтської бібліотеки для взаємодії з програмою, а `pg.wallet` представляє ваш гаманець у Playground. +Solana Playground спрощує початкову підготовку: `pg.program` дозволяє отримати +доступ до клієнтської бібліотеки для взаємодії з програмою, а `pg.wallet` +представляє ваш гаманець у Playground. ```ts filename="anchor.test.ts" const program = pg.program; const wallet = pg.wallet; ``` -У рамках налаштування ми отримуємо PDA акаунта повідомлення. Це демонструє, як отримати PDA у Javascript, використовуючи сіди, визначені у програмі. - +У рамках налаштування ми отримуємо PDA акаунта повідомлення. Це демонструє, як +отримати PDA у Javascript, використовуючи сіди, визначені у програмі. ```ts filename="anchor.test.ts" const [messagePda, messageBump] = PublicKey.findProgramAddressSync( @@ -674,8 +749,9 @@ const [messagePda, messageBump] = PublicKey.findProgramAddressSync( -Запустіть тестовий файл, виконавши команду `test` у терміналі Playground, щоб переконатися, що файл працює, як очікувалося. Ми реалізуємо тести на наступних етапах. - +Запустіть тестовий файл, виконавши команду `test` у терміналі Playground, щоб +переконатися, що файл працює, як очікувалося. Ми реалізуємо тести на наступних +етапах. ```shell filename="Terminal" test @@ -702,7 +778,6 @@ Running tests... Оновіть перший тест наступним кодом: - ```ts filename="anchor.test.ts" it("Create Message Account", async () => { const message = "Hello, World!"; @@ -757,8 +832,8 @@ it("Create Message Account", async () => { -Спочатку ми надсилаємо транзакцію, яка викликає інструкцію `create`, передаючи "Hello, World!" як повідомлення. - +Спочатку ми надсилаємо транзакцію, яка викликає інструкцію `create`, передаючи +"Hello, World!" як повідомлення. ```ts filename="anchor.test.ts" const message = "Hello, World!"; @@ -770,8 +845,8 @@ const transactionSignature = await program.methods .rpc({ commitment: "confirmed" }); ``` -Після надсилання транзакції та створення акаунта ми отримуємо акаунт за його адресою (`messagePda`). - +Після надсилання транзакції та створення акаунта ми отримуємо акаунт за його +адресою (`messagePda`). ```ts filename="anchor.test.ts" const messageAccount = await program.account.messageAccount.fetch( @@ -780,8 +855,8 @@ const messageAccount = await program.account.messageAccount.fetch( ); ``` -Нарешті, ми виводимо у журнал дані акаунта та посилання для перегляду деталей транзакції. - +Нарешті, ми виводимо у журнал дані акаунта та посилання для перегляду деталей +транзакції. ```ts filename="anchor.test.ts" console.log(JSON.stringify(messageAccount, null, 2)); @@ -798,7 +873,6 @@ console.log( Оновіть другий тест наступним кодом: - ```ts filename="anchor.test.ts" it("Update Message Account", async () => { const message = "Hello, Solana!"; @@ -853,8 +927,8 @@ it("Update Message Account", async () => { -Спочатку ми надсилаємо транзакцію, яка викликає інструкцію `update`, передаючи "Hello, Solana!" як нове повідомлення. - +Спочатку ми надсилаємо транзакцію, яка викликає інструкцію `update`, передаючи +"Hello, Solana!" як нове повідомлення. ```ts filename="anchor.test.ts" const message = "Hello, Solana!"; @@ -866,7 +940,8 @@ const transactionSignature = await program.methods .rpc({ commitment: "confirmed" }); ``` -Після надсилання транзакції та оновлення акаунта ми отримуємо акаунт за його адресою (`messagePda`). +Після надсилання транзакції та оновлення акаунта ми отримуємо акаунт за його +адресою (`messagePda`). ```ts filename="anchor.test.ts" const messageAccount = await program.account.messageAccount.fetch( @@ -875,8 +950,8 @@ const messageAccount = await program.account.messageAccount.fetch( ); ``` -Нарешті, ми виводимо у журнал дані акаунта та посилання для перегляду деталей транзакції. - +Нарешті, ми виводимо у журнал дані акаунта та посилання для перегляду деталей +транзакції. ```ts filename="anchor.test.ts" console.log(JSON.stringify(messageAccount, null, 2)); @@ -893,7 +968,6 @@ console.log( Оновіть третій тест наступним кодом: - ```ts filename="anchor.test.ts" it("Delete Message Account", async () => { const transactionSignature = await program.methods @@ -946,8 +1020,8 @@ it("Delete Message Account", async () => { -Спочатку ми надсилаємо транзакцію, яка викликає інструкцію `delete` для закриття акаунта повідомлення. - +Спочатку ми надсилаємо транзакцію, яка викликає інструкцію `delete` для закриття +акаунта повідомлення. ```ts filename="anchor.test.ts" const transactionSignature = await program.methods @@ -958,8 +1032,9 @@ const transactionSignature = await program.methods .rpc({ commitment: "confirmed" }); ``` -Після надсилання транзакції та закриття акаунта ми намагаємося отримати акаунт за його адресою (`messagePda`), використовуючи `fetchNullable`, оскільки ми очікуємо, що результат буде `null`, тому що акаунт закритий. - +Після надсилання транзакції та закриття акаунта ми намагаємося отримати акаунт +за його адресою (`messagePda`), використовуючи `fetchNullable`, оскільки ми +очікуємо, що результат буде `null`, тому що акаунт закритий. ```ts filename="anchor.test.ts" const messageAccount = await program.account.messageAccount.fetchNullable( @@ -968,8 +1043,8 @@ const messageAccount = await program.account.messageAccount.fetchNullable( ); ``` -Нарешті, ми виводимо у журнал дані акаунта та посилання для перегляду деталей транзакції, де дані акаунта повинні бути відображені як `null`. - +Нарешті, ми виводимо у журнал дані акаунта та посилання для перегляду деталей +транзакції, де дані акаунта повинні бути відображені як `null`. ```ts filename="anchor.test.ts" console.log(JSON.stringify(messageAccount, null, 2)); @@ -984,8 +1059,8 @@ console.log( ### Запуск Тестів -Після налаштування тестів запустіть тестовий файл, виконавши команду `test` у терміналі Playground. - +Після налаштування тестів запустіть тестовий файл, виконавши команду `test` у +терміналі Playground. ```shell filename="Terminal" test diff --git a/docs/locales/uk/intro/quick-start/reading-from-network.md b/docs/locales/uk/intro/quick-start/reading-from-network.md index 1403a31ef..e7dd00e7f 100644 --- a/docs/locales/uk/intro/quick-start/reading-from-network.md +++ b/docs/locales/uk/intro/quick-start/reading-from-network.md @@ -4,33 +4,47 @@ title: Читання з Мережі sidebarSortOrder: 1 description: Дізнайтеся, як зчитувати дані з блокчейн-мережі Solana. Цей посібник охоплює - отримання акаунтів гаманців, програмних акаунтів і акаунтів випуску токенів - за допомогою JavaScript/TypeScript із практичними прикладами на основі - бібліотеки Solana web3.js. + отримання акаунтів гаманців, програмних акаунтів і акаунтів випуску токенів за + допомогою JavaScript/TypeScript із практичними прикладами на основі бібліотеки + Solana web3.js. --- -Давайте розглянемо, як зчитувати дані з мережі Solana. Ми отримаємо кілька різних акаунтів, щоб зрозуміти структуру акаунта Solana. +Давайте розглянемо, як зчитувати дані з мережі Solana. Ми отримаємо кілька +різних акаунтів, щоб зрозуміти структуру акаунта Solana. -У Solana всі дані містяться у так званих "акаунтах". Ви можете думати про дані в Solana як про загальнодоступну базу даних із єдиною таблицею "Accounts", де кожен запис у цій таблиці є окремим акаунтом. +У Solana всі дані містяться у так званих "акаунтах". Ви можете думати про дані в +Solana як про загальнодоступну базу даних із єдиною таблицею "Accounts", де +кожен запис у цій таблиці є окремим акаунтом. -Акаунти Solana можуть містити "стан" або виконувані програми, які можна розглядати як записи в одній таблиці "Accounts". Кожен акаунт має "адресу" (публічний ключ), яка є унікальним ідентифікатором для доступу до відповідних даних у блокчейні. +Акаунти Solana можуть містити "стан" або виконувані програми, які можна +розглядати як записи в одній таблиці "Accounts". Кожен акаунт має "адресу" +(публічний ключ), яка є унікальним ідентифікатором для доступу до відповідних +даних у блокчейні. Акаунти Solana можуть містити: -- **Стан**: Дані, які призначені для зчитування і зберігання. Це може бути інформація про токени, дані користувачів або будь-які інші дані, визначені у програмі. -- **Виконувані програми**: Акаунти, які містять фактичний код програм Solana. Вони включають інструкції, які можна виконувати у мережі. +- **Стан**: Дані, які призначені для зчитування і зберігання. Це може бути + інформація про токени, дані користувачів або будь-які інші дані, визначені у + програмі. +- **Виконувані програми**: Акаунти, які містять фактичний код програм Solana. + Вони включають інструкції, які можна виконувати у мережі. -Цей поділ програмного коду та стану програми є ключовою особливістю Моделі Акаунтів Solana. Для отримання додаткової інформації відвідайте сторінку [Модель Акаунтів Solana](/docs/uk/core/accounts). +Цей поділ програмного коду та стану програми є ключовою особливістю Моделі +Акаунтів Solana. Для отримання додаткової інформації відвідайте сторінку +[Модель Акаунтів Solana](/docs/uk/core/accounts). ## Отримання Гаманця Playground -Почнемо з розгляду знайомого акаунта — вашого власного гаманця Playground! Ми отримаємо цей акаунт і розглянемо його структуру, щоб зрозуміти, як виглядає базовий акаунт Solana. +Почнемо з розгляду знайомого акаунта — вашого власного гаманця Playground! Ми +отримаємо цей акаунт і розглянемо його структуру, щоб зрозуміти, як виглядає +базовий акаунт Solana. ### Відкриття Прикладу 1 -Натисніть це [посилання](https://beta.solpg.io/6671c5e5cffcf4b13384d198), щоб відкрити приклад у Solana Playground. Ви побачите такий код: +Натисніть це [посилання](https://beta.solpg.io/6671c5e5cffcf4b13384d198), щоб +відкрити приклад у Solana Playground. Ви побачите такий код: ```ts filename="client.ts" const address = pg.wallet.publicKey; @@ -73,7 +87,8 @@ console.log(JSON.stringify(accountInfo, null, 2)); run ``` -Ви повинні побачити деталі вашого акаунта гаманця, включаючи його баланс у лампортах, із результатом, схожим на наступний: +Ви повинні побачити деталі вашого акаунта гаманця, включаючи його баланс у +лампортах, із результатом, схожим на наступний: @@ -98,23 +113,36 @@ Running client... -Ваш гаманець насправді є лише акаунтом, яким керує Системна програма. Основна мета акаунта гаманця — зберігати баланс SOL (значення у полі `lamports`). +Ваш гаманець насправді є лише акаунтом, яким керує Системна програма. Основна +мета акаунта гаманця — зберігати баланс SOL (значення у полі `lamports`). --- -В основі всі акаунти Solana представлені у стандартному форматі, який називається `AccountInfo`. Тип даних [AccountInfo](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/account_info.rs#L19-L36) є базовою структурою даних для всіх акаунтів Solana. +В основі всі акаунти Solana представлені у стандартному форматі, який +називається `AccountInfo`. Тип даних +[AccountInfo](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/account_info.rs#L19-L36) +є базовою структурою даних для всіх акаунтів Solana. Розберемо поля у виведених даних: -- `data` — Це поле містить те, що ми зазвичай називаємо "даними" акаунта. Для гаманця воно порожнє (0 байтів), але інші акаунти використовують це поле для зберігання будь-яких довільних даних у вигляді серіалізованого буфера байтів. +- `data` — Це поле містить те, що ми зазвичай називаємо "даними" акаунта. Для + гаманця воно порожнє (0 байтів), але інші акаунти використовують це поле для + зберігання будь-яких довільних даних у вигляді серіалізованого буфера байтів. -> Коли дані "буферизуються" таким чином, вони зберігають свою цілісність і можуть пізніше бути десеріалізовані назад у свій початковий вигляд для використання у програмах. Цей процес широко використовується в блокчейні для ефективної обробки даних. +> Коли дані "буферизуються" таким чином, вони зберігають свою цілісність і +> можуть пізніше бути десеріалізовані назад у свій початковий вигляд для +> використання у програмах. Цей процес широко використовується в блокчейні для +> ефективної обробки даних. -- `executable` — Прапорець, який вказує, чи є акаунт виконуваною програмою. Для гаманців та будь-яких акаунтів, які зберігають стан, значення `false`. -- `owner` — Це поле показує, яка програма контролює акаунт. Для гаманців це завжди Системна програма з адресою `11111111111111111111111111111111`. +- `executable` — Прапорець, який вказує, чи є акаунт виконуваною програмою. Для + гаманців та будь-яких акаунтів, які зберігають стан, значення `false`. +- `owner` — Це поле показує, яка програма контролює акаунт. Для гаманців це + завжди Системна програма з адресою `11111111111111111111111111111111`. - `lamports` — Баланс акаунта у лампортах (1 SOL = 1,000,000,000 лампортів). -- `rentEpoch` — Поле, пов’язане зі старим механізмом збору оренди Solana (наразі не використовується). -- `space` — Вказує ємність (довжину) поля `data`, але не є полем типу `AccountInfo`. +- `rentEpoch` — Поле, пов’язане зі старим механізмом збору оренди Solana (наразі + не використовується). +- `space` — Вказує ємність (довжину) поля `data`, але не є полем типу + `AccountInfo`. @@ -123,13 +151,15 @@ Running client... ## Отримання Програми Token Program -Далі ми розглянемо програму Token Extensions, яка є виконуваною програмою для взаємодії з токенами на Solana. +Далі ми розглянемо програму Token Extensions, яка є виконуваною програмою для +взаємодії з токенами на Solana. ### Відкриття Прикладу 2 -Натисніть це [посилання](https://beta.solpg.io/6671c6e7cffcf4b13384d199), щоб відкрити приклад у Solana Playground. Ви побачите такий код: +Натисніть це [посилання](https://beta.solpg.io/6671c6e7cffcf4b13384d199), щоб +відкрити приклад у Solana Playground. Ви побачите такий код: ```ts filename="client.ts" {3} import { PublicKey } from "@solana/web3.js"; @@ -139,17 +169,20 @@ const accountInfo = await pg.connection.getAccountInfo(address); console.log(JSON.stringify(accountInfo, null, 2)); ``` -Замість отримання вашого гаманця Playground, тут ми отримуємо адресу акаунта програми Token Extensions. + +Замість отримання вашого гаманця Playground, тут ми отримуємо адресу акаунта +програми Token Extensions. ### Запуск Прикладу 2 Запустіть код, виконавши команду `run` у терміналі. - ```shell filename="Terminal" run ``` -Ознайомтеся з виведеними даними та тим, чим цей акаунт програми відрізняється від вашого акаунта гаманця. + +Ознайомтеся з виведеними даними та тим, чим цей акаунт програми відрізняється +від вашого акаунта гаманця. @@ -180,13 +213,19 @@ Running client... -Програма Token Extensions є виконуваним акаунтом програми, але має таку ж структуру `AccountInfo`. +Програма Token Extensions є виконуваним акаунтом програми, але має таку ж +структуру `AccountInfo`. Основні відмінності в `AccountInfo`: -- **`executable`** — Встановлено у `true`, що вказує на те, що цей акаунт є виконуваною програмою. -- **`data`** — Містить серіалізовані дані (на відміну від порожніх даних у акаунті гаманця). Дані для акаунта програми зберігають адресу іншого акаунта (Program Executable Data Account), який містить байт-код програми. -- **`owner`** — Акаунт належить завантажувачу Upgradable BPF Loader (`BPFLoaderUpgradeab1e11111111111111111111111`), спеціальній програмі, яка управляє виконуваними акаунтами. +- **`executable`** — Встановлено у `true`, що вказує на те, що цей акаунт є + виконуваною програмою. +- **`data`** — Містить серіалізовані дані (на відміну від порожніх даних у + акаунті гаманця). Дані для акаунта програми зберігають адресу іншого акаунта + (Program Executable Data Account), який містить байт-код програми. +- **`owner`** — Акаунт належить завантажувачу Upgradable BPF Loader + (`BPFLoaderUpgradeab1e11111111111111111111111`), спеціальній програмі, яка + управляє виконуваними акаунтами. --- @@ -195,7 +234,8 @@ Running client... та його відповідного [Program Executable Data Account](https://explorer.solana.com/address/DoU57AYuPFu2QU514RktNPG22QhApEjnKxnBcu4BHDTY). -Program Executable Data Account містить скомпільований байт-код програми Token Extensions +Program Executable Data Account містить скомпільований байт-код програми Token +Extensions [вихідний код](https://github.com/solana-labs/solana-program-library/tree/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program-2022/src). @@ -205,14 +245,15 @@ Program Executable Data Account містить скомпільований ба ## Отримання Акаунта Mint -На цьому етапі ми розглянемо акаунт Mint, який представляє унікальний токен у мережі Solana. +На цьому етапі ми розглянемо акаунт Mint, який представляє унікальний токен у +мережі Solana. ### Відкриття Прикладу 3 -Натисніть це [посилання](https://beta.solpg.io/6671c9aecffcf4b13384d19a), щоб відкрити приклад у Solana Playground. Ви побачите такий код: - +Натисніть це [посилання](https://beta.solpg.io/6671c9aecffcf4b13384d19a), щоб +відкрити приклад у Solana Playground. Ви побачите такий код: ```ts filename="client.ts" {3} import { PublicKey } from "@solana/web3.js"; @@ -222,13 +263,13 @@ const accountInfo = await pg.connection.getAccountInfo(address); console.log(JSON.stringify(accountInfo, null, 2)); ``` + У цьому прикладі ми отримаємо адресу існуючого акаунта Mint у devnet. ### Запуск Прикладу 3 Запустіть код, виконавши команду `run`. - ```shell filename="Terminal" run ``` @@ -264,20 +305,33 @@ Running client... Основні відмінності в `AccountInfo`: -- **`owner`** — Акаунт mint належить програмі Token Extensions (`TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb`). -- **`executable`** — Встановлено у `false`, оскільки цей акаунт зберігає стан, а не виконуваний код. -- **`data`** — Містить серіалізовані дані про токен (авторитет випуску, загальну кількість, кількість знаків після коми тощо). +- **`owner`** — Акаунт mint належить програмі Token Extensions + (`TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb`). +- **`executable`** — Встановлено у `false`, оскільки цей акаунт зберігає стан, а + не виконуваний код. +- **`data`** — Містить серіалізовані дані про токен (авторитет випуску, загальну + кількість, кількість знаків після коми тощо). ### Десеріалізація Даних Акаунта Mint -Щоб зчитати поле `data` з будь-якого акаунта, потрібно десеріалізувати буфер даних у очікуваний тип даних. Це часто виконується за допомогою допоміжних функцій клієнтських бібліотек для конкретної програми. +Щоб зчитати поле `data` з будь-якого акаунта, потрібно десеріалізувати буфер +даних у очікуваний тип даних. Це часто виконується за допомогою допоміжних +функцій клієнтських бібліотек для конкретної програми. -**Десеріалізація** — це процес перетворення даних зі збереженого формату (наприклад, необроблених байтів або JSON) назад у використовуваний структурований формат у програмі. У блокчейні це включає взяття необроблених, закодованих даних із мережі та їх перетворення назад в об'єкти, класи або читабельні структури, щоб розробники могли отримати доступ до конкретної інформації та маніпулювати нею у програмі. Десеріалізація є важливою для інтерпретації даних акаунтів або транзакцій, отриманих із мережі, у формі, яку програма може обробляти і відображати осмислено. +**Десеріалізація** — це процес перетворення даних зі збереженого формату +(наприклад, необроблених байтів або JSON) назад у використовуваний +структурований формат у програмі. У блокчейні це включає взяття необроблених, +закодованих даних із мережі та їх перетворення назад в об'єкти, класи або +читабельні структури, щоб розробники могли отримати доступ до конкретної +інформації та маніпулювати нею у програмі. Десеріалізація є важливою для +інтерпретації даних акаунтів або транзакцій, отриманих із мережі, у формі, яку +програма може обробляти і відображати осмислено. -Відкрийте цей [приклад](https://beta.solpg.io/6671cd8acffcf4b13384d19b) у Solana Playground. Ви побачите такий код: +Відкрийте цей [приклад](https://beta.solpg.io/6671cd8acffcf4b13384d19b) у Solana +Playground. Ви побачите такий код: ```ts filename="client.ts" import { PublicKey } from "@solana/web3.js"; @@ -294,13 +348,15 @@ const mintData = await getMint( console.log(mintData); ``` -Цей приклад використовує функцію `getMint`, яка автоматично десеріалізує поле `data` акаунта Mint. +Цей приклад використовує функцію `getMint`, яка автоматично десеріалізує поле +`data` акаунта Mint. Запустіть код, виконавши команду `run`. ```shell filename="Terminal" run ``` + Ви повинні побачити наступні десеріалізовані дані акаунта Mint. @@ -321,20 +377,25 @@ Running client... -Функція `getMint` десеріалізує дані акаунта у тип даних [Mint](https://github.com/solana-labs/solana-program-library/blob/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program/src/state.rs#L18-L32), визначений у вихідному коді програми Token Extensions. +Функція `getMint` десеріалізує дані акаунта у тип даних +[Mint](https://github.com/solana-labs/solana-program-library/blob/b1c44c171bc95e6ee74af12365cb9cbab68be76c/token/program/src/state.rs#L18-L32), +визначений у вихідному коді програми Token Extensions. - **`address`** — Адреса акаунта Mint. - **`mintAuthority`** — Авторитет, який може випускати нові токени. - **`supply`** — Загальна кількість токенів в обігу. - **`decimals`** — Кількість десяткових знаків для токена. - **`isInitialized`** — Чи були дані Mint ініціалізовані. -- **`freezeAuthority`** — Авторитет, який має право заморожувати акаунти токенів. -- **`tlvData`** — Додаткові дані для Token Extensions (вимагають подальшої десеріалізації). +- **`freezeAuthority`** — Авторитет, який має право заморожувати акаунти + токенів. +- **`tlvData`** — Додаткові дані для Token Extensions (вимагають подальшої + десеріалізації). -Ви можете переглянути повністю десеріалізовані [дані акаунта Mint](https://explorer.solana.com/address/C33qt1dZGZSsqTrHdtLKXPZNoxs6U1ZBfyDkzmj6mXeR?cluster=devnet), включаючи активовані Token Extensions, у Solana Explorer. +Ви можете переглянути повністю десеріалізовані +[дані акаунта Mint](https://explorer.solana.com/address/C33qt1dZGZSsqTrHdtLKXPZNoxs6U1ZBfyDkzmj6mXeR?cluster=devnet), +включаючи активовані Token Extensions, у Solana Explorer. - diff --git a/docs/locales/uk/intro/quick-start/writing-to-network.md b/docs/locales/uk/intro/quick-start/writing-to-network.md index 1e17da27f..37bbbc4bf 100644 --- a/docs/locales/uk/intro/quick-start/writing-to-network.md +++ b/docs/locales/uk/intro/quick-start/writing-to-network.md @@ -4,23 +4,33 @@ title: Запис у Мережу sidebarSortOrder: 2 description: Дізнайтеся, як взаємодіяти з мережею Solana шляхом надсилання транзакцій та - інструкцій. Слідуйте покроковим прикладам для переказу токенів SOL та створення - нових токенів за допомогою System Program та Token Extensions Program. + інструкцій. Слідуйте покроковим прикладам для переказу токенів SOL та + створення нових токенів за допомогою System Program та Token Extensions + Program. --- -Тепер, коли ми розглянули зчитування даних із мережі Solana, давайте навчимося записувати дані до неї. У Solana взаємодія з мережею здійснюється шляхом надсилання транзакцій, що складаються з інструкцій. Ці інструкції визначаються програмами, які містять бізнес-логіку про те, як мають оновлюватися акаунти. +Тепер, коли ми розглянули зчитування даних із мережі Solana, давайте навчимося +записувати дані до неї. У Solana взаємодія з мережею здійснюється шляхом +надсилання транзакцій, що складаються з інструкцій. Ці інструкції визначаються +програмами, які містять бізнес-логіку про те, як мають оновлюватися акаунти. -Розглянемо два поширені операції, переказ SOL і створення токена, щоб продемонструвати, як створювати і надсилати транзакції. Для отримання додаткової інформації відвідайте сторінки [Транзакції та Інструкції](/docs/uk/core/transactions) і [Комісії у Solana](/docs/uk/core/fees). +Розглянемо два поширені операції, переказ SOL і створення токена, щоб +продемонструвати, як створювати і надсилати транзакції. Для отримання додаткової +інформації відвідайте сторінки +[Транзакції та Інструкції](/docs/uk/core/transactions) і +[Комісії у Solana](/docs/uk/core/fees). ## Переказ SOL -Почнемо із простої операції переказу SOL з вашого гаманця на інший акаунт. Це вимагає виклику інструкції переказу у System Program. +Почнемо із простої операції переказу SOL з вашого гаманця на інший акаунт. Це +вимагає виклику інструкції переказу у System Program. ### Відкриття Прикладу 1 -Натисніть це [посилання](https://beta.solpg.io/6671d85ecffcf4b13384d19e), щоб відкрити приклад у Solana Playground. Ви побачите такий код: +Натисніть це [посилання](https://beta.solpg.io/6671d85ecffcf4b13384d19e), щоб +відкрити приклад у Solana Playground. Ви побачите такий код: ```ts filename="client.ts" import { @@ -97,7 +107,8 @@ console.log( ); ``` -- Виводить посилання на SolanaFM у термінал Playground для перегляду деталей транзакції. +- Виводить посилання на SolanaFM у термінал Playground для перегляду деталей + транзакції. ```ts console.log( @@ -113,12 +124,12 @@ console.log( Запустіть код, виконавши команду `run`. - ```shell filename="Terminal" run ``` -Натисніть на посилання у виведених даних, щоб переглянути деталі транзакції у SolanaFM Explorer. +Натисніть на посилання у виведених даних, щоб переглянути деталі транзакції у +SolanaFM Explorer. @@ -134,13 +145,16 @@ Running client... ![Transfer SOL](/assets/docs/intro/quickstart/transfer-sol.png) -Ви щойно надіслали свою першу транзакцію у Solana! Зверніть увагу, як ми створили інструкцію, додали її до транзакції, а потім відправили цю транзакцію до мережі. Це базовий процес для створення будь-якої транзакції. +Ви щойно надіслали свою першу транзакцію у Solana! Зверніть увагу, як ми +створили інструкцію, додали її до транзакції, а потім відправили цю транзакцію +до мережі. Це базовий процес для створення будь-якої транзакції. ## Створення Токена -Тепер створимо новий токен шляхом створення та ініціалізації акаунта Mint. Для цього потрібні дві інструкції: +Тепер створимо новий токен шляхом створення та ініціалізації акаунта Mint. Для +цього потрібні дві інструкції: - Виклик System Program для створення нового акаунта. - Виклик Token Extensions Program для ініціалізації даних акаунта. @@ -149,7 +163,8 @@ Running client... ### Відкриття Прикладу 2 -Натисніть це [посилання](https://beta.solpg.io/6671da4dcffcf4b13384d19f), щоб відкрити приклад у Solana Playground. Ви побачите наступний код: +Натисніть це [посилання](https://beta.solpg.io/6671da4dcffcf4b13384d19f), щоб +відкрити приклад у Solana Playground. Ви побачите наступний код: ```ts filename="client.ts" import { @@ -226,6 +241,7 @@ console.log( Цей скрипт виконує наступні кроки: - Налаштовує ваш гаманець Playground і з'єднання з devnet Solana: + ```ts const wallet = pg.wallet; const connection = new Connection(clusterApiUrl("devnet"), "confirmed"); @@ -243,7 +259,8 @@ console.log( const rentLamports = await getMinimumBalanceForRentExemptMint(connection); ``` -- Створює інструкцію для створення нового акаунта mint, вказуючи програму Token Extensions (TOKEN_2022_PROGRAM_ID) як власника нового акаунта: +- Створює інструкцію для створення нового акаунта mint, вказуючи програму Token + Extensions (TOKEN_2022_PROGRAM_ID) як власника нового акаунта: ```ts const createAccountInstruction = SystemProgram.createAccount({ @@ -276,7 +293,10 @@ console.log( ); ``` -- Відправляє та підтверджує транзакцію. Гаманець і ключова пара mint передаються як підписувачі транзакції. Гаманець потрібен для оплати створення нового акаунта, а ключова пара mint потрібна, оскільки її публічний ключ використовується як адреса нового акаунта: +- Відправляє та підтверджує транзакцію. Гаманець і ключова пара mint передаються + як підписувачі транзакції. Гаманець потрібен для оплати створення нового + акаунта, а ключова пара mint потрібна, оскільки її публічний ключ + використовується як адреса нового акаунта: ```ts const transactionSignature = await sendAndConfirmTransaction( @@ -286,7 +306,8 @@ console.log( ); ``` -- Виводить посилання для перегляду транзакції та деталей акаунта mint на SolanaFM: +- Виводить посилання для перегляду транзакції та деталей акаунта mint на + SolanaFM: ```ts console.log( @@ -316,7 +337,8 @@ run - Одне для деталей транзакції - Інше для новоствореного акаунта mint -Натисніть на посилання, щоб переглянути деталі транзакції та новостворений акаунт mint у SolanaFM. +Натисніть на посилання, щоб переглянути деталі транзакції та новостворений +акаунт mint у SolanaFM. @@ -337,6 +359,9 @@ Mint Account: https://solana.fm/address/CoZ3Nz488rmATDhy1hPk5fvwSZaipCngvf8rYBYV ![Mint Account](/assets/docs/intro/quickstart/mint-account.png) -Зверніть увагу, як цього разу ми створили транзакцію з кількома інструкціями. Спочатку ми створили новий акаунт, а потім ініціалізували його дані як mint. Таким чином створюються складніші транзакції, які включають інструкції з кількох програм. +Зверніть увагу, як цього разу ми створили транзакцію з кількома інструкціями. +Спочатку ми створили новий акаунт, а потім ініціалізували його дані як mint. +Таким чином створюються складніші транзакції, які включають інструкції з кількох +програм. diff --git a/docs/locales/uk/intro/wallets.md b/docs/locales/uk/intro/wallets.md index f12d22c36..e3af2e607 100644 --- a/docs/locales/uk/intro/wallets.md +++ b/docs/locales/uk/intro/wallets.md @@ -4,32 +4,67 @@ title: Посібник із Гаманців Solana sidebarSortOrder: 3 --- -Цей документ описує різні варіанти гаманців, доступних користувачам Solana, які хочуть надсилати, отримувати та взаємодіяти з токенами SOL у блокчейні Solana. +Цей документ описує різні варіанти гаманців, доступних користувачам Solana, які +хочуть надсилати, отримувати та взаємодіяти з токенами SOL у блокчейні Solana. ## Що таке Гаманець? -Криптогаманець — це пристрій або програма, яка зберігає набір ключів і може використовуватися для надсилання, отримання та відстеження володіння криптовалютами. Гаманці можуть мати різні форми. Гаманець може бути каталогом або файлом у файловій системі вашого комп’ютера, аркушем паперу або спеціалізованим пристроєм, який називається _апаратний гаманець_. Також існують різні програми для смартфонів і комп’ютерів, які надають зручний спосіб створення та управління гаманцями. +Криптогаманець — це пристрій або програма, яка зберігає набір ключів і може +використовуватися для надсилання, отримання та відстеження володіння +криптовалютами. Гаманці можуть мати різні форми. Гаманець може бути каталогом +або файлом у файловій системі вашого комп’ютера, аркушем паперу або +спеціалізованим пристроєм, який називається _апаратний гаманець_. Також існують +різні програми для смартфонів і комп’ютерів, які надають зручний спосіб +створення та управління гаманцями. ### Keypair -[_Keypair_](/docs/uk/terminology.md#keypair) — це безпечно згенерований [_секретний ключ_](#secret-key) і його криптографічно виведений [_публічний ключ_](#public-key). Секретний ключ та його відповідний публічний ключ разом називаються _ключовою парою_. Гаманець містить колекцію однієї або кількох ключових пар і надає засоби для взаємодії з ними. +[_Keypair_](/docs/uk/terminology.md#keypair) — це безпечно згенерований +[_секретний ключ_](#secret-key) і його криптографічно виведений +[_публічний ключ_](#public-key). Секретний ключ та його відповідний публічний +ключ разом називаються _ключовою парою_. Гаманець містить колекцію однієї або +кількох ключових пар і надає засоби для взаємодії з ними. ### Публічний ключ -[_Публічний ключ_](/docs/uk/terminology.md#public-key-pubkey) (часто скорочується до _pubkey_) відомий як _адреса для отримання_ гаманця або просто його _адреса_. Адресу гаманця **можна вільно передавати та показувати**. Коли інша сторона збирається надіслати певну кількість криптовалюти на гаманець, їй потрібно знати адресу для отримання. Залежно від реалізації блокчейну, адреса також може використовуватися для перегляду певної інформації про гаманець, наприклад, балансу, але вона не дозволяє змінювати гаманець або знімати з нього токени. +[_Публічний ключ_](/docs/uk/terminology.md#public-key-pubkey) (часто +скорочується до _pubkey_) відомий як _адреса для отримання_ гаманця або просто +його _адреса_. Адресу гаманця **можна вільно передавати та показувати**. Коли +інша сторона збирається надіслати певну кількість криптовалюти на гаманець, їй +потрібно знати адресу для отримання. Залежно від реалізації блокчейну, адреса +також може використовуватися для перегляду певної інформації про гаманець, +наприклад, балансу, але вона не дозволяє змінювати гаманець або знімати з нього +токени. ### Секретний ключ -[_Секретний ключ_](/docs/uk/terminology.md#private-key) (також називається _приватним ключем_) потрібен для цифрового підпису будь-яких транзакцій для відправлення криптовалюти на іншу адресу або внесення змін до гаманця. Секретний ключ **ніколи не повинен бути переданий іншим**. Якщо хтось отримає доступ до секретного ключа гаманця, він може зняти всі токени, які він містить. Якщо секретний ключ гаманця втрачено, будь-які токени, відправлені на адресу цього гаманця, **назавжди втрачені**. +[_Секретний ключ_](/docs/uk/terminology.md#private-key) (також називається +_приватним ключем_) потрібен для цифрового підпису будь-яких транзакцій для +відправлення криптовалюти на іншу адресу або внесення змін до гаманця. Секретний +ключ **ніколи не повинен бути переданий іншим**. Якщо хтось отримає доступ до +секретного ключа гаманця, він може зняти всі токени, які він містить. Якщо +секретний ключ гаманця втрачено, будь-які токени, відправлені на адресу цього +гаманця, **назавжди втрачені**. ## Безпека -Різні рішення для гаманців пропонують різні підходи до безпеки ключової пари, взаємодії з нею та підписання транзакцій для використання/витрачання токенів. Деякі є простішими у використанні, ніж інші. Деякі забезпечують більш безпечне зберігання та резервне копіювання секретних ключів. Solana підтримує кілька типів гаманців, тому ви можете обрати правильний баланс між безпекою та зручністю. +Різні рішення для гаманців пропонують різні підходи до безпеки ключової пари, +взаємодії з нею та підписання транзакцій для використання/витрачання токенів. +Деякі є простішими у використанні, ніж інші. Деякі забезпечують більш безпечне +зберігання та резервне копіювання секретних ключів. Solana підтримує кілька +типів гаманців, тому ви можете обрати правильний баланс між безпекою та +зручністю. -**Якщо ви хочете отримувати токени SOL у блокчейні Solana, вам спочатку потрібно створити гаманець.** +**Якщо ви хочете отримувати токени SOL у блокчейні Solana, вам спочатку потрібно +створити гаманець.** ## Підтримувані Гаманці -Кілька гаманців на основі браузера та мобільних додатків підтримують Solana. Знайдіть варіанти, які можуть підійти вам, на сторінці [Solana Wallets](https://solana.com/wallets). +Кілька гаманців на основі браузера та мобільних додатків підтримують Solana. +Знайдіть варіанти, які можуть підійти вам, на сторінці +[Solana Wallets](https://solana.com/wallets). -Для досвідчених користувачів або розробників більше підходять [гаманці командного рядка](https://docs.anza.xyz/cli/wallets), оскільки нові функції в блокчейні Solana завжди спочатку підтримуються в командному рядку, перш ніж бути інтегрованими у сторонні рішення. +Для досвідчених користувачів або розробників більше підходять +[гаманці командного рядка](https://docs.anza.xyz/cli/wallets), оскільки нові +функції в блокчейні Solana завжди спочатку підтримуються в командному рядку, +перш ніж бути інтегрованими у сторонні рішення. diff --git a/docs/locales/uk/more/exchange.md b/docs/locales/uk/more/exchange.md index 19a773cbc..9958a67a3 100644 --- a/docs/locales/uk/more/exchange.md +++ b/docs/locales/uk/more/exchange.md @@ -2,19 +2,27 @@ title: Додати Solana на Вашу Біржу --- -Цей посібник описує, як додати нативний токен Solana (SOL) до вашої криптовалютної біржі. +Цей посібник описує, як додати нативний токен Solana (SOL) до вашої +криптовалютної біржі. ## Налаштування Ноди -Ми наполегливо рекомендуємо налаштувати щонайменше дві ноди на високопродуктивних комп’ютерах або хмарних інстанціях, своєчасно оновлювати їх до нових версій і відстежувати роботу сервісу за допомогою вбудованих інструментів моніторингу. +Ми наполегливо рекомендуємо налаштувати щонайменше дві ноди на +високопродуктивних комп’ютерах або хмарних інстанціях, своєчасно оновлювати їх +до нових версій і відстежувати роботу сервісу за допомогою вбудованих +інструментів моніторингу. Це налаштування дозволяє вам: -- мати самостійно керований шлюз до кластеру Solana mainnet-beta для отримання даних і надсилання транзакцій на виведення +- мати самостійно керований шлюз до кластеру Solana mainnet-beta для отримання + даних і надсилання транзакцій на виведення - мати повний контроль над тим, скільки історичних даних блоків зберігається - забезпечувати доступність вашого сервісу навіть у разі відмови однієї з нод -Ноди Solana вимагають відносно високої обчислювальної потужності для обробки швидких блоків і високої пропускної здатності (TPS). Для конкретних вимог дивіться [рекомендації щодо апаратного забезпечення](https://docs.anza.xyz/operations/requirements). +Ноди Solana вимагають відносно високої обчислювальної потужності для обробки +швидких блоків і високої пропускної здатності (TPS). Для конкретних вимог +дивіться +[рекомендації щодо апаратного забезпечення](https://docs.anza.xyz/operations/requirements). Щоб запустити ноду API: @@ -35,70 +43,132 @@ solana-validator \ --only-known-rpc ``` -Налаштуйте параметр `--ledger` для бажаного розташування зберігання леджера та параметр `--rpc-port` для порту, який ви хочете зробити доступним. +Налаштуйте параметр `--ledger` для бажаного розташування зберігання леджера та +параметр `--rpc-port` для порту, який ви хочете зробити доступним. -Параметри `--entrypoint` та `--expected-genesis-hash` є специфічними для кластера, до якого ви приєднуєтеся. +Параметри `--entrypoint` та `--expected-genesis-hash` є специфічними для +кластера, до якого ви приєднуєтеся. [Поточні параметри для Mainnet Beta](https://docs.anza.xyz/clusters/available#example-solana-validator-command-line-2) -Параметр `--limit-ledger-size` дозволяє вказати, скільки [шредів](/docs/uk/terminology.md#shred) леджера ваша нода зберігатиме на диску. Якщо цей параметр не вказано, валідатор зберігатиме весь леджер, доки не закінчиться місце на диску. Значення за замовчуванням намагається обмежити використання місця на диску леджером до 500 ГБ. За потреби можна змінити це значення, додавши аргумент до параметра `--limit-ledger-size`. Для перегляду значення за замовчуванням, яке використовується параметром `--limit-ledger-size`, виконайте команду `solana-validator --help`. Більше інформації про вибір власного значення обмеження можна знайти [тут](https://github.com/solana-labs/solana/blob/583cec922b6107e0f85c7e14cb5e642bc7dfb340/core/src/ledger_cleanup_service.rs#L15-L26). - -Вказівка одного або кількох параметрів `--known-validator` може захистити вас від запуску з підробленого знімку. +Параметр `--limit-ledger-size` дозволяє вказати, скільки +[шредів](/docs/uk/terminology.md#shred) леджера ваша нода зберігатиме на диску. +Якщо цей параметр не вказано, валідатор зберігатиме весь леджер, доки не +закінчиться місце на диску. Значення за замовчуванням намагається обмежити +використання місця на диску леджером до 500 ГБ. За потреби можна змінити це +значення, додавши аргумент до параметра `--limit-ledger-size`. Для перегляду +значення за замовчуванням, яке використовується параметром +`--limit-ledger-size`, виконайте команду `solana-validator --help`. Більше +інформації про вибір власного значення обмеження можна знайти +[тут](https://github.com/solana-labs/solana/blob/583cec922b6107e0f85c7e14cb5e642bc7dfb340/core/src/ledger_cleanup_service.rs#L15-L26). + +Вказівка одного або кількох параметрів `--known-validator` може захистити вас +від запуску з підробленого знімку. [Більше про цінність запуску з відомими валідаторами](https://docs.anza.xyz/operations/guides/validator-start#known-validators) Додаткові параметри, які варто розглянути: -- `--private-rpc` забороняє публікацію вашого RPC-порту для використання іншими нодами +- `--private-rpc` забороняє публікацію вашого RPC-порту для використання іншими + нодами - `--rpc-bind-address` дозволяє вказати іншу IP-адресу для прив’язки RPC-порту ### Автоматичний Перезапуск та Моніторинг -Ми рекомендуємо налаштувати кожну з ваших нод на автоматичний перезапуск після завершення роботи, щоб мінімізувати втрату даних. Запуск програмного забезпечення Solana як служби systemd є одним із чудових варіантів. +Ми рекомендуємо налаштувати кожну з ваших нод на автоматичний перезапуск після +завершення роботи, щоб мінімізувати втрату даних. Запуск програмного +забезпечення Solana як служби systemd є одним із чудових варіантів. -Для моніторингу ми надаємо інструмент -[`solana-watchtower`](https://github.com/solana-labs/solana/blob/master/watchtower/README.md), -який може моніторити ваш валідатор і визначати, чи є процес `solana-validator` несправним. Він може бути налаштований для сповіщень через Slack, Telegram, Discord або Twilio. Для деталей виконайте команду `solana-watchtower --help`. +Для моніторингу ми надаємо інструмент +[`solana-watchtower`](https://github.com/solana-labs/solana/blob/master/watchtower/README.md), +який може моніторити ваш валідатор і визначати, чи є процес `solana-validator` +несправним. Він може бути налаштований для сповіщень через Slack, Telegram, +Discord або Twilio. Для деталей виконайте команду `solana-watchtower --help`. ```shell solana-watchtower --validator-identity ``` -> Додаткову інформацію про [найкращі практики для Solana Watchtower](https://docs.anza.xyz/operations/best-practices/monitoring#solana-watchtower) можна знайти у документації. + +> Додаткову інформацію про +> [найкращі практики для Solana Watchtower](https://docs.anza.xyz/operations/best-practices/monitoring#solana-watchtower) +> можна знайти у документації. #### Оголошення про Нові Релізи ПЗ -Ми випускаємо нове програмне забезпечення часто (приблизно один реліз на тиждень). Іноді нові версії містять несумісні протокольні зміни, які вимагають своєчасного оновлення ПЗ, щоб уникнути помилок при обробці блоків. +Ми випускаємо нове програмне забезпечення часто (приблизно один реліз на +тиждень). Іноді нові версії містять несумісні протокольні зміни, які вимагають +своєчасного оновлення ПЗ, щоб уникнути помилок при обробці блоків. -Наші офіційні оголошення про всі види релізів (звичайні та пов’язані з безпекою) публікуються в [каналі Discord](https://solana.com/discord) під назвою `#mb-announcement` (`mb` означає `mainnet-beta`). +Наші офіційні оголошення про всі види релізів (звичайні та пов’язані з безпекою) +публікуються в [каналі Discord](https://solana.com/discord) під назвою +`#mb-announcement` (`mb` означає `mainnet-beta`). -Як і для валідаторів зі ставками, ми очікуємо, що валідатори, які обслуговуються біржами, будуть оновлюватися протягом одного-двох робочих днів після оголошення про звичайний реліз. Для релізів, пов’язаних із безпекою, може знадобитися більш термінове реагування. +Як і для валідаторів зі ставками, ми очікуємо, що валідатори, які обслуговуються +біржами, будуть оновлюватися протягом одного-двох робочих днів після оголошення +про звичайний реліз. Для релізів, пов’язаних із безпекою, може знадобитися більш +термінове реагування. ### Цілісність Леджера -За замовчуванням кожна з ваших нод завантажується зі знімку, наданого одним із ваших відомих валідаторів. Цей знімок відображає поточний стан ланцюга, але не містить повного історичного леджера. Якщо одна з ваших нод зупиняється та завантажується з нового знімка, у леджері цієї ноди може з’явитися прогалина. Щоб уникнути цієї проблеми, додайте параметр `--no-snapshot-fetch` до команди `solana-validator`, щоб отримувати історичні дані леджера замість знімка. +За замовчуванням кожна з ваших нод завантажується зі знімку, наданого одним із +ваших відомих валідаторів. Цей знімок відображає поточний стан ланцюга, але не +містить повного історичного леджера. Якщо одна з ваших нод зупиняється та +завантажується з нового знімка, у леджері цієї ноди може з’явитися прогалина. +Щоб уникнути цієї проблеми, додайте параметр `--no-snapshot-fetch` до команди +`solana-validator`, щоб отримувати історичні дані леджера замість знімка. -Не додавайте параметр `--no-snapshot-fetch` під час початкового завантаження, оскільки неможливо завантажити ноду від самого генезис-блоку. Спочатку завантажтеся зі знімка, а потім додайте параметр `--no-snapshot-fetch` для наступних перезавантажень. +Не додавайте параметр `--no-snapshot-fetch` під час початкового завантаження, +оскільки неможливо завантажити ноду від самого генезис-блоку. Спочатку +завантажтеся зі знімка, а потім додайте параметр `--no-snapshot-fetch` для +наступних перезавантажень. -Варто зазначити, що обсяг доступного історичного леджера від інших нод у мережі обмежений. Якщо ваші валідатори зазнають значних простоїв, вони можуть не змогти синхронізуватися з мережею і будуть змушені завантажити новий знімок від відомого валідатора, що створить прогалину в історичному леджері, яку неможливо заповнити. +Варто зазначити, що обсяг доступного історичного леджера від інших нод у мережі +обмежений. Якщо ваші валідатори зазнають значних простоїв, вони можуть не змогти +синхронізуватися з мережею і будуть змушені завантажити новий знімок від +відомого валідатора, що створить прогалину в історичному леджері, яку неможливо +заповнити. ### Мінімізація Доступу до Портів Валідатора -Валідатору необхідно, щоб різні UDP- і TCP-порти були відкриті для вхідного трафіку від усіх інших валідаторів Solana. Хоча це найефективніший режим роботи і настійно рекомендується, можливо обмежити валідатор лише для вхідного трафіку від одного іншого валідатора Solana. - -Спочатку додайте аргумент `--restricted-repair-only-mode`. Це призведе до роботи валідатора в обмеженому режимі, в якому він не отримуватиме push-повідомлення від інших валідаторів і замість цього постійно опитуватиме інші валідатори для отримання блоків. Валідатор буде передавати UDP-пакети іншим валідаторам лише через порти _Gossip_ та _ServeR_ ("serve repair") і отримуватиме UDP-пакети лише через порти _Gossip_ та _Repair_. - -Порт _Gossip_ є двостороннім і дозволяє вашому валідатору підтримувати зв’язок із рештою кластеру. Ваш валідатор передаватиме запити на ремонт через порт _ServeR_, щоб отримувати нові блоки від решти мережі, оскільки Turbine тепер відключено. Ваш валідатор отримуватиме відповіді на запити ремонту через порт _Repair_ від інших валідаторів. - -Щоб додатково обмежити валідатор для запитів блоків лише від одного або кількох валідаторів, спочатку визначте публічний ключ (pubkey) цього валідатора та додайте аргументи `--gossip-pull-validator PUBKEY --repair-validator PUBKEY` для кожного PUBKEY. Це створить навантаження на кожен валідатор, який ви додаєте, тому робіть це обережно і лише після консультації з цільовим валідатором. - -Ваш валідатор тепер повинен спілкуватися лише з чітко вказаними валідаторами і лише через порти _Gossip_, _Repair_ та _ServeR_. +Валідатору необхідно, щоб різні UDP- і TCP-порти були відкриті для вхідного +трафіку від усіх інших валідаторів Solana. Хоча це найефективніший режим роботи +і настійно рекомендується, можливо обмежити валідатор лише для вхідного трафіку +від одного іншого валідатора Solana. + +Спочатку додайте аргумент `--restricted-repair-only-mode`. Це призведе до роботи +валідатора в обмеженому режимі, в якому він не отримуватиме push-повідомлення +від інших валідаторів і замість цього постійно опитуватиме інші валідатори для +отримання блоків. Валідатор буде передавати UDP-пакети іншим валідаторам лише +через порти _Gossip_ та _ServeR_ ("serve repair") і отримуватиме UDP-пакети лише +через порти _Gossip_ та _Repair_. + +Порт _Gossip_ є двостороннім і дозволяє вашому валідатору підтримувати зв’язок +із рештою кластеру. Ваш валідатор передаватиме запити на ремонт через порт +_ServeR_, щоб отримувати нові блоки від решти мережі, оскільки Turbine тепер +відключено. Ваш валідатор отримуватиме відповіді на запити ремонту через порт +_Repair_ від інших валідаторів. + +Щоб додатково обмежити валідатор для запитів блоків лише від одного або кількох +валідаторів, спочатку визначте публічний ключ (pubkey) цього валідатора та +додайте аргументи `--gossip-pull-validator PUBKEY --repair-validator PUBKEY` для +кожного PUBKEY. Це створить навантаження на кожен валідатор, який ви додаєте, +тому робіть це обережно і лише після консультації з цільовим валідатором. + +Ваш валідатор тепер повинен спілкуватися лише з чітко вказаними валідаторами і +лише через порти _Gossip_, _Repair_ та _ServeR_. ## Налаштування Депозитних Акаунтів -Акаунти Solana не потребують жодної ініціалізації в мережі; як тільки вони містять деяку кількість SOL, вони існують. Щоб налаштувати депозитний акаунт для вашої біржі, просто створіть ключову пару Solana за допомогою будь-якого з наших [інструментів для гаманців](https://docs.anza.xyz/cli/wallets). +Акаунти Solana не потребують жодної ініціалізації в мережі; як тільки вони +містять деяку кількість SOL, вони існують. Щоб налаштувати депозитний акаунт для +вашої біржі, просто створіть ключову пару Solana за допомогою будь-якого з наших +[інструментів для гаманців](https://docs.anza.xyz/cli/wallets). -Рекомендуємо використовувати унікальний депозитний акаунт для кожного з ваших користувачів. - -Акаунти Solana мають бути звільнені від оренди, містячи еквівалент 2-річної [оренди](/docs/uk/core/fees.md#rent) у SOL. Щоб визначити мінімальний баланс для звільнення від оренди для ваших депозитних акаунтів, виконайте запит до [ендпоінту `getMinimumBalanceForRentExemption`](/docs/uk/rpc/http/getMinimumBalanceForRentExemption.mdx): +Рекомендуємо використовувати унікальний депозитний акаунт для кожного з ваших +користувачів. +Акаунти Solana мають бути звільнені від оренди, містячи еквівалент 2-річної +[оренди](/docs/uk/core/fees.md#rent) у SOL. Щоб визначити мінімальний баланс для +звільнення від оренди для ваших депозитних акаунтів, виконайте запит до +[ендпоінту `getMinimumBalanceForRentExemption`](/docs/uk/rpc/http/getMinimumBalanceForRentExemption.mdx): ```shell curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" -d '{ @@ -117,33 +187,56 @@ curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" - ### Офлайн Акаунти -Ви можете залишити ключі для одного або декількох акаунтів колекції офлайн для підвищення безпеки. У цьому випадку вам потрібно буде переміщати SOL до "гарячих" акаунтів за допомогою наших [офлайн-методів](https://docs.anza.xyz/cli/examples/offline-signing). +Ви можете залишити ключі для одного або декількох акаунтів колекції офлайн для +підвищення безпеки. У цьому випадку вам потрібно буде переміщати SOL до +"гарячих" акаунтів за допомогою наших +[офлайн-методів](https://docs.anza.xyz/cli/examples/offline-signing). ## Відстеження Депозитів -Коли користувач хоче внести SOL на вашу біржу, інструктуйте його виконати переказ на відповідну депозитну адресу. +Коли користувач хоче внести SOL на вашу біржу, інструктуйте його виконати +переказ на відповідну депозитну адресу. ### Міграція Транзакцій із Версіями -Коли мережа Mainnet Beta почне обробляти транзакції із версіями, біржі **ЗОБОВ'ЯЗАНІ** внести зміни. Якщо не внести змін, виявлення депозитів працюватиме неправильно, оскільки отримання транзакції з версією або блоку, що містить такі транзакції, призведе до помилки. +Коли мережа Mainnet Beta почне обробляти транзакції із версіями, біржі +**ЗОБОВ'ЯЗАНІ** внести зміни. Якщо не внести змін, виявлення депозитів +працюватиме неправильно, оскільки отримання транзакції з версією або блоку, що +містить такі транзакції, призведе до помилки. - `{"maxSupportedTransactionVersion": 0}` - Параметр `maxSupportedTransactionVersion` потрібно додати до запитів `getBlock` і `getTransaction`, щоб уникнути порушення роботи виявлення депозитів. Остання версія транзакції — `0`, і саме її слід зазначати як максимальну підтримувану версію транзакції. + Параметр `maxSupportedTransactionVersion` потрібно додати до запитів + `getBlock` і `getTransaction`, щоб уникнути порушення роботи виявлення + депозитів. Остання версія транзакції — `0`, і саме її слід зазначати як + максимальну підтримувану версію транзакції. -Важливо розуміти, що транзакції з версіями дозволяють користувачам створювати транзакції, які використовують інший набір ключів акаунтів, завантажених з ончейн таблиць пошуку адрес. +Важливо розуміти, що транзакції з версіями дозволяють користувачам створювати +транзакції, які використовують інший набір ключів акаунтів, завантажених з +ончейн таблиць пошуку адрес. - `{"encoding": "jsonParsed"}` - При отриманні блоків і транзакцій тепер рекомендується використовувати кодування `"jsonParsed"`, оскільки воно включає всі ключі акаунтів транзакції (включаючи ті, що з таблиць пошуку) у список `"accountKeys"` повідомлення. Це спрощує розв'язання змін балансу, описаних у `preBalances` / `postBalances` і `preTokenBalances` / `postTokenBalances`. + При отриманні блоків і транзакцій тепер рекомендується використовувати + кодування `"jsonParsed"`, оскільки воно включає всі ключі акаунтів транзакції + (включаючи ті, що з таблиць пошуку) у список `"accountKeys"` повідомлення. Це + спрощує розв'язання змін балансу, описаних у `preBalances` / `postBalances` і + `preTokenBalances` / `postTokenBalances`. - Якщо використовується кодування `"json"`, записи у `preBalances` / `postBalances` і `preTokenBalances` / `postTokenBalances` можуть посилатися на ключі акаунтів, які **НЕ** входять до списку `"accountKeys"` і потребують розв'язання за допомогою записів `"loadedAddresses"` у метаданих транзакції. + Якщо використовується кодування `"json"`, записи у `preBalances` / + `postBalances` і `preTokenBalances` / `postTokenBalances` можуть посилатися на + ключі акаунтів, які **НЕ** входять до списку `"accountKeys"` і потребують + розв'язання за допомогою записів `"loadedAddresses"` у метаданих транзакції. ### Опитування Блоків -Для відстеження всіх депозитних акаунтів вашої біржі регулярно опитуйте кожен підтверджений блок і перевіряйте адреси, що вас цікавлять, використовуючи JSON-RPC сервіс вашої ноди API Solana. +Для відстеження всіх депозитних акаунтів вашої біржі регулярно опитуйте кожен +підтверджений блок і перевіряйте адреси, що вас цікавлять, використовуючи +JSON-RPC сервіс вашої ноди API Solana. -- Щоб визначити, які блоки доступні, надішліть запит [`getBlocks`](/docs/uk/rpc/http/getBlocks.mdx), передавши останній блок, який ви вже обробили, як параметр start-slot: +- Щоб визначити, які блоки доступні, надішліть запит + [`getBlocks`](/docs/uk/rpc/http/getBlocks.mdx), передавши останній блок, який + ви вже обробили, як параметр start-slot: ```shell curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" -d '{ @@ -165,19 +258,25 @@ curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" - "id": 1 } ``` + Не кожен слот створює блок, тому в послідовності чисел можуть бути прогалини. -- Для кожного блоку запитуйте його вміст за допомогою запиту [`getBlock`](/docs/uk/rpc/http/getBlock.mdx): +- Для кожного блоку запитуйте його вміст за допомогою запиту + [`getBlock`](/docs/uk/rpc/http/getBlock.mdx): ### Поради для Отримання Блоків - `{"rewards": false}` -За замовчуванням отримані блоки містять інформацію про комісії валідаторів за кожен блок і нагороди за стейкінг на межах епох. Якщо ця інформація вам не потрібна, вимкніть її за допомогою параметра `"rewards"`. +За замовчуванням отримані блоки містять інформацію про комісії валідаторів за +кожен блок і нагороди за стейкінг на межах епох. Якщо ця інформація вам не +потрібна, вимкніть її за допомогою параметра `"rewards"`. - `{"transactionDetails": "accounts"}` -За замовчуванням отримані блоки містять багато інформації про транзакції та метадані, які не потрібні для відстеження балансів акаунтів. Встановіть параметр `"transactionDetails"` для прискорення отримання блоків. +За замовчуванням отримані блоки містять багато інформації про транзакції та +метадані, які не потрібні для відстеження балансів акаунтів. Встановіть параметр +`"transactionDetails"` для прискорення отримання блоків. ```shell curl https://api.devnet.solana.com -X POST -H 'Content-Type: application/json' -d '{ @@ -263,15 +362,29 @@ curl https://api.devnet.solana.com -X POST -H 'Content-Type: application/json' - } ``` -Поля `preBalances` і `postBalances` дозволяють відстежувати зміни балансу кожного акаунта без необхідності аналізувати всю транзакцію. Вони містять початкові та кінцеві баланси кожного акаунта у [лампортах](/docs/uk/terminology.md#lamport), проіндексовані до списку `accountKeys`. Наприклад, якщо депозитна адреса, яка вас цікавить, — це `G1wZ113tiUHdSpQEBcid8n1x8BAvcWZoZgxPKxgE5B7o`, то ця транзакція представляє переказ 1040000000 - 1030000000 = 10,000,000 лампортів = 0.01 SOL. +Поля `preBalances` і `postBalances` дозволяють відстежувати зміни балансу +кожного акаунта без необхідності аналізувати всю транзакцію. Вони містять +початкові та кінцеві баланси кожного акаунта у +[лампортах](/docs/uk/terminology.md#lamport), проіндексовані до списку +`accountKeys`. Наприклад, якщо депозитна адреса, яка вас цікавить, — це +`G1wZ113tiUHdSpQEBcid8n1x8BAvcWZoZgxPKxgE5B7o`, то ця транзакція представляє +переказ 1040000000 - 1030000000 = 10,000,000 лампортів = 0.01 SOL. -Якщо вам потрібна додаткова інформація про тип транзакції або інші специфічні дані, ви можете запросити блок із RPC у бінарному форматі та проаналізувати його за допомогою нашого [Rust SDK](https://github.com/solana-labs/solana) або [JavaScript SDK](https://github.com/solana-labs/solana-web3.js). +Якщо вам потрібна додаткова інформація про тип транзакції або інші специфічні +дані, ви можете запросити блок із RPC у бінарному форматі та проаналізувати його +за допомогою нашого [Rust SDK](https://github.com/solana-labs/solana) або +[JavaScript SDK](https://github.com/solana-labs/solana-web3.js). ### Історія Адрес -Ви також можете запитати історію транзакцій для певної адреси. Це, як правило, _не_ є життєздатним методом для відстеження всіх ваших депозитних адрес за всіма слотами, але може бути корисним для аналізу кількох акаунтів за певний період часу. +Ви також можете запитати історію транзакцій для певної адреси. Це, як правило, +_не_ є життєздатним методом для відстеження всіх ваших депозитних адрес за всіма +слотами, але може бути корисним для аналізу кількох акаунтів за певний період +часу. -- Надішліть запит [`getSignaturesForAddress`](/docs/uk/rpc/http/getSignaturesForAddress.mdx) до API-ноди: +- Надішліть запит + [`getSignaturesForAddress`](/docs/uk/rpc/http/getSignaturesForAddress.mdx) до + API-ноди: ```shell curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" -d '{ @@ -321,7 +434,9 @@ curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" - "id": 1 } ``` -- Для кожного отриманого підпису отримайте деталі транзакції, надіславши запит [`getTransaction`](/docs/uk/rpc/http/getTransaction.mdx): + +- Для кожного отриманого підпису отримайте деталі транзакції, надіславши запит + [`getTransaction`](/docs/uk/rpc/http/getTransaction.mdx): ```shell curl https://api.devnet.solana.com -X POST -H 'Content-Type: application/json' -d '{ @@ -420,44 +535,69 @@ curl https://api.devnet.solana.com -X POST -H 'Content-Type: application/json' - ## Відправлення Виведення -Щоб виконати запит користувача на виведення SOL, ви повинні створити транзакцію переказу Solana та надіслати її на API-ноду для передачі в кластер. +Щоб виконати запит користувача на виведення SOL, ви повинні створити транзакцію +переказу Solana та надіслати її на API-ноду для передачі в кластер. ### Синхронний Переказ -Відправлення синхронного переказу до кластера Solana дозволяє легко переконатися, що переказ успішно завершено та підтверджено кластером. - -Інструмент командного рядка Solana пропонує просту команду `solana transfer` для створення, подання та підтвердження транзакцій переказу. За замовчуванням цей метод чекатиме та відстежуватиме прогрес через stderr, доки транзакція не буде підтверджена кластером. У разі невдачі транзакції буде повідомлено про будь-які помилки. +Відправлення синхронного переказу до кластера Solana дозволяє легко +переконатися, що переказ успішно завершено та підтверджено кластером. +Інструмент командного рядка Solana пропонує просту команду `solana transfer` для +створення, подання та підтвердження транзакцій переказу. За замовчуванням цей +метод чекатиме та відстежуватиме прогрес через stderr, доки транзакція не буде +підтверджена кластером. У разі невдачі транзакції буде повідомлено про будь-які +помилки. ```shell solana transfer --allow-unfunded-recipient --keypair --url http://localhost:8899 ``` -[Solana Javascript SDK](https://github.com/solana-labs/solana-web3.js) пропонує схожий підхід для екосистеми JS. Використовуйте `SystemProgram` для створення транзакції переказу та надсилайте її за допомогою методу `sendAndConfirmTransaction`. +[Solana Javascript SDK](https://github.com/solana-labs/solana-web3.js) пропонує +схожий підхід для екосистеми JS. Використовуйте `SystemProgram` для створення +транзакції переказу та надсилайте її за допомогою методу +`sendAndConfirmTransaction`. ### Асинхронний Переказ -Для більшої гнучкості ви можете надсилати перекази на виведення асинхронно. У цьому випадку саме ви несете відповідальність за перевірку успішності транзакції та її підтвердження кластером. +Для більшої гнучкості ви можете надсилати перекази на виведення асинхронно. У +цьому випадку саме ви несете відповідальність за перевірку успішності транзакції +та її підтвердження кластером. -**Примітка:** Кожна транзакція містить [recent blockhash](/docs/uk/core/transactions.md#recent-blockhash), що вказує на її актуальність. Важливо **дочекатися**, поки цей blockhash не стане недійсним, перш ніж повторювати спробу переказу, який, схоже, не було підтверджено або завершено кластером. Інакше ви ризикуєте створити подвійний витрату. Дивіться більше про [термін дії blockhash](#blockhash-expiration) нижче. +**Примітка:** Кожна транзакція містить +[recent blockhash](/docs/uk/core/transactions.md#recent-blockhash), що вказує на +її актуальність. Важливо **дочекатися**, поки цей blockhash не стане недійсним, +перш ніж повторювати спробу переказу, який, схоже, не було підтверджено або +завершено кластером. Інакше ви ризикуєте створити подвійний витрату. Дивіться +більше про [термін дії blockhash](#blockhash-expiration) нижче. -Спочатку отримайте недавній blockhash за допомогою ендпоінту [`getFees`](/docs/uk/rpc/deprecated/getFees.mdx) або команди CLI: +Спочатку отримайте недавній blockhash за допомогою ендпоінту +[`getFees`](/docs/uk/rpc/deprecated/getFees.mdx) або команди CLI: ```shell solana fees --url http://localhost:8899 ``` -У командному рядку передайте аргумент `--no-wait`, щоб відправити переказ асинхронно, і додайте ваш недавній blockhash за допомогою аргументу `--blockhash`: +У командному рядку передайте аргумент `--no-wait`, щоб відправити переказ +асинхронно, і додайте ваш недавній blockhash за допомогою аргументу +`--blockhash`: ```shell solana transfer --no-wait --allow-unfunded-recipient --blockhash --keypair --url http://localhost:8899 ``` -Ви також можете створити, підписати та серіалізувати транзакцію вручну, а потім надіслати її до кластера за допомогою ендпоінта JSON-RPC [`sendTransaction`](/docs/uk/rpc/http/sendTransaction.mdx). +Ви також можете створити, підписати та серіалізувати транзакцію вручну, а потім +надіслати її до кластера за допомогою ендпоінта JSON-RPC +[`sendTransaction`](/docs/uk/rpc/http/sendTransaction.mdx). #### Підтвердження Транзакцій та Фінальність -Отримайте статус групи транзакцій за допомогою ендпоінта JSON-RPC [`getSignatureStatuses`](/docs/uk/rpc/http/getSignatureStatuses.mdx). Поле `confirmations` вказує, скільки [підтверджених блоків](/docs/uk/terminology.md#confirmed-block) минуло з моменту обробки транзакції. Якщо `confirmations: null`, це означає, що транзакція є [фіналізованою](/docs/uk/terminology.md#finality). +Отримайте статус групи транзакцій за допомогою ендпоінта JSON-RPC +[`getSignatureStatuses`](/docs/uk/rpc/http/getSignatureStatuses.mdx). Поле +`confirmations` вказує, скільки +[підтверджених блоків](/docs/uk/terminology.md#confirmed-block) минуло з моменту +обробки транзакції. Якщо `confirmations: null`, це означає, що транзакція є +[фіналізованою](/docs/uk/terminology.md#finality). ```shell curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" -d '{ @@ -507,33 +647,52 @@ curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" - #### Термін Дії Blockhash -Ви можете перевірити, чи є конкретний blockhash ще дійсним, надіславши запит [`getFeeCalculatorForBlockhash`](/docs/uk/rpc/deprecated/getFeeCalculatorForBlockhash.mdx) з blockhash як параметром. Якщо значення у відповіді `null`, blockhash недійсний, і транзакція на виведення, яка використовує цей blockhash, не має шансів на успіх. +Ви можете перевірити, чи є конкретний blockhash ще дійсним, надіславши запит +[`getFeeCalculatorForBlockhash`](/docs/uk/rpc/deprecated/getFeeCalculatorForBlockhash.mdx) +з blockhash як параметром. Якщо значення у відповіді `null`, blockhash +недійсний, і транзакція на виведення, яка використовує цей blockhash, не має +шансів на успіх. ### Перевірка Адрес Акаунтів, Наданих Користувачами, для Виведення -Оскільки транзакції на виведення є незворотними, хорошою практикою може бути перевірка адреси акаунта, наданої користувачем, перед авторизацією виведення, щоб запобігти випадковій втраті коштів користувача. +Оскільки транзакції на виведення є незворотними, хорошою практикою може бути +перевірка адреси акаунта, наданої користувачем, перед авторизацією виведення, +щоб запобігти випадковій втраті коштів користувача. #### Основна Перевірка -Адреси Solana — це 32-байтовий масив, закодований за допомогою алфавіту base58 від Bitcoin. Це призводить до отримання ASCII-рядка, що відповідає наступному регулярному виразу: +Адреси Solana — це 32-байтовий масив, закодований за допомогою алфавіту base58 +від Bitcoin. Це призводить до отримання ASCII-рядка, що відповідає наступному +регулярному виразу: ```text [1-9A-HJ-NP-Za-km-z]{32,44} ``` -Ця перевірка сама по собі є недостатньою, оскільки адреси Solana не мають контрольної суми, тому помилки друку не можуть бути виявлені. Для додаткової перевірки введення користувачем можна декодувати рядок і підтвердити, що довжина отриманого байтового масиву дорівнює 32. Однак існують адреси, які можуть декодуватися у 32 байти, незважаючи на помилки, наприклад, пропущений символ, перестановка символів або ігнорування регістру. +Ця перевірка сама по собі є недостатньою, оскільки адреси Solana не мають +контрольної суми, тому помилки друку не можуть бути виявлені. Для додаткової +перевірки введення користувачем можна декодувати рядок і підтвердити, що довжина +отриманого байтового масиву дорівнює 32. Однак існують адреси, які можуть +декодуватися у 32 байти, незважаючи на помилки, наприклад, пропущений символ, +перестановка символів або ігнорування регістру. #### Розширена Перевірка -Через вразливість до помилок друку, описану вище, рекомендується запитувати баланс для можливих адрес виведення та запитувати у користувача підтвердження, якщо буде виявлено ненульовий баланс. +Через вразливість до помилок друку, описану вище, рекомендується запитувати +баланс для можливих адрес виведення та запитувати у користувача підтвердження, +якщо буде виявлено ненульовий баланс. #### Перевірка Валідного ed25519 Публічного Ключа -Адреса звичайного акаунта в Solana — це Base58-кодований рядок 256-бітного публічного ключа ed25519. Не всі бітові патерни є валідними публічними ключами для кривої ed25519, тому можна забезпечити, що адреси акаунтів, надані користувачем, принаймні є правильними публічними ключами ed25519. +Адреса звичайного акаунта в Solana — це Base58-кодований рядок 256-бітного +публічного ключа ed25519. Не всі бітові патерни є валідними публічними ключами +для кривої ed25519, тому можна забезпечити, що адреси акаунтів, надані +користувачем, принаймні є правильними публічними ключами ed25519. #### Java -Ось приклад на Java для перевірки адреси, наданої користувачем, як валідного публічного ключа ed25519: +Ось приклад на Java для перевірки адреси, наданої користувачем, як валідного +публічного ключа ed25519: Наступний приклад коду передбачає використання Maven. @@ -590,11 +749,13 @@ public class PubkeyValidator ## Мінімальні Суми Депозиту та Виведення -Кожен депозит та виведення SOL повинні бути більшими або дорівнювати мінімальному балансу, звільненому від оренди, для акаунта за адресою гаманця (базовий акаунт SOL, який не містить даних), який наразі складає: **0.000890880 SOL**. +Кожен депозит та виведення SOL повинні бути більшими або дорівнювати +мінімальному балансу, звільненому від оренди, для акаунта за адресою гаманця +(базовий акаунт SOL, який не містить даних), який наразі складає: **0.000890880 +SOL**. Аналогічно, кожен депозитний акаунт повинен містити принаймні цей баланс. - ```shell curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" -d '{ "jsonrpc": "2.0", @@ -612,65 +773,99 @@ curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" - ## Пріоритетні Комісії та Обчислювальні Одиниці -У періоди високого попиту транзакція може стати недійсною до того, як валідатор включить її до блоку, оскільки були обрані інші транзакції з вищою економічною цінністю. Валідні транзакції в Solana можуть бути затримані або скасовані, якщо Пріоритетні Комісії не впроваджені належним чином. +У періоди високого попиту транзакція може стати недійсною до того, як валідатор +включить її до блоку, оскільки були обрані інші транзакції з вищою економічною +цінністю. Валідні транзакції в Solana можуть бути затримані або скасовані, якщо +Пріоритетні Комісії не впроваджені належним чином. -[Пріоритетні Комісії](/docs/uk/terminology.md#prioritization-fee) — це додаткові комісії, які можна додати до [базової комісії за транзакцію](/docs/uk/core/fees.md#transaction-fees), щоб забезпечити включення транзакцій у блоки і їх доставку. +[Пріоритетні Комісії](/docs/uk/terminology.md#prioritization-fee) — це додаткові +комісії, які можна додати до +[базової комісії за транзакцію](/docs/uk/core/fees.md#transaction-fees), щоб +забезпечити включення транзакцій у блоки і їх доставку. -Ці пріоритетні комісії додаються до транзакції шляхом додавання спеціальної інструкції `Compute Budget`, яка встановлює бажану суму комісії. +Ці пріоритетні комісії додаються до транзакції шляхом додавання спеціальної +інструкції `Compute Budget`, яка встановлює бажану суму комісії. -Якщо ці інструкції не впровадити, це може призвести до збоїв у роботі мережі та скасування транзакцій. Наполегливо рекомендується кожній біржі, що підтримує Solana, використовувати пріоритетні комісії для уникнення збоїв. +Якщо ці інструкції не впровадити, це може призвести до збоїв у роботі мережі та +скасування транзакцій. Наполегливо рекомендується кожній біржі, що підтримує +Solana, використовувати пріоритетні комісії для уникнення збоїв. ### Що таке Пріоритетна Комісія? -Пріоритетні комісії виражаються у мікролампортах за обчислювальну одиницю (наприклад, невеликі суми SOL) і додаються до транзакцій, щоб зробити їх економічно привабливими для валідаторів і забезпечити їх включення до блоків у мережі. +Пріоритетні комісії виражаються у мікролампортах за обчислювальну одиницю +(наприклад, невеликі суми SOL) і додаються до транзакцій, щоб зробити їх +економічно привабливими для валідаторів і забезпечити їх включення до блоків у +мережі. ### Якою має бути Пріоритетна Комісія? -Метод встановлення пріоритетної комісії має включати запити до недавніх значень пріоритетних комісій, щоб встановити розмір комісії, яка буде привабливою для мережі. Використовуючи метод RPC [`getRecentPrioritizationFees`](/docs/uk/rpc/http/getrecentprioritizationfees), можна отримати дані про пріоритетні комісії, необхідні для підтвердження транзакції в недавньому блоці. +Метод встановлення пріоритетної комісії має включати запити до недавніх значень +пріоритетних комісій, щоб встановити розмір комісії, яка буде привабливою для +мережі. Використовуючи метод RPC +[`getRecentPrioritizationFees`](/docs/uk/rpc/http/getrecentprioritizationfees), +можна отримати дані про пріоритетні комісії, необхідні для підтвердження +транзакції в недавньому блоці. -Стратегія ціноутворення пріоритетних комісій залежить від ваших потреб. Універсального підходу не існує. Однією зі стратегій може бути розрахунок рівня успішності ваших транзакцій і коригування пріоритетної комісії відповідно до даних з API про комісії. Ціноутворення на пріоритетні комісії є динамічним і залежить від активності в мережі та ставок інших учасників. +Стратегія ціноутворення пріоритетних комісій залежить від ваших потреб. +Універсального підходу не існує. Однією зі стратегій може бути розрахунок рівня +успішності ваших транзакцій і коригування пріоритетної комісії відповідно до +даних з API про комісії. Ціноутворення на пріоритетні комісії є динамічним і +залежить від активності в мережі та ставок інших учасників. ### Як Впровадити Пріоритетні Комісії -Додавання пріоритетних комісій до транзакції включає додавання двох інструкцій Compute Budget: +Додавання пріоритетних комісій до транзакції включає додавання двох інструкцій +Compute Budget: - для встановлення ціни за обчислювальну одиницю - для встановлення ліміту обчислювальних одиниць -> Детальний [посібник для розробників про використання пріоритетних комісій](/content/guides/advanced/how-to-use-priority-fees.md) доступний для додаткової інформації. +> Детальний +> [посібник для розробників про використання пріоритетних комісій](/content/guides/advanced/how-to-use-priority-fees.md) +> доступний для додаткової інформації. -Створіть інструкцію `setComputeUnitPrice`, щоб додати Пріоритетну Комісію понад Базову Комісію за Транзакцію (5,000 лампортів). +Створіть інструкцію `setComputeUnitPrice`, щоб додати Пріоритетну Комісію понад +Базову Комісію за Транзакцію (5,000 лампортів). ```typescript // import { ComputeBudgetProgram } from "@solana/web3.js" ComputeBudgetProgram.setComputeUnitPrice({ microLamports: number }); ``` -Значення, надане в мікролампортах, буде множитися на обчислювальний бюджет (Compute Unit, CU), щоб визначити Пріоритетну Комісію в лампортах. Наприклад, якщо ваш бюджет CU становить 1M CU, і ви додаєте `1 мікролампорта/CU`, Пріоритетна Комісія становитиме 1 лампорт (1M \* 0.000001). Загальна комісія складе 5001 лампорт. - -Щоб встановити новий обчислювальний бюджет для транзакції, створіть інструкцію `setComputeUnitLimit`. +Значення, надане в мікролампортах, буде множитися на обчислювальний бюджет +(Compute Unit, CU), щоб визначити Пріоритетну Комісію в лампортах. Наприклад, +якщо ваш бюджет CU становить 1M CU, і ви додаєте `1 мікролампорта/CU`, +Пріоритетна Комісія становитиме 1 лампорт (1M \* 0.000001). Загальна комісія +складе 5001 лампорт. +Щоб встановити новий обчислювальний бюджет для транзакції, створіть інструкцію +`setComputeUnitLimit`. ```typescript // import { ComputeBudgetProgram } from "@solana/web3.js" ComputeBudgetProgram.setComputeUnitLimit({ units: number }); ``` -Значення `units`, яке ви надаєте, замінить стандартне значення обчислювального бюджету (Compute Budget) в середовищі виконання Solana. +Значення `units`, яке ви надаєте, замінить стандартне значення обчислювального +бюджету (Compute Budget) в середовищі виконання Solana. -Транзакції повинні запитувати мінімальну кількість обчислювальних одиниць (CU), необхідну для виконання, щоб максимізувати пропускну здатність і мінімізувати загальні комісії. +Транзакції повинні запитувати мінімальну кількість обчислювальних одиниць (CU), +необхідну для виконання, щоб максимізувати пропускну здатність і мінімізувати +загальні комісії. -Ви можете дізнатися, скільки CU споживає транзакція, надіславши її в інший кластер Solana, наприклад, devnet. Наприклад, [простий переказ токенів](https://explorer.solana.com/tx/5scDyuiiEbLxjLUww3APE9X7i8LE3H63unzonUwMG7s2htpoAGG17sgRsNAhR1zVs6NQAnZeRVemVbkAct5myi17) займає 300 CU. +Ви можете дізнатися, скільки CU споживає транзакція, надіславши її в інший +кластер Solana, наприклад, devnet. Наприклад, +[простий переказ токенів](https://explorer.solana.com/tx/5scDyuiiEbLxjLUww3APE9X7i8LE3H63unzonUwMG7s2htpoAGG17sgRsNAhR1zVs6NQAnZeRVemVbkAct5myi17) +займає 300 CU. - ```typescript // import { ... } from "@solana/web3.js" @@ -697,33 +892,55 @@ const transaction = new Transaction() ### Пріоритетні Комісії та Транзакції з Durable Nonces -Якщо у вашій системі використовуються транзакції з Durable Nonces, важливо правильно впровадити Пріоритетні Комісії разом із Durable Transaction Nonces, щоб забезпечити успішне виконання транзакцій. Якщо цього не зробити, заплановані Durable Nonce транзакції не будуть розпізнані належним чином. +Якщо у вашій системі використовуються транзакції з Durable Nonces, важливо +правильно впровадити Пріоритетні Комісії разом із Durable Transaction Nonces, +щоб забезпечити успішне виконання транзакцій. Якщо цього не зробити, заплановані +Durable Nonce транзакції не будуть розпізнані належним чином. -Якщо ви ВИКОРИСТОВУЄТЕ Durable Transaction Nonces, інструкція `AdvanceNonceAccount` МАЄ бути зазначена ПЕРШОЮ у списку інструкцій, навіть якщо використовуються інструкції обчислювального бюджету для встановлення пріоритетних комісій. +Якщо ви ВИКОРИСТОВУЄТЕ Durable Transaction Nonces, інструкція +`AdvanceNonceAccount` МАЄ бути зазначена ПЕРШОЮ у списку інструкцій, навіть якщо +використовуються інструкції обчислювального бюджету для встановлення +пріоритетних комісій. -Специфічний приклад коду, що демонструє використання durable nonces і пріоритетних комісій разом, можна знайти у [керівництві для розробників](/content/guides/advanced/how-to-use-priority-fees.md#special-considerations). +Специфічний приклад коду, що демонструє використання durable nonces і +пріоритетних комісій разом, можна знайти у +[керівництві для розробників](/content/guides/advanced/how-to-use-priority-fees.md#special-considerations). ## Підтримка Стандарту SPL Token -[SPL Token](https://spl.solana.com/token) є стандартом для створення і обміну обгорнутих/синтетичних токенів у блокчейні Solana. +[SPL Token](https://spl.solana.com/token) є стандартом для створення і обміну +обгорнутих/синтетичних токенів у блокчейні Solana. -Робочий процес SPL Token схожий на той, що використовується для нативних SOL токенів, але є кілька відмінностей, які будуть розглянуті в цьому розділі. +Робочий процес SPL Token схожий на той, що використовується для нативних SOL +токенів, але є кілька відмінностей, які будуть розглянуті в цьому розділі. ### Токен Mints -Кожен _тип_ SPL Token декларується шляхом створення акаунта _mint_. Цей акаунт зберігає метадані, які описують характеристики токена, такі як пропозиція, кількість десяткових знаків і різні повноваження з контролю за mint. Кожен акаунт SPL Token посилається на відповідний mint і може взаємодіяти лише з SPL Token цього типу. +Кожен _тип_ SPL Token декларується шляхом створення акаунта _mint_. Цей акаунт +зберігає метадані, які описують характеристики токена, такі як пропозиція, +кількість десяткових знаків і різні повноваження з контролю за mint. Кожен +акаунт SPL Token посилається на відповідний mint і може взаємодіяти лише з SPL +Token цього типу. ### Встановлення CLI Інструменту `spl-token` -Акаунти SPL Token можна запитувати та змінювати за допомогою утиліти командного рядка `spl-token`. Приклади, наведені в цьому розділі, залежать від того, що вона встановлена на вашій локальній системі. +Акаунти SPL Token можна запитувати та змінювати за допомогою утиліти командного +рядка `spl-token`. Приклади, наведені в цьому розділі, залежать від того, що +вона встановлена на вашій локальній системі. -`spl-token` розповсюджується з Rust [crates.io](https://crates.io/crates/spl-token) через утиліту командного рядка Rust `cargo`. Останню версію `cargo` можна встановити за допомогою простого скрипта для вашої платформи на [rustup.rs](https://rustup.rs). Після встановлення `cargo`, утиліту `spl-token` можна отримати за допомогою такої команди: +`spl-token` розповсюджується з Rust +[crates.io](https://crates.io/crates/spl-token) через утиліту командного рядка +Rust `cargo`. Останню версію `cargo` можна встановити за допомогою простого +скрипта для вашої платформи на [rustup.rs](https://rustup.rs). Після +встановлення `cargo`, утиліту `spl-token` можна отримати за допомогою такої +команди: ```shell cargo install spl-token-cli ``` -Після цього ви можете перевірити встановлену версію, щоб переконатися у правильності встановлення: +Після цього ви можете перевірити встановлену версію, щоб переконатися у +правильності встановлення: ```shell spl-token --version @@ -734,12 +951,21 @@ spl-token --version ```text spl-token-cli 2.0.1 ``` + ### Створення Акаунтів -Акаунти SPL Token мають додаткові вимоги, яких не мають нативні акаунти System Program: +Акаунти SPL Token мають додаткові вимоги, яких не мають нативні акаунти System +Program: -1. Акаунти SPL Token мають бути створені до того, як у них можна буде внести токени. Акаунти токенів можна створити явно за допомогою команди `spl-token create-account` або неявно за допомогою команди `spl-token transfer --fund-recipient ...`. -2. Акаунти SPL Token повинні залишатися [звільненими від оренди](/docs/uk/core/fees.md#rent-exempt) протягом усього періоду їх існування, а отже, вимагають внесення невеликої кількості нативних SOL токенів під час створення акаунта. Для акаунтів SPL Token ця сума становить 0.00203928 SOL (2,039,280 лампортів). +1. Акаунти SPL Token мають бути створені до того, як у них можна буде внести + токени. Акаунти токенів можна створити явно за допомогою команди + `spl-token create-account` або неявно за допомогою команди + `spl-token transfer --fund-recipient ...`. +2. Акаунти SPL Token повинні залишатися + [звільненими від оренди](/docs/uk/core/fees.md#rent-exempt) протягом усього + періоду їх існування, а отже, вимагають внесення невеликої кількості нативних + SOL токенів під час створення акаунта. Для акаунтів SPL Token ця сума + становить 0.00203928 SOL (2,039,280 лампортів). #### Командний Рядок @@ -764,6 +990,7 @@ spl-token create-account AkUFCWTXb3w9nY2n6SFJvBV6VwvFUCe4KBMCcgLsa2ir Creating account 6VzWGL51jLebvnDifvcuEDec17sK6Wupi4gYhm5RzfkV Signature: 4JsqZEPra2eDTHtHpB4FMWSfk3UgcCVmkKkP7zESZeMrKmFFkDkNd91pKP3vPVVZZPiu5XxyJwS73Vi5WsZL88D7 ``` + Або щоб створити акаунт SPL Token з конкретною ключовою парою: ```shell @@ -778,6 +1005,7 @@ spl-token create-account AkUFCWTXb3w9nY2n6SFJvBV6VwvFUCe4KBMCcgLsa2ir token-acco Creating account 6VzWGL51jLebvnDifvcuEDec17sK6Wupi4gYhm5RzfkV Signature: 4JsqZEPra2eDTHtHpB4FMWSfk3UgcCVmkKkP7zESZeMrKmFFkDkNd91pKP3vPVVZZPiu5XxyJwS73Vi5WsZL88D7 ``` + ### Перевірка Балансу Акаунта #### Командний Рядок @@ -799,11 +1027,15 @@ solana balance 6VzWGL51jLebvnDifvcuEDec17sK6Wupi4gYhm5RzfkV ``` 0 ``` + ### Переказ Токенів -Вихідним акаунтом для переказу є фактичний акаунт токенів, який містить необхідну суму. +Вихідним акаунтом для переказу є фактичний акаунт токенів, який містить +необхідну суму. -Однак адресою отримувача може бути звичайний гаманець. Якщо асоційований токен акаунт для вказаного mint ще не існує для цього гаманця, переказ створить його, якщо буде вказаний аргумент `--fund-recipient`. +Однак адресою отримувача може бути звичайний гаманець. Якщо асоційований токен +акаунт для вказаного mint ще не існує для цього гаманця, переказ створить його, +якщо буде вказаний аргумент `--fund-recipient`. #### Командний Рядок @@ -831,19 +1063,43 @@ Signature: 3R6tsog17QM8KfzbcbdP4aoMfwgo6hBggJDVy7dZPVmH2xbCWjEj31JKD53NzMrf25ChF ### Депозити -Оскільки кожна пара `(гаманець, mint)` потребує окремого акаунта в ончейні, рекомендується, щоб адреси для цих акаунтів були отримані з гаманців для депозиту SOL за допомогою схеми [Associated Token Account (ATA)](https://spl.solana.com/associated-token-account), і приймалися _лише_ депозити з ATA адрес. +Оскільки кожна пара `(гаманець, mint)` потребує окремого акаунта в ончейні, +рекомендується, щоб адреси для цих акаунтів були отримані з гаманців для +депозиту SOL за допомогою схеми +[Associated Token Account (ATA)](https://spl.solana.com/associated-token-account), +і приймалися _лише_ депозити з ATA адрес. -Відстеження транзакцій депозиту має використовувати метод [опитування блоків](#poll-for-blocks), описаний вище. Кожен новий блок слід сканувати на наявність успішних транзакцій, що посилаються на адреси акаунтів, отриманих для користувачів. Поля `preTokenBalance` і `postTokenBalance` з метаданих транзакцій необхідно використовувати для визначення ефективної зміни балансу. Ці поля ідентифікують mint токена та власника акаунта (основну адресу гаманця) відповідного акаунта. +Відстеження транзакцій депозиту має використовувати метод +[опитування блоків](#poll-for-blocks), описаний вище. Кожен новий блок слід +сканувати на наявність успішних транзакцій, що посилаються на адреси акаунтів, +отриманих для користувачів. Поля `preTokenBalance` і `postTokenBalance` з +метаданих транзакцій необхідно використовувати для визначення ефективної зміни +балансу. Ці поля ідентифікують mint токена та власника акаунта (основну адресу +гаманця) відповідного акаунта. -Зауважте, що якщо акаунт для отримання створюється під час транзакції, у нього не буде запису `preTokenBalance`, оскільки стан акаунта раніше не існував. У цьому випадку початковий баланс можна вважати нульовим. +Зауважте, що якщо акаунт для отримання створюється під час транзакції, у нього +не буде запису `preTokenBalance`, оскільки стан акаунта раніше не існував. У +цьому випадку початковий баланс можна вважати нульовим. ### Виведення Адреса для виведення, надана користувачем, має бути адресою їх SOL гаманця. -Перед виконанням [переказу](#token-transfers) для виведення біржа повинна перевірити адресу, як це [описано вище](#validating-user-supplied-account-addresses-for-withdrawals). Крім того, ця адреса має належати System Program і не мати даних акаунта. Якщо на цій адресі відсутній баланс SOL, перед виконанням виведення слід отримати підтвердження користувача. Усі інші адреси для виведення повинні бути відхилені. - -З адреси для виведення [Associated Token Account (ATA)](https://spl.solana.com/associated-token-account) для відповідного mint отримується, і переказ виконується на цей акаунт за допомогою інструкції [TransferChecked](https://github.com/solana-labs/solana-program-library/blob/fc0d6a2db79bd6499f04b9be7ead0c400283845e/token/program/src/instruction.rs#L268). Зауважте, що ATA адреса може ще не існувати, у цьому випадку біржа повинна профінансувати акаунт від імені користувача. Для акаунтів SPL Token фінансування акаунта для виведення потребує 0.00203928 SOL (2,039,280 лампортів). +Перед виконанням [переказу](#token-transfers) для виведення біржа повинна +перевірити адресу, як це +[описано вище](#validating-user-supplied-account-addresses-for-withdrawals). +Крім того, ця адреса має належати System Program і не мати даних акаунта. Якщо +на цій адресі відсутній баланс SOL, перед виконанням виведення слід отримати +підтвердження користувача. Усі інші адреси для виведення повинні бути відхилені. + +З адреси для виведення +[Associated Token Account (ATA)](https://spl.solana.com/associated-token-account) +для відповідного mint отримується, і переказ виконується на цей акаунт за +допомогою інструкції +[TransferChecked](https://github.com/solana-labs/solana-program-library/blob/fc0d6a2db79bd6499f04b9be7ead0c400283845e/token/program/src/instruction.rs#L268). +Зауважте, що ATA адреса може ще не існувати, у цьому випадку біржа повинна +профінансувати акаунт від імені користувача. Для акаунтів SPL Token фінансування +акаунта для виведення потребує 0.00203928 SOL (2,039,280 лампортів). Шаблон команди `spl-token transfer` для виведення: @@ -855,31 +1111,54 @@ spl-token transfer --fund-recipient #### Freeze Authority (Замороження Акаунтів) -Для дотримання регуляторних вимог емітент токенів SPL може опціонально мати "Freeze Authority" (повноваження замороження) для всіх акаунтів, створених у зв'язку з його mint. Це дозволяє йому [заморожувати](https://spl.solana.com/token#freezing-accounts) активи в певному акаунті за бажанням, роблячи акаунт недоступним до моменту його розморожування. Якщо ця функція використовується, публічний ключ freeze authority буде зареєстрований у акаунті mint токену SPL. +Для дотримання регуляторних вимог емітент токенів SPL може опціонально мати +"Freeze Authority" (повноваження замороження) для всіх акаунтів, створених у +зв'язку з його mint. Це дозволяє йому +[заморожувати](https://spl.solana.com/token#freezing-accounts) активи в певному +акаунті за бажанням, роблячи акаунт недоступним до моменту його розморожування. +Якщо ця функція використовується, публічний ключ freeze authority буде +зареєстрований у акаунті mint токену SPL. ### Основна Підтримка Стандарту SPL Token-2022 (Token-Extensions) -[SPL Token-2022](https://spl.solana.com/token-2022) є новим стандартом для створення й обміну обгорнутих/синтетичних токенів у блокчейні Solana. +[SPL Token-2022](https://spl.solana.com/token-2022) є новим стандартом для +створення й обміну обгорнутих/синтетичних токенів у блокчейні Solana. -Відомий також як "Token Extensions", цей стандарт включає багато нових функцій, які можуть бути опціонально увімкнені творцями токенів та власниками акаунтів. До таких функцій належать конфіденційні перекази, комісії за переказ, закриття mint, метадані, постійні делегати, незмінна власність тощо. Більше інформації дивіться в [керівництві з розширень](https://spl.solana.com/token-2022/extensions). +Відомий також як "Token Extensions", цей стандарт включає багато нових функцій, +які можуть бути опціонально увімкнені творцями токенів та власниками акаунтів. +До таких функцій належать конфіденційні перекази, комісії за переказ, закриття +mint, метадані, постійні делегати, незмінна власність тощо. Більше інформації +дивіться в +[керівництві з розширень](https://spl.solana.com/token-2022/extensions). -Якщо ваша біржа підтримує SPL Token, багато додаткових зусиль для підтримки SPL Token-2022 не знадобиться: +Якщо ваша біржа підтримує SPL Token, багато додаткових зусиль для підтримки SPL +Token-2022 не знадобиться: -- CLI інструмент безпроблемно працює з обома програмами, починаючи з версії 3.0.0. -- Поля `preTokenBalances` та `postTokenBalances` включають баланси SPL Token-2022. -- RPC індексує акаунти SPL Token-2022, але їх потрібно запитувати окремо за програмним ідентифікатором `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb`. +- CLI інструмент безпроблемно працює з обома програмами, починаючи з версії + 3.0.0. +- Поля `preTokenBalances` та `postTokenBalances` включають баланси SPL + Token-2022. +- RPC індексує акаунти SPL Token-2022, але їх потрібно запитувати окремо за + програмним ідентифікатором `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb`. -Програма Associated Token Account працює так само, і правильно розраховує необхідну суму депозиту SOL для нового акаунта. +Програма Associated Token Account працює так само, і правильно розраховує +необхідну суму депозиту SOL для нового акаунта. -Однак через розширення акаунти можуть бути більшими за 165 байтів, тому вони можуть потребувати більше ніж 0.00203928 SOL для фінансування. +Однак через розширення акаунти можуть бути більшими за 165 байтів, тому вони +можуть потребувати більше ніж 0.00203928 SOL для фінансування. -Наприклад, програма Associated Token Account завжди включає розширення "immutable owner", тому акаунти займають мінімум 170 байтів, що вимагає 0.00207408 SOL. +Наприклад, програма Associated Token Account завжди включає розширення +"immutable owner", тому акаунти займають мінімум 170 байтів, що вимагає +0.00207408 SOL. ### Міркування Щодо Розширень -Попередній розділ описує базову підтримку SPL Token-2022. Оскільки розширення змінюють поведінку токенів, біржам, можливо, доведеться змінити, як вони обробляють токени. +Попередній розділ описує базову підтримку SPL Token-2022. Оскільки розширення +змінюють поведінку токенів, біржам, можливо, доведеться змінити, як вони +обробляють токени. -Можливо побачити всі розширення на mint або токен акаунті за допомогою наступної команди: +Можливо побачити всі розширення на mint або токен акаунті за допомогою наступної +команди: ```shell spl-token display @@ -887,9 +1166,11 @@ spl-token display #### Комісія за Переказ -Токен може бути налаштований з комісією за переказ, при якій частина переданих токенів утримується на адресі отримувача для подальшого стягнення. +Токен може бути налаштований з комісією за переказ, при якій частина переданих +токенів утримується на адресі отримувача для подальшого стягнення. -Якщо ваша біржа здійснює переказ цих токенів, зверніть увагу, що не всі токени можуть надійти на адресу отримувача через утриману суму. +Якщо ваша біржа здійснює переказ цих токенів, зверніть увагу, що не всі токени +можуть надійти на адресу отримувача через утриману суму. Під час переказу можна вказати очікувану комісію, щоб уникнути несподіванок: @@ -899,9 +1180,11 @@ spl-token transfer --expected-fee --fund-recipient #### Конфіденційні Перекази -Mint може бути налаштований для конфіденційних переказів, при яких суми токенів шифруються, але власники акаунтів залишаються публічними. +Mint може бути налаштований для конфіденційних переказів, при яких суми токенів +шифруються, але власники акаунтів залишаються публічними. -Біржі можуть налаштувати токен акаунти для відправлення та отримання конфіденційних переказів, щоб приховати суми користувачів. Увімкнення конфіденційних переказів для токен акаунтів не є обов’язковим, тому біржі можуть змусити користувачів надсилати токени неконфіденційно. +Біржі можуть налаштувати токен акаунти для відправлення та отримання +конфіденційних переказів, щоб приховати суми користувачів. Увімкнення +конфіденційних переказів для токен акаунтів не є обов’язковим, тому біржі можуть +змусити користувачів надсилати токени неконфіденційно. -Щоб увімкнути конфіденційні перекази, акаунт має бути налаштований відповідним чином: +Щоб увімкнути конфіденційні перекази, акаунт має бути налаштований відповідним +чином: ```shell spl-token configure-confidential-transfer-account --address @@ -927,7 +1215,9 @@ spl-token configure-confidential-transfer-account --address spl-token transfer --confidential ``` -Під час конфіденційного переказу поля `preTokenBalance` та `postTokenBalance` не показуватимуть змін. Щоб виконати операцію з депозитними акаунтами, необхідно розшифрувати новий баланс, щоб вивести токени: +Під час конфіденційного переказу поля `preTokenBalance` та `postTokenBalance` не +показуватимуть змін. Щоб виконати операцію з депозитними акаунтами, необхідно +розшифрувати новий баланс, щоб вивести токени: ```shell spl-token apply-pending-balance --address @@ -936,7 +1226,9 @@ spl-token withdraw-confidential-tokens --address --transfer-hook-account ... ``` + #### Обов'язкова Нотатка (Memo) при Переказі -Користувачі можуть налаштувати свої токен акаунти так, щоб перекази вимагали нотатку (memo). +Користувачі можуть налаштувати свої токен акаунти так, щоб перекази вимагали +нотатку (memo). -Біржі можуть додавати інструкцію нотатки перед тим, як переказати токени користувачам, або вимагати, щоб користувачі додавали нотатку перед відправкою токенів на біржу: +Біржі можуть додавати інструкцію нотатки перед тим, як переказати токени +користувачам, або вимагати, щоб користувачі додавали нотатку перед відправкою +токенів на біржу: ```shell spl-token transfer --with-memo ``` -## Тестування Інтеграції -Обов'язково протестуйте весь свій робочий процес у кластерах Solana devnet та testnet [clusters](/docs/uk/core/clusters.md) перед переходом до продакшну на mainnet-beta. Devnet є найбільш відкритим і гнучким, і ідеально підходить для початкової розробки, тоді як testnet пропонує більш реалістичну конфігурацію кластера. Обидва кластери devnet та testnet підтримують faucet. Використовуйте команду `solana airdrop 1`, щоб отримати трохи SOL для devnet або testnet для розробки та тестування. +## Тестування Інтеграції +Обов'язково протестуйте весь свій робочий процес у кластерах Solana devnet та +testnet [clusters](/docs/uk/core/clusters.md) перед переходом до продакшну на +mainnet-beta. Devnet є найбільш відкритим і гнучким, і ідеально підходить для +початкової розробки, тоді як testnet пропонує більш реалістичну конфігурацію +кластера. Обидва кластери devnet та testnet підтримують faucet. Використовуйте +команду `solana airdrop 1`, щоб отримати трохи SOL для devnet або testnet для +розробки та тестування. diff --git a/docs/locales/uk/programs/anchor/client-typescript.md b/docs/locales/uk/programs/anchor/client-typescript.md index 42be6e41c..d53d54e12 100644 --- a/docs/locales/uk/programs/anchor/client-typescript.md +++ b/docs/locales/uk/programs/anchor/client-typescript.md @@ -1,15 +1,16 @@ --- title: JS/TS Client description: - Дізнайтеся, як використовувати клієнтську бібліотеку TypeScript для взаємодії з Solana + Дізнайтеся, як використовувати клієнтську бібліотеку TypeScript для взаємодії + з Solana sidebarLabel: JS/TS Client sidebarSortOrder: 3 --- Anchor надає бібліотеку клієнта TypeScript ([@coral-xyz/anchor](https://github.com/coral-xyz/anchor/tree/v0.30.1/ts/packages/anchor)) -Це спрощує процес взаємодії з програмами Solana від клієнта -у JavaScript або TypeScript. +Це спрощує процес взаємодії з програмами Solana від клієнта у JavaScript або +TypeScript. ## Клієнтська програма @@ -22,15 +23,15 @@ Anchor надає бібліотеку клієнта TypeScript `AnchorProvider` - це абстракція, яка поєднує дві речі: - `Підключення ' - з'єднання з [кластером Solana] (/docs/core/clusters.md) -(тобто localhost, devnet, mainnet) -- `Wallet` - (необов’язково) Гаманець за замовчуванням, який використовується для оплати та підписання транзакцій - - - + (тобто localhost, devnet, mainnet) +- `Wallet` - (необов’язково) Гаманець за замовчуванням, який використовується + для оплати та підписання транзакцій + + -При інтеграції з фронтендом за допомогою -[Адаптер гаманця] (https://solana.com/developers/guides/wallets/add-solana-wallet-adapter-to-nextjs), -Вам потрібно буде налаштувати `AnchorProvider` та `Program`. +При інтеграції з фронтендом за допомогою [Адаптер гаманця] +(https://solana.com/developers/guides/wallets/add-solana-wallet-adapter-to-nextjs), +Вам потрібно буде налаштувати `AnchorProvider` та `Program`. ```ts {9-10, 12-14} import { Program, AnchorProvider, setProvider } from "@coral-xyz/anchor"; @@ -52,13 +53,13 @@ export const program = new Program(idl as HelloAnchor, { У фрагменті коду вище: - `idl.json` - це файл IDL, створений якір, знайдено на -`/target/idl/ .json` в якорі. + `/target/idl/ .json` в якорі. - `idltype.ts` - це тип IDL (для використання з TS), знайдено в -`/target/type/ .ts` в якорі. + `/target/type/ .ts` в якорі. -Крім того, ви можете створити екземпляр, використовуючи лише IDL -і підключення до кластеру солани.Це означає, що немає за замовчуванням -`Wallet`, але дозволяє використовувати` Програму 'для отримання облікових записів або побудувати +Крім того, ви можете створити екземпляр, використовуючи лише IDL і підключення +до кластеру солани.Це означає, що немає за замовчуванням `Wallet`, але дозволяє +використовувати` Програму 'для отримання облікових записів або побудувати Інструкції без підключеного гаманця. ```ts {8-10} @@ -77,9 +78,10 @@ export const program = new Program(idl as HelloAnchor, { -Якір автоматично налаштовує екземпляр `Program` у тестовому файлі за замовчуванням -нові проекти.Однак ця установка відрізняється від того, як ви ініціалізуєте програму -Поза робочою областю якоря, наприклад, у програмах React або Node.js. +Якір автоматично налаштовує екземпляр `Program` у тестовому файлі за +замовчуванням нові проекти.Однак ця установка відрізняється від того, як ви +ініціалізуєте програму Поза робочою областю якоря, наприклад, у програмах React +або Node.js. ```typescript import * as anchor from "@coral-xyz/anchor"; @@ -105,20 +107,23 @@ describe("hello_anchor", () => { ## Виклик інструкцій -Після того як `Program` налаштовано за допомогою програмного IDL, ви можете використовувати якір +Після того як `Program` налаштовано за допомогою програмного IDL, ви можете +використовувати якір [`MethodsBuilder`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/methods.ts#L155) для: + - Створіть окремі інструкції - Будуйте транзакції - Будуйте та надсилайте транзакції Основний формат виглядає як наступне: + -`program.methods` - Це API Builder для створення інструкційних дзвінків з -IDL програми +`program.methods` - Це API Builder для створення інструкційних дзвінків з IDL +програми ```ts /methods/ {1} await program.methods @@ -131,7 +136,8 @@ await program.methods -У розділі `.methods` вказуйте назву інструкції з IDL програми, передаючи будь-які необхідні аргументи як значення, розділені комами. +У розділі `.methods` вказуйте назву інструкції з IDL програми, передаючи +будь-які необхідні аргументи як значення, розділені комами. ```ts /instructionName/ /instructionData1/ /instructionData2/ {2} await program.methods @@ -144,7 +150,8 @@ await program.methods -`.accounts` - Вказуйте адресу облікових записів, необхідних для інструкції, як це зазначено в IDL. +`.accounts` - Вказуйте адресу облікових записів, необхідних для інструкції, як +це зазначено в IDL. ```ts /accounts/ {3} await program.methods @@ -153,7 +160,9 @@ await program.methods .signers([]) .rpc(); ``` -Зверніть увагу, що деякі адреси облікових записів не потрібно вказувати явно, оскільки клієнт Anchor може автоматично їх визначити. Це зазвичай стосується: + +Зверніть увагу, що деякі адреси облікових записів не потрібно вказувати явно, +оскільки клієнт Anchor може автоматично їх визначити. Це зазвичай стосується: - Загальних облікових записів (наприклад, Програма Системи) - Облікових записів, де адреса є PDA (Програма-Походження Адреси) @@ -161,7 +170,10 @@ await program.methods -`.signers` - Необов'язково передайте масив ключових пар, які потрібні як додаткові підписанти для інструкції. Це зазвичай використовується при створенні нових облікових записів, де адреса облікового запису є публічним ключем нещодавно згенерованої ключової пари. +`.signers` - Необов'язково передайте масив ключових пар, які потрібні як +додаткові підписанти для інструкції. Це зазвичай використовується при створенні +нових облікових записів, де адреса облікового запису є публічним ключем +нещодавно згенерованої ключової пари. ```ts /signers/ {4} await program.methods @@ -171,7 +183,9 @@ await program.methods .rpc(); ``` -Зверніть увагу, що `.signers` слід використовувати тільки при використанні `.rpc()`. Коли ви використовуєте `.transaction()` або `.instruction()`, підписанти повинні бути додані до транзакції перед її відправкою. +Зверніть увагу, що `.signers` слід використовувати тільки при використанні +`.rpc()`. Коли ви використовуєте `.transaction()` або `.instruction()`, +підписанти повинні бути додані до транзакції перед її відправкою. @@ -182,11 +196,13 @@ Anchor надає кілька методів для створення інст -Метод [`rpc()`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/methods.ts#L283) +Метод +[`rpc()`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/methods.ts#L283) [відправляє підписану транзакцію](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/rpc.ts#L29) з вказаною інструкцією та повертає `TransactionSignature`. -При використанні `.rpc` гаманець з `Provider` автоматично додається як підписант. +При використанні `.rpc` гаманець з `Provider` автоматично додається як +підписант. ```ts {13} // Generate keypair for the new account @@ -207,7 +223,8 @@ const transactionSignature = await program.methods -Метод [`transaction()`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/methods.ts#L382) +Метод +[`transaction()`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/methods.ts#L382) [створює `Transaction`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/transaction.ts#L18-L26) з вказаною інструкцією без відправки транзакції. @@ -234,9 +251,11 @@ const transactionSignature = await connection.sendTransaction(transaction, [ -Метод [`instruction()`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/methods.ts#L348) +Метод +[`instruction()`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/methods.ts#L348) [створює `TransactionInstruction`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/instruction.ts#L57-L61) -з вказаною інструкцією. Це корисно, якщо ви хочете вручну додати інструкцію до транзакції та поєднати її з іншими інструкціями. +з вказаною інструкцією. Це корисно, якщо ви хочете вручну додати інструкцію до +транзакції та поєднати її з іншими інструкціями. ```ts {12} /instruction()/ // Generate keypair for the new account @@ -265,16 +284,20 @@ const transactionSignature = await connection.sendTransaction(transaction, [ ## Отримання облікових записів -Клієнт `Program` спрощує процес отримання та десеріалізації облікових записів, створених вашою програмою Anchor. +Клієнт `Program` спрощує процес отримання та десеріалізації облікових записів, +створених вашою програмою Anchor. -Використовуйте `program.account`, за яким слідує назва типу облікового запису, визначеного в IDL. Anchor надає кілька методів для отримання облікових записів. +Використовуйте `program.account`, за яким слідує назва типу облікового запису, +визначеного в IDL. Anchor надає кілька методів для отримання облікових записів. -Використовуйте [`all()`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/account.ts#L251) -для отримання всіх існуючих облікових записів для конкретного типу облікового запису. +Використовуйте +[`all()`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/account.ts#L251) +для отримання всіх існуючих облікових записів для конкретного типу облікового +запису. ```ts /all/ const accounts = await program.account.newAccount.all(); @@ -283,9 +306,13 @@ const accounts = await program.account.newAccount.all(); -Використовуйте `memcmp` (порівняння пам'яті) для фільтрації облікових записів, дані яких відповідають конкретному значенню на вказаному зсуві. Для використання `memcmp` необхідно розуміти байтову структуру поля даних для типу облікового запису, який ви отримуєте. +Використовуйте `memcmp` (порівняння пам'яті) для фільтрації облікових записів, +дані яких відповідають конкретному значенню на вказаному зсуві. Для використання +`memcmp` необхідно розуміти байтову структуру поля даних для типу облікового +запису, який ви отримуєте. -При обчисленні зсуву пам'ятайте, що перші 8 байтів у облікових записах, створених програмою Anchor, зарезервовані для дискримінатора облікового запису. +При обчисленні зсуву пам'ятайте, що перші 8 байтів у облікових записах, +створених програмою Anchor, зарезервовані для дискримінатора облікового запису. ```ts /memcmp/ const accounts = await program.account.newAccount.all([ @@ -301,7 +328,8 @@ const accounts = await program.account.newAccount.all([ -Використовуйте [`fetch()`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/account.ts#L165) +Використовуйте +[`fetch()`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/account.ts#L165) для отримання даних облікового запису для одного облікового запису. ```ts /fetch/ @@ -311,8 +339,10 @@ const account = await program.account.newAccount.fetch(ACCOUNT_ADDRESS); -Використовуйте [`fetchMultiple()`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/account.ts#L200) -для отримання даних облікових записів для кількох облікових записів, передавши масив адрес облікових записів. +Використовуйте +[`fetchMultiple()`](https://github.com/coral-xyz/anchor/blob/v0.30.1/ts/packages/anchor/src/program/namespace/account.ts#L200) +для отримання даних облікових записів для кількох облікових записів, передавши +масив адрес облікових записів. ```ts /fetchMultiple/ const accounts = await program.account.newAccount.fetchMultiple([ diff --git a/docs/locales/uk/programs/anchor/cpi.md b/docs/locales/uk/programs/anchor/cpi.md index 4e725d555..311a1444f 100644 --- a/docs/locales/uk/programs/anchor/cpi.md +++ b/docs/locales/uk/programs/anchor/cpi.md @@ -1,29 +1,30 @@ --- title: CPIs з Anchor description: - Дізнайтеся, як реалізувати Cross Program Invocations (CPI) в програмах на Anchor, - що дозволяє взаємодіяти між різними програмами на Solana + Дізнайтеся, як реалізувати Cross Program Invocations (CPI) в програмах на + Anchor, що дозволяє взаємодіяти між різними програмами на Solana sidebarLabel: CPIs з Anchor sidebarSortOrder: 5 --- [Cross Program Invocations (CPI)](/docs/core/cpi.md) означають процес, коли одна -програма викликає інструкції іншої програми, що дозволяє здійснювати композицію програм на Solana. +програма викликає інструкції іншої програми, що дозволяє здійснювати композицію +програм на Solana. -Цей розділ охоплює основи реалізації CPIs в програмі Anchor, -використовуючи інструкцію простого переказу SOL як практичний приклад. Після того, як ви -зрозумієте основи реалізації CPI, ви зможете застосувати ці ж концепції -для будь-якої інструкції. +Цей розділ охоплює основи реалізації CPIs в програмі Anchor, використовуючи +інструкцію простого переказу SOL як практичний приклад. Після того, як ви +зрозумієте основи реалізації CPI, ви зможете застосувати ці ж концепції для +будь-якої інструкції. ## Cross Program Invocations -Розглянемо програму, яка реалізує CPI для інструкції переказу в System Program. Ось приклад програми на +Розглянемо програму, яка реалізує CPI для інструкції переказу в System Program. +Ось приклад програми на [Solana Playground](https://beta.solpg.io/66df2751cffcf4b13384d35a). Файл `lib.rs` містить одну інструкцію `sol_transfer`. Коли інструкція -`sol_transfer` в програмі Anchor викликається, програма -внутрішньо викликає інструкцію переказу з System Program. - +`sol_transfer` в програмі Anchor викликається, програма внутрішньо викликає +інструкцію переказу з System Program. ```rs filename="lib.rs" /sol_transfer/ /transfer/ {23} use anchor_lang::prelude::*; @@ -63,8 +64,8 @@ pub struct SolTransfer<'info> { } ``` -Файл `cpi.test.ts` показує, як викликати інструкцію `sol_transfer` програми Anchor і реєструє посилання на деталі транзакції на SolanaFM. - +Файл `cpi.test.ts` показує, як викликати інструкцію `sol_transfer` програми +Anchor і реєструє посилання на деталі транзакції на SolanaFM. ```ts filename="cpi.test.ts" it("SOL Transfer Anchor", async () => { @@ -83,29 +84,30 @@ it("SOL Transfer Anchor", async () => { }); ``` -Ви можете побудувати, розгорнути та запустити тест для цього прикладу на Playground, щоб переглянути -деталі транзакції на [SolanaFM explorer](https://solana.fm/). +Ви можете побудувати, розгорнути та запустити тест для цього прикладу на +Playground, щоб переглянути деталі транзакції на +[SolanaFM explorer](https://solana.fm/). Деталі транзакції покажуть, що спочатку була викликана програма Anchor -(інструкція 1), яка потім викликає System Program (інструкція 1.1), -що призводить до успішного переказу SOL. +(інструкція 1), яка потім викликає System Program (інструкція 1.1), що +призводить до успішного переказу SOL. ![Деталі транзакції](/assets/docs/core/cpi/transaction-details.png) ### Пояснення прикладу 1 -Реалізація CPI слідує такому ж шаблону, як і створення інструкції для додавання в -транзакцію. Коли реалізуємо CPI, потрібно вказати ID програми, -рахунки та дані інструкції для викликаної інструкції. +Реалізація CPI слідує такому ж шаблону, як і створення інструкції для додавання +в транзакцію. Коли реалізуємо CPI, потрібно вказати ID програми, рахунки та дані +інструкції для викликаної інструкції. Інструкція переказу в System Program вимагає два рахунки: - `from`: Рахунок, що надсилає SOL. - `to`: Рахунок, що отримує SOL. -У прикладній програмі структура `SolTransfer` вказує рахунки, необхідні -для інструкції переказу. System Program також включена, оскільки CPI -викликає System Program. +У прикладній програмі структура `SolTransfer` вказує рахунки, необхідні для +інструкції переказу. System Program також включена, оскільки CPI викликає System +Program. ```rust /sender/ /recipient/ /system_program/ #[derive(Accounts)] @@ -127,13 +129,13 @@ CPI. -Інструкція `sol_transfer`, включена в прикладний код, показує типовий -підхід до побудови CPIs за допомогою фреймворку Anchor. +Інструкція `sol_transfer`, включена в прикладний код, показує типовий підхід до +побудови CPIs за допомогою фреймворку Anchor. Цей підхід передбачає створення [`CpiContext`](https://docs.rs/anchor-lang/latest/anchor_lang/context/struct.CpiContext.html), -який містить `program_id` та рахунки, необхідні для викликаної інструкції, а також допоміжну функцію (`transfer`) для виклику конкретної -інструкції. +який містить `program_id` та рахунки, необхідні для викликаної інструкції, а +також допоміжну функцію (`transfer`) для виклику конкретної інструкції. ```rust use anchor_lang::system_program::{transfer, Transfer}; @@ -158,8 +160,8 @@ pub fn sol_transfer(ctx: Context, amount: u64) -> Result<()> { } ``` -Змінна `cpi_context` вказує ID програми (System Program) та -рахунки (відправник і отримувач), необхідні для інструкції переказу. +Змінна `cpi_context` вказує ID програми (System Program) та рахунки (відправник +і отримувач), необхідні для інструкції переказу. ```rust /program_id/ /from_pubkey/ /to_pubkey/ let cpi_context = CpiContext::new( @@ -171,8 +173,8 @@ let cpi_context = CpiContext::new( ); ``` -Змінні `cpi_context` та `amount` передаються в функцію `transfer` для -виконання CPI, що викликає інструкцію переказу з System Program. +Змінні `cpi_context` та `amount` передаються в функцію `transfer` для виконання +CPI, що викликає інструкцію переказу з System Program. ```rust transfer(cpi_context, amount)?; @@ -181,12 +183,13 @@ transfer(cpi_context, amount)?; -Цей приклад показує інший підхід до реалізації CPI за допомогою функції `invoke` та +Цей приклад показує інший підхід до реалізації CPI за допомогою функції `invoke` +та [`system_instruction::transfer`](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/system_instruction.rs#L881), що зазвичай використовується в рідних програмах на Rust. -Під капотом попередній приклад є абстракцією цієї реалізації. -Нижче наведений приклад є функціонально еквівалентним попередньому. +Під капотом попередній приклад є абстракцією цієї реалізації. Нижче наведений +приклад є функціонально еквівалентним попередньому. ```rust use anchor_lang::solana_program::{program::invoke, system_instruction}; @@ -209,11 +212,13 @@ pub fn sol_transfer(ctx: Context, amount: u64) -> Result<()> { -Ви також можете вручну створити інструкцію для передачі в функцію `invoke()`. -Це корисно, коли немає доступної бібліотеки, що допомагає побудувати -інструкцію, яку ви хочете викликати. Цей підхід вимагає вказати `AccountMeta` для інструкції та правильно створити буфер даних інструкції. +Ви також можете вручну створити інструкцію для передачі в функцію `invoke()`. Це +корисно, коли немає доступної бібліотеки, що допомагає побудувати інструкцію, +яку ви хочете викликати. Цей підхід вимагає вказати `AccountMeta` для інструкції +та правильно створити буфер даних інструкції. -Інструкція `sol_transfer` нижче є вручну реалізованим CPI для інструкції переказу в System Program. +Інструкція `sol_transfer` нижче є вручну реалізованим CPI для інструкції +переказу в System Program. ```rust /instruction/10,13 {28} pub fn sol_transfer(ctx: Context, amount: u64) -> Result<()> { @@ -249,13 +254,13 @@ pub fn sol_transfer(ctx: Context, amount: u64) -> Result<()> { ``` Інструкція `sol_transfer` вище повторює цей -[приклад](/docs/core/transactions.md#manual-sol-transfer) вручну побудованої інструкції переказу SOL. Вона слідує тому ж шаблону, що і створення +[приклад](/docs/core/transactions.md#manual-sol-transfer) вручну побудованої +інструкції переказу SOL. Вона слідує тому ж шаблону, що і створення [інструкції](/docs/core/transactions.md#instruction) для додавання в транзакцію. При створенні інструкції на Rust використовуйте наступний синтаксис для вказівки `AccountMeta` для кожного рахунку: - ```rust AccountMeta::new(account1_pubkey, true), // writable, signer AccountMeta::new(account2_pubkey, false), // writable, not signer @@ -272,12 +277,13 @@ AccountMeta::new_readonly(account4_pubkey, true), // writable, signer ## Cross Program Invocations з PDA підписами -Далі розглянемо програму, яка реалізує CPI для інструкції переказу в System Program, де відправником є Програма Походження Адреси (PDA), для якої програма повинна "підписати" транзакцію. Ось приклад програми на +Далі розглянемо програму, яка реалізує CPI для інструкції переказу в System +Program, де відправником є Програма Походження Адреси (PDA), для якої програма +повинна "підписати" транзакцію. Ось приклад програми на [Solana Playground](https://beta.solpg.io/66df2bd2cffcf4b13384d35b). Файл `lib.rs` містить наступну програму з єдиною інструкцією `sol_transfer`. - ```rust filename="lib.rs" use anchor_lang::prelude::*; use anchor_lang::system_program::{transfer, Transfer}; @@ -325,11 +331,11 @@ pub struct SolTransfer<'info> { } ``` -Файл `cpi.test.ts` показує, як викликати інструкцію `sol_transfer` програми Anchor і реєструє посилання на деталі транзакції на SolanaFM. +Файл `cpi.test.ts` показує, як викликати інструкцію `sol_transfer` програми +Anchor і реєструє посилання на деталі транзакції на SolanaFM. Він показує, як отримати PDA за допомогою насіння, вказаного в програмі: - ```ts /pda/ /wallet.publicKey/ const [PDA] = PublicKey.findProgramAddressSync( [Buffer.from("pda"), wallet.publicKey.toBuffer()], @@ -337,8 +343,8 @@ const [PDA] = PublicKey.findProgramAddressSync( ); ``` -Першим кроком у цьому прикладі є фінансування рахунку PDA за допомогою простого переказу SOL з гаманця Playground. - +Першим кроком у цьому прикладі є фінансування рахунку PDA за допомогою простого +переказу SOL з гаманця Playground. ```ts filename="cpi.test.ts" it("Fund PDA with SOL", async () => { @@ -364,8 +370,8 @@ it("Fund PDA with SOL", async () => { ``` Коли PDA буде фінансовано SOL, викликається інструкція `sol_transfer`. Ця -інструкція переказує SOL з рахунку PDA назад на рахунок `wallet` через -CPI до System Program, що "підписується" програмою. +інструкція переказує SOL з рахунку PDA назад на рахунок `wallet` через CPI до +System Program, що "підписується" програмою. ```ts it("SOL Transfer with PDA signer", async () => { @@ -383,12 +389,12 @@ it("SOL Transfer with PDA signer", async () => { }); ``` -Ви можете побудувати, розгорнути та запустити тест, щоб переглянути деталі транзакції на -[SolanaFM explorer](https://solana.fm/). +Ви можете побудувати, розгорнути та запустити тест, щоб переглянути деталі +транзакції на [SolanaFM explorer](https://solana.fm/). Деталі транзакції покажуть, що спочатку була викликана користувацька програма -(інструкція 1), яка потім викликає System Program (інструкція 1.1), -що призводить до успішного переказу SOL. +(інструкція 1), яка потім викликає System Program (інструкція 1.1), що +призводить до успішного переказу SOL. ![Деталі транзакції](/assets/docs/core/cpi/transaction-details-pda.png) @@ -397,10 +403,10 @@ it("SOL Transfer with PDA signer", async () => { У прикладному коді структура `SolTransfer` вказує рахунки, необхідні для інструкції переказу. -Відправником є PDA, для якого програма повинна підписати транзакцію. `seeds`, які використовуються для отримання -адреси для `pda_account`, включають зашитий рядок "pda" та адресу -рахунку `recipient`. Це означає, що адреса для `pda_account` є -унікальною для кожного `recipient`. +Відправником є PDA, для якого програма повинна підписати транзакцію. `seeds`, +які використовуються для отримання адреси для `pda_account`, включають зашитий +рядок "pda" та адресу рахунку `recipient`. Це означає, що адреса для +`pda_account` є унікальною для кожного `recipient`. ```rust /pda_account/ /recipient/2 /system_program/ #[derive(Accounts)] @@ -425,6 +431,7 @@ const [PDA] = PublicKey.findProgramAddressSync( program.programId, ); ``` + Наступні вкладки представляють два підходи до реалізації Cross Program Invocations (CPI), кожен з яких має різний рівень абстракції. Обидва приклади є функціонально еквівалентними. Основною метою є ілюстрація деталей реалізації @@ -434,13 +441,13 @@ CPI. -Інструкція `sol_transfer`, включена в прикладний код, показує типовий -підхід до побудови CPIs за допомогою фреймворку Anchor. +Інструкція `sol_transfer`, включена в прикладний код, показує типовий підхід до +побудови CPIs за допомогою фреймворку Anchor. Цей підхід передбачає створення [`CpiContext`](https://docs.rs/anchor-lang/latest/anchor_lang/context/struct.CpiContext.html), -який містить `program_id` та рахунки, необхідні для викликаної інструкції, а також допоміжну функцію (`transfer`) для виклику конкретної -інструкції. +який містить `program_id` та рахунки, необхідні для викликаної інструкції, а +також допоміжну функцію (`transfer`) для виклику конкретної інструкції. ```rust /cpi_context/ {19} pub fn sol_transfer(ctx: Context, amount: u64) -> Result<()> { @@ -485,9 +492,8 @@ let cpi_context = CpiContext::new( .with_signer(signer_seeds); ``` -Змінні `cpi_context` та `amount` передаються в функцію `transfer` для -виконання CPI. - +Змінні `cpi_context` та `amount` передаються в функцію `transfer` для виконання +CPI. ```rust transfer(cpi_context, amount)?; @@ -495,19 +501,19 @@ transfer(cpi_context, amount)?; Коли обробляється CPI, середовище виконання Solana перевіряє, чи правильно наведені насіння та ID програми викликача для отримання дійсного PDA. Потім PDA -додається як підписант під час виклику. Цей механізм дозволяє програмам підписувати PDA, -які отримані з їхнього ID програми. +додається як підписант під час виклику. Цей механізм дозволяє програмам +підписувати PDA, які отримані з їхнього ID програми. -Під капотом попередній приклад є обгорткою для функції `invoke_signed()`, -яка використовує +Під капотом попередній приклад є обгорткою для функції `invoke_signed()`, яка +використовує [`system_instruction::transfer`](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/system_instruction.rs#L881) для побудови інструкції. -Цей приклад показує, як використовувати функцію `invoke_signed()`, щоб зробити CPI -підписаним PDA. +Цей приклад показує, як використовувати функцію `invoke_signed()`, щоб зробити +CPI підписаним PDA. ```rust use anchor_lang::solana_program::{program::invoke_signed, system_instruction}; @@ -530,8 +536,9 @@ pub fn sol_transfer(ctx: Context, amount: u64) -> Result<()> { Ok(()) } ``` -Ця реалізація функціонально еквівалентна попередньому прикладу. -`signer_seeds` передаються в функцію `invoke_signed`. + +Ця реалізація функціонально еквівалентна попередньому прикладу. `signer_seeds` +передаються в функцію `invoke_signed`. diff --git a/docs/locales/uk/programs/anchor/idl.md b/docs/locales/uk/programs/anchor/idl.md index 1f4024f89..080f030d6 100644 --- a/docs/locales/uk/programs/anchor/idl.md +++ b/docs/locales/uk/programs/anchor/idl.md @@ -7,19 +7,22 @@ sidebarLabel: Файл IDL sidebarSortOrder: 2 --- -Файл Interface Definition Language (IDL) надає стандартизований JSON-файл, -який описує інструкції та рахунки програми. Цей файл спрощує процес інтеграції -вашої програми на блокчейні з клієнтськими додатками. +Файл Interface Definition Language (IDL) надає стандартизований JSON-файл, який +описує інструкції та рахунки програми. Цей файл спрощує процес інтеграції вашої +програми на блокчейні з клієнтськими додатками. Основні переваги IDL: -- Стандартизація: Надає послідовний формат для опису інструкцій та рахунків програми -- Генерація клієнта: Використовується для генерації коду клієнта для взаємодії з програмою +- Стандартизація: Надає послідовний формат для опису інструкцій та рахунків + програми +- Генерація клієнта: Використовується для генерації коду клієнта для взаємодії з + програмою Команда `anchor build` генерує файл IDL, який знаходиться за адресою `/target/idl/.json`. -Нижче наведені фрагменти коду, що показують, як програма, IDL та клієнт взаємопов'язані. +Нижче наведені фрагменти коду, що показують, як програма, IDL та клієнт +взаємопов'язані. ## Інструкції програми @@ -31,8 +34,8 @@ sidebarSortOrder: 2 -Наведена програма включає інструкцію `initialize`, що вказує на рахунки -та параметри, які вона потребує. +Наведена програма включає інструкцію `initialize`, що вказує на рахунки та +параметри, які вона потребує. ```rust {8-12, 15-22} use anchor_lang::prelude::*; @@ -181,17 +184,16 @@ describe("hello_anchor", () => { ## Рахунки програми -Масив `accounts` у файлі IDL відповідає структурам у програмі, -позначеним макросом `#[account]`. Ці структури визначають дані, які зберігаються в +Масив `accounts` у файлі IDL відповідає структурам у програмі, позначеним +макросом `#[account]`. Ці структури визначають дані, які зберігаються в рахунках, створених програмою. -Наведена програма визначає структуру `NewAccount` з одним полем `data` -типу `u64`. - +Наведена програма визначає структуру `NewAccount` з одним полем `data` типу +`u64`. ```rust {24-27} use anchor_lang::prelude::*; @@ -229,7 +231,6 @@ pub struct NewAccount { Згенерований файл IDL включає рахунок у стандартизованому форматі JSON, включаючи його ім'я, дискримінатор та поля. - ```json filename="JSON" {39-40, 45-54} { "address": "BYFW1vhC1ohxwRbYoLbAWs86STa25i9sD5uEusVjTYNd", @@ -341,23 +342,27 @@ describe("hello_anchor", () => { ## Дискримінатори -Anchor призначає унікальний 8-байтовий дискримінатор для кожної інструкції та типу рахунку в програмі. Ці дискримінатори служать як ідентифікатори для відрізнення різних інструкцій або типів рахунків. +Anchor призначає унікальний 8-байтовий дискримінатор для кожної інструкції та +типу рахунку в програмі. Ці дискримінатори служать як ідентифікатори для +відрізнення різних інструкцій або типів рахунків. -Дискримінатор генерується за допомогою перших 8 байтів хешу Sha256 префікса, поєднаного з ім'ям інструкції або рахунку. Починаючи з версії Anchor v0.30, ці дискримінатори включені в файл IDL. +Дискримінатор генерується за допомогою перших 8 байтів хешу Sha256 префікса, +поєднаного з ім'ям інструкції або рахунку. Починаючи з версії Anchor v0.30, ці +дискримінатори включені в файл IDL. Зверніть увагу, що при роботі з Anchor, вам зазвичай не потрібно взаємодіяти -безпосередньо з цими дискримінаторами. Цей розділ надає контекст щодо того, -як генерується і використовується дискримінатор. +безпосередньо з цими дискримінаторами. Цей розділ надає контекст щодо того, як +генерується і використовується дискримінатор. -Дискримінатор інструкції використовується програмою для визначення, яку конкретну -інструкцію виконати при виклику. +Дискримінатор інструкції використовується програмою для визначення, яку +конкретну інструкцію виконати при виклику. -Коли інструкція програми Anchor викликається, дискримінатор включається як -перші 8 байтів даних інструкції. Це робиться автоматично клієнтом Anchor. +Коли інструкція програми Anchor викликається, дискримінатор включається як перші +8 байтів даних інструкції. Це робиться автоматично клієнтом Anchor. ```json filename="IDL" {4} "instructions": [ @@ -369,7 +374,8 @@ Anchor призначає унікальний 8-байтовий дискрим ] ``` -Дискримінатор для інструкції — це перші 8 байтів хешу Sha256 префікса `global` плюс ім'я інструкції. +Дискримінатор для інструкції — це перші 8 байтів хешу Sha256 префікса `global` +плюс ім'я інструкції. Наприклад: @@ -404,8 +410,9 @@ ed = 237 -Дискримінатор рахунку використовується для ідентифікації конкретного типу рахунку при -десеріалізації даних з ланцюга та встановлюється при створенні рахунку. +Дискримінатор рахунку використовується для ідентифікації конкретного типу +рахунку при десеріалізації даних з ланцюга та встановлюється при створенні +рахунку. ```json filename="IDL" {4} "accounts": [ @@ -416,11 +423,11 @@ ed = 237 ] ``` -Дискримінатор для рахунку — це перші 8 байтів хешу Sha256 префікса `account` плюс ім'я рахунку. +Дискримінатор для рахунку — це перші 8 байтів хешу Sha256 префікса `account` +плюс ім'я рахунку. Наприклад: - ``` sha256("account:NewAccount") ``` @@ -447,13 +454,16 @@ e8 = 232 Реалізацію генерації дискримінатора ви можете знайти в кодовій базі Anchor [тут](https://github.com/coral-xyz/anchor/blob/v0.30.1/lang/attribute/account/src/lib.rs#L101-L117). -Зверніть увагу, що різні програми, які використовують однакові імена рахунків, генеруватимуть той самий дискримінатор. При десеріалізації даних рахунків програми Anchor також перевірятимуть, що рахунок належить очікуваній програмі для заданого типу рахунку. +Зверніть увагу, що різні програми, які використовують однакові імена рахунків, +генеруватимуть той самий дискримінатор. При десеріалізації даних рахунків +програми Anchor також перевірятимуть, що рахунок належить очікуваній програмі +для заданого типу рахунку. -Дискримінатор події використовується для ідентифікації конкретного типу події при -десеріалізації даних з ланцюга при емісії події. +Дискримінатор події використовується для ідентифікації конкретного типу події +при десеріалізації даних з ланцюга при емісії події. ```json filename="IDL" {4} "events": [ @@ -464,7 +474,8 @@ e8 = 232 ] ``` -Дискримінатор для події — це перші 8 байтів хешу Sha256 префікса `event` плюс ім'я події. +Дискримінатор для події — це перші 8 байтів хешу Sha256 префікса `event` плюс +ім'я події. Наприклад: @@ -496,9 +507,10 @@ c9 = 201 Реалізацію генерації дискримінатора ви можете знайти в кодовій базі Anchor [тут](https://github.com/coral-xyz/anchor/blob/v0.30.1/lang/attribute/event/src/lib.rs#L23-L27). -Зверніть увагу, що різні програми, які використовують однакові імена подій, генеруватимуть той самий -дискримінатор. При десеріалізації даних подій програми Anchor також перевірятимуть, що -подія належить очікуваній програмі для заданого типу події. +Зверніть увагу, що різні програми, які використовують однакові імена подій, +генеруватимуть той самий дискримінатор. При десеріалізації даних подій програми +Anchor також перевірятимуть, що подія належить очікуваній програмі для заданого +типу події. - \ No newline at end of file + diff --git a/docs/locales/uk/programs/anchor/index.md b/docs/locales/uk/programs/anchor/index.md index 35be0c546..169686979 100644 --- a/docs/locales/uk/programs/anchor/index.md +++ b/docs/locales/uk/programs/anchor/index.md @@ -1,8 +1,9 @@ --- title: Початок роботи з Anchor description: - Дізнайтесь, як будувати програми для Solana за допомогою фреймворку Anchor. Цей - детальний посібник охоплює створення, збірку, тестування та розгортання смарт-контрактів Solana з використанням Anchor. + Дізнайтесь, як будувати програми для Solana за допомогою фреймворку Anchor. + Цей детальний посібник охоплює створення, збірку, тестування та розгортання + смарт-контрактів Solana з використанням Anchor. sidebarLabel: Фреймворк Anchor sidebarSortOrder: 0 altRoutes: @@ -11,9 +12,9 @@ altRoutes: - /docs/programs/overview --- -Фреймворк Anchor — це інструмент, який спрощує процес створення програм для Solana. -Неважливо, чи ви новачок у блокчейн-розробці, чи досвідчений програміст, Anchor спрощує процес написання, тестування та розгортання -програм для Solana. +Фреймворк Anchor — це інструмент, який спрощує процес створення програм для +Solana. Неважливо, чи ви новачок у блокчейн-розробці, чи досвідчений програміст, +Anchor спрощує процес написання, тестування та розгортання програм для Solana. У цьому розділі ми розглянемо: @@ -35,7 +36,6 @@ altRoutes: Щоб перевірити встановлення Anchor CLI, відкрийте термінал і виконайте: - ```shell filename="Terminal" anchor --version ``` @@ -48,13 +48,16 @@ anchor-cli 0.30.1 ## Початок роботи -Цей розділ охоплює основні кроки для створення, зборки та тестування вашої першої локальної програми на Anchor. +Цей розділ охоплює основні кроки для створення, зборки та тестування вашої +першої локальної програми на Anchor. ### Створення нового проекту -Щоб почати новий проект, використовуйте команду `anchor init`, після якої вкажіть назву вашого проекту. Ця команда створює нову директорію з вказаним ім'ям і налаштовує стандартну програму та тестовий файл. +Щоб почати новий проект, використовуйте команду `anchor init`, після якої +вкажіть назву вашого проекту. Ця команда створює нову директорію з вказаним +ім'ям і налаштовує стандартну програму та тестовий файл. ```shell filename="Terminal" anchor init my-project @@ -66,7 +69,8 @@ anchor init my-project cd my-project ``` -Стандартна програма Anchor знаходиться за адресою `programs/my-project/src/lib.rs`. +Стандартна програма Anchor знаходиться за адресою +`programs/my-project/src/lib.rs`. @@ -99,13 +103,14 @@ pub struct Initialize {} -Стандартний тестовий файл TypeScript знаходиться за адресою `/tests/my-project.ts`. +Стандартний тестовий файл TypeScript знаходиться за адресою +`/tests/my-project.ts`. -Цей файл демонструє, як викликати інструкцію `initialize` стандартної програми в TypeScript. - +Цей файл демонструє, як викликати інструкцію `initialize` стандартної програми в +TypeScript. ```ts filename="my-project.ts" import * as anchor from "@coral-xyz/anchor"; @@ -129,8 +134,8 @@ describe("my-project", () => { -Якщо ви віддаєте перевагу Rust для тестування, ініціалізуйте свій проект за допомогою прапорця -`--test-template rust`. +Якщо ви віддаєте перевагу Rust для тестування, ініціалізуйте свій проект за +допомогою прапорця `--test-template rust`. ```shell anchor init --test-template rust my-project @@ -183,9 +188,9 @@ fn test_initialize() { anchor build ``` -Зкомпільована програма буде знаходитися за адресою `/target/deploy/my_project.so`. Вміст -цього файлу буде збережено в мережі Solana (як виконуваний акаунт) -під час розгортання вашої програми. +Зкомпільована програма буде знаходитися за адресою +`/target/deploy/my_project.so`. Вміст цього файлу буде збережено в мережі Solana +(як виконуваний акаунт) під час розгортання вашої програми. ### Тестування програми @@ -195,24 +200,31 @@ anchor build anchor test ``` -За замовчуванням конфігураційний файл `Anchor.toml` вказує на кластер `localnet`. При розробці на `localnet`, команда `anchor test` автоматично: +За замовчуванням конфігураційний файл `Anchor.toml` вказує на кластер +`localnet`. При розробці на `localnet`, команда `anchor test` автоматично: 1. Запускає локальний валідатор Solana 2. Створює та розгортає вашу програму на локальному кластері 3. Виконує тести з папки `tests` 4. Зупиняє локальний валідатор Solana -Альтернативно, ви можете вручну запустити локальний валідатор Solana та виконувати тести проти нього. Це корисно, якщо ви хочете, щоб валідатор працював, поки ви працюєте над програмою. Це дозволяє вам перевіряти акаунти та журнали транзакцій на [Solana Explorer](https://explorer.solana.com/?cluster=custom) під час розробки локально. +Альтернативно, ви можете вручну запустити локальний валідатор Solana та +виконувати тести проти нього. Це корисно, якщо ви хочете, щоб валідатор +працював, поки ви працюєте над програмою. Це дозволяє вам перевіряти акаунти та +журнали транзакцій на +[Solana Explorer](https://explorer.solana.com/?cluster=custom) під час розробки +локально. -Відкрийте новий термінал і запустіть локальний валідатор Solana, виконуючи команду -`solana-test-validator`. +Відкрийте новий термінал і запустіть локальний валідатор Solana, виконуючи +команду `solana-test-validator`. ```shell filename="Terminal" copy solana-test-validator ``` -У окремому терміналі виконайте тести проти локального кластера. Використовуйте прапорець -`--skip-local-validator`, щоб пропустити запуск локального валідатора, оскільки він уже працює. +У окремому терміналі виконайте тести проти локального кластера. Використовуйте +прапорець `--skip-local-validator`, щоб пропустити запуск локального валідатора, +оскільки він уже працює. ```shell filename="Terminal" copy anchor test --skip-local-validator @@ -220,7 +232,8 @@ anchor test --skip-local-validator ### Розгортання на Devnet -За замовчуванням конфігураційний файл `Anchor.toml` у проекті Anchor вказує на кластер localnet. +За замовчуванням конфігураційний файл `Anchor.toml` у проекті Anchor вказує на +кластер localnet. ```toml filename="Anchor.toml" {14} [toolchain] @@ -243,7 +256,9 @@ wallet = "~/.config/solana/id.json" test = "yarn run ts-mocha -p ./tsconfig.json -t 1000000 tests/**/*.ts" ``` -Щоб розгорнути вашу програму на devnet, змініть значення `cluster` на `Devnet`. Зверніть увагу, що для цього ваш гаманець повинен мати достатньо SOL на Devnet для покриття вартості розгортання. +Щоб розгорнути вашу програму на devnet, змініть значення `cluster` на `Devnet`. +Зверніть увагу, що для цього ваш гаманець повинен мати достатньо SOL на Devnet +для покриття вартості розгортання. ```diff -cluster = "Localnet" @@ -256,13 +271,16 @@ cluster = "Devnet" wallet = "~/.config/solana/id.json" ``` -Тепер, коли ви виконаєте команду `anchor deploy`, ваша програма буде розгорнута на кластері devnet. Команда `anchor test` також використовуватиме кластер, вказаний у файлі `Anchor.toml`. +Тепер, коли ви виконаєте команду `anchor deploy`, ваша програма буде розгорнута +на кластері devnet. Команда `anchor test` також використовуватиме кластер, +вказаний у файлі `Anchor.toml`. ```shell anchor deploy ``` -Щоб розгорнути на mainnet, просто оновіть файл `Anchor.toml`, вказавши кластер mainnet. +Щоб розгорнути на mainnet, просто оновіть файл `Anchor.toml`, вказавши кластер +mainnet. ```toml filename="Anchor.toml" [provider] @@ -272,17 +290,18 @@ wallet = "~/.config/solana/id.json" ### Оновлення програми -Програми Solana можна оновити, повторно розгорнувши програму з тим самим ID програми. - -Щоб оновити програму, просто внесіть зміни в код вашої програми і виконайте команду -`anchor build` для генерації оновленого файлу `.so`. +Програми Solana можна оновити, повторно розгорнувши програму з тим самим ID +програми. +Щоб оновити програму, просто внесіть зміни в код вашої програми і виконайте +команду `anchor build` для генерації оновленого файлу `.so`. ```shell anchor build ``` -Потім виконайте команду `anchor deploy`, щоб повторно розгорнути оновлену програму. +Потім виконайте команду `anchor deploy`, щоб повторно розгорнути оновлену +програму. ```shell anchor deploy @@ -290,15 +309,18 @@ anchor deploy ### Закриття програми -Щоб повернути SOL, виділені на акаунт програми, ви можете закрити вашу програму Solana. +Щоб повернути SOL, виділені на акаунт програми, ви можете закрити вашу програму +Solana. -Для закриття програми використовуйте команду `solana program close `. Наприклад: +Для закриття програми використовуйте команду +`solana program close `. Наприклад: ```shell solana program close 3ynNB373Q3VAzKp7m4x238po36hjAGFXFJB4ybN2iTyg --bypass-warning ``` -Зверніть увагу, що після закриття програми, ID програми не можна буде використовувати для розгортання нової програми. +Зверніть увагу, що після закриття програми, ID програми не можна буде +використовувати для розгортання нової програми. @@ -334,11 +356,13 @@ solana program close 3ynNB373Q3VAzKp7m4x238po36hjAGFXFJB4ybN2iTyg --bypass-warni ### Папка Programs -Папка `/programs` містить програми Anchor вашого проекту. Один робочий простір може містити кілька програм. +Папка `/programs` містить програми Anchor вашого проекту. Один робочий простір +може містити кілька програм. ### Папка Tests -Папка `/tests` містить тестові файли для вашого проекту. Стандартний тестовий файл створюється автоматично під час створення вашого проекту. +Папка `/tests` містить тестові файли для вашого проекту. Стандартний тестовий +файл створюється автоматично під час створення вашого проекту. ### Папка Target @@ -354,8 +378,10 @@ solana program close 3ynNB373Q3VAzKp7m4x238po36hjAGFXFJB4ybN2iTyg --bypass-warni ### Папка .anchor -Містить файл `program-logs`, що містить журнали транзакцій з останнього виконання тестових файлів. +Містить файл `program-logs`, що містить журнали транзакцій з останнього +виконання тестових файлів. ### Папка App -Папка `/app` є порожньою і може бути опційно використана для вашого фронтенд-коду. \ No newline at end of file +Папка `/app` є порожньою і може бути опційно використана для вашого +фронтенд-коду. diff --git a/docs/locales/uk/programs/anchor/pda.md b/docs/locales/uk/programs/anchor/pda.md index 505698c82..5b80e71a7 100644 --- a/docs/locales/uk/programs/anchor/pda.md +++ b/docs/locales/uk/programs/anchor/pda.md @@ -1,50 +1,55 @@ --- title: PDAs з Anchor description: - Дізнайтеся, як використовувати Program Derived Addresses (PDA) в програмах Anchor, використовуючи - обмеження та реалізуючи поширені шаблони PDA + Дізнайтеся, як використовувати Program Derived Addresses (PDA) в програмах + Anchor, використовуючи обмеження та реалізуючи поширені шаблони PDA sidebarLabel: PDAs з Anchor sidebarSortOrder: 4 --- -[Program Derived Addresses (PDA)](/docs/core/pda) — це функція розробки на Solana, -яка дозволяє створювати унікальну адресу, що отримується детерміновано -з попередньо визначених вхідних значень (насіння) та ID програми. +[Program Derived Addresses (PDA)](/docs/core/pda) — це функція розробки на +Solana, яка дозволяє створювати унікальну адресу, що отримується детерміновано з +попередньо визначених вхідних значень (насіння) та ID програми. Цей розділ охоплює базові приклади використання PDA в програмі Anchor. ## Обмеження Anchor для PDA -При використанні PDA в програмі Anchor, зазвичай використовуються обмеження акаунтів Anchor -для визначення насіння, що використовуються для отримання PDA. Ці обмеження служать -як перевірки безпеки, щоб переконатися, що правильна адреса була отримана. +При використанні PDA в програмі Anchor, зазвичай використовуються обмеження +акаунтів Anchor для визначення насіння, що використовуються для отримання PDA. +Ці обмеження служать як перевірки безпеки, щоб переконатися, що правильна адреса +була отримана. Обмеження, які використовуються для визначення насіння PDA, включають: -- `seeds`: Масив необов'язкових насінь, що використовуються для отримання PDA. Насіння можуть бути - статичними значеннями або динамічними посиланнями на дані акаунтів. -- `bump`: Bump seed, що використовується для отримання PDA. Використовується для забезпечення того, - щоб адреса не потрапляла на криву Ed25519 і була дійсним PDA. -- `seeds::program` - (Необов'язково) ID програми, що використовується для отримання адреси PDA. - Це обмеження використовується лише для отримання PDA, де ID програми не є - поточною програмою. +- `seeds`: Масив необов'язкових насінь, що використовуються для отримання PDA. + Насіння можуть бути статичними значеннями або динамічними посиланнями на дані + акаунтів. +- `bump`: Bump seed, що використовується для отримання PDA. Використовується для + забезпечення того, щоб адреса не потрапляла на криву Ed25519 і була дійсним + PDA. +- `seeds::program` - (Необов'язково) ID програми, що використовується для + отримання адреси PDA. Це обмеження використовується лише для отримання PDA, де + ID програми не є поточною програмою. Обмеження `seeds` та `bump` повинні використовуватися разом. ### Приклади використання -Нижче наведені приклади, що демонструють, як використовувати обмеження PDA в програмі Anchor. +Нижче наведені приклади, що демонструють, як використовувати обмеження PDA в +програмі Anchor. -Обмеження `seeds` визначає необов'язкові значення, що використовуються для отримання PDA. +Обмеження `seeds` визначає необов'язкові значення, що використовуються для +отримання PDA. #### Без необов'язкових сідів -- Використовуйте порожній масив `[]`, щоб визначити PDA без необов'язкових насінь. - +- Використовуйте порожній масив `[]`, щоб визначити PDA без необов'язкових + насінь. ```rs #[derive(Accounts)] @@ -74,8 +79,8 @@ pub struct InstructionAccounts<'info> { #### Кілька насінь та посилань на акаунти -- Можна вказати кілька насінь в обмеженні `seeds`. Обмеження `seeds` - також може посилатися на інші адреси акаунтів або дані акаунтів. +- Можна вказати кілька насінь в обмеженні `seeds`. Обмеження `seeds` також може + посилатися на інші адреси акаунтів або дані акаунтів. ```rs #[derive(Accounts)] @@ -89,8 +94,8 @@ pub struct InstructionAccounts<'info> { } ``` -Приклад вище використовує як статичне насіння (`b"hello_world"`), так і динамічне насіння -(публічний ключ підписанта). +Приклад вище використовує як статичне насіння (`b"hello_world"`), так і +динамічне насіння (публічний ключ підписанта). @@ -115,7 +120,9 @@ pub struct InstructionAccounts<'info> { #### Вказати значення Bump -Ви можете явно вказати значення bump, що корисно для оптимізації використання обчислювальних одиниць. Це передбачає, що акаунт PDA вже був створений і bump seed зберігається як поле в існуючому акаунті. +Ви можете явно вказати значення bump, що корисно для оптимізації використання +обчислювальних одиниць. Це передбачає, що акаунт PDA вже був створений і bump +seed зберігається як поле в існуючому акаунті. ```rs #[derive(Accounts)] @@ -133,16 +140,19 @@ pub struct CustomAccount { } ``` -Зберігаючи значення bump у даних акаунту, програма не потребує його повторного обчислення, що дозволяє заощадити обчислювальні одиниці. Збережене значення bump може бути збережено в самому акаунті або в іншому акаунті. +Зберігаючи значення bump у даних акаунту, програма не потребує його повторного +обчислення, що дозволяє заощадити обчислювальні одиниці. Збережене значення bump +може бути збережено в самому акаунті або в іншому акаунті. -Обмеження `seeds::program` визначає ID програми, що використовується для отримання PDA. -Це обмеження використовується лише при отриманні PDA з іншої програми. +Обмеження `seeds::program` визначає ID програми, що використовується для +отримання PDA. Це обмеження використовується лише при отриманні PDA з іншої +програми. -Використовуйте це обмеження, коли ваша інструкція повинна взаємодіяти з акаунтами PDA, -створеними іншою програмою. +Використовуйте це обмеження, коли ваша інструкція повинна взаємодіяти з +акаунтами PDA, створеними іншою програмою. ```rs #[derive(Accounts)] @@ -160,8 +170,8 @@ pub struct InstructionAccounts<'info> { -Обмеження `init` зазвичай використовується разом з `seeds` та `bump` для створення нового -акаунту з адресою, яка є PDA. Під капотом обмеження `init` +Обмеження `init` зазвичай використовується разом з `seeds` та `bump` для +створення нового акаунту з адресою, яка є PDA. Під капотом обмеження `init` викликає System Program для створення акаунту. ```rs @@ -191,7 +201,9 @@ pub struct CustomAccount { ## Насіння PDA в IDL -Насіння Program Derived Address (PDA), визначені в обмеженні `seeds`, включені в IDL файл програми. Це дозволяє клієнту Anchor автоматично вирішувати акаунти, використовуючи ці насіння під час побудови інструкцій. +Насіння Program Derived Address (PDA), визначені в обмеженні `seeds`, включені в +IDL файл програми. Це дозволяє клієнту Anchor автоматично вирішувати акаунти, +використовуючи ці насіння під час побудови інструкцій. Наведений нижче приклад показує взаємозв'язок між програмою, IDL та клієнтом. @@ -199,8 +211,8 @@ pub struct CustomAccount { -Програма нижче визначає `pda_account`, використовуючи статичне насіння (`b"hello_world"`) -та публічний ключ підписанта як динамічне насіння. +Програма нижче визначає `pda_account`, використовуючи статичне насіння +(`b"hello_world"`) та публічний ключ підписанта як динамічне насіння. ```rs {18} /signer/ use anchor_lang::prelude::*; @@ -280,7 +292,10 @@ IDL файл програми включає насіння PDA, визначе Клієнт Anchor може автоматично визначити адресу PDA, використовуючи IDL файл. -У наведеному нижче прикладі Anchor автоматично визначає адресу PDA, використовуючи гаманець постачальника як підписанта, а його публічний ключ як динамічне насіння для отримання PDA. Це усуває необхідність явного отримання PDA під час побудови інструкції. +У наведеному нижче прикладі Anchor автоматично визначає адресу PDA, +використовуючи гаманець постачальника як підписанта, а його публічний ключ як +динамічне насіння для отримання PDA. Це усуває необхідність явного отримання PDA +під час побудови інструкції. ```ts {13} import * as anchor from "@coral-xyz/anchor"; @@ -301,7 +316,8 @@ describe("hello_anchor", () => { }); ``` -Коли інструкція викликається, PDA виводиться в журнали програми, як це визначено в інструкції програми. +Коли інструкція викликається, PDA виводиться в журнали програми, як це визначено +в інструкції програми. ```{3} Program BZLiJ62bzRryYp9mRobz47uA66WDgtfTXhhgM25tJyx5 invoke [1] diff --git a/docs/locales/uk/programs/anchor/program-structure.md b/docs/locales/uk/programs/anchor/program-structure.md index 3fc534b6c..e37a5eac7 100644 --- a/docs/locales/uk/programs/anchor/program-structure.md +++ b/docs/locales/uk/programs/anchor/program-structure.md @@ -1,8 +1,8 @@ --- title: Структура програми Anchor description: - Дізнайтеся про структуру програм Anchor, включаючи основні макроси та їх - роль у спрощенні розробки програм для Solana + Дізнайтеся про структуру програм Anchor, включаючи основні макроси та їх роль + у спрощенні розробки програм для Solana sidebarLabel: Структура програми sidebarSortOrder: 1 --- @@ -15,16 +15,17 @@ sidebarSortOrder: 1 Основні макроси, які використовуються в програмі Anchor, включають: - [`declare_id`](#declare-id-macro): Визначає on-chain адресу програми -- [`#[program]`](#program-macro): Визначає модуль, що містить логіку інструкцій програми -- [`#[derive(Accounts)]`](#derive-accounts-macro): Застосовується до структур для - вказівки списку акаунтів, необхідних для інструкції +- [`#[program]`](#program-macro): Визначає модуль, що містить логіку інструкцій + програми +- [`#[derive(Accounts)]`](#derive-accounts-macro): Застосовується до структур + для вказівки списку акаунтів, необхідних для інструкції - [`#[account]`](#account-macro): Застосовується до структур для створення користувацьких типів акаунтів для програми ## Приклад програми -Давайте розглянемо просту програму, яка демонструє використання вищезгаданих макросів, -щоб зрозуміти основну структуру програми Anchor. +Давайте розглянемо просту програму, яка демонструє використання вищезгаданих +макросів, щоб зрозуміти основну структуру програми Anchor. Наведена нижче програма створює новий акаунт (`NewAccount`), який зберігає значення `u64`, передане в інструкцію `initialize`. @@ -71,8 +72,8 @@ use anchor_lang::prelude::*; declare_id!("11111111111111111111111111111111"); ``` -За замовчуванням, ID програми — це публічний ключ ключової пари, згенерованої за адресою -`/target/deploy/your_program_name.json`. +За замовчуванням, ID програми — це публічний ключ ключової пари, згенерованої за +адресою `/target/deploy/your_program_name.json`. Щоб оновити значення ID програми в макросі `declare_id` за допомогою публічного ключа ключової пари з файлу `/target/deploy/your_program_name.json`, виконайте @@ -83,15 +84,16 @@ anchor keys sync ``` Команда `anchor keys sync` корисна для виконання при клонуванні репозиторію, де -значення ID програми в макросі `declare_id` клонованого репозиторію не буде співпадати -з тим, що генерується при виконанні команди `anchor build` локально. +значення ID програми в макросі `declare_id` клонованого репозиторію не буде +співпадати з тим, що генерується при виконанні команди `anchor build` локально. ## Макрос `#[program]` Макрос [`#[program]`](https://github.com/coral-xyz/anchor/blob/v0.30.1/lang/attribute/program/src/lib.rs#L12) -визначає модуль, що містить усі обробники інструкцій для вашої програми. Кожна публічна функція -в межах цього модуля відповідає інструкції, яку можна викликати. +визначає модуль, що містить усі обробники інструкцій для вашої програми. Кожна +публічна функція в межах цього модуля відповідає інструкції, яку можна +викликати. ```rust filename="lib.rs" {5, 8-12} use anchor_lang::prelude::*; @@ -125,7 +127,10 @@ pub struct NewAccount { ### Контекст інструкції -Обробники інструкцій — це функції, які визначають логіку, що виконується, коли інструкція викликається. Перший параметр кожного обробника має тип `Context`, де `T` — це структура, яка реалізує трейд `Accounts` і вказує на акаунти, які потрібні для інструкції. +Обробники інструкцій — це функції, які визначають логіку, що виконується, коли +інструкція викликається. Перший параметр кожного обробника має тип `Context`, +де `T` — це структура, яка реалізує трейд `Accounts` і вказує на акаунти, які +потрібні для інструкції. Тип [`Context`](https://github.com/coral-xyz/anchor/blob/v0.30.1/lang/src/context.rs#L24) @@ -151,12 +156,14 @@ pub struct Context<'a, 'b, 'c, 'info, T> { - `ctx.accounts`: Акаунти, необхідні для інструкції - `ctx.program_id`: Публічний ключ програми (адреса) -- `ctx.remaining_accounts`: Додаткові акаунти, які не вказані в структурі `Accounts`. +- `ctx.remaining_accounts`: Додаткові акаунти, які не вказані в структурі + `Accounts`. - `ctx.bumps`: Bump seed для будь-яких акаунтів [Program Derived Address (PDA)](/docs/core/pda.md), вказаних у структурі `Accounts` -Додаткові параметри є необов'язковими та можуть бути включені для вказівки аргументів, які повинні бути надані при виклику інструкції. +Додаткові параметри є необов'язковими та можуть бути включені для вказівки +аргументів, які повинні бути надані при виклику інструкції. ```rust filename="lib.rs" /Context/ /data/1 pub fn initialize(ctx: Context, data: u64) -> Result<()> { @@ -166,8 +173,8 @@ pub fn initialize(ctx: Context, data: u64) -> Result<()> { } ``` -У цьому прикладі структура `Initialize` реалізує трейд `Accounts`, де -кожне поле в структурі представляє акаунт, необхідний для інструкції `initialize`. +У цьому прикладі структура `Initialize` реалізує трейд `Accounts`, де кожне поле +в структурі представляє акаунт, необхідний для інструкції `initialize`. ```rust filename="lib.rs" /Initialize/ /Accounts/ #[program] @@ -194,9 +201,11 @@ pub struct Initialize<'info> { Макрос [`#[derive(Accounts)]`](https://github.com/coral-xyz/anchor/blob/v0.30.1/lang/derive/accounts/src/lib.rs#L630) -застосовується до структури для вказівки акаунтів, які повинні бути надані під час виклику інструкції. Цей макрос реалізує трейд +застосовується до структури для вказівки акаунтів, які повинні бути надані під +час виклику інструкції. Цей макрос реалізує трейд [`Accounts`](https://github.com/coral-xyz/anchor/blob/v0.30.1/lang/src/lib.rs#L105), -що спрощує перевірку акаунтів, а також серіалізацію та десеріалізацію даних акаунтів. +що спрощує перевірку акаунтів, а також серіалізацію та десеріалізацію даних +акаунтів. ```rust /Accounts/ {1} #[derive(Accounts)] @@ -209,7 +218,9 @@ pub struct Initialize<'info> { } ``` -Кожне поле в структурі представляє акаунт, необхідний для інструкції. Іменування кожного поля є довільним, але рекомендується використовувати описове ім'я, яке вказує на призначення акаунту. +Кожне поле в структурі представляє акаунт, необхідний для інструкції. Іменування +кожного поля є довільним, але рекомендується використовувати описове ім'я, яке +вказує на призначення акаунту. ```rust /signer/2 /new_account/ /system_program/ #[derive(Accounts)] @@ -224,10 +235,15 @@ pub struct Initialize<'info> { ### Перевірка акаунтів -Для запобігання вразливостям безпеки важливо перевіряти, що акаунти, надані інструкції, є очікуваними. Акаунти перевіряються в програмах Anchor двома способами, які зазвичай використовуються разом: +Для запобігання вразливостям безпеки важливо перевіряти, що акаунти, надані +інструкції, є очікуваними. Акаунти перевіряються в програмах Anchor двома +способами, які зазвичай використовуються разом: - [Обмеження акаунтів](https://www.anchor-lang.com/docs/account-constraints): - Обмеження визначають додаткові умови, які акаунт повинен задовольняти, щоб вважатися дійсним для інструкції. Обмеження застосовуються за допомогою атрибута `#[account(..)]`, який розміщується над полем у структурі, що реалізує трейд `Accounts`. + Обмеження визначають додаткові умови, які акаунт повинен задовольняти, щоб + вважатися дійсним для інструкції. Обмеження застосовуються за допомогою + атрибута `#[account(..)]`, який розміщується над полем у структурі, що + реалізує трейд `Accounts`. Реалізацію обмежень можна знайти [тут](https://github.com/coral-xyz/anchor/blob/v0.30.1/lang/syn/src/parser/accounts/constraints.rs). @@ -243,8 +259,9 @@ pub struct Initialize<'info> { } ``` -- [Типи акаунтів](https://www.anchor-lang.com/docs/account-types): Anchor - надає різні типи акаунтів, щоб допомогти гарантувати, що акаунт, наданий клієнтом, відповідає тому, що очікує програма. +- [Типи акаунтів](https://www.anchor-lang.com/docs/account-types): Anchor надає + різні типи акаунтів, щоб допомогти гарантувати, що акаунт, наданий клієнтом, + відповідає тому, що очікує програма. Реалізацію типів акаунтів можна знайти [тут](https://github.com/coral-xyz/anchor/blob/v0.30.1/lang/src/accounts). @@ -261,7 +278,8 @@ pub struct Initialize<'info> { ``` Коли інструкція в програмі Anchor викликається, програма спочатку перевіряє -надані акаунти перед виконанням логіки інструкції. Після перевірки ці акаунти можна отримати в інструкції за допомогою синтаксису `ctx.accounts`. +надані акаунти перед виконанням логіки інструкції. Після перевірки ці акаунти +можна отримати в інструкції за допомогою синтаксису `ctx.accounts`. ```rust filename="lib.rs" /ctx.accounts.new_account/ /new_account/ /Initialize/ use anchor_lang::prelude::*; @@ -297,8 +315,8 @@ pub struct NewAccount { Макрос [`#[account]`](https://github.com/coral-xyz/anchor/blob/v0.30.1/lang/attribute/account/src/lib.rs#L66) -застосовується до структур, які визначають дані, що зберігаються в користувацьких акаунтах, -створених вашою програмою. +застосовується до структур, які визначають дані, що зберігаються в +користувацьких акаунтах, створених вашою програмою. ```rust #[account] @@ -319,8 +337,8 @@ pub struct NewAccount { перші 8 байтів даних акаунту під час його ініціалізації. Це допомагає відрізняти типи акаунтів і використовується для перевірки акаунтів. - [Серіалізація та десеріалізація даних](https://github.com/coral-xyz/anchor/blob/v0.30.1/lang/attribute/account/src/lib.rs#L202-L246): - Дані акаунту автоматично серіалізуються та десеріалізуються відповідно до типу акаунту. - + Дані акаунту автоматично серіалізуються та десеріалізуються відповідно до типу + акаунту. ```rust filename="lib.rs" /data/2,6 /NewAccount/ {24-27} use anchor_lang::prelude::*; @@ -356,9 +374,11 @@ pub struct NewAccount { Дискримінатор акаунту в програмі Anchor — це 8-байтовий ідентифікатор, унікальний для кожного типу акаунту. Він отримується з перших 8 байтів SHA256 -хешу рядка `account:`. Цей дискримінатор зберігається як перші 8 байтів даних акаунту під час його створення. +хешу рядка `account:`. Цей дискримінатор зберігається як перші 8 +байтів даних акаунту під час його створення. -При створенні акаунту в програмі Anchor для дискримінатора повинно бути виділено 8 байтів. +При створенні акаунту в програмі Anchor для дискримінатора повинно бути виділено +8 байтів. ```rust /8/1 #[account(init, payer = signer, space = 8 + 8)] @@ -367,7 +387,11 @@ pub new_account: Account<'info, NewAccount>, Дискримінатор використовується в наступних двох сценаріях: -- Ініціалізація: Коли акаунт створюється, дискримінатор встановлюється як перші 8 байтів даних акаунту. -- Десеріалізація: Коли дані акаунту десеріалізуються, перші 8 байтів даних акаунту перевіряються на відповідність дискримінатору очікуваного типу акаунту. +- Ініціалізація: Коли акаунт створюється, дискримінатор встановлюється як перші + 8 байтів даних акаунту. +- Десеріалізація: Коли дані акаунту десеріалізуються, перші 8 байтів даних + акаунту перевіряються на відповідність дискримінатору очікуваного типу + акаунту. -Якщо є невідповідність, це вказує на те, що клієнт надав неочікуваний акаунт. Цей механізм служить перевіркою валідності акаунтів у програмах Anchor. +Якщо є невідповідність, це вказує на те, що клієнт надав неочікуваний акаунт. +Цей механізм служить перевіркою валідності акаунтів у програмах Anchor. diff --git a/docs/locales/uk/programs/deploying.md b/docs/locales/uk/programs/deploying.md index 7486f9866..c4b2bd845 100644 --- a/docs/locales/uk/programs/deploying.md +++ b/docs/locales/uk/programs/deploying.md @@ -1,19 +1,20 @@ --- title: "Розгортання програм" description: - Розгортання програм на ланцюгу можна здійснити за допомогою Solana CLI, використовуючи - Upgradable BPF loader для завантаження скомпільованого байт-коду на блокчейн Solana. + Розгортання програм на ланцюгу можна здійснити за допомогою Solana CLI, + використовуючи Upgradable BPF loader для завантаження скомпільованого + байт-коду на блокчейн Solana. sidebarSortOrder: 2 --- -Програми Solana зберігаються в "виконуваних" акаунтах в мережі. Ці -акаунти містять скомпільований байт-код програми, який визначає інструкції, -які користувачі викликають для взаємодії з програмою. +Програми Solana зберігаються в "виконуваних" акаунтах в мережі. Ці акаунти +містять скомпільований байт-код програми, який визначає інструкції, які +користувачі викликають для взаємодії з програмою. ## Команди CLI -Цей розділ призначений як довідник для базових команд CLI для створення -та розгортання програм Solana. Для покрокового посібника зі створення вашої першої +Цей розділ призначений як довідник для базових команд CLI для створення та +розгортання програм Solana. Для покрокового посібника зі створення вашої першої програми почніть з [Розробки програм на Rust](/docs/programs/rust). ### Збірка програми @@ -28,30 +29,47 @@ cargo build-sbf 1. Скомпілює вашу програму 2. Створить директорію `target/deploy` -3. Згенерує файл `.so`, де `` відповідає імені вашої програми у файлі `Cargo.toml` +3. Згенерує файл `.so`, де `` відповідає імені вашої + програми у файлі `Cargo.toml` -Вивантажений файл `.so` містить скомпільований байт-код вашої програми, який буде -збережено в акаунті Solana під час розгортання вашої програми. +Вивантажений файл `.so` містить скомпільований байт-код вашої програми, який +буде збережено в акаунті Solana під час розгортання вашої програми. ### Розгортання програми -Щоб розгорнути вашу програму, використовуйте команду `solana program deploy`, вказавши шлях до файлу `.so`, який був створений командою `cargo build-sbf`. +Щоб розгорнути вашу програму, використовуйте команду `solana program deploy`, +вказавши шлях до файлу `.so`, який був створений командою `cargo build-sbf`. ```shell solana program deploy ./target/deploy/your_program.so ``` -Під час періодів завантаження є кілька додаткових прапорців, які можна використовувати для полегшення розгортання програми. - -- `--with-compute-unit-price`: Встановіть ціну за обчислювальні одиниці для транзакції, в increments 0.000001 лампортів (мікро-лампорти) за обчислювальну одиницю. -- `--max-sign-attempts`: Максимальна кількість спроб підписати або повторно підписати транзакції після закінчення терміну дії blockhash. Якщо будь-які транзакції, надіслані під час розгортання програми, залишаються непідтвердженими після закінчення терміну дії початково вибраного останнього blockhash, ці транзакції будуть повторно підписані з новим blockhash і відправлені знову. Використовуйте цей параметр для налаштування максимальної кількості спроб підписання транзакцій. Кожен blockhash є дійсним близько 60 секунд, що означає, що використання значення за замовчуванням 5 призведе до надсилання транзакцій щонайменше 5 хвилин або до тих пір, поки всі транзакції не будуть підтверджені, залежно від того, що відбудеться раніше. [за замовчуванням: 5] -- `--use-rpc`: Надсилайте транзакції запису до налаштованого RPC замість TPU валідатора. Цей прапорець вимагає RPC з урахуванням ставки. +Під час періодів завантаження є кілька додаткових прапорців, які можна +використовувати для полегшення розгортання програми. + +- `--with-compute-unit-price`: Встановіть ціну за обчислювальні одиниці для + транзакції, в increments 0.000001 лампортів (мікро-лампорти) за обчислювальну + одиницю. +- `--max-sign-attempts`: Максимальна кількість спроб підписати або повторно + підписати транзакції після закінчення терміну дії blockhash. Якщо будь-які + транзакції, надіслані під час розгортання програми, залишаються + непідтвердженими після закінчення терміну дії початково вибраного останнього + blockhash, ці транзакції будуть повторно підписані з новим blockhash і + відправлені знову. Використовуйте цей параметр для налаштування максимальної + кількості спроб підписання транзакцій. Кожен blockhash є дійсним близько 60 + секунд, що означає, що використання значення за замовчуванням 5 призведе до + надсилання транзакцій щонайменше 5 хвилин або до тих пір, поки всі транзакції + не будуть підтверджені, залежно від того, що відбудеться раніше. [за + замовчуванням: 5] +- `--use-rpc`: Надсилайте транзакції запису до налаштованого RPC замість TPU + валідатора. Цей прапорець вимагає RPC з урахуванням ставки. Ви можете використовувати ці прапорці окремо або поєднувати їх разом. Наприклад: ```shell solana program deploy ./target/deploy/your_program.so --with-compute-unit-price 10000 --max-sign-attempts 1000 --use-rpc ``` + - Використовуйте [Priority Fee API від Helius](https://docs.helius.dev/guides/priority-fee-api) для отримання оцінки пріоритетної плати, яку потрібно встановити за допомогою @@ -59,18 +77,19 @@ solana program deploy ./target/deploy/your_program.so --with-compute-unit-price - Отримайте [RPC з урахуванням ставки](https://solana.com/developers/guides/advanced/stake-weighted-qos) - від [Helius](https://www.helius.dev/) або - [Triton](https://triton.one/) для використання з прапорцем `--use-rpc`. Прапорець - `--use-rpc` повинен використовуватись тільки з RPC з урахуванням ставки. + від [Helius](https://www.helius.dev/) або [Triton](https://triton.one/) для + використання з прапорцем `--use-rpc`. Прапорець `--use-rpc` повинен + використовуватись тільки з RPC з урахуванням ставки. -Щоб оновити ваш за умовчанням RPC URL за допомогою власної точки доступу RPC, використовуйте команду -`solana config set`. +Щоб оновити ваш за умовчанням RPC URL за допомогою власної точки доступу RPC, +використовуйте команду `solana config set`. ```shell solana config set --url ``` -Ви можете переглянути список програм, які ви розгорнули, використовуючи підкоманду `program show`: +Ви можете переглянути список програм, які ви розгорнули, використовуючи +підкоманду `program show`: ```shell solana program show --programs @@ -85,18 +104,18 @@ Program Id | Slot | Authority ### Оновлення програми -Авторизація на оновлення програми може змінювати існуючу програму Solana, розгортаючи -новий файл `.so` на той самий ID програми. +Авторизація на оновлення програми може змінювати існуючу програму Solana, +розгортаючи новий файл `.so` на той самий ID програми. Щоб оновити існуючу програму Solana: - Змініть вихідний код вашої програми - Виконайте команду `cargo build-sbf`, щоб згенерувати оновлений файл `.so` -- Виконайте команду `solana program deploy ./target/deploy/your_program.so`, щоб розгорнути - оновлений файл `.so` +- Виконайте команду `solana program deploy ./target/deploy/your_program.so`, щоб + розгорнути оновлений файл `.so` -Авторизацію на оновлення можна змінити за допомогою підкоманди `set-upgrade-authority` -наступним чином: +Авторизацію на оновлення можна змінити за допомогою підкоманди +`set-upgrade-authority` наступним чином: ```shell solana program set-upgrade-authority --new-upgrade-authority @@ -104,14 +123,15 @@ solana program set-upgrade-authority --new-upgrade-authority < ### Незмінна програма -Програму можна зробити незмінною, видаливши її авторизацію на оновлення. Це незворотна дія. +Програму можна зробити незмінною, видаливши її авторизацію на оновлення. Це +незворотна дія. ```shell solana program set-upgrade-authority --final ``` -Ви можете вказати, що програма має бути незмінною при розгортанні, встановивши прапорець -`--final` під час розгортання програми. +Ви можете вказати, що програма має бути незмінною при розгортанні, встановивши +прапорець `--final` під час розгортання програми. ```shell solana program deploy ./target/deploy/your_program.so --final @@ -135,15 +155,18 @@ Closed Program Id 4Ujf5fXfLx2PAwRqcECCLtgDxHKPznoJpa43jUBxFfMz, 0.1350588 SOL reclaimed ``` -Зверніть увагу, що після закриття програми її ID програми не можна буде використовувати знову. Спроба розгорнути програму з раніше закритим ID програми призведе до помилки. +Зверніть увагу, що після закриття програми її ID програми не можна буде +використовувати знову. Спроба розгорнути програму з раніше закритим ID програми +призведе до помилки. ``` Error: Program 4Ujf5fXfLx2PAwRqcECCLtgDxHKPznoJpa43jUBxFfMz has been closed, use a new Program Id ``` -Якщо вам потрібно повторно розгорнути програму після її закриття, ви повинні згенерувати новий -ID програми. Щоб згенерувати нову ключову пару для програми, виконайте наступну команду: +Якщо вам потрібно повторно розгорнути програму після її закриття, ви повинні +згенерувати новий ID програми. Щоб згенерувати нову ключову пару для програми, +виконайте наступну команду: ```shell filename="Terminal" solana-keygen new -o ./target/deploy/your_program-keypair.json --force @@ -154,8 +177,9 @@ solana-keygen new -o ./target/deploy/your_program-keypair.json --force ### Акаунти буфера програми -Розгортання програми вимагає кількох транзакцій через обмеження в 1232 байти -для транзакцій на Solana. Проміжним кроком процесу розгортання є запис байт-коду програми в тимчасовий "акаунт буфера". +Розгортання програми вимагає кількох транзакцій через обмеження в 1232 байти для +транзакцій на Solana. Проміжним кроком процесу розгортання є запис байт-коду +програми в тимчасовий "акаунт буфера". Цей акаунт буфера автоматично закривається після успішного розгортання програми. Однак, якщо розгортання не вдалося, акаунт буфера залишається, і ви можете: @@ -163,7 +187,8 @@ solana-keygen new -o ./target/deploy/your_program-keypair.json --force - Продовжити розгортання, використовуючи існуючий акаунт буфера - Закрити акаунт буфера, щоб повернути виділений SOL (оренду) -Ви можете перевірити, чи є відкриті акаунти буфера, використовуючи підкоманду `program show`, наступним чином: +Ви можете перевірити, чи є відкриті акаунти буфера, використовуючи підкоманду +`program show`, наступним чином: ```shell solana program show --buffers @@ -176,7 +201,8 @@ Buffer Address | Authority 5TRm1DxYcXLbSEbbxWcQbEUCce7L4tVgaC6e2V4G82pM | 4kh6HxYZiAebF8HWLsUWod2EaQQ6iWHpHYCz8UcmFbM1 | 0.57821592 SOL ``` -Ви можете продовжити до розгортання за допомогою підкоманди `program deploy` наступним чином: +Ви можете продовжити до розгортання за допомогою підкоманди `program deploy` +наступним чином: ```shell solana program deploy --buffer 5TRm1DxYcXLbSEbbxWcQbEUCce7L4tVgaC6e2V4G82pM @@ -198,11 +224,13 @@ solana program close --buffers ### ELF Dump -Внутрішні дані SBF shared object можна вивести в текстовий файл, щоб отримати більше -інформації про склад програми та те, що вона може виконувати під час виконання. Вивантаження -містить як ELF інформацію, так і список всіх символів та інструкцій, що їх реалізують. Деякі з повідомлень журналу помилок BPF loader -будуть посилатися на конкретні номери інструкцій, де сталася помилка. -Ці посилання можна знайти у вивантаженні ELF, щоб ідентифікувати помилкову інструкцію та її контекст. +Внутрішні дані SBF shared object можна вивести в текстовий файл, щоб отримати +більше інформації про склад програми та те, що вона може виконувати під час +виконання. Вивантаження містить як ELF інформацію, так і список всіх символів та +інструкцій, що їх реалізують. Деякі з повідомлень журналу помилок BPF loader +будуть посилатися на конкретні номери інструкцій, де сталася помилка. Ці +посилання можна знайти у вивантаженні ELF, щоб ідентифікувати помилкову +інструкцію та її контекст. ```shell cargo build-bpf --dump @@ -213,14 +241,17 @@ cargo build-bpf --dump ## Процес розгортання програми Розгортання програми на Solana вимагає кількох транзакцій через максимальний -ліміт розміру транзакцій у 1232 байти. Solana CLI надсилає ці транзакції за допомогою підкоманди `solana program deploy`. Процес можна розділити на наступні 3 фази: +ліміт розміру транзакцій у 1232 байти. Solana CLI надсилає ці транзакції за +допомогою підкоманди `solana program deploy`. Процес можна розділити на наступні +3 фази: 1. [Ініціалізація буфера](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/cli/src/program.rs#L2113): Спочатку CLI надсилає транзакцію, яка [створює акаунт буфера](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/cli/src/program.rs#L1903) достатнього розміру для байт-коду, що розгортається. Також викликається [інструкція ініціалізації буфера](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/programs/bpf_loader/src/lib.rs#L320), - щоб встановити право власності на буфер і обмежити записи на вибрану адресу розробника. + щоб встановити право власності на буфер і обмежити записи на вибрану адресу + розробника. 2. [Запис буфера](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/cli/src/program.rs#L2129): Після ініціалізації акаунту буфера CLI [розбиває байт-код програми](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/cli/src/program.rs#L1940) @@ -228,7 +259,9 @@ cargo build-bpf --dump [відправляє транзакції зі швидкістю 100 транзакцій за секунду](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/client/src/tpu_client.rs#L133), щоб записати кожен шматок за допомогою [інструкції запису буфера](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/programs/bpf_loader/src/lib.rs#L334). - Ці транзакції надсилаються безпосередньо до порту обробки транзакцій (TPU) поточного лідера і обробляються паралельно. Після того, як всі транзакції будуть надіслані, CLI + Ці транзакції надсилаються безпосередньо до порту обробки транзакцій (TPU) + поточного лідера і обробляються паралельно. Після того, як всі транзакції + будуть надіслані, CLI [опитує RPC API партіями підписів транзакцій](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/client/src/tpu_client.rs#L216), щоб переконатися, що кожен запис був успішним і підтвердженим. 3. [Фіналізація](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/cli/src/program.rs#L1807): @@ -238,8 +271,8 @@ cargo build-bpf --dump [розгорнути нову програму](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/programs/bpf_loader/src/lib.rs#L362) або [оновити існуючу програму](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/programs/bpf_loader/src/lib.rs#L513). - В будь-якому випадку байт-код, записаний в акаунт буфера, буде скопійовано - в акаунт даних програми і перевірено. + В будь-якому випадку байт-код, записаний в акаунт буфера, буде скопійовано в + акаунт даних програми і перевірено. ## Оновлювана програма BPF Loader @@ -252,48 +285,49 @@ Solana. Коли ви розгортаєте програму, власник а Оновлювана програма BPF loader підтримує три різні типи акаунтів стану: 1. [Акаунт програми](https://github.com/solana-labs/solana/blob/master/sdk/program/src/bpf_loader_upgradeable.rs#L34): - Це основний акаунт програми на ланцюгу, і його адреса зазвичай - називається "ID програми". ID програми — це те, на що посилаються інструкції транзакцій - для виклику програми. Акаунти програми незмінні після розгортання, тому ви можете вважати їх проксі-акаунтами для байт-коду та - стану, що зберігаються в інших акаунтах. + Це основний акаунт програми на ланцюгу, і його адреса зазвичай називається + "ID програми". ID програми — це те, на що посилаються інструкції транзакцій + для виклику програми. Акаунти програми незмінні після розгортання, тому ви + можете вважати їх проксі-акаунтами для байт-коду та стану, що зберігаються в + інших акаунтах. 2. [Акаунт даних програми](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/sdk/program/src/bpf_loader_upgradeable.rs#L39): - Цей акаунт зберігає виконуваний байт-код програми на ланцюгу. - Коли програма оновлюється, дані цього акаунту оновлюються новим - байт-кодом. Крім байт-коду, акаунти даних програми також - відповідають за зберігання слоту, коли вони були востаннє змінені, та адреси - єдиного акаунту, авторизованого для зміни акаунту (ця адреса може бути - очищена, щоб зробити програму незмінною). + Цей акаунт зберігає виконуваний байт-код програми на ланцюгу. Коли програма + оновлюється, дані цього акаунту оновлюються новим байт-кодом. Крім байт-коду, + акаунти даних програми також відповідають за зберігання слоту, коли вони були + востаннє змінені, та адреси єдиного акаунту, авторизованого для зміни акаунту + (ця адреса може бути очищена, щоб зробити програму незмінною). 3. [Акаунти буфера](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/sdk/program/src/bpf_loader_upgradeable.rs#L27): - Ці акаунти тимчасово зберігають байт-код під час активного - розгортання програми через серію транзакцій. Вони також зберігають адресу - єдиного акаунту, який авторизований для виконання записів. + Ці акаунти тимчасово зберігають байт-код під час активного розгортання + програми через серію транзакцій. Вони також зберігають адресу єдиного + акаунту, який авторизований для виконання записів. ### Інструкції -Акаунти стану, перераховані вище, можуть бути змінені лише за допомогою однієї з наступних -інструкцій, що підтримуються програмою Upgradeable BPF Loader: +Акаунти стану, перераховані вище, можуть бути змінені лише за допомогою однієї з +наступних інструкцій, що підтримуються програмою Upgradeable BPF Loader: 1. [Ініціалізація буфера](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/sdk/program/src/loader_upgradeable_instruction.rs#L21): - Створює акаунт буфера і зберігає адресу авторизації, яка дозволена - змінювати буфер. + Створює акаунт буфера і зберігає адресу авторизації, яка дозволена змінювати + буфер. 2. [Запис](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/sdk/program/src/loader_upgradeable_instruction.rs#L28): Записує байт-код на вказаний байтовий офсет в акаунті буфера. Записи обробляються маленькими шматками через обмеження транзакцій Solana, максимальний розмір яких складає 1232 байти. 3. [Розгортання](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/sdk/program/src/loader_upgradeable_instruction.rs#L77): - Створює акаунт програми та акаунт даних програми. Він заповнює - акаунт даних програми, копіюючи байт-код, що зберігається в акаунті буфера. Якщо - байт-код є дійсним, акаунт програми буде встановлений як виконуваний, - дозволяючи його викликати. Якщо байт-код недійсний, інструкція не вдасться, і всі зміни будуть скасовані. + Створює акаунт програми та акаунт даних програми. Він заповнює акаунт даних + програми, копіюючи байт-код, що зберігається в акаунті буфера. Якщо байт-код + є дійсним, акаунт програми буде встановлений як виконуваний, дозволяючи його + викликати. Якщо байт-код недійсний, інструкція не вдасться, і всі зміни + будуть скасовані. 4. [Оновлення](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/sdk/program/src/loader_upgradeable_instruction.rs#L102): - Заповнює існуючий акаунт даних програми, копіюючи виконуваний байт-код з акаунта - буфера. Подібно до інструкції розгортання, вона буде успішною лише в тому випадку, якщо - байт-код є дійсним. + Заповнює існуючий акаунт даних програми, копіюючи виконуваний байт-код з + акаунта буфера. Подібно до інструкції розгортання, вона буде успішною лише в + тому випадку, якщо байт-код є дійсним. 5. [Встановлення авторизації](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/sdk/program/src/loader_upgradeable_instruction.rs#L114): Оновлює авторизацію акаунта даних програми або акаунта буфера, якщо поточний - власник акаунту підписав транзакцію, що обробляється. Якщо авторизація буде видалена без заміни, - її можна буде встановити лише один раз і акаунт більше не можна буде закрити. + власник акаунту підписав транзакцію, що обробляється. Якщо авторизація буде + видалена без заміни, її можна буде встановити лише один раз і акаунт більше + не можна буде закрити. 6. [Закриття](https://github.com/solana-labs/solana/blob/7409d9d2687fba21078a745842c25df805cdf105/sdk/program/src/loader_upgradeable_instruction.rs#L127): - Очищає дані акаунта програми або акаунта буфера та повертає SOL, - використані для депозиту звільнення від оренди. - + Очищає дані акаунта програми або акаунта буфера та повертає SOL, використані + для депозиту звільнення від оренди. diff --git a/docs/locales/uk/programs/examples.md b/docs/locales/uk/programs/examples.md index be25a95dd..e20f39553 100644 --- a/docs/locales/uk/programs/examples.md +++ b/docs/locales/uk/programs/examples.md @@ -1,8 +1,9 @@ --- title: "Приклади програм" description: - "Список прикладів програм для Solana на різних мовах і фреймворках, - які можуть допомогти вам вивчити та використовувати їх як посилання для ваших власних проектів." + "Список прикладів програм для Solana на різних мовах і фреймворках, які можуть + допомогти вам вивчити та використовувати їх як посилання для ваших власних + проектів." tags: - quickstart - program @@ -28,19 +29,19 @@ sidebarSortOrder: 3 Репозиторій [Solana Program Examples](https://github.com/solana-developers/program-examples) -на GitHub пропонує кілька підпапок, кожна з яких містить приклади коду -для різних парадигм програмування Solana та мов, створених, щоб допомогти +на GitHub пропонує кілька підпапок, кожна з яких містить приклади коду для +різних парадигм програмування Solana та мов, створених, щоб допомогти розробникам вивчати та експериментувати з розробкою на блокчейні Solana. Ви можете знайти приклади в репозиторії `solana-developers/program-examples` разом з файлами README, що пояснюють, як запускати різні приклади. Більшість прикладів є самодостатніми та доступні на рідному Rust (тобто без використання -фреймворку) та [Anchor](https://www.anchor-lang.com/docs/installation). Також -є список прикладів, які ми з радістю б +фреймворку) та [Anchor](https://www.anchor-lang.com/docs/installation). Також є +список прикладів, які ми з радістю б [побачили як внески](https://github.com/solana-developers/program-examples?tab=readme-ov-file#examples-wed-love-to-see). -У репозиторії ви знайдете наступну підпапку, кожну з яких з різними -прикладами програм: +У репозиторії ви знайдете наступну підпапку, кожну з яких з різними прикладами +програм: - [Основи](#basics) - [Стиснення](#compression) @@ -52,26 +53,26 @@ sidebarSortOrder: 3 ## Основи -Містить серію прикладів, які демонструють основні кроки для -створення програм Solana, використовуючи рідні бібліотеки Rust. Ці приклади -призначені для того, щоб допомогти розробникам зрозуміти основні концепції програмування Solana. - -| Назва прикладу | Опис | Мова | -| ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------ | -| [Дані акаунта](https://github.com/solana-developers/program-examples/tree/main/basics/account-data) | Збереження адреси з ім'ям, номером будинку, вулицею та містом в акаунті. | Native, Anchor | -| [Перевірка акаунтів](https://github.com/solana-developers/program-examples/tree/main/basics/checking-accounts) | Уроки безпеки, що показують, як виконувати перевірки акаунтів | Native, Anchor | -| [Закриття акаунта](https://github.com/solana-developers/program-examples/tree/main/basics/close-account) | Показує, як закривати акаунти, щоб повернути оренду. | Native, Anchor | -| [Лічильник](https://github.com/solana-developers/program-examples/tree/main/basics/counter) | Простий програмний лічильник на всіх різних архітектурах. | Native, Anchor, mpl-stack| -| [Створення акаунта](https://github.com/solana-developers/program-examples/tree/main/basics/create-account) | Як створити системний акаунт в межах програми. | Native, Anchor | -| [Перехресний виклик програми](https://github.com/solana-developers/program-examples/tree/main/basics/cross-program-invocation) | Використовуючи аналогію з рукою та важелем, показує, як викликати іншу програму з програми. | Native, Anchor | -| [Hello Solana](https://github.com/solana-developers/program-examples/tree/main/basics/hello-solana) | Приклад "Hello world", який просто виводить hello world у журналах транзакцій. | Native, Anchor | -| [Pda Rent payer](https://github.com/solana-developers/program-examples/tree/main/basics/pda-rent-payer) | Показує, як можна використовувати лампорти з PDA для оплати нового акаунта. | Native, Anchor | -| [Обробка інструкцій](https://github.com/solana-developers/program-examples/tree/main/basics/processing-instructions) | Показує, як обробляти рядкові дані інструкцій та u32. | Native, Anchor | -| [Програма з похідними адресами](https://github.com/solana-developers/program-examples/tree/main/basics/program-derived-addresses) | Показує, як використовувати насіння для посилання на PDA та збереження даних в ньому. | Native, Anchor | -| [Перерозподіл](https://github.com/solana-developers/program-examples/tree/main/basics/realloc) | Показує, як збільшувати та зменшувати розмір існуючого акаунта. | Native, Anchor | -| [Оренда](https://github.com/solana-developers/program-examples/tree/main/basics/rent) | Тут ви дізнаєтесь, як обчислювати вимоги оренди в межах програми. | Native, Anchor | -| [Розташування репозиторію](https://github.com/solana-developers/program-examples/tree/main/basics/repository-layout) | Рекомендації щодо структурування вашого макету програми. | Native, Anchor | -| [Передача SOL](https://github.com/solana-developers/program-examples/tree/main/basics/transfer-sol) | Різні методи передачі SOL для системних акаунтів та PDA. | Native, Anchor, Seahorse | +Містить серію прикладів, які демонструють основні кроки для створення програм +Solana, використовуючи рідні бібліотеки Rust. Ці приклади призначені для того, +щоб допомогти розробникам зрозуміти основні концепції програмування Solana. + +| Назва прикладу | Опис | Мова | +| --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ------------------------- | +| [Дані акаунта](https://github.com/solana-developers/program-examples/tree/main/basics/account-data) | Збереження адреси з ім'ям, номером будинку, вулицею та містом в акаунті. | Native, Anchor | +| [Перевірка акаунтів](https://github.com/solana-developers/program-examples/tree/main/basics/checking-accounts) | Уроки безпеки, що показують, як виконувати перевірки акаунтів | Native, Anchor | +| [Закриття акаунта](https://github.com/solana-developers/program-examples/tree/main/basics/close-account) | Показує, як закривати акаунти, щоб повернути оренду. | Native, Anchor | +| [Лічильник](https://github.com/solana-developers/program-examples/tree/main/basics/counter) | Простий програмний лічильник на всіх різних архітектурах. | Native, Anchor, mpl-stack | +| [Створення акаунта](https://github.com/solana-developers/program-examples/tree/main/basics/create-account) | Як створити системний акаунт в межах програми. | Native, Anchor | +| [Перехресний виклик програми](https://github.com/solana-developers/program-examples/tree/main/basics/cross-program-invocation) | Використовуючи аналогію з рукою та важелем, показує, як викликати іншу програму з програми. | Native, Anchor | +| [Hello Solana](https://github.com/solana-developers/program-examples/tree/main/basics/hello-solana) | Приклад "Hello world", який просто виводить hello world у журналах транзакцій. | Native, Anchor | +| [Pda Rent payer](https://github.com/solana-developers/program-examples/tree/main/basics/pda-rent-payer) | Показує, як можна використовувати лампорти з PDA для оплати нового акаунта. | Native, Anchor | +| [Обробка інструкцій](https://github.com/solana-developers/program-examples/tree/main/basics/processing-instructions) | Показує, як обробляти рядкові дані інструкцій та u32. | Native, Anchor | +| [Програма з похідними адресами](https://github.com/solana-developers/program-examples/tree/main/basics/program-derived-addresses) | Показує, як використовувати насіння для посилання на PDA та збереження даних в ньому. | Native, Anchor | +| [Перерозподіл](https://github.com/solana-developers/program-examples/tree/main/basics/realloc) | Показує, як збільшувати та зменшувати розмір існуючого акаунта. | Native, Anchor | +| [Оренда](https://github.com/solana-developers/program-examples/tree/main/basics/rent) | Тут ви дізнаєтесь, як обчислювати вимоги оренди в межах програми. | Native, Anchor | +| [Розташування репозиторію](https://github.com/solana-developers/program-examples/tree/main/basics/repository-layout) | Рекомендації щодо структурування вашого макету програми. | Native, Anchor | +| [Передача SOL](https://github.com/solana-developers/program-examples/tree/main/basics/transfer-sol) | Різні методи передачі SOL для системних акаунтів та PDA. | Native, Anchor, Seahorse | ## Стиснення @@ -79,62 +80,67 @@ sidebarSortOrder: 3 [стиснення стану](/docs/advanced/state-compression.md) на Solana. Головним чином фокусується на стиснених NFT (cNFT). -| Назва прикладу | Опис | Мова | -| -------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ------- | -| [cNFT-burn](https://github.com/solana-developers/program-examples/tree/main/compression/cnft-burn) | Для знищення cNFT він може бути спалений. Цей приклад показує, як це зробити в програмі. | Anchor | -| [cNFT-Vault](https://github.com/solana-developers/program-examples/tree/main/compression/cnft-vault/anchor) | Як зберігати cNFT в програмі та відправляти його знову. | Anchor | -| [cutils](https://github.com/solana-developers/program-examples/tree/main/compression/cutils) | Набір утиліт для, наприклад, мінтування та перевірки cNFT в програмі. | Anchor | +| Назва прикладу | Опис | Мова | +| ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ------ | +| [cNFT-burn](https://github.com/solana-developers/program-examples/tree/main/compression/cnft-burn) | Для знищення cNFT він може бути спалений. Цей приклад показує, як це зробити в програмі. | Anchor | +| [cNFT-Vault](https://github.com/solana-developers/program-examples/tree/main/compression/cnft-vault/anchor) | Як зберігати cNFT в програмі та відправляти його знову. | Anchor | +| [cutils](https://github.com/solana-developers/program-examples/tree/main/compression/cutils) | Набір утиліт для, наприклад, мінтування та перевірки cNFT в програмі. | Anchor | ## Оракули Оракули дозволяють використовувати дані поза ланцюгом в програмах. -| Назва прикладу | Опис | Мова | -| ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ------ | -| [Pyth](https://github.com/solana-developers/program-examples/tree/main/oracles/pyth) | Pyth надає дані про ціни токенів для використання в програмах на ланцюгу. | Anchor | +| Назва прикладу | Опис | Мова | +| ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------- | ------ | +| [Pyth](https://github.com/solana-developers/program-examples/tree/main/oracles/pyth) | Pyth надає дані про ціни токенів для використання в програмах на ланцюгу. | Anchor | ## Токени -Більшість токенів на Solana використовують стандарт токенів Solana Program Library (SPL). Тут -ви знайдете багато прикладів, як створювати, передавати, спалювати токени та навіть як взаємодіяти з ними в програмах. +Більшість токенів на Solana використовують стандарт токенів Solana Program +Library (SPL). Тут ви знайдете багато прикладів, як створювати, передавати, +спалювати токени та навіть як взаємодіяти з ними в програмах. -| Назва прикладу | Опис | Мова | -| --------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | ------------ | -| [Створення токена](https://github.com/solana-developers/program-examples/tree/main/tokens/create-token) | Як створити токен та додати метадані метаплекса до нього. | Anchor, Native | -| [NFT Minter](https://github.com/solana-developers/program-examples/tree/main/tokens/nft-minter) | Мінтування тільки однієї кількості токену, а потім видалення права на мінтинг. | Anchor, Native | -| [PDA Mint Authority](https://github.com/solana-developers/program-examples/tree/main/tokens/pda-mint-authority) | Показує, як змінити право на мінтинг токенів через PDA. | Anchor, Native | -| [SPL Token Minter](https://github.com/solana-developers/program-examples/tree/main/tokens/spl-token-minter) | Пояснює, як використовувати Associated Token Accounts для відслідковування токен акаунтів. | Anchor, Native | -| [Token Swap](https://github.com/solana-developers/program-examples/tree/main/tokens/token-swap) | Розширений приклад, який показує, як побудувати AMM (автоматизований маркет-мейкер) пул для SPL токенів. | Anchor | -| [Передача токенів](https://github.com/solana-developers/program-examples/tree/main/tokens/transfer-tokens) | Показує, як передавати SPL токени за допомогою CPIs у програму токенів. | Anchor, Native | -| [Token-2022](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022) | Див. Token 2022 (Розширення токенів). | Anchor, Native | +| Назва прикладу | Опис | Мова | +| --------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | -------------- | +| [Створення токена](https://github.com/solana-developers/program-examples/tree/main/tokens/create-token) | Як створити токен та додати метадані метаплекса до нього. | Anchor, Native | +| [NFT Minter](https://github.com/solana-developers/program-examples/tree/main/tokens/nft-minter) | Мінтування тільки однієї кількості токену, а потім видалення права на мінтинг. | Anchor, Native | +| [PDA Mint Authority](https://github.com/solana-developers/program-examples/tree/main/tokens/pda-mint-authority) | Показує, як змінити право на мінтинг токенів через PDA. | Anchor, Native | +| [SPL Token Minter](https://github.com/solana-developers/program-examples/tree/main/tokens/spl-token-minter) | Пояснює, як використовувати Associated Token Accounts для відслідковування токен акаунтів. | Anchor, Native | +| [Token Swap](https://github.com/solana-developers/program-examples/tree/main/tokens/token-swap) | Розширений приклад, який показує, як побудувати AMM (автоматизований маркет-мейкер) пул для SPL токенів. | Anchor | +| [Передача токенів](https://github.com/solana-developers/program-examples/tree/main/tokens/transfer-tokens) | Показує, як передавати SPL токени за допомогою CPIs у програму токенів. | Anchor, Native | +| [Token-2022](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022) | Див. Token 2022 (Розширення токенів). | Anchor, Native | ## Token 2022 (Розширення токенів) -Token 2022 — це новий стандарт для токенів на Solana. Це більш гнучкий стандарт, який -дозволяє додавати до токену 16 різних розширень для додавання більшої функціональності. - -| Назва прикладу | Опис | Мова | -| ----------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------ | -| [Основи](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/basics/anchor) | Як створити токен, мінтувати та передавати його. | Anchor | -| [Стандартний стан акаунта](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/default-account-state/native) | Це розширення дозволяє створювати акаунти токенів з певним станом, наприклад замороженими. | Native | -| [Право закриття мінта](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/mint-close-authority) | З старою програмою токенів не було можливості закривати мінт. Тепер це можливо. | Native | -| [Багато розширень](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/multiple-extensions) | Показує, як додавати кілька розширень до одного мінта | Native | -| [Вказівник метаданих NFT](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/nft-meta-data-pointer) | Можна використовувати розширення метаданих для створення NFT та додавання динамічних метаданих на ланцюг. | Anchor | -| [Не передаваємий](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/non-transferable/native) | Корисно, наприклад, для досягнень, програм рефералів або будь-яких токенів, які не можна передавати. | Native | -| [Плата за передачу](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/transfer-fees) | Кожна передача токенів утримує певну кількість токенів у акаунті токена, яку потім можна забрати. | Native | -| [Transfer Hook](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/transfer-hook) | Чотири приклади для додавання додаткової функціональності до вашого токена за допомогою CPI з програми токенів. | Anchor | +Token 2022 — це новий стандарт для токенів на Solana. Це більш гнучкий стандарт, +який дозволяє додавати до токену 16 різних розширень для додавання більшої +функціональності. + +| Назва прикладу | Опис | Мова | +| ------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------- | ------ | +| [Основи](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/basics/anchor) | Як створити токен, мінтувати та передавати його. | Anchor | +| [Стандартний стан акаунта](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/default-account-state/native) | Це розширення дозволяє створювати акаунти токенів з певним станом, наприклад замороженими. | Native | +| [Право закриття мінта](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/mint-close-authority) | З старою програмою токенів не було можливості закривати мінт. Тепер це можливо. | Native | +| [Багато розширень](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/multiple-extensions) | Показує, як додавати кілька розширень до одного мінта | Native | +| [Вказівник метаданих NFT](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/nft-meta-data-pointer) | Можна використовувати розширення метаданих для створення NFT та додавання динамічних метаданих на ланцюг. | Anchor | +| [Не передаваємий](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/non-transferable/native) | Корисно, наприклад, для досягнень, програм рефералів або будь-яких токенів, які не можна передавати. | Native | +| [Плата за передачу](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/transfer-fees) | Кожна передача токенів утримує певну кількість токенів у акаунті токена, яку потім можна забрати. | Native | +| [Transfer Hook](https://github.com/solana-developers/program-examples/tree/main/tokens/token-2022/transfer-hook) | Чотири приклади для додавання додаткової функціональності до вашого токена за допомогою CPI з програми токенів. | Anchor | ## Break -[Break](https://break.solana.com/) — це додаток на React, який дає користувачам можливість -відчути, наскільки швидко і ефективно працює мережа Solana. Чи зможете ви _зламати_ блокчейн Solana? Протягом 15 секунд кожне натискання кнопки або клавіші -відправляє нову транзакцію в кластер. Ударте по клавіатурі так швидко, як можете, і дивіться, -як ваші транзакції підтверджуються в реальному часі, поки мережа справляється з усім! +[Break](https://break.solana.com/) — це додаток на React, який дає користувачам +можливість відчути, наскільки швидко і ефективно працює мережа Solana. Чи +зможете ви _зламати_ блокчейн Solana? Протягом 15 секунд кожне натискання кнопки +або клавіші відправляє нову транзакцію в кластер. Ударте по клавіатурі так +швидко, як можете, і дивіться, як ваші транзакції підтверджуються в реальному +часі, поки мережа справляється з усім! -Break можна грати на наших мережах Devnet, Testnet та Mainnet Beta. Ігри безкоштовні на Devnet і Testnet, -де сесія фінансується мережевим фонтаном. На Mainnet Beta користувачі платять 0,08 SOL за гру. Сесійний акаунт можна -фінансувати через локальний гаманець keystore або скануючи QR-код з Trust Wallet для -переміщення токенів. +Break можна грати на наших мережах Devnet, Testnet та Mainnet Beta. Ігри +безкоштовні на Devnet і Testnet, де сесія фінансується мережевим фонтаном. На +Mainnet Beta користувачі платять 0,08 SOL за гру. Сесійний акаунт можна +фінансувати через локальний гаманець keystore або скануючи QR-код з Trust Wallet +для переміщення токенів. [Клацніть тут, щоб зіграти в Break](https://break.solana.com/) @@ -142,10 +148,10 @@ Break можна грати на наших мережах Devnet, Testnet та Спочатку отримайте останню версію прикладів коду: - ```shell git clone https://github.com/solana-labs/break.git cd break ``` -Дотримуйтесь кроків у файлі [README](https://github.com/solana-labs/break/blob/main/README.md) репозиторію. +Дотримуйтесь кроків у файлі +[README](https://github.com/solana-labs/break/blob/main/README.md) репозиторію. diff --git a/docs/locales/uk/programs/faq.md b/docs/locales/uk/programs/faq.md index d11a5f914..7514d785e 100644 --- a/docs/locales/uk/programs/faq.md +++ b/docs/locales/uk/programs/faq.md @@ -15,65 +15,68 @@ sidebarSortOrder: 7 [Berkeley Packet Filter (BPF)](https://en.wikipedia.org/wiki/Berkeley_Packet_Filter) байткоду. -Оскільки Solana використовує інфраструктуру компілятора LLVM, програму можна написати -на будь-якій мові програмування, яка підтримує компіляцію в BPF бекенд LLVM. +Оскільки Solana використовує інфраструктуру компілятора LLVM, програму можна +написати на будь-якій мові програмування, яка підтримує компіляцію в BPF бекенд +LLVM. BPF надає ефективний [набір інструкцій](https://github.com/iovisor/bpf-docs/blob/master/eBPF.md), -який можна виконувати в інтерпретованій віртуальній машині або як ефективно згенеровані -нативні інструкції за допомогою just-in-time компіляції. +який можна виконувати в інтерпретованій віртуальній машині або як ефективно +згенеровані нативні інструкції за допомогою just-in-time компіляції. ## Карта пам'яті -Віртуальна адресна карта пам'яті, яку використовують програми Solana SBF, є фіксованою -та має наступне розташування: +Віртуальна адресна карта пам'яті, яку використовують програми Solana SBF, є +фіксованою та має наступне розташування: - Код програми починається з адреси 0x100000000 - Дані стека починаються з адреси 0x200000000 - Дані купи починаються з адреси 0x300000000 - Вхідні параметри програми починаються з адреси 0x400000000 -Вищезазначені віртуальні адреси є початковими адресами, але програми отримують доступ до -підмножини карти пам'яті. Програма викликає паніку, якщо вона намагається читати або -записувати в віртуальну адресу, до якої не було надано доступу, і повертається помилка -`AccessViolation`, яка містить адресу та розмір спроби порушення. +Вищезазначені віртуальні адреси є початковими адресами, але програми отримують +доступ до підмножини карти пам'яті. Програма викликає паніку, якщо вона +намагається читати або записувати в віртуальну адресу, до якої не було надано +доступу, і повертається помилка `AccessViolation`, яка містить адресу та розмір +спроби порушення. ## InvalidAccountData Ця помилка програми може статися з багатьох причин. Зазвичай це викликано передачею акаунта в програму, якого програма не очікує, або через неправильне -положення акаунта в інструкції або акаунт, який не сумісний з виконуваною інструкцією. +положення акаунта в інструкції або акаунт, який не сумісний з виконуваною +інструкцією. -Реалізація програми може також спричинити цю помилку при виконанні -перехресної інструкції між програмами, якщо забули надати акаунт для програми, -яку ви викликаєте. +Реалізація програми може також спричинити цю помилку при виконанні перехресної +інструкції між програмами, якщо забули надати акаунт для програми, яку ви +викликаєте. ## InvalidInstructionData -Ця помилка програми може статися при спробі десеріалізувати інструкцію, перевірте, -чи структура, передана в інструкцію, точно відповідає вимогам програми. Між полями -може бути деяке додаткове заповнення. Якщо програма реалізує трейти Rust `Pack`, спробуйте -упакувати і розпакувати тип інструкції `T`, щоб визначити точне кодування, -яке програма очікує. +Ця помилка програми може статися при спробі десеріалізувати інструкцію, +перевірте, чи структура, передана в інструкцію, точно відповідає вимогам +програми. Між полями може бути деяке додаткове заповнення. Якщо програма +реалізує трейти Rust `Pack`, спробуйте упакувати і розпакувати тип інструкції +`T`, щоб визначити точне кодування, яке програма очікує. ## MissingRequiredSignature -Деякі інструкції вимагають, щоб акаунт був підписантом; ця помилка повертається, якщо -очікується підпис акаунта, але він відсутній. +Деякі інструкції вимагають, щоб акаунт був підписантом; ця помилка повертається, +якщо очікується підпис акаунта, але він відсутній. Реалізація програми може також викликати цю помилку при виконанні -[перехресного виклику програми](/docs/core/cpi.md), який вимагає підписаного адреси програми, -але передані насіння підписувача до `invoke_signed` не збігаються з -насіннями підписувача, що використовуються для створення адреси програми -[`create_program_address`](/docs/core/pda.md#createprogramaddress). +[перехресного виклику програми](/docs/core/cpi.md), який вимагає підписаного +адреси програми, але передані насіння підписувача до `invoke_signed` не +збігаються з насіннями підписувача, що використовуються для створення адреси +програми [`create_program_address`](/docs/core/pda.md#createprogramaddress). ## Стек -SBF використовує стекові кадри замість змінного покажчика стеку. Кожен стековий кадр -має розмір 4 КБ. +SBF використовує стекові кадри замість змінного покажчика стеку. Кожен стековий +кадр має розмір 4 КБ. -Якщо програма порушує розмір цього стекового кадру, компілятор повідомить -про перевищення розміру як попередження. +Якщо програма порушує розмір цього стекового кадру, компілятор повідомить про +перевищення розміру як попередження. Наприклад: @@ -81,82 +84,92 @@ SBF використовує стекові кадри замість змінн Error: Function _ZN16curve25519_dalek7edwards21EdwardsBasepointTable6create17h178b3d2411f7f082E Stack offset of -30728 exceeded max offset of -4096 by 26632 bytes, please minimize large stack variables ``` -Повідомлення вказує, який символ перевищує розмір свого стекового кадру, але ім'я може бути змінене. +Повідомлення вказує, який символ перевищує розмір свого стекового кадру, але +ім'я може бути змінене. -> Щоб деманглювати символ Rust, використовуйте [rustfilt](https://github.com/luser/rustfilt). - -Вищезазначене попередження походить від програми на Rust, тому демангльоване ім'я символу: +> Щоб деманглювати символ Rust, використовуйте +> [rustfilt](https://github.com/luser/rustfilt). +Вищезазначене попередження походить від програми на Rust, тому демангльоване +ім'я символу: ```shell rustfilt _ZN16curve25519_dalek7edwards21EdwardsBasepointTable6create17h178b3d2411f7f082E curve25519_dalek::edwards::EdwardsBasepointTable::create ``` -Причина того, що виводиться попередження, а не помилка, полягає в тому, що деякі залежні -пакети можуть містити функціональність, яка порушує обмеження розміру стекового кадру, навіть -якщо програма не використовує цю функціональність. Якщо програма порушить розмір стеку під час виконання, -то буде виведено помилку `AccessViolation`. -Стекові кадри SBF займають діапазон віртуальних адрес, починаючи з `0x200000000`. +Причина того, що виводиться попередження, а не помилка, полягає в тому, що деякі +залежні пакети можуть містити функціональність, яка порушує обмеження розміру +стекового кадру, навіть якщо програма не використовує цю функціональність. Якщо +програма порушить розмір стеку під час виконання, то буде виведено помилку +`AccessViolation`. + +Стекові кадри SBF займають діапазон віртуальних адрес, починаючи з +`0x200000000`. ## Розмір купи Програми мають доступ до купи часу виконання через API Rust `alloc`. Для -швидкого виділення пам'яті використовується проста купа на 32 КБ. Куча не підтримує -`free` або `realloc`. +швидкого виділення пам'яті використовується проста купа на 32 КБ. Куча не +підтримує `free` або `realloc`. -Програми мають доступ до пам'яті об'ємом 32 КБ, починаючи з віртуальної -адреси 0x300000000, і можуть реалізувати власну купу на основі специфічних потреб програми. +Програми мають доступ до пам'яті об'ємом 32 КБ, починаючи з віртуальної адреси +0x300000000, і можуть реалізувати власну купу на основі специфічних потреб +програми. Програми на Rust реалізують купу безпосередньо, визначаючи власний [`global_allocator`](https://github.com/solana-labs/solana/blob/d9b0fc0e3eec67dfe4a97d9298b15969b2804fab/sdk/program/src/entrypoint.rs#L72) ## Завантажувачі -Програми розгортаються і виконуються через завантажувачі часу виконання, наразі підтримуються -два завантажувачі: +Програми розгортаються і виконуються через завантажувачі часу виконання, наразі +підтримуються два завантажувачі: + - [BPF Loader](https://github.com/solana-labs/solana/blob/7ddf10e602d2ed87a9e3737aa8c32f1db9f909d8/sdk/program/src/bpf_loader.rs#L17) - [BPF loader (deprecated)](https://github.com/solana-labs/solana/blob/7ddf10e602d2ed87a9e3737aa8c32f1db9f909d8/sdk/program/src/bpf_loader_deprecated.rs#L14) -Завантажувачі можуть підтримувати різні інтерфейси бінарних додатків, тому розробники повинні -пишуть свої програми для одного завантажувача і розгортають їх на тому ж завантажувачі. Якщо програма, -написана для одного завантажувача, буде розгорнута на іншому, це зазвичай призведе до -помилки `AccessViolation` через невідповідність десеріалізації вхідних параметрів програми. +Завантажувачі можуть підтримувати різні інтерфейси бінарних додатків, тому +розробники повинні пишуть свої програми для одного завантажувача і розгортають +їх на тому ж завантажувачі. Якщо програма, написана для одного завантажувача, +буде розгорнута на іншому, це зазвичай призведе до помилки `AccessViolation` +через невідповідність десеріалізації вхідних параметрів програми. -Для практичних цілей програми завжди повинні бути написані для останнього -BPF завантажувача, і останній завантажувач є за умовчанням для інтерфейсу командного рядка -та JavaScript API. +Для практичних цілей програми завжди повинні бути написані для останнього BPF +завантажувача, і останній завантажувач є за умовчанням для інтерфейсу командного +рядка та JavaScript API. - [Точки входу програми Rust](/docs/programs/lang-rust.md#program-entrypoint) ### Розгортання -Розгортання програми SBF — це процес завантаження спільного об'єкта BPF в -дані акаунта програми та позначення акаунта як виконуваного. Клієнт розбиває -спільний об'єкт SBF на менші частини і надсилає їх як дані інструкцій +Розгортання програми SBF — це процес завантаження спільного об'єкта BPF в дані +акаунта програми та позначення акаунта як виконуваного. Клієнт розбиває спільний +об'єкт SBF на менші частини і надсилає їх як дані інструкцій [`Write`](https://github.com/solana-labs/solana/blob/bc7133d7526a041d1aaee807b80922baa89b6f90/sdk/program/src/loader_instruction.rs#L13) -до завантажувача, де завантажувач записує ці дані в акаунт програми. -Якщо всі частини отримані, клієнт надсилає +до завантажувача, де завантажувач записує ці дані в акаунт програми. Якщо всі +частини отримані, клієнт надсилає [`Finalize`](https://github.com/solana-labs/solana/blob/bc7133d7526a041d1aaee807b80922baa89b6f90/sdk/program/src/loader_instruction.rs#L30) -інструкцію до завантажувача, завантажувач потім перевіряє, чи є дані SBF дійсними -і позначає акаунт програми як _виконуваний_. Після того, як акаунт програми -буде позначено як виконуваний, подальші транзакції можуть видавати інструкції для цієї -програми для обробки. +інструкцію до завантажувача, завантажувач потім перевіряє, чи є дані SBF +дійсними і позначає акаунт програми як _виконуваний_. Після того, як акаунт +програми буде позначено як виконуваний, подальші транзакції можуть видавати +інструкції для цієї програми для обробки. -Коли інструкція спрямована до виконуваної програми SBF, завантажувач -конфігурує середовище виконання програми, серіалізує вхідні параметри програми, -викликає точку входу програми і повідомляє про будь-які помилки. +Коли інструкція спрямована до виконуваної програми SBF, завантажувач конфігурує +середовище виконання програми, серіалізує вхідні параметри програми, викликає +точку входу програми і повідомляє про будь-які помилки. -Додаткову інформацію див. в розділі [розгортання програм](/docs/programs/deploying.md). +Додаткову інформацію див. в розділі +[розгортання програм](/docs/programs/deploying.md). ### Серіалізація вхідних параметрів -Завантажувачі SBF серіалізують вхідні параметри програми в масив байтів, який потім передається -в точку входу програми, де програма відповідає за їх десеріалізацію на ланцюгу. Одна з змін між -депрецованим завантажувачем і поточним полягає в тому, що вхідні параметри серіалізуються так, -що різні параметри потрапляють на вирівняні офсети в межах вирівняного байтового -масиву. Це дозволяє реалізаціям десеріалізації безпосередньо посилатися на -байтовий масив і надавати вирівняні вказівники до програми. +Завантажувачі SBF серіалізують вхідні параметри програми в масив байтів, який +потім передається в точку входу програми, де програма відповідає за їх +десеріалізацію на ланцюгу. Одна з змін між депрецованим завантажувачем і +поточним полягає в тому, що вхідні параметри серіалізуються так, що різні +параметри потрапляють на вирівняні офсети в межах вирівняного байтового масиву. +Це дозволяє реалізаціям десеріалізації безпосередньо посилатися на байтовий +масив і надавати вирівняні вказівники до програми. - [Десеріалізація параметрів програми на Rust](/docs/programs/lang-rust.md#parameter-deserialization) @@ -165,8 +178,8 @@ BPF завантажувача, і останній завантажувач є - 8 байт беззнакового числа акаунтів - Для кожного акаунта: - - 1 байт, що вказує, чи є цей акаунт дублікатом, якщо ні — значення 0xff, - в іншому випадку значення — це індекс акаунта, з яким він є дублікатом. + - 1 байт, що вказує, чи є цей акаунт дублікатом, якщо ні — значення 0xff, в + іншому випадку значення — це індекс акаунта, з яким він є дублікатом. - Якщо дублікати: 7 байт заповнювальної пам'яті - Якщо не дублікати: - 1 байт булевого типу, true, якщо акаунт є підписантом diff --git a/docs/locales/uk/programs/limitations.md b/docs/locales/uk/programs/limitations.md index a2e33411f..955549850 100644 --- a/docs/locales/uk/programs/limitations.md +++ b/docs/locales/uk/programs/limitations.md @@ -3,15 +3,20 @@ title: "Обмеження" sidebarSortOrder: 6 --- -Розробка програм на блокчейні Solana має деякі вроджені обмеження. Нижче наведено список поширених обмежень, з якими ви можете зіткнутися. +Розробка програм на блокчейні Solana має деякі вроджені обмеження. Нижче +наведено список поширених обмежень, з якими ви можете зіткнутися. ## Бібліотеки Rust -Оскільки програми Rust на блокчейні повинні бути детермінованими і виконуватись у середовищі з обмеженими ресурсами та одночасною обробкою, вони мають деякі обмеження щодо використання бібліотек. +Оскільки програми Rust на блокчейні повинні бути детермінованими і виконуватись +у середовищі з обмеженими ресурсами та одночасною обробкою, вони мають деякі +обмеження щодо використання бібліотек. -Програми Rust на блокчейні підтримують більшість бібліотек Rust, таких як libstd, libcore, liballoc, а також багато сторонніх бібліотек. +Програми Rust на блокчейні підтримують більшість бібліотек Rust, таких як +libstd, libcore, liballoc, а також багато сторонніх бібліотек. -Проте існують певні обмеження через обмежені ресурси середовища та необхідність детермінованості: +Проте існують певні обмеження через обмежені ресурси середовища та необхідність +детермінованості: - Немає доступу до: - `rand` @@ -28,41 +33,62 @@ sidebarSortOrder: 6 - `std::os` - Використання Bincode є дуже ресурсомістким і його слід уникати. - Форматування рядків також є ресурсомістким і повинно бути мінімізоване. -- Відсутня підтримка для `println!` та `print!`, замість цього використовуйте макрос +- Відсутня підтримка для `println!` та `print!`, замість цього використовуйте + макрос [`msg!`](https://github.com/solana-labs/solana/blob/d9b0fc0e3eec67dfe4a97d9298b15969b2804fab/sdk/program/src/log.rs#L33). -- Під час виконання встановлено обмеження на кількість інструкцій, які програма може виконати під час обробки однієї інструкції. Дивіться [бюджет обчислень](/docs/core/fees.md#compute-budget) для більш детальної інформації. +- Під час виконання встановлено обмеження на кількість інструкцій, які програма + може виконати під час обробки однієї інструкції. Дивіться + [бюджет обчислень](/docs/core/fees.md#compute-budget) для більш детальної + інформації. ## Бюджет обчислень -Для запобігання зловживанню обчислювальними ресурсами блокчейну кожна транзакція отримує [бюджет обчислень](/docs/terminology.md#compute-budget). Перевищення цього бюджету призведе до провалу транзакції. +Для запобігання зловживанню обчислювальними ресурсами блокчейну кожна транзакція +отримує [бюджет обчислень](/docs/terminology.md#compute-budget). Перевищення +цього бюджету призведе до провалу транзакції. -Дивіться документацію про [обмеження обчислень](/docs/core/fees.md#compute-budget) для більш детальної інформації. +Дивіться документацію про +[обмеження обчислень](/docs/core/fees.md#compute-budget) для більш детальної +інформації. ## Глибина стеку викликів — помилка `CallDepthExceeded` Програми Solana мають обмежену глибину стеку викликів до **64 кадрів**. -Якщо програма перевищує дозволену глибину стеку викликів, вона отримує помилку `CallDepthExceeded`. +Якщо програма перевищує дозволену глибину стеку викликів, вона отримує помилку +`CallDepthExceeded`. ## Глибина викликів CPI — помилка `CallDepth` -Перехресні виклики між програмами дозволяють програмам викликати інші програми безпосередньо, але наразі глибина обмежена до `4`. +Перехресні виклики між програмами дозволяють програмам викликати інші програми +безпосередньо, але наразі глибина обмежена до `4`. -Якщо програма перевищує дозволену [глибину викликів між програмами](/docs/core/cpi.md), вона отримує помилку `CallDepth`. +Якщо програма перевищує дозволену +[глибину викликів між програмами](/docs/core/cpi.md), вона отримує помилку +`CallDepth`. ## Підтримка типів float у Rust -Програми підтримують обмежений набір операцій із типами float у Rust. Якщо програма намагається використовувати операцію із float, яка не підтримується, виконання викликає помилку про нерозв’язаний символ. +Програми підтримують обмежений набір операцій із типами float у Rust. Якщо +програма намагається використовувати операцію із float, яка не підтримується, +виконання викликає помилку про нерозв’язаний символ. -Операції із float виконуються через програмні бібліотеки (LLVM's float built-ins) і споживають більше обчислювальних одиниць, ніж операції з цілими числами. Загалом рекомендується використовувати фіксовану точку там, де це можливо. +Операції із float виконуються через програмні бібліотеки (LLVM's float +built-ins) і споживають більше обчислювальних одиниць, ніж операції з цілими +числами. Загалом рекомендується використовувати фіксовану точку там, де це +можливо. -[Математичні тести Solana Program Library](https://github.com/solana-labs/solana-program-library/tree/master/libraries/math) демонструють продуктивність деяких математичних операцій. Для запуску тесту синхронізуйте репозиторій і виконайте: +[Математичні тести Solana Program Library](https://github.com/solana-labs/solana-program-library/tree/master/libraries/math) +демонструють продуктивність деяких математичних операцій. Для запуску тесту +синхронізуйте репозиторій і виконайте: ```shell cargo test-sbf -- --nocapture --test-threads=1 ``` -Недавні результати показують, що операції із float споживають більше інструкцій порівняно з еквівалентами для цілих чисел. Реалізації з фіксованою точкою також будуть менш ресурсомісткими, ніж float: +Недавні результати показують, що операції із float споживають більше інструкцій +порівняно з еквівалентами для цілих чисел. Реалізації з фіксованою точкою також +будуть менш ресурсомісткими, ніж float: ```text u64 f32 @@ -72,7 +98,11 @@ Divide 9 219 ## Статичні змінні, які можна змінювати -Спільні об’єкти програм не підтримують змінювані спільні дані. Програми спільно використовують один і той самий код та дані лише для читання, що означає, що розробники не повинні включати статичні змінювані або глобальні змінні в програми. У майбутньому може бути додано механізм копіювання при записі для підтримки змінюваних даних. +Спільні об’єкти програм не підтримують змінювані спільні дані. Програми спільно +використовують один і той самий код та дані лише для читання, що означає, що +розробники не повинні включати статичні змінювані або глобальні змінні в +програми. У майбутньому може бути додано механізм копіювання при записі для +підтримки змінюваних даних. ## Ділення зі знаком diff --git a/docs/locales/uk/programs/rust/index.md b/docs/locales/uk/programs/rust/index.md index bfc459af9..16c3c79c3 100644 --- a/docs/locales/uk/programs/rust/index.md +++ b/docs/locales/uk/programs/rust/index.md @@ -1,28 +1,31 @@ --- title: Розробка програм на Rust description: - Дізнайтеся, як розробляти програми для Solana, використовуючи Rust, включаючи покрокові - інструкції для створення, збірки, тестування та розгортання смарт-контрактів на - блокчейні Solana. + Дізнайтеся, як розробляти програми для Solana, використовуючи Rust, включаючи + покрокові інструкції для створення, збірки, тестування та розгортання + смарт-контрактів на блокчейні Solana. sidebarLabel: Програми на Rust sidebarSortOrder: 1 altRoutes: - /docs/programs/lang-rust --- -Програми для Solana в основному розробляються за допомогою мови програмування Rust. -Ця сторінка зосереджена на написанні програм для Solana на Rust без використання фреймворку Anchor, -метод, який часто називають написанням "рідних програм на Rust". +Програми для Solana в основному розробляються за допомогою мови програмування +Rust. Ця сторінка зосереджена на написанні програм для Solana на Rust без +використання фреймворку Anchor, метод, який часто називають написанням "рідних +програм на Rust". Розробка рідних програм на Rust дає розробникам повний контроль над їхніми програмами для Solana. Однак цей підхід вимагає більше ручної налаштування та -шаблонного коду порівняно з використанням фреймворку Anchor. Цей метод рекомендований для розробників, які: +шаблонного коду порівняно з використанням фреймворку Anchor. Цей метод +рекомендований для розробників, які: - Шукають детальний контроль над логікою програми та оптимізаціями -- Хочуть зрозуміти основні концепції, перш ніж переходити до фреймворків вищого рівня +- Хочуть зрозуміти основні концепції, перш ніж переходити до фреймворків вищого + рівня -Для початківців ми рекомендуємо почати з фреймворку Anchor. Для отримання додаткової інформації див. розділ -[Anchor](/docs/programs/anchor). +Для початківців ми рекомендуємо почати з фреймворку Anchor. Для отримання +додаткової інформації див. розділ [Anchor](/docs/programs/anchor). ## Попередні вимоги @@ -36,37 +39,38 @@ altRoutes: ## Початок роботи -Наведений приклад охоплює основні кроки для створення вашої першої програми для Solana, -написаної на Rust. Ми створимо мінімальну програму, яка виводить "Hello, world!" в -журнали програми. +Наведений приклад охоплює основні кроки для створення вашої першої програми для +Solana, написаної на Rust. Ми створимо мінімальну програму, яка виводить "Hello, +world!" в журнали програми. ### Створення нової програми -Спочатку створіть новий проект на Rust, використовуючи стандартну команду `cargo init` з -прапорцем `--lib`. +Спочатку створіть новий проект на Rust, використовуючи стандартну команду +`cargo init` з прапорцем `--lib`. ```shell filename="Terminal" cargo init hello_world --lib ``` -Перейдіть до директорії проекту. Ви повинні побачити стандартні файли `src/lib.rs` та -`Cargo.toml`. +Перейдіть до директорії проекту. Ви повинні побачити стандартні файли +`src/lib.rs` та `Cargo.toml`. ```shell filename="Terminal" cd hello_world ``` -Далі додайте залежність `solana-program`. Це мінімальна залежність, -необхідна для побудови програми Solana. +Далі додайте залежність `solana-program`. Це мінімальна залежність, необхідна +для побудови програми Solana. ```shell filename="Terminal" cargo add solana-program@1.18.26 ``` Далі додайте наступний фрагмент до файлу `Cargo.toml`. Якщо ви не включите цю -конфігурацію, директорія `target/deploy` не буде згенерована під час збірки програми. +конфігурацію, директорія `target/deploy` не буде згенерована під час збірки +програми. ```toml filename="Cargo.toml" [lib] @@ -88,9 +92,12 @@ crate-type = ["cdylib", "lib"] solana-program = "1.18.26" ``` -Далі замініть вміст файлу `src/lib.rs` на наступний код. Це мінімальна програма для Solana, яка виводить "Hello, world!" в журнал програми, коли програма викликається. +Далі замініть вміст файлу `src/lib.rs` на наступний код. Це мінімальна програма +для Solana, яка виводить "Hello, world!" в журнал програми, коли програма +викликається. -Макрос `msg!` використовується в програмах Solana для виведення повідомлення в журнал програми. +Макрос `msg!` використовується в програмах Solana для виведення повідомлення в +журнал програми. ```rs filename="lib.rs" use solana_program::{ @@ -121,11 +128,11 @@ cargo build-sbf 1. Файл `.so` (наприклад, `hello_world.so`): Це зкомпільована програма Solana, яка буде розгорнута в мережі як "смарт-контракт". -2. Файл ключової пари (наприклад, `hello_world-keypair.json`): Публічний ключ цієї - ключової пари використовується як ID програми при розгортанні програми. +2. Файл ключової пари (наприклад, `hello_world-keypair.json`): Публічний ключ + цієї ключової пари використовується як ID програми при розгортанні програми. -Щоб переглянути ID програми, виконайте наступну команду у вашому терміналі. Ця команда -виводить публічний ключ ключової пари за вказаним шляхом до файлу: +Щоб переглянути ID програми, виконайте наступну команду у вашому терміналі. Ця +команда виводить публічний ключ ключової пари за вказаним шляхом до файлу: ```shell filename="Terminal" solana address -k ./target/deploy/hello_world-keypair.json @@ -139,8 +146,8 @@ Example output: ### Тестування програми -Далі протестуйте програму за допомогою crate `solana-program-test`. Додайте наступні -залежності до файлу `Cargo.toml`. +Далі протестуйте програму за допомогою crate `solana-program-test`. Додайте +наступні залежності до файлу `Cargo.toml`. ```shell filename="Terminal" cargo add solana-program-test@1.18.26 --dev @@ -181,8 +188,8 @@ mod test { } ``` -Запустіть тест за допомогою команди `cargo test-sbf`. У журналі програми буде виведено -"Hello, world!". +Запустіть тест за допомогою команди `cargo test-sbf`. У журналі програми буде +виведено "Hello, world!". ```shell filename="Terminal" cargo test-sbf @@ -223,8 +230,8 @@ Keypair Path: /.config/solana/id.json Commitment: confirmed ``` -Відкрийте новий термінал і виконайте команду `solana-test-validator`, щоб запустити -локальний валідатор. +Відкрийте новий термінал і виконайте команду `solana-test-validator`, щоб +запустити локальний валідатор. ```shell filename="Terminal" solana-test-validator @@ -247,8 +254,9 @@ Signature: Ви можете перевірити ID програми та підпис транзакції на [Solana Explorer](https://explorer.solana.com/?cluster=custom&customUrl=http%3A%2F%2Flocalhost%3A8899). -Зверніть увагу, що кластер на Solana Explorer також повинен бути localhost. Опція "Custom RPC -URL" на Solana Explorer за замовчуванням встановлюється на `http://localhost:8899`. +Зверніть увагу, що кластер на Solana Explorer також повинен бути localhost. +Опція "Custom RPC URL" на Solana Explorer за замовчуванням встановлюється на +`http://localhost:8899`. ### Виклик програми @@ -276,7 +284,8 @@ cargo add solana-client@1.18.26 --dev ``` Додайте наступний код до файлу `examples/client.rs`. Це Rust клієнтський скрипт, -який фінансує нову ключову пару для оплати зборів за транзакцію і потім викликає програму hello world. +який фінансує нову ключову пару для оплати зборів за транзакцію і потім викликає +програму hello world. ```rs filename="example/client.rs" use solana_client::rpc_client::RpcClient; @@ -334,7 +343,8 @@ async fn main() { } ``` -Перед виконанням скрипту замініть ID програми в наведеному коді на той, що відповідає вашій програмі. +Перед виконанням скрипту замініть ID програми в наведеному коді на той, що +відповідає вашій програмі. Ви можете отримати свій ID програми, виконавши наступну команду. @@ -369,8 +379,9 @@ Transaction Signature: 54TWxKi3Jsi3UTeZbhLGUFX6JQH7TspRJjRRFZ8NFnwG5BXM9udxiX77b ### Оновлення програми -Програми Solana можна оновити, повторно розгорнувши їх на той самий ID програми. Оновіть -програму в `src/lib.rs`, щоб виводити "Hello, Solana!" замість "Hello, world!". +Програми Solana можна оновити, повторно розгорнувши їх на той самий ID програми. +Оновіть програму в `src/lib.rs`, щоб виводити "Hello, Solana!" замість "Hello, +world!". ```diff filename="lib.rs" pub fn process_instruction( @@ -428,7 +439,8 @@ cargo run --example client Ви можете закрити свою програму Solana, щоб повернути SOL, виділені для акаунту. Закриття програми є незворотним, тому це слід робити обережно. -Щоб закрити програму, використовуйте команду `solana program close `. Наприклад: +Щоб закрити програму, використовуйте команду +`solana program close `. Наприклад: ```shell filename="Terminal" solana program close 4Ujf5fXfLx2PAwRqcECCLtgDxHKPznoJpa43jUBxFfMz @@ -442,21 +454,25 @@ Closed Program Id 4Ujf5fXfLx2PAwRqcECCLtgDxHKPznoJpa43jUBxFfMz, 0.1350588 SOL reclaimed ``` -Зверніть увагу, що після закриття програми її ID програми не можна буде використовувати знову. Спроба розгорнути програму з раніше закритим ID програми призведе до помилки. +Зверніть увагу, що після закриття програми її ID програми не можна буде +використовувати знову. Спроба розгорнути програму з раніше закритим ID програми +призведе до помилки. ``` Error: Program 4Ujf5fXfLx2PAwRqcECCLtgDxHKPznoJpa43jUBxFfMz has been closed, use a new Program Id ``` -Якщо вам потрібно повторно розгорнути програму з тим самим вихідним кодом після закриття програми, ви повинні згенерувати новий ID програми. Щоб згенерувати нову ключову пару для програми, виконайте наступну команду: +Якщо вам потрібно повторно розгорнути програму з тим самим вихідним кодом після +закриття програми, ви повинні згенерувати новий ID програми. Щоб згенерувати +нову ключову пару для програми, виконайте наступну команду: ```shell filename="Terminal" solana-keygen new -o ./target/deploy/hello_world-keypair.json --force ``` Альтернативно, ви можете видалити існуючий файл ключової пари (наприклад, -`./target/deploy/hello_world-keypair.json`) і знову виконати команду `cargo build-sbf`, -що згенерує новий файл ключової пари. +`./target/deploy/hello_world-keypair.json`) і знову виконати команду +`cargo build-sbf`, що згенерує новий файл ключової пари. diff --git a/docs/locales/uk/programs/rust/program-structure.md b/docs/locales/uk/programs/rust/program-structure.md index 96955bdbf..e8d172094 100644 --- a/docs/locales/uk/programs/rust/program-structure.md +++ b/docs/locales/uk/programs/rust/program-structure.md @@ -2,14 +2,14 @@ title: Структура програми на Rust sidebarLabel: Структура програми description: - Дізнайтесь, як структуровані програми Solana на Rust, включаючи точки входу, управління станом, - обробку інструкцій та тестування. + Дізнайтесь, як структуровані програми Solana на Rust, включаючи точки входу, + управління станом, обробку інструкцій та тестування. sidebarSortOrder: 1 --- Програми Solana, написані на Rust, мають мінімальні вимоги до структури, що дає -гнучкість у тому, як організовувати код. Єдина вимога — програма повинна мати `entrypoint`, -який визначає точку початку виконання програми. +гнучкість у тому, як організовувати код. Єдина вимога — програма повинна мати +`entrypoint`, який визначає точку початку виконання програми. ## Структура програми @@ -28,14 +28,16 @@ sidebarSortOrder: 1 ## Приклад програми -Щоб продемонструвати, як побудувати рідну програму на Rust з кількома інструкціями, -ми розглянемо просту програму лічильника, яка реалізує дві інструкції: +Щоб продемонструвати, як побудувати рідну програму на Rust з кількома +інструкціями, ми розглянемо просту програму лічильника, яка реалізує дві +інструкції: -1. `InitializeCounter`: Створює і ініціалізує новий акаунт з початковим значенням. +1. `InitializeCounter`: Створює і ініціалізує новий акаунт з початковим + значенням. 2. `IncrementCounter`: Збільшує значення, що зберігається в існуючому акаунті. -Для простоти програма буде реалізована в одному файлі `lib.rs`, -хоча на практиці вам, можливо, захочеться розділити більші програми на кілька файлів. +Для простоти програма буде реалізована в одному файлі `lib.rs`, хоча на практиці +вам, можливо, захочеться розділити більші програми на кілька файлів. @@ -315,28 +317,30 @@ tokio = "1.41.0" ### Створення нової програми -Спочатку створіть новий проект на Rust, використовуючи стандартну команду `cargo init` з прапорцем `--lib`. +Спочатку створіть новий проект на Rust, використовуючи стандартну команду +`cargo init` з прапорцем `--lib`. ```shell filename="Terminal" cargo init counter_program --lib ``` -Перейдіть до директорії проекту. Ви повинні побачити стандартні файли `src/lib.rs` та -`Cargo.toml`. +Перейдіть до директорії проекту. Ви повинні побачити стандартні файли +`src/lib.rs` та `Cargo.toml`. ```shell filename="Terminal" cd counter_program ``` -Далі додайте залежність `solana-program`. Це мінімальна залежність, -необхідна для побудови програми Solana. +Далі додайте залежність `solana-program`. Це мінімальна залежність, необхідна +для побудови програми Solana. ```shell filename="Terminal" cargo add solana-program@1.18.26 ``` Далі додайте наступний фрагмент до файлу `Cargo.toml`. Якщо ви не включите цю -конфігурацію, директорія `target/deploy` не буде згенерована під час збірки програми. +конфігурацію, директорія `target/deploy` не буде згенерована під час збірки +програми. ```toml filename="Cargo.toml" [lib] @@ -361,8 +365,8 @@ solana-program = "1.18.26" ### Точка входу програми Точка входу програми Solana — це функція, яка викликається, коли програма -активується. Точка входу має наступне сире визначення, і розробники можуть створювати власну -реалізацію функції точки входу. +активується. Точка входу має наступне сире визначення, і розробники можуть +створювати власну реалізацію функції точки входу. Для простоти використовуйте макрос [`entrypoint!`](https://github.com/solana-labs/solana/blob/v2.0/sdk/program/src/entrypoint.rs#L124-L140) @@ -422,24 +426,32 @@ pub type ProcessInstruction = - `program_id`: Публічний ключ викликаної програми (поточна програма) - `accounts`: `AccountInfo` для акаунтів, необхідних для викликаної інструкції -- `instruction_data`: Додаткові дані, передані програмі, які вказують інструкцію для виконання та її необхідні аргументи +- `instruction_data`: Додаткові дані, передані програмі, які вказують інструкцію + для виконання та її необхідні аргументи Ці три параметри безпосередньо відповідають даним, які клієнти повинні надати при побудові інструкції для виклику програми. ### Визначення стану програми -При створенні програми Solana зазвичай починають з визначення стану програми — даних, які будуть зберігатися в акаунтах, створених і належних вашій програмі. +При створенні програми Solana зазвичай починають з визначення стану програми — +даних, які будуть зберігатися в акаунтах, створених і належних вашій програмі. -Стан програми визначається за допомогою структур Rust, які представляють макет даних акаунтів програми. Ви можете визначити кілька структур для представлення різних типів акаунтів вашої програми. +Стан програми визначається за допомогою структур Rust, які представляють макет +даних акаунтів програми. Ви можете визначити кілька структур для представлення +різних типів акаунтів вашої програми. -При роботі з акаунтами вам потрібен спосіб перетворювати типи даних вашої програми в і з сирих байтів, що зберігаються в полі даних акаунту: +При роботі з акаунтами вам потрібен спосіб перетворювати типи даних вашої +програми в і з сирих байтів, що зберігаються в полі даних акаунту: -- Серіалізація: Перетворення ваших типів даних у байти для збереження в полі даних акаунту -- Десеріалізація: Перетворення байтів, збережених в акаунті, назад у ваші типи даних +- Серіалізація: Перетворення ваших типів даних у байти для збереження в полі + даних акаунту +- Десеріалізація: Перетворення байтів, збережених в акаунті, назад у ваші типи + даних -Хоча ви можете використовувати будь-який формат серіалізації для розробки програм Solana, -[Borsh](https://borsh.io/) є загальноприйнятим. Щоб використовувати Borsh у вашій програмі Solana: +Хоча ви можете використовувати будь-який формат серіалізації для розробки +програм Solana, [Borsh](https://borsh.io/) є загальноприйнятим. Щоб +використовувати Borsh у вашій програмі Solana: 1. Додайте crate `borsh` як залежність до вашого `Cargo.toml`: @@ -447,8 +459,8 @@ pub type ProcessInstruction = cargo add borsh ``` -2. Імпортуйте трейди Borsh і використовуйте макрос `derive`, щоб реалізувати трейди для - ваших структур: +2. Імпортуйте трейди Borsh і використовуйте макрос `derive`, щоб реалізувати + трейди для ваших структур: ```rust use borsh::{BorshSerialize, BorshDeserialize}; @@ -460,8 +472,9 @@ pub struct CounterAccount { } ``` -Додайте структуру `CounterAccount` до файлу `lib.rs` для визначення стану програми. Ця -структура буде використовуватися як в інструкції ініціалізації, так і в інструкції збільшення. +Додайте структуру `CounterAccount` до файлу `lib.rs` для визначення стану +програми. Ця структура буде використовуватися як в інструкції ініціалізації, так +і в інструкції збільшення. ```rs filename="lib.rs" {12} {25-29} use solana_program::{ @@ -496,7 +509,9 @@ pub struct CounterAccount { ### Визначення інструкцій -Інструкції позначають різні операції, які ваша програма Solana може виконувати. Вважайте їх публічними API вашої програми — вони визначають, які дії користувачі можуть виконувати при взаємодії з вашою програмою. +Інструкції позначають різні операції, які ваша програма Solana може виконувати. +Вважайте їх публічними API вашої програми — вони визначають, які дії користувачі +можуть виконувати при взаємодії з вашою програмою. Інструкції зазвичай визначаються за допомогою enum на Rust, де: @@ -515,12 +530,14 @@ pub enum CounterInstruction { } ``` -Коли клієнт викликає вашу програму, він повинен надати дані інструкції (як буфер байтів), де: +Коли клієнт викликає вашу програму, він повинен надати дані інструкції (як буфер +байтів), де: - Перший байт вказує, який варіант інструкції потрібно виконати (0, 1 і т.д.) - Решта байтів містить серіалізовані параметри інструкції (якщо це необхідно) -Для перетворення даних інструкції (байтів) у варіант enum зазвичай реалізують допоміжний метод. Цей метод: +Для перетворення даних інструкції (байтів) у варіант enum зазвичай реалізують +допоміжний метод. Цей метод: 1. Розділяє перший байт, щоб отримати варіант інструкції 2. Зіставляє варіант і парсить будь-які додаткові параметри з решти байтів @@ -553,7 +570,8 @@ impl CounterInstruction { } ``` -Додайте наступний код до файлу `lib.rs` для визначення інструкцій для програми лічильника. +Додайте наступний код до файлу `lib.rs` для визначення інструкцій для програми +лічильника. ```rs filename="lib.rs" {18-46} use borsh::{BorshDeserialize, BorshSerialize}; @@ -605,12 +623,14 @@ impl CounterInstruction { ### Обробники інструкцій -Обробники інструкцій — це функції, які містять бізнес-логіку для кожної інструкції. Зазвичай функції обробників називаються як -`process_`, але ви вільні вибрати будь-яку конвенцію найменувань. +Обробники інструкцій — це функції, які містять бізнес-логіку для кожної +інструкції. Зазвичай функції обробників називаються як +`process_`, але ви вільні вибрати будь-яку конвенцію +найменувань. -Додайте наступний код до файлу `lib.rs`. Цей код використовує enum `CounterInstruction` -та метод `unpack`, визначений на попередньому кроці, для маршрутизації вхідних інструкцій -до відповідних функцій обробників: +Додайте наступний код до файлу `lib.rs`. Цей код використовує enum +`CounterInstruction` та метод `unpack`, визначений на попередньому кроці, для +маршрутизації вхідних інструкцій до відповідних функцій обробників: ```rs filename="lib.rs" {8-17} {20-32} /process_initialize_counter/1 /process_increment_counter/1 entrypoint!(process_instruction); @@ -647,8 +667,8 @@ fn process_increment_counter(program_id: &Pubkey, accounts: &[AccountInfo]) -> P } ``` -Далі додайте реалізацію функції `process_initialize_counter`. Цей -обробник інструкції: +Далі додайте реалізацію функції `process_initialize_counter`. Цей обробник +інструкції: 1. Створює і виділяє місце для нового акаунту для збереження даних лічильника 2. Ініціалізує дані акаунту з `initial_value`, переданим в інструкцію @@ -663,13 +683,13 @@ fn process_increment_counter(program_id: &Pubkey, accounts: &[AccountInfo]) -> P 3. System Program, який ми викликаємо для створення нового акаунту Для визначення акаунтів, необхідних для інструкції, ми створюємо ітератор по -масиву `accounts` та використовуємо функцію `next_account_info`, щоб отримати кожен -акаунт. Кількість акаунтів, яку ви визначаєте, є кількістю акаунтів, необхідних для -інструкції. +масиву `accounts` та використовуємо функцію `next_account_info`, щоб отримати +кожен акаунт. Кількість акаунтів, яку ви визначаєте, є кількістю акаунтів, +необхідних для інструкції. Порядок акаунтів має значення — при побудові інструкції на стороні клієнта, -акаунти повинні надаватися в тому ж порядку, в якому вони визначені в -програмі, щоб інструкція виконалася успішно. +акаунти повинні надаватися в тому ж порядку, в якому вони визначені в програмі, +щоб інструкція виконалася успішно. Хоча змінні імена акаунтів не впливають на функціональність програми, рекомендується використовувати описові імена. @@ -692,9 +712,12 @@ fn process_initialize_counter( Перед створенням акаунту нам потрібно: -1. Вказати простір (у байтах), який потрібно виділити для поля даних акаунту. Оскільки ми зберігаємо значення типу u64 (`count`), нам потрібно 8 байтів. +1. Вказати простір (у байтах), який потрібно виділити для поля даних акаунту. + Оскільки ми зберігаємо значення типу u64 (`count`), нам потрібно 8 байтів. -2. Обчислити мінімальний баланс "ренту", необхідний для акаунту. На Solana акаунти повинні підтримувати мінімальний баланс лампортів (ренту), що залежить від кількості даних, що зберігаються в акаунті. +2. Обчислити мінімальний баланс "ренту", необхідний для акаунту. На Solana + акаунти повинні підтримувати мінімальний баланс лампортів (ренту), що + залежить від кількості даних, що зберігаються в акаунті. ```rs filename="lib.rs" {12-17} fn process_initialize_counter( @@ -722,22 +745,23 @@ fn process_initialize_counter( Після того, як простір визначено і рент обчислений, створіть акаунт, викликавши інструкцію `create_account` з System Program. -На Solana нові акаунти можуть бути створені тільки через System Program. При створенні -акаунту ми вказуємо кількість байтів для виділення та програму-власника -нового акаунту. System Program: +На Solana нові акаунти можуть бути створені тільки через System Program. При +створенні акаунту ми вказуємо кількість байтів для виділення та +програму-власника нового акаунту. System Program: 1. Створює новий акаунт 2. Виділяє вказаний простір для поля даних акаунту 3. Передає право власності на вказану програму -Цей перехід права власності важливий, оскільки тільки власник акаунту може змінювати -дані акаунту. У цьому випадку ми встановлюємо нашу програму як власника, що дозволить нам змінювати -дані акаунту для збереження значення лічильника. +Цей перехід права власності важливий, оскільки тільки власник акаунту може +змінювати дані акаунту. У цьому випадку ми встановлюємо нашу програму як +власника, що дозволить нам змінювати дані акаунту для збереження значення +лічильника. Щоб викликати System Program з інструкції нашої програми, ми робимо Cross Program Invocation (CPI) через функцію `invoke`. CPI дозволяє одній програмі -викликати інструкції інших програм — в цьому випадку інструкцію `create_account` з System Program. - +викликати інструкції інших програм — в цьому випадку інструкцію `create_account` +з System Program. ```rs filename="lib.rs" {19-33} fn process_initialize_counter( @@ -780,10 +804,11 @@ fn process_initialize_counter( Після того, як акаунт створено, ми ініціалізуємо дані акаунту за допомогою: -1. Створення нової структури `CounterAccount` з переданим значенням `initial_value`. +1. Створення нової структури `CounterAccount` з переданим значенням + `initial_value`. 2. Отримання змінної посилання на поле даних нового акаунту. -3. Серіалізації структури `CounterAccount` в поле даних акаунту, - що ефективно зберігає значення `initial_value` в акаунті. +3. Серіалізації структури `CounterAccount` в поле даних акаунту, що ефективно + зберігає значення `initial_value` в акаунті. ```rs filename="lib.rs" {35-44} /initial_value/ fn process_initialize_counter( @@ -893,22 +918,24 @@ fn process_initialize_counter( } ``` -Далі додайте реалізацію функції `process_increment_counter`. Ця -інструкція збільшує значення існуючого акаунту лічильника. +Далі додайте реалізацію функції `process_increment_counter`. Ця інструкція +збільшує значення існуючого акаунту лічильника. -Так само, як і в функції `process_initialize_counter`, ми починаємо з створення ітератора -по акаунтах. У цьому випадку ми очікуємо лише один акаунт, який є акаунтом, що має бути оновлений. +Так само, як і в функції `process_initialize_counter`, ми починаємо з створення +ітератора по акаунтах. У цьому випадку ми очікуємо лише один акаунт, який є +акаунтом, що має бути оновлений. -Зверніть увагу, що на практиці розробник повинен реалізувати різні перевірки безпеки для -валідності акаунтів, переданих до програми. Оскільки всі акаунти надаються викликачем інструкції, -немає гарантії, що надані акаунти — це саме ті акаунти, які програма очікує. Відсутність перевірок -валідності акаунтів є поширеним джерелом вразливостей програми. +Зверніть увагу, що на практиці розробник повинен реалізувати різні перевірки +безпеки для валідності акаунтів, переданих до програми. Оскільки всі акаунти +надаються викликачем інструкції, немає гарантії, що надані акаунти — це саме ті +акаунти, які програма очікує. Відсутність перевірок валідності акаунтів є +поширеним джерелом вразливостей програми. -Наведений приклад містить перевірку для того, щоб переконатися, що акаунт, на який ми посилаємось як -`counter_account`, належить виконуючій програмі. +Наведений приклад містить перевірку для того, щоб переконатися, що акаунт, на +який ми посилаємось як `counter_account`, належить виконуючій програмі. ```rs filename="lib.rs" {6-9} // Update an existing counter's value @@ -999,8 +1026,8 @@ fn process_increment_counter(program_id: &Pubkey, accounts: &[AccountInfo]) -> P ### Тестування інструкцій -Для тестування інструкцій програми додайте наступні залежності до -файлу `Cargo.toml`. +Для тестування інструкцій програми додайте наступні залежності до файлу +`Cargo.toml`. ```shell filename="Terminal" cargo add solana-program-test@1.18.26 --dev @@ -1008,9 +1035,9 @@ cargo add solana-sdk@1.18.26 --dev cargo add tokio --dev ``` -Далі додайте наступний тестовий модуль до файлу `lib.rs` і виконайте команду `cargo test-sbf` для -запуску тестів. За бажанням, використовуйте прапорець `--nocapture`, щоб побачити -виведені дані в результатах. +Далі додайте наступний тестовий модуль до файлу `lib.rs` і виконайте команду +`cargo test-sbf` для запуску тестів. За бажанням, використовуйте прапорець +`--nocapture`, щоб побачити виведені дані в результатах. ```shell filename="Термінал" cargo test-sbf -- --nocapture @@ -1040,9 +1067,9 @@ mod test { } ``` -Далі налаштуйте тест за допомогою `ProgramTest`. Потім створіть нову ключову пару, яку будемо використовувати як -адресу для акаунту лічильника, який ми ініціалізуємо, і визначте початкове значення, -яке встановимо для лічильника. +Далі налаштуйте тест за допомогою `ProgramTest`. Потім створіть нову ключову +пару, яку будемо використовувати як адресу для акаунту лічильника, який ми +ініціалізуємо, і визначте початкове значення, яке встановимо для лічильника. ```rs filename="lib.rs" #[cfg(test)] @@ -1091,7 +1118,8 @@ AccountMeta::new_readonly(account4_pubkey, true), // writable, signer Для тестування інструкції ініціалізації: -- Створіть дані інструкції з варіантом 0 (`InitializeCounter`) та початковим значенням +- Створіть дані інструкції з варіантом 0 (`InitializeCounter`) та початковим + значенням - Побудуйте інструкцію з ID програми, даними інструкції та необхідними акаунтами - Відправте транзакцію з інструкцією ініціалізації - Перевірте, що акаунт був створений з правильним початковим значенням @@ -1160,8 +1188,8 @@ AccountMeta::new_readonly(account4_pubkey, true), // writable, signer - Перевірте, що акаунт був збільшений до правильного значення Зверніть увагу, що дані інструкції для інструкції збільшення — це `[1]`, що -відповідає варіанту 1 (`IncrementCounter`). Оскільки інструкція збільшення не має додаткових -параметрів, дані — це просто варіант інструкції. +відповідає варіанту 1 (`IncrementCounter`). Оскільки інструкція збільшення не +має додаткових параметрів, дані — це просто варіант інструкції. ```rs filename="lib.rs" {55-82} #[tokio::test] diff --git a/docs/locales/uk/programs/testing.md b/docs/locales/uk/programs/testing.md index 663653121..2ec9784b0 100644 --- a/docs/locales/uk/programs/testing.md +++ b/docs/locales/uk/programs/testing.md @@ -1,48 +1,76 @@ --- title: "Тестування з NodeJS" -description: "Тестування нативних solana programs написаних Rust використовуючи NodeJS" +description: + "Тестування нативних solana programs написаних Rust використовуючи NodeJS" sidebarSortOrder: 5 --- ## Тестування з NodeJS -Коли ви розробляєте програми на Solana, важливо забезпечити їхню правильність і надійність. До цього часу розробники використовували `solana-test-validator` для тестування. Цей документ описує тестування вашої програми Solana за допомогою Node.js і бібліотеки `solana-bankrun`. +Коли ви розробляєте програми на Solana, важливо забезпечити їхню правильність і +надійність. До цього часу розробники використовували `solana-test-validator` для +тестування. Цей документ описує тестування вашої програми Solana за допомогою +Node.js і бібліотеки `solana-bankrun`. ## Огляд Є два способи тестування програм на Solana: -1. [solana-test-validator](https://docs.anza.xyz/cli/examples/test-validator): Локальний емулятор блокчейна Solana, який обробляє транзакції, що надсилаються на валідацію. -2. Різні фреймворки для тестування програм SBF (Solana Bytecode Format) на базі BanksClient: - - `Bankrun` — це фреймворк, що імітує роботу Solana bank, дозволяючи розробникам розгортати програми, взаємодіяти з ними та оцінювати їх поведінку у тестових умовах, що нагадують mainnet. - - Підтримуються фреймворки як [solana-program-test](https://docs.rs/solana-program-test) (Rust), [solana-bankrun](https://github.com/kevinheavey/solana-bankrun) (Rust, JavaScript), [anchor-bankrun](https://www.npmjs.com/package/anchor-bankrun) (Anchor, JavaScript), [solders.bankrun](https://kevinheavey.github.io/solders/api_reference/bankrun.html) (Python). +1. [solana-test-validator](https://docs.anza.xyz/cli/examples/test-validator): + Локальний емулятор блокчейна Solana, який обробляє транзакції, що + надсилаються на валідацію. +2. Різні фреймворки для тестування програм SBF (Solana Bytecode Format) на базі + BanksClient: + - `Bankrun` — це фреймворк, що імітує роботу Solana bank, дозволяючи + розробникам розгортати програми, взаємодіяти з ними та оцінювати їх + поведінку у тестових умовах, що нагадують mainnet. + - Підтримуються фреймворки як + [solana-program-test](https://docs.rs/solana-program-test) (Rust), + [solana-bankrun](https://github.com/kevinheavey/solana-bankrun) (Rust, + JavaScript), [anchor-bankrun](https://www.npmjs.com/package/anchor-bankrun) + (Anchor, JavaScript), + [solders.bankrun](https://kevinheavey.github.io/solders/api_reference/bankrun.html) + (Python). > [`pnpm create solana-program`](https://github.com/solana-program/create-solana-program) -> може допомогти створити клієнти для JS і Rust, включаючи тести. Anchor ще не підтримується. +> може +> допомогти створити клієнти для JS і Rust, включаючи тести. Anchor ще не +> підтримується. У цьому керівництві ми використовуємо `Solana Bankrun`. -`Bankrun` — це дуже швидкий, потужний та легкий фреймворк для тестування програм Solana у Node.js. +`Bankrun` — це дуже швидкий, потужний та легкий фреймворк для тестування програм +Solana у Node.js. -- Основна перевага використання `Solana Bankrun` полягає в тому, що вам не потрібно налаштовувати середовище для тестування програм, як це потрібно при використанні `solana-test-validator`. Це можна зробити за допомогою коду всередині тестів. -- `Bankrun` динамічно встановлює час та дані акаунтів, що неможливо при використанні `solana-test-validator`. +- Основна перевага використання `Solana Bankrun` полягає в тому, що вам не + потрібно налаштовувати середовище для тестування програм, як це потрібно при + використанні `solana-test-validator`. Це можна зробити за допомогою коду + всередині тестів. +- `Bankrun` динамічно встановлює час та дані акаунтів, що неможливо при + використанні `solana-test-validator`. ## Інсталяція -Додайте `solana-bankrun` як dev-залежність до вашого Node.js проекту. Якщо ваша Solana програма ще не є Node.js проектом, ви можете ініціалізувати її за допомогою команди `npm init`: +Додайте `solana-bankrun` як dev-залежність до вашого Node.js проекту. Якщо ваша +Solana програма ще не є Node.js проектом, ви можете ініціалізувати її за +допомогою команди `npm init`: ```bash npm i -D solana-bankrun ``` + ## Використання ### Директорія для Програми -Перш за все, `.so` файл вашої програми повинен бути присутнім в одній із наступних директорій: +Перш за все, `.so` файл вашої програми повинен бути присутнім в одній із +наступних директорій: - `./tests/fixtures` (створіть цю директорію, якщо її ще не існує). - Ваша поточна робоча директорія. -- Директорія, яку ви визначите в змінних середовища `BPF_OUT_DIR` або `SBF_OUT_DIR`. - Наприклад: +- Директорія, яку ви визначите в змінних середовища `BPF_OUT_DIR` або + `SBF_OUT_DIR`. + Наприклад: + ```json { "scripts": { @@ -50,9 +78,12 @@ npm i -D solana-bankrun } } ``` + ### Початок Роботи -Функція `start` з бібліотеки `solana-bankrun` запускає `BanksServer` і `BanksClient`, розгортає програми та додає акаунти відповідно до ваших інструкцій. +Функція `start` з бібліотеки `solana-bankrun` запускає `BanksServer` і +`BanksClient`, розгортає програми та додає акаунти відповідно до ваших +інструкцій. Приклад використання: @@ -69,12 +100,22 @@ test("testing program instruction", async () => { // write tests }); ``` + ### `context` у Bankrun -- Ми отримуємо доступ до `context` з функції `start`. `context` містить `BanksClient`, останній blockhash та профінансовану keypair для підпису транзакцій. -- У `context` є `payer`, який є профінансованою парою ключів і може використовуватися для підпису транзакцій. -- `context` також містить `context.lastBlockhash` або `context.getLatestBlockhash`, що спрощує отримання [Blockhash](https://solana.com/docs/terminology#blockhash) під час тестів. -- `context.banksClient` використовується для надсилання транзакцій і отримання даних акаунтів зі стану реєстру. Наприклад, іноді потрібна [оренда (Rent)](https://solana.com/docs/terminology#rent) (в лампортах) для створення транзакції, наприклад, при використанні інструкції `createAccount()` з `SystemProgram`. Це можна зробити за допомогою `BanksClient`: +- Ми отримуємо доступ до `context` з функції `start`. `context` містить + `BanksClient`, останній blockhash та профінансовану keypair для підпису + транзакцій. +- У `context` є `payer`, який є профінансованою парою ключів і може + використовуватися для підпису транзакцій. +- `context` також містить `context.lastBlockhash` або + `context.getLatestBlockhash`, що спрощує отримання + [Blockhash](https://solana.com/docs/terminology#blockhash) під час тестів. +- `context.banksClient` використовується для надсилання транзакцій і отримання + даних акаунтів зі стану реєстру. Наприклад, іноді потрібна + [оренда (Rent)](https://solana.com/docs/terminology#rent) (в лампортах) для + створення транзакції, наприклад, при використанні інструкції `createAccount()` + з `SystemProgram`. Це можна зробити за допомогою `BanksClient`: ```typescript const rent = await client.getRent(); @@ -85,7 +126,9 @@ test("testing program instruction", async () => { //.... }); ``` -- Ви можете зчитувати дані акаунта з `BanksClient`, використовуючи функцію `getAccount`. + +- Ви можете зчитувати дані акаунта з `BanksClient`, використовуючи функцію + `getAccount`. ```typescript AccountInfo = await client.getAccount(counter); @@ -93,17 +136,19 @@ test("testing program instruction", async () => { ### Обробка Транзакції -Функція `processTransaction()` виконує транзакцію з використанням завантажених програм і акаунтів, отриманих із функції `start`. Вона повертає результат виконаної транзакції. +Функція `processTransaction()` виконує транзакцію з використанням завантажених +програм і акаунтів, отриманих із функції `start`. Вона повертає результат +виконаної транзакції. ```typescript let transaction = await client.processTransaction(tx); ``` + ## Приклад Ось приклад тесту для програми [hello world](https://github.com/solana-developers/program-examples/tree/main/basics/hello-solana/native): - ```typescript import { PublicKey, @@ -158,6 +203,7 @@ describe("hello-solana", async () => { }); }); ``` + Ось як виглядає результат після запуску тестів для [hello world програми](https://github.com/solana-developers/program-examples/tree/main/basics/hello-solana/native): diff --git a/docs/locales/uk/rpc.md b/docs/locales/uk/rpc.md index e8e6582a6..d63508930 100644 --- a/docs/locales/uk/rpc.md +++ b/docs/locales/uk/rpc.md @@ -4,7 +4,7 @@ sidebarSortOrder: 1 isSkippedInNav: true --- -Цей файл не повинен редагуватися, оскільки він не призначений для відображення. Він існує лише для створення посилання в головній бічній панелі документації. +Цей файл не повинен редагуватися, оскільки він не призначений для відображення. +Він існує лише для створення посилання в головній бічній панелі документації. -Документація JSON RPC для Solana доступна в -[`rpc` каталозі](./rpc/) +Документація JSON RPC для Solana доступна в [`rpc` каталозі](./rpc/) diff --git a/docs/locales/uk/terminology.md b/docs/locales/uk/terminology.md index 39d74a750..5a06d576d 100644 --- a/docs/locales/uk/terminology.md +++ b/docs/locales/uk/terminology.md @@ -11,23 +11,28 @@ keywords: isSkippedInNav: true --- -Наведені нижче терміни використовуються в документації Solana та екосистемі розробки. +Наведені нижче терміни використовуються в документації Solana та екосистемі +розробки. ## Обліковий запис (account) Запис у реєстрі Solana, який або зберігає дані, або є виконуваною програмою. -Як і обліковий запис у традиційному банку, обліковий запис Solana може зберігати кошти, які називаються [лампортами](#lamport). Як файл у Linux, він адресується ключем, часто згадуваним як [публічний ключ](#public-key-pubkey) або pubkey. +Як і обліковий запис у традиційному банку, обліковий запис Solana може зберігати +кошти, які називаються [лампортами](#lamport). Як файл у Linux, він адресується +ключем, часто згадуваним як [публічний ключ](#public-key-pubkey) або pubkey. Ключ може бути одним із таких: - Публічний ключ ed25519 -- Адреса облікового запису, отримана програмно (32-байтне значення поза кривою ed25519) +- Адреса облікового запису, отримана програмно (32-байтне значення поза кривою + ed25519) - Хеш публічного ключа ed25519 із рядком із 32 символів ## Власник облікового запису (account owner) -Адреса програми, якій належить обліковий запис. Тільки програма-власник може змінювати обліковий запис. +Адреса програми, якій належить обліковий запис. Тільки програма-власник може +змінювати обліковий запис. Див. також [Повноваження](#authority). @@ -41,28 +46,39 @@ isSkippedInNav: true Наприклад: -- Можливість карбування нових токенів надається обліковому запису, який є "владою карбування" токена. -- Можливість оновлювати програму надається обліковому запису, який є "владою оновлення" програми. +- Можливість карбування нових токенів надається обліковому запису, який є + "владою карбування" токена. +- Можливість оновлювати програму надається обліковому запису, який є "владою + оновлення" програми. ## Стан банку (bank state) -Результат виконання всіх програм у реєстрі на певній [висоті тікання](#tick-height). Він включає щонайменше набір усіх [облікових записів](#account), які зберігають ненульові [нативні токени](#native-token). +Результат виконання всіх програм у реєстрі на певній +[висоті тікання](#tick-height). Він включає щонайменше набір усіх +[облікових записів](#account), які зберігають ненульові +[нативні токени](#native-token). ## Блок (block) -Неперервний набір [записів](#entry) у реєстрі, підтверджений [голосуванням](#ledger-vote). [Лідер](#leader) створює не більше одного блоку за [слот](#slot). +Неперервний набір [записів](#entry) у реєстрі, підтверджений +[голосуванням](#ledger-vote). [Лідер](#leader) створює не більше одного блоку за +[слот](#slot). ## Блокхеш (blockhash) -Унікальне значення ([хеш](#hash)), яке ідентифікує запис (блок). Solana обчислює блокхеш із останнього [ідентифікатора запису](#entry-id) блоку. +Унікальне значення ([хеш](#hash)), яке ідентифікує запис (блок). Solana обчислює +блокхеш із останнього [ідентифікатора запису](#entry-id) блоку. ## Висота блоку (block height) -Кількість [блоків](#block) під поточним блоком. Перший блок після [генезис-блоку](#genesis-block) має висоту один. +Кількість [блоків](#block) під поточним блоком. Перший блок після +[генезис-блоку](#genesis-block) має висоту один. ## Завантажувач BPF (BPF loader) -Програма Solana, яка завантажує [програми на основі BPF](/docs/uk/core/programs#berkeley-packet-filter-bpf) в [блокчейн](#onchain-program), дозволяючи їм взаємодіяти з середовищем виконання. +Програма Solana, яка завантажує +[програми на основі BPF](/docs/uk/core/programs#berkeley-packet-filter-bpf) в +[блокчейн](#onchain-program), дозволяючи їм взаємодіяти з середовищем виконання. ## Клієнт (client) @@ -78,7 +94,8 @@ isSkippedInNav: true ## Бюджет обчислень (compute budget) -Максимальна кількість [обчислювальних одиниць](#compute-units), спожитих за транзакцію. +Максимальна кількість [обчислювальних одиниць](#compute-units), спожитих за +транзакцію. ## Обчислювальні одиниці (compute units) @@ -86,11 +103,13 @@ isSkippedInNav: true ## Час підтвердження (confirmation time) -Час, який пройшов між створенням [тікового запису](#tick) [лідером](#leader) та створенням [підтвердженого блоку](#confirmed-block). +Час, який пройшов між створенням [тікового запису](#tick) [лідером](#leader) та +створенням [підтвердженого блоку](#confirmed-block). ## Підтверджений блок (confirmed block) -[Блок](#block), який отримав [супербільшість](#supermajority) [голосів реєстру](#ledger-vote). +[Блок](#block), який отримав [супербільшість](#supermajority) +[голосів реєстру](#ledger-vote). ## Площина керування (control plane) @@ -98,7 +117,9 @@ isSkippedInNav: true ## Період охолодження (cooldown period) -Декілька [епох](#epoch) після деактивації [ставки](#stake), протягом яких вона поступово стає доступною для зняття. Під час цього періоду ставка вважається "деактивованою". Докладніше: +Декілька [епох](#epoch) після деактивації [ставки](#stake), протягом яких вона +поступово стає доступною для зняття. Під час цього періоду ставка вважається +"деактивованою". Докладніше: [періоди прогріву та охолодження](https://docs.anza.xyz/implemented-proposals/staking-rewards#stake-warmup-cooldown-withdrawal). ## Кредит (credit) @@ -107,23 +128,28 @@ isSkippedInNav: true ## Виклик між програмами (CPI) -Виклик однієї [програми на блокчейні](#onchain-program) до іншої. Докладніше див. [Виклик між програмами](/docs/uk/core/cpi.md). +Виклик однієї [програми на блокчейні](#onchain-program) до іншої. Докладніше +див. [Виклик між програмами](/docs/uk/core/cpi.md). ## Площина даних (data plane) -Мультикаст-мережа, яка використовується для ефективної перевірки [записів](#entry) і досягнення консенсусу. +Мультикаст-мережа, яка використовується для ефективної перевірки +[записів](#entry) і досягнення консенсусу. ## Дрон (drone) -Зовнішній сервіс, який виступає в ролі хранителя приватного ключа користувача. Зазвичай використовується для перевірки та підпису транзакцій. +Зовнішній сервіс, який виступає в ролі хранителя приватного ключа користувача. +Зазвичай використовується для перевірки та підпису транзакцій. ## Запис (entry) -Запис у [реєстрі](#ledger), який може бути або [тіком](#tick), або [записом транзакції](#transactions-entry). +Запис у [реєстрі](#ledger), який може бути або [тіком](#tick), або +[записом транзакції](#transactions-entry). ## Ідентифікатор запису (entry id) -Хеш ([hash](#hash)), стійкий до попереднього зображення, який є унікальним ідентифікатором [запису](#entry). Хеш слугує доказом: +Хеш ([hash](#hash)), стійкий до попереднього зображення, який є унікальним +ідентифікатором [запису](#entry). Хеш слугує доказом: - Генерації запису після певного проміжку часу - Включення зазначених [транзакцій](#transaction) у запис @@ -133,19 +159,25 @@ isSkippedInNav: true ## Епоха (epoch) -Проміжок часу, визначений кількістю [слотів](#slot), протягом яких діє [розклад лідерів](#leader-schedule). +Проміжок часу, визначений кількістю [слотів](#slot), протягом яких діє +[розклад лідерів](#leader-schedule). ## Обліковий запис для комісій (fee account) -Обліковий запис у транзакції, який оплачує вартість включення транзакції до реєстру. Це перший обліковий запис у транзакції. Він має бути оголошений як читально-записуваний (writable), оскільки оплата транзакції зменшує баланс облікового запису. +Обліковий запис у транзакції, який оплачує вартість включення транзакції до +реєстру. Це перший обліковий запис у транзакції. Він має бути оголошений як +читально-записуваний (writable), оскільки оплата транзакції зменшує баланс +облікового запису. ## Фінальність (finality) -Стан, коли вузли, що представляють 2/3 [ставки](#stake), мають спільний [корінь](#root). +Стан, коли вузли, що представляють 2/3 [ставки](#stake), мають спільний +[корінь](#root). ## Форк (fork) -[Реєстр](#ledger), створений на основі загальних записів, але який розійшовся у своєму розвитку. +[Реєстр](#ledger), створений на основі загальних записів, але який розійшовся у +своєму розвитку. ## Генезис-блок (genesis block) @@ -153,7 +185,8 @@ isSkippedInNav: true ## Генезис-конфігурація (genesis config) -Файл конфігурації, який підготовлює [реєстр](#ledger) для [генезис-блоку](#genesis-block). +Файл конфігурації, який підготовлює [реєстр](#ledger) для +[генезис-блоку](#genesis-block). ## Хеш (hash) @@ -161,7 +194,8 @@ isSkippedInNav: true ## Інфляція (inflation) -Збільшення кількості токенів із часом, яке використовується для фінансування винагород за валідацію та подальшого розвитку Solana. +Збільшення кількості токенів із часом, яке використовується для фінансування +винагород за валідацію та подальшого розвитку Solana. ## Внутрішня інструкція (inner instruction) @@ -169,66 +203,96 @@ isSkippedInNav: true ## Інструкція (instruction) -Виклик для запуску конкретного [обробника інструкцій](#instruction-handler) у [програмі](#program). Інструкція також вказує, які облікові записи потрібно прочитати або змінити, та додаткові дані, які слугують допоміжним вхідним параметром для [обробника інструкцій](#instruction-handler). Кожна [транзакція](#transaction) має містити принаймні одну інструкцію. +Виклик для запуску конкретного [обробника інструкцій](#instruction-handler) у +[програмі](#program). Інструкція також вказує, які облікові записи потрібно +прочитати або змінити, та додаткові дані, які слугують допоміжним вхідним +параметром для [обробника інструкцій](#instruction-handler). Кожна +[транзакція](#transaction) має містити принаймні одну інструкцію. ## Обробник інструкцій (instruction handler) -Функції [програм](#program), які обробляють [інструкції](#instruction) із [транзакцій](#transaction). Обробник інструкцій може містити одну або кілька [викликів між програмами](#cross-program-invocation-cpi). +Функції [програм](#program), які обробляють [інструкції](#instruction) із +[транзакцій](#transaction). Обробник інструкцій може містити одну або кілька +[викликів між програмами](#cross-program-invocation-cpi). ## Пара ключів (keypair) -[Публічний ключ](#public-key-pubkey) і відповідний [приватний ключ](#private-key), які використовуються для доступу до облікового запису. +[Публічний ключ](#public-key-pubkey) і відповідний +[приватний ключ](#private-key), які використовуються для доступу до облікового +запису. ## Лампорти (lamport) -Дробова одиниця [нативного токена](#native-token) із вартістю 0.000000001 [SOL](#sol). +Дробова одиниця [нативного токена](#native-token) із вартістю 0.000000001 +[SOL](#sol). > У межах бюджету обчислень використовується кількість -> _[мікролампортів](https://github.com/solana-labs/solana/blob/ced8f6a512c61e0dd5308095ae8457add4a39e94/program-runtime/src/prioritization_fee.rs#L1-L2)_ для розрахунку [пріоритетної комісії](#prioritization-fee). +> _[мікролампортів](https://github.com/solana-labs/solana/blob/ced8f6a512c61e0dd5308095ae8457add4a39e94/program-runtime/src/prioritization_fee.rs#L1-L2)_ +> для розрахунку [пріоритетної комісії](#prioritization-fee). ## Лідер (leader) -Роль [валідатора](#validator), який додає [записи](#entry) до [реєстру](#ledger). +Роль [валідатора](#validator), який додає [записи](#entry) до +[реєстру](#ledger). ## Розклад лідерів (leader schedule) -Послідовність [публічних ключів](#public-key-pubkey) [валідаторів](#validator), пов’язаних із [слотами](#slot). Кластер використовує цей розклад, щоб визначити, який валідатор є [лідером](#leader) у певний момент часу. +Послідовність [публічних ключів](#public-key-pubkey) [валідаторів](#validator), +пов’язаних із [слотами](#slot). Кластер використовує цей розклад, щоб визначити, +який валідатор є [лідером](#leader) у певний момент часу. ## Реєстр (ledger) -Список [записів](#entry), що містять [транзакції](#transaction), підписані [клієнтами](#client). Концептуально це можна простежити до [генезис-блоку](#genesis-block), але реєстр конкретного [валідатора](#validator) може містити лише новіші [блоки](#block), щоб зменшити обсяг зберігання, оскільки старіші блоки не потрібні для перевірки майбутніх блоків за задумом. +Список [записів](#entry), що містять [транзакції](#transaction), підписані +[клієнтами](#client). Концептуально це можна простежити до +[генезис-блоку](#genesis-block), але реєстр конкретного [валідатора](#validator) +може містити лише новіші [блоки](#block), щоб зменшити обсяг зберігання, +оскільки старіші блоки не потрібні для перевірки майбутніх блоків за задумом. ## Голос у реєстрі (ledger vote) -[Хеш](#hash) стану [валідатора](#validator) на певній [висоті тікання](#tick-height). Він включає підтвердження валідатора, що [блок](#block), який він отримав, був перевірений, а також обіцянку не голосувати за конфліктуючий [блок](#block) (тобто [форк](#fork)) протягом певного часу, відомого як період [блокування](#lockout). +[Хеш](#hash) стану [валідатора](#validator) на певній +[висоті тікання](#tick-height). Він включає підтвердження валідатора, що +[блок](#block), який він отримав, був перевірений, а також обіцянку не +голосувати за конфліктуючий [блок](#block) (тобто [форк](#fork)) протягом +певного часу, відомого як період [блокування](#lockout). ## Легкий клієнт (light client) -Тип [клієнта](#client), який може перевірити, що він підключений до валідного [кластеру](#cluster). Він виконує більше перевірок реєстру, ніж [тонкий клієнт](#thin-client), але менше, ніж [валідатор](#validator). +Тип [клієнта](#client), який може перевірити, що він підключений до валідного +[кластеру](#cluster). Він виконує більше перевірок реєстру, ніж +[тонкий клієнт](#thin-client), але менше, ніж [валідатор](#validator). ## Завантажувач (loader) -[Програма](#program) із можливістю інтерпретувати двійкове кодування інших програм на блокчейні. +[Програма](#program) із можливістю інтерпретувати двійкове кодування інших +програм на блокчейні. ## Блокування (lockout) -Тривалість часу, протягом якої [валідатор](#validator) не може [голосувати](#ledger-vote) за інший [форк](#fork). +Тривалість часу, протягом якої [валідатор](#validator) не може +[голосувати](#ledger-vote) за інший [форк](#fork). ## Повідомлення (message) -Структурований вміст [транзакції](#transaction), зазвичай містить заголовок, масив адрес облікових записів, недавній [блокхеш](#blockhash) та масив [інструкцій](#instruction). +Структурований вміст [транзакції](#transaction), зазвичай містить заголовок, +масив адрес облікових записів, недавній [блокхеш](#blockhash) та масив +[інструкцій](#instruction). Докладніше про [форматування повідомлень у транзакціях](/docs/uk/core/transactions.md#message-header). ## Коефіцієнт Накамото (Nakamoto coefficient) -Міра децентралізації, яка визначає найменшу кількість незалежних суб’єктів, що можуть колективно зупинити блокчейн. Термін запропонований Балажі С. Срінівасаном і Леландом Лі у статті +Міра децентралізації, яка визначає найменшу кількість незалежних суб’єктів, що +можуть колективно зупинити блокчейн. Термін запропонований Балажі С. +Срінівасаном і Леландом Лі у статті [Quantifying Decentralization](https://news.earn.com/quantifying-decentralization-e39db233c28e). ## Нативний токен (native token) -[Токен](#token), що використовується для відстеження роботи [вузлів](#node) у кластері. +[Токен](#token), що використовується для відстеження роботи [вузлів](#node) у +кластері. ## Вузол (node) @@ -240,7 +304,10 @@ isSkippedInNav: true ## Програма на блокчейні (onchain program) -Виконуваний код у блокчейні Solana, який інтерпретує [інструкції](#instruction), надіслані в кожній [транзакції](#transaction), щоб читати та змінювати облікові записи, якими він управляє. Ці програми часто називають "[розумними контрактами](/docs/uk/core/programs.md)" на інших блокчейнах. +Виконуваний код у блокчейні Solana, який інтерпретує [інструкції](#instruction), +надіслані в кожній [транзакції](#transaction), щоб читати та змінювати облікові +записи, якими він управляє. Ці програми часто називають +"[розумними контрактами](/docs/uk/core/programs.md)" на інших блокчейнах. ## PoH (Proof of History) @@ -248,7 +315,10 @@ isSkippedInNav: true ## Окуляр (point) -Зважений [кредит](#credit) у системі винагород. У системі [винагород валідатора](https://docs.anza.xyz/consensus/stake-delegation-and-rewards) кількість очок, що належить [ставці](#stake), є добутком [голосових кредитів](#vote-credit) і кількості лампортів, що були поставлені. +Зважений [кредит](#credit) у системі винагород. У системі +[винагород валідатора](https://docs.anza.xyz/consensus/stake-delegation-and-rewards) +кількість очок, що належить [ставці](#stake), є добутком +[голосових кредитів](#vote-credit) і кількості лампортів, що були поставлені. ## Програма (program) @@ -256,7 +326,8 @@ isSkippedInNav: true ## Програмно отриманий обліковий запис (PDA) -Обліковий запис, підписуючою владою якого є програма, і тому він не контролюється приватним ключем, як інші облікові записи. +Обліковий запис, підписуючою владою якого є програма, і тому він не +контролюється приватним ключем, як інші облікові записи. ## Ідентифікатор програми (program id) @@ -264,15 +335,22 @@ isSkippedInNav: true ## Доказ історії (Proof of History, PoH) -Стек доказів, кожен із яких підтверджує, що певні дані існували до моменту створення доказу і що пройшов точний проміжок часу до попереднього доказу. Як і [перевірювана функція затримки (VDF)](#verifiable-delay-function-vdf), Proof of History може бути перевірений швидше, ніж його створення. +Стек доказів, кожен із яких підтверджує, що певні дані існували до моменту +створення доказу і що пройшов точний проміжок часу до попереднього доказу. Як і +[перевірювана функція затримки (VDF)](#verifiable-delay-function-vdf), Proof of +History може бути перевірений швидше, ніж його створення. ## Пріоритетна комісія (prioritization fee) -Додаткова комісія, яку користувач може вказати в інструкції бюджету обчислень, щоб пріоритизувати свої [транзакції](#transaction). +Додаткова комісія, яку користувач може вказати в інструкції бюджету обчислень, +щоб пріоритизувати свої [транзакції](#transaction). -Пріоритетна комісія розраховується шляхом множення запитаного максимуму обчислювальних одиниць на ціну обчислювальної одиниці (вказується в інтервалах 0.000001 лампорта за одиницю), округлену до найближчого лампорта. +Пріоритетна комісія розраховується шляхом множення запитаного максимуму +обчислювальних одиниць на ціну обчислювальної одиниці (вказується в інтервалах +0.000001 лампорта за одиницю), округлену до найближчого лампорта. -Транзакції повинні запитувати мінімальну кількість обчислювальних одиниць, необхідних для виконання, щоб зменшити комісію. +Транзакції повинні запитувати мінімальну кількість обчислювальних одиниць, +необхідних для виконання, щоб зменшити комісію. ## Публічний ключ (public key, pubkey) @@ -280,49 +358,80 @@ isSkippedInNav: true ## Оренда (rent) -Комісія, яку сплачують [облікові записи](#account) і [програми](#program) за зберігання даних у блокчейні. Якщо на рахунку недостатньо балансу для оплати оренди, він може бути видалений. +Комісія, яку сплачують [облікові записи](#account) і [програми](#program) за +зберігання даних у блокчейні. Якщо на рахунку недостатньо балансу для оплати +оренди, він може бути видалений. -Див. також [звільнення від оренди](#rent-exempt). Докладніше про оренду: [Що таке оренда?](/docs/uk/intro/rent.md). +Див. також [звільнення від оренди](#rent-exempt). Докладніше про оренду: +[Що таке оренда?](/docs/uk/intro/rent.md). ## Звільнення від оренди (rent exempt) -Облікові записи, які підтримують мінімальний баланс лампортів, пропорційний кількості даних, що зберігаються в обліковому записі. Усі нові облікові записи зберігаються на блокчейні постійно, доки обліковий запис не буде закрито. Неможливо створити обліковий запис, який не відповідає порогу звільнення від оренди. +Облікові записи, які підтримують мінімальний баланс лампортів, пропорційний +кількості даних, що зберігаються в обліковому записі. Усі нові облікові записи +зберігаються на блокчейні постійно, доки обліковий запис не буде закрито. +Неможливо створити обліковий запис, який не відповідає порогу звільнення від +оренди. ## Корінь (root) -[Блок](#block) або [слот](#slot), який досяг максимального [блокування](#lockout) у [валідатора](#validator). Корінь є найвищим блоком, який є предком усіх активних форків у валідатора. Усі предкові блоки кореня також транзитивно є коренями. Блоки, які не є предками чи нащадками кореня, виключаються з розгляду для консенсусу і можуть бути відкинуті. +[Блок](#block) або [слот](#slot), який досяг максимального +[блокування](#lockout) у [валідатора](#validator). Корінь є найвищим блоком, +який є предком усіх активних форків у валідатора. Усі предкові блоки кореня +також транзитивно є коренями. Блоки, які не є предками чи нащадками кореня, +виключаються з розгляду для консенсусу і можуть бути відкинуті. ## Середовище виконання (runtime) -Компонент [валідатора](#validator), відповідальний за виконання [програм](#program). +Компонент [валідатора](#validator), відповідальний за виконання +[програм](#program). ## Sealevel -Паралельне середовище виконання Solana для [програм на блокчейні](#onchain-program). +Паралельне середовище виконання Solana для +[програм на блокчейні](#onchain-program). ## Шред (shred) -Фрагмент [блоку](#block); найменша одиниця, яка передається між [валідаторами](#validator). +Фрагмент [блоку](#block); найменша одиниця, яка передається між +[валідаторами](#validator). ## Підпис (signature) -64-байтний підпис ed25519, що складається з R (32 байти) і S (32 байти). Цей підпис забезпечує відсутність можливості модифікації (мальованості). Кожна транзакція повинна мати щонайменше один підпис для [облікового запису комісій](#fee-account). Таким чином, перший підпис у транзакції може використовуватися як [ідентифікатор транзакції](#transaction-id). +64-байтний підпис ed25519, що складається з R (32 байти) і S (32 байти). Цей +підпис забезпечує відсутність можливості модифікації (мальованості). Кожна +транзакція повинна мати щонайменше один підпис для +[облікового запису комісій](#fee-account). Таким чином, перший підпис у +транзакції може використовуватися як +[ідентифікатор транзакції](#transaction-id). ## Рівень пропуску (skip rate) -Відсоток [пропущених слотів](#skipped-slot) від загальної кількості слотів лідера в поточній епосі. Ця метрика може бути оманливою через високу варіативність після межі епохи, коли вибірка невелика, а також для валідаторів із малою кількістю слотів лідера. Однак вона може бути корисною для виявлення неправильних конфігурацій вузлів. +Відсоток [пропущених слотів](#skipped-slot) від загальної кількості слотів +лідера в поточній епосі. Ця метрика може бути оманливою через високу +варіативність після межі епохи, коли вибірка невелика, а також для валідаторів +із малою кількістю слотів лідера. Однак вона може бути корисною для виявлення +неправильних конфігурацій вузлів. ## Пропущений слот (skipped slot) -Минулий [слот](#slot), у якому не було створено [блоку](#block), тому що лідер був офлайн або [форк](#fork), що містить цей слот, був залишений на користь кращого варіанту за консенсусом кластера. Пропущений слот не з’явиться як предок для блоків у наступних слотах, не збільшить [висоту блоку](#block-height) і не призведе до прострочення найстарішого `recent_blockhash`. +Минулий [слот](#slot), у якому не було створено [блоку](#block), тому що лідер +був офлайн або [форк](#fork), що містить цей слот, був залишений на користь +кращого варіанту за консенсусом кластера. Пропущений слот не з’явиться як предок +для блоків у наступних слотах, не збільшить [висоту блоку](#block-height) і не +призведе до прострочення найстарішого `recent_blockhash`. -Чи було пропущено слот, можна визначити лише тоді, коли він стає старішим за останній [корінний](#root) (а отже, не пропущений) слот. +Чи було пропущено слот, можна визначити лише тоді, коли він стає старішим за +останній [корінний](#root) (а отже, не пропущений) слот. ## Слот (slot) -Проміжок часу, протягом якого кожен [лідер](#leader) приймає транзакції та створює [блок](#block). +Проміжок часу, протягом якого кожен [лідер](#leader) приймає транзакції та +створює [блок](#block). -Колективно слоти створюють логічний годинник. Слоти упорядковані послідовно та не перекриваються, охоплюючи приблизно однакові інтервали реального часу відповідно до [PoH](#proof-of-history-poh). +Колективно слоти створюють логічний годинник. Слоти упорядковані послідовно та +не перекриваються, охоплюючи приблизно однакові інтервали реального часу +відповідно до [PoH](#proof-of-history-poh). ## Розумний контракт (smart contract) @@ -334,15 +443,18 @@ isSkippedInNav: true ## Бібліотека програм Solana (SPL) -[Бібліотека програм](https://spl.solana.com/) на Solana, таких як spl-token, що сприяють виконанню завдань, як-от створення та використання токенів. +[Бібліотека програм](https://spl.solana.com/) на Solana, таких як spl-token, що +сприяють виконанню завдань, як-от створення та використання токенів. ## Ставка (stake) -Токени, які можуть бути конфісковані [кластером](#cluster), якщо буде доведено зловмисну поведінку [валідатора](#validator). +Токени, які можуть бути конфісковані [кластером](#cluster), якщо буде доведено +зловмисну поведінку [валідатора](#validator). ## Якість обслуговування з урахуванням ставки (stake-weighted quality of service, SWQoS) -SWQoS дозволяє [надавати перевагу транзакціям, які надходять від валідаторів із поставленими токенами](https://solana.com/developers/guides/advanced/stake-weighted-qos). +SWQoS дозволяє +[надавати перевагу транзакціям, які надходять від валідаторів із поставленими токенами](https://solana.com/developers/guides/advanced/stake-weighted-qos). ## Супербільшість (supermajority) @@ -350,11 +462,16 @@ SWQoS дозволяє [надавати перевагу транзакціям ## Системна змінна (sysvar) -Системний [обліковий запис](#account). [Системні змінні (Sysvars)](https://docs.anza.xyz/runtime/sysvars) надають інформацію про стан кластера, наприклад поточну висоту тіку, значення винагород [очок](#point) тощо. Програми можуть отримати доступ до системних змінних через обліковий запис Sysvar (публічний ключ) або запитати через системний виклик. +Системний [обліковий запис](#account). +[Системні змінні (Sysvars)](https://docs.anza.xyz/runtime/sysvars) надають +інформацію про стан кластера, наприклад поточну висоту тіку, значення винагород +[очок](#point) тощо. Програми можуть отримати доступ до системних змінних через +обліковий запис Sysvar (публічний ключ) або запитати через системний виклик. ## Тонкий клієнт (thin client) -Тип [клієнта](#client), який довіряє, що він підключений до дійсного [кластеру](#cluster). +Тип [клієнта](#client), який довіряє, що він підключений до дійсного +[кластеру](#cluster). ## Тік (tick) @@ -370,15 +487,21 @@ N-тий [тік](#tick) у [реєстрі](#ledger). ## Програма розширення токенів (Token Extensions Program) -[Програма розширення токенів](https://spl.solana.com/token-2022) має ідентифікатор `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb` і включає всі ті самі функції, що й [Програма токенів](#token-program), але додає розширення, як-от конфіденційні перекази, кастомна логіка переказу, розширені метадані тощо. +[Програма розширення токенів](https://spl.solana.com/token-2022) має +ідентифікатор `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb` і включає всі ті +самі функції, що й [Програма токенів](#token-program), але додає розширення, +як-от конфіденційні перекази, кастомна логіка переказу, розширені метадані тощо. ## Карбування токенів (token mint) -Обліковий запис, який може створювати токени. Різні токени відрізняються за унікальними адресами карбування токенів. +Обліковий запис, який може створювати токени. Різні токени відрізняються за +унікальними адресами карбування токенів. ## Програма токенів (Token Program) -[Програма токенів](https://spl.solana.com/token) має ідентифікатор `TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA` і надає базові можливості передачі, заморожування та карбування токенів. +[Програма токенів](https://spl.solana.com/token) має ідентифікатор +`TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA` і надає базові можливості +передачі, заморожування та карбування токенів. ## TPS @@ -390,15 +513,21 @@ N-тий [тік](#tick) у [реєстрі](#ledger). ## Транзакція (transaction) -Одна або кілька [інструкцій](#instruction), підписаних [клієнтом](#client) за допомогою однієї або кількох [пар ключів](#keypair), виконуються атомарно з двома можливими результатами: успіх або невдача. +Одна або кілька [інструкцій](#instruction), підписаних [клієнтом](#client) за +допомогою однієї або кількох [пар ключів](#keypair), виконуються атомарно з +двома можливими результатами: успіх або невдача. ## Ідентифікатор транзакції (transaction id) -Перший [підпис](#signature) у [транзакції](#transaction), який можна використовувати для унікальної ідентифікації транзакції у повному [реєстрі](#ledger). +Перший [підпис](#signature) у [транзакції](#transaction), який можна +використовувати для унікальної ідентифікації транзакції у повному +[реєстрі](#ledger). ## Підтвердження транзакції (transaction confirmations) -Кількість [підтверджених блоків](#confirmed-block) з моменту прийняття транзакції до [реєстру](#ledger). Транзакція завершується, коли її блок стає [коренем](#root). +Кількість [підтверджених блоків](#confirmed-block) з моменту прийняття +транзакції до [реєстру](#ledger). Транзакція завершується, коли її блок стає +[коренем](#root). ## Запис транзакцій (transactions entry) @@ -410,7 +539,8 @@ N-тий [тік](#tick) у [реєстрі](#ledger). ## Валідатор (validator) -Повноцінний учасник мережі Solana, який створює нові [блоки](#block). Валідатор перевіряє транзакції, додані до [реєстру](#ledger). +Повноцінний учасник мережі Solana, який створює нові [блоки](#block). Валідатор +перевіряє транзакції, додані до [реєстру](#ledger). ## VDF @@ -418,7 +548,9 @@ N-тий [тік](#tick) у [реєстрі](#ledger). ## Перевірювана функція затримки (VDF) -Функція, яка займає фіксований проміжок часу для виконання та генерує доказ, що вона виконалася. Цей доказ можна перевірити швидше, ніж час, необхідний для його створення. +Функція, яка займає фіксований проміжок часу для виконання та генерує доказ, що +вона виконалася. Цей доказ можна перевірити швидше, ніж час, необхідний для його +створення. ## Голос (vote) @@ -426,13 +558,18 @@ N-тий [тік](#tick) у [реєстрі](#ledger). ## Кредит голосування (vote credit) -Нарахування винагороди для [валідаторів](#validator). Кредит голосування присуджується валідатору на його рахунок голосування, коли він досягає [кореня](#root). +Нарахування винагороди для [валідаторів](#validator). Кредит голосування +присуджується валідатору на його рахунок голосування, коли він досягає +[кореня](#root). ## Гаманець (wallet) -Набір [пар ключів](#keypair), який дозволяє користувачам керувати своїми коштами. +Набір [пар ключів](#keypair), який дозволяє користувачам керувати своїми +коштами. ## Період прогріву (warmup period) -Декілька [епох](#epoch) після делегування [ставки](#stake), протягом яких вона поступово стає активною. Під час цього періоду ставка вважається "активованою". Докладніше: +Декілька [епох](#epoch) після делегування [ставки](#stake), протягом яких вона +поступово стає активною. Під час цього періоду ставка вважається "активованою". +Докладніше: [періоди прогріву та охолодження](https://docs.anza.xyz/consensus/stake-delegation-and-rewards#stake-warmup-cooldown-withdrawal).